From mw_triad at users.sourceforge.net Tue Dec 1 01:24:26 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 30 Nov 2009 19:24:26 -0600 Subject: [RFA] Your [PACKAGE_NAME] did not pass QA In-Reply-To: <4cea600cd03ede0378323808f52fa436.squirrel@arekh.dyndns.org> References: <870180fe0911230851m316090dem984d1d307baf996@mail.gmail.com> <1259002133.7011.29.camel@arekh.okg> <1259010811.9312.546.camel@adam.local.net> <1259011741.9748.54.camel@arekh.okg> <1259013053.9312.549.camel@adam.local.net> <4B0BDCFD.7090803@fetzig.org> <20091124150031.GA1423294@hiwaay.net> <20091124160143.GB1423294@hiwaay.net> <4cea600cd03ede0378323808f52fa436.squirrel@arekh.dyndns.org> Message-ID: Nicolas Mailhot wrote: > When i18n asked what was the exact need for bitmap-fonts no one answered. Legibility? I don't know about font systems, is Terminuis a "core font"? It is bitmapped, but I don't know if that automatically makes it a "core font". -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Do not expose to extreme heat, cold, or open flame. From huzaifas at redhat.com Tue Dec 1 05:26:05 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Tue, 01 Dec 2009 10:56:05 +0530 Subject: [Heads up] goffice = 0.7.16 in rawhide Message-ID: <4B14A8ED.70707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I put updated goffice to 0.7.16 in rawhide. It will affect three packages namely gnumeric, gnu-cash and gnu-chemistry-utils. I am going to update gnumeric to the lastest soon, and i am sure gnu-cash and gnu-chemistry-utils is ready to handle the updated goffice-devel. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLFKjtzHDc8tpb2uURAqiHAJ4kXIOzSTnookfK662euyIlT9fkSACeL8Xo bMZ6hcJXr3le/oNwpxrktzo= =SyJY -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Tue Dec 1 07:12:27 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 01 Dec 2009 08:12:27 +0100 Subject: [RFA] Your [PACKAGE_NAME] did not pass QA In-Reply-To: References: <870180fe0911230851m316090dem984d1d307baf996@mail.gmail.com> <1259002133.7011.29.camel@arekh.okg> <1259010811.9312.546.camel@adam.local.net> <1259011741.9748.54.camel@arekh.okg> <1259013053.9312.549.camel@adam.local.net> <4B0BDCFD.7090803@fetzig.org> <20091124150031.GA1423294@hiwaay.net> <20091124160143.GB1423294@hiwaay.net> <4cea600cd03ede0378323808f52fa436.squirrel@arekh.dyndns.org> Message-ID: <1259651547.5846.2.camel@arekh.okg> Le lundi 30 novembre 2009 ? 19:24 -0600, Matthew Woehlke a ?crit : > Nicolas Mailhot wrote: > > When i18n asked what was the exact need for bitmap-fonts no one > answered. Bitmap-fonts is an exact package name installed by default for no reason anyone would justify > Legibility? > > I don't know about font systems, is Terminuis a "core font"? It is > bitmapped, but I don't know if that automatically makes it a "core > font". It does not make it automatically a "core font". Look, people, either take my word core fonts are bad, and induce maintenance, or make the effort to document yourself. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Tue Dec 1 07:50:15 2009 From: dcbw at redhat.com (Dan Williams) Date: Mon, 30 Nov 2009 23:50:15 -0800 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B142260.4010604@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> Message-ID: <1259653815.13178.2.camel@localhost.localdomain> On Mon, 2009-11-30 at 19:52 +0000, Terry Barnaby wrote: > On 11/30/2009 06:12 PM, Dan Williams wrote: > > On Mon, 2009-11-30 at 09:55 +0000, Terry Barnaby wrote: > >> On 11/29/2009 11:30 PM, Dan Williams wrote: > >>> On Sat, 2009-11-28 at 09:10 +0000, Terry Barnaby wrote: > >>>> On 11/28/2009 08:35 AM, Rakesh Pandit wrote: > >>>>> 2009/11/28 Terry Barnaby wrote: > >>>>>> If the NetworkManager service is running, but not managing the current > >>>>>> network connection, then Firefox starts up in offline mode. > >>>>>> > >>>>>> Is this a bug in NetworkManager or Firefox ? > >>>>>> > >>>>> > >>>>> This is odd behaviour and needs to be fixed. I would suggest open up a > >>>>> bug against firefox. I know one can change > >>>>> toolkit.networkmanager.disable preference, but it is a PITA for our > >>>>> users. One of use cases is: Sometime network manager does not connect > >>>>> me via my CDMA usb modem (in case signal is weak), but wvdial does and > >>>>> once I switch from NM to wvdial, my firefox gets to offline mode, > >>>>> which I don't expect it to as I am connected. > >>>>> > >>>> Ok, filed as: 542078 > >>> > >>> NetworkManager is intended to control the default internet connection. > >>> If NetworkManager cannot control the default internet connection, then > >>> you may not want to use NetworkManager. > >>> > >>> In your case, you're using a mobile broadband device. The real bug here > >>> is that for whatever reason, NM/MM aren't connecting your modem, and we > >>> should follow up on that bug instead. > >>> > >>> Dan > >>> > >> I am not using a mobile broadband device. The network connection my systems > > > > My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G > > connection. > > > >> use is not just the Internet it is a local network LAN connection that also > >> serves the internet. Most of my systems use a local network server which > >> provides NIS, /home and /data using NFS and VPN etc. I normally use the > >> service "network" to bring up wired or wireless networking for this. Fedora, > >> by default, uses NetworkManager to manage all network devices though. I use > >> the service "network" as, for some reason, the NetworkManager service is > >> started after the netfs and other services are started. Is there a reason > >> for this ?? > > > > No particular reason, in fact that looks like a bug. NM no longer > > depends on HAL, but that dependency is still in the initscript, which > > looks like it pushes NM later than netfs. > > > > But in reality, you're looking for a dependency based initsystem which > > we don't quite yet have. There are already scripts that kick netfs to > > mount stuff when NM brings the network up > > (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous > > bootup *and* your mounts. The rest of the system, if it requires > > something from the mounted directories, needs to be smart enough to know > > that. > > > > If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network, > > which causes the NetworkManager initscript to block until a network > > connection is brought up, or 30 seconds have passed. > > > >> I can obviously turn of the NetworkManager service, which I have done on the > >> desktop systems. However, I also have a few Laptops that can roam. In F11 and > >> before I have used the network and NetworkManager services. When the laptop > >> boots away from home, the "network" service fails and I can then use the > >> NetworkManager service to connect to whatever wireless network or G3 network is > >> available. > >> > >> It does seem sensible to me that the "system" provides applications with info > >> on if the network is up (not just the Internet). The NetworkManager service > >> seems the place to do this and it looks like the applications are starting > >> to use it for this purpose. > >> So maybe a generic NM "isNetworkUp()" API call is called for ? > > > > See the other mail; the problem with a generic isUp() is that it simply > > says hey, is there a connection? It doesn't provide enough information > > about the networking state of the system for anything to make an > > intelligent decision about anything. It's a "hey I'm connected to > > something" but there's no information about *what* you're connected to; > > whether it's a secure home network, whether it's a slow 3G network, > > whether it's billed by the minute or the hour or unlimited, etc. > > > > Dan > > > Hi, Thanks for the info. > I would have thought that a generic isUp() is good enough for the likes > of Firefox and Pidgen though to decide if to start offline. Being connected to a > Network is probably all you need, you may be accessing an Intranet as all > my systems Firefox home pages do ... > > Anyway, following your email (And notes in Bugzilla) I thought I'd try and > use NM properly for my config. However I have a problem, which may be > a bug. I have turned off the Network services and turned on NetworkManger. > I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are > set to be managed by NM and to start at boot. I have also added > NETWORKWAIT=yes in /etc/sysconfig/network. > > When I boot with this the network (eth1 (eth0 is disconnected)) does not > come up at boot. There is a message stating a failure on the line > where it is waiting for the network to come up. When I log in as a > local user the network then comes up ... > > I also note that, before the user is logged in, I cannot start the network > with "service network start" and the WiFi light is off. It looks like > NM has done something like powered down my WiFi chip ? > (Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52) > > Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled. > Maybe ypbind should be modified to not start when the network is down and > also added to /etc/NetworkManager/dispatcher.d ? NM has two types of connection: system and user (see http://live.gnome.org/NetworkManagerConfiguration ). NM treats ifcfg files as system connections and thus they are available at boot time and before login. I had assumed that since your connection was working correctly with the 'network' service that it was also a system connection. What is the result of 'ls /etc/sysconfig/network-scripts/ifcfg-*' and what are the contents of /var/log/messages when the device is not correctly connected on bootup? Before logging in, can you also drop to a VT, log in, and run 'nm-tool' for me? THanks, Dan From terry1 at beam.ltd.uk Tue Dec 1 10:24:33 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Tue, 01 Dec 2009 10:24:33 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <1259653815.13178.2.camel@localhost.localdomain> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> Message-ID: <4B14EEE1.2000802@beam.ltd.uk> On 12/01/2009 07:50 AM, Dan Williams wrote: > On Mon, 2009-11-30 at 19:52 +0000, Terry Barnaby wrote: >> On 11/30/2009 06:12 PM, Dan Williams wrote: >>> On Mon, 2009-11-30 at 09:55 +0000, Terry Barnaby wrote: >>>> On 11/29/2009 11:30 PM, Dan Williams wrote: >>>>> On Sat, 2009-11-28 at 09:10 +0000, Terry Barnaby wrote: >>>>>> On 11/28/2009 08:35 AM, Rakesh Pandit wrote: >>>>>>> 2009/11/28 Terry Barnaby wrote: >>>>>>>> If the NetworkManager service is running, but not managing the current >>>>>>>> network connection, then Firefox starts up in offline mode. >>>>>>>> >>>>>>>> Is this a bug in NetworkManager or Firefox ? >>>>>>>> >>>>>>> >>>>>>> This is odd behaviour and needs to be fixed. I would suggest open up a >>>>>>> bug against firefox. I know one can change >>>>>>> toolkit.networkmanager.disable preference, but it is a PITA for our >>>>>>> users. One of use cases is: Sometime network manager does not connect >>>>>>> me via my CDMA usb modem (in case signal is weak), but wvdial does and >>>>>>> once I switch from NM to wvdial, my firefox gets to offline mode, >>>>>>> which I don't expect it to as I am connected. >>>>>>> >>>>>> Ok, filed as: 542078 >>>>> >>>>> NetworkManager is intended to control the default internet connection. >>>>> If NetworkManager cannot control the default internet connection, then >>>>> you may not want to use NetworkManager. >>>>> >>>>> In your case, you're using a mobile broadband device. The real bug here >>>>> is that for whatever reason, NM/MM aren't connecting your modem, and we >>>>> should follow up on that bug instead. >>>>> >>>>> Dan >>>>> >>>> I am not using a mobile broadband device. The network connection my systems >>> >>> My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G >>> connection. >>> >>>> use is not just the Internet it is a local network LAN connection that also >>>> serves the internet. Most of my systems use a local network server which >>>> provides NIS, /home and /data using NFS and VPN etc. I normally use the >>>> service "network" to bring up wired or wireless networking for this. Fedora, >>>> by default, uses NetworkManager to manage all network devices though. I use >>>> the service "network" as, for some reason, the NetworkManager service is >>>> started after the netfs and other services are started. Is there a reason >>>> for this ?? >>> >>> No particular reason, in fact that looks like a bug. NM no longer >>> depends on HAL, but that dependency is still in the initscript, which >>> looks like it pushes NM later than netfs. >>> >>> But in reality, you're looking for a dependency based initsystem which >>> we don't quite yet have. There are already scripts that kick netfs to >>> mount stuff when NM brings the network up >>> (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous >>> bootup *and* your mounts. The rest of the system, if it requires >>> something from the mounted directories, needs to be smart enough to know >>> that. >>> >>> If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network, >>> which causes the NetworkManager initscript to block until a network >>> connection is brought up, or 30 seconds have passed. >>> >>>> I can obviously turn of the NetworkManager service, which I have done on the >>>> desktop systems. However, I also have a few Laptops that can roam. In F11 and >>>> before I have used the network and NetworkManager services. When the laptop >>>> boots away from home, the "network" service fails and I can then use the >>>> NetworkManager service to connect to whatever wireless network or G3 network is >>>> available. >>>> >>>> It does seem sensible to me that the "system" provides applications with info >>>> on if the network is up (not just the Internet). The NetworkManager service >>>> seems the place to do this and it looks like the applications are starting >>>> to use it for this purpose. >>>> So maybe a generic NM "isNetworkUp()" API call is called for ? >>> >>> See the other mail; the problem with a generic isUp() is that it simply >>> says hey, is there a connection? It doesn't provide enough information >>> about the networking state of the system for anything to make an >>> intelligent decision about anything. It's a "hey I'm connected to >>> something" but there's no information about *what* you're connected to; >>> whether it's a secure home network, whether it's a slow 3G network, >>> whether it's billed by the minute or the hour or unlimited, etc. >>> >>> Dan >>> >> Hi, Thanks for the info. >> I would have thought that a generic isUp() is good enough for the likes >> of Firefox and Pidgen though to decide if to start offline. Being connected to a >> Network is probably all you need, you may be accessing an Intranet as all >> my systems Firefox home pages do ... >> >> Anyway, following your email (And notes in Bugzilla) I thought I'd try and >> use NM properly for my config. However I have a problem, which may be >> a bug. I have turned off the Network services and turned on NetworkManger. >> I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are >> set to be managed by NM and to start at boot. I have also added >> NETWORKWAIT=yes in /etc/sysconfig/network. >> >> When I boot with this the network (eth1 (eth0 is disconnected)) does not >> come up at boot. There is a message stating a failure on the line >> where it is waiting for the network to come up. When I log in as a >> local user the network then comes up ... >> >> I also note that, before the user is logged in, I cannot start the network >> with "service network start" and the WiFi light is off. It looks like >> NM has done something like powered down my WiFi chip ? >> (Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52) >> >> Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled. >> Maybe ypbind should be modified to not start when the network is down and >> also added to /etc/NetworkManager/dispatcher.d ? > > NM has two types of connection: system and user (see > http://live.gnome.org/NetworkManagerConfiguration ). NM treats ifcfg > files as system connections and thus they are available at boot time and > before login. I had assumed that since your connection was working > correctly with the 'network' service that it was also a system > connection. What is the result of > 'ls /etc/sysconfig/network-scripts/ifcfg-*' and what are the contents > of /var/log/messages when the device is not correctly connected on > bootup? > > Before logging in, can you also drop to a VT, log in, and run 'nm-tool' > for me? > > THanks, > Dan > > Hi Dan, As far as I am aware my connections are "system" connections. I have configured the Network interfaces using the system-config-network tool. When I use the "network" service the eth1 wireless network comes up fine at boot. When I use NetworkManager the eth1 wireless network does not come up at boot. There is the error: "Waiting for network... [FAILED]" If the NetworkManger service is running (eth1 has not come up) and I run "service network start" the eth1 interface still does not come up. If I stop the NetworkManger service and again run "service network start" then the eth1 interface comes up ... The configuration files are: /etc/sysconfig/network-scripts/ifcfg-* files are there: /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1 /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/network-scripts/ifcfg-Vodaphone /etc/sysconfig/network-scripts/ifcfg-eth1 is: # Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection DEVICE=eth1 HWADDR=00:16:6F:8A:E1:95 ONBOOT=yes BOOTPROTO=dhcp TYPE=Wireless NM_CONTROLLED=yes USERCTL=yes PEERDNS=yes IPV6INIT=no MODE=Auto RATE=auto ESSID=beamwifi CHANNEL= Section of /var/log/messages attached. Output of nm-tool attached. nm-tool also outputs the error on stderr: ** (process:1492): WARNING **: error: failed to read connections from org.freedesktop.NetworkManagerUserSettings: The name org.freedesktop.NetworkManagerUserSettings was not provided by any .service files Cheers Terry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: messages.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nm-tool.txt URL: From promac at gmail.com Tue Dec 1 10:34:29 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 1 Dec 2009 08:34:29 -0200 Subject: Pulseaudio in F12 In-Reply-To: <20091130113601.2555b2f2@leela> References: <68720af30911290658u5beb38cbqd697c5afb0df899a@mail.gmail.com> <68720af30911290753qb339958t4a1db690bfe39172@mail.gmail.com> <20d6441a0911290826t55e26fcet838582b2429770fc@mail.gmail.com> <68720af30911300105i7b0e401bgdbefee18c6070d55@mail.gmail.com> <20091130103815.483d1ca5@leela> <20091130111238.4eee6b93@gmail.com> <20091130113601.2555b2f2@leela> Message-ID: <68720af30912010234o30cb7dedw3f9f53b58319a945@mail.gmail.com> On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt wrote: > Dne Mon, 30 Nov 2009 11:12:38 +0100 Michael Schwendt napsal(a): > > On Mon, 30 Nov 2009 10:38:15 +0100, Michal wrote: > > > > > Dne Mon, 30 Nov 2009 07:05:28 -0200 Paulo Cavalcanti napsal(a): > > > > Thanks for the explanation. > > > > > > > > At least 3 applications are not restoring the volumes: > > > > > > > > xmms, mplayer and audacious. > > > > > > Interesting. Maybe these programs try to be too clever and force the > > > volume themselves. > > > > It's not an attempt at being "too clever", but several upstream > > developers feel lost in what they have to do or what they have not to > > do to get something right. Temporarily, Audacious devlopers have > > dropped their "pulse_audio" driver (originally from XMMS) even, since > > they were of the impression that "it didn't work anyway". Ubuntu > > users currently feel punished with Pulse Audio. With a first bunch of > > fixes [for volume issues in Fedora 12 Rawhide, volume decreased for > > every new song], the driver was restored again for Audacious 2.2 > > development. With more recent changes in Pulse Audio, it seems, more > > changes are necessary. But Audacious 2.1 cannot reflect external > > volume level changes in its UI anyway. Its volume slider cannot move > > for volume level changes made with external tools. Only the next > > release can do that, and it suffers from new bugs (such as a bug in > > alsa-lib that will require an update in Fedora, too). > > Thanks for the explanation. Before I saw your reply, I played with > audacious-plugins and made a kludge to prevent it from forcing 100 % > volume on startup. It probably breaks something else, I haven't really > tested it too much. > > Notice that the documentation for pa_stream_connect_playback strongly > recommends passing NULL as volume. > > Index: audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c > =================================================================== > --- audacious-plugins-fedora-2.1.orig/src/pulse_audio/pulse_audio.c > +++ audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c > @@ -666,7 +666,7 @@ static int pulse_open(AFormat fmt, int r > pa_stream_set_write_callback(stream, stream_request_cb, NULL); > pa_stream_set_latency_update_callback(stream, stream_latency_update_cb, > NULL); > > - if (pa_stream_connect_playback(stream, NULL, NULL, > PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, &volume, NULL) < > 0) { > + if (pa_stream_connect_playback(stream, NULL, NULL, > PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, NULL, NULL) < 0) > { > AUDDBG("Failed to connect stream: %s", > pa_strerror(pa_context_errno(context))); > goto unlock_and_fail; > } > @@ -715,6 +715,7 @@ static int pulse_open(AFormat fmt, int r > } > > pa_operation_unref(o); > +#if 0 > /* set initial volume */ > if (!(o = pa_context_set_sink_input_volume(context, > pa_stream_get_index(stream), &volume, NULL, NULL))) { > g_warning("pa_context_set_sink_input_volume() failed: %s", > pa_strerror(pa_context_errno(context))); > @@ -725,6 +726,7 @@ static int pulse_open(AFormat fmt, int r > pa_threaded_mainloop_wait(mainloop); > } > pa_operation_unref(o); > +#endif > > do_trigger = 0; > written = 0; > > > Your patch almost worked. Audacious starts at the right volume level. However, when audacious volume slider is hit for the first time, the volume goes to the maximum again. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Tue Dec 1 10:48:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 1 Dec 2009 11:48:02 +0100 Subject: Pulseaudio in F12 In-Reply-To: <68720af30912010234o30cb7dedw3f9f53b58319a945@mail.gmail.com> References: <68720af30911290658u5beb38cbqd697c5afb0df899a@mail.gmail.com> <68720af30911290753qb339958t4a1db690bfe39172@mail.gmail.com> <20d6441a0911290826t55e26fcet838582b2429770fc@mail.gmail.com> <68720af30911300105i7b0e401bgdbefee18c6070d55@mail.gmail.com> <20091130103815.483d1ca5@leela> <20091130111238.4eee6b93@gmail.com> <20091130113601.2555b2f2@leela> <68720af30912010234o30cb7dedw3f9f53b58319a945@mail.gmail.com> Message-ID: <20091201114802.089a810a@gmail.com> On Tue, 1 Dec 2009 08:34:29 -0200, Paulo wrote: > On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt wrote: > [patch] > Your patch almost worked. Audacious starts at the right volume level. > However, when audacious volume slider is hit for the first time, > the volume goes to the maximum again. I've explained that earlier in the thread. Audacious' volume slider does not reflect volume level changes made with external tools. Only with Audacious 2.2 that will become possible. [That also means that when you start Audacious, it does not know what volume level to show with its volume slider as it hasn't connected with Pulse Audio yet.] From rakesh.pandit at gmail.com Tue Dec 1 11:19:09 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 1 Dec 2009 16:49:09 +0530 Subject: Package Review Stats for last 7 days ending 29th Nov Message-ID: Top four FAS account holders who have completed reviewing "Package review" components on bugzilla for last 7 days ending 29th Nov were Steve Traylen, Andreas Osowski, Jiri Popelka and Mamoru Tasaka. Steve Traylen : 4 https://bugzilla.redhat.com/show_bug.cgi?id=516523 https://bugzilla.redhat.com/show_bug.cgi?id=516525 https://bugzilla.redhat.com/show_bug.cgi?id=516531 https://bugzilla.redhat.com/show_bug.cgi?id=516535 Andreas Osowski : 3 https://bugzilla.redhat.com/show_bug.cgi?id=529254 https://bugzilla.redhat.com/show_bug.cgi?id=529255 https://bugzilla.redhat.com/show_bug.cgi?id=529256 Jiri Popelka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=226106 https://bugzilla.redhat.com/show_bug.cgi?id=226206 https://bugzilla.redhat.com/show_bug.cgi?id=226665 Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=515230 https://bugzilla.redhat.com/show_bug.cgi?id=540791 https://bugzilla.redhat.com/show_bug.cgi?id=541185 Lubomir Rintel : 2 https://bugzilla.redhat.com/show_bug.cgi?id=536684 https://bugzilla.redhat.com/show_bug.cgi?id=537451 Parag AN(????) : 2 https://bugzilla.redhat.com/show_bug.cgi?id=541317 https://bugzilla.redhat.com/show_bug.cgi?id=539486 Peter Lemenkov : 2 https://bugzilla.redhat.com/show_bug.cgi?id=537897 https://bugzilla.redhat.com/show_bug.cgi?id=537563 Andrew Overholt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=510195 Antti Andreimann : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541004 Caolan McNamara : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541533 Chitlesh GOORAH : 1 https://bugzilla.redhat.com/show_bug.cgi?id=538087 Christof Damian : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529544 David Timms : 1 https://bugzilla.redhat.com/show_bug.cgi?id=508922 Jan Zeleny : 1 https://bugzilla.redhat.com/show_bug.cgi?id=175840 Jochen Schmitt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=538046 Kalev Lember : 1 https://bugzilla.redhat.com/show_bug.cgi?id=523224 Kevin Fenzi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541154 Matthew Kent : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539606 Michael Schwendt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533803 Michal Ingeli : 1 https://bugzilla.redhat.com/show_bug.cgi?id=534135 Michal Nowak : 1 https://bugzilla.redhat.com/show_bug.cgi?id=226423 Petr Machata : 1 https://bugzilla.redhat.com/show_bug.cgi?id=225789 Remi Collet : 1 https://bugzilla.redhat.com/show_bug.cgi?id=528469 Ryan Rix : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533765 Thomas Janssen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=526444 Total reviews modified: 37 Merge Reviews: 5 Review Requests: 32 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first From mrunge at matthias-runge.de Tue Dec 1 11:53:01 2009 From: mrunge at matthias-runge.de (Matthias Runge) Date: Tue, 01 Dec 2009 12:53:01 +0100 Subject: Review request - django-lint Message-ID: <4B15039D.5080303@matthias-runge.de> Hi everybody, just a few days ago I've made a package django-lint. rpmlint is happy, koji builder too. https://bugzilla.redhat.com/show_bug.cgi?id=540617 I'd be glad, if someone is willing and able to support me, since it's my first packet. Cheers, Matthias From rawhide at fedoraproject.org Tue Dec 1 13:46:37 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 1 Dec 2009 13:46:37 +0000 Subject: rawhide report: 20091201 changes Message-ID: <20091201134637.GA25675@releng2.fedora.phx.redhat.com> Compose started at Tue Dec 1 08:15:10 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 blacs-mpich2-1.1-33.fc12.i686 requires libmpich.so.1.1 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 evolution-exchange-2.28.0-1.fc12.i686 requires libexchange-storage-1.2.so.3 galeon-2.0.7-19.fc13.i686 requires gecko-libs = 0:1.9.1.5 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnucash-2.2.9-2.fc12.i686 requires libgoffice-0.6.so.6 1:gnumeric-1.8.4-5.fc13.i686 requires libgoffice-0.6.so.6 1:gnumeric-devel-1.8.4-5.fc13.i686 requires pkgconfig(libgoffice-0.6) hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.i686 requires libortp.so.7 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 maniadrive-1.2-18.fc12.i686 requires libphp5-5.3.0.so maniadrive-track-editor-1.2-18.fc12.i686 requires libphp5-5.3.0.so monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 postgis-jdbc-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 postgis-utils-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 raydium-1.2-18.fc12.i686 requires libphp5-5.3.0.so rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.i686 requires libmpich.so.1.1 1:xmms-1.2.11-9.20071117cvs.fc12.i686 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) blacs-mpich2-1.1-33.fc12.x86_64 requires libmpich.so.1.1()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) evolution-exchange-2.28.0-1.fc12.x86_64 requires libexchange-storage-1.2.so.3()(64bit) galeon-2.0.7-19.fc13.x86_64 requires gecko-libs = 0:1.9.1.5 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnome-chemistry-utils-0.10.9-1.fc13.x86_64 requires libgoffice-0.6.so.6()(64bit) gnucash-2.2.9-2.fc12.x86_64 requires libgoffice-0.6.so.6()(64bit) 1:gnumeric-1.8.4-5.fc13.i686 requires libgoffice-0.6.so.6 1:gnumeric-1.8.4-5.fc13.x86_64 requires libgoffice-0.6.so.6()(64bit) 1:gnumeric-devel-1.8.4-5.fc13.i686 requires pkgconfig(libgoffice-0.6) 1:gnumeric-devel-1.8.4-5.fc13.x86_64 requires pkgconfig(libgoffice-0.6) hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.x86_64 requires libortp.so.7()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) maniadrive-1.2-18.fc12.x86_64 requires libphp5-5.3.0.so()(64bit) maniadrive-track-editor-1.2-18.fc12.x86_64 requires libphp5-5.3.0.so()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) postgis-jdbc-1.4.1-rc2_1.fc13.1.x86_64 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 postgis-utils-1.4.1-rc2_1.fc13.1.x86_64 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 raydium-1.2-18.fc12.i686 requires libphp5-5.3.0.so raydium-1.2-18.fc12.x86_64 requires libphp5-5.3.0.so()(64bit) rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.x86_64 requires libmpich.so.1.1()(64bit) 1:xmms-1.2.11-9.20071117cvs.fc12.x86_64 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop New package mingw32-libgeotiff GeoTIFF format library New package perl-Config-Model-CursesUI Curses interface to edit config data New package pycryptopp Python wrappers for the Crypto++ library Removed package perl-XML-LibXML-Common Updated Packages: ClanLib06-0.6.5-16.fc13 ----------------------- * Sun Nov 29 2009 Hans de Goede 0.6.5-16 - ClanLib06 used a hardcoded keycode table (lame), these have changed for some keys with us moving over to evdev, breaking the usage of these keys. Fix this by switching over to dynamically querying the X-server for keycodes - Add a number of missing defines for non alpha-numerical keys - Fix some abuse of iterators - Remove smpflags, as that results in somehow broken libs (apps using them crash on exit ?) GtkAda-2.14.0-3.fc13 -------------------- * Mon Nov 30 2009 Bj?rn Persson - 2.14.0-3 - Enabled debug information. * Sun Nov 29 2009 Bj?rn Persson - 2.14.0-2 - Fixed project files and gtkada-config for multilib systems. - Marked the doc subpackage as noarch. ImageMagick-6.5.4.7-4.fc13 -------------------------- * Mon Nov 30 2009 Pavel Alexeev - 6.5.4.7-4 - Explude file Generic.ttf from -perl subpackage demos. Demos perfectly work without it, but with bundled font package does not pass QA (Unfortunately no bugreport there, only mail from Nicolas Mailhot) SimGear-1.9.1-9.fc13 -------------------- * Sun Nov 29 2009 Fabrice Bellet 1.9.1-9 - Fix osgParticle dependency (bz#542132) TurboGears-1.0.9-1.fc13 ----------------------- * Mon Nov 30 2009 Toshio Kuratomi - 1.0.8-8 - Fix problem with sql create and sqlobject * Mon Nov 30 2009 Toshio Kuratomi - 1.0.9-1 - Update to 1.0.9 bugfix release. - Paginate fix is in upstream. atari++-1.58-1.fc13.1 --------------------- * Mon Nov 30 2009 Dan Hor?k 1.58-1 - updated to version 1.58 - used better patch for the making the build output verbose * Mon Nov 30 2009 Dan Hor?k 1.58-1.1 - rebuilt with updated source archive atk-1.29.3-1.fc13 ----------------- * Mon Nov 30 2009 Matthias Clasen - 1.29.3-1 - Update to 1.29.3 augeas-0.6.0-1.fc13 ------------------- * Mon Nov 30 2009 David Lutterkort - 0.6.0-1 - Install vim syntax files avr-libc-1.6.7-2.fc13 --------------------- * Mon Nov 30 2009 Thibault North 1.6.5-2 - Rebuild with new avr-gcc cdrdao-1.2.3-1.fc13 ------------------- * Mon Nov 30 2009 Nikola Pajkovsky - 1.2.3-1 - new upstream chunkd-0.6-0.1.gcf9b95c8.fc13 ----------------------------- * Mon Nov 30 2009 Jeff Garzik - 0.6-0.1.gcf9b95c8 - update source to commit cf9b95c883437690793976564936c1ef0b249368 cjkuni-fonts-0.2.20080216.1-34.fc13 ----------------------------------- * Tue Dec 01 2009 Caius 'kaio' Chance - 0.2.20080216.1-32 - Mailhot's font audit: - Add obsolete package versions. - Add default attributes. - Remove symlinks. * Tue Dec 01 2009 Caius 'kaio' Chance - 0.2.20080216.1-33 - Remove -compat. * Tue Dec 01 2009 Caius 'kaio' Chance - 0.2.20080216.1-34 - rebuild cld-0.3-0.6.g50fcd615.fc13 -------------------------- * Mon Nov 30 2009 Jeff Garzik - 0.3-0.6.g50fcd615 - update to 0.3git commit 50fcd61590984c3c12f5584069da98bc8f4aec0f * Sun Nov 29 2009 Jeff Garzik - 0.3-0.5.g70268c35 - update to 0.3git commit 70268c3568db1e024f8adcdc399cbe235832ea17 dx-4.4.4-12.fc13 ---------------- emacs-23.1-14.fc13 ------------------ * Mon Nov 30 2009 Daniel Novotny 1:23.1-14 - fixed FTBFS in F12 and higher (#540921) empathy-2.29.3-1.fc13 --------------------- * Mon Nov 30 2009 Brian Pepple - 2.29.3-1 - Update to 2.29.3. - Drop nautilus sendto plugin linking patch. Fixed upstream. - Drop broken NetworkManager patch. Fixed upstream. enscript-1.6.4-15.fc13 ---------------------- * Mon Nov 30 2009 Adam Tkac - 1.6.4-15 - ship postscript files with .eps extension (#505775) - merge review fixes (#225729) - improve enscript-1.6.1-config.patch environment-modules-3.2.7b-6.fc13 --------------------------------- * Mon Nov 30 2009 Orion Poplawski - 3.2.7b-6 - Add Requires: propcs (bug #54272) evolution-2.29.3-1.fc13 ----------------------- * Mon Nov 30 2009 Milan Crha - 2.29.3-1.fc13 - Update to 2.29.3 - Add patch for missing m4 files from tarball. - Disable autoreconf call. evolution-data-server-2.29.3-1.fc13 ----------------------------------- * Mon Nov 30 2009 Milan Crha - 2.29.3-1.fc13 - Update to 2.29.3 fbterm-1.6-1.fc13 ----------------- * Mon Nov 30 2009 Ding-Yi Chen - 1.6-1 - Fixed [Bug 539186] FTBFS fbterm-1.5-2.fc12 - Upstream fixed [Bug 542284] terminfo file for fbterm not included with fbterm package in fedora. - Patch for EL-5 - Upstream update: 1. added VESA video card support 2. added rendering messages for IM server development 3. fixed a bug where Ctrl+Space is a shortcut even user run FbTerm without "input-method" option 4. fixed a bug where user compile FbTerm without gpm mouse support but run it in a gpm server enabled environment 5. fixed a IM program dead loop bug triggered by FbTerm's crash 6. fixed several spelling errors in FbTerm's help message and man-page fedora-icon-theme-1.0.0-7.fc13 ------------------------------ * Tue Nov 24 2009 Matthias Clasen - 1.0.0-7 - Drop old icons file-5.03-16.fc13 ----------------- * Mon Nov 30 2009 Daniel Novotny 5.03-16 - fixed the patch for multilib (#515767) frei0r-plugins-1.1.22-3.fc13 ---------------------------- gcl-2.6.8-0.7.20090701cvs.fc13 ------------------------------ * Mon Nov 30 2009 Jerry James - 2.6.8-0.7.20090701cvs - Fix scripts to reflect actual installation order (bz 541050) - Update PLT patch for GNU ld >= 2.19 (bz 542004) - Use (X)Emacs macros to simplify the spec file glest-3.2.2-2.fc12 ------------------ * Sat Nov 07 2009 Bruno Wolff III - 3.2.2-2 - Fix first time start up and language resetting to english (#501232) glib2-2.23.0-1.fc13 ------------------- * Mon Nov 30 2009 Matthias Clasen - 2.23.0-1 - Update to 2.23.0 glibc-2.11.90-3 --------------- * Mon Nov 30 2009 Andreas Schwab - 2.11.90-3 - Update from master. - Fix infloop in __pthread_disable_asynccancel on x86_64 (#537690). - Prevent unintended file desriptor leak in grantpt (#530558). - Fix startup to security-relevant statically linked binaries (#528631). - Re-install CFI in x86/x86_64 clone (#491542). gnome-bluetooth-2.29.3-1.fc13 ----------------------------- * Mon Nov 30 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 gnustep-base-1.18.0-8.fc13 -------------------------- * Mon Nov 30 2009 Jochen Schmitt 1.18.0-8 - Remove strace command * Thu Nov 26 2009 Jochen Schmitt 1.18.0-7 - Using temp. modified GNUstep.conf to access to DTDs (#539092) goffice-0.7.16-2.fc13 --------------------- * Tue Dec 01 2009 Huzaifa Sidhpurwala 0.7.16-2 - New build - Version bump grubby-7.0.9-3.fc13 ------------------- * Mon Nov 30 2009 Peter Jones - 7.0.9-3 - Use s390utils-base as the s390 dep, not s390utils Related: rhbz#540565 gstreamer-0.10.25.1-2.fc13 -------------------------- * Mon Nov 30 2009 Bastien Nocera 0.10.25.1-2 - Update to snapshot gstreamer-plugins-base-0.10.25.1-2.fc13 --------------------------------------- * Mon Nov 30 2009 Bastien Nocera 0.10.25.1-2 - Update to snapshot * Fri Nov 06 2009 Bastien Nocera 0.10.25-6 - Fix hangs when loading a movie with an associated subtitle in Totem gstreamer-plugins-good-0.10.17-2.fc13 ------------------------------------- * Mon Nov 30 2009 Bastien Nocera 0.10.17-2 - Add support for authenticating RTSP sources gtk2-2.19.1-1.fc13 ------------------ gtkhtml3-3.29.3-1.fc13 ---------------------- * Mon Nov 30 2009 Milan Crha - 3.29.3-1.fc13 - Update to 3.29.3 gvfs-1.5.1-2.fc13 ----------------- * Mon Nov 30 2009 Tomas Bzatek - 1.5.1-2 - Metadata fixes - SMB: Fix free space calculation for older samba servers - fuse: Fix setting timestamps htdig-3.2.0-0.9.b6.fc13 ----------------------- * Mon Nov 30 2009 Adam Tkac - 4:3.2.0-0.9.b6 - merge review related fixes (#225889) ifstat-1.1-12.fc13 ------------------ jaxodraw-2.0.1-4.fc13 --------------------- * Mon Nov 30 2009 Jussi Lehtola - 2.0.1-4 - Get rid of erroneous Require. kde-plasma-smooth-tasks-0.0.1-0.1.wip20091126.fc13 -------------------------------------------------- * Mon Nov 30 2009 Thomas Janssen 0.0.1-0.1.wip20091126 - New upstream version. - FIX: taskbar getting stuck issue - FIX: tiny bit better animation tick time calculation kdebase-runtime-4.3.75-0.2.svn1048496.fc13 ------------------------------------------ * Mon Nov 30 2009 Kevin Kofler - 4.3.75-0.2.svn1048496 - BR libssh-devel >= 0.3.92 lcms-1.19-1.fc13 ---------------- * Mon Nov 30 2009 Nicolas Chauvet - 1.19-1 - Update to 1.19 libdrm-2.4.16-0.1.fc13 ---------------------- * Tue Dec 01 2009 Dave Airlie 2.4.16-0.1 - rebase to pre-snapshot of 2.4.16 * Sat Nov 28 2009 Dave Airlie 2.4.15-6 - add new upstream API for drivers. * Fri Nov 20 2009 Dave Airlie 2.4.15-5 - update radeon API to upstream fixes libfprint-0.1.0-13.pre2.fc13 ---------------------------- * Mon Nov 30 2009 Bastien Nocera 0.1.0-13.pre2 - Add aes1610 driver (#499732) libtirpc-0.2.1-1.fc13 --------------------- * Mon Nov 30 2009 Steve Dickson 0.2.1-1 - Updated to latest upstream version: 0.2.1 mrpt-0.7.1-0.1.20090818svn1148.fc13 ----------------------------------- munin-1.4.0-1.fc13 ------------------ * Sat Nov 28 2009 Kevin Fenzi - 1.4.0-1 - Update to final 1.4.0 version * Sat Nov 21 2009 Kevin Fenzi - 1.4.0-0.1.beta - Update to beta 1.4.0 version. - Add common subpackage for common files. * Sun Nov 08 2009 Kevin Fenzi - 1.4.0-0.1.alpha - Initial alpha version of 1.4.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13 ---------------------------------------- nautilus-sendto-2.28.2-2.fc13 ----------------------------- * Mon Nov 30 2009 Bastien Nocera 2.28.2-2 - Remove bluetooth plugin, it's now in gnome-bluetooth ncview-1.93c-6.fc13 ------------------- netcf-0.1.5-1.fc13 ------------------ * Mon Nov 30 2009 David Lutterkort - 0.1.5-1 - New version olpc-update-2.21-1.fc13 ----------------------- * Mon Nov 30 2009 Daniel Drake - 2.21-1 - version bump ortp-0.16.1-1.fc13 ------------------ * Mon Nov 30 2009 Rakesh Pandit - 1:0.16.1-1 - Updated to 0.16.1, removed old patch - removed autotool calls, and using install -p phonon-4.3.50-5.20091124svn.fc13 -------------------------------- * Mon Nov 30 2009 Rex Dieter - 4.3.50-5.20091124 - backend-gstreamer: Requires: gstreamer-plugins-good php-ZendFramework-1.9.6-1.fc13 ------------------------------ * Mon Nov 30 2009 Felix Kaechele - 1.9.6-1 - update to 1.9.6 php-doctrine-Doctrine-1.2.0-1.fc13 ---------------------------------- php-facedetect-1.0.0-3.fc13 --------------------------- * Sun Nov 29 2009 Andrew Colin Kissa - 1.0.0-3 - Rebuild with new opencv postgis-1.4.1-rc2_1.fc13.1 -------------------------- * Tue Dec 01 2009 Devrim G?ND?Z - 1.4.1-rc2_1.1 - Update spec for rc2 changes. * Mon Nov 30 2009 Devrim GUNDUZ - 1.4.1rc2-1 - Update to 1.4.1rc2 * Mon Nov 23 2009 Devrim GUNDUZ - 1.4.1rc1-1 - Update to 1.4.1rc1 rainbow-0.8.5-2.fc13 -------------------- * Mon Nov 30 2009 Michael Stone - 0.8.5-2 - rhbz#542699: build with %{optflags} redhat-menus-12.0.1-2.fc13 -------------------------- * Mon Nov 30 2009 Matthias Clasen - 12.0.1-2 - Drop desktop-menu-patches roundcubemail-0.3.1-1.fc13 -------------------------- * Mon Nov 30 2009 Jon Ciesla = 0.3.1-1 - New upstream. rsh-0.17-59.fc13 ---------------- * Mon Nov 30 2009 Adam Tkac - 0.17-59 - merge review related fixes (#226379) - remove unused patches - netkit-rsh-0.16-pamfix.patch - netkit-rsh-0.16-jbj2.patch - netkit-rsh-0.16-jbj3.patch samtools-0.1.7a-1.fc13 ---------------------- * Mon Nov 30 2009 Rasmus Ory Nielsen - 0.1.7a-1 - Updated to 0.1.7a. seahorse-2.29.3-1.fc13 ---------------------- * Mon Nov 30 2009 Tomas Bzatek 2.29.3-1 - Update to 2.29.3 seahorse-plugins-2.29.3-1.fc13 ------------------------------ * Mon Nov 30 2009 Tomas Bzatek 2.29.3-1 - Update to 2.29.3 setroubleshoot-2.2.50-1.fc13 ---------------------------- * Mon Nov 30 2009 Dan Walsh - 2.2.50-1 - Exit with error code if you run sealert as root and try to connect to session bus - Fix Crash when ino is not defined setroubleshoot-plugins-2.1.35-1.fc13 ------------------------------------ * Mon Nov 30 2009 - 2.1.35-1 - Remove plugin httpd_unified and httpd_tmp_bad_labels. - Change priority on restorecon plugin sim-0.9.5-0.23.20091129svn3078rev.fc13 -------------------------------------- * Mon Nov 30 2009 Pavel Alexeev - 0.9.5-0.23.20091129svn3078rev - Add hack as workaround of http://developer.berlios.de/bugs/?func=detailbug&bug_id=16502&group_id=4482 - use system libtool instead of bundled one. BR libtool also added. (FBFS bz#538954) * Sun Nov 29 2009 Pavel Alexeev - 0.9.5-0.22.20091129svn3078rev - Fix FBFS bz#538954 - Update to fresh svn 20091129svn3078rev - Removee Patch1, it is not needed now. - Required QT >= 3.2 (up from 3.0) - Correct handle qt include dir through pkg-config. - Add pkgconfig in BR. - Add hack to remove rpath due to bug - http://developer.berlios.de/bugs/?func=detailbug&bug_id=16495&group_id=4482 - Delete in %install and do not pack *.la files. - Fix some rpmlint warnings (spaces with tab mix, macro in changelog) skrooge-0.5.4-1.fc13 -------------------- * Mon Nov 30 2009 Thomas Janssen 0.5.4-1 - Update to new upstream version - Corrects a lot of bugs and problems. See the changelog for details. sssd-0.99.0-1.fc13 ------------------ * Mon Nov 30 2009 Stephen Gallagher - 0.99.0-1 - New upstream release 0.99.0 system-config-printer-1.1.15-1.fc13 ----------------------------------- * Mon Nov 30 2009 Tim Waugh 1.1.15-1 - 1.1.15: - Fixed traceback introduced by fix to bug #541882. tabled-0.5-0.1.g26571e40.fc13 ----------------------------- * Mon Nov 30 2009 Jeff Garzik - 0.5-0.1.g26571e40 - add sources for git commit 26571e40570dfb0d0fc69507cbe8386e65252ff8 taipeifonts-1.2-10.fc13 ----------------------- * Tue Dec 01 2009 Caius 'kaio' Chance - 1.2-10.fc12 - Fixes to Mailhot's font audit. - Add metadata. - Add default attributes. tangogps-0.99.1-1.fc13 ---------------------- * Mon Nov 30 2009 Peter Robinson 0.99.1-1 - New upstream 0.99.1 release totem-2.29.2-1.fc13 ------------------- * Mon Nov 30 2009 Bastien Nocera 2.29.2-1 - Update to 2.29.2 unzip-6.0-2.fc13 ---------------- * Mon Nov 30 2009 Karel Klic - 6.0-2 - Fixed a buffer overflow (rhbz#532380, unzip-6.0-attribs-overflow.patch) - Generate debuginfos (rhbz#540220, unzip-6.0-nostrip.patch) wordpress-mu-2.8.6-1.fc13 ------------------------- * Mon Nov 30 2009 Bret McMillan - 2.8.6-1 - update to 2.8.6; couple of security fixes including 1 XSS * Fri Nov 06 2009 Bret McMillan - 2.8.5.2-1 - Update to version 2.8.5.2 for security fixes wvdial-1.61-3.fc13 ------------------ * Mon Nov 30 2009 Ondrej Vasik - 1.61-3 - fix source0 link (#226546) xcircuit-3.6.164-1.fc13 ----------------------- * Mon Nov 30 2009 Chitlesh Goorah - 3.6.164-1 - new upstream stable release xdelta-1.1.4-8.fc13 ------------------- * Mon Nov 30 2009 Adam Tkac 1.1.4-8 - merge review related fixes (#226552) xdg-utils-1.0.2-15.20091016cvs.fc13 ----------------------------------- * Mon Nov 30 2009 Rex Dieter - 1.0.2-15.20091016cvs - add Obsoletes: htmlview (#541179, f13+) Summary: Added Packages: 3 Removed Packages: 1 Modified Packages: 83 From ajax at redhat.com Tue Dec 1 14:25:55 2009 From: ajax at redhat.com (Adam Jackson) Date: Tue, 01 Dec 2009 09:25:55 -0500 Subject: Notification of uploads to the lookaside cache In-Reply-To: References: Message-ID: <1259677555.7251.31345.camel@atropine.boston.devel.redhat.com> On Sat, 2009-11-21 at 19:34 -0500, Jon Stanley wrote: > As part of our ever vigilant stance towards security around our > packaging process, we have added a new feature to upload.cgi (which > accepts file uploads into the lookaside cache) which will email the > package owner (-owner at fedoraproject.org, specifically) and > fedora-extras-commits at redhat.com whenever a file is uploaded to the > lookaside cache. Previously this was a big black box and an area of > concern. > > The message will contain the name of the file, the package concerned, > the md5sum, and the user that uploaded it. An example is below: > > File upload.cgi for package sportrop-fonts has been uploaded to the > lookaside cache with md5sum 26489f9e92601f0f84cfbb278c2b98e1 by > jstanley > > Please let me know if you have any questions, comments, or room for improvement! Can we get an X-Fedora-Upload: header in these or something? Filtering by subject line always makes me feel dirty. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Tue Dec 1 15:23:27 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 01 Dec 2009 10:23:27 -0500 Subject: livecds in the future In-Reply-To: <4B140E78.3080001@redhat.com> References: <4B0AF5E5.5080401@math.vt.edu> <8278b1b0911241307g1900a516jea391c2cd501d4de@mail.gmail.com> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> <4B140E78.3080001@redhat.com> Message-ID: <4B1534EF.3060001@redhat.com> On 11/30/2009 01:27 PM, Peter Jones wrote: > On 11/30/2009 12:27 PM, Matthias Clasen wrote: >> 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid >> the 'Can't boot USB' problem. Did we figure out how Mandriva are doing >> it ? > > No, we didn't. There are some things we might be able to do here, though, > which may solve this problem without actually "chain-booting". The most > obvious is to make sure the live image's initrd searches for a USB device > with the right filesystem label (and possibly other criteria) and mounts > that as root, and then build a liveboot.iso with one boot image and no[1] > real filesystem. The boot image would contain the kernel and initrd as > the only boot option. > > This is fairly trivial to do, actually. > > [1] It'd have to have an iso9660 filesystem with the isolinux/ directory > much like our current boot.iso does, but the kernel and initrd there would > be the ones from the live image, and we wouldn't put the rest of the live > OS on the disc. > Further research[1] seems to indicate that this is almost exactly what they're doing. [1] Adam pointed me at http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/rescue/make_flash_rescue?revision=263686&view=markup -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia From tmz at pobox.com Tue Dec 1 15:31:55 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 1 Dec 2009 10:31:55 -0500 Subject: Notification of uploads to the lookaside cache In-Reply-To: <1259677555.7251.31345.camel@atropine.boston.devel.redhat.com> References: <1259677555.7251.31345.camel@atropine.boston.devel.redhat.com> Message-ID: <20091201153155.GA23717@inocybe.localdomain> Adam Jackson wrote: > Can we get an X-Fedora-Upload: header in these or something? > Filtering by subject line always makes me feel dirty. How about using the Keywords header? That way we can also use it to create a topic for the fedora-extras-commits list. Something like: Keywords: Fedora file upload ($package, $filename) perhaps? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tell a man there are 300 billion stars in the universe, he'll believe you. Tell him a bench has wet paint on it and he'll have to touch it to be sure. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From notting at redhat.com Tue Dec 1 15:35:52 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Dec 2009 10:35:52 -0500 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) Message-ID: <20091201153551.GG26255@nostromo.devel.redhat.com> Dave Airlie (airlied at redhat.com) said: > On Fri, 2009-11-27 at 08:07 +0200, Pekka Savola wrote: > > Well, here's one graphics regression: > > https://bugzilla.redhat.com/show_bug.cgi?id=540476 > > > > radeon.modeset=0 worked around the problem. > > > > (I'm not sure if it's filed against the right component.) > > Don't use radeonhd, the Fedora X team don't support it and never have. > > I'm thinking it should reallyt be removed from the distro at this point > as it makes things worse rather than better. remove your xorg.conf > and turn modesetting on and if its still horrible, then we can talk. > > So you've proven you can break your own machine that is all. So, if our X maintainers won't handle bugs with it, we have a working default alternative that is maintained upstream, and it's *known* to be broken in the default configuration, why ship it? If we're trying to focus on quality, I'm not sure why we'd ship something that's known broken. Hans, are you OK if we block this from rawhide? Bill From stickster at gmail.com Tue Dec 1 15:41:06 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 1 Dec 2009 10:41:06 -0500 Subject: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status) In-Reply-To: <4B0CE4A5.70201@leemhuis.info> References: <4AFB2CF0.10303@leemhuis.info> <4B024899.60707@leemhuis.info> <4B02FDCC.8050508@leemhuis.info> <4B0B8EC3.9080403@leemhuis.info> <4B0CE4A5.70201@leemhuis.info> Message-ID: <20091201154106.GG2803@victoria.internal.frields.org> On Wed, Nov 25, 2009 at 09:02:45AM +0100, Thorsten Leemhuis wrote: > Hi > > Me again ;-) > > Thorsten Leemhuis wrote on 24.11.2009 08:44: > > Thorsten Leemhuis wrote on 17.11.2009 20:47: > >> On 17.11.2009 07:54, Thorsten Leemhuis wrote: > >>> Thorsten Leemhuis wrote on 11.11.2009 22:30: > >>>> As you may have heard already, several seats of the Fedora > >>>> Board, FESCo, and FAMSCO are up for election soon(?). Right now > >>>> we are in the nomination period, which will be followed by a > >>>> "Candidate Questionnaire." [...] > >> Deadline for answers: 20091124-06:00 UTC [...] > > Quick status update: I sent the questions to 23 people and 19 of them > > replied with the answers. I didn't get any replies to the questions (or > > my reminder mail from Sunday evening) from > > > > * Rodrigo Padula de Oliveira (RodrigoPadula) > > * Max Spevack (spevack) > > * Scott Seiersen (sseiersen) > > * Will Woods (wwoods) > > Max sent a apology, but the other remained silent afaics. > > > I hope to find time to work through the answers later today (in > > something like 12 hours from now) and publish them afterwards. > > Compiled a wiki page with the answers and gave the nominees 12 hours to > check the results. A few bugs were found and fixed, but I think > everything is fine now. > > So the answers are now free for public consumption on this page: > https://fedoraproject.org/wiki/Elections/F13_Questionnaire Thorsten, thanks for the time and effort you put into this. We'll make sure to notify the community that if they want to see results for a questionnaire for the next election, someone will need to take over this responsibility. Your help has been much appreciated! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From ngompa13 at gmail.com Tue Dec 1 15:42:44 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Tue, 1 Dec 2009 09:42:44 -0600 Subject: livecds in the future In-Reply-To: <4B1534EF.3060001@redhat.com> References: <4B0AF5E5.5080401@math.vt.edu> <8278b1b0911241307g1900a516jea391c2cd501d4de@mail.gmail.com> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> <4B140E78.3080001@redhat.com> <4B1534EF.3060001@redhat.com> Message-ID: <8278b1b0912010742q26d75b94mcc91d89b82a02eb3@mail.gmail.com> On Tue, Dec 1, 2009 at 9:23 AM, Peter Jones wrote: > On 11/30/2009 01:27 PM, Peter Jones wrote: > > On 11/30/2009 12:27 PM, Matthias Clasen wrote: > >> 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid > >> the 'Can't boot USB' problem. Did we figure out how Mandriva are doing > >> it ? > > > > No, we didn't. There are some things we might be able to do here, though, > > which may solve this problem without actually "chain-booting". The most > > obvious is to make sure the live image's initrd searches for a USB device > > with the right filesystem label (and possibly other criteria) and mounts > > that as root, and then build a liveboot.iso with one boot image and no[1] > > real filesystem. The boot image would contain the kernel and initrd as > > the only boot option. > > > > This is fairly trivial to do, actually. > > > > [1] It'd have to have an iso9660 filesystem with the isolinux/ directory > > much like our current boot.iso does, but the kernel and initrd there > would > > be the ones from the live image, and we wouldn't put the rest of the live > > OS on the disc. > > > > Further research[1] seems to indicate that this is almost exactly what > they're doing. > > [1] Adam pointed me at > http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/rescue/make_flash_rescue?revision=263686&view=markup > > -- > Peter > > The Shuttle is now going five times the sound of speed. > -- Dan Rather, first landing of Columbia > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I found another tool that claims to be able to search and boot a USB device, from a floppy disk no less! The tool is called PLoP[1], and it is a custom boot manager that can boot USB, CD, and hard disks. Maybe that will help some people figure out how it is done. [1]: http://www.plop.at/en/bootmanager.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at niemueller.de Tue Dec 1 15:51:02 2009 From: tim at niemueller.de (Tim Niemueller) Date: Tue, 01 Dec 2009 16:51:02 +0100 Subject: Build Failure regarding Boost Message-ID: <4B153B66.3090801@niemueller.de> Hi all. I'm trying to build the newest version 3.0.0 of the Player package. It builds just fine on F11/F12, but it fails with an error that "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, boost-thread is being installed according to root.log. The package uses cmake for building, where I suspect the problem. On my (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses the non-mt version (well, a non-multithreaded threading library is kind of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. Is there a known problem? Does anyone else maintain a project build with cmake and using Boost and can give a hint how to solve? The failed build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=1840649 Any ideas to get this fixed are welcome, Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From pjones at redhat.com Tue Dec 1 16:18:36 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 01 Dec 2009 11:18:36 -0500 Subject: livecds in the future In-Reply-To: <8278b1b0912010742q26d75b94mcc91d89b82a02eb3@mail.gmail.com> References: <4B0AF5E5.5080401@math.vt.edu> <8278b1b0911241307g1900a516jea391c2cd501d4de@mail.gmail.com> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> <4B140E78.3080001@redhat.com> <4B1534EF.3060001@redhat.com> <8278b1b0912010742q26d75b94mcc91d89b82a02eb3@mail.gmail.com> Message-ID: <4B1541DC.6000800@redhat.com> On 12/01/2009 10:42 AM, Sir Gallantmon wrote: > I found another tool that claims to be able to search and boot a USB device, > from a floppy disk no less! The tool is called PLoP[1], and it is a custom > boot manager that can boot USB, CD, and hard disks. > > Maybe that will help some people figure out how it is done. > > [1]: http://www.plop.at/en/bootmanager.html That's pretty neat, but probably not much help to us. What this is is a custom (proprietary, closed source, it seems) bootloader which basically does this: 1) installs what amounts to a DOS TSR driver for each of: a) IDE (of some unspecified variety) b) [EOU]HCI c) ATAPI and similar (i.e. SCSI MMC/SBC command sets along with encapsulation for CDROM and USB-storage) d) notably not any SATA/AHCI/etc 2) acts as a chainloading boot loader for whatever bootloader is on media that it finds. Which is also just a fancy way of saying it /replaces/ some of your BIOS's int 13h routines with what are plausibly slightly smarter (but also plausibly slightly dumber) ones. If somebody wants to implement an open source version of this, it could be helpful, I guess. But it's a lot of fairly difficult work, and the only real advantage it has over the other scheme I've discussed is that the CD (or whatever) you're booting from doesn't have to match the OS being booted. Anyway, if somebody's looking for a truly complex and isolating project to work on, go right ahead, but I'm not going to ;) -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia From ngompa13 at gmail.com Tue Dec 1 16:49:08 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Tue, 1 Dec 2009 10:49:08 -0600 Subject: livecds in the future In-Reply-To: <4B1541DC.6000800@redhat.com> References: <4B0AF5E5.5080401@math.vt.edu> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> <4B140E78.3080001@redhat.com> <4B1534EF.3060001@redhat.com> <8278b1b0912010742q26d75b94mcc91d89b82a02eb3@mail.gmail.com> <4B1541DC.6000800@redhat.com> Message-ID: <8278b1b0912010849o77addfe9uea7e4ea0de3ec495@mail.gmail.com> On Tue, Dec 1, 2009 at 10:18 AM, Peter Jones wrote: > On 12/01/2009 10:42 AM, Sir Gallantmon wrote: > > > I found another tool that claims to be able to search and boot a USB > device, > > from a floppy disk no less! The tool is called PLoP[1], and it is a > custom > > boot manager that can boot USB, CD, and hard disks. > > > > Maybe that will help some people figure out how it is done. > > > > [1]: http://www.plop.at/en/bootmanager.html > > That's pretty neat, but probably not much help to us. What this is is a > custom (proprietary, closed source, it seems) bootloader which basically > does this: > > 1) installs what amounts to a DOS TSR driver for each of: > a) IDE (of some unspecified variety) > b) [EOU]HCI > c) ATAPI and similar (i.e. SCSI MMC/SBC command sets along with > encapsulation for CDROM and USB-storage) > d) notably not any SATA/AHCI/etc > 2) acts as a chainloading boot loader for whatever bootloader is on > media that it finds. > > Which is also just a fancy way of saying it /replaces/ some of your BIOS's > int 13h routines with what are plausibly slightly smarter (but also > plausibly slightly dumber) ones. > > If somebody wants to implement an open source version of this, it could be > helpful, I guess. But it's a lot of fairly difficult work, and the only > real advantage it has over the other scheme I've discussed is that the CD > (or whatever) you're booting from doesn't have to match the OS being > booted. > > Anyway, if somebody's looking for a truly complex and isolating project to > work on, go right ahead, but I'm not going to ;) > > -- > Peter > > The Shuttle is now going five times the sound of speed. > -- Dan Rather, first landing of Columbia > > Couldn't something like that be implemented into GRUB/GRUB2? Unlike PLoP, GRUB doesn't really have a size restriction, so maybe smarter methods of detection could be implemented. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Dec 1 16:55:29 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Dec 2009 11:55:29 -0500 Subject: gnucash updated to development branch in rawhide Message-ID: <20091201165528.GD26041@nostromo.devel.redhat.com> As a consequence of the goffice update, I've updated gnucash to the 2.3.x development branch in rawhide. (Backporting the fixes for newer goffice-0.7.x series to the stable branch was looking a bit ugly, and 2.4.0 should be out well before F13 is frozen.) Of note is that this release includes the rewritten SQL backend for storage, and uses webkit for HTML rendering instead of gtkhtml. Please file bugs in bugzilla, etc. Bill From deadbabylon at googlemail.com Tue Dec 1 17:15:36 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Tue, 1 Dec 2009 18:15:36 +0100 Subject: KDE-SIG weekly report (49/2009) Message-ID: <200912011815.46581.deadbabylon@googlemail.com> 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: 49/2009 Time: 2009-12-01 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-01 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-01/kde-sig.2009-12-01-14.13.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-01/kde- sig.2009-12-01-14.13.log.html ---------------------------------------------------------------------------------- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * MaryEllenFoster * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen ---------------------------------------------------------------------------------- = Agenda = * Qt 4.6 * KDE 4.4 Beta 1 * KDE 4.3.4 * Phonon/PulseAudio issues due to the F12 Live CD missing xine-lib-pulseaudio = Summary = Qt 4.6: * Qt 4.6 is now available in rawhide. * In the next build a regression causing trouble in KMail will be fixed. * Qt 4.6 builds for F12 will probably not be build before KDE 4.4.0. KDE 4.4 Beta 1: * LukasTinkl is working on KDE 4.4 Beta 1 in rawhide. * WebKit support (which is currently disabled) needs to be reenabled. KDE 4.3.4: * ThanNgo started work on KDE 4.3.4. * There will likely be no update for F-10 (at least there was no clear decision because the EOL is quite near). Phonon/PulseAudio issues due to the F12 Live CD missing xine-lib-pulseaudio: * Missing xine-lib-pulseaudio on Fedora 12 Live images causes Phonon not to use Pulseaudio. * There seems to be no easy solution (or hacks) for enabling Pulseaudio again on an already installed system without overwriting settings that intentionally disabled Pulseaudio. * An updated Phonon from trunk with a supplied device-manager-module in Pulseaudio (#541419) could help in this issue by disabling Phonon's device management. [1] * KevinKofler is going to discuss shipping the device-manager module and Phonon PA integration with lennart. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-08 ---------------------------------------------------------------------------------- = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=541419 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kwizart at gmail.com Tue Dec 1 17:31:01 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Tue, 1 Dec 2009 18:31:01 +0100 Subject: Build Failure regarding Boost In-Reply-To: <4B153B66.3090801@niemueller.de> References: <4B153B66.3090801@niemueller.de> Message-ID: 2009/12/1 Tim Niemueller : > Hi all. > > I'm trying to build the newest version 3.0.0 of the Player package. It > builds just fine on F11/F12, but it fails with an error that > "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, > boost-thread is being installed according to root.log. > > The package uses cmake for building, where I suspect the problem. On my > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > the non-mt version (well, a non-multithreaded threading library is kind > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > Is there a known problem? Does anyone else maintain a project build with > cmake and using Boost and can give a hint how to solve? aqsis use cmake and boost, but also explicitly tell which boost library to use. You may have to adapt the cmake option if they are non-standardized. Nicolas (kwizart) From gene at czarc.net Tue Dec 1 17:38:25 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 12:38:25 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> References: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> Message-ID: <200912011238.25166.gene@czarc.net> On Monday 30 November 2009 22:40:07 Hal Murray wrote: > gene at czarc.net said: > ... > > > A written description of the security policy is a must! > > ... > > Is the idea of a single one-size-fits-all security policy reasonable? I > think Fedora has a broad range of users. > No. Initially, I recommend one security policy and one reference implementation to test against. Each variation needs its own security policy and reference implementation definition. Later ones are easier to create because they can use the early ones as "guidance". So, why go through all of this paperwork and bureaucratic bullshit? Well, those of us who have done this before believe that it is necessary. I do not like the bureaucratic BS any more than anyone else but, if you do not do it, then you are not quite sure what you have when you say that something meets security requirements. Gene From gene at czarc.net Tue Dec 1 17:47:26 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 12:47:26 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259623010.9312.778.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> Message-ID: <200912011247.26758.gene@czarc.net> On Monday 30 November 2009 18:16:50 Adam Williamson wrote: > On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote: > > Gene, > > (Ahh... someone with a similar background...) > > > > So the biggest question, to me, is to what standard do we start? > > There are plenty to choose from from DISA to NIST. I, personally, > > find the NSA's "Guide to the Secure Configuration of Red Hat > > Enterprise Linux 5" very good and might be a good place to start. I'm > > not saying that we do everything that is in the guide but maybe take > > the guide and strike things out that don't make sense and add stuff to > > it that does make sense. > > Thanks for the thoughts, Gene and Eric. You seem to be running a long > way ahead here :). I should probably say that I think I mistitled the > thread: what I was really thinking about here is not 'security', but the > more limited area of 'privilege escalation'. I'm not sure we're ready to > bite off a comprehensive distro-wide security policy yet, to the extent > you two are discussing. But, you did say the right words for what is needed to do security QA and not just privilege escalation. > > Where I'm currently at is that I'm going to talk to some Red Hat / > Fedora security folks about the issues raised in all the discussions > about this, including this thread, and then file a ticket to ask FESco > to look at the matter, possibly including a proposed policy if the > security folks help come up with one. And for the moment, only really > concerned with the question of privileges. > Start small with just privilege escalation and it can be grown to be something more comprehensive. FESco is the right place to go and see what the project wants to do. I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. Gene From eric at christensenplace.us Tue Dec 1 17:47:23 2009 From: eric at christensenplace.us (Eric Christensen) Date: Tue, 1 Dec 2009 12:47:23 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> References: <200911301509.50553.gene@czarc.net> <20091201034008.C1FEABCFC@ip-64-139-1-69.sjc.megapath.net> Message-ID: On Mon, Nov 30, 2009 at 22:40, Hal Murray wrote: > > gene at czarc.net said: > ... > > A written description of the security policy is a must! > ... > > Is the idea of a single one-size-fits-all security policy reasonable? I > think Fedora has a broad range of users. > Probably not but there are some basics that should be implemented for everyone. > > Security is a tradeoff. If you make it impossible for the bad guys to get > in, the good guys probably can't get any work done. How secure do you need > to be? How much are you willing to pay for it? > How much are you willing to pay to clean up the aftermath? > > I'd much rather have an overview document that explains the likely attacks > and potential solutions, and their costs and benefits. Additionally, I > think > it's much easier to follow a policy if I understand the reasonaing behind > it. > The Fedora Security Guide (found at docs.fedoraproject.org and in a friendly repo near you) started out that way and has blossomed into that and a whole lot more. As always suggestions and patches are welcome. > I think sample policy documents with descriptions of their target audience > and checklists for how to implement them would be helpful. > +1 --Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at christensenplace.us Tue Dec 1 18:04:02 2009 From: eric at christensenplace.us (Eric Christensen) Date: Tue, 1 Dec 2009 13:04:02 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200912011247.26758.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski wrote: > On Monday 30 November 2009 18:16:50 Adam Williamson wrote: > > Where I'm currently at is that I'm going to talk to some Red Hat / > > Fedora security folks about the issues raised in all the discussions > > about this, including this thread, and then file a ticket to ask FESco > > to look at the matter, possibly including a proposed policy if the > > security folks help come up with one. And for the moment, only really > > concerned with the question of privileges. > > > Start small with just privilege escalation and it can be grown to be > something > more comprehensive. FESco is the right place to go and see what the > project > wants to do. > There is already a security policy in place. It's not formalized nor is it written down but it's there. It's the current posture of Fedora. We set a root passphrase at the beginning of install and we give people the option of securing GRUB with a passphrase and encrypting the hard drive. We also have the unwritten rule of user privileges. It may be time to document our current posture to at least show where we are and the standard we expect all developers to live up to. In the process of documenting you may find that we are lacking somewhere. --Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Tue Dec 1 18:15:55 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 01 Dec 2009 13:15:55 -0500 Subject: Build Failure regarding Boost In-Reply-To: References: <4B153B66.3090801@niemueller.de> Message-ID: <1259691355.31044.39.camel@localhost> On Tue, 2009-12-01 at 18:31 +0100, Nicolas Chauvet wrote: > 2009/12/1 Tim Niemueller : > > Hi all. > > > > I'm trying to build the newest version 3.0.0 of the Player package. It > > builds just fine on F11/F12, but it fails with an error that > > "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, > > boost-thread is being installed according to root.log. > > > > The package uses cmake for building, where I suspect the problem. On my > > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > > the non-mt version (well, a non-multithreaded threading library is kind > > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > > Is there a known problem? Does anyone else maintain a project build with > > cmake and using Boost and can give a hint how to solve? > aqsis use cmake and boost, but also explicitly tell which boost library to use. > You may have to adapt the cmake option if they are non-standardized. Broadly speaking (beyond just Fedora), there's enough variability in the potential names of Boost libraries that a package's configuration needs the ability to specify a Boost library suffix. It sounds like your package's configuration is trying to be clever and divine the required suffix--and it's failing and falling back to no suffix. If your package's configuration won't let you specify a suffix, the most expedient thing to do may be just to hack it on. But an upstream-worthy patch would add a means to specify an arbitrary suffix. Also, -mt is a saner default than no suffix at all. -- Braden McDaniel From mmcgrath at redhat.com Tue Dec 1 18:45:21 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 1 Dec 2009 12:45:21 -0600 (CST) Subject: Upcoming multi-day outage Message-ID: Starting on December 12th The Fedora Project will start to move several servers, disk trays and related hardware from our current hosting location to another. This move is planned to be completed on December 15th and will ultimately provide better hosting facilities and room for growth. Since the servers will physically be loaded onto a truck and moved, this means lots of services people rely on will be down. We'll be working hard and using whatever tricks we have at our disposal to keep things as normal as possible, for example http://mirrors.fedoraproject.org/ will remain up (which includes the mechanism yum uses to get its mirror list). Some critical services like the buildsystem will be completely unavailable for 48 hours or longer. I'll be sending another update out as the day gets closer to remind everyone. Also this is the official ticket we're tracking with for those who care to watch it: https://fedorahosted.org/fedora-infrastructure/ticket/1845 Please do stop by #fedora-admin on irc.freenode.net or comment in the ticket with any questions or concerns you have. -Mike _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From awilliam at redhat.com Tue Dec 1 18:56:51 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 01 Dec 2009 10:56:51 -0800 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <200912011247.26758.gene@czarc.net> References: <1259014111.9312.563.camel@adam.local.net> <1259623010.9312.778.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: <1259693811.487.11.camel@adam.local.net> On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: > I suspect that most commercial and government customers will be interested in > Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology > base on which future Red Hat Enterprise Linux releases are built. The better > Fedora is, the more confidence customers will have the the Red Hat product. I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo. Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From gene at czarc.net Tue Dec 1 19:56:20 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 14:56:20 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: <1259693811.487.11.camel@adam.local.net> References: <1259014111.9312.563.camel@adam.local.net> <200912011247.26758.gene@czarc.net> <1259693811.487.11.camel@adam.local.net> Message-ID: <200912011456.20917.gene@czarc.net> On Tuesday 01 December 2009 13:56:51 Adam Williamson wrote: > On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: > > I suspect that most commercial and government customers will be > > interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora > > is the technology base on which future Red Hat Enterprise Linux releases > > are built. The better Fedora is, the more confidence customers will have > > the the Red Hat product. > > I agree. What I'm really worried about here, ultimately, is PolicyKit, > and the way it permits a lot more grey areas than have been possible > before. If you look at previous privilege escalation mechanisms, they're > simplistic; whether you're using sudo or consolehelper or whatever, > ultimately you either have a process run as root or as user. And it's > pretty obvious what should run as root and what shouldn't; I don't > remember there being any real serious debates about that, everyone > pretty much reaches the same conclusions independently. The > authentication question is equally simple: basically either the process > just runs as root automatically (which everyone agrees should happen for > as few processes as possible), or you have to authenticate each time - > for Fedora, basically you have to type the root password, since we never > really used sudo. > > Things like 'well, we can perform this one specific type of operation > with this one specific type of authentication' just weren't possible. > Now they are, so stuff like the PackageKit issue was bound to start > happening. The things PolicyKit make possible really need some kind of > coherent oversight, I think, and that is indeed something Red Hat > Enterprise Linux will also need to address, so obviously from an RH > perspective, it helps RH if Fedora develops some kind of policy for > this. But I think it's necessary for Fedora anyway, regardless of RH. > What you are saying put more emphasis on getting a security policy written and ratified by FESco. And you will also need some oversight of what the developers are doing with respect to security and this security policy. The QA process should catch the "oops" problems ... not those done intentionally by a well-intentioned developer. I do not know that much about PolicyKit and given my interests in security, I probably need to learn about it. One thing that occurs to me is to wonder if PolicyKit is using SELinux (see SELinux Users and Roles). If not, why not? Regardless of how PolicyKit works, the default should be locked-down with an easy-to-use sysadmin tool to provide configuration with the ability to open- things-up in a controlled manner. You should talk to the folks handling SELinux. My impression of them is that they know what they are doing and may provide some insight into the PolicyKit "problem". Fedora has come a long way since SELinux was first introduced. It would be a shame if the enhanced security provided by SELinux was negated by PolicyKit. A couple of other comments: - No, I do not believe that regular users should be able to update or install software globally without transitioning to an admin role ... they can put stuff in their home directory but not globally. - I agree with Smooge in one of the messages he wrote ... there are many users who would like to run Fedora just like Windows95. That may be but that does not mean that Fedora should follow that idea. Gene From gene at czarc.net Tue Dec 1 20:10:29 2009 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 1 Dec 2009 15:10:29 -0500 Subject: Security testing: need for a security policy, and a security-critical package process In-Reply-To: References: <1259014111.9312.563.camel@adam.local.net> <200912011247.26758.gene@czarc.net> Message-ID: <200912011510.29511.gene@czarc.net> On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote: > On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski wrote: > > On Monday 30 November 2009 18:16:50 Adam Williamson wrote: > > > Where I'm currently at is that I'm going to talk to some Red Hat / > > > > > > Fedora security folks about the issues raised in all the discussions > > > about this, including this thread, and then file a ticket to ask FESco > > > to look at the matter, possibly including a proposed policy if the > > > security folks help come up with one. And for the moment, only really > > > concerned with the question of privileges. > > > > Start small with just privilege escalation and it can be grown to be > > something > > more comprehensive. FESco is the right place to go and see what the > > project > > wants to do. > > There is already a security policy in place. It's not formalized nor is it > written down but it's there. It's the current posture of Fedora. We set a > root passphrase at the beginning of install and we give people the option > of securing GRUB with a passphrase and encrypting the hard drive. We also > have the unwritten rule of user privileges. > > It may be time to document our current posture to at least show where we > are and the standard we expect all developers to live up to. In the > process of documenting you may find that we are lacking somewhere. Yes, there has always been a security policy as defined by the written code (software). But, that is subject to individual interpretation. I agree that creating a written security policy is likely to identify shortcomings such as my point about the GRUB password. Lots of folks who use computers clearly do not understand the underlying technology and are clearly not paranoid enough. Given a home computer, do you really want your teenager installing file-sharing software. Recently, the US Congress discovered that some of their users had installed file-sharing software --- and the result was not positive. Fedora needs to provide good functionality while keeping our collective sanity ... we need software which is not just easy to use but is smarter about how it is used. Gene From arequipeno at gmail.com Tue Dec 1 20:27:19 2009 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 01 Dec 2009 14:27:19 -0600 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <20091201153551.GG26255@nostromo.devel.redhat.com> References: <20091201153551.GG26255@nostromo.devel.redhat.com> Message-ID: On 12/01/2009 09:35 AM, Bill Nottingham wrote: > So, if our X maintainers won't handle bugs with it, we have a working > default alternative that is maintained upstream, and it's *known* to > be broken in the default configuration, why ship it? If we're trying to > focus on quality, I'm not sure why we'd ship something that's known > broken. Because the alternative may be more broken for some people? https://bugzilla.redhat.com/show_bug.cgi?id=495688 -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From notting at redhat.com Tue Dec 1 20:43:27 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Dec 2009 15:43:27 -0500 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: References: <20091201153551.GG26255@nostromo.devel.redhat.com> Message-ID: <20091201204326.GB28720@nostromo.devel.redhat.com> Ian Pilcher (arequipeno at gmail.com) said: > On 12/01/2009 09:35 AM, Bill Nottingham wrote: > > So, if our X maintainers won't handle bugs with it, we have a working > > default alternative that is maintained upstream, and it's *known* to > > be broken in the default configuration, why ship it? If we're trying to > > focus on quality, I'm not sure why we'd ship something that's known > > broken. > > Because the alternative may be more broken for some people? > > https://bugzilla.redhat.com/show_bug.cgi?id=495688 If the e1000 driver is broken in the kernel for some people, we don't support shipping an alternate driver. If a new version of the intel graphics driver is broken for some people, we don't support shipping a pre-KMS version of the driver. Why would we do differently here? Bill From kevin.kofler at chello.at Wed Dec 2 00:52:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 02 Dec 2009 01:52:35 +0100 Subject: Build Failure regarding Boost References: <4B153B66.3090801@niemueller.de> Message-ID: Tim Niemueller wrote: > The package uses cmake for building, where I suspect the problem. On my > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > the non-mt version (well, a non-multithreaded threading library is kind > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > Is there a known problem? Does anyone else maintain a project build with > cmake and using Boost and can give a hint how to solve? Does the package ship its own FindBoost.cmake? If it does, try removing it in %prep and seeing if that helps. (It'll use CMake's version then.) If the package isn't shipping its own FindBoost.cmake or if removing it doesn't fix the problem, please file a bug against CMake. Kevin Kofler From tim at niemueller.de Wed Dec 2 00:53:54 2009 From: tim at niemueller.de (Tim Niemueller) Date: Wed, 02 Dec 2009 01:53:54 +0100 Subject: Build Failure regarding Boost In-Reply-To: <1259691355.31044.39.camel@localhost> References: <4B153B66.3090801@niemueller.de> <1259691355.31044.39.camel@localhost> Message-ID: <4B15BAA2.8040504@niemueller.de> On 01.12.2009 19:15, Braden McDaniel wrote: > Broadly speaking (beyond just Fedora), there's enough variability in the > potential names of Boost libraries that a package's configuration needs > the ability to specify a Boost library suffix. It sounds like your > package's configuration is trying to be clever and divine the required > suffix--and it's failing and falling back to no suffix. > > If your package's configuration won't let you specify a suffix, the most > expedient thing to do may be just to hack it on. But an upstream-worthy > patch would add a means to specify an arbitrary suffix. Also, -mt is a > saner default than no suffix at all. The suffix is determined in /usr/share/cmake/Modules/FindBoost.cmake which is part of cmake, so there is nothing I can do about this in the Player package. Could this be a problem with new cmake or boost versions? Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From kevin.kofler at chello.at Wed Dec 2 00:54:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 02 Dec 2009 01:54:57 +0100 Subject: Upcoming multi-day outage References: Message-ID: Mike McGrath wrote: > Starting on December 12th The Fedora Project will start to move several > servers, disk trays and related hardware from our current hosting location > to another. This move is planned to be completed on December 15th and > will ultimately provide better hosting facilities and room for growth. Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that the last day to file F10 updates in Bodhi will be December 14, that's now right within the outage window. Kevin Kofler From ngompa13 at gmail.com Wed Dec 2 01:26:28 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Tue, 1 Dec 2009 19:26:28 -0600 Subject: Build Failure regarding Boost In-Reply-To: <4B15BAA2.8040504@niemueller.de> References: <4B153B66.3090801@niemueller.de> <1259691355.31044.39.camel@localhost> <4B15BAA2.8040504@niemueller.de> Message-ID: <8278b1b0912011726k7b42f728ge49853f6c8c98bf9@mail.gmail.com> On Tue, Dec 1, 2009 at 6:53 PM, Tim Niemueller wrote: > On 01.12.2009 19:15, Braden McDaniel wrote: > > Broadly speaking (beyond just Fedora), there's enough variability in the > > potential names of Boost libraries that a package's configuration needs > > the ability to specify a Boost library suffix. It sounds like your > > package's configuration is trying to be clever and divine the required > > suffix--and it's failing and falling back to no suffix. > > > > If your package's configuration won't let you specify a suffix, the most > > expedient thing to do may be just to hack it on. But an upstream-worthy > > patch would add a means to specify an arbitrary suffix. Also, -mt is a > > saner default than no suffix at all. > > The suffix is determined in /usr/share/cmake/Modules/FindBoost.cmake > which is part of cmake, so there is nothing I can do about this in the > Player package. Could this be a problem with new cmake or boost versions? > > Tim > > -- > Tim Niemueller www.niemueller.de > ================================================================= > Imagination is more important than knowledge. (Albert Einstein) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Perhaps CMake needs to be updated to 2.8.0 final? I think there was a FindBoost.cmake update in 2.8.0... -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent at brentnorris.net Wed Dec 2 01:32:02 2009 From: brent at brentnorris.net (Brent Norris) Date: Tue, 01 Dec 2009 19:32:02 -0600 Subject: Odd partition error in F12, but not in F11 Message-ID: <4B15C392.8000208@brentnorris.net> I have a friend that doesn't read the list that has been fighting a very odd issue with F12, which does not surface in F11. On a clean install from the F12 DVD with the updates repo enabled, he created a RAID 5 setup across 6 drives. Each drive has only one partition on it. When the machine reboots it cannot rebuild the raid because it cannot find 4 of the 6 partitions. It drops to the root prompt and from there if you do an ls /dev/sd?* four of the drives show no entries for the partitions while the other two show the normal one partition. If you open one of the incorrect drives with fdisk it shows the correct partition table and if you write it out from fdisk it then shows correctly in /dev If you do this to each of the drives they all show up and then mdadm can assemble the raid correctly. Reboot the machine and you are right back to where you started. dmesg seems to show the kernel correctly listing each drive and correctly listing them with each one partition, but the entries are not in /dev for the partitions. We rolled back to F11 and performed the same process and it worked fine. I am really at a loss for what to look at or what to test against. We currently have the machine up and working with F11, so I can get any information about hardware that might help. I posted it here rather than the users list, because I don't really think this is a configuration problem. It seems like a bug in F12, but I don't know what to check it against. Brent From jwboyer at gmail.com Wed Dec 2 01:39:39 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 1 Dec 2009 20:39:39 -0500 Subject: Upcoming multi-day outage In-Reply-To: References: Message-ID: <20091202013939.GB4449@hansolo.jdub.homelinux.org> On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: >Mike McGrath wrote: >> Starting on December 12th The Fedora Project will start to move several >> servers, disk trays and related hardware from our current hosting location >> to another. This move is planned to be completed on December 15th and >> will ultimately provide better hosting facilities and room for growth. > >Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that >the last day to file F10 updates in Bodhi will be December 14, that's now >right within the outage window. Hm. Crap, you are correct. I had been thinking I said it was Dec 11 for several days now. I have no idea why, but we might seriously want to change the final F10 push date to Dec 11 to accommodate for the outage. josh From jwboyer at gmail.com Wed Dec 2 01:50:22 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 1 Dec 2009 20:50:22 -0500 Subject: Upcoming multi-day outage In-Reply-To: <20091202013939.GB4449@hansolo.jdub.homelinux.org> References: <20091202013939.GB4449@hansolo.jdub.homelinux.org> Message-ID: <20091202015022.GC4449@hansolo.jdub.homelinux.org> On Tue, Dec 01, 2009 at 08:39:39PM -0500, Josh Boyer wrote: >On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: >>Mike McGrath wrote: >>> Starting on December 12th The Fedora Project will start to move several >>> servers, disk trays and related hardware from our current hosting location >>> to another. This move is planned to be completed on December 15th and >>> will ultimately provide better hosting facilities and room for growth. >> >>Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that >>the last day to file F10 updates in Bodhi will be December 14, that's now >>right within the outage window. > >Hm. Crap, you are correct. I had been thinking I said it was Dec 11 >for several days now. I have no idea why, but we might seriously want >to change the final F10 push date to Dec 11 to accommodate for the >outage. I've created https://fedorahosted.org/fesco/ticket/282 to track this. Normally a final push date doesn't require FESCo approval, but given that this is a change in the date that gives people less time I thought it might be prudent. (I'm going to ignore the fact that this is pushing updates to a release that will be EOL'd 6 days later.) Transparency and junk and stuff. josh From orion at cora.nwra.com Wed Dec 2 04:27:58 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 1 Dec 2009 21:27:58 -0700 (MST) Subject: Build Failure regarding Boost In-Reply-To: <8278b1b0912011726k7b42f728ge49853f6c8c98bf9@mail.gmail.com> References: <4B153B66.3090801@niemueller.de> <1259691355.31044.39.camel@localhost> <4B15BAA2.8040504@niemueller.de> <8278b1b0912011726k7b42f728ge49853f6c8c98bf9@mail.gmail.com> Message-ID: <51640.75.171.236.122.1259728078.squirrel@www.cora.nwra.com> On Tue, December 1, 2009 6:26 pm, Sir Gallantmon wrote: > Perhaps CMake needs to be updated to 2.8.0 final? I think there was a > FindBoost.cmake update in 2.8.0... cmake 2.8.0 final is in rawhide so you can test there. I'm not comfortable pushing it to F12/11. We could make an update with an updated FindBoost.cmake if necessary. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From huzaifas at redhat.com Wed Dec 2 05:11:08 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 02 Dec 2009 10:41:08 +0530 Subject: gnumeric-1.9.16-1.fc13 in rawhide now Message-ID: <4B15F6EC.8040302@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Just updated gnumeric in rawhide to gnumeric-1.9.16-1.fc13. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLFfbszHDc8tpb2uURAuCaAJ9PcscbyiZtgvVfy7ZYDu450dkTBgCdGvsT TyMKWiajZ4Y3Dz17JW/DgKs= =60AZ -----END PGP SIGNATURE----- From mcepl at redhat.com Wed Dec 2 07:04:57 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Wed, 02 Dec 2009 08:04:57 +0100 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <20091201204326.GB28720@nostromo.devel.redhat.com> References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> Message-ID: Dne 1.12.2009 21:43, Bill Nottingham napsal(a): > If the e1000 driver is broken in the kernel for some people, we don't support > shipping an alternate driver. If a new version of the intel graphics driver > is broken for some people, we don't support shipping a pre-KMS version > of the driver. > > Why would we do differently here? Because if e1000 is broken, we can be sure with reasonably high level of certainity, it will be fixed without undue delay. For Xorg drivers (especially with regards to 3D support) we have hope that it will be slightly better in the next Fedora release, but complete coverage is still just a dream. Moreover, I don't know what's your problem with radeonhd driver in Fedora. Hanz does IMHO excellent job on maintaining it and it doesn't drag much additional resources on anybody (except on me, perhaps, because I triage bugs for him as well, which is the reason that this time I even a little know what I am talking about ;)). And of course comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati bugs (http://is.gd/59Hp0) is unfair, because there are many more users of -ati driver, but at least it shows that radeonhd is really not burning issue. What's the problem? Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Our lives are spectacles of powerlessness. -- Richard Rohr From nicu_fedora at nicubunu.ro Wed Dec 2 07:46:46 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 02 Dec 2009 09:46:46 +0200 Subject: livecds in the future In-Reply-To: <1259602063.2487.113.camel@planemask> References: <4B0AF5E5.5080401@math.vt.edu> <8278b1b0911241307g1900a516jea391c2cd501d4de@mail.gmail.com> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> Message-ID: <4B161B66.50408@nicubunu.ro> On 11/30/2009 07:27 PM, Matthias Clasen wrote: > > 2. More download choices are not a part of the solution, but a part of > the problem... We already have the problem that people are choosing to > download the DVD just because DVD> CD; but unlike the spins, the DVD is > not a designed product at all. This may mean also a good number of people to not care about a "designed product", they just want the packages. Or it may be the case the design for the "designed products" (that is the Desktop Spin, right?) is not that great (I think is not, I am completely out of its target). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ From ikem.krueger at googlemail.com Wed Dec 2 11:01:23 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Wed, 2 Dec 2009 11:01:23 +0000 Subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? In-Reply-To: <1259621278.9312.774.camel@adam.local.net> References: <4B0E8A1C.9080501@beam.ltd.uk> <1259302128.6876.9.camel@localhost> <1259440690.18660.1.camel@localhost> <1259600511.20291.32.camel@localhost.localdomain> <4B141A0D.9060603@gmail.com> <604aa7910911301128l2db59635jc5d06918ad0d327f@mail.gmail.com> <1259621278.9312.774.camel@adam.local.net> Message-ID: > Nope, Bryce doesn't get to work on upstream in any significant way as part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.) Did you chatted with Bryce? From hun at n-dimensional.de Wed Dec 2 12:05:51 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Wed, 2 Dec 2009 13:05:51 +0100 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <20091201153551.GG26255@nostromo.devel.redhat.com> References: <20091201153551.GG26255@nostromo.devel.redhat.com> Message-ID: <20091202130551.55a9ac62@n-dimensional.de> On Tue, 1 Dec 2009 10:35:52 -0500 Bill Nottingham wrote: [ radeonhd vs radeon ] > So, if our X maintainers won't handle bugs with it, we have a working > default alternative that is maintained upstream, and it's *known* to > be broken in the default configuration, why ship it? If we're trying > to focus on quality, I'm not sure why we'd ship something that's known > broken. > > Hans, are you OK if we block this from rawhide? >From where I stand, there are a number of reasons both for and against having a radeonhd package in Fedora. Most of those reasons will have different importance for different people. The reasons I see for having radeonhd in Fedora all boil down to radeonhd and radeon containing different sets of bugs, and triggering different sets of bugs in other software components (and probably also hardware). Often, those issues can be hard to find if the exact hardware is not available to the developers, and thus take quite long to fix. See e.g. http://airlied.livejournal.com/68550.html There have always been cases of one driver working for people while the other does not, and vice versa. The complexity of the whole graphics system suggests this will probably not change soon. For keeping radeonhd in Fedora K1. Giving users a working system using the other driver during the weeks or months needed to fix a bug in one of the drivers is good for users. K2. Easy availability of another driver to try makes locating the bug easier: Is the issue common to both drivers, or different or not present at all with the other. For blocking radeonhd from Fedora B1. Less work for me and Matej in bugzilla. B2. Less bugs mistakenly assigned to radeonhd by the reporters. B3. Lacking an alternative, the pressure to fix bugs with radeon would increase (and hopefully improve things). B4. radeonhd requires some nomodeset kernel parameter, depending on kernel version. As to the KMS issue, I do not see where to communicate to users that radeonhd needs KMS off but in README.fedora. radeonhd upstream do not support KMS. All that said, I have been mostly running radeon with nomodeset on my F11 system (ThinkPad T60, X1400/rv515) for the last few months, so for me personally, I would not lose much by radeonhd being removed from Fedora. I have not had an opportunity to test the state of affairs on F12 or even rawhide, and also have no R6xx, R7xx, R8xx chipsets, so I cannot comment on any of that. -- Hans Ulrich Niedermann From mzerqung at 0pointer.de Wed Dec 2 12:43:00 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 2 Dec 2009 13:43:00 +0100 Subject: Pulseaudio in F12 In-Reply-To: <68720af30911290658u5beb38cbqd697c5afb0df899a@mail.gmail.com> References: <68720af30911290658u5beb38cbqd697c5afb0df899a@mail.gmail.com> Message-ID: <20091202124259.GE8455@tango.0pointer.de> On Sun, 29.11.09 12:58, Paulo Cavalcanti (promac at gmail.com) wrote: > Hi, > > I made a clean install of Fedora 12, and pulseaudio seems to be behaving > completely different. Any mixer control I have (master, pcm, front ,,,) > affects > the pulse volume slider (looking at pavucontrol). In the past, pulse only > controlled PCM, I guess. http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes > But the worst point is that there is no more application volume memory. > All applications when launched are at full volume, and this is really > annoying ... That is not true, unless you reconfigured PA in some way... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From fedora-list at gunduz.org Wed Dec 2 13:12:13 2009 From: fedora-list at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 02 Dec 2009 15:12:13 +0200 Subject: GEOS 3.2.0rc3 will hit rawhide soon Message-ID: <1259759533.3318.1.camel@hp-laptop2.gunduz.org> Hi, Just a FYI: I will update GEOS to 3.2.0rc3 in rawhide in a few minutes. Some packages may need to be rebuilt. Regards, -- Devrim G?ND?Z, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz From promac at gmail.com Wed Dec 2 13:18:37 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 2 Dec 2009 11:18:37 -0200 Subject: Pulseaudio in F12 In-Reply-To: <20091202124259.GE8455@tango.0pointer.de> References: <68720af30911290658u5beb38cbqd697c5afb0df899a@mail.gmail.com> <20091202124259.GE8455@tango.0pointer.de> Message-ID: <68720af30912020518q17a229b7u252a2a46acd8f033@mail.gmail.com> On Wed, Dec 2, 2009 at 10:43 AM, Lennart Poettering wrote: > On Sun, 29.11.09 12:58, Paulo Cavalcanti (promac at gmail.com) wrote: > > > Hi, > > > > I made a clean install of Fedora 12, and pulseaudio seems to be behaving > > completely different. Any mixer control I have (master, pcm, front ,,,) > > affects > > the pulse volume slider (looking at pavucontrol). In the past, pulse only > > controlled PCM, I guess. > > http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes > > > But the worst point is that there is no more application volume memory. > > All applications when launched are at full volume, and this is really > > annoying ... > > That is not true, unless you reconfigured PA in some way... > > You are right. This is true for some applications only, and I found so far three applications needing to be fixed: xmms, audacious and mplayer. I installed audacious 2.2 and it is behaving much better. xmms-pulse plugin was written by you, but I do not know if you are willing to patch xmms. mplayer will be fixed eventually. Now that I understand what you have done, it seems to be a good idea indeed. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Wed Dec 2 13:28:51 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 02 Dec 2009 08:28:51 -0500 Subject: abrt issues Message-ID: Wondering about these odd messages: Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled exception in /tmp/hgtests.eYmApF/install/bin/hg Dec 2 07:40:12 nbecker6 abrtd: Directory 'pyhook-1259757612-30443' creation detected Dec 2 07:40:12 nbecker6 abrtd: Lock file '/var/cache/abrt/pyhook-1259757612-30443.lock' is locked by process 30445 Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled exception in /tmp/hgtests.eYmApF/install/bin/hg Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting Dec 2 07:40:13 nbecker6 abrtd: Directory 'pyhook-1259757612-30446' creation detected Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting Dec 2 07:45:56 nbecker6 python: abrt: Pyhook: Detected unhandled exception in dumb.py Dec 2 07:45:56 nbecker6 abrtd: Directory 'pyhook-1259757956-4737' creation detected Dec 2 07:45:56 nbecker6 abrtd: Lock file '/var/cache/abrt/pyhook-1259757956-4737.lock' is locked by process 4773 Dec 2 07:45:56 nbecker6 abrtd: Executable doesn't belong to any package Dec 2 07:45:56 nbecker6 abrtd: Corrupted or bad crash, deleting From jnovy at redhat.com Wed Dec 2 13:39:51 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 2 Dec 2009 14:39:51 +0100 Subject: Parallel XZ - request for testing Message-ID: <20091202133951.GA8760@dhcp-lab-133.englab.brq.redhat.com> Hi all, the Parallel XZ just reached usable state so if you want to take advantage of parallel LZMA compression, please give it a try before its inclusion into Fedora. PXZ homepage is: http://jnovy.fedorapeople.org/pxz/ Sources and YUM repos are available at: http://jnovy.fedorapeople.org/pxz/node3.html Please note that it saves most of the compression time for large files. E.g. file is split to parts of the size of the dictionary for given compression level (8MiB for default -6 compression) and then runs compression itself in as many threads as your system allows. Benchmarks and usage cases are presented on the PXZ homepage. Thanks, Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From mbooth at redhat.com Wed Dec 2 14:39:30 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 14:39:30 +0000 Subject: Proposed F13 feature: drop separate updates repository Message-ID: <4B167C22.3000504@redhat.com> The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From limb at jcomserv.net Wed Dec 2 15:00:53 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 02 Dec 2009 09:00:53 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <4B168125.1040501@jcomserv.net> Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've > been using RHL/Fedora Core/Fedora. It means you have two places to > look when searching for packages manually, and twice as much to > configure when you're configuring yum. It has never benefitted me, or > anybody I know, but it has caught me out on any number of occasions. > What's more, nobody really seems to know why it's like that: it seems > it's always been that way, and nobody ever bother to fix it. > > So lets fix it. The package set at release time is only interesting to > historians. If any of them are really that bothered, I'm sure somebody > can come up with a yum module which finds the oldest available version > of a package in a repo. > > Matt Would not this also provide the minor added benefit that there could now be a drpm for the first update for a package? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From rc040203 at freenet.de Wed Dec 2 15:20:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Dec 2009 16:20:47 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <4B1685CF.4080302@freenet.de> On 12/02/2009 03:39 PM, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. It has never benefitted me, or anybody I know, > but it has caught me out on any number of occasions. What's more, nobody > really seems to know why it's like that: it seems it's always been that > way, and nobody ever bother to fix it. > > So lets fix it. The package set at release time is only interesting to > historians. If any of them are really that bothered, I'm sure somebody > can come up with a yum module which finds the oldest available version > of a package in a repo. So your proposal is to drop updates, but to add updates to "Everything"? In this case, I am all for it. Ralf From robert at marcanoonline.com Wed Dec 2 15:23:23 2009 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 02 Dec 2009 10:53:23 -0430 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B168125.1040501@jcomserv.net> References: <4B167C22.3000504@redhat.com> <4B168125.1040501@jcomserv.net> Message-ID: <4B16866B.4090705@marcanoonline.com> On 12/02/2009 10:30 AM, Jon Ciesla wrote: > Matthew Booth wrote: >> The separate updates directory has been a pain for as long as I've >> been using RHL/Fedora Core/Fedora. It means you have two places to >> look when searching for packages manually, and twice as much to >> configure when you're configuring yum. It has never benefitted me, or >> anybody I know, but it has caught me out on any number of occasions. >> What's more, nobody really seems to know why it's like that: it seems >> it's always been that way, and nobody ever bother to fix it. >> >> So lets fix it. The package set at release time is only interesting to >> historians. If any of them are really that bothered, I'm sure somebody >> can come up with a yum module which finds the oldest available version >> of a package in a repo. >> >> Matt > Would not this also provide the minor added benefit that there could now > be a drpm for the first update for a package? I like the proposal, the only drawback I found is that when a new Fedora release is out we mirror (local) the updates repository with priority, and the big Everything repository is mirrored using a small bandwidth setting because it is not needed normally for the first updates (updates that add new dependecies are not common the first weeks) > > -J > From jwboyer at gmail.com Wed Dec 2 15:26:28 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Dec 2009 10:26:28 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B168125.1040501@jcomserv.net> References: <4B167C22.3000504@redhat.com> <4B168125.1040501@jcomserv.net> Message-ID: <20091202152628.GA14279@hansolo.jdub.homelinux.org> On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote: > Matthew Booth wrote: >> The separate updates directory has been a pain for as long as I've >> been using RHL/Fedora Core/Fedora. It means you have two places to >> look when searching for packages manually, and twice as much to >> configure when you're configuring yum. It has never benefitted me, or >> anybody I know, but it has caught me out on any number of occasions. >> What's more, nobody really seems to know why it's like that: it seems >> it's always been that way, and nobody ever bother to fix it. >> >> So lets fix it. The package set at release time is only interesting to >> historians. If any of them are really that bothered, I'm sure somebody >> can come up with a yum module which finds the oldest available version >> of a package in a repo. >> >> Matt > Would not this also provide the minor added benefit that there could now > be a drpm for the first update for a package? We already have that if the update is done after GA. josh From jwboyer at gmail.com Wed Dec 2 15:26:55 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Dec 2009 10:26:55 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <20091202152655.GB14279@hansolo.jdub.homelinux.org> On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. It has never benefitted me, or anybody I know, > but it has caught me out on any number of occasions. What's more, nobody > really seems to know why it's like that: it seems it's always been that > way, and nobody ever bother to fix it. > > So lets fix it. And how do you propose to do that? josh From pjones at redhat.com Wed Dec 2 15:37:20 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 10:37:20 -0500 Subject: livecds in the future In-Reply-To: <8278b1b0912010849o77addfe9uea7e4ea0de3ec495@mail.gmail.com> References: <4B0AF5E5.5080401@math.vt.edu> <4B0C4D87.3000004@redhat.com> <1259097919.9312.602.camel@adam.local.net> <4B0C526D.7000203@redhat.com> <1259120507.9312.605.camel@adam.local.net> <1259602063.2487.113.camel@planemask> <4B140E78.3080001@redhat.com> <4B1534EF.3060001@redhat.com> <8278b1b0912010742q26d75b94mcc91d89b82a02eb3@mail.gmail.com> <4B1541DC.6000800@redhat.com> <8278b1b0912010849o77addfe9uea7e4ea0de3ec495@mail.gmail.com> Message-ID: <4B1689B0.6080505@redhat.com> On 12/01/2009 11:49 AM, Sir Gallantmon wrote: > Couldn't something like that be implemented into GRUB/GRUB2? Unlike PLoP, > GRUB doesn't really have a size restriction, so maybe smarter methods of > detection could be implemented. The approach of loading what amounts to DOS TSRs is something you could do with pretty much any x86 bootloader (though it's worlds simpler with syslinux than grub). But we're still basically talking about writing a bunch of 16-bit device drivers. I'm thinking it's not going to happen. -- Peter Growth for the sake of growth is the ideology of the cancer cell. From mbooth at redhat.com Wed Dec 2 15:44:08 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 15:44:08 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202152655.GB14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> Message-ID: <4B168B48.8050504@redhat.com> On 02/12/09 15:26, Josh Boyer wrote: > On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: >> The separate updates directory has been a pain for as long as I've been >> using RHL/Fedora Core/Fedora. It means you have two places to look when >> searching for packages manually, and twice as much to configure when >> you're configuring yum. It has never benefitted me, or anybody I know, >> but it has caught me out on any number of occasions. What's more, nobody >> really seems to know why it's like that: it seems it's always been that >> way, and nobody ever bother to fix it. >> >> So lets fix it. > > And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. More involved would be: 1. Updating all packages which expect 2 repos to only expect 1. 2. Communicating the change effectively. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From limb at jcomserv.net Wed Dec 2 15:59:06 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 02 Dec 2009 09:59:06 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202152628.GA14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <4B168125.1040501@jcomserv.net> <20091202152628.GA14279@hansolo.jdub.homelinux.org> Message-ID: <4B168ECA.4030907@jcomserv.net> Josh Boyer wrote: > On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote: > >> Matthew Booth wrote: >> >>> The separate updates directory has been a pain for as long as I've >>> been using RHL/Fedora Core/Fedora. It means you have two places to >>> look when searching for packages manually, and twice as much to >>> configure when you're configuring yum. It has never benefitted me, or >>> anybody I know, but it has caught me out on any number of occasions. >>> What's more, nobody really seems to know why it's like that: it seems >>> it's always been that way, and nobody ever bother to fix it. >>> >>> So lets fix it. The package set at release time is only interesting to >>> historians. If any of them are really that bothered, I'm sure somebody >>> can come up with a yum module which finds the oldest available version >>> of a package in a repo. >>> >>> Matt >>> >> Would not this also provide the minor added benefit that there could now >> be a drpm for the first update for a package? >> > > We already have that if the update is done after GA. > > josh > > If that's the case, then good. In that case, I see no huge benefit to leaving it or changing it. -- in your fear, seek only peace in your fear, seek only love -d. bowie From jmforbes at linuxtx.org Wed Dec 2 16:01:51 2009 From: jmforbes at linuxtx.org (Justin M. Forbes) Date: Wed, 2 Dec 2009 10:01:51 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <20091202160151.GA21874@linuxtx.org> On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when you're > configuring yum. It has never benefitted me, or anybody I know, but it has > caught me out on any number of occasions. What's more, nobody really seems > to know why it's like that: it seems it's always been that way, and nobody > ever bother to fix it. > The only downside to merging updates into the main repository is that network installs from the repository will no longer install the "release" they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the "release" as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. Justin From jwboyer at gmail.com Wed Dec 2 16:06:22 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Dec 2009 11:06:22 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B168B48.8050504@redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> Message-ID: <20091202160622.GD14279@hansolo.jdub.homelinux.org> On Wed, Dec 02, 2009 at 03:44:08PM +0000, Matthew Booth wrote: > On 02/12/09 15:26, Josh Boyer wrote: >> On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: >>> The separate updates directory has been a pain for as long as I've been >>> using RHL/Fedora Core/Fedora. It means you have two places to look when >>> searching for packages manually, and twice as much to configure when >>> you're configuring yum. It has never benefitted me, or anybody I know, >>> but it has caught me out on any number of occasions. What's more, nobody >>> really seems to know why it's like that: it seems it's always been that >>> way, and nobody ever bother to fix it. >>> >>> So lets fix it. >> >> And how do you propose to do that? > > Unfortunately I'm not intimately familiar with Fedora infrastructure > under-the-hood. However, I would hope that, technically at least, it > wouldn't be much more than a systematic removal of all updates > repositories and redirecting files which would have gone into them into > the main repositories instead. This stems from the observation that if > you copied everything from the main repository into updates you would > have created the repository which people unfamiliar with the history > would expect. The infrastructure side of this, on the face of it, sounds > very simple. What you describe is effectively how the development repository is built, so it's certainly a technical possibility. It does have implications though. Off the top of my head, I can think of: 1) Composing a new everything tree for updates would lead to larger compose times. That could possibly mean that getting updates out would take > 1 day per 'push'. We've been trying to improve updates push times so it would be a bit detrimental to that goal. 2) There might be GPL compliance issues 3) You would still need an 'updates-testing' repository given that this is a supposedly stable release. So there is still going to be at least one additional repo regardless. However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? josh From notting at redhat.com Wed Dec 2 16:05:10 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Dec 2009 11:05:10 -0500 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> Message-ID: <20091202160509.GC14426@nostromo.devel.redhat.com> Mat?j Cepl (mcepl at redhat.com) said: > Moreover, I don't know what's your problem with radeonhd driver in > Fedora. Hanz does IMHO excellent job on maintaining it and it > doesn't drag much additional resources on anybody (except on me, > perhaps, because I triage bugs for him as well, which is the reason > that this time I even a little know what I am talking about ;)). And > of course comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati > bugs (http://is.gd/59Hp0) is unfair, because there are many more > users of -ati driver, but at least it shows that radeonhd is really > not burning issue. > > What's the problem? Does not work at all with KMS, which is on by default; is unsupported by the people that maintain the servers and the rest of the drivers. Following a sane OAOO strategy, we'll get better results if we try and get all fixes on a single driver path moving forwards. Bill From jmoskovc at redhat.com Wed Dec 2 16:07:57 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Wed, 02 Dec 2009 17:07:57 +0100 Subject: abrt issues In-Reply-To: References: Message-ID: <4B1690DD.2020704@redhat.com> What is the question here, so I try to describe what's abrt trying so say: On 12/02/2009 02:28 PM, Neal Becker wrote: > Wondering about these odd messages: > > Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled > exception in /tmp/hgtests.eYmApF/install/bin/hg - hook detected an unhandled exception > Dec 2 07:40:12 nbecker6 abrtd: Directory 'pyhook-1259757612-30443' > creation detected - abrt daemon detected a new directory containing info about some crash > Dec 2 07:40:12 nbecker6 abrtd: Lock file > '/var/cache/abrt/pyhook-1259757612-30443.lock' is locked by process > 30445 - but at that time hook wasn't done with writing the info into, so the daemon had to wait... > Dec 2 07:40:12 nbecker6 python: abrt: Pyhook: Detected unhandled > exception in /tmp/hgtests.eYmApF/install/bin/hg - and the same crash occured again ... > Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any > package - now the daemon examined the info written by the hook and noticed that it doesn't belong to any package > Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting - so the daemon deleted it (saying this confusing message) > Dec 2 07:40:13 nbecker6 abrtd: Directory 'pyhook-1259757612-30446' > creation detected - now the daemon noticed the second crash > Dec 2 07:40:13 nbecker6 abrtd: Executable doesn't belong to any > package > Dec 2 07:40:13 nbecker6 abrtd: Corrupted or bad crash, deleting - and did the same as with the first one.. > Dec 2 07:45:56 nbecker6 python: abrt: Pyhook: Detected unhandled > exception in dumb.py > Dec 2 07:45:56 nbecker6 abrtd: Directory 'pyhook-1259757956-4737' > creation detected > Dec 2 07:45:56 nbecker6 abrtd: Lock file > '/var/cache/abrt/pyhook-1259757956-4737.lock' is locked by process > 4773 > Dec 2 07:45:56 nbecker6 abrtd: Executable doesn't belong to any > package > Dec 2 07:45:56 nbecker6 abrtd: Corrupted or bad crash, deleting > - and again ... -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From notting at redhat.com Wed Dec 2 16:09:41 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Dec 2009 11:09:41 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <20091202160941.GD14426@nostromo.devel.redhat.com> Matthew Booth (mbooth at redhat.com) said: > The separate updates directory has been a pain for as long as I've > been using RHL/Fedora Core/Fedora. It means you have two places to > look when searching for packages manually, and twice as much to > configure when you're configuring yum. It has never benefitted me, > or anybody I know, but it has caught me out on any number of > occasions. What's more, nobody really seems to know why it's like > that: it seems it's always been that way, and nobody ever bother to > fix it. > > So lets fix it. The package set at release time is only interesting > to historians. If any of them are really that bothered, I'm sure > somebody can come up with a yum module which finds the oldest > available version of a package in a repo. The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. Bill From naheemzaffar at gmail.com Wed Dec 2 16:11:01 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 2 Dec 2009 16:11:01 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160151.GA21874@linuxtx.org> References: <4B167C22.3000504@redhat.com> <20091202160151.GA21874@linuxtx.org> Message-ID: <3adc77210912020811q4651e3d1id6321e7acfe7a624@mail.gmail.com> 2009/12/2 Justin M. Forbes > The only downside to merging updates into the main repository... I would also assume that the repo data will need to be regenerated and often be much larger than the one that is for the updates only repository, so there will be acost to end users with this proposed change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajax at redhat.com Wed Dec 2 16:16:09 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 02 Dec 2009 11:16:09 -0500 Subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? In-Reply-To: References: <4B0E8A1C.9080501@beam.ltd.uk> <1259302128.6876.9.camel@localhost> <1259440690.18660.1.camel@localhost> <1259600511.20291.32.camel@localhost.localdomain> <4B141A0D.9060603@gmail.com> <604aa7910911301128l2db59635jc5d06918ad0d327f@mail.gmail.com> <1259621278.9312.774.camel@adam.local.net> Message-ID: <1259770569.7251.31387.camel@atropine.boston.devel.redhat.com> On Wed, 2009-12-02 at 11:01 +0000, Ikem Krueger wrote: > > Nope, Bryce doesn't get to work on upstream in any significant way as > > part of his Ubuntu work. I was chatting with Dave about this on IRC the > > other day. The most significant submission to upstream X.org that's ever > > come out of Ubuntu is a quirk table. (yippee.) > > Did you chatted with Bryce? Let's chat with git: atropine:~/xserver% git log --author=bryce | grep -c ^commit 0 atropine:~/drivers/intel% git log --author=bryce --pretty=oneline 6b93afc564a5e74b0eaaa46c95f557449951b3b9 add pipe a force quirk for Dell mini 6c56521bdc0443c0656271caaa795feb13bc1d6b pipe-a quirk for thinkpad x30 83377b543defdca7226d7c1a7794e4ff3d8b4c84 Pipe-A quirk for HP 2730p (bug #18852) 6c4e134a1a30785c2e5c6d57b21fde54a2dd3413 PipeA quirk for Quanta/W251U (launchpad bug #244242) afa630b448e5993850433c9f0b129758ec4d37b5 Add TV out quirk for HP Compaq nx6110 231a302013981cc597ba09ee89b367c8ab56e8ba Two more Dell quirks d91d9e6a2f2ba18b35cb6fd7bc3fe8bc617eb44f More Pipe A force quirks be746a90a87d7a9807fa4243493e7e4d48f7f1c0 More quirks from ubuntu/dell 37bc23660a8c346f1eaa6c93ed2c7a840828f0b0 Quirks from Ubuntu/Dell atropine:~/drivers/ati% git log --author=bryce --pretty=oneline c71b2f050e8996787eae463eddbfdb5864ffa65a radeon: AGPMode quirk needed for SiS e3659ed06fc5bb8817f1dbd7c2d6bc94c67b30f7 radeon: AGPMode quirk needed for IBM Thinkpad T40 with Mobility M7 LW 2391531ed6b7c11ddd5ab91b2369821cc5f8b8a7 radeon: AGPMode quirk needed for HP Omnibook 6200 49b57767d0d2c041517b0764c2ed2d2ba5a7092c Quirk for RV280 on 82865G/PE/P DRAM Controller/Host-Hub fe73d9a7dfe8ec5c8f1a8dc08e14b4e138aa9276 Add another AGP quirk 36a7dc6ea1e1929e986ab1159497c71521cb2f10 Additional AGP quirks 937b7ac2a259cf504a19dcf62a58b1db1afb8eb9 Add AGP quirk table 1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445 radeon: Fix pasto in connector table setup for vga powerbooks - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From berrange at redhat.com Wed Dec 2 16:19:16 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 2 Dec 2009 16:19:16 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160151.GA21874@linuxtx.org> References: <4B167C22.3000504@redhat.com> <20091202160151.GA21874@linuxtx.org> Message-ID: <20091202161916.GA21184@redhat.com> On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote: > On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: > > The separate updates directory has been a pain for as long as I've been > > using RHL/Fedora Core/Fedora. It means you have two places to look when > > searching for packages manually, and twice as much to configure when you're > > configuring yum. It has never benefitted me, or anybody I know, but it has > > caught me out on any number of occasions. What's more, nobody really seems > > to know why it's like that: it seems it's always been that way, and nobody > > ever bother to fix it. > > > The only downside to merging updates into the main repository is that > network installs from the repository will no longer install the "release" > they will install the updated release. QA that goes into that first > impression is no longer there, and your installs are not repeatable because > installing system A on one day and system B on another could end up with > different versions of packages. Of course you can always install from the > ISOs to avoid these problems. As things are, you have the choice of the > "release" as it was, or the updated release at install time. I am not > saying that this is a bad idea, in fact I rather like it, but there are > things to consider. I think this is quite a compelling reason not to touch it. Much as we'd like the updates repository to always be perfectly stable, there are still plenty of occassions when we hit problems with updates. Being able to reliably install the release at all times is pretty critical & saying we should install off ISO if we want a reliable install is not really an acceptable alternative since many people do all their installs straight off the network. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rc040203 at freenet.de Wed Dec 2 16:27:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Dec 2009 17:27:17 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160941.GD14426@nostromo.devel.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> Message-ID: <4B169565.6080406@freenet.de> On 12/02/2009 05:09 PM, Bill Nottingham wrote: > Matthew Booth (mbooth at redhat.com) said: >> The separate updates directory has been a pain for as long as I've >> been using RHL/Fedora Core/Fedora. It means you have two places to >> look when searching for packages manually, and twice as much to >> configure when you're configuring yum. It has never benefitted me, >> or anybody I know, but it has caught me out on any number of >> occasions. What's more, nobody really seems to know why it's like >> that: it seems it's always been that way, and nobody ever bother to >> fix it. >> >> So lets fix it. The package set at release time is only interesting >> to historians. If any of them are really that bothered, I'm sure >> somebody can come up with a yum module which finds the oldest >> available version of a package in a repo. > > The separate Everything tree that does not get obsoleted is required > in some form for GPL compliance, with respect to the ISO images that > we ship. Isn't this the "Fedora" repo? To my knowledge the "Fedora" repos corresponds 1:1 to the isos. Ralf From stickster at gmail.com Wed Dec 2 16:28:24 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 2 Dec 2009 11:28:24 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160941.GD14426@nostromo.devel.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> Message-ID: <20091202162824.GN3563@victoria.internal.frields.org> On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: > Matthew Booth (mbooth at redhat.com) said: > > The separate updates directory has been a pain for as long as I've > > been using RHL/Fedora Core/Fedora. It means you have two places to > > look when searching for packages manually, and twice as much to > > configure when you're configuring yum. It has never benefitted me, > > or anybody I know, but it has caught me out on any number of > > occasions. What's more, nobody really seems to know why it's like > > that: it seems it's always been that way, and nobody ever bother to > > fix it. > > > > So lets fix it. The package set at release time is only interesting > > to historians. If any of them are really that bothered, I'm sure > > somebody can come up with a yum module which finds the oldest > > available version of a package in a repo. > > The separate Everything tree that does not get obsoleted is required > in some form for GPL compliance, with respect to the ISO images that > we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From kevin at scrye.com Wed Dec 2 16:32:42 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 2 Dec 2009 09:32:42 -0700 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B169565.6080406@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <4B169565.6080406@freenet.de> Message-ID: <20091202093242.0d19ef61@ohm.scrye.com> On Wed, 02 Dec 2009 17:27:17 +0100 Ralf Corsepius wrote: > On 12/02/2009 05:09 PM, Bill Nottingham wrote: > > Matthew Booth (mbooth at redhat.com) said: > >> The separate updates directory has been a pain for as long as I've > >> been using RHL/Fedora Core/Fedora. It means you have two places to > >> look when searching for packages manually, and twice as much to > >> configure when you're configuring yum. It has never benefitted me, > >> or anybody I know, but it has caught me out on any number of > >> occasions. What's more, nobody really seems to know why it's like > >> that: it seems it's always been that way, and nobody ever bother to > >> fix it. > >> > >> So lets fix it. The package set at release time is only interesting > >> to historians. If any of them are really that bothered, I'm sure > >> somebody can come up with a yum module which finds the oldest > >> available version of a package in a repo. > > > > The separate Everything tree that does not get obsoleted is required > > in some form for GPL compliance, with respect to the ISO images that > > we ship. > Isn't this the "Fedora" repo? > > To my knowledge the "Fedora" repos corresponds 1:1 to the isos. To the DVD iso, yes. To any of the spins/desktop/live... nope. They use packages from Everything/ kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rc040203 at freenet.de Wed Dec 2 16:43:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Dec 2009 17:43:47 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202093242.0d19ef61@ohm.scrye.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <4B169565.6080406@freenet.de> <20091202093242.0d19ef61@ohm.scrye.com> Message-ID: <4B169943.30900@freenet.de> On 12/02/2009 05:32 PM, Kevin Fenzi wrote: > On Wed, 02 Dec 2009 17:27:17 +0100 > Ralf Corsepius wrote: > >> On 12/02/2009 05:09 PM, Bill Nottingham wrote: >>> Matthew Booth (mbooth at redhat.com) said: >>>> The separate updates directory has been a pain for as long as I've >>>> been using RHL/Fedora Core/Fedora. It means you have two places to >>>> look when searching for packages manually, and twice as much to >>>> configure when you're configuring yum. It has never benefitted me, >>>> or anybody I know, but it has caught me out on any number of >>>> occasions. What's more, nobody really seems to know why it's like >>>> that: it seems it's always been that way, and nobody ever bother to >>>> fix it. >>>> >>>> So lets fix it. The package set at release time is only interesting >>>> to historians. If any of them are really that bothered, I'm sure >>>> somebody can come up with a yum module which finds the oldest >>>> available version of a package in a repo. >>> >>> The separate Everything tree that does not get obsoleted is required >>> in some form for GPL compliance, with respect to the ISO images that >>> we ship. >> Isn't this the "Fedora" repo? >> >> To my knowledge the "Fedora" repos corresponds 1:1 to the isos. > > To the DVD iso, yes. > > To any of the spins/desktop/live... nope. They use packages from > Everything/ A question however remains: Does the FSF/GPL demand to keep a repo around for ISOs? A "rolling Everything" would not touch the ISOs. They would still be around. Ralf From notting at redhat.com Wed Dec 2 16:44:59 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Dec 2009 11:44:59 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B169943.30900@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <4B169565.6080406@freenet.de> <20091202093242.0d19ef61@ohm.scrye.com> <4B169943.30900@freenet.de> Message-ID: <20091202164458.GF14426@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > Does the FSF/GPL demand to keep a repo around for ISOs? > A "rolling Everything" would not touch the ISOs. They would still be around. The LiveCD/spins satisfy their source requirements via the source repositories; they do not compose separate live source images. Bill From cdahlin at redhat.com Wed Dec 2 16:54:50 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Wed, 2 Dec 2009 11:54:50 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202162824.GN3563@victoria.internal.frields.org> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <20091202162824.GN3563@victoria.internal.frields.org> Message-ID: <20091202165449.GA29353@fearengine.rdu.redhat.com> On Wed, Dec 02, 2009 at 11:28:24AM -0500, Paul W. Frields wrote: > > > > The separate Everything tree that does not get obsoleted is required > > in some form for GPL compliance, with respect to the ISO images that > > we ship. Any new solution would have to preserve this. > > Might there also be export compliance implications too? What manner of export issues? This change doesn't, afaik, affect where export-restricted software appears in any way. --CJD From cdahlin at redhat.com Wed Dec 2 17:01:49 2009 From: cdahlin at redhat.com (Casey Dahlin) Date: Wed, 2 Dec 2009 12:01:49 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160622.GD14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> Message-ID: <20091202170149.GB29353@fearengine.rdu.redhat.com> On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote: > 1) Composing a new everything tree for updates would lead to larger > compose times. That could possibly mean that getting updates out would > take > 1 day per 'push'. We've been trying to improve updates push > times so it would be a bit detrimental to that goal. > This might be a good opportunity to look at some way of pushing incremental sets of packages rather than re-building the entire yum repo each time. Mashing is not a cheap operation. > 2) There might be GPL compliance issues > > 3) You would still need an 'updates-testing' repository given that this > is a supposedly stable release. So there is still going to be at least > one additional repo regardless. > We have tags for updates that mark them as bugfix/feature/security. Maybe we could have one for "testing" which would keep yum from installing the package unless explicitly asked or specially configured. > However, other than 'browsing manually for packages', I'm not really > sure what problem you are trying to solve by getting rid of the > updates repository. It would seem like this has quite a bit of cost > for relatively little to no real gain? > This is true. I don't know that manual package browsing is a use case we've ever been interested in, and if we're going to be interested in it there's probably a better way (search engine in the Fedora community portal comes to mind). > josh You owe me $5. --CJD From skvidal at fedoraproject.org Wed Dec 2 17:08:30 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 12:08:30 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202162824.GN3563@victoria.internal.frields.org> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <20091202162824.GN3563@victoria.internal.frields.org> Message-ID: On Wed, 2 Dec 2009, Paul W. Frields wrote: > On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: >> we ship. Any new solution would have to preserve this. > > Might there also be export compliance implications too? > A larger isssue is constantly having the repodata for the everything repo be: 1. growing 2. changing So now instead of having a 15K pkg repo that never changes you have an ever-growing repo that never shrinks in size that changes what? 3 times a week? -sv From rc040203 at freenet.de Wed Dec 2 17:09:52 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Dec 2009 18:09:52 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202170149.GB29353@fearengine.rdu.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> Message-ID: <4B169F60.2090602@freenet.de> On 12/02/2009 06:01 PM, Casey Dahlin wrote: > On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote: >> However, other than 'browsing manually for packages', I'm not really >> sure what problem you are trying to solve by getting rid of the >> updates repository. It would seem like this has quite a bit of cost >> for relatively little to no real gain? >> > > This is true. It is not true. * It shifts "costs" from "users" to "vendor" and from "mirrors" to "master". * It helps users who are using networked installs to spare bandwidth (avoids downloading obsolete packages from "Everything"/"Fedora"). Admitted, for most users, it would change almost nothing. Ralf From mbooth at redhat.com Wed Dec 2 17:37:19 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 17:37:19 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160151.GA21874@linuxtx.org> References: <4B167C22.3000504@redhat.com> <20091202160151.GA21874@linuxtx.org> Message-ID: <4B16A5CF.9050907@redhat.com> On 02/12/09 16:01, Justin M. Forbes wrote: > On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: >> The separate updates directory has been a pain for as long as I've been >> using RHL/Fedora Core/Fedora. It means you have two places to look when >> searching for packages manually, and twice as much to configure when you're >> configuring yum. It has never benefitted me, or anybody I know, but it has >> caught me out on any number of occasions. What's more, nobody really seems >> to know why it's like that: it seems it's always been that way, and nobody >> ever bother to fix it. >> > The only downside to merging updates into the main repository is that > network installs from the repository will no longer install the "release" > they will install the updated release. QA that goes into that first > impression is no longer there, and your installs are not repeatable because > installing system A on one day and system B on another could end up with > different versions of packages. Of course you can always install from the > ISOs to avoid these problems. As things are, you have the choice of the > "release" as it was, or the updated release at install time. I am not > saying that this is a bad idea, in fact I rather like it, but there are > things to consider. That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or F11 feature that anaconda allowed the user to specify that updates be installed at installation time? Certainly I used to have Debianites crow at me that my installation was vulnerable until I updated it. Not only that, but I had to download updated packages twice. These days I always install with updates. I find the installation argument dubious at best. Still, we could rename the main repo the 'installation' repo, and nothing but anaconda would ever look at it. Everything else would look at the main repo, which would be the same as the current updates repo except with everything in it from the start. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From jkeating at redhat.com Wed Dec 2 17:36:28 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 09:36:28 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <1259775388.12203.70.camel@localhost.localdomain> On Wed, 2009-12-02 at 14:39 +0000, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. It has never benefitted me, or anybody I know, > but it has caught me out on any number of occasions. What's more, nobody > really seems to know why it's like that: it seems it's always been that > way, and nobody ever bother to fix it. > > So lets fix it. The package set at release time is only interesting to > historians. If any of them are really that bothered, I'm sure somebody > can come up with a yum module which finds the oldest available version > of a package in a repo. > This runs us into a few different problems. 1) current compose tools do a fresh compose of a tag every time, into a fresh directory. It is not easy to just 'add' newer things to a directory and only keep X number around. 2) the metadata generation step for the Everything repo is long, and very resource intensive. Doing it every time we push updates would cause unreasonable stress on the infrastructure and the people doing the pushes. 3) the repodata for the Everything repo is huge. Forcing users to download the entire thing every day or so as updates are pushed would cause unreasonable stress on the users's bandwidth, local machine resources to parse it, and the servers offering it for download. I think there are more, but those above are enough for me to not persue this avenue currently. The pros of this change, which seem small to me, don't outweigh the above cons, and we have far more other issues we could be spending time and resources on. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mbooth at redhat.com Wed Dec 2 17:38:57 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 17:38:57 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160941.GD14426@nostromo.devel.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> Message-ID: <4B16A631.9060804@redhat.com> On 02/12/09 16:09, Bill Nottingham wrote: > Matthew Booth (mbooth at redhat.com) said: >> The separate updates directory has been a pain for as long as I've >> been using RHL/Fedora Core/Fedora. It means you have two places to >> look when searching for packages manually, and twice as much to >> configure when you're configuring yum. It has never benefitted me, >> or anybody I know, but it has caught me out on any number of >> occasions. What's more, nobody really seems to know why it's like >> that: it seems it's always been that way, and nobody ever bother to >> fix it. >> >> So lets fix it. The package set at release time is only interesting >> to historians. If any of them are really that bothered, I'm sure >> somebody can come up with a yum module which finds the oldest >> available version of a package in a repo. > > The separate Everything tree that does not get obsoleted is required > in some form for GPL compliance, with respect to the ISO images that > we ship. Any new solution would have to preserve this. This argument sounds weird to me. However, there no reason you can't keep around as many repositories as you like as long as the One True Repository exists and people can use it exclusively. Currently it doesn't exist. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From jkeating at redhat.com Wed Dec 2 17:40:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 09:40:45 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B169F60.2090602@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> Message-ID: <1259775645.12203.73.camel@localhost.localdomain> On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote: > > * It shifts "costs" from "users" to "vendor" > and from "mirrors" to "master". > * It helps users who are using networked installs to spare bandwidth > (avoids downloading obsolete packages from "Everything"/"Fedora"). > > Admitted, for most users, it would change almost nothing. > > People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, especially if we went the route of having updates-testing mixed in and only marked by some update tag. We'd have to keep sets of what's in updates-testing, updates, and the GA release set, and all of that would be in one repodata set. Everybody doing a network install, whether they wanted updates, updates-testing, or not would have to download and consume that larger repodata, introducing a higher cost for them. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From walters at verbum.org Wed Dec 2 17:44:31 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 2 Dec 2009 17:44:31 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16A5CF.9050907@redhat.com> References: <4B167C22.3000504@redhat.com> <20091202160151.GA21874@linuxtx.org> <4B16A5CF.9050907@redhat.com> Message-ID: On Wed, Dec 2, 2009 at 5:37 PM, Matthew Booth wrote: > > That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or F11 > feature that anaconda allowed the user to specify that updates be installed > at installation time? Certainly I used to have Debianites crow at me that my > installation was vulnerable until I updated it. Not only that, but I had to > download updated packages twice. These days I always install with updates. I > find the installation argument dubious at best. This could be equivalently fixed by have the desktop check on initial login if there are any updates available before letting you launch say the web browser. However - we have bigger issues related to updates to fix. From mbooth at redhat.com Wed Dec 2 17:47:17 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 17:47:17 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160622.GD14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> Message-ID: <4B16A825.2040803@redhat.com> On 02/12/09 16:06, Josh Boyer wrote: > On Wed, Dec 02, 2009 at 03:44:08PM +0000, Matthew Booth wrote: >> On 02/12/09 15:26, Josh Boyer wrote: >>> On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: >>>> The separate updates directory has been a pain for as long as I've been >>>> using RHL/Fedora Core/Fedora. It means you have two places to look when >>>> searching for packages manually, and twice as much to configure when >>>> you're configuring yum. It has never benefitted me, or anybody I know, >>>> but it has caught me out on any number of occasions. What's more, nobody >>>> really seems to know why it's like that: it seems it's always been that >>>> way, and nobody ever bother to fix it. >>>> >>>> So lets fix it. >>> >>> And how do you propose to do that? >> >> Unfortunately I'm not intimately familiar with Fedora infrastructure >> under-the-hood. However, I would hope that, technically at least, it >> wouldn't be much more than a systematic removal of all updates >> repositories and redirecting files which would have gone into them into >> the main repositories instead. This stems from the observation that if >> you copied everything from the main repository into updates you would >> have created the repository which people unfamiliar with the history >> would expect. The infrastructure side of this, on the face of it, sounds >> very simple. > > What you describe is effectively how the development repository is built, > so it's certainly a technical possibility. It does have implications > though. Off the top of my head, I can think of: > > 1) Composing a new everything tree for updates would lead to larger > compose times. That could possibly mean that getting updates out would > take> 1 day per 'push'. We've been trying to improve updates push > times so it would be a bit detrimental to that goal. I can't comment on this. > 2) There might be GPL compliance issues This line of reasoning sounds bizarre to me. You can publish things in multiple places. > 3) You would still need an 'updates-testing' repository given that this > is a supposedly stable release. So there is still going to be at least > one additional repo regardless. Indeed, however that would only be testers. Most people can ignore it. > However, other than 'browsing manually for packages', I'm not really > sure what problem you are trying to solve by getting rid of the > updates repository. It would seem like this has quite a bit of cost > for relatively little to no real gain? Any tool which deals with repositories requires the repo to be configured twice. Off the top of my head I can think of: 1. yum separate repo and updates-repo in yum.conf. 2. livecd tools two repos in kickstart 3. revisor two repos in kickstart 4. febootstrap two repos on command line Given that you almost always want updates, it would an improvement if all of the above could be replaced with a single configuration. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From jkeating at redhat.com Wed Dec 2 17:48:59 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 09:48:59 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <1259776139.12203.80.camel@localhost.localdomain> On Wed, 2009-12-02 at 14:39 +0000, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. It has never benefitted me, or anybody I know, > but it has caught me out on any number of occasions. What's more, nobody > really seems to know why it's like that: it seems it's always been that > way, and nobody ever bother to fix it. If the real motivation is "I want to manually browse a single directory for all the packages" I have an alternate proposal. createrepo has the ability to take a list of packages (as paths) for input. I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), yet still maintain different repo paths for the different logical separation of rpms. One path would be the "Everything" repo, which would have repodata for the GA versions of the packages. Another path would be the "updates" repo, which has repodata for the current set of stable updates, and a third path would be the "updates-testing" repo, which has repodata for the current set of testing updates. All the repodata would reference files in a central directory (or directory tree). You could achieve a single place to manually look for packages, whilst users would still have logically separated repository metadata. Of course, I'm papering over the amount of work it would take to modify our compose tools to perform in this way, and the added work mirrors would have (they don't normally have to scan the Everything tree for changes, but now they'd have to scan a giant tree of rpms every rsync to see if anything changed), and the added complexity of trying to keep track of which packages are active in the repos and which aren't, and keeping the central directory pruned of obsolete packages. I'm certainly not signing up to work on this, but I am offering this as an alternative approach. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From fedoraproject at cyberpear.com Wed Dec 2 17:54:50 2009 From: fedoraproject at cyberpear.com (James Cassell) Date: Wed, 02 Dec 2009 12:54:50 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16A825.2040803@redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <4B16A825.2040803@redhat.com> Message-ID: On Wed, 02 Dec 2009 12:47:17 -0500, Matthew Booth wrote: > > Any tool which deals with repositories requires the repo to be > configured twice. Off the top of my head I can think of: > 1. yum > separate repo and updates-repo in yum.conf. > 2. livecd tools > two repos in kickstart > 3. revisor > two repos in kickstart > 4. febootstrap > two repos on command line > Given that you almost always want updates, it would an improvement if > all of the above could be replaced with a single configuration. > Matt So, create a meta-repo that just says "I'm the combination of these several repos over here"? Of course, it'd require modification of all the programs that know how to talk to repos... Personally, I think the current repo setup is just fine as it is. -- James Cassell From mbooth at redhat.com Wed Dec 2 17:58:58 2009 From: mbooth at redhat.com (Matthew Booth) Date: Wed, 02 Dec 2009 17:58:58 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259775645.12203.73.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> Message-ID: <4B16AAE2.2000903@redhat.com> On 02/12/09 17:40, Jesse Keating wrote: > On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote: >> >> * It shifts "costs" from "users" to "vendor" >> and from "mirrors" to "master". >> * It helps users who are using networked installs to spare bandwidth >> (avoids downloading obsolete packages from "Everything"/"Fedora"). >> >> Admitted, for most users, it would change almost nothing. >> >> > > People doing network installs can either add the updates repo to their > kickstart, or check the box in the anaconda UI, so that the updates > repos are considered at install time. No download of duplicate data. > > In fact, having separate repos would likely cost less bandwidth. If we > only had one combined repo, there would be many duplicate packages, > especially if we went the route of having updates-testing mixed in and > only marked by some update tag. We'd have to keep sets of what's in > updates-testing, updates, and the GA release set, and all of that would > be in one repodata set. Everybody doing a network install, whether they > wanted updates, updates-testing, or not would have to download and > consume that larger repodata, introducing a higher cost for them. There's an argument for separate updates-testing. However, my original point was that nobody is interested in the original GA release set except historians. People should, and we rightly help them, be installing updates frequently. So, people doing network installs fall into: People who want to install GA only: Hopefully nobody. The only good reason to do this is if the distro is broken. People who want to install GA+updates: Everybody except testers. People who want GA+updates+testing: testers. The GA package could be kept around as a separate, static repo nobody uses under normal circumstances. Combining GA+updates into a single repo would not consume additional bandwidth for anybody at all, and only testers would have to do any additional configuration. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From berrange at redhat.com Wed Dec 2 18:00:15 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 2 Dec 2009 18:00:15 +0000 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16A825.2040803@redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <4B16A825.2040803@redhat.com> Message-ID: <20091202180015.GB21184@redhat.com> On Wed, Dec 02, 2009 at 05:47:17PM +0000, Matthew Booth wrote: > On 02/12/09 16:06, Josh Boyer wrote: > >On Wed, Dec 02, 2009 at 03:44:08PM +0000, Matthew Booth wrote: > >>On 02/12/09 15:26, Josh Boyer wrote: > >>>On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote: > >>>>The separate updates directory has been a pain for as long as I've been > >>>>using RHL/Fedora Core/Fedora. It means you have two places to look when > >>>>searching for packages manually, and twice as much to configure when > >>>>you're configuring yum. It has never benefitted me, or anybody I know, > >>>>but it has caught me out on any number of occasions. What's more, nobody > >>>>really seems to know why it's like that: it seems it's always been that > >>>>way, and nobody ever bother to fix it. > >>>> > >>>>So lets fix it. > >>> > >>>And how do you propose to do that? > >> > >>Unfortunately I'm not intimately familiar with Fedora infrastructure > >>under-the-hood. However, I would hope that, technically at least, it > >>wouldn't be much more than a systematic removal of all updates > >>repositories and redirecting files which would have gone into them into > >>the main repositories instead. This stems from the observation that if > >>you copied everything from the main repository into updates you would > >>have created the repository which people unfamiliar with the history > >>would expect. The infrastructure side of this, on the face of it, sounds > >>very simple. > > > >What you describe is effectively how the development repository is built, > >so it's certainly a technical possibility. It does have implications > >though. Off the top of my head, I can think of: > > > >1) Composing a new everything tree for updates would lead to larger > >compose times. That could possibly mean that getting updates out would > >take> 1 day per 'push'. We've been trying to improve updates push > >times so it would be a bit detrimental to that goal. > > I can't comment on this. > > >2) There might be GPL compliance issues > > This line of reasoning sounds bizarre to me. You can publish things in > multiple places. > > >3) You would still need an 'updates-testing' repository given that this > >is a supposedly stable release. So there is still going to be at least > >one additional repo regardless. > > Indeed, however that would only be testers. Most people can ignore it. > > >However, other than 'browsing manually for packages', I'm not really > >sure what problem you are trying to solve by getting rid of the > >updates repository. It would seem like this has quite a bit of cost > >for relatively little to no real gain? > > Any tool which deals with repositories requires the repo to be > configured twice. Off the top of my head I can think of: > > 1. yum > separate repo and updates-repo in yum.conf. > 2. livecd tools > two repos in kickstart > 3. revisor > two repos in kickstart > 4. febootstrap > two repos on command line > > Given that you almost always want updates, it would an improvement if > all of the above could be replaced with a single configuration. That sounds like something for a yum plugin to solve. eg Have a URL you can query to get a list of valid repos for a particular release. Have a YUM plugin implements a virtual repo, and this repo simply fetches that URL, and then exposes a package set which is the union of all repos listed. That way we still have separate YUM repos & separate metadata hosted on all the servers, but the clients can all be configured with this single virtual repo Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From skvidal at fedoraproject.org Wed Dec 2 18:02:53 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 13:02:53 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <4B16A825.2040803@redhat.com> Message-ID: On Wed, 2 Dec 2009, James Cassell wrote: > On Wed, 02 Dec 2009 12:47:17 -0500, Matthew Booth wrote: > > So, create a meta-repo that just says "I'm the combination of these several > repos over here"? Of course, it'd require modification of all the programs > that know how to talk to repos... > it wouldn't require any code changes at all. createrepo/mergerepos can do this now and yum interacts with them fine - EXCEPT it gets into mirroring issues. :-/ -sv From awilliam at redhat.com Wed Dec 2 18:05:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 02 Dec 2009 10:05:24 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160622.GD14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> Message-ID: <1259777124.26397.1.camel@adam.local.net> On Wed, 2009-12-02 at 11:06 -0500, Josh Boyer wrote: > so it's certainly a technical possibility. It does have implications > though. Off the top of my head, I can think of: > > 1) Composing a new everything tree for updates would lead to larger > compose times. That could possibly mean that getting updates out would > take > 1 day per 'push'. We've been trying to improve updates push > times so it would be a bit detrimental to that goal. > > 2) There might be GPL compliance issues > > 3) You would still need an 'updates-testing' repository given that this > is a supposedly stable release. So there is still going to be at least > one additional repo regardless. 4) makes it much harder to recover from broken updates by simply pulling in the original release version of the package. Yes, the correct fix to this is not to ship broken updates, but we _do_ ship broken updates, and at least people have this option available currently. (And we have 'yum downgrade' which mostly automates the procedure if you're lucky.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Wed Dec 2 18:08:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 10:08:30 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16AAE2.2000903@redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B16AAE2.2000903@redhat.com> Message-ID: <1259777310.12203.94.camel@localhost.localdomain> On Wed, 2009-12-02 at 17:58 +0000, Matthew Booth wrote: > The GA package could be kept around as a separate, static repo nobody > uses under normal circumstances. Combining GA+updates into a single repo > would not consume additional bandwidth for anybody at all, and only > testers would have to do any additional configuration. After initial install, a GA+updates repo would cause consumption of more bandwidth, as the repodata would change on a nearly daily basis causing rather large repodata files to be downloaded over and over and over again. Instead what we have now is a static GA repo that is downloaded usually once, and a much much much smaller updates repo that is downloaded more frequently, but since it is much smaller the impact is much lower. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed Dec 2 18:09:25 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 13:09:25 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259776139.12203.80.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> Message-ID: On Wed, 2 Dec 2009, Jesse Keating wrote: > On Wed, 2009-12-02 at 14:39 +0000, Matthew Booth wrote: >> The separate updates directory has been a pain for as long as I've been >> using RHL/Fedora Core/Fedora. It means you have two places to look when >> searching for packages manually, and twice as much to configure when >> you're configuring yum. It has never benefitted me, or anybody I know, >> but it has caught me out on any number of occasions. What's more, nobody >> really seems to know why it's like that: it seems it's always been that >> way, and nobody ever bother to fix it. > > If the real motivation is "I want to manually browse a single directory > for all the packages" I have an alternate proposal. > > createrepo has the ability to take a list of packages (as paths) for > input. I hypothesize that we could place all rpms for a given release > in a single directory (seth will hate this as he wants to split them up > based on first letter of their name for better filesystem performance), And better webbrowser and webserver performance since having A GIANT list eats my webbrowser often. > yet still maintain different repo paths for the different logical > separation of rpms. One path would be the "Everything" repo, which > would have repodata for the GA versions of the packages. Another path > would be the "updates" repo, which has repodata for the current set of > stable updates, and a third path would be the "updates-testing" repo, > which has repodata for the current set of testing updates. All the > repodata would reference files in a central directory (or directory > tree). the paths don't matter - you just need to generate the lists and feed that into SOME sort of metadata. > Of course, I'm papering over the amount of work it would take to modify > our compose tools to perform in this way, and the added work mirrors > would have (they don't normally have to scan the Everything tree for > changes, but now they'd have to scan a giant tree of rpms every rsync to > see if anything changed), and the added complexity of trying to keep > track of which packages are active in the repos and which aren't, and > keeping the central directory pruned of obsolete packages. The compose tools would just have to make a list of pkgs in what dirs - a list they already have. I guess what I don't see is what the net benefit is here. the merger of repos is already happening at the yum layer. -sv From jkeating at redhat.com Wed Dec 2 18:15:56 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 10:15:56 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> Message-ID: <1259777756.12203.95.camel@localhost.localdomain> On Wed, 2009-12-02 at 13:09 -0500, Seth Vidal wrote: > I guess what I don't see is what the net benefit is here. From what I can gather... A) a single path to look at when manually looking for rpms. B) only one config entry to mess with when modifying repos for a release (my alternate proposal does not solve this one) > > the merger of repos is already happening at the yum layer. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From nathanael at gnat.ca Wed Dec 2 18:31:59 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 02 Dec 2009 11:31:59 -0700 Subject: F12 Yum/package kit bug?? Message-ID: <4B16B29F.80904@gnat.ca> Over the last few days I have been unable to install updates via the package kit applet that pops up. I get the following output after clicking 'install updates'. Error Type: Error Value: Error getting repository data for installed, repository not found File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in main() File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main backend.dispatcher(sys.argv[1:]) File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 710, in dispatcher self.dispatch_command(args[0], args[1:]) File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 657, in dispatch_command self.update_packages(only_trusted, package_ids) File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in update_packages signed = self._is_package_repo_signed(pkg) File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in _is_package_repo_signed repo = self.yumbase.repos.getRepo(pkg.repoid) File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo 'Error getting repository data for $s, repository not found' $ (repoid) However yum update functions properly. Is this a known bug? From nicolas.mailhot at laposte.net Wed Dec 2 18:35:03 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 02 Dec 2009 19:35:03 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259776139.12203.80.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> Message-ID: <1259778903.24751.7.camel@arekh.okg> Since people are posting wishes, here is mine: 1. stop shuffling packages from directory to directory as they get promoted/demoted from release to release 2. have a single authoritative URL for each package 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) 4. generate indexes of the kojipkgs.fedoraproject.org tree that represent Fedora X, Fedora X + updates, Fedora X + testing, etc. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at fedoraproject.org Wed Dec 2 18:34:58 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 13:34:58 -0500 (EST) Subject: F12 Yum/package kit bug?? In-Reply-To: <4B16B29F.80904@gnat.ca> References: <4B16B29F.80904@gnat.ca> Message-ID: On Wed, 2 Dec 2009, Nathanael D. Noblet wrote: > Over the last few days I have been unable to install updates via the package > kit applet that pops up. I get the following output after clicking 'install > updates'. > > Error Type: > Error Value: Error getting repository data for installed, repository not > found > File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in > > main() > File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main > backend.dispatcher(sys.argv[1:]) > File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 710, in > dispatcher > self.dispatch_command(args[0], args[1:]) > File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 657, in > dispatch_command > self.update_packages(only_trusted, package_ids) > File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in > update_packages > signed = self._is_package_repo_signed(pkg) > File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in > _is_package_repo_signed > repo = self.yumbase.repos.getRepo(pkg.repoid) > File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo > 'Error getting repository data for $s, repository not found' $ (repoid) > > > However yum update functions properly. Is this a known bug? > yes. It's in PK and I believe it's been fixed upstream. -sv From cmadams at hiwaay.net Wed Dec 2 19:16:17 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 2 Dec 2009 13:16:17 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B167C22.3000504@redhat.com> References: <4B167C22.3000504@redhat.com> Message-ID: <20091202191617.GC1074359@hiwaay.net> Once upon a time, Matthew Booth said: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when > you're configuring yum. Are these really significant issues for a significant number of users? Not many people go looking manually for packages, since there are many tools to do it easier (yum, PK, repoquery, etc.). The repos are automatically configured with fedora-release; how often are you configuring yum? The only time I have to care about this is if I'm writing a kickstart file, but it is one extra line (and then I copy the same kickstart base over and over). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From airlied at redhat.com Wed Dec 2 20:20:20 2009 From: airlied at redhat.com (Dave Airlie) Date: Thu, 03 Dec 2009 06:20:20 +1000 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> Message-ID: <1259785220.3950.1.camel@localhost> On Wed, 2009-12-02 at 08:04 +0100, Mat?j Cepl wrote: > Dne 1.12.2009 21:43, Bill Nottingham napsal(a): > > If the e1000 driver is broken in the kernel for some people, we don't support > > shipping an alternate driver. If a new version of the intel graphics driver > > is broken for some people, we don't support shipping a pre-KMS version > > of the driver. > > > > Why would we do differently here? > > Because if e1000 is broken, we can be sure with reasonably high level of > certainity, it will be fixed without undue delay. For Xorg drivers > (especially with regards to 3D support) we have hope that it will be > slightly better in the next Fedora release, but complete coverage is > still just a dream. > > Moreover, I don't know what's your problem with radeonhd driver in > Fedora. Hanz does IMHO excellent job on maintaining it and it doesn't > drag much additional resources on anybody (except on me, perhaps, > because I triage bugs for him as well, which is the reason that this > time I even a little know what I am talking about ;)). And of course > comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati bugs > (http://is.gd/59Hp0) is unfair, because there are many more users of > -ati driver, but at least it shows that radeonhd is really not burning > issue. 3D is a misnomer, radeonhd vs radeon has nothing whatsoever to do with the 3D stack. The big issue is with KMS on using radeonhd is like shooting yourself in the face. Either we need to patch radeonhd in Fedora to not start with KMS enabled or remove it from the distro. Dave. From skvidal at fedoraproject.org Wed Dec 2 20:52:03 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 15:52:03 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259777756.12203.95.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259777756.12203.95.camel@localhost.localdomain> Message-ID: On Wed, 2 Dec 2009, Jesse Keating wrote: > On Wed, 2009-12-02 at 13:09 -0500, Seth Vidal wrote: >> I guess what I don't see is what the net benefit is here. > > From what I can gather... > > A) a single path to look at when manually looking for rpms. Isn't this, eventually, what the packagedb is supposed to be able to do? > B) only one config entry to mess with when modifying repos for a release > (my alternate proposal does not solve this one) This one seems pretty minor - you only need to do this once. and most people will do it never. -sv From skvidal at fedoraproject.org Wed Dec 2 20:53:30 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 15:53:30 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259778903.24751.7.camel@arekh.okg> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> Message-ID: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: > Since people are posting wishes, here is mine: > > 1. stop shuffling packages from directory to directory as they get > promoted/demoted from release to release we sort of do this now with hardlinks - the problem is when we have to resign the pkgs. > 2. have a single authoritative URL for each package packagedb... > 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org > (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. > 4. generate indexes of the kojipkgs.fedoraproject.org tree that > represent Fedora X, Fedora X + updates, Fedora X + testing, etc. this is intriguing but expensive on kojipkgs. -sv From hun at n-dimensional.de Wed Dec 2 21:12:00 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Wed, 2 Dec 2009 22:12:00 +0100 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <1259785220.3950.1.camel@localhost> References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> <1259785220.3950.1.camel@localhost> Message-ID: <20091202221200.2425bc84@n-dimensional.de> On Thu, 03 Dec 2009 06:20:20 +1000 Dave Airlie wrote: > The big issue is with KMS on using radeonhd is like shooting yourself > in the face. Either we need to patch radeonhd in Fedora to not start > with KMS enabled or remove it from the distro. I am working on such a patch to radeonhd right now. For some reason, the necessary information on how to do that is much easier to find now than it was back then when KMS was first introduced to Fedora when I first tried to write one. -- Hans Ulrich Niedermann From dcbw at redhat.com Wed Dec 2 21:32:48 2009 From: dcbw at redhat.com (Dan Williams) Date: Wed, 02 Dec 2009 13:32:48 -0800 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B14EEE1.2000802@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> Message-ID: <1259789568.17666.53.camel@localhost.localdomain> On Tue, 2009-12-01 at 10:24 +0000, Terry Barnaby wrote: > On 12/01/2009 07:50 AM, Dan Williams wrote: > > On Mon, 2009-11-30 at 19:52 +0000, Terry Barnaby wrote: > >> On 11/30/2009 06:12 PM, Dan Williams wrote: > >>> On Mon, 2009-11-30 at 09:55 +0000, Terry Barnaby wrote: > >>>> On 11/29/2009 11:30 PM, Dan Williams wrote: > >>>>> On Sat, 2009-11-28 at 09:10 +0000, Terry Barnaby wrote: > >>>>>> On 11/28/2009 08:35 AM, Rakesh Pandit wrote: > >>>>>>> 2009/11/28 Terry Barnaby wrote: > >>>>>>>> If the NetworkManager service is running, but not managing the current > >>>>>>>> network connection, then Firefox starts up in offline mode. > >>>>>>>> > >>>>>>>> Is this a bug in NetworkManager or Firefox ? > >>>>>>>> > >>>>>>> > >>>>>>> This is odd behaviour and needs to be fixed. I would suggest open up a > >>>>>>> bug against firefox. I know one can change > >>>>>>> toolkit.networkmanager.disable preference, but it is a PITA for our > >>>>>>> users. One of use cases is: Sometime network manager does not connect > >>>>>>> me via my CDMA usb modem (in case signal is weak), but wvdial does and > >>>>>>> once I switch from NM to wvdial, my firefox gets to offline mode, > >>>>>>> which I don't expect it to as I am connected. > >>>>>>> > >>>>>> Ok, filed as: 542078 > >>>>> > >>>>> NetworkManager is intended to control the default internet connection. > >>>>> If NetworkManager cannot control the default internet connection, then > >>>>> you may not want to use NetworkManager. > >>>>> > >>>>> In your case, you're using a mobile broadband device. The real bug here > >>>>> is that for whatever reason, NM/MM aren't connecting your modem, and we > >>>>> should follow up on that bug instead. > >>>>> > >>>>> Dan > >>>>> > >>>> I am not using a mobile broadband device. The network connection my systems > >>> > >>> My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G > >>> connection. > >>> > >>>> use is not just the Internet it is a local network LAN connection that also > >>>> serves the internet. Most of my systems use a local network server which > >>>> provides NIS, /home and /data using NFS and VPN etc. I normally use the > >>>> service "network" to bring up wired or wireless networking for this. Fedora, > >>>> by default, uses NetworkManager to manage all network devices though. I use > >>>> the service "network" as, for some reason, the NetworkManager service is > >>>> started after the netfs and other services are started. Is there a reason > >>>> for this ?? > >>> > >>> No particular reason, in fact that looks like a bug. NM no longer > >>> depends on HAL, but that dependency is still in the initscript, which > >>> looks like it pushes NM later than netfs. > >>> > >>> But in reality, you're looking for a dependency based initsystem which > >>> we don't quite yet have. There are already scripts that kick netfs to > >>> mount stuff when NM brings the network up > >>> (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous > >>> bootup *and* your mounts. The rest of the system, if it requires > >>> something from the mounted directories, needs to be smart enough to know > >>> that. > >>> > >>> If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network, > >>> which causes the NetworkManager initscript to block until a network > >>> connection is brought up, or 30 seconds have passed. > >>> > >>>> I can obviously turn of the NetworkManager service, which I have done on the > >>>> desktop systems. However, I also have a few Laptops that can roam. In F11 and > >>>> before I have used the network and NetworkManager services. When the laptop > >>>> boots away from home, the "network" service fails and I can then use the > >>>> NetworkManager service to connect to whatever wireless network or G3 network is > >>>> available. > >>>> > >>>> It does seem sensible to me that the "system" provides applications with info > >>>> on if the network is up (not just the Internet). The NetworkManager service > >>>> seems the place to do this and it looks like the applications are starting > >>>> to use it for this purpose. > >>>> So maybe a generic NM "isNetworkUp()" API call is called for ? > >>> > >>> See the other mail; the problem with a generic isUp() is that it simply > >>> says hey, is there a connection? It doesn't provide enough information > >>> about the networking state of the system for anything to make an > >>> intelligent decision about anything. It's a "hey I'm connected to > >>> something" but there's no information about *what* you're connected to; > >>> whether it's a secure home network, whether it's a slow 3G network, > >>> whether it's billed by the minute or the hour or unlimited, etc. > >>> > >>> Dan > >>> > >> Hi, Thanks for the info. > >> I would have thought that a generic isUp() is good enough for the likes > >> of Firefox and Pidgen though to decide if to start offline. Being connected to a > >> Network is probably all you need, you may be accessing an Intranet as all > >> my systems Firefox home pages do ... > >> > >> Anyway, following your email (And notes in Bugzilla) I thought I'd try and > >> use NM properly for my config. However I have a problem, which may be > >> a bug. I have turned off the Network services and turned on NetworkManger. > >> I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are > >> set to be managed by NM and to start at boot. I have also added > >> NETWORKWAIT=yes in /etc/sysconfig/network. > >> > >> When I boot with this the network (eth1 (eth0 is disconnected)) does not > >> come up at boot. There is a message stating a failure on the line > >> where it is waiting for the network to come up. When I log in as a > >> local user the network then comes up ... > >> > >> I also note that, before the user is logged in, I cannot start the network > >> with "service network start" and the WiFi light is off. It looks like > >> NM has done something like powered down my WiFi chip ? > >> (Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52) > >> > >> Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled. > >> Maybe ypbind should be modified to not start when the network is down and > >> also added to /etc/NetworkManager/dispatcher.d ? > > > > NM has two types of connection: system and user (see > > http://live.gnome.org/NetworkManagerConfiguration ). NM treats ifcfg > > files as system connections and thus they are available at boot time and > > before login. I had assumed that since your connection was working > > correctly with the 'network' service that it was also a system > > connection. What is the result of > > 'ls /etc/sysconfig/network-scripts/ifcfg-*' and what are the contents > > of /var/log/messages when the device is not correctly connected on > > bootup? > > > > Before logging in, can you also drop to a VT, log in, and run 'nm-tool' > > for me? > > > > THanks, > > Dan > > > > > Hi Dan, > > As far as I am aware my connections are "system" connections. I have configured > the Network interfaces using the system-config-network tool. When I use the > "network" service the eth1 wireless network comes up fine at boot. When I use > NetworkManager the eth1 wireless network does not come up at boot. There is the > error: "Waiting for network... [FAILED]" > If the NetworkManger service is running (eth1 has not come up) and I run > "service network start" the eth1 interface still does not come up. If > I stop the NetworkManger service and again run "service network start" then > the eth1 interface comes up ... > > The configuration files are: > /etc/sysconfig/network-scripts/ifcfg-* files are there: > /etc/sysconfig/network-scripts/ifcfg-eth0 > /etc/sysconfig/network-scripts/ifcfg-eth1 > /etc/sysconfig/network-scripts/ifcfg-lo > /etc/sysconfig/network-scripts/ifcfg-Vodaphone > > /etc/sysconfig/network-scripts/ifcfg-eth1 is: > # Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection > DEVICE=eth1 > HWADDR=00:16:6F:8A:E1:95 > ONBOOT=yes > BOOTPROTO=dhcp > TYPE=Wireless > NM_CONTROLLED=yes > USERCTL=yes > PEERDNS=yes > IPV6INIT=no > MODE=Auto ^^^^ This is the problem. "Auto" is not a valid mode. Dec 1 09:59:05 think NetworkManager: ifcfg-rh: error: Invalid mode 'auto' (not 'Ad-Hoc' or 'Managed') you'll probably be seeing something on the console when running "ifup eth1" like this: Error for wireless request "Set Mode" (8B06) : SET failed on device wlan0 ; Invalid argument. Since all ifup-wireless does is send $MODE to iwconfig, and "auto" is not a valid mode. Dan > RATE=auto > ESSID=beamwifi > CHANNEL= > > Section of /var/log/messages attached. > Output of nm-tool attached. > > nm-tool also outputs the error on stderr: > ** (process:1492): WARNING **: error: failed to read connections from > org.freedesktop.NetworkManagerUserSettings: > The name org.freedesktop.NetworkManagerUserSettings was not provided by any > .service files > > > Cheers > > > Terry > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From terry1 at beam.ltd.uk Wed Dec 2 21:48:03 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Wed, 02 Dec 2009 21:48:03 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <1259789568.17666.53.camel@localhost.localdomain> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> Message-ID: <4B16E093.6000904@beam.ltd.uk> On 12/02/2009 09:32 PM, Dan Williams wrote: > On Tue, 2009-12-01 at 10:24 +0000, Terry Barnaby wrote: >> On 12/01/2009 07:50 AM, Dan Williams wrote: >>> On Mon, 2009-11-30 at 19:52 +0000, Terry Barnaby wrote: >>>> On 11/30/2009 06:12 PM, Dan Williams wrote: >>>>> On Mon, 2009-11-30 at 09:55 +0000, Terry Barnaby wrote: >>>>>> On 11/29/2009 11:30 PM, Dan Williams wrote: >>>>>>> On Sat, 2009-11-28 at 09:10 +0000, Terry Barnaby wrote: >>>>>>>> On 11/28/2009 08:35 AM, Rakesh Pandit wrote: >>>>>>>>> 2009/11/28 Terry Barnaby wrote: >>>>>>>>>> If the NetworkManager service is running, but not managing the current >>>>>>>>>> network connection, then Firefox starts up in offline mode. >>>>>>>>>> >>>>>>>>>> Is this a bug in NetworkManager or Firefox ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is odd behaviour and needs to be fixed. I would suggest open up a >>>>>>>>> bug against firefox. I know one can change >>>>>>>>> toolkit.networkmanager.disable preference, but it is a PITA for our >>>>>>>>> users. One of use cases is: Sometime network manager does not connect >>>>>>>>> me via my CDMA usb modem (in case signal is weak), but wvdial does and >>>>>>>>> once I switch from NM to wvdial, my firefox gets to offline mode, >>>>>>>>> which I don't expect it to as I am connected. >>>>>>>>> >>>>>>>> Ok, filed as: 542078 >>>>>>> >>>>>>> NetworkManager is intended to control the default internet connection. >>>>>>> If NetworkManager cannot control the default internet connection, then >>>>>>> you may not want to use NetworkManager. >>>>>>> >>>>>>> In your case, you're using a mobile broadband device. The real bug here >>>>>>> is that for whatever reason, NM/MM aren't connecting your modem, and we >>>>>>> should follow up on that bug instead. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>> I am not using a mobile broadband device. The network connection my systems >>>>> >>>>> My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G >>>>> connection. >>>>> >>>>>> use is not just the Internet it is a local network LAN connection that also >>>>>> serves the internet. Most of my systems use a local network server which >>>>>> provides NIS, /home and /data using NFS and VPN etc. I normally use the >>>>>> service "network" to bring up wired or wireless networking for this. Fedora, >>>>>> by default, uses NetworkManager to manage all network devices though. I use >>>>>> the service "network" as, for some reason, the NetworkManager service is >>>>>> started after the netfs and other services are started. Is there a reason >>>>>> for this ?? >>>>> >>>>> No particular reason, in fact that looks like a bug. NM no longer >>>>> depends on HAL, but that dependency is still in the initscript, which >>>>> looks like it pushes NM later than netfs. >>>>> >>>>> But in reality, you're looking for a dependency based initsystem which >>>>> we don't quite yet have. There are already scripts that kick netfs to >>>>> mount stuff when NM brings the network up >>>>> (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous >>>>> bootup *and* your mounts. The rest of the system, if it requires >>>>> something from the mounted directories, needs to be smart enough to know >>>>> that. >>>>> >>>>> If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network, >>>>> which causes the NetworkManager initscript to block until a network >>>>> connection is brought up, or 30 seconds have passed. >>>>> >>>>>> I can obviously turn of the NetworkManager service, which I have done on the >>>>>> desktop systems. However, I also have a few Laptops that can roam. In F11 and >>>>>> before I have used the network and NetworkManager services. When the laptop >>>>>> boots away from home, the "network" service fails and I can then use the >>>>>> NetworkManager service to connect to whatever wireless network or G3 network is >>>>>> available. >>>>>> >>>>>> It does seem sensible to me that the "system" provides applications with info >>>>>> on if the network is up (not just the Internet). The NetworkManager service >>>>>> seems the place to do this and it looks like the applications are starting >>>>>> to use it for this purpose. >>>>>> So maybe a generic NM "isNetworkUp()" API call is called for ? >>>>> >>>>> See the other mail; the problem with a generic isUp() is that it simply >>>>> says hey, is there a connection? It doesn't provide enough information >>>>> about the networking state of the system for anything to make an >>>>> intelligent decision about anything. It's a "hey I'm connected to >>>>> something" but there's no information about *what* you're connected to; >>>>> whether it's a secure home network, whether it's a slow 3G network, >>>>> whether it's billed by the minute or the hour or unlimited, etc. >>>>> >>>>> Dan >>>>> >>>> Hi, Thanks for the info. >>>> I would have thought that a generic isUp() is good enough for the likes >>>> of Firefox and Pidgen though to decide if to start offline. Being connected to a >>>> Network is probably all you need, you may be accessing an Intranet as all >>>> my systems Firefox home pages do ... >>>> >>>> Anyway, following your email (And notes in Bugzilla) I thought I'd try and >>>> use NM properly for my config. However I have a problem, which may be >>>> a bug. I have turned off the Network services and turned on NetworkManger. >>>> I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are >>>> set to be managed by NM and to start at boot. I have also added >>>> NETWORKWAIT=yes in /etc/sysconfig/network. >>>> >>>> When I boot with this the network (eth1 (eth0 is disconnected)) does not >>>> come up at boot. There is a message stating a failure on the line >>>> where it is waiting for the network to come up. When I log in as a >>>> local user the network then comes up ... >>>> >>>> I also note that, before the user is logged in, I cannot start the network >>>> with "service network start" and the WiFi light is off. It looks like >>>> NM has done something like powered down my WiFi chip ? >>>> (Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52) >>>> >>>> Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled. >>>> Maybe ypbind should be modified to not start when the network is down and >>>> also added to /etc/NetworkManager/dispatcher.d ? >>> >>> NM has two types of connection: system and user (see >>> http://live.gnome.org/NetworkManagerConfiguration ). NM treats ifcfg >>> files as system connections and thus they are available at boot time and >>> before login. I had assumed that since your connection was working >>> correctly with the 'network' service that it was also a system >>> connection. What is the result of >>> 'ls /etc/sysconfig/network-scripts/ifcfg-*' and what are the contents >>> of /var/log/messages when the device is not correctly connected on >>> bootup? >>> >>> Before logging in, can you also drop to a VT, log in, and run 'nm-tool' >>> for me? >>> >>> THanks, >>> Dan >>> >>> >> Hi Dan, >> >> As far as I am aware my connections are "system" connections. I have configured >> the Network interfaces using the system-config-network tool. When I use the >> "network" service the eth1 wireless network comes up fine at boot. When I use >> NetworkManager the eth1 wireless network does not come up at boot. There is the >> error: "Waiting for network... [FAILED]" >> If the NetworkManger service is running (eth1 has not come up) and I run >> "service network start" the eth1 interface still does not come up. If >> I stop the NetworkManger service and again run "service network start" then >> the eth1 interface comes up ... >> >> The configuration files are: >> /etc/sysconfig/network-scripts/ifcfg-* files are there: >> /etc/sysconfig/network-scripts/ifcfg-eth0 >> /etc/sysconfig/network-scripts/ifcfg-eth1 >> /etc/sysconfig/network-scripts/ifcfg-lo >> /etc/sysconfig/network-scripts/ifcfg-Vodaphone >> >> /etc/sysconfig/network-scripts/ifcfg-eth1 is: >> # Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection >> DEVICE=eth1 >> HWADDR=00:16:6F:8A:E1:95 >> ONBOOT=yes >> BOOTPROTO=dhcp >> TYPE=Wireless >> NM_CONTROLLED=yes >> USERCTL=yes >> PEERDNS=yes >> IPV6INIT=no >> MODE=Auto > > ^^^^ This is the problem. "Auto" is not a valid mode. > > Dec 1 09:59:05 think NetworkManager: ifcfg-rh: error: Invalid mode 'auto' (not 'Ad-Hoc' or 'Managed') > > you'll probably be seeing something on the console when running "ifup > eth1" like this: > > Error for wireless request "Set Mode" (8B06) : > SET failed on device wlan0 ; Invalid argument. > > Since all ifup-wireless does is send $MODE to iwconfig, and "auto" is > not a valid mode. The "MODE" was set up by system-config-network, it is from its list of possible options for Mode and I think was the default. If I run ifup the error you mention is not reported and the interface comes up fine. However, I do get the error: domainname: you must be root to change the domain name Which I assume is due to another F12 bug. Could this cause NM to abort the connection ? > > Dan > >> RATE=auto >> ESSID=beamwifi >> CHANNEL= >> >> Section of /var/log/messages attached. >> Output of nm-tool attached. >> >> nm-tool also outputs the error on stderr: >> ** (process:1492): WARNING **: error: failed to read connections from >> org.freedesktop.NetworkManagerUserSettings: >> The name org.freedesktop.NetworkManagerUserSettings was not provided by any >> .service files >> >> >> Cheers >> >> >> Terry >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > From notting at redhat.com Wed Dec 2 21:52:08 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Dec 2009 16:52:08 -0500 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <1259789568.17666.53.camel@localhost.localdomain> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> Message-ID: <20091202215208.GA30748@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > > ONBOOT=yes > > BOOTPROTO=dhcp > > TYPE=Wireless > > NM_CONTROLLED=yes > > USERCTL=yes > > PEERDNS=yes > > IPV6INIT=no > > MODE=Auto > > ^^^^ This is the problem. "Auto" is not a valid mode. It's a valid mode according to the iwconfig man page. I have no idea what cards actually support it. Bill From jkeating at redhat.com Wed Dec 2 22:03:51 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 14:03:51 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259777756.12203.95.camel@localhost.localdomain> Message-ID: <1259791431.12203.117.camel@localhost.localdomain> On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: > Isn't this, eventually, what the packagedb is supposed to be able to > do? I gather it's a "ls in a directory" kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From terry1 at beam.ltd.uk Wed Dec 2 22:34:47 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Wed, 02 Dec 2009 22:34:47 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B16E093.6000904@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <4B16E093.6000904@beam.ltd.uk> Message-ID: <4B16EB87.4000005@beam.ltd.uk> On 12/02/2009 09:48 PM, Terry Barnaby wrote: > On 12/02/2009 09:32 PM, Dan Williams wrote: >> On Tue, 2009-12-01 at 10:24 +0000, Terry Barnaby wrote: >>> On 12/01/2009 07:50 AM, Dan Williams wrote: >>>> On Mon, 2009-11-30 at 19:52 +0000, Terry Barnaby wrote: >>>>> On 11/30/2009 06:12 PM, Dan Williams wrote: >>>>>> On Mon, 2009-11-30 at 09:55 +0000, Terry Barnaby wrote: >>>>>>> On 11/29/2009 11:30 PM, Dan Williams wrote: >>>>>>>> On Sat, 2009-11-28 at 09:10 +0000, Terry Barnaby wrote: >>>>>>>>> On 11/28/2009 08:35 AM, Rakesh Pandit wrote: >>>>>>>>>> 2009/11/28 Terry Barnaby wrote: >>>>>>>>>>> If the NetworkManager service is running, but not managing >>>>>>>>>>> the current >>>>>>>>>>> network connection, then Firefox starts up in offline mode. >>>>>>>>>>> >>>>>>>>>>> Is this a bug in NetworkManager or Firefox ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is odd behaviour and needs to be fixed. I would suggest >>>>>>>>>> open up a >>>>>>>>>> bug against firefox. I know one can change >>>>>>>>>> toolkit.networkmanager.disable preference, but it is a PITA >>>>>>>>>> for our >>>>>>>>>> users. One of use cases is: Sometime network manager does not >>>>>>>>>> connect >>>>>>>>>> me via my CDMA usb modem (in case signal is weak), but wvdial >>>>>>>>>> does and >>>>>>>>>> once I switch from NM to wvdial, my firefox gets to offline mode, >>>>>>>>>> which I don't expect it to as I am connected. >>>>>>>>>> >>>>>>>>> Ok, filed as: 542078 >>>>>>>> >>>>>>>> NetworkManager is intended to control the default internet >>>>>>>> connection. >>>>>>>> If NetworkManager cannot control the default internet >>>>>>>> connection, then >>>>>>>> you may not want to use NetworkManager. >>>>>>>> >>>>>>>> In your case, you're using a mobile broadband device. The real >>>>>>>> bug here >>>>>>>> is that for whatever reason, NM/MM aren't connecting your modem, >>>>>>>> and we >>>>>>>> should follow up on that bug instead. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>> I am not using a mobile broadband device. The network connection >>>>>>> my systems >>>>>> >>>>>> My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G >>>>>> connection. >>>>>> >>>>>>> use is not just the Internet it is a local network LAN connection >>>>>>> that also >>>>>>> serves the internet. Most of my systems use a local network >>>>>>> server which >>>>>>> provides NIS, /home and /data using NFS and VPN etc. I normally >>>>>>> use the >>>>>>> service "network" to bring up wired or wireless networking for >>>>>>> this. Fedora, >>>>>>> by default, uses NetworkManager to manage all network devices >>>>>>> though. I use >>>>>>> the service "network" as, for some reason, the NetworkManager >>>>>>> service is >>>>>>> started after the netfs and other services are started. Is there >>>>>>> a reason >>>>>>> for this ?? >>>>>> >>>>>> No particular reason, in fact that looks like a bug. NM no longer >>>>>> depends on HAL, but that dependency is still in the initscript, which >>>>>> looks like it pushes NM later than netfs. >>>>>> >>>>>> But in reality, you're looking for a dependency based initsystem >>>>>> which >>>>>> we don't quite yet have. There are already scripts that kick netfs to >>>>>> mount stuff when NM brings the network up >>>>>> (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous >>>>>> bootup *and* your mounts. The rest of the system, if it requires >>>>>> something from the mounted directories, needs to be smart enough >>>>>> to know >>>>>> that. >>>>>> >>>>>> If you need to, you can set NETWORKWAIT=yes in >>>>>> /etc/sysconfig/network, >>>>>> which causes the NetworkManager initscript to block until a network >>>>>> connection is brought up, or 30 seconds have passed. >>>>>> >>>>>>> I can obviously turn of the NetworkManager service, which I have >>>>>>> done on the >>>>>>> desktop systems. However, I also have a few Laptops that can >>>>>>> roam. In F11 and >>>>>>> before I have used the network and NetworkManager services. When >>>>>>> the laptop >>>>>>> boots away from home, the "network" service fails and I can then >>>>>>> use the >>>>>>> NetworkManager service to connect to whatever wireless network or >>>>>>> G3 network is >>>>>>> available. >>>>>>> >>>>>>> It does seem sensible to me that the "system" provides >>>>>>> applications with info >>>>>>> on if the network is up (not just the Internet). The >>>>>>> NetworkManager service >>>>>>> seems the place to do this and it looks like the applications are >>>>>>> starting >>>>>>> to use it for this purpose. >>>>>>> So maybe a generic NM "isNetworkUp()" API call is called for ? >>>>>> >>>>>> See the other mail; the problem with a generic isUp() is that it >>>>>> simply >>>>>> says hey, is there a connection? It doesn't provide enough >>>>>> information >>>>>> about the networking state of the system for anything to make an >>>>>> intelligent decision about anything. It's a "hey I'm connected to >>>>>> something" but there's no information about *what* you're >>>>>> connected to; >>>>>> whether it's a secure home network, whether it's a slow 3G network, >>>>>> whether it's billed by the minute or the hour or unlimited, etc. >>>>>> >>>>>> Dan >>>>>> >>>>> Hi, Thanks for the info. >>>>> I would have thought that a generic isUp() is good enough for the >>>>> likes >>>>> of Firefox and Pidgen though to decide if to start offline. Being >>>>> connected to a >>>>> Network is probably all you need, you may be accessing an Intranet >>>>> as all >>>>> my systems Firefox home pages do ... >>>>> >>>>> Anyway, following your email (And notes in Bugzilla) I thought I'd >>>>> try and >>>>> use NM properly for my config. However I have a problem, which may be >>>>> a bug. I have turned off the Network services and turned on >>>>> NetworkManger. >>>>> I have two main network interfaces eth0 (wired) and eth1 (Wifi), >>>>> both are >>>>> set to be managed by NM and to start at boot. I have also added >>>>> NETWORKWAIT=yes in /etc/sysconfig/network. >>>>> >>>>> When I boot with this the network (eth1 (eth0 is disconnected)) >>>>> does not >>>>> come up at boot. There is a message stating a failure on the line >>>>> where it is waiting for the network to come up. When I log in as a >>>>> local user the network then comes up ... >>>>> >>>>> I also note that, before the user is logged in, I cannot start the >>>>> network >>>>> with "service network start" and the WiFi light is off. It looks like >>>>> NM has done something like powered down my WiFi chip ? >>>>> (Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52) >>>>> >>>>> Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled. >>>>> Maybe ypbind should be modified to not start when the network is >>>>> down and >>>>> also added to /etc/NetworkManager/dispatcher.d ? >>>> >>>> NM has two types of connection: system and user (see >>>> http://live.gnome.org/NetworkManagerConfiguration ). NM treats ifcfg >>>> files as system connections and thus they are available at boot time >>>> and >>>> before login. I had assumed that since your connection was working >>>> correctly with the 'network' service that it was also a system >>>> connection. What is the result of >>>> 'ls /etc/sysconfig/network-scripts/ifcfg-*' and what are the contents >>>> of /var/log/messages when the device is not correctly connected on >>>> bootup? >>>> >>>> Before logging in, can you also drop to a VT, log in, and run 'nm-tool' >>>> for me? >>>> >>>> THanks, >>>> Dan >>>> >>>> >>> Hi Dan, >>> >>> As far as I am aware my connections are "system" connections. I have >>> configured >>> the Network interfaces using the system-config-network tool. When I >>> use the >>> "network" service the eth1 wireless network comes up fine at boot. >>> When I use >>> NetworkManager the eth1 wireless network does not come up at boot. >>> There is the >>> error: "Waiting for network... [FAILED]" >>> If the NetworkManger service is running (eth1 has not come up) and I run >>> "service network start" the eth1 interface still does not come up. If >>> I stop the NetworkManger service and again run "service network >>> start" then >>> the eth1 interface comes up ... >>> >>> The configuration files are: >>> /etc/sysconfig/network-scripts/ifcfg-* files are there: >>> /etc/sysconfig/network-scripts/ifcfg-eth0 >>> /etc/sysconfig/network-scripts/ifcfg-eth1 >>> /etc/sysconfig/network-scripts/ifcfg-lo >>> /etc/sysconfig/network-scripts/ifcfg-Vodaphone >>> >>> /etc/sysconfig/network-scripts/ifcfg-eth1 is: >>> # Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection >>> DEVICE=eth1 >>> HWADDR=00:16:6F:8A:E1:95 >>> ONBOOT=yes >>> BOOTPROTO=dhcp >>> TYPE=Wireless >>> NM_CONTROLLED=yes >>> USERCTL=yes >>> PEERDNS=yes >>> IPV6INIT=no >>> MODE=Auto >> >> ^^^^ This is the problem. "Auto" is not a valid mode. >> >> Dec 1 09:59:05 think NetworkManager: ifcfg-rh: error: Invalid mode >> 'auto' (not 'Ad-Hoc' or 'Managed') >> >> you'll probably be seeing something on the console when running "ifup >> eth1" like this: >> >> Error for wireless request "Set Mode" (8B06) : >> SET failed on device wlan0 ; Invalid argument. >> >> Since all ifup-wireless does is send $MODE to iwconfig, and "auto" is >> not a valid mode. > The "MODE" was set up by system-config-network, it is from > its list of possible options for Mode and I think was the > default. > If I run ifup the error you mention is not reported and the > interface comes up fine. > However, I do get the error: > domainname: you must be root to change the domain name > > Which I assume is due to another F12 bug. Could this cause NM > to abort the connection ? I note that "domainname" is called from /etc/dhcp/dhclient.d/nis.sh. At point of invocation $UID and $EUID are 0 .... > >> >> Dan >> >>> RATE=auto >>> ESSID=beamwifi >>> CHANNEL= >>> >>> Section of /var/log/messages attached. >>> Output of nm-tool attached. >>> >>> nm-tool also outputs the error on stderr: >>> ** (process:1492): WARNING **: error: failed to read connections from >>> org.freedesktop.NetworkManagerUserSettings: >>> The name org.freedesktop.NetworkManagerUserSettings was not provided >>> by any >>> .service files >>> >>> >>> Cheers >>> >>> >>> Terry >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From mcepl at redhat.com Wed Dec 2 20:53:10 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Wed, 02 Dec 2009 21:53:10 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160622.GD14279@hansolo.jdub.homelinux.org> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> Message-ID: Dne 2.12.2009 17:06, Josh Boyer napsal(a): > However, other than 'browsing manually for packages', I'm not really > sure what problem you are trying to solve by getting rid of the > updates repository. It would seem like this has quite a bit of cost > for relatively little to no real gain? I am usually too lazy, so I use yumdownloader anyway. So, I really don't see any real use case covered. Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. From pjones at redhat.com Wed Dec 2 22:46:49 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 17:46:49 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259776139.12203.80.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> Message-ID: <4B16EE59.10502@redhat.com> (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: > I hypothesize that we could place all rpms for a given release > in a single directory (seth will hate this as he wants to split them up > based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/ # contains packages named 0 through 3* 4/ # 4 through 9* a/ # a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From pjones at redhat.com Wed Dec 2 22:48:11 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 17:48:11 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259791431.12203.117.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259777756.12203.95.camel@localhost.localdomain> <1259791431.12203.117.camel@localhost.localdomain> Message-ID: <4B16EEAB.1020003@redhat.com> On 12/02/2009 05:03 PM, Jesse Keating wrote: > On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: >> Isn't this, eventually, what the packagedb is supposed to be able to >> do? > > I gather it's a "ls in a directory" kind of thing, not an interface to > one tool or another kind of thing. But I could be wrong. Sure, but the better optimization for this is "don't do it". -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From pjones at redhat.com Wed Dec 2 22:50:50 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 17:50:50 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> Message-ID: <4B16EF4A.7020905@redhat.com> On 12/02/2009 03:53 PM, Seth Vidal wrote: > On Wed, 2 Dec 2009, Nicolas Mailhot wrote: >> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >> (make sure it works with web infrastructure instead of fighting it) > > I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From Matt_Domsch at dell.com Wed Dec 2 22:54:27 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 2 Dec 2009 16:54:27 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259791431.12203.117.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259777756.12203.95.camel@localhost.localdomain> <1259791431.12203.117.camel@localhost.localdomain> Message-ID: <20091202225427.GA1864@auslistsprd01.us.dell.com> On Wed, Dec 02, 2009 at 02:03:51PM -0800, Jesse Keating wrote: > On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: > > Isn't this, eventually, what the packagedb is supposed to be able to > > do? > > I gather it's a "ls in a directory" kind of thing, not an interface to > one tool or another kind of thing. But I could be wrong. We're at a point where 'ls in a directory' is becoming difficult even; you can't glob 15k package names in a shell. find . is your friend. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Wed Dec 2 22:56:01 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 2 Dec 2009 16:56:01 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259778903.24751.7.camel@arekh.okg> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> Message-ID: <20091202225601.GB1864@auslistsprd01.us.dell.com> On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: > 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org > (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From skvidal at fedoraproject.org Wed Dec 2 22:58:24 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 17:58:24 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16EE59.10502@redhat.com> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: On Wed, 2 Dec 2009, Peter Jones wrote: > (on my on tangent...) > > On 12/02/2009 12:48 PM, Jesse Keating wrote: >> I hypothesize that we could place all rpms for a given release >> in a single directory (seth will hate this as he wants to split them up >> based on first letter of their name for better filesystem performance), > > Ugh, first letter isn't really a great plan anyway. First (few) letters > of a hash of the filename is much better, but obviously hurts browsability. > Next best is probably something like how a dead-tree dictionary index works; > list everything, split the list up by starting letters evenly, so the > directories (given a really unlikely hypothetical package set) are > > 0/ # contains packages named 0 through 3* > 4/ # 4 through 9* > a/ # a through ay* > az/ # az through bw* > bx/ # bx through cz* > da/ # da through whatever's next > ... > > so that every directory has about the same number of things. If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. -sv From Matt_Domsch at dell.com Wed Dec 2 22:58:49 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 2 Dec 2009 16:58:49 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202160941.GD14426@nostromo.devel.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> Message-ID: <20091202225849.GC1864@auslistsprd01.us.dell.com> On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: > The separate Everything tree that does not get obsoleted is required > in some form for GPL compliance, with respect to the ISO images that > we ship. Any new solution would have to preserve this. ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso images on the mirrors already. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From skvidal at fedoraproject.org Wed Dec 2 22:58:52 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 17:58:52 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16EF4A.7020905@redhat.com> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <4B16EF4A.7020905@redhat.com> Message-ID: On Wed, 2 Dec 2009, Peter Jones wrote: > On 12/02/2009 03:53 PM, Seth Vidal wrote: >> On Wed, 2 Dec 2009, Nicolas Mailhot wrote: >>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >>> (make sure it works with web infrastructure instead of fighting it) >> >> I don't think that would work fine with a lot of our mirrors. > > I think it probably /could/ if we put some (relatively major) work in > on the server side to make it look like the directories it isn't. Not > that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. -sv From pjones at redhat.com Wed Dec 2 22:59:54 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 17:59:54 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <4B16EF4A.7020905@redhat.com> Message-ID: <4B16F16A.9060508@redhat.com> On 12/02/2009 05:58 PM, Seth Vidal wrote: > > > On Wed, 2 Dec 2009, Peter Jones wrote: > >> On 12/02/2009 03:53 PM, Seth Vidal wrote: >>> On Wed, 2 Dec 2009, Nicolas Mailhot wrote: >>>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >>>> (make sure it works with web infrastructure instead of fighting it) >>> >>> I don't think that would work fine with a lot of our mirrors. >> >> I think it probably /could/ if we put some (relatively major) work in >> on the server side to make it look like the directories it isn't. Not >> that I'm endorsing such a plan. > > we'd have to make all our mirrors use that. > > not gonna fly. Well, you just wouldn't get the benefits of this if you're using a mirror. Which, yes, is pretty lame. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From pjones at redhat.com Wed Dec 2 23:00:30 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 18:00:30 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: <4B16F18E.7040204@redhat.com> On 12/02/2009 05:58 PM, Seth Vidal wrote: > > > On Wed, 2 Dec 2009, Peter Jones wrote: > >> (on my on tangent...) >> >> On 12/02/2009 12:48 PM, Jesse Keating wrote: >>> I hypothesize that we could place all rpms for a given release >>> in a single directory (seth will hate this as he wants to split them up >>> based on first letter of their name for better filesystem performance), >> >> Ugh, first letter isn't really a great plan anyway. First (few) letters >> of a hash of the filename is much better, but obviously hurts >> browsability. >> Next best is probably something like how a dead-tree dictionary index >> works; >> list everything, split the list up by starting letters evenly, so the >> directories (given a really unlikely hypothetical package set) are >> >> 0/ # contains packages named 0 through 3* >> 4/ # 4 through 9* >> a/ # a through ay* >> az/ # az through bw* >> bx/ # bx through cz* >> da/ # da through whatever's next >> ... >> >> so that every directory has about the same number of things. > > If you're looking for perfect division, sure - but the reality is this: > > 19K items in a single dir and ext3 and nfs and many many other things > crap themselves returning that list. > > If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for > producing the same list of files. > > I tested it on our backend to be sure. getting the complete pkglist goes > from taking 5 minutes to take 30s. > > yes, I said 5 minutes. Yeah, I buy that. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From skvidal at fedoraproject.org Wed Dec 2 23:00:56 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 18:00:56 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16F16A.9060508@redhat.com> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <4B16EF4A.7020905@redhat.com> <4B16F16A.9060508@redhat.com> Message-ID: On Wed, 2 Dec 2009, Peter Jones wrote: > On 12/02/2009 05:58 PM, Seth Vidal wrote: >> >> >> On Wed, 2 Dec 2009, Peter Jones wrote: >> >>> On 12/02/2009 03:53 PM, Seth Vidal wrote: >>>> On Wed, 2 Dec 2009, Nicolas Mailhot wrote: >>>>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >>>>> (make sure it works with web infrastructure instead of fighting it) >>>> >>>> I don't think that would work fine with a lot of our mirrors. >>> >>> I think it probably /could/ if we put some (relatively major) work in >>> on the server side to make it look like the directories it isn't. Not >>> that I'm endorsing such a plan. >> >> we'd have to make all our mirrors use that. >> >> not gonna fly. > > Well, you just wouldn't get the benefits of this if you're using a mirror. > > Which, yes, is pretty lame. we won't get the benefits in fedora then. Our mirror infrastructure is a HUGE reason why we can do what we do. If we can't farm things out to our mirrors then we might as well go home b/c our users will NEVER be able to get our bits. -sv From james at fedoraproject.org Wed Dec 2 23:05:03 2009 From: james at fedoraproject.org (James Antill) Date: Wed, 02 Dec 2009 18:05:03 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B16EE59.10502@redhat.com> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: <1259795103.14386.8.camel@code.and.org> On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote: > (on my on tangent...) > > On 12/02/2009 12:48 PM, Jesse Keating wrote: > > I hypothesize that we could place all rpms for a given release > > in a single directory (seth will hate this as he wants to split them up > > based on first letter of their name for better filesystem performance), > > Ugh, first letter isn't really a great plan anyway. It's not "great" but it's better than the current "all in one dir." and easy to do, and I haven't heard of any downsides (that aren't applicable to "all in one dir."). > First (few) letters > of a hash of the filename is much better, but obviously hurts browsability. Right, which is important enough to not do that IMO. I'm sure Jesse wouldn't like finding packages to mean using find. > Next best is probably something like how a dead-tree dictionary index works; > list everything, split the list up by starting letters evenly, so the > directories (given a really unlikely hypothetical package set) are > > 0/ # contains packages named 0 through 3* > 4/ # 4 through 9* > a/ # a through ay* > az/ # az through bw* > bx/ # bx through cz* > da/ # da through whatever's next > ... > > so that every directory has about the same number of things. This should be fairly easy to code, but has a big downside: Packages will move directories. 1. This will upset yum (old repo. MD == no packages download). 2. This might upset mirrors. 3. This will probably upset users: i. URLs will only be safe until the next mash, they won't even be able to bookmark /y if they just want to see yum each time. ii. Users have to look/parse the directory layout each time they visit to see what "blah" is. -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From pjones at redhat.com Wed Dec 2 23:07:38 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 02 Dec 2009 18:07:38 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259795103.14386.8.camel@code.and.org> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> <1259795103.14386.8.camel@code.and.org> Message-ID: <4B16F33A.1060900@redhat.com> On 12/02/2009 06:05 PM, James Antill wrote: > On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote: >> so that every directory has about the same number of things. > > This should be fairly easy to code, but has a big downside: > > Packages will move directories. > > 1. This will upset yum (old repo. MD == no packages download). > 2. This might upset mirrors. > 3. This will probably upset users: > i. URLs will only be safe until the next mash, they > won't even be able to bookmark /y if they just > want to see yum each time. > ii. Users have to look/parse the directory layout each > time they visit to see what "blah" is. Yeah. Seth makes a good point - first letter is such vast improvement that we probably don't need to worry about doing better - at least for now. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. From jkeating at redhat.com Wed Dec 2 23:08:06 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 15:08:06 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202225849.GC1864@auslistsprd01.us.dell.com> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <20091202225849.GC1864@auslistsprd01.us.dell.com> Message-ID: <1259795286.12203.140.camel@localhost.localdomain> On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote: > On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: > > The separate Everything tree that does not get obsoleted is required > > in some form for GPL compliance, with respect to the ISO images that > > we ship. Any new solution would have to preserve this. > > ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso > images on the mirrors already. > As stated elsewhere, that doesn't carry the packages found on all the live images we produce. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Wed Dec 2 23:17:11 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 2 Dec 2009 17:17:11 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259795286.12203.140.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <20091202160941.GD14426@nostromo.devel.redhat.com> <20091202225849.GC1864@auslistsprd01.us.dell.com> <1259795286.12203.140.camel@localhost.localdomain> Message-ID: <20091202231711.GA6013@auslistsprd01.us.dell.com> On Wed, Dec 02, 2009 at 03:08:06PM -0800, Jesse Keating wrote: > On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote: > > On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: > > > The separate Everything tree that does not get obsoleted is required > > > in some form for GPL compliance, with respect to the ISO images that > > > we ship. Any new solution would have to preserve this. > > > > ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso > > images on the mirrors already. > > > > As stated elsewhere, that doesn't carry the packages found on all the > live images we produce. All the more reason to put more effort into http://git.fedorahosted.org/git/correspondingsource.git -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bruno at wolff.to Wed Dec 2 23:18:58 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 2 Dec 2009 17:18:58 -0600 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: <20091202231858.GA31566@wolff.to> On Wed, Dec 02, 2009 at 17:58:24 -0500, Seth Vidal wrote: > > I tested it on our backend to be sure. getting the complete pkglist > goes from taking 5 minutes to take 30s. > > yes, I said 5 minutes. Have you tried any of the tunning knobs to have the directory cache be alotted more space or given higher priority? For example: vfs_cache_pressure ------------------ Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. From skvidal at fedoraproject.org Wed Dec 2 23:27:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 18:27:23 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202231858.GA31566@wolff.to> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> <20091202231858.GA31566@wolff.to> Message-ID: On Wed, 2 Dec 2009, Bruno Wolff III wrote: > On Wed, Dec 02, 2009 at 17:58:24 -0500, > Seth Vidal wrote: >> >> I tested it on our backend to be sure. getting the complete pkglist >> goes from taking 5 minutes to take 30s. >> >> yes, I said 5 minutes. > > Have you tried any of the tunning knobs to have the directory cache be > alotted more space or given higher priority? For example: > > vfs_cache_pressure > ------------------ > > Controls the tendency of the kernel to reclaim the memory which is used for > caching of directory and inode objects. > > At the default value of vfs_cache_pressure=100 the kernel will attempt to > reclaim dentries and inodes at a "fair" rate with respect to pagecache and > swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer > to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 > causes the kernel to prefer to reclaim dentries and inodes. Not tried that - worth giving it a shot - but it still won't help the 'holy crap there are 15K items on this webpage and it won't render' problem. -sv From kevin.kofler at chello.at Thu Dec 3 02:12:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 03 Dec 2009 03:12:20 +0100 Subject: Proposed F13 feature: drop separate updates repository References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: Seth Vidal wrote: > If you're looking for perfect division, sure - but the reality is this: > > 19K items in a single dir and ext3 and nfs and many many other things crap > themselves returning that list. > > If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for > producing the same list of files. The problem is, a few of those starting letters still correspond to A LOT of packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of stuff (especially Perl and Python). And adding python3-* (and perl6-*, or are we going to use the rakudo-* namespace there?) won't make it any less. Kevin Kofler From skvidal at fedoraproject.org Thu Dec 3 02:20:14 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 2 Dec 2009 21:20:14 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: On Thu, 3 Dec 2009, Kevin Kofler wrote: > Seth Vidal wrote: >> If you're looking for perfect division, sure - but the reality is this: >> >> 19K items in a single dir and ext3 and nfs and many many other things crap >> themselves returning that list. >> >> If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for >> producing the same list of files. > > The problem is, a few of those starting letters still correspond to A LOT of > packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of > stuff (especially Perl and Python). And adding python3-* (and perl6-*, or > are we going to use the rakudo-* namespace there?) won't make it any less. > And yet, when tested, just making those 36 subdirs made a HUGE difference. What I've found is getting any one dir down below 3K entries makes things faster, by a lot. -sv From jwboyer at gmail.com Thu Dec 3 03:23:15 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Dec 2009 22:23:15 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202170149.GB29353@fearengine.rdu.redhat.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> Message-ID: <20091203032315.GJ14279@hansolo.jdub.homelinux.org> On Wed, Dec 02, 2009 at 12:01:49PM -0500, Casey Dahlin wrote: > >You owe me $5. It hasn't been a week and you haven't sent me your address. I did notice though, so keep up the good work ;) josh From mmcgrath at redhat.com Thu Dec 3 03:32:03 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Dec 2009 21:32:03 -0600 (CST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202231858.GA31566@wolff.to> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> <20091202231858.GA31566@wolff.to> Message-ID: On Wed, 2 Dec 2009, Bruno Wolff III wrote: > On Wed, Dec 02, 2009 at 17:58:24 -0500, > Seth Vidal wrote: > > > > I tested it on our backend to be sure. getting the complete pkglist > > goes from taking 5 minutes to take 30s. > > > > yes, I said 5 minutes. > > Have you tried any of the tunning knobs to have the directory cache be > alotted more space or given higher priority? For example: > > vfs_cache_pressure > ------------------ > > Controls the tendency of the kernel to reclaim the memory which is used for > caching of directory and inode objects. > > At the default value of vfs_cache_pressure=100 the kernel will attempt to > reclaim dentries and inodes at a "fair" rate with respect to pagecache and > swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer > to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 > causes the kernel to prefer to reclaim dentries and inodes. > We have experimented with this for the purposes of rsync on our mirrors but haven't experimented for this specific issue. -Mike From rc040203 at freenet.de Thu Dec 3 05:24:16 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 03 Dec 2009 06:24:16 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259775645.12203.73.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> Message-ID: <4B174B80.8070309@freenet.de> On 12/02/2009 06:40 PM, Jesse Keating wrote: > On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote: >> >> * It shifts "costs" from "users" to "vendor" >> and from "mirrors" to "master". >> * It helps users who are using networked installs to spare bandwidth >> (avoids downloading obsolete packages from "Everything"/"Fedora"). >> >> Admitted, for most users, it would change almost nothing. >> >> > > People doing network installs can either add the updates repo to their > kickstart, or check the box in the anaconda UI, so that the updates > repos are considered at install time. No download of duplicate data. Yes, for people who are doing "full featured networked installs" w/ custom kickstart files. I've never met such a person. > In fact, having separate repos would likely cost less bandwidth. If we > only had one combined repo, there would be many duplicate packages, Where? Unlike now, where you have each package twice (in Everything and "updates"), you would have each package only once: In Everything. It would help people like me, who are locally reusing downloaded packages in a networked environment, instead of letting each machine accesses the original repos directly. > especially if we went the route of having updates-testing mixed in and > only marked by some update tag. Updates-testing is an add-on repo to "Everything+updates". A merged new Everything would not change anything wrt. "updates-testing". The only difference would be packages being pushed to "Everything" instead of "updates". > We'd have to keep sets of what's in > updates-testing, updates, and the GA release set, and all of that would > be in one repodata set. Everybody doing a network install, whether they > wanted updates, updates-testing, or not would have to download and > consume that larger repodata, introducing a higher cost for them. Your concern is the bigger repodata? Reality check: # ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2 updates/11/x86_64/repodata/*.sqlite.bz2 16M releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2 11M releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2 5.8M releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2 9.0M updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2 6.0M updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2 3.2M updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2 => An estimate for the increase in downloaded files's sizes you are talking about is ca. factor 2, from 18.2M (current "updates") to 32.8M+ (current "Everything"+"newly introduced packages) Whether this increase in download-size is "significant" is up to the beholder. For me, it gets lost in the noise of accessing a "good" or a "bad" connection to a mirror and in the time required to download packages from mirrors. On the other hand, the content (the packages referenced inside) of "updates" overlaps with packages in Everything => The number of packages to be considered in dep-computation should become much (?) smaller. However, I am not knowledgable enough with yum's internals to estimate the impact this would have on turnaround-times, memory and diskspace requirements this would have on yum. Ralf From rc040203 at freenet.de Thu Dec 3 05:28:23 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 03 Dec 2009 06:28:23 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> Message-ID: <4B174C77.2050702@freenet.de> On 12/02/2009 07:09 PM, Seth Vidal wrote: > the merger of repos is already happening at the yum layer. On the client's side - With a combined Everything+updates, this would happen on the server side. It's one of the aspects which made me said "a combined Everything+updates shifts costs from client to server". Ralf From skvidal at fedoraproject.org Thu Dec 3 05:32:41 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 3 Dec 2009 00:32:41 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B174C77.2050702@freenet.de> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> Message-ID: On Thu, 3 Dec 2009, Ralf Corsepius wrote: > On 12/02/2009 07:09 PM, Seth Vidal wrote: > >> the merger of repos is already happening at the yum layer. > > On the client's side - With a combined Everything+updates, this would happen > on the server side. > > It's one of the aspects which made me said "a combined Everything+updates > shifts costs from client to server". except they wouldn't be merged on the server side -it would just be additive. We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. this is why it is less good for our users. -sv From rc040203 at freenet.de Thu Dec 3 05:51:44 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 03 Dec 2009 06:51:44 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> Message-ID: <4B1751F0.3040206@freenet.de> On 12/03/2009 06:32 AM, Seth Vidal wrote: > > > On Thu, 3 Dec 2009, Ralf Corsepius wrote: > >> On 12/02/2009 07:09 PM, Seth Vidal wrote: >> >>> the merger of repos is already happening at the yum layer. >> >> On the client's side - With a combined Everything+updates, this would >> happen on the server side. >> >> It's one of the aspects which made me said "a combined >> Everything+updates shifts costs from client to server". > > except they wouldn't be merged on the server side -it would just be > additive. > > > We wouldn't be talking about removing the original GA set - just adding > updated pkgs into the path. Woa!!! With all due respect, but this would seem an stupid and silly plan to me. > So you'd still have the number of pkgs -just > all in one repo, that you have to download all of the metadata for all > of the more often, despite that 15K of them don't CHANGE. > > this is why it is less good for our users. Yes - cf. above. I have nothing to add. Ralf From fedora at shmuelhome.mine.nu Thu Dec 3 07:59:52 2009 From: fedora at shmuelhome.mine.nu (shmuel siegel) Date: Thu, 03 Dec 2009 09:59:52 +0200 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B174B80.8070309@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> Message-ID: <4B176FF8.7000704@shmuelhome.mine.nu> Ralf Corsepius wrote: > Your concern is the bigger repodata? > My download of repodata towards the end of a release, or from rawhide, is usually bigger than my download of packages. So yes, this would make a difference. On the otherhand, there probably could be a repodiff that would alleviate a lot of this problem. From terry1 at beam.ltd.uk Thu Dec 3 08:49:13 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Thu, 03 Dec 2009 08:49:13 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B16EB87.4000005@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <4B16E093.6000904@beam.ltd.uk> <4B16EB87.4000005@beam.ltd.uk> Message-ID: <4B177B89.6030902@beam.ltd.uk> >> The "MODE" was set up by system-config-network, it is from >> its list of possible options for Mode and I think was the >> default. >> If I run ifup the error you mention is not reported and the >> interface comes up fine. >> However, I do get the error: >> domainname: you must be root to change the domain name >> >> Which I assume is due to another F12 bug. Could this cause NM >> to abort the connection ? > I note that "domainname" is called from /etc/dhcp/dhclient.d/nis.sh. > At point of invocation $UID and $EUID are 0 .... I added a "sh" into /etc/dhcp/dhclient.d/nis.sh to have a look. Here getuid() and geteuid() return 0. whoami returns "root". But when I run "domainname kingnet" I get the error: "domainname: you must be root to change the domain name" Also "su" states "su: incorrect password" without even prompting for one. What is happening here ? The environment variables are set by dhcp and do not have the usual user environment variables .... Note that on this system, selinux is disabled. From awilliam at redhat.com Thu Dec 3 08:51:42 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 03 Dec 2009 00:51:42 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> Message-ID: <1259830302.26397.15.camel@adam.local.net> On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: > We wouldn't be talking about removing the original GA set - just adding > updated pkgs into the path. So you'd still have the number of pkgs -just > all in one repo, that you have to download all of the metadata for all of > the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From emmanuel.seyman at club-internet.fr Thu Dec 3 09:16:54 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 3 Dec 2009 10:16:54 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259830302.26397.15.camel@adam.local.net> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> <1259830302.26397.15.camel@adam.local.net> Message-ID: <20091203091654.GA7656@orient.maison.lan> * Adam Williamson [03/12/2009 10:10] : > > I don't think that was actually made clear in the initial proposal. I'd > been assuming that the proposal was _exactly_ to remove the GA set. No can do. People who install from the netinst CD or do PXE installs without adding the updates repo during the installation would be unable to finish it. Emmanuel From nicolas.mailhot at laposte.net Thu Dec 3 09:29:45 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 3 Dec 2009 10:29:45 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202225601.GB1864@auslistsprd01.us.dell.com> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <20091202225601.GB1864@auslistsprd01.us.dell.com> Message-ID: <27fabe81cb669cea9c92f00630f99bc0.squirrel@arekh.dyndns.org> Le Mer 2 d?cembre 2009 23:56, Matt Domsch a ?crit : > > On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: >> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >> (make sure it works with web infrastructure instead of fighting it) > > Sorry, I don't understand this. Can you elaborate? That would help > me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. -- Nicolas Mailhot From schwab at redhat.com Thu Dec 3 09:47:49 2009 From: schwab at redhat.com (Andreas Schwab) Date: Thu, 03 Dec 2009 10:47:49 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <20091202225427.GA1864@auslistsprd01.us.dell.com> (Matt Domsch's message of "Wed, 2 Dec 2009 16:54:27 -0600") References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259777756.12203.95.camel@localhost.localdomain> <1259791431.12203.117.camel@localhost.localdomain> <20091202225427.GA1864@auslistsprd01.us.dell.com> Message-ID: Matt Domsch writes: > We're at a point where 'ls in a directory' is becoming difficult even; > you can't glob 15k package names in a shell. Recent kernels have no argv limit any more. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From terry1 at beam.ltd.uk Thu Dec 3 09:51:05 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Thu, 03 Dec 2009 09:51:05 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B177B89.6030902@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <4B16E093.6000904@beam.ltd.uk> <4B16EB87.4000005@beam.ltd.uk> <4B177B89.6030902@beam.ltd.uk> Message-ID: <4B178A09.1060103@beam.ltd.uk> On 12/03/2009 08:49 AM, Terry Barnaby wrote: >>> The "MODE" was set up by system-config-network, it is from >>> its list of possible options for Mode and I think was the >>> default. >>> If I run ifup the error you mention is not reported and the >>> interface comes up fine. >>> However, I do get the error: >>> domainname: you must be root to change the domain name >>> >>> Which I assume is due to another F12 bug. Could this cause NM >>> to abort the connection ? >> I note that "domainname" is called from /etc/dhcp/dhclient.d/nis.sh. >> At point of invocation $UID and $EUID are 0 .... > > I added a "sh" into /etc/dhcp/dhclient.d/nis.sh to have a look. > Here getuid() and geteuid() return 0. whoami returns "root". > But when I run "domainname kingnet" I get the error: > "domainname: you must be root to change the domain name" > Also "su" states "su: incorrect password" without even > prompting for one. What is happening here ? > The environment variables are set by dhcp and do not have > the usual user environment variables .... > Note that on this system, selinux is disabled. > Looking at this I guess the CAP_SYS_ADMIN capability has been lost somewhere. Maybe the dhclient ? From akahl at imttechnologies.com Thu Dec 3 10:20:38 2009 From: akahl at imttechnologies.com (Alexander Kahl) Date: Thu, 03 Dec 2009 11:20:38 +0100 Subject: FYI: Accouncing retirement of BMPx Message-ID: <1259835638.3042.7.camel@lambda.homenet> I just had a private correspondence with Milosz Derezynski, the main dev of BMPx where he confirmed the project was abandoned for the sake of a new project, Youki, that will partly take over BMPx' code base (feature-wise). As I cannot expect any support from upstream anymore and I am neither willing nor capable (due to lack of time) to maintain the project myself, I'm going start the retirement process now, close all open and new tickets for BMPx and advise against (re-)adopting the package. - Alex From casimiro.barreto at gmail.com Thu Dec 3 12:19:07 2009 From: casimiro.barreto at gmail.com (casimiro barreto) Date: Thu, 3 Dec 2009 10:19:07 -0200 Subject: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message) Message-ID: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> Since November 29 I detected that thunderbird is crashing whenever I try to send e-mail. Bugzilla report filled (I see that several other users have had the same problem & also reported). But it appears in bugzilla as a "low priority" "medium severity" problem. Is it possible to retrofit thunderbird until a fix is devised? Best regards, CdAB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at redhat.com Thu Dec 3 12:40:59 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 3 Dec 2009 13:40:59 +0100 Subject: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message) In-Reply-To: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> References: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> Message-ID: <20091203134059.1795ebbe@leela> I searched BZ for your bugreport (you could have provided a link) and found it: https://bugzilla.redhat.com/show_bug.cgi?id=543120 On Thu, 3 Dec 2009 10:19:07 -0200 casimiro barreto wrote: > Since November 29 I detected that thunderbird is crashing whenever I > try to send e-mail. This is valuable information. Why don't you put it in the bugreport? > Bugzilla report filled (I see that several other > users have had the same problem & also reported). If you find duplicate reports, please mark them as such if you can. > But it appears in bugzilla as a "low priority" "medium severity" problem. "Priority" has no standardized meaning. Most maintainers do not use this field at all. Michal From skvidal at fedoraproject.org Thu Dec 3 13:20:49 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 3 Dec 2009 08:20:49 -0500 (EST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259830302.26397.15.camel@adam.local.net> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> <1259830302.26397.15.camel@adam.local.net> Message-ID: On Thu, 3 Dec 2009, Adam Williamson wrote: > On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: > >> We wouldn't be talking about removing the original GA set - just adding >> updated pkgs into the path. So you'd still have the number of pkgs -just >> all in one repo, that you have to download all of the metadata for all of >> the more often, despite that 15K of them don't CHANGE. > > I don't think that was actually made clear in the initial proposal. I'd > been assuming that the proposal was _exactly_ to remove the GA set. > Usually, when a newer package shows up in any given repository, we don't > keep the previous version of the package, do we? So I assumed the > proposal was expecting that behaviour for the combined repository. >From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. -sv From james at fedoraproject.org Thu Dec 3 13:28:23 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 03 Dec 2009 08:28:23 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <27fabe81cb669cea9c92f00630f99bc0.squirrel@arekh.dyndns.org> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <20091202225601.GB1864@auslistsprd01.us.dell.com> <27fabe81cb669cea9c92f00630f99bc0.squirrel@arekh.dyndns.org> Message-ID: <1259846903.14386.11.camel@code.and.org> On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: > > Le Mer 2 d?cembre 2009 23:56, Matt Domsch a ?crit : > > > > On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: > >> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org > >> (make sure it works with web infrastructure instead of fighting it) > > > > Sorry, I don't understand this. Can you elaborate? That would help > > me scope the impact to MirrorManager. > > Right now the same package moves from master URL to master URL as it is pushed > from testing to updates to GA to whatever. That means the same package gets > downloaded many times over because it changed URL (and browsers, proxies, etc > understand new url = new file) It only moves once, at least in the vast majority of cases. > My proposal is to never move a package, put it in a single unchanging place > after a koji build, and just index it or not in the relevant repodata when it > gets promoted or demoted. One problem is that atm. when it moves from testing to updates, or rawhide to GA, it also gets resigned with a different key ... so the bits are not the same. Having the URL be the same will not be helpful until that changes. -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From liangsuilong at gmail.com Thu Dec 3 13:36:31 2009 From: liangsuilong at gmail.com (Liang Suilong) Date: Thu, 3 Dec 2009 21:36:31 +0800 Subject: Proposed F13 feature: drop separate updates repository Message-ID: I think that idea maybe isn't benefit with repository. If updates repository is merged into Everything repository, Will metadata files become too large? I know that the size of metadatas on updates and everything are more than 30 megabytes. If these two repositories compose, We will need download more than 30MB files before updating. I believe that it will decrease the advantage of delrarpm update. It will increase more time to download the files. Is there any way to make createrepo generate delta metadata files? Just like delta rpm, we just need to get what meta files are changed, then yum generates the entire metadata files. We exactly not need and want to download the big files. Additionally, if an user is far away from repository server, though ISP provides quite a good 10Mbps connection, it is still quite slow to install some big applications, such OpenOffice.org, Eclipse, Netbeans, KOffice and some 3D games. Does yum allow to download more than one rpm files with only one thread per files after checking dependencies? Or using a yum plugin to replace yum default downloader by axel to download one rpm files with multi threads. I ever found out this kind of plugin, but I can assure it can run in Fedora 12. -- My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Thu Dec 3 13:56:06 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 3 Dec 2009 05:56:06 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259846903.14386.11.camel@code.and.org> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <1259778903.24751.7.camel@arekh.okg> <20091202225601.GB1864@auslistsprd01.us.dell.com> <27fabe81cb669cea9c92f00630f99bc0.squirrel@arekh.dyndns.org> <1259846903.14386.11.camel@code.and.org> Message-ID: <02F142EC-3467-4847-817C-25290683B40F@j2solutions.net> On Dec 3, 2009, at 5:28, James Antill wrote: > On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: >> >> Le Mer 2 d?cembre 2009 23:56, Matt Domsch a ?crit : >>> >>> On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: >>>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org >>>> (make sure it works with web infrastructure instead of fighting it) >>> >>> Sorry, I don't understand this. Can you elaborate? That would help >>> me scope the impact to MirrorManager. >> >> Right now the same package moves from master URL to master URL as >> it is pushed >> from testing to updates to GA to whatever. That means the same >> package gets >> downloaded many times over because it changed URL (and browsers, >> proxies, etc >> understand new url = new file) > > It only moves once, at least in the vast majority of cases. > >> My proposal is to never move a package, put it in a single >> unchanging place >> after a koji build, and just index it or not in the relevant >> repodata when it >> gets promoted or demoted. > > One problem is that atm. when it moves from testing to updates, or > rawhide to GA, it also gets resigned with a different key ... so the > bits are not the same. Having the URL be the same will not be helpful > until that changes. > > -- > That is no longer true. We used a single key for all of f11 and a single key for all of f12. -- Jes From rawhide at fedoraproject.org Thu Dec 3 14:00:40 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 3 Dec 2009 14:00:40 +0000 Subject: rawhide report: 20091203 changes Message-ID: <20091203140040.GA25681@releng2.fedora.phx.redhat.com> Compose started at Thu Dec 3 08:15:12 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 blacs-mpich2-1.1-33.fc12.i686 requires libmpich.so.1.1 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 galeon-2.0.7-19.fc13.i686 requires gecko-libs = 0:1.9.1.5 geos-devel-3.2.0-rc3_1.fc13.i686 requires geos = 0:3.2.0rc3-rc3_1.fc13 geos-python-3.2.0-rc3_1.fc13.i686 requires geos = 0:3.2.0rc3-rc3_1.fc13 geos-ruby-3.2.0-rc3_1.fc13.i686 requires geos = 0:3.2.0rc3-rc3_1.fc13 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.i686 requires libortp.so.7 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 postgis-jdbc-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 postgis-utils-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 python-basemap-0.99.2-5.fc12.i686 requires libgeos-3.1.1.so rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.i686 requires libmpich.so.1.1 1:xmms-1.2.11-9.20071117cvs.fc12.i686 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) blacs-mpich2-1.1-33.fc12.x86_64 requires libmpich.so.1.1()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) galeon-2.0.7-19.fc13.x86_64 requires gecko-libs = 0:1.9.1.5 geos-devel-3.2.0-rc3_1.fc13.i686 requires geos = 0:3.2.0rc3-rc3_1.fc13 geos-devel-3.2.0-rc3_1.fc13.x86_64 requires geos = 0:3.2.0rc3-rc3_1.fc13 geos-python-3.2.0-rc3_1.fc13.x86_64 requires geos = 0:3.2.0rc3-rc3_1.fc13 geos-ruby-3.2.0-rc3_1.fc13.x86_64 requires geos = 0:3.2.0rc3-rc3_1.fc13 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnome-chemistry-utils-0.10.9-1.fc13.x86_64 requires libgoffice-0.6.so.6()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.x86_64 requires libortp.so.7()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) postgis-jdbc-1.4.1-rc2_1.fc13.1.x86_64 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 postgis-utils-1.4.1-rc2_1.fc13.1.x86_64 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 python-basemap-0.99.2-5.fc12.x86_64 requires libgeos-3.1.1.so()(64bit) rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.x86_64 requires libmpich.so.1.1()(64bit) 1:xmms-1.2.11-9.20071117cvs.fc12.x86_64 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop New package eclipse-emf-query Specify and execute queries against EMF models New package eclipse-emf-transaction A model management layer for managing EMF resources New package eclipse-emf-validation Verify the integrity of EMF models New package eclipse-m2m-qvtoml Implementation of Operational QVT for Eclipse New package eclipse-mdt-ocl Implementation of the OCL OMG metamodel for Eclipse New package eclipse-slice2java A plugin that integrates Eclipse with Ice object middleware New package fedora-accessibility-guide-en-US Using Fedora with a visual, hearing, or mobility impairment New package i3 Improved tiling window manager New package i3lock Simple X display locker New package i3status Generates a status line for dzen2 or wmii New package php-phpunit-File-Iterator FilterIterator implementation that filters files based on a list of suffixes New package python-dmidecode Python module to access DMI data New package xstream Java XML serialization library Removed package compat-libgdamm Removed package htmlview Updated Packages: 389-ds-base-1.2.5-0.2.rc1.fc13 ------------------------------ * Wed Dec 02 2009 Rich Megginson - 1.2.5-0.2.rc1 - 1.2.5.rc1 release * Thu Nov 12 2009 Rich Megginson - 1.2.5-0.1.a1 - 1.2.5.a1 release OpenIPMI-2.0.16-6.fc13 ---------------------- * Tue Dec 01 2009 Jan Safranek - 2.0.16-6 - fix package compilation to remove rpmlint errors adjtimex-1.28-1.fc13 -------------------- * Tue Dec 01 2009 Miroslav Lichvar 1.28-1 - update to 1.28 anaconda-13.9-1.fc13 -------------------- * Tue Dec 01 2009 Chris Lumens - 13.9-1 - Improve text mode fcoe interface (hdegoede) - Fix udev rule to test whether we're in anaconda. (dlehman) - Fix devicelibs.dm.device_is_multipath support for new udev rules. (pjones) - Display progress or wait window when creating devices. (dlehman) - Display progress or wait window when formatting devices. (dlehman) - Add optional progress windows to devicelibs create functions. (dlehman) - Force mkswap to do its job. (dlehman) - Don't try to get dm node or update sysfs path for lvm vgs. (dlehman) - Log upon leaving installer steps as well as entering (a part of #524980). (akozumpl) - An unitialized variable in iw/partition_gui.py and a typo in kickstart.py (akozumpl) - Add DCB option to text mode FCoE setup (#513011) (hdegoede) - Add DCB option to GUI FCoE setup (#513011) (hdegoede) - Add DCB option to kickstart FCoE code (#513011) (hdegoede) - Add support for DCB to fcoe.py (#513011) (hdegoede) - Include fcoemon and dcbd in install.img for FCoE DCB support (#513011) (hdegoede) - Add RAID4 support (#541433) (oliva) - Clear a partition's BOOT flag when formatting it (hdegoede) - Do not set boot flag when there is already a partition with the flag (#533658) (hdegoede) - Fixes a syntax error in commit b495db2cd56c881a7e661ac55bd31069510cf662. (akozumpl) - If /boot is too small to preupgrade, don't allow going back (#499321). (clumens) - One reference to earlyKS somehow survived. Kill it. (clumens) - Quote backticks when writing out the .bash_history file, and add another cmd. (clumens) - Set the default keyboard based on language before showing the UI (#532843). (clumens) - Don't attempt to get the size of a filesystem unless it's supported (#540598). (clumens) - Require /boot to be on a GPT or MSDOS disk label on x86 (#540588). (clumens) - Fix killall -USR2 anaconda writing out a traceback file. (clumens) - Only check for DEVICE_DASD in S390.diskLabelType, not for all platforms. (clumens) - Use installclass to make the bootloader timeout 5 seconds on RHEL. (pjones) - Make sure we get tcp_wrappers-libs installed for stage 2 (pjones) - Mount usbfs before installing packages (#532397) (mmatsuya) - Use fs with largest amount of freespace to store install.img (hdegoede) - Always update booty drivelist before filling bootstore (#533335) (hdegoede) - Enhance drive specification for clearpart, ignoredisk, and partition. (clumens) - Add a function that determines which devices match a given shell glob. (clumens) - Extend udev_resolve_devspec to allow specifying devices in more ways. (clumens) - Name log files something that doesn't conflict with the system (#539542). (clumens) - Adds interactive install support for NFS options (#537764) (akozumpl) - Introduces check_asprintf macro that checks asprintfs return value and terminates program in OOM scenarios. (akozumpl) - Sleep if the kickstart file read fails (#537361) (akozumpl) - Move libcurl initialization to urlinstTransfer() (#537870). (dcantrell) - Replace all popt use with glib's option parsing code. (dcantrell) - Clean up initProductInfo() in loader.c. (dcantrell) - Use glib string parsing functions in driverselect.c. (dcantrell) - If a package has %pre/%post scriptlet errors, abort the install (#531599). (clumens) - If a package has a dependency problem, offer to continue/abort (#511801). (clumens) - Generate more complete device.map grub file when upgrading grub. (#533621) (rvykydal) - Added the libudev python bindings (mgracik) - If the kickstart log file's path doesn't exist, make it. (clumens) - Don't make chown or lsetfilecon errors fatal (#529940). (clumens) - Get correct boot device in reIPL code for s390 (#537390). (hamzy) - Expand the proxy table a little bit to reduce clutter (#537878). (clumens) - Use glib data structures in loader's module handling code. (dcantrell) - Various improvements to kickstart scriptlet reporting (#510636). (clumens) apbs-1.2.1-2.fc13 ----------------- * Tue Dec 01 2009 Tim Fenn - 1.2.1-2 - add RPM_OPT_FLAGS aspell-0.60.6-9.fc13 -------------------- * Tue Dec 01 2009 Ivana Hutarova Varekova - 12:0.60.6-9 - add --disable-rpath to configure part remove remanent obsolete tags fix license field asterisk-1.6.2.0-0.15.rc7.fc13 ------------------------------ * Wed Dec 02 2009 Jeffrey C. Ollie - 1.6.2.0-0.15.rc7 - Update to 1.6.2.0-rc7 * Tue Dec 01 2009 Jeffrey C. Ollie - 1.6.2.0-0.14.rc6 - Change the logrotate and the init scripts so that Asterisk doesn't try and write to / or /root * Thu Nov 19 2009 Jeffrey C. Ollie - 1.6.2.0-0.13.rc6 - Make dependency on uw-imap conditional and some other changes to make building on RHEL5 easier. atk-1.29.3-2.fc13 ----------------- * Wed Dec 02 2009 Matthias Clasen - 1.29.3-2 - Drop BR audacious-2.2-2.fc13 -------------------- * Wed Dec 02 2009 Michael Schwendt - 2.2-2 - Drop Musepack and SID MIME types from desktop files. As of Audacious 2.2, Musepack is only supported by the separate "ffaudio" plugin. The SID plugin in a separate subpackage provides its own desktop file. - Drop unsupported MIME types from desktop files. audacious-plugins-2.2-2.fc13 ---------------------------- * Wed Dec 02 2009 Michael Schwendt - 2.2-2 - Move SID music plugin into audacious-plugins-sid package. Its built with libsidplay 1 while 3rd party package providers may build it with libsidplay 2. - Include metronome plugin in base plugins package. No reason to split this off into an optional subpackage. auriferous-1.0.1-10.fc13 ------------------------ * Sun Nov 29 2009 Hans de Goede 1.0.1-10 - Fix levels not loading - Fix getting stuck at top of ladder below bar (in level 2) - Add support for several non alpha numeric keys in key bindings dialog - Silence ClanLib warning about sound stream looping not being implemented - Fix crash on exit (real fix is in ClanLib06, #542178) azureus-4.3.0.4-1.fc13 ---------------------- * Tue Dec 01 2009 David Juran - 4.3.0.4-1 - upgrade to 4.3.0.4 bibletime-2.4-1.fc13 -------------------- * Wed Dec 02 2009 Deji Akingunola - 2.4-1 - Update to 2.4 - Update the description and summary. bind-9.7.0-0.9.b3.fc13 ---------------------- * Tue Dec 01 2009 Adam Tkac 32:9.7.0-0.9.b3 - update to 9.7.0b3 bind-dyndb-ldap-0.1.0-0.5.a1.fc13 --------------------------------- * Tue Dec 01 2009 Adam Tkac - 0.1.0-0.5.a1 - rebuild against new bind brasero-2.29.3-2.fc13 --------------------- * Wed Dec 02 2009 Bastien Nocera 2.29.3-2 - Make libbeagle dep more automatic * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 c-ares-1.7.0-1.fc13 ------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 1.7.0-1 - update to 1.7.0 cacti-0.8.7e-3.fc13 ------------------- * Tue Dec 01 2009 Mike McGrath - 0.8.7e-3 - Pulling in some official patches - #541279 - #541962 calibre-0.6.25-1.fc13 --------------------- * Wed Dec 02 2009 Ionu? C. Ar??ri?i - 0.6.25-1 - New upstream release checkpolicy-2.0.21-1.fc13 ------------------------- * Sun Nov 01 2009 Dan Walsh - 2.0.21-1 - Latest update from NSA * Add support for building Xen policies from Paul Nuzzi. * Add long options to checkpolicy and checkmodule by Guido Trentalancia cherokee-0.99.30-1.fc13 ----------------------- * Tue Dec 01 2009 Lorenzo Villani - 0.99.30-1 - 0.99.30 clojure-1.0.0-5.fc13 -------------------- * Wed Dec 02 2009 Jochen Schmitt 1:1.0.0-3 - Add Epoch to get proper EVR path * Wed Dec 02 2009 Jochen Schmitt 1:1.0.0-5 - Installing maven pom file * Tue Dec 01 2009 Jochen Schmitt 1.0.0-1 - New upstream release - change license tag to EPL * Tue Dec 01 2009 Jochen Schmitt 1.0.0-2 - Forgot uploading soruces coccinella-0.96.16-1.fc13 ------------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 0.96.16-1 - update to 0.96.16 cpmtools-2.11-2.fc13 -------------------- * Tue Dec 01 2009 Lucian Langa - 2.11-2 - patch to fix crash in cpmcp cracklib-2.8.15-1.fc13 ---------------------- * Tue Dec 01 2009 Nalin Dahyabhai - 2.8.15-1 - update to 2.8.15 - update cracklib-words to the current version (2008-05-07) - fixup URLs for various dictionary sources that we use - fix freeing-an-uninitialized-pointer in the python module (SF#2907102) - add a disttag crda-1.1.0_2009.11.25-1.fc13 ---------------------------- * Wed Dec 02 2009 John W. Linville 1.1.0_2009.11.25-1 - Update wireless-regdb to version 2009.11.25 * Wed Nov 11 2009 John W. Linville 1.1.0_2009.11.10-1 - Update wireless-regdb to version 2009.11.10 curl-7.19.7-4.fc13 ------------------ * Tue Dec 01 2009 Kamil Dudka 7.19.7-4 - do not require valgrind on s390 and s390x - temporarily disabled SCP/SFTP test-suite (#539444) devhelp-2.29.3-2.fc13 --------------------- * Wed Dec 02 2009 Matthew Barnes - 2.29.3-2 - Add patch for RH bug #543177 (missing webkit-1.0 requirement). * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 dnsperf-1.0.1.0-14.fc13 ----------------------- * Tue Dec 01 2009 Adam Tkac - 1.0.1.0-14 - rebuild against new bind drupal-cck-6.x.2.6-1.fc13 ------------------------- * Tue Dec 01 2009 Jon Ciesla - 6.x.2.6-1 - New upstream, BZ 541439. drupal-views-6.x.2.7-1.fc13 --------------------------- * Tue Dec 01 2009 Jon Ciesla - 6.x.2.7-1 - New upstream, BZ 541440. emacs-23.1-15.fc13 ------------------ * Wed Dec 02 2009 Daniel Novotny 1:23.1-15 - fix #543046 - Using scroll bar in emacs highlights/selects text eog-2.29.3-1.fc13 ----------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 epiphany-2.29.3-1.fc13 ---------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 etoys-4.0.2339-1.fc13 --------------------- * Tue Dec 01 2009 Daniel Drake - 4.0.2339-1 - new upstream release evince-2.29.3-1.fc13 -------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 evolution-data-server-2.29.3-2.fc13 ----------------------------------- * Wed Dec 02 2009 Matthew Barnes - 2.29.3-2.fc13 - Devel subpackage does not need to require doc subpackage. evolution-exchange-2.29.3-1.fc13 -------------------------------- * Mon Nov 30 2009 Milan Crha - 2.29.3-1.fc13 - Update to 2.29.3 - Remove patch to work around intltool issue (fixed upstream). - Add patch for missing ldap libs. * Tue Nov 17 2009 Matthew Barnes - 2.29.2-1.fc13 - Update to 2.29.2 - Add patch to work around intltool issue. * Tue Oct 27 2009 Matthew Barnes - 2.29.1-1.fc13 - Update to 2.29.1 - Bump evo_major to 2.30. - Drop eds_major definition since it will never change. evolution-mapi-0.29.3-1.fc13 ---------------------------- * Mon Nov 30 2009 Milan Crha - 0.29.3-1 - Update to 0.29.3 - Remove patch for Gnome bug #588453 (fixed upstream). - Remove patch for Gnome bug #595260 (fixed upstream). - Remove patch for Gnome bug #595355 (fixed upstream). - Remove patch for Gnome bug #595480 (fixed upstream). evtest-1.25-1.fc13 ------------------ * Thu Dec 03 2009 Peter Hutterer 1.25-1 - evtest 1.25 (includes evtest-capture) file-roller-2.29.2-2.fc13 ------------------------- * Wed Dec 02 2009 Matthias Clasen 2.29.2-2 - Drop unneded BRs * Tue Dec 01 2009 Bastien Nocera 2.29.2-1 - Update to 2.29.2 fontpackages-1.41-1.fc13 ------------------------ * Tue Dec 01 2009 Nicolas Mailhot - 1.41-1 ? Bugfix release freeipmi-0.7.16-1.fc13 ---------------------- * Tue Dec 01 2009 Jan Safranek - 0.7.16-1 - Update to freeipmi-0.7.16 frozen-bubble-2.2.0-4.fc13 -------------------------- * Tue Dec 01 2009 Hans de Goede 2.2.0-4 - Do not remove server user (#542423), per: http://fedoraproject.org/wiki/Packaging/UsersAndGroups gedit-2.29.3-2.fc13 ------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 * Tue Dec 01 2009 Brian Pepple - 1:2.29.3-2 - Rebase fix python path patch. gedit-latex-plugin-0.2-0.4.rc2.fc13 ----------------------------------- * Mon Nov 30 2009 Sergio Pascual - 0.2-0.4.rc2 - Using virtual requires to pull in the TeX packages (bz #542611) gedit-plugins-2.29.3-1.fc13 --------------------------- * Wed Dec 02 2009 Rakesh Pandit 2.29.3-1 - Updated to 2.29.3 geos-3.2.0-rc3_1.fc13 --------------------- * Wed Dec 02 2009 Devrim GUNDUZ - 3.2.0rc3-1 - Update to 3.2.0 rc3 ghdl-0.28-0.131svn.0.fc13 ------------------------- * Wed Dec 02 2009 Thomas Sailer - 0.28-0.131svn.0 - update to 0.28/svn131 - symlink v08 libraries to v93 for now gnome-commander-1.2.9-0.1.git_D20091203T1630.fc13 ------------------------------------------------- * Thu Dec 03 2009 Mamoru Tasaka - Update to the latest git (to fix crash when cancelling symlink creation with ESC bug 542366, GNOME bug 603301) gnome-python2-desktop-2.28.0-2.fc12 ----------------------------------- * Fri Nov 13 2009 Matthew Barnes - 2.28.0-2.fc12 - gnome-python2-nautilus-cd-burner obsoleted by gnome-python2-brasero, sort of (RH bug #536757). gnome-vfs2-2.24.2-3.fc13 ------------------------ * Wed Dec 02 2009 Tomas Bzatek - 2.24.2-3 - Patch security hole in embedded neon (CVE-2009-2473) gnote-0.6.3-1.fc13 ------------------ * Tue Dec 01 2009 Bastien Nocera 0.6.3-1 - Update to 0.6.3 gnucash-2.3.7-1.fc13 -------------------- * Tue Dec 01 2009 Bill Nottingham - 2.3.7-1 - Update to development version. - Fix accelerators (#533019, #541915) * Wed Aug 12 2009 Ville Skytt? - 2.2.9-3 - Use lzma compressed upstream tarball. gnumeric-1.9.16-1.fc13 ---------------------- * Mon Nov 30 2009 Huzaifa Sidhpurwala 1:1.9.16-1 - New upstream gromacs-4.0.5-5.fc13 -------------------- * Tue Dec 01 2009 Jussi Lehtola - 4.0.5-4 - Fix obsoletes. * Tue Dec 01 2009 Jussi Lehtola - 4.0.5-5 - Put correct MPI devel package requires in place. * Mon Nov 30 2009 Jussi Lehtola - 4.0.5-3 - Combine libs with binaries and drop debug packages to avoid explosion of number of packages. - Adopt use of MPI guidelines. * Fri Jul 24 2009 Fedora Release Engineering - 4.0.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Fri May 22 2009 Jussi Lehtola - 4.0.5-1 - Update to 4.0.5. - Change spec %defines to %globals. - Add debug subpackages to make debugging of GROMACS possible. grub2-1.97.1-4.fc13 ------------------- * Tue Dec 01 2009 Dennis Gilmore - 1:1.97.1-4 - add patch so that grub2 finds fedora's initramfs gtk-doc-1.11-6.fc13 ------------------- * Thu Dec 03 2009 Matthias Clasen - 1.11-6 - Drop unnecessary BRs gtksourceview2-2.9.3-1.fc13 --------------------------- * Tue Dec 01 2009 Bastien Nocera 2.9.3-1 - Update to 2.9.3 gtkspell-2.0.16-1.fc13 ---------------------- * Wed Dec 02 2009 Matthew Barnes - 2.0.16-1.fc13 - Update to 2.0.16 - No need to run libtoolize and autoreconf. - Remove language comparison patch (fixed upstream). gzip-1.3.13-1.fc13 ------------------ * Tue Dec 01 2009 Karel Klic - 1.3.13-1 - New upstream version - Updated license from GPLv2 to GPLv3+ - Removed gzip-1.3.12-futimens.patch, as it is fixed in the new version - Updated rsync patch to the new upstream version - Updated cve-2006-4337 patch to use gzip_error instead of error hamster-applet-2.29.3-1.fc13 ---------------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 hedgewars-0.9.12-2.fc13 ----------------------- * Tue Dec 01 2009 Hans de Goede 0.9.12-2 - Use RPM_OPT_FLAGS when building c++ code and pass -g to fpc (#542000) hunspell-nso-0.20091201-1.fc13 ------------------------------ * Wed Dec 02 2009 Caolan McNamara - 0.20091201-1 - latest version icu-4.2.1-8.fc13 ---------------- * Wed Dec 02 2009 Caolan McNamara - 4.2.1-8 - Resolves: rhbz#543386 update icu-config * Thu Nov 19 2009 Caolan McNamara - 4.2.1-7 - Fix FTBFS with yet another autoconf version that changes behaviour ipa-1.2.2-2.fc12 ---------------- * Tue Nov 24 2009 Simo Sorce - 1.2.2-2 - Add patch to fix installation with krb5 1.7 iperf-2.0.4-4.fc13 ------------------ * Tue Dec 01 2009 Gabriel Somlo 2.0.4-4 - patched to current svn trunk to address performance issues (#506884) iscsi-initiator-utils-6.2.0.870-11.fc13 --------------------------------------- * Tue Dec 01 2009 Hans de Goede 6.2.0.870-11 - Own /etc/iscsi (#542849) - Do not own /etc/NetworkManager/dispatcher.d (#533700) iso-codes-3.12-1.fc13 --------------------- * Wed Dec 02 2009 Parag Nemade - 3.12-1 - Update to 3.12 iw-0.9.18-1.fc13 ---------------- * Wed Dec 02 2009 John W. Linville 0.9.18-1 - Update to 0.9.18 jakarta-commons-modeler-2.0.1-1.fc13 ------------------------------------ * Wed Dec 02 2009 Mat Booth - 2.0.1-1 - Update to 2.0.1 - Rewrite spec file to build using upstream-preferred maven instead of ant - Drop patches to build script - Now with OSGi manifest (comes free with the maven build) - Now installs pom and fettles the maven dep-map, see RHBZ #542730 - Fix javadoc package requires jetty-6.1.21-4.fc13 ------------------- * Wed Dec 02 2009 Jeff Johnston 6.1.21-4 - Resovles #543081 - Add maven depmap fragments. kde-settings-4.4-3 ------------------ * Tue Dec 01 2009 Rex Dieter 4.4-2 - kdmrc: revert to ServerVTs=-1 (#475890) * Tue Dec 01 2009 Rex Dieter 4.4-3 - kdmrc: ServerArgsLocal=-nr , for better transition from plymouth kernel-2.6.32-0.65.rc8.git5.fc13 -------------------------------- * Wed Dec 02 2009 Dave Airlie 2.6.32-0.62.rc8.git2 - forward port radeon fixes from F-12 + add radeon display port support * Wed Dec 02 2009 David Woodhouse 2.6.32-0.63.rc8.git2 - forward port IOMMU fixes from F-12 for HP BIOS brokenness - Fix oops with intel_iommu=igfx_off - agp/intel: Clear full GTT at startup * Wed Dec 02 2009 John W. Linville 2.6.32-0.64.rc8.git2 - ath9k: add fixes suggested by upstream maintainer * Wed Dec 02 2009 Kyle McMartin 2.6.32-0.65.rc8.git5 - 2.6.32-rc8-git5 - nuke 9p cachefiles fix, upstream. - SLOW_WORK_PROC was renamed to SLOW_WORK_DEBUG, debugfs instead of procfs. * Mon Nov 30 2009 Kyle McMartin - drm-i915-fix-sync-to-vbl-when-vga-is-off.patch: add, (rhbz#541670) * Mon Nov 30 2009 Kyle McMartin 2.6.32-0.60.rc8.git2 - 2.6.32-rc8-git2 daily snapshot - nuke include/generated nuke-age since the patch was reverted upstream - config changes: - generic: +CONFIG_FSCACHE_OBJECT_LIST=y +CONFIG_SLOW_WORK_PROC=y * Mon Nov 30 2009 Kyle McMartin 2.6.32-0.61.rc8.git2 - fix-9p-fscache.patch: fix build. * Sun Nov 29 2009 Kyle McMartin - linux-2.6-sysrq-c.patch: drop, was made consistent upstream. kexec-tools-2.0.0-30.fc13 ------------------------- * Tue Dec 01 2009 Neil Horman - 2.0.0-30 - Fix raid support in mkdumprd (bz 519767) * Mon Nov 23 2009 Neil Horman - 2.0.0-29 - Updating firstboot script to RHEL-6 version (bz 539812) latexmk-4.11-1.fc13 ------------------- * Tue Dec 01 2009 Jerry James - 4.11-1 - Update to 4.11. lcdf-typetools-2.80-1.fc13 -------------------------- * Wed Dec 02 2009 Parag Nemade - 2.80-1 - Update to next upstream release 2.80 libfprint-0.1.0-14.pre2.fc13 ---------------------------- * Tue Dec 01 2009 Bastien Nocera 0.1.0-14.pre2 - Update AES1610 patch libgnome-2.28.0-3.fc13 ---------------------- * Wed Dec 02 2009 Matthias Clasen - 2.28.0-3 - Rebuild libgnomekbd-2.28.0-3.fc13 ------------------------- * Thu Dec 03 2009 Matthias Clasen - 2.28.0-3 - Small spec fixes libmlx4-1.0.1-2.fc13 -------------------- * Tue Dec 01 2009 Doug Ledford - 1.0.1-1 - Update to latest upstream release - Add pseudo provides of libibverbs-driver - Update buildrequires for libibverbs API change * Tue Dec 01 2009 Doug Ledford - 1.0.1-2 - Merge various bits from Red Hat package into Fedora package libmthca-1.0.5-5.fc13 --------------------- * Wed Dec 02 2009 Doug Ledford - 1.0.5-5 - Rename devel-static package to just -static, it only has a single static lib in it and no actual devel files (like headers, those are part of libibverbs-devel instead). Obsolete the various other named packages we want this to supercede - Enable valgrind annotations on all arches except ia64 - Update to latest code, including update for libibverbs API change - Bump release to 5 so it is higher than the current rhel5 libmthca release - Add various patches from the upstream git repo that haven't been rolled into a new release tarball yet libmtp-1.0.1-2.fc13 ------------------- * Tue Dec 01 2009 Linus Walleij 1.0.1-2 - Two patches from Dan Nicholson to fix up the udev rules a bit. libselinux-2.0.90-1.fc13 ------------------------ * Tue Dec 01 2009 Dan Walsh - 2.0.90-1 - Update to upstream * add/reformat man pages by Guido Trentalancia . * Change exception.sh to be called with bash by Manoj Srivastava libsemanage-2.0.43-1.fc13 ------------------------- * Tue Dec 01 2009 Dan Walsh - 2.0.43-1 - Update to upstream * Move libsemanage.so to /usr/lib * Add NAME lines to man pages from Manoj Srivastava libsoup-2.29.3-1.fc13 --------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 libtool-2.2.6-17.fc13 --------------------- * Wed Dec 02 2009 Karsten Hopp 2.2.6b-2 - fix gcc version * Wed Dec 02 2009 Karsten Hopp 2.2.6-16 - make sure that NVR is higher than previous version * Wed Dec 02 2009 Karsten Hopp 2.2.6-17 - fix directory name used in libtool tarball * Tue Dec 01 2009 Karsten Hopp 2.2.6b-1 - update to 2.2.6b, fixes CVE-2009-3736: libltdl may load and execute code from a library in the current directory libusb1-1.0.6-1.fc13 -------------------- * Wed Dec 02 2009 Jindrich Novy 1.0.6-1 - update to 1.0.6 libvirt-cim-0.5.8-1.fc13 ------------------------ * Wed Dec 02 2009 Kaitlin Rupert - 0.5.8-1 - Updated to latest upstream source libvirt-java-0.4.0-2.fc13 ------------------------- * Tue Dec 01 2009 Bryan Kearney - 0.4.0-2 - Modified the dependency to be libvirt-client instead of libvirt. libvpd-2.1.1-1.fc13 ------------------- * Wed Dec 02 2009 Eric Munson - 2.1.1-1 - Update to latest libvpd release libxcb-1.4-2.fc13 ----------------- * Wed Dec 02 2009 Adam Jackson 1.4-2 - libxcb-1.4-keepalive.patch: setsockopt(SO_KEEPALIVE) for TCP (#476415) libxklavier-4.0-6.fc12 ---------------------- * Thu Oct 15 2009 Matthias Clasen - 4.0-6 - Incorporate upstream fixes for XInput error handling liveusb-creator-3.9-1.fc13 -------------------------- * Tue Dec 01 2009 Luke Macken - 3.8.8-1 - 3.8.8, bugfix release * Tue Dec 01 2009 Luke Macken - 3.8.9-1 - 3.8.9, fixes bug #540255 * Tue Dec 01 2009 Luke Macken - 3.9-1 - 3.9 release lksctp-tools-1.0.11-1.fc13 -------------------------- * Tue Dec 01 2009 Jan Safranek 1.0.11-1 - Update to 1.0.11 - Remove rpath from compiled binaries - Remove static libraries lockdev-1.0.1-20.fc13 --------------------- * Thu Dec 03 2009 Jiri Popelka - 1.0.1-20 - Fixed pre section (http://fedoraproject.org/wiki/Packaging/UsersAndGroups) - Added back Buildroot to silence rpmlint's false positive * Tue Dec 01 2009 Jiri Popelka - 1.0.1-19 - Added license text to package log4cxx-0.10.0-9.fc13 --------------------- * Tue Dec 01 2009 Caol?n McNamara - 0.10.0-9 - Rebuild for new db4 log4net-1.2.10-10.fc13 ---------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 1.2.10-10 - use system mono.snk key instead of generating our own on each build * Sun Nov 29 2009 Christopher Brown - 1.2.10-9 - Fix pkg-config file location lsvpd-1.6.7-1.fc13 ------------------ * Wed Dec 02 2009 Eric Munson - 1.6.7-1 - Update to latest lsvpd release - Add librtas support to build on POWERPC - Add patch to lookup *.ids file location at runtime lucene-2.4.1-1.fc13 ------------------- * Tue Dec 01 2009 Orion Poplawski - 0:2.4.1-1 - Update to 2.4.1 man-1.6f-24.fc13 ---------------- * Tue Dec 01 2009 Ivana Varekova - 1.6f-24 - fix the problem: #542852 - 'man cut cut' throws an error man-pages-3.23-3.fc13 --------------------- * Wed Dec 02 2009 Ivana Hutarova Varekova - 3.22-7 - fix sched_setaffinity(2) page - add an EXAMPLE and new NOTES maniadrive-1.2-19.fc13 ---------------------- * Fri Nov 20 2009 Remi Collet 1.2-19 - Rebuild for new php 5.3.1 mdadm-3.0.3-2.fc13 ------------------ * Tue Dec 01 2009 Doug Ledford - 3.0.3-2 - Minor tweak to init script for LSB compliance (bz527957) mercurial-1.4.1-1.fc13 ---------------------- * Wed Dec 02 2009 Neal Becker - 1.4.1-1 - Update to 1.4.1 midori-0.2.1-1.fc13 ------------------- * Wed Dec 02 2009 Adam Miller - 0.2.1-1 - Update to new upstream release (0.2.1): Fix Mouse Gestures to work after activation, Explicitly link to X11 to support gold, Implement various Hildon specific features, Hide the navigationbar in fullscreen, Implement permanent storage of form history, Support keyboard shortcuts like Ctrl+Tab or "a", Handle SIGHUP, SIGINT, SIGTERM and SIGQUIT, Make creation of new windows fast, Introduce the Tab History List extension, Load icons laziy at startup to speed up startup, Introduce a Web Cache extension, Refactor and tweak the Preferences dialogue, Implement combos to choose external applications mingw32-atk-1.29.3-1.fc13 ------------------------- * Wed Dec 02 2009 Erik van Pienbroek - 1.29.3-1 - Update to 1.29.3 mingw32-glib2-2.23.0-1.fc13 --------------------------- * Wed Dec 02 2009 Erik van Pienbroek - 2.23.0-1 - Update to 2.23.0 - Added BR: mingw32-zlib mingw32-gtk2-2.19.1-1.fc13 -------------------------- * Wed Dec 02 2009 Erik van Pienbroek - 2.19.1-1 - Update to 2.19.1 - Dropped the autoreconf call mingw32-qt-4.6.0-1.fc13 ----------------------- * Tue Dec 01 2009 Thomas Sailer - 4.6.0-1 - update to 4.6.0 mingw32-qt-qmake-4.6.0-1.fc13 ----------------------------- * Tue Dec 01 2009 Thomas Sailer - 4.6.0-1 - update to 4.6.0 mingw32-qwt-5.2.0-2.fc13 ------------------------ * Wed Dec 02 2009 Thomas Sailer - 5.2.0-2 - qt 4.6.0 compile workarounds * Tue Nov 24 2009 Thomas Sailer - 5.2.0-1 - update to 5.2.0 mod_selinux-2.2.2454-2.fc13 --------------------------- * Fri Dec 04 2009 KaiGai Kohei - 2.2.2454-2 - rebuild for the base policy of F-13 mojito-0.21.7-1.fc13 -------------------- * Wed Dec 02 2009 Peter Robinson 0.21.7-1 - Update to 0.21.7 mono-2.6-3.fc13 --------------- * Tue Dec 01 2009 Tom "spot" Callaway 2.6-2 - generate and package mono.snk for packages without bundled keys to use - put mono.snk in /etc/pki/mono/ - package /etc/pki/mono/* in mono-devel * Tue Dec 01 2009 Tom "spot" Callaway 2.6-3 - perms on mono.snk should be 0644 mono-cecil-flowanalysis-0.1-0.11.20080409svn100264.fc13 ------------------------------------------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 0.1-0.11.20080409svn100264 - use the system mono.snk key instead of regenerating on every build mono-ndoc-1.3.1-8.fc13 ---------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 1.3.1-8 - use the system mono.snk key instead of regenerating on every build mono-nunit22-2.2.10-12.fc13 --------------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 1:2.2.10-12 - use the system mono.snk key instead of regenerating on every build mono-sharpcvslib-0.35-13.fc13 ----------------------------- * Tue Dec 01 2009 Tom "spot" Callaway - 0.35-13 - use the system mono.snk key instead of regenerating on every build mousetweaks-2.29.3-1.fc13 ------------------------- * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 nano-2.2.0-1.fc13 ----------------- * Tue Dec 01 2009 Kamil Dudka - 2.2.0-1 - new upstream release nant-0.85-32.fc13.1 ------------------- * Tue Dec 01 2009 Tom "spot" Callaway 1:0.85-32.1 - bootstrap again nautilus-2.28.2-1.fc13 ---------------------- * Mon Nov 30 2009 Alexander Larsson - 2.28.2-1 - Update to 2.28.2 nbtk-1.2.3-2.fc13 ----------------- * Tue Dec 01 2009 Peter Robinson 1.2.3-1 - New upstream 1.2.3 stable release, move to a proper tarball * Tue Dec 01 2009 Peter Robinson 1.2.3-2 - Bump release netcdf-4.1.0-0.6.2009120100.fc13 -------------------------------- * Tue Dec 01 2009 Orion Poplawski - 4.1.0-0.6.2009120100 - Update snapshot, removes SZIP defines from header * Fri Nov 13 2009 Orion Poplawski - 4.1.0-0.5.2009111309 - Update snapshot - Docs are installed now nmap-5.00-5.fc13 ---------------- * Tue Dec 01 2009 Michal Hlavinka - 2:5.00-5 - spec cleanup olpc-library-2.0.3-1.fc13 ------------------------- * Tue Dec 01 2009 Daniel Drake - 2.0.3-1 - new version olpc-utils-1.0.12-1.fc13 ------------------------ * Wed Dec 02 2009 Daniel Drake - 1.0.12-1 - Bump to v1.0.12 openoffice.org-3.2.0-6.3.fc13 ----------------------------- * Tue Dec 01 2009 Caol?n McNamara - 1:3.2.0-6.3 - add workspace.pythonssldedux.patch to get CRAM-MD5 working from emailmerge openslide-2.2.1-1.fc12 ---------------------- * Fri Oct 23 2009 Adam Goode - 2.2.1-1 - New upstream release + Fix thread safety (not really lockless anymore) parole-0.1.99-1.fc13 -------------------- * Tue Dec 01 2009 Christoph Wickert - 0.1.99-1 - Update to 0.1.99 and drop all patches - Make the plugin require mozilla-filesystem perl-5.10.0-87.fc13 ------------------- * Tue Dec 01 2009 Stepan Kasal - 4:5.10.0-87 - fix patch-update-Compress-Raw-Zlib.patch (did not patch Zlib.pm) - update Compress::Raw::Zlib to 2.023 - update IO::Compress::Base, and IO::Compress::Zlib to 2.015 (#542645) * Mon Nov 30 2009 Marcela Ma?l??ov? - 4:5.10.0-86 - 542645 update IO-Compress-Base perl-Catalyst-Plugin-Authorization-ACL-0.15-1.fc13 -------------------------------------------------- * Tue Dec 01 2009 Gabriel Somlo 0.15-1 - update to 0.15 perl-Finance-Quote-1.17-1.fc12 ------------------------------ * Mon Nov 23 2009 Bradley Baetz - 1.17-1 - Update to 1.17 - Add extra BuildRequires needed for tests to pass pgbouncer-1.3.1-1.fc13 ---------------------- * Tue Dec 01 2009 - Devrim GUNDUZ 1.3.1-1 - Update to 1.3.1 pixman-0.17.2-1.fc13 -------------------- * Wed Dec 02 2009 Soren Sandmann - 0.17.2-1 - pixman 0.17.2 policycoreutils-2.0.78-1.fc13 ----------------------------- * Tue Dec 01 2009 Dan Walsh 2.0.78-1 - Update to upstream * Remove non-working OUTFILE from fixfiles from Dan Walsh. * Additional exception handling in chcat from Dan Walsh. * fix sepolgen to read a "type 1403" msg as a policy load by Stephen Smalley * Add support for Xen ocontexts from Paul Nuzzi. postgresql-pgpool-II-2.2.6-1.fc13 --------------------------------- * Tue Dec 01 2009 Devrim GUNDUZ - 2.2.6-1 - Update to 2.2.6 * Sun Nov 01 2009 Devrim GUNDUZ - 2.2.5-2 - Remove init script from all runlevels before uninstall. Per RH Bugzilla psacct-6.3.2-56.fc13 -------------------- * Wed Dec 02 2009 Ivana Hutarova Varekova - 6.2.3-56 - add dump-utmp.8 and dump-acct.8 man-pages pulseaudio-0.9.21-2.fc13 ------------------------ * Wed Dec 02 2009 Rex Dieter - 0.9.21-2 - module-device-manager, kde autostart bits missing (#541419) qbittorrent-2.0.0-0.9.svn3027.fc13 ---------------------------------- * Wed Dec 02 2009 Leigh Scott - 2.0.0-0.9.svn3027 - update to svn 3027 qt-4.6.0-1.fc13 --------------- * Tue Dec 01 2009 Than Ngo - 4.6.0-1 - 4.6.0 qt-creator-1.3.0-2.fc13 ----------------------- * Tue Dec 01 2009 Lorenzo Villani - 1.3.0-1 - 1.3.0 final * Tue Dec 01 2009 Lorenzo Villani - 1.3.0-2 - Force dependency on Qt >= 4.6.0 rdma-1.0-6.fc13 --------------- * Tue Dec 01 2009 Doug Ledford - 1.0-6 - Tweak init script for LSB compliance - Tweak ifup-ib script to work properly with bonded slaves that need their MTU set - Tweak ifup-ib script to properly change connected mode either on or off instead of only setting it on but not turning it off if the setting changes rkhunter-1.3.6-2.fc13 --------------------- * Tue Dec 01 2009 Kevin Fenzi - 1.3.6-2 - Disable apps check by default - bug #543065 ruby-RMagick-2.12.2-2.fc13 -------------------------- * Wed Dec 02 2009 Mamoru Tasaka - 2.12.2-2 - Set ImageMagick dependency correctly again smartmontools-5.39-0.1.rc1.fc13 ------------------------------- * Wed Dec 02 2009 Michal Hlavinka - 1:5.39-0.1.rc1 - update to 5.39-rc1 * Wed Nov 25 2009 Michal Hlavinka - 1:5.38-25.20091119svn - spec cleanup soprano-2.3.70-1.fc13 --------------------- * Wed Dec 02 2009 Rex Dieter - 2.3.70-1 - soprano-2.3.70 (#543440) sugar-0.87.1-1.fc13 ------------------- * Tue Dec 01 2009 Sebastian Dziallas - 0.87.1-1 - New upstream release - Make this noarch again sugar-base-0.87.1-1.fc13 ------------------------ * Tue Dec 01 2009 Sebastian Dziallas - 0.87.1-1 - New upstream release sugar-datastore-0.87.1-1.fc13 ----------------------------- * Tue Dec 01 2009 Sebastian Dziallas - 0.87.1-1 - New upstream release sugar-presence-service-0.87.1-1.fc13 ------------------------------------ * Tue Dec 01 2009 Sebastian Dziallas - 0.87.1-1 - New upstream release sugar-toolkit-0.87.1-1.fc13 --------------------------- * Tue Dec 01 2009 Sebastian Dziallas - 0.87.1-1 - New upstream release sysprof-1.1.4-1.fc12 -------------------- * Tue Nov 03 2009 Gianluca Sforna - 1.1.4-1 - New upstream release sysstat-9.0.6-1.fc13 -------------------- * Wed Dec 02 2009 Ivana Hutarva Varekova - 9.0.6-1 - update to 9.0.6 telepathy-sofiasip-0.5.19-1.fc13 -------------------------------- * Tue Dec 01 2009 Brian Pepple - 0.5.19-1 - Update to 0.5.19. tkimg-1.4-0.6.20091129svn.fc13 ------------------------------ * Tue Dec 01 2009 Sergio Pascual - 1.4-0.6.20091129svn - New upstream source, version 228 from trunk - Provides man pages - Passing tests for sgi format - Fixes bz #542356 tortoisehg-0.9.1.1-1.fc13 ------------------------- * Thu Dec 03 2009 Mads Kiilerich - 0.9.1-1 - tortoisehg-0.9.1 * Thu Dec 03 2009 Mads Kiilerich - 0.9.1.1-1 - tortoisehg-0.9.1.1 - a brown paperbag release units-1.87-7.fc13 ----------------- * Tue Dec 01 2009 Kamil Dudka - 1.87-6 - update license to GPLv3+, sanitize specfile - fix tons of gcc warnings * Tue Dec 01 2009 Kamil Dudka - 1.87-7 - add BuildRequires for bison vym-1.12.6-1.fc13 ----------------- * Wed Dec 02 2009 Jon Ciesla - 1.12.6-1 - Updated to new upstream version, BZ 543442. webacula-3.4-1.fc13 ------------------- * Fri Oct 16 2009 Yuri Timofeev 3.4-1 - Version 3.4 webkitgtk-1.1.17-1.fc13 ----------------------- * Tue Dec 01 2009 Bastien Nocera 1.1.17-1 - Update to 1.1.17 xapian-bindings-1.0.17-2.fc13 ----------------------------- * Wed Dec 02 2009 Peter Robinson 1.0.17-1 - Update to 1.0.17 * Wed Dec 02 2009 Peter Robinson 1.0.17-2 - Drop upstreamed patch xapian-core-1.0.17-1.fc13 ------------------------- * Wed Dec 02 2009 Peter Robinson - 1.0.17-1 - Update to 1.0.17 xemacs-packages-extra-20090217-6.fc13 ------------------------------------- * Tue Dec 01 2009 Jerry James - 20090217-6 - The last ediff fix included more Emacs-specific code (bz 537531). - Don't package x-symbol fonts, which are only needed on Windows anyway. xmltooling-1.3.2-1.fc13 ----------------------- * Wed Dec 02 2009 Steve Traylen 1.3.2-1 - New upstream 1.3.2 xorg-x11-drv-ati-6.13.0-0.18.20091201git88a50a30d.fc13 ------------------------------------------------------ * Wed Dec 02 2009 Dave Airlie 6.13.0-0.17.20091201git88a50a30d - ums displayport + bump libdrm requires for new function needed * Wed Dec 02 2009 Dave Airlie 6.13.0-0.18.20091201git88a50a30d - add R600 RLC firmware for IRQ handling * Tue Dec 01 2009 Dave Airlie 6.13.0-0.16.20091201git88a50a30d - fixed up multi-op support for r600s * Fri Nov 27 2009 Dave Airlie 6.13.0-0.15.20091127gita8dbf7c23 - upstream snapshot with fix for resize under shadowfb, merged multi-op * Thu Nov 26 2009 Dave Airlie 6.13.0-0.14.20091125git8b28534bc - revert r600 multi-op for now seems to cause regression * Wed Nov 25 2009 Dave Airlie 6.13.0-0.13.20091125git8b28534bc - rebase to upstream with r600 speed ups and r100 fixes integrated. * Fri Nov 20 2009 Dave Airlie 6.13.0-0.12.20091119git437113124 - fix r100 Xv (partly inspired by 505152), rn50 small VRAM fixes. xorg-x11-drv-dummy-0.3.3-1.fc13 ------------------------------- * Tue Dec 01 2009 Adam Jackson 0.3.3-1 - dummy 0.3.3 xorg-x11-drv-wacom-0.10.2-1.fc13 -------------------------------- * Thu Dec 03 2009 Peter Hutterer 0.10.2-1 - wacom 0.10.2 yelp-2.28.0-2.fc13 ------------------ * Wed Dec 02 2009 Matthias Clasen - 2.28.0-2 - make mono dep more automatic Summary: Added Packages: 13 Removed Packages: 2 Modified Packages: 170 From skasal at redhat.com Thu Dec 3 16:29:39 2009 From: skasal at redhat.com (Stepan Kasal) Date: Thu, 3 Dec 2009 17:29:39 +0100 Subject: perl-5.10.1 update, modules rebuild Message-ID: <20091203162939.GA22689@camelia.ucw.cz> Hello, a big update of Perl in Fedora has just been kicked off. Small step for perl (5.10.0 -> 5.10.1) but big jump for Fedora: there will be significant changes in the packaging tied to this upgrade. Nonetheless, things are expected to just work; if not, contact me or file a bug. If you are interested, you can find more details below; otherwise, let me wish to enjoy perl-5.10.1. Two imporant changes are happening in Fedora at this opportunity: First, the @INC path will become much simpler. This change was first presented here http://article.gmane.org/gmane.linux.redhat.fedora.perl/9664 Second, "production" is going to be built. (Fedora 9--12 contains perl built with debugging support, which makes it slower. This was not intentional, perl's Configure script was being too smart.) Each of the changes breaks backward compatibility: Perl modules and applications built against libperl.so will no longer work after the change is fully implemented. To reflect this situation rpm-wise, the changes are tied to the version change: newly built packages will require perl(:MODULE_COMPAT_5.10.1), while the old ones require perl(:MODULE_COMPAT_5.10.0). To arrange for smooth transition, the first build(s) of perl 5.10.1 will contain backward compatibility aids so that it will still work in combination with old modules and libperl-linked packages. Consequently, this build will provide both perl(:MODULE_COMPAT_5.10.1) and perl(:MODULE_COMPAT_5.10.0). With this package in place, it will be possible to rebuild the dependent packages. When this rebuild will have been done, perl can be upgraded to a clean version, without the compatibility aids; that build will no longer provide perl(:MODULE_COMPAT_5.10.0). At this moment, we are at the begining of the rebuild, perl-5.10.1-101.fc13 is the build with compatibility aids. There is more than one way to break rawhide, Stepan Kasal From awilliam at redhat.com Thu Dec 3 16:35:51 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 03 Dec 2009 08:35:51 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> <1259830302.26397.15.camel@adam.local.net> Message-ID: <1259858151.26397.19.camel@adam.local.net> On Thu, 2009-12-03 at 08:20 -0500, Seth Vidal wrote: > >> We wouldn't be talking about removing the original GA set - just adding > >> updated pkgs into the path. So you'd still have the number of pkgs -just > >> all in one repo, that you have to download all of the metadata for all of > >> the more often, despite that 15K of them don't CHANGE. > > > > I don't think that was actually made clear in the initial proposal. I'd > > been assuming that the proposal was _exactly_ to remove the GA set. > > Usually, when a newer package shows up in any given repository, we don't > > keep the previous version of the package, do we? So I assumed the > > proposal was expecting that behaviour for the combined repository. > > >From a QA standpoint I'd think you'd want at least one known-installable > set of pkgs. Since everything after the original GA set is a giant > questionmark. > > Not to mention that removing all the old pkgs would more or less make > deltarpms very difficult. I'm not saying I support the proposal, I don't, I think it's a waste of effort for no benefit. I was just clarifying the initial characterization. Actually I think the initial proposer _was_ expecting to remove initial packages when updates become available, because they keep saying stuff like 'only historians are interested in the GA packages'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Thu Dec 3 16:54:44 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 03 Dec 2009 08:54:44 -0800 Subject: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message) In-Reply-To: <20091203134059.1795ebbe@leela> References: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> <20091203134059.1795ebbe@leela> Message-ID: <1259859284.26397.25.camel@adam.local.net> On Thu, 2009-12-03 at 13:40 +0100, Michal Schmidt wrote: > > But it appears in bugzilla as a "low priority" "medium severity" problem. > > "Priority" has no standardized meaning. Most maintainers do not use > this field at all. Policy on this is: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity as Michal said, there is no official definition of Priority, and the only group entitled to set it is the maintainer(s) of the affected component; maintainers can choose to use it however they like, or not at all. Most maintainers don't use it at present. Severity can be set by initial reporter, triager, or maintainer. It didn't get set when you reported it because abrt doesn't set this field. It hasn't been set by a triager yet, because it hasn't been triaged (thunderbird isn't actually on our priority triage components list; I don't think anyone's working on triaging tbird bugs at present). And it hasn't been set by the maintainer because they haven't looked at it yet (and they may not really care about severity settings either). Also, as Michal pointed out, you didn't provide any explanation in the report of when the crash actually happened, or explain that it crashes every time you send a mail. Even if a triager were to look at it, it would be impossible to judge a severity based on the information you provided in the report. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From pjones at redhat.com Thu Dec 3 16:56:09 2009 From: pjones at redhat.com (Peter Jones) Date: Thu, 03 Dec 2009 11:56:09 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B174B80.8070309@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> Message-ID: <4B17EDA9.6090307@redhat.com> On 12/03/2009 12:24 AM, Ralf Corsepius wrote: > On 12/02/2009 06:40 PM, Jesse Keating wrote: >> People doing network installs can either add the updates repo to their >> kickstart, or check the box in the anaconda UI, so that the updates >> repos are considered at install time. No download of duplicate data. > Yes, for people who are doing "full featured networked installs" w/ > custom kickstart files. I've never met such a person. Really? This very much seems to me like it's a vast majority of kickstarts that happen. -- Peter Power corrupts. Absolute power is kind of neat. -- John Lehman, Secretary of the Navy, 1981-1987 From pjones at redhat.com Thu Dec 3 17:02:08 2009 From: pjones at redhat.com (Peter Jones) Date: Thu, 03 Dec 2009 12:02:08 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> <1259830302.26397.15.camel@adam.local.net> Message-ID: <4B17EF10.9000905@redhat.com> On 12/03/2009 08:20 AM, Seth Vidal wrote: > > > On Thu, 3 Dec 2009, Adam Williamson wrote: > >> On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: >> >>> We wouldn't be talking about removing the original GA set - just adding >>> updated pkgs into the path. So you'd still have the number of pkgs -just >>> all in one repo, that you have to download all of the metadata for >>> all of >>> the more often, despite that 15K of them don't CHANGE. >> >> I don't think that was actually made clear in the initial proposal. I'd >> been assuming that the proposal was _exactly_ to remove the GA set. >> Usually, when a newer package shows up in any given repository, we don't >> keep the previous version of the package, do we? So I assumed the >> proposal was expecting that behaviour for the combined repository. > >> From a QA standpoint I'd think you'd want at least one known-installable > set of pkgs. Since everything after the original GA set is a giant > questionmark. > > Not to mention that removing all the old pkgs would more or less make > deltarpms very difficult. Well, if we're talking about removing them from Fedora/ but leaving them in Everything/ (am I understanding the current form of the proposal correctly?), then it's not really significantly more difficult, but it is one more process that needs modification in order to enact such a plan. -- Peter If the facts don't fit the theory, change the facts. -- Einstein From pjones at redhat.com Thu Dec 3 17:06:06 2009 From: pjones at redhat.com (Peter Jones) Date: Thu, 03 Dec 2009 12:06:06 -0500 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B16EE59.10502@redhat.com> Message-ID: <4B17EFFE.4060602@redhat.com> On 12/02/2009 09:12 PM, Kevin Kofler wrote: > Seth Vidal wrote: >> If you're looking for perfect division, sure - but the reality is this: >> >> 19K items in a single dir and ext3 and nfs and many many other things crap >> themselves returning that list. >> >> If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for >> producing the same list of files. > > The problem is, a few of those starting letters still correspond to A LOT of > packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of > stuff (especially Perl and Python). And adding python3-* (and perl6-*, or > are we going to use the rakudo-* namespace there?) won't make it any less. Even still, separating "p" out to a subdirectory means that subdirectory has an order of magnitude fewer files than the previous way. That's a really big difference. -- Peter If the facts don't fit the theory, change the facts. -- Einstein From lsof at nodata.co.uk Thu Dec 3 17:05:58 2009 From: lsof at nodata.co.uk (nodata) Date: Thu, 03 Dec 2009 18:05:58 +0100 Subject: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message) In-Reply-To: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> References: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> Message-ID: <4B17EFF6.7030006@nodata.co.uk> Am 2009-12-03 13:19, schrieb casimiro barreto: > Since November 29 I detected that thunderbird is crashing whenever I try > to send e-mail. Bugzilla report filled (I see that several other users > have had the same problem & also reported). But it appears in bugzilla > as a "low priority" "medium severity" problem. > > Is it possible to retrofit thunderbird until a fix is devised? > > Best regards, > > CdAB > Try running thunderbird in safe mode. From jfontain at free.fr Thu Dec 3 17:23:21 2009 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 03 Dec 2009 18:23:21 +0100 Subject: selinux disabled: what selinux related rpms can I safely remove? Message-ID: <4B17F409.2080103@free.fr> Thanks, jlf From mschwendt at gmail.com Thu Dec 3 18:05:21 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 3 Dec 2009 19:05:21 +0100 Subject: selinux disabled: what selinux related rpms can I safely remove? In-Reply-To: <4B17F409.2080103@free.fr> References: <4B17F409.2080103@free.fr> Message-ID: <20091203190521.168ac52c@gmail.com> On Thu, 03 Dec 2009 18:23:21 +0100, Jean-Luc wrote: > Thanks, > jlf > At least: rpm -e selinux-policy policycoreutils-gui selinux-policy-targeted rpm -e checkpolicy policycoreutils policycoreutils-python setroubleshoot-server setroubleshoot-plugins Drop any that aren't present (or else rpm -e fails). From mcepl at redhat.com Thu Dec 3 18:15:23 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Thu, 03 Dec 2009 19:15:23 +0100 Subject: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message) In-Reply-To: <4B17EFF6.7030006@nodata.co.uk> References: <578ed5910912030419k1adc56c7y2a0385843c979037@mail.gmail.com> <4B17EFF6.7030006@nodata.co.uk> Message-ID: Dne 3.12.2009 18:05, nodata napsal(a): > Try running thunderbird in safe mode. Also upgrade your engimail (be it packaged or form the a.m.o) to at least 1.0. Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC And religious texts are a bit like software standards, the interpretation is always the tricky and complicated bit. -- Alan Cox From xose.vazquez at gmail.com Thu Dec 3 18:30:18 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Thu, 03 Dec 2009 19:30:18 +0100 Subject: selinux disabled: what selinux related rpms can I safely remove? Message-ID: <4B1803BA.2000407@gmail.com> hi, fast and easy, also disable audit: put SELINUX=disabled in /etc/sysconfig/selinux run chkconfig auditd off add to the kernel line selinux=0 audit=0 in /etc/grub.conf -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.? From tgl at redhat.com Thu Dec 3 18:49:09 2009 From: tgl at redhat.com (Tom Lane) Date: Thu, 03 Dec 2009 13:49:09 -0500 Subject: libtiff 3.9.2 pushed to rawhide Message-ID: <12034.1259866149@sss.pgh.pa.us> I have updated libtiff from 3.8.2 to 3.9.2. This is supposed to be an ABI-compatible update, so in theory nobody will notice. If you notice, please let me know. I plan to push this back into F-12 in a week or so if no problems are reported. There is a packaging change: the command-line tools such as tiff2pdf have been split into a separate subpackage libtiff-tools. regards, tom lane From jfontain at free.fr Thu Dec 3 19:29:27 2009 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 03 Dec 2009 20:29:27 +0100 Subject: selinux disabled: what selinux related rpms can I safely remove? In-Reply-To: <20091203190521.168ac52c@gmail.com> References: <4B17F409.2080103@free.fr> <20091203190521.168ac52c@gmail.com> Message-ID: <4B181197.1060408@free.fr> On 12/03/2009 07:05 PM, Michael Schwendt wrote: > On Thu, 03 Dec 2009 18:23:21 +0100, Jean-Luc wrote: > > >> Thanks, >> jlf >> >> > At least: > > rpm -e selinux-policy policycoreutils-gui selinux-policy-targeted > rpm -e checkpolicy policycoreutils policycoreutils-python setroubleshoot-server setroubleshoot-plugins > > Drop any that aren't present (or else rpm -e fails). > Thanks, jlf From notting at redhat.com Thu Dec 3 21:52:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Dec 2009 16:52:36 -0500 Subject: Plan for tomorrow's (20091203) FESCo meeting Message-ID: <20091203215235.GB8724@nostromo.devel.redhat.com> Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. This meeting may be cancelled if we cannot reach quorum. FESCo members who cannot make it are encouraged to vote or comment in the tickets. 274 Linville requests "provenpackager" membership 281 Approve Fedora 13 Schedule Features: 272 Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA 278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname 279 User Account Dialog - https://fedoraproject.org/wiki/Features/UserAccountDialog 286 Copy/Paste Just Works - https://fedoraproject.org/wiki/Features/CopyPasteJustWorks 287 Upstart 0.6.x - https://fedoraproject.org/wiki/Features/Upstart0.6.0 288 NetBeans 6.8 - https://fedoraproject.org/wiki/Features/NetBeans_6.8 289 RPM 4.8 - https://fedoraproject.org/wiki/Features/RPM4.8 290 Rollback with BTRFS - https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. Bill From skvidal at fedoraproject.org Thu Dec 3 21:54:00 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 3 Dec 2009 16:54:00 -0500 (EST) Subject: Plan for tomorrow's (20091203) FESCo meeting In-Reply-To: <20091203215235.GB8724@nostromo.devel.redhat.com> References: <20091203215235.GB8724@nostromo.devel.redhat.com> Message-ID: On Thu, 3 Dec 2009, Bill Nottingham wrote: > Following is the list of topics that will be discussed in the FESCo > meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on > irc.freenode.net. > > This meeting may be cancelled if we cannot reach quorum. FESCo members > who cannot make it are encouraged to vote or comment in the tickets. I won't be there - I'll be in the air, most likely. -sv From notting at redhat.com Thu Dec 3 21:59:38 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Dec 2009 16:59:38 -0500 Subject: Plan for tomorrow's (20091204) FESCo meeting In-Reply-To: <20091203215235.GB8724@nostromo.devel.redhat.com> Message-ID: <20091203215938.GA9786@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Following is the list of topics that will be discussed in the FESCo > meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on > irc.freenode.net. Despite what the original subject said, that should be tomorrow, December *4th* at 17:0UTC. Bill From inode0 at gmail.com Thu Dec 3 23:46:52 2009 From: inode0 at gmail.com (inode0) Date: Thu, 3 Dec 2009 17:46:52 -0600 Subject: Election Town Halls Message-ID: Today we completed the 6 town halls for the Fedora Project Board, FESCo, and FAmSCo elections. If you weren't able to attend these you can access logs from each meeting from the main election page on the wiki. http://fedoraproject.org/wiki/Elections I'd like to thank all the candidates who chose to participate in one or more of the town halls. Without their cooperation our moderators would have been very lonely. I'd like to also thank Yaakov Nemoy, Toshio Kuratomi, Kevin Fenzi, Lars Delhage, Karsten Wade, and Paul Mellors for volunteering to do the sometimes exciting and sometimes not so exciting work as moderators of these events. Remember to vote! The schedule for voting has been slightly revised as described on the wiki but will begin on December 5 and run through at least December 15. Vote early though to help us minimize any impact our other activities might have. John From behdad at behdad.org Fri Dec 4 00:13:42 2009 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 03 Dec 2009 19:13:42 -0500 Subject: FreeType patented bytecode interpreter now in rawhide Message-ID: <4B185436.4090802@behdad.org> Hi, Since the patents covering the TrueType bytecode interpreter expired at the end of October, I've now built FreeType in rawhide with that part of code enabled. Note that the subpixel stuff remains disabled as it was. behdad From pbrobinson at gmail.com Fri Dec 4 01:05:07 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 4 Dec 2009 01:05:07 +0000 Subject: Head-up - new firefox in rawhide In-Reply-To: <4B0655AA.5080706@redhat.com> References: <4B03E564.4020409@redhat.com> <5256d0b0911200021g1ae39375i916da03c76ccbd8d@mail.gmail.com> <4B0655AA.5080706@redhat.com> Message-ID: <5256d0b0912031705yc0ec219x3ea4579ad0d61bff@mail.gmail.com> On Fri, Nov 20, 2009 at 8:39 AM, Martin Stransky wrote: > On 11/20/2009 09:21 AM, Peter Robinson wrote: >> >> 2009/11/18 Martin Stransky: >>> >>> Hi, >>> >>> a new firefox (3.6 beta 2) just hit rawhide (a.k.a f13). There are some >>> changes which affect everyone who builds with xulrunner-devel-unstable >>> package. >>> >>> Mozilla decided to merge all include directories to one (mozbz#398573) >>> and >>> stop shipping stable/unstable packages. So all headers/libraries are >>> merged >>> to one big xulrunner-devel package (with respective pkgconfig files) and >>> xulrunner-devel-unstable has been removed. >> >> Is this the same with the -python and -python-devel pacakges? > > I'm not sure what's going on with python interface but it looks removed from > 3.6. I'm still investigating it... Having a quick google around the mozilla.org site I found the following mercurial repo [1] so it looks like its been split out to a separate project but I'm not 100% sure. Its used by hulahop/sugar-browse so it would be useful to add back in some form or another but I has issues building it but then I know very little about the mozilla build system. Cheers, Peter [1] http://hg.mozilla.org/pyxpcom From hun at n-dimensional.de Fri Dec 4 01:46:48 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Fri, 4 Dec 2009 02:46:48 +0100 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <20091202221200.2425bc84@n-dimensional.de> References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> <1259785220.3950.1.camel@localhost> <20091202221200.2425bc84@n-dimensional.de> Message-ID: <20091204024648.7a0a48ba@n-dimensional.de> On Wed, 2 Dec 2009 22:12:00 +0100 Hans Ulrich Niedermann wrote: > On Thu, 03 Dec 2009 06:20:20 +1000 > Dave Airlie wrote: > > > The big issue is with KMS on using radeonhd is like shooting > > yourself in the face. Either we need to patch radeonhd in Fedora to > > not start with KMS enabled or remove it from the distro. > > I am working on such a patch to radeonhd right now. The patch has been finished and has been tested on my system. Packages with the patch have been built and are both in rawhide and on their way towards updates-testing/ and updates/ for F11 and F12 (xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc*). -- Hans Ulrich Niedermann From pmatilai at laiskiainen.org Fri Dec 4 08:57:47 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 4 Dec 2009 10:57:47 +0200 (EET) Subject: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs Message-ID: Grepping through spec files from CVS devel/ shows there are a handful of package still using %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} macros. These were considered "backwards compatibility stuff" in 1998 (yes, eleven years ago) already, please change them to use the %{version} and %{release} macros instead. The packages using these ancient macros are: - kernel - kernel-xen-2.6 (dead package?) - glibc32, glibc64 (dead packages?) - fmt-ptrn - libunwind Rpm >= 4.8.x removes the support for the ancient %{PACKAGE_*} macros so packages still using them will fail to build with it. - Panu - From itamar at ispbrasil.com.br Fri Dec 4 09:04:12 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Fri, 4 Dec 2009 07:04:12 -0200 Subject: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 6:57 AM, Panu Matilainen wrote: > > Grepping through spec files from CVS devel/ shows there are a handful of > package still using %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} macros. These > were considered "backwards compatibility stuff" in 1998 (yes, eleven years > ago) already, please change them to use the %{version} and %{release} macros > instead. > > The packages using these ancient macros are: > - kernel > - kernel-xen-2.6 (dead package?) yes > - glibc32, glibc64 (dead packages?) yes > - fmt-ptrn > - libunwind > > Rpm >= 4.8.x removes the support for the ancient %{PACKAGE_*} macros so > packages still using them will fail to build with it. > > ? ? ? ?- Panu - > I think a proven packager or someone with chuck norris power can fix the other's packager's -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From jan.kratochvil at redhat.com Fri Dec 4 09:48:11 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Dec 2009 10:48:11 +0100 Subject: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs In-Reply-To: References: Message-ID: <20091204094811.GA25541@host0.dyn.jankratochvil.net> On Fri, 04 Dec 2009 09:57:47 +0100, Panu Matilainen wrote: > handful of package still using %{PACKAGE_VERSION} and > %{PACKAGE_RELEASE} macros. ... > - libunwind Fixed: libunwind-0.99-0.13.20090430betagit4b8404d1.fc13 Jan From jwboyer at gmail.com Fri Dec 4 11:14:39 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 4 Dec 2009 06:14:39 -0500 Subject: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs In-Reply-To: References: Message-ID: <20091204111439.GQ14279@hansolo.jdub.homelinux.org> On Fri, Dec 04, 2009 at 07:04:12AM -0200, Itamar Reis Peixoto wrote: >> - glibc32, glibc64 (dead packages?) >yes No. They are needed in the build system. They just havent been updated since FC6 or so. josh From dpierce at redhat.com Fri Dec 4 12:35:48 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 4 Dec 2009 07:35:48 -0500 Subject: Orphaning some packages... Message-ID: <20091204123548.GD28789@mcpierce-desktop.usersys.redhat.com> I'd like to turn over the following packages to someone else to maintain since I have no time or interest in keeping up with them going forward: * rubygem-activeldap -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mcepl at redhat.com Fri Dec 4 12:50:58 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Fri, 04 Dec 2009 13:50:58 +0100 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: <4B185436.4090802@behdad.org> References: <4B185436.4090802@behdad.org> Message-ID: Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): > Since the patents covering the TrueType bytecode interpreter expired at > the end of October, I've now built FreeType in rawhide with that part of > code enabled. can we hope for the update in F12 as well, please? > Note that the subpixel stuff remains disabled as it was. What does this exactly mean? If I have freetype-freeworld installed can I get rid of it now (well, when this comes to F12)? Will we have also cairo and pango (whichever is relevant) upgraded to use it? Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He can compress the most words into the smallest idea of any man I know. -- Abraham Lincoln From a.badger at gmail.com Fri Dec 4 13:39:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 4 Dec 2009 05:39:24 -0800 Subject: Orphaning gnome-common Message-ID: <20091204133924.GE2712@clingman.lan> This is a heads up that I'm going to orphan gnome-common. I don't do any gtk programming anymore so it doesn't make sense for me to keep this package. mclasen has done several of the recently needed updates to this package; if he and the desktop team would like to take it over let me know; I'll do the packagedb magic to hand it over to them. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Dec 4 13:49:43 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 4 Dec 2009 14:49:43 +0100 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: References: <4B185436.4090802@behdad.org> Message-ID: <8ff5cb21a6af08250c674f0086874bb3.squirrel@arekh.dyndns.org> Le Ven 4 d?cembre 2009 13:50, Mat?j Cepl a ?crit : > > Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): >> Since the patents covering the TrueType bytecode interpreter expired at >> the end of October, I've now built FreeType in rawhide with that part of >> code enabled. > > can we hope for the update in F12 as well, please? Given how any font rendering changes seems to degrade font rendering for some users, I'd very much prefer it went through a full release testing cycle before hitting unsuspecting users. -- Nicolas Mailhot From mclasen at redhat.com Fri Dec 4 14:05:00 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 04 Dec 2009 09:05:00 -0500 Subject: Orphaning gnome-common In-Reply-To: <20091204133924.GE2712@clingman.lan> References: <20091204133924.GE2712@clingman.lan> Message-ID: <1259935500.25800.3.camel@planemask> On Fri, 2009-12-04 at 05:39 -0800, Toshio Kuratomi wrote: > This is a heads up that I'm going to orphan gnome-common. I don't do any > gtk programming anymore so it doesn't make sense for me to keep this > package. mclasen has done several of the recently needed updates to this > package; if he and the desktop team would like to take it over let me know; > I'll do the packagedb magic to hand it over to them. I'll find someone to own it, probably not before fudcon though... From ilyes.gouta at gmail.com Fri Dec 4 15:55:10 2009 From: ilyes.gouta at gmail.com (Ilyes Gouta) Date: Fri, 4 Dec 2009 16:55:10 +0100 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: <8ff5cb21a6af08250c674f0086874bb3.squirrel@arekh.dyndns.org> References: <4B185436.4090802@behdad.org> <8ff5cb21a6af08250c674f0086874bb3.squirrel@arekh.dyndns.org> Message-ID: <234fa2210912040755p38cc10f3g2c6b55e9a9e59508@mail.gmail.com> Finally! It was like a non-ending movie through all these years, having such one essential/basic feature disabled. An update for F12, whenever it gets ready, would be really welcome! > Given how any font rendering changes seems to degrade font rendering for some The TrueType bytecode interpreter really makes the difference. -Ilyes On Fri, Dec 4, 2009 at 2:49 PM, Nicolas Mailhot wrote: > > > Le Ven 4 d?cembre 2009 13:50, Mat?j Cepl a ?crit : > > > > Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): > >> Since the patents covering the TrueType bytecode interpreter expired at > >> the end of October, I've now built FreeType in rawhide with that part of > >> code enabled. > > > > can we hope for the update in F12 as well, please? > > Given how any font rendering changes seems to degrade font rendering for > some > users, I'd very much prefer it went through a full release testing cycle > before hitting unsuspecting users. > > -- > Nicolas Mailhot > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Dec 4 16:21:22 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Dec 2009 11:21:22 -0500 Subject: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?) In-Reply-To: <20091204024648.7a0a48ba@n-dimensional.de> References: <20091201153551.GG26255@nostromo.devel.redhat.com> <20091201204326.GB28720@nostromo.devel.redhat.com> <1259785220.3950.1.camel@localhost> <20091202221200.2425bc84@n-dimensional.de> <20091204024648.7a0a48ba@n-dimensional.de> Message-ID: <20091204162121.GF18762@nostromo.devel.redhat.com> Hans Ulrich Niedermann (hun at n-dimensional.de) said: > > > The big issue is with KMS on using radeonhd is like shooting > > > yourself in the face. Either we need to patch radeonhd in Fedora to > > > not start with KMS enabled or remove it from the distro. > > > > I am working on such a patch to radeonhd right now. > > The patch has been finished and has been tested on my system. > > Packages with the patch have been built and are both in rawhide and on > their way towards updates-testing/ and updates/ for F11 and F12 > (xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc*). Cool. Objection withdrawn. :) Bill From kevin.kofler at chello.at Fri Dec 4 16:51:25 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 04 Dec 2009 17:51:25 +0100 Subject: FreeType patented bytecode interpreter now in rawhide References: <4B185436.4090802@behdad.org> Message-ID: Mat?j Cepl wrote: > can we hope for the update in F12 as well, please? Well, that would change the looks of our default DejaVu fonts a lot. (freetype-freeworld currently disables the BCI for the DejaVu family by default for that reason, which has always been a controversial move, I'll of course stop doing that from F13 on.) I'm not convinced this is a good idea to ship as an update. >> Note that the subpixel stuff remains disabled as it was. > > What does this exactly mean? If I have freetype-freeworld installed can > I get rid of it now (well, when this comes to F12)? If you need subpixel antialiasing, no. I will continue to build freetype- freeworld packages for the subpixel stuff. > Will we have also cairo and pango (whichever is relevant) upgraded to use > it? "It" as in subpixel rendering? There have been patches to Cairo to use the FreeType subpixel filters, they even remove some probably patent-encumbered code (dumb subpixel filters) from Cairo itself, but still they haven't been accepted yet. :-( As FreeType always provides the relevant APIs, just implemented as dummies which always return an error, it's perfectly possible to make the decision whether to use freetype-freeworld's subpixel filters at runtime (e.g. Qt 4 does that). As for the BCI, it should need no special support from Cairo nor Pango. Kevin Kofler From kevin.kofler at chello.at Fri Dec 4 16:56:02 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 04 Dec 2009 17:56:02 +0100 Subject: FreeType patented bytecode interpreter now in rawhide References: <4B185436.4090802@behdad.org> Message-ID: Behdad Esfahbod wrote: > Since the patents covering the TrueType bytecode interpreter expired at > the end of October, I've now built FreeType in rawhide with that part of > code enabled. IMHO, if we want to ship this by default, we really need to fix FreeType for the case where the font doesn't provide hinting bytecode. AFAICT, currently, in that case, if FreeType is built with the BCI enabled, it won't do any hinting at all. See e.g. the CJK characters in the screenshot by Martin Sourada at: http://2.bp.blogspot.com/_lh41g82r7rk/SuWk7rqgaJI/AAAAAAAAAQ8/AfWQU9yAHu8/s1600-h/mark-the-difference.png (the first line is no antialiasing, no hinting, the second one is antialiasing only, the third one is antialiasing+hinting and the last one is antialiasing+hinting with forced autohinter) from: http://mso-chronicles.blogspot.com/2009/10/mark-difference-ugly-fonts-in-fedora.html It should fall back to the autohinter when the font does not provide hinting bytecode. Kevin Kofler From notting at redhat.com Fri Dec 4 18:36:44 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Dec 2009 13:36:44 -0500 Subject: FESCo meeting summary for 2009-12-04 Message-ID: <20091204183643.GA22132@nostromo.devel.redhat.com> ======================================= #fedora-meeting: FESCo meeting 20091204 ======================================= Meeting started by notting at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-12-04/fesco.2009-12-04-17.00.log.html . Meeting summary --------------- * ACTION: notting will close out ticket 274 (notting, 17:04:23) * F13 schedule (notting, 17:04:38) * AGREED: F13 schedule as proposed is accepted. (notting, 17:10:39) * Feature Intellij IDEA (notting, 17:11:51) * LINK: http://www.jetbrains.com/idea/nextversion/editions_comparison_matrix.html (Kevin_Kofler, 17:15:54) * ACTION: this was already accepted at the 2009-11-20 meeting (notting, 17:20:03) * Feature - Better Hostname (notting, 17:22:47) * ACTION: discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page (notting, 17:33:21) * Feature - User Account Dialog (notting, 17:33:35) * ACTION: User Account Dialog feature has been accepted for F13 (notting, 17:38:37) * Feature - Copy/Paste Just Works (notting, 17:38:56) * ACTION: CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. (notting, 17:44:30) * ACTION: correction: Fedora 13 (notting, 17:45:18) * Feature - Upstart 0.6.x (notting, 17:45:49) * ACTION: Upstart 0.6.x has been accepted as a Fedora 13 feature (notting, 17:50:08) * Feature - NetBeans 6.8 (notting, 17:50:24) * ACTION: NetBeans 6.8 feature has been approved for Fedora 13 (notting, 17:54:30) * Feature - RPM 4.8 (notting, 17:54:45) * ACTION: RPM 4.8 has been accepted as a Fedora 13 feature (notting, 17:57:58) * Feature - Rollback with BTRFS (notting, 17:58:11) * AGREED: Rollback with BTRFS has been approved as a F13 feature (notting, 18:17:54) * Open floor (notting, 18:18:43) * FPC report (notting, 18:20:11) * AGREED: pkgconfig guideline change approved (notting, 18:22:59) * Emacs Packaging (notting, 18:23:09) * AGREED: Emacs guideline change approved (notting, 18:24:57) * PHP guidelines revised (notting, 18:25:30) * AGREED: PHP guideline revision approved. (notting, 18:29:17) * Open floor (notting, 18:29:25) Meeting ended at 18:33:36 UTC. Action Items ------------ * notting will close out ticket 274 * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature Action Items, by person ----------------------- * notting * notting will close out ticket 274 * sk * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * **UNASSIGNED** * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature People Present (lines said) --------------------------- * notting (118) * Kevin_Kofler (60) * nirik (56) * dwmw2 (38) * cjb (19) * josef (17) * sharkcz (17) * zodbot (15) * tibbs|h (12) * sadmac (3) * mjg59 (1) * miniperl (1) * skvidal (0) * j-rod (0) * sk (0) * jds2001 (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From dcbw at redhat.com Fri Dec 4 18:55:46 2009 From: dcbw at redhat.com (Dan Williams) Date: Fri, 04 Dec 2009 10:55:46 -0800 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <20091202215208.GA30748@nostromo.devel.redhat.com> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <20091202215208.GA30748@nostromo.devel.redhat.com> Message-ID: <1259952946.27022.3.camel@localhost.localdomain> On Wed, 2009-12-02 at 16:52 -0500, Bill Nottingham wrote: > Dan Williams (dcbw at redhat.com) said: > > > ONBOOT=yes > > > BOOTPROTO=dhcp > > > TYPE=Wireless > > > NM_CONTROLLED=yes > > > USERCTL=yes > > > PEERDNS=yes > > > IPV6INIT=no > > > MODE=Auto > > > > ^^^^ This is the problem. "Auto" is not a valid mode. > > It's a valid mode according to the iwconfig man page. I have no idea > what cards actually support it. Oh, probably none. I'll go fix ifcfg-rh to alias "Auto" to infrastructure mode. Dan From jkeating at redhat.com Thu Dec 3 06:16:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 22:16:57 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B1751F0.3040206@freenet.de> References: <4B167C22.3000504@redhat.com> <1259776139.12203.80.camel@localhost.localdomain> <4B174C77.2050702@freenet.de> <4B1751F0.3040206@freenet.de> Message-ID: <1259821017.24679.0.camel@localhost.localdomain> On Thu, 2009-12-03 at 06:51 +0100, Ralf Corsepius wrote: > > We wouldn't be talking about removing the original GA set - just adding > > updated pkgs into the path. > > Woa!!! With all due respect, but this would seem an stupid and silly > plan to me. The only way not to do that would be to maintain yet another directory of packages that matches the GA set, for GPL compliance. Now we're just getting silly. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Dec 3 06:22:39 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 02 Dec 2009 22:22:39 -0800 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B174B80.8070309@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> Message-ID: <1259821359.24679.5.camel@localhost.localdomain> On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: > > People doing network installs can either add the updates repo to their > > kickstart, or check the box in the anaconda UI, so that the updates > > repos are considered at install time. No download of duplicate data. > Yes, for people who are doing "full featured networked installs" w/ > custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. > > > In fact, having separate repos would likely cost less bandwidth. If we > > only had one combined repo, there would be many duplicate packages, > Where? Unlike now, where you have each package twice (in Everything and > "updates"), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, which as noted in other parts of this thread gets complicated with GPL compliance. > > It would help people like me, who are locally reusing downloaded > packages in a networked environment, instead of letting each machine > accesses the original repos directly. Surely a caching proxy server doesn't care what folder a file comes from, it'll cache it. Whether the new file shows up in Everything/ or the new file shows up in updates/ shouldn't matter. > > > especially if we went the route of having updates-testing mixed in and > > only marked by some update tag. > Updates-testing is an add-on repo to "Everything+updates". > > A merged new Everything would not change anything wrt. > "updates-testing". The only difference would be packages being pushed to > "Everything" instead of "updates". > > > We'd have to keep sets of what's in > > updates-testing, updates, and the GA release set, and all of that would > > be in one repodata set. Everybody doing a network install, whether they > > wanted updates, updates-testing, or not would have to download and > > consume that larger repodata, introducing a higher cost for them. > Your concern is the bigger repodata? > > Reality check: > # ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2 > updates/11/x86_64/repodata/*.sqlite.bz2 > > 16M > releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2 > 11M > releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2 > 5.8M > releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2 > > 9.0M > updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2 > 6.0M > updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2 > 3.2M > updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2 > > => An estimate for the increase in downloaded files's sizes you are > talking about is ca. factor 2, from 18.2M (current "updates") > to 32.8M+ (current "Everything"+"newly introduced packages) > > > Whether this increase in download-size is "significant" is up to the > beholder. For me, it gets lost in the noise of accessing a "good" or a > "bad" connection to a mirror and in the time required to download > packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Fri Dec 4 19:39:11 2009 From: dcbw at redhat.com (Dan Williams) Date: Fri, 04 Dec 2009 11:39:11 -0800 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <1259952946.27022.3.camel@localhost.localdomain> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <20091202215208.GA30748@nostromo.devel.redhat.com> <1259952946.27022.3.camel@localhost.localdomain> Message-ID: <1259955551.27022.7.camel@localhost.localdomain> On Fri, 2009-12-04 at 10:55 -0800, Dan Williams wrote: > On Wed, 2009-12-02 at 16:52 -0500, Bill Nottingham wrote: > > Dan Williams (dcbw at redhat.com) said: > > > > ONBOOT=yes > > > > BOOTPROTO=dhcp > > > > TYPE=Wireless > > > > NM_CONTROLLED=yes > > > > USERCTL=yes > > > > PEERDNS=yes > > > > IPV6INIT=no > > > > MODE=Auto > > > > > > ^^^^ This is the problem. "Auto" is not a valid mode. > > > > It's a valid mode according to the iwconfig man page. I have no idea > > what cards actually support it. > > Oh, probably none. I'll go fix ifcfg-rh to alias "Auto" to > infrastructure mode. 96a61a9909c9442aa5f1c14d89dbd3356d4715f1 (master) 090eeaff16c77f4db4454de39d6d4e76d5390443 (0.7.x) Dan From notting at redhat.com Fri Dec 4 21:10:34 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Dec 2009 16:10:34 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you Message-ID: <20091204211034.GB27613@nostromo.devel.redhat.com> https://fedoraproject.org/wiki/Features/Upstart0.6.0 was approved at today's FESCo meeting. We hope to land this in the next week or so. What this means for you (for very specific values of you): If you own any of the following packages, you have upstart job files that will need modified for any needed format changes, and the new location. * vpnc rjones * ConsoleKit mccann * clamav ensc * dhcp-forwarder ensc * hdapsd ttorcz * ip-sentinel ensc * milter-greylist ensc * olpc-utils pbrobinson * tor ensc We're willing to do the legwork for you, or you can do the update yourself once we land 0.6.x; give us a reply with which you'd prefer. See the feature page for more details on the changes required. What this means for you (for very general values of you): Once it lands, it's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. We can investigate adding some compat code to ease this, if people would really prefer. Once you reboot, things should work pretty much the same. Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Questions? Comments? Bill From notting at redhat.com Fri Dec 4 21:14:00 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Dec 2009 16:14:00 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <20091204211359.GC27613@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Obvious FAQ: > > Q: Should we port our SysV scripts to native upstart scripts? > > A: No, not at this time. Q: I'd like to play with it before it lands. A: There's a repo at http://notting.fedorapeople.org/upstart0.6/. You can also check the new upstart package out of devel/ CVS, and the initscripts changes out of the upstart-0.6.0-branch in initscripts git. Bill From mlichvar at redhat.com Fri Dec 4 21:39:42 2009 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 4 Dec 2009 22:39:42 +0100 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <20091204213942.GD19016@localhost> On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > https://fedoraproject.org/wiki/Features/Upstart0.6.0 The features highlight list has: Communication with the init daemon over D-Bus. > Questions? Comments? Does this mean that running dbus will be required to reboot/shutdown the system? -- Miroslav Lichvar From notting at redhat.com Fri Dec 4 21:45:10 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Dec 2009 16:45:10 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204213942.GD19016@localhost> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> Message-ID: <20091204214509.GA29249@nostromo.devel.redhat.com> Miroslav Lichvar (mlichvar at redhat.com) said: > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > The features highlight list has: > Communication with the init daemon over D-Bus. > > > Questions? Comments? > > Does this mean that running dbus will be required to reboot/shutdown > the system? No. The init daemon speaks the dbus protocol, and can be communicated with over the system daemon. But it can also be talked to directly. Bill From ngompa13 at gmail.com Fri Dec 4 22:05:30 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Fri, 4 Dec 2009 16:05:30 -0600 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204214509.GA29249@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> <20091204214509.GA29249@nostromo.devel.redhat.com> Message-ID: <8278b1b0912041405y594a511cr11fb0b62b78babba@mail.gmail.com> On Fri, Dec 4, 2009 at 3:45 PM, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > > > The features highlight list has: > > Communication with the init daemon over D-Bus. > > > > > Questions? Comments? > > > > Does this mean that running dbus will be required to reboot/shutdown > > the system? > > No. The init daemon speaks the dbus protocol, and can be communicated > with over the system daemon. But it can also be talked to directly. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Why aren't the sysVinit scripts being ported over to native upstart scripts? I thought the reason why upstart was adopted was to be able to utilize the benefits of native upstart scripts (event based daemon handling, etc.)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From che666 at gmail.com Fri Dec 4 22:12:13 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 4 Dec 2009 23:12:13 +0100 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <8278b1b0912041405y594a511cr11fb0b62b78babba@mail.gmail.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> <20091204214509.GA29249@nostromo.devel.redhat.com> <8278b1b0912041405y594a511cr11fb0b62b78babba@mail.gmail.com> Message-ID: > Why aren't the sysVinit scripts being ported over to native upstart scripts? > I thought the reason why upstart was adopted was to be able to utilize the > benefits of native upstart scripts (event based daemon handling, etc.)? No one is holding you back from starting to convert them now, but the format is most probably going to change again till the 1.0 release. Happy porting to you. ;) kind regards, Rudolf Kastl > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From james at fedoraproject.org Fri Dec 4 22:39:34 2009 From: james at fedoraproject.org (James Antill) Date: Fri, 04 Dec 2009 17:39:34 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204214509.GA29249@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> <20091204214509.GA29249@nostromo.devel.redhat.com> Message-ID: <1259966374.15022.5.camel@code.and.org> On Fri, 2009-12-04 at 16:45 -0500, Bill Nottingham wrote: > Miroslav Lichvar (mlichvar at redhat.com) said: > > On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > > > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > > > The features highlight list has: > > Communication with the init daemon over D-Bus. > > > > > Questions? Comments? > > > > Does this mean that running dbus will be required to reboot/shutdown > > the system? > > No. The init daemon speaks the dbus protocol, and can be communicated > with over the system daemon. But it can also be talked to directly. Looking at upstart-0.6.3-3.fc13.src.rpm, the specfile includes /sbin/shutdown etc. ... and looking at the tarball those seem to come from util/*.c. Which AFAICS require DBus to work. Also given that init now listens and is controlled by DBus, has anyone done any analysis of how resistant DBus services are to DOS attacks? -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From kevin.kofler at chello.at Sat Dec 5 03:02:47 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 05 Dec 2009 04:02:47 +0100 Subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? References: <4B0E8A1C.9080501@beam.ltd.uk> <4B0E9331.6020201@beam.ltd.uk> <1259273525.6876.5.camel@localhost> <4B0FAF69.7090602@earthlink.net> <4B103BDC.40204@earthlink.net> <2d319b780911271502v28431a66w2385894cf4984259@mail.gmail.com> Message-ID: Mathieu Bridon (bochecha) wrote: > How about visually impaired people? Compiz and the zoom plugin *are* > essential to them. They can use the plain old KMag which doesn't require any sort of compositing at all. Kevin Kofler From rc040203 at freenet.de Sat Dec 5 04:20:41 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 05 Dec 2009 05:20:41 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <1259821359.24679.5.camel@localhost.localdomain> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> <1259821359.24679.5.camel@localhost.localdomain> Message-ID: <4B19DF99.5040702@freenet.de> On 12/03/2009 07:22 AM, Jesse Keating wrote: > On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: >>> People doing network installs can either add the updates repo to their >>> kickstart, or check the box in the anaconda UI, so that the updates >>> repos are considered at install time. No download of duplicate data. >> Yes, for people who are doing "full featured networked installs" w/ >> custom kickstart files. I've never met such a person. > > Really? I meet people who use kickstart all the time. May-be internal at RH? > Any sizable > deployment of Fedora/RHEL uses or should use kickstart. And those that > don't aren't afraid to check that little 'updates' box at the software > selection screen. You seemed to have ignored that part of my point. No, I didn't. It's just that unless this "little check button" is the default, many users will ignore it or as in my case ... I am normally "yum-upgrading" between distros and rarely use anaconda. >>> In fact, having separate repos would likely cost less bandwidth. If we >>> only had one combined repo, there would be many duplicate packages, >> Where? Unlike now, where you have each package twice (in Everything and >> "updates"), you would have each package only once: In Everything. > > That assumes we purge anything but the latest version of a package, Correct. > which as noted in other parts of this thread gets complicated with GPL > compliance. Not necessarily - E.g. it would be GPL compliant to store "purged packages" outside of the "current" repos. And whether "spins" and the way they currently are implemented is "good"/"feasible"/"reasonable" is a different question. >> => An estimate for the increase in downloaded files's sizes you are >> talking about is ca. factor 2, from 18.2M (current "updates") >> to 32.8M+ (current "Everything"+"newly introduced packages) >> >> >> Whether this increase in download-size is "significant" is up to the >> beholder. For me, it gets lost in the noise of accessing a "good" or a >> "bad" connection to a mirror and in the time required to download >> packages from mirrors. > > 33~ megs downloaded every single time an update is pushed is a > significant hit for a fair number of people. Yes, but ... some more figures: The same figures as above for FC10: => Everything: 25.8M => updates: 18.5M => A rough estimate for sizes of repodata for a "near EOL'ed" Fedora: 70% of the size of "Everything's repodata". I.e. should this estimate apply to later Fedoras, Fedora 11 users are likely to see 70% of 33MB = 23MB near EOL of Fedora 11. > That was why it was > important to make yum not re-fetch that repodata every time, and use a > cached version of it. Yes, the keys to minimize bandwidth demands would be * to shink the size of the repodata/-files * to shink the size of "changes" to them. Besides obvious solutions, such as using a different compression (e.g. xz instead of bz2) and minimizing their contents, one could ship repodata/-files in "chunks". What I mean: In theory, one could * update repodata/-files incrementally by shipping some kind of "deltas". * split repodata/-files into several, e.g. sorted by "some other criteria", i.e. to provide several sets of *-[primary,filelist,other] files. One "package push", then would only affect a subset of the files, but not all. - This is very similar to what (IIRC) Seth had proposed (Split the repo into several repos, alphabetically), except that the "split" would happen inside of repodata and thus be transparent to users. I am not sure how difficult to implement this would be. Ralf From ngompa13 at gmail.com Sat Dec 5 04:49:41 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Fri, 4 Dec 2009 22:49:41 -0600 Subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? In-Reply-To: References: <4B0E8A1C.9080501@beam.ltd.uk> <4B0E9331.6020201@beam.ltd.uk> <1259273525.6876.5.camel@localhost> <4B0FAF69.7090602@earthlink.net> <4B103BDC.40204@earthlink.net> <2d319b780911271502v28431a66w2385894cf4984259@mail.gmail.com> Message-ID: <8278b1b0912042049v4ae16d0fmac2879b36a595b41@mail.gmail.com> On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler wrote: > Mathieu Bridon (bochecha) wrote: > > How about visually impaired people? Compiz and the zoom plugin *are* > > essential to them. > > They can use the plain old KMag which doesn't require any sort of > compositing at all. > > Kevin Kofler > > But why? And if you didn't install KDE, I doubt you would have KMag installed. And all the dependencies that get pulled in for installing a single KDE app is ridiculous. Plus, Compiz and the zoom plugin are smoother and more effective than KMag. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Sat Dec 5 05:22:21 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 4 Dec 2009 22:22:21 -0700 (MST) Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <4B19DF99.5040702@freenet.de> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> <1259821359.24679.5.camel@localhost.localdomain> <4B19DF99.5040702@freenet.de> Message-ID: <53674.75.166.232.127.1259990541.squirrel@www.cora.nwra.com> On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: > On 12/03/2009 07:22 AM, Jesse Keating wrote: >> On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: >>> Yes, for people who are doing "full featured networked installs" w/ >>> custom kickstart files. I've never met such a person. >> >> Really? I meet people who use kickstart all the time. > May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. In fact - every "upgrade" is a fresh kickstart install + restore critical files from backup. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rc040203 at freenet.de Sat Dec 5 05:26:31 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 05 Dec 2009 06:26:31 +0100 Subject: Proposed F13 feature: drop separate updates repository In-Reply-To: <53674.75.166.232.127.1259990541.squirrel@www.cora.nwra.com> References: <4B167C22.3000504@redhat.com> <20091202152655.GB14279@hansolo.jdub.homelinux.org> <4B168B48.8050504@redhat.com> <20091202160622.GD14279@hansolo.jdub.homelinux.org> <20091202170149.GB29353@fearengine.rdu.redhat.com> <4B169F60.2090602@freenet.de> <1259775645.12203.73.camel@localhost.localdomain> <4B174B80.8070309@freenet.de> <1259821359.24679.5.camel@localhost.localdomain> <4B19DF99.5040702@freenet.de> <53674.75.166.232.127.1259990541.squirrel@www.cora.nwra.com> Message-ID: <4B19EF07.6040504@freenet.de> On 12/05/2009 06:22 AM, Orion Poplawski wrote: > > On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: >> On 12/03/2009 07:22 AM, Jesse Keating wrote: >>> On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: >>>> Yes, for people who are doing "full featured networked installs" w/ >>>> custom kickstart files. I've never met such a person. >>> >>> Really? I meet people who use kickstart all the time. >> May-be internal at RH? > > I do every install via kickstart - small company with 30-50 machines. > Been doing fedora+everything+updates installs for many releases now. OK, then it's likely a "full time" professional admins vs. "part time"/"side-job" admins and "home-users" thing. Ralf From jwboyer at gmail.com Thu Dec 3 13:04:02 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Dec 2009 08:04:02 -0500 Subject: UPDATE: Final F-10 updates push date revised In-Reply-To: <20091125013135.GE13962@hansolo.jdub.homelinux.org> References: <20091125013135.GE13962@hansolo.jdub.homelinux.org> Message-ID: <20091203130402.GK14279@hansolo.jdub.homelinux.org> On Tue, Nov 24, 2009 at 08:31:35PM -0500, Josh Boyer wrote: >Hi All, > >Fedora 10 will go EOL on December 17th. The final day for >updates to be submitted will be December 14th. Please make >sure any final updates you want pushed to the F10 repos are >submitted by this date. Due to the infrastructure outage that has been scheduled for this timeframe, the final F10 updates push has now been rescheduled for December 11th, 2009. Please make sure any final updates you want pushed to the F10 repos are submitted by the revised date of December 11th, 2009. Apologies for the confusion and change in schedule. We will work more closely with the Infrastructure team in the future to avoid a similar situation. josh _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jlaska at redhat.com Fri Dec 4 00:01:31 2009 From: jlaska at redhat.com (James Laska) Date: Thu, 3 Dec 2009 19:01:31 -0500 (EST) Subject: [ANNOUNCEMENT] Red Hat Bugzilla 3.4 Upgrade Public Beta In-Reply-To: <1247828733.1503721259884727394.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <743408409.1503761259884891005.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Greetings, I am sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Fedora uses this instance of bugzilla too. Please forward this on to any appropriate lists that were missed. Thanks, James ========================== Greetings, The Red Hat Bugzilla team is happy to announce the first public beta release of the next version of Red Hat Bugzilla based on the upstream 3.4 code base. Please test drive at: https://partner-bugzilla.redhat.com Over the years Red Hat has made substantial customizations to Bugzilla to fit into the Engineering tool chain. Over time the upstream has incorporated some of these customizations or solved them in different ways. Upgrading reduces our customization footprint (and thus maintenance) while bringing many bug fixes & enhancements. The main area of focus for our public betas are stability. Functionality that currently works in our 3.2 code base should continue to work as expected in the new 3.4 release. These include various ajax optimizations, needinfo actor support, frontpage.cgi, product browser, several various UI enhancements, and of course the XMLRPC API. Please feel free to point your various scripts and third party applications that use the XMLRPC API at the test server to make sure they continue to function properly. There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 3.2 is possible in the new system. There are also numerous new features/fixes that are part of the upstream 3.4 release. For more detailed information on what has changed since the last release, check out the Release Notes page. The database is a recent snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Also with a full snapshot it is possible to test for any performance related issues. Email has been disabled so that unnecessary spam is not sent out. So feel free to make changes to bugs to verify proper working order. We are asking for everyone to get involved as much as possible with testing and feedback on the beta releases to help us make this the most robust and stable release possible. Please file any enhancement requests or bug reports in our current Bugzilla system at bugzilla.redhat.com. File them under the Bugzilla product and relevant component with the version 3.4. With everyone's help we can make this a great release. Thanks The Red Hat Bugzilla Team _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From nmiell at gmail.com Sat Dec 5 10:43:29 2009 From: nmiell at gmail.com (Nicholas Miell) Date: Sat, 05 Dec 2009 02:43:29 -0800 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: <8ff5cb21a6af08250c674f0086874bb3.squirrel@arekh.dyndns.org> References: <4B185436.4090802@behdad.org> <8ff5cb21a6af08250c674f0086874bb3.squirrel@arekh.dyndns.org> Message-ID: <4B1A3951.6020405@gmail.com> On 12/04/2009 05:49 AM, Nicolas Mailhot wrote: > > > Le Ven 4 d?cembre 2009 13:50, Mat?j Cepl a ?crit : >> >> Dne 4.12.2009 01:13, Behdad Esfahbod napsal(a): >>> Since the patents covering the TrueType bytecode interpreter expired at >>> the end of October, I've now built FreeType in rawhide with that part of >>> code enabled. >> >> can we hope for the update in F12 as well, please? > > Given how any font rendering changes seems to degrade font rendering for some > users, I'd very much prefer it went through a full release testing cycle > before hitting unsuspecting users. > c.f. https://bugs.freedesktop.org/show_bug.cgi?id=23981 From promac at gmail.com Sat Dec 5 14:48:22 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Sat, 5 Dec 2009 12:48:22 -0200 Subject: v4l applications Message-ID: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> There are some old v4l applications that do not work in Fedora 12. I found so far fmtools and gnomeradio. Gnomeradio accepts v4l2, but one has to use a gconf editor to change the driver (there is no option in the application interface). I tried to patch gnomerario, but I do not know how to force updating gconf database. I think that a new account should have the new defaults, but how do I force a change in a previously created account? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sat Dec 5 15:05:12 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 5 Dec 2009 07:05:12 -0800 Subject: Orphaning gnome-common In-Reply-To: <1259935500.25800.3.camel@planemask> References: <20091204133924.GE2712@clingman.lan> <1259935500.25800.3.camel@planemask> Message-ID: <20091205150512.GH2712@clingman.lan> On Fri, Dec 04, 2009 at 09:05:00AM -0500, Matthias Clasen wrote: > On Fri, 2009-12-04 at 05:39 -0800, Toshio Kuratomi wrote: > > This is a heads up that I'm going to orphan gnome-common. I don't do any > > gtk programming anymore so it doesn't make sense for me to keep this > > package. mclasen has done several of the recently needed updates to this > > package; if he and the desktop team would like to take it over let me know; > > I'll do the packagedb magic to hand it over to them. > > I'll find someone to own it, probably not before fudcon though... > Thank Matthias! Let me know. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From che666 at gmail.com Sat Dec 5 15:52:25 2009 From: che666 at gmail.com (Rudolf Kastl) Date: Sat, 5 Dec 2009 16:52:25 +0100 Subject: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM In-Reply-To: References: Message-ID: interestingly i just updated a radeon hd4650 box to latest rawhide and the same error pops up again: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 45. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! kind regards, Rudolf Kastl From notting at redhat.com Sat Dec 5 15:51:39 2009 From: notting at redhat.com (Bill Nottingham) Date: Sat, 5 Dec 2009 10:51:39 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <1259966374.15022.5.camel@code.and.org> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> <20091204214509.GA29249@nostromo.devel.redhat.com> <1259966374.15022.5.camel@code.and.org> Message-ID: <20091205155139.GA4710@nostromo.devel.redhat.com> James Antill (james at fedoraproject.org) said: > > > Does this mean that running dbus will be required to reboot/shutdown > > > the system? > > > > No. The init daemon speaks the dbus protocol, and can be communicated > > with over the system daemon. But it can also be talked to directly. > > Looking at upstart-0.6.3-3.fc13.src.rpm, the specfile > includes /sbin/shutdown etc. ... and looking at the tarball those seem > to come from util/*.c. Which AFAICS require DBus to work. ... which does not *require* the system dbus daemon. Bill From notting at redhat.com Sat Dec 5 15:53:00 2009 From: notting at redhat.com (Bill Nottingham) Date: Sat, 5 Dec 2009 10:53:00 -0500 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <8278b1b0912041405y594a511cr11fb0b62b78babba@mail.gmail.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> <20091204213942.GD19016@localhost> <20091204214509.GA29249@nostromo.devel.redhat.com> <8278b1b0912041405y594a511cr11fb0b62b78babba@mail.gmail.com> Message-ID: <20091205155300.GB4710@nostromo.devel.redhat.com> Sir Gallantmon (ngompa13 at gmail.com) said: > Why aren't the sysVinit scripts being ported over to native upstart scripts? > I thought the reason why upstart was adopted was to be able to utilize the > benefits of native upstart scripts (event based daemon handling, etc.)? - Semantics may change for 1.0 (although they're trying to keep the format the same between 0.6 and 1.0) - A system that's half-upstart and half-SysV has a variety of compatiblity problems, if you ever need to have dependencies between them. Bill From fedora at matbooth.co.uk Sat Dec 5 17:31:55 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Sat, 5 Dec 2009 17:31:55 +0000 Subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? In-Reply-To: <8278b1b0912042049v4ae16d0fmac2879b36a595b41@mail.gmail.com> References: <4B0E8A1C.9080501@beam.ltd.uk> <4B0E9331.6020201@beam.ltd.uk> <1259273525.6876.5.camel@localhost> <4B0FAF69.7090602@earthlink.net> <4B103BDC.40204@earthlink.net> <2d319b780911271502v28431a66w2385894cf4984259@mail.gmail.com> <8278b1b0912042049v4ae16d0fmac2879b36a595b41@mail.gmail.com> Message-ID: <9497e9990912050931w4fc71051pbd06e10379a75c2@mail.gmail.com> 2009/12/5 Sir Gallantmon : > On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler wrote: >> >> Mathieu Bridon (bochecha) wrote: >> > How about visually impaired people? Compiz and the zoom plugin *are* >> > essential to them. >> >> They can use the plain old KMag which doesn't require any sort of >> compositing at all. >> >> ? ? ? ?Kevin Kofler >> > > But why? And if you didn't install KDE, I doubt you would have KMag > installed. And all the dependencies that get pulled in for installing a > single KDE app is ridiculous. Plus, Compiz and the zoom plugin are smoother > and more effective than KMag. Orca then, whatever. Point is, it's possible without compiz. -- Mat Booth From dominik at greysector.net Sat Dec 5 20:45:40 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 5 Dec 2009 21:45:40 +0100 Subject: v4l applications In-Reply-To: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> Message-ID: <20091205204540.GB30634@mokona.greysector.net> On Saturday, 05 December 2009 at 15:48, Paulo Cavalcanti wrote: > There are some old v4l applications that do not work in Fedora 12. > > I found so far fmtools and gnomeradio. > > Gnomeradio accepts v4l2, but one has to use a gconf editor > to change the driver (there is no option in the application interface). > > I tried to patch gnomerario, but I do not know how to force > updating gconf database. I think that a new account should > have the new defaults, but how do I force a change in a previously created > account? I'm the maintainer of gnomeradio, but I haven't used it for a while because I'm away from my desktop PC, which has an analog tv/radio tuner card. Would you be interested in co-maintaining gnomeradio? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From promac at gmail.com Sun Dec 6 09:36:04 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 6 Dec 2009 07:36:04 -0200 Subject: v4l applications In-Reply-To: <20091205204540.GB30634@mokona.greysector.net> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <20091205204540.GB30634@mokona.greysector.net> Message-ID: <68720af30912060136h7efc44ddx2830849eef3b0d08@mail.gmail.com> On Sat, Dec 5, 2009 at 6:45 PM, Dominik 'Rathann' Mierzejewski < dominik at greysector.net> wrote: > On Saturday, 05 December 2009 at 15:48, Paulo Cavalcanti wrote: > > There are some old v4l applications that do not work in Fedora 12. > > > > I found so far fmtools and gnomeradio. > > > > Gnomeradio accepts v4l2, but one has to use a gconf editor > > to change the driver (there is no option in the application interface). > > > > I tried to patch gnomerario, but I do not know how to force > > updating gconf database. I think that a new account should > > have the new defaults, but how do I force a change in a previously > created > > account? > > I'm the maintainer of gnomeradio, but I haven't used it for a while because > I'm away from my desktop PC, which has an analog tv/radio tuner card. > Would you be interested in co-maintaining gnomeradio? > > Sure. There are very few radio applications around, and they are kind of unmaintained upstream. I made a review request yesterday with a patched gqradio for working with v4l2. gnomeradio just needs best defaults for v4l2 and a script for having sound using sox, because it never recognized the mixer channels of my card: http://orion.lcg.ufrj.br/RPMS/src/gnomeradio-1.8-4.fc12.src.rpm kradio4 works fine with v4l2 and fmtools is bkoken. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at lisas.de Sun Dec 6 10:48:12 2009 From: adrian at lisas.de (Adrian Reber) Date: Sun, 6 Dec 2009 11:48:12 +0100 Subject: Exception request from FESCo for bundled libaries Message-ID: <20091206104812.GB8376@lisas.de> I was informed that wordpress uses bundled libraries and would like to request an exception from FESCo. https://bugzilla.redhat.com/show_bug.cgi?id=544720 Adrian From enrico.scholz at informatik.tu-chemnitz.de Sun Dec 6 11:25:30 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 06 Dec 2009 12:25:30 +0100 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> (Bill Nottingham's message of "Fri, 4 Dec 2009 16:10:34 -0500") References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <87d42sbaz9.fsf@sheridan.bigo.ensc.de> Bill Nottingham writes: > If you own any of the following packages, you have upstart job files that > will need modified for any needed format changes, and the new location. > > * clamav ensc > * dhcp-forwarder ensc > * ip-sentinel ensc > * milter-greylist ensc > * tor ensc > > We're willing to do the legwork for you, or you can do the update > yourself once we land 0.6.x; give us a reply with which you'd prefer. I updated (but not tested) them in rawhide. Enrico From dominik at greysector.net Sun Dec 6 11:46:27 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Dec 2009 12:46:27 +0100 Subject: v4l applications In-Reply-To: <68720af30912060136h7efc44ddx2830849eef3b0d08@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <20091205204540.GB30634@mokona.greysector.net> <68720af30912060136h7efc44ddx2830849eef3b0d08@mail.gmail.com> Message-ID: <20091206114627.GA32704@mokona.greysector.net> On Sunday, 06 December 2009 at 10:36, Paulo Cavalcanti wrote: > On Sat, Dec 5, 2009 at 6:45 PM, Dominik 'Rathann' Mierzejewski < > dominik at greysector.net> wrote: > > > On Saturday, 05 December 2009 at 15:48, Paulo Cavalcanti wrote: > > > There are some old v4l applications that do not work in Fedora 12. > > > > > > I found so far fmtools and gnomeradio. > > > > > > Gnomeradio accepts v4l2, but one has to use a gconf editor > > > to change the driver (there is no option in the application interface). > > > > > > I tried to patch gnomerario, but I do not know how to force > > > updating gconf database. I think that a new account should > > > have the new defaults, but how do I force a change in a previously > > created > > > account? > > > > I'm the maintainer of gnomeradio, but I haven't used it for a while because > > I'm away from my desktop PC, which has an analog tv/radio tuner card. > > Would you be interested in co-maintaining gnomeradio? > > > > > Sure. There are very few radio applications around, and they are kind of > unmaintained upstream. I made a review request yesterday with a patched > gqradio for working with v4l2. > > gnomeradio just needs best defaults for v4l2 and a script for having sound > using sox, because it never recognized the mixer channels of my card: > > http://orion.lcg.ufrj.br/RPMS/src/gnomeradio-1.8-4.fc12.src.rpm > > kradio4 works fine with v4l2 and fmtools is bkoken. It would've been easier for me if you had just posted a patch for the specfile along with the patch you wanted to apply to the source. Anyway, I had a look at it and I don't like it. You're hardcoding the driver to v4l2. I think it'd be better to simply make the autodetection try v4l2 first. Also, is it necessary to change "/dev/radio" to "/dev/radio0"? Please try the attached patch and see if it works for you. Thanks and regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -------------- next part -------------- diff -up gnomeradio-1.8/src/prefs.c.v4l2 gnomeradio-1.8/src/prefs.c --- gnomeradio-1.8/src/prefs.c.v4l2 2008-04-13 15:04:52.000000000 +0200 +++ gnomeradio-1.8/src/prefs.c 2009-12-06 12:43:45.000000000 +0100 @@ -112,7 +112,7 @@ gboolean load_settings(void) /* Load general settings */ settings.device = gconf_client_get_string(client, "/apps/gnomeradio/device" , NULL); if (!settings.device) - settings.device = g_strdup("/dev/radio"); + settings.device = g_strdup("/dev/radio0"); settings.driver = gconf_client_get_string(client, "/apps/gnomeradio/driver" , NULL); if (!settings.driver) settings.driver = g_strdup("any"); diff -up gnomeradio-1.8/src/radio.c.v4l2 gnomeradio-1.8/src/radio.c --- gnomeradio-1.8/src/radio.c.v4l2 2008-04-13 14:55:43.000000000 +0200 +++ gnomeradio-1.8/src/radio.c 2009-12-06 12:44:01.000000000 +0100 @@ -41,9 +41,9 @@ int radio_init(char *device, DriverType } switch (driver) { + case DRIVER_ANY: case DRIVER_V4L2: goto try_v4l2; - case DRIVER_ANY: case DRIVER_V4L1: default: goto try_v4l1; From promac at gmail.com Sun Dec 6 12:40:52 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 6 Dec 2009 10:40:52 -0200 Subject: v4l applications In-Reply-To: <20091206114627.GA32704@mokona.greysector.net> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <20091205204540.GB30634@mokona.greysector.net> <68720af30912060136h7efc44ddx2830849eef3b0d08@mail.gmail.com> <20091206114627.GA32704@mokona.greysector.net> Message-ID: <68720af30912060440p79408da4x5da74d87480ea944@mail.gmail.com> On Sun, Dec 6, 2009 at 9:46 AM, Dominik 'Rathann' Mierzejewski < dominik at greysector.net> wrote: > On Sunday, 06 December 2009 at 10:36, Paulo Cavalcanti wrote: > > On Sat, Dec 5, 2009 at 6:45 PM, Dominik 'Rathann' Mierzejewski < > > dominik at greysector.net> wrote: > > > > > On Saturday, 05 December 2009 at 15:48, Paulo Cavalcanti wrote: > > > > There are some old v4l applications that do not work in Fedora 12. > > > > > > > > I found so far fmtools and gnomeradio. > > > > > > > > Gnomeradio accepts v4l2, but one has to use a gconf editor > > > > to change the driver (there is no option in the application > interface). > > > > > > > > I tried to patch gnomerario, but I do not know how to force > > > > updating gconf database. I think that a new account should > > > > have the new defaults, but how do I force a change in a previously > > > created > > > > account? > > > > > > I'm the maintainer of gnomeradio, but I haven't used it for a while > because > > > I'm away from my desktop PC, which has an analog tv/radio tuner card. > > > Would you be interested in co-maintaining gnomeradio? > > > > > > > > Sure. There are very few radio applications around, and they are kind of > > unmaintained upstream. I made a review request yesterday with a patched > > gqradio for working with v4l2. > > > > gnomeradio just needs best defaults for v4l2 and a script for having > sound > > using sox, because it never recognized the mixer channels of my card: > > > > http://orion.lcg.ufrj.br/RPMS/src/gnomeradio-1.8-4.fc12.src.rpm > > > > kradio4 works fine with v4l2 and fmtools is bkoken. > > It would've been easier for me if you had just posted a patch for the > specfile > along with the patch you wanted to apply to the source. > > Anyway, I had a look at it and I don't like it. You're hardcoding the > driver > to v4l2. I think it'd be better to simply make the autodetection try v4l2 > first. Also, is it necessary to change "/dev/radio" to "/dev/radio0"? > > There is no /dev/radio in Fedora 12 any more. Only /dev/radio0. But this is up to you, because it can be set using the interface. > Please try the attached patch and see if it works for you. > > It worked just fine, and it is much better indeed. This way, the default can be "any", and it will work with v4l2. It is also working in Fedora 10 for me. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Sun Dec 6 13:15:40 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Dec 2009 14:15:40 +0100 Subject: Heads up: new (lib)tre coming to rawhide near you Message-ID: <20091206131540.GC32704@mokona.greysector.net> Hi all! tre-0.8.0 will be landing in rawhide soon. The only dependent packages are crm114, which is mine and msort, which requires a small patch to build, because the new tre breaks ABI. Replacing all reg* calls with tre_reg* would be recommended, too, but since there are macros to preserve the API, it's not strictly necessary. I'm attaching the patch for reference, but since the package ACLs are open to provenpackagers, I'll just commit it and rebuild msort myself. On a side note, msort could be updated to the latest release, which is 8.52 (current rawhide is 8.46). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -------------- next part -------------- diff -up msort-8.46/configure.ac.tre msort-8.46/configure.ac --- msort-8.46/configure.ac.tre 2008-05-28 02:23:13.000000000 +0200 +++ msort-8.46/configure.ac 2009-12-06 13:43:45.984378670 +0100 @@ -69,7 +69,7 @@ AC_PROG_CC AC_PROG_INSTALL # Checks for libraries. -AC_CHECK_LIB([tre], [regwcomp],,[AC_MSG_ERROR([libtre not found. see http://laurikari.net/tre/])]) +AC_CHECK_LIB([tre], [tre_regwcomp],,[AC_MSG_ERROR([libtre not found. see http://laurikari.net/tre/])]) # Checks for header files. AC_HEADER_STDC diff -up msort-8.46/configure.tre msort-8.46/configure --- msort-8.46/configure.tre 2008-05-28 02:23:47.000000000 +0200 +++ msort-8.46/configure 2009-12-06 13:44:53.027621362 +0100 @@ -3045,8 +3045,8 @@ test -z "$INSTALL_DATA" && INSTALL_DATA= # Checks for libraries. -echo "$as_me:$LINENO: checking for regwcomp in -ltre" >&5 -echo $ECHO_N "checking for regwcomp in -ltre... $ECHO_C" >&6 +echo "$as_me:$LINENO: checking for tre_regwcomp in -ltre" >&5 +echo $ECHO_N "checking for tre_regwcomp in -ltre... $ECHO_C" >&6 if test "${ac_cv_lib_tre_regwcomp+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else @@ -3065,11 +3065,11 @@ extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char regwcomp (); +char tre_regwcomp (); int main () { -regwcomp (); +tre_regwcomp (); ; return 0; } From debarshi.ray at gmail.com Sun Dec 6 13:21:55 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 6 Dec 2009 15:21:55 +0200 Subject: Packages looking for new owners In-Reply-To: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Message-ID: <3170f42f0912060521k67b8b1e5u83b920e82d32d1d0@mail.gmail.com> > I don't mind keeping libopenraw, avrdude and uisp unless anyone > _really_ want to maintain these packages. I have taken libopenraw. Happy hacking, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From chitlesh.goorah at gmail.com Sun Dec 6 13:25:20 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sun, 6 Dec 2009 14:25:20 +0100 Subject: Packages looking for new owners In-Reply-To: <200809082312.38592.konrad@tylerc.org> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200809082312.38592.konrad@tylerc.org> Message-ID: <50baabb30912060525m669fd3dbwfcc8d2ab0d7208c5@mail.gmail.com> On Tue, Sep 9, 2008 at 7:12 AM, Conrad Meyer wrote: > > I'd like to take sdcc. Can you also package http://eclipse-sdcc.sourceforge.net/ please ? Chitlesh From dominik at greysector.net Sun Dec 6 13:51:51 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Dec 2009 14:51:51 +0100 Subject: v4l applications In-Reply-To: <68720af30912060440p79408da4x5da74d87480ea944@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <20091205204540.GB30634@mokona.greysector.net> <68720af30912060136h7efc44ddx2830849eef3b0d08@mail.gmail.com> <20091206114627.GA32704@mokona.greysector.net> <68720af30912060440p79408da4x5da74d87480ea944@mail.gmail.com> Message-ID: <20091206135151.GE32704@mokona.greysector.net> On Sunday, 06 December 2009 at 13:40, Paulo Cavalcanti wrote: > On Sun, Dec 6, 2009 at 9:46 AM, Dominik 'Rathann' Mierzejewski < > dominik at greysector.net> wrote: > > > On Sunday, 06 December 2009 at 10:36, Paulo Cavalcanti wrote: > > > On Sat, Dec 5, 2009 at 6:45 PM, Dominik 'Rathann' Mierzejewski < > > > dominik at greysector.net> wrote: > > > > > > > On Saturday, 05 December 2009 at 15:48, Paulo Cavalcanti wrote: > > > > > There are some old v4l applications that do not work in Fedora 12. > > > > > > > > > > I found so far fmtools and gnomeradio. > > > > > > > > > > Gnomeradio accepts v4l2, but one has to use a gconf editor > > > > > to change the driver (there is no option in the application > > interface). > > > > > > > > > > I tried to patch gnomerario, but I do not know how to force > > > > > updating gconf database. I think that a new account should > > > > > have the new defaults, but how do I force a change in a previously > > > > created > > > > > account? > > > > > > > > I'm the maintainer of gnomeradio, but I haven't used it for a while > > because > > > > I'm away from my desktop PC, which has an analog tv/radio tuner card. > > > > Would you be interested in co-maintaining gnomeradio? > > > > > > > > > > > Sure. There are very few radio applications around, and they are kind of > > > unmaintained upstream. I made a review request yesterday with a patched > > > gqradio for working with v4l2. > > > > > > gnomeradio just needs best defaults for v4l2 and a script for having > > sound > > > using sox, because it never recognized the mixer channels of my card: > > > > > > http://orion.lcg.ufrj.br/RPMS/src/gnomeradio-1.8-4.fc12.src.rpm > > > > > > kradio4 works fine with v4l2 and fmtools is bkoken. > > > > It would've been easier for me if you had just posted a patch for the > > specfile > > along with the patch you wanted to apply to the source. > > > > Anyway, I had a look at it and I don't like it. You're hardcoding the > > driver > > to v4l2. I think it'd be better to simply make the autodetection try v4l2 > > first. Also, is it necessary to change "/dev/radio" to "/dev/radio0"? > > > > > There is no /dev/radio in Fedora 12 any more. Only /dev/radio0. > But this is up to you, because it can be set using the interface. OK. I think your change can stay, then. > > Please try the attached patch and see if it works for you. > > > > > It worked just fine, and it is much better indeed. This way, the default > can be "any", and it will work with v4l2. > > It is also working in Fedora 10 for me. Great! Thanks for testing. I've applied the patch to rawhide. Feel free to request ACLs and port the changes to F-12/11 yourself. I might be too busy to do it anytime soon. Could you forward the patch upstream, too? One more thing: I added your script to the package, but as %doc. I don't think we should be installing it in %{_bindir} by default. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bruno at wolff.to Sun Dec 6 15:03:15 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 6 Dec 2009 09:03:15 -0600 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <20091206104812.GB8376@lisas.de> References: <20091206104812.GB8376@lisas.de> Message-ID: <20091206150315.GB1696@wolff.to> On Sun, Dec 06, 2009 at 11:48:12 +0100, Adrian Reber wrote: > > I was informed that wordpress uses bundled libraries and would like to > request an exception from FESCo. > > https://bugzilla.redhat.com/show_bug.cgi?id=544720 You didn't list any reasons for needing an exception in either your message or the ticket. I am not on FESCO, but I don't think that exceptions are granted solely on the basis of something being bundled upstream. If you want to use a ticket specifically to bring something to FESCO's attention (for a meeting topic), then trac is probably a better place than bugzilla to file it. You can start at https://fedorahosted.org/fesco/wiki to file a ticket for them. From kwizart at gmail.com Sun Dec 6 15:53:14 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Sun, 6 Dec 2009 16:53:14 +0100 Subject: v4l applications In-Reply-To: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> Message-ID: 2009/12/5 Paulo Cavalcanti : > There are some old v4l applications that do not work in Fedora 12. > > I found so far fmtools and gnomeradio. I will have a look on fmtools in ew days, but until then, patches welcomed. Nicolas (kwizart) From cemeyer at u.washington.edu Sun Dec 6 21:48:13 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 6 Dec 2009 13:48:13 -0800 Subject: Packages looking for new owners In-Reply-To: <50baabb30912060525m669fd3dbwfcc8d2ab0d7208c5@mail.gmail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200809082312.38592.konrad@tylerc.org> <50baabb30912060525m669fd3dbwfcc8d2ab0d7208c5@mail.gmail.com> Message-ID: <200912061348.13626.cemeyer@u.washington.edu> On Sunday 06 December 2009 05:25:20 am Chitlesh GOORAH wrote: > On Tue, Sep 9, 2008 at 7:12 AM, Conrad Meyer wrote: > > I'd like to take sdcc. > > Can you also package http://eclipse-sdcc.sourceforge.net/ please ? > > Chitlesh Sorry, I'm not an eclipse user, and java packages are exceedingly painful to maintain. Also, SDCC currently does not build (clarification: the software builds fine. rpmbuild is choking on non-native ar files) and I am unsure how to fix it. I've asked the list a few weeks back and did not get any replies, so I may be forced to orphan it (I do not want to, but if I cannot get it to build...). Regards, -- Conrad Meyer From rspanton at zepler.net Mon Dec 7 00:01:54 2009 From: rspanton at zepler.net (Robert Spanton) Date: Mon, 07 Dec 2009 00:01:54 +0000 Subject: Help with packaging In-Reply-To: <200911241916.20064.cemeyer@u.washington.edu> References: <200911241916.20064.cemeyer@u.washington.edu> Message-ID: <1260144114.11089.15.camel@prefect.blob> Hi Conrad, On Tue, 2009-11-24 at 19:16 -0800, Conrad Meyer wrote: > I'm experiencing trouble trying to get one of my packages (sdcc) to build for > Fedora 12. It builds on Fedora 11 and older (just double-checked in mock). It > seems to be some sort of change in how RPM uses __os_install_post or how brp- > strip-static-archive works between F11 and F12. Anyone familiar with any such > changes? You might find it useful to have a look at what I'm doing in msp430-libc with __os_install_post. I think I was inspired to do this by what was done in avr-libc. RPM seems to be one of those things where knowledge is passed on by word of mouth between generations :-/ Cheers, Rob p.s. Sorry for not replying sooner -- I don't read all posts to fedora-devel, as I would go insane :-P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From cemeyer at u.washington.edu Mon Dec 7 02:25:06 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 6 Dec 2009 18:25:06 -0800 Subject: Help with packaging In-Reply-To: <1260144114.11089.15.camel@prefect.blob> References: <200911241916.20064.cemeyer@u.washington.edu> <1260144114.11089.15.camel@prefect.blob> Message-ID: <200912061825.06300.cemeyer@u.washington.edu> On Sunday 06 December 2009 04:01:54 pm Robert Spanton wrote: > On Tue, 2009-11-24 at 19:16 -0800, Conrad Meyer wrote: > > I'm experiencing trouble trying to get one of my packages (sdcc) to build > > for Fedora 12. It builds on Fedora 11 and older (just double-checked in > > mock). It seems to be some sort of change in how RPM uses > > __os_install_post or how brp- strip-static-archive works between F11 and > > F12. Anyone familiar with any such changes? > > You might find it useful to have a look at what I'm doing in msp430-libc > with __os_install_post. I think I was inspired to do this by what was > done in avr-libc. Thanks, I'll try doing that now. Unfortunately it seems like that will stop rpmbuild from stripping the (native) sdcc binaries, but I'd like to see the package building. > RPM seems to be one of those things where knowledge is passed on by word > of mouth between generations :-/ Yes, and perhaps more work could be done with rpm to improve support for cross-compiler-related packages. > p.s. Sorry for not replying sooner -- I don't read all posts to > fedora-devel, as I would go insane :-P I'm glad to get any help. Thanks, -- Conrad Meyer From craftjml at gmail.com Mon Dec 7 02:32:16 2009 From: craftjml at gmail.com (Jud Craft) Date: Sun, 6 Dec 2009 21:32:16 -0500 Subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ? In-Reply-To: <9497e9990912050931w4fc71051pbd06e10379a75c2@mail.gmail.com> References: <4B0E8A1C.9080501@beam.ltd.uk> <1259273525.6876.5.camel@localhost> <4B0FAF69.7090602@earthlink.net> <4B103BDC.40204@earthlink.net> <2d319b780911271502v28431a66w2385894cf4984259@mail.gmail.com> <8278b1b0912042049v4ae16d0fmac2879b36a595b41@mail.gmail.com> <9497e9990912050931w4fc71051pbd06e10379a75c2@mail.gmail.com> Message-ID: <20d6441a0912061832t289d7195g6ee2d980f991f31a@mail.gmail.com> On Sat, Dec 5, 2009 at 12:31 PM, Mat Booth wrote: > Orca then, whatever. Point is, it's possible without compiz. Isn't Orca's magnifier getting phased out? Yeah. And whenever GNOME Shell rolls out their new accessibility magnifier...well, it's gonna need compositing. Like everything else. Not to mention that without compositing, usable full-screen magnification really isn't possible. Orca lets you zoom in the screen -- but at modern resolutions, it's a slideshow of a magnifier that doesn't let you do much else very fluidly. From wtogami at redhat.com Mon Dec 7 03:00:34 2009 From: wtogami at redhat.com (Warren Togami) Date: Sun, 06 Dec 2009 22:00:34 -0500 Subject: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available Message-ID: <4B1C6FD2.5060708@redhat.com> Apache SpamAssassin 3.3.0-beta1 is now available for testing. Downloads are available from: http://people.apache.org/~wtogami/devel/ md5sum of archive files: 9b39e4e4fad09cfe9eff974f3d5a01ea Mail-SpamAssassin-3.3.0-beta1.tar.bz2 530fb1bd28977271f30b348bc2b68db1 Mail-SpamAssassin-3.3.0-beta1.tar.gz 637f6495b28e9ab9580206ee344a2074 Mail-SpamAssassin-3.3.0-beta1.zip cbd092c4e0e71b531f7aca81d4eb2781 Mail-SpamAssassin-rules-3.3.0-beta1.r886683.tgz sha1sum of archive files: b6aa2f21610e1de87bf21b629b98df9bddfa0988 Mail-SpamAssassin-3.3.0-beta1.tar.bz2 6750417097ce289a5b295c75bfc20a877bea87e6 Mail-SpamAssassin-3.3.0-beta1.tar.gz 95a54095f6e201a1b582f3715c81c9485aab5325 Mail-SpamAssassin-3.3.0-beta1.zip 3e2b23828dd3a7575ced80b2d6571995aebd7299 Mail-SpamAssassin-rules-3.3.0-beta1.r886683.tgz Note that the *-rules-*.tgz files are only necessary if you cannot, or do not wish to, run "sa-update" after install to download the latest fresh rules. The release files also have a .asc accompanying them. The file serves as an external GPG signature for the given release file. The signing key is available via the wwwkeys.pgp.net key server, as well as http://www.apache.org/dist/spamassassin/KEYS The key information is: pub 4096R/F7D39814 2009-12-02 Key fingerprint = D809 9BC7 9E17 D7E4 9BC2 1E31 FDE5 2F40 F7D3 9814 uid SpamAssassin Project Management Committee uid SpamAssassin Signing Key (Code Signing Key, replacement for 1024D/265FA05B) sub 4096R/7B3265A5 2009-12-02 See the INSTALL and UPGRADE files in the distribution for important installation notes. Summary of major changes since 3.2.5 ------------------------------------ COMPATIBILITY WITH 3.2.5 - rules are no longer distributed with the package, but installed by sa-update - either automatically fetched from the network (preferably), or from a tar archive, which is available for downloading separately - CPAN module requirements: - minimum required version of ExtUtils::MakeMaker is 6.17 - modules now required: Time::HiRes, NetAddr::IP, Archive::Tar - minimal version of Mail::DKIM is 0.31 (preferred: 0.37 or later); expect some tests in t/dkim2.t to fail with versions older than 0.36_5; - no longer used: Mail::DomainKeys, Mail::SPF::Query - if module Digest::SHA is not available, a module Digest::SHA1 will be used, but at least one of them must be installed; a DKIM plugin requires Digest::SHA (the older Digest::SHA1 does not support sha256 hashes), so in practice the Digest::SHA is required - if keeping AWL database in SQL, the field awl.ip must be extended to 40 characters. The change is necessary to allow AWL to keep track of IPv6 addresses which may appear in a mail header even on non-IPv6 -enabled host. While at it, consider also adding a field 'signedby' to the SQL table 'awl' (and adding 'auto_whitelist_distinguish_signed 1' to local.cf); See sql/README.awl for details. The change need not be undone even if downgrading back to 3.2.* for some reason; - fixing a protocol implementation error regarding a PING command required bumping up the SPAMC protocol version to 1.5. Spamd retains compatibility with older spamc clients. Combining new spamc clients with pre-3.3 versions of a spamd daemon is not supported (but happens to work, except for the PING and SKIP commands). - it may be worth mentioning that a rule DKIM_VERIFIED has been renamed to DKIM_VALID, to match its semantics; - support for versions of perl 5.6.* is being gradually revoked (may still work, but no promises and no support) - preferred versions of perl are 5.8.8, 5.8.9, and 5.10.1 or later MAIN NEW FEATURES - IPv6 support was substantially improved (see below); - many improvements to the DKIM plugin (understands author domain signatures, supports multiple signatures, ADSP support with overrides) - (see below); - added 'if can(Class::method)' conditional statement, allowing configuration settings to be conditionalised on plugin capabilities without requiring new version releases to do so; - added a configuration option 'time_limit', defaulting to 300 seconds or whatever the caller (like spamd) provides; attempting to gracefully terminate the checking when a time limit is reached, reporting the score and test hits that were collected so far, along with an added hit on a rule TIME_LIMIT_EXCEEDED; - more expensive code sections are now instrumented with timing measurements; timing report is logged as a debug message by the end of processing, and made available to a caller and to 'add_header' directives through a TIMING tag; - added a configuration option skip_uribl_checks to the URIDNSBL plugin, cross-document it with skip_rbl_checks; - preserve order of declared 'add_header' header fields; - configurable network mask length for the AWL plugin (see below); - added support for DCC reputations (see below); - improved error handling and robustness (see below); - added timestamps when logging on stderr; - allowed debug areas to be excluded from debugging, e.g.: -D all,norules,noconfig,nodcc BUILDING AND PACKAGING - rules are no longer distributed with the package, but installed by sa-update - Makefile.PL has been simplified and a bug fixed in a DESTDIR support by increasing the minimum required version of ExtUtils::MakeMaker to 6.17 - tools check_whitelist and check_spamd are now included in the distribution, now called 'sa-awl' and 'sa-check_spamd' WORKAROUNDS TO PERL BUGS AND LIMITATIONS - modified the Check.pm plugin to produce smaller chunks of source code from rules (60 kB) to avoid Perl compiler crashing on exceeding stack size - localized global variables $1, $2, etc at several places, avoiding taint issue from propagating - avoided Perl I/O bug by replacing line-by-line reading with read() where suitable, or played down the EBADF status in other places and only report it as a dbg instead of a die - while also providing a little speedup (10 .. 25 %) on reading a message - provided a new sub Message::split_into_array_of_short_lines to split a text into array of paragraph chunks of sizes between 1 kB and 2 kB, giving less opportunity to runaway regular expressions in rules; fixes bugs: 5717, 5644, 5795, 5486, 5801, 5041 MEMORY FOOTPRINT - as a side-effect of compiling rules in smaller chunks (to avoid compiler crashes), virtual memory footprint of SpamAssassin is reduced; - saved some memory by not importing the Pod::Usage unless it is needed; - saved 350k+ of memory in sa-compile by replacing DynaLoader with XSLoader; - removed unneeded index from MySQL bayes_token table; IPv6 SUPPORT - added IPv6 support for trusted_networks, internal_networks, msa_networks, whitelist_from_rcvd, and other stuff that uses NetSet and the Received header field parser, using NetAddr::IP; - allowed usage of a remote dccifd host through an INET or INET6 socket; - added IPv6 support to AWL plugin and its utility modules; a network mask length is now configurable and defaults to /48, which controls what data is stored in an AWL database; - sql/README.awl and sql/awl_*.sql: increased suggested awl.ip field width to 40 characters to be able to hold IPv6 addresses; - IP_PRIVATE now includes ipv6 variants of private address space, as well as the ipv6-mapped ipv4 addresses. - NetSet now understands that ::ffff:192.168.1.2 and 192.168.1.2 are the same address; - IPv6 addresses are now recognised in Received header fields; - when reading Received header fields, the "IPv6:" prefix is stripped from IPv6 addresses, and "::ffff:" is removed from IPv6-mapped IPv4 addresses (so strings can match them as simply IPv4 addresses); - ::1/128 is always included in the trusted_networks/internal_networks set similar to 127.0.0.0/8; - some of the IPv6 functionality in SpamAssassin requires that a perl module IO::Socket::INET6 is available (like accessing a DNS resolver over inet6, talking to a dccifd host over inet6 socket, SPAMC protocol); SPAMC - Mail::SpamAssasin::Client ping may erroneously result in broken pipe; bump spamc protocol version to 1.5, updated spamd, spamc and Client.pm; - added -n / --connect-timeout switch to spamc, allowing separate connection timeout from communication timeout; - added --filter-retries and --filter-retry-sleep - spamc would not time out connections to a hung spamd, fixed - spamc client library leaked the zlib compression buffer if compression is used - spamc long option '--dest' was broken SPAMD - when spamd is started with the daemonize option do not exit the parent until a child signals that it has logged the pid, to allow a wrapper script to simply continue immediately after starting spamd; - additional tempfile cleanup in kill_handler; - added SPAMD_LOCALHOST option to "make test" to allow specifying non-127.0.0.1 IP address for use in FreeBSD jail API - adding one optional argument to Mail::SpamAssassin::parse allows caller to pass additional out-of-band information to SpamAssassin (such as a deadline time, DKIM verification results, information about a SMTP session, or dynamic rule hits); this information is made available to plugins and the rest of the code through a 'suppl_attrib' hash; - Plugin::Check - pick up 'rule_hits' from caller via the new mechanism and call got_hit() on them; - simplified adding dynamic score hits and dynamic rules by plugins (such as AWL, CRM114, FuzzyOcr, Check) by letting got_hit() accept options tflags and description, and letting it store a supplied dynamic score for proper reporting; - let the timing breakdown information be accessible to a caller through the existing get_tag mechanism (tag TIMING); - let the generated header fields ('add_header' configuration options) be accessible to a caller through the existing get_tag mechanism (tags ADDEDHEADER, ADDEDHEADERHAM, ADDEDHEADERSPAM); RULES - rules are no longer distributed with the package; - new scores have been generated by a GA algorithm and then manually tweaked, based on cleaned datasets supplied by a dozen of volunteers; - dropped redundant rules or rules causing too many false positives; - added or updated many rules; incomplete list in no particular order: vbounce, lotsa_money, muchmoney, image spam, fill_this_form, FreeMail, European Parliament, HTML attachments, uri_obfu*, urinsrhsbl, urinsrhssub, urifullnsrhsbl, URI_OBFU_X9_WS, rDNS=localhost, INVALID_DATE_TZ_ABSURD, KHOP_SC, RCVD_IN_PSBL, FRT_VALIUM*, BOUNCE_MESSAGE, VBOUNCE_MESSAGE, __BOUNCE_UNDELIVERABLE, HELO_STATIC_HOST, FILL_THIS_FORM_FRAUD_PHISH, CHALLENGE_RESPONSE, DKIM_VALID, DKIM_VALID_AU, DKIM_ADSP_*, NML_ADSP_CUSTOM_{LOW,MED,HIGH}, __VIA_ML, MIME_BASE64_TEXT, LOTTO_URI, FORGED_MUA_THEBAT_BOUN, FORGED_MUA_THEBAT_CS, UNRESOLVED_TEMPLATE, __THEBAT_MUA, __ANY_OUTLOOK_MUA, RP_MATCHES_RCVD, one-word X-Mailer, advance_fee update, tweak SPAN rules, tweak skype and misquoted-HTML rules, added some new HTML obfuscation and Google feedproxy URI rules, tweak reevolved advance fee second-order metarules, added a test rule for postmaster+abuse missing, FROM_MISSPACED, fix FROM_CONTAINS_TAB, added Facebook redirector pattern, avoided ISO-2022-JP FPs on TVD_SPACE_RATIO, GAPPY_SUBJECT, PLING_QUERY and FM_FRM_RN_L_BRACK rules, FP fix for one-word mails on TVD_SPACE_RATIO, RATWARE_BOUNDARY plus variant, supersede all previous RATWARE_OUTLOOK stuff, added exclusion for __ISO_2022_JP_DELIM to OBFUSCATING_COMMENT, FP in obfuscated URI rule, fixed breakage in tbird image rule, fixed SUBJECT_FUZZY_MEDS FP on unobfuscated "meds", added misspaced From header field rule, numeric+cctld URI rule, ... - added PSBL blacklist - http://psbl.surriel.com/ - added support for http://www.spamhaus.org/css/ - added rule for plain text attachments with octet-stream MIME type; - avoided false positives on ISO-2022-JP messages in several rules; - removed massmailers from uridnsbl_skip_domain in 25_uribl.cf; - updated various default whitelists, uridnsbl_skip_domain, adsp_override, ... PLUGINS - new plugins: FreeMail, PhishTag, Reuse - now enabled by default: DKIM - now disabled by default: AWL - retired plugin: DomainKeys AWL PLUGIN - plugin AWL is now disabled by default; - added new configuration options auto_whitelist_ipv4_mask_len and auto_whitelist_ipv6_mask_len to allow more control on what part of an IP address is stored into an AWL database; - README.awl: increased a suggested awl.ip field width to 40 characters to support IPv6 addresses; - AutoWhitelist.pm: allowed storing a canonicalized IPv6 address, cropped to a configurable network mask (previously causing SQL server errors: 'value too long') - let AWL with SQL keep separate records for DKIM-signed and unsigned mail (when auto_whitelist_distinguish_signed configuration option is true, and a field awl.signedby exists); - avoided a race condition in SQLBasedAddrList.pm when multiple processes try to insert-or-update an awl SQL record: trying INSERT first, and if that fails go for UPDATE; - gracefully handle NaN from corrupted database or a broken emulator or virtualizer; DCC PLUGIN - added support for DCC reputations, added setting dcc_rep_percent, new test check_dcc_reputation_range(), new tag DCCREP (DCC servers supply reputation data only to licensed clients); - allowed usage of a remote dccifd host through an INET or INET6 socket; DKIM PLUGIN - the plugin is now enabled by default; - absolute minimal version of Mail::DKIM is 0.31; support for ADSP requires Mail::DKIM 0.34; a DNS test (and rule) for NXDOMAIN is operational since Mail::DKIM 0.36_5 - a perl module Digest::SHA is required if the DKIM plugin is enabled (if a perl module Digest::SHA is available, the module Digest::SHA1 becomes optional as far as SpamAssassin is concerned (but is still needed by Razor agents)); - added support for multiple signatures (useful for whitelisting); - plugin now distinguishes author domain signatures from third party signatures (useful for whitelisting); - provides a tag DKIMIDENTITY (in addition to DKIMDOMAIN); - DKIM now supports Author Domain Signing Practices - ADSP (RFC 5617); - use the Mail::DKIM::AuthorDomainPolicy instead of Mail::DKIM::DkimPolicy, when available (since Mail::DKIM 0.34); - implements an 'adsp_override' configuration directive and adds an eval:check_dkim_adsp check, which is used by new DKIM_ADSP_* rules; - rules contain an initial set of 'adsp_override' directives, listing some of the more popular target domains for phishing (applicable only to domains which sign all their direct mail with a DKIM or DK signature); - this plugin can now re-use Mail::DKIM verification results if made available by a caller, which saves resources and makes it possible for SpamAssassin to work on a truncated large mail without breaking DKIM signatures; - check_dkim_signed and check_dkim_adsp eval rules can now take an optional list of domain names, which limits their action to listed domains only. It facilitates building DKIM-based rules for specific domains, without having to resort to meta rules; - draft-ietf-dkim-ssp-10/RFC-5617 made Author Domain Signature based on 'd': updated ADSP code accordingly; changed whitelisting code to be based on SDID ('d') instead of AUID ('i'); - Plugin/DKIM.pm: terminology changes in comments and logging according to RFC 5617 and draft-ietf-dkim-rfc4871-errata-07; BUG FIXES - fixed Rule2XSBody segfaults; - no longer treat user data as perl booleans (a string "0" is a false); - avoid data from the wild be interpreted as perl regular expressions; - ArchiveIterator: prevent _scan_directory from passing directories to _scan_file (on NFS it would fail with EISDIR on read(2); - fixed vpopmail support; - fixed incorrect mode bits when creating lock files for AWL; - fixed some cases where :addr headers were parsed incorrectly; - fixed leakage of 'whitelist_from_rcvd' entries between spamd users; - fixing run_and_catch, which failed to catch a non-timed run; - 127/8 isn't an illegal IP; - reworked the M::S::Timeout module to deal with nested timers as one would expect: an inner timer shouldn't be able to extend an outer timer's limit; account for time elapsed in the submitted subroutine when restarting an outer timer; reset() should have accounted for time already spent; - the 'exists:' evaluator in HEADER rules now works as documented and tests for existence of a header field, instead of testing for a header field body being nonempty; internally, the pms->get can also now distinguish between empty and nonexistent header fields; - applied fixes to header fields parsing in several places: header field names are case-insensitive, whitespace is not required after a colon, obsolete rfc822 syntax allowed whitespace before a colon; VBounce: match "Received:" only at the beginning of a line; - fixed bug 6237: 2.0.0.0/8 is now an allocated address range, fixed RCVD_ILLEGAL_IP with IP 2.0.0.0/8 (and 223.0.0.0/8); - fixed bug 6205 comment 5 in URIDetail.pm; - 'pyzor_options' in Plugin/Pyzor.pm was not untainted; - URIDetail plugin was not taint safe, fixed; - fixed parsing of multi-line Received header fields for BOUNCE_MESSAGE/VBOUNCE_MESSAGE et al; - Bug 6206, Bug 2536: spamd: untaint directory as obtained from a password file or from vpopmail utilities, avoid implicit untainting; report error if user preferences file exists but cannot be accessed; - avoid using raw data from DNS as a regexp in Plugin/ASN.pm; - ensured the dbg() and info() calls always return the same value (true) regardless of log level; - suppress logging of $& when its value is not available (i.e. when no regexp has been evaluated during rule evaluation); - Exporter never really worked in SA, was not enclosed in BEGIN {}; - masses/runGA and masses/mk-baseline-results: prevent a shell 'source' command from loading an unrelated file named 'config' which happens to be in the current PATH - must use a ./ in an arg to a 'source' command; ERROR HANDLING, ROBUSTNESS - improved error detection and reporting: test status of all system calls and I/O operations (or explicitly document where not), and report unexpected failures; - eval calls now check for eval result instead of testing the $@, which is not always reliable; - localized $@ and $! in DESTROY methods to prevent potential calls to eval and calls to system routines in code executed from a DESTROY method from clobbering global variables $@ and $!; - Util::helper_app_pipe_open_unix: contain a failing exec with an eval to prevent additional cases of process cloning. The exec could fail this way when given tainted arguments; - Util::helper_app_pipe_open_unix: flush stdout and stderr before forking, otherwise an error reported by exec (such as 'insecure dependency') was lost in a buffer; - eval-protected an open($fh,'-|') to capture implied fork failures due to lack of system resource; - explicit untainting: combine "use re 'taint'" with untaint_var(), avoiding implicit perl untainting, along with workarounds to prevent it; - added 'use strict' where missing; - avoided a bunch of warnings on "Use of uninitialized value" - clearly report reasons for helper application process failures - t/SATest.pm: provide information about the process failure reason if a system() call fails; improved its reporting of failures; - improved error reporting in Plugin/DCC.pm on finding a DCC home directory to facilitate troubleshooting; OTHER CHANGES - pseudoheader "ALL:raw" returns a pristine header section, and pseudoheader "ALL" returns a cleaned header section - total rewrite of URI detection in plain text body; - many updates to the list of top level domains; - added 'util_rb_3tld', allowing 3-level TLDs to be listed in URIBLs and allowing new 3TLDs to be added from rule updates; - avoided trusted_networks bog down due to O(n^2) loop with millions of entries; - applied fixes to Plugin/VBounce.pm, updated VBounce ruleset; - added support for a 'Communigate Pro' Received header field; - parse Communigate Pro "with HTTPU" auth token; - provided a workaround for Net::DNS::Packet::new inconsistency; - let SpamAssassin use either Digest::SHA or Digest::SHA1, whichever is available (the Digest::SHA is now a base module since perl 5.10.0); - improved parsing of eval-type rules: allow unquoted domain names, disallow unmatched quotes; - provided a new module Mail::SpamAssassin::BayesStore::BDB. It should be treated as alpha-quality (needs more testing) and is not yet ready for production use; - exposed existing function 'received_within_months' as an eval function in Plugin/HeaderEval.pm; - use /var/lock/subsys/spamd instead of /var/lock/subsys/spamassassin for rc script, so that 'service spamd status' will work; - re-download MIRRRORED.BY files at least once a week, or if 'sa-update --refreshmirrors' switch is used; - input delimiter $/ can be corrupted by a plugin, localize $/ and $\ before calling a plugin; - takes almost a minute to start spamd on a slow machine, bumped up the retry counter to 90 seconds; - resolved Bug 5325: syslog severity level in spamc/libspamc.c for max message size (changed LOG_ERR into LOG_NOTICE for the message: "skipped message, greater than max message size"); - avoid taint warnings if hostname is returned as '(none)'; - produce an error message if an sa-update channel doesn't exist; - Bug 6150, Bug 6127, Bug 5981, Bug 5950, Bug 6191: let spamd log/report a child process exit status or aborting condition in an informative way; - detect accidental match-everything regexps in rules; - updated garescorer for 3.3.0: use more epochs in GA runs for better scores; clarify some mass-check warning output, ensure rule name always appears at start of line; if a rule had no default/existing score in 50_scores.cf, don't tell the GA that 1.0 is an appropriate default value, instead pick the midway point of its score range. this produces better results; remove some dead code from masses/score-ranges-from-freqs; - report performance as iterations per second in garescorer.c; - added test to ensure that all config settings are correctly handled when switching between users; added more config setting type metadata to enable those tests to work; and fix URIDetail to store config on the {conf} object, not on the plugin; - moved 'release tests' to xt/ directory; mirror long-running, net-tests and stress tests with xt/50_testname.t scripts to enforce their run before a release; - numerous additional and updated self-tests; - added a Test::Perl::Critic release-test; - some code cleanups based on suggestions by a perl module Test::Perl::Critic, among others: . enable TestingAndDebugging::ProhibitNoStrict test but allow the use of 'no strict "refs"'; . deal with BuiltinFunctions::RequireGlobFunction; . deal with ControlStructures::ProhibitMutatingListFunctions removing this exception from xt/60_perlcritic.t; . deal with BayesStore/BDB.pm, Variables::ProhibitConditionalDeclarations . now that the module Time::HiRes is a required module, we can afford to replace a select() with Time::HiRes::sleep, and remove exception BuiltinFunctions::ProhibitSleepViaSelect from xt/60_perlcritic.t - documentation was updated, fixing numerous typos and mistakes in documentation text and in log messages; - extensive improvements to development process: automated testing through Hudson, improvements to mass-check and rules From kevin.kofler at chello.at Mon Dec 7 04:56:51 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 07 Dec 2009 05:56:51 +0100 Subject: Exception request from FESCo for bundled libaries References: <20091206104812.GB8376@lisas.de> Message-ID: Adrian Reber wrote: > I was informed that wordpress uses bundled libraries and would like to > request an exception from FESCo. > > https://bugzilla.redhat.com/show_bug.cgi?id=544720 The right thing to do is to fix the problem, not to request an exception. It is likely to be voted down. I'm not going to vote for an exception if you can't prove that it's truly necessary, and in past precedents, most folks on FESCo felt even stronger about this issue than me. And "upstream does it that way" is NOT a valid reason, you're supposed to patch the code to use the system libraries, it's part of being a maintainer. Kevin Kofler From kevin.kofler at chello.at Mon Dec 7 05:03:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 07 Dec 2009 06:03:15 +0100 Subject: Packages looking for new owners References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200809082312.38592.konrad@tylerc.org> <50baabb30912060525m669fd3dbwfcc8d2ab0d7208c5@mail.gmail.com> <200912061348.13626.cemeyer@u.washington.edu> Message-ID: Conrad Meyer wrote: > Also, SDCC currently does not build (clarification: the software builds > fine. rpmbuild is choking on non-native ar files) Try this: %define __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib/rpm/[^/]*/?brp-strip-static-archive %{__strip}!!g') (It's working fine in tigcc.spec to prevent tigcc.a from being corrupted.) Kevin Kofler From cemeyer at u.washington.edu Mon Dec 7 06:06:07 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Sun, 6 Dec 2009 22:06:07 -0800 Subject: Packages looking for new owners In-Reply-To: References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200912061348.13626.cemeyer@u.washington.edu> Message-ID: <200912062206.07996.cemeyer@u.washington.edu> On Sunday 06 December 2009 09:03:15 pm Kevin Kofler wrote: > Conrad Meyer wrote: > > Also, SDCC currently does not build (clarification: the software builds > > fine. rpmbuild is choking on non-native ar files) > > Try this: > %define __os_install_post %(echo '%{__os_install_post}' | sed -e > 's!/usr/lib/rpm/[^/]*/?brp-strip-static-archive %{__strip}!!g') (It's > working fine in tigcc.spec to prevent tigcc.a from being corrupted.) > > Kevin Kofler Ah, since my earlier email I've fixed the sdcc package under advice from another cross lib maintainer[0]. msp430-libc (and now sdcc) just set __os_install_post to brp-compress; I guess the advantage of sed-ing out only the strip-static-archive is that the native binaries get stripped. I'll try this for sdcc. By the way, perhaps that %define should be changed to %global? [0]: http://article.gmane.org/gmane.linux.redhat.fedora.devel/125372 Thanks, -- Conrad Meyer From rjones at redhat.com Mon Dec 7 10:36:14 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Dec 2009 10:36:14 +0000 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <20091207103614.GI23109@amd.home.annexia.org> On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > https://fedoraproject.org/wiki/Features/Upstart0.6.0 [...] > If you own any of the following packages, you have upstart job files that > will need modified for any needed format changes, and the new location. > > * vpnc rjones [...] > We're willing to do the legwork for you, or you can do the update yourself > once we land 0.6.x; give us a reply with which you'd prefer. See the > feature page for more details on the changes required. I'm quite happy for you to make the changes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From christoph.wickert at googlemail.com Mon Dec 7 11:42:33 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 07 Dec 2009 12:42:33 +0100 Subject: rpms/gnome-shell/devel gnome-shell.spec,1.21,1.22 In-Reply-To: <20091207061305.96FB511C00EE@cvs1.fedora.phx.redhat.com> References: <20091207061305.96FB511C00EE@cvs1.fedora.phx.redhat.com> Message-ID: <1260186153.3323.33.camel@wicktop.localdomain> Am Montag, den 07.12.2009, 06:13 +0000 schrieb Adam Miller: > Author: maxamillion > > Update of /cvs/extras/rpms/gnome-shell/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28650 > > Modified Files: > gnome-shell.spec > Log Message: > Not sure why the autogen.sh isn't found, changing some stuff to test for scratch > builds. We need git so I can branch this and not attack peoples inboxes. Run "make srpm" and do a scratch build of it, no need to commit anything. Regards, Christoph From pbrobinson at gmail.com Mon Dec 7 13:31:54 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 7 Dec 2009 13:31:54 +0000 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <5256d0b0912070531s55e4b687y67aea12b23d66952@mail.gmail.com> > What this means for you (for very specific values of you): > > If you own any of the following packages, you have upstart job files that > will need modified for any needed format changes, and the new location. > > * olpc-utils ? ? ? ? ? ?pbrobinson > > We're willing to do the legwork for you, or you can do the update yourself > once we land 0.6.x; give us a reply with which you'd prefer. See the > feature page for more details on the changes required. I'm quite happy for you to make the changes. Cheers, Peter From pmatilai at redhat.com Mon Dec 7 13:32:59 2009 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 7 Dec 2009 15:32:59 +0200 (EET) Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide Message-ID: Now that FESCo has approved new major RPM version for F-13 and the public beta is officially out... it's going to hit rawhide in a few hours. Couple of practical issues: - Soname bump is involved, so anything directly linking to librpm needs to be rebuilt. This includes deltarpm, gdb, net-snmp, abrt and a few others. - The new version has integrated support for extracting OCaml dependencies, this clashes with the existing ocaml-dependency extraction mechanism in Fedora. Notably rpm-build conflicts with current ocaml-runtime, and the ocaml build-macros need updating to let the integrated pieces do their work. And of course, watch out for regressions: >From Fedora POV perhaps the biggest suspect is the python bindings as they've seen a pretty dramatic cleanup and revamp all over. It's supposed to be compatible for the commonly used parts (eg yum certainly works fine with it) but I'd be rather surprised if some rarely used dark corner hasn't broken up. Another thing to watch out for is installation (and erasure) ordering. The algorithm has been pretty much rewritten and produces significantly different orderings than the previous one. However note that different != incorrect, the old algorithm completely blew it up in various dependency loop cases etc. So if something worked with the previous versions but no longer does with the new beta, it doesn't automatically mean it's a bug in the new ordering code: you might've just been lucky. Any regressions in this area need to be carefully analyzed case by case to determine whether they're true regressions or just incorrect dependencies in packages. - Panu - From a.badger at gmail.com Mon Dec 7 15:21:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 7 Dec 2009 07:21:18 -0800 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <20091206104812.GB8376@lisas.de> References: <20091206104812.GB8376@lisas.de> Message-ID: <20091207152118.GA10167@clingman.lan> On Sun, Dec 06, 2009 at 11:48:12AM +0100, Adrian Reber wrote: > > I was informed that wordpress uses bundled libraries and would like to > request an exception from FESCo. > > https://bugzilla.redhat.com/show_bug.cgi?id=544720 > You need to have an explanation of why an exception would be appropriate. Bundling libraries is, among other things, a potential security hazard which means that people are able to get connected to the place. When formulating the explanation, remember that you have to make the case that unbundling libraries would be harmful and that the problems outlined on this page: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rjones at redhat.com Mon Dec 7 16:14:43 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Dec 2009 16:14:43 +0000 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: References: Message-ID: <20091207161443.GA29653@amd.home.annexia.org> On Mon, Dec 07, 2009 at 03:32:59PM +0200, Panu Matilainen wrote: > - The new version has integrated support for extracting OCaml > dependencies, this clashes with the existing ocaml-dependency > extraction mechanism in Fedora. Notably rpm-build conflicts with current > ocaml-runtime, and the ocaml build-macros need updating to let the > integrated pieces do their work. Ah, that answers the question I was about to ask :-) I'll rebuild the OCaml base package to cope with this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Mon Dec 7 16:19:03 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 7 Dec 2009 16:19:03 +0000 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: <20091207161443.GA29653@amd.home.annexia.org> References: <20091207161443.GA29653@amd.home.annexia.org> Message-ID: <20091207161903.GB29653@amd.home.annexia.org> I'm tracking this in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=545116 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 From snecklifter at gmail.com Mon Dec 7 19:25:14 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 7 Dec 2009 19:25:14 +0000 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <20091207152118.GA10167@clingman.lan> References: <20091206104812.GB8376@lisas.de> <20091207152118.GA10167@clingman.lan> Message-ID: <364d303b0912071125i7f82072epa397462f57fa65b3@mail.gmail.com> 2009/12/7 Toshio Kuratomi : > On Sun, Dec 06, 2009 at 11:48:12AM +0100, Adrian Reber wrote: >> >> I was informed that wordpress uses bundled libraries and would like to >> request an exception from FESCo. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=544720 >> > You need to have an explanation of why an exception would be appropriate. > Bundling libraries is, among other things, a potential security hazard which > means that people are able to get connected to the place. ?When formulating > the explanation, remember that you have to make the case that unbundling > libraries would be harmful and that the problems outlined on this page: > > ?https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries It looks like there is a clear advantage to shipping _without_ bundled libraries anyway as the wordpress people keep having to update their bundled bits for security and feature reasons... But anyway, I think Adrian gets the message now .... :) -- Christopher Brown From tomek at pipebreaker.pl Mon Dec 7 21:30:30 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Mon, 7 Dec 2009 22:30:30 +0100 Subject: Upstart 0.6.3 coming to a rawhide near you In-Reply-To: <20091204211034.GB27613@nostromo.devel.redhat.com> References: <20091204211034.GB27613@nostromo.devel.redhat.com> Message-ID: <20091207213030.GD6007@mother.pipebreaker.pl> On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: > https://fedoraproject.org/wiki/Features/Upstart0.6.0 > > was approved at today's FESCo meeting. We hope to land this in the next > week or so. > > If you own any of the following packages, you have upstart job files that > will need modified for any needed format changes, and the new location. > * hdapsd ttorcz hdapsd is ready in version 20090401-5. -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzichubg at chrome.pl "God is more forgiving." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available URL: From kevin.kofler at chello.at Mon Dec 7 22:13:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 07 Dec 2009 23:13:21 +0100 Subject: Packages looking for new owners References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200912061348.13626.cemeyer@u.washington.edu> <200912062206.07996.cemeyer@u.washington.edu> Message-ID: Conrad Meyer wrote: > I guess the advantage of sed-ing out only the strip-static-archive is that > the native binaries get stripped. Right. Otherwise you end up with unstripped binaries and no or an empty -debuginfo package, not quite ideal. > By the way, perhaps that %define should be changed to %global? They all should. All my specfiles are still stuck with %define, I guess I'll never get used to the newly-recommended syntax. :-( Kevin Kofler From fedora at matbooth.co.uk Mon Dec 7 22:29:08 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 7 Dec 2009 22:29:08 +0000 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: References: Message-ID: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> 2009/12/7 Panu Matilainen : > > Now that FESCo has approved new major RPM version for F-13 and the public > beta is officially out... it's going to hit rawhide in a few hours. > I remember hearing a rumour about automagic OSGi dependency resolution... Is that something that's likely to appear in the near future? -- Mat Booth From sundaram at fedoraproject.org Mon Dec 7 22:40:39 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Dec 2009 04:10:39 +0530 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> References: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> Message-ID: <4B1D8467.3070403@fedoraproject.org> On 12/08/2009 03:59 AM, Mat Booth wrote: > 2009/12/7 Panu Matilainen >> >> Now that FESCo has approved new major RPM version for F-13 and the public >> beta is officially out... it's going to hit rawhide in a few hours. >> > > > I remember hearing a rumour about automagic OSGi dependency > resolution... Is that something that's likely to appear in the near > future? http://rpm.org/wiki/Releases/4.8.0 mentions it. Rahul From awilliam at redhat.com Mon Dec 7 22:55:57 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 07 Dec 2009 14:55:57 -0800 Subject: Fedora release criteria completely revised Message-ID: <076d60721cac4a9affc7c22ac0354c71@mailserver> During FUDCon, we've been working on revising the Fedora release criteria. John Poelstra had already fleshed out a structure and much of the final content, and we've been revising and tweaking it in conjunction with QA (myself, Will Woods and James Laska), release engineering (Jesse Keating), anaconda team (especially Denise Dumas and Peter Jones) and desktop team (Christopher Aillon and Matthias Clasen, who provided suggestions at an earlier stage). The new structure is based around a general page and specific pages for the Fedora 13 Alpha, Beta and Final releases (which have been written generically so they can easily be converted into pages for F14 and all future releases just by copying and pasting). You can find the criteria here: https://fedoraproject.org/wiki/Fedora_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria they should contain everything you need to know. We based most of the criteria around testing that was already being carried out but with no formal policy basis, with additional suggestions from the anaconda and desktop teams. We will follow these criteria for the Fedora 13 release process. So if you can see any problems or potential trouble with any of this, please do reply and let us know! Desktop team - can you please let us know of any additional things that you would expect to be working at each point during the release cycle? Note that only things that *must* be working at each point should be listed on these pages, not nice-to-haves. You must be able to commit to the idea that, if any criterion on the page is not met, we would slip the release in question. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Mon Dec 7 23:02:58 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Dec 2009 04:32:58 +0530 Subject: Fedora 13 Alpha Release Notes Message-ID: <4B1D89A2.1060005@fedoraproject.org> Hi I have put up a very early draft at https://fedoraproject.org/wiki/Fedora_13_Alpha_release_notes Please add important changes to the release notes. This would include new features, notable changes in behavior from the previous release, things that need explicit testing and any known issues. Rahul From sundaram at fedoraproject.org Mon Dec 7 23:20:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Dec 2009 04:50:00 +0530 Subject: Parallel XZ - request for testing In-Reply-To: <20091202133951.GA8760@dhcp-lab-133.englab.brq.redhat.com> References: <20091202133951.GA8760@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <4B1D8DA0.8030606@fedoraproject.org> On 12/02/2009 07:09 PM, Jindrich Novy wrote: > Hi all, > > the Parallel XZ just reached usable state so if you want to take > advantage of parallel LZMA compression, please give it a try before > its inclusion into Fedora. > > PXZ homepage is: > http://jnovy.fedorapeople.org/pxz/ Are you moving this to fedorahosted.org? Are you proposing this as a feature in Fedora 13? Rahul From jussilehtola at fedoraproject.org Mon Dec 7 23:32:57 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Tue, 08 Dec 2009 01:32:57 +0200 Subject: Deprecation of LAM/MPI? Message-ID: <1260228777.6753.15.camel@localhost> Hi, First of all, I'm not the maintainer of LAM, but since Doug seems to be busy with other things I took the liberty of taking things into my own hands: I really would like everything to confer to the MPI guidelines in Fedora 13, but the problem is that so far no-one has volunteered to rework the LAM/MPI package to conform to the new guidelines [1]. IMHO LAM/MPI could be safely pulled out from Fedora 13, since it was obsoleted by Open MPI 3 years ago. Any thoughts? Does someone care deeply enough about LAM to take ownership and fix the package? [1] https://bugzilla.redhat.com/show_bug.cgi?id=523998 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From pmatilai at laiskiainen.org Tue Dec 8 06:31:20 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 8 Dec 2009 08:31:20 +0200 (EET) Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> References: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> Message-ID: On Mon, 7 Dec 2009, Mat Booth wrote: > 2009/12/7 Panu Matilainen : >> >> Now that FESCo has approved new major RPM version for F-13 and the public >> beta is officially out... it's going to hit rawhide in a few hours. >> > > > I remember hearing a rumour about automagic OSGi dependency > resolution... Is that something that's likely to appear in the near > future? You're probably thinking of this: http://fedoraproject.org/wiki/Features/OSGiAutoDeps Rpm has carried the OSGi dep extractor script for couple of years now, but it doesn't get run automatically. - Panu - From johannbg at hi.is Tue Dec 8 07:11:52 2009 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Tue, 08 Dec 2009 07:11:52 +0000 Subject: Fedora release criteria completely revised In-Reply-To: <076d60721cac4a9affc7c22ac0354c71@mailserver> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <4B1DFC38.7070708@hi.is> On 12/07/2009 10:55 PM, Adam Williamson wrote: In https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria under "Beta Release Requirements", Item 10 "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually". Does this mean that the Fedora officially "Supports" upgrades now? If so dont application need to be backwards compatible and QA and Doc team be noted if they are not. If it's not officially supported why is it in the "Beta Release Requirements"? JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 372 bytes Desc: not available URL: From pekkas at netcore.fi Tue Dec 8 08:33:37 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 8 Dec 2009 10:33:37 +0200 (EET) Subject: F12 updates-testing issue: X flickers and fails to start Message-ID: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by "yum history undo 1" which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dcbw at redhat.com Tue Dec 8 09:50:56 2009 From: dcbw at redhat.com (Dan Williams) Date: Tue, 08 Dec 2009 01:50:56 -0800 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: References: Message-ID: <1260265856.2138.4.camel@localhost.localdomain> On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: > Hi, > > On my laptop, after F12 updates-testing update today, after reboot F > logo shows but then the screen goes dark and starts flickering between > various shades of dark (changing modes?) with intel graphics chipset > (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using > a previous kernel didn't help. Booting to runlevel 3 and running > system-config-display (--reconfig) resulted in the same. > > I've worked around the issue by "yum history undo 1" which rolled > back a couple of hundred packages. > > Any idea which package could be the culprit and I should file a bug > against or to isolate it? Somehow I don't think this is necessarily > an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. Dan > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From andy at warmcat.com Tue Dec 8 09:52:41 2009 From: andy at warmcat.com (Andy Green) Date: Tue, 08 Dec 2009 10:52:41 +0100 Subject: Fedora release criteria completely revised In-Reply-To: <076d60721cac4a9affc7c22ac0354c71@mailserver> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <4B1E21E9.4060305@warmcat.com> On 12/07/09 23:55, Somebody in the thread at some point said: Hi - > these pages, not nice-to-haves. You must be able to commit to the idea > that, if any criterion on the page is not met, we would slip the release in > question. I think it's great you guys are looking to increase Quality-with-a-capital-Q. ''9 There must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login'' https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria It might be wise to specify on what particular set of test machines or platforms you want to see not abrt stuff from. Because current F12 kernels kill a 4-core box here and iwlagn gives abrt warnings on this laptop, but it's still otherwise fine as a released kernel. It's not realistic to hold a release until the kernel never crashes on any platform. -Andy From panemade at gmail.com Tue Dec 8 10:33:18 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Tue, 8 Dec 2009 16:03:18 +0530 Subject: orphaned packages Message-ID: Hi, I have orphaned 2 packages and have plans to retire them from rawhide. 1) Since last 3 years I am the maintainer for scanbuttond package. I have one RFE bug open for this package but didn't get time to work on it as I have no scanner with me to work on it. This package has not seen any upstream release since its initial version in fedora 0.2.3 which was released in 2006-02-17. Now I have orphaned it and thinking there should not be any peoples using it. 2) v4l2-tool package is also orphaned. I am the upstream developer as well as Fedora package maintainer for this. I have stopped development on this as I have no time and no webcam device to work on. The last upstream release for this packages was on 28 august 2007. In case someone is still using these packages and want to maintain them then please follow https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure. Regards, Parag. From promac at gmail.com Tue Dec 8 11:51:55 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 8 Dec 2009 09:51:55 -0200 Subject: Why pavucontrol is not installed by default? Message-ID: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> I did a clean install of Fedora 12 and realized that pavucontrol was not installed by default. I have two sound cards and I only got sound when I manually installed pavucontrol and used it. Any reason? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomek at pipebreaker.pl Tue Dec 8 11:59:34 2009 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Tue, 8 Dec 2009 12:59:34 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> Message-ID: <20091208115934.GE6007@mother.pipebreaker.pl> On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > I did a clean install of Fedora 12 and realized > that pavucontrol was not installed by default. > I have two sound cards and I only got sound when > I manually installed pavucontrol and used it. > > Any reason? > pavucontrol is regarded as advance tool, but also partly obsolete. Current gnome-volume-control superseded most of its functionality: controlling different streams volume, switching profile, outputs, fallback devices. -- Tomasz Torcz "Funeral in the morning, IDE hacking xmpp: zdzichubg at chrome.pl in the afternoon and evening." - Alan Cox From fedora at matbooth.co.uk Tue Dec 8 13:01:11 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 8 Dec 2009 13:01:11 +0000 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: References: <9497e9990912071429j4a85d8e0mbaf17b57ce1d6e0d@mail.gmail.com> Message-ID: <9497e9990912080501n4d3631baqa12bf9d4abd8e069@mail.gmail.com> 2009/12/8 Panu Matilainen : > On Mon, 7 Dec 2009, Mat Booth wrote: > >> 2009/12/7 Panu Matilainen : >>> >>> Now that FESCo has approved new major RPM version for F-13 and the public >>> beta is officially out... it's going to hit rawhide in a few hours. >>> >> >> >> I remember hearing a rumour about automagic OSGi dependency >> resolution... Is that something that's likely to appear in the near >> future? > > You're probably thinking of this: > http://fedoraproject.org/wiki/Features/OSGiAutoDeps > Yes, that must be where I saw it. > Rpm has carried the OSGi dep extractor script for couple of years now, but > it doesn't get run automatically. > Is it not reliable enough? -- Mat Booth From akurtako at redhat.com Tue Dec 8 13:15:24 2009 From: akurtako at redhat.com (Alexander Kurtakov) Date: Tue, 8 Dec 2009 15:15:24 +0200 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: <9497e9990912080501n4d3631baqa12bf9d4abd8e069@mail.gmail.com> References: <9497e9990912080501n4d3631baqa12bf9d4abd8e069@mail.gmail.com> Message-ID: <200912081515.24900.akurtako@redhat.com> > 2009/12/8 Panu Matilainen : > > On Mon, 7 Dec 2009, Mat Booth wrote: > >> 2009/12/7 Panu Matilainen : > >>> Now that FESCo has approved new major RPM version for F-13 and the > >>> public beta is officially out... it's going to hit rawhide in a few > >>> hours. > >> > >> I remember hearing a rumour about automagic OSGi dependency > >> resolution... Is that something that's likely to appear in the near > >> future? > > > > You're probably thinking of this: > > http://fedoraproject.org/wiki/Features/OSGiAutoDeps > > Yes, that must be where I saw it. > > > Rpm has carried the OSGi dep extractor script for couple of years now, > > but it doesn't get run automatically. > > Is it not reliable enough? > Hi Mat, Look at bug https://bugzilla.redhat.com/show_bug.cgi?id=488352 . I think that some of the packages that need applying patches are yours :) so you can speed up the process a bit. Hopefully once we verify it is good enough for several Eclipse plugins it can be enabled by default. Regards, Alex From limb at jcomserv.net Tue Dec 8 13:26:31 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 08 Dec 2009 07:26:31 -0600 Subject: orphaning dblatex In-Reply-To: <4B13EE73.7060900@jcomserv.net> References: <4B13EE73.7060900@jcomserv.net> Message-ID: <4B1E5407.9040002@jcomserv.net> Jon Ciesla wrote: > Neal Becker wrote: >> I no longer wish to maintain dblatex. Any takers? >> >> > I can if none of the co-maintainers want it. > -J > Ping? -- in your fear, seek only peace in your fear, seek only love -d. bowie From icon at fedoraproject.org Tue Dec 8 13:29:29 2009 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 8 Dec 2009 08:29:29 -0500 Subject: Useless setroubleshoot alerts Message-ID: >From the point of view of security usability, this is cardinal sin: http://file.status.net/identica/tieguy-20091208T063036-ngc2rhp.png If we start the warning message with "SELinux has detected suspicious behaviour on your system" and end it with "You can safely ignore this avc," then we are doing everyone a nasty disservice. Please, let's fix it as soon as possible. I understand the need for SELinux to log things purely for auditing purposes, but the user must NOT see those alerts, or we'll condition everyone to just dismiss them. I'm fairly certain this is a bug, but I've not yet bz'd it, as I wanted to make sure that this is not "intended behaviour." Regards, -- McGill University IT Security Konstantin Ryabitsev Montr?al, Qu?bec From kevin.kofler at chello.at Tue Dec 8 14:07:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 08 Dec 2009 15:07:21 +0100 Subject: Fedora release criteria completely revised References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: Adam Williamson wrote: > During FUDCon, we've been working on revising the Fedora release criteria. > John Poelstra had already fleshed out a structure and much of the final > content, and we've been revising and tweaking it in conjunction with QA > (myself, Will Woods and James Laska), release engineering (Jesse Keating), > anaconda team (especially Denise Dumas and Peter Jones) and desktop team > (Christopher Aillon and Matthias Clasen, who provided suggestions at an > earlier stage). So once again things get decided by a small group of people in an in-person meeting and whoever didn't happen to be at the right place at the right time only gets to know the final decision after the fact? :-( I've complained many times about this lack of transparency and I'll continue to do so. Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks present at FUDCon.) Are you planning to ship Fedora 13 even if the KDE Live image is broken? Kevin Kofler From cmadams at hiwaay.net Tue Dec 8 14:13:24 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 8 Dec 2009 08:13:24 -0600 Subject: Fedora release criteria completely revised In-Reply-To: References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <20091208141324.GA1225108@hiwaay.net> Once upon a time, Kevin Kofler said: > So once again things get decided by a small group of people in an in-person > meeting and whoever didn't happen to be at the right place at the right time > only gets to know the final decision after the fact? :-( I've complained > many times about this lack of transparency and I'll continue to do so. Please give the conspiracy theories a rest. A meeting at a Fedora conference is hardly a "lack of transparency". Do you expect people to attend a FUDCon, sit in a room, and not talk about anything Fedora related, lest you be left out? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From walters at verbum.org Tue Dec 8 14:19:35 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 8 Dec 2009 09:19:35 -0500 Subject: Fedora release criteria completely revised In-Reply-To: <076d60721cac4a9affc7c22ac0354c71@mailserver> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: Hi Adam, Looks really great in general! One specific comment, for Final 9; I think we need a more specific definition of "and subsequent login". Does that mean that you just type your username/password and look at the default desktop? Are we scoping in any specific apps (firefox?) Under any specific use cases (websites, random plugins?). Any other apps? (I see just now someone else commented on this specific criteria, but instead asking about hardware). My take is we should just scope it to critpath (i.e. enough of the desktop to run packagekit), and have some sort of separate criteria/process for applications. On Mon, Dec 7, 2009 at 5:55 PM, Adam Williamson wrote: > During FUDCon, we've been working on revising the Fedora release criteria. > John Poelstra had already fleshed out a structure and much of the final > content, and we've been revising and tweaking it in conjunction with QA > (myself, Will Woods and James Laska), release engineering (Jesse Keating), > anaconda team (especially Denise Dumas and Peter Jones) and desktop team > (Christopher Aillon and Matthias Clasen, who provided suggestions at an > earlier stage). > > The new structure is based around a general page and specific pages for the > Fedora 13 Alpha, Beta and Final releases (which have been written > generically so they can easily be converted into pages for F14 and all > future releases just by copying and pasting). You can find the criteria > here: > > https://fedoraproject.org/wiki/Fedora_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria > > they should contain everything you need to know. We based most of the > criteria around testing that was already being carried out but with no > formal policy basis, with additional suggestions from the anaconda and > desktop teams. > > We will follow these criteria for the Fedora 13 release process. So if you > can see any problems or potential trouble with any of this, please do reply > and let us know! > > Desktop team - can you please let us know of any additional things that you > would expect to be working at each point during the release cycle? Note > that only things that *must* be working at each point should be listed on > these pages, not nice-to-haves. You must be able to commit to the idea > that, if any criterion on the page is not met, we would slip the release in > question. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From awilliam at redhat.com Tue Dec 8 15:12:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 08 Dec 2009 10:12:09 -0500 Subject: Fedora release criteria completely revised In-Reply-To: References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <1260285129.22036.10.camel@vaio.local.net> On Tue, 2009-12-08 at 15:07 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > During FUDCon, we've been working on revising the Fedora release criteria. > > John Poelstra had already fleshed out a structure and much of the final > > content, and we've been revising and tweaking it in conjunction with QA > > (myself, Will Woods and James Laska), release engineering (Jesse Keating), > > anaconda team (especially Denise Dumas and Peter Jones) and desktop team > > (Christopher Aillon and Matthias Clasen, who provided suggestions at an > > earlier stage). > > So once again things get decided by a small group of people in an in-person > meeting and whoever didn't happen to be at the right place at the right time > only gets to know the final decision after the fact? :-( Nope. This has been discussed for several weeks now. John Poelstra posted the initial draft to test-list on November 20th, and asked for feedback: https://www.redhat.com/archives/fedora-test-list/2009-November/msg00926.html He posted a further request for feedback on December 2nd, with an explicit explanation that we would be gathering to finish working on the pages at FUDCon: https://www.redhat.com/archives/fedora-test-list/2009-December/msg00047.html It was also brought up at each QA group meeting during this time. All the feedback that was received in response to any of those requests was considered for the page either before or at FUDCon. This is not really about 'deciding things', it's about documenting an existing process. Everything in the criteria is either based on the existing QA acceptance test plan or has been requested by the anaconda or desktop teams. > I've complained > many times about this lack of transparency and I'll continue to do so. I don't think complaint is justified in this case. It was a perfectly transparent process. There was a lot of opportunity to feed in. > Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks > present at FUDCon.) We had a pre-hackfest meeting for the whole FUDCon attendee list where everyone who wanted to hack on something stood up and announced what they would be hacking on. John Poelstra announced at that meeting that we would be gathering to work on the release criteria. The KDE people who were at FUDCon were at that meeting, so they were in a position to know about the work. I was running around all day telling people what we were working on, it wasn't a secret. > Are you planning to ship Fedora 13 even if the KDE Live > image is broken? That depends on whether you want us to or not. :) If a SIG has criteria they want to add to the list, and they can commit to fulfilling those criteria and be willing to take the responsibility of causing a release to slip if they _don't_ fulfill them, we can certainly add those to the lists. If KDE has minimum functional levels for the KDE spin that they can commit to, please do send them to this thread and we'll look at putting them in the criteria. We intentionally didn't specifically address the issue of the relative 'importance' of spins in the criteria as it's a difficult topic and one that's not really appropriate to decide in this place. The existing criteria didn't address this either - they didn't say anything about _any_ spin having to be not 'broken' before we ship - so there's no change there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dledford at redhat.com Tue Dec 8 15:44:14 2009 From: dledford at redhat.com (Doug Ledford) Date: Tue, 08 Dec 2009 10:44:14 -0500 Subject: Deprecation of LAM/MPI? In-Reply-To: <1260228777.6753.15.camel@localhost> References: <1260228777.6753.15.camel@localhost> Message-ID: <4B1E744E.1050003@redhat.com> On 12/07/2009 06:32 PM, Jussi Lehtola wrote: > Hi, > > > > First of all, I'm not the maintainer of LAM, but since Doug seems to be > busy with other things I took the liberty of taking things into my own > hands: > > I really would like everything to confer to the MPI guidelines in Fedora > 13, but the problem is that so far no-one has volunteered to rework the > LAM/MPI package to conform to the new guidelines [1]. IMHO LAM/MPI could > be safely pulled out from Fedora 13, since it was obsoleted by Open MPI > 3 years ago. > > Any thoughts? Does someone care deeply enough about LAM to take > ownership and fix the package? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=523998 > There has been no public response to this, and Jussi has indicated in the referenced bugzilla that at least one former lam board member is advocating for the package's removal. The current plan is to block lam from rawhide. If someone decides later that they wish to take over ownership of lam, then we can always unblock it. However, this does mean that the few lam using packages out there will need to be rebuilt to remove their lam subpackages and dependency. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Tue Dec 8 16:12:13 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 8 Dec 2009 17:12:13 +0100 Subject: Deprecation of LAM/MPI? In-Reply-To: <4B1E744E.1050003@redhat.com> References: <1260228777.6753.15.camel@localhost> <4B1E744E.1050003@redhat.com> Message-ID: <20091208161213.GB2901@free.fr> On Tue, Dec 08, 2009 at 10:44:14AM -0500, Doug Ledford wrote: > > There has been no public response to this, and Jussi has indicated in > the referenced bugzilla that at least one former lam board member is > advocating for the package's removal. The current plan is to block lam > from rawhide. If someone decides later that they wish to take over > ownership of lam, then we can always unblock it. However, this does > mean that the few lam using packages out there will need to be rebuilt > to remove their lam subpackages and dependency. I doubt lam users are on this list: lam users are certainly users who favor stability over change, and are likely not to be that much interested in fedora, and even less in fedora development. If I still used fedora, I would have liked to have lam kept in fedora, but I don't use fedora anymore. In the end it really depend how much you want to keep/attract users interested in stability versus the cost of maintaining software for those users given that fedora is unlikely to be in their distributions of choice. -- Pat From robinstar1574 at gmail.com Tue Dec 8 16:27:32 2009 From: robinstar1574 at gmail.com (Rallias UberNerd) Date: Tue, 08 Dec 2009 10:27:32 -0600 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> Message-ID: On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler wrote: > Bill McGonigle wrote: >> "Are you installing Fedora on the computer you're using now?" [YES] >> [NO] >> YES -> is any sort of check even possible if the user is running >> 32-bit on 64-bit? > > Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU > and > using the 32-bit version is suboptimal. > > Kevin Kofler > But wouldn't it be better to use 32 bit when less then 4 GB of ram is present? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From robinstar1574 at gmail.com Tue Dec 8 16:27:44 2009 From: robinstar1574 at gmail.com (Rallias UberNerd) Date: Tue, 08 Dec 2009 10:27:44 -0600 Subject: Vote for the bug (was Re: Local users get to play root?) In-Reply-To: <08EA989E-C81D-4B2B-A762-F11415776106@j2solutions.net> References: <4B0429F3.8010500@nodata.co.uk> <4B042B58.5080708@fedoraproject.org> <4B05095F.80705@fedoraproject.org> <1258622387.7407.3.camel@shrek.rexursive.com> <4B0514A1.70907@fedoraproject.org> <1258626090.7407.5.camel@shrek.rexursive.com> <4B051BB1.5060505@fedoraproject.org> <1258627962.7407.24.camel@shrek.rexursive.com> <4B05241E.6020101@fedoraproject.org> <1258630140.7407.28.camel@shrek.rexursive.com> <1258663847.2963.0.camel@localhost> <4B05B48E.10105@fedoraproject.org> <1258666131.18044.7.camel@shrek.rexursive.com> <4B05BDCD.7020504@pobox.com> <08EA989E-C81D-4B2B-A762-F11415776106@j2solutions.net> Message-ID: On Thu, 19 Nov 2009 18:48:45 -0600, Jesse Keating wrote: > > > On Nov 19, 2009, at 13:51, Jeff Garzik wrote: > >> >> Note to all... >> >> Please add your vote to >> https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local >> console users get to install signed software on a machine they do not >> have the root password to) >> >> I agree with Rahul that it is less productive to "+1" on this email >> thread. >> >> Jeff >> >> >> > > Yes because what we really need here is more noise... > > Please do /not/ pile on to the bug. It will not help no matter what your > opinion is. > > -- > Jes > So why is everyone replying to it? Think about it. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From fedora at matbooth.co.uk Tue Dec 8 17:30:23 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 8 Dec 2009 17:30:23 +0000 Subject: Heads-up: RPM 4.8.0-beta1 about to hit rawhide In-Reply-To: <200912081515.24900.akurtako@redhat.com> References: <9497e9990912080501n4d3631baqa12bf9d4abd8e069@mail.gmail.com> <200912081515.24900.akurtako@redhat.com> Message-ID: <9497e9990912080930s232f9fbbn7ae1387d45439371@mail.gmail.com> 2009/12/8 Alexander Kurtakov : >> 2009/12/8 Panu Matilainen : >> > On Mon, 7 Dec 2009, Mat Booth wrote: >> >> 2009/12/7 Panu Matilainen : >> >>> Now that FESCo has approved new major RPM version for F-13 and the >> >>> public beta is officially out... it's going to hit rawhide in a few >> >>> hours. >> >> >> >> I remember hearing a rumour about automagic OSGi dependency >> >> resolution... Is that something that's likely to appear in the near >> >> future? >> > >> > You're probably thinking of this: >> > http://fedoraproject.org/wiki/Features/OSGiAutoDeps >> >> Yes, that must be where I saw it. >> >> > Rpm has carried the OSGi dep extractor script for couple of years now, >> > but it doesn't get run automatically. >> >> Is it not reliable enough? >> > Hi Mat, > Look at bug https://bugzilla.redhat.com/show_bug.cgi?id=488352 . I think that > some of the packages that need applying patches are yours :) so you can speed > up the process a bit. Hopefully once we verify it is good enough for several > Eclipse plugins it can be enabled by default. > > Regards, > Alex > Aha, I didn't know about that bug; thanks for the pointer. -- Mat Booth From drago01 at gmail.com Tue Dec 8 17:41:58 2009 From: drago01 at gmail.com (drago01) Date: Tue, 8 Dec 2009 18:41:58 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> Message-ID: On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd wrote: > On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler > wrote: > >> Bill McGonigle wrote: >>> >>> "Are you installing Fedora on the computer you're using now?" [YES] ?[NO] >>> ?YES -> is any sort of check even possible if the user is running >>> 32-bit on 64-bit? >> >> Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and >> using the 32-bit version is suboptimal. >> >> ? ? ? ?Kevin Kofler >> > But wouldn't it be better to use 32 bit when less then 4 GB of ram is > present? no, using x86_64 means more registers, sse2 as default floating point instruction set, better calling convention (register passing vs. stack) or in other words in most cases faster code. From rc040203 at freenet.de Tue Dec 8 17:47:58 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Dec 2009 18:47:58 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> Message-ID: <4B1E914E.9010706@freenet.de> On 12/08/2009 06:41 PM, drago01 wrote: > On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd > wrote: >> On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Kofler >> wrote: >> >>> Bill McGonigle wrote: >>>> >>>> "Are you installing Fedora on the computer you're using now?" [YES] [NO] >>>> YES -> is any sort of check even possible if the user is running >>>> 32-bit on 64-bit? >>> >>> Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and >>> using the 32-bit version is suboptimal. >>> >>> Kevin Kofler >>> >> But wouldn't it be better to use 32 bit when less then 4 GB of ram is >> present? > > no, using x86_64 means more registers, sse2 as default floating point > instruction set, better calling convention (register passing vs. > stack) or in other words in most cases faster code. That's one side, the other side is: * Larger demands on RAM (x86_64 is more demanding on memory requirements). * More packages (rpms) to cope with. * The "faster" is hardly sensible to ordinary users. Ralf From gmaxwell at gmail.com Tue Dec 8 19:02:46 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 8 Dec 2009 14:02:46 -0500 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1E914E.9010706@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> Message-ID: On Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius wrote: > That's one side, the other side is: > * Larger demands on RAM (x86_64 is more demanding on memory > ?requirements). Even if it were a full doubling (which is the absolute worst case possible), it would only be pushing the effective cost of memory back roughly 18 months or so. In reality the increase should be much less than 2x. > * More packages (rpms) to cope with. Hmm? I'm not sure what you're talking about there. It's completely reasonable to run an exclusively x86_64 system. I don't see why it implies any more packages. > * The "faster" is hardly sensible to ordinary users. You could equally say that the difference in memory consumption is not relevant to most ordinary users. Performance matters to everyone at least sometimes, but memory is only a big issue when you don't have enough. I think very few people running fedora are all that low on memory. Fedora has already chosen to make the 32bit builds incompatible with pre-686 systems for performance gains much smaller than you typically get from x86_64 vs x86, so it seems that some people think that performance is pretty important. Even the most undemanding users care about performance in at least some areas, for example on any given hardware x86_64 libtheora can play larger videos than 32-bit. On some hardware x86_64 vs 32bit is the difference between good and bad 1080p playback. I think if your position is that most users don't care about performance and other things (like compatibility) are more important then you should strongly promote x86_64 Fedora for everyone who can use it. If x86_64 fedora is widely used by those who can there will be less pressure to put leading-edge but less compatible features into the 32bit fedora build. From jonathan at jonmasters.org Tue Dec 8 19:05:32 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Tue, 08 Dec 2009 14:05:32 -0500 Subject: Why pavucontrol is not installed by default? In-Reply-To: <20091208115934.GE6007@mother.pipebreaker.pl> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> Message-ID: <1260299132.3027.368.camel@tonnant> On Tue, 2009-12-08 at 12:59 +0100, Tomasz Torcz wrote: > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > I did a clean install of Fedora 12 and realized > > that pavucontrol was not installed by default. > > I have two sound cards and I only got sound when > > I manually installed pavucontrol and used it. > > Any reason? > pavucontrol is regarded as advance tool, but also partly > obsolete. Current gnome-volume-control superseded most of > its functionality: controlling different streams volume, > switching profile, outputs, fallback devices. The new gnome-volume-control is so cut-down it's not useful to me. In the quest to be more Mac-like in removing mixer controls (and not even having any obvious "advanced" mode), I now have a choice of no audio or having full volume LFE output *and* whatever mixer level I have set for the master output. alsamixer works fine, but then I can't use the volume sliders on my desktop and it gets rather awkward. I still pine for the days of isapnpdump when I had to do all the heavy lifting by hand, but it worked 100% of the time. Jon. From jcm at redhat.com Tue Dec 8 19:07:46 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 08 Dec 2009 14:07:46 -0500 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> Message-ID: <1260299266.3027.370.camel@tonnant> On Tue, 2009-12-08 at 18:41 +0100, drago01 wrote: > On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd > > But wouldn't it be better to use 32 bit when less then 4 GB of ram is > > present? > > no, using x86_64 means more registers, sse2 as default floating point > instruction set, better calling convention (register passing vs. > stack) or in other words in most cases faster code. Indeed. Intel 64 (x86_64) is really a different animal. More registers, different behaviors, and not just an LP64 version of what was there before. I've spent the last few weeks finally reading the x86_64 docs on my Kindle and really look forward to the older stuff just dying. Jon. From kevin.kofler at chello.at Tue Dec 8 19:09:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 08 Dec 2009 20:09:12 +0100 Subject: Deprecation of LAM/MPI? References: <1260228777.6753.15.camel@localhost> Message-ID: Jussi Lehtola wrote: > I really would like everything to confer to the MPI guidelines in Fedora > 13, but the problem is that so far no-one has volunteered to rework the > LAM/MPI package to conform to the new guidelines [1]. IMHO LAM/MPI could > be safely pulled out from Fedora 13, since it was obsoleted by Open MPI > 3 years ago. I see no reason to continue shipping an obsolete MPI implementation, so yes, LAM should be blocked now. (But it should be done now, not at the very end of the final freeze, so there's time to fix packages to drop their -lam subpackages, and create -openmpi ones where they aren't already there. The timing for F12 was really poor, which was why it got unblocked there.) Kevin Kofler From kevin.kofler at chello.at Tue Dec 8 19:13:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 08 Dec 2009 20:13:17 +0100 Subject: Promoting i386 version over x86_64? References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> Message-ID: Ralf Corsepius wrote: > * More packages (rpms) to cope with. Only if you pollute your system with 32-bit multilibs. A pure x86_64 system doesn't have any more packages than a 32-bit one. We don't even install multilibs by default anymore. Kevin Kofler From mmcgrath at redhat.com Tue Dec 8 19:47:31 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 8 Dec 2009 13:47:31 -0600 (CST) Subject: Fedora release criteria completely revised In-Reply-To: <1260285129.22036.10.camel@vaio.local.net> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260285129.22036.10.camel@vaio.local.net> Message-ID: On Tue, 8 Dec 2009, Adam Williamson wrote: > On Tue, 2009-12-08 at 15:07 +0100, Kevin Kofler wrote: > > Adam Williamson wrote: > > > During FUDCon, we've been working on revising the Fedora release criteria. > > > John Poelstra had already fleshed out a structure and much of the final > > > content, and we've been revising and tweaking it in conjunction with QA > > > (myself, Will Woods and James Laska), release engineering (Jesse Keating), > > > anaconda team (especially Denise Dumas and Peter Jones) and desktop team > > > (Christopher Aillon and Matthias Clasen, who provided suggestions at an > > > earlier stage). > > > > So once again things get decided by a small group of people in an in-person > > meeting and whoever didn't happen to be at the right place at the right time > > only gets to know the final decision after the fact? :-( > > Nope. This has been discussed for several weeks now. John Poelstra > posted the initial draft to test-list on November 20th, and asked for > feedback: > > https://www.redhat.com/archives/fedora-test-list/2009-November/msg00926.html > > He posted a further request for feedback on December 2nd, with an > explicit explanation that we would be gathering to finish working on the > pages at FUDCon: > > https://www.redhat.com/archives/fedora-test-list/2009-December/msg00047.html > > It was also brought up at each QA group meeting during this time. > > All the feedback that was received in response to any of those requests > was considered for the page either before or at FUDCon. > > This is not really about 'deciding things', it's about documenting an > existing process. Everything in the criteria is either based on the > existing QA acceptance test plan or has been requested by the anaconda > or desktop teams. > > > I've complained > > many times about this lack of transparency and I'll continue to do so. > > I don't think complaint is justified in this case. It was a perfectly > transparent process. There was a lot of opportunity to feed in. > > > Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks > > present at FUDCon.) > > We had a pre-hackfest meeting for the whole FUDCon attendee list where > everyone who wanted to hack on something stood up and announced what > they would be hacking on. John Poelstra announced at that meeting that > we would be gathering to work on the release criteria. The KDE people > who were at FUDCon were at that meeting, so they were in a position to > know about the work. I was running around all day telling people what we > were working on, it wasn't a secret. > > > Are you planning to ship Fedora 13 even if the KDE Live > > image is broken? > > That depends on whether you want us to or not. :) If a SIG has criteria > they want to add to the list, and they can commit to fulfilling those > criteria and be willing to take the responsibility of causing a release > to slip if they _don't_ fulfill them, we can certainly add those to the > lists. If KDE has minimum functional levels for the KDE spin that they > can commit to, please do send them to this thread and we'll look at > putting them in the criteria. > > We intentionally didn't specifically address the issue of the relative > 'importance' of spins in the criteria as it's a difficult topic and one > that's not really appropriate to decide in this place. The existing > criteria didn't address this either - they didn't say anything about > _any_ spin having to be not 'broken' before we ship - so there's no > change there. > In the future could all decisions about Fedora be run through me prior to them being enacted? -Mike From airlied at redhat.com Tue Dec 8 20:14:54 2009 From: airlied at redhat.com (Dave Airlie) Date: Wed, 09 Dec 2009 06:14:54 +1000 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: <1260265856.2138.4.camel@localhost.localdomain> References: <1260265856.2138.4.camel@localhost.localdomain> Message-ID: <1260303294.13514.0.camel@localhost> On Tue, 2009-12-08 at 01:50 -0800, Dan Williams wrote: > On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: > > Hi, > > > > On my laptop, after F12 updates-testing update today, after reboot F > > logo shows but then the screen goes dark and starts flickering between > > various shades of dark (changing modes?) with intel graphics chipset > > (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using > > a previous kernel didn't help. Booting to runlevel 3 and running > > system-config-display (--reconfig) resulted in the same. > > > > I've worked around the issue by "yum history undo 1" which rolled > > back a couple of hundred packages. > > > > Any idea which package could be the culprit and I should file a bug > > against or to isolate it? Somehow I don't think this is necessarily > > an Xorg base or driver issue. > > I'd start with xorg-x11-drv-intel. Update to the package set that > caused the problem, then for the bug report attach the output of > 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci > -nv'. Also indicate your kernel version, the version of > xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. > kernel is probably first up nowadays to blame for GPU bugs. File bugs against the X drivers generally though is easier for us to find them, kernel bug triage can be a long process. Dave. From ville.skytta at iki.fi Tue Dec 8 20:26:14 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 Dec 2009 22:26:14 +0200 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B1E914E.9010706@freenet.de> Message-ID: <200912082226.15007.ville.skytta@iki.fi> On Tuesday 08 December 2009, Kevin Kofler wrote: > Ralf Corsepius wrote: > > * More packages (rpms) to cope with. > > Only if you pollute your system with 32-bit multilibs. A pure x86_64 system > doesn't have any more packages than a 32-bit one. Fedora x86_64 repos do however carry ix86 packages around which shows in metadata sizes and I guess to some extent in performance of some yum operations. These probably aren't things to be generally overly concerned about though, and maybe not even what Ralf meant (he specifically mentioned rpms). From fedora at shmuelhome.mine.nu Tue Dec 8 20:57:40 2009 From: fedora at shmuelhome.mine.nu (shmuel siegel) Date: Tue, 08 Dec 2009 22:57:40 +0200 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> Message-ID: <4B1EBDC4.8000102@shmuelhome.mine.nu> Kevin Kofler wrote: > Ralf Corsepius wrote: > >> * More packages (rpms) to cope with. >> > > Only if you pollute your system with 32-bit multilibs. A pure x86_64 system > doesn't have any more packages than a 32-bit one. We don't even install > multilibs by default anymore. > > Kevin Kofler > > 32-bit multilibs seems hard to avoid if you want to run wine. From bnocera at redhat.com Tue Dec 8 21:45:28 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 08 Dec 2009 21:45:28 +0000 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260299132.3027.368.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> Message-ID: <1260308728.3311.1994.camel@localhost.localdomain> On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote: > On Tue, 2009-12-08 at 12:59 +0100, Tomasz Torcz wrote: > > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > > I did a clean install of Fedora 12 and realized > > > that pavucontrol was not installed by default. > > > I have two sound cards and I only got sound when > > > I manually installed pavucontrol and used it. > > > > Any reason? > > > pavucontrol is regarded as advance tool, but also partly > > obsolete. Current gnome-volume-control superseded most of > > its functionality: controlling different streams volume, > > switching profile, outputs, fallback devices. > > The new gnome-volume-control is so cut-down it's not useful to me. In > the quest to be more Mac-like in removing mixer controls No, it's in a quest of providing *solutions* to user's problems, and not blindly showing everything the software and the hardware can do. > (and not even > having any obvious "advanced" mode), I now have a choice of no audio or > having full volume LFE output *and* whatever mixer level I have set for > the master output. The sub-woofer setting works fine here, what's the problem? > alsamixer works fine, but then I can't use the volume > sliders on my desktop and it gets rather awkward. > > I still pine for the days of isapnpdump when I had to do all the heavy > lifting by hand, but it worked 100% of the time. You can still do all the heavy lifting you want. Install the old gst-mixer, or whatever GUI alsa mixer, just don't expect it to integrate with the desktop. Cheers From rc040203 at freenet.de Wed Dec 9 05:35:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Dec 2009 06:35:04 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: <200912082226.15007.ville.skytta@iki.fi> References: <4B1E914E.9010706@freenet.de> <200912082226.15007.ville.skytta@iki.fi> Message-ID: <4B1F3708.5080903@freenet.de> On 12/08/2009 09:26 PM, Ville Skytt? wrote: > On Tuesday 08 December 2009, Kevin Kofler wrote: >> Ralf Corsepius wrote: >>> * More packages (rpms) to cope with. >> >> Only if you pollute your system with 32-bit multilibs. A pure x86_64 system >> doesn't have any more packages than a 32-bit one. > > Fedora x86_64 repos do however carry ix86 packages around which shows in > metadata sizes and I guess to some extent in performance of some yum > operations. and in ... ... bandwidth demands ... ... package dep conflicts resolution ... ... maintenance efforts (At the very point you have one true 32bit-only capable machine around, installing x86_64 on a single machine means duplicating the maintenance effort). > These probably aren't things to be generally overly concerned > about though, ... try a yum update over GSM or over a modem and you'll very soon experience what I am talking about. > and maybe not even what Ralf meant (he specifically mentioned > rpms). I was indirectly referring to this (c.f. another thread on this list earlier this week). Ralf From rc040203 at freenet.de Wed Dec 9 05:51:59 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Dec 2009 06:51:59 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> Message-ID: <4B1F3AFF.90707@freenet.de> On 12/08/2009 08:02 PM, Gregory Maxwell wrote: > On Tue, Dec 8, 2009 at 12:47 PM, Ralf Corsepius wrote: >> That's one side, the other side is: >> * Larger demands on RAM (x86_64 is more demanding on memory >> requirements). > > Even if it were a full doubling (which is the absolute worst case > possible), it would only be pushing the effective cost of memory back > roughly 18 months or so. In reality the increase should be much less > than 2x. Correct - I didn't say "twice", I only said "more". On systems with smaller memory (or with soldered memory) this "more" can be the "drop" which may be responsible for exceeding memory demands to beyond physical memory and be the cause of swapping. >> * More packages (rpms) to cope with. > > Hmm? I'm not sure what you're talking about there. multilibs. x86_64 means coping with more packages in an installation (ca. 1/3 more). This has an impact on maintenance complexity (parallel installation of i386 packages), on metadata sizes (yum bandwith demands), etc. >> * The "faster" is hardly sensible to ordinary users. > > You could equally say that the difference in memory consumption is not > relevant to most ordinary users. No. At the very point a system starts swapping, memory consumption will become sensible. > Fedora has already chosen to make the 32bit builds incompatible with > pre-686 systems for performance gains Yes, a decision I consider to be a Fedora managment mistake. Seems to me, as if some people in Fedora's leadership don't want to understand that being able to deploy Linux on "old" or "recycled" hardware used to be one big selling point in Linux. Certainly, Fedora devs tend to be equipped with modern HW, but it's a mistake to believe everybody is. > I think if your position is that most users don't care about > performance and other things (like compatibility) are more important > then you should strongly promote x86_64 Fedora for everyone who can > use it. Not quite. My position actually is: Most users don't care much about 1-2% improved performance nor about improved internals (more registers etc.), as long as "their system" does what they want it to do. That said, these users don't actually care about using 64bit or 32bit Linux, as long as "their applications" behave "reasonable" and as long as the OS is easy to use. Or differently: I don't need a car with a 250kw engine and 7 seats to drive to the supermarket. My 8-years of VW Polo with its 50kW engine will also do ;) Ralf From oget.fedora at gmail.com Wed Dec 9 07:44:11 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 9 Dec 2009 02:44:11 -0500 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260299132.3027.368.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> Message-ID: On Tue, Dec 8, 2009 at 2:05 PM, Jon Masters wrote: > > The new gnome-volume-control is so cut-down it's not useful to me. In > the quest to be more Mac-like in removing mixer controls (and not even > having any obvious "advanced" mode), I now have a choice of no audio or > having full volume LFE output *and* whatever mixer level I have set for > the master output. alsamixer works fine, but then I can't use the volume > sliders on my desktop and it gets rather awkward. > Sadly, they consider this bug as an enhancement. I have had friends who had the same hardware with me but they were using another OS. I remember them being jealous because I had so much more control over same sound card. It made me proud at the time. I fear that this disease of oversimplifying will make us forget why we are using Linux. Try kmix, it always works. You can probably put in on Gnome panel too. Orcan From pekkas at netcore.fi Wed Dec 9 09:12:07 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 9 Dec 2009 11:12:07 +0200 (EET) Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: <1260303294.13514.0.camel@localhost> References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> Message-ID: On Wed, 9 Dec 2009, Dave Airlie wrote: >> I'd start with xorg-x11-drv-intel. Update to the package set that >> caused the problem, then for the bug report attach the output of >> 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci >> -nv'. Also indicate your kernel version, the version of >> xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. > > kernel is probably first up nowadays to blame for GPU bugs. > > File bugs against the X drivers generally though is easier for us to > find them, kernel bug triage can be a long process. As an update, I tried reproducing this as follows: 1) update kernel to the latest; reboot 2) update everything except 'xorg*' to the latest; reboot 3) update xorg* except xorg-x11-server*; reboot 4) update xorg-x11-server-*; reboot It's still working, so I'm left wondering what was the issue. Now gdm login however doesn't show my username and fingerprint login is no longer an option (this is probably because 'Administration - Users and Groups' thinks I'm a system user, maybe because my uid is 154). But that's a different issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mschmidt at redhat.com Wed Dec 9 09:36:32 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Wed, 9 Dec 2009 10:36:32 +0100 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> Message-ID: <20091209103632.62e51af0@leela> On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: > Now gdm login however doesn't show my username and fingerprint login > is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 From sassmann at redhat.com Wed Dec 9 12:23:27 2009 From: sassmann at redhat.com (Stefan Assmann) Date: Wed, 09 Dec 2009 13:23:27 +0100 Subject: thunderbird is removing spaces Message-ID: <4B1F96BF.2090604@redhat.com> Hi, thunderbird seem to remove spaces from lines that only consist of one or more spaces. Any way of preventing thunderbird from doing so? I already have "mailnews.send_plaintext_flowed false" and turned of line wrapping. With these option sending patches works pretty well, only recently I had a patch that got corrupted because of spaces being removed. Any ideas? Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera From ndbecker2 at gmail.com Wed Dec 9 12:47:44 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 09 Dec 2009 07:47:44 -0500 Subject: abrt issue Message-ID: I just got a crash in kde plasma. Traceback is not useful, because of missing debug pacakges. I'm told I can reload after 'installing the needed packages', but there is no clue what packages are needed. A bit of a mystery. It seems sometimes abrt will go ahead and download needed debuginfo packages, but other times (like today), it doesn't, and doesn't offer any clue what packages are missing. Either way, still not very user friendly. From christof at damian.net Wed Dec 9 12:51:39 2009 From: christof at damian.net (Christof Damian) Date: Wed, 9 Dec 2009 13:51:39 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <20091208115934.GE6007@mother.pipebreaker.pl> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> Message-ID: On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz wrote: > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > ?pavucontrol is regarded as advance tool, but also partly > obsolete. Current gnome-volume-control superseded most of > its functionality: controlling different streams volume, > switching profile, outputs, fallback devices. I am curious: If pavucontrol is obsolete, is there some other tool to tell skype to use headsets, while rhythmbox uses the speakers? pavucontrol currently crashes (and pulseaudio) for me on one machine and I need this functionality. Cheers, Christof From jmoskovc at redhat.com Wed Dec 9 12:56:03 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Wed, 09 Dec 2009 13:56:03 +0100 Subject: abrt issue In-Reply-To: References: Message-ID: <4B1F9E63.1030502@redhat.com> On 12/09/2009 01:47 PM, Neal Becker wrote: > I just got a crash in kde plasma. Traceback is not useful, because of > missing debug pacakges. > > I'm told I can reload after 'installing the needed packages', but > there is no clue what packages are needed. > > A bit of a mystery. It seems sometimes abrt will go ahead and download > needed debuginfo packages, but other times (like today), it doesn't, and > doesn't offer any clue what packages are missing. Weird, ABRT should tell you the exact package you should install debuginfo for. I just tried that and abrt says this: Reporting disabled because the backtrace is unusable. Please try to install debuginfo manually by using command: *debuginfo-install python* the use the Refresh button to regenerate the backtrace. Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From mschwendt at gmail.com Wed Dec 9 12:56:46 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 9 Dec 2009 13:56:46 +0100 Subject: abrt issue In-Reply-To: References: Message-ID: <20091209135646.25e0e00a@gmail.com> On Wed, 09 Dec 2009 07:47:44 -0500, Neal wrote: > I just got a crash in kde plasma. Traceback is not useful, because of > missing debug pacakges. Seems to happen more frequently recently. The latest backtraces I've seen in bugzilla all were missing dozens of debuginfo packages. > I'm told I can reload after 'installing the needed packages', but > there is no clue what packages are needed. ABRT once told me to use debuginfo-install, but it doesn't [or can't] get that hint right if an app uses plugins/modules from separate packages. > A bit of a mystery. It seems sometimes abrt will go ahead and download > needed debuginfo packages, but other times (like today), it doesn't, and > doesn't offer any clue what packages are missing. > > Either way, still not very user friendly. It would be an improvement if it worked. With dozens of missing debuginfo packages and missing "steps on how to reproduce a problem" the filed tickets are close to useless. From ndbecker2 at gmail.com Wed Dec 9 13:05:25 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 09 Dec 2009 08:05:25 -0500 Subject: abrt issue References: <4B1F9E63.1030502@redhat.com> Message-ID: Jiri Moskovcak wrote: > On 12/09/2009 01:47 PM, Neal Becker wrote: >> I just got a crash in kde plasma. Traceback is not useful, because of >> missing debug pacakges. >> >> I'm told I can reload after 'installing the needed packages', but >> there is no clue what packages are needed. >> >> A bit of a mystery. It seems sometimes abrt will go ahead and download >> needed debuginfo packages, but other times (like today), it doesn't, and >> doesn't offer any clue what packages are missing. > > Weird, ABRT should tell you the exact package you should install > debuginfo for. I just tried that and abrt says this: > > Reporting disabled because the backtrace is unusable. > Please try to install debuginfo manually by using command: > *debuginfo-install python* > the use the Refresh button to regenerate the backtrace. > > Jirka Yes, I've gotten messages like this sometimes, and that's what I was looking for. But not today. Maybe related? Dec 9 07:50:11 localhost abrtd: New crash, saving Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not successful: Plugin 'RunApp' is not registered From bruno at wolff.to Wed Dec 9 13:05:07 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 9 Dec 2009 07:05:07 -0600 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1F3AFF.90707@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> Message-ID: <20091209130507.GA4291@wolff.to> On Wed, Dec 09, 2009 at 06:51:59 +0100, Ralf Corsepius wrote: > > Seems to me, as if some people in Fedora's leadership don't want to > understand that being able to deploy Linux on "old" or "recycled" > hardware used to be one big selling point in Linux. I think the question is really, is Fedora suitable for being deployed on older hardware? Currently it isn't (for some value of older). I think if people wanted to try and make this happen, it could happen. But it would be a lot of work and might be different enough that it couldn't use the Fedora brand. From joachim.backes at rhrk.uni-kl.de Wed Dec 9 13:07:55 2009 From: joachim.backes at rhrk.uni-kl.de (Joachim Backes) Date: Wed, 09 Dec 2009 14:07:55 +0100 Subject: thunderbird is removing spaces In-Reply-To: <4B1F96BF.2090604@redhat.com> References: <4B1F96BF.2090604@redhat.com> Message-ID: <4B1FA12B.90604@rhrk.uni-kl.de> On 12/09/2009 01:23 PM, Stefan Assmann wrote: > Hi, > > thunderbird seem to remove spaces from lines that only consist of one or > more spaces. Any way of preventing thunderbird from doing so? I already > have "mailnews.send_plaintext_flowed false" and turned of line wrapping. > > With these option sending patches works pretty well, only recently I > had a patch that got corrupted because of spaces being removed. > > Any ideas? > > Stefan Hi Stefan, I'm running the recently (yesterday) released 3.0 version of thunderbird from mozilla.org, and I can confirm the same behaviour, but have no solution how to get rid from this. Regards Joachim Backes -- Joachim Backes http://www.rhrk.uni-kl.de/~backes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6101 bytes Desc: S/MIME Cryptographic Signature URL: From jmoskovc at redhat.com Wed Dec 9 13:18:40 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Wed, 09 Dec 2009 14:18:40 +0100 Subject: abrt issue In-Reply-To: References: <4B1F9E63.1030502@redhat.com> Message-ID: <4B1FA3B0.4060804@redhat.com> On 12/09/2009 02:05 PM, Neal Becker wrote: > Jiri Moskovcak wrote: > >> On 12/09/2009 01:47 PM, Neal Becker wrote: >>> I just got a crash in kde plasma. Traceback is not useful, because of >>> missing debug pacakges. >>> >>> I'm told I can reload after 'installing the needed packages', but >>> there is no clue what packages are needed. >>> >>> A bit of a mystery. It seems sometimes abrt will go ahead and download >>> needed debuginfo packages, but other times (like today), it doesn't, and >>> doesn't offer any clue what packages are missing. >> >> Weird, ABRT should tell you the exact package you should install >> debuginfo for. I just tried that and abrt says this: >> >> Reporting disabled because the backtrace is unusable. >> Please try to install debuginfo manually by using command: >> *debuginfo-install python* >> the use the Refresh button to regenerate the backtrace. >> >> Jirka > > Yes, I've gotten messages like this sometimes, and that's what I was looking > for. But not today. > > Maybe related? > Dec 9 07:50:11 localhost abrtd: New crash, saving > Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not > successful: Plugin 'RunApp' is not registered > This shouldn't be related, but I'm wondering where did you get the line "reload after 'installing the needed packages'" it doesn't come from ABRT. If ABRT thinks the BT is ok it won't give you any advice, but if the developer wants you to install additional debuginfo packages, then the formula is quite simple if the refresh button fails then: $ debuginfo-install and it should handle the rest. or you can try: $ yum update abrt --enablerepo=testing and try the updated version which should fix some problems with debuginfo installing. Jirka -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From jmoskovc at redhat.com Wed Dec 9 13:20:32 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Wed, 09 Dec 2009 14:20:32 +0100 Subject: abrt issue In-Reply-To: <4B1FA3B0.4060804@redhat.com> References: <4B1F9E63.1030502@redhat.com> <4B1FA3B0.4060804@redhat.com> Message-ID: <4B1FA420.5020606@redhat.com> > > $ yum update abrt --enablerepo=updatetesting and try the updated version which > should fix some problems with debuginfo installing. It should be: yum update abrt --enablerepo=updates-testing, but it seems it didn't hit the repository yet even thou I got the email. J. -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From ndbecker2 at gmail.com Wed Dec 9 13:23:47 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 09 Dec 2009 08:23:47 -0500 Subject: abrt issue References: <4B1F9E63.1030502@redhat.com> <4B1FA3B0.4060804@redhat.com> Message-ID: Jiri Moskovcak wrote: > On 12/09/2009 02:05 PM, Neal Becker wrote: >> Jiri Moskovcak wrote: >> >>> On 12/09/2009 01:47 PM, Neal Becker wrote: >>>> I just got a crash in kde plasma. Traceback is not useful, because of >>>> missing debug pacakges. >>>> >>>> I'm told I can reload after 'installing the needed packages', but >>>> there is no clue what packages are needed. >>>> >>>> A bit of a mystery. It seems sometimes abrt will go ahead and download >>>> needed debuginfo packages, but other times (like today), it doesn't, >>>> and doesn't offer any clue what packages are missing. >>> >>> Weird, ABRT should tell you the exact package you should install >>> debuginfo for. I just tried that and abrt says this: >>> >>> Reporting disabled because the backtrace is unusable. >>> Please try to install debuginfo manually by using command: >>> *debuginfo-install python* >>> the use the Refresh button to regenerate the backtrace. >>> >>> Jirka >> >> Yes, I've gotten messages like this sometimes, and that's what I was >> looking >> for. But not today. >> >> Maybe related? >> Dec 9 07:50:11 localhost abrtd: New crash, saving >> Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not >> successful: Plugin 'RunApp' is not registered >> > > This shouldn't be related, but I'm wondering where did you get the line > "reload after 'installing the needed packages'" it doesn't come from > ABRT. This is not an exact quote, but it's what I got from abrt when I clicked on 'next'. I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't give a good answer. Why isn't abrt telling me? From jmoskovc at redhat.com Wed Dec 9 13:27:26 2009 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Wed, 09 Dec 2009 14:27:26 +0100 Subject: abrt issue In-Reply-To: References: <4B1F9E63.1030502@redhat.com> <4B1FA3B0.4060804@redhat.com> Message-ID: <4B1FA5BE.1020906@redhat.com> On 12/09/2009 02:23 PM, Neal Becker wrote: > Jiri Moskovcak wrote: > >> On 12/09/2009 02:05 PM, Neal Becker wrote: >>> Jiri Moskovcak wrote: >>> >>>> On 12/09/2009 01:47 PM, Neal Becker wrote: >>>>> I just got a crash in kde plasma. Traceback is not useful, because of >>>>> missing debug pacakges. >>>>> >>>>> I'm told I can reload after 'installing the needed packages', but >>>>> there is no clue what packages are needed. >>>>> >>>>> A bit of a mystery. It seems sometimes abrt will go ahead and download >>>>> needed debuginfo packages, but other times (like today), it doesn't, >>>>> and doesn't offer any clue what packages are missing. >>>> >>>> Weird, ABRT should tell you the exact package you should install >>>> debuginfo for. I just tried that and abrt says this: >>>> >>>> Reporting disabled because the backtrace is unusable. >>>> Please try to install debuginfo manually by using command: >>>> *debuginfo-install python* >>>> the use the Refresh button to regenerate the backtrace. >>>> >>>> Jirka >>> >>> Yes, I've gotten messages like this sometimes, and that's what I was >>> looking >>> for. But not today. >>> >>> Maybe related? >>> Dec 9 07:50:11 localhost abrtd: New crash, saving >>> Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not >>> successful: Plugin 'RunApp' is not registered >>> >> >> This shouldn't be related, but I'm wondering where did you get the line >> "reload after 'installing the needed packages'" it doesn't come from >> ABRT. > This is not an exact quote, but it's what I got from abrt when I clicked on > 'next'. > > I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't > give a good answer. Why isn't abrt telling me? > It definitely is telling you. You can see it either in main window in column "Package" or in the report window if you scrolldown the backtrace you'll see row "package" J. -------------- next part -------------- A non-text attachment was scrubbed... Name: jmoskovc.vcf Type: text/x-vcard Size: 126 bytes Desc: not available URL: From linuxguy123 at gmail.com Wed Dec 9 13:27:18 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Wed, 09 Dec 2009 06:27:18 -0700 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: <20091209103632.62e51af0@leela> References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> <20091209103632.62e51af0@leela> Message-ID: <1260365238.11526.38.camel@localhost.localdomain> On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: > On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: > > Now gdm login however doesn't show my username and fingerprint login > > is no longer an option > > Looks like the issue with hal-0.5.14-1: > https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 I think it has something to do with display power management and the monitor brightness level. I can replicate the behavior by simply adjusting the display brightness in a KDE session. I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 From linuxguy123 at gmail.com Wed Dec 9 13:29:29 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Wed, 09 Dec 2009 06:29:29 -0700 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: <1260365238.11526.38.camel@localhost.localdomain> References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> <20091209103632.62e51af0@leela> <1260365238.11526.38.camel@localhost.localdomain> Message-ID: <1260365369.11526.40.camel@localhost.localdomain> On Wed, 2009-12-09 at 06:27 -0700, Linuxguy123 wrote: > On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: > > On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: > > > Now gdm login however doesn't show my username and fingerprint login > > > is no longer an option > > > > Looks like the issue with hal-0.5.14-1: > > https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 > > > I think it has something to do with display power management and the > monitor brightness level. I can replicate the behavior by simply > adjusting the display brightness in a KDE session. > > I have logged 2 bugs that are possibly related to this. > > https://bugzilla.redhat.com/show_bug.cgi?id=528188 > > https://bugzilla.redhat.com/show_bug.cgi?id=525767 > I recommend connecting an external monitor to see if the issue is display specific and have you tried ctrl-alt-F6 to get to a console at login and then going back to the X session with ctrl-alt-F1 ? From snecklifter at gmail.com Wed Dec 9 13:34:45 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 9 Dec 2009 13:34:45 +0000 Subject: Useless setroubleshoot alerts In-Reply-To: References: Message-ID: <364d303b0912090534o1f181c5dx912709ea8cc0bd70@mail.gmail.com> 2009/12/8 Konstantin Ryabitsev : > >From the point of view of security usability, this is cardinal sin: > > http://file.status.net/identica/tieguy-20091208T063036-ngc2rhp.png > > If we start the warning message with "SELinux has detected suspicious > behaviour on your system" and end it with "You can safely ignore this > avc," then we are doing everyone a nasty disservice. Please, let's fix > it as soon as possible. I understand the need for SELinux to log > things purely for auditing purposes, but the user must NOT see those > alerts, or we'll condition everyone to just dismiss them. > > I'm fairly certain this is a bug, but I've not yet bz'd it, as I > wanted to make sure that this is not "intended behaviour." If it is then it is proof of insanity. I shy away from any "Yet Another SELinux Rant" type stuff but this is plain ridiculous. I had Gnome-terminal up this morning and was shelled into a remote box. Thats it. Then I got a warning of the above - something to do with bash and prelink. Couldn't care less really. The end result is me disabling SELinux on my box. Sorry, I don't have time or inclination to file a bug on this constant irritant ever since it was introduced as nobody seems to take notice. Instead I'm asked to: # chcon_text_rel_slib insert_irritating_long_option_here add_some_random_characters_for_good_measure_}{)(&)(*^&^$%$"1 or something. SELinux was quite good on F11 and F12. Now it would seem it is starting to regress again. -- Christopher Brown From poelstra at redhat.com Wed Dec 9 13:37:20 2009 From: poelstra at redhat.com (John Poelstra) Date: Wed, 09 Dec 2009 05:37:20 -0800 Subject: Fedora release criteria completely revised In-Reply-To: <1260285129.22036.10.camel@vaio.local.net> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260285129.22036.10.camel@vaio.local.net> Message-ID: <4B1FA810.7040603@redhat.com> Adam Williamson said the following on 12/08/2009 07:12 AM Pacific Time: > On Tue, 2009-12-08 at 15:07 +0100, Kevin Kofler wrote: >> Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks >> present at FUDCon.) > > We had a pre-hackfest meeting for the whole FUDCon attendee list where > everyone who wanted to hack on something stood up and announced what > they would be hacking on. John Poelstra announced at that meeting that > we would be gathering to work on the release criteria. The KDE people > who were at FUDCon were at that meeting, so they were in a position to > know about the work. I was running around all day telling people what we > were working on, it wasn't a secret. > >> Are you planning to ship Fedora 13 even if the KDE Live >> image is broken? > > That depends on whether you want us to or not. :) If a SIG has criteria > they want to add to the list, and they can commit to fulfilling those > criteria and be willing to take the responsibility of causing a release > to slip if they _don't_ fulfill them, we can certainly add those to the > lists. If KDE has minimum functional levels for the KDE spin that they > can commit to, please do send them to this thread and we'll look at > putting them in the criteria. > > We intentionally didn't specifically address the issue of the relative > 'importance' of spins in the criteria as it's a difficult topic and one > that's not really appropriate to decide in this place. The existing > criteria didn't address this either - they didn't say anything about > _any_ spin having to be not 'broken' before we ship - so there's no > change there. This is a good clarification that we should add to the criteria page--it only speaks to requirements to release our default offering. It is also a framework to add more detail to once the "Target Audience" discussion is finalized. The Fedora QA process, for as long as I've been near it has focused on the "default offering" which has the Gnome desktop. I don't speak for the QA group, but to my knowledge Fedora QA has never officially tested or been responsible for testing any of the spins, including KDE. When I was part of the spins process it was understood that each Spins team was responsible for testing their spin. It would be a mistake to take the new release criteria pages and attempt to mold them to make them be "all things to all Spins." Just as each of the public releases (Alpha, Beta, and Final) have different target audiences, so do the spins themselves. What would make sense would be for each of the Spins SIGS to copy the release criteria pages and mold their own from them. The Fedora QA Team already has enough things on their plate and they are doing a great job, but don't muddy the waters by trying to mix two target audiences into the same release criteria. John From dominik at greysector.net Wed Dec 9 13:54:42 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 9 Dec 2009 14:54:42 +0100 Subject: Fedora release criteria completely revised In-Reply-To: <076d60721cac4a9affc7c22ac0354c71@mailserver> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <20091209135442.GA2748@mokona.greysector.net> On Monday, 07 December 2009 at 23:55, Adam Williamson wrote: [...] > https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria 16. Automatic mounting on insertion of removable media must work It should be clarified with "... after GUI login", because it sure never worked before a user is logged in. Also it never worked when user was logged in via text console, did it? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Wed Dec 9 14:00:51 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 9 Dec 2009 15:00:51 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: <1260299266.3027.370.camel@tonnant> References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> Message-ID: <20091209140051.GB2748@mokona.greysector.net> On Tuesday, 08 December 2009 at 20:07, Jon Masters wrote: > On Tue, 2009-12-08 at 18:41 +0100, drago01 wrote: > > On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd > > > > But wouldn't it be better to use 32 bit when less then 4 GB of ram is > > > present? > > > > no, using x86_64 means more registers, sse2 as default floating point > > instruction set, better calling convention (register passing vs. > > stack) or in other words in most cases faster code. > > Indeed. Intel 64 (x86_64) is really a different animal. More registers, Actually, x86_64 is an AMD invention (originally called AMD64) and is called EM64T by Intel. The only "Intel 64" I can think of is IA64, i.e. Itanium (called "Itanic" by some). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bnocera at redhat.com Wed Dec 9 14:14:55 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 09 Dec 2009 14:14:55 +0000 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> Message-ID: <1260368095.3311.2013.camel@localhost.localdomain> On Wed, 2009-12-09 at 13:51 +0100, Christof Damian wrote: > On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz wrote: > > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > pavucontrol is regarded as advance tool, but also partly > > obsolete. Current gnome-volume-control superseded most of > > its functionality: controlling different streams volume, > > switching profile, outputs, fallback devices. > > I am curious: If pavucontrol is obsolete, is there some other tool to > tell skype to use headsets, while rhythmbox uses the speakers? It's not obsolete, it's just not installed by default. > pavucontrol currently crashes (and pulseaudio) for me on one machine > and I need this functionality. File bugs! From pbrobinson at gmail.com Wed Dec 9 14:25:18 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 9 Dec 2009 14:25:18 +0000 Subject: rawhide and tagging requests Message-ID: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> Hi All, What's the status of the issues with the rawhide compose? Are they going to be fixed and a push done before the upcoming extended outage? What about outstanding tag build-override requests? Cheers, Peter From rc040203 at freenet.de Wed Dec 9 14:26:07 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Dec 2009 15:26:07 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: <20091209130507.GA4291@wolff.to> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> Message-ID: <4B1FB37F.30009@freenet.de> On 12/09/2009 02:05 PM, Bruno Wolff III wrote: > On Wed, Dec 09, 2009 at 06:51:59 +0100, > Ralf Corsepius wrote: > >> Seems to me, as if some people in Fedora's leadership don't want to >> understand that being able to deploy Linux on "old" or "recycled" >> hardware used to be one big selling point in Linux. >> > I think the question is really, is Fedora suitable for being deployed > on older hardware? In its early days, it was. > Currently it isn't (for some value of older). > Ageed, it isn't anymore. As I feel, "Fedora has followed up Microsoft the Vista way" Those using modern hardware may find this "cool", those who don't, switch away to using different distros. > I think if people wanted to try and make this happen, it could happen. > It wasn't a lot of work in the early Fedora day - It simply worked out of the box! However, some $DEITY's have decided otherwise ... I am inclined to think "inevitably, because such platforms aren't the platforms most developers use nor the platforms "RHEL is aiming at" ... These people think in terms of "Quad machines" and "RH clients", but forget about the amount of "old" machines which are still actively being used and about "use-case niches". Ralf From nicolas.mailhot at laposte.net Wed Dec 9 14:26:40 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Dec 2009 15:26:40 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: <20091209140051.GB2748@mokona.greysector.net> References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> <20091209140051.GB2748@mokona.greysector.net> Message-ID: Le Mer 9 d?cembre 2009 15:00, Dominik 'Rathann' Mierzejewski a ?crit : > Actually, x86_64 is an AMD invention (originally called AMD64) > and is called EM64T by Intel. The only "Intel 64" I can think of > is IA64, i.e. Itanium (called "Itanic" by some). When Intel realised Itanium was a failure, they dumped the ia32/ia64 classification and adopted x32/x64 (which is the same thing, except x64 != ia64, talk about hiding past mistakes) -- Nicolas Mailhot From mjg at redhat.com Wed Dec 9 14:28:12 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 9 Dec 2009 14:28:12 +0000 Subject: Promoting i386 version over x86_64? In-Reply-To: <20091209140051.GB2748@mokona.greysector.net> References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> <20091209140051.GB2748@mokona.greysector.net> Message-ID: <20091209142812.GA17378@srcf.ucam.org> On Wed, Dec 09, 2009 at 03:00:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: > Actually, x86_64 is an AMD invention (originally called AMD64) > and is called EM64T by Intel. The only "Intel 64" I can think of > is IA64, i.e. Itanium (called "Itanic" by some). http://www.intel.com/technology/intel64/ We have always been at war with Itanium, -- Matthew Garrett | mjg59 at srcf.ucam.org From jkeating at redhat.com Wed Dec 9 14:43:05 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Dec 2009 06:43:05 -0800 Subject: rawhide and tagging requests In-Reply-To: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> Message-ID: <1260369785.30425.8.camel@localhost.localdomain> On Wed, 2009-12-09 at 14:25 +0000, Peter Robinson wrote: > > What's the status of the issues with the rawhide compose? All the broken deps preventing a compose attempt have been cleared out. However the new rpm build was busted in a way that it made the compose fall over, a new build of rpm is coming and I hope to kick off another rawhide attempt when it lands. > Are they > going to be fixed and a push done before the upcoming extended outage? Hopefully > What about outstanding tag build-override requests? > > I'll try to get to those today. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Wed Dec 9 14:58:02 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 9 Dec 2009 14:58:02 +0000 Subject: rawhide and tagging requests In-Reply-To: <1260369785.30425.8.camel@localhost.localdomain> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> Message-ID: <5256d0b0912090658u28484d7ep85ea1296168d5c3f@mail.gmail.com> Hi Jesse, On Wed, Dec 9, 2009 at 2:43 PM, Jesse Keating wrote: > On Wed, 2009-12-09 at 14:25 +0000, Peter Robinson wrote: >> >> What's the status of the issues with the rawhide compose? > > All the broken deps preventing a compose attempt have been cleared out. > However the new rpm build was busted in a way that it made the compose > fall over, a new build of rpm is coming and I hope to kick off another > rawhide attempt when it lands. > >> ?Are they >> going to be fixed and a push done before the upcoming extended outage? > > Hopefully > >> What about outstanding tag build-override requests? >> >> > > I'll try to get to those today. Thanks for the update, Cheers, Peter From james at fedoraproject.org Wed Dec 9 15:14:10 2009 From: james at fedoraproject.org (James Antill) Date: Wed, 09 Dec 2009 10:14:10 -0500 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1FB37F.30009@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> Message-ID: <1260371650.13006.95.camel@code.and.org> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: > However, some $DEITY's have decided otherwise ... > > I am inclined to think "inevitably, because such platforms aren't the > platforms most developers use nor the platforms "RHEL is aiming at" ... > These people think in terms of "Quad machines" and "RH clients", but > forget about the amount of "old" machines which are still actively being > used and about "use-case niches". A+ for, eventually, coming to the obvious solution. Although, personally, I haven't had a quad core yet all the computers I currently have running are either laptops or dual cores. The minimum RAM size on any of these 5 boxes is 2GB. I'd be surprised to find that anyone working as a full time developer has any (non-virt) boxes that are spec'd less than that. And yes, shockingly, developers will test on the machines they have easy access to. So, yeh, if _you_ want to support slower machines ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l "Everyone should solve my problems" is unlikely to actually help. IMO. -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From bruno at wolff.to Wed Dec 9 15:32:13 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 9 Dec 2009 09:32:13 -0600 Subject: Promoting i386 version over x86_64? In-Reply-To: <1260371650.13006.95.camel@code.and.org> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> Message-ID: <20091209153213.GA13695@wolff.to> On Wed, Dec 09, 2009 at 10:14:10 -0500, James Antill wrote: > > So, yeh, if _you_ want to support slower machines ... _you_ will have > to do the work, you might get help from the community but just ranting > on f-d-l "Everyone should solve my problems" is unlikely to actually > help. IMO. I think the question is more about supporting machines with less memory and processors that don't support all of the 686 instructions. I have a couple of old laptops that I use at a gaming convention once a year that have pentium 90s with 24MB of memory. I have redhat 6.2 on them, but would have liked to have tried using Fedora on at least one of them. But I wouldn't be able to use anaconda to do the install and I might need to build a custom kernel to cut the memory needed down a bit. But I'll probably just leave them as is and in a few years find some other old hand me down laptop to replace them. I also have a couple of low end routers that currently have ddwrt images on them. When openwrt has 2.6 kernel broadcom support, I plan to switch over to openwrt. But it would be cool to be able to run a Fedora based router spin on them if such a thing existed. (Not cool enough for me to do the development, as I have other things I want done more.) From robinstar1574 at gmail.com Wed Dec 9 15:48:30 2009 From: robinstar1574 at gmail.com (Rallias UberNerd) Date: Wed, 09 Dec 2009 09:48:30 -0600 Subject: Fedora release criteria completely revised In-Reply-To: References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260285129.22036.10.camel@vaio.local.net> Message-ID: On Tue, 08 Dec 2009 13:47:31 -0600, Mike McGrath wrote: > On Tue, 8 Dec 2009, Adam Williamson wrote: > >> On Tue, 2009-12-08 at 15:07 +0100, Kevin Kofler wrote: >> > Adam Williamson wrote: >> > > During FUDCon, we've been working on revising the Fedora release criteria. >> > > John Poelstra had already fleshed out a structure and much of the final >> > > content, and we've been revising and tweaking it in conjunction with QA >> > > (myself, Will Woods and James Laska), release engineering (Jesse Keating), >> > > anaconda team (especially Denise Dumas and Peter Jones) and desktop team >> > > (Christopher Aillon and Matthias Clasen, who provided suggestions at an >> > > earlier stage). >> > >> > So once again things get decided by a small group of people in an in-person >> > meeting and whoever didn't happen to be at the right place at the right time >> > only gets to know the final decision after the fact? :-( >> >> Nope. This has been discussed for several weeks now. John Poelstra >> posted the initial draft to test-list on November 20th, and asked for >> feedback: >> >> https://www.redhat.com/archives/fedora-test-list/2009-November/msg00926.html >> >> He posted a further request for feedback on December 2nd, with an >> explicit explanation that we would be gathering to finish working on the >> pages at FUDCon: >> >> https://www.redhat.com/archives/fedora-test-list/2009-December/msg00047.html >> >> It was also brought up at each QA group meeting during this time. >> >> All the feedback that was received in response to any of those requests >> was considered for the page either before or at FUDCon. >> >> This is not really about 'deciding things', it's about documenting an >> existing process. Everything in the criteria is either based on the >> existing QA acceptance test plan or has been requested by the anaconda >> or desktop teams. >> >> > I've complained >> > many times about this lack of transparency and I'll continue to do so. >> >> I don't think complaint is justified in this case. It was a perfectly >> transparent process. There was a lot of opportunity to feed in. >> >> > Plus, why was the KDE SIG not invited? (We had at least 4 KDE SIG folks >> > present at FUDCon.) >> >> We had a pre-hackfest meeting for the whole FUDCon attendee list where >> everyone who wanted to hack on something stood up and announced what >> they would be hacking on. John Poelstra announced at that meeting that >> we would be gathering to work on the release criteria. The KDE people >> who were at FUDCon were at that meeting, so they were in a position to >> know about the work. I was running around all day telling people what we >> were working on, it wasn't a secret. >> >> > Are you planning to ship Fedora 13 even if the KDE Live >> > image is broken? >> >> That depends on whether you want us to or not. :) If a SIG has criteria >> they want to add to the list, and they can commit to fulfilling those >> criteria and be willing to take the responsibility of causing a release >> to slip if they _don't_ fulfill them, we can certainly add those to the >> lists. If KDE has minimum functional levels for the KDE spin that they >> can commit to, please do send them to this thread and we'll look at >> putting them in the criteria. >> >> We intentionally didn't specifically address the issue of the relative >> 'importance' of spins in the criteria as it's a difficult topic and one >> that's not really appropriate to decide in this place. The existing >> criteria didn't address this either - they didn't say anything about >> _any_ spin having to be not 'broken' before we ship - so there's no >> change there. >> > > > > In the future could all decisions about Fedora be run through me prior to > them being enacted? > > > > -Mike > You can always fix that by starting your own distro tangent. They just voted on what they provide. Rallias PS: What does sarcasm HTML tag do? It caused an error in my specialized email reader. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jreiser at bitwagon.com Wed Dec 9 15:51:50 2009 From: jreiser at bitwagon.com (John Reiser) Date: Wed, 09 Dec 2009 07:51:50 -0800 Subject: Promoting i386 version over x86_64? In-Reply-To: <1260371650.13006.95.camel@code.and.org> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> Message-ID: <4B1FC796.2080209@bitwagon.com> On 12/09/2009 07:14 AM, James Antill wrote: > ... The minimum RAM size on any of these 5 boxes is 2GB. > > I'd be surprised to find that anyone working as a full time developer > has any (non-virt) boxes that are spec'd less than that. Surprise! I have 4 boxes that are 1GB or less (as low as 320MB), and several that are 2GB or more. > And yes, shockingly, developers will test on the machines they have > easy access to. Sometimes I doubt even that, particularly when shipped software has python syntax errors (type mismatch, wrong number of arguments, no such member, ...) -- From christof at damian.net Wed Dec 9 15:54:22 2009 From: christof at damian.net (Christof Damian) Date: Wed, 9 Dec 2009 16:54:22 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260368095.3311.2013.camel@localhost.localdomain> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260368095.3311.2013.camel@localhost.localdomain> Message-ID: On Wed, Dec 9, 2009 at 15:14, Bastien Nocera wrote: >> I am curious: If pavucontrol is obsolete, is there some other tool to >> tell skype to use headsets, while rhythmbox uses the speakers? > > It's not obsolete, it's just not installed by default. > >> pavucontrol currently crashes (and pulseaudio) for me on one machine >> and I need this functionality. > > File bugs! I do, but this one is already in bugzilla as far as I can see. I just wanted to mention why I am looking for an alternative. Christof From rc040203 at freenet.de Wed Dec 9 16:47:49 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Dec 2009 17:47:49 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: <1260371650.13006.95.camel@code.and.org> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> Message-ID: <4B1FD4B5.2070206@freenet.de> On 12/09/2009 04:14 PM, James Antill wrote: > On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: > So, yeh, if _you_ want to support slower machines Well, I do not want to, I can't avoid to ... > ... _you_ will have > to do the work, you might get help from the community but just ranting > on f-d-l "Everyone should solve my problems" is unlikely to actually > help. IMO. There is an easier solution: Stop using/promoting/advertising Fedora and switch to a different distro ... Ralf From jgarzik at pobox.com Wed Dec 9 16:49:42 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Wed, 09 Dec 2009 11:49:42 -0500 Subject: thunderbird is removing spaces In-Reply-To: <4B1FA12B.90604@rhrk.uni-kl.de> References: <4B1F96BF.2090604@redhat.com> <4B1FA12B.90604@rhrk.uni-kl.de> Message-ID: <4B1FD526.7030608@pobox.com> On 12/09/2009 08:07 AM, Joachim Backes wrote: > On 12/09/2009 01:23 PM, Stefan Assmann wrote: >> Hi, >> >> thunderbird seem to remove spaces from lines that only consist of one or >> more spaces. Any way of preventing thunderbird from doing so? I already >> have "mailnews.send_plaintext_flowed false" and turned of line wrapping. >> >> With these option sending patches works pretty well, only recently I >> had a patch that got corrupted because of spaces being removed. >> >> Any ideas? > I'm running the recently (yesterday) released 3.0 version of thunderbird > from mozilla.org, and I can confirm the same behaviour, but have no > solution how to get rid from this. ACK, another confirmation here. Do we have a bug filed? :) Jeff From skvidal at fedoraproject.org Wed Dec 9 16:51:14 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 9 Dec 2009 11:51:14 -0500 (EST) Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1FD4B5.2070206@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> <4B1FD4B5.2070206@freenet.de> Message-ID: On Wed, 9 Dec 2009, Ralf Corsepius wrote: > On 12/09/2009 04:14 PM, James Antill wrote: >> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: > >> So, yeh, if _you_ want to support slower machines > Well, I do not want to, I can't avoid to ... > >> ... _you_ will have >> to do the work, you might get help from the community but just ranting >> on f-d-l "Everyone should solve my problems" is unlikely to actually >> help. IMO. > > There is an easier solution: Stop using/promoting/advertising Fedora and > switch to a different distro ... > okay, for you, that sounds like it may be the best option. You are obviously unhappy with fedora. We've appreciated your constructive contributions but if you are no longer interested in working on/with fedora, then we wish you well in your endeavors. It would be most polite to officially orphan your packages before you go. Thanks and good luck in the future. -sv From sundaram at fedoraproject.org Wed Dec 9 16:51:37 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 09 Dec 2009 22:21:37 +0530 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1FD4B5.2070206@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> <4B1FD4B5.2070206@freenet.de> Message-ID: <4B1FD599.5090004@fedoraproject.org> On 12/09/2009 10:17 PM, Ralf Corsepius wrote: > On 12/09/2009 04:14 PM, James Antill wrote: >> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: > >> So, yeh, if _you_ want to support slower machines > Well, I do not want to, I can't avoid to ... > >> ... _you_ will have >> to do the work, you might get help from the community but just ranting >> on f-d-l "Everyone should solve my problems" is unlikely to actually >> help. IMO. > > There is an easier solution: Stop using/promoting/advertising Fedora and > switch to a different distro ... Absolutely. Fedora can't be everything to everybody. If noone is willing to do the work involved, try and find the tools to do the job better. Just ranting isn't useful. Rahul From rc040203 at freenet.de Wed Dec 9 17:05:36 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Dec 2009 18:05:36 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> <4B1FD4B5.2070206@freenet.de> Message-ID: <4B1FD8E0.3070409@freenet.de> On 12/09/2009 05:51 PM, Seth Vidal wrote: > > > On Wed, 9 Dec 2009, Ralf Corsepius wrote: > >> On 12/09/2009 04:14 PM, James Antill wrote: >>> On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: >> >>> So, yeh, if _you_ want to support slower machines >> Well, I do not want to, I can't avoid to ... >> >>> ... _you_ will have >>> to do the work, you might get help from the community but just ranting >>> on f-d-l "Everyone should solve my problems" is unlikely to actually >>> help. IMO. >> >> There is an easier solution: Stop using/promoting/advertising Fedora >> and switch to a different distro ... >> > > okay, for you, that sounds like it may be the best option. You are > obviously unhappy with fedora. Did I say this? I am unhappy with Fedora's management's decisions. Technically, Fedora is quite usable (most of the time), on more or modern machines. > We've appreciated your constructive > contributions but if you are no longer interested in working on/with > fedora, then we wish you well in your endeavors. If I wasn't interested in Fedora, I wouldn't complain. It's just that Fedora increasingly diverges from my needs and increasingly is not applicable for my purposes. Less abstract: This development forces me to not recommend Fedora (or RHEL) to customers. > It would be most polite to officially orphan your packages before you go. Thanks you for sheding more insights in how you intend to take community interests into account. From rjones at redhat.com Wed Dec 9 17:11:02 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 9 Dec 2009 17:11:02 +0000 Subject: yum download estimates and stalls Message-ID: <20091209171102.GA23967@amd.home.annexia.org> I don't want to make unfair comparisons to the famous bug in Windows Vista[1], but it seems as if when a yum download stalls, then the estimates can start to look a little large: rawhide/primar 20% [- ] 0.0 B/s | 2.5 MB 2046434610655583470384211558:24 ETA # yum --version 3.2.25 Installed: rpm-4.7.1-6.fc12.x86_64 at 2009-11-25 22:30 Built : Fedora Project at 2009-09-21 13:30 Committed: Panu Matilainen at 2009-09-21 12:00 Installed: yum-3.2.25-1.fc12.noarch at 2009-11-25 22:42 Built : Fedora Project at 2009-10-16 20:44 Committed: Seth Vidal at 2009-10-14 12:00 Rich. [1] http://www.istartedsomething.com/wp-content/uploads/2007/12/vista47117days.jpg -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From skvidal at fedoraproject.org Wed Dec 9 17:20:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 9 Dec 2009 12:20:12 -0500 (EST) Subject: yum download estimates and stalls In-Reply-To: <20091209171102.GA23967@amd.home.annexia.org> References: <20091209171102.GA23967@amd.home.annexia.org> Message-ID: On Wed, 9 Dec 2009, Richard W.M. Jones wrote: > I don't want to make unfair comparisons to the famous bug in Windows > Vista[1], but it seems as if when a yum download stalls, then the > estimates can start to look a little large: > > rawhide/primar 20% [- ] 0.0 B/s | 2.5 MB 2046434610655583470384211558:24 ETA > What ver of python-urlgrabber do you have installed? And there is a patch posted I've not merged yet, mainly b/c I was out of the world for the weekend. -sv From awilliam at redhat.com Wed Dec 9 17:25:25 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 09 Dec 2009 09:25:25 -0800 Subject: Fedora release criteria completely revised In-Reply-To: <4B1E21E9.4060305@warmcat.com> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <4B1E21E9.4060305@warmcat.com> Message-ID: <1260379525.2412.1.camel@adam.local.net> On Tue, 2009-12-08 at 10:52 +0100, Andy Green wrote: > On 12/07/09 23:55, Somebody in the thread at some point said: > > Hi - > > > these pages, not nice-to-haves. You must be able to commit to the idea > > that, if any criterion on the page is not met, we would slip the release in > > question. > > I think it's great you guys are looking to increase > Quality-with-a-capital-Q. > > ''9 There must be no SELinux 'AVC: denied' messages or abrt crash > notifications on initial boot and subsequent login'' > > https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria > > It might be wise to specify on what particular set of test machines or > platforms you want to see not abrt stuff from. Because current F12 > kernels kill a 4-core box here and iwlagn gives abrt warnings on this > laptop, but it's still otherwise fine as a released kernel. > > It's not realistic to hold a release until the kernel never crashes on > any platform. Luckily, we have a tailor-made get-out clause for that one (actually I pointed out the same problem as you, and wrote it, shortly before FUDCon): https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F I'll turn that criterion into a 'in most cases' one with a link to that FAQ entry, as we did for the other similar criteria. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed Dec 9 17:27:29 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 09 Dec 2009 09:27:29 -0800 Subject: Fedora release criteria completely revised In-Reply-To: References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <1260379649.2412.2.camel@adam.local.net> On Tue, 2009-12-08 at 09:19 -0500, Colin Walters wrote: > Hi Adam, > > Looks really great in general! Thanks! > One specific comment, for Final 9; I > think we need a more specific definition of "and subsequent login". > Does that mean that you just type your username/password and look at > the default desktop? This is what it was intended to mean, actually running apps I would have defined as 'login and use'. How would you suggest wording a clarification? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From Jochen at herr-schmitt.de Wed Dec 9 17:33:08 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 09 Dec 2009 18:33:08 +0100 Subject: Changed license for clojure-1.0.0 (CPL -> EPL) Message-ID: <4B1FDF54.3070701@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, I want to notifiy you, that the license of clojure-1.0.0 was changed from the Common Public License to Eclipse Public License 1.0. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAksf3z4ACgkQZLAIBz9lVu9FjAQAm0uRZ+7wVodnGkmLKiAummkt z/ZyLib/40TNDy3+HujMDZfFezyXXS+VmGWR4S4JZMjONOCA20g87AGWP+oSGwMD L6B5IfeLhsYi+lzr+0h1B++gDxarpRN1uyQV6QteHiSuGoJQAkXIPVHJL5TRmCyu En+3SyiWLEZjiCcrhxU= =05MF -----END PGP SIGNATURE----- From kevin.kofler at chello.at Wed Dec 9 17:36:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 09 Dec 2009 18:36:28 +0100 Subject: F12 updates-testing issue: X flickers and fails to start References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> <20091209103632.62e51af0@leela> <1260365238.11526.38.camel@localhost.localdomain> Message-ID: Linuxguy123 wrote: > I have logged 2 bugs that are possibly related to this. > > https://bugzilla.redhat.com/show_bug.cgi?id=528188 > > https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. These bugs filed by Rex Dieter about issues caused by HAL 0.5.14 are probably more relevant: https://bugzilla.redhat.com/show_bug.cgi?id=545258 https://bugzilla.redhat.com/show_bug.cgi?id=545639 Kevin Kofler From rjones at redhat.com Wed Dec 9 17:39:28 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 9 Dec 2009 17:39:28 +0000 Subject: yum download estimates and stalls In-Reply-To: References: <20091209171102.GA23967@amd.home.annexia.org> Message-ID: <20091209173928.GB23967@amd.home.annexia.org> On Wed, Dec 09, 2009 at 12:20:12PM -0500, Seth Vidal wrote: > On Wed, 9 Dec 2009, Richard W.M. Jones wrote: > >> I don't want to make unfair comparisons to the famous bug in Windows >> Vista[1], but it seems as if when a yum download stalls, then the >> estimates can start to look a little large: >> >> rawhide/primar 20% [- ] 0.0 B/s | 2.5 MB 2046434610655583470384211558:24 ETA >> > > What ver of python-urlgrabber do you have installed? python-urlgrabber-3.9.1-4.fc12.noarch Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From walters at verbum.org Wed Dec 9 17:40:02 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 9 Dec 2009 17:40:02 +0000 Subject: Fedora release criteria completely revised In-Reply-To: <1260379649.2412.2.camel@adam.local.net> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260379649.2412.2.camel@adam.local.net> Message-ID: On Wed, Dec 9, 2009 at 5:27 PM, Adam Williamson wrote: > This is what it was intended to mean, actually running apps I would have > defined as 'login and use'. How would you suggest wording a > clarification? Looking at it again, it's fairly clear that this just covers the desktop view, given criteria 12. So this looks fine, thanks! From kyle at mcmartin.ca Wed Dec 9 18:14:53 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 9 Dec 2009 13:14:53 -0500 Subject: kernel update highly recommended Message-ID: <20091209181453.GW28962@bombadil.infradead.org> Hi folks, I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update to the latest kernel in the koji builds here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871 http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876 They fix a rather severe security problem with ext4 caused by insufficient permission checking by the ext4 ioctl code, allowing a malicious local user to corrupt files. Note, the ioctl isn't currently used by userspace, so if you build your own kernels, you can just nuke the entire EXT4_IOC_MOVE_EXT ioctl case. NOTE: This is only a problem if you're using EXT4, if you aren't, you're safe. I'll get these pushed out to stable asap, but I wanted to let folks know just in case rawhide doesn't compose before the downtime. regards, Kyle M. From nathanael at gnat.ca Wed Dec 9 18:20:02 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 09 Dec 2009 11:20:02 -0700 Subject: kernel update highly recommended In-Reply-To: <20091209181453.GW28962@bombadil.infradead.org> References: <20091209181453.GW28962@bombadil.infradead.org> Message-ID: <4B1FEA52.7010701@gnat.ca> On 12/09/2009 11:14 AM, Kyle McMartin wrote: > Hi folks, > > I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update > to the latest kernel in the koji builds here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871 > http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876 > > They fix a rather severe security problem with ext4 caused by > insufficient permission checking by the ext4 ioctl code, allowing a > malicious local user to corrupt files. Note, the ioctl isn't currently > used by userspace, so if you build your own kernels, you can just nuke > the entire EXT4_IOC_MOVE_EXT ioctl case. > > NOTE: This is only a problem if you're using EXT4, if you aren't, you're > safe. > > I'll get these pushed out to stable asap, but I wanted to let folks know > just in case rawhide doesn't compose before the downtime. This a rawhide only issue or F12 as well? From bruno at wolff.to Wed Dec 9 18:23:50 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 9 Dec 2009 12:23:50 -0600 Subject: kernel update highly recommended In-Reply-To: <4B1FEA52.7010701@gnat.ca> References: <20091209181453.GW28962@bombadil.infradead.org> <4B1FEA52.7010701@gnat.ca> Message-ID: <20091209182350.GA11700@wolff.to> On Wed, Dec 09, 2009 at 11:20:02 -0700, "Nathanael D. Noblet" wrote: > > This a rawhide only issue or F12 as well? It affects F12. You want the -166 kernel. However right now it is still building. (I didn't check to see if some arches are done already.) The updated kernel for rawhide has completed building. From kyle at mcmartin.ca Wed Dec 9 18:27:15 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 9 Dec 2009 13:27:15 -0500 Subject: kernel update highly recommended In-Reply-To: <4B1FEA52.7010701@gnat.ca> References: <20091209181453.GW28962@bombadil.infradead.org> <4B1FEA52.7010701@gnat.ca> Message-ID: <20091209182715.GX28962@bombadil.infradead.org> On Wed, Dec 09, 2009 at 11:20:02AM -0700, Nathanael D. Noblet wrote: >> I'd highly recommend if you're running 2.6.31 or 2.6.32, that you update >> to the latest kernel in the koji builds here: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1864871 >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1864876 >> > This a rawhide only issue or F12 as well? > It is indeed both, so there's a build there for each. regards, Kyle From bruno at wolff.to Wed Dec 9 18:28:35 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 9 Dec 2009 12:28:35 -0600 Subject: kernel update highly recommended In-Reply-To: <20091209182350.GA11700@wolff.to> References: <20091209181453.GW28962@bombadil.infradead.org> <4B1FEA52.7010701@gnat.ca> <20091209182350.GA11700@wolff.to> Message-ID: <20091209182835.GA17055@wolff.to> On Wed, Dec 09, 2009 at 12:23:50 -0600, Bruno Wolff III wrote: > On Wed, Dec 09, 2009 at 11:20:02 -0700, > "Nathanael D. Noblet" wrote: > > > > This a rawhide only issue or F12 as well? > > It affects F12. You want the -166 kernel. However right now it is still > building. (I didn't check to see if some arches are done already.) The > updated kernel for rawhide has completed building. The 686 step is not quite done yet, but eveything else is. You can grab the rpms that are done by walking down into the tasks. The build will probably be done in a few minutes though. From ville.skytta at iki.fi Wed Dec 9 18:37:07 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 9 Dec 2009 20:37:07 +0200 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1F3708.5080903@freenet.de> References: <200912082226.15007.ville.skytta@iki.fi> <4B1F3708.5080903@freenet.de> Message-ID: <200912092037.07973.ville.skytta@iki.fi> On Wednesday 09 December 2009, Ralf Corsepius wrote: > On 12/08/2009 09:26 PM, Ville Skytt? wrote: > > These probably aren't things to be generally overly concerned > > about though, > > ... try a yum update over GSM or over a modem and you'll very soon > experience what I am talking about. Been there, done that occasionally. Scenarios like that just don't happen to be part of what I meant by "generally". But I'd have nothing against "purifying" x86_64 repos and instructing people who need something from ix86 repos to enable them as well. I suppose this is something PackageKit could even suggest on demand. Anyway I also suppose that if it was this simple, it would have been done already. From jonathan at jonmasters.org Wed Dec 9 18:40:38 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 09 Dec 2009 13:40:38 -0500 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260308728.3311.1994.camel@localhost.localdomain> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260308728.3311.1994.camel@localhost.localdomain> Message-ID: <1260384038.3027.411.camel@tonnant> On Tue, 2009-12-08 at 21:45 +0000, Bastien Nocera wrote: > On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote: > > The new gnome-volume-control is so cut-down it's not useful to me. In > > the quest to be more Mac-like in removing mixer controls > > No, it's in a quest of providing *solutions* to user's problems, and not > blindly showing everything the software and the hardware can do. I couldn't disagree more strongly. As a Linux user, I want the "show me everything" option. I don't care if I have to check a box to do it, but I want to see all the knobs and dials. And I at least expect not to have what I'm doing with alsamixer interfered with by the other tools. Jon. From jonathan at jonmasters.org Wed Dec 9 18:46:16 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 09 Dec 2009 13:46:16 -0500 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> Message-ID: <1260384376.3027.414.camel@tonnant> On Wed, 2009-12-09 at 02:44 -0500, Orcan Ogetbil wrote: > On Tue, Dec 8, 2009 at 2:05 PM, Jon Masters wrote: > > > > The new gnome-volume-control is so cut-down it's not useful to me. In > > the quest to be more Mac-like in removing mixer controls (and not even > > having any obvious "advanced" mode), I now have a choice of no audio or > > having full volume LFE output *and* whatever mixer level I have set for > > the master output. alsamixer works fine, but then I can't use the volume > > sliders on my desktop and it gets rather awkward. > Sadly, they consider this bug as an enhancement. I have had friends > who had the same hardware with me but they were using another OS. I > remember them being jealous because I had so much more control over > same sound card. It made me proud at the time. I fear that this > disease of oversimplifying will make us forget why we are using Linux. All paranoia and ranting aside, there is some truth to this. There is a definite trend in the Linux community to want to cater to the lowest common denominator by being more Mac/Windows-esque. I put up with it because I can usually ignore it (I refuse on principal to use a GUI to copy a file, for example, but that's just me being weird), but I don't see the harm in hiding the advanced stuff under a checkbox - the advanced mixer stuff is still there underneath after all. Jon. From linuxguy123 at gmail.com Wed Dec 9 19:20:03 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Wed, 09 Dec 2009 12:20:03 -0700 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> <20091209103632.62e51af0@leela> <1260365238.11526.38.camel@localhost.localdomain> Message-ID: <1260386403.11526.48.camel@localhost.localdomain> On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: > Linuxguy123 wrote: > > I have logged 2 bugs that are possibly related to this. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=528188 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=525767 > > Huh? One of these is a Nouveau bug, the other is a bug in the proprietary > nvidia driver, both of them already happened with F12 as released, so these > have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? I say they have similar symptoms. I said they *might* be related. I bet my bugs have nothing to do with the nouveau or nvidia drivers. I've been saying that all along. I guess we will find out. From jspaleta at gmail.com Wed Dec 9 19:24:16 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Dec 2009 10:24:16 -0900 Subject: Request for help maintaining packages while away. Message-ID: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> Good Alaskan Morning! In two weeks I'm going to be in Antarctica for a month+ and I'm looking for other packagers to step in for me and maintain my packages and prepare them for F13. I'm not exactly sure what my time and bandwidth access will be so I'm planning for the worst and that I'll be reliably off the grid through mid Feb. Please let me know if you can take on a co-maintainer/primary maintainer role for any of the packges and see them through the next couple of months. Here's the set of packages that I own. I will be contacting existing co-maintainers for individual packages in the list separately this week. ScientificPython -- A collection of Python modules that are useful for scientific computing g3data -- Program for extracting the data from scanned graphs gourmet -- Recipe Manager for the GNOME desktop environment gpodder -- Podcast receiver/catcher written in Python istanbul -- Desktop Session Recorder nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C pyscript -- PyScript - Postscript graphics with Python python-basemap -- Plots data on map projections (with continental and political boundaries) python-basemap-data -- Data for python-basemap python-dateutil -- Powerful extensions to the standard datetime module python-matplotlib -- Python plotting library python-xlib -- X client library for Python pytz -- World Timezone Definitions for Python revelation -- Password manager for GNOME 2 safekeep -- The SafeKeep backup system scipy -- Scipy: Scientific Tools for Python telescope-server -- Opensource Telescope control servers to interface with stellarium usbsink -- USBSink is a GNOME -jef"Does living in Alaska and travelling to Antarctica make me bipolar?"spaleta From limb at jcomserv.net Wed Dec 9 19:29:00 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 09 Dec 2009 13:29:00 -0600 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> Message-ID: <4B1FFA7C.6010303@jcomserv.net> Jeff Spaleta wrote: > Good Alaskan Morning! > > In two weeks I'm going to be in Antarctica for a month+ and I'm > looking for other packagers to step in for me and maintain my packages > and prepare them for F13. I'm not exactly sure what my time and > bandwidth access will be so I'm planning for the worst and that I'll > be reliably off the grid through mid Feb. Please let me know if you > can take on a co-maintainer/primary maintainer role for any of the > packges and see them through the next couple of months. > > Here's the set of packages that I own. I will be contacting existing > co-maintainers for individual packages in the list separately this > week. > > ScientificPython -- A collection of Python modules that are useful for > scientific computing > g3data -- Program for extracting the data from scanned graphs > gourmet -- Recipe Manager for the GNOME desktop environment > gpodder -- Podcast receiver/catcher written in Python > istanbul -- Desktop Session Recorder > nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C > pyscript -- PyScript - Postscript graphics with Python > python-basemap -- Plots data on map projections (with continental and > political boundaries) > python-basemap-data -- Data for python-basemap > python-dateutil -- Powerful extensions to the standard datetime module > python-matplotlib -- Python plotting library > python-xlib -- X client library for Python > pytz -- World Timezone Definitions for Python > revelation -- Password manager for GNOME 2 > safekeep -- The SafeKeep backup system > scipy -- Scipy: Scientific Tools for Python > telescope-server -- Opensource Telescope control servers to interface > with stellarium > usbsink -- USBSink is a GNOME > > > -jef"Does living in Alaska and travelling to Antarctica make me bipolar?"spaleta > > Sweet! Have a fun and safe trip. I can probably help out with scipy, I'll apply as co-maintainer. -- in your fear, seek only peace in your fear, seek only love -d. bowie From skvidal at fedoraproject.org Wed Dec 9 19:30:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 9 Dec 2009 14:30:31 -0500 (EST) Subject: Promoting i386 version over x86_64? In-Reply-To: <200912092037.07973.ville.skytta@iki.fi> References: <200912082226.15007.ville.skytta@iki.fi> <4B1F3708.5080903@freenet.de> <200912092037.07973.ville.skytta@iki.fi> Message-ID: On Wed, 9 Dec 2009, Ville Skytt? wrote: > On Wednesday 09 December 2009, Ralf Corsepius wrote: >> On 12/08/2009 09:26 PM, Ville Skytt? wrote: > >>> These probably aren't things to be generally overly concerned >>> about though, >> >> ... try a yum update over GSM or over a modem and you'll very soon >> experience what I am talking about. > > Been there, done that occasionally. Scenarios like that just don't happen to > be part of what I meant by "generally". > > But I'd have nothing against "purifying" x86_64 repos and instructing people > who need something from ix86 repos to enable them as well. I suppose this is > something PackageKit could even suggest on demand. Anyway I also suppose that > if it was this simple, it would have been done already. > if you want to purify x86_64 you can always add: exclude=*.i[3456]86 to your yum.conf under [main] -sv From jamatos at fc.up.pt Wed Dec 9 19:37:06 2009 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Wed, 9 Dec 2009 19:37:06 +0000 Subject: abrt issue In-Reply-To: References: Message-ID: <200912091937.06559.jamatos@fc.up.pt> On Wednesday 09 December 2009 12:47:44 Neal Becker wrote: > I just got a crash in kde plasma. Traceback is not useful, because of > missing debug pacakges. Downgrading hal and hal-libs fixes the crash. I noticed the other thread where this bug is reported. I was seeing both https://bugzilla.redhat.com/show_bug.cgi?id=545639 https://bugzilla.redhat.com/show_bug.cgi?id=545258 You need to downgrade hal-libs as well or else yum will pick hal-libs.i686 and that will require to install glibc.i686 and friends. -- Jos? Ab?lio From jspaleta at gmail.com Wed Dec 9 19:38:55 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Dec 2009 10:38:55 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <4B1FFA7C.6010303@jcomserv.net> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <4B1FFA7C.6010303@jcomserv.net> Message-ID: <604aa7910912091138o1a715f57y7d0b1ab0c1234323@mail.gmail.com> On Wed, Dec 9, 2009 at 10:29 AM, Jon Ciesla wrote: > Sweet! ?Have a fun and safe trip. > > I can probably help out with scipy, I'll apply as co-maintainer. For F13 you probably want to push latest versions of the both scipy and matplotlib together. So if you take scipy* sign up for matplotlib* as well. -jef From ville.skytta at iki.fi Wed Dec 9 20:39:37 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Wed, 9 Dec 2009 22:39:37 +0200 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <200912092037.07973.ville.skytta@iki.fi> Message-ID: <200912092239.38031.ville.skytta@iki.fi> On Wednesday 09 December 2009, Seth Vidal wrote: > On Wed, 9 Dec 2009, Ville Skytt? wrote: > > > But I'd have nothing against "purifying" x86_64 repos and instructing > > people who need something from ix86 repos to enable them as well. I > > suppose this is something PackageKit could even suggest on demand. > > Anyway I also suppose that if it was this simple, it would have been done > > already. > > if you want to purify x86_64 you can always add: > > exclude=*.i[3456]86 > > to your yum.conf under [main] Yeah, I've done that in some setups but I was talking about purifying the _repos_ above; that setting doesn't affect them, e.g. it doesn't make the metadata to be downloaded any smaller. (As said, not that I think it's a big general issue at all, but just that I'd personally have nothing against if it would be "fixed" nevertheless.) From awilliam at redhat.com Wed Dec 9 20:52:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 09 Dec 2009 12:52:24 -0800 Subject: Fedora release criteria completely revised In-Reply-To: <20091209135442.GA2748@mokona.greysector.net> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <20091209135442.GA2748@mokona.greysector.net> Message-ID: <1260391944.2412.3.camel@adam.local.net> On Wed, 2009-12-09 at 14:54 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 07 December 2009 at 23:55, Adam Williamson wrote: > [...] > > https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > 16. Automatic mounting on insertion of removable media must work > > It should be clarified with "... after GUI login", because it sure never > worked before a user is logged in. Also it never worked when user was > logged in via text console, did it? Good point - changed. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From vpivaini at cs.helsinki.fi Wed Dec 9 20:56:49 2009 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Wed, 09 Dec 2009 22:56:49 +0200 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> Message-ID: <1260392209.2000.2.camel@poytakone.lan> ke, 2009-12-09 kello 10:24 -0900, Jeff Spaleta kirjoitti: > gpodder -- Podcast receiver/catcher written in Python I've been following gPodder development for a while and have written a couple of patches, so I know some of the code, too. I'm interested in co-maintaining it and I've applied for commit access at pkgdb. -- Ville-Pekka Vainio From kevin.kofler at chello.at Wed Dec 9 21:03:49 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 09 Dec 2009 22:03:49 +0100 Subject: Promoting i386 version over x86_64? References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> <4B1FC796.2080209@bitwagon.com> Message-ID: John Reiser wrote: > Sometimes I doubt even that, particularly when shipped software > has python syntax errors (type mismatch, wrong number of arguments, > no such member, ...) The joys of interpreted languages? In a compiled language, such an error would just fail the build. Kevin Kofler From drago01 at gmail.com Wed Dec 9 21:07:50 2009 From: drago01 at gmail.com (drago01) Date: Wed, 9 Dec 2009 22:07:50 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> <4B1FC796.2080209@bitwagon.com> Message-ID: On Wed, Dec 9, 2009 at 10:03 PM, Kevin Kofler wrote: > John Reiser wrote: >> Sometimes I doubt even that, particularly when shipped software >> has python syntax errors (type mismatch, wrong number of arguments, >> no such member, ...) > > The joys of interpreted languages? In a compiled language, such an > error would just fail the build. where a sightly different error can lead to a segault or even a exploitable security hole .... (or in short every language has it pros and cons) From kevin.kofler at chello.at Wed Dec 9 21:10:46 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 09 Dec 2009 22:10:46 +0100 Subject: Promoting i386 version over x86_64? References: <200912092037.07973.ville.skytta@iki.fi> <200912092239.38031.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > Yeah, I've done that in some setups but I was talking about purifying the > _repos_ above; that setting doesn't affect them, e.g. it doesn't make the > metadata to be downloaded any smaller. (As said, not that I think it's a > big general issue at all, but just that I'd personally have nothing > against if it would be "fixed" nevertheless.) Kicking out multilibs from the repos might also make it much faster to compose updates repositories. A lot of time is wasted computing multilibs now. Kevin Kofler From kevin.kofler at chello.at Wed Dec 9 21:11:49 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 09 Dec 2009 22:11:49 +0100 Subject: Promoting i386 version over x86_64? References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> <20091209140051.GB2748@mokona.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski wrote: > Actually, x86_64 is an AMD invention (originally called AMD64) > and is called EM64T by Intel. The only "Intel 64" I can think of > is IA64, i.e. Itanium (called "Itanic" by some). EM64T was renamed to Intel 64 eons ago. Kevin Kofler From kevin.kofler at chello.at Wed Dec 9 21:18:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 09 Dec 2009 22:18:11 +0100 Subject: abrt issue References: <4B1F9E63.1030502@redhat.com> <4B1FA3B0.4060804@redhat.com> Message-ID: Neal Becker wrote: > I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't > give a good answer. Probably kdebase-workspace (and its dependencies, like kdelibs, but debuginfo-install takes care of that automatically). Kevin Kofler From stickster at gmail.com Wed Dec 9 21:26:16 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 9 Dec 2009 16:26:16 -0500 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> Message-ID: <20091209212616.GP9741@victoria.internal.frields.org> On Wed, Dec 09, 2009 at 10:24:16AM -0900, Jeff Spaleta wrote: > Good Alaskan Morning! > > In two weeks I'm going to be in Antarctica for a month+ and I'm > looking for other packagers to step in for me and maintain my packages > and prepare them for F13. I'm not exactly sure what my time and > bandwidth access will be so I'm planning for the worst and that I'll > be reliably off the grid through mid Feb. Please let me know if you > can take on a co-maintainer/primary maintainer role for any of the > packges and see them through the next couple of months. > > Here's the set of packages that I own. I will be contacting existing > co-maintainers for individual packages in the list separately this > week. > > ScientificPython -- A collection of Python modules that are useful for > scientific computing > g3data -- Program for extracting the data from scanned graphs > gourmet -- Recipe Manager for the GNOME desktop environment > gpodder -- Podcast receiver/catcher written in Python > istanbul -- Desktop Session Recorder > nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C > pyscript -- PyScript - Postscript graphics with Python > python-basemap -- Plots data on map projections (with continental and > political boundaries) > python-basemap-data -- Data for python-basemap > python-dateutil -- Powerful extensions to the standard datetime module > python-matplotlib -- Python plotting library > python-xlib -- X client library for Python > pytz -- World Timezone Definitions for Python > revelation -- Password manager for GNOME 2 > safekeep -- The SafeKeep backup system > scipy -- Scipy: Scientific Tools for Python > telescope-server -- Opensource Telescope control servers to interface > with stellarium > usbsink -- USBSink is a GNOME Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jspaleta at gmail.com Wed Dec 9 21:38:11 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Dec 2009 12:38:11 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <20091209212616.GP9741@victoria.internal.frields.org> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> Message-ID: <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: > Jef, I'll help with istanbul. ?If anyone else out there is considering > doing so, please feel free to team up with me. Other than revelation(which essentially has a dead upstream)...Istanbul is probably the most in need of more development love. Upstream seems to be inactive with no release activity in quite a while. There's a lot of deprecation warnings for some pygtk calls that I would love to clean up in time for F13. And there are a couple of abrt crash tickets being spawned by istanbul.. which maybe traced back to gdk libraries calls if I'm reading the crash dumps correctly. -jef From mclasen at redhat.com Wed Dec 9 21:45:21 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Dec 2009 16:45:21 -0500 Subject: Planning the accessibility stack rebase Message-ID: <1260395121.1747.59.camel@planemask> As some of you may know, the accessibility framework is getting ported from CORBA/ORBit to DBus [1]. The (ambitious) upstream plan is to have this transition completed in time for GNOME 2.30, ie within the F-13 timeframe. This is a big effort, and the accessibility guys need all the help they can get. To help with testing and feedback, I plan to get the new accessibility stack into rawhide in early January. I have done initial packages for the at-spi2 components [2], but they are not quite ready for prime time yet (they don't have the coexistence part entirely sorted out). Some details about the changes that coming: The CORBA-based at-spi package is being replaced by three components: at-spi2-core - protocol definitions and registry daemon at-spi2-atk - the atk-bridge GTK+ module pyatspi - Python bindings for at-spi There is no replacement for the cspi 'C bindings' at the moment. The current users of cspi are being ported to use D-Bus directly (mousetweaks) or replaced (gok being replaced by Caribou [3]). I am not sure about the porting status of dasher... To make the transition phase less painful, there are some efforts to allow the old and new stacks to coexist. The CORBA-based at-spi stuff will install its atk-bridge module and Python bindings somewhere else, and there will be a desktop file that sets the GTK_PATH environment variable and a pyatspi.pth Python module that sets some Python path. These path-tweaks will be triggered by a GConf key, allowing both stacks to be installed at the same time and allowing users and testers to switch back and forth between the stacks. It would be great if people who are interested in accessibility on Fedora could chime in and help with planning this to make the transition as smooth as it can. I'm sure there will be some bumps along the way anyway... Matthias PS Having written all this down, I realize that I should probably turn this into a feature page... [1] http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/at-spi/at-spi_on_d-bus [2] http://bugzilla.redhat.com/show_bug.cgi?id=544628 http://bugzilla.redhat.com/show_bug.cgi?id=544629 http://bugzilla.redhat.com/show_bug.cgi?id=544630 [3] http://live.gnome.org/Caribou From nicolas.mailhot at laposte.net Wed Dec 9 21:48:18 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 09 Dec 2009 22:48:18 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <200912082226.15007.ville.skytta@iki.fi> <4B1F3708.5080903@freenet.de> <200912092037.07973.ville.skytta@iki.fi> Message-ID: <1260395298.16026.1.camel@arekh.okg> Le mercredi 09 d?cembre 2009 ? 14:30 -0500, Seth Vidal a ?crit : > > if you want to purify x86_64 you can always add: > > exclude=*.i[3456]86 > > to your yum.conf under [main] However, it would be nice if a pure x86_64 index was generated somewhere for people who run pure 64 bit systems and do not want to download 32 bit metadata all year round just to exclude it localy -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From cmadams at hiwaay.net Wed Dec 9 21:49:37 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 9 Dec 2009 15:49:37 -0600 Subject: Promoting i386 version over x86_64? In-Reply-To: <200912092239.38031.ville.skytta@iki.fi> References: <200912092037.07973.ville.skytta@iki.fi> <200912092239.38031.ville.skytta@iki.fi> Message-ID: <20091209214937.GF1501488@hiwaay.net> Once upon a time, Ville Skytt? said: > Yeah, I've done that in some setups but I was talking about purifying the > _repos_ above; that setting doesn't affect them, e.g. it doesn't make the > metadata to be downloaded any smaller. (As said, not that I think it's a big > general issue at all, but just that I'd personally have nothing against if it > would be "fixed" nevertheless.) One way to make this smaller (without any overlap) would be to split the current two (i386 and x86_64) repos into three: i386-common, i386, x86_64. For an i386 system, you use i386 and i386-common, for a multilib x86_64 system you use x86_64 and i386-common, and for a pure x86_64 system you use just x86_64. I don't know if it is worth the trouble though. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at fedoraproject.org Wed Dec 9 21:51:07 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 9 Dec 2009 16:51:07 -0500 (EST) Subject: Promoting i386 version over x86_64? In-Reply-To: <20091209214937.GF1501488@hiwaay.net> References: <200912092037.07973.ville.skytta@iki.fi> <200912092239.38031.ville.skytta@iki.fi> <20091209214937.GF1501488@hiwaay.net> Message-ID: On Wed, 9 Dec 2009, Chris Adams wrote: > Once upon a time, Ville Skytt? said: >> Yeah, I've done that in some setups but I was talking about purifying the >> _repos_ above; that setting doesn't affect them, e.g. it doesn't make the >> metadata to be downloaded any smaller. (As said, not that I think it's a big >> general issue at all, but just that I'd personally have nothing against if it >> would be "fixed" nevertheless.) > > One way to make this smaller (without any overlap) would be to split the > current two (i386 and x86_64) repos into three: i386-common, i386, > x86_64. For an i386 system, you use i386 and i386-common, for a > multilib x86_64 system you use x86_64 and i386-common, and for a pure > x86_64 system you use just x86_64. > > I don't know if it is worth the trouble though. and then you have to do that as well for updates. :( -sv From andreas.tunek at gmail.com Wed Dec 9 21:52:35 2009 From: andreas.tunek at gmail.com (Andreas Tunek) Date: Wed, 09 Dec 2009 22:52:35 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260384376.3027.414.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260384376.3027.414.camel@tonnant> Message-ID: <1260395555.11173.2.camel@localhost.localdomain> ons 2009-12-09 klockan 13:46 -0500 skrev Jon Masters: > On Wed, 2009-12-09 at 02:44 -0500, Orcan Ogetbil wrote: > > On Tue, Dec 8, 2009 at 2:05 PM, Jon Masters wrote: > > > > > > The new gnome-volume-control is so cut-down it's not useful to me. In > > > the quest to be more Mac-like in removing mixer controls (and not even > > > having any obvious "advanced" mode), I now have a choice of no audio or > > > having full volume LFE output *and* whatever mixer level I have set for > > > the master output. alsamixer works fine, but then I can't use the volume > > > sliders on my desktop and it gets rather awkward. > > > Sadly, they consider this bug as an enhancement. I have had friends > > who had the same hardware with me but they were using another OS. I > > remember them being jealous because I had so much more control over > > same sound card. It made me proud at the time. I fear that this > > disease of oversimplifying will make us forget why we are using Linux. > > All paranoia and ranting aside, there is some truth to this. There is a > definite trend in the Linux community to want to cater to the lowest > common denominator by being more Mac/Windows-esque. I put up with it > because I can usually ignore it (I refuse on principal to use a GUI to > copy a file, for example, but that's just me being weird), but I don't > see the harm in hiding the advanced stuff under a checkbox - the > advanced mixer stuff is still there underneath after all. > Then why can't you use the old alsamixer? /Andreas > Jon. > > From gmaxwell at gmail.com Wed Dec 9 21:58:12 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 9 Dec 2009 16:58:12 -0500 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <200912092037.07973.ville.skytta@iki.fi> <200912092239.38031.ville.skytta@iki.fi> <20091209214937.GF1501488@hiwaay.net> Message-ID: On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal wrote: > and then you have to do that as well for updates. :( Not if you don't have a separate updates repo, no? From sundaram at fedoraproject.org Wed Dec 9 22:21:21 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 10 Dec 2009 03:51:21 +0530 Subject: Non responsive maintainer: Karol Trzcionka Message-ID: <4B2022E1.5050604@fedoraproject.org> Hi, As per policy at http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers, I have filed https://bugzilla.redhat.com/show_bug.cgi?id=546072 Rahul From debayanin at gmail.com Wed Dec 9 22:31:06 2009 From: debayanin at gmail.com (Debayan Banerjee) Date: Thu, 10 Dec 2009 04:01:06 +0530 Subject: Non responsive maintainer: Karol Trzcionka In-Reply-To: <4B2022E1.5050604@fedoraproject.org> References: <4B2022E1.5050604@fedoraproject.org> Message-ID: 2009/12/10 Rahul Sundaram : > Hi, > > As per policy at > http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers, > I have filed > > https://bugzilla.redhat.com/show_bug.cgi?id=546072 This person used to maintain the Tesseract OCR software. He has not packaged the latest version which is 2.04 . I work on this project actively, and would love to maintain the package. However, I am a complete n00b to RPM packaging, and would require some hand holding (I shall do the googling). > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Regards, Debayan Banerjee From debayanin at gmail.com Wed Dec 9 22:32:19 2009 From: debayanin at gmail.com (Debayan Banerjee) Date: Thu, 10 Dec 2009 04:02:19 +0530 Subject: Non responsive maintainer: Karol Trzcionka In-Reply-To: References: <4B2022E1.5050604@fedoraproject.org> Message-ID: 2009/12/10 Debayan Banerjee : > 2009/12/10 Rahul Sundaram : >> Hi, >> >> As per policy at >> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers, >> I have filed >> >> https://bugzilla.redhat.com/show_bug.cgi?id=546072 > > This person used to maintain the Tesseract OCR software. He has not > packaged the latest version which is 2.04 > . I work on > this project actively, and would love to maintain the package. > However, I am a complete n00b to RPM packaging, ermm, I do know how to write spec files, and build RPMs, but am a bit unsure about the process of uploading the packages upstream to Fedora repos. Again, I shall Google and learn. -- Regards, Debayan Banerjee From christoph.wickert at googlemail.com Wed Dec 9 22:39:05 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 09 Dec 2009 23:39:05 +0100 Subject: Non responsive maintainer: Karol Trzcionka In-Reply-To: References: <4B2022E1.5050604@fedoraproject.org> Message-ID: <1260398345.2581.2.camel@wicktop.localdomain> Am Donnerstag, den 10.12.2009, 04:02 +0530 schrieb Debayan Banerjee: > ermm, I do know how to write spec files, and build RPMs, but am a bit > unsure about the process of uploading the packages upstream to Fedora > repos. Again, I shall Google and learn. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Regards, Christoph From sundaram at fedoraproject.org Wed Dec 9 22:39:51 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 10 Dec 2009 04:09:51 +0530 Subject: Non responsive maintainer: Karol Trzcionka In-Reply-To: References: <4B2022E1.5050604@fedoraproject.org> Message-ID: <4B202737.8020300@fedoraproject.org> On 12/10/2009 04:02 AM, Debayan Banerjee wrote: > 2009/12/10 Debayan Banerjee >> 2009/12/10 Rahul Sundaram >>> Hi, >>> >>> As per policy at >>> http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers, >>> I have filed >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=546072 >> >> This person used to maintain the Tesseract OCR software. He has not >> packaged the latest version which is 2.04 >> . I work on >> this project actively, and would love to maintain the package. >> However, I am a complete n00b to RPM packaging, > > ermm, I do know how to write spec files, and build RPMs, but am a bit > unsure about the process of uploading the packages upstream to Fedora > repos. Again, I shall Google and learn. I see updates on other software up until Aug so not sure it is required yet but come up to #fedora-india and I will let you know the details. Rahul From notting at redhat.com Wed Dec 9 22:46:10 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Dec 2009 17:46:10 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 Message-ID: <20091209224610.GA20658@nostromo.devel.redhat.com> https://fedoraproject.org/wiki/Features/Upstart0.6.0 was approved at last week's FESCo meeting. It was built today, and will land in rawhide tomorrow. What this means for you: It's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. Once you reboot, things should work pretty much the same. All users have been converted with the exception of readahead[1], unless we missed some. Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Bill [1] because I missed in in the first scan and haven't had a chance to talk to the maintainer. From jamatos at fc.up.pt Wed Dec 9 23:23:39 2009 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 9 Dec 2009 23:23:39 +0000 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091138o1a715f57y7d0b1ab0c1234323@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <4B1FFA7C.6010303@jcomserv.net> <604aa7910912091138o1a715f57y7d0b1ab0c1234323@mail.gmail.com> Message-ID: <200912092323.39325.jamatos@fc.up.pt> On Wednesday 09 December 2009 19:38:55 Jeff Spaleta wrote: > For F13 you probably want to push latest versions of the both scipy > and matplotlib together. So if you take scipy* sign up for matplotlib* > as well. Not only those but also: python-basemap -- Plots data on map projections (with continental and political boundaries) python-basemap-data -- Data for python-basemap python-dateutil -- Powerful extensions to the standard datetime module pytz -- World Timezone Definitions for Python and also not directly related but ScientificPython -- A collection of Python modules that are useful for scientific computing is more or less on the bundle. Those are packages that interest me, and I would like to see them in good shape. :-) FWIW, the sage bundle would be a nice bonus. :-) > -jef -- Jos? Ab?lio From stickster at gmail.com Wed Dec 9 23:58:09 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 9 Dec 2009 18:58:09 -0500 Subject: Docs Installation Guide - Submission and Download problem In-Reply-To: <6d4237680912040051k15738b01x4b310e36a47eb83d@mail.gmail.com> References: <4B0B62F8.5090601@redhat.com> <4B14BEDA.9030504@gmail.com> <4B15C3A7.2020405@redhat.com> <6d4237680912012347t5f53cc1apba4e5682465b3e84@mail.gmail.com> <4B174117.7070606@redhat.com> <6d4237680912040051k15738b01x4b310e36a47eb83d@mail.gmail.com> Message-ID: <20091209235809.GH9741@victoria.internal.frields.org> On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote: > 2009/12/3 Ruediger Landmann : > > On 12/02/2009 05:47 PM, Dimitris Glezos wrote: > >> > >> Rudi, you could clear the cache and refresh it. > >> > > > > Really? How do I do that? I'd thought that a button like that would be useful for the > > maintainer of a project > > This button is available on the web interface on component pages for > maintainers. > > > , not least of which because changes to a POT in the repo don't automatically > > trigger a refresh (of course!) while submissions of updated POs do. > > This functionality has been available in Transifex for a while, it's > just that Fedora is still running an old (and unmaintained) version. Diego posted the summary of what needs to be done here: https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10 In short, we need a few people to step up and help with the process Diego posted. We already do have a L10n Admin group[1] that should be overseeing and managing this process, to ensure a successful rollout for translators. Their charter is to maintain the infrastructure for translators, and this clearly falls into that area. I've heard from two of the people in that group that they can't do all this work themselves, but haven't heard from Ankit or Asgeir about it. What I would suggest is that Diego should help with bullet #4 on that list, as it probably requires the greatest degree of specific technical knowledge, in this case a database upgrade. The rest of the work on that ticket could likely be done entirely by the remainder of the team, maybe with limited input from Diego. It would be helpful for Asgeir or Ankit to help manage this set of tasks in collaboration with Diego, who has appropriate package access. (I'm cc'ing Ignacio directly as well, so he can add appropriate CVS access for any other people who are willing to help maintain the EL-5 package used on our Infrastructure.) Without help, it's doubtful there will be a new Transifex rolled out, and that means some of the problems people are experiencing will continue, even though they're already fixed upstream. I'm cc'ing the docs, devel, and infrastructure lists to see if any of the people in areas well served by translators are willing to help see this project through. It's time to pull together, guys, and see if we can help the translators who give so much across the whole Fedora Project. * * * [1] https://fedoraproject.org/wiki/L10N/Tools#Website -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From snecklifter at gmail.com Thu Dec 10 00:22:25 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Dec 2009 00:22:25 +0000 Subject: kernel update highly recommended In-Reply-To: <20091209181453.GW28962@bombadil.infradead.org> References: <20091209181453.GW28962@bombadil.infradead.org> Message-ID: <364d303b0912091622g20d5dc8em973c23bda4df5c0f@mail.gmail.com> 2009/12/9 Kyle McMartin : > NOTE: This is only a problem if you're using EXT4, if you aren't, you're > safe. ReiserFS FTW!!! :) -- Christopher Brown From stickster at gmail.com Thu Dec 10 00:39:19 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 9 Dec 2009 19:39:19 -0500 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> Message-ID: <20091210003919.GN9741@victoria.internal.frields.org> On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote: > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: > > Jef, I'll help with istanbul. ?If anyone else out there is considering > > doing so, please feel free to team up with me. > > Other than revelation(which essentially has a dead > upstream)...Istanbul is probably the most in need of more development > love. Upstream seems to be inactive with no release activity in quite > a while. There's a lot of deprecation warnings for some pygtk calls > that I would love to clean up in time for F13. And there are a couple > of abrt crash tickets being spawned by istanbul.. which maybe traced > back to gdk libraries calls if I'm reading the crash dumps correctly. Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this weekend at FUDCon if memory serves. I'll also do what I can for existing bugs in my Copious Spare Time(tm). You might be interested in knowing that we had some discussion at FUDCon about extending my PulseCaster project (currently only functional in the most gracious sense) to cover more 'casting needs while maintaining a simple, usable interface: * Newscast -- single person audio, e.g. reading the news * Screencast -- single person audio + desktop screencap * Interview -- multi-person audio * App discussion or instruction -- multi-person audio + one desktop screencap * Save to file or send to streaming server I'm planning on spending some time on the project as part of my Christmas vacation. We had a lot of great ideas for how this functionality will work, but I do want some UI review for it including comparing it to GNOME HIG. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From noriko at redhat.com Thu Dec 10 01:45:23 2009 From: noriko at redhat.com (Noriko Mizumoto) Date: Thu, 10 Dec 2009 11:45:23 +1000 Subject: Docs Installation Guide - Submission and Download problem In-Reply-To: <20091209235809.GH9741@victoria.internal.frields.org> References: <4B0B62F8.5090601@redhat.com> <4B14BEDA.9030504@gmail.com> <4B15C3A7.2020405@redhat.com> <6d4237680912012347t5f53cc1apba4e5682465b3e84@mail.gmail.com> <4B174117.7070606@redhat.com> <6d4237680912040051k15738b01x4b310e36a47eb83d@mail.gmail.com> <20091209235809.GH9741@victoria.internal.frields.org> Message-ID: <4B2052B3.6080005@redhat.com> Paul W. Frields ????????: > On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote: >> 2009/12/3 Ruediger Landmann : >>> On 12/02/2009 05:47 PM, Dimitris Glezos wrote: >>>> Rudi, you could clear the cache and refresh it. >>>> >>> Really? How do I do that? I'd thought that a button like that would be useful for the >>> maintainer of a project >> This button is available on the web interface on component pages for >> maintainers. >> >>> , not least of which because changes to a POT in the repo don't automatically >>> trigger a refresh (of course!) while submissions of updated POs do. >> This functionality has been available in Transifex for a while, it's >> just that Fedora is still running an old (and unmaintained) version. > > Diego posted the summary of what needs to be done here: > > https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10 > > In short, we need a few people to step up and help with the process > Diego posted. > > We already do have a L10n Admin group[1] that should be overseeing and > managing this process, to ensure a successful rollout for translators. > Their charter is to maintain the infrastructure for translators, and > this clearly falls into that area. I've heard from two of the people > in that group that they can't do all this work themselves, but haven't > heard from Ankit or Asgeir about it. > > What I would suggest is that Diego should help with bullet #4 on that > list, as it probably requires the greatest degree of specific > technical knowledge, in this case a database upgrade. The rest of the > work on that ticket could likely be done entirely by the remainder of > the team, maybe with limited input from Diego. It would be helpful > for Asgeir or Ankit to help manage this set of tasks in collaboration > with Diego, who has appropriate package access. (I'm cc'ing Ignacio > directly as well, so he can add appropriate CVS access for any other > people who are willing to help maintain the EL-5 package used on our > Infrastructure.) > > Without help, it's doubtful there will be a new Transifex rolled out, > and that means some of the problems people are experiencing will > continue, even though they're already fixed upstream. I'm cc'ing the > docs, devel, and infrastructure lists to see if any of the people in > areas well served by translators are willing to help see this project > through. It's time to pull together, guys, and see if we can help the > translators who give so much across the whole Fedora Project. Thanks Paul, We are very much appreciated if any of you guys can give a hand to L10n team this time, as by coincidence both of Ankit and Asgeir are having leave (most likely traveling) and they might not be able have connection at all. I like to add brother i18n team as well. noriko > > * * * > [1] https://fedoraproject.org/wiki/L10N/Tools#Website > From jspaleta at gmail.com Thu Dec 10 01:50:39 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Dec 2009 16:50:39 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <20091210003919.GN9741@victoria.internal.frields.org> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> <20091210003919.GN9741@victoria.internal.frields.org> Message-ID: <604aa7910912091750ydf90e74r726d66c049838a4b@mail.gmail.com> On Wed, Dec 9, 2009 at 3:39 PM, Paul W. Frields wrote: > You might be interested in knowing that we had some discussion at > FUDCon about extending my PulseCaster project (currently only > functional in the most gracious sense) to cover more 'casting needs > while maintaining a simple, usable interface: Cool. If you can fold in instabul's use case inside PulseCaster's functionality...even better. I've no problem seeing istanbul obsoleted... long live progress. -jef From jkeating at redhat.com Thu Dec 10 02:15:53 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 09 Dec 2009 18:15:53 -0800 Subject: rawhide and tagging requests In-Reply-To: <1260369785.30425.8.camel@localhost.localdomain> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> Message-ID: <1260411353.30425.29.camel@localhost.localdomain> On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: > All the broken deps preventing a compose attempt have been cleared > out. > However the new rpm build was busted in a way that it made the compose > fall over, a new build of rpm is coming and I hope to kick off another > rawhide attempt when it lands. Ugh, things are still broken on the rpm front. My attempt from earlier fell over, may not get a fix in place for tonight's attempt either :/ -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Thu Dec 10 02:27:33 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 9 Dec 2009 20:27:33 -0600 Subject: rawhide and tagging requests In-Reply-To: <1260411353.30425.29.camel@localhost.localdomain> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> Message-ID: <20091210022733.GA3626@wolff.to> On Wed, Dec 09, 2009 at 18:15:53 -0800, Jesse Keating wrote: > On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: > > All the broken deps preventing a compose attempt have been cleared > > out. > > However the new rpm build was busted in a way that it made the compose > > fall over, a new build of rpm is coming and I hope to kick off another > > rawhide attempt when it lands. > > Ugh, things are still broken on the rpm front. My attempt from earlier > fell over, may not get a fix in place for tonight's attempt either :/ Thanks for the update. From skvidal at fedoraproject.org Thu Dec 10 03:17:08 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 9 Dec 2009 22:17:08 -0500 (EST) Subject: Promoting i386 version over x86_64? In-Reply-To: References: <200912092037.07973.ville.skytta@iki.fi> <200912092239.38031.ville.skytta@iki.fi> <20091209214937.GF1501488@hiwaay.net> Message-ID: On Wed, 9 Dec 2009, Gregory Maxwell wrote: > On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal wrote: >> and then you have to do that as well for updates. :( > > Not if you don't have a separate updates repo, no? > still need an updates-testing. -sv From vasily.v.levchenko at gmail.com Thu Dec 10 04:32:05 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Thu, 10 Dec 2009 07:32:05 +0300 Subject: X on UEFI systems. Message-ID: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> Hi, folks. Currently at Virtualbox has introduced UEFI support in 3.1 release. But there is one issue with X server. When trying configure X with -configure. Resulted xorg.conf.new looks right except missed Modes. Observing code I've supposed that missed information should be somehow fetched from screen info (prepared by EFIFB) via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't called and doing strace of X -configure the /dev/fb0 is open and than immediately closed ([pastebin.org]). So the question is what should be added in VirtualBox/UEFI firmware to get full xorg.conf? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf.new Type: application/octet-stream Size: 1906 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From airlied at redhat.com Thu Dec 10 05:06:15 2009 From: airlied at redhat.com (Dave Airlie) Date: Thu, 10 Dec 2009 15:06:15 +1000 Subject: X on UEFI systems. In-Reply-To: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> Message-ID: <1260421575.3307.0.camel@localhost> On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: > Hi, folks. > > > Currently at Virtualbox has introduced UEFI support in 3.1 release. > But there is one issue with X server. When trying configure X with > -configure. Resulted xorg.conf.new looks right except missed Modes. > Observing code I've supposed that missed information should be somehow > fetched from screen info (prepared by EFIFB) > via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't > called and doing strace of X -configure the /dev/fb0 is open and than > immediately closed ([pastebin.org]). So the question is what should be > added in VirtualBox/UEFI firmware to get full xorg.conf? > Does it not work without an xorg.conf, that would be the first goal. Dave. From kevin.kofler at chello.at Thu Dec 10 06:04:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Dec 2009 07:04:43 +0100 Subject: Planning the accessibility stack rebase References: <1260395121.1747.59.camel@planemask> Message-ID: Matthias Clasen wrote: > It would be great if people who are interested in accessibility on > Fedora could chime in and help with planning this to make the transition > as smooth as it can. I'm sure there will be some bumps along the way > anyway... This should also allow interoperability between Qt/KDE and GTK+/GNOME for accessibility in the long run. The required Qt code can be found here: https://labs.codethink.co.uk/index.php/p/qt-atspi2/ but I suspect it's still experimental. But I can try to package that once we have the rest of the at-spi2 stack in, then we'll see how well it works. Kevin Kofler From vasily.v.levchenko at gmail.com Thu Dec 10 06:36:36 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Thu, 10 Dec 2009 09:36:36 +0300 Subject: X on UEFI systems. In-Reply-To: <1260421575.3307.0.camel@localhost> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> Message-ID: <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> On Dec 10, 2009, at 8:06 AM, Dave Airlie wrote: > On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: >> Hi, folks. >> >> >> Currently at Virtualbox has introduced UEFI support in 3.1 release. >> But there is one issue with X server. When trying configure X with >> -configure. Resulted xorg.conf.new looks right except missed Modes. >> Observing code I've supposed that missed information should be somehow >> fetched from screen info (prepared by EFIFB) >> via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't >> called and doing strace of X -configure the /dev/fb0 is open and than >> immediately closed ([pastebin.org]). So the question is what should be >> added in VirtualBox/UEFI firmware to get full xorg.conf? >> > > Does it not work without an xorg.conf, that would be the first goal. > No. > Dave. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From mmcgrath at redhat.com Thu Dec 10 07:15:30 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 10 Dec 2009 01:15:30 -0600 (CST) Subject: Outage Notification - date -d '2009-12-11 02:00:00 UTC' Message-ID: There will be an outage starting at date -d '2009-12-11 02:00:00 UTC', which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d 'date -d '2009-12-11 02:00:00 UTC'' Affected Services: Database Fedora Hosted (Just auth against trac) Translation Services Websites Unaffected Services: Buildsystem CVS / Source Control DNS Fedora Talk Fedora People Mail Mirror System Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1845 Reason for Outage: Our temporary DB hosts are in PHX are ready to take on load. We're going to shut down db1 and db2, do an rsync then bring them up. During this time we'll also be configuring our new VPN. Also, a reminder for those who don't read the link, we'll be having a massive outage of many Fedora services this weekend while we are moving our servers to a new location. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From vasily.v.levchenko at gmail.com Thu Dec 10 07:31:51 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Thu, 10 Dec 2009 10:31:51 +0300 Subject: X on UEFI systems. In-Reply-To: <1260421575.3307.0.camel@localhost> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> Message-ID: <824C8223-3026-41CB-992A-B882232234E5@gmail.com> On Dec 10, 2009, at 8:06 AM, Dave Airlie wrote: > On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: >> Hi, folks. >> >> >> Currently at Virtualbox has introduced UEFI support in 3.1 release. >> But there is one issue with X server. When trying configure X with >> -configure. Resulted xorg.conf.new looks right except missed Modes. >> Observing code I've supposed that missed information should be somehow >> fetched from screen info (prepared by EFIFB) >> via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't >> called and doing strace of X -configure the /dev/fb0 is open and than >> immediately closed ([pastebin.org]). So the question is what should be >> added in VirtualBox/UEFI firmware to get full xorg.conf? >> > > Does it not work without an xorg.conf, that would be the first goal. > Right, ability to work with built-in config would be excellent :). I've debugged X and X -configure and noticed in both cases #0 fbdev_open (scrnIndex=, dev=0x1501fc "/dev/fb0", namep=0x0) at fbdevhw.c:412 #1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at fbdevhw.c:442 #2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=) at fbdev.c:394 #3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at xf86Init.c:663 #4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4) at xf86Init.c:939 #5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315 fbdev_open called with namep = 0, that blocks fetch information from efifb if (namep) { if (-1 == ioctl(fd,FBIOGET_FSCREENINFO,(void*)(&fix))) { *namep = NULL; xf86DrvMsg(scrnIndex, X_ERROR, "FBIOGET_FSCREENINFO: %s\n", strerror(errno)); return -1; } else { *namep = xnfalloc(16); strncpy(*namep,fix.id,16); } } calling right ioctl from gdb: (gdb) call ioctl(fd,0x4602,(void*)(&fix)) $2 = 0 (gdb) p fix $3 = {id = "EFI VGA\0\0\0\0\0\0\0\0", smem_start = 0x80000000
, smem_len = 6291456, type = 0, type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0, line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0, reserved = {0, 0, 0}} shows that efifb prepared right information for frame buffer clients. the difference between X and X -configure, is vesa driver (it seems) tries to occur information via libint10, assuming existence of VGA BIOS, which ofc is absent in our case. (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/lib/xorg/modules//libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.1.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) VESA(0): initializing int10 (EE) VESA(0): V_BIOS address 0x0 out of range (II) UnloadModule: "vesa" (II) UnloadModule: "int10" (II) Unloading /usr/lib/xorg/modules//libint10.so (II) UnloadModule: "vbe" (II) Unloading /usr/lib/xorg/modules//libvbe.so (EE) Screen(s) found, but none have a usable configuration. > Dave. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Thu Dec 10 08:56:15 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 10 Dec 2009 10:56:15 +0200 (EET) Subject: rawhide and tagging requests In-Reply-To: <1260411353.30425.29.camel@localhost.localdomain> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> Message-ID: On Wed, 9 Dec 2009, Jesse Keating wrote: > On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: >> All the broken deps preventing a compose attempt have been cleared >> out. >> However the new rpm build was busted in a way that it made the compose >> fall over, a new build of rpm is coming and I hope to kick off another >> rawhide attempt when it lands. > > Ugh, things are still broken on the rpm front. My attempt from earlier > fell over, may not get a fix in place for tonight's attempt either :/ Hmm, looking at the traceback at the end of http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's not at all clear whether this is rpm-python bustage or yum... the last good compose (from 20091203) was before this went in: * Thu Dec 3 2009 Seth Vidal - 3.2.25-2 - rebuild yum with latest HEAD patch - add rpmdb caching patch james wrote to see if it breaks everyone :) ...and the rpmdb caching patch does touch the area where it's crashing. Can you try a compose with yum tagged down to 3.2.25-1 just to cut down on the moving parts involved? Alternatively a reproducer that doesn't involve processing the entire rawhide would be helpful :) - Panu - From mcepl at redhat.com Thu Dec 10 07:57:34 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Thu, 10 Dec 2009 08:57:34 +0100 Subject: X on UEFI systems. In-Reply-To: <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> Message-ID: Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >> Does it not work without an xorg.conf, that would be the first goal. >> > > No. File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Why should I travel, when I'm already there? -- Bostonian lady, when being asked why she never visited other places than Boston From jkeating at redhat.com Thu Dec 10 09:17:56 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Dec 2009 01:17:56 -0800 Subject: rawhide and tagging requests In-Reply-To: References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> Message-ID: <1260436676.30425.32.camel@localhost.localdomain> On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: > Hmm, looking at the traceback at the end of > http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's > not at all clear whether this is rpm-python bustage or yum... the > last > good compose (from 20091203) was before this went in: > > * Thu Dec 3 2009 Seth Vidal - 3.2.25-2 > - rebuild yum with latest HEAD patch > - add rpmdb caching patch james wrote to see if it breaks everyone :) > > ...and the rpmdb caching patch does touch the area where it's > crashing. > Can you try a compose with yum tagged down to 3.2.25-1 just to cut > down on > the moving parts involved? > > Alternatively a reproducer that doesn't involve processing the entire > rawhide would be helpful :) > > Yeah, it could totally be yum, I didn't do much investigation into it. Just didn't have it in me as I'm stranded at an airport over night. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jreznik at redhat.com Thu Dec 10 09:27:52 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 10 Dec 2009 10:27:52 +0100 Subject: abrt issue In-Reply-To: References: <4B1FA3B0.4060804@redhat.com> Message-ID: <200912101027.52720.jreznik@redhat.com> On Wednesday 09 December 2009 14:23:47 Neal Becker wrote: > Jiri Moskovcak wrote: > > On 12/09/2009 02:05 PM, Neal Becker wrote: > >> Jiri Moskovcak wrote: > >>> On 12/09/2009 01:47 PM, Neal Becker wrote: > >>>> I just got a crash in kde plasma. Traceback is not useful, because of > >>>> missing debug pacakges. > >>>> > >>>> I'm told I can reload after 'installing the needed packages', but > >>>> there is no clue what packages are needed. > >>>> > >>>> A bit of a mystery. It seems sometimes abrt will go ahead and > >>>> download needed debuginfo packages, but other times (like today), it > >>>> doesn't, and doesn't offer any clue what packages are missing. > >>> > >>> Weird, ABRT should tell you the exact package you should install > >>> debuginfo for. I just tried that and abrt says this: > >>> > >>> Reporting disabled because the backtrace is unusable. > >>> Please try to install debuginfo manually by using command: > >>> *debuginfo-install python* > >>> the use the Refresh button to regenerate the backtrace. > >>> > >>> Jirka > >> > >> Yes, I've gotten messages like this sometimes, and that's what I was > >> looking > >> for. But not today. > >> > >> Maybe related? > >> Dec 9 07:50:11 localhost abrtd: New crash, saving > >> Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not > >> successful: Plugin 'RunApp' is not registered > > > > This shouldn't be related, but I'm wondering where did you get the line > > "reload after 'installing the needed packages'" it doesn't come from > > ABRT. > > This is not an exact quote, but it's what I got from abrt when I clicked on > 'next'. You probably mean Dr. Konqui and not Abrt ;-) KDE is still using Dr. Konqui! There's some sort of debuginfo packages auto downloading but we're considering Abrt usage in Fedora KDE too as it better integrates to Fedora. The plan is even for native KDE/Qt Abrt GUI! Ping Abrt people - do you need a help? What's the status? Jaroslav > I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't > give a good answer. Why isn't abrt telling me? > -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From vasily.v.levchenko at gmail.com Thu Dec 10 09:28:37 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Thu, 10 Dec 2009 12:28:37 +0300 Subject: X on UEFI systems. In-Reply-To: References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> Message-ID: On Dec 10, 2009, at 10:57 AM, Mat?j Cepl wrote: > Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >>> Does it not work without an xorg.conf, that would be the first goal. >>> >> >> No. > > File a bug please, attaching your xorg.conf, Xorg.0.log and output of > the dmesg command (all from inside of VB virtual machine, of course). > the bug is filed https://bugzilla.redhat.com/show_bug.cgi?id=546166 please let me know if more information is required. > Mat?j > > -- > http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz > GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC > > Why should I travel, when I'm already there? > -- Bostonian lady, when being asked why she never visited > other places than Boston > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From dominik at greysector.net Thu Dec 10 11:20:28 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 10 Dec 2009 12:20:28 +0100 Subject: Promoting i386 version over x86_64? In-Reply-To: References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> <20091209140051.GB2748@mokona.greysector.net> Message-ID: <20091210112028.GB12784@mokona.greysector.net> On Wednesday, 09 December 2009 at 22:11, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski wrote: > > Actually, x86_64 is an AMD invention (originally called AMD64) > > and is called EM64T by Intel. The only "Intel 64" I can think of > > is IA64, i.e. Itanium (called "Itanic" by some). > > EM64T was renamed to Intel 64 eons ago. Call me a dinosaur, then. ;) I stand corrected. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rajeeshknambiar at gmail.com Thu Dec 10 12:30:42 2009 From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar) Date: Thu, 10 Dec 2009 18:00:42 +0530 Subject: yum doesn't like installonly_limit=1? Message-ID: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> I changed the "installonly_limit" to "1" from the default value "3" in /etc/yum.conf, and yum blows up. # yum search boinc Loaded plugins: presto, refresh-packagekit Options Error: Error parsing '1': out of range integer value PackageKit gave me a better traceback: Traceback (most recent call last): File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2956, in __init__ self.repos.confirm_func = self._repo_gpg_confirm File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 717, in repos = property(fget=lambda self: self._getRepos(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 496, in _getRepos self.conf # touch the config class first File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 723, in conf = property(fget=lambda self: self._getConfig(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 276, in _getConfig self._conf = config.readMainConfig(startupconf) File "/usr/lib/python2.6/site-packages/yum/config.py", line 827, in readMainConfig yumconf.populate(startupconf._parser, 'main') File "/usr/lib/python2.6/site-packages/yum/config.py", line 505, in populate setattr(self, name, value) File "/usr/lib/python2.6/site-packages/yum/config.py", line 94, in __set__ raise ValueError('Error parsing $r: $s' $ (value, str(e))) ValueError: Error parsing '1': out of range integer value I changed the value to 0, 2, 3 etc, all of them resulting in a working yum environment. Is it a known issue, or worth filing a bug? Yum version is yum-3.2.25-1.fc12.noarch -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com From skvidal at fedoraproject.org Thu Dec 10 13:01:39 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 10 Dec 2009 08:01:39 -0500 (EST) Subject: rawhide and tagging requests In-Reply-To: <1260436676.30425.32.camel@localhost.localdomain> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260436676.30425.32.camel@localhost.localdomain> Message-ID: On Thu, 10 Dec 2009, Jesse Keating wrote: > On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: >> Hmm, looking at the traceback at the end of >> http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's >> not at all clear whether this is rpm-python bustage or yum... the >> last >> good compose (from 20091203) was before this went in: >> >> * Thu Dec 3 2009 Seth Vidal - 3.2.25-2 >> - rebuild yum with latest HEAD patch >> - add rpmdb caching patch james wrote to see if it breaks everyone :) >> >> ...and the rpmdb caching patch does touch the area where it's >> crashing. >> Can you try a compose with yum tagged down to 3.2.25-1 just to cut >> down on >> the moving parts involved? >> >> Alternatively a reproducer that doesn't involve processing the entire >> rawhide would be helpful :) >> >> > > Yeah, it could totally be yum, I didn't do much investigation into it. > Just didn't have it in me as I'm stranded at an airport over night. Looking at the rpmdb caching patch I'm not sure how it could be that. The parsing of local pkgs (what createrepo does) doesn't hit the rpmdb. -sv From pmatilai at laiskiainen.org Thu Dec 10 13:07:21 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 10 Dec 2009 15:07:21 +0200 (EET) Subject: rawhide and tagging requests In-Reply-To: References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260436676.30425.32.camel@localhost.localdomain> Message-ID: On Thu, 10 Dec 2009, Seth Vidal wrote: > > On Thu, 10 Dec 2009, Jesse Keating wrote: > >> On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: >>> Hmm, looking at the traceback at the end of >>> http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's >>> not at all clear whether this is rpm-python bustage or yum... the >>> last >>> good compose (from 20091203) was before this went in: >>> >>> * Thu Dec 3 2009 Seth Vidal - 3.2.25-2 >>> - rebuild yum with latest HEAD patch >>> - add rpmdb caching patch james wrote to see if it breaks everyone :) >>> >>> ...and the rpmdb caching patch does touch the area where it's >>> crashing. >>> Can you try a compose with yum tagged down to 3.2.25-1 just to cut >>> down on >>> the moving parts involved? >>> >>> Alternatively a reproducer that doesn't involve processing the entire >>> rawhide would be helpful :) >>> >>> >> >> Yeah, it could totally be yum, I didn't do much investigation into it. >> Just didn't have it in me as I'm stranded at an airport over night. > > Looking at the rpmdb caching patch I'm not sure how it could be that. The > parsing of local pkgs (what createrepo does) doesn't hit the rpmdb. Yup, but this isn't createrepo crashing (the earlier one was): 2009-12-09 20:11:04 mash: createrepo: finished /mnt/koji/mash/rawhide-20091209/development/x86_64/os/ 2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method devel 2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish... 2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64 Traceback (most recent call last): File "/usr/bin/mash", line 96, in main() File "/usr/bin/mash", line 84, in main rc = themash.doMultilib() File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 538, in doMultilib pid = self.doDepSolveAndMultilib(arch, repocache) File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 511, in doDepSolveAndMultilib (rc, errors) = yumbase.resolveDeps() File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 718, in resolveDeps for po, dep in self._checkFileRequires(): File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 1012, in _checkFileRequires po = self.getInstalledPackageObject(pkgtup) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2421, in getInstalledPackageObject raise Errors.RpmDBError, _('Package tuple %s could not be found in rpmdb') % str(pkgtup) yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch', '0', '0.95.3', '1301.fc13') could not be found in rpmdb - Panu - From skvidal at fedoraproject.org Thu Dec 10 13:16:04 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 10 Dec 2009 08:16:04 -0500 (EST) Subject: rawhide and tagging requests In-Reply-To: References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260436676.30425.32.camel@localhost.localdomain> Message-ID: On Thu, 10 Dec 2009, Panu Matilainen wrote: > Yup, but this isn't createrepo crashing (the earlier one was): > > 2009-12-09 20:11:04 mash: createrepo: finished > /mnt/koji/mash/rawhide-20091209/development/x86_64/os/ > 2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method > devel > 2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish... > 2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64 > Traceback (most recent call last): > File "/usr/bin/mash", line 96, in > main() > File "/usr/bin/mash", line 84, in main > rc = themash.doMultilib() > File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 538, in > doMultilib > pid = self.doDepSolveAndMultilib(arch, repocache) > File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 511, in > doDepSolveAndMultilib > (rc, errors) = yumbase.resolveDeps() > File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 718, in > resolveDeps > for po, dep in self._checkFileRequires(): > File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 1012, in > _checkFileRequires > po = self.getInstalledPackageObject(pkgtup) > File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2421, in > getInstalledPackageObject > raise Errors.RpmDBError, _('Package tuple %s could not be found in > rpmdb') % str(pkgtup) > yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch', > '0', '0.95.3', '1301.fc13') could not be found in rpmdb My mistake - I thought we were talking about the earlier traceback. Yes, the above looks like it could be caching. I'll see what I can do. -sv From limb at jcomserv.net Thu Dec 10 13:21:26 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 10 Dec 2009 07:21:26 -0600 Subject: Request for help maintaining packages while away. In-Reply-To: <200912092323.39325.jamatos@fc.up.pt> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <4B1FFA7C.6010303@jcomserv.net> <604aa7910912091138o1a715f57y7d0b1ab0c1234323@mail.gmail.com> <200912092323.39325.jamatos@fc.up.pt> Message-ID: <4B20F5D6.9040000@jcomserv.net> Jos? Matos wrote: > On Wednesday 09 December 2009 19:38:55 Jeff Spaleta wrote: > >> For F13 you probably want to push latest versions of the both scipy >> and matplotlib together. So if you take scipy* sign up for matplotlib* >> as well. >> > > Not only those but also: > python-basemap -- Plots data on map projections (with continental and > political boundaries) > python-basemap-data -- Data for python-basemap > python-dateutil -- Powerful extensions to the standard datetime module > pytz -- World Timezone Definitions for Python > > and also not directly related but > ScientificPython -- A collection of Python modules that are useful for > scientific computing > > is more or less on the bundle. > > Those are packages that interest me, and I would like to see them in good > shape. :-) > > FWIW, the sage bundle would be a nice bonus. :-) > > >> -jef >> > > I've added myself to scipy, python-matplotlib, and the above. I'll try to get to the updates. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From james at fedoraproject.org Thu Dec 10 14:28:12 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 10 Dec 2009 09:28:12 -0500 Subject: yum doesn't like installonly_limit=1? In-Reply-To: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> References: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> Message-ID: <1260455292.13006.1500.camel@code.and.org> On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: > I changed the "installonly_limit" to "1" from the default value "3" in > /etc/yum.conf, and yum blows up. > > # yum search boinc > Loaded plugins: presto, refresh-packagekit > Options Error: Error parsing '1': out of range integer value This is an error message, not what I'd usually term "blows up". > PackageKit gave me a better traceback: This is just more text to say the same thing, 1 is an invalid argument. > I changed the value to 0, 2, 3 etc, all of them resulting in a working > yum environment. Is it a known issue, or worth filing a bug? > Yum version is yum-3.2.25-1.fc12.noarch Maybe3 a better question is: What do you want to achieve by setting this value to 1? -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From james at fedoraproject.org Thu Dec 10 14:39:26 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 10 Dec 2009 09:39:26 -0500 Subject: rawhide and tagging requests In-Reply-To: References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260436676.30425.32.camel@localhost.localdomain> Message-ID: <1260455966.13006.1515.camel@code.and.org> On Thu, 2009-12-10 at 08:16 -0500, Seth Vidal wrote: > > On Thu, 10 Dec 2009, Panu Matilainen wrote: > > > Yup, but this isn't createrepo crashing (the earlier one was): > > > > 2009-12-09 20:11:04 mash: createrepo: finished > > /mnt/koji/mash/rawhide-20091209/development/x86_64/os/ > > 2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method > > devel > > 2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish... > > 2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64 > > Traceback (most recent call last): > > File "/usr/bin/mash", line 96, in > > main() > > File "/usr/bin/mash", line 84, in main > > rc = themash.doMultilib() > > File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 538, in > > doMultilib > > pid = self.doDepSolveAndMultilib(arch, repocache) > > File "/usr/lib/python2.6/site-packages/mash/__init__.py", line 511, in > > doDepSolveAndMultilib > > (rc, errors) = yumbase.resolveDeps() > > File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 718, in > > resolveDeps > > for po, dep in self._checkFileRequires(): > > File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 1012, in > > _checkFileRequires > > po = self.getInstalledPackageObject(pkgtup) > > File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2421, in > > getInstalledPackageObject > > raise Errors.RpmDBError, _('Package tuple %s could not be found in > > rpmdb') % str(pkgtup) > > yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch', > > '0', '0.95.3', '1301.fc13') could not be found in rpmdb Gah, I see the problem. clamav-scanner-upstart is in the transaction, to be installed, but we are only looking in the rpmdb. My fault, off to do a patch. From james at fedoraproject.org Thu Dec 10 14:52:06 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 10 Dec 2009 09:52:06 -0500 Subject: rawhide and tagging requests In-Reply-To: References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> Message-ID: <1260456726.13006.1529.camel@code.and.org> On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: > On Wed, 9 Dec 2009, Jesse Keating wrote: > > > On Wed, 2009-12-09 at 06:43 -0800, Jesse Keating wrote: > >> All the broken deps preventing a compose attempt have been cleared > >> out. > >> However the new rpm build was busted in a way that it made the compose > >> fall over, a new build of rpm is coming and I hope to kick off another > >> rawhide attempt when it lands. > > > > Ugh, things are still broken on the rpm front. My attempt from earlier > > fell over, may not get a fix in place for tonight's attempt either :/ > > Hmm, looking at the traceback at the end of > http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log Note that while I fixed the bug which caused the traceback, the traceback is in a code path that means "clamav-scanner-upstart" has a file dep. that can't be satisfied ... so I'm not sure if that means the compose will fail anyway? -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From notting at redhat.com Thu Dec 10 14:54:46 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Dec 2009 09:54:46 -0500 Subject: rawhide and tagging requests In-Reply-To: <1260456726.13006.1529.camel@code.and.org> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260456726.13006.1529.camel@code.and.org> Message-ID: <20091210145445.GB17118@nostromo.devel.redhat.com> James Antill (james at fedoraproject.org) said: > > Hmm, looking at the traceback at the end of > > http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log > > Note that while I fixed the bug which caused the traceback, the > traceback is in a code path that means "clamav-scanner-upstart" has a > file dep. that can't be satisfied ... so I'm not sure if that means the > compose will fail anyway? Broken deps will only fail the compose if they're critical enough to prevent composing the chroot that rawhide composes in (essentially, dependnecies of mash - yum, python, etc.). clamav-scanner-upstart would not fall into that category. Bill From rajeeshknambiar at gmail.com Thu Dec 10 15:15:39 2009 From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar) Date: Thu, 10 Dec 2009 20:45:39 +0530 Subject: yum doesn't like installonly_limit=1? In-Reply-To: <1260455292.13006.1500.camel@code.and.org> References: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> <1260455292.13006.1500.camel@code.and.org> Message-ID: <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> On 12/10/09, James Antill wrote: > On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: >> I changed the "installonly_limit" to "1" from the default value "3" in >> /etc/yum.conf, and yum blows up. >> >> # yum search boinc >> Loaded plugins: presto, refresh-packagekit >> Options Error: Error parsing '1': out of range integer value > > This is an error message, not what I'd usually term "blows up". I mean - can't install anything, can't search a package. It took me a while to realize that the change made to the config file caused it as I tried to use yum again after couple of days. > >> PackageKit gave me a better traceback: > > This is just more text to say the same thing, 1 is an invalid argument. > >> I changed the value to 0, 2, 3 etc, all of them resulting in a working >> yum environment. Is it a known issue, or worth filing a bug? >> Yum version is yum-3.2.25-1.fc12.noarch > > Maybe3 a better question is: > > What do you want to achieve by setting this value to 1? Ah, I realize that it would have the same effect as installonly_limit=0 ? > > -- > James Antill - james at fedoraproject.org > http://yum.baseurl.org/wiki/releases > http://yum.baseurl.org/wiki/whatsnew/3.2.25 > http://yum.baseurl.org/wiki/YumMultipleMachineCaching > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com From skvidal at fedoraproject.org Thu Dec 10 15:17:25 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 10 Dec 2009 10:17:25 -0500 (EST) Subject: yum doesn't like installonly_limit=1? In-Reply-To: <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> References: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> <1260455292.13006.1500.camel@code.and.org> <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> Message-ID: On Thu, 10 Dec 2009, Rajeesh K Nambiar wrote: > On 12/10/09, James Antill wrote: >> On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: >>> I changed the "installonly_limit" to "1" from the default value "3" in >>> /etc/yum.conf, and yum blows up. >>> >>> # yum search boinc >>> Loaded plugins: presto, refresh-packagekit >>> Options Error: Error parsing '1': out of range integer value >> >> This is an error message, not what I'd usually term "blows up". > > I mean - can't install anything, can't search a package. It took me a > while to realize that the change made to the config file caused it as > I tried to use yum again after couple of days. The message should include what option is not able to be parsed. I'll fix it up. thanks, -sv From jmforbes at linuxtx.org Thu Dec 10 15:29:37 2009 From: jmforbes at linuxtx.org (Justin M. Forbes) Date: Thu, 10 Dec 2009 09:29:37 -0600 Subject: Promoting i386 version over x86_64? In-Reply-To: <20091210112028.GB12784@mokona.greysector.net> References: <4B05BC21.4040701@bfccomputing.com> <1260299266.3027.370.camel@tonnant> <20091209140051.GB2748@mokona.greysector.net> <20091210112028.GB12784@mokona.greysector.net> Message-ID: <20091210152937.GB29153@linuxtx.org> On Thu, Dec 10, 2009 at 12:20:28PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 09 December 2009 at 22:11, Kevin Kofler wrote: > > Dominik 'Rathann' Mierzejewski wrote: > > > Actually, x86_64 is an AMD invention (originally called AMD64) > > > and is called EM64T by Intel. The only "Intel 64" I can think of > > > is IA64, i.e. Itanium (called "Itanic" by some). > > > > EM64T was renamed to Intel 64 eons ago. > > Call me a dinosaur, then. ;) > I stand corrected. > Easy mistake to make considering it started as CT, then was IA-32e, then EM64T, and finally Intel 64. All of them refer to the same thing at some point. Justin From james at fedoraproject.org Thu Dec 10 15:52:40 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 10 Dec 2009 10:52:40 -0500 Subject: yum doesn't like installonly_limit=1? In-Reply-To: <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> References: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> <1260455292.13006.1500.camel@code.and.org> <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> Message-ID: <1260460360.13006.1595.camel@code.and.org> On Thu, 2009-12-10 at 20:45 +0530, Rajeesh K Nambiar wrote: > On 12/10/09, James Antill wrote: > > On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: > >> I changed the "installonly_limit" to "1" from the default value "3" in > >> /etc/yum.conf, and yum blows up. > >> > >> # yum search boinc > >> Loaded plugins: presto, refresh-packagekit > >> Options Error: Error parsing '1': out of range integer value > > > > This is an error message, not what I'd usually term "blows up". > > I mean - can't install anything, can't search a package. It took me a > while to realize that the change made to the config file caused it as > I tried to use yum again after couple of days. Fair enough, as Seth said we should probably tell you want option is the problem :). > > What do you want to achieve by setting this value to 1? > > Ah, I realize that it would have the same effect as installonly_limit=0 ? No, 0 is "special" and means the same thing as "". "1" would make it act like a normal package (old version removed as new version is installed) ... except the kernel package doesn't work if you do that, so we just disallow it. -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From notting at redhat.com Thu Dec 10 16:56:49 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Dec 2009 11:56:49 -0500 Subject: rawhide and tagging requests In-Reply-To: <1260455966.13006.1515.camel@code.and.org> References: <5256d0b0912090625l3b111919ic4c9e14143982496@mail.gmail.com> <1260369785.30425.8.camel@localhost.localdomain> <1260411353.30425.29.camel@localhost.localdomain> <1260436676.30425.32.camel@localhost.localdomain> <1260455966.13006.1515.camel@code.and.org> Message-ID: <20091210165647.GA27259@nostromo.devel.redhat.com> James Antill (james at fedoraproject.org) said: > Gah, I see the problem. clamav-scanner-upstart is in the transaction, > to be installed, but we are only looking in the rpmdb. My fault, off to > do a patch. I've kicked off a new rawhide with the patched yum. Bill From henriquecsj at gmail.com Thu Dec 10 17:05:55 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Thu, 10 Dec 2009 15:05:55 -0200 Subject: MariaDB and Fedora Message-ID: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> Hello everyone, There are, currently, someone with the intention of bringing MariaDB for Fedora? -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From itamar at ispbrasil.com.br Thu Dec 10 17:26:22 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 10 Dec 2009 15:26:22 -0200 Subject: MariaDB and Fedora In-Reply-To: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 3:05 PM, Henrique Junior wrote: > Hello everyone, > There are, currently, someone with the intention of bringing MariaDB for > Fedora? > I think postgresql won. the future of MySQL is not clear -- ------------ Itamar Reis Peixoto e-mail/msn/google talk/sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From henriquecsj at gmail.com Thu Dec 10 17:38:10 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Thu, 10 Dec 2009 15:38:10 -0200 Subject: MariaDB and Fedora In-Reply-To: References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> Message-ID: <1260466690.2963.3.camel@localhost> Em Qui, 2009-12-10 ?s 15:26 -0200, Itamar Reis Peixoto escreveu: > On Thu, Dec 10, 2009 at 3:05 PM, Henrique Junior wrote: > > Hello everyone, > > There are, currently, someone with the intention of bringing MariaDB for > > Fedora? > > > > I think postgresql won. > > the future of MySQL is not clear > > > > -- > ------------ > > Itamar Reis Peixoto > > e-mail/msn/google talk/sip: itamar at ispbrasil.com.br > skype: itamarjp > icq: 81053601 > +55 11 4063 5033 > +55 34 3221 8599 > I agree that postgresql is great, but MariaDB is expanding very fast. I'm not the best person to opine about databases, my experience is very limited, but it would be nice to keep an eye on MariaDB. -- Henrique Junior From rajeeshknambiar at gmail.com Thu Dec 10 18:08:54 2009 From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar) Date: Thu, 10 Dec 2009 23:38:54 +0530 Subject: yum doesn't like installonly_limit=1? In-Reply-To: <1260460360.13006.1595.camel@code.and.org> References: <815462c80912100430s52138ea8icb5a253819479137@mail.gmail.com> <1260455292.13006.1500.camel@code.and.org> <815462c80912100715m5d8bac21j5198ed21b5724c5b@mail.gmail.com> <1260460360.13006.1595.camel@code.and.org> Message-ID: <815462c80912101008x63bacb2dga64fd450f87bba94@mail.gmail.com> On Thu, Dec 10, 2009 at 9:22 PM, James Antill wrote: > On Thu, 2009-12-10 at 20:45 +0530, Rajeesh K Nambiar wrote: >> On 12/10/09, James Antill wrote: >> > On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: >> >> I changed the "installonly_limit" to "1" from the default value "3" in >> >> /etc/yum.conf, and yum blows up. >> >> >> >> # yum search boinc >> >> Loaded plugins: presto, refresh-packagekit >> >> Options Error: Error parsing '1': out of range integer value >> > >> > ?This is an error message, not what I'd usually term "blows up". >> >> I mean - can't install anything, can't search a package. It took me a >> while to realize that the change made to the config file caused it as >> I tried to use yum again after couple of days. > > ?Fair enough, as Seth said we should probably tell you want option is > the problem :). > >> > ?What do you want to achieve by setting this value to 1? >> >> Ah, I realize that it would have the same effect as installonly_limit=0 ? > > ?No, 0 is "special" and means the same thing as "". > > ?"1" would make it act like a normal package (old version removed as new > version is installed) ... except the kernel package doesn't work if you > do that, so we just disallow it. > Yeah, that was the intention ;-) Thanks for the answers! > -- > James Antill - james at fedoraproject.org > http://yum.baseurl.org/wiki/releases > http://yum.baseurl.org/wiki/whatsnew/3.2.25 > http://yum.baseurl.org/wiki/YumMultipleMachineCaching > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com From jwboyer at gmail.com Thu Dec 10 11:52:22 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 10 Dec 2009 06:52:22 -0500 Subject: Reminder: Tomorrow is the last F10 updates push Message-ID: <20091210115222.GH7691@hansolo.jdub.homelinux.org> Hi All, Just a friendly reminder that Dec 11 00:00:00 UTC is the cutoff for F10 updates submission. Ideally these would just be the final stable updates, as pushes to updates-testing would basically be stuck there forever. Please take a few moments to review your pending requests, add any final stable updates you'd like pushed, and clear out any update requests that don't make much sense for a soon to be EOL'd distro. josh _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From philipp_subx at redfish-solutions.com Thu Dec 10 18:43:54 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Thu, 10 Dec 2009 10:43:54 -0800 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4A66B3BC.90303@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> Message-ID: <4B21416A.1040204@redfish-solutions.com> On 07/21/2009 11:37 PM, Philip A. Prindeville wrote: > Philip A. Prindeville wrote: > >> Hi. >> >> I need a sponsor for this. An RPM has been built on several systems >> (including FC8 and FC9 and Centos5) and tested on all of those. >> >> The ticket has been languishing now unassigned for almost a year. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=452636 >> >> Can someone please pick this up? >> >> It's just an .src.rpm for Apache's mod_proxy_html. >> >> It's pretty trivial. >> >> Thanks, >> >> -Philip >> >> >> > Wow. Who knew sponsors were that hard to come by? Especially when most > of the work is already done... > > -Philip > Still looking for a sponsor... and a list of bugs to do mock code reviews of... From Jochen at herr-schmitt.de Thu Dec 10 19:00:04 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 10 Dec 2009 20:00:04 +0100 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4B21416A.1040204@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> <4B21416A.1040204@redfish-solutions.com> Message-ID: <4B214534.70309@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.12.2009 19:43, schrieb Philip A. Prindeville: > On 07/21/2009 11:37 PM, Philip A. Prindeville wrote: >> Philip A. Prindeville wrote: >> >>> Hi. >>> >>> I need a sponsor for this. An RPM has been built on several >>> systems (including FC8 and FC9 and Centos5) and tested on all >>> of those. >>> >>> The ticket has been languishing now unassigned for almost a >>> year. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=452636 >>> >>> Can someone please pick this up? >>> >>> It's just an .src.rpm for Apache's mod_proxy_html. >>> >>> It's pretty trivial. >>> >>> Thanks, >>> >>> -Philip >>> >>> >>> >> Wow. Who knew sponsors were that hard to come by? Especially >> when most of the work is already done... >> >> -Philip >> > > Still looking for a sponsor... and a list of bugs to do mock code > reviews of... > > I have take a look on it and have to recorgnise, that the packaged release is outdated. So if you may create a package based on the current release, I may willing to sponsor you. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkshRTQACgkQZLAIBz9lVu8jaAQA6dA9rlTal7hGUDGwc8u9bVK2 R99E2sbcpdjKjogAyB96i+//aqySBBOHvoAiDpqxM4Aw5gbaDfGyLIvSGbCG2HjW os9HPBiIXdFOmM34n3DLb8EfGpLnLwqHhTZ+QUYhLeT08zA2WKDtw4lbV0FZ8J50 mfwsvmMJXOu4Df+L088= =LNk5 -----END PGP SIGNATURE----- From philipp_subx at redfish-solutions.com Thu Dec 10 19:12:25 2009 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Thu, 10 Dec 2009 11:12:25 -0800 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4B214534.70309@herr-schmitt.de> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> <4B21416A.1040204@redfish-solutions.com> <4B214534.70309@herr-schmitt.de> Message-ID: <4B214819.6060302@redfish-solutions.com> On 12/10/2009 11:00 AM, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 10.12.2009 19:43, schrieb Philip A. Prindeville: > >> On 07/21/2009 11:37 PM, Philip A. Prindeville wrote: >> >>> Philip A. Prindeville wrote: >>> >>> >>>> Hi. >>>> >>>> I need a sponsor for this. An RPM has been built on several >>>> systems (including FC8 and FC9 and Centos5) and tested on all >>>> of those. >>>> >>>> The ticket has been languishing now unassigned for almost a >>>> year. >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=452636 >>>> >>>> Can someone please pick this up? >>>> >>>> It's just an .src.rpm for Apache's mod_proxy_html. >>>> >>>> It's pretty trivial. >>>> >>>> Thanks, >>>> >>>> -Philip >>>> >>>> >>>> >>>> >>> Wow. Who knew sponsors were that hard to come by? Especially >>> when most of the work is already done... >>> >>> -Philip >>> >>> >> Still looking for a sponsor... and a list of bugs to do mock code >> reviews of... >> >> >> > I have take a look on it and have to recorgnise, that the packaged > release is outdated. So if you may create a package based on the current > release, I may willing to sponsor you. > > Best Regards: > > Jochen Schmitt > Updated to 3.1.2 and re-attached to bug. From zaitcev at redhat.com Thu Dec 10 20:01:09 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 10 Dec 2009 13:01:09 -0700 Subject: MariaDB and Fedora In-Reply-To: <1260466690.2963.3.camel@localhost> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> Message-ID: <20091210130109.51db0e6b@redhat.com> On Thu, 10 Dec 2009 15:38:10 -0200 Henrique Junior wrote: > I agree that postgresql is great, but MariaDB is expanding very fast. > I'm not the best person to opine about databases, my experience is very > limited, but it would be nice to keep an eye on MariaDB. Well, duh. Who's going to maintain it though? There must be a warm body. -- Pete From terry1 at beam.ltd.uk Thu Dec 10 20:15:34 2009 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Thu, 10 Dec 2009 20:15:34 +0000 Subject: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web In-Reply-To: <4B178A09.1060103@beam.ltd.uk> References: <4B10D801.7080204@beam.ltd.uk> <4B10E8FD.1000901@beam.ltd.uk> <1259537405.14191.13.camel@localhost.localdomain> <4B139675.40201@beam.ltd.uk> <1259604740.2846.18.camel@localhost.localdomain> <4B142260.4010604@beam.ltd.uk> <1259653815.13178.2.camel@localhost.localdomain> <4B14EEE1.2000802@beam.ltd.uk> <1259789568.17666.53.camel@localhost.localdomain> <4B16E093.6000904@beam.ltd.uk> <4B16EB87.4000005@beam.ltd.uk> <4B177B89.6030902@beam.ltd.uk> <4B178A09.1060103@beam.ltd.uk> Message-ID: <4B2156E6.80800@beam.ltd.uk> On 12/03/2009 09:51 AM, Terry Barnaby wrote: > On 12/03/2009 08:49 AM, Terry Barnaby wrote: >>>> The "MODE" was set up by system-config-network, it is from >>>> its list of possible options for Mode and I think was the >>>> default. >>>> If I run ifup the error you mention is not reported and the >>>> interface comes up fine. >>>> However, I do get the error: >>>> domainname: you must be root to change the domain name >>>> >>>> Which I assume is due to another F12 bug. Could this cause NM >>>> to abort the connection ? >>> I note that "domainname" is called from /etc/dhcp/dhclient.d/nis.sh. >>> At point of invocation $UID and $EUID are 0 .... >> >> I added a "sh" into /etc/dhcp/dhclient.d/nis.sh to have a look. >> Here getuid() and geteuid() return 0. whoami returns "root". >> But when I run "domainname kingnet" I get the error: >> "domainname: you must be root to change the domain name" >> Also "su" states "su: incorrect password" without even >> prompting for one. What is happening here ? >> The environment variables are set by dhcp and do not have >> the usual user environment variables .... >> Note that on this system, selinux is disabled. >> > Looking at this I guess the CAP_SYS_ADMIN capability has been > lost somewhere. Maybe the dhclient ? > This all seems fixed in NetworkManager-0.7.997-1.fc12 Thanks to all who fixed this. Cheers Terry From notting at redhat.com Thu Dec 10 20:32:29 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Dec 2009 15:32:29 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091209224610.GA20658@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> Message-ID: <20091210203228.GA13743@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > It's going to be a bit of a bumpy first yum upgrade. You will likely have > to reboot with 'reboot -f', as the job formats have changed > slightly, and the communication with init(8) has changed. > > Once you reboot, things should work pretty much the same. One notable change that was made is that we were able to simplify the jobs to the point where the number of login consoles is now configurable, without editing or removing upstart job definitions. This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; the default value is "/dev/tty/[1-6]", which means that mingetty will be started on ttys 1 through 6. Shell globs are accepted. Bill From mschwendt at gmail.com Thu Dec 10 20:36:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 10 Dec 2009 21:36:36 +0100 Subject: rpms/blacs/F-12 blacs.spec,1.35,1.36 In-Reply-To: <20091210194723.0D24A11C025D@cvs1.fedora.phx.redhat.com> References: <20091210194723.0D24A11C025D@cvs1.fedora.phx.redhat.com> Message-ID: <20091210213636.559f8be2@gmail.com> On Thu, 10 Dec 2009 19:47:23 +0000 (UTC), Deji wrote: > Author: deji > > Update of /cvs/pkgs/rpms/blacs/F-12 > - Fix broken dep issue on F-12 > -Release: 34%{?dist}.1 > +Release: 34%{?dist}.2 > -Obsoletes: blacs-lam < 1.1-33 > +Obsoletes: blacs-lam <= 1.1-33 This is a common pitfall due to %dist. spot's packaging changes are in -34%{?dist}, so you want the Obsoletes to be: < 1.1-34 to cover also -33%{?dist} > -Obsoletes: blacs-lam-devel < 1.1-33 > +Obsoletes: blacs-lam-devel <= 1.1-33 > -Obsoletes: blacs-lam-static < 1.1-33 > +Obsoletes: blacs-lam-static <= 1.1-33 From jcm at redhat.com Thu Dec 10 20:39:27 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 10 Dec 2009 15:39:27 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091210203228.GA13743@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> Message-ID: <1260477567.3027.487.camel@tonnant> On Thu, 2009-12-10 at 15:32 -0500, Bill Nottingham wrote: > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; > the default value is "/dev/tty/[1-6]", which means that mingetty > will be started on ttys 1 through 6. Shell globs are accepted. Nice. Great for VMs where you don't even need more than one. Jon. From mcepl at redhat.com Thu Dec 10 21:46:17 2009 From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Thu, 10 Dec 2009 22:46:17 +0100 Subject: MariaDB and Fedora In-Reply-To: <20091210130109.51db0e6b@redhat.com> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> Message-ID: Dne 10.12.2009 21:01, Pete Zaitcev napsal(a): > Well, duh. Who's going to maintain it though? There must be a warm body. Somebody from Poland or Ireland? And the help file will have light blue background? /me couldn't resist bad joke -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Home is where ~/.bashrc is. -- from Usenet From pjones at redhat.com Thu Dec 10 21:52:55 2009 From: pjones at redhat.com (Peter Jones) Date: Thu, 10 Dec 2009 16:52:55 -0500 Subject: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs In-Reply-To: References: Message-ID: <4B216DB7.7050609@redhat.com> On 12/04/2009 03:57 AM, Panu Matilainen wrote: > - glibc32, glibc64 (dead packages?) These packages are used in the build system so we don't have to install .i686 glibc packages in the x86_64 buildroot, and other things of that nature. They're not dead, but they very rarely need modification. -- Peter When in doubt, debug-on-entry the function you least suspect has anything to do with something. From fedora at matbooth.co.uk Fri Dec 11 00:55:19 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 11 Dec 2009 00:55:19 +0000 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <4B21416A.1040204@redfish-solutions.com> References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> <4B21416A.1040204@redfish-solutions.com> Message-ID: <9497e9990912101655t2a41d818g20b062dfa49c5dc8@mail.gmail.com> 2009/12/10 Philip A. Prindeville : > On 07/21/2009 11:37 PM, Philip A. Prindeville wrote: >> Philip A. Prindeville wrote: >> >>> Hi. >>> >>> I need a sponsor for this. ?An RPM has been built on several systems >>> (including FC8 and FC9 and Centos5) and tested on all of those. >>> >>> The ticket has been languishing now unassigned for almost a year. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=452636 >>> >>> Can someone please pick this up? >>> >>> It's just an .src.rpm for Apache's mod_proxy_html. >>> >>> It's pretty trivial. >>> >>> Thanks, >>> >>> -Philip >>> >>> >>> >> Wow. ?Who knew sponsors were that hard to come by? ?Especially when most >> of the work is already done... >> >> -Philip >> > > Still looking for a sponsor... and a list of bugs to do mock code reviews of... > > Here is a list of review requests that are not yet assigned to a reviewer: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=Review%20Request&product=Fedora&component=Package%20Review&bug_status=NEW&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review -- Mat Booth From smooge at gmail.com Fri Dec 11 01:23:23 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 10 Dec 2009 18:23:23 -0700 Subject: Request for help maintaining packages while away. In-Reply-To: <20091209212616.GP9741@victoria.internal.frields.org> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> Message-ID: <80d7e4090912101723t3737d857sd404e8e31803bc6c@mail.gmail.com> On Wed, Dec 9, 2009 at 2:26 PM, Paul W. Frields wrote: > On Wed, Dec 09, 2009 at 10:24:16AM -0900, Jeff Spaleta wrote: >> Good Alaskan Morning! >> >> In two weeks I'm going to be in Antarctica for a month+ and I'm >> looking for other packagers to step in for me and maintain my packages >> and prepare them for F13. ?I'm not exactly sure what my time and >> bandwidth access will be so I'm planning for the worst and that I'll >> be reliably off the grid through mid Feb. ? Please let me know if you >> can take on a co-maintainer/primary maintainer role for any of the >> packges and see them through the next couple of months. >> >> Here's the set of packages that I own. ?I will be contacting existing >> co-maintainers for individual packages in the list separately this >> week. >> >> ScientificPython -- A collection of Python modules that are useful for >> scientific computing >> g3data -- Program for extracting the data from scanned graphs >> gourmet -- Recipe Manager for the GNOME desktop environment >> gpodder -- Podcast receiver/catcher written in Python >> istanbul -- Desktop Session Recorder >> nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C >> pyscript -- PyScript - Postscript graphics with Python >> python-basemap -- Plots data on map projections (with continental and >> political boundaries) >> python-basemap-data -- Data for python-basemap >> python-dateutil -- Powerful extensions to the standard datetime module >> python-matplotlib -- Python plotting library >> python-xlib -- X client library for Python >> pytz -- World Timezone Definitions for Python >> revelation -- Password manager for GNOME 2 >> safekeep -- The SafeKeep backup system >> scipy -- Scipy: Scientific Tools for Python >> telescope-server -- Opensource Telescope control servers to interface >> with stellarium >> usbsink -- USBSink is a GNOME > > Jef, I'll help with istanbul. ?If anyone else out there is considering > doing so, please feel free to team up with me. > I would like to learn how to do this in Fedora proper. I could handle revelation also. I don't have anything to test telescope-server with though or I would take that. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From smooge at gmail.com Fri Dec 11 01:24:35 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 10 Dec 2009 18:24:35 -0700 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> Message-ID: <80d7e4090912101724y72849cefrc0498c6c6025841e@mail.gmail.com> On Wed, Dec 9, 2009 at 2:38 PM, Jeff Spaleta wrote: > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: >> Jef, I'll help with istanbul. ?If anyone else out there is considering >> doing so, please feel free to team up with me. > > Other than revelation(which essentially has a dead > upstream)...Istanbul is probably the most in need of more development Its dead upstream? Oh dear. I use it quite a bit so probably need to look it over then. > love. ?Upstream seems to be inactive with no release activity in quite > a while. ?There's a lot of deprecation warnings for some pygtk calls > that I would love to clean up in time for F13. And there are a couple > of abrt crash tickets being spawned by istanbul.. which maybe traced > back to gdk libraries calls if I'm reading the crash dumps correctly. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From tibbs at math.uh.edu Fri Dec 11 01:35:39 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 10 Dec 2009 19:35:39 -0600 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: <9497e9990912101655t2a41d818g20b062dfa49c5dc8@mail.gmail.com> (Mat Booth's message of "Fri, 11 Dec 2009 00:55:19 +0000") References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> <4B21416A.1040204@redfish-solutions.com> <9497e9990912101655t2a41d818g20b062dfa49c5dc8@mail.gmail.com> Message-ID: >>>>> "MB" == Mat Booth writes: MB> Here is a list of review requests that are not yet assigned to a MB> reviewer: Rather than huge bugzilla queries, why not just http://fedoraproject.org/PackageReviewStatus/ ? - J< From jonstanley at gmail.com Fri Dec 11 01:38:35 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 10 Dec 2009 20:38:35 -0500 Subject: Plan for tomorrow's (20091211) FESCo meeting Message-ID: The following items will be discussed at tomorrow's FESCo meeting, at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net 284 request for provenpackager - Rakesh Pandit (rakesh) 267 Proven packager request - Sebastian Dziallas 291 Man pages Packaging Guideline 278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname 292 Color Management - https://fedoraproject.org/wiki/Features/ColorManagement 293 Moblin 2.2 - https://fedoraproject.org/wiki/Features/Moblin-2.2 294 SSSD by default - https://fedoraproject.org/wiki/Features/SSSDByDefault For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. From zaitcev at redhat.com Fri Dec 11 02:16:53 2009 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 10 Dec 2009 19:16:53 -0700 Subject: MariaDB and Fedora In-Reply-To: References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> Message-ID: <20091210191653.2b5c3347@redhat.com> On Thu, 10 Dec 2009 22:46:17 +0100, Mat?j Cepl wrote: > Dne 10.12.2009 21:01, Pete Zaitcev napsal(a): > > Well, duh. Who's going to maintain it though? There must be a warm body. > > Somebody from Poland or Ireland? And the help file will have light blue > background? > > /me couldn't resist bad joke Never watched Maria-sama ga Miteru, I see. ^_^ -- Pete From awilliam at redhat.com Fri Dec 11 03:08:17 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 10 Dec 2009 19:08:17 -0800 Subject: F12 updates-testing issue: X flickers and fails to start In-Reply-To: <1260386403.11526.48.camel@localhost.localdomain> References: <1260265856.2138.4.camel@localhost.localdomain> <1260303294.13514.0.camel@localhost> <20091209103632.62e51af0@leela> <1260365238.11526.38.camel@localhost.localdomain> <1260386403.11526.48.camel@localhost.localdomain> Message-ID: <1260500897.19557.16.camel@adam.local.net> On Wed, 2009-12-09 at 12:20 -0700, Linuxguy123 wrote: > On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: > > Linuxguy123 wrote: > > > I have logged 2 bugs that are possibly related to this. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=528188 > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=525767 > > > > Huh? One of these is a Nouveau bug, the other is a bug in the proprietary > > nvidia driver, both of them already happened with F12 as released, so these > > have absolutely nothing to do with this thread. > > That is what you say. How exactly did you determine that ? OR are you > guessing ? The fact that it only broke for the reporter with an update from three days ago, but you had those problems in September and October. Seems pretty clear. It's not even the same problem description. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Fri Dec 11 03:54:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Dec 2009 19:54:01 -0800 Subject: Help wanted with dist-cvs to git conversion Message-ID: <1260503641.30425.45.camel@localhost.localdomain> I'm currently playing with a utility called parsecvs to convert our cvs stuff into git. This utility can also translate the raw usernames that CVS has into more useful names+email addresses that you'd typically get out of git. But to make this conversion it needs a translation file. It would be really helpful if somebody could generate a file for me that is in the format of: = eg: jkeating=Jesse Keating notting=Bill Nottingham For the initial testing, just giving every user a @feodraproject.org domain would be sufficient, however we should have a discussion about whether to use this email address or to use the user's real email address. Should be easy enough to get a list of users from FAS for this purpose. Thanks in advance! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ngompa13 at gmail.com Fri Dec 11 04:00:47 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Thu, 10 Dec 2009 22:00:47 -0600 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <1260503641.30425.45.camel@localhost.localdomain> References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: <8278b1b0912102000k674db38cm7fbae74042ddbb2b@mail.gmail.com> On Thu, Dec 10, 2009 at 9:54 PM, Jesse Keating wrote: > I'm currently playing with a utility called parsecvs to convert our cvs > stuff into git. This utility can also translate the raw usernames that > CVS has into more useful names+email addresses that you'd typically get > out of git. But to make this conversion it needs a translation file. > > It would be really helpful if somebody could generate a file for me that > is in the format of: > > = > > eg: > > jkeating=Jesse Keating > notting=Bill Nottingham > > For the initial testing, just giving every user a @feodraproject.org > domain would be sufficient, however we should have a discussion about > whether to use this email address or to use the user's real email > address. > > Should be easy enough to get a list of users from FAS for this purpose. > Thanks in advance! > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Is it even possible to get a listing of all the users so such a file could be generated? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Dec 11 04:44:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Dec 2009 20:44:21 -0800 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <8278b1b0912102000k674db38cm7fbae74042ddbb2b@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <8278b1b0912102000k674db38cm7fbae74042ddbb2b@mail.gmail.com> Message-ID: <1260506661.30425.46.camel@localhost.localdomain> On Thu, 2009-12-10 at 22:00 -0600, Sir Gallantmon wrote: > Is it even possible to get a listing of all the users so such a file could > be generated? > FAS should provide this information. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri Dec 11 05:12:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 11 Dec 2009 00:12:46 -0500 (EST) Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <1260503641.30425.45.camel@localhost.localdomain> References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: On Thu, 10 Dec 2009, Jesse Keating wrote: > I'm currently playing with a utility called parsecvs to convert our cvs > stuff into git. This utility can also translate the raw usernames that > CVS has into more useful names+email addresses that you'd typically get > out of git. But to make this conversion it needs a translation file. > > It would be really helpful if somebody could generate a file for me that > is in the format of: > > = > > eg: > > jkeating=Jesse Keating > notting=Bill Nottingham > > For the initial testing, just giving every user a @feodraproject.org > domain would be sufficient, however we should have a discussion about > whether to use this email address or to use the user's real email > address. > I just did this on fedorapeople.org not against fas but I suspect that's the same set of users. #!/usr/bin/python -tt import pwd for pw in pwd.getpwall(): if pw.pw_uid < 10000: continue msg='%s=%s <%s at fedoraproject.org>' % (pw.pw_name, pw.pw_gecos, pw.pw_name) print msg the file with these contents is in my homedir on fedorapeople.org as: wacky-list-for-git if you want me to do it directly talking to fas I'll do it in the morning. -sv From cemeyer at u.washington.edu Fri Dec 11 05:28:43 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Thu, 10 Dec 2009 21:28:43 -0800 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: <200912102128.43410.cemeyer@u.washington.edu> On Thursday 10 December 2009 09:12:46 pm Seth Vidal wrote: > On Thu, 10 Dec 2009, Jesse Keating wrote: > > I'm currently playing with a utility called parsecvs to convert our cvs > > stuff into git. This utility can also translate the raw usernames that > > CVS has into more useful names+email addresses that you'd typically get > > out of git. But to make this conversion it needs a translation file. > > > > It would be really helpful if somebody could generate a file for me that > > is in the format of: > > > > = > > > > eg: > > > > jkeating=Jesse Keating > > notting=Bill Nottingham > > > > For the initial testing, just giving every user a @feodraproject.org > > domain would be sufficient, however we should have a discussion about > > whether to use this email address or to use the user's real email > > address. > > I just did this on fedorapeople.org not against fas but I suspect that's > the same set of users. > > #!/usr/bin/python -tt > > import pwd > > for pw in pwd.getpwall(): > if pw.pw_uid < 10000: > continue > msg='%s=%s <%s at fedoraproject.org>' % (pw.pw_name, pw.pw_gecos, > pw.pw_name) > print msg > > > the file with these contents is in my homedir on fedorapeople.org as: > wacky-list-for-git > > if you want me to do it directly talking to fas I'll do it in the morning. > -sv A script that grabs the entries from FAS, and outputs everything as UTF-8 files: http://konradm.fedorapeople.org/usernamelist.py Results with FAS emails (in my $HOME on fedorapeople.org): FAS-users-normalemails or fedoraproject.org emails: FAS-users-fedoraprojectemails Regards, -- Conrad Meyer From cemeyer at u.washington.edu Fri Dec 11 05:31:42 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Thu, 10 Dec 2009 21:31:42 -0800 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <200912102128.43410.cemeyer@u.washington.edu> References: <1260503641.30425.45.camel@localhost.localdomain> <200912102128.43410.cemeyer@u.washington.edu> Message-ID: <200912102131.42108.cemeyer@u.washington.edu> On Thursday 10 December 2009 09:28:43 pm Conrad Meyer wrote: > A script that grabs the entries from FAS, and outputs everything as UTF-8 > files: > > http://konradm.fedorapeople.org/usernamelist.py I forgot to mention, this requires the 'python-fedora' package. (Doh!) Regards, -- Conrad Meyer From jspaleta at gmail.com Fri Dec 11 05:43:30 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Dec 2009 20:43:30 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <80d7e4090912101724y72849cefrc0498c6c6025841e@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> <80d7e4090912101724y72849cefrc0498c6c6025841e@mail.gmail.com> Message-ID: <604aa7910912102143i305712d0p5c4e508481ac76ba@mail.gmail.com> On Thu, Dec 10, 2009 at 4:24 PM, Stephen John Smoogen wrote: > Its dead upstream? Oh dear. I use it quite a bit so probably need to > look it over then. I use it too. A lot of people use it. I poked upstream prior to F11 and the developer responded saying he was getting back to it soon but I haven't seen much activity. Up to this point I've tried to at least tell the Ubuntu maintainer about any patches I add since its not clear how to submit patches to upstream. What I'd like to do is get the different distro maintainers together as a group form a game plan on setting up a new dvcs trunk for the project and then politely tell the existing upstream we want to move ahead with his blessing and have him as a contributor. It's an aging codebase and it needs to transition to using the newer gvfs stuff versus the older gnomevfs stuff... at a minimum. I don't want to do that as a set of downstream patches in Fedora. And until I get back from the other side of the world I can't commit to being a new upstream....sadly. If you want to get that conversation started...you have my blessing. -jef From huzaifas at redhat.com Fri Dec 11 08:37:29 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Fri, 11 Dec 2009 14:07:29 +0530 Subject: What is public/private fork? - Criteria packaging in fedora Message-ID: <4B2204C9.8060804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have forked libtar as libtar-ng, because the upstream does not have time to maintain it anymore. Here is the bz: https://bugzilla.redhat.com/show_bug.cgi?id=546169 Now the question is what is a private fork? Am i wrong in forking it and packaging in fedora? Any replies/suggestions are appreciated, Thanks. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) IT Desktop R&D Lead. Global Help Desk, Pune (India) Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLIgTJzHDc8tpb2uURAgyUAKCIhzdxCssxWoB1tEiYJVlmfxiZqwCeLJDG uafJkLUxxAowSksrLiQGVGs= =qO8e -----END PGP SIGNATURE----- From mschwendt at gmail.com Fri Dec 11 09:36:15 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 11 Dec 2009 10:36:15 +0100 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B2204C9.8060804@redhat.com> References: <4B2204C9.8060804@redhat.com> Message-ID: <20091211103615.59302ccb@gmail.com> On Fri, 11 Dec 2009 14:07:29 +0530, Huzaifa wrote: > I have forked libtar as libtar-ng, because the upstream does not have > time to maintain it anymore. > > Here is the bz: > https://bugzilla.redhat.com/show_bug.cgi?id=546169 > > Now the question is what is a private fork? > Am i wrong in forking it and packaging in fedora? > > Any replies/suggestions are appreciated, Thanks. You could have avoided a lot of confusion by simply providing an accurate spec file prior to requesting reviews. Quoting from: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec | URL: http://www.feep.net/libtar/ That is the _old_ libtar project web page which has nothing to do with the tarball you provided. Only later in bugzilla you mentioned that your fork also has its own project infrastructure at: https://fedorahosted.org/libtar-ng/ So, *that* is the URL you ought to have used. Further, I think it would be good to explain what your plans are with regard to the "-ng" in the project name. Starting libtar-ng at exactly the same version as the old libtar also adds confusion. Here the maintainer acknowledges inactivity, requests forks to use a different project name, and comments on current code quality: https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html More recent threads comment on licensing. From sundaram at fedoraproject.org Fri Dec 11 09:45:46 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 Dec 2009 15:15:46 +0530 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B2204C9.8060804@redhat.com> References: <4B2204C9.8060804@redhat.com> Message-ID: <4B2214CA.3030107@fedoraproject.org> On 12/11/2009 02:07 PM, Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have forked libtar as libtar-ng, because the upstream does not have > time to maintain it anymore. > > Here is the bz: > https://bugzilla.redhat.com/show_bug.cgi?id=546169 > > Now the question is what is a private fork? > Am i wrong in forking it and packaging in fedora? > > Any replies/suggestions are appreciated, Thanks. You might want to get in touch with other distributions via http://lists.freedesktop.org/mailman/listinfo/distributions See, if they have distribution specific patches you can merge. Directly contact the maintainer of libtar in other mainstream distributions as well. Rahul From thomasj at fedoraproject.org Fri Dec 11 10:05:48 2009 From: thomasj at fedoraproject.org (Thomas Janssen) Date: Fri, 11 Dec 2009 11:05:48 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <1260503641.30425.45.camel@localhost.localdomain> References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: 2009/12/11 Jesse Keating : > For the initial testing, just giving every user a @feodraproject.org > domain would be sufficient, however we should have a discussion about > whether to use this email address or to use the user's real email > address. Definitely @fedoraproject.org email addresses. A lot of us use them even in Bugzilla, all my packages have the fp.o address in %changelog. I dont want to fiddle around when i change my "real" email address. Just pop in to FAS and change it there, done. Best regards -- LG Thomas Dubium sapientiae initium From dominik at greysector.net Fri Dec 11 10:10:19 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 11 Dec 2009 11:10:19 +0100 Subject: Plan for tomorrow's (20091211) FESCo meeting In-Reply-To: References: Message-ID: <20091211101019.GB20352@mokona.greysector.net> On Friday, 11 December 2009 at 02:38, Jon Stanley wrote: > The following items will be discussed at tomorrow's FESCo meeting, at > 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net [...] > 291 Man pages Packaging Guideline Um, what? This was tabled for further discussion during the last FPC meeting. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ffesti at redhat.com Fri Dec 11 10:26:56 2009 From: ffesti at redhat.com (Florian Festi) Date: Fri, 11 Dec 2009 11:26:56 +0100 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B2204C9.8060804@redhat.com> References: <4B2204C9.8060804@redhat.com> Message-ID: <4B221E70.6000301@redhat.com> Without knowing the history: Best solution would be to ask former upstream for permission to continue the project under its original name and may be even to forward the old mailing list and web page the to new ones. But I am not sure if you are living the the best of all possible worlds... Florian From sundaram at fedoraproject.org Fri Dec 11 10:44:40 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 Dec 2009 16:14:40 +0530 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B221E70.6000301@redhat.com> References: <4B2204C9.8060804@redhat.com> <4B221E70.6000301@redhat.com> Message-ID: <4B222298.1080902@fedoraproject.org> On 12/11/2009 03:56 PM, Florian Festi wrote: > Without knowing the history: > > Best solution would be to ask former upstream for permission to continue > the project under its original name That was already denied https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html Rahul From mschwendt at gmail.com Fri Dec 11 11:08:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 11 Dec 2009 12:08:25 +0100 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B222298.1080902@fedoraproject.org> References: <4B2204C9.8060804@redhat.com> <4B221E70.6000301@redhat.com> <4B222298.1080902@fedoraproject.org> Message-ID: <20091211120825.7283c0e5@gmail.com> On Fri, 11 Dec 2009 16:14:40 +0530, Rahul wrote: > On 12/11/2009 03:56 PM, Florian Festi wrote: > > Without knowing the history: > > > > Best solution would be to ask former upstream for permission to continue > > the project under its original name > > That was already denied > > https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html Don't call it denial, though, because libtar is licensed under terms similar to MIT/BSD (with no advertising clause) [1]. This alone gives many permissions. See the license text for the details. The real reason not to use the "libtar" namespace for a fork are others. See my comment to the review request. [1] Dunno whether this license matches any on Fedora's list of licenses. From bnocera at redhat.com Fri Dec 11 11:11:30 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 11 Dec 2009 11:11:30 +0000 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B222298.1080902@fedoraproject.org> References: <4B2204C9.8060804@redhat.com> <4B221E70.6000301@redhat.com> <4B222298.1080902@fedoraproject.org> Message-ID: <1260529890.3311.2036.camel@localhost.localdomain> On Fri, 2009-12-11 at 16:14 +0530, Rahul Sundaram wrote: > On 12/11/2009 03:56 PM, Florian Festi wrote: > > Without knowing the history: > > > > Best solution would be to ask former upstream for permission to continue > > the project under its original name > > That was already denied > > https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html That's not what the maintainer said. He just doesn't want to give away the name itself, that is, he doesn't want to relinquish control of the project even though he doesn't contribute code to it any more. Frankly, calling a fork of libtar libtar-ng when the upstream says the library is "pretty awful" is a bit weird. "If you or someone else wants to apply some patches to the current code base and cut a new release, I'd be happy to discuss the best way to do that." Well, best discuss it then From sundaram at fedoraproject.org Fri Dec 11 11:13:16 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 Dec 2009 16:43:16 +0530 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <20091211120825.7283c0e5@gmail.com> References: <4B2204C9.8060804@redhat.com> <4B221E70.6000301@redhat.com> <4B222298.1080902@fedoraproject.org> <20091211120825.7283c0e5@gmail.com> Message-ID: <4B22294C.4060005@fedoraproject.org> On 12/11/2009 04:38 PM, Michael Schwendt wrote: > On Fri, 11 Dec 2009 16:14:40 +0530, Rahul wrote: > >> On 12/11/2009 03:56 PM, Florian Festi wrote: >>> Without knowing the history: >>> >>> Best solution would be to ask former upstream for permission to continue >>> the project under its original name >> >> That was already denied >> >> https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html > > Don't call it denial, though, because libtar is licensed under terms > similar to MIT/BSD (with no advertising clause) [1]. This alone gives many > permissions. See the license text for the details. Sure but my comment has nothing to do with the license but the name of the project. > The real reason not to use the "libtar" namespace for a fork are > others. If a upstream developer requests anyone not to use the same name for continuing maintenance of a project, then regardless of the license, it would only be polite not to do so setting aside everything else. Rahul From mschwendt at gmail.com Fri Dec 11 11:33:13 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 11 Dec 2009 12:33:13 +0100 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B22294C.4060005@fedoraproject.org> References: <4B2204C9.8060804@redhat.com> <4B221E70.6000301@redhat.com> <4B222298.1080902@fedoraproject.org> <20091211120825.7283c0e5@gmail.com> <4B22294C.4060005@fedoraproject.org> Message-ID: <20091211123313.35f3fe51@gmail.com> On Fri, 11 Dec 2009 16:43:16 +0530, Rahul wrote: > On 12/11/2009 04:38 PM, Michael Schwendt wrote: > > On Fri, 11 Dec 2009 16:14:40 +0530, Rahul wrote: > > > >> On 12/11/2009 03:56 PM, Florian Festi wrote: > >>> Without knowing the history: > >>> > >>> Best solution would be to ask former upstream for permission to continue > >>> the project under its original name > >> > >> That was already denied > >> > >> https://lists.feep.net:8080/pipermail/libtar/2009-May/000259.html > > > > Don't call it denial, though, because libtar is licensed under terms > > similar to MIT/BSD (with no advertising clause) [1]. This alone gives many > > permissions. See the license text for the details. > > Sure but my comment has nothing to do with the license but the name of > the project. The author doesn't deny it, he only expressed a personal wish. The license decides whether one may modify the project and distribute the modified project ... and so on. Whether to do that in a src.rpm with patches, in a private fork or in a public fork, is a different matter. https://lists.feep.net:8080/pipermail/libtar/2009-December/000287.html Interestingly, the author refers to the license as "BSD-style", https://lists.feep.net:8080/pipermail/libtar/2009-December/000282.html which is what matches my impression quoted above. Fedora's package says "MIT", which isn't true. Another item for the review request. > > The real reason not to use the "libtar" namespace for a fork are > > others. > > If a upstream developer requests anyone not to use the same name for > continuing maintenance of a project, then regardless of the license, it > would only be polite not to do so setting aside everything else. Here I agree. Just changing the project name does not suffice, however, if files and API and ABI conflict with the old project. Refer to my older bugzilla comment for the details. From lkundrak at v3.sk Fri Dec 11 13:07:14 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Fri, 11 Dec 2009 14:07:14 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: <1260536834.7433.13.camel@localhost.localdomain> On Fri, 2009-12-11 at 11:05 +0100, Thomas Janssen wrote: > 2009/12/11 Jesse Keating : > > For the initial testing, just giving every user a @feodraproject.org > > domain would be sufficient, however we should have a discussion about > > whether to use this email address or to use the user's real email > > address. > > Definitely @fedoraproject.org email addresses. A lot of us use them > even in Bugzilla, all my packages have the fp.o address in %changelog. > I dont want to fiddle around when i change my "real" email address. > Just pop in to FAS and change it there, done. A big -1 for this. Your "A lot" is in fact "a tiny fraction" and for some of us an e-mail address is important mean for identifying an user ("Oh, this is John Doe of Canonical", ...). It would be awesome if names in GIT log would correspond to what an user uses in the package's change log (maybe falling back to @fp.o if there's no changelog entry for him). Some of us (well, maybe just me) use e-mail addresses to separate packages maintained in private time to job-related packages and it would be awesome if it could be preserved in the GIT log. Would this be possible? (If noone would volunteer to write a script that would generate the database, I'd do. This would need a slightly different format of the information, since package information should be added though). -- Flash is the Web2.0 version of blink and animated gifs. -- Stephen Smoogen From skvidal at fedoraproject.org Fri Dec 11 13:12:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 11 Dec 2009 08:12:22 -0500 (EST) Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <1260536834.7433.13.camel@localhost.localdomain> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> Message-ID: On Fri, 11 Dec 2009, Lubomir Rintel wrote: > > A big -1 for this. Your "A lot" is in fact "a tiny fraction" and for > some of us an e-mail address is important mean for identifying an user > ("Oh, this is John Doe of Canonical", ...). I use mine exclusively and I think referring to the generic address makes life a lot easier. And let me put it this way: if fedora decides to post my non @fp.o address somewhere, like in git entries, I'm going to be extremely pissed off about it. -sv From jlaska at redhat.com Fri Dec 11 13:20:56 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 11 Dec 2009 08:20:56 -0500 Subject: Fedora release criteria completely revised In-Reply-To: <4B1DFC38.7070708@hi.is> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <4B1DFC38.7070708@hi.is> Message-ID: <1260537656.3549.2.camel@localhost> On Tue, 2009-12-08 at 07:11 +0000, "J?hann B. Gu?mundsson" wrote: > On 12/07/2009 10:55 PM, Adam Williamson wrote: > > In https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria under > "Beta Release Requirements", Item 10 "The installer must be able to > successfully complete an upgrade installation from a clean, fully > updated default installation of the previous stable Fedora release, > either via preupgrade or by booting to the installer manually". Does > this mean that the Fedora officially "Supports" upgrades now? If so dont > application need to be backwards compatible and QA and Doc team be noted > if they are not. If it's not officially supported why is it in the "Beta > Release Requirements"? As far as I know ... upgrades are "supported". However, we can adjust if that statement changes. http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-upgrade-x86.html Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bochecha at fedoraproject.org Fri Dec 11 13:22:00 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 11 Dec 2009 14:22:00 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> Message-ID: <2d319b780912110522i66754a49l49de04cc5dff6e6a@mail.gmail.com> On Fri, Dec 11, 2009 at 14:12, Seth Vidal wrote: > On Fri, 11 Dec 2009, Lubomir Rintel wrote: > >> >> A big -1 for this. Your "A lot" is in fact "a tiny fraction" and for >> some of us an e-mail address is important mean for identifying an user >> ("Oh, this is John Doe of Canonical", ...). > > I use mine exclusively and I think referring to the generic address makes > life a lot easier. > > And let me put it this way: if fedora decides to post my non @fp.o address > somewhere, like in git entries, I'm going to be extremely pissed off about > it. Isn't it already posted in IRC when someone enters the ".fasinfo skvidal" command ? Mine (and several others) is also in the FAS source code : https://fedorahosted.org/python-fedora/browser/python-fedora-devel/fedora/client/fas2.py (and yeah, I feel the same, I'd rather use exclusively my @fp.o address for Fedora stuff) ---------- Mathieu Bridon (bochecha) From bochecha at fedoraproject.org Fri Dec 11 13:22:44 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Fri, 11 Dec 2009 14:22:44 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <1260536834.7433.13.camel@localhost.localdomain> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> Message-ID: <2d319b780912110522oeb58e69qc8d6ae22dcdf49f3@mail.gmail.com> On Fri, Dec 11, 2009 at 14:07, Lubomir Rintel wrote: > On Fri, 2009-12-11 at 11:05 +0100, Thomas Janssen wrote: >> 2009/12/11 Jesse Keating : >> > For the initial testing, just giving every user a @feodraproject.org >> > domain would be sufficient, however we should have a discussion about >> > whether to use this email address or to use the user's real email >> > address. >> >> Definitely @fedoraproject.org email addresses. A lot of us use them >> even in Bugzilla, all my packages have the fp.o address in %changelog. >> I dont want to fiddle around when i change my "real" email address. >> Just pop in to FAS and change it there, done. > > A big -1 for this. Your "A lot" is in fact "a tiny fraction" and for > some of us an e-mail address is important mean for identifying an user > ("Oh, this is John Doe of Canonical", ...). I think no one will ever agree on this particular issue. Maybe we could add a setting in FAS where each one can decide "I want to use my personal address" or "I want to use my @fp.o address". Then when FAS is requested for an email address, it would answer the one the user chose. I know adding configuration is almost never a good idea, but in this case, it might be the only way to avoid endless sterile flamewars. :-/ ---------- Mathieu Bridon (bochecha) From skvidal at fedoraproject.org Fri Dec 11 13:25:07 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 11 Dec 2009 08:25:07 -0500 (EST) Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <2d319b780912110522i66754a49l49de04cc5dff6e6a@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> <2d319b780912110522i66754a49l49de04cc5dff6e6a@mail.gmail.com> Message-ID: On Fri, 11 Dec 2009, Mathieu Bridon (bochecha) wrote: > On Fri, Dec 11, 2009 at 14:12, Seth Vidal wrote: >> On Fri, 11 Dec 2009, Lubomir Rintel wrote: >> >>> >>> A big -1 for this. Your "A lot" is in fact "a tiny fraction" and for >>> some of us an e-mail address is important mean for identifying an user >>> ("Oh, this is John Doe of Canonical", ...). >> >> I use mine exclusively and I think referring to the generic address makes >> life a lot easier. >> >> And let me put it this way: if fedora decides to post my non @fp.o address >> somewhere, like in git entries, I'm going to be extremely pissed off about >> it. > > Isn't it already posted in IRC when someone enters the ".fasinfo > skvidal" command ? That's not in every google-retrievable gitweb interface, though. -sv From otaylor at redhat.com Fri Dec 11 13:46:39 2009 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 11 Dec 2009 08:46:39 -0500 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: <1260539199.2639.565.camel@localhost.localdomain> On Fri, 2009-12-11 at 11:05 +0100, Thomas Janssen wrote: > 2009/12/11 Jesse Keating : > > For the initial testing, just giving every user a @feodraproject.org > > domain would be sufficient, however we should have a discussion about > > whether to use this email address or to use the user's real email > > address. > > Definitely @fedoraproject.org email addresses. A lot of us use them > even in Bugzilla, all my packages have the fp.o address in %changelog. > I dont want to fiddle around when i change my "real" email address. > Just pop in to FAS and change it there, done. Another consideration in favor of using @fedoraproject.org emails is if you use real emails, they will be used for old commits, even when that's not historically accurate. We went with @src.gnome.org addresses for the GNOME git conversion because we didn't want, say, 5 years of work someone did at company A show up as commits from user at companyb.com because that's where they work now. - Owen (We actually did something a little fancier at that - if the log message for the CVS/SVN commit contained something that looked like a ChangeLog entry with an obvious email address, then we used that as the Author and the @src.gnome.org only as the Committer. If we couldn't determine a plausible Author, then we used the @src.gnome.org address for both.) From fedora at camperquake.de Fri Dec 11 13:56:29 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 11 Dec 2009 14:56:29 +0100 Subject: Fedora release criteria completely revised In-Reply-To: <4B1DFC38.7070708@hi.is> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <4B1DFC38.7070708@hi.is> Message-ID: <20091211145629.543ac828@dhcp03.addix.net> Hi. On Tue, 08 Dec 2009 07:11:52 +0000, J?hann B. Gu?mundsson wrote: > manually". Does this mean that the Fedora officially "Supports" > upgrades now? Were upgraded installs not always supported, as long as the upgrade did not take place within the running system? From jlaska at redhat.com Fri Dec 11 15:53:40 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 11 Dec 2009 10:53:40 -0500 Subject: Fedora release criteria completely revised In-Reply-To: <076d60721cac4a9affc7c22ac0354c71@mailserver> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> Message-ID: <1260546820.3549.30.camel@localhost> On Mon, 2009-12-07 at 14:55 -0800, Adam Williamson wrote: > During FUDCon, we've been working on revising the Fedora release criteria. > John Poelstra had already fleshed out a structure and much of the final > content, and we've been revising and tweaking it in conjunction with QA > (myself, Will Woods and James Laska), release engineering (Jesse Keating), > anaconda team (especially Denise Dumas and Peter Jones) and desktop team > (Christopher Aillon and Matthias Clasen, who provided suggestions at an > earlier stage). > > The new structure is based around a general page and specific pages for the > Fedora 13 Alpha, Beta and Final releases (which have been written > generically so they can easily be converted into pages for F14 and all > future releases just by copying and pasting). You can find the criteria > here: > > https://fedoraproject.org/wiki/Fedora_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria > > they should contain everything you need to know. We based most of the > criteria around testing that was already being carried out but with no > formal policy basis, with additional suggestions from the anaconda and > desktop teams. > > We will follow these criteria for the Fedora 13 release process. So if you > can see any problems or potential trouble with any of this, please do reply > and let us know! > > Desktop team - can you please let us know of any additional things that you > would expect to be working at each point during the release cycle? Note > that only things that *must* be working at each point should be listed on > these pages, not nice-to-haves. You must be able to commit to the idea > that, if any criterion on the page is not met, we would slip the release in > question. Not sure if this has been raised yet, but are we specifying when in the release that packages should be signed with a valid signature? I believe packages are signed at all release milestones, but I'd like to clear up that assumption. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Dec 11 16:04:33 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Dec 2009 08:04:33 -0800 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> Message-ID: <1260547473.30425.49.camel@localhost.localdomain> On Fri, 2009-12-11 at 08:12 -0500, Seth Vidal wrote: > > And let me put it this way: if fedora decides to post my non @fp.o address > somewhere, like in git entries, I'm going to be extremely pissed off about > it. > I think this would depend on what gets configured for your git client for fedora package repos, probably another file in .fedora/. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dennisml at conversis.de Fri Dec 11 16:06:12 2009 From: dennisml at conversis.de (Dennis J.) Date: Fri, 11 Dec 2009 17:06:12 +0100 Subject: MariaDB and Fedora In-Reply-To: <20091210130109.51db0e6b@redhat.com> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> Message-ID: <4B226DF4.9020603@conversis.de> On 12/10/2009 09:01 PM, Pete Zaitcev wrote: > On Thu, 10 Dec 2009 15:38:10 -0200 > Henrique Junior wrote: > >> I agree that postgresql is great, but MariaDB is expanding very fast. >> I'm not the best person to opine about databases, my experience is very >> limited, but it would be nice to keep an eye on MariaDB. > > Well, duh. Who's going to maintain it though? There must be a warm body. I for one care much more about Drizzle than about MariaDB. From what I can tell MariaDB is basically just a new storage engine inside the old crufty MySQL shell whereas Drizzle is a (much needed) overhaul of the whole thing. Much more interesting for future projects if you ask me. Regards, Dennis From jkeating at redhat.com Fri Dec 11 16:09:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Dec 2009 08:09:31 -0800 Subject: Fedora release criteria completely revised In-Reply-To: <1260546820.3549.30.camel@localhost> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260546820.3549.30.camel@localhost> Message-ID: <1260547771.30425.51.camel@localhost.localdomain> On Fri, 2009-12-11 at 10:53 -0500, James Laska wrote: > > Not sure if this has been raised yet, but are we specifying when in the > release that packages should be signed with a valid signature? I > believe packages are signed at all release milestones, but I'd like to > clear up that assumption. > I have 3 answers for that. 1) if we get koji autosign builds working, every official build that comes out of koji will be signed automatically 2) failing that, if we get no frozen rawhide working right, every build will be signed once we branch away from rawhide as we'll be using bodhi to manage it. 3) failing that, the builds will be signed leading up to the release milestones. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Fri Dec 11 16:10:01 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 11 Dec 2009 10:10:01 -0600 Subject: Fedora release criteria completely revised In-Reply-To: <1260546820.3549.30.camel@localhost> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260546820.3549.30.camel@localhost> Message-ID: <20091211161001.GA16421@wolff.to> On Fri, Dec 11, 2009 at 10:53:40 -0500, James Laska wrote: > > Not sure if this has been raised yet, but are we specifying when in the > release that packages should be signed with a valid signature? I > believe packages are signed at all release milestones, but I'd like to > clear up that assumption. I belive the plan is that all official koji builds are going to be signed with the same key. The key will just provide assurance that the rpms were official builds from our koji and not that they are tied to a particular release or release type. From awilliam at redhat.com Fri Dec 11 16:20:33 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 08:20:33 -0800 Subject: Fedora release criteria completely revised In-Reply-To: <1260546820.3549.30.camel@localhost> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260546820.3549.30.camel@localhost> Message-ID: <1260548433.19557.17.camel@adam.local.net> On Fri, 2009-12-11 at 10:53 -0500, James Laska wrote: > Not sure if this has been raised yet, but are we specifying when in the > release that packages should be signed with a valid signature? I > believe packages are signed at all release milestones, but I'd like to > clear up that assumption. Do you think that's a criteria issue, i.e. something to which there's an innate correct answer which can be defined and which shouldn't change? I'd think of it more as a process issue, but IMBW. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From adam at spicenitz.org Fri Dec 11 16:46:57 2009 From: adam at spicenitz.org (Adam Goode) Date: Fri, 11 Dec 2009 11:46:57 -0500 Subject: mono and snk key files In-Reply-To: <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> References: <4B1297E5.1030207@smartlink.ee> <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> Message-ID: <4B227781.7080409@spicenitz.org> On 11/29/2009 11:29 AM, Christopher Brown wrote: > 2009/11/29 Kalev Lember : >> Hello, > > > >> Comments? > > I'm the maintainer for log4net but unfortunately not for nant. I've > finally gotten around to looking at this. > > Debian have a policy[1] of using a standard mono.snk which is provided > by a package (I guess we just then BuildRequires this) and I think > this seems like a good solution but have no experience of this. > We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key. The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From jlaska at redhat.com Fri Dec 11 16:52:21 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 11 Dec 2009 11:52:21 -0500 Subject: Fedora release criteria completely revised In-Reply-To: <1260548433.19557.17.camel@adam.local.net> References: <076d60721cac4a9affc7c22ac0354c71@mailserver> <1260546820.3549.30.camel@localhost> <1260548433.19557.17.camel@adam.local.net> Message-ID: <1260550341.3549.45.camel@localhost> On Fri, 2009-12-11 at 08:20 -0800, Adam Williamson wrote: > On Fri, 2009-12-11 at 10:53 -0500, James Laska wrote: > > > Not sure if this has been raised yet, but are we specifying when in the > > release that packages should be signed with a valid signature? I > > believe packages are signed at all release milestones, but I'd like to > > clear up that assumption. > > Do you think that's a criteria issue, i.e. something to which there's an > innate correct answer which can be defined and which shouldn't change? > I'd think of it more as a process issue, but IMBW. Yeah, that's my question ... is there an assumption that all packages will be signed? Does this assumption need to be validated? Looking at our current test plans for the release, I don't see anything where we confirm that packages are properly signed. Should we be testing this, and if so ... does it map back to a specific release criteria? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From fedora at matbooth.co.uk Fri Dec 11 17:10:38 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 11 Dec 2009 17:10:38 +0000 Subject: Need a sponsor: mod_proxy_html (apache) In-Reply-To: References: <4A60D611.9010501@redfish-solutions.com> <4A66B3BC.90303@redfish-solutions.com> <4B21416A.1040204@redfish-solutions.com> <9497e9990912101655t2a41d818g20b062dfa49c5dc8@mail.gmail.com> Message-ID: <9497e9990912110910i27625051j5ce0f85b0efc0b8@mail.gmail.com> 2009/12/11 Jason L Tibbitts III : >>>>>> "MB" == Mat Booth writes: > > MB> Here is a list of review requests that are not yet assigned to a > MB> reviewer: > > Rather than huge bugzilla queries, why not just > http://fedoraproject.org/PackageReviewStatus/ ? > Neat, I didn't know about that. -- Mat Booth From jonstanley at gmail.com Fri Dec 11 17:59:11 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 11 Dec 2009 12:59:11 -0500 Subject: FESCo meeting summary for 20091211 Message-ID: ======================================= #fedora-meeting: FESCo meeting 20091211 ======================================= Meeting started by jds2001 at 17:02:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-12-11/fesco.2009-12-11-17.02.log.html . Meeting summary --------------- * provenpackager request - rakesh pandit (jds2001, 17:04:24) * AGREED: rakesh provenpackager membership is approved. (jds2001, 17:06:40) * provenpackager request - sdz (jds2001, 17:06:54) * AGREED: sdz provenpackager membership is approved (jds2001, 17:07:47) * man pages guidelines (jds2001, 17:08:00) * AGREED: add to packaging guidelines SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense. (jds2001, 17:22:29) * better hostname feature (jds2001, 17:22:48) * AGREED: the better hostname feature is deferred as there are unanswered questions on the talk page (jds2001, 17:30:34) * color management (jds2001, 17:30:45) * AGREED: gnome-COLOR-manager feature is approved (jds2001, 17:34:07) * Moblin 2.2 (jds2001, 17:34:57) * AGREED: Moblin 2.2 feature is accepted (jds2001, 17:36:01) * SSSD by default (jds2001, 17:36:09) * AGREED: SSSD feature is accpeted (jds2001, 17:42:56) * mono strong name key (jds2001, 17:44:14) * AGREED: this has already been done in rawhide. (jds2001, 17:47:35) * AGREED: no action from fesco is required. (jds2001, 17:47:53) * open floor (jds2001, 17:48:07) * go vote in the fesco elections :) (jds2001, 17:48:16) * Fedora mailing lists will be moved to Fedora Infrastructure on 1/9 and 1/10 (jds2001, 17:50:20) Meeting ended at 17:57:58 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jds2001 (84) * Kevin_Kofler (51) * dgilmore (43) * nirik (29) * notting (28) * brunowolff (17) * sgallagh (13) * zodbot (12) * sharkcz (10) * mclasen (6) * j-rod_ (6) * rjune (5) * j-rod (5) * spot (3) * abadger1999 (3) * skvidal (2) * Southern_Gentlem (1) * kalev (1) * dwmw2 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From awilliam at redhat.com Fri Dec 11 18:21:44 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 10:21:44 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260299132.3027.368.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> Message-ID: <1260555704.19557.19.camel@adam.local.net> On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote: > On Tue, 2009-12-08 at 12:59 +0100, Tomasz Torcz wrote: > > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > > I did a clean install of Fedora 12 and realized > > > that pavucontrol was not installed by default. > > > I have two sound cards and I only got sound when > > > I manually installed pavucontrol and used it. > > > > Any reason? > > > pavucontrol is regarded as advance tool, but also partly > > obsolete. Current gnome-volume-control superseded most of > > its functionality: controlling different streams volume, > > switching profile, outputs, fallback devices. > > The new gnome-volume-control is so cut-down it's not useful to me. In > the quest to be more Mac-like in removing mixer controls (and not even > having any obvious "advanced" mode), I now have a choice of no audio or > having full volume LFE output *and* whatever mixer level I have set for > the master output. alsamixer works fine, but then I can't use the volume > sliders on my desktop and it gets rather awkward. pauvucontrol is no different in that respect. If gnome-volume-control / pavucontrol do not correctly control your volume, please file an appropriate bug report: https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri Dec 11 18:22:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 10:22:47 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260308728.3311.1994.camel@localhost.localdomain> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260308728.3311.1994.camel@localhost.localdomain> Message-ID: <1260555767.19557.20.camel@adam.local.net> On Tue, 2009-12-08 at 21:45 +0000, Bastien Nocera wrote: > You can still do all the heavy lifting you want. Install the old > gst-mixer, I actually dropped gst-mixer with F12, as we planned all along. So that one's not an option for F12. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From maxamillion at fedoraproject.org Fri Dec 11 18:38:39 2009 From: maxamillion at fedoraproject.org (Adam Miller) Date: Fri, 11 Dec 2009 12:38:39 -0600 Subject: new webkitgtk incremental release for F12 Message-ID: There is currently a new incremental release to webkitgtk (the current release in F12 is 1.1.15-3, latest is 1.1.15-4) and I wanted to shoot out to the list to find out if there is anything that would need a new build against webkitgtk if I were to build the latest as a potential stable update for F12 (possibly pywebkitgtk and/or $other?). I've done a scratch build and tested with Midori which has been a positive experience so far, so if there are any other alternative web browsers that use webkitgtk they should work as well against the new build, but testing is always best. Feedback welcome, -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From rawhide at fedoraproject.org Fri Dec 11 19:16:02 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 11 Dec 2009 19:16:02 +0000 Subject: rawhide report: 20091211 changes Message-ID: <20091211191602.GA28395@releng2.fedora.phx.redhat.com> Compose started at Fri Dec 11 08:15:05 UTC 2009 Broken deps for i386 ---------------------------------------------------------- abrt-1.0.0-1.fc13.i686 requires librpm.so.0 abrt-1.0.0-1.fc13.i686 requires librpmio.so.0 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 egoboo-2.7.5-7.fc12.i686 requires libenet-1.2.so gg2-core-2.3.0-13.fc12.i686 requires perl(DynaLoader) = 0:1.08 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 gvfs-afc-1.5.1-2.fc13.i686 requires libplist.so.0 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so ifuse-0.9.4-2.fc13.i686 requires libplist.so.0 inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kdebase-workspace-python-applet-4.3.80-3.fc13.i686 requires PyKDE4 >= 0:4.3.80 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.i686 requires libortp.so.7 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 libiphone-0.9.4-2.fc13.i686 requires libplist.so.0 libiphone-python-0.9.4-2.fc13.i686 requires libplist.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 ovaldi-5.5.25-1.fc12.i686 requires librpm.so.0 ovaldi-5.5.25-1.fc12.i686 requires librpmio.so.0 perl-RPM2-0.68-5.fc13.i686 requires librpm.so.0 perl-RPM2-0.68-5.fc13.i686 requires librpmio.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.2-5.fc12.i686 requires libgeos-3.1.1.so rpmreaper-0.1.6-2.fc12.i686 requires librpmbuild.so.0 rpmreaper-0.1.6-2.fc12.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 systemtap-1.0-2.fc13.i686 requires librpm.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- abrt-1.0.0-1.fc13.x86_64 requires librpm.so.0()(64bit) abrt-1.0.0-1.fc13.x86_64 requires librpmio.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) egoboo-2.7.5-7.fc12.x86_64 requires libenet-1.2.so()(64bit) gg2-core-2.3.0-13.fc12.x86_64 requires perl(DynaLoader) = 0:1.08 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) gvfs-afc-1.5.1-2.fc13.x86_64 requires libplist.so.0()(64bit) hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) ifuse-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kdebase-workspace-python-applet-4.3.80-3.fc13.x86_64 requires PyKDE4 >= 0:4.3.80 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.x86_64 requires libortp.so.7()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) libiphone-0.9.4-2.fc13.i686 requires libplist.so.0 libiphone-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) libiphone-python-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) ovaldi-5.5.25-1.fc12.x86_64 requires librpm.so.0()(64bit) ovaldi-5.5.25-1.fc12.x86_64 requires librpmio.so.0()(64bit) perl-RPM2-0.68-5.fc13.x86_64 requires librpm.so.0()(64bit) perl-RPM2-0.68-5.fc13.x86_64 requires librpmio.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.2-5.fc12.x86_64 requires libgeos-3.1.1.so()(64bit) rpmreaper-0.1.6-2.fc12.x86_64 requires librpmbuild.so.0()(64bit) rpmreaper-0.1.6-2.fc12.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) systemtap-1.0-2.fc13.x86_64 requires librpm.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package Maelstrom A space combat game New package attica Implementation of the Open Collaboration Services API New package emacs-irsim-mode Irsim mode for emacs New package f2c A Fortran 77 to C/C++ conversion program New package gant Groovy-based build system that uses Ant tasks New package genesis Graphical frontend to SyncEvolution New package globus-duct-common Globus Toolkit - Globus Duct Common New package globus-duroc-common Globus Toolkit - DUROC Common Library New package globus-gass-cache-program Globus Toolkit - Tools to manipulate local and remote GASS caches New package globus-gram-job-manager-scripts Globus Toolkit - GRAM Job ManagerScripts New package gnome-color-manager Color management tools for GNOME New package groovy Agile dynamic language for the Java Platform New package javacsv Stream-based Java library for reading and writing CSV and other delimited data New package jazzy Java-based spell checker New package lamson A Python mail server framework New package mingw32-openjpeg MinGW Windows openjpeg library New package mono-bouncycastle Bouncy Castle Crypto Package for Mono New package mygui Fast, simple and flexible GUI library for Ogre New package perl-CGI-Application-Plugin-ActionDispatch Adds attribute based support for parsing the PATH_INFO of an HTTP request New package perl-DBIx-Simple Easy-to-use OO interface to DBI New package perl-HTTP-Daemon-SSL Simple http server class with SSL support New package php-gettext Gettext emulation in PHP New package php-nusoap SOAP Toolkit for PHP New package php-pear-HTTP-OAuth Implementation of the OAuth spec New package php-pear-HTTP-Request2 Provides an easy way to perform HTTP requests New package php-pear-Net-URL2 Class for parsing and handling URL New package php-pear-OLE Package for reading and writing OLE containers New package php-pear-Services-Twitter PHP interface to Twitter's API New package pxe-kexec Linux boots Linux via network New package rubygem-ParseTree Extracts the parse tree for a class/method and returns an s-expression New package rubygem-rcov Code coverage analysis tool for Ruby New package rubygem-ruby2ruby Generate pure ruby from RubyParser compatible Sexps New package rubygem-ruby_parser A ruby parser written in pure ruby New package shared-color-profiles Shared color profiles to be used in color management aware applications New package shared-desktop-ontologies Shared ontologies needed for semantic environments New package sqljet Pure Java SQLite New package synfig Vector-based 2D animation rendering backend New package udisks Storage Management Service New package unicornscan Scalable, accurate, flexible and efficient network probing New package woff Encoding and Decoding for Web Open Font Format(Woff) New package woffTools Tool for manipulating and examining WOFF files New package wordpress-plugin-bad-behavior Bad Behavior plugin for WordPress New package xfce4-volumed Daemon to add additional functionality to the volume keys of the keyboard New package xmlbeans XML-Java binding tool New package yajl Yet Another JSON Library (YAJL) New package zikula-module-menutree Menutree allows to create multilevel, hierarchical (tree-like) menu Removed package bilbo Removed package bmpx Removed package lam Removed package synergy Removed package v4l2-tool Updated Packages: ConsoleKit-0.4.1-2.fc13 ----------------------- * Wed Dec 09 2009 Bill Nottingham 0.4.1-2 - Adjust for upstart 0.6 DevIL-1.7.8-4.fc13 ------------------ * Fri Dec 04 2009 Hans de Goede 1.7.8-4 - Fix DICOM Processing Buffer Overflow Vulnerability CVE-2009-3994 (#542700) DeviceKit-power-013-1.fc13 -------------------------- * Mon Dec 07 2009 Richard Hughes - 013-1 - Update to 013 - Detect more supported UPS devices. - Fix the Toshiba battery recall data. - Fix a crash when the battery NVRAM is invalid. - Add a couple of fixes for very new battery support. ETL-0.04.13-1.fc13 ------------------ * Sat Nov 14 2009 Lubomir Rintel - 0.04.13-1 - New upstream release - Drop our build patch, since upstream fixed necessary bits MiniCopier-0.5-1.fc13 --------------------- * Sat Dec 05 2009 Hicham HAOUARI 0.5-1 - New upstream release ModemManager-0.2.997-1.fc13 --------------------------- * Mon Dec 07 2009 Dan Williams - 0.2.997-1 - core: fix reconnect after manual disconnect (rh #541314) - core: fix various segfaults during registration - core: fix probing of various modems on big-endian architectures (ie PPC) - core: implement modem states to avoid duplicate operations - hso: fix authentication for Icera-based devices like iCON 505 - zte: use correct port for new devices - nozomi: fix detection MySQL-zrm-2.1.1-6.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 2.1.1-6 - rebuild against perl 5.10.1 NaturalDocs-1.4-5.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4-5 - rebuild against perl 5.10.1 NetworkManager-0.7.997-1.fc13 ----------------------------- * Mon Dec 07 2009 Dan Williams - 0.7.997-1 - core: remove haldaemon from initscript dependencies (rh #542078) - core: handle PEM certificates without an ending newline (rh #507315) - core: fix rfkill reporting for ipw2x00 devices - core: increase PPPoE timeout to 30 seconds - core: fix re-activating system connections with secrets - core: fix crash when deleting automatically created wired connections - core: ensure that a VPN's DNS servers are used when sharing the VPN connection - ifcfg-rh: support routes files (rh #507307) - ifcfg-rh: warn when device will be managed due to missing HWADDR (rh #545003) - ifcfg-rh: interpret DEFROUTE as never-default (rh #528281) - ifcfg-rh: handle MODE=Auto correctly - rpm: fix rpmlint errors - applet: don't crash on various D-Bus and other errors (rh #545011) (rh #542617) - editor: fix various PolicyKit-related crashes (rh #462944) - applet+editor: notify user that private keys must be protected PackageKit-0.5.5-1.fc13 ----------------------- * Mon Dec 07 2009 Richard Hughes - 0.5.5-1 - New upstream release of 0.5.5. - Check the filename is valid before exploding. Fixes #537381 - Only check certain transaction elements, not all of them. Fixes #541645 - Handle the cnf error condition where the package name would be invalid. Fixes #533014 - After a successful cnf installation, re-exec new binary not command-not-found. Fixes #533554 - When cnf searches for available files, use our preferred arch. Fixes #534169 - Run the newly installed file sync so we can return a proper exit code. Fixes #540482 - Only email using cron when a useful action was done. Fixes #540949 - Do not split more than one locale hint to fix setting LC_ variables. Fixes #543716 Perlbal-1.70-5.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 1.70-5 - rebuild against perl 5.10.1 R-BSgenome-1.14.2-1.fc12 ------------------------ * Sat Nov 21 2009 pingou 1.14.2-1 - Update to 1.14.2 - Remove %post and %postun - Adapt %files to R-2.10.0 R-BSgenome.Celegans.UCSC.ce2-1.3.16-1.fc13 ------------------------------------------ * Sat Nov 21 2009 pingou 1.3.16-1 - Update to 1.3.16 - Remove %post and %postun - Adapt %files to R-2.10.0 R-Biostrings-2.14.7-2.fc13 -------------------------- * Fri Dec 04 2009 pingou 2.14.7-2 - Remove the folder R-ex * Sat Nov 21 2009 pingou 2.14.7-1 - Update to 2.14.7 - Remove %post and %postun - Adapt %files to R-2.10.0 Sprog-0.14-18.fc13 ------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-18 - rebuild against perl 5.10.1 Zim-0.28-3.fc13 --------------- * Fri Dec 04 2009 Stepan Kasal - 0.28-3 - rebuild against perl 5.10.1 abby-0.4.6.1-1.fc13 ------------------- * Sun Dec 06 2009 Nicoleau Fabien 0.4.6.1-1 - Update to 0.4.6.1 ack-1.86-4.fc13 --------------- * Fri Dec 04 2009 Stepan Kasal - 1.86-4 - rebuild against perl 5.10.1 aide-0.13.1-14.fc13 ------------------- * Wed Dec 09 2009 Steve Grubb - 0.13.1-14 - Revise patch for Initialize libgcrypt correctly (#530485) akonadi-1.2.80-1.fc13 --------------------- * Mon Dec 07 2009 Rex Dieter 1.2.80-1 - Akonadi 1.2.80 - restore mysql deps almanah-0.6.1-2.fc13 -------------------- * Tue Dec 08 2009 Andreas Osowski - 0.6.1-2 - Cosmetic changes * Fri Nov 27 2009 Andreas Osowski - 0.6.1-1 - Update to new release - Fixed BuildRequires for new release amanda-2.6.0p2-15.fc13 ---------------------- * Fri Dec 04 2009 Stepan Kasal - 2.6.0p2-15 - rebuild against perl 5.10.1 amarok-2.2.1.90-1.fc13 ---------------------- * Thu Dec 10 2009 Rex Dieter - 2.2.1.90-1 - amarok-2.2.1.90 (2.2.2 beta1) anaconda-13.10-1.fc13 --------------------- * Wed Dec 09 2009 Chris Lumens - 13.10-1 - Kickstart support for unpartitioned disks. (dlehman) - Skip disklabel handling for biosraid and multipath members. (dlehman) - Improve disklabel's name attr so we don't have to hide them anymore. (dlehman) - Hide devices with certain formatting in the main partitioning UI. (dlehman) - Automatic partitioning support for whole-disk formatting. (dlehman) - Add support for whole-disk formatting. (dlehman) - Add per-row control over sensitive property for CheckList and WideCheckList. (dlehman) - Use a function to add a device to the partition gui. (dlehman) - Don't crash if there's no intf passed to getLUKSPassphrase. (dlehman) - Remove unused selinux file context functions from isys. (dlehman) - Use selinux python module for file context operations. (dlehman) - Obtain device alignment information from parted. (#529051) (dlehman) - Handle roots with or without trailing "/" in FileDevice.path. (#541473) (dlehman) - sundries.h is no longer used. (clumens) - Kill yet another unused lodaer flag. (clumens) - stage1 (init): Make /tmp tmpfs large enough to hold install.img (#540146) (hdegoede) - With flags.setupFilesystems gone, justConfig can be removed from booty. (clumens) - Nothing sets flags.setupFilesystems anymore, so it can go too. (clumens) - Remove test mode from the loader, too. (clumens) - Complain if we're started in test or rootPath mode instead of aborting. (clumens) - Remove test mode. (clumens) - Remove rootPath mode. (clumens) - Enable method/repo nfs options in stage2. (rvykydal) - Accept "nfs:" prefix in ks repo --baseurl setting beside "nfs://". (rvykydal) - Display url having invalid prefix in repo editing dialog. (rvykydal) - Do not traceback on invalid ks repo --baseurl values (#543003) (rvykydal) - Remove /etc/localtime before trying to copy into it (#533240). (akozumpl) - Whenever storage code tries to log a method call, do so into the 'tmp/storage.log' file. (a part of #524980) (akozumpl) - Make loader log time with milliseconds (part of #524980). (akozumpl) - Log storage in the same format as the main anaconda log (a part of anerley-0.2.0-3.fc13 -------------------- * Sun Dec 06 2009 Peter Robinson 0.2.0-3 - Fix spec file. Damn FUDCon hotel wifi * Sat Dec 05 2009 Peter Robinson 0.2.0-2 - Add patch from upstream to fix segfault when no self contact is found apt-0.5.15lorg3.95-0.git416.6.fc13 ---------------------------------- * Mon Dec 07 2009 Panu Matilainen - 0.5.15lorg3.95-0.git416.6 - rebuild for rpm 4.8.0 aria2-1.7.1-1.fc13 ------------------ * Mon Dec 07 2009 Rahul Sundaram - 1.7.1-1 - Option --bt-prioritize-piece=tail will work again - http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1721 arora-0.10.2-2.fc13 ------------------- * Thu Dec 10 2009 Jaroslav Reznik - 0.10.2-1 - Update to 0.10.2 - QtWebKit patch removed * Thu Dec 10 2009 Jaroslav Reznik - 0.10.2-2 - Conditionaly check for qt4 version arts-1.5.10-10.fc13 ------------------- * Thu Dec 10 2009 Stepan Kasal - 1.5.10-10 - patch autoconfigury to build with autoconf >= 2.64 * Sun Dec 06 2009 Than Ngo - 1.5.10-9 - fix url - fix security issues in libltdl (CVE-2009-3736) aspell-0.60.6-10.fc13 --------------------- * Fri Dec 04 2009 Ivana Hutarova Varekova - 12:0.60.6-10 - fix rpath problem (chrpath) asterisk-1.6.2.0-0.16.rc8.fc13 ------------------------------ * Wed Dec 09 2009 Jeffrey C. Ollie - 1.6.2.0-0.16.rc8 - Update to 1.6.2.0-rc8 asterisk-sounds-core-1.4.16-3.fc13 ---------------------------------- * Fri Dec 04 2009 Jeffrey C. Ollie - 1.4.16-3 - Add fr/1.g729 back and build with new version of RPM. at-3.1.12-1.fc13 ---------------- * Thu Dec 03 2009 Marcela Ma?l??ov? - 3.1.12-1 - update to the new version of at - adapt patches for new version - change our pam config to source - start using new upstream test instead of our nonfunctinal - upstream changed nofork option -n to foreground option -f at-spi-1.29.3-2.fc13 -------------------- * Sat Dec 05 2009 Matthias Clasen - 1.29.3-2 - Undo the relocation for now * Fri Dec 04 2009 Matthias Clasen - 1.29.3-1 - Update to 1.29.3 - The Python bindings have been relocated to pyatspi-corba to coexist with the new dbus-based bindings audacity-1.3.10-0.1.beta.fc13 ----------------------------- * Fri Dec 04 2009 Michael Schwendt - 1.3.9-0.5.beta - Prevent race-condition segfault with Sound Activated Recording (#544125). * Fri Dec 04 2009 Michael Schwendt - 1.3.10-0.1.beta - Upgrade to 1.3.10-beta. audit-2.0.4-1.fc13 ------------------ * Tue Dec 08 2009 Steve Grubb 2.0.4-1 - New upstream release authconfig-6.0.0-1.fc13 ----------------------- * Thu Dec 10 2009 Tomas Mraz - 6.0.0-1 - support for SSSD enabling/disabling and basic support for SSSD domain setup - safe atomic overwrites of the config files auto-buildrequires-1.1-1.fc13 ----------------------------- * Wed Dec 09 2009 Richard W.M. Jones - 1.1-1 - New upstream version 1.1. - Fixes bug when LANG != C (RHBZ#545867). autofs-5.0.5-16.fc13 -------------------- * Tue Dec 08 2009 Ian Kent - 1:5.0.5-16 - fix memory leak on reload (bz545137). * Fri Dec 04 2009 Ian Kent - 1:5.0.5-14 - fix rpc fail on large export list (bz543023). automake-1.11.1-1.fc13 ---------------------- * Wed Dec 09 2009 Karsten Hopp 1.11.1-1 - update to version 1.11.1 to fix CVE-2009-4029 * Tue Dec 01 2009 Karsten Hopp 1.11-6 - preserve time stamps of man pages (#225302) - drop MIT from list of licenses backup-manager-0.7.8-6.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.7.8-6 - rebuild against perl 5.10.1 bacula-3.0.3-5.fc13 ------------------- * Tue Dec 08 2009 Jon Ciesla - 2.0.1-15 - Applied patch from lkundrak to do not hang when no devices found. bz#537073 beediff-1.9-5.fc13 ------------------ * Sat Dec 05 2009 Terje Rosten - 1.9-3 - Web pages moved bibus-1.5.1-1.fc13 ------------------ * Wed Dec 09 2009 Alex Lancaster - 1.5.1-1 - Update to latest upstream (1.5.1) - Should fix connection problem with newer OpenOffice.org (#545809) bind-dyndb-ldap-0.1.0-0.6.a1.20091210git.fc13 --------------------------------------------- * Thu Dec 10 2009 Martin Nagy - 0.1.0-0.6.a1.20091210git - update to the latest git snapshot - change upstream URL, project moved to fedorahosted - change license to GPL version 2 or later - add epoch to versioned requires - add krb5-devel to the list of build requires binutils-2.20.51.0.2-9.fc13 --------------------------- * Wed Dec 09 2009 Nick Clifton - 2.20.51.0.2-9 - Apply patch for PR 10856. (BZ 544358) * Tue Dec 01 2009 Roland McGrath - 2.20.51.0.2-8 - Build gold only for x86 flavors until others are tested. bisho-0.17-2.fc13 ----------------- * Thu Dec 03 2009 Peter Robinson 0.17-2 - Require gvfs to fix issues with gtk_show_uri blacs-1.1-34.fc13 ----------------- * Mon Dec 07 2009 Tom "spot" Callaway - 1.1-34 - drop lam subpackages (fixes FTBFS, 539057) - blacs-mpich2-* now Provides/Obsoletes blacs-lam-*, this is a dirty lie, but we need something to do it - move static bits to -static subpackages (resolves 545142) - package up Bdef.h for other dependent packages to use (resolves 533929, thanks to Deji Akingunola) bochs-2.3.8-0.9.git04387139e3b.fc13 ----------------------------------- * Fri Dec 04 2009 Jon Ciesla 2.3.8-0.9.git04387139e3b - Include symlinks to VGABIOS in vgabios rpm, BZ 544310. - Enable cpu level 6. bonnie++-1.96-1.fc13 -------------------- * Wed Dec 09 2009 Rob Myers - 1.96 - Update to experimental version (#490895) - Merge patch from David Fetter calibre-0.6.26-1.fc13 --------------------- * Sun Dec 06 2009 Ionu? C. Ar??ri?i - 0.6.26-1 - New upstream version - Regenerated no-update patch because of code relocation cas-0.15-1.fc12.1 ----------------- * Thu Oct 15 2009 Adam Stokes - 0.15-1 - Require paramiko for all remote executions - Rip out func code - Documentation update to include ssh setup cclive-0.5.6-1.fc13 ------------------- * Sun Dec 06 2009 Nicoleau Fabien 0.5.6-1 - Update to 0.5.6 cdparanoia-10.2-6.fc13 ---------------------- * Tue Dec 08 2009 Matthias Saou 10.2-6 - Fix all of the problems detected during the review which aren't acceptable according to the current policies and guidelines (part of #225638). - Don't prefix summaries with "A" nor suffix them with a dot. - Move .so symlink to the devel sub-package (#203620). - Add highest known version to the cdparanoia-III obsoletes. - Remove incorrect buildroot removal from %build. - Use acceptable %clean section. - Provide cdparanoia-static in the devel sub-package since the *.a is there. - Use single-command scriplet syntax for /sbin/ldconfig calls. - Escape all macros in changelog. - Include license file since it is present with the sources. cflow-1.3-1.fc13 ---------------- * Sat Dec 05 2009 Terje Rosten - 1.3-1 - 1.3 cherokee-0.99.31-1.fc13 ----------------------- * Thu Dec 03 2009 Lorenzo Villani - 0.99.31-1 - New upstream release: 0.99.31 clamav-0.95.3-1301.fc13 ----------------------- * Sun Dec 06 2009 Enrico Scholz - 0.95.3-1301 - updated -upstart to upstart 0.6.3 * Sat Nov 21 2009 Enrico Scholz - adjusted chkconfig positions for clamav-milter (#530101) - use %apply instead of %patch claws-mail-plugins-3.7.3-2.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 3.7.3-2 - rebuild against perl 5.10.1 clearsilver-0.10.5-8.fc13 ------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.10.5-8 - rebuild against perl 5.10.1 clive-2.2.7-2.fc13 ------------------ * Fri Dec 04 2009 Stepan Kasal - 2.2.7-2 - rebuild against perl 5.10.1 cluster-3.0.6-1.fc13 -------------------- * Mon Dec 07 2009 Fabio M. Di Nitto - 3.0.6-1 - New upstream release - spec file update: * use global instead of define * use new Source0 url * use cluster macro more aggressively * bump Requires on fence-agents * ship var/run/cluster and var/lib/cluster coda-6.9.4-9.fc13 ----------------- * Fri Dec 04 2009 Neil Horman - 6.9.4-9 - Convert venus-setup to coda-client-setup (bz 544096) * Thu Sep 17 2009 Adam Goode - 6.9.4-8 - Patch venus-setup.in to remove unnecessary modules.conf stuff code2html-0.9.1-6.fc13 ---------------------- * Fri Dec 04 2009 Stepan Kasal - 0.9.1-6 - rebuild against perl 5.10.1 collectd-4.8.1-3.fc13 --------------------- * Fri Dec 04 2009 Stepan Kasal - 4.8.1-3 - rebuild against perl 5.10.1 condor-7.4.0-1.fc12 ------------------- * Fri Dec 04 2009 - 7.4.0-1 - Upgrade to 7.4.0 release - Fixed POSTIN error (BZ540439) - Removed NOTICE.txt source, now provided by upstream - Removed no_rpmdb_query.patch, applied upstream - Removed no_basename.patch, applied upstream - Added only_dynamic_unstripped.patch to reduce build time - Added guess_version_from_release_dir.patch, for previous - Added fix_platform_check.patch - Use new --with-platform, to avoid modification of make_final_tarballs - Introduced vm-gahp package to hold libvirt deps control-center-2.28.1-13.fc13 ----------------------------- * Thu Dec 10 2009 Matthias Clasen 2.28.1-11 - More wm keybinding fixes * Thu Dec 10 2009 Christoph Wickert - 2.28.1-12 - Let filesystem package own %{_datadir}/gnome-control-center/default-apps * Thu Dec 10 2009 Jon McCann 2.28.1-13 - Update aspect ratio patch (gnome #147808) * Tue Dec 08 2009 Matthias Clasen 2.28.1-10 - Avoid duplicate entries in the keybinding preferences (#542401) * Mon Dec 07 2009 Matthias Clasen 2.28.1-6 - Improve typing break locking for multiple monitors corosync-1.2.0-1.fc13 --------------------- * Tue Dec 08 2009 Fabio M. Di Nitto - 1.2.0-1 - New upstream release - Use global instead of define - Update Source0 url - Use more corosync macro around - Cleanup install section. Init script is now installed by upstream - Cleanup whitespace - Don't deadlock between package upgrade and corosync condrestart - Ship service.d config directory - Fix Conflicts vs Requires - Ship new sam library and man pages cpan-upload-2.2-6.fc13 ---------------------- * Fri Dec 04 2009 Stepan Kasal - 2.2-6 - rebuild against perl 5.10.1 cpanspec-1.78-4.fc13 -------------------- * Fri Dec 04 2009 Stepan Kasal - 1.78-4 - rebuild against perl 5.10.1 crm114-0-1.12.20090807.fc13 --------------------------- * Sun Sep 20 2009 Dominik Mierzejewski 0-1.12.20090807 - included missing shuffle.crm (rhbz#520397) - rebuilt against new tre - improved Summary: cryptopp-5.6.1-0.1.svn479.fc13 ------------------------------ * Thu Nov 26 2009 Alexey Kurov - 5.6.1-0.1.svn479 - svn r479. MARS placed in the public domain by Wei Dai - Fixes rhbz#539227 * Fri Oct 30 2009 Rahul Sundaram 5.6.0-5 - Fix source cscope-15.6-6.fc12 ------------------ * Wed Dec 09 2009 Neil Horman - Fixed broken parsing of invalid options (bz 545816) csound-5.10.1-14.fc13 --------------------- * Thu Dec 03 2009 Peter Robinson - 5.10.1-14 - Updated python patch thanks to dsd. ctdb-1.0.108-1.fc13 ------------------- * Tue Dec 08 2009 Sumit Bose - 1.0.108-1 - Update to ctdb version 1.0.108 - added fix for bz537223 - added tdb-tools to Requires, fixes bz526479 * Wed Dec 02 2009 : Version 1.0.107 - fix for rusty to solve a double-free that can happen when there are multiple packets queued and the connection is destroyed before all packets are processed. * Wed Dec 02 2009 Sumit Bose - 1.0.107-1 - Update to ctdb version 1.0.107 * Tue Dec 01 2009 : Version 1.0.106 - Buildscript changes from Michael Adam - Dont do a full recovery when there is a mismatch detected for ip addresses, just do a less disruptive ip-reallocation - When starting ctdbd, wait until all initial recoveries have finished before we issue the "startup" event. So dont start services or monitoring until the cluster has stabilized. - Major eventscript overhaul by Ronnie, Rusty and Martins and fixes of a few bugs found. * Thu Nov 19 2009 : Version 1.0.105 - Fix a bug where we could SEGV if multiple concurrent "ctdb eventscript ..." are used and some of them block. - Monitor the daemon from the syslog child process so we shutdown cleanly when the main daemon terminates. - Add a 500k line ringbuffer in memory where all log messages are stored. - Add a "ctdb getlog " command to pull log messages from the in memory ringbuffer. - From martin : fixes to cifs and nfs autotests - from michael a : fix a bashism in 11.natgw * Fri Nov 06 2009 : Version 1.0.104 - Suggestion from Metze, we can now use killtcp to kill local connections for nfs so change the killtcp script to kill both directions of an NFS connection. We used to deliberately only kill one direction in these cases due to limitations. - Suggestion from christian Ambach, when using natgw, try to avoid using a UNHEALTHY node as the natgw master. - From Michael Adam: Fix a SEGV bug in the recent change to the eventscripts to allow the timeout to apply to each individual script. - fix a talloc bug in teh vacuuming code that produced nasty valgrind warnings. - From Rusty: Set up ulimit to create core files for ctdb, and spawned processes by default. This is useful for debugging and testing but can be disabled by setting CTDB_SUPRESS_COREFILE=yes in the sysconfig file. - Remove the wbinfo -t check from the startup check that winbindd is happy. - Enhance the test for bond devices so we also check if the sysadmin have disabled all slave devices using "ifdown". * Tue Nov 03 2009 : Version 1.0.103 - Dont use vacuuming on persistent databases - Michael A : transaction updates to persistent databases - Dont activate service automatically when installing the RPM. Leave this to the admin. - Create a child process to send all log messages to, to prevent a hung/slow syslogd from blocking the main daemon. In this case, discard log messages instead and let the child process block. - Michael A: updates to log messages * Thu Oct 29 2009 : Version 1.0.102 - Wolfgang: fix for the vacuuming code - Wolfgang: stronger tests for persistent database filename tests - Improve the log message when we refuse to startup since wbinfo -t fails to make it easier to spot in the log. - Update the uptime command output and the man page to indicate that "time since last ..." if from either the last recovery OR the last failover - Michael A: transaction updates * Wed Oct 28 2009 : Version 1.0.100 - Change eventscript handling to allow EventScriptTimeout for each individual script instead of for all scripts as a whole. - Enhanced logging from the eventscripts, log the name and the duration for each script as it finishes. - Add a check to use wbinfo -t for the startup event of samba - TEMP: allow clients to attach to databases even when teh node is in recovery mode - dont run the monitor event as frequently after an event has failed - DEBUG: in the eventloops, check the local time and warn if the time changes backward or rapidly forward - From Metze, fix a bug where recovery master becoming unhealthy did not trigger an ip failover. - Disable the multipath script by default - Automatically re-activate the reclock checking if the reclock file is specified at runtime. Update manpage to reflect this. - Add a mechanism where samba can register a SRVID and if samba unexpectedly disconnects, a message will be broadcasted to all other samba daemons. - Log the pstree on hung scripts to a file in /tmp isntead of /var/log/messages - change ban count before unhealthy/banned to 10 * Wed Oct 28 2009 : Version 1.0.101 - create a separate context for non-monitoring events so they dont interfere with the monitor event - make sure to return status 0 in teh callback when we abort an event ctemplate-0.96-1.fc13 --------------------- * Fri Dec 04 2009 Rakesh Pandit - 0.96-1 - Updated to 0.96 cups-1.4.2-17.fc13 ------------------ * Thu Dec 10 2009 Tim Waugh - 1:1.4.2-17 - Fixed invalid read in cupsAddDest (bug #547460). * Wed Dec 09 2009 Tim Waugh - 1:1.4.2-15 - Use upstream patch to fix scheduler crash when an active printer was deleted (rev 8914). * Tue Dec 08 2009 Tim Waugh - 1:1.4.2-14 - The scheduler did not use the Get-Job-Attributes policy for a printer (STR #3431). - The scheduler added two job-name attributes to each job object (STR #3428). - The scheduler did not clean out completed jobs when PreserveJobHistory was turned off (STR #3425). - The web interface did not show completed jobs (STR #3436). - Authenticated printing did not always work when printing directly to a remote server (STR #3435). - Use upstream patch to stop the network backends incorrectly clearing the media-empty-warning state (rev 8896). - Use upstream patch to fix interrupt handling in the side-channel APIs (rev 8896). - Use upstream patch to handle negative SNMP string lengths (rev 8896). - Use upstream fix for SNMP detection (bug #542857, STR #3413). - Use the text filter for text/css files (bug #545026, STR #3442). - Show conflicting option values in web UI (bug #544326, STR #3440). - Use upstream fix for adjustment of conflicting options (bug #533426, STR #3439). - No longer requires paps. The texttopaps filter MIME conversion file is now provided by the paps package (bug #545036). - Moved %{_datadir}/cups/ppdc/*.h to the main package (bug #545348). * Fri Dec 04 2009 Tim Waugh - 1:1.4.2-13 - The web interface prevented conflicting options from being adjusted (bug #533426, STR #3439). * Thu Dec 03 2009 Tim Waugh - 1:1.4.2-12 - Fixes for SNMP scanning with Lexmark printers (bug #542857, STR #3413). cups-pk-helper-0.0.4-9.fc12 --------------------------- * Thu Dec 03 2009 Marek Kasik - 0.0.4-9 - Allow inactive users and any user to authenticate - Resolves: #543085 * Wed Sep 30 2009 Marek Kasik - 0.0.4-8 - Fix adding of printers without specification of device-uri. - Patch by Tim Waugh. - Resolves: #526442 curl-7.19.7-8.fc13 ------------------ * Wed Dec 09 2009 Kamil Dudka 7.19.7-7 - use different port numbers for 32bit and 64bit builds - temporary workaround for #545779 * Wed Dec 09 2009 Kamil Dudka 7.19.7-8 - replace hard wired port numbers in the test suite * Tue Dec 08 2009 Kamil Dudka 7.19.7-6 - make it possible to run test241 - re-enable SCP/SFTP tests (#539444) * Sat Dec 05 2009 Kamil Dudka 7.19.7-5 - avoid use of uninitialized value in lib/nss.c - suppress failure of test513 on s390 cyrus-imapd-2.3.15-10.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.3.15-9 - rebuild against perl 5.10.1 * Fri Dec 04 2009 Michal Hlavinka - 2.3.15-10 - fix shell for daily cron job (#544182) * Thu Nov 26 2009 Michal Hlavinka - 2.3.15-8 - spec cleanup dahdi-tools-2.1.0.2-9.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.1.0.2-9 - rebuild against perl 5.10.1 dap-hdf4_handler-3.7.14-3.fc13 ------------------------------ * Tue Dec 08 2009 Michael Schwendt - 3.7.14-3 - Explicitly BR hdf-static in accordance with the Packaging Guidelines (hdf-devel is still static-only). deltarpm-3.5-0.5.20090913git.fc13 --------------------------------- * Tue Dec 08 2009 Jesse Keating - 3.5-0.5.20090913git - Rebuild for new rpm dhcp-forwarder-0.8-1300.fc13 ---------------------------- * Sun Dec 06 2009 Enrico Scholz - 0.8-1300 - updated -upstart to upstart 0.6.3 dirmngr-1.0.3-4.fc13 -------------------- * Tue Dec 08 2009 Michael Schwendt - 1.0.3-4 - Explicitly BR libassuan-static in accordance with the Packaging Guidelines (libassuan-devel is still static-only). djview4-4.5-1.fc13 ------------------ * Sun Dec 06 2009 Terje Rosten - 4.5-1 - 4.5 djvulibre-3.5.22-1.fc13 ----------------------- * Mon Nov 30 2009 Ralesh Pandit 3.5.22-1 - Updated to 3.5.22 (#542221) (Spec patch by Michal Schmidt) dnssec-tools-1.5-5.fc13 ----------------------- * Fri Dec 04 2009 Stepan Kasal - 1.5-5 - rebuild against perl 5.10.1 docbook2X-0.8.8-6.fc13 ---------------------- * Fri Dec 04 2009 Stepan Kasal - 0.8.8-6 - rebuild against perl 5.10.1 dokuwiki-0-0.1.20091202.rc.fc13 ------------------------------- * Fri Dec 04 2009 Andrew Colin Kissa - 0-0.1.20091202.rc - Upgrade to new upstream - Fix bugzilla bugs #544257, #544268 dosfstools-3.0.6-1.fc13 ----------------------- * Sun Dec 06 2009 Lubomir Rintel - 3.0.6-1 - Bump to newer release - Fix numerous out-of-bound writes dracut-modules-olpc-0.3.1-1.fc13 -------------------------------- * Mon Dec 07 2009 Daniel Drake - 0.3.1-1 - New version to fix booting alternate image dstat-0.7.0-1.fc13 ------------------ * Thu Dec 03 2009 Jan Zeleny - 0.7.0-1 - rebased to 0.7.0 dvisvgm-0.8.7-2.fc13 -------------------- * Tue Dec 08 2009 Michael Schwendt - 0.8.7-2 - Explicitly BR potrace-static in accordance with the Packaging Guidelines (potrace-devel is still static-only). dwarves-1.8-1.fc13 ------------------ * Fri Dec 04 2009 Apr 23 2009 Arnaldo Carvalho de Melo - 1.8-1 - New release dx-4.4.4-13.fc13 ---------------- * Tue Dec 08 2009 Michael Schwendt - 4.4.4-13 - Explicitly BR hdf-static in accordance with the Packaging Guidelines (hdf-devel is still static-only). dxcc-20080225-7.fc13 -------------------- * Fri Dec 04 2009 Stepan Kasal - 20080225-7 - rebuild against perl 5.10.1 e16-1.0.1-1.fc13 ---------------- * Mon Dec 07 2009 Terje Rosten - 1.0.1-1 - 1.0.1 e16-themes-1.0.0-1.fc13 ----------------------- * Mon Dec 07 2009 Terje Rosten - 1.0.0-1 - 1.0.0 eclipse-3.5.1-24.fc13 --------------------- * Fri Dec 04 2009 Alexander Kurtakov 1:3.5.1-24 - Replace gecko BR/Rs with xulrunner. - Drop xulrunner-devel-unstable now that it's merged in xulrunner-devel. * Thu Dec 03 2009 Alexander Kurtakov 1:3.5.1-23 - Remove old manipulations to bundles.info. - Update to eclipse-build 0.4 release. * Mon Nov 30 2009 Andrew Overholt 1:3.5.1-22 - Move ant-nodeps out of bootstrap. eclipse-oprofile-0.4.0-1.fc13 ----------------------------- * Sat Dec 05 2009 Kent Sebastian - 0.4.0-1 - 0.4.0 (long overdue) eclipse-pydev-1.5.3-1.fc13 -------------------------- * Thu Dec 10 2009 Alexander Kurtakov 1:1.5.3-1 - Update to 1.5.3. * Wed Dec 09 2009 Alexander Kurtakov 1:1.5.2-1 - Update to 1.5.2. eclipse-rpm-editor-0.4.3-2.fc13 ------------------------------- * Fri Dec 04 2009 Alexander Kurtakov 0.4.3-2 - Update to Linux Tools 0.4 release. eclipse-rpmstubby-0.4.0-1.fc13 ------------------------------ * Fri Dec 04 2009 Alexander Kurtakov 0.4.0-1 - Update to Linux Tools 0.4 release. ejabberd-2.1.0-2.fc13 --------------------- * Thu Dec 10 2009 Peter Lemenkov 2.1.0-2 - DB backups are made on every upgrade/uninstall - Fixed installation of captcha.sh example helper - Added patches 9,10,11,12,13 from Debian's package emacs-23.1-17.fc13 ------------------ * Tue Dec 08 2009 Karel Klic 1:23.1-17 - Fixed rhbz#545398 - ETags messes up filenames * Thu Dec 03 2009 Daniel Novotny 1:23.1-16 - fix #542657 - emacs does not display indic text enchant-1.5.0-4.fc13 -------------------- * Sat Dec 05 2009 Marc Maurer 1:1.5.0-4 - Fix 544473: Move enchant.so from the devel to the main package enet-1.2.1-1.fc13 ----------------- * Fri Dec 04 2009 Rakesh Pandit - 1.2.1-1 - Updated to 1.2.1 eog-2.29.3-2.fc13 ----------------- * Thu Dec 03 2009 Matthias Clasen 2.29.3-2 - Don't ship .la files epiphany-2.29.3-2.fc13 ---------------------- * Wed Dec 09 2009 Bastien Nocera 2.29.3-2 - Remove gnome-vfs2-devel dependency for the devel package epydoc-3.0.1-6.fc13 ------------------- * Tue Dec 08 2009 Matthias Saou 3.0.1-6 - Add texlive-dvips and texlive-latex requirements (#522249). epylog-1.0.3-11.fc13 -------------------- * Fri Dec 04 2009 Stepan Kasal - 1.0.3-11 - rebuild against perl 5.10.1 evolution-data-server-2.29.3-3.fc13 ----------------------------------- * Wed Dec 09 2009 Bastien Nocera 2.29.3-3 - Remove libgnome and libgnomeui requirements exim-4.69-19.fc13 ----------------- * Fri Dec 04 2009 Stepan Kasal - 4.69-19 - rebuild against perl 5.10.1 * Mon Oct 05 2009 David Woodhouse - 4.69-18 - Fix typo in clamd %post (#527085) expat-2.0.1-8.fc13 ------------------ * Tue Dec 01 2009 Joe Orton - 2.0.1-8 - add security fix for CVE-2009-3560 (#533174) - add security fix for CVE-2009-3720 (#531697) - run the test suite extrema-4.4.2-1.fc13 -------------------- * Sun Dec 06 2009 Terje Rosten - 4.4.2-1 - 4.4.2 fcgi-2.4.0-11.fc13 ------------------ * Fri Dec 04 2009 Stepan Kasal - 2.4.0-11 - rebuild against perl 5.10.1 fcoe-utils-1.0.9-2.20091204git.fc13 ----------------------------------- * Thu Dec 10 2009 Jan Zeleny - 1.0.9-2.20091204git - excluded s390 and ppc * Fri Dec 04 2009 Jan Zeleny - 1.0.9-1.20091204git - rebase to latest version of fcoe-utils fence-agents-3.0.6-2.fc13 ------------------------- * Mon Dec 07 2009 Fabio M. Di Nitto - 3.0.6-1 - New upstream release (drop fence_head.diff) - spec file updates: * use new Source0 url * use file based Requires for ipmitools (rhbz: 545237) * Mon Dec 07 2009 Fabio M. Di Nitto - 3.0.6-2 - Use the correct tarball from upstream * Fri Dec 04 2009 Fabio M. Di Nitto - 3.0.5-2.git0a6184070 - Drop fence_xvm from upstream (fence_head.diff) - spec file updates: * Drop unrequired comments * Readd alpha tag and clean it's usage around * Requires: fence-virt in sufficient version to provide fence_xvm fence-virt-0.1.3-1.fc13 ----------------------- flickcurl-1.14-1.fc13 --------------------- * Thu Dec 03 2009 Rakesh Pandit - 1.14-1 - Updated to 1.14 fltk-1.1.10-0.1.rc3.fc13 ------------------------ * Tue Dec 08 2009 Rex Dieter - 1.1.10-0.1.rc3 - fltk-1.1.10rc3 * Mon Dec 07 2009 Rex Dieter - 1.1.9-7 - real -static subpkg (#545145) fluidsynth-1.0.9-5.fc13 ----------------------- * Wed Dec 09 2009 Kevin Kofler - 1.0.9-5 - Enable PulseAudio support (#538224, FESCo#265, also works around #500087) fontconfig-2.8.0-1.fc13 ----------------------- * Thu Dec 03 2009 Behdad Esfahbod - 2.8.0-1 - Update to 2.8.0 foomatic-db-4.0-8.20091126.fc13 ------------------------------- * Fri Dec 04 2009 Tim Waugh 4.0-8.20091126 - Added foomatic-db-hpijs tarball back in. fotowall-0.9-1.fc13 ------------------- * Tue Dec 08 2009 Nicoleau Fabien - 1:0.9-1 - Update to 0.9 fprintd-0.1-16.git04fd09cfa.fc13 -------------------------------- * Wed Dec 09 2009 Bastien Nocera 0.1-16.git04fd09cfa - Remove use of g_error(), or people think that it crashes when we actually abort() (#543194) freetype-2.3.11-2.fc13 ---------------------- * Thu Dec 03 2009 Behdad Esfahbod 2.3.11-2 - Drop upstreamed patch. - Enable patented bytecode interpretter now that the patents are expired. frescobaldi-0.7.16-1.fc12 ------------------------- * Wed Nov 18 2009 Orcan Ogetbil - 0.7.16-1 - New upstream version fuse-zip-0.2.8-1.fc13 --------------------- * Fri Dec 04 2009 Rakesh Pandit - 0.2.8-1 - Updated to 0.2.8 galeon-2.0.7-22.fc13 -------------------- * Tue Dec 08 2009 Yanko Kaneti - 2.0.7-22 - Avoid warnings (#514289) and empty looking spinner button * Mon Dec 07 2009 Yanko Kaneti - 2.0.7-21 - Add patches so that it actually builds against newer gecko * Thu Nov 26 2009 Jan Horak - 2.0.7-20 - Rebuild against newer gecko garmintools-0.10-3.fc13 ----------------------- * Tue Dec 08 2009 Michael Schwendt - 0.10-3 - Explicitly BR libgarmin-static in accordance with the Packaging Guidelines (libgarmin-devel is still static-only). gc-7.1-10.fc13 -------------- * Tue Dec 08 2009 Michael Schwendt - 7.1-10 - Explicitly BR libatomic_ops-static in accordance with the Packaging Guidelines (libatomic_ops-devel is still static-only). gcalctool-5.29.2-1.fc13 ----------------------- * Fri Dec 04 2009 Matthias Clasen - 5.29.2-1 - Update to 5.29.2 gdal-1.6.2-3.fc13 ----------------- * Tue Dec 08 2009 Michael Schwendt - 1.6.2-3 - Explicitly BR hdf-static in accordance with the Packaging Guidelines (hdf-devel is still static-only). gdb-7.0-9.fc12 -------------- * Mon Dec 07 2009 Jan Kratochvil - 7.0-9.fc12 - Replace the PIE (Position Indepdent Executable) support patch by a new one. - Drop gdb-6.3-nonthreaded-wp-20050117.patch as fuzzy + redundant. - Fix callback-mode readline-6.0 regression for CTRL-C. - Fix syscall restarts for amd64->i386 biarch. - Various testsuite results stability fixes. - Fix crash on reading stabs on 64bit (BZ 537837). - archer-jankratochvil-fedora12 commit: 16276c1aad1366b92e687c72cab30192280e1906 - archer-jankratochvil-pie-fedora12 ct: 2ae60b5156d43aabfe5757940eaf7b4370fb05d2 * Thu Dec 03 2009 Jan Kratochvil - 7.0-8.fc12 - Fix slowness/hang when printing some variables (Sami Wagiaalla, BZ 541093). - archer-jankratochvil-fedora12 commit: 6817a81cd411acc9579f04dcc105e9bce72859ff gdl-0.9-0.9.rc3.fc13 -------------------- * Tue Dec 08 2009 Michael Schwendt - 0.9-0.9.rc3 - Explicitly BR hdf-static in accordance with the Packaging Guidelines (hdf-devel is still static-only). gdm-2.29.1-3.fc13 ----------------- * Wed Dec 09 2009 Ray Strode 2.29.1-3 - Update to work better with latest plymouth * Thu Dec 03 2009 Ray Strode 2.29.1-2 - Drop upstreamed patches - rebase multi-stack patch * Tue Dec 01 2009 Bastien Nocera 2.29.1-1 - Update to 2.29.1 * Sat Oct 31 2009 Matthias Clasen 2.28.1-18 - Actually set up statusicon padding * Sat Oct 31 2009 Matthias Clasen 2.28.1-20 - Don't show 'Lock Screen' in the user switcher if locked down * Fri Oct 30 2009 Ray Strode 2.28.1-17 - Make the user list slide animation smoother * Thu Oct 29 2009 Ray Strode 2.28.1-15 - Don't show fingerprint task button unless fingerprint is enabled - Don't show smartcard task button and list item unless pcscd is running. * Thu Oct 29 2009 Ray Strode 2.28.1-16 - Shrink autologin timer - Make language dialog not double spaced * Wed Oct 28 2009 Ray Strode 2.28.1-13 - Fix double free during user switching (might address bug 512944) * Wed Oct 28 2009 Ray Strode 2.28.1-14 - Don't show image on login button gedit-2.29.3-3.fc13 ------------------- * Thu Dec 03 2009 Matthias Clasen - 1:2.29.3-3 - Don't ship .la files gedit-vala-0.6.1-1.fc13 ----------------------- * Tue Dec 08 2009 Michel Salim - 0.6.1-1 - Update to 0.6.1 geos-3.2.0-rc3_1.fc13.1 ----------------------- * Thu Dec 03 2009 Devrim G?ND?Z - 3.2.0-rc3_1.1 - Fix spec (dep error). gfan-0.3-7.fc13 --------------- * Tue Dec 08 2009 Michael Schwendt - 0.3-7 - Explicitly BR cddlib-static in accordance with the Packaging Guidelines (cddlib-devel is still static-only). gflags-1.2-1.fc13 ----------------- * Fri Dec 04 2009 Rakesh Pandit - 1.2-1 - Updated to 1.2 ginac-1.5.5-1.fc13 ------------------ * Fri Dec 04 2009 Rakesh Pandit - 1.5.5-1 - Updated to 1.5.5 git-1.6.5.5-1.fc13 ------------------ * Sun Dec 06 2009 Todd Zullinger - 1.6.5.5-1 - git-1.6.5.5 * Fri Dec 04 2009 Stepan Kasal - 1.6.5.3-2 - rebuild against perl 5.10.1 gle-4.2.1-1.fc13 ---------------- * Sun Dec 06 2009 Terje Rosten - 4.2.1-1 - 4.2.1 globus-core-5.15-7.fc13 ----------------------- * Mon Dec 07 2009 Mattias Ellert - 5.15-7 - rebuild against perl 5.10.1 gnome-chemistry-utils-0.10.9-2.fc13 ----------------------------------- * Tue Dec 01 2009 Julian Sikorski - 0.10.9-2 - Rebuilt for new goffice - Added patch from to allow such build gnome-desktop-2.29.3-2.fc13 --------------------------- * Thu Dec 10 2009 Jon McCann - 2.29.3-2 - Update per-monitor backgrounds patch (gnome #147808) * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 * Thu Nov 12 2009 Matthias Clasen - 2.28.1-5 - Make slideshows work again (gnome #601753) gnome-disk-utility-2.29.0-0.git20091202.fc13 -------------------------------------------- * Wed Dec 02 2009 David Zeuthen - 2.29.0-0.git20091202.fc13 - Update to git snapshot that requires udisks instead of DeviceKit-disks - The UI has been completely revamped gnome-games-2.29.3-2.fc13 ------------------------- * Sat Dec 05 2009 Mamoru Tasaka 2.29.3-2 - Fix syntax error on scriptlets * Tue Dec 01 2009 Bastien Nocera 2.29.3-1 - Update to 2.29.3 gnome-nettool-2.28.0-1.fc13 --------------------------- * Fri Dec 04 2009 Matthias Clasen - 2.28.0-1 - Update to 2.28.0 gnome-power-manager-2.29.1-1.fc13 --------------------------------- * Tue Dec 08 2009 Richard Hughes - 2.29.1-1 - Update to 2.29.1 - Remove upstreamed patches * Mon Dec 07 2009 Bastien Nocera 2.28.1-5 - Remove HAL dependency gnome-screensaver-2.28.0-8.fc13 ------------------------------- * Thu Dec 03 2009 Matthias Clasen 2.28.0-8 - Drop an unwanted dependency gnome-shell-2.28.0.20091206git-5 -------------------------------- * Mon Dec 07 2009 Adam Miller - 2.28.0.20091206git-4 - Added gnome-common needed by autogen.sh in git snapshot build * Mon Dec 07 2009 Adam Miller - 2.28.0.20091206git-5 - Added libtool, glib-gettext for the libtoolize dep of git snapshot * Sun Dec 06 2009 Adam Miller - 2.28.0.20091206git-1 - Update to git snapshot on 20091206 * Sun Dec 06 2009 Adam Miller - 2.28.0.20091206git-2 - Fixed the setup naming issue with the git snapshot directory naming * Sun Dec 06 2009 Adam Miller - 2.28.0.20091206git-3 - Added the autotools needed to build the git snapshot to the build requires gnome-themes-2.29.2-1.fc13 -------------------------- * Fri Dec 04 2009 Matthias Clasen - 2.29.2-1 - Update to 2.29.2 gnomeradio-1.8-4.fc13 --------------------- * Fri Dec 04 2009 Dominik Mierzejewski - 1.8-4 - Changed defaults for using v4l2 (based on a patch by Paulo Roma) - Included script gnomeradio.sh (Paulo Roma) - fixed URL gnonlin-0.10.13.2-1.fc13 ------------------------ * Thu Dec 10 2009 Jeffrey C. Ollie - 0.10.13.2-1 - Update to prerelease version. gnucash-2.3.8-1.fc13 -------------------- * Thu Dec 10 2009 Bill Nottingham - 2.3.8-1 - update to 2.3.8 gnupg2-2.0.13-4.fc13 -------------------- * Tue Dec 08 2009 Michael Schwendt - 2.0.13-4 - Explicitly BR libassuan-static in accordance with the Packaging Guidelines (libassuan-devel is still static-only). gnusim8085-1.3.5-6.fc13 ----------------------- * Thu Dec 10 2009 Chitlesh Goorah - 1.3.5-6 - Fixed broken package version naming - Change docdir in configure.in fix RHBZ 542945 - Reverted sources to stable 1.3.5 : thankfully release 5 was not pushed to repos * Thu Dec 03 2009 Rangeen Basu Roy Chowdhury - svn.141-4 - Updated to svn.141 version * Thu Dec 03 2009 Rangeen Basu Roy Chowdhury - svn.141-5 - Fixed Bug-542945 gob2-2.0.16-4.fc13 ------------------ * Thu Dec 03 2009 Daniel Novotny 2.0.16-4 - fixed "Source:" URL in spec (merge review: #225851) gok-2.29.2-1.fc13 ----------------- * Sat Dec 05 2009 Matthias Clasen 2.29.2-1 - Update to 2.29.2 gpa-0.8.0-3.fc13 ---------------- * Tue Dec 08 2009 Michael Schwendt - 0.8.0-3 - Explicitly BR libassuan-static in accordance with the Packaging Guidelines (libassuan-devel is still static-only). grads-2.0.a7.1-0.3.fc13 ----------------------- * Tue Dec 08 2009 Michael Schwendt - 2.0.a7.1-0.3 - Same as below with hdf-static. - Explicitly BR g2clib-static in accordance with the Packaging Guidelines (g2clib-devel is still static-only). gramps-3.1.3-1.fc13 ------------------- * Wed Dec 09 2009 Jeffrey C. Ollie - 3.1.3-1 - Update to 3.1.3 grass-6.3.0-15.fc13 ------------------- * Fri Dec 04 2009 Devrim G?ND?Z - 6.3.0-15 - Rebuilt with new geos grepmail-5.3034-2.fc13 ---------------------- * Fri Dec 04 2009 Stepan Kasal - 5.3034-2 - rebuild against perl 5.10.1 gromacs-4.0.7-1.fc13 -------------------- * Sun Dec 06 2009 Jussi Lehtola - 4.0.6-1 - Update to 4.0.6. * Sun Dec 06 2009 Jussi Lehtola - 4.0.7-1 - Update to 4.0.7. * Fri Dec 04 2009 Jussi Lehtola - 4.0.5-6 - Fix file conflict. gssdp-0.7.1-1.fc13 ------------------ * Fri Dec 04 2009 Peter Robinson 0.7.1-1 - Update to 0.7.1 gstreamer-plugins-good-0.10.17-4.fc13 ------------------------------------- * Mon Dec 07 2009 Bastien Nocera 0.10.17-4 - Remove HAL elements, they're unused and obsolete * Fri Dec 04 2009 Bastien Nocera 0.10.17-3 - Disable LADSPA plugins, they should be in -bad (#540198) gtest-1.4.0-1.fc13 ------------------ * Sat Nov 14 2009 Debarshi Ray - 1.4.0-1 - Version bump to 1.4.0. * New feature: the event listener API. * New feature: test shuffling. * New feature: the XML report format is closer to junitreport and can be parsed by Hudson now. * New feature: elapsed time for the tests is printed by default. * New feature: comes with a TR1 tuple implementation such that Boost is no longer needed for Combine(). * New feature: EXPECT_DEATH_IF_SUPPORTED macro and friends. * New feature: the Xcode project can now produce static gtest libraries in addition to a framework. * Compatibility fixes for gcc and minGW. * Bug fixes and implementation clean-ups. gtg-0.1.9-1.fc13 ---------------- * Thu Dec 03 2009 Yanko Kaneti 0.1.9-1 - 0.2 beta. http://gtg.fritalk.com/post/2009/12/02/Getting-Things-GNOME!-0.1.9-is-out! - Remove some no longer necessary patching - BR: pyxdg gucharmap-2.29.1-1.fc13 ----------------------- * Fri Dec 04 2009 Matthias Clasen - 2.29.1-1 - Update to 2.29.1 gupnp-0.13.2-1.fc13 ------------------- * Fri Dec 04 2009 Peter Robinson 0.13.2-1 - Update to 0.13.2 gupnp-vala-0.6.2-2.fc13 ----------------------- * Thu Dec 10 2009 Peter Robinson 0.6.2-2 - Disable the empty debuginfo package hal-0.5.14-1.fc13 ----------------- * Fri Dec 04 2009 Richard Hughes - 0.5.14-1 - New release. - See http://lists.freedesktop.org/archives/hal/2009-November/013671.html hdapsd-20090401-5.fc13 ---------------------- * Mon Dec 07 2009 Tomasz Torcz 20090401-5 - port initscript file to upstart 0.6, removing custom udev rule hplip-3.9.10-5.fc13 ------------------- * Thu Dec 10 2009 Tim Waugh - 3.9.10-5 - Reverted fix for bug #533462 until bug #541604 is solved. httpd-2.2.14-1.fc13 ------------------- * Thu Dec 03 2009 Joe Orton - 2.2.14-1 - update to 2.2.14 - relax permissions on /var/run/httpd (#495780) - Requires(pre): httpd in mod_ssl subpackage (#543275) - add partial security fix for CVE-2009-3555 (#533125) hunspell-1.2.8-13.fc13 ---------------------- * Tue Dec 08 2009 Caolan McNamara - 1.2.8-13 - Resolves: rhbz#544372 survive having no HOME hunspell-da-1.7.31-1.fc13 ------------------------- * Thu Dec 10 2009 Caolan McNamara - 1.7.31-1 - latest version hunspell-eo-1.0-0.1.dev.fc13 ---------------------------- * Thu Dec 03 2009 Caolan McNamara - 1.0-0.1.dev - latest version hunspell-ht-0.05-1.fc13 ----------------------- * Thu Dec 10 2009 Caolan McNamara - 0.05-1 - latest version ibus-1.2.0.20091204-2.fc13 -------------------------- * Thu Dec 10 2009 Peng Huang - 1.2.0.2001204-2 - Fix rpmlint warnings and errors. * Fri Dec 04 2009 Peng Huang - 1.2.0.2001204-1 - Update to 1.2.0.20091204 - Fix Bug 529920 - language panel pops up on the wrong monitor - Fix Bug 541197 - Ibus crash ibus-chewing-1.2.0.20091211-1.fc13 ---------------------------------- * Fri Dec 11 2009 Ding-Yi Chen - 1.2.0.20091211-1 - Fix Google issue 608: ibus-chewing does not show cursor in xim mode. - Fix Google issue 611: ibus-chewing keyboard setting reverts to default unexpectlly. - Fix Google issue 660: failed to build with binutils-gold. - Remove make target commit. - Add make target tag * Fri Oct 09 2009 Ding-Yi Chen - 1.2.0.20091002-1 - Bug 518901 - ibus-chewing would not work with locale zh_TW.Big - Fix Google issue 501: ibus-chewing buffer doesn't get cleared when toggling ibus on/off - Fix Google issue 502: ibus-chewing: character selection window stays behind when toggling ibus off- Use WM's revised ibus-chewing icon. - Debug output now marked with levels. ibus-hangul-1.2.0.20091031-1.fc13 --------------------------------- * Fri Dec 11 2009 Peng Huang - 1.1.0.20091031-1 - Update version to 1.2.0.20091031. - Drop ibus-hangul-1.1.0.20090328-right-ctrl-hanja.patch and ibus-hangul-1.1.0.20090328-hanja-arrow-keys.patch temporarily, because patches conflict with 1.2.0.20091031, and the key configure will available in next release. ibus-pinyin-1.2.99.20091211-1.fc13 ---------------------------------- * Fri Dec 11 2009 Peng Huang - 1.2.99.20091211-1 - Update to 1.2.99.20091211-1 * Thu Dec 10 2009 Peng Huang - 1.2.0.20090915-2 - Correct pinyin database download location. ibus-qt-1.2.0.20091206-2.fc13 ----------------------------- * Sun Dec 06 2009 Peng Huang - 1.2.0.20091206-1 - Update to 1.2.0.20091206. ibus-rawcode-1.2.0.20090703-4.fc13 ---------------------------------- * Fri Dec 11 2009 Pravin Satpute - @VERSON at -4 - resolved bug 546521 initscripts-9.03-1 ------------------ * Wed Dec 09 2009 Bill Nottingham - 9.03-1 - migrate to upstart 0.6.x (, ) -- jobs move to /etc/init -- collapse rcX and ttyX jobs into single job definitions -- jobs are no longer %config - remove obsolete doexec command - rc.sysinit: handle yet another random return string from dmraid - remove never-used 'sulogin' upstart event - fix time-setting udev rules for old-style RTC devices (#537595) - init.d/network: keep error codes limited to '1'. (#537841) - add initial ifup/ifdown man pages. (#529328, ) inkscape-0.47-2.fc13 -------------------- * Sun Dec 06 2009 Lubomir Rintel - 0.47-2 - Fix Rawhide build. * Wed Nov 25 2009 Lubomir Rintel - 0.47-1 - Stable release * Mon Nov 23 2009 Adam Jackson 0.47-0.18.pre4.20091101svn - Fix RHEL6 build. ip-sentinel-0.12-1300.fc13 -------------------------- * Sun Dec 06 2009 Enrico Scholz - 0.12-1300 - updated -upstart to upstart 0.6.3 itcl-3.4-6.fc13 --------------- * Mon Dec 07 2009 Wart - 3.4-6 - Fix segfault during startup (BZ #539453) iverilog-0.9.20091205-1.fc13 ---------------------------- * Sat Dec 05 2009 Chitlesh Goorah - 0.9.20091205-1 - New development snapshot - 0.9.2 prerelease snapshot * Fri Dec 04 2009 Chitlesh Goorah - 0.9.20091204-1 - New development snapshot - 0.9.2 prerelease snapshot * Sat Nov 28 2009 Chitlesh Goorah - 0.9.20091130-1 - New development snapshot iwidgets-4.0.2-4.fc13 --------------------- * Sat Dec 05 2009 Wart - 4.0.2-4 - Remove version requirement on Tk iwl3945-firmware-15.32.2.9-4.fc13 --------------------------------- * Fri Dec 04 2009 John W. Linville 15.32.2.9-3 - Use reasonable permissions for text files * Fri Dec 04 2009 John W. Linville 15.32.2.9-4 - Use of a dist tag is now back in favor... jakarta-commons-codec-1.4-5.fc13 -------------------------------- * Tue Dec 08 2009 Mat Booth - 1.4-5 - Enable OSGi automatic depsolving (from Alphonse Van Assche). jd-2.5.5-0.1.svn3244_trunk.fc13 ------------------------------- * Fri Dec 11 2009 Mamoru Tasaka - rev 3244 * Sun Dec 06 2009 Mamoru Tasaka - 2.5.0-1 - 2.5.0 jide-oss-2.7.6-3.1340svn.fc13 ----------------------------- * Mon Dec 07 2009 Hicham HAOUARI 2.7.6-3.1340svn - Fix a missing doc package * Sat Dec 05 2009 Hicham HAOUARI 2.7.6-2.1340svn - New svn snapshot k3b-1.69.0-2.fc13 ----------------- * Thu Dec 10 2009 Rex Dieter - 1:1.69.0-1 - k3b-1.69.0 (alpha4) * Thu Dec 10 2009 Rex Dieter - 1:1.69.0-2 - fix %post scriptlet kannel-1.4.3-4.fc13 ------------------- * Mon Dec 07 2009 Matthias Saou 1.4.3-4 - Fix gw-config wrapper to actually have it work (#542605). kde-plasma-yawp-0.3.2-1.fc13 ---------------------------- * Sun Dec 06 2009 Orcan Ogetbil - 0.3.2-1 - Update to new upstream version kdebase-4.3.80-3.fc13 --------------------- * Wed Dec 09 2009 Rex Dieter - 4.3.80-2 - BR: shared-desktop-ontologies-devel * Wed Dec 09 2009 Kevin Kofler - 4.3.80-3 - rebuild against Nepomuk-enabled kdelibs * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdebase-runtime-4.3.80-3.fc13 ----------------------------- * Wed Dec 09 2009 Rex Dieter - 4.3.80-3 - BR: attica-devel shared-desktop-ontologies-devel * Sat Dec 05 2009 Kevin Kofler - 4.3.80-2 - BR exiv2-devel * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdebase-workspace-4.3.80-3.fc13 ------------------------------- * Wed Dec 09 2009 Rex Dieter - 4.3.80-2 - BR: shared-desktop-ontologies-devel * Wed Dec 09 2009 Kevin Kofler - 4.3.80-3 - drop polkit-qt* Obsoletes, we have a new polkit-qt now * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) - kdm_plymouth patch (#475890) kdegraphics-4.3.80-1.fc13 ------------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdelibs-4.3.80-4.fc13 --------------------- * Wed Dec 09 2009 Rex Dieter - 4.3.80-4 - BR: attica-devel shared-desktop-ontologies-devel - phonon_ver 4.3.80 - soprano_ver 2.3.70 * Fri Dec 04 2009 Than Ngo - 4.3.80-3 - respin * Thu Dec 03 2009 Kevin Kofler - 4.3.80-2 - BR polkit-qt-devel - fix the build of the KAuth PolkitQt-1 backend (upstream patch) * Tue Dec 01 2009 Ben Boeckel - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdepim-runtime-4.3.80-3.fc13 ---------------------------- * Tue Dec 08 2009 Than Ngo - 4.3.80-3 - drop BR kdelibs-experimental-devel * Fri Dec 04 2009 Than Ngo - 4.3.80-2 - respin * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdepimlibs-4.3.80-1.fc13 ------------------------ * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) keepalived-1.1.19-3.fc13 ------------------------ * Tue Dec 08 2009 Matthias Saou 1.1.19-3 - Update init script to have keepalived start after the local MTA (#526512). - Simplify the kernel source detection, to avoid running rpm from rpmbuild. kernel-2.6.32-7.fc13 -------------------- * Wed Dec 09 2009 Kyle McMartin 2.6.32-7 - ext4-fix-insufficient-checks-in-EXT4_IOC_MOVE_EXT.patch: CVE-2009-4131 fix insufficient permission checking which could result in arbitrary data corruption by a local unprivileged user. * Tue Dec 08 2009 Kyle McMartin 2.6.32-4 - Disable CONFIG_DEBUG_PERF_USE_VMALLOC for now, causes issues on x86_64. (rhbz#542791) * Tue Dec 08 2009 Kyle McMartin 2.6.32-5 - new rpm changes: - %{PACKAGE_VERSION} -> 2.6.32 - %{PACKAGE_RELEASE} -> 7.fc13 * Tue Dec 08 2009 Chuck Ebbert 2.6.32-6 - Copy fix for #540580 from F-12. * Mon Dec 07 2009 Steve Dickson 2.6.32-2 - Updated the NFS4 pseudo root code to the latest release. * Mon Dec 07 2009 Justin M. Forbes 2.6.32-3 - Allow userspace to adjust kvmclock offset (#530389) * Thu Dec 03 2009 Kyle McMartin 2.6.32-1 - Linux 2.6.32 kismet-0.0.2009.11.R1-1300.fc13 ------------------------------- * Sun Dec 06 2009 Enrico Scholz - 0.0.2009.11.R1-1300 - updated to 2009-11-R1 klibido-0.2.5-13.fc13 --------------------- * Tue Dec 08 2009 Michael Schwendt - 0.2.5-13 - Explicitly BR uulib-static in accordance with the Packaging Guidelines (uulib-devel is still static-only). knemo-0.6.0-1.fc13 ------------------ * Fri Dec 04 2009 Alexey Kurov - 0.6.0-1 - update to 0.6.0 knm-new-fixed-fonts-1.1-10.fc13 ------------------------------- * Fri Dec 04 2009 Akira TAGOH - 1.1-10 - revert the previous change and set the priority to 69 to ensure loading the rule later according to the result of https://bugzilla.redhat.com/show_bug.cgi?id=532237#c6 (#532237) konq-plugins-4.3.3-5.fc13 ------------------------- * Thu Dec 10 2009 Kevin Kofler - 4.3.3-4 - fix build with KDE 4.3.80's version of webkitkde (upstream patch) * Thu Dec 10 2009 Kevin Kofler - 4.3.3-5 - BR libtidy-devel (Fedora only) krb5-1.7-13.fc13 ---------------- * Wed Dec 09 2009 Nalin Dahyabhai - 1.7-13 - and put it back in * Tue Dec 08 2009 Nalin Dahyabhai - 1.7-12 - try to make gss_krb5_copy_ccache() work correctly for spnego (#542868) * Tue Dec 08 2009 Nalin Dahyabhai - back that last change out * Fri Dec 04 2009 Nalin Dahyabhai - make krb5-config suppress CFLAGS output when called with --libs (#544391) * Thu Dec 03 2009 Nalin Dahyabhai - 1.7-11 - ksu: move account management checks to before we drop privileges, like su does (#540769) - selinux: set the user part of file creation contexts to match the current context instead of what we looked up - configure with --enable-dns-for-realm instead of --enable-dns, which isn't recognized any more * Fri Nov 20 2009 Nalin Dahyabhai - 1.7-10 - move /etc/pam.d/ksu from krb5-workstation-servers to krb5-workstation, where it's actually needed (#538703) ksh-20091206-1.fc13 ------------------- * Mon Dec 07 2009 Michal Hlavinka - 20091206-1 - updated to 2009-12-06 * Fri Dec 04 2009 Michal Hlavinka - 20091130-1 - updated to 2009-11-30 * Wed Nov 18 2009 Michal Hlavinka - 20091021-1 - updated to 2009-10-21 lapack-3.2.1-4.fc13 ------------------- * Wed Dec 09 2009 Tom "spot" Callaway - 3.2.1-4 - Move static libs to static subpackages (resolves bz 545143) ldapvi-1.7-10.fc13 ------------------ * Mon Dec 07 2009 Mat?j Cepl - 1.7-10 - Improving .spec file to work both on Fedora and RHEL ldns-1.6.3-1.fc13 ----------------- * Fri Dec 04 2009 Paul Wouters - 1.6.3-1 - Upgraded to 1.6.3, which has minor bugfixes * Fri Nov 13 2009 Paul Wouters - 1.6.2-1 - Upgraded to 1.6.2. This fixes various bugs. (upstream released mostly to default with sha2 for the imminent signed root, but we already enabled that in our builds) less-436-3.fc12 --------------- * Wed Dec 09 2009 Nikola Pajkovsky - 436-3 - Resolves: #537746 - Two different descriptions about the default value of LESSBINFMT libatasmart-0.17-2.fc13 ----------------------- * Wed Dec 09 2009 Matthias Clasen - 0.17-2 - Fix an unitialized variable that causes problems in udisks libbase-1.1.3-1.fc13 -------------------- * Thu Dec 03 2009 Caolan McNamara 1.1.3-1 - latest version libcap-2.17-1.fc13 ------------------ * Thu Dec 10 2009 Karsten Hopp 2.17-1 - update to 2.17 libcroco-0.6.2-4.fc13 --------------------- * Tue Dec 08 2009 Matthias Clasen - 0.6.2-4 - Add source url libfac-3.1.0-3.fc13 ------------------- * Tue Dec 08 2009 Michael Schwendt - 3.1.0-3 - Explicitly BR factory-static in accordance with the Packaging Guidelines (factory-devel is still static-only). libfonts-1.1.3-1.fc13 --------------------- * Thu Dec 03 2009 Caolan McNamara 1.1.3-1 - latest version libformula-1.1.3-1.fc13 ----------------------- * Thu Dec 03 2009 Caolan McNamara 1.1.3-1 - latest version libgadu-1.9.0-0.3.rc2.fc13 -------------------------- * Sun Dec 06 2009 Dominik Mierzejewski 1.9.0-0.2.rc2 - updated to 1.9.0-rc2 * Sun Dec 06 2009 Dominik Mierzejewski 1.9.0-0.3.rc2 - disabled OpenSSL support (not used in practice), fixes license trouble for GPL apps libgnomekbd-2.28.0-4.fc13 ------------------------- libgpod-0.7.2-6.fc13 -------------------- * Thu Dec 10 2009 Bastien Nocera 0.7.2-6 - Handle partial UTF-16 strings (#542176) libhangul-0.0.10-1.fc13 ----------------------- * Thu Dec 10 2009 Jens Petersen - 0.0.10-1 - update to 0.0.10 - drop buildroot field and removal libhbalinux-1.0.9-1.20091204git.fc13 ------------------------------------ * Fri Dec 04 2009 Jan Zeleny - 1.0.9-20091204git - rebased to the latest version in upstream git libibcm-1.0.5-1.fc13 -------------------- * Thu Dec 03 2009 Doug Ledford - 1.0.5-1 - Update to latest upstream version libibmad-1.3.3-1.fc13 --------------------- * Thu Dec 03 2009 Doug Ledford - 1.3.3-1 - Update to latest upstream release libibumad-1.3.3-1.fc13 ---------------------- * Thu Dec 03 2009 Doug Ledford - 1.3.3-1 - Update to latest upstream version libibverbs-1.1.3-3.fc13 ----------------------- * Sat Dec 05 2009 Doug Ledford - 1.1.3-3 - Own the /etc/libibverbs.d directory liblayout-0.2.10-1.fc13 ----------------------- * Thu Dec 03 2009 Caolan McNamara 0.2.10-1 - latest version libloader-1.1.3-1.fc13 ---------------------- * Wed Dec 02 2009 Caolan McNamara 1.1.3 - latest version libmlx4-1.0.1-3.fc13 -------------------- * Sat Dec 05 2009 Doug Ledford - 1.0.1-3 - Tweak the provides and obsoletes a little bit to make sure we only pull in the -static package to replace past -devel-static packages, and not past -devel packages. libmthca-1.0.5-6.fc13 --------------------- * Sat Dec 05 2009 Doug Ledford - 1.0.5-6 - Tweak the provides and obsoletes a little bit to make sure we only pull in the -static package to replace past -devel-static packages, and not past -devel packages. libopenraw-0.0.8-1.fc13 ----------------------- * Sat Dec 05 2009 Debarshi Ray - 0.0.8-1 - Version bump to 0.0.8. * Fixed a huge memory leak. (FreeDesktop Bugzilla #21435) * cfa output should write the data in PGM as big endian. * Better handling of Canon CR2 "slices" to fix crasher with Canon 450D/Digital Rebel XSi files (and possibly others). * Added new API or_rawfile_new_from_memory() to load a Raw file from a memory buffer. * Added new API or_rawfile_get_typeid() and the associated consts. * Added new API or_rawdata_get_minmax(). * Added new API or_get_file_extensions(). * Added new API or_rawfile_get_rendered_image() to get a rendered image. * Added new API or_bitmapdata_*(). * New GdkPixbuf loader. * Decompress NEF files. - License changed to LGPLv3 or later. - Missing includes fixed by upstream. - Replaced 'BuildRequires: chrpath glib2-devel' with 'BuildRequires: exempi-devel libcurl-devel'. - Added 'Requires: gtk2' to pixbuf-loader for directory ownership. - Added a %check stanza. libopensync-plugin-synce-0.22.1-3.fc13 -------------------------------------- * Mon Dec 07 2009 Michael Schwendt - 1:0.22.1-3 - Explicitly BR libmimedir-static in accordance with the Packaging Guidelines (libmimedir is still static-only). libpciaccess-0.10.9-2.20091209.fc13 ----------------------------------- * Wed Dec 09 2009 Adam Jackson 0.10.9-2.20091209 - New git snapshot - Drop the fd cache patch libplist-1.0-4.fc13 ------------------- * Mon Dec 07 2009 Peter Robinson 1.0.0-1 - Upstream stable 1.0.0 release * Mon Dec 07 2009 Peter Robinson 1.0.0-2 - Drop upstreamed patch * Mon Dec 07 2009 Peter Robinson 1.0.0-3 - Further updated fixes for the spec file * Mon Dec 07 2009 Peter Robinson 1.0.0-4 - and once more with feeling libpng10-1.0.51-1.fc13 ---------------------- * Thu Dec 03 2009 Paul Howarth 1.0.51-1 - update to 1.0.51 (see ANNOUNCE for details) - update soname patch to apply to 1.0.51 libprelude-0.9.24.1-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.24.1-2 - rebuild against perl 5.10.1 libpreludedb-0.9.15.1-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.15.1-6 - rebuild against perl 5.10.1 librdmacm-1.0.10-1.fc13 ----------------------- * Thu Dec 03 2009 Doug Ledford - 1.0.10-1 - Update to latest upstream release - Change Requires on -devel package (bz533937) librepository-1.1.3-1.fc13 -------------------------- * Wed Dec 02 2009 Caolan McNamara 1.1.3-1 - latest version librra-0.14-3.fc13 ------------------ * Mon Dec 07 2009 Michael Schwendt - 0.14-3 - Explicitly BR libmimedir-static in accordance with the Packaging Guidelines (libmimedir is still static-only). libsexy-0.1.11-15.fc13 ---------------------- * Sat Dec 05 2009 Brian Pepple - 0.1.11-15 - Update url. libtiff-3.9.2-1.fc13 -------------------- * Thu Dec 03 2009 Tom Lane 3.9.2-1 - Update to libtiff 3.9.2; stop carrying a lot of old patches Resolves: #520734 - Split command-line tools into libtiff-tools subpackage Resolves: #515170 - Use build system's libtool instead of what package contains; among other cleanup this gets rid of unwanted rpath specs in executables Related: #226049 libunwind-0.99-0.13.20090430betagit4b8404d1.fc13 ------------------------------------------------ * Fri Dec 04 2009 Fedora Release Engineering - 0.99-0.13.20090430betagit4b8404d1 - The devel package now requires also base package's 0.13.20090430betagit4b8404d1.fc13. - Update the obsolete macro %{package_version}. libvirt-qpid-0.2.17-3.fc12 -------------------------- * Thu Dec 10 2009 Ian Main - 0.2.17-3 - Woops, don't need -lqmfengine. * Thu Nov 05 2009 Ian Main - 0.2.17-2 - Fix libraries for new qpidc in src. libvtemm-0.22.2-1.fc13 ---------------------- * Wed Dec 09 2009 Krzesimir Nowak - 0.22.2-1 - New upstream release. libxklavier-4.0-7.fc13 ---------------------- * Thu Dec 10 2009 Matthias Clasen - 4.0-7 - Catch more X errors liveusb-creator-3.9.1-1.fc13 ---------------------------- * Tue Dec 08 2009 Luke Macken - 3.9.1-1 - 3.9.1 bugfix release lockdev-1.0.3-3.fc13 -------------------- * Thu Dec 10 2009 Jiri Popelka - 1.0.3-2 - Correct rh.patch * Thu Dec 10 2009 Jiri Popelka - 1.0.3-3 - Correct rh.patch * Mon Dec 07 2009 Jiri Popelka - 1.0.3-1 - 1.0.3. No longer need 1.0.0-signal, 1.0.1-subdir, 1.0.1-fcntl, 1.0.1-32bit patches. - Renumbered patches and sources. logstalgia-0.9.2-1.fc13 ----------------------- * Sat Dec 05 2009 Terje R?sten - 0.9.2-1 - 0.9.2 - All patches now upstream lohit-malayalam-fonts-2.4.4-3.fc13 ---------------------------------- * Wed Dec 09 2009 Pravin Satpute - 2.4.4-3 - bugfix 520041 lsscsi-0.23-1.fc13 ------------------ * Sun Dec 06 2009 Dan Hor?k - 0.23-1 - update to 0.23 ltsp-5.1.95-1.fc13 ------------------ * Thu Dec 03 2009 Warren Togami - 5.1.95-1 - Configure Fedora 12 client chroot lxmenu-data-0.1.1-3.fc13 ------------------------ * Sun Dec 06 2009 Christoph Wickert - 0.1.1-3 - Move Accessibility to Utilities lynis-1.2.7-1.fc13 ------------------ * Fri Dec 04 2009 Rakesh Pandit - 1.2.7-1 - Updated to 1.2.7 lyx-1.6.5-2.fc13 ---------------- * Wed Dec 09 2009 Jos? Matos - 1.6.5-1 - lyx-1.6.5 * Wed Dec 09 2009 Jos? Matos - 1.6.5-2 - Add patch for autoconf 2.65 (F13+) m2crypto-0.20.2-3.fc13 ---------------------- * Mon Dec 07 2009 Miloslav Trma? - 0.20.2-3 - Don't use '!# /usr/bin/env python' Resolves: #521887 maatkit-5014-2.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 5014-2 - rebuild against perl 5.10.1 man-pages-3.23-4.fc13 --------------------- * Thu Dec 03 2009 Ivana Hutarova Varekova - 3.23-4 - fix typo in sched_setaffinity(2) patch mapserver-5.6.0-rc1_1.fc13 -------------------------- * Fri Dec 04 2009 Devrim GUNDUZ - 5.6.0-rc1-1 - Update to 5.6.0-rc1, which includes fixes described in: http://trac.osgeo.org/mapserver/browser/tags/rel-5-6-0-rc1/mapserver/HISTORY.TXT mathomatic-15.0.0-1.fc13 ------------------------ * Sat Dec 05 2009 Terje Rosten - 15.0.0-1 - 15.0.0 maxima-5.20.0-1.fc13 -------------------- * Thu Dec 10 2009 Rex Dieter - 5.20.0-1 - maxima-5.20.0 merkaartor-0.14-2.fc13 ---------------------- * Thu Dec 10 2009 Sven Lankes - 0.14-2 - Write log to /dev/null unless specified (bz# 544284) metacity-2.28.0-13.fc13 ----------------------- * Thu Dec 10 2009 Owen Taylor - 2.28.0-12 - Require gnome-themes rather than nodoka-metacity-theme (rhbz 532455, Stijn Hoop) - Add patches for GNOME bugs 445447 - Application-induced window raise fails when raise_on_click off (rhbz 526045) 530702 - compiz doesn't start if metacity compositor is enabled (rhbz 537791) 559816 - Doesn't update keybindings being disabled/cleared (rhbz 532282) 567528 - Cannot raise windows from applications in Tcl/Tk and Java (rhbz 503522) 577576 - Failed to read saved session file warning on new sessions (rhbz 493245) 598231 - When Chromium rings the bell, metacity quits(rhbz 532282) 598995 - Don't focus ancestor window on a different workspace (rhbz 237158) 599097 - For mouse and sloppy focus, return to "mouse mode" on motion (rhbz 530261) 599248 - Add no_focus_windows preference to list windows that shouldn't be focused (rhbz 530262) 599261 - Add a new_windows_always_on_top preference (rhbz 530263) 599262 - Add XFCE Terminal as a terminal 604319 - XIOError unknown display (rhbz 537845) microcode_ctl-1.17-1.56.fc13 ---------------------------- * Wed Dec 02 2009 Kyle McMartin 1.17-1.56 - Add AMD x86/x86-64 microcode. (Dated: 2009-10-09) Doesn't need microcode_ctl modifications as it's loaded by request_firmware() like any other sensible driver. - Eventually, this AMD firmware can probably live inside kernel-firmware once it is split out. * Wed Sep 30 2009 Dave Jones - Update to microcode-20090927.dat * Fri Sep 11 2009 Dave Jones - Remove some unnecessary code from the init script. milter-greylist-4.2.3-1300.fc13 ------------------------------- * Sun Dec 06 2009 Enrico Scholz - 4.2.3-1300 - updated -upstart to upstart 0.6.3 mingw32-cairomm-1.8.4-1.fc13 ---------------------------- * Sat Dec 05 2009 Thomas Sailer - 1.8.4-1 - update to 1.8.44 mingw32-sqlite-3.6.20-1.fc13 ---------------------------- * Sat Dec 05 2009 Thomas Sailer - 3.6.20-1 - update to 3.6.20 mkvtoolnix-2.9.9-1.fc13 ----------------------- * Sun Dec 06 2009 Dominik Mierzejewski 2.9.9-1 - updated to 2.9.9 * new CLI tool: mkvpropedit - fixed compilation of vc1parser moblin-icon-theme-0.10.0-2.fc13 ------------------------------- * Thu Dec 03 2009 Peter Robinson 0.10.0-2 - Fix some issues with the theme moblin-session-0.12-7.fc13 -------------------------- * Thu Dec 10 2009 Peter Robinson 0.12-7 - Start MC5 not MC. Fixes #540693 mod_perl-2.0.4-10.fc13 ---------------------- * Tue Dec 08 2009 Joe Orton - 2.0.4-10 - add security fix for CVE-2009-0796 (#544455) mod_perlite-0.10-2.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-2 - rebuild against perl 5.10.1 mono-sharpcvslib-0.35-14.fc13 ----------------------------- * Thu Dec 03 2009 Tom "spot" Callaway - 0.35-14 - bump it once more for nant monotone-0.45-2.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.45-2 - rebuild against perl 5.10.1 moodle-1.9.7-1.fc13 ------------------- * Tue Dec 08 2009 Jon Ciesla - 1.9.7-1 - Update to 1.9.7, BZ 544766. moserial-2.28.0-2.fc13 ---------------------- * Sat Dec 05 2009 Terje Rosten - 2.28.0-1 - 2.28.0 - Fix file perms * Sat Dec 05 2009 Terje Rosten - 2.28.0-2 - rarian-compat needed to build * Tue Aug 11 2009 Ville Skytt? - 2.27.3-2 - Use bzipped upstream tarball. mr-0.43-2.fc13 -------------- * Mon Dec 07 2009 Stepan Kasal - 0.43-2 - rebuild against perl 5.10.1 msort-8.46-5.fc13 ----------------- * Sun Dec 06 2009 Dominik Mierzejewski - 8.46-5 - rebuilt for new tre mtr-0.75-6.fc13 --------------- * Mon Dec 07 2009 Adam Tkac 2:0.75-6 - install mtr as SUID binary (#518828) - use fprintf instead of perror when getaddrinfo fails (#516603) munin-1.4.1-2.fc13 ------------------ * Wed Dec 09 2009 Ingvar Hagelund - 1.4.1-2 - Remove jmx plugins when not supported (like on el4 and older fedora) - Correct font path on older distros like el5, el4 and fedora<11 * Fri Dec 04 2009 Kevin Fenzi - 1.4.1-1 - Update to 1.4.1 myproxy-5.0-1.fc13 ------------------ * Fri Dec 04 2009 Steve Traylen - 5.0-1 - Add globus-globus-usage-location.patch https://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=6897 - Addition of globus-usage-devel to BR. - New upstream 5.0 - Upstream source hosting changed from globus to sourceforge. mysql-connector-java-5.1.8-2.fc13 --------------------------------- * Fri Dec 04 2009 Mary Ellen Foster - 1:5.1.8-2 - Add Maven POM and depmap fragment nagios-3.2.0-3.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 3.2.0-3 - rebuild against perl 5.10.1 nant-0.85-33.fc13 ----------------- nautilus-2.28.2-3.fc13 ---------------------- * Thu Dec 10 2009 Jon McCann - 2.28.2-3 - Update the monitor changes patch (gnome #147808) * Tue Dec 08 2009 Tomas Bzatek - 2.28.2-2 - Fix some memory leaks ncftp-3.2.3-1.fc13 ------------------ * Tue Dec 08 2009 Matthias Saou 2:3.2.3-1 - Update to 3.2.3. - Rebase the ncursesw patch. - Remove no longer required no_lfs64_source patch. ncl-5.1.1-5.fc13 ---------------- * Tue Dec 08 2009 Michael Schwendt - 5.1.1-5 - Same as below with hdf-static - Explicitly BR g2clib-static in accordance with the Packaging Guidelines (g2clib-devel is still static-only). nemiver-0.7.3-1.fc13 -------------------- * Sun Dec 06 2009 Dodji Seketeli - 0.7.3-1 - Update to new upstream release (0.7.3) net-snmp-5.5-6.fc13 ------------------- * Tue Dec 08 2009 Jan Safranek - 1:5.5-6 - fix compilation of the python module * Mon Dec 07 2009 Stepan Kasal - 1:5.5-5 - rebuild against perl 5.10.1 * Wed Dec 02 2009 Jan Safranek 1:5.5-4 - fix udpTable indexes on big-endian systems (#543352) - fix snmptrapd init script to survive with empty /etc/sysconfig/snmptrapd - lower the default log level of snmpd to get rid of the debug messages net-tools-1.60-99.fc13 ---------------------- * Thu Dec 03 2009 Jiri Popelka - 1.60-99 - return defining of BuildRoot even it's no longer necessary (https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag) to silent rpmlint false warning netcdf-4.1.0-0.7.2009120100.fc13 -------------------------------- * Sat Dec 05 2009 Orion Poplawski - 4.1.0-0.7.2009120100 - Leave include files in /usr/include netcdf-perl-1.2.4-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.2.4-4 - rebuild against perl 5.10.1 netpbm-10.47.05-1.fc13 ---------------------- * Thu Dec 10 2009 Jindrich Novy 10.47.05-1 - update to 10.47.05 - fixes pnmtofiasco, fiascotopnm, pamtosvg, pamtouil and ppmrainbow - upstream fix to pamtosvg caused netpbm not to be rebuildable on any arch because of missing semicolon, the fix is now fixed :-/ * Mon Dec 07 2009 Jindrich Novy 10.47.04-3 - fix segfault in pnmsmooth (#545089) network-manager-netbook-1.7.0-0.1.fc13 -------------------------------------- * Thu Dec 10 2009 Peter Robinson 1.7.0-0.1 - Update to new n-m-n git head, add bluetooth support * Fri Dec 04 2009 Peter Robinson 1.3.1-0.6 - Update n-m-n desktop file patch nfs-utils-1.2.1-6.fc13 ---------------------- * Thu Dec 10 2009 Steve Dickson 1.2.1-6 - Update the pseudo root to handle security flavors better. * Mon Dec 07 2009 Steve Dickson 1.2.1-4 - Updated to the latest pseudo root release (rel9) (bz 538609). * Mon Dec 07 2009 Steve Dickson 1.2.1-5 - mount.nfs: Retry v4 mounts with v3 on ENOENT errors nginx-0.7.64-1.fc13 ------------------- * Fri Dec 04 2009 Jeremy Hinegardner - 0.7.64-1 - Update to new stable 0.7.64 ngspice-20-3.fc13 ----------------- * Tue Dec 08 2009 Chitlesh Goorah 20-2 - Improved interoperobability with xcircuit * Tue Dec 08 2009 Chitlesh Goorah 20-3 - Fixed build on CentOS-5 * Mon Nov 16 2009 Chitlesh Goorah 20-1 - new upstream release nkf-2.0.8b-7.fc13 ----------------- * Mon Dec 07 2009 Stepan Kasal - 1:2.0.8b-7 - rebuild against perl 5.10.1 nspluginwrapper-1.3.0-10.fc13 ----------------------------- * Fri Dec 04 2009 Martin Stransky 1.3.0-10 - added Compiz workaround (#542424) nss-3.12.5-1.fc13.4 ------------------- * Wed Dec 09 2009 Elio Maldonado - 3.12.5-2.1 - Remove unneeded patch * Thu Dec 03 2009 Elio Maldonado - 3.12.5-1 - Update to 3.12.5 - Patch to allow ssl/tls clients to interoperate with servers that require renogiation * Thu Dec 03 2009 Elio Maldonado - 3.12.5-1.1 - Retagging to include missing patch nss-util-3.12.5-1.fc13 ---------------------- * Thu Dec 03 2009 Elio Maldonado - 3.12.5-1 - Update to 3.12.5 nted-1.9.10-1.fc13 ------------------ * Fri Dec 04 2009 Hans Ulrich Niedermann - 1.9.10-1 - Update to 1.9.10 ntp-4.2.4p8-1.fc13 ------------------ * Wed Dec 09 2009 Miroslav Lichvar 4.2.4p8-1 - update to 4.2.4p8 (#545557, CVE-2009-3563) obexd-0.20-1.fc13 ----------------- * Wed Dec 09 2009 Bastien Nocera 0.20-1 - Update to 0.20 obexftp-0.23-3.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-3 - rebuild against perl 5.10.1 olpc-switch-desktop-0.7-2.fc13 ------------------------------ * Wed Dec 09 2009 Daniel Drake - 0.7-1 - Updated translations * Wed Dec 09 2009 Daniel Drake - 0.7-2 - build requires intltool olpc-utils-1.0.13-2.fc13 ------------------------ * Wed Dec 09 2009 Bill Nottingham - 1.0.13-2 - adjust for upstart 0.6 * Fri Dec 04 2009 Daniel Drake - 1.0.13-1 - Bump to v1.0.13 openais-1.1.1-1.fc13 -------------------- * Fri Dec 04 2009 Fabio M. Di Nitto - 1.1.1-1 - New upstream release. - spec file updates: * Cleanup macro usage * Drop Conflict: in favour of correct Requires: * Whitespace cleanup openbox-3.4.8-1.fc13 -------------------- * Thu Dec 10 2009 Miroslav Lichvar - 3.4.8-1 - Update to 3.4.8 - Fix crash in xdg-autostart on desktop files with TryExec (#544006) openconnect-2.12-1.fc13 ----------------------- * Mon Dec 07 2009 David Woodhouse - 2.12-1 - Update to 2.12. opencv-2.0.0-2.fc13 ------------------- * Sun Dec 06 2009 Ha?kel Gu?mar - 2.0.0-2 - Fix autotools scripts (missing LBP features) - #544167 openjade-1.3.2-36.fc13 ---------------------- * Thu Dec 10 2009 Ondrej Vasik 1.3.2-36 - Merge Review (#226213) - added url, fixed rpmlint warnings, no macros in changelog openoffice.org-3.2.0-7.2.fc13 ----------------------------- * Wed Dec 09 2009 Caol?n McNamara - 1:3.2.0-7.2 - Resolves: rhbz#544124 add openoffice.org-3.2.0.ooo106502.svx.fixspelltimer.patch - Resolves: rhbz#544218 add openoffice.org-3.2.0.ooo107552.vcl.sft.patch * Thu Dec 03 2009 Caol?n McNamara - 1:3.2.0-6.4 - Resolves: rhbz#543934 drop "kid" pseudo-translations * Thu Dec 03 2009 Caol?n McNamara - 1:3.2.0-7.1 - latest milestone opensc-0.11.11-2.fc13 --------------------- * Tue Dec 08 2009 Michael Schwendt - 0.11.11-2 - Explicitly BR libassuan-static in accordance with the Packaging Guidelines (libassuan-devel is still static-only). opensm-3.3.3-1.fc13 ------------------- * Thu Dec 03 2009 Doug Ledford - 3.3.3-1 - Update to latest upstream release - Minor tweaks to init script for LSB compliance openssh-5.3p1-12.fc13 --------------------- * Fri Dec 04 2009 Jan F. Chadima - 5.3p1-12 - Add possibility to autocreate only RSA key into initscript (#533339) orca-2.29.2-1.fc13 ------------------ * Sat Dec 05 2009 Matthias Clasen - 2.29.2-1 - Update to 2.29.2 osslsigncode-1.3.1-1.fc13 ------------------------- * Tue Dec 08 2009 Matthias Saou 1.3.1-1 - Update to 1.3.1. oxygen-icon-theme-4.3.80-1.fc13 ------------------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) p0rn-comfort-0.0.4-9.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.0.4-9 - rebuild against perl 5.10.1 p7zip-9.04-1.fc13 ----------------- * Tue Dec 08 2009 Matthias Saou 9.04-1 - Update to 9.04. - Update norar patch. pacemaker-1.0.5-5.fc13 ---------------------- * Wed Dec 09 2009 Andrew Beekhof - 1.0.5-5 - Include patch of changeset 66b7bfd467f3: Some clients such as gfs_controld want a cluster name, allow one to be specified in corosync.conf pango-1.26.1-1.fc13 ------------------- * Thu Dec 03 2009 Behdad Esfahbod - 1.26.1-1 - 1.26.1 papi-3.7.2-3.fc13 ----------------- * Thu Dec 10 2009 William Cohen - 3.7.2-3 - Adjust configure. * Wed Dec 09 2009 William Cohen - 3.7.2-1 - Import papi-3.7.2. * Wed Dec 09 2009 William Cohen - 3.7.2-2 - Remove dependency on kernel-devel. * Thu Nov 19 2009 William Cohen - 3.7.1-4 - Exclude s390 and s390x. paps-0.6.8-12.fc13 ------------------ * Tue Dec 08 2009 Akira TAGOH - 0.6.8-12 - Add paps.convs to behaves the cups filter without the hardcoded thing in cups. (#545031) papyrus-0.13.1-1.fc13 --------------------- * Wed Dec 09 2009 Rick L Vinyard Jr - 0.13.1-1 - New release pcb-0.20091103-2.fc13 --------------------- * Sun Dec 06 2009 Chitlesh Goorah - 0.20091103-2 - Enable build for dbus support - improved reference card pcsc-perl-1.4.8-2.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4.8-2 - rebuild against perl 5.10.1 pentaho-libxml-1.1.3-1.fc13 --------------------------- * Thu Dec 03 2009 Caolan McNamara 1.1.3 - latest version pentaho-reporting-flow-engine-0.9.4-1.fc13 ------------------------------------------ * Thu Dec 03 2009 Caolan McNamara 0.9.4-1 - latest version perl-5.10.1-104.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 4:5.10.1-103 - do not pack Bzip2 modules (#544582) - hack: cheat about Compress::Raw::Zlib version (#544582) * Mon Dec 07 2009 Stepan Kasal - 4:5.10.1-104 - do not pack Bzip2 manpages either (#544582) * Thu Dec 03 2009 Stepan Kasal - 4:5.10.1-101 - be more careful with the libperl.so compatibility symlink (#543936) * Thu Dec 03 2009 Stepan Kasal - 4:5.10.1-102 - switch off check for ppc64 and s390x - remove the hack for "make test," it is no longer needed * Wed Dec 02 2009 Stepan Kasal - 4:5.10.1-100 - new upstream version - release number must be high, because of stale version numbers of some of the subpackages - drop upstreamed patches - update the versions of bundled modules - shorten the paths in @INC - build without DEBUGGING - implement compatibility measures for the above two changes, for a short transition period - provide perl(:MODULE_COMPAT_5.10.0), for that transition period only perl-Ace-1.92-4.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 1.92-4 - rebuild against perl 5.10.1 perl-Acme-Damn-0.04-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-Acme-PlayCode-0.11-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Affix-Infix2Postfix-0.03-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-Algorithm-Annotate-0.10-9.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-9 - rebuild against perl 5.10.1 perl-Algorithm-C3-0.08-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-Algorithm-CheckDigits-0.50-4.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.50-4 - rebuild against perl 5.10.1 perl-Algorithm-CurveFit-1.03-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-5 - rebuild against perl 5.10.1 perl-Algorithm-Dependency-1.110-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.110-3 - rebuild against perl 5.10.1 perl-Algorithm-Diff-1.1902-9.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1902-9 - rebuild against perl 5.10.1 perl-Algorithm-FastPermute-0.999-5.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.999-5 - rebuild against perl 5.10.1 perl-Algorithm-IncludeExclude-0.01-3.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-3 - rebuild against perl 5.10.1 perl-Algorithm-Merge-0.08-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-Algorithm-Permute-0.12-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-4 - rebuild against perl 5.10.1 perl-Alien-SeleniumRC-1.01-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-2 - rebuild against perl 5.10.1 * Tue Sep 15 2009 Emmanuel Seyman - 1.01-1 - Update to 1.01 perl-Alien-wxWidgets-0.44-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.44-3 - rebuild against perl 5.10.1 perl-Any-Moose-0.10-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-2 - rebuild against perl 5.10.1 perl-AnyData-0.10-9.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.10-9 - rebuild against perl 5.10.1 perl-AnyEvent-5.22-1.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 5.11-3 - rebuild against perl 5.10.1 * Mon Dec 07 2009 Nicolas Chauvet - 5.22-1 - Update to 5.22 (rpm version : 5.22) perl-AnyEvent-AIO-1.1-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-3 - rebuild against perl 5.10.1 perl-AnyEvent-BDB-1.1-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-2 - rebuild against perl 5.10.1 perl-Apache-DBI-1.07-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-4 - rebuild against perl 5.10.1 perl-Apache-DBI-Cache-0.08-4.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-4 - rebuild against perl 5.10.1 perl-Apache-Htpasswd-1.8-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.8-4 - rebuild against perl 5.10.1 perl-Apache-LogRegex-1.5-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.5-4 - rebuild against perl 5.10.1 perl-Apache-Session-1.88-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.88-3 - rebuild against perl 5.10.1 perl-Apache-Session-Wrapper-0.33-6.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33-6 - rebuild against perl 5.10.1 perl-Apache2-SOAP-0.73-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.73-4 - rebuild against perl 5.10.1 perl-App-Asciio-1.02.71-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.02.71-5 - rebuild against perl 5.10.1 perl-App-CLI-0.07-7.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.07-7 - rebuild against perl 5.10.1 perl-App-Cache-0.36-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.36-2 - rebuild against perl 5.10.1 perl-App-Cmd-0.301-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.301-2 - rebuild against perl 5.10.1 perl-App-Daemon-0.08-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-2 - rebuild against perl 5.10.1 perl-App-Nopaste-0.17-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.17-2 - rebuild against perl 5.10.1 perl-AppConfig-1.66-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.66-6 - rebuild against perl 5.10.1 perl-AppConfig-Std-1.07-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.07-5 - rebuild against perl 5.10.1 perl-Archive-Any-0.0932-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.0932-3 - rebuild against perl 5.10.1 perl-Archive-RPM-0.04-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-Archive-Zip-1.30-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.30-2 - rebuild against perl 5.10.1 perl-Array-Compare-2.01-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.01-2 - rebuild against perl 5.10.1 perl-Array-Diff-0.05002-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05002-3 - rebuild against perl 5.10.1 perl-Array-RefElem-1.00-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.00-5 - rebuild against perl 5.10.1 perl-Astro-FITS-CFITSIO-1.05-7.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-7 - rebuild against perl 5.10.1 perl-Async-MergePoint-0.03-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-2 - rebuild against perl 5.10.1 perl-Authen-Captcha-1.023-5.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.023-5 - rebuild against perl 5.10.1 perl-Authen-DigestMD5-0.04-8.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-8 - rebuild against perl 5.10.1 perl-Authen-Krb5-1.7-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.7-8 - rebuild against perl 5.10.1 perl-Authen-Krb5-Admin-0.11-5.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Authen-PAM-0.16-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-8 - rebuild against perl 5.10.1 perl-Authen-Radius-0.13-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.13-6 - rebuild against perl 5.10.1 perl-Authen-SASL-2.13-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.13-2 - rebuild against perl 5.10.1 perl-Authen-Simple-0.4-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.4-2 - rebuild against perl 5.10.1 perl-AutoClass-1_01-10.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1_01-10 - rebuild against perl 5.10.1 perl-AutoXS-Header-1.02-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.02-3 - rebuild against perl 5.10.1 perl-B-Hooks-EndOfScope-0.08-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-B-Hooks-OP-Check-0.17-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.17-3 - rebuild against perl 5.10.1 perl-B-Hooks-OP-Check-StashChange-0.06-3.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-3 - rebuild against perl 5.10.1 perl-B-Keywords-1.09-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-4 - rebuild against perl 5.10.1 perl-B-Utils-0.08-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.08-2 - rebuild against perl 5.10.1 perl-BDB-1.86-2.fc13 -------------------- * Tue Dec 08 2009 Nicolas Chauvet - 1.86-2 - Patch to force db 4.8. * Mon Dec 07 2009 Stepan Kasal - 1.84-2 - rebuild against perl 5.10.1 * Mon Dec 07 2009 Nicolas Chauvet - 1.86-1 - Update to 1.86 perl-BSD-Resource-1.29.03-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.29.03-3 - rebuild against perl 5.10.1 * Thu Oct 29 2009 Stepan Kasal - 1.29.03-2 - bump release perl-BZ-Client-1.02-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-2 - rebuild against perl 5.10.1 perl-Beanstalk-Client-1.05-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-3 - rebuild against perl 5.10.1 perl-BerkeleyDB-0.39-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.39-2 - rebuild against perl 5.10.1 perl-Best-0.12-3.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-3 - rebuild against perl 5.10.1 perl-Bio-ASN1-EntrezGene-1.091-9.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.091-9 - rebuild against perl 5.10.1 perl-Bio-Graphics-1.97-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.97-3 - rebuild against perl 5.10.1 perl-Bit-Vector-7.1-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 7.1-2 - rebuild against perl 5.10.1 perl-Boulder-1.30-8.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.30-8 - rebuild against perl 5.10.1 perl-Business-CreditCard-0.30-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.30-4 - rebuild against perl 5.10.1 perl-Business-Hours-0.09-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-4 - rebuild against perl 5.10.1 perl-Business-ISBN-2.05-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.05-2 - rebuild against perl 5.10.1 perl-Business-ISBN-Data-20081208-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 20081208-2 - rebuild against perl 5.10.1 perl-CGI-Ajax-0.707-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.707-4 - rebuild against perl 5.10.1 perl-CGI-Application-4.31-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.31-2 - rebuild against perl 5.10.1 perl-CGI-Application-Dispatch-2.16-3.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.16-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-AutoRunmode-0.16-4.fc13 --------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-4 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-ConfigAuto-1.31-2.fc13 -------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.31-2 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-DBH-4.00-3.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.00-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-DBIC-Schema-0.3-2.fc13 -------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3-2 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-DBIx-Class-0.093011-3.fc13 ------------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.093011-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-DebugScreen-0.06-3.fc13 --------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-DevPopup-1.03-2.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.03-2 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-ErrorPage-1.21-4.fc13 ------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.21-4 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-FillInForm-1.15-3.fc13 -------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.15-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-Forward-1.06-3.fc13 ----------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-LogDispatch-1.02-3.fc13 --------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-Redirect-1.00-3.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.00-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-Session-1.03-3.fc13 ----------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-Stream-2.10-3.fc13 ---------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.10-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-SuperForm-0.4-3.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.4-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-TT-1.04-3.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.04-3 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-ValidateRM-2.3-4.fc13 ------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.3-4 - rebuild against perl 5.10.1 perl-CGI-Application-Plugin-ViewCode-1.02-3.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.02-3 - rebuild against perl 5.10.1 perl-CGI-Application-Server-0.061-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.061-3 - rebuild against perl 5.10.1 perl-CGI-Application-Standard-Config-1.01-3.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-3 - rebuild against perl 5.10.1 perl-CGI-Application-Structured-0.003-2.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.003-2 - rebuild against perl 5.10.1 perl-CGI-Ex-2.27-3.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 2.27-3 - rebuild against perl 5.10.1 perl-CGI-FastTemplate-1.09-7.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-7 - rebuild against perl 5.10.1 perl-CGI-FormBuilder-3.0501-8.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.0501-8 - rebuild against perl 5.10.1 perl-CGI-Prototype-0.9053-8.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9053-8 - rebuild against perl 5.10.1 perl-CGI-Session-4.35-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.35-4 - rebuild against perl 5.10.1 perl-CGI-Simple-1.108-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.108-3 - rebuild against perl 5.10.1 perl-CGI-SpeedyCGI-2.22-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.22-7 - rebuild against perl 5.10.1 perl-CGI-Untaint-1.26-8.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.26-8 - rebuild against perl 5.10.1 perl-CGI-Untaint-date-1.00-8.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-8 - rebuild against perl 5.10.1 perl-CGI-Untaint-email-0.03-8.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-8 - rebuild against perl 5.10.1 perl-CSS-Minifier-0.01-3.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.01-3 - rebuild against perl 5.10.1 perl-CSS-Tiny-1.15-4.fc13 ------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.15-4 - rebuild against perl 5.10.1 perl-Cache-2.04-6.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 2.04-6 - rebuild against perl 5.10.1 perl-Cache-Cache-1.06-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-3 - rebuild against perl 5.10.1 perl-Cache-FastMmap-1.34-4.fc13 ------------------------------- * Tue Dec 08 2009 Iain Arnell 1.34-4 - drop failing leak test (rt #39342) * Mon Dec 07 2009 Stepan Kasal - 1.34-3 - rebuild against perl 5.10.1 perl-Cache-Memcached-1.28-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.28-2 - rebuild against perl 5.10.1 perl-Cache-Mmap-0.11-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-4 - rebuild against perl 5.10.1 perl-Cache-Simple-TimedExpiry-0.27-7.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.27-7 - rebuild against perl 5.10.1 perl-Cairo-1.060-3.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.060-3 - rebuild against perl 5.10.1 perl-Calendar-Simple-1.20-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.20-4 - rebuild against perl 5.10.1 perl-Callback-1.07-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-5 - rebuild against perl 5.10.1 perl-Captcha-reCAPTCHA-0.92-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-4 - rebuild against perl 5.10.1 perl-Capture-Tiny-0.06-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-Carp-Assert-0.20-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.20-5 - rebuild against perl 5.10.1 perl-Carp-Assert-More-1.12-7.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-7 - rebuild against perl 5.10.1 perl-Carp-Clan-6.03-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 6.03-2 - rebuild against perl 5.10.1 perl-Carp-Clan-Share-0.013-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.013-3 - rebuild against perl 5.10.1 perl-Catalyst-Action-RenderView-0.13-2.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.13-1 - auto-update to 0.13 (by cpan-spec-update 0.01) perl-Catalyst-Authentication-Store-DBIx-Class-0.1082-5.fc13 ----------------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.1082-5 - rebuild against perl 5.10.1 perl-Catalyst-Component-InstancePerContext-0.001001-4.fc13 ---------------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.001001-4 - rebuild against perl 5.10.1 perl-Catalyst-Controller-BindLex-0.05-4.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-Catalyst-Controller-FormBuilder-0.05-4.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-Catalyst-Controller-HTML-FormFu-0.06000-1.fc13 --------------------------------------------------- * Wed Dec 09 2009 Iain Arnell 0.06000-1 - update to latest upstream version * Mon Dec 07 2009 Stepan Kasal - 0.05000-3 - rebuild against perl 5.10.1 perl-Catalyst-Devel-1.20-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.20-2 - rebuild against perl 5.10.1 perl-Catalyst-Engine-Apache-1.12-5.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-5 - rebuild against perl 5.10.1 perl-Catalyst-Helper-FastCGI-ExternalServer-0.05-3.fc13 ------------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-Catalyst-Log-Log4perl-1.04-2.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-2 - rebuild against perl 5.10.1 perl-Catalyst-Manual-5.8002-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:5.8002-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 5.8002-1 - auto-update to 5.8002 (by cpan-spec-update 0.01) perl-Catalyst-Model-DBIC-Schema-0.23-3.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-3 - rebuild against perl 5.10.1 perl-Catalyst-Model-LDAP-0.16-7.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.16-7 - rebuild against perl 5.10.1 perl-Catalyst-Model-XMLRPC-0.04-6.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-6 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Authorization-ACL-0.15-2.fc13 -------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Authorization-Roles-0.07-4.fc13 ---------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-4 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-CGI-Untaint-0.05-7.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-7 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Cache-0.08-4.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-4 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-ConfigLoader-0.27-2.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.27-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Email-0.08-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-I18N-0.09-4.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-4 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-PageCache-0.22-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.22-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Session-0.29-2.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.29-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.29-1 - auto-update to 0.29 (by cpan-spec-update 0.01) - added a new req on perl(Test::More) (version 0) perl-Catalyst-Plugin-Session-State-Cookie-0.17-2.fc13 ----------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.17-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.17-1 - auto-update to 0.17 (by cpan-spec-update 0.01) - altered br on perl(Catalyst::Plugin::Session) (0.19 => 0.27) - altered req on perl(Catalyst::Plugin::Session) (0.19 => 0.27) perl-Catalyst-Plugin-Session-State-URI-0.13-2.fc13 -------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Session-Store-Cache-0.01-2.fc13 ---------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Session-Store-FastMmap-0.12-2.fc13 ------------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Session-Store-File-0.18-2.fc13 --------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-2 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Setenv-0.03-3.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-3 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-Singleton-0.02-3.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.02-3 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-StackTrace-0.10-3.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-3 - rebuild against perl 5.10.1 perl-Catalyst-Plugin-SubRequest-0.15-2.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.15-1 - add default filtering - auto-update to 0.15 (by cpan-spec-update 0.01) - added a new br on perl(Catalyst::Runtime) (version 5.7012) - altered br on perl(ExtUtils::MakeMaker) (0 => 6.42) perl-Catalyst-Plugin-Unicode-0.92-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-3 - rebuild against perl 5.10.1 perl-Catalyst-View-Email-0.13-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.13-3 - rebuild against perl 5.10.1 perl-Catalyst-View-JSON-0.26-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26-2 - rebuild against perl 5.10.1 perl-Catalyst-View-Mason-0.18-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.18-2 - rebuild against perl 5.10.1 perl-Catalyst-View-PDF-Reuse-0.03-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-3 - rebuild against perl 5.10.1 perl-Catalyst-View-TT-0.31-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.31-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.31-1 - auto-update to 0.31 (by cpan-spec-update 0.01) perl-CatalystX-Component-Traits-0.14-2.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-2 - rebuild against perl 5.10.1 * Sun Dec 06 2009 Chris Weyl 0.14-1 - auto-update to 0.14 (by cpan-spec-update 0.01) - altered br on perl(Test::More) (0 => 0.88) - added a new req on perl(List::MoreUtils) (version 0) - added a new req on perl(Scalar::Util) (version 0) - added a new req on perl(namespace::autoclean) (version 0) perl-Cflow-1.053-12.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.053-12 - rebuild against perl 5.10.1 perl-Chart-2.4.1-9.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 2.4.1-9 - rebuild against perl 5.10.1 perl-Chatbot-Eliza-1.04-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.04-7 - rebuild against perl 5.10.1 perl-Check-ISA-0.04-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-5 - rebuild against perl 5.10.1 perl-Class-Accessor-0.34-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.34-2 - rebuild against perl 5.10.1 perl-Class-Accessor-Chained-0.01-10.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-10 - rebuild against perl 5.10.1 perl-Class-Accessor-Grouped-0.09000-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09000-2 - rebuild against perl 5.10.1 perl-Class-Adapter-1.06-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.06-2 - rebuild against perl 5.10.1 perl-Class-Autouse-1.29-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.29-7 - rebuild against perl 5.10.1 perl-Class-Base-0.03-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Class-C3-0.21-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.21-3 - rebuild against perl 5.10.1 perl-Class-C3-Adopt-NEXT-0.12-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.12-3 - rebuild against perl 5.10.1 perl-Class-C3-Componentised-1.0006-2.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0006-2 - rebuild against perl 5.10.1 perl-Class-C3-XS-0.13-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 perl-Class-CSV-1.03-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-6 - rebuild against perl 5.10.1 perl-Class-Can-0.01-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-4 - rebuild against perl 5.10.1 perl-Class-Container-0.12-10.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-10 - rebuild against perl 5.10.1 perl-Class-DBI-3.0.17-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.0.17-6 - rebuild against perl 5.10.1 perl-Class-DBI-AbstractSearch-0.07-8.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-8 - rebuild against perl 5.10.1 perl-Class-DBI-AsForm-2.42-10.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.42-10 - rebuild against perl 5.10.1 perl-Class-DBI-FromCGI-1.00-7.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-7 - rebuild against perl 5.10.1 perl-Class-DBI-Loader-0.34-6.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.34-6 - rebuild against perl 5.10.1 perl-Class-DBI-Loader-Relationship-1.3-11.fc13 ---------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.3-11 - rebuild against perl 5.10.1 perl-Class-DBI-Pager-0.08-7.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-7 - rebuild against perl 5.10.1 perl-Class-DBI-Pg-0.09-8.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-8 - rebuild against perl 5.10.1 perl-Class-DBI-Plugin-0.03-10.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-10 - rebuild against perl 5.10.1 perl-Class-DBI-Plugin-DeepAbstractSearch-0.08-3.fc13 ---------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-Class-DBI-Plugin-RetrieveAll-1.04-7.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-7 - rebuild against perl 5.10.1 perl-Class-DBI-Plugin-Type-0.02-10.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-10 - rebuild against perl 5.10.1 perl-Class-DBI-SQLite-0.11-8.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-8 - rebuild against perl 5.10.1 perl-Class-DBI-mysql-1.00-8.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-8 - rebuild against perl 5.10.1 perl-Class-Data-Accessor-0.04004-5.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04004-5 - rebuild against perl 5.10.1 perl-Class-Data-Inheritable-0.08-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-4 - rebuild against perl 5.10.1 perl-Class-Date-1.1.9-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1.9-7 - rebuild against perl 5.10.1 perl-Class-ErrorHandler-0.01-8.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-8 - rebuild against perl 5.10.1 perl-Class-Exporter-0.03-5.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-Class-Factory-1.06-4.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 1.06-4 - rebuild against perl 5.10.1 perl-Class-Factory-Util-1.7-6.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.7-6 - rebuild against perl 5.10.1 perl-Class-Inner-0.1-9.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.1-9 - rebuild against perl 5.10.1 perl-Class-Inspector-1.24-4.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.24-4 - rebuild against perl 5.10.1 perl-Class-Loader-2.03-9.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.03-9 - rebuild against perl 5.10.1 perl-Class-MOP-0.94-2.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.94-2 - rebuild against perl 5.10.1 perl-Class-MakeMethods-1.01-6.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.01-6 - rebuild against perl 5.10.1 perl-Class-Method-Modifiers-1.04-2.fc13 --------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.04-2 - rebuild against perl 5.10.1 perl-Class-MethodMaker-2.15-3.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.15-3 - rebuild against perl 5.10.1 perl-Class-Mix-0.003-3.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.003-3 - rebuild against perl 5.10.1 perl-Class-Observable-1.04-7.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.04-7 - rebuild against perl 5.10.1 perl-Class-Prototyped-1.11-5.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.11-5 - rebuild against perl 5.10.1 perl-Class-ReturnValue-0.55-5.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.55-5 - rebuild against perl 5.10.1 perl-Class-Singleton-1.4-6.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.4-6 - rebuild against perl 5.10.1 perl-Class-Std-0.0.8-6.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.0.8-6 - rebuild against perl 5.10.1 perl-Class-Throwable-0.10-4.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.10-4 - rebuild against perl 5.10.1 perl-Class-Unload-0.05-5.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-Class-Whitehole-0.04-8.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-8 - rebuild against perl 5.10.1 perl-Class-XSAccessor-1.05-2.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.05-2 - rebuild against perl 5.10.1 perl-Config-Model-CursesUI-1.103-3.fc11 --------------------------------------- perl-Crypt-SSLeay-0.57-16.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.57-16 - rebuild against perl 5.10.1 perl-Crypt-Twofish-2.13-3.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 2.13-3 - rebuild against perl 5.10.1 perl-Curses-1.27-3.fc13 ----------------------- * Fri Dec 04 2009 Stepan Kasal - 1.27-3 - rebuild against perl 5.10.1 perl-Curses-UI-0.9607-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9607-3 - rebuild against perl 5.10.1 perl-DBD-AnyData-0.09-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-6 - rebuild against perl 5.10.1 perl-DBD-CSV-0.22-9.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.22-9 - rebuild against perl 5.10.1 perl-DBD-Mock-1.39-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.39-4 - rebuild against perl 5.10.1 perl-DBD-Multi-0.14-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-5 - rebuild against perl 5.10.1 perl-DBD-MySQL-4.013-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.013-3 - rebuild against perl 5.10.1 perl-DBD-Pg-2.15.1-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.15.1-2 - rebuild against perl 5.10.1 perl-DBD-SQLite-1.27-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.27-2 - rebuild against perl 5.10.1 perl-DBD-SQLite2-0.33-13.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33-13 - rebuild against perl 5.10.1 perl-DBD-XBase-0.241-10.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.241-10 - rebuild against perl 5.10.1 perl-DBI-1.609-4.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1.609-4 - rebuild against perl 5.10.1 perl-DBICx-TestDatabase-0.02-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-DBIx-Class-DateTime-Epoch-0.05-5.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-DBIx-Class-DynamicDefault-0.03-4.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-DBIx-Class-EncodedColumn-0.00005-2.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.00005-2 - rebuild against perl 5.10.1 perl-DBIx-Class-Schema-Loader-0.04006-6.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04006-6 - rebuild against perl 5.10.1 perl-DBIx-Class-TimeStamp-0.12-2.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-DBIx-ContextualFetch-1.03-8.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-8 - rebuild against perl 5.10.1 perl-DBIx-DBSchema-0.36-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.36-5 - rebuild against perl 5.10.1 perl-DBIx-POS-0.03-8.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-8 - rebuild against perl 5.10.1 perl-DBIx-Safe-1.2.5-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.2.5-7 - rebuild against perl 5.10.1 perl-DBIx-SearchBuilder-1.56-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.56-2 - rebuild against perl 5.10.1 perl-DBM-Deep-0.983-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.983-6 - rebuild against perl 5.10.1 perl-DDL-Oracle-1.11-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.11-4 - rebuild against perl 5.10.1 perl-Daemon-Generic-0.61-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.61-3 - rebuild against perl 5.10.1 perl-Danga-Socket-1.58-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.58-4 - rebuild against perl 5.10.1 perl-Data-Alias-1.07-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-6 - rebuild against perl 5.10.1 perl-Data-AsObject-0.05-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-Data-Buffer-0.04-9.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-9 - rebuild against perl 5.10.1 perl-Data-Compare-1.21-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.21-4 - rebuild against perl 5.10.1 perl-Data-Denter-0.15-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-3 - rebuild against perl 5.10.1 perl-Data-Dump-1.15-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.15-2 - rebuild against perl 5.10.1 perl-Data-Dump-Streamer-2.09-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.09-4 - rebuild against perl 5.10.1 perl-Data-Dumper-Names-0.03-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Data-FormValidator-4.63-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.63-3 - rebuild against perl 5.10.1 perl-Data-FormValidator-Constraints-DateTime-1.09-3.fc13 -------------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-3 - rebuild against perl 5.10.1 perl-Data-HexDump-0.02-7.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-7 - rebuild against perl 5.10.1 perl-Data-Hierarchy-0.34-7.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.34-7 - rebuild against perl 5.10.1 perl-Data-ICal-0.16-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-2 - rebuild against perl 5.10.1 perl-Data-ObjectDriver-0.06-5.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-5 - rebuild against perl 5.10.1 perl-Data-OptList-0.104-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.104-4 - rebuild against perl 5.10.1 perl-Data-Page-2.01-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.01-3 - rebuild against perl 5.10.1 perl-Data-Password-1.07-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.07-6 - rebuild against perl 5.10.1 perl-Data-Report-0.10-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-4 - rebuild against perl 5.10.1 perl-Data-Section-0.091820-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.091820-3 - rebuild against perl 5.10.1 perl-Data-Stag-0.11-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-4 - rebuild against perl 5.10.1 perl-Data-Structure-Util-0.15-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.15-4 - rebuild against perl 5.10.1 perl-Data-TreeDumper-0.35-6.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-6 - rebuild against perl 5.10.1 perl-Data-TreeDumper-Renderer-GTK-0.02-7.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-7 - rebuild against perl 5.10.1 perl-Data-Visitor-0.25-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.25-3 - rebuild against perl 5.10.1 perl-Date-Calc-6.3-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 6.3-2 - rebuild against perl 5.10.1 perl-Date-ICal-1.72-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.72-3 - rebuild against perl 5.10.1 perl-Date-Leapyear-1.72-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.72-3 - rebuild against perl 5.10.1 perl-Date-Manip-5.54-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 5.54-4 - rebuild against perl 5.10.1 perl-Date-Pcalc-1.2-8.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.2-8 - rebuild against perl 5.10.1 perl-Date-Simple-3.03-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.03-5 - rebuild against perl 5.10.1 perl-Date-Tiny-1.03-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-4 - rebuild against perl 5.10.1 perl-DateTime-0.4501-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:0.4501-4 - rebuild against perl 5.10.1 perl-DateTime-Calendar-Mayan-0.0601-3.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.0601-3 - rebuild against perl 5.10.1 perl-DateTime-Event-ICal-0.09-8.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-8 - rebuild against perl 5.10.1 perl-DateTime-Event-Recurrence-0.16-9.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.16-9 - rebuild against perl 5.10.1 perl-DateTime-Format-Builder-0.7901-5.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.7901-5 - rebuild against perl 5.10.1 perl-DateTime-Format-DB2-0.05-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-DateTime-Format-DBI-0.032-4.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.032-4 - rebuild against perl 5.10.1 perl-DateTime-Format-DateManip-0.04-5.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-5 - rebuild against perl 5.10.1 perl-DateTime-Format-DateParse-0.04-4.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-DateTime-Format-Excel-0.2901-4.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2901-4 - rebuild against perl 5.10.1 perl-DateTime-Format-Flexible-0.09-3.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-3 - rebuild against perl 5.10.1 perl-DateTime-Format-HTTP-0.38-4.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.38-4 - rebuild against perl 5.10.1 perl-DateTime-Format-IBeat-0.161-8.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.161-8 - rebuild against perl 5.10.1 perl-DateTime-Format-ICal-0.09-4.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-4 - rebuild against perl 5.10.1 perl-DateTime-Format-ISO8601-0.06-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-3 - rebuild against perl 5.10.1 perl-DateTime-Format-Mail-0.3001-6.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3001-6 - rebuild against perl 5.10.1 perl-DateTime-Format-MySQL-0.04-9.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-9 - rebuild against perl 5.10.1 perl-DateTime-Format-Natural-0.81-1.fc13 ---------------------------------------- * Wed Dec 09 2009 Iain Arnell 0.81-1 - update to latest upstream version * Mon Dec 07 2009 Stepan Kasal - 0.80-2 - rebuild against perl 5.10.1 perl-DateTime-Format-Oracle-0.05-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-DateTime-Format-Pg-0.16004-2.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16004-2 - rebuild against perl 5.10.1 perl-DateTime-Format-SQLite-0.10-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-4 - rebuild against perl 5.10.1 perl-DateTime-Format-Strptime-1.0800-4.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0800-4 - rebuild against perl 5.10.1 perl-DateTime-Format-W3CDTF-0.04-8.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-8 - rebuild against perl 5.10.1 perl-DateTime-Precise-1.05-7.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-7 - rebuild against perl 5.10.1 perl-DateTime-Set-0.26-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26-4 - rebuild against perl 5.10.1 perl-DateTimeX-Easy-0.087-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.087-4 - rebuild against perl 5.10.1 perl-Declare-Constraints-Simple-0.03-6.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Devel-Caller-2.03-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.03-6 - rebuild against perl 5.10.1 perl-Devel-CheckOS-1.50-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.50-5 - rebuild against perl 5.10.1 perl-Devel-Cycle-1.11-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.11-2 - rebuild against perl 5.10.1 perl-Devel-Dumpvar-0.04-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-5 - rebuild against perl 5.10.1 perl-Devel-FastProf-0.08-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-Devel-FindRef-1.42-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.42-7 - rebuild against perl 5.10.1 perl-Devel-GlobalDestruction-0.02-8.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-8 - rebuild against perl 5.10.1 perl-Devel-Hide-0.0008-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.0008-3 - rebuild against perl 5.10.1 perl-Devel-Leak-0.03-10.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-10 - rebuild against perl 5.10.1 perl-Devel-LeakGuard-Object-0.06-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-Devel-LexAlias-0.04-6.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-6 - rebuild against perl 5.10.1 perl-Devel-NYTProf-2.10-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.10-3 - rebuild against perl 5.10.1 perl-Devel-Profiler-0.04-7.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-7 - rebuild against perl 5.10.1 perl-Devel-REPL-1.003007-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.003007-4 - rebuild against perl 5.10.1 perl-Devel-Refactor-0.05-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-2 - rebuild against perl 5.10.1 perl-Devel-Refcount-0.06-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-Devel-Size-0.71-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.71-3 - rebuild against perl 5.10.1 perl-Devel-SmallProf-2.02-5.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.02-5 - rebuild against perl 5.10.1 perl-Devel-StackTrace-1.22-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:1.22-3 - rebuild against perl 5.10.1 perl-Devel-Symdump-2.08-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1:2.08-2 - rebuild against perl 5.10.1 * Mon Oct 05 2009 Stepan Kasal - 1:2.08-1 - new upstream version perl-Device-SerialPort-1.04-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-6 - rebuild against perl 5.10.1 perl-Digest-BubbleBabble-0.01-11.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-11 - rebuild against perl 5.10.1 perl-Digest-CRC-0.14-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-4 - rebuild against perl 5.10.1 perl-Digest-HMAC-1.01-22.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-22 - rebuild against perl 5.10.1 perl-Digest-MD2-2.03-11.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.03-11 - rebuild against perl 5.10.1 perl-Digest-MD4-1.5-11.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.5-11 - rebuild against perl 5.10.1 * Wed Nov 25 2009 Paul Howarth - 1.5-10 - use %{?perl_default_filter} for provides filter - make %files list more explicit perl-Digest-Nilsimsa-0.06-13.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-13 - rebuild against perl 5.10.1 perl-Digest-SHA1-2.12-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.12-2 - rebuild against perl 5.10.1 perl-Directory-Scratch-0.14-5.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-5 - rebuild against perl 5.10.1 perl-Directory-Scratch-Structured-0.04-4.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-Email-Abstract-3.001-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.001-3 - rebuild against perl 5.10.1 perl-Email-Address-1.889-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.889-4 - rebuild against perl 5.10.1 perl-Email-Date-1.103-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.103-7 - rebuild against perl 5.10.1 perl-Email-Date-Format-1.002-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.002-5 - rebuild against perl 5.10.1 perl-Email-Find-0.10-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-5 - rebuild against perl 5.10.1 perl-Email-MIME-1.863-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.863-3 - rebuild against perl 5.10.1 perl-Email-MIME-Attachment-Stripper-1.316-3.fc13 ------------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.316-3 - rebuild against perl 5.10.1 perl-Email-MIME-Creator-1.456-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.456-2 - rebuild against perl 5.10.1 perl-Email-MIME-Encodings-1.313-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.313-3 - rebuild against perl 5.10.1 perl-Email-MIME-Modifier-1.444-2.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.444-2 - rebuild against perl 5.10.1 perl-Email-MessageID-1.401-5.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.401-5 - rebuild against perl 5.10.1 perl-Email-Reply-1.202-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.202-5 - rebuild against perl 5.10.1 perl-Email-Send-2.194-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.194-3 - rebuild against perl 5.10.1 perl-Email-Simple-2.005-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.005-4 - rebuild against perl 5.10.1 perl-Email-Simple-Creator-1.424-6.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.424-6 - rebuild against perl 5.10.1 perl-Email-Valid-0.180-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.180-3 - rebuild against perl 5.10.1 perl-Encode-Detect-1.01-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-2 - rebuild against perl 5.10.1 perl-Error-0.17015-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:0.17015-4 - rebuild against perl 5.10.1 perl-Eval-Context-0.07-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-5 - rebuild against perl 5.10.1 perl-Event-1.12-2.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-2 - rebuild against perl 5.10.1 perl-Event-ExecFlow-0.63-7.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.63-7 - rebuild against perl 5.10.1 perl-Event-Lib-1.03-9.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-9 - rebuild against perl 5.10.1 perl-Event-RPC-1.01-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-4 - rebuild against perl 5.10.1 perl-Exception-Class-1.29-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.29-2 - rebuild against perl 5.10.1 perl-Exception-Class-TryCatch-1.12-3.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-3 - rebuild against perl 5.10.1 perl-Expect-1.21-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.21-4 - rebuild against perl 5.10.1 perl-Expect-Simple-0.04-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-Exporter-Lite-0.02-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.02-6 - rebuild against perl 5.10.1 perl-ExtUtils-AutoInstall-0.63-11.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.63-11 - rebuild against perl 5.10.1 perl-ExtUtils-Depends-0.302-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.302-2 - rebuild against perl 5.10.1 perl-ExtUtils-F77-1.16-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.16-6 - rebuild against perl 5.10.1 perl-ExtUtils-InstallPAR-0.03-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-ExtUtils-MakeMaker-Coverage-0.05-8.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-8 - rebuild against perl 5.10.1 perl-ExtUtils-PkgConfig-1.12-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-4 - rebuild against perl 5.10.1 perl-ExtUtils-XSBuilder-0.28-7.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.28-7 - rebuild against perl 5.10.1 perl-ExtUtils-XSpp-0.04-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-FCGI-ProcManager-0.19-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.19-2 - rebuild against perl 5.10.1 perl-Fedora-Bugzilla-0.10-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-3 - rebuild against perl 5.10.1 perl-Feed-Find-0.06-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-6 - rebuild against perl 5.10.1 perl-File-BOM-0.14-6.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-6 - rebuild against perl 5.10.1 perl-File-BaseDir-0.03-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-File-ChangeNotify-0.07-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-2 - rebuild against perl 5.10.1 perl-File-Comments-0.07-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.07-5 - rebuild against perl 5.10.1 perl-File-Copy-Recursive-0.38-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.38-4 - rebuild against perl 5.10.1 perl-File-DesktopEntry-0.04-9.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-9 - rebuild against perl 5.10.1 perl-File-ExtAttr-1.09-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-3 - rebuild against perl 5.10.1 perl-File-Find-Rule-0.30-9.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.30-9 - rebuild against perl 5.10.1 perl-File-Find-Rule-PPI-0.05-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-File-Find-Rule-Perl-1.09-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.09-2 - rebuild against perl 5.10.1 perl-File-Find-Rule-VCS-1.05-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-4 - rebuild against perl 5.10.1 perl-File-Flat-1.04-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-5 - rebuild against perl 5.10.1 perl-File-Flock-2008.01-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2008.01-3 - rebuild against perl 5.10.1 perl-File-HomeDir-0.86-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.86-3 - rebuild against perl 5.10.1 perl-File-LibMagic-0.91-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.91-3 - rebuild against perl 5.10.1 perl-File-MMagic-1.27-8.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.27-8 - rebuild against perl 5.10.1 perl-File-MMagic-XS-0.09003-7.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09003-7 - rebuild against perl 5.10.1 perl-File-MimeInfo-0.15-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.15-5 - rebuild against perl 5.10.1 perl-File-Modified-0.07-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.07-8 - rebuild against perl 5.10.1 perl-File-NCopy-0.36-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.36-4 - rebuild against perl 5.10.1 perl-File-NFSLock-1.20-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.20-6 - rebuild against perl 5.10.1 perl-File-Next-1.02-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-5 - rebuild against perl 5.10.1 perl-File-Pid-1.01-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-3 - rebuild against perl 5.10.1 perl-File-ReadBackwards-1.04-8.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-8 - rebuild against perl 5.10.1 perl-File-Remove-1.42-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.42-4 - rebuild against perl 5.10.1 perl-File-RsyncP-0.68-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.68-7 - rebuild against perl 5.10.1 perl-File-Slurp-9999.13-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 9999.13-7 - rebuild against perl 5.10.1 perl-File-Sync-0.09-8.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-8 - rebuild against perl 5.10.1 perl-File-Tail-0.99.3-9.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.99.3-9 - rebuild against perl 5.10.1 perl-File-Type-0.22-9.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-9 - rebuild against perl 5.10.1 perl-File-Which-1.09-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-2 - rebuild against perl 5.10.1 perl-File-chdir-0.09-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-5 - rebuild against perl 5.10.1 perl-File-chmod-0.32-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.32-6 - rebuild against perl 5.10.1 perl-File-pushd-1.00-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-4 - rebuild against perl 5.10.1 perl-FileHandle-Fmode-0.09-7.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-7 - rebuild against perl 5.10.1 perl-FileHandle-Unget-0.1623-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.1623-2 - rebuild against perl 5.10.1 perl-Filesys-Df-0.92-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-6 - rebuild against perl 5.10.1 perl-Finance-Quote-1.17-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.17-2 - rebuild against perl 5.10.1 perl-Finance-YahooQuote-0.22-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-3 - rebuild against perl 5.10.1 perl-Flickr-API-1.02-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-2 - rebuild against perl 5.10.1 perl-Flickr-Upload-1.32-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.32-3 - rebuild against perl 5.10.1 perl-Font-AFM-1.20-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.20-4 - rebuild against perl 5.10.1 perl-Font-TTF-0.45-6.fc13 ------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.45-6 - rebuild against perl 5.10.1 perl-FreezeThaw-0.45-4.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.45-4 - rebuild against perl 5.10.1 perl-Frontier-RPC-0.07b4p1-8.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.07b4p1-8 - rebuild against perl 5.10.1 perl-GD-2.44-3.fc13 ------------------- * Fri Dec 04 2009 Stepan Kasal - 2.44-3 - rebuild against perl 5.10.1 perl-GD-Barcode-1.15-6.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.15-6 - rebuild against perl 5.10.1 perl-GD-SVG-0.32-4.fc13 ----------------------- * Fri Dec 04 2009 Stepan Kasal - 0.32-4 - rebuild against perl 5.10.1 perl-GDGraph-1.44-7.fc13 ------------------------ * Fri Dec 04 2009 Stepan Kasal - 1:1.44-7 - rebuild against perl 5.10.1 perl-GDGraph3d-0.63-12.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.63-12 - rebuild against perl 5.10.1 perl-GDTextUtil-0.86-15.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.86-15 - rebuild against perl 5.10.1 perl-GO-TermFinder-0.82-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.82-5 - rebuild against perl 5.10.1 perl-GPS-0.16-3.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-3 - rebuild against perl 5.10.1 perl-GPS-PRN-0.05-5.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-GSSAPI-0.26-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26-4 - rebuild against perl 5.10.1 perl-GStreamer-0.15-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-5 - rebuild against perl 5.10.1 perl-GTop-0.16-10.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-10 - rebuild against perl 5.10.1 perl-Gearman-1.09-5.fc13 ------------------------ * Fri Dec 04 2009 Stepan Kasal - 1.09-5 - rebuild against perl 5.10.1 perl-Gearman-Client-Async-0.94-7.fc13 ------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.94-7 - rebuild against perl 5.10.1 perl-Gearman-Server-1.09-5.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.09-5 - rebuild against perl 5.10.1 perl-Geo-Constants-0.06-5.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.06-5 - rebuild against perl 5.10.1 perl-Geo-Ellipsoids-0.16-3.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.16-3 - rebuild against perl 5.10.1 perl-Geo-Forward-0.11-5.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Geo-Functions-0.07-5.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.07-5 - rebuild against perl 5.10.1 perl-Geo-IP-1.38-3.fc13 ----------------------- * Fri Dec 04 2009 Stepan Kasal - 1.38-3 - rebuild against perl 5.10.1 perl-Geo-IPfree-0.4-4.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.4-4 - rebuild against perl 5.10.1 perl-Geo-Inverse-0.05-5.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-Geo-METAR-1.15-5.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.15-5 - rebuild against perl 5.10.1 perl-Geography-Countries-1.4-6.fc13 ----------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.4-6 - rebuild against perl 5.10.1 perl-Getopt-ArgvFile-1.11-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.11-4 - rebuild against perl 5.10.1 perl-Getopt-Euclid-0.2.1-3.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.2.1-3 - rebuild against perl 5.10.1 perl-Getopt-GUI-Long-0.91-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.91-3 - rebuild against perl 5.10.1 perl-Getopt-Long-Descriptive-0.077-2.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.077-2 - rebuild against perl 5.10.1 perl-Git-CPAN-Patch-0.2.1-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2.1-2 - rebuild against perl 5.10.1 perl-Gnome2-1.042-5.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.042-5 - rebuild against perl 5.10.1 perl-Gnome2-Canvas-1.002-13.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.002-13 - rebuild against perl 5.10.1 perl-Gnome2-GConf-1.044-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.044-8 - rebuild against perl 5.10.1 perl-Gnome2-Print-1.000-9.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.000-9 - rebuild against perl 5.10.1 perl-Gnome2-VFS-1.081-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.081-5 - rebuild against perl 5.10.1 perl-Gnome2-Wnck-0.16-9.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-9 - rebuild against perl 5.10.1 perl-GnuPG-Interface-0.42-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.42-3 - rebuild against perl 5.10.1 perl-Goo-Canvas-0.06-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-7 - rebuild against perl 5.10.1 perl-Graph-0.91-4.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.91-4 - rebuild against perl 5.10.1 perl-GraphViz-2.04-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.04-3 - rebuild against perl 5.10.1 perl-Graphics-ColorNames-2.11-6.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.11-6 - rebuild against perl 5.10.1 perl-Gtk2-1.203-4.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.203-4 - rebuild against perl 5.10.1 perl-Gtk2-Ex-CalendarButton-0.01-8.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-8 - rebuild against perl 5.10.1 perl-Gtk2-Ex-Carp-0.01-7.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-7 - rebuild against perl 5.10.1 perl-Gtk2-Ex-Dialogs-0.11-6.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-6 - rebuild against perl 5.10.1 perl-Gtk2-Ex-FormFactory-0.65-6.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.65-6 - rebuild against perl 5.10.1 perl-Gtk2-Ex-PodViewer-0.18-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-4 - rebuild against perl 5.10.1 perl-Gtk2-Ex-Simple-List-0.50-7.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.50-7 - rebuild against perl 5.10.1 perl-Gtk2-Ex-Utils-0.09-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-6 - rebuild against perl 5.10.1 perl-Gtk2-GladeXML-1.007-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.007-5 - rebuild against perl 5.10.1 perl-Gtk2-ImageView-0.04-6.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-6 - rebuild against perl 5.10.1 perl-Gtk2-Notify-0.05-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-7 - rebuild against perl 5.10.1 perl-Gtk2-Sexy-0.05-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-Gtk2-Spell-1.03-12.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-12 - rebuild against perl 5.10.1 perl-Gtk2-TrayIcon-0.06-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.06-8 - rebuild against perl 5.10.1 perl-Guard-1.021-2.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.021-2 - rebuild against perl 5.10.1 perl-HTML-CalendarMonthSimple-1.25-6.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.25-6 - rebuild against perl 5.10.1 perl-HTML-DOMbo-3.10-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.10-4 - rebuild against perl 5.10.1 perl-HTML-Defang-1.02-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-2 - rebuild against perl 5.10.1 perl-HTML-Encoding-0.60-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.60-5 - rebuild against perl 5.10.1 perl-HTML-FillInForm-2.00-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.00-3 - rebuild against perl 5.10.1 perl-HTML-FormFu-0.05004-1.fc13 ------------------------------- * Tue Dec 08 2009 Iain Arnell 0.05004-1 - update to latest upstream version - use perl_default_filter * Mon Dec 07 2009 Stepan Kasal - 0.05001-3 - rebuild against perl 5.10.1 perl-HTML-FormFu-Model-DBIC-0.05002-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05002-2 - rebuild against perl 5.10.1 perl-HTML-Format-2.04-12.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.04-12 - rebuild against perl 5.10.1 perl-HTML-FormatText-WithLinks-0.09-7.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-7 - rebuild against perl 5.10.1 perl-HTML-FromText-2.05-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.05-6 - rebuild against perl 5.10.1 perl-HTML-GenToc-3.10-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.10-3 - rebuild against perl 5.10.1 perl-HTML-LinkList-0.1503-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.1503-3 - rebuild against perl 5.10.1 perl-HTML-Lint-2.06-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.06-5 - rebuild against perl 5.10.1 perl-HTML-Mason-1.42-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:1.42-3 - rebuild against perl 5.10.1 perl-HTML-Parser-3.64-2.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 3.64-2 - rebuild against perl 5.10.1 perl-HTML-PrettyPrinter-0.03-7.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-7 - rebuild against perl 5.10.1 perl-HTML-Prototype-1.48-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.48-3 - rebuild against perl 5.10.1 perl-HTML-RewriteAttributes-0.03-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-HTML-Scrubber-0.08-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.08-8 - rebuild against perl 5.10.1 perl-HTML-SimpleParse-0.12-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-3 - rebuild against perl 5.10.1 perl-HTML-Strip-1.06-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-3 - rebuild against perl 5.10.1 perl-HTML-StripScripts-1.04-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-3 - rebuild against perl 5.10.1 perl-HTML-StripScripts-Parser-1.02-3.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-3 - rebuild against perl 5.10.1 perl-HTML-SuperForm-1.09-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-2 - rebuild against perl 5.10.1 perl-HTML-Table-2.08a-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.08a-4 - rebuild against perl 5.10.1 perl-HTML-TableExtract-2.10-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.10-6 - rebuild against perl 5.10.1 perl-HTML-TagCloud-0.34-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.34-3 - rebuild against perl 5.10.1 perl-HTML-Tagset-3.20-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.20-4 - rebuild against perl 5.10.1 perl-HTML-Template-2.9-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.9-6 - rebuild against perl 5.10.1 perl-HTML-Template-Expr-0.07-9.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-9 - rebuild against perl 5.10.1 perl-HTML-Template-Pro-0.87-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.87-2 - rebuild against perl 5.10.1 perl-HTML-Tidy-1.08-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-6 - rebuild against perl 5.10.1 perl-HTML-Tiny-1.05-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-5 - rebuild against perl 5.10.1 perl-HTML-Toc-1.11-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.11-3 - rebuild against perl 5.10.1 perl-HTML-TokeParser-Simple-3.15-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.15-4 - rebuild against perl 5.10.1 perl-HTML-Tree-3.23-10.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:3.23-10 - rebuild against perl 5.10.1 perl-HTML-TreeBuilder-XPath-0.11-3.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-3 - rebuild against perl 5.10.1 perl-HTML-WikiConverter-0.68-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.68-3 - rebuild against perl 5.10.1 perl-HTML-WikiConverter-Markdown-0.05-3.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-HTTP-Body-1.05-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-5 - rebuild against perl 5.10.1 perl-HTTP-BrowserDetect-0.99-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.99-5 - rebuild against perl 5.10.1 perl-HTTP-Cache-Transparent-1.0-6.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0-6 - rebuild against perl 5.10.1 perl-HTTP-DAV-0.35-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-5 - rebuild against perl 5.10.1 perl-HTTP-Proxy-0.23-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-5 - rebuild against perl 5.10.1 perl-HTTP-Recorder-0.05-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.05-5 - rebuild against perl 5.10.1 perl-HTTP-Request-AsCGI-0.9-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9-3 - rebuild against perl 5.10.1 perl-HTTP-Request-Params-1.01-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-5 - rebuild against perl 5.10.1 perl-HTTP-Response-Encoding-0.06-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-HTTP-Server-Simple-0.41-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.41-2 - rebuild against perl 5.10.1 perl-HTTP-Server-Simple-Mason-0.13-2.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 perl-HTTP-Server-Simple-Static-0.07-4.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.07-4 - rebuild against perl 5.10.1 perl-Hardware-Verilog-Parser-0.13-4.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-4 - rebuild against perl 5.10.1 perl-Hardware-Vhdl-Lexer-1.00-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.00-5 - rebuild against perl 5.10.1 perl-Hardware-Vhdl-Parser-0.12-5.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-5 - rebuild against perl 5.10.1 perl-Hardware-Vhdl-Tidy-0.8-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.8-6 - rebuild against perl 5.10.1 perl-Hash-Case-1.006-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.006-4 - rebuild against perl 5.10.1 perl-Hash-Flatten-1.16-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.16-3 - rebuild against perl 5.10.1 perl-Hash-Merge-0.11-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-4 - rebuild against perl 5.10.1 perl-Hash-Merge-Simple-0.04-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-Hash-Util-FieldHash-Compat-0.03-4.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-Hash-WithDefaults-0.04-7.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-7 - rebuild against perl 5.10.1 perl-Heap-0.80-5.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.80-5 - rebuild against perl 5.10.1 perl-Hook-LexWrap-0.22-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-4 - rebuild against perl 5.10.1 perl-IO-AIO-3.17-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 3.17-4 - rebuild against perl 5.10.1 perl-IO-All-0.39-5.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 0.39-5 - rebuild against perl 5.10.1 perl-IO-Async-0.23-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-2 - rebuild against perl 5.10.1 perl-IO-Capture-0.05-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-6 - rebuild against perl 5.10.1 perl-IO-CaptureOutput-1.1101-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1101-3 - rebuild against perl 5.10.1 perl-IO-Digest-0.10-10.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-10 - rebuild against perl 5.10.1 perl-IO-Interface-1.05-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-3 - rebuild against perl 5.10.1 perl-IO-Multiplex-1.10-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.10-6 - rebuild against perl 5.10.1 perl-IO-Null-1.01-7.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-7 - rebuild against perl 5.10.1 perl-IO-Prompt-0.99.4-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.99.4-6 - rebuild against perl 5.10.1 perl-IO-Socket-INET6-2.56-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.56-3 - rebuild against perl 5.10.1 perl-IO-Socket-SSL-1.31-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.31-2 - rebuild against perl 5.10.1 perl-IO-String-1.08-9.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-9 - rebuild against perl 5.10.1 perl-IO-TieCombine-1.000-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.000-5 - rebuild against perl 5.10.1 perl-IO-Tty-1.08-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-4 - rebuild against perl 5.10.1 perl-IPC-DirQueue-1.0-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0-3 - rebuild against perl 5.10.1 perl-IPC-Run-0.84-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.84-2 - rebuild against perl 5.10.1 perl-IPC-Run-SafeHandles-0.02-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.02-5 - rebuild against perl 5.10.1 perl-IPC-Run3-0.043-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.043-3 - rebuild against perl 5.10.1 perl-IPC-ShareLite-0.13-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.13-4 - rebuild against perl 5.10.1 perl-IPC-Shareable-0.60-11.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.60-11 - rebuild against perl 5.10.1 perl-IPC-SharedCache-1.3-12.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.3-12 - rebuild against perl 5.10.1 perl-IPC-System-Simple-1.18-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.18-3 - rebuild against perl 5.10.1 perl-IPTables-Parse-0.7-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.7-5 - rebuild against perl 5.10.1 perl-Ima-DBI-0.35-8.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.35-8 - rebuild against perl 5.10.1 perl-Image-Base-1.07-13.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-13 - rebuild against perl 5.10.1 perl-Image-ExifTool-8.00-1.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 7.67-5 - rebuild against perl 5.10.1 * Mon Dec 07 2009 Tom "spot" Callaway 8.00-1 - update to 8.00 (Production) perl-Image-Info-1.28-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.28-6 - rebuild against perl 5.10.1 perl-Image-Math-Constrain-1.02-5.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-5 - rebuild against perl 5.10.1 perl-Image-Size-3.2-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.2-3 - rebuild against perl 5.10.1 perl-Image-Xbm-1.08-12.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-12 - rebuild against perl 5.10.1 perl-Image-Xpm-1.09-12.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.09-12 - rebuild against perl 5.10.1 perl-Imager-0.67-5.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 0.67-5 - rebuild against perl 5.10.1 perl-Inline-0.44-23.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.44-23 - rebuild against perl 5.10.1 perl-Inline-Files-0.62-7.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.62-7 - rebuild against perl 5.10.1 perl-JSON-RPC-0.96-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.96-4 - rebuild against perl 5.10.1 perl-JSON-RPC-Common-0.03-5.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-JSON-XS-2.24-3.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1:2.24-3 - rebuild against perl 5.10.1 perl-JavaScript-Beautifier-0.13-2.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 perl-JavaScript-Minifier-1.05-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.05-3 - rebuild against perl 5.10.1 perl-JavaScript-Minifier-XS-0.06-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-Jcode-2.07-2.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 2.07-2 - rebuild against perl 5.10.1 perl-KinoSearch-0.165-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.165-3 - rebuild against perl 5.10.1 perl-Kwiki-0.39-7.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.39-7 - rebuild against perl 5.10.1 perl-Kwiki-Archive-Rcs-0.15-12.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-12 - rebuild against perl 5.10.1 perl-Kwiki-Attachments-0.18-9.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-9 - rebuild against perl 5.10.1 perl-Kwiki-Diff-0.03-10.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-10 - rebuild against perl 5.10.1 perl-Kwiki-ModPerl-0.09-10.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-10 - rebuild against perl 5.10.1 perl-Kwiki-NewPage-0.12-11.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-11 - rebuild against perl 5.10.1 perl-Kwiki-Raw-0.02-10.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-10 - rebuild against perl 5.10.1 perl-Kwiki-RecentChanges-0.14-9.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-9 - rebuild against perl 5.10.1 perl-Kwiki-Revisions-0.15-11.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-11 - rebuild against perl 5.10.1 perl-Kwiki-Search-0.12-11.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.12-11 - rebuild against perl 5.10.1 perl-Kwiki-UserName-0.14-11.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-11 - rebuild against perl 5.10.1 perl-Kwiki-UserPreferences-0.13-10.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-10 - rebuild against perl 5.10.1 perl-Kwiki-Users-Remote-0.04-9.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-9 - rebuild against perl 5.10.1 perl-LDAP-0.34-7.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1:0.34-7 - rebuild against perl 5.10.1 perl-LWP-Authen-Wsse-0.05-6.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-6 - rebuild against perl 5.10.1 perl-LWP-Online-1.07-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-2 - rebuild against perl 5.10.1 perl-Lexical-Persistence-1.01-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-2 - rebuild against perl 5.10.1 perl-Lingua-EN-Inflect-1.89-11.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.89-11 - rebuild against perl 5.10.1 perl-Lingua-EN-Inflect-Number-1.1-12.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-12 - rebuild against perl 5.10.1 perl-Lingua-EN-Numbers-Ordinate-1.02-6.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-6 - rebuild against perl 5.10.1 perl-Lingua-Flags-0.05-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-Lingua-Preferred-0.2.4-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2.4-6 - rebuild against perl 5.10.1 perl-Lingua-Stem-Snowball-0.952-5.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.952-5 - rebuild against perl 5.10.1 perl-Lingua-StopWords-0.09-6.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-6 - rebuild against perl 5.10.1 perl-Linux-Inotify2-1.2-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.2-3 - rebuild against perl 5.10.1 perl-Linux-Pid-0.04-9.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-9 - rebuild against perl 5.10.1 perl-List-Compare-0.37-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-5 - rebuild against perl 5.10.1 perl-List-MoreUtils-0.22-10.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-10 - rebuild against perl 5.10.1 perl-Locale-Maketext-Fuzzy-0.10-6.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-6 - rebuild against perl 5.10.1 perl-Locale-Maketext-Gettext-1.27-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.27-3 - rebuild against perl 5.10.1 perl-Locale-Maketext-Lexicon-0.77-5.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.77-5 - rebuild against perl 5.10.1 perl-Locale-Msgfmt-0.14-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-2 - rebuild against perl 5.10.1 perl-Locale-PO-0.21-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.21-3 - rebuild against perl 5.10.1 perl-Locale-SubCountry-1.41-5.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.41-5 - rebuild against perl 5.10.1 perl-LockFile-Simple-0.207-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.207-3 - rebuild against perl 5.10.1 perl-Log-Dispatch-2.22-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.22-5 - rebuild against perl 5.10.1 perl-Log-Dispatch-Config-1.02-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.02-5 - rebuild against perl 5.10.1 perl-Log-Dispatch-FileRotate-1.19-5.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.19-5 - rebuild against perl 5.10.1 perl-Log-Dispatch-Perl-0.03-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Log-Log4perl-1.24-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.24-2 - rebuild against perl 5.10.1 perl-Log-LogLite-0.82-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.82-3 - rebuild against perl 5.10.1 perl-Log-Trace-1.070-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.070-3 - rebuild against perl 5.10.1 perl-Log-TraceMessages-1.4-5.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4-5 - rebuild against perl 5.10.1 perl-Log-Trivial-0.31-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.31-5 - rebuild against perl 5.10.1 perl-MARC-Record-2.0.0-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.0.0-6 - rebuild against perl 5.10.1 perl-MD5-2.03-5.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 2.03-5 - rebuild against perl 5.10.1 perl-MIME-Charset-1.006.2-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.006.2-4 - rebuild against perl 5.10.1 perl-MIME-EncWords-1.010.101-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.010.101-4 - rebuild against perl 5.10.1 perl-MIME-Lite-3.027-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.027-2 - rebuild against perl 5.10.1 perl-MIME-Types-1.28-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.28-2 - rebuild against perl 5.10.1 perl-MIME-tools-5.427-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 5.427-4 - rebuild against perl 5.10.1 perl-MLDBM-2.01-9.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 2.01-9 - rebuild against perl 5.10.1 perl-MP3-Info-1.24-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.24-2 - rebuild against perl 5.10.1 perl-MRO-Compat-0.11-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-3 - rebuild against perl 5.10.1 perl-Mail-Alias-1.12-12.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-12 - rebuild against perl 5.10.1 perl-Mail-Box-2.091-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.091-2 - rebuild against perl 5.10.1 perl-Mail-Box-Parser-C-3.006-7.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.006-7 - rebuild against perl 5.10.1 perl-Mail-DKIM-0.37-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-2 - rebuild against perl 5.10.1 perl-Mail-GnuPG-0.15-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-5 - rebuild against perl 5.10.1 perl-Mail-IMAPClient-3.21-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.21-2 - rebuild against perl 5.10.1 perl-Mail-Mbox-MessageParser-1.5002-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.5002-2 - rebuild against perl 5.10.1 perl-Mail-POP3Client-2.18-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.18-4 - rebuild against perl 5.10.1 perl-Mail-RFC822-Address-0.3-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3-5 - rebuild against perl 5.10.1 perl-Mail-SPF-2.006-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.006-4 - rebuild against perl 5.10.1 perl-Mail-Sender-0.8.16-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.8.16-4 - rebuild against perl 5.10.1 perl-Mail-Sendmail-0.79-13.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.79-13 - rebuild against perl 5.10.1 perl-Mail-Transport-Dbx-0.07-9.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-9 - rebuild against perl 5.10.1 perl-MailTools-2.04-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.04-4 - rebuild against perl 5.10.1 perl-Makefile-DOM-0.004-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.004-3 - rebuild against perl 5.10.1 perl-Makefile-Parser-0.211-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.211-2 - rebuild against perl 5.10.1 perl-MasonX-Interp-WithCallbacks-1.18-4.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.18-4 - rebuild against perl 5.10.1 perl-MasonX-Request-WithApacheSession-0.30-8.fc13 ------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.30-8 - rebuild against perl 5.10.1 perl-Math-Base85-0.2-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2-7 - rebuild against perl 5.10.1 perl-Math-BaseCnv-1.4.75O6Pbr-6.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.4.75O6Pbr-6 - rebuild against perl 5.10.1 perl-Math-BigInt-GMP-1.24-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.24-4 - rebuild against perl 5.10.1 perl-Math-Calc-Units-1.06-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-3 - rebuild against perl 5.10.1 perl-Math-Curve-Hilbert-0.04-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-Math-Derivative-0.01-7.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-7 - rebuild against perl 5.10.1 perl-Math-FFT-1.28-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.28-4 - rebuild against perl 5.10.1 perl-Math-GMP-2.06-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.06-2 - rebuild against perl 5.10.1 perl-Math-MatrixReal-2.05-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.05-4 - rebuild against perl 5.10.1 perl-Math-Random-MT-Auto-6.14-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 6.14-4 - rebuild against perl 5.10.1 perl-Math-Round-0.06-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-5 - rebuild against perl 5.10.1 perl-Math-Spline-0.01-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-6 - rebuild against perl 5.10.1 perl-Math-Symbolic-0.510-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.510-5 - rebuild against perl 5.10.1 perl-Math-Vec-1.01-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-5 - rebuild against perl 5.10.1 perl-Maypole-2.13-3.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1:2.13-3 - rebuild against perl 5.10.1 perl-Mixin-Linewise-0.002-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.002-3 - rebuild against perl 5.10.1 perl-ModelSim-List-0.06-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.06-4 - rebuild against perl 5.10.1 perl-Module-CPANTS-Analyse-0.85-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.85-3 - rebuild against perl 5.10.1 perl-Module-Compile-0.20-6.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.20-6 - rebuild against perl 5.10.1 perl-Module-Depends-0.14-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-4 - rebuild against perl 5.10.1 perl-Module-Extract-0.01-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-5 - rebuild against perl 5.10.1 perl-Module-ExtractUse-0.23-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-4 - rebuild against perl 5.10.1 perl-Module-Find-0.08-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-2 - rebuild against perl 5.10.1 perl-Module-Info-0.31-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.31-7 - rebuild against perl 5.10.1 perl-Module-Inspector-1.05-6.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-6 - rebuild against perl 5.10.1 perl-Module-Install-ExtraTests-0.006-4.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.006-4 - rebuild against perl 5.10.1 perl-Module-Install-GithubMeta-0.10-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.10-2 - rebuild against perl 5.10.1 perl-Module-Locate-1.7-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.7-5 - rebuild against perl 5.10.1 perl-Module-Manifest-0.03-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-Module-Math-Depends-0.02-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.02-5 - rebuild against perl 5.10.1 perl-Module-Pluggable-Ordered-1.5-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.5-3 - rebuild against perl 5.10.1 perl-Module-Refresh-0.13-6.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-6 - rebuild against perl 5.10.1 perl-Module-ScanDeps-0.95-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.95-2 - rebuild against perl 5.10.1 perl-Module-Signature-0.61-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.61-2 - rebuild against perl 5.10.1 perl-Module-Starter-PBP-0.000003-9.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.000003-9 - rebuild against perl 5.10.1 perl-Module-Used-1.2.0-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.2.0-3 - rebuild against perl 5.10.1 perl-Module-Util-1.07-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-3 - rebuild against perl 5.10.1 perl-Module-Versions-Report-1.06-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-4 - rebuild against perl 5.10.1 perl-MogileFS-Client-1.08-5.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-5 - rebuild against perl 5.10.1 perl-MogileFS-Utils-2.12-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.12-5 - rebuild against perl 5.10.1 perl-Mon-0.11-4.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-4 - rebuild against perl 5.10.1 perl-Moose-0.92-2.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-2 - rebuild against perl 5.10.1 perl-Moose-Autobox-0.09-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-2 - rebuild against perl 5.10.1 perl-Moose-Policy-0.03-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-MooseX-App-Cmd-0.06-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-2 - rebuild against perl 5.10.1 perl-MooseX-Async-0.07-4.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.07-4 - rebuild against perl 5.10.1 perl-MooseX-AttributeHelpers-0.22-2.fc13 ---------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.22-2 - rebuild against perl 5.10.1 perl-MooseX-CascadeClearing-0.02-2.fc13 --------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.02-2 - rebuild against perl 5.10.1 perl-MooseX-ConfigFromFile-0.02-4.fc13 -------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-MooseX-Daemonize-0.09-1.fc13 --------------------------------- * Wed Dec 09 2009 Allisson Azevedo 0.09-1 - Update to 0.09. - Update BuildRequires. * Sun Jul 26 2009 Fedora Release Engineering - 0.08-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild perl-MooseX-Emulate-Class-Accessor-Fast-0.00903-2.fc13 ------------------------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.00903-2 - rebuild against perl 5.10.1 perl-MooseX-Getopt-0.22-2.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.22-2 - rebuild against perl 5.10.1 perl-MooseX-Iterator-0.11-2.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.11-2 - rebuild against perl 5.10.1 perl-MooseX-LazyLogDispatch-0.02-4.fc13 --------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-MooseX-Log-Log4perl-0.40-4.fc13 ------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.40-4 - rebuild against perl 5.10.1 perl-MooseX-LogDispatch-1.2000-5.fc13 ------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.2000-5 - rebuild against perl 5.10.1 perl-MooseX-MethodAttributes-0.18-2.fc13 ---------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.18-2 - rebuild against perl 5.10.1 perl-MooseX-MultiInitArg-0.01-5.fc13 ------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.01-5 - rebuild against perl 5.10.1 perl-MooseX-Object-Pluggable-0.0011-3.fc13 ------------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.0011-3 - rebuild against perl 5.10.1 perl-MooseX-POE-0.205-2.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.205-2 - rebuild against perl 5.10.1 perl-MooseX-Param-0.02-4.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-MooseX-Params-Validate-0.12-2.fc13 --------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-MooseX-Policy-SemiAffordanceAccessor-0.02-4.fc13 ----------------------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-MooseX-Role-Cmd-0.05-3.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-MooseX-Role-Parameterized-0.13-2.fc13 ------------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 * Sat Sep 19 2009 Chris Weyl 0.13-1 - auto-update to 0.13 (by cpan-spec-update 0.01) - added a new br on perl(Test::Moose) (version 0) * Wed Aug 19 2009 Chris Weyl 0.10-1 - auto-update to 0.10 (by cpan-spec-update 0.01) * Sun Jul 26 2009 Fedora Release Engineering - 0.09-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild perl-MooseX-Role-XMLRPC-Client-0.04-3.fc13 ------------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-MooseX-SemiAffordanceAccessor-0.05-2.fc13 ---------------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.05-2 - rebuild against perl 5.10.1 perl-MooseX-SimpleConfig-0.03-4.fc13 ------------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-MooseX-Singleton-0.21-3.fc13 --------------------------------- * Thu Dec 10 2009 Allisson Azevedo 0.21-3 - Update BR. - Remove README from docs. * Fri Dec 04 2009 Stepan Kasal - 0.21-2 - rebuild against perl 5.10.1 * Sat Sep 19 2009 Chris Weyl 0.21-1 - auto-update to 0.21 (by cpan-spec-update 0.01) - altered br on perl(Moose) (0.74 => 0.82) - added a new req on perl(Moose) (version 0.82) perl-MooseX-Storage-0.21-2.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.21-2 - rebuild against perl 5.10.1 perl-MooseX-StrictConstructor-0.08-3.fc13 ----------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.08-3 - rebuild against perl 5.10.1 perl-MooseX-Traits-Pluggable-0.08-2.fc13 ---------------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.08-2 - rebuild against perl 5.10.1 perl-MooseX-Types-0.20-2.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.20-2 - rebuild against perl 5.10.1 perl-MooseX-Types-Path-Class-0.05-6.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-6 - rebuild against perl 5.10.1 perl-MooseX-Types-Set-Object-0.02-4.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-MooseX-Types-URI-0.02-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-3 - rebuild against perl 5.10.1 perl-MooseX-Workers-0.05-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-Mouse-0.35-2.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-2 - rebuild against perl 5.10.1 perl-MouseX-Types-0.01-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-4 - rebuild against perl 5.10.1 perl-NOCpulse-CLAC-1.9.8-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.9.8-4 - rebuild against perl 5.10.1 perl-NOCpulse-Debug-1.23.15-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.23.15-4 - rebuild against perl 5.10.1 perl-NOCpulse-Gritch-1.27.4-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.27.4-3 - rebuild against perl 5.10.1 perl-NOCpulse-Object-1.26.10-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.26.10-4 - rebuild against perl 5.10.1 perl-NOCpulse-SetID-1.6.9-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.9-4 - rebuild against perl 5.10.1 perl-NOCpulse-Utils-1.14.11-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.14.11-4 - rebuild against perl 5.10.1 perl-Nagios-NSCA-0.1-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.1-5 - rebuild against perl 5.10.1 perl-Nagios-Plugin-0.33-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.33-3 - rebuild against perl 5.10.1 perl-Nagios-Plugin-Beanstalk-0.04-4.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-Net-Amazon-0.59-2.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.59-2 - rebuild against perl 5.10.1 perl-Net-Amazon-EC2-0.09-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-4 - rebuild against perl 5.10.1 perl-Net-CIDR-0.13-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-3 - rebuild against perl 5.10.1 perl-Net-CIDR-Lite-0.20-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.20-7 - rebuild against perl 5.10.1 perl-Net-CUPS-0.61-4.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.61-4 - rebuild against perl 5.10.1 perl-Net-DBus-0.33.6-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33.6-5 - rebuild against perl 5.10.1 perl-Net-DBus-GLib-0.33.0-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33.0-4 - rebuild against perl 5.10.1 perl-Net-DNS-0.65-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.65-2 - rebuild against perl 5.10.1 perl-Net-DNS-Resolver-Programmable-0.003-6.fc13 ----------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.003-6 - rebuild against perl 5.10.1 perl-Net-DNS-SEC-0.14-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-6 - rebuild against perl 5.10.1 perl-Net-Daemon-0.44-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.44-8 - rebuild against perl 5.10.1 perl-Net-Domain-TLD-1.68-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.68-3 - rebuild against perl 5.10.1 perl-Net-FTPServer-1.122-8.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.122-8 - rebuild against perl 5.10.1 perl-Net-GPSD-0.37-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-3 - rebuild against perl 5.10.1 perl-Net-GitHub-0.19-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.19-3 - rebuild against perl 5.10.1 perl-Net-IP-1.25-11.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.25-11 - rebuild against perl 5.10.1 perl-Net-IP-CMatch-0.02-11.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-11 - rebuild against perl 5.10.1 perl-Net-IPv4Addr-0.10-7.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-7 - rebuild against perl 5.10.1 perl-Net-IRC-0.75-6.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.75-6 - rebuild against perl 5.10.1 perl-Net-Jabber-2.0-12.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.0-12 - rebuild against perl 5.10.1 perl-Net-LibIDN-0.12-3.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-3 - rebuild against perl 5.10.1 perl-Net-Libdnet-0.01-9.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-9 - rebuild against perl 5.10.1 perl-Net-NBName-0.26-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26-6 - rebuild against perl 5.10.1 perl-Net-Netmask-1.9015-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.9015-5 - rebuild against perl 5.10.1 perl-Net-OAuth-0.19-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.19-2 - rebuild against perl 5.10.1 perl-Net-Patricia-1.15-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.15-3 - rebuild against perl 5.10.1 perl-Net-Pcap-0.16-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-3 - rebuild against perl 5.10.1 perl-Net-Ping-External-0.12-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-4 - rebuild against perl 5.10.1 perl-Net-SCP-0.08-5.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.08-5 - rebuild against perl 5.10.1 perl-Net-SFTP-0.10-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-5 - rebuild against perl 5.10.1 perl-Net-SMTP-SSL-1.01-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-4 - rebuild against perl 5.10.1 perl-Net-SNMP-5.2.0-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 5.2.0-5 - rebuild against perl 5.10.1 perl-Net-SNPP-1.17-9.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.17-9 - rebuild against perl 5.10.1 perl-Net-SSH-0.09-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-4 - rebuild against perl 5.10.1 perl-Net-SSH-Perl-1.34-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.34-5 - rebuild against perl 5.10.1 perl-Net-SSH2-0.27-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.27-2 - rebuild against perl 5.10.1 perl-Net-SSLeay-1.35-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.35-8 - rebuild against perl 5.10.1 perl-Net-Server-0.97-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.97-8 - rebuild against perl 5.10.1 perl-Net-Stomp-0.34-5.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.34-5 - rebuild against perl 5.10.1 perl-Net-UPnP-1.41-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.41-5 - rebuild against perl 5.10.1 perl-Net-XMPP-1.02-8.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-8 - rebuild against perl 5.10.1 perl-Net-eBay-0.52-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.52-3 - rebuild against perl 5.10.1 perl-NetAddr-IP-4.027-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.027-2 - rebuild against perl 5.10.1 * Wed Sep 16 2009 Warren Togami - 4.027-1 - 4.027 perl-Newt-1.08-25.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.08-25 - rebuild against perl 5.10.1 perl-Nmap-Parser-1.19-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.19-3 - rebuild against perl 5.10.1 perl-Number-Compare-0.01-13.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-13 - rebuild against perl 5.10.1 perl-Number-Format-1.73-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.73-2 - rebuild against perl 5.10.1 perl-OLE-Storage_Lite-0.19-1.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-3 - rebuild against perl 5.10.1 * Mon Dec 07 2009 Tom "spot" Callaway - 0.19-1 - Update to 0.19 perl-ORLite-1.22-3.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.22-3 - rebuild against perl 5.10.1 perl-ORLite-Migrate-0.03-5.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-Object-Deadly-0.09-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-6 - rebuild against perl 5.10.1 perl-Object-Event-0.7-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.7-4 - rebuild against perl 5.10.1 perl-Object-InsideOut-3.56-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.56-2 - rebuild against perl 5.10.1 perl-Object-MultiType-0.05-4.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-Object-Realize-Later-0.18-7.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-7 - rebuild against perl 5.10.1 perl-Object-Signature-1.05-6.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-6 - rebuild against perl 5.10.1 perl-OpenFrame-3.05-11.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.05-11 - rebuild against perl 5.10.1 perl-PAR-0.994-2.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.994-2 - rebuild against perl 5.10.1 perl-PAR-Dist-0.46-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.46-2 - rebuild against perl 5.10.1 perl-PAR-Packer-0.991-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.991-5 - rebuild against perl 5.10.1 perl-PBS-0.33-6.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33-6 - rebuild against perl 5.10.1 perl-PDF-API2-0.73-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.73-3 - rebuild against perl 5.10.1 perl-PDF-Reuse-0.35-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-3 - rebuild against perl 5.10.1 perl-PDL-2.4.4_05-7.fc13 ------------------------ * Tue Dec 08 2009 Michael Schwendt - 2.4.4_05-7 - Explicitly BR hdf-static in accordance with the Packaging Guidelines (hdf-devel is still static-only). * Mon Dec 07 2009 Stepan Kasal - 2.4.4_05-6 - rebuild against perl 5.10.1 perl-PDL-Graphics-PLplot-0.51-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.51-4 - rebuild against perl 5.10.1 perl-PHP-Serialization-0.27-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.27-4 - rebuild against perl 5.10.1 perl-POE-1.269-2.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1.269-2 - rebuild against perl 5.10.1 perl-POE-API-Peek-1.34-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:1.34-2 - rebuild against perl 5.10.1 perl-POE-Component-Client-DNS-1.050-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.050-2 - rebuild against perl 5.10.1 perl-POE-Component-Client-Keepalive-0.2600-4.fc13 ------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2600-4 - rebuild against perl 5.10.1 perl-POE-Component-Client-LDAP-0.04-8.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.04-8 - rebuild against perl 5.10.1 perl-POE-Component-Client-SMTP-0.22-2.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.22-2 - rebuild against perl 5.10.1 perl-POE-Component-DBIAgent-0.26-6.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26-6 - rebuild against perl 5.10.1 perl-POE-Component-IRC-6.14-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 6.14-2 - rebuild against perl 5.10.1 perl-POE-Component-JobQueue-0.570-2.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.570-2 - rebuild against perl 5.10.1 perl-POE-Component-Log4perl-0.03-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-2 - rebuild against perl 5.10.1 perl-POE-Component-Logger-1.00-6.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-6 - rebuild against perl 5.10.1 perl-POE-Component-Pluggable-1.24-2.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.24-2 - rebuild against perl 5.10.1 perl-POE-Component-SNMP-1.1001-3.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1001-3 - rebuild against perl 5.10.1 perl-POE-Component-SSLify-0.15-3.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.15-3 - rebuild against perl 5.10.1 perl-POE-Component-Server-Bayeux-0.03-2.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-2 - rebuild against perl 5.10.1 perl-POE-Component-Server-HTTP-0.09-8.fc13 ------------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-8 - rebuild against perl 5.10.1 perl-POE-Component-Server-XMLRPC-0.05-7.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-7 - rebuild against perl 5.10.1 perl-POE-Component-SimpleDBI-1.27-3.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.27-3 - rebuild against perl 5.10.1 perl-POE-Component-SimpleLog-1.05-4.fc13 ---------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-4 - rebuild against perl 5.10.1 perl-POE-Filter-IRCD-2.40-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.40-3 - rebuild against perl 5.10.1 perl-POE-Filter-Transparent-SMTP-0.2-6.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2-6 - rebuild against perl 5.10.1 perl-POE-Filter-Zlib-2.02-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.02-3 - rebuild against perl 5.10.1 perl-POE-Wheel-Null-0.01-7.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-7 - rebuild against perl 5.10.1 perl-PPI-1.206-2.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1.206-2 - rebuild against perl 5.10.1 perl-PPI-HTML-1.07-6.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-6 - rebuild against perl 5.10.1 perl-PPI-Tester-0.06-8.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-8 - rebuild against perl 5.10.1 perl-PPIx-EditorTools-0.09-2.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-2 - rebuild against perl 5.10.1 perl-Package-Generator-0.103-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.103-2 - rebuild against perl 5.10.1 perl-PadWalker-1.9-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.9-2 - rebuild against perl 5.10.1 perl-Panotools-Script-0.22-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-3 - rebuild against perl 5.10.1 perl-Parallel-ForkManager-0.7.5-5.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.7.5-5 - rebuild against perl 5.10.1 perl-Params-CallbackRequest-1.19-4.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.19-4 - rebuild against perl 5.10.1 perl-Params-Coerce-0.14-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-5 - rebuild against perl 5.10.1 perl-Params-Util-1.00-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-3 - rebuild against perl 5.10.1 perl-Params-Validate-0.92-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-2 - rebuild against perl 5.10.1 perl-Parse-BACKPAN-Packages-0.35-2.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-2 - rebuild against perl 5.10.1 perl-Parse-CPAN-Meta-1.40-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.40-2 - rebuild against perl 5.10.1 perl-Parse-CPAN-Packages-2.31-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.31-3 - rebuild against perl 5.10.1 perl-Parse-ErrorString-Perl-0.11-5.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Parse-ExuberantCTags-1.01-2.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-2 - rebuild against perl 5.10.1 perl-Parse-Yapp-1.05-41.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-41 - rebuild against perl 5.10.1 perl-ParseLex-2.15-16.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.15-16 - rebuild against perl 5.10.1 perl-PatchReader-0.9.5-8.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.5-8 - rebuild against perl 5.10.1 perl-Path-Class-0.16-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.16-6 - rebuild against perl 5.10.1 perl-Perl-Critic-1.105-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.105-3 - rebuild against perl 5.10.1 perl-Perl-MinimumVersion-1.20-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.20-3 - rebuild against perl 5.10.1 perl-Perl-Tags-0.28-1.fc13 -------------------------- * Wed Dec 09 2009 Iain Arnell 0.28-1 - update to latest upstream version (now comes with a super-simple command line interface) - update BRs * Mon Dec 07 2009 Stepan Kasal - 0.26-3 - rebuild against perl 5.10.1 perl-Perl6-Bible-0.30-8.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.30-8 - rebuild against perl 5.10.1 perl-Perl6-Junction-1.40000-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.40000-4 - rebuild against perl 5.10.1 perl-PerlIO-eol-0.14-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-7 - rebuild against perl 5.10.1 perl-PerlIO-gzip-0.18-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-7 - rebuild against perl 5.10.1 perl-PerlIO-via-dynamic-0.12-7.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-7 - rebuild against perl 5.10.1 perl-PerlIO-via-symlink-0.05-8.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-8 - rebuild against perl 5.10.1 perl-Perlbal-XS-HTTPHeaders-0.19-8.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.19-8 - rebuild against perl 5.10.1 perl-Perlilog-0.3-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.3-4 - rebuild against perl 5.10.1 perl-Pipeline-3.12-9.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.12-9 - rebuild against perl 5.10.1 perl-PlRPC-0.2020-3.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.2020-3 - rebuild against perl 5.10.1 perl-Pod-Abstract-0.17-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.17-4 - rebuild against perl 5.10.1 perl-Pod-Coverage-0.20-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.20-4 - rebuild against perl 5.10.1 perl-Pod-POM-0.25-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.25-2 - rebuild against perl 5.10.1 perl-Pod-Readme-0.090-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.090-6 - rebuild against perl 5.10.1 perl-Pod-Simple-Wiki-0.09-8.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-8 - rebuild against perl 5.10.1 perl-Pod-Spell-1.01-7.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-7 - rebuild against perl 5.10.1 perl-Pod-Strip-1.02-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-6 - rebuild against perl 5.10.1 perl-Pod-Tests-1.19-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.19-4 - rebuild against perl 5.10.1 perl-Pod-Xhtml-1.59-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.59-3 - rebuild against perl 5.10.1 perl-PostScript-0.06-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-6 - rebuild against perl 5.10.1 perl-Probe-Perl-0.01-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-4 - rebuild against perl 5.10.1 perl-Proc-Daemon-0.03-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-5 - rebuild against perl 5.10.1 perl-Proc-ProcessTable-0.44-5.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.44-5 - rebuild against perl 5.10.1 perl-Proc-Simple-1.26-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.26-2 - rebuild against perl 5.10.1 perl-Pugs-Compiler-Rule-0.37-4.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-4 - rebuild against perl 5.10.1 perl-QWizard-3.15-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 3.15-4 - rebuild against perl 5.10.1 perl-RPM-Specfile-1.51-8.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.51-8 - rebuild against perl 5.10.1 perl-RPM2-0.68-5.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.68-5 - rebuild against perl 5.10.1 perl-RT-Client-REST-0.37-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-3 - rebuild against perl 5.10.1 perl-Razor-Agent-2.85-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.85-5 - rebuild against perl 5.10.1 perl-Readonly-1.03-11.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-11 - rebuild against perl 5.10.1 perl-Readonly-XS-1.05-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-3 - rebuild against perl 5.10.1 perl-Regexp-Assemble-0.34-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.34-4 - rebuild against perl 5.10.1 perl-Regexp-Common-2.122-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.122-4 - rebuild against perl 5.10.1 perl-Regexp-Copy-0.06-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.06-5 - rebuild against perl 5.10.1 perl-Regexp-Shellish-0.93-7.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.93-7 - rebuild against perl 5.10.1 perl-Return-Value-1.302-7.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.302-7 - rebuild against perl 5.10.1 perl-SDL-2.1.3-12.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 2.1.3-12 - rebuild against perl 5.10.1 perl-SGML-Parser-OpenSP-0.994-5.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.994-5 - rebuild against perl 5.10.1 perl-SGMLSpm-1.03ii-21.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03ii-21 - rebuild against perl 5.10.1 perl-SNMP-Info-2.01-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.01-3 - rebuild against perl 5.10.1 perl-SNMP_Session-1.12-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12-4 - rebuild against perl 5.10.1 perl-SQL-Abstract-1.60-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.60-2 - rebuild against perl 5.10.1 perl-SQL-Abstract-Limit-0.141-4.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.141-4 - rebuild against perl 5.10.1 perl-SQL-Library-0.0.3-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.0.3-6 - rebuild against perl 5.10.1 perl-SQL-Shell-1.14-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.14-4 - rebuild against perl 5.10.1 perl-SQL-Statement-1.20-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.20-2 - rebuild against perl 5.10.1 perl-SVG-2.49-4.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 2.49-4 - rebuild against perl 5.10.1 perl-SVG-Graph-0.02-4.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-4 - rebuild against perl 5.10.1 perl-SVG-Parser-1.03-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-4 - rebuild against perl 5.10.1 perl-SVK-2.2.1-5.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 2.2.1-5 - rebuild against perl 5.10.1 perl-Sane-0.03-3.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-3 - rebuild against perl 5.10.1 perl-Satcon-1.10-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.10-4 - rebuild against perl 5.10.1 perl-Scalar-Properties-0.13-6.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.13-6 - rebuild against perl 5.10.1 perl-Schedule-Cron-Events-1.8-19.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.8-19 - rebuild against perl 5.10.1 perl-Scope-Guard-0.03-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Scope-Upper-0.09-3.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.09-3 - rebuild against perl 5.10.1 perl-Search-Xapian-1.0.15.0-2.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0.15.0-2 - rebuild against perl 5.10.1 perl-Sendmail-PMilter-0.97-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.97-3 - rebuild against perl 5.10.1 perl-Set-Crontab-1.02-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-4 - rebuild against perl 5.10.1 perl-Set-Infinite-0.63-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.63-4 - rebuild against perl 5.10.1 perl-Set-IntSpan-1.13-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.13-5 - rebuild against perl 5.10.1 perl-Set-Object-1.26-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.26-6 - rebuild against perl 5.10.1 perl-Set-Scalar-1.23-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.23-4 - rebuild against perl 5.10.1 perl-Smart-Comments-v1.0.3-5.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:v1.0.3-5 - rebuild against perl 5.10.1 perl-Socket-GetAddrInfo-0.12-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-Socket6-0.23-3.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.23-3 - rebuild against perl 5.10.1 perl-Software-License-0.012-3.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.012-3 - rebuild against perl 5.10.1 perl-Sort-Key-1.28-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.28-3 - rebuild against perl 5.10.1 perl-Sort-Naturally-1.02-4.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-4 - rebuild against perl 5.10.1 perl-Sort-Versions-1.5-13.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.5-13 - rebuild against perl 5.10.1 perl-Spiffy-0.30-12.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.30-12 - rebuild against perl 5.10.1 perl-Spoon-0.24-6.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 0.24-6 - rebuild against perl 5.10.1 perl-Spreadsheet-ParseExcel-0.4900-4.fc13 ----------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.4900-4 - rebuild against perl 5.10.1 perl-Spreadsheet-ParseExcel-Simple-1.04-6.fc13 ---------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-6 - rebuild against perl 5.10.1 perl-Spreadsheet-WriteExcel-2.30-1.fc13 --------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.25-3 - rebuild against perl 5.10.1 * Mon Dec 07 2009 Tom "spot" Callaway - 2.30-1 - update to 2.30 perl-Spreadsheet-WriteExcel-Simple-1.04-6.fc13 ---------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.04-6 - rebuild against perl 5.10.1 perl-Statistics-Descriptive-2.6-6.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.6-6 - rebuild against perl 5.10.1 perl-String-Approx-3.26-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 3.26-8 - rebuild against perl 5.10.1 perl-String-CRC32-1.4-9.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4-9 - rebuild against perl 5.10.1 perl-String-Diff-0.04-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-4 - rebuild against perl 5.10.1 perl-String-Format-1.16-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.16-2 - rebuild against perl 5.10.1 perl-String-Random-0.22-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.22-5 - rebuild against perl 5.10.1 perl-String-RewritePrefix-0.004-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.004-3 - rebuild against perl 5.10.1 perl-String-ShellQuote-1.03-8.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.03-8 - rebuild against perl 5.10.1 perl-Sub-Exporter-0.982-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.982-4 - rebuild against perl 5.10.1 perl-Sub-Identify-0.04-7.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-7 - rebuild against perl 5.10.1 perl-Sub-Install-0.925-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.925-4 - rebuild against perl 5.10.1 perl-Sub-Name-0.04-5.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-5 - rebuild against perl 5.10.1 perl-Sub-Override-0.08-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-5 - rebuild against perl 5.10.1 perl-Sub-Uplevel-0.2002-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.2002-4 - rebuild against perl 5.10.1 perl-Sub-WrapPackages-1.3-2.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.3-2 - rebuild against perl 5.10.1 perl-Syntax-Highlight-Engine-Kate-0.04-6.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-6 - rebuild against perl 5.10.1 perl-Syntax-Highlight-Perl-Improved-1.01-3.fc13 ----------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-3 - rebuild against perl 5.10.1 perl-Sys-SigAction-0.11-3.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.11-3 - rebuild against perl 5.10.1 perl-Sys-Syscall-0.22-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.22-6 - rebuild against perl 5.10.1 perl-Sysadm-Install-0.33-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.33-2 - rebuild against perl 5.10.1 perl-SystemC-Vregs-1.463-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.463-3 - rebuild against perl 5.10.1 perl-TAP-Formatter-HTML-0.07-3.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.07-3 - rebuild against perl 5.10.1 perl-TAP-Harness-Archive-0.14-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-2 - rebuild against perl 5.10.1 perl-TAP-Harness-JUnit-0.32-4.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.32-4 - rebuild against perl 5.10.1 perl-Taint-Runtime-0.03-8.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.03-8 - rebuild against perl 5.10.1 perl-Task-Weaken-1.02-6.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.02-6 - rebuild against perl 5.10.1 perl-Template-Alloy-1.013-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.013-4 - rebuild against perl 5.10.1 perl-Template-GD-2.66-7.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.66-7 - rebuild against perl 5.10.1 perl-Template-Plugin-Class-0.14-3.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.14-3 - rebuild against perl 5.10.1 perl-Template-Plugin-JavaScript-0.01-4.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-4 - rebuild against perl 5.10.1 perl-Template-Provider-Encoding-0.10-5.fc13 ------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.10-5 - rebuild against perl 5.10.1 perl-Template-Timer-1.00-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-3 - rebuild against perl 5.10.1 perl-Template-Toolkit-2.22-2.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.22-2 - rebuild against perl 5.10.1 perl-Term-Completion-0.91-3.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.91-3 - rebuild against perl 5.10.1 perl-Term-ProgressBar-2.09-7.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.09-7 - rebuild against perl 5.10.1 perl-Term-Prompt-1.04-3.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.04-3 - rebuild against perl 5.10.1 perl-Term-ReadLine-Gnu-1.19-3.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.19-3 - rebuild against perl 5.10.1 perl-Term-ReadPassword-0.11-5.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Term-Size-0.2-5.fc13 ------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.2-5 - rebuild against perl 5.10.1 perl-Term-Size-Any-0.001-3.fc13 ------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.001-3 - rebuild against perl 5.10.1 perl-Term-Size-Perl-0.029-4.fc13 -------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.029-4 - rebuild against perl 5.10.1 perl-TermReadKey-2.30-9.fc13 ---------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.30-9 - rebuild against perl 5.10.1 perl-Test-Assert-0.0501-4.fc13 ------------------------------ * Fri Dec 04 2009 Stepan Kasal - 0.0501-4 - rebuild against perl 5.10.1 perl-Test-Assertions-1.054-3.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.054-3 - rebuild against perl 5.10.1 perl-Test-Base-0.58-3.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.58-3 - rebuild against perl 5.10.1 perl-Test-Block-0.11-5.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.11-5 - rebuild against perl 5.10.1 perl-Test-Class-0.33-2.fc13 --------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.33-2 - rebuild against perl 5.10.1 perl-Text-Markdown-1.000029-1.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.0.24-4 - rebuild against perl 5.10.1 * Fri Dec 04 2009 Iain Arnell 1.000029-1 - update to latest upstream version - perl-Text-MultiMarkdown split into separate package perl-Text-SpellChecker-0.05-4.fc13 ---------------------------------- * Fri Dec 04 2009 Stepan Kasal - 0.05-4 - rebuild against perl 5.10.1 perl-Text-Textile-2.12-3.fc13 ----------------------------- * Fri Dec 04 2009 Stepan Kasal - 2.12-3 - rebuild against perl 5.10.1 perl-Titanium-1.04-1.fc13 ------------------------- * Thu Dec 10 2009 Stepan Kasal - 1.04-1 - Update to 1.04 * Fri Dec 04 2009 Stepan Kasal - 1.03-2 - rebuild against perl 5.10.1 perl-URI-1.40-2.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 1.40-2 - rebuild against perl 5.10.1 perl-URI-Fetch-0.08-7.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-7 - rebuild against perl 5.10.1 perl-URI-Find-20090319-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 20090319-4 - rebuild against perl 5.10.1 perl-URI-FromHash-0.03-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-6 - rebuild against perl 5.10.1 perl-Unix-Syslog-1.1-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-4 - rebuild against perl 5.10.1 perl-User-1.8-6.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 1.8-6 - rebuild against perl 5.10.1 perl-User-Identity-0.92-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.92-6 - rebuild against perl 5.10.1 perl-V-0.13-2.fc13 ------------------ * Mon Dec 07 2009 Stepan Kasal - 0.13-2 - rebuild against perl 5.10.1 perl-VCS-LibCVS-1.0002-6.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0002-6 - rebuild against perl 5.10.1 perl-Variable-Magic-0.37-2.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.37-2 - rebuild against perl 5.10.1 perl-Verilog-3.212-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.212-2 - rebuild against perl 5.10.1 perl-Verilog-CodeGen-0.9.4-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.4-3 - rebuild against perl 5.10.1 perl-Verilog-Perl-3.222-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 3.222-2 - rebuild against perl 5.10.1 perl-Verilog-Readmem-0.04-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-3 - rebuild against perl 5.10.1 perl-WWW-Babelfish-0.16-5.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.16-5 - rebuild against perl 5.10.1 perl-WWW-Bugzilla-0.9-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9-5 - rebuild against perl 5.10.1 perl-WWW-Curl-4.09-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.09-3 - rebuild against perl 5.10.1 perl-WWW-Mechanize-GZip-0.12-2.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-WWW-Mechanize-TreeBuilder-1.10000-3.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.10000-3 - rebuild against perl 5.10.1 perl-WWW-Myspace-0.60-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.60-5 - rebuild against perl 5.10.1 perl-WWW-Pastebin-PastebinCom-Create-0.002-4.fc13 ------------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.002-4 - rebuild against perl 5.10.1 perl-WWW-Pastebin-RafbNet-Create-0.001-4.fc13 --------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.001-4 - rebuild against perl 5.10.1 perl-WWW-Search-2.507-5.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.507-5 - rebuild against perl 5.10.1 perl-Want-0.18-5.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.18-5 - rebuild against perl 5.10.1 perl-WebService-Validator-CSS-W3C-0.2-4.fc13 -------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.2-4 - rebuild against perl 5.10.1 perl-WebService-Validator-HTML-W3C-0.24-4.fc13 ---------------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.24-4 - rebuild against perl 5.10.1 perl-Workflow-1.32-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.32-3 - rebuild against perl 5.10.1 perl-Wx-0.92-2.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 0.92-2 - rebuild against perl 5.10.1 perl-Wx-Perl-DataWalker-0.02-6.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-6 - rebuild against perl 5.10.1 perl-Wx-Perl-ProcessStream-0.11-4.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-4 - rebuild against perl 5.10.1 perl-X11-Protocol-0.56-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.56-5 - rebuild against perl 5.10.1 perl-XML-Atom-0.35-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-3 - rebuild against perl 5.10.1 perl-XML-Atom-SimpleFeed-0.86-2.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.86-2 - rebuild against perl 5.10.1 perl-XML-DOM-1.44-7.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.44-7 - rebuild against perl 5.10.1 perl-XML-DOM-XPath-0.14-4.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.14-4 - rebuild against perl 5.10.1 perl-XML-Entities-0.03-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-XML-Feed-0.43-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.43-3 - rebuild against perl 5.10.1 perl-XML-Filter-BufferText-1.01-8.fc13 -------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-8 - rebuild against perl 5.10.1 perl-XML-Filter-XInclude-1.0-5.fc13 ----------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.0-5 - rebuild against perl 5.10.1 perl-XML-Generator-1.01-6.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.01-6 - rebuild against perl 5.10.1 perl-XML-Generator-DBI-1.00-8.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.00-8 - rebuild against perl 5.10.1 perl-XML-Grove-0.46alpha-40.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.46alpha-40 - rebuild against perl 5.10.1 perl-XML-Handler-YAWriter-0.23-8.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.23-8 - rebuild against perl 5.10.1 perl-XML-LibXML-1.70-4.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1:1.70-4 - rebuild against perl 5.10.1 perl-XML-LibXSLT-1.70-2.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.70-2 - rebuild against perl 5.10.1 perl-XML-Merge-1.2.565EgGd-6.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.2.565EgGd-6 - rebuild against perl 5.10.1 perl-XML-NamespaceSupport-1.10-2.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.10-2 - rebuild against perl 5.10.1 perl-XML-Parser-Lite-Tree-0.12-2.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-2 - rebuild against perl 5.10.1 perl-XML-RSS-1.45-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.45-2 - rebuild against perl 5.10.1 perl-XML-RSS-LibXML-0.3004-3.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3004-3 - rebuild against perl 5.10.1 perl-XML-RegExp-0.03-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-7 - rebuild against perl 5.10.1 perl-XML-SAX-Writer-0.50-8.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.50-8 - rebuild against perl 5.10.1 perl-XML-Simple-2.18-6.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.18-6 - rebuild against perl 5.10.1 perl-XML-Simple-DTDReader-0.04-5.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.04-5 - rebuild against perl 5.10.1 perl-XML-Smart-1.6.9-5.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.9-5 - rebuild against perl 5.10.1 perl-XML-Stream-1.22-12.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.22-12 - rebuild against perl 5.10.1 perl-XML-Tidy-1.2.54HJnFa-7.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.2.54HJnFa-7 - rebuild against perl 5.10.1 perl-XML-TokeParser-0.05-3.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 perl-XML-TreeBuilder-3.09-18.fc13 --------------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.09-18 - rebuild against perl 5.10.1 perl-XML-Twig-3.33-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 3.33-2 - rebuild against perl 5.10.1 perl-XML-Validator-Schema-1.10-4.fc13 ------------------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.10-4 - rebuild against perl 5.10.1 perl-XML-Writer-0.606-4.fc13 ---------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.606-4 - rebuild against perl 5.10.1 perl-XML-XPath-1.13-10.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.13-10 - rebuild against perl 5.10.1 perl-XML-XPathEngine-0.12-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-3 - rebuild against perl 5.10.1 perl-XML-XQL-0.68-9.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.68-9 - rebuild against perl 5.10.1 perl-XML-Xerces-2.7.0_0-14.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.7.0_0-14 - rebuild against perl 5.10.1 perl-XXX-0.12-4.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.12-4 - rebuild against perl 5.10.1 perl-YAML-0.70-3.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.70-3 - rebuild against perl 5.10.1 perl-YAML-LibYAML-0.32-4.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.32-4 - rebuild against perl 5.10.1 perl-YAML-Parser-Syck-0.01-14.fc13 ---------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.01-14 - rebuild against perl 5.10.1 perl-YAML-Syck-1.07-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.07-3 - rebuild against perl 5.10.1 perl-YAML-Tiny-1.40-2.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.40-2 - rebuild against perl 5.10.1 perl-accessors-1.01-3.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.01-3 - rebuild against perl 5.10.1 perl-aliased-0.30-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.30-2 - rebuild against perl 5.10.1 perl-asa-0.02-5.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.02-5 - rebuild against perl 5.10.1 perl-autobox-2.55-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 2.55-4 - rebuild against perl 5.10.1 perl-bioperl-1.6.1-3.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.1-3 - rebuild against perl 5.10.1 * Thu Nov 12 2009 Stepan Kasal - 1.6.1-2 - use the new filtering macros (cf #537138) perl-bioperl-run-1.6.1-3.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.1-3 - rebuild against perl 5.10.1 perl-boolean-0.20-5.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.20-5 - rebuild against perl 5.10.1 perl-capitalization-0.03-9.fc13 ------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-9 - rebuild against perl 5.10.1 perl-ccom-1.4.1-5.fc13 ---------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4.1-5 - rebuild against perl 5.10.1 perl-eperl-2.2.14-12.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.2.14-12 - rebuild against perl 5.10.1 perl-gettext-1.05-17.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.05-17 - rebuild against perl 5.10.1 perl-latest-0.03-2.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 0.03-2 - rebuild against perl 5.10.1 perl-libwhisker2-2.4-7.fc13 --------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.4-7 - rebuild against perl 5.10.1 perl-libwww-perl-5.833-2.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 5.833-2 - rebuild against perl 5.10.1 perl-libxml-perl-0.08-10.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.08-10 - rebuild against perl 5.10.1 perl-local-lib-1.004007-2.fc13 ------------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.004007-2 - rebuild against perl 5.10.1 perl-mogilefs-server-2.30-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 2.30-4 - rebuild against perl 5.10.1 perl-namespace-autoclean-0.09-3.fc13 ------------------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.09-3 - rebuild against perl 5.10.1 perl-namespace-clean-0.11-3.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.11-3 - rebuild against perl 5.10.1 perl-p5-Palm-1.011-2.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.011-2 - rebuild against perl 5.10.1 perl-parent-0.223-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 0.223-2 - rebuild against perl 5.10.1 perl-perlmenu-4.0-10.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 4.0-10 - rebuild against perl 5.10.1 perl-pgsql_perl5-1.9.0-5.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 1.9.0-5 - rebuild against perl 5.10.1 perl-pmtools-1.10-4.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.10-4 - rebuild against perl 5.10.1 perl-prefork-1.04-2.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 1.04-2 - rebuild against perl 5.10.1 perl-qooxdoo-compat-0.7.3-6.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.7.3-6 - rebuild against perl 5.10.1 * Wed Aug 12 2009 Ville Skytt? - 0.7.3-5 - Use upstream gzipped tarball instead of zip. perl-rpm-build-perl-0.6.8-4.fc13 -------------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.6.8-4 - rebuild against perl 5.10.1 pgadmin3-1.10.1-1.fc13 ---------------------- * Thu Dec 03 2009 Devrim GUNDUZ 1.10.1-1 - Update to 1.10.1 pgbouncer-1.3.1-2.fc13 ---------------------- * Sat Dec 05 2009 Devrim G?ND?Z - 1.3.1-2 - Fix init script, per report from Scott Bowers: http://lists.pgfoundry.org/pipermail/pgbouncer-general/2009-December/000477.html pgp-tools-1.1-4.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-4 - rebuild against perl 5.10.1 phonon-4.3.80-2.fc13 -------------------- * Thu Dec 03 2009 Rex Dieter - 4.3.50-6.20091203 - phonon-4.3.50 (20091203 snapshot) * Thu Dec 03 2009 Rex Dieter - 4.3.80-1.20091203 - phonon-4.3.80 (20091203 snapshot) * Thu Dec 03 2009 Rex Dieter - 4.3.80-2 - phonon-4.3.80 (upstream tarball, yes getting rediculous now) php-doctrine-Doctrine-1.2.1-1.fc13 ---------------------------------- * Tue Dec 08 2009 Christof Damian - 1.2.1-1 - upstream 1.2.1 php-pear-Mail-mimeDecode-1.5.1-1.fc13 ------------------------------------- * Thu Dec 03 2009 Remi Collet 1.5.1-1 - update to 1.5.1 - rename Mail_mimeDecode.xml to php-pear-Mail-mimeDecode.xml phpMyAdmin-3.2.4-1.fc13 ----------------------- * Thu Dec 03 2009 Robert Scheck 3.2.4-1 - Upstream released 3.2.4 (#540871, #540891) pianobooster-0.6.4-1.fc13 ------------------------- * Sun Dec 06 2009 Christian Krause - 0.6.4-1 - Update to new upstream version 0.6.4 - Fix icon permissions pidgin-2.6.4-4.fc13 ------------------- * Tue Dec 08 2009 Warren Togami - 2.6.4-4 - temporarily disable evolution integration in F13 until it is fixed * Mon Dec 07 2009 Stepan Kasal - 2.6.4-3 - rebuild against perl 5.10.1 * Wed Dec 02 2009 Warren Togami 2.6.4-2 - disable SILC in EL6 builds * Mon Nov 30 2009 Warren Togami 2.6.4-1 - 2.6.4 pisg-0.72-6.fc13 ---------------- * Mon Dec 07 2009 Stepan Kasal - 0.72-6 - rebuild against perl 5.10.1 pitivi-0.13.3-3.fc13 -------------------- * Thu Dec 03 2009 Jeffrey C. Ollie - 0.13.3-3 - Add Req on python-setuptools for BZ#540192 planner-0.14.4-7.fc13 --------------------- * Wed Dec 09 2009 Caol?n McNamara - 0.14.4-7 - Resolves: rhbz#545711 use GtkComboBoxEntry instead of GtkCombo * Thu Dec 03 2009 Caol?n McNamara - 0.14.4-6 - Resolves: rhbz#543741 use PlannerCalander in edit->task plymouth-0.8.0-0.2009129.fc13 ----------------------------- * Wed Dec 09 2009 Ray Strode 0.8.0-0.2009129 - Update to latest snapshot po4a-0.35-14.fc13 ----------------- * Mon Dec 07 2009 Stepan Kasal - 0.35-14 - rebuild against perl 5.10.1 polkit-qt-0.95-0.2.20091119svn.fc13 ----------------------------------- * Wed Dec 09 2009 Kevin Kofler - 0.95-0.2.20091119svn - Obsoletes: polkit-qt-examples < 0.10 for upgrade path postgis-1.4.1-rc2_1.fc13.2 -------------------------- * Thu Dec 03 2009 Devrim G?ND?Z - 1.4.1-rc2_1.2 - Fix spec per rawhide report. postgresql-8.4.1-5.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 8.4.1-5 - rebuild against perl 5.10.1 powermanga-0.90-7 ----------------- * Tue Dec 08 2009 Matthias Saou 0.90-7 - Remove coreutils scriplet requirements : Current guidelines don't require it, as we have "|| :" anyway. - Clean up desktop file. - Fix the build warning about config.ini being listed twice. proftpd-1.3.2c-1.fc13 --------------------- * Thu Dec 10 2009 Paul Howarth 1.3.2b-3 - Add patch for upstream bug 3350 - segfault on auth failures * Thu Dec 10 2009 Paul Howarth 1.3.2c-1 - Update to 1.3.2c, addressing the following issues: - SSL/TLS renegotiation vulnerability (CVE-2009-3555, bug 3324) - Failed database transaction can cause mod_quotatab to loop (bug 3228) - Segfault in mod_wrap (bug 3332) - sections can have problems (bug 3337) - mod_wrap2 segfaults when a valid user retries the USER command (bug 3341) - mod_auth_file handles 'getgroups' request incorrectly (bug 3347) - Segfault caused by scrubbing zero-length portion of memory (bug 3350) - Drop upstreamed segfault patch * Wed Dec 09 2009 Paul Howarth 1.3.2b-2 - Reduce the mod_facts patch to the single commit addressing the issue with directory names with glob characters (#521634), avoiding introducing a further problem with (#544002) proj-4.7.0-1.fc13 ----------------- * Fri Dec 04 2009 Devrim G?ND?Z 4.7.0-1 - Update to 4.7.0 - Update to new datumgrid (1.5) psacct-6.3.2-57.fc13 -------------------- * Wed Dec 09 2009 Ivana Hutarova Varekova - 6.2.3-57 - fix the initscript (service restart does not work) psi-0.14-1.fc13 --------------- * Thu Dec 03 2009 Aurelien Bompard - 0.14-1 - 0.14 final - patch1 merged upstream publican-1.3-0.fc13 ------------------- * Tue Dec 08 2009 Jeff Fearn 1.3-0 - Fixed --version BZ #533081 - Fixed empty params in new book cfg file. BZ #533322 - Fixed clean_ids taking too long. - Added nowait option for brew. - Improved epub support. BZ #536706 - Add missing rpm-build req. BZ #537970 - Changed ol ol style. BZ #537256 - Fix missing revision history field crash. BZ #539741 - Fix bug in condition logic in XmlClean. BZ #540685 - Add translation stats. BZ #540696 - Stopped processing xml files in extras dir. BZ #540383 - Fixed callout rendering. BZ #531686 - Fix wrong docs for condition usage. BZ #540691 - Remove list style from stepalternatives. BZ #511404 - Force step::para to keep-with-next if followed by a figure. - Edited Conventions.xml. - Exclude Legal_Notice.xml from pot creation. - Fix nested XML breaking translations. - Fix syntax highlighting adding whitespace. BZ #544141 - Better error message for Kate language mismatch. pulseaudio-0.9.21-3.fc13 ------------------------ * Tue Dec 08 2009 Michael Schwendt - 0.9.21-3 - Explicitly BR libatomic_ops-static in accordance with the Packaging Guidelines (libatomic_ops-devel is still static-only). puppet-0.25.1-1.fc13.1 ---------------------- * Thu Dec 03 2009 Todd Zullinger - 0.25.1-1.1 - Bump and rebuild to get 0.25.1 into rawhide * Wed Nov 25 2009 Jeroen van Meeuwen - 0.25.1-1 - New upstream version * Tue Oct 27 2009 Todd Zullinger - 0.25.1-0.3 - Update to 0.25.1 - Include the pi program and man page (R.I.Pienaar) * Sat Oct 17 2009 Todd Zullinger - 0.25.1-0.2.rc2 - Update to 0.25.1rc2 * Tue Sep 22 2009 Todd Zullinger - 0.25.1-0.1.rc1 - Update to 0.25.1rc1 - Move puppetca to puppet package, it has uses on client systems - Drop redundant %doc from manpage %file listings * Fri Sep 04 2009 Todd Zullinger - 0.25.0-1 - Update to 0.25.0 - Fix permissions on /var/log/puppet (#495096) - Install emacs mode and vim syntax files (#491437) - Install ext/ directory in %{_datadir}/puppet (/usr/share/puppet) pure-0.36-2.fc13 ---------------- * Tue Dec 08 2009 Michael Schwendt - 0.36-2 - Explicitly BR llvm-static in accordance with the Packaging Guidelines (llvm-devel is still static-only). pure-ftpd-1.0.27-1.fc13 ----------------------- * Fri Dec 04 2009 Aurelien Bompard - 1.0.27-1 - version 1.0.27 purple-facebookchat-1.64-1.fc13 ------------------------------- * Tue Dec 08 2009 Ismael Olea 1.64-1 - updating to 1.64 pykickstart-1.67-1.fc13 ----------------------- * Thu Dec 03 2009 Chris Lumens - 1.67-1 - Don't use action="append_const" in firewall.py. - Make "make archive" depend on test and check passing again. - versionToString now works in all cases we test for. - Fix the few pychecker errors outstanding in options.py. - Fix make docs to make docs dir before trying to download files there (hdegoede) python-BeautifulSoup-3.0.8-1.fc13 --------------------------------- * Sun Dec 06 2009 Terje Rosten - 1:3.0.8-1 - 3.0.8 - Fix source url python-argparse-1.0.1-1.fc13 ---------------------------- * Sun Dec 06 2009 Terje Rosten - 1.0.1-1 - 1.0.1 - Ship more docs - Project has moved - Disable test for now - Change license to Apache 2.0 python-cherrypy2-2.3.0-11.fc13 ------------------------------ * Fri Dec 04 2009 Toshio Kuratomi - 2.3.0-11 - Fix deprecation warnings. - Change setuptools BuildRequirement as we're back to one package in F-13. python-coverage-3.2-1.fc13 -------------------------- * Wed Dec 09 2009 Tom "spot" Callaway - 3.2-1 - update to 3.2 python-cryptsetup-0.0.10-2.fc13 ------------------------------- * Tue Dec 08 2009 Martin Sivak - 0.0.10-2 - add python-devel into build requires - change the Url so it uses git repo python-fiat-0.3.5-1.fc13 ------------------------ * Sun Dec 06 2009 Fabian Affolter - 0.3.5-1 - Updated to new upsteram version 0.3.5 python-inotify-0.8.8-1.fc13 --------------------------- * Sun Dec 06 2009 Terje Rosten - 0.8.8-1 - 0.8.8 python-ptrace-0.6.2-1.fc13 -------------------------- * Sat Dec 05 2009 Terje Rosten - 0.6.2-1 - 0.6.2 python-virtinst-0.500.1-2.fc13 ------------------------------ * Wed Dec 09 2009 Cole Robinson - 0.500.1-2.fc13 - Fix interface API detection for libvirt < 0.7.4 * Thu Dec 03 2009 Cole Robinson - 0.500.1-1.fc13 - Update to version 0.500.1 - virt-install now attempts --os-variant detection by default. - New --disk option 'format', for creating image formats like qcow2 or vmdk - Many improvements and bugfixes qbittorrent-2.0.0-1.fc13 ------------------------ * Thu Dec 10 2009 Leigh Scott - 2.0.0-1 - update to 2.0.0 * Mon Dec 07 2009 Leigh Scott - 2.0.0-0.11.svn3054 - update to svn 3054 - add Br: libnotify-devel * Mon Dec 07 2009 Leigh Scott - 2.0.0-0.12.svn3054 - change requires qt4 * Mon Dec 07 2009 Leigh Scott - 2.0.0-0.13.svn3058 - update to svn 3058 (RC6) * Sun Dec 06 2009 Leigh Scott - 2.0.0-0.10.svn3043 - update to svn 3043 qosmic-1.4.2-4.fc13 ------------------- * Tue Dec 08 2009 Michael Schwendt - 1.4.2-4 - Explicitly BR flam3-static in accordance with the Packaging Guidelines (flam3-devel is still static-only). qt-4.6.0-2.fc13 --------------- * Sat Dec 05 2009 Kevin Kofler - 4.6.0-2 - own %{_qt4_plugindir}/gui_platform queuegraph-1.1-7.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1.1-7 - rebuild against perl 5.10.1 remctl-2.11-10.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 2.11-10 - rebuild against perl 5.10.1 remoot-0.9-7.fc13 ----------------- * Mon Dec 07 2009 Stepan Kasal - 0.9-7 - rebuild against perl 5.10.1 resource-agents-3.0.6-1.fc13 ---------------------------- * Mon Dec 07 2009 Andrew Beekhof - 3.0.5-2 - Update Pacameker agents to upstream version: bc00c0b065d9 + High: RA: introduce OCF_FUNCTIONS_DIR, allow it to be overridden (LF2239) + High: doc: add man pages for all RAs (LF2237) + High: syslog-ng: new RA + High: vmware: make meta-data work and several cleanups (LF 2212) + Medium: .ocf-shellfuncs: add ocf_is_probe function + Medium: Dev: make RAs executable (LF2239) + Medium: IPv6addr: ifdef out the ip offset hack for libnet v1.1.4 (LF 2034) + Medium: add mercurial repository version information to .ocf-shellfuncs + Medium: build: add perl-MailTools runtime dependency to ldirectord package (LF 1469) + Medium: iSCSITarget, iSCSILogicalUnit: support LIO + Medium: nfsserver: use check_binary properly in validate (LF 2211) + Medium: nfsserver: validate should not check if nfs_shared_infodir exists (thanks to eelco at procolix.com) (LF 2219) + Medium: oracle/oralsnr: export variables properly + Medium: pgsql: remove the previous backup_label if it exists + Medium: postfix: fix double stop (thanks to Dinh N. Quoc) + RA: LVM: Make monitor operation quiet in logs (bnc#546353) + RA: Xen: Remove instance_attribute "allow_migrate" (bnc#539968) + ldirectord: OCF agent: overhaul * Mon Dec 07 2009 Fabio M. Di Nitto - 3.0.6-1 - New rgmanager resource agents upstream release - spec file update: * use global instead of define * use new Source0 url * use resource-agents macro more aggressively rgmanager-3.0.6-1.fc13 ---------------------- * Mon Dec 07 2009 Fabio M. Di Nitto - 3.0.6-1 - New upstream release - spec file cleanup: * use global instead of define * use new Source0 url * use rgmanager macro more aggressively rhythmbox-0.12.6-4.fc13 ----------------------- * Thu Dec 10 2009 Bastien Nocera 0.12.6-3 - Fix crasher in WebKit when using the context pane (#540672) * Thu Dec 10 2009 Bastien Nocera 0.12.6-4 - Fix crasher when musicbrainz cannot read a disc (#546188) * Mon Dec 07 2009 Bastien Nocera 0.12.6-2 - Remove libhal requirement ricci-0.16.1-6.fc13 ------------------- * Thu Dec 10 2009 Ryan McCabe - 0.16.1-6 - Add a ricci function to set the cluster version, as it's no longer done while syncing the configuration files via ccs_sync. * Wed Dec 09 2009 Ryan McCabe - 0.16.1-5 - Don't update the cluster version via cman_set_version rpm-4.8.0-0.beta1.3 ------------------- * Wed Dec 09 2009 Panu Matilainen - 4.8.0-0.beta1.3 - fix a bunch of python refcount-errors causing major memory leaks * Mon Dec 07 2009 Panu Matilainen - 4.8.0-0.beta1.1 - update to 4.8.0-beta1 (http://rpm.org/wiki/Releases/4.8.0) - rpm-build conflicts with current ocaml-runtime * Mon Dec 07 2009 Panu Matilainen - 4.8.0-0.beta1.2 - fix noise from python bytecompile on non-python packages (#539635) - make all our -devel [build]requires isa-specific - trim out superfluous -devel dependencies from rpm-devel * Fri Dec 04 2009 Panu Matilainen - 4.7.2-2 - missing error exit code from signing password checking (#496754) - dont fail build on unrecognized data files (#532489) - dont try to parse subkeys and secret keys (#436812) - fix chmod test on selinux, breaking %{_fixperms} macro (#543035) rpmconf-0.1.8-2.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.1.8-2 - rebuild against perl 5.10.1 rpmdevtools-7.6-1.fc13 ---------------------- * Mon Dec 07 2009 Ville Skytt? - 7.6-1 - Update to 7.6, fixes #528907. rpmorphan-1.4-7.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 1.4-7 - rebuild against perl 5.10.1 rsync-3.0.6-4.fc13 ------------------ * Mon Dec 07 2009 Jan Zeleny - 3.0.6-4 - applied patch to avoid retouching dir permissions (#542679) rsyslog-4.4.2-2.fc13 -------------------- * Wed Dec 09 2009 Robert Scheck 4.4.2-2 - run libtoolize to avoid errors due mismatching libtool version * Thu Dec 03 2009 Tomas Heinrich 4.4.2-1 - upgrade to new upstream stable version 4.4.2 - add support for arbitrary number of open file descriptors rt3-3.8.6-1.fc13 ---------------- * Fri Dec 04 2009 Ralf Cors?pius - 3.8.5-2 - Add rt-3.8.4-rh-bz543962.diff (BZ #543962). * Fri Dec 04 2009 Ralf Cors?pius - 3.8.6-1 - Upstream update. - Remove rt-3.8.4-Makefile.diff, rt-3.8.4-test-dependencies.diff, rt-3.8.4-rh-bz543962.diff. - Add rt-3.8.6-Makefile.diff, rt-3.8.6-test-dependencies.diff ruby-1.8.6.383-5.fc13 --------------------- * Wed Dec 09 2009 Mamoru Tasaka - 1.8.6.383-5 - Change mkmf.rb to use LIBRUBYARG_SHARED so that have_library() works without libruby-static.a (bug 428384) - And move libruby-static.a to -static subpackage ruby-icon-artist-0.1.92-1.fc13 ------------------------------ * Sat Dec 05 2009 Martin Sourada - 0.1.92-1 - New upstream release - Workaround broken remote branches name detection by rubygem(git) - Better icon name detection rubygem-activeldap-1.2.0-4.fc13 ------------------------------- * Fri Dec 04 2009 Mamoru Tasaka - 1.2.0-4 - Change the dependency against locale/gettext/active* from "strictly equal (=)" to "not less than (>=)" (bug 542917) rubygem-rake-compiler-0.7.0-1.fc13 ---------------------------------- * Thu Dec 10 2009 Mamoru Tasaka - 0.7.0-1 - 0.7.0 rubygem-rspec-1.2.9-1.fc13 -------------------------- * Wed Dec 09 2009 Michael Stahnke - 1.2.9-1 - New Version rxvt-unicode-9.06-5.fc13 ------------------------ * Mon Dec 07 2009 Stepan Kasal - 9.06-5 - rebuild against perl 5.10.1 sabayon-2.29.2-1.fc13 --------------------- * Wed Dec 09 2009 Tomas Bzatek - 2.29.2-1 - Update to 2.29.2 sblim-indication_helper-0.4.2-4.fc13 ------------------------------------ * Mon Dec 07 2009 Praveen K Paladugu - 0.4.2-4 - fixed the build failure because of missing definition of stderr scalapack-1.7.5-8.fc13 ---------------------- * Wed Dec 09 2009 Tom "spot" Callaway - 1.7.5-8 - drop lam support (Provides/Obsoletes by mpich2, which is a hack, but something's gotta do it) - move static libs to static subpackages (resolves bz 545150) sdcc-2.9.0-7.fc13 ----------------- * Sun Dec 06 2009 Conrad Meyer - 2.9.0-6 - Work around rpmbuild failure by disabling brp-strip. * Sun Dec 06 2009 Conrad Meyer - 2.9.0-7 - Only disable brp-strip-static. * Fri Sep 11 2009 Conrad Meyer - 2.9.0-5 - Fix a bug with single-bit types, logical NOT, and casting to char (I'm fuzzy on the details) that was reported by a Fedora user with the r5508 patch from upstream. sec-2.5.3-0.fc13 ---------------- * Thu Dec 10 2009 Stefan Schulze Frielinghaus - 2.5.3-0 - New upstream release selinux-policy-3.7.4-1.fc13 --------------------------- * Fri Dec 04 2009 Dan Walsh 3.7.4-1 - Update to upstream release sepostgresql-8.4.1-2464.fc13 ---------------------------- * Tue Dec 08 2009 KaiGai Kohei - 8.4.1-2464 - rework: backport features from v8.5devel tree - fixbug: selinux netlink receiver process didn't have correct ps display setroubleshoot-2.2.52-1.fc13 ---------------------------- * Thu Dec 03 2009 Dan Walsh - 2.2.52-1 - Fix ignore button - Add delete button setup-2.8.11-1.fc13 ------------------- * Thu Dec 03 2009 Ondrej Vasik 2.8.11-1 - don't have HISTCONTROL ignorespace by default (#520632), but do not override it when it is already set - add csync alias for port 2005 / tcp, udp shorewall-4.4.4.2-3.fc13 ------------------------ * Thu Dec 10 2009 Jonathan G. Underwood - 4.4.4.2-1 - Update to 4.4.4.2 * Thu Dec 10 2009 Jonathan G. Underwood - 4.4.4.2-2 - Add logrotate files to packages * Thu Dec 10 2009 Jonathan G. Underwood - 4.4.4.2-3 - Fix typo in logrotate script name for shorewall6-lite shutter-0.85.1-1.fc13 --------------------- * Mon Dec 07 2009 Liang Suilong - 0.85.1-1 - Upgrade to shutter-0.85.1 skinlf-6.7-10.cvs20091205.fc13 ------------------------------ * Sat Dec 05 2009 6.7-10.cvs20091205 - Additional ASL Files slang-2.2.2-1.fc13 ------------------ * Mon Dec 07 2009 Miroslav Lichvar - 2.2.2-1 - update to 2.2.2 smbldap-tools-0.9.5-6.fc13 -------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.5-6 - rebuild against perl 5.10.1 smc-fonts-04.2-3.fc13 --------------------- * Wed Dec 09 2009 Pravin Satpute 04.2-3 - bugfix 545683 sos-1.8-18.fc12 --------------- * Thu Nov 05 2009 Adam Stokes - 1.8-18 - Option to enable selinux fixfiles check - Start of replacing Thread module with multiprocessing - Update translations - More checks against conf file versus command line opts spamassassin-3.3.0-0.21.beta1.fc13 ---------------------------------- * Thu Dec 03 2009 Warren Togami - 3.3.0-0.21.beta1 - 3.3.0-beta1 springlobby-0.40-1.fc13 ----------------------- * Sun Dec 06 2009 Aurelien Bompard - 0.40-1 - version 0.40 sqlite-3.6.21-1.fc13 -------------------- * Tue Dec 08 2009 Panu Matilainen - 3.6.21-1 - update to 3.6.21 (http://www.sqlite.org/releaselog/3_6_21.html) sshmenu-3.18-1.fc13 ------------------- * Tue Dec 08 2009 Matthias Saou 3.18-1 - Update to 3.18. - Rebased both patches for the Makefile changes. - Fix scriplets by adding "|| :" for touch. - Include new bash_completion.d as-is since all packages seem to do it. stfl-0.21-8.fc13 ---------------- * Mon Dec 07 2009 Stepan Kasal - 0.21-8 - rebuild against perl 5.10.1 stunnel-4.29-1.fc13 ------------------- * Wed Dec 09 2009 Avesh Agrwal - 4.29-1 - New upstream realease 4.29 - Updated authpriv and sample patches for the new release - Modified spec file to include dist tag subversion-1.6.6-4.fc13 ----------------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.6-4 - rebuild against perl 5.10.1 suck-4.3.2-29.fc13 ------------------ * Mon Dec 07 2009 Stepan Kasal - 4.3.2-29 - rebuild against perl 5.10.1 sugar-artwork-0.87.1-1.fc13 --------------------------- * Sat Dec 05 2009 Mathieu Bridon - 0.87.1-1 - New upstream release sunbird-1.0-0.16.20090916hg.fc13 -------------------------------- * Wed Dec 09 2009 Jan Horak - 1.0-0.16.20090916hg - Rebuild against new Thunderbird * Thu Dec 03 2009 Jan Horak - 1.0-0.15.20090916hg - Rebuild against new Thunderbird surl-0.6.1-1.fc13 ----------------- * Sat Dec 05 2009 Fabian Affolter - 0.6.1-1 - Changed source url - Updated to new upstream version 0.6.1 * Tue Aug 11 2009 Ville Skytt? - 0.5.4-2 - Use bzipped upstream tarball. svnkit-1.3.2-1.fc13 ------------------- * Thu Dec 03 2009 Alexander Kurtakov 1.3.2-1 - Update to 1.3.2. swatch-3.2.1-5.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 3.2.1-5 - rebuild against perl 5.10.1 swig-1.3.40-2.fc13 ------------------ * Mon Dec 07 2009 Adam Tkac 1.3.40-2 - package review related fixes (#226442) synaptic-0.57.2-22.fc13 ----------------------- * Mon Dec 07 2009 Panu Matilainen - 0.57.2-22 - rebuild for rpm 4.8.0 - drop nss-hack patch, it shouldn't be needed with rpm >= 4.7.1 syncevolution-0.9.2+1.0alpha1-1.fc13 ------------------------------------ * Thu Dec 03 2009 Peter Robinson - 0.9.2+1.0alpha1-1 - Update to 1.0.0 alpha 1 synergy-plus-1.3.4-5.fc13 ------------------------- * Mon Dec 07 2009 Matthias Saou 1.3.4-5 - Obsolete synergy (last upstream released version is from 2006) since synergy+ is a drop-in replacement (#538179). system-config-kdump-2.0.2-1.fc13 -------------------------------- * Mon Dec 07 2009 Roman Rakus - 2.0.2-1 - Don't be interested in non linux entries in bootloaders conf Resolves: #538850 system-config-kickstart-2.8.3-1.fc13 ------------------------------------ * Fri Dec 04 2009 Chris Lumens - 2.8.3-1 - Add ext4, make it the default (#544079). - Add support for authconfig --enablefingerprint (#539371). - Fix an import error (#530739, nelsoninva AT gmail.com). - Update lots of translations. * Mon Sep 14 2009 Ville Skytt? - 2.8.2-2 - Convert specfile to UTF-8. system-config-language-1.3.3-4.fc13 ----------------------------------- * Thu Dec 10 2009 Pravin Satpute - 1.3.3-4 - updated URL and source field * Mon Oct 26 2009 Pravin Satpute - 1.3.3-3 - fixed 530698 system-config-network-1.5.99-2.fc13 ----------------------------------- * Mon Dec 07 2009 Jiri Popelka 1.5.99-2 - Fixed s-control-network crash when adding new modem (bz #544412) system-config-printer-1.1.15-7.fc13 ----------------------------------- * Wed Dec 09 2009 Tim Waugh - 1.1.15-7 - Fixed jobviewer traceback with short-lived state reasons (bug #545733). * Tue Dec 08 2009 Tim Waugh - 1.1.15-6 - Fixed traceback with short lpd device URIs (bug #545397). * Mon Dec 07 2009 Tim Waugh - 1.1.15-5 - Fixed traceback when troubleshooter operation is cancelled (bug #544356). * Thu Dec 03 2009 Tim Waugh - 1.1.15-2 - Handle RuntimeError when localizing state reason (bug #543937). * Thu Dec 03 2009 Tim Waugh - 1.1.15-3 - Fixed cupsd.conf parsing when lines begin with blanks (bug #544003). - Don't overwrite BrowsePoll settings in basic settings dialog (bug #543986). sysusage-2.10-3.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 2.10-3 - rebuild against perl 5.10.1 tangogps-0.99.2-1.fc13 ---------------------- * Thu Dec 03 2009 Peter Robinson 0.99.2-1 - New upstream 0.99.2 release tar-1.22-11.fc13 ---------------- * Tue Dec 08 2009 Ondrej Vasik 2:1.22-11 - fix segfault with corrupted metadata in code_ns_fraction (#531441) - commented patches and sources task-1.8.5-2.fc13 ----------------- * Sat Dec 05 2009 Federico Hernandez - 1.8.5-1 Intial RPM for task bugfix release 1.8.5 * Sat Dec 05 2009 Federico Hernandez - 1.8.5-2 Fixed wrong ChangeLog file telepathy-gabble-0.8.9-1.fc13 ----------------------------- * Mon Dec 07 2009 Brian Pepple - 0.8.9-1 - Update to 0.8.9. - Drop proxy patch. Fixed upstream. telepathy-glib-0.9.2-1.fc13 --------------------------- * Thu Dec 03 2009 Brian Pepple - 0.9.2-1 - Update to 0.9.2. terminus-fonts-4.30-1.fc13 -------------------------- * Fri Dec 04 2009 Hans Ulrich Niedermann - 4.30-1 - update to 4.30 release: - new size 22 (not very good) - 25 additional characters - various small fixes tesseract-langpack-2.00-6 ------------------------- * Thu Dec 10 2009 Karol Trzcionka - 2.00-5 - Fix typo * Thu Dec 10 2009 Karol Trzcionka - 2.00-6 - Delete %{?dist} macro texlive-texmf-2007-34.fc13 -------------------------- * Fri Dec 04 2009 Jindrich Novy 2007-34 - fix permissions of /var/lib/texmf/web2c (#512459, #531894) - add IEEEconf (#495877) - update achemso (#521459) - update perltex to 2.0 from CTAN - obsolete tetex-perltex thunderbird-3.0-4.fc13 ---------------------- * Wed Dec 09 2009 Jan Horak - 3.0-4 - Update to 3.0 * Thu Dec 03 2009 Jan Horak - 3.0-3.13.rc2 - Update to RC2 tidy-0.99.0-20.20091203.fc13 ---------------------------- * Thu Dec 03 2009 Rex Dieter - 0.99.0-20.20091203 - 20091203 snapshot - spec housecleaning - Tidy erroniously removes whitespace, causing mangled text (#481350) tk-8.5.7-3.fc12 --------------- * Wed Dec 09 2009 Nikola Pajkovsky - 1:8.5.7-3 - Resolves: #545807 - Color hash problem on x86_64 toped-0.9.51-1.fc13 ------------------- * Thu Dec 10 2009 Chitlesh Goorah - 0.9.51-1 - 0.9.51 release to fix start-up crash with Mesa DRI on Intel(R) 945GM - RHBZ 541879 tor-0.2.1.20-1301.fc13 ---------------------- * Sun Dec 06 2009 Enrico Scholz - 0.2.1.20-1301 - updated -upstart to upstart 0.6.3 trac-0.11.6-1.fc13 ------------------ * Sat Dec 05 2009 Felix Schwarz - 0.11.6-1 - New upstream release tre-0.8.0-1.fc13 ---------------- * Sun Sep 20 2009 Dominik Mierzejewski 0.8.0-1 - updated to 0.8.0 (ABI change) trytond-1.4.3-1.fc13 -------------------- * Thu Dec 10 2009 Dan Hor?k 1.4.3-1 - update to upstream version 1.4.3 tsclient-2.0.2-6.fc13 --------------------- * Thu Dec 03 2009 Matthias Clasen - 2.0.2-6 - Don't ship .la files tucan-0.3.9-0.3.alpha.fc13 -------------------------- * Sun Dec 06 2009 Simon Wesp - 0.3.9-0.3.alpha - RHBZ #544653 tuned-0.2.6-1.fc13 ------------------ * Tue Dec 08 2009 Phil Knirsch 0.2.6-1 - Included Jan Vcelak's patch for pyo and pyc files - Updated ktune.sh script for laptop-battery-powersave profile with latest ALPM mechanism - Fixed ktune.sh script for laptop-battery-powersave profile to stop printing errors when files in /sys are missing tuxguitar-1.2-2.fc13 -------------------- * Sat Nov 28 2009 Orcan Ogetbil > - 1.2-2 - Change build system (we'll use our build-fedora.xml rather than patching Debian's Makefile). - Disable system tray and oss plugins by default. - Make fluidsynth/alsa/fluid soundfont combination the default output so that the software works out of the box. twinkle-1.4.2-4.fc13 -------------------- * Mon Nov 23 2009 Kevin Fenzi - 1.4.2-4 - Add patch for Fedora talk in the providers list - bug 530629 udunits-1.12.9-6.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 1.12.9-6 - rebuild against perl 5.10.1 ufraw-0.16-1.fc13 ----------------- * Sat Dec 05 2009 Dennis Gilmore - 0.16-1 - update to 0.16 unetbootin-0-7.377bzr.fc13 -------------------------- * Sun Dec 06 2009 Jussi Lehtola - 0-7.377bzr - Update to revision 377. unhide-1.0-5.fc13.20090810 -------------------------- * Fri Dec 04 2009 Rakesh Pandit 1.0-5.20090810 - Updated to 20090810 up-imapproxy-1.2.7-0.7.rc3.fc13 ------------------------------- * Fri Dec 04 2009 Rakesh Pandit 1.2.7-0.7.rc3 - Updated to 1.2.7-0.7.rc3 upstart-0.6.3-3.fc13 -------------------- * Thu Dec 03 2009 Bill Nottingham 0.6.3-3 - make 'telinit u' a no-op, temporarily * Fri Nov 27 2009 Petr Lautrbach 0.6.3-2 - Removed tests which fail in koji * Fri Nov 20 2009 Casey Dahlin - 0.6.3-1 - Upgrade to 0.6.3 usbmuxd-1.0.0-1.fc13 -------------------- * Mon Dec 07 2009 Peter Robinson 1.0.0-1 - New stable 1.0.0 release util-linux-ng-2.17-0.5.fc13 --------------------------- * Wed Dec 09 2009 Karel Zak 2.17-0.5 - upgrade to 2.17-rc2 ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.17/v2.17-rc2-ChangeLog * Mon Dec 07 2009 Karel Zak 2.17-0.4 - add clock.8 man page (manlink to hwclock) - add --help to mount.tmpfs uuid-1.6.1-9.fc13 ----------------- * Mon Dec 07 2009 Stepan Kasal - 1.6.1-9 - rebuild against perl 5.10.1 vegastrike-0.5.0-15.fc13 ------------------------ * Thu Dec 10 2009 Hans de Goede 0.5.0-15 - Rebuild for silent boost-python ABI breakage (#540277) vhostmd-0.4-2.fc13 ------------------ * Thu Dec 10 2009 Richard W.M. Jones - 0.4-2 - Fix the PagedOutMemory and PagedInMemory stats to report MB instead of pages (fixes supplied by Joachim Schneider). * Wed Dec 09 2009 Richard W.M. Jones - 0.4-1 - vhostmd didn't chdir ("/") when daemonizing. Fixed in this 0.4 release. vim-7.2.315-2.fc13 ------------------ * Mon Dec 07 2009 Stepan Kasal - 2:7.2.315-2 - rebuild against perl 5.10.1 * Thu Dec 03 2009 Karsten Hopp 7.2.315-1 - patchlevel 315 - fix vimrc location in man page (#456992) - correct syntax highlighting of httpd config files in /etc/httpd (#499123) - Buildrequire ruby, ruby-devel (#503872) - Remove check for static gravity (#510307) - sort tags file (#517725) - use one gvim to open multiple file selections from nautilus (#519265) - use elinks -source instead of elinks -dump (#518791) - add ext4 keyword to /etc/fstab syntax highlighting (#498290) * Mon Nov 09 2009 Karsten Hopp 7.2.284-1 - patchlevel 284 vinagre-2.29.1-1.fc13 --------------------- * Fri Dec 04 2009 Matthias Clasen 2.29.1-1 - 2.29.1 virt-manager-0.8.1-3.fc13 ------------------------- * Wed Dec 09 2009 Cole Robinson - 0.8.1-3.fc13 - Select manager row on right click, regressed with 0.8.1 * Sat Dec 05 2009 Cole Robinson - 0.8.1-2.fc13 - Set proper version Requires: for python-virtinst * Thu Dec 03 2009 Cole Robinson - 0.8.1-1.fc13 - Update to release 0.8.1 - VM Migration wizard, exposing various migration options - Enumerate CDROM and bridge devices on remote connections - Support storage pool source enumeration for LVM, NFS, and SCSI virt-v2v-0.3.2-2.fc13 --------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3.2-2 - rebuild against perl 5.10.1 virtaal-0.5.0-1.fc13 -------------------- * Thu Dec 03 2009 Dwayne Bailey - 0.5.0-1 - Update to 0.5.0 final - Correctly support Open-Tran for languages with regional modifiers - Web requests now accept compressed responses if the server offers it - New translations: Ukrainian. - Various bug fixes - Drop Korean translation fix * Tue Dec 01 2009 Dwayne Bailey - 0.5.0-0.2.rc1 - Typo in postun vlgothic-fonts-20091202-1.fc13 ------------------------------ * Mon Dec 07 2009 Akira TAGOH - 20091202-1 - New upstream release. - Set the priority to 65 for vlgothic-p-fonts to override the rule in vlgothic-fonts for sans-serif. - Set the priority to 66 and contains both rules for sans-serif and monospace to avoid picking up the unrelated fonts in Live. where doesn't have vlgothic-p-fonts installed. (#544957) voms-mysql-plugin-3.1.3.1-1.fc13 -------------------------------- * Thu Dec 03 2009 Mattias Ellert - 3.1.3.1-1 - Update to version 3.1.3.1. vpnc-0.5.3-7.fc13 ----------------- * Wed Dec 09 2009 Bill Nottingham - 0.5.3-7 - Adjust for upstart 0.6 vrq-1.0.67-1.fc13 ----------------- * Fri Dec 04 2009 Shakthi Kannan - 1.0.67-1 - Updated to upstream package 1.0.67 vte-0.23.1-1.fc13 ----------------- * Thu Dec 03 2009 Behdad Esfahbod 0.23.1-1 - Update to 0.23.1 webkitkde-0.0.3-0.2.svn1057318.fc13 ----------------------------------- * Thu Dec 03 2009 Alexey Kurov - 0.0.3-0.2.svn1057318 - svn 1057318 weechat-0.3.0-3.fc13 -------------------- * Mon Dec 07 2009 Stepan Kasal - 0.3.0-3 - rebuild against perl 5.10.1 wgrib2-1.8.2-3.fc13 ------------------- * Tue Dec 08 2009 Michael Schwendt - 1.8.2-3 - Explicitly BR g2clib-static in accordance with the Packaging Guidelines (g2clib-devel is still static-only). whatsup-1.9-3.fc13 ------------------ * Mon Dec 07 2009 Stepan Kasal - 1.9-3 - rebuild against perl 5.10.1 workrave-1.9.1-1.fc13 --------------------- * Wed Dec 09 2009 Tomas Mraz - 1.9.1-1 - new upstream version x3270-3.3.10ga4-1.fc13 ---------------------- * Tue Dec 08 2009 Karsten Hopp 3.3.10ga4-1 - update to 3.3.10ga4-1 xchat-2.8.6-14.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 1:2.8.6-14 - rebuild against perl 5.10.1 xchat-gnome-0.26.1-6.fc13 ------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.26.1-6 - rebuild against perl 5.10.1 xdelta-1.1.4-9.fc13 ------------------- * Thu Dec 03 2009 Adam Tkac 1.1.4-9 - use appropriate BuildRoot xemacs-21.5.29-9.fc13 --------------------- * Tue Dec 08 2009 Jerry James - 21.5.29-9 - Add patch to use memmove in etags (bz 545399). xemacs-packages-extra-20090217-7.fc13 ------------------------------------- * Fri Dec 04 2009 Jerry James - 20090217-7 - Fix one more ediff problem found during testing (bz 537531). xen-3.4.2-2.fc13 ---------------- * Thu Dec 10 2009 Gerd Hoffmann - 3.4.2-1 - update to 3.4.2 release. - drop backport patches. * Thu Dec 10 2009 Gerd Hoffmann - 3.4.2-2 - adapt module load script to evtchn.ko -> xen-evtchn.ko rename. * Thu Oct 08 2009 Justin M. Forbes - 3.4.1-5 - add PyXML to dependencies. (#496135) - Take ownership of {_libdir}/fs (#521806) xfconf-4.6.1-5.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 4.6.1-5 - rebuild against perl 5.10.1 xfsprogs-3.0.3-5.fc13 --------------------- * Tue Dec 08 2009 Eric Sandeen 3.0.3-5 - And finally, BuildRequire libblkid-devel * Mon Dec 07 2009 Eric Sandeen 3.0.3-4 - Actually patch & run configure script w/ blkid bits... - Kill rpath in xfs_fsr xine-lib-1.1.17-2.fc13 ---------------------- * Mon Dec 07 2009 Bastien Nocera 1.1.17-2 - Remove gnome-vfs2 plugin, it's mostly useless * Wed Dec 02 2009 Rex Dieter - 1.1.17-1 - xine-lib-1.1.17, plugin-abi 1.27 xls2csv-1.06-6.fc13 ------------------- * Mon Dec 07 2009 Stepan Kasal - 1.06-6 - rebuild against perl 5.10.1 xmms-1.2.11-10.20071117cvs.fc13 ------------------------------- * Wed Dec 09 2009 Matthias Saou 1:1.2.11-10.20071117cvs - Include xmms.desktop, taken from redhat-audio-player.desktop which is no longer provided by any package (it was about time). - Update scriplets to what I understand is best from ScriptletSnippets page. xmms-flac-1.2.1-1.fc13 ---------------------- * Tue Dec 08 2009 Matthias Saou 1.2.1-1 - Update to 1.2.1. * Tue Nov 24 2009 Matthias Saou 1.1.4-7 - Include hidden desktop entry for the mimetype (#508203). xmms2-0.6-5.fc13 ---------------- * Fri Dec 04 2009 Stepan Kasal - 0.6-5 - rebuild against perl 5.10.1 xmoto-0.5.2-1.1.fc13 -------------------- * Mon Dec 07 2009 Jon Ciesla 0.5.2-1.1 - EVR bump for fix CVS tagging snafu. * Sun Dec 06 2009 Howard Liberty 0.5.2-1 - New upstream. - Add x86-64 patch so it can be compiled in x86-64 enviroment. xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc13 ------------------------------------------------ * Fri Dec 04 2009 Hans Ulrich Niedermann - 1.3.0-4.2.20091204git - Abort driver startup if kernel modesetting (KMS) is enabled - New snapshot (upstream commit 98d1d5f68f5be3f9dc3cd4b483ca4bea708e1eb8): - 98d1d5f6: Blacklist: Marking 0x9710, 0x1043, 0x83A2 hotplug unusable. - f7aed406: conntest: Update PCI ID list. xorg-x11-drv-synaptics-1.2.0-3.fc13 ----------------------------------- * Wed Dec 09 2009 Adam Jackson 1.2.0-3 - synaptics-1.2.0-timer-fix.patch: Don't free the timer in DeviceClose, since that gets called on VT switch. (#540248) xscreensaver-5.10-4.fc13 ------------------------ * Fri Dec 11 2009 Mamoru Tasaka - 1:5.10-4 - Fix occasional crash on substrate (bug 545847) - Fix initialization process on apple2, hopefully fix bug 540790?? xterm-252-1.fc13 ---------------- * Tue Dec 08 2009 Miroslav Lichvar 252-1 - update to 252 xulrunner-1.9.2.1-0.6.b4.fc13 ----------------------------- * Thu Dec 03 2009 Martin Stransky 1.9.2.1-0.6.b4 - Added fix for #543585 - mozilla-plugin.pc contains incorrect CFLAGS xzgv-0.9.1-1.fc13 ----------------- * Sat Dec 05 2009 Terje Rosten - 0.9.1-1 - 0.9.1 yasm-0.8.0-3.fc13 ----------------- * Mon Dec 07 2009 Matthias Saou 0.8.0-1 - Update to 0.8.0 (#523729). - Include new ytasm binary. yelp-2.28.1-1.fc13 ------------------ * Fri Dec 04 2009 Matthias Clasen - 2.28.1-1 - Update to 2.28.1 yp-tools-2.10-1.fc13 -------------------- * Thu Dec 10 2009 Karel Klic - 2.10-1 - Updated to new version - Removed unnecessary obsoletes yum-3.2.25-7.fc13 ----------------- * Thu Dec 10 2009 James Antill - 3.2.25-7 - Fixes the mash bug, lookup in the tsInfo too. :( - And fix the txmbr/po confusion ... third build the charm. * Fri Dec 04 2009 James Antill - 3.2.25-4 - Fixes for yum clean all, BZ 544173 - Also allow "yum clean rpmdb" to work, bad tester, bad. * Thu Dec 03 2009 Seth Vidal - 3.2.25-2 - rebuild yum with latest HEAD patch - add rpmdb caching patch james wrote to see if it breaks everyone :) yum-presto-0.6.2-1.fc13 ----------------------- * Thu Dec 10 2009 Jonathan Dieter - 0.6.2-1 - Register package name with yum - Remove multiple cleanup messages (#524633) zikula-module-filterutil-0-0.3.20090915svn15.fc13 ------------------------------------------------- * Sun Dec 06 2009 Sebastian Dziallas - 0.3.20090915svn15 - Modify install location and fix typo in bugfix patch zile-2.3.14-1.fc13 ------------------ * Fri Dec 04 2009 Rakesh Pandit - 2.3.14-1 - Updated to 2.3.14 znc-0.077-1.svn1672.fc13 ------------------------ * Mon Dec 07 2009 Nick Bebout - 0.077-1.svn1672 - Add a DCCVHost config option which specifies the VHost (IP only!) for DCC bouncing. (r1647) - Users cloned via the admin module no longer automatically connect into IRC. (r1653) - Inform new clients about their /away status. (r1655) - The "BUG" messages from route_replies can now be turned off via /msg *route_replies silent yes. (r1660) - Rewrite znc.conf on SIGUSR1. (r1666) - ISpoofFormat now supports ExpandString. (r1670) - Allow specifing port and password for delserver. (r1640) - Write the config file on restart and shutdown. (r1641) - Disable c-ares if it is not found unless --enable-c-ares was used. (r1644) (r1645) - blockuser was missing an admin check. (r1648) - Sometimes, removing a server caused znc to lose track of which server it is connected to. (r1659) - Include a more portable header for uint32_t in SHA256.h. (r1665) - Fixed cases where ZNC didn't properly block PONG replies to its own PINGs. (r1668) - Fixed a possible crash if a client disconnected before an auth module was able to verify the login. (r1669) - Away allowed to accidentally execute IRC commands. (r1672) - Comment out some weird code in Client.cpp. (r1646) - Remove connect_throttle since it's obsoleted by fail2ban. (r1649) - Remove outdated sample znc.conf. (r1654) - route_replies now got a higher timeout before it generates a "BUG" message. (r1657) - Documented the signals on which znc reacts better. (r1667) - New module hook OnIRCConnecting(). (r1638) - Remove obsolete CUtils::GetHashPass(). (r1642) - A module's GetDescription() now returns a C-String. (r1661) (r1662) - When opening a module, check the version number first and don't do anything on a mismatch. (r1663) * Fri Dec 04 2009 Stepan Kasal - 0.076-3 - rebuild against perl 5.10.1 zoneminder-1.24.2-4.fc13 ------------------------ * Fri Dec 04 2009 Stepan Kasal - 1.24.2-4 - rebuild against perl 5.10.1 - use Perl vendorarch and archlib variables correctly Summary: Added Packages: 46 Removed Packages: 5 Modified Packages: 1602 From awilliam at redhat.com Fri Dec 11 19:26:23 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 11:26:23 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260384038.3027.411.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260308728.3311.1994.camel@localhost.localdomain> <1260384038.3027.411.camel@tonnant> Message-ID: <1260559583.19557.24.camel@adam.local.net> On Wed, 2009-12-09 at 13:40 -0500, Jon Masters wrote: > I couldn't disagree more strongly. As a Linux user, I want the "show me > everything" option. I don't care if I have to check a box to do it, but > I want to see all the knobs and dials. And I at least expect not to have > what I'm doing with alsamixer interfered with by the other tools. It's quite difficult for any given mixer not to 'interfere' with any other, given that, in the end, they're all poking the same underlying dials. We're always going to provide alsamixer for anyone who needs access to all the controls, it's not going anywhere. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Fri Dec 11 19:31:48 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 11:31:48 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260384376.3027.414.camel@tonnant> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260384376.3027.414.camel@tonnant> Message-ID: <1260559908.19557.27.camel@adam.local.net> On Wed, 2009-12-09 at 13:46 -0500, Jon Masters wrote: > All paranoia and ranting aside, there is some truth to this. There is a > definite trend in the Linux community to want to cater to the lowest > common denominator by being more Mac/Windows-esque. I put up with it > because I can usually ignore it (I refuse on principal to use a GUI to > copy a file, for example, but that's just me being weird), but I don't > see the harm in hiding the advanced stuff under a checkbox - the > advanced mixer stuff is still there underneath after all. That kind of 'split' interface - with the advanced stuff 'hidden away' - has several significant problems. It's much more difficult to support when you have to consider the possibility of there being two different interfaces the user could be using to the program. It's also been quite solidly documented in usability studies that just about everyone tends to consider themselves an expert and hence hit the 'advanced' button, even when they don't actually have a freaking clue what they're doing. It also encourages lazy interface design - the designer can always think 'well, I'll just make this a checkbox under 'advanced' somewhere', rather than considering how to properly design a single configuration interface. There are probably still cases where it makes sense, but it's not an unproblematic design, and I'm not sure I'd agree it's a sensible model for the default volume control. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From darrellpf at gmail.com Fri Dec 11 19:32:18 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 11 Dec 2009 11:32:18 -0800 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091210203228.GA13743@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> Message-ID: On Thu, Dec 10, 2009 at 12:32, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > It's going to be a bit of a bumpy first yum upgrade. You will likely have > > to reboot with 'reboot -f', as the job formats have changed > > slightly, and the communication with init(8) has changed. > > > > Once you reboot, things should work pretty much the same. > > One notable change that was made is that we were able to simplify the > jobs to the point where the number of login consoles is now configurable, > without editing or removing upstart job definitions. > > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; > the default value is "/dev/tty/[1-6]", which means that mingetty > will be started on ttys 1 through 6. Shell globs are accepted. > > I updated from my machine from koji (yes, I know, even more insane than from rawhide) After plymouth there is no X and no consoles. Rebooting at runlevel 3 and doing a startx works. Rebooting at runlevel 3 and doing a telinit 5 works. https://bugzilla.redhat.com/show_bug.cgi?id=546721 (Filed against initscripts rather than upstart) darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Fri Dec 11 19:35:13 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 11:35:13 -0800 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> Message-ID: <1260560113.19557.28.camel@adam.local.net> On Wed, 2009-12-09 at 12:38 -0900, Jeff Spaleta wrote: > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: > > Jef, I'll help with istanbul. If anyone else out there is considering > > doing so, please feel free to team up with me. > > Other than revelation(which essentially has a dead > upstream)...Istanbul is probably the most in need of more development > love. This made me prick up my ears, as I keep my entire gigantic password database in revelation. What kind of development does it actually need? Dead upstream or not, it seems to work fine. Is it in imminent danger of dying? I can't help, not being a coder, but I'd like to know what's going on in case I have to change my workflow :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From promac at gmail.com Fri Dec 11 19:35:57 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Fri, 11 Dec 2009 17:35:57 -0200 Subject: v4l applications In-Reply-To: References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> Message-ID: <68720af30912111135s4f3ad9ecr6621fa568e6e6346@mail.gmail.com> On Sun, Dec 6, 2009 at 1:53 PM, Nicolas Chauvet wrote: > 2009/12/5 Paulo Cavalcanti : > > There are some old v4l applications that do not work in Fedora 12. > > > > I found so far fmtools and gnomeradio. > I will have a look on fmtools in ew days, but until then, patches welcomed. > > The current fmtools developer, Ben Pfaff, told me he would send me a patch soon. I will test it and then forward it to you. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Fri Dec 11 19:41:19 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 11:41:19 -0800 Subject: X on UEFI systems. In-Reply-To: References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> Message-ID: <1260560479.19557.30.camel@adam.local.net> On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: > Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): > >> Does it not work without an xorg.conf, that would be the first goal. > >> > > > > No. > > File a bug please, attaching your xorg.conf, Xorg.0.log and output of > the dmesg command (all from inside of VB virtual machine, of course). ...aaaand (oh boy, I love it when a plan comes together) mark it as blocking F13Beta , because I reckon this breaks beta criterion #4: https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From dcbw at redhat.com Fri Dec 11 19:47:56 2009 From: dcbw at redhat.com (Dan Williams) Date: Fri, 11 Dec 2009 11:47:56 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260559908.19557.27.camel@adam.local.net> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260384376.3027.414.camel@tonnant> <1260559908.19557.27.camel@adam.local.net> Message-ID: <1260560876.6254.6.camel@localhost.localdomain> On Fri, 2009-12-11 at 11:31 -0800, Adam Williamson wrote: > On Wed, 2009-12-09 at 13:46 -0500, Jon Masters wrote: > > > All paranoia and ranting aside, there is some truth to this. There is a > > definite trend in the Linux community to want to cater to the lowest > > common denominator by being more Mac/Windows-esque. I put up with it > > because I can usually ignore it (I refuse on principal to use a GUI to > > copy a file, for example, but that's just me being weird), but I don't > > see the harm in hiding the advanced stuff under a checkbox - the > > advanced mixer stuff is still there underneath after all. > > That kind of 'split' interface - with the advanced stuff 'hidden away' - > has several significant problems. It's much more difficult to support > when you have to consider the possibility of there being two different > interfaces the user could be using to the program. It's also been quite > solidly documented in usability studies that just about everyone tends > to consider themselves an expert and hence hit the 'advanced' button, > even when they don't actually have a freaking clue what they're doing. > > It also encourages lazy interface design - the designer can always think > 'well, I'll just make this a checkbox under 'advanced' somewhere', > rather than considering how to properly design a single configuration > interface. (or, also, how to properly design the underlying service that the UI is supposed to configure) Example: openvpn. It has literally 500 configuration options that must be set exactly the same on both the server and the client. It is too dumb to automatically negotiate options and thus keep the client configuration simple. Thus the hapless user is required to know that the "TLS Auth Direction" must be 1 on the the client because it is 0 on the server. Which requires the sysadmin to publish the server's configuration somewhere. Yay. One could make the same general complaint about ALSA. Dan From awilliam at redhat.com Fri Dec 11 20:02:04 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 12:02:04 -0800 Subject: new webkitgtk incremental release for F12 In-Reply-To: References: Message-ID: <1260561724.19557.33.camel@adam.local.net> On Fri, 2009-12-11 at 12:38 -0600, Adam Miller wrote: > There is currently a new incremental release to webkitgtk (the current > release in F12 is 1.1.15-3, latest is 1.1.15-4) and I wanted to shoot > out to the list to find out if there is anything that would need a new > build against webkitgtk if I were to build the latest as a potential > stable update for F12 (possibly pywebkitgtk and/or $other?). > > I've done a scratch build and tested with Midori which has been a > positive experience so far, so if there are any other alternative web > browsers that use webkitgtk they should work as well against the new > build, but testing is always best. Isn't the Epiphany in F12 the webkit version? I think kazehakase may use it too, but not 100% sure. And I think quite a lot of bits of GNOME use webkit for HTML rendering these days. A quick-n-dirty check gives: [adamw at adam Download]$ repoquery --whatrequires "libwebkit-1.0.so.2()(64bit)" gimp-help-browser-2:2.6.7-2.fc12.x86_64 evolution-rss-0:0.1.4-12.fc12.x86_64 epiphany-extensions-0:2.28.1-2.fc12.x86_64 awn-extras-applets-0:0.3.2.1-8.fc11.x86_64 libproxy-webkit-0:0.2.3-12.fc12.x86_64 kazehakase-webkit-0:0.5.8-3.fc12.x86_64 gimp-help-browser-2:2.6.7-3.fc12.x86_64 devhelp-0:2.28.1-1.fc12.x86_64 empathy-libs-0:2.28.1.1-3.fc12.x86_64 gmpc-0:0.18.0-1.fc12.x86_64 empathy-0:2.28.1.2-1.fc12.x86_64 epiphany-0:2.28.1-1.fc12.x86_64 anjuta-1:2.28.1.0-2.fc12.x86_64 kazehakase-webkit-0:0.5.8-2.fc12.x86_64 solang-0:0.3-2.fc12.x86_64 evolution-rss-0:0.1.4-5.fc12.x86_64 webkitgtk-devel-0:1.1.15.3-1.fc12.x86_64 empathy-libs-0:2.28.1.2-1.fc12.x86_64 empathy-0:2.28.1.1-3.fc12.x86_64 claws-mail-plugins-fancy-0:3.7.3-1.fc12.x86_64 midori-0:0.2.0-1.fc12.x86_64 webkitgtk-0:1.1.15.3-1.fc12.x86_64 cairo-dock-plug-ins-webkit-0:2.1.1.2-1.fc12.x86_64 liferea-1:1.6.0-1.fc12.x86_64 anjal-0:0.1.0-1.fc12.x86_64 pywebkitgtk-0:1.1.6-2.fc12.x86_64 devhelp-0:2.28.1-2.fc12.x86_64 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bruno at wolff.to Fri Dec 11 20:01:49 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 11 Dec 2009 14:01:49 -0600 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> Message-ID: <20091211200149.GA4667@wolff.to> On Fri, Dec 11, 2009 at 11:32:18 -0800, darrell pfeifer wrote: > I updated from my machine from koji (yes, I know, even more insane than from > rawhide) I do that from time to time. A cherry pick koji builds regularly. But when rawhide is frozen (or composes are broken) for a long (a week or two) time then I do mass pulls of the latest stuff. I did that for the latest update lull, but I see that rawhide is back now and will be using that again. From jlaska at redhat.com Fri Dec 11 20:06:10 2009 From: jlaska at redhat.com (James Laska) Date: Fri, 11 Dec 2009 15:06:10 -0500 Subject: [ANNOUNCEMENT] Red Hat Bugzilla 3.4 Upgrade Public Beta 2 Message-ID: <1260561970.3549.89.camel@localhost> I am sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Please forward this on to any appropriate lists that were missed. ======== Greetings, The Red Hat Bugzilla team is happy to announce the second public beta release of the next version of Red Hat Bugzilla based on the upstream 3.4 code base. We have not yet received a lot of reports or feedback from our last public beta, so please take some time to try out our latest code release so that we will be sure that this is as stable as possible when we deploy live. Please test drive at: https://partner-bugzilla.redhat.com Over the years Red Hat has made substantial customizations to Bugzilla to fit into the Engineering tool chain. Over time the upstream has incorporated some of these customizations or solved them in different ways. Upgrading reduces our customization footprint (and thus maintenance) while bringing many bug fixes & enhancements. The main area of focus for our public betas are stability. Functionality that currently works in our 3.2 code base should continue to work as expected in the new 3.4 release. These include various ajax optimizations, needinfo actor support, frontpage.cgi, product browser, several various UI enhancements, and of course the XMLRPC API. Please feel free to point your various scripts and third party applications that use the XMLRPC API at the test server to make sure they continue to function properly. There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 3.2 is possible in the new system. There are also numerous new features/fixes that are part of the upstream 3.4 release. For more detailed information on what has changed since the last release, check out release notes here: https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html The database is a recent snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Also with a full snapshot it is possible to test for any performance related issues. Email has been disabled so that unnecessary spam is not sent out. So feel free to make changes to bugs to verify proper working order. We are asking for everyone to get involved as much as possible with testing and feedback on the beta releases to help us make this the most robust and stable release possible. Please file any enhancement requests or bug reports in our current Bugzilla system go here: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.4 To see current list of 3.4 related bugs as well as blockers for release, go here: https://bugzilla.redhat.com/buglist.cgi?product=Bugzilla&version=3.4 Thanks The Red Hat Bugzilla Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Dec 11 20:12:04 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 11 Dec 2009 11:12:04 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <1260560113.19557.28.camel@adam.local.net> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> <1260560113.19557.28.camel@adam.local.net> Message-ID: <604aa7910912111212t74b2b4bfmaa2bec88d294dc25@mail.gmail.com> It's making use of some deprecated functionality.... for example gnomevfs which really should be ported to the newer gvfs stuff. There are probably some pygtk/gtk-isms which need to be updated. I'm willing to carry this as downstream patches if I have to but I really don't want to do that. Less critically for basic operation... the export functionality needs love. I'm not willing to carry this as downstream patches as I view the export functionality as a nice-to-have feature and not critical. I'm more inclined to just patch it to keep export from crashing on error than actually fix the export to work as a downstream only patch. There's some subtle problems with language support... which I'm personally ill-equipped to work through as a US English speaker (and barely at that). Crasher bug and something I'm willing to hold as downstream only patches if needed. -jef On 12/11/09, Adam Williamson wrote: > On Wed, 2009-12-09 at 12:38 -0900, Jeff Spaleta wrote: >> On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields >> wrote: >> > Jef, I'll help with istanbul. If anyone else out there is considering >> > doing so, please feel free to team up with me. >> >> Other than revelation(which essentially has a dead >> upstream)...Istanbul is probably the most in need of more development >> love. > > This made me prick up my ears, as I keep my entire gigantic password > database in revelation. What kind of development does it actually need? > Dead upstream or not, it seems to work fine. Is it in imminent danger of > dying? I can't help, not being a coder, but I'd like to know what's > going on in case I have to change my workflow :/ > > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From awilliam at redhat.com Fri Dec 11 20:16:09 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 12:16:09 -0800 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912111212t74b2b4bfmaa2bec88d294dc25@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> <1260560113.19557.28.camel@adam.local.net> <604aa7910912111212t74b2b4bfmaa2bec88d294dc25@mail.gmail.com> Message-ID: <1260562569.19557.34.camel@adam.local.net> On Fri, 2009-12-11 at 11:12 -0900, Jeff Spaleta wrote: > It's making use of some deprecated functionality.... for example > gnomevfs which really should be ported to the newer gvfs stuff. > There are probably some pygtk/gtk-isms which need to be updated. I'm > willing to carry this as downstream patches if I have to but I really > don't want to do that. Thanks. > Less critically for basic operation... the export functionality needs > love. I'm not willing to carry this as downstream patches as I view > the export functionality as a nice-to-have feature and not critical. > I'm more inclined to just patch it to keep export from crashing on > error than actually fix the export to work as a downstream only patch. Well, I suppose a little ironically, if revelation were to die, the 'export' functionality would likely be the _most_ critical bit :) > There's some subtle problems with language support... which I'm > personally ill-equipped to work through as a US English speaker (and > barely at that). Crasher bug and something I'm willing to hold as > downstream only patches if needed. Haven't ever seen it crash. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From kevin at scrye.com Fri Dec 11 20:17:53 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 11 Dec 2009 13:17:53 -0700 Subject: new webkitgtk incremental release for F12 In-Reply-To: <1260561724.19557.33.camel@adam.local.net> References: <1260561724.19557.33.camel@adam.local.net> Message-ID: <20091211131753.0fb94428@ohm.scrye.com> On Fri, 11 Dec 2009 12:02:04 -0800 Adam Williamson wrote: > On Fri, 2009-12-11 at 12:38 -0600, Adam Miller wrote: > > There is currently a new incremental release to webkitgtk (the > > current release in F12 is 1.1.15-3, latest is 1.1.15-4) and I > > wanted to shoot out to the list to find out if there is anything > > that would need a new build against webkitgtk if I were to build > > the latest as a potential stable update for F12 (possibly > > pywebkitgtk and/or $other?). > > > > I've done a scratch build and tested with Midori which has been a > > positive experience so far, so if there are any other alternative > > web browsers that use webkitgtk they should work as well against > > the new build, but testing is always best. > > Isn't the Epiphany in F12 the webkit version? Yep. > I think kazehakase may use it too, but not 100% sure. And I think > quite a lot of bits of GNOME use webkit for HTML rendering these days. > > A quick-n-dirty check gives: > > [adamw at adam Download]$ repoquery --whatrequires ...snip... Note that this update does not change ABI. It's a stable bugfix release only... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From peter at thecodergeek.com Fri Dec 11 20:22:38 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 11 Dec 2009 12:22:38 -0800 Subject: new webkitgtk incremental release for F12 In-Reply-To: References: Message-ID: <1260562958.3126.2.camel@localhost> On Fri, 2009-12-11 at 12:38 -0600, Adam Miller wrote: > There is currently a new incremental release to webkitgtk (the current > release in F12 is 1.1.15-3, latest is 1.1.15-4) and I wanted to shoot > out to the list to find out if there is anything that would need a new > build against webkitgtk if I were to build the latest as a potential > stable update for F12 (possibly pywebkitgtk and/or $other?). From my own brief testing, Epiphany has no apparent problems with it either. I think it should be fine as an update; but like any other version bump, we'd want to have it in updates-testing for a reasonable amount of time before pushing it stable - just to certain. On a side note, Adam, many thanks again for helping maintain this. -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From maxamillion at gmail.com Fri Dec 11 21:03:21 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 11 Dec 2009 15:03:21 -0600 Subject: new webkitgtk incremental release for F12 In-Reply-To: <20091211131753.0fb94428@ohm.scrye.com> References: <1260561724.19557.33.camel@adam.local.net> <20091211131753.0fb94428@ohm.scrye.com> Message-ID: On Fri, Dec 11, 2009 at 2:17 PM, Kevin Fenzi wrote: > > Note that this update does not change ABI. > It's a stable bugfix release only... > > kevin > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Sorry, I should have mentioned that bit in my previous email. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From maxamillion at gmail.com Fri Dec 11 21:05:05 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 11 Dec 2009 15:05:05 -0600 Subject: new webkitgtk incremental release for F12 In-Reply-To: <1260562958.3126.2.camel@localhost> References: <1260562958.3126.2.camel@localhost> Message-ID: On Fri, Dec 11, 2009 at 2:22 PM, Peter Gordon wrote: > > From my own brief testing, Epiphany has no apparent problems with it > either. > > I think it should be fine as an update; but like any other version bump, > we'd want to have it in updates-testing for a reasonable amount of time > before pushing it stable - just to certain. > Agreed, good to know epiphany has a positive experience. > On a side note, Adam, many thanks again for helping maintain this. Happy to help! :) > -- > Peter Gordon (codergeek42) > Who am I? :: http://thecodergeek.com/about-me > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Ok, I'll got ahead and fire off a build and put it in updates-testing to await karma. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From pjones at redhat.com Fri Dec 11 22:14:40 2009 From: pjones at redhat.com (Peter Jones) Date: Fri, 11 Dec 2009 17:14:40 -0500 Subject: X on UEFI systems. In-Reply-To: <1260560479.19557.30.camel@adam.local.net> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> Message-ID: <4B22C450.20008@redhat.com> On 12/11/2009 02:41 PM, Adam Williamson wrote: > On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: >> Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >>>> Does it not work without an xorg.conf, that would be the first goal. >>>> >>> >>> No. >> >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of >> the dmesg command (all from inside of VB virtual machine, of course). > > ...aaaand (oh boy, I love it when a plan comes together) mark it as > blocking F13Beta , because I reckon this breaks beta criterion #4: > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria I like the sentiment here, but I'm not sure this is really in the spirit of the criteria - Vasily, as I understand it, is still in the process of implementing the support for UEFI on VirtualBox. Which is to say, yes, we need to fix the parts that are distro problems, but I'm not sure we've gotten to the point where VirtualBox+UEFI is expected to be a working system in the first place. But maybe I'm wrong - Vasily, what do you think? -- Peter I hope you know that this will go down on your permanent record. From awilliam at redhat.com Fri Dec 11 22:27:21 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 11 Dec 2009 14:27:21 -0800 Subject: X on UEFI systems. In-Reply-To: <4B22C450.20008@redhat.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> <4B22C450.20008@redhat.com> Message-ID: <1260570441.19557.38.camel@adam.local.net> On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: > On 12/11/2009 02:41 PM, Adam Williamson wrote: > > On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: > >> Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): > >>>> Does it not work without an xorg.conf, that would be the first goal. > >>>> > >>> > >>> No. > >> > >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of > >> the dmesg command (all from inside of VB virtual machine, of course). > > > > ...aaaand (oh boy, I love it when a plan comes together) mark it as > > blocking F13Beta , because I reckon this breaks beta criterion #4: > > > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > I like the sentiment here, but I'm not sure this is really in the > spirit of the criteria - Vasily, as I understand it, is still in the > process of implementing the support for UEFI on VirtualBox. > > Which is to say, yes, we need to fix the parts that are distro problems, > but I'm not sure we've gotten to the point where VirtualBox+UEFI is > expected to be a working system in the first place. > > But maybe I'm wrong - Vasily, what do you think? >From what I saw in the thread, the bug seems to be that X is assuming the presence of a VGA BIOS, which would seem to be a fairly generic problem that would hit any EFI setup. AIUI anyway. See Vasily's message of a couple of days ago. But I could be wrong, and also I'm not sure why he's testing with F11 rather than F12 or Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ndbecker2 at gmail.com Fri Dec 11 23:12:19 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 11 Dec 2009 18:12:19 -0500 Subject: [ANNOUNCEMENT] Red Hat Bugzilla 3.4 Upgrade Public Beta 2 References: <1260561970.3549.89.camel@localhost> Message-ID: It doesn't work with konqueror. Neither did it's predecessor. It keeps asking for a password on every page. I am not doing anything with cookies. I have no problem with original bugzilla. From dmalcolm at redhat.com Fri Dec 11 23:36:23 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 11 Dec 2009 18:36:23 -0500 Subject: Request for help maintaining packages while away. In-Reply-To: <20091210003919.GN9741@victoria.internal.frields.org> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <20091209212616.GP9741@victoria.internal.frields.org> <604aa7910912091338j4a83a0c3w1f7d59a49667b736@mail.gmail.com> <20091210003919.GN9741@victoria.internal.frields.org> Message-ID: <1260574583.10410.60.camel@brick> On Wed, 2009-12-09 at 19:39 -0500, Paul W. Frields wrote: > On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote: > > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields wrote: > > > Jef, I'll help with istanbul. If anyone else out there is considering > > > doing so, please feel free to team up with me. > > > > Other than revelation(which essentially has a dead > > upstream)...Istanbul is probably the most in need of more development > > love. Upstream seems to be inactive with no release activity in quite > > a while. There's a lot of deprecation warnings for some pygtk calls > > that I would love to clean up in time for F13. And there are a couple > > of abrt crash tickets being spawned by istanbul.. which maybe traced > > back to gdk libraries calls if I'm reading the crash dumps correctly. > > Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this > weekend at FUDCon if memory serves. I'll also do what I can for > existing bugs in my Copious Spare Time(tm). I spent some time trying to figure out bug 543278 but got stumped; need a GTK maintainer's help with this one; pygtk appears to be correctly passing the --sync flag on to GTK fwiw [snip] From mmcgrath at redhat.com Sat Dec 12 04:18:33 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 11 Dec 2009 22:18:33 -0600 (CST) Subject: Outage Notification - 2009-12-12 11:00 UTC Message-ID: There will be an outage starting at 2009-12-12 11:00 UTC, which will last approximately 48 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-12-12 11:00 UTC' Affected Services: Buildsystem CVS / Source Control Translation Services Websites Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1845 Reason for Outage: This is the official outage notification that was mentioned days ago. The ticket link above will have the most up to date information and we will be coordinating the outage in #fedora-admin on irc.freenode.net. At the time specified above we will be powering down hosts, moving them on to a truck, unloading them re-racking and re-cabling and powering on. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From nicolas.mailhot at laposte.net Sat Dec 12 07:03:03 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 12 Dec 2009 08:03:03 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <1260559908.19557.27.camel@adam.local.net> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260384376.3027.414.camel@tonnant> <1260559908.19557.27.camel@adam.local.net> Message-ID: <1260601383.25559.4.camel@arekh.okg> Le vendredi 11 d?cembre 2009 ? 11:31 -0800, Adam Williamson a ?crit : > It also encourages lazy interface design - the designer can always > think > 'well, I'll just make this a checkbox under 'advanced' somewhere', > rather than considering how to properly design a single configuration > interface. I fail to see how it is worse than designers that think "this is advanced stuff, I don't need to handle it" and then redefine advanced users as "people able to use bugzilla and contradict me" At least in the fist lazy design variant the features are available somewhere. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jim at meyering.net Sat Dec 12 14:43:12 2009 From: jim at meyering.net (Jim Meyering) Date: Sat, 12 Dec 2009 15:43:12 +0100 Subject: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion In-Reply-To: <1260503641.30425.45.camel@localhost.localdomain> (Jesse Keating's message of "Thu, 10 Dec 2009 19:54:01 -0800") References: <1260503641.30425.45.camel@localhost.localdomain> Message-ID: <87638cp81r.fsf@meyering.net> Jesse Keating wrote: > I'm currently playing with a utility called parsecvs to convert our cvs > stuff into git. This utility can also translate the raw usernames that > CVS has into more useful names+email addresses that you'd typically get > out of git. But to make this conversion it needs a translation file. I've used parsecvs a lot. Over the course of converting the likes of coreutils, glibc, emacs, diffutils, gzip, grep, etc. I've made a number of changes to fix NULL-dereferences, adapt to evolving GIT APIs and to remove at least one performance bottleneck that dramatically sped up the conversion of glibc. I've even added a testing framework and a test case (the first!) and pushed another that was contributed privately. All local, but I'd rather share. Does anyone know of a public and *maintained* repository for parsecvs? I've looked numerous times (as recently as a few weeks ago), and tried to contact Keith Packard, hoping he would still be maintaining it, but have had no luck. From jwboyer at gmail.com Sat Dec 12 15:06:40 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 12 Dec 2009 10:06:40 -0500 Subject: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion In-Reply-To: <87638cp81r.fsf@meyering.net> References: <1260503641.30425.45.camel@localhost.localdomain> <87638cp81r.fsf@meyering.net> Message-ID: <20091212150639.GK7691@hansolo.jdub.homelinux.org> On Sat, Dec 12, 2009 at 03:43:12PM +0100, Jim Meyering wrote: >Jesse Keating wrote: >> I'm currently playing with a utility called parsecvs to convert our cvs >> stuff into git. This utility can also translate the raw usernames that >> CVS has into more useful names+email addresses that you'd typically get >> out of git. But to make this conversion it needs a translation file. > >I've used parsecvs a lot. >Over the course of converting the likes of coreutils, glibc, emacs, >diffutils, gzip, grep, etc. I've made a number of changes to fix >NULL-dereferences, adapt to evolving GIT APIs and to remove at least >one performance bottleneck that dramatically sped up the conversion >of glibc. I've even added a testing framework and a test case (the >first!) and pushed another that was contributed privately. All local, >but I'd rather share. > >Does anyone know of a public and *maintained* repository for parsecvs? >I've looked numerous times (as recently as a few weeks ago), and tried >to contact Keith Packard, hoping he would still be maintaining it, >but have had no luck. I'd suggest creating a fedorahosted project for it, or something similar. I think there are many random versions of it out there and starting a project to try and consolidate would be great. josh From casimiro.barreto at gmail.com Sat Dec 12 15:49:21 2009 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 12 Dec 2009 13:49:21 -0200 Subject: Problems updating - YUM - kmod-VirtualBox... In-Reply-To: <20091212150639.GK7691@hansolo.jdub.homelinux.org> References: <1260503641.30425.45.camel@localhost.localdomain> <87638cp81r.fsf@meyering.net> <20091212150639.GK7691@hansolo.jdub.homelinux.org> Message-ID: <4B23BB81.9090703@gmail.com> # yum --skip-broken update ... gnome-keyring-sharp i686 1.0.1-0.5.133722svn.fc12 fedora 20 k kmod-nvidia-173xx-2.6.31.6-166.fc12.i686.PAE i686 173.14.22-1.fc12.4 rpmfusion-nonfree-updates 1.8 M Removendo para as depend?ncias: kmod-VirtualBox-OSE-2.6.31.5-127.fc12.i686.PAE i686 3.0.10-1.fc12.4 installed 393 k kmod-nvidia-173xx-2.6.31.5-127.fc12.i686.PAE i686 173.14.22-1.fc12 installed 7.5 M Resumo da transa??o ================================================================================================================================================================================================================ Instalar 4 Pacote(s) Atualizar 53 Pacote(s) Remover 4 Pacote(s) Reinstalar 0 Pacote(s) Desatualizar 0 Pacote(s) Tamanho total: 106 M Correto? [s/N]:s Baixando pacotes: Executando o rpm_check_debug Erro com o rpm_check_debug vs depsolve: kernel-uname-r = 2.6.30.9-96.fc11.i686.PAE is needed by (installed) kmod-VirtualBox-OSE-2.6.30.9-96.fc11.i686.PAE-3.0.10-1.fc11.3.i686 kernel-uname-r = 2.6.30.8-64.fc11.i686.PAE is needed by (installed) kmod-VirtualBox-OSE-2.6.30.8-64.fc11.i686.PAE-3.0.8-1.fc11.i686 kernel-uname-r = 2.6.30.9-90.fc11.i686.PAE is needed by (installed) kmod-VirtualBox-OSE-2.6.30.9-90.fc11.i686.PAE-3.0.10-1.fc11.i686 Conclu?do! From awilliam at redhat.com Sat Dec 12 16:57:11 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sat, 12 Dec 2009 08:57:11 -0800 Subject: Problems updating - YUM - kmod-VirtualBox... In-Reply-To: <4B23BB81.9090703@gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <87638cp81r.fsf@meyering.net> <20091212150639.GK7691@hansolo.jdub.homelinux.org> <4B23BB81.9090703@gmail.com> Message-ID: <1260637031.19557.48.camel@adam.local.net> On Sat, 2009-12-12 at 13:49 -0200, Casimiro de Almeida Barreto wrote: > # yum --skip-broken update Wrong list. VirtualBox is part of RPM Fusion, not Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bjorn at xn--rombobjrn-67a.se Sat Dec 12 19:30:14 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Sat, 12 Dec 2009 20:30:14 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> Message-ID: <200912122030.26756.bjorn@xn--rombobjrn-67a.se> Seth Vidal wrote: > And let me put it this way: if fedora decides to post my non @fp.o address > somewhere, like in git entries, I'm going to be extremely pissed off about > it. As for me, I don't mind publishing my real email address but I would prefer not to have my fedoraproject.org alias published where the spammers can find it. I don't particularly like having forwarding aliases created for me, but if you have to give me one then please don't publish it. I have a spam blocker that makes my address pretty much unspammable. It's unspammable even if the spam comes through a forwarding alias, but in that case backscatter may be generated. The spam blocker is implemented such that my own server never sends out backscatter, but I naturally have no control over the fedoraproject.org server or other forwarding servers. Therefore I try to avoid using forwarding aliases in ways that might allow spammers to find them, not because it affects me but to be nice to other netizens who don't have as effectual spam blockers as I have. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From ngompa13 at gmail.com Sat Dec 12 19:57:11 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Sat, 12 Dec 2009 13:57:11 -0600 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <200912122030.26756.bjorn@xn--rombobjrn-67a.se> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> Message-ID: <8278b1b0912121157o2853010bu71ce38ed8acc62ae@mail.gmail.com> I have only successfully pushed up one package, but I'll tell you that I don't like having my personal email address attached to it. An fp.o email address alias would be preferable to me. I can immediately have my account filter all emails sent to fp.o and deal with it there. It makes me somewhat uncomfortable to have my personal email address floating around unprotected in the internet. I am aware the same thing happens when I post in a mailing list, but it's somewhat protected there. 2009/12/12 Bj?rn Persson > Seth Vidal wrote: > > And let me put it this way: if fedora decides to post my non @fp.o > address > > somewhere, like in git entries, I'm going to be extremely pissed off > about > > it. > > As for me, I don't mind publishing my real email address but I would prefer > not to have my fedoraproject.org alias published where the spammers can > find > it. I don't particularly like having forwarding aliases created for me, but > if > you have to give me one then please don't publish it. > > I have a spam blocker that makes my address pretty much unspammable. It's > unspammable even if the spam comes through a forwarding alias, but in that > case backscatter may be generated. The spam blocker is implemented such > that > my own server never sends out backscatter, but I naturally have no control > over the fedoraproject.org server or other forwarding servers. Therefore I > try > to avoid using forwarding aliases in ways that might allow spammers to find > them, not because it affects me but to be nice to other netizens who don't > have > as effectual spam blockers as I have. > > Bj?rn Persson > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From debarshi.ray at gmail.com Sat Dec 12 22:04:57 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 13 Dec 2009 00:04:57 +0200 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <200912122030.26756.bjorn@xn--rombobjrn-67a.se> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> Message-ID: <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> >> And let me put it this way: if fedora decides to post my non @fp.o address >> somewhere, like in git entries, I'm going to be extremely pissed off about >> it. > > As for me, I don't mind publishing my real email address but I would prefer > not to have my fedoraproject.org alias published where the spammers can find > it. I don't particularly like having forwarding aliases created for me, but if > you have to give me one then please don't publish it. Here you go: rombobeorn at fedoraproject.org rombobeorn at fedoraproject.org rombobeorn at fedoraproject.org rombobeorn at fedoraproject.org rombobeorn at fedoraproject.org Now what? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From jkeating at redhat.com Sat Dec 12 23:40:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 12 Dec 2009 15:40:40 -0800 Subject: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion In-Reply-To: <87638cp81r.fsf@meyering.net> References: <1260503641.30425.45.camel@localhost.localdomain> <87638cp81r.fsf@meyering.net> Message-ID: <1260661240.2221.2.camel@localhost.localdomain> On Sat, 2009-12-12 at 15:43 +0100, Jim Meyering wrote: > Does anyone know of a public and *maintained* repository for parsecvs? > I've looked numerous times (as recently as a few weeks ago), and tried > to contact Keith Packard, hoping he would still be maintaining it, > but have had no luck. Kristian H?gsberg has a repo for the changes he made and used for gnome conversion: http://cgit.freedesktop.org/~krh/parsecvs It is slightly newer than Keith's repo. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From vasily.v.levchenko at gmail.com Sun Dec 13 07:49:33 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Sun, 13 Dec 2009 10:49:33 +0300 Subject: X on UEFI systems. In-Reply-To: <1260570441.19557.38.camel@adam.local.net> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> <4B22C450.20008@redhat.com> <1260570441.19557.38.camel@adam.local.net> Message-ID: <5665AC64-1027-4BC5-B725-8ED9457E139B@gmail.com> On Dec 12, 2009, at 1:27 AM, Adam Williamson wrote: > On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: >> On 12/11/2009 02:41 PM, Adam Williamson wrote: >>> On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: >>>> Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >>>>>> Does it not work without an xorg.conf, that would be the first goal. >>>>>> >>>>> >>>>> No. >>>> >>>> File a bug please, attaching your xorg.conf, Xorg.0.log and output of >>>> the dmesg command (all from inside of VB virtual machine, of course). >>> >>> ...aaaand (oh boy, I love it when a plan comes together) mark it as >>> blocking F13Beta , because I reckon this breaks beta criterion #4: >>> >>> https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria >> >> I like the sentiment here, but I'm not sure this is really in the >> spirit of the criteria - Vasily, as I understand it, is still in the >> process of implementing the support for UEFI on VirtualBox. >> >> Which is to say, yes, we need to fix the parts that are distro problems, >> but I'm not sure we've gotten to the point where VirtualBox+UEFI is >> expected to be a working system in the first place. >> >> But maybe I'm wrong - Vasily, what do you think? > Right, we still in progress (e.g. VBox 3.1 is failing to load FC12 with ACPI, and it can't load Windows Vista and 7/EFI) but with VBox 3.1 with manually edited config runs FC11(i386/x86_64) fine. >> From what I saw in the thread, the bug seems to be that X is assuming > the presence of a VGA BIOS, which would seem to be a fairly generic > problem that would hit any EFI setup. I guess real EFI systems has proprietary drivers + corresponding drivers, e.g. nvidia, and there're no serious reasons to use vga bios. > AIUI anyway. See Vasily's message > of a couple of days ago. But I could be wrong, and also I'm not sure why > he's testing with F11 rather than F12 or Rawhide. > About rawhide, could you please give me some pointers on ISO images, instructions for kernel compilations (looks like it bit different from compilation of vanilla kernels)? > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From awilliam at redhat.com Sun Dec 13 08:15:04 2009 From: awilliam at redhat.com (Adam Williamson) Date: Sun, 13 Dec 2009 00:15:04 -0800 Subject: X on UEFI systems. In-Reply-To: <5665AC64-1027-4BC5-B725-8ED9457E139B@gmail.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> <4B22C450.20008@redhat.com> <1260570441.19557.38.camel@adam.local.net> <5665AC64-1027-4BC5-B725-8ED9457E139B@gmail.com> Message-ID: <1260692104.19557.50.camel@adam.local.net> On Sun, 2009-12-13 at 10:49 +0300, Vasily Levchenko wrote: > Right, we still in progress (e.g. VBox 3.1 is failing to load FC12 with ACPI, and it can't load > Windows Vista and 7/EFI) but with VBox 3.1 with manually edited config runs FC11(i386/x86_64) > fine. > > > >> From what I saw in the thread, the bug seems to be that X is assuming > > the presence of a VGA BIOS, which would seem to be a fairly generic > > problem that would hit any EFI setup. > > I guess real EFI systems has proprietary drivers + corresponding drivers, e.g. nvidia, > and there're no serious reasons to use vga bios. Fedora never assumes the presence of proprietary drivers. When we say we want EFI to work, we mean with the drivers included in Fedora. > > AIUI anyway. See Vasily's message > > of a couple of days ago. But I could be wrong, and also I'm not sure why > > he's testing with F11 rather than F12 or Rawhide. > > About rawhide, could you please give me some pointers on ISO images, > instructions for kernel compilations (looks like it bit different from compilation of > vanilla kernels)? Live images go up nightly here: http://alt.fedoraproject.org/pub/alt/nightly-composes/ building kernels - well, approaches differ. Personally I tend to grab the latest .src.rpm, make the changes I want in the spec, build it back into a .src.rpm and compile with mock. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sundaram at fedoraproject.org Sun Dec 13 09:47:14 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 13 Dec 2009 15:17:14 +0530 Subject: Anyone else want to maintain alltray? Message-ID: <4B24B822.2060208@fedoraproject.org> Hi It is a application that lets you minimize any app to the system tray and is compatible with GNOME, Xfce, KDE etc. It has a dormant upstream and I haven't had time to look into all the crash reports from Abrt. If noone picks it up, I will orphan it in a week. $ yum info alltray Loaded plugins: presto, refresh-packagekit Available Packages Name : alltray Arch : i686 Version : 0.70 Release : 4.fc12 Size : 62 k Repo : fedora Summary : Dock any application in the tray URL : http://alltray.sourceforge.net/ License : GPLv2+ Rahul From snecklifter at gmail.com Sun Dec 13 11:13:24 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 13 Dec 2009 11:13:24 +0000 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <1260536834.7433.13.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> Message-ID: <364d303b0912130313x3bed3bf1r1154536f7e22be33@mail.gmail.com> 2009/12/12 Debarshi Ray : >>> And let me put it this way: if fedora decides to post my non @fp.o address >>> somewhere, like in git entries, I'm going to be extremely pissed off about >>> it. >> >> As for me, I don't mind publishing my real email address but I would prefer >> not to have my fedoraproject.org alias published where the spammers can find >> it. I don't particularly like having forwarding aliases created for me, but if >> you have to give me one then please don't publish it. > > Here you go: > rombobeorn at fedoraproject.org > rombobeorn at fedoraproject.org > rombobeorn at fedoraproject.org > rombobeorn at fedoraproject.org > rombobeorn at fedoraproject.org > > Now what? > > Cheers, > Debarshi I think that is unnecessarily untagonistic. This is a non-issue. Both my fpo and non-fpo are published regularly in commits and whatnot and I receive about 1 spam per week. But then I have gmail. :) -- Christopher Brown From snecklifter at gmail.com Sun Dec 13 11:16:38 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 13 Dec 2009 11:16:38 +0000 Subject: mono and snk key files In-Reply-To: <4B227781.7080409@spicenitz.org> References: <4B1297E5.1030207@smartlink.ee> <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> <4B227781.7080409@spicenitz.org> Message-ID: <364d303b0912130316g3b64c40ex49c9572bf8bcc4ea@mail.gmail.com> 2009/12/11 Adam Goode : > On 11/29/2009 11:29 AM, Christopher Brown wrote: >> 2009/11/29 Kalev Lember : >>> Hello, >> >> >> >>> Comments? >> >> I'm the maintainer for log4net but unfortunately not for nant. I've >> finally gotten around to looking at this. >> >> Debian have a policy[1] of using a standard mono.snk which is provided >> by a package (I guess we just then BuildRequires this) and I think >> this seems like a good solution but have no experience of this. >> > > We should definitely use Debian's key, right? Otherwise some Fedora CLI > libraries would be unnecessarily incompatible with Debian, and whoever > else uses Debian's key. > > The whole business of not shipping code-signing keys is a little > contrary to open source. I think this is something that GPLv3 would > prohibit. We should use a single well-known signing key for any package > that we don't have the keys for, I think. You're right. This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it. Best -- Christopher Brown From snecklifter at gmail.com Sun Dec 13 11:21:38 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 13 Dec 2009 11:21:38 +0000 Subject: MariaDB and Fedora In-Reply-To: <4B226DF4.9020603@conversis.de> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> Message-ID: <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> 2009/12/11 Dennis J. : > On 12/10/2009 09:01 PM, Pete Zaitcev wrote: >> >> On Thu, 10 Dec 2009 15:38:10 -0200 >> Henrique Junior ?wrote: >> >>> I agree that postgresql is great, but MariaDB is expanding very fast. >>> I'm not the best person to opine about databases, my experience is very >>> limited, but it would be nice to keep an eye on MariaDB. >> >> Well, duh. Who's going to maintain it though? There must be a warm body. > > I for one care much more about Drizzle than about MariaDB. From what I can > tell MariaDB is basically just a new storage engine inside the old crufty > MySQL shell whereas Drizzle is a (much needed) overhaul of the whole thing. > Much more interesting for future projects if you ask me. > > Regards, > ?Dennis Meh. May the best code win. I would have thought that at the moment you could pretty much drop the MariaDB sources into the MySQL directories and: sed 's/MySQL/MariaDB/g' mysql.spec > mariadb.spec as a start. -- Christopher Brown From supercyper at 163.com Sun Dec 13 11:26:59 2009 From: supercyper at 163.com (supercyper) Date: Sun, 13 Dec 2009 19:26:59 +0800 (CST) Subject: Anyone else want to maintain alltray? In-Reply-To: <4B24B822.2060208@fedoraproject.org> References: <4B24B822.2060208@fedoraproject.org> Message-ID: <21048995.146311260703619158.JavaMail.coremail@bj163app38.163.com> The upstream seems still active. See https://code.launchpad.net/alltray/trunk ?2009-12-13?"Rahul Sundaram" ??? >Hi > >It is a application that lets you minimize any app to the system tray >and is compatible with GNOME, Xfce, KDE etc. It has a dormant upstream >and I haven't had time to look into all the crash reports from Abrt. If >noone picks it up, I will orphan it in a week. > >$ yum info alltray >Loaded plugins: presto, refresh-packagekit >Available Packages >Name : alltray >Arch : i686 >Version : 0.70 >Release : 4.fc12 >Size : 62 k >Repo : fedora >Summary : Dock any application in the tray >URL : http://alltray.sourceforge.net/ >License : GPLv2+ > >Rahul > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at xn--rombobjrn-67a.se Sun Dec 13 15:52:16 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Sun, 13 Dec 2009 16:52:16 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> Message-ID: <200912131652.17135.bjorn@xn--rombobjrn-67a.se> Debarshi Ray wrote: > Now what? What happens now? Not much I guess, as the list archive obfuscates email addresses, but if you managed to reach a spammer with that message, what happens is that my mailbox is still spam-free but a number of innocent third parties may be getting an increased amount of junk in their mailboxes. Does that give you a feeling of accomplishment? Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From bjorn at xn--rombobjrn-67a.se Sun Dec 13 15:52:35 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Sun, 13 Dec 2009 16:52:35 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <364d303b0912130313x3bed3bf1r1154536f7e22be33@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> <364d303b0912130313x3bed3bf1r1154536f7e22be33@mail.gmail.com> Message-ID: <200912131652.36035.bjorn@xn--rombobjrn-67a.se> Christopher Brown wrote: > This is a non-issue. It may be a non-issue to you but not to Seth Vidal obviously. > Both my fpo and non-fpo are published regularly > in commits and whatnot and I receive about 1 spam per week. But then I > have gmail. :) Well I have received zero spams since April when I flipped the switch to enforcing mode (except when the spam blocker crashed; there seems to be a race condition that I haven't tracked down yet.) Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From henriquecsj at gmail.com Sun Dec 13 15:59:26 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Sun, 13 Dec 2009 13:59:26 -0200 Subject: MariaDB and Fedora In-Reply-To: <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> Message-ID: <1260719966.16370.2.camel@localhost> Em Dom, 2009-12-13 ?s 11:21 +0000, Christopher Brown escreveu: > 2009/12/11 Dennis J. : > > On 12/10/2009 09:01 PM, Pete Zaitcev wrote: > >> > >> On Thu, 10 Dec 2009 15:38:10 -0200 > >> Henrique Junior wrote: > >> > >>> I agree that postgresql is great, but MariaDB is expanding very fast. > >>> I'm not the best person to opine about databases, my experience is very > >>> limited, but it would be nice to keep an eye on MariaDB. > >> > >> Well, duh. Who's going to maintain it though? There must be a warm body. > > > > I for one care much more about Drizzle than about MariaDB. From what I can > > tell MariaDB is basically just a new storage engine inside the old crufty > > MySQL shell whereas Drizzle is a (much needed) overhaul of the whole thing. > > Much more interesting for future projects if you ask me. > > > > Regards, > > Dennis > > Meh. May the best code win. I would have thought that at the moment > you could pretty much drop the MariaDB sources into the MySQL > directories and: > > sed 's/MySQL/MariaDB/g' mysql.spec > mariadb.spec > > as a start. > > -- > Christopher Brown > Yes, I'm comparing the codes right now and they seems very similar. -- Henrique Junior From alsadi at gmail.com Sun Dec 13 17:39:22 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Sun, 13 Dec 2009 19:39:22 +0200 Subject: MariaDB and Fedora In-Reply-To: <1260719966.16370.2.camel@localhost> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> Message-ID: <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> > Yes, I'm comparing the codes right now and they seems very similar. > not the code, the spec he means you may start by reusing the spec file of mysql From paul at dishone.st Sun Dec 13 18:33:01 2009 From: paul at dishone.st (Paul Jakma) Date: Sun, 13 Dec 2009 18:33:01 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <4B04ADCD.8060302@pobox.com> References: <4B04ADCD.8060302@pobox.com> Message-ID: On Wed, 18 Nov 2009, Jeff Garzik wrote: > Running a 64-bit kernel with a 32-bit userland is a common practice > on non-x86 platforms, and non-Linux OS's. FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while. About the only thing that doesn't work right is yum wrt kernel updates. > For a lot of tasks, you simply do not need 64-bit pointers and a > 64-bit process address space. Both executable code and in-memory > data structures tend to be smaller on 32-bit. Indeed. It would be nice if i386-userspace/x64-kernel were officially support.. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Blore's Razor: Given a choice between two theories, take the one which is funnier. From paul at dishone.st Sun Dec 13 18:34:58 2009 From: paul at dishone.st (Paul Jakma) Date: Sun, 13 Dec 2009 18:34:58 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091119025624.8011620E1@magilla.sf.frob.com> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> Message-ID: On Wed, 18 Nov 2009, Roland McGrath wrote: > x86 is unlike other architectures because 64-bit also has twice as > many registers as 32-bit. So you get to trade off the benefits of > register allocation across more registers against the memory/cache > footprint of 64-bit pointers. For what percentage of code is that an appreciable advantage? regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: QOTD: "If he learns from his mistakes, pretty soon he'll know everything." From drago01 at gmail.com Sun Dec 13 18:41:25 2009 From: drago01 at gmail.com (drago01) Date: Sun, 13 Dec 2009 19:41:25 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: On Sun, Dec 13, 2009 at 7:33 PM, Paul Jakma wrote: > On Wed, 18 Nov 2009, Jeff Garzik wrote: > >> Running a 64-bit kernel with a 32-bit userland is a common practice on >> non-x86 platforms, and non-Linux OS's. > > FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while. > About the only thing that doesn't work right is yum wrt kernel updates. > >> For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit >> process address space. ?Both executable code and in-memory data structures >> tend to be smaller on 32-bit. > > Indeed. > > It would be nice if i386-userspace/x64-kernel were officially support.. such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste .... From tgl at redhat.com Sun Dec 13 18:53:05 2009 From: tgl at redhat.com (Tom Lane) Date: Sun, 13 Dec 2009 13:53:05 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> Message-ID: <27016.1260730385@sss.pgh.pa.us> Paul Jakma writes: > On Wed, 18 Nov 2009, Roland McGrath wrote: >> x86 is unlike other architectures because 64-bit also has twice as >> many registers as 32-bit. So you get to trade off the benefits of >> register allocation across more registers against the memory/cache >> footprint of 64-bit pointers. > For what percentage of code is that an appreciable advantage? Pretty much everything, actually. The x86 ISA completely sucks. regards, tom lane From paul at dishone.st Sun Dec 13 19:16:29 2009 From: paul at dishone.st (Paul Jakma) Date: Sun, 13 Dec 2009 19:16:29 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: On Sun, 13 Dec 2009, drago01 wrote: > such a setup does not make much sense, when your hardware supports > x86_64 not using it for userspace is a waste .... a) i386 has a lower memory footprint, as has been mentioned in this thread. b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches - QA - package building and distribution Every supported arch increases the size of the test matrix. Minimising the number of arches you have to, say, test a "cp" bugfix against helps reduce QA load and helps you get better software to your users, faster (better cause you release time spent on architecture QA that can be spent on improving software generally). d) Like or not, i386 is the de-facto standard for binary interfaces: - Netscape plugins - Windows executables The retort no doubt will "Oh but this is Fedora, we don't care about any closed-source stuff", but that would miss the point entirely re *Interface*. The i386 machine can be a plugin interface between 2 different open-source systems, e.g. consider: - VM images to run in, say, QEMU/KVM - Sandboxing technologies for, say, browser plugins (I think Google have stuff in this area) - Free software windows-only apps (don't know if they exist) All the code here can be open-source/free-software and still be relying on i386 as a widely known and hence convenient /interface/. As such, it likely needs to be supported on x86_64 kernel-based systems anyway, as performantly as possible. (And yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). So personally I think x86_64-pure is unrealistic and, independently, I think 32-on-64 makes sense, but hey. :) regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: He who despises himself nevertheless esteems himself as a self-despiser. -- Friedrich Nietzsche From ikem.krueger at googlemail.com Sun Dec 13 19:19:51 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Sun, 13 Dec 2009 19:19:51 +0000 Subject: Promoting i386 version over x86_64? In-Reply-To: <4B1F3AFF.90707@freenet.de> References: <4B05BC21.4040701@bfccomputing.com> <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> Message-ID: >> Fedora has already chosen to make the 32bit builds incompatible with pre-686 systems for performance gains > Yes, a decision I consider to be a Fedora managment mistake. > Seems to me, as if some people in Fedora's leadership don't want to understand that being able to deploy Linux on "old" or "recycled" hardware used to be one big selling point in Linux. > Certainly, Fedora devs tend to be equipped with modern HW, but it's a mistake to believe everybody is. >> I think if your position is that most users don't care about performance and other things (like compatibility) are more important then you should strongly promote x86_64 Fedora for everyone who can use it. > Not quite. My position actually is: Most users don't care much about 1-2% improved performance nor about improved internals (more registers etc.), as long as "their system" does what they want it to do. > That said, these users don't actually care about using 64bit or 32bit Linux, as long as "their applications" behave "reasonable" and as long as the OS is easy to use. > Or differently: I don't need a car with a 250kw engine and 7 seats to drive to the supermarket. My 8-years of VW Polo with its 50kW engine will also do ;) I totally agree with you. :) From ikem.krueger at googlemail.com Sun Dec 13 19:27:48 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Sun, 13 Dec 2009 19:27:48 +0000 Subject: Promoting i386 version over x86_64? In-Reply-To: <1260371650.13006.95.camel@code.and.org> References: <4B1E914E.9010706@freenet.de> <4B1F3AFF.90707@freenet.de> <20091209130507.GA4291@wolff.to> <4B1FB37F.30009@freenet.de> <1260371650.13006.95.camel@code.and.org> Message-ID: > if _you_ want to support slower machines ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l "Everyone should solve my problems" is unlikely to actually help. IMO. I would if I could. I can't program. Else I would just shutup and would DO the work! So the only thing I can do is "babel". Alternative I can just sit there and see how the things become worse.. From paul at dishone.st Sun Dec 13 19:27:45 2009 From: paul at dishone.st (Paul Jakma) Date: Sun, 13 Dec 2009 19:27:45 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: On Sun, 13 Dec 2009, Paul Jakma wrote: > b) The amount of code on your system that is CPU bound and/or > memory-bound due to register pressure, to an extent that the x64 > faster AFAICT, and there's plenty of experience to say that most > software is far from CPU bound or memory bound. Oops, this is unclear - "memory bound" here in these 2 cases refers to memory-I/O, not amount of memory. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Plus ,ca change, plus c'est la m^eme chose. [The more things change, the more they remain the same.] -- Alphonse Karr, "Les Gu^epes" From drago01 at gmail.com Sun Dec 13 20:09:17 2009 From: drago01 at gmail.com (drago01) Date: Sun, 13 Dec 2009 21:09:17 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma wrote: > On Sun, 13 Dec 2009, drago01 wrote: > >> such a setup does not make much sense, when your hardware supports x86_64 >> not using it for userspace is a waste .... > > a) i386 has a lower memory footprint, as has been mentioned in this > ? thread. Yes which is pretty much the only valid complaint but trading memory for performance is a price I am willing to take ... > b) The amount of code on your system that is CPU bound and/or > ? memory-bound due to register pressure, to an extent that the x64 > ? registers would make an appreciable difference is probably not > ? that significant > > ? - kernel hotpots The kernel doesn't do any have computing... > ? - graphics hotspots (X server perhaps) > > ? I havn't measured this, but nor have the people who say x86_64 is > ? faster AFAICT, and there's plenty of experience to say that most > ? software is far from CPU bound or memory bound. Yes but the stuff adds up, you gain almost nothing by running i686 code but where it matters x86_64 can make a HUGE difference. > c) There is a definite cost to a distro in having to maintain 2 > ? x86_64 and i386 as separate arches Not a reason to move forward with hardware development. > > d) Like or not, i386 is the de-facto standard for binary interfaces: > > ? - Netscape plugins This is slowly being fixed. > ? - Windows executables Nobody stops you from running i386 apps on a x86_64 system. > ? - VM images to run in, say, QEMU/KVM > ? - Sandboxing technologies for, say, browser plugins (I think > ? ? Google have stuff in this area) > ? - Free software windows-only apps (don't know if they exist) > > ? All the code here can be open-source/free-software and still be > ? relying on i386 as a widely known and hence convenient > ? /interface/. As such, it likely needs to be supported on x86_64 > ? kernel-based systems anyway, as performantly as possible. (And > ? yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). Er.. don't quite get your point here, what is stopping me from running i686 VMs on a x86_64 host? I have been doing this for a while and there are there problems (you don't even need multilib for that) > So personally I think x86_64-pure is unrealistic and, independently, I think > 32-on-64 makes sense, but hey. :) I did not suggest using pure x86_64 but using x86_64 where we can (ie. not just the kernel). From drago01 at gmail.com Sun Dec 13 20:10:37 2009 From: drago01 at gmail.com (drago01) Date: Sun, 13 Dec 2009 21:10:37 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: On Sun, Dec 13, 2009 at 9:09 PM, drago01 wrote: >> c) There is a definite cost to a distro in having to maintain 2 >> ? x86_64 and i386 as separate arches > > Not a reason to move forward with hardware development. reason to _not_ move ... > Er.. don't quite get your point here, what is stopping me from running > i686 VMs on a x86_64 host? > I have been doing this for a while ?and there are there problems (you > don't even need multilib for that) should read _zero_ problems. From henriquecsj at gmail.com Sun Dec 13 21:02:55 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Sun, 13 Dec 2009 19:02:55 -0200 Subject: MariaDB and Fedora In-Reply-To: <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> Message-ID: <1260738175.4566.13.camel@localhost> Em Dom, 2009-12-13 ?s 19:39 +0200, Muayyad AlSadi escreveu: > > Yes, I'm comparing the codes right now and they seems very similar. > > > not the code, the spec > > he means you may start by reusing the spec file of mysql > Yes, I mean the spec (my bad). A draft spec for MariaDB is getting very similar to MySQL's spec (great part works), but I have no intention of submitting it, since I do not have the necessary knowledge in databases to package (and fix) it as it deserves. By the way, Monty is asking for some "Help saving MySQL" [0]. [0] - http://monty-says.blogspot.com/2009/12/help-saving-mysql.html From cmadams at hiwaay.net Sun Dec 13 21:35:27 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 13 Dec 2009 15:35:27 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> Message-ID: <20091213213527.GB1479857@hiwaay.net> Once upon a time, Paul Jakma said: > b) The amount of code on your system that is CPU bound and/or > memory-bound due to register pressure, to an extent that the x64 > registers would make an appreciable difference is probably not > that significant > > - kernel hotpots > - graphics hotspots (X server perhaps) > > I havn't measured this, but nor have the people who say x86_64 is > faster AFAICT, and there's plenty of experience to say that most > software is far from CPU bound or memory bound. As soon as you bring in even one 64 bit user-space program that is run much, you've pulled in at least glibc and friends. At that point, you might as well run all (or as close to all as possible) 64 bit user-space, because the libraries are shared (code will be in the cache, etc.). The only time my systems have run 32 bit code in several years is for the Flash plugin (since the open-source plugins don't seem to be able to keep up and since the 64 bit Adobe plugin doesn't seem to get the security updates) and sometimes the Acrobat Reader plugin (since I've run into websites that assume they can embed PDFs in the page and AFAIK there's no plugin for Evince). Since both cases are not all that common in my every-day use, I don't hit the 32 bit libraries and such very often. Running a single-arch and single-lib system is more efficient. As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. I have one 32 bit desktop at work, and comparing the resident RAM usage between it and a 64 bit desktop, I don't see much difference in the common desktop programs. I know that for some reason PHP on 64 bit arches bloats up significantly (at least older versions), but that's the only major difference I've seen. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jonathan at jonmasters.org Sun Dec 13 21:42:46 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Sun, 13 Dec 2009 16:42:46 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <27016.1260730385@sss.pgh.pa.us> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> Message-ID: <1260740566.6151.16.camel@tonnant> On Sun, 2009-12-13 at 13:53 -0500, Tom Lane wrote: > Paul Jakma writes: > > On Wed, 18 Nov 2009, Roland McGrath wrote: > >> x86 is unlike other architectures because 64-bit also has twice as > >> many registers as 32-bit. So you get to trade off the benefits of > >> register allocation across more registers against the memory/cache > >> footprint of 64-bit pointers. > > > For what percentage of code is that an appreciable advantage? > > Pretty much everything, actually. The x86 ISA completely sucks. Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) and it's not simply a doubling of memory footprint because variable width instructions are used in the first place, and continue to be used in the newer ISA upgrade. Personally, I think anyone running i386 on x86_64 who isn't doing some kind of testing under KVM or similar is completely wasting their computing resources and should receive a free copy of the Intel documentation for the holidays ;) Jon. From cmadams at hiwaay.net Sun Dec 13 22:19:54 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 13 Dec 2009 16:19:54 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <1260740566.6151.16.camel@tonnant> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> Message-ID: <20091213221954.GC1479857@hiwaay.net> Once upon a time, Jon Masters said: > Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very > different beast. Intel fixed a lot of the issues with the (more than 20 > year old really x86 ISA) That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at dishone.st Sun Dec 13 22:24:29 2009 From: paul at dishone.st (Paul Jakma) Date: Sun, 13 Dec 2009 22:24:29 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091213213527.GB1479857@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> Message-ID: On Sun, 13 Dec 2009, Chris Adams wrote: > As soon as you bring in even one 64 bit user-space program that is run > much, you've pulled in at least glibc and friends. At that point, you > might as well run all (or as close to all as possible) 64 bit > user-space, because the libraries are shared (code will be in the cache, > etc.). That's assuming that the footprint of libraries relative to distinct applications is large enough to cancel out the space savings. (I have no data either way). A 64bit kernel doesn't need any 32bit userspace. An X server, on my 32bit system has about 8.5MB of programme text (server and libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. So if you ran a 32bit system with a 64bit kernel and X server, you'd lose out on about 10MB of shareable code. For comparison, my 32bit system has O(10) times that allocated to things like browsers and feed-readers. It's using 4.8GB in total (ex buffers/cache) apparently. Space for text (programmes, code) is simply insignificant these days, compared to the huge amounts of data which programmes allocate - data which sometimes includes a lot of pointers. You're also assuming that this cancels out the other benefits. > The only time my systems have run 32 bit code in several years is for > the Flash plugin (since the open-source plugins don't seem to be able to > keep up and since the 64 bit Adobe plugin doesn't seem to get the > security updates) and sometimes the Acrobat Reader plugin (since I've > run into websites that assume they can embed PDFs in the page and AFAIK > there's no plugin for Evince). It's interesting that both you and drago have "almost always" (to paraphrase) run 64bit pure systems. Surely that *reinforces* my point about the futility of "64bit pure systems" as an achievable goal (in the aggregate across all reasonable uses of a distro), and i386 being a de-facto standard for software interfaces. > As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it > much in the real world. I have one 32 bit desktop at work, and > comparing the resident RAM usage between it and a 64 bit desktop, I > don't see much difference in the common desktop programs. That's the wrong comparison - compare the aggregate RAM usage, with each system in similar states. > I know that for some reason PHP on 64 bit arches bloats up > significantly (at least older versions), but that's the only major > difference I've seen. Pointer rich data structures, likely.. Anyway, as I don't intend to contribute anything, I'll try stop making noise. Aside to the list: Thanks for all the hard-work on Fedora ;) regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Dogs just don't seem to be able to tell the difference between important people and the rest of us. From kevin.kofler at chello.at Sun Dec 13 23:09:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Dec 2009 00:09:59 +0100 Subject: What is public/private fork? - Criteria packaging in fedora References: <4B2204C9.8060804@redhat.com> Message-ID: Huzaifa Sidhpurwala wrote: > I have forked libtar as libtar-ng, because the upstream does not have > time to maintain it anymore. > > Here is the bz: > https://bugzilla.redhat.com/show_bug.cgi?id=546169 > > Now the question is what is a private fork? > Am i wrong in forking it and packaging in fedora? IMHO, this should be packaged, and in a way to Obsoletes/Provides: libtar as it's backwards-compatible and actually actively maintained unlike libtar. The Obsoletes/Provides should of course be versioned, so if a new libtar springs up at a later point (i.e. if the maintainer really goes back to actively developing it), it can be introduced instead of or in addition to the fork. Kevin Kofler From bruno at wolff.to Sun Dec 13 23:20:17 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 13 Dec 2009 17:20:17 -0600 Subject: MariaDB and Fedora In-Reply-To: <1260738175.4566.13.camel@localhost> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> Message-ID: <20091213232017.GA12262@wolff.to> On Sun, Dec 13, 2009 at 19:02:55 -0200, Henrique Junior wrote: > By the way, Monty is asking for some "Help saving MySQL" [0]. Monty can just go and fork it. The only limitation is that he won't be able to dual license it any more. From ngompa13 at gmail.com Sun Dec 13 23:56:31 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Sun, 13 Dec 2009 17:56:31 -0600 Subject: MariaDB and Fedora In-Reply-To: <20091213232017.GA12262@wolff.to> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> Message-ID: <8278b1b0912131556k4b015effofa70e000e9a5c13a@mail.gmail.com> I think he wants to be able to work on the dual licensed version... On Sun, Dec 13, 2009 at 5:20 PM, Bruno Wolff III wrote: > On Sun, Dec 13, 2009 at 19:02:55 -0200, > Henrique Junior wrote: > > By the way, Monty is asking for some "Help saving MySQL" [0]. > > Monty can just go and fork it. The only limitation is that he won't be > able to dual license it any more. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Mon Dec 14 00:20:18 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 13 Dec 2009 18:20:18 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091213221954.GC1479857@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> <20091213221954.GC1479857@hiwaay.net> Message-ID: <20091214002018.GB8257@wolff.to> On Sun, Dec 13, 2009 at 16:19:54 -0600, Chris Adams wrote: > > That would be AMD that fixed it, not Intel. Intel tried to push > everybody to a new architecture (Itanium), while AMD revised and > extended i386 to 64 bits. After Itanium failed to catch on in the > marketplace, Intel had to copy AMD's work. I expect that has a lot to do with AMD being open source friendly. If they had had to rely on Microsoft to get an OS to run on their machine, they probably would have failed as well. From tgl at redhat.com Mon Dec 14 00:27:42 2009 From: tgl at redhat.com (Tom Lane) Date: Sun, 13 Dec 2009 19:27:42 -0500 Subject: MariaDB and Fedora In-Reply-To: <20091213232017.GA12262@wolff.to> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> Message-ID: <2635.1260750462@sss.pgh.pa.us> Bruno Wolff III writes: > Henrique Junior wrote: >> By the way, Monty is asking for some "Help saving MySQL" [0]. > Monty can just go and fork it. The only limitation is that he won't be > able to dual license it any more. Monty thinks it's impossible to make money off open source unless he can dual-license it. Setting aside various existence proofs to the contrary, the fact remains that he already SOLD the rights to dual-license MySQL, when he sold MySQL AB to Sun; and he made a pretty hefty amount of money doing so. Now he'd like the EU to force Oracle to give him back that right for free. This isn't so much about "let's help save MySQL" as it is about "let's help Monty get a second bite of the apple". (FWIW, I completely agree with Monty that Oracle is likely to do their best to kill MySQL once they have it. But they can't kill the GPL'd version as long as people are willing to work on that. Evidently Monty isn't.) regards, tom lane From john5342 at googlemail.com Mon Dec 14 00:32:15 2009 From: john5342 at googlemail.com (John5342) Date: Mon, 14 Dec 2009 00:32:15 +0000 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091214002018.GB8257@wolff.to> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> <20091213221954.GC1479857@hiwaay.net> <20091214002018.GB8257@wolff.to> Message-ID: <6dc6523c0912131632l322ffc5clb8c2aaf20a73ccb7@mail.gmail.com> On Mon, Dec 14, 2009 at 00:20, Bruno Wolff III wrote: > On Sun, Dec 13, 2009 at 16:19:54 -0600, > ?Chris Adams wrote: >> >> That would be AMD that fixed it, not Intel. ?Intel tried to push >> everybody to a new architecture (Itanium), while AMD revised and >> extended i386 to 64 bits. ?After Itanium failed to catch on in the >> marketplace, Intel had to copy AMD's work. > > I expect that has a lot to do with AMD being open source friendly. If they > had had to rely on Microsoft to get an OS to run on their machine, they > probably would have failed as well. Actually i think the reason AMDs approach worked was because it was backward compatible with ix86 so instead of having to have an OS ready up front and people having to migrate wholesale customers could start upgrading to x86_64 processors slowly while still using 32bit OS. Then as 64bit OS becomes available people can use that whilst still enjoying their favorite apps that haven't yet been ported to 64bit. In short it was evolutionary rather than revolutionary. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From bruno at wolff.to Mon Dec 14 02:35:51 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 13 Dec 2009 20:35:51 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <6dc6523c0912131632l322ffc5clb8c2aaf20a73ccb7@mail.gmail.com> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> <20091213221954.GC1479857@hiwaay.net> <20091214002018.GB8257@wolff.to> <6dc6523c0912131632l322ffc5clb8c2aaf20a73ccb7@mail.gmail.com> Message-ID: <20091214023551.GA26374@wolff.to> On Mon, Dec 14, 2009 at 00:32:15 +0000, John5342 wrote: > > Actually i think the reason AMDs approach worked was because it was > backward compatible with ix86 so instead of having to have an OS ready > up front and people having to migrate wholesale customers could start > upgrading to x86_64 processors slowly while still using 32bit OS. Then > as 64bit OS becomes available people can use that whilst still > enjoying their favorite apps that haven't yet been ported to 64bit. In > short it was evolutionary rather than revolutionary. I think that was also needed. But I don't think they would have been able to get traction in the server market without having the prompt linux / gcc support. From bruno at wolff.to Mon Dec 14 02:48:01 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 13 Dec 2009 20:48:01 -0600 Subject: MariaDB and Fedora In-Reply-To: <2635.1260750462@sss.pgh.pa.us> References: <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> Message-ID: <20091214024801.GB26374@wolff.to> On Sun, Dec 13, 2009 at 19:27:42 -0500, Tom Lane wrote: > > Monty thinks it's impossible to make money off open source unless he > can dual-license it. Setting aside various existence proofs to the > contrary, the fact remains that he already SOLD the rights to > dual-license MySQL, when he sold MySQL AB to Sun; and he made a pretty > hefty amount of money doing so. Now he'd like the EU to force Oracle to > give him back that right for free. This isn't so much about "let's help > save MySQL" as it is about "let's help Monty get a second bite of the > apple". > > (FWIW, I completely agree with Monty that Oracle is likely to do their > best to kill MySQL once they have it. But they can't kill the GPL'd > version as long as people are willing to work on that. Evidently > Monty isn't.) I pretty much agree with all of the above. I don't feel sorry for Monty. With all of the money he got I wouldn't have expected money to be an issue. If he wants to work on a fork he can afford to, and if he doesn't want to work on one, money is unlikely to provide enough incentive to make him want to either. I don't really see a downside if Oracle does kill off new MySQL development, as Postgres has been better for a very long while and Postgres might get more / better out of the box support (and proper use) from open source applications. From ngompa13 at gmail.com Mon Dec 14 02:52:33 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Sun, 13 Dec 2009 20:52:33 -0600 Subject: MariaDB and Fedora In-Reply-To: <20091214024801.GB26374@wolff.to> References: <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> Message-ID: <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> On Sun, Dec 13, 2009 at 8:48 PM, Bruno Wolff III wrote: > On Sun, Dec 13, 2009 at 19:27:42 -0500, > Tom Lane wrote: > > > > Monty thinks it's impossible to make money off open source unless he > > can dual-license it. Setting aside various existence proofs to the > > contrary, the fact remains that he already SOLD the rights to > > dual-license MySQL, when he sold MySQL AB to Sun; and he made a pretty > > hefty amount of money doing so. Now he'd like the EU to force Oracle to > > give him back that right for free. This isn't so much about "let's help > > save MySQL" as it is about "let's help Monty get a second bite of the > > apple". > > > > (FWIW, I completely agree with Monty that Oracle is likely to do their > > best to kill MySQL once they have it. But they can't kill the GPL'd > > version as long as people are willing to work on that. Evidently > > Monty isn't.) > > I pretty much agree with all of the above. I don't feel sorry for Monty. > With all of the money he got I wouldn't have expected money to be an issue. > If he wants to work on a fork he can afford to, and if he doesn't want to > work on one, money is unlikely to provide enough incentive to make him > want to either. > > I don't really see a downside if Oracle does kill off new MySQL > development, > as Postgres has been better for a very long while and Postgres might get > more / better out of the box support (and proper use) from open source > applications. > > I dunno. While I did push for the CMS project I work on to support PostgreSQL, I personally think that Postgres is huge overkill for most things. It can also be a huge PITA to set up. Whenever I have to test Postgres stuff, I usually grab EnterpriseDB's distribution because I don't want to suffer hell setting it up on the various platforms I have to test on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huzaifas at redhat.com Mon Dec 14 03:33:29 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 14 Dec 2009 09:03:29 +0530 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B24B822.2060208@fedoraproject.org> References: <4B24B822.2060208@fedoraproject.org> Message-ID: <4B25B209.1050105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I want to take it Rahul Sundaram wrote: > Hi > > It is a application that lets you minimize any app to the system tray > and is compatible with GNOME, Xfce, KDE etc. It has a dormant upstream > and I haven't had time to look into all the crash reports from Abrt. If > noone picks it up, I will orphan it in a week. > > $ yum info alltray > Loaded plugins: presto, refresh-packagekit > Available Packages > Name : alltray > Arch : i686 > Version : 0.70 > Release : 4.fc12 > Size : 62 k > Repo : fedora > Summary : Dock any application in the tray > URL : http://alltray.sourceforge.net/ > License : GPLv2+ > > Rahul > - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) IT Desktop R&D Lead. Global Help Desk, Pune (India) Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLJbIJzHDc8tpb2uURAp5wAKCYrStfIZKX1ZVfxGvUmf8sb39ZiQCaAtEC nwXZCdvX+RNrUo7OGYYzCCo= =147O -----END PGP SIGNATURE----- From nathanael at gnat.ca Mon Dec 14 03:56:38 2009 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun, 13 Dec 2009 20:56:38 -0700 Subject: MariaDB and Fedora In-Reply-To: <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> References: <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> Message-ID: <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> On Dec 13, 2009, at 7:52 PM, Sir Gallantmon wrote: > On Sun, Dec 13, 2009 at 8:48 PM, Bruno Wolff III wrote: > > I dunno. While I did push for the CMS project I work on to support PostgreSQL, I personally think that Postgres is huge overkill for most things. It can also be a huge PITA to set up. Whenever I have to test Postgres stuff, I usually grab EnterpriseDB's distribution because I don't want to suffer hell setting it up on the various platforms I have to test on. As a DBA / Developer, I second this... obviously I can't complain because they are both free. However the setup/configuration of postgreSQL compared to MySQL is basically something easy, versus something where I don't have a clue what is going on, and there are million ways to do it, and when I'm done I have no idea if I'm wide open to the entire world, or as secure as on MySQL. There are a few other odd bits too, I mean I really don't get the purpose of copying template1, what is that? etc etc etc... MySQL is just more intuitive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Dec 14 04:13:15 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 13 Dec 2009 22:13:15 -0600 (CST) Subject: cvs.fedora.redhat.com Message-ID: Some of you that have very old checkouts (I'm looking at you Domsch!) might still be trying to contact cvs.fedora.redhat.com. If you try to use cvs in the future and it's not working suddenly, make sure your CVSROOT points to cvs.fedoraproject.org and do a fresh checkout. -Mike From jonathan at jonmasters.org Mon Dec 14 06:56:17 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Mon, 14 Dec 2009 01:56:17 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091213221954.GC1479857@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> <20091213221954.GC1479857@hiwaay.net> Message-ID: <1260773777.6151.32.camel@tonnant> On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote: > Once upon a time, Jon Masters said: > > Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very > > different beast. Intel fixed a lot of the issues with the (more than 20 > > year old really x86 ISA) > > That would be AMD that fixed it, not Intel. Intel tried to push > everybody to a new architecture (Itanium), while AMD revised and > extended i386 to 64 bits. After Itanium failed to catch on in the > marketplace, Intel had to copy AMD's work. That's presumptuous and unfair. Sure, without AMD and others we'd likely be on Itanium (which I actually quite like as an architecture) but Intel 64 isn't just some copy-and-paste effort either. Besides, whatever the history we shouldn't be encouraging people to use plain older x86. Jon. From josephine.tannhauser at googlemail.com Mon Dec 14 07:06:48 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 14 Dec 2009 08:06:48 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <20091206104812.GB8376@lisas.de> References: <20091206104812.GB8376@lisas.de> Message-ID: <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> 2009/12/6, Adrian Reber : > https://bugzilla.redhat.com/show_bug.cgi?id=544720 This is not a lib! -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From sundaram at fedoraproject.org Mon Dec 14 07:14:29 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 Dec 2009 12:44:29 +0530 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B25B209.1050105@redhat.com> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> Message-ID: <4B25E5D5.9080405@fedoraproject.org> On 12/14/2009 09:03 AM, Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > I want to take it > It is all yours now. Have fun. Rahul From fedora at camperquake.de Mon Dec 14 07:43:03 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 14 Dec 2009 08:43:03 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091213213527.GB1479857@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> Message-ID: <20091214084303.6a4c0dd0@dhcp03.addix.net> Hi. On Sun, 13 Dec 2009 15:35:27 -0600, Chris Adams wrote: > The only time my systems have run 32 bit code in several years is for > the Flash plugin (since the open-source plugins don't seem to be able > to keep up and since the 64 bit Adobe plugin doesn't seem to get the > security updates) It does. There may not be a yum repo for it, but the last update was some days ago to 10.0 r42, similar to the 32 bit version. From huzaifas at redhat.com Mon Dec 14 08:30:06 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 14 Dec 2009 14:00:06 +0530 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: References: <4B2204C9.8060804@redhat.com> Message-ID: <4B25F78E.5040604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, So taking into consideration all the feed back , here are the changes done: - - bump soname in the code from 1.2.11 to 1.2.12 - - In the srpm, libtar-ng now obsoletes libtar, so that the conflicts are resolved. - - Tar ball is bz2 and not gzip to save space. - - The autom4te.cache dir is now removed. - - License changes from MIT to BSD as per the original suggestion of the author. - - Removed README.new from the tar and updated README with new code details, Also updated COPYRIGHT, while retaining the original clauses. SPEC: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec SRPM: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-1.fc12.src.rpm Any more comments/suggestions would be welcome. Kevin Kofler wrote: > Huzaifa Sidhpurwala wrote: >> I have forked libtar as libtar-ng, because the upstream does not have >> time to maintain it anymore. >> >> Here is the bz: >> https://bugzilla.redhat.com/show_bug.cgi?id=546169 >> >> Now the question is what is a private fork? >> Am i wrong in forking it and packaging in fedora? > > IMHO, this should be packaged, and in a way to Obsoletes/Provides: libtar as > it's backwards-compatible and actually actively maintained unlike libtar. > The Obsoletes/Provides should of course be versioned, so if a new libtar > springs up at a later point (i.e. if the maintainer really goes back to > actively developing it), it can be introduced instead of or in addition to > the fork. > > Kevin Kofler > - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLJfeNzHDc8tpb2uURAmAPAJ95Bi1pavbb9YmT6vfksjHzgf59rgCfXm75 E+X/Aa6LF+RwXiq7ExupLUQ= =oSV4 -----END PGP SIGNATURE----- From jgarzik at pobox.com Mon Dec 14 08:41:19 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 14 Dec 2009 03:41:19 -0500 Subject: F12 great on Wal-Mart special Message-ID: <4B25FA2F.5050401@pobox.com> Wal-Mart just sold a few million of these laptops at $299 a pop (entire in-store inventory nationwide sold in under 24 hours): http://www.walmart.com/catalog/product.do?product_id=12456200 AMD CPU, ATI graphics, RealTek wireless & ethernet, SATA/300 hard drive, CD/DVD reader+burner. And all of it works flawlessly on Fedora 12/x86-64, including dual-boot with the installed Windows 7. Kudos to everyone, especially the wireless and X/graphics hackers. This was a volume platform that IMO Fedora could not afford to screw up, and F12 easily gets high marks. Jeff 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge 00:01.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (int gfx) 00:04.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 0) 00:05.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 1) 00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2) 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] 00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller 00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller 00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller 00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller 00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller 00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a) 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 11h HyperTransport Configuration (rev 40) 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 11h Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 11h DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 11h Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 11h Link Control 01:05.0 VGA compatible controller: ATI Technologies Inc RS780MC [Radeon HD 3100 Graphics] 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02) From andre at bwh.harvard.edu Mon Dec 14 09:12:31 2009 From: andre at bwh.harvard.edu (Andre Robatino) Date: Mon, 14 Dec 2009 04:12:31 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) Message-ID: <4B26017F.2010907@bwh.harvard.edu> Ralf Ertzinger wrote: > It does. There may not be a yum repo for it, but the last update was > some days ago to 10.0 r42, similar to the 32 bit version. There is an unofficial yum repo for 64-bit flash-plugin: http://forums.fedoraforum.org/showthread.php?t=205642 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Mon Dec 14 09:19:26 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 10:19:26 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> Message-ID: <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> Le Lun 14 d?cembre 2009 08:06, Josephine Tannh?user a ?crit : > > 2009/12/6, Adrian Reber : >> https://bugzilla.redhat.com/show_bug.cgi?id=544720 > This is not a lib! The guidelines should be read as: ? Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons ? (Just IMHO, that's the guidelines spirit, the guidelines text should be amended in a non-library-oriented wording, libs are the most common case but they're not the only one) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Dec 14 09:27:33 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 10:27:33 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091213213527.GB1479857@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> Message-ID: <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> Le Dim 13 d?cembre 2009 22:35, Chris Adams a ?crit : > As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it > much in the real world. The worst case I've seen reported is when the RAM overhead managed to annihilate register improvements (worst case in a very specific load). So "RAM overhead" is pretty much a urban myth on x86_64 -- Nicolas Mailhot From supercyper at 163.com Mon Dec 14 09:31:30 2009 From: supercyper at 163.com (supercyper) Date: Mon, 14 Dec 2009 17:31:30 +0800 (CST) Subject: Need a sponsor to review my packages Message-ID: <12259574.296231260783090906.JavaMail.coremail@app190.163.com> Hi The qtiplot hasn't been maintained since 20081215, see http://koji.fedoraproject.org/koji/packageinfo?packageID=5171. I want to sync qtiplot version with upstream. I need a sponsor to review the following two packages, which are required by qtiplot 0.9.7.10: https://bugzilla.redhat.com/show_bug.cgi?id=liborigin2 https://bugzilla.redhat.com/show_bug.cgi?id=542313 Later if possible, I would like to be a comaintainer for qtiplot. Anyone can help me? Qtiplot may be the best opensource alternatives of origin. Thanks Chen Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.moix at axianet.ch Mon Dec 14 09:32:48 2009 From: steven.moix at axianet.ch (Steven Moix) Date: Mon, 14 Dec 2009 10:32:48 +0100 Subject: MariaDB and Fedora In-Reply-To: <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> References: <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> Message-ID: <4B260640.6040801@axianet.ch> Hi On 12/14/2009 04:56 AM, Nathanael Noblet wrote: > > As a DBA / Developer, I second this... obviously I can't complain > because they are both free. However the setup/configuration of > postgreSQL compared to MySQL is basically something easy, versus > something where I don't have a clue what is going on, and there are > million ways to do it, and when I'm done I have no idea if I'm wide open > to the entire world, or as secure as on MySQL. There are a few other odd > bits too, I mean I really don't get the purpose of copying template1, > what is that? etc etc etc... MySQL is just more intuitive. I agree on that, and a "major" problem with PostgreSQL at the moment is that it doesn't have a clustering engine. So MySQL is still the simplest choice out there for the end user. Steven From nicolas.mailhot at laposte.net Mon Dec 14 09:37:15 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 10:37:15 +0100 Subject: MariaDB and Fedora In-Reply-To: <20091213232017.GA12262@wolff.to> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> Message-ID: Le Lun 14 d?cembre 2009 00:20, Bruno Wolff III a ?crit : > > On Sun, Dec 13, 2009 at 19:02:55 -0200, > Henrique Junior wrote: >> By the way, Monty is asking for some "Help saving MySQL" [0]. > > Monty can just go and fork it. The only limitation is that he won't be > able to dual license it any more. Yes, unfortunately a lot of the noise against the SUN/Oracle merger is people that just want the licensing changed because they can't imagine building a successful company on GPL software (very sad). The same kind of people splintered the open source Java community by refusing to help sun when it GPL-ed the JVM and diverting resources to new projetcs instead. That being said, Mysql *does* compete with Oracle (not technically, but commercially very much so, it kills the "use one db everywhere" corp market paradigm where Oracle is all too happy to count cpus for lots of small Oracle databases), and this competition relies on the Mysql brand (that finally managed to reach CTO awareness level), and Oracle getting its hand on the brand would definitely lower competition for several years (and I don't have any SAP or other shares). -- Nicolas Mailhot From mschwendt at gmail.com Mon Dec 14 10:24:56 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 14 Dec 2009 11:24:56 +0100 Subject: What is public/private fork? - Criteria packaging in fedora In-Reply-To: <4B25F78E.5040604@redhat.com> References: <4B2204C9.8060804@redhat.com> <4B25F78E.5040604@redhat.com> Message-ID: <20091214112456.765ed062@gmail.com> On Mon, 14 Dec 2009 14:00:06 +0530, Huzaifa wrote: > Hi, > So taking into consideration all the feed back , here are the changes done: > > - - bump soname in the code from 1.2.11 to 1.2.12 Please, with further comments on this package let's limit ourselves to one place only. _Eiter_ the review request ticket _or_ this list, but no cross-comment madness which requires answers in multiple places. With that said, 1.2.12 has not touched the SONAME at all. http://bugzilla.redhat.com/546169 From josephine.tannhauser at googlemail.com Mon Dec 14 10:28:08 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 14 Dec 2009 11:28:08 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> Message-ID: <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> 2009/12/14, Nicolas Mailhot : > The guidelines should be read as: > > ? Bundling any other component your component depends on in the same package > is forbidden; each component should be packaged separately in its own > package > for legal and maintenance reasons ? This is more a wishful thinking than a practical thing.... The guidelines should be a system of rules without place for everyone to interprete in it what he/she wants to see in the guidelines. -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From nicolas.mailhot at laposte.net Mon Dec 14 10:41:40 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 11:41:40 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> Message-ID: <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> Le Lun 14 d?cembre 2009 11:28, Josephine Tannh?user a ?crit : > > 2009/12/14, Nicolas Mailhot : >> The guidelines should be read as: >> >> ? Bundling any other component your component depends on in the same package >> is forbidden; each component should be packaged separately in its own >> package >> for legal and maintenance reasons ? > This is more a wishful thinking than a practical thing.... > The guidelines should be a system of rules without place for everyone > to interprete in it what he/she wants to see in the guidelines. I don't have the time right now but I personally would not hesitate to propose this as a formal packaging guideline if FPC feels it is not what the current guidelines intended (but did not express cleanly). Every domain I've packaged has the same recurring maintenance problems with bundled components (be it libraries, java jars, reference files), there is nothing library specific in the problems bundling causes (forking, non tracking of upstream fixes, conflicts, etc) So, you may think this is wishful thinking, but on my experience it is a very practical and pragmatic rule. Bundling helps you get new components in fast and then makes package maintenance a burden forever (years after years). -- Nicolas Mailhot From debarshi.ray at gmail.com Mon Dec 14 11:26:09 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon, 14 Dec 2009 13:26:09 +0200 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> Message-ID: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> > That's assuming that the footprint of libraries relative to distinct > applications is large enough to cancel out the space savings. (I have no > data either way). A 64bit kernel doesn't need any 32bit userspace. An X > server, on my 32bit system has about 8.5MB of programme text (server and > libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. Regarding shared libraries its worth noting the point about "Instruction pointer relative data access": http://en.wikipedia.org/wiki/X86-64#Architectural_features Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From josephine.tannhauser at googlemail.com Mon Dec 14 11:45:02 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 14 Dec 2009 12:45:02 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> Message-ID: <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> of course this is a practicable rule, BUT the problem is upstream or the rule itself. kernels internal zlib is not a lib its a module, wordpress internal php-gettext is not a lib, its a php code file. The trick is to declare that a lib is not a lib and you can close the bug as not a bug... Easy cake.. -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From rc040203 at freenet.de Mon Dec 14 11:51:22 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 Dec 2009 12:51:22 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> Message-ID: <4B2626BA.6060109@freenet.de> On 12/14/2009 10:27 AM, Nicolas Mailhot wrote: > > > Le Dim 13 d?cembre 2009 22:35, Chris Adams a ?crit : > >> As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it >> much in the real world. > > The worst case I've seen reported is when the RAM overhead managed to > annihilate register improvements (worst case in a very specific load). So "RAM > overhead" is pretty much a urban myth on x86_64 It's not an urban myth - Conversely, it can quite easily be proven: int main() { long i; void *array[1000000]; for ( i = 0; i < 1000000; i++ ) { array[i] = (void*) i; }; while(1) {}; } Compile this snippet for -m64/-m32: # gcc -m64 -o test-64 -Wall test.c # gcc -m32 -o test-32 -Wall test.c Then run them and watch memory consumption (here "top"): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5909 corsepiu 20 0 11536 8128 248 R 100.0 0.4 0:16.93 test-64 5903 corsepiu 20 0 5560 4180 224 R 99.0 0.2 1:10.20 test-32 QED Of course, this is an extreme case, but they also aren't "that rare" in real world cases. Ralf From schwab at redhat.com Mon Dec 14 11:56:30 2009 From: schwab at redhat.com (Andreas Schwab) Date: Mon, 14 Dec 2009 12:56:30 +0100 Subject: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion In-Reply-To: <87638cp81r.fsf@meyering.net> (Jim Meyering's message of "Sat, 12 Dec 2009 15:43:12 +0100") References: <1260503641.30425.45.camel@localhost.localdomain> <87638cp81r.fsf@meyering.net> Message-ID: Jim Meyering writes: > Does anyone know of a public and *maintained* repository for parsecvs? > I've looked numerous times (as recently as a few weeks ago), and tried > to contact Keith Packard, hoping he would still be maintaining it, > but have had no luck. I've recently pushed a few changes to a fork of the tree @ repo.or.cz. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From paul at dishone.st Mon Dec 14 12:16:50 2009 From: paul at dishone.st (Paul Jakma) Date: Mon, 14 Dec 2009 12:16:50 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <4B2626BA.6060109@freenet.de> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> <4B2626BA.6060109@freenet.de> Message-ID: On Mon, 14 Dec 2009, Ralf Corsepius wrote: > Of course, this is an extreme case, It isn't that extreme - pointers can make up a significant component of data-structures. E.g. any programme that has to store many instances of small amounts of data, the pointer size can have a big impact on memory usage. If the data is heavily inter-linked, even more so. Whether that's the case for most applications, I do not know however. It would though be interesting for someone to go measure this, especially in the aggregate. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: If this is timesharing, give me my share right now. From nicolas.mailhot at laposte.net Mon Dec 14 12:27:52 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 13:27:52 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> Message-ID: <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> Le Lun 14 d?cembre 2009 12:45, Josephine Tannh?user a ?crit : > > of course this is a practicable rule, BUT > the problem is upstream or the rule itself. > > kernels internal zlib is not a lib its a module, > wordpress internal php-gettext is not a lib, its a php code file. > > The trick is to declare that a lib is not a lib and you can close the > bug as not a bug... > Easy cake.. This is playing with words. I'm sure that when the guideline was written lib was intended as "some code in any language that can be shared". What is less clear is the other shared components which are not code (resource files, fonts, templates, etc) but there is no doubt at all in my mind on the code part. Though your interpretation is one reason we keep refining guidelines to leave no room for bad packager excuses. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Dec 14 12:31:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 13:31:16 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <4B2626BA.6060109@freenet.de> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> <4B2626BA.6060109@freenet.de> Message-ID: <702f4d036d021d506556f84e825ce6a4.squirrel@arekh.dyndns.org> Le Lun 14 d?cembre 2009 12:51, Ralf Corsepius a ?crit : > Of course, this is an extreme case, but they also aren't "that rare" in > real world cases. They aren't "that rare" on very specific workloads (numeric computation). People in those fields often have large datasets that appreciate lots of memory (ours work with GiB-sized datasets at least) -- Nicolas Mailhot From paul at dishone.st Mon Dec 14 12:33:26 2009 From: paul at dishone.st (Paul Jakma) Date: Mon, 14 Dec 2009 12:33:26 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: On Mon, 14 Dec 2009, Debarshi Ray wrote: > Regarding shared libraries its worth noting the point about > "Instruction pointer relative data access": > http://en.wikipedia.org/wiki/X86-64#Architectural_features You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. The point is that few applications need to be 64bit (this may change in time, when email and browser apps start to demand 4GB+, but that time is a while away - per-process memory demands should stay flat for a while if browsers and the like switch from single-process/multi-threaded to a multi-processes model). For the few apps where it makes a difference, sure, run them as 64bit. (Also, please assume in any replies that I have a modicum of clue about the low-level technical details between i386 and x86_64). regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: magnetic interferance from money/credit cards From jwboyer at gmail.com Mon Dec 14 12:34:44 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 14 Dec 2009 07:34:44 -0500 Subject: cvs.fedora.redhat.com In-Reply-To: References: Message-ID: <20091214123444.GB16448@hansolo.jdub.homelinux.org> On Sun, Dec 13, 2009 at 10:13:15PM -0600, Mike McGrath wrote: >Some of you that have very old checkouts (I'm looking at you Domsch!) >might still be trying to contact cvs.fedora.redhat.com. If you try to use >cvs in the future and it's not working suddenly, make sure your CVSROOT >points to cvs.fedoraproject.org and do a fresh checkout. The script that builds rawhide was still using this. I've fixed it on the master branch of the releng git repo. Someone will need to move the tag that is used to build rawhide. josh From Matt_Domsch at dell.com Mon Dec 14 13:16:19 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 14 Dec 2009 07:16:19 -0600 Subject: cvs.fedora.redhat.com In-Reply-To: References: Message-ID: <20091214131619.GA16814@auslistsprd01.us.dell.com> On Sun, Dec 13, 2009 at 10:13:15PM -0600, Mike McGrath wrote: > Some of you that have very old checkouts (I'm looking at you Domsch!) > might still be trying to contact cvs.fedora.redhat.com. If you try to use > cvs in the future and it's not working suddenly, make sure your CVSROOT > points to cvs.fedoraproject.org and do a fresh checkout. You can also use this to rewrite the CVS/Root files. find . -name Root -exec sed -i -e \ 's/cvs.fedora.redhat.com/cvs.fedoraproject.org/' \{\} \; Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From nicolas.mailhot at laposte.net Mon Dec 14 13:23:51 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 14:23:51 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <702f4d036d021d506556f84e825ce6a4.squirrel@arekh.dyndns.org> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <2fb355add74484ca61be7b91cce54819.squirrel@arekh.dyndns.org> <4B2626BA.6060109@freenet.de> <702f4d036d021d506556f84e825ce6a4.squirrel@arekh.dyndns.org> Message-ID: <4bfb330703395f846adcb4f234e71997.squirrel@arekh.dyndns.org> Le Lun 14 d?cembre 2009 13:31, Nicolas Mailhot a ?crit : > > > > Le Lun 14 d?cembre 2009 12:51, Ralf Corsepius a ?crit : > >> Of course, this is an extreme case, but they also aren't "that rare" in >> real world cases. > > They aren't "that rare" on very specific workloads (numeric computation). > People in those fields often have large datasets that appreciate lots of > memory (ours work with GiB-sized datasets at least) BTW, I didn't claim the overhead didn't exist, just that it was more than compensated in practice by access to more memory and architecture improvements in real world use cases (for the people who care about performance, ie people who are ready to buy a ram stick to win a few percentages in speed tests. If speed is not worth a ram stick for you given today's ridiculous ram prices you should not argue in some percentages more or less in processing times) -- Nicolas Mailhot From sailer at sailer.dynip.lugs.ch Mon Dec 14 13:57:44 2009 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Mon, 14 Dec 2009 14:57:44 +0100 Subject: Is bodhi supposed to be fully working again? Message-ID: <1260799064.15816.30.camel@xbox360.hq.axsem.com> Is Bodhi (aka https://admin.fedoraproject.org/updates/) supposed to be fully working again? I can login, but whenever I try to add a new update, I get "500 Internal error" after clicking on "Save Update" and waiting a minute or so. Tom From rjones at redhat.com Mon Dec 14 14:20:27 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Dec 2009 14:20:27 +0000 Subject: cvs.fedora.redhat.com In-Reply-To: <20091214131619.GA16814@auslistsprd01.us.dell.com> References: <20091214131619.GA16814@auslistsprd01.us.dell.com> Message-ID: <20091214142027.GA21989@amd.home.annexia.org> On Mon, Dec 14, 2009 at 07:16:19AM -0600, Matt Domsch wrote: > On Sun, Dec 13, 2009 at 10:13:15PM -0600, Mike McGrath wrote: > > Some of you that have very old checkouts (I'm looking at you Domsch!) > > might still be trying to contact cvs.fedora.redhat.com. If you try to use > > cvs in the future and it's not working suddenly, make sure your CVSROOT > > points to cvs.fedoraproject.org and do a fresh checkout. > > You can also use this to rewrite the CVS/Root files. > > find . -name Root -exec sed -i -e \ > 's/cvs.fedora.redhat.com/cvs.fedoraproject.org/' \{\} \; Or the command 'cvschroot' in package cvsutils. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From bnocera at redhat.com Mon Dec 14 13:42:42 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 14 Dec 2009 13:42:42 +0000 Subject: "make update" broken? Message-ID: <1260798163.3311.5674.camel@localhost.localdomain> Ideas? $ make update Creating a new update for gnome-bluetooth-2.28.4-2.fc12 Password for hadess: Creating a new update for gnome-bluetooth-2.28.4-2.fc12 ServerError(https://admin.fedoraproject.org/updates/save, 500, Internal Server Error) Traceback (most recent call last): File "/usr/bin/bodhi", line 153, in main data = bodhi.save(**update_args) File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111, in save 'bugs': bugs, File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line 316, in send_request req_params = req_params, auth_params = auth_params) File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line 292, in send_request raise ServerError(url, http_status, msg) ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 500, Internal Server Error) make: *** [bodhi] Error 255 From jeff at ocjtech.us Mon Dec 14 14:29:49 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 14 Dec 2009 08:29:49 -0600 Subject: "make update" broken? In-Reply-To: <1260798163.3311.5674.camel@localhost.localdomain> References: <1260798163.3311.5674.camel@localhost.localdomain> Message-ID: <935ead450912140629v7991adafkbba3b09142d45fd7@mail.gmail.com> On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera wrote: > Ideas? The Fedora Infrastrutcure is being moved to a new datacenter: https://www.redhat.com/archives/fedora-announce-list/2009-December/msg00008.html https://fedorahosted.org/fedora-infrastructure/ticket/1845 -- Jeff Ollie From jan.kratochvil at redhat.com Mon Dec 14 14:36:04 2009 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 14 Dec 2009 15:36:04 +0100 Subject: cvs.fedora.redhat.com In-Reply-To: References: Message-ID: <20091214143604.GA30524@host0.dyn.jankratochvil.net> On Mon, 14 Dec 2009 05:13:15 +0100, Mike McGrath wrote: > Some of you that have very old checkouts (I'm looking at you Domsch!) > might still be trying to contact cvs.fedora.redhat.com. If you try to use > cvs in the future and it's not working suddenly, make sure your CVSROOT > points to cvs.fedoraproject.org and do a fresh checkout. Wouldn't it be worth to setup some dummy host printing such message on SSH banned login? I was still waiting for cvs.fedora.redhat.com until the outage ends. Regads, Jan From bnocera at redhat.com Mon Dec 14 14:43:34 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 14 Dec 2009 14:43:34 +0000 Subject: "make update" broken? In-Reply-To: <935ead450912140629v7991adafkbba3b09142d45fd7@mail.gmail.com> References: <1260798163.3311.5674.camel@localhost.localdomain> <935ead450912140629v7991adafkbba3b09142d45fd7@mail.gmail.com> Message-ID: <1260801814.3311.5738.camel@localhost.localdomain> On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: > On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera wrote: > > Ideas? > > The Fedora Infrastrutcure is being moved to a new datacenter: > > https://www.redhat.com/archives/fedora-announce-list/2009-December/msg00008.html > https://fedorahosted.org/fedora-infrastructure/ticket/1845 I though this was finished already. I guess not... From ajax at redhat.com Mon Dec 14 14:44:23 2009 From: ajax at redhat.com (Adam Jackson) Date: Mon, 14 Dec 2009 09:44:23 -0500 Subject: X on UEFI systems. In-Reply-To: <4B22C450.20008@redhat.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> <4B22C450.20008@redhat.com> Message-ID: <1260801863.7251.31725.camel@atropine.boston.devel.redhat.com> On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: > On 12/11/2009 02:41 PM, Adam Williamson wrote: > > On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: > >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of > >> the dmesg command (all from inside of VB virtual machine, of course). > > > > ...aaaand (oh boy, I love it when a plan comes together) mark it as > > blocking F13Beta , because I reckon this breaks beta criterion #4: > > > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > I like the sentiment here, but I'm not sure this is really in the > spirit of the criteria - Vasily, as I understand it, is still in the > process of implementing the support for UEFI on VirtualBox. There's at least two issues here. One is that we're not shipping the native X driver for vbox video yet. Last I checked this was because it's hidden away in the vbox source, and didn't build against whatever X server we were shipping, and that vbox upstream didn't _want_ it shipped externally yet because they hadn't finalized the interface. The other is that the kernel doesn't seem to be binding an efifb device to it, and/or that it is and X is not noticing that and thus loads vesa instead of fbdev. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dsd at laptop.org Mon Dec 14 14:55:39 2009 From: dsd at laptop.org (Daniel Drake) Date: Mon, 14 Dec 2009 14:55:39 +0000 Subject: "make update" broken? In-Reply-To: <1260801814.3311.5738.camel@localhost.localdomain> References: <1260798163.3311.5674.camel@localhost.localdomain> <935ead450912140629v7991adafkbba3b09142d45fd7@mail.gmail.com> <1260801814.3311.5738.camel@localhost.localdomain> Message-ID: <1260802539.3385.10.camel@localhost.localdomain> On Mon, 2009-12-14 at 14:43 +0000, Bastien Nocera wrote: > On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: > > On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera wrote: > > > Ideas? > > > > The Fedora Infrastrutcure is being moved to a new datacenter: > > > > https://www.redhat.com/archives/fedora-announce-list/2009-December/msg00008.html > > https://fedorahosted.org/fedora-infrastructure/ticket/1845 > > I though this was finished already. I guess not... It's working at least partially. I managed to submit a F11 update but the same update for F12 fails with internal server error. Strange. Daniel From fedora-list at gunduz.org Mon Dec 14 15:03:41 2009 From: fedora-list at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Mon, 14 Dec 2009 17:03:41 +0200 Subject: MariaDB and Fedora In-Reply-To: <2635.1260750462@sss.pgh.pa.us> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> Message-ID: <1260803021.2669.2.camel@hp-laptop2.gunduz.org> On Sun, 2009-12-13 at 19:27 -0500, Tom Lane wrote: > (FWIW, I completely agree with Monty that Oracle is likely to do their > best to kill MySQL once they have it. But they can't kill the GPL'd > version as long as people are willing to work on that. Evidently > Monty isn't.) http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL-1090000.html "Oracle Makes Commitments to Customers, Developers and Users of MySQL" Just released. -- Devrim G?ND?Z, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz From cmadams at hiwaay.net Mon Dec 14 15:07:59 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 14 Dec 2009 09:07:59 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: <20091214150758.GB1094301@hiwaay.net> Once upon a time, Paul Jakma said: > If I put you in front of 2 identical machines, one running 32bit and > one 64bit software, would you be able to tell which one was which, > from the interactive performance of common applications? I'd be > willing to bet that for the vast majority of applications you > wouldn't be. Then you might as well run the native system architecture, which is 64 bit, rather than try to figure out which apps run better as 32 bit and maintain a full duplicate set of libraries! :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fedora-list at gunduz.org Mon Dec 14 15:09:02 2009 From: fedora-list at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Mon, 14 Dec 2009 17:09:02 +0200 Subject: MariaDB and Fedora In-Reply-To: <4B260640.6040801@axianet.ch> References: <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> <4B260640.6040801@axianet.ch> Message-ID: <1260803342.2669.6.camel@hp-laptop2.gunduz.org> On Mon, 2009-12-14 at 10:32 +0100, Steven Moix wrote: > I agree on that, and a "major" problem with PostgreSQL at the moment > is that it doesn't have a clustering engine. Except Hot Standby and Streaming Replication features that will likely appear in 8.5, PostgreSQL project won't have an "engine" which will provide clustering support -- and PostgreSQL will have one and only one engine. There are some solutions around, though. > So MySQL is still the simplest choice out there for the end user Depends. *I* have tried it a few times, and I lost data. -- Devrim G?ND?Z, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz From cemeyer at u.washington.edu Mon Dec 14 15:34:14 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Mon, 14 Dec 2009 07:34:14 -0800 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> References: <20091206104812.GB8376@lisas.de> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> Message-ID: <200912140734.14883.cemeyer@u.washington.edu> On Monday 14 December 2009 04:27:52 am Nicolas Mailhot wrote: > Le Lun 14 d?cembre 2009 12:45, Josephine Tannh?user a ?crit : > > of course this is a practicable rule, BUT > > the problem is upstream or the rule itself. > > > > kernels internal zlib is not a lib its a module, > > wordpress internal php-gettext is not a lib, its a php code file. > > > > The trick is to declare that a lib is not a lib and you can close the > > bug as not a bug... > > Easy cake.. > > This is playing with words. I'm sure that when the guideline was written > lib was intended as "some code in any language that can be shared". What > is less clear is the other shared components which are not code (resource > files, fonts, templates, etc) but there is no doubt at all in my mind on > the code part. > > Though your interpretation is one reason we keep refining guidelines to > leave no room for bad packager excuses. I just wanted to jump in and point out that this isn't just Nicolas picking on you, he's right. -- Conrad Meyer From kevin.kofler at chello.at Mon Dec 14 15:41:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Dec 2009 16:41:20 +0100 Subject: Exception request from FESCo for bundled libaries References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> Message-ID: Josephine Tannh?user wrote: > kernels internal zlib is not a lib its a module, The kernel cannot use userspace shared libraries, so it's the one component which is allowed to bundle zlib. But it's the only one! > wordpress internal php-gettext is not a lib, its a php code file. That's just a lame excuse. Kevin Kofler From a.badger at gmail.com Mon Dec 14 15:44:09 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Dec 2009 07:44:09 -0800 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> Message-ID: <20091214154409.GC3259@clingman.lan> On Mon, Dec 14, 2009 at 01:27:52PM +0100, Nicolas Mailhot wrote: > > > Le Lun 14 d?cembre 2009 12:45, Josephine Tannh?user a ?crit : > > > > of course this is a practicable rule, BUT > > the problem is upstream or the rule itself. > > > > kernels internal zlib is not a lib its a module, > > wordpress internal php-gettext is not a lib, its a php code file. > > > > The trick is to declare that a lib is not a lib and you can close the > > bug as not a bug... > > Easy cake.. > > This is playing with words. I'm sure that when the guideline was written lib > was intended as "some code in any language that can be shared". What is less > clear is the other shared components which are not code (resource files, > fonts, templates, etc) but there is no doubt at all in my mind on the code > part. > Just to make clear, Nicolas's interpretation is correct. Attempting to work around the problem by language lawyering does not promote better software. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aa.lucelio at gmail.com Mon Dec 14 16:19:12 2009 From: aa.lucelio at gmail.com (=?UTF-8?B?THVjw6lsaW8gR29tZXMgZGUgRnJlaXRhcw==?=) Date: Mon, 14 Dec 2009 14:19:12 -0200 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B25E5D5.9080405@fedoraproject.org> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> <4B25E5D5.9080405@fedoraproject.org> Message-ID: <4B266580.1080802@gmail.com> Rahul Sundaram, ref: alltray Is it possible to do something else for this package, except be the main maintainer? I use it, and want to follow, and learn more about it. Thanks. Em 14-12-2009 05:14, Rahul Sundaram escreveu: > On 12/14/2009 09:03 AM, Huzaifa Sidhpurwala wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> I want to take it >> >> > It is all yours now. Have fun. > > Rahul > > -- Luc?lio Gomes de Freitas ETFCSF-> U.G.F.-> P.U.C.(RJ) Eng?, Analista Suporte(Free Mind). Email:aa.lucelio at gmail.com Tel: 55 0XX 21 85964911 From gmaxwell at gmail.com Mon Dec 14 16:12:37 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 14 Dec 2009 11:12:37 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 7:33 AM, Paul Jakma wrote: > If I put you in front of 2 identical machines, one running 32bit > and one 64bit software, would you be able to tell which one was > which, from the interactive performance of common applications? I'd > be willing to bet that for the vast majority of applications you > wouldn't be. Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. [snip] > time, when email and browser apps start to demand 4GB+, but that time is a > while away I enjoyed how in nearly one breath you claim that performance is usually irrelevant then go on to name an application where performance is quite visible: A considerable amount of page load time is browser rendering. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) What was the point of this conversation again? People have demonstrated on this list, with benchmarks, that x86_64 makes a material performance improvement across a broad swath of applications where performance matters. You point out that users don't care about performance in many cases. I do not disagree but I have no clue how we can qualify or quantify that. Certainly, when some website posts benchmarks of Fedora vs other distribution those threads get a lot of discussion but that isn't really evidence. I also do not know how it is relevant, in context of x86_64, to Fedora as the use of x86_64 is effectively free. The costs, such as reduced compatibility with binary browser plugins, are simply not relevant to many people. You're obviously convinced of your opinion, other people hold the view that good performance is part of the distribution's core job. Other than the point that x86_64 also increases security (from greatly increased address space layout randomization, and reduced PIE cost), I think we've hit on every point for and against using x86_64 in this thread? yet I think not a single person has changed their initial view. I don't see how any resolution is going to come from further discussion. From npajkovs at redhat.com Mon Dec 14 16:20:12 2009 From: npajkovs at redhat.com (Nikola Pajkovsky) Date: Mon, 14 Dec 2009 17:20:12 +0100 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B266580.1080802@gmail.com> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> <4B25E5D5.9080405@fedoraproject.org> <4B266580.1080802@gmail.com> Message-ID: <4B2665BC.4080707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 14.12.2009 17:19, Luc?lio Gomes de Freitas napsal(a): > Rahul Sundaram, > > ref: alltray > > Is it possible to do something else for this package, except be the main > maintainer? > I use it, and want to follow, and learn more about it. > > Thanks. Yes, you can be co-maintainer. - -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: nikis at isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJmW8AAoJED4+/Vgo+H2XGU8H/jMfXumiD5PIE+xMM1U7pKoS dBPznFAqGYei3dZsgAUMgLni4uAIzn+nBFyX05eTPyMyJspGgaPs1LmgXho5grrW pMByuoJq1Ty4DzSqhrU8bLnn3W9jsHc4y9/Iq7yoI8jLMfeug8hU8MX8MV5LDinL fwpORMsCXLdoBahS4gX9yPZ3SA07ekDNCjVg3bjeYt+APL+PedEJq3qUmiAr0jnT hKrkl7oznvqZwzR1D8FgnClSfngn6P2un7nCohSkexZsOEJ6ONWp2x8zu6J6dPOZ usDt7WAvvskyTDg8jqmWnyqI8rOOrHg1Gtdwe2+dNl01Za01zyvbObdV+gGmbSs= =3qPF -----END PGP SIGNATURE----- From przemek.klosowski at nist.gov Mon Dec 14 16:42:52 2009 From: przemek.klosowski at nist.gov (Przemek Klosowski) Date: Mon, 14 Dec 2009 11:42:52 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <1260773777.6151.32.camel@tonnant> References: <4B04ADCD.8060302@pobox.com> <20091119025624.8011620E1@magilla.sf.frob.com> <27016.1260730385@sss.pgh.pa.us> <1260740566.6151.16.camel@tonnant> <20091213221954.GC1479857@hiwaay.net> <1260773777.6151.32.camel@tonnant> Message-ID: <4B266B0C.3050603@nist.gov> On 12/14/2009 01:56 AM, Jon Masters wrote: > On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote: >> Once upon a time, Jon Masters said: >>> Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very >>> different beast. Intel fixed a lot of the issues with the (more than 20 >>> year old really x86 ISA) >> >> That would be AMD that fixed it, not Intel. Intel tried to push >> everybody to a new architecture (Itanium), while AMD revised and >> extended i386 to 64 bits. After Itanium failed to catch on in the >> marketplace, Intel had to copy AMD's work. > > That's presumptuous and unfair. Sure, without AMD and others we'd likely > be on Itanium (which I actually quite like as an architecture) but Intel > 64 isn't just some copy-and-paste effort either. I thought Intel adopted AMD 64-bit extensions pretty much wholesale. No shame in that---they were well-designed and well engineered. We the CPU consumers should be thankful for how well this was executed by both Intel and AMD. Kudos to Intel for acting in the best interest of their customers especially since they had so much invested in Itanium, both financially and in term of company pride. While Itanium (aka Itanic :) was well-intentioned and looked good on paper, Intel/HP run into practical problems with the extent to which VLIW can be exploited by compilers, and with the hardware implementations, so that the actual performance is underwhelming. The Itanium siren song contributed to demise of SGI and wobbliness of HP so let's not be too nostalgic about it. From paul at dishone.st Mon Dec 14 17:18:47 2009 From: paul at dishone.st (Paul Jakma) Date: Mon, 14 Dec 2009 17:18:47 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: On Mon, 14 Dec 2009, Gregory Maxwell wrote: > Yet I could tell from the applications where performance is important. > You reject my metric, I reject yours. Something of an impasse. I'm not rejecting the performance metric at all. > (It's also not too hard to make firefox use more than 3GB of virtual > address space, though I admit you do need to work at it a little) Only because it's obsolete. Multi-process browsers use a lot less RAM per process. > What was the point of this conversation again? For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. Some people chose to argue "But you should just run 64bit completely", despite people already having described one reason to 32bit (memory usage). And from that we somehow got into a "x86_64 versus x86" thread of doom, with (IMHO) much missing of the general point. Anyway, enough. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Where do you go to get anorexia? -- Shelley Winters From aa.lucelio at gmail.com Mon Dec 14 17:54:13 2009 From: aa.lucelio at gmail.com (=?UTF-8?B?THVjw6lsaW8gR29tZXMgZGUgRnJlaXRhcw==?=) Date: Mon, 14 Dec 2009 15:54:13 -0200 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B2665BC.4080707@redhat.com> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> <4B25E5D5.9080405@fedoraproject.org> <4B266580.1080802@gmail.com> <4B2665BC.4080707@redhat.com> Message-ID: <4B267BC5.3090001@gmail.com> Nikola Pajkovsky, OK.. I am ready to be co-maintainer, it is a pleasure to be part of this team. what is the first step/guideline? I hope do not dissapoint. Thanks. Em 14-12-2009 14:20, Nikola Pajkovsky escreveu: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dne 14.12.2009 17:19, Luc?lio Gomes de Freitas napsal(a): > >> Rahul Sundaram, >> >> ref: alltray >> >> Is it possible to do something else for this package, except be the main >> maintainer? >> I use it, and want to follow, and learn more about it. >> >> Thanks. >> > Yes, you can be co-maintainer. > > - -- > Nikola Pajkovsky .~. > Base Operating Systems Brno /V\ > // \\ > Jabber: nikis at isgeek.info /( )\ > Mobile: +420 777 895 064 ^`~'^ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLJmW8AAoJED4+/Vgo+H2XGU8H/jMfXumiD5PIE+xMM1U7pKoS > dBPznFAqGYei3dZsgAUMgLni4uAIzn+nBFyX05eTPyMyJspGgaPs1LmgXho5grrW > pMByuoJq1Ty4DzSqhrU8bLnn3W9jsHc4y9/Iq7yoI8jLMfeug8hU8MX8MV5LDinL > fwpORMsCXLdoBahS4gX9yPZ3SA07ekDNCjVg3bjeYt+APL+PedEJq3qUmiAr0jnT > hKrkl7oznvqZwzR1D8FgnClSfngn6P2un7nCohSkexZsOEJ6ONWp2x8zu6J6dPOZ > usDt7WAvvskyTDg8jqmWnyqI8rOOrHg1Gtdwe2+dNl01Za01zyvbObdV+gGmbSs= > =3qPF > -----END PGP SIGNATURE----- > > -- Luc?lio Gomes de Freitas ETFCSF-> U.G.F.-> P.U.C.(RJ) Eng?, Analista Suporte(Free Mind). Email: aa.lucelio at gmail.com Tel: 55 0XX 21 85964911 From awilliam at redhat.com Mon Dec 14 17:50:57 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 14 Dec 2009 09:50:57 -0800 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: <1260813057.2414.2.camel@adam.local.net> On Mon, 2009-12-14 at 12:33 +0000, Paul Jakma wrote: > You're missing the point. > > If I put you in front of 2 identical machines, one running 32bit and > one 64bit software, would you be able to tell which one was which, > from the interactive performance of common applications? I'd be > willing to bet that for the vast majority of applications you > wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From paul at dishone.st Mon Dec 14 18:17:10 2009 From: paul at dishone.st (Paul Jakma) Date: Mon, 14 Dec 2009 18:17:10 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <1260813057.2414.2.camel@adam.local.net> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <1260813057.2414.2.camel@adam.local.net> Message-ID: On Mon, 14 Dec 2009, Adam Williamson wrote: > On Mon, 2009-12-14 at 12:33 +0000, Paul Jakma wrote: > >> You're missing the point. >> >> If I put you in front of 2 identical machines, one running 32bit and >> one 64bit software, would you be able to tell which one was which, >> from the interactive performance of common applications? I'd be >> willing to bet that for the vast majority of applications you >> wouldn't be. > That's a silly argument, because it simply relies on the fact that most > uses of computers aren't CPU-bound at all. In the same way I could > probably steal half the RAM from your system and clock the CPU down 50% > (the BOFH's favourite revenue-generating technique!) and from 'the > interactive performance of common applications' you wouldn't be able to > tell the difference. I don't think that _means_ very much, though. It's quite meaningful, e.g. for power conservation. As you no doubt are aware of, modern system regularly clock down the CPU. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: It occurred to me lately that nothing has occurred to me lately. From vasily.v.levchenko at gmail.com Mon Dec 14 18:17:24 2009 From: vasily.v.levchenko at gmail.com (Vasily Levchenko) Date: Mon, 14 Dec 2009 21:17:24 +0300 Subject: X on UEFI systems. In-Reply-To: <1260801863.7251.31725.camel@atropine.boston.devel.redhat.com> References: <805103B6-9C58-4B9B-8569-D02A988BA982@gmail.com> <1260421575.3307.0.camel@localhost> <4C1749CE-FEC0-4795-A197-B5BEB452A6F6@gmail.com> <1260560479.19557.30.camel@adam.local.net> <4B22C450.20008@redhat.com> <1260801863.7251.31725.camel@atropine.boston.devel.redhat.com> Message-ID: <0D4A3645-C3FD-46E9-9A0A-FD765D2583F2@gmail.com> On Dec 14, 2009, at 5:44 PM, Adam Jackson wrote: > On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: >> On 12/11/2009 02:41 PM, Adam Williamson wrote: >>> On Thu, 2009-12-10 at 08:57 +0100, Mat?j Cepl wrote: >>>> File a bug please, attaching your xorg.conf, Xorg.0.log and output of >>>> the dmesg command (all from inside of VB virtual machine, of course). >>> >>> ...aaaand (oh boy, I love it when a plan comes together) mark it as >>> blocking F13Beta , because I reckon this breaks beta criterion #4: >>> >>> https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria >> >> I like the sentiment here, but I'm not sure this is really in the >> spirit of the criteria - Vasily, as I understand it, is still in the >> process of implementing the support for UEFI on VirtualBox. > > There's at least two issues here. > > One is that we're not shipping the native X driver for vbox video yet. > Last I checked this was because it's hidden away in the vbox source, and > didn't build against whatever X server we were shipping, and that vbox > upstream didn't _want_ it shipped externally yet because they hadn't > finalized the interface. > Right, looks like it isn't good time to package vboxvideo. > The other is that the kernel doesn't seem to be binding an efifb device > to it, Kernel uses efifb, and progress bar with logo drawn in the center looks nice and correct. > and/or that it is and X is not noticing that and thus loads vesa > instead of fbdev. X detects fbdev right (at least X -configure creates xorg.conf with right driver), but it couldn't detect modes (resolution) using fbdev, thus X loads vesa to somehow fill the gaps imho. #0 fbdev_open (scrnIndex=, dev=0x1501fc "/dev/fb0", namep=0x0) at fbdevhw.c:412 #1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at fbdevhw.c:442 #2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=) at fbdev.c:394 #3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at xf86Init.c:663 #4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4) at xf86Init.c:939 #5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315 fbdev_open with (,namep = 0x0,) doesn't call ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,), which might returns required information: (gdb) call ioctl(fd,0x4602,(void*)(&fix)) $2 = 0 (gdb) p fix $3 = {id = "EFI VGA\0\0\0\0\0\0\0\0", smem_start = 0x80000000
, smem_len = 6291456, type = 0, type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0, line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0, reserved = {0, 0, 0}} ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,) called from fbdev_open with (,namep != 0x0,), but I am not sure how fbdevHWProbe(,namep != 0x0,) will affect probing algorithm and X working :) . > > - ajax > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Dec 14 18:21:19 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 19:21:19 +0100 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <200912140734.14883.cemeyer@u.washington.edu> References: <20091206104812.GB8376@lisas.de> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> <200912140734.14883.cemeyer@u.washington.edu> Message-ID: <1260814879.8432.3.camel@arekh.okg> > On Monday 14 December 2009 04:27:52 am Nicolas Mailhot wrote: > > Though your interpretation is one reason we keep refining guidelines > to > > leave no room for bad packager excuses. Just to be clear what is bad here is the excuse, not the packager (didn't realise it when writing, English has this funny property you can stack words directly and create valid sentences that may be read in many different ways) It is hard to write unambiguous text. In guidelines or other documents. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Dec 14 18:34:08 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 14 Dec 2009 19:34:08 +0100 Subject: MariaDB and Fedora In-Reply-To: <1260803021.2669.2.camel@hp-laptop2.gunduz.org> References: <4f629b520912100905h76fd32cbw7464fd3025e9d5a5@mail.gmail.com> <1260466690.2963.3.camel@localhost> <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <1260803021.2669.2.camel@hp-laptop2.gunduz.org> Message-ID: <1260815648.8432.15.camel@arekh.okg> Le lundi 14 d?cembre 2009 ? 17:03 +0200, Devrim G?ND?Z a ?crit : > On Sun, 2009-12-13 at 19:27 -0500, Tom Lane wrote: > > > (FWIW, I completely agree with Monty that Oracle is likely to do > their > > best to kill MySQL once they have it. But they can't kill the GPL'd > > version as long as people are willing to work on that. Evidently > > Monty isn't.) > > http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL > -1090000.html > > "Oracle Makes Commitments to Customers, Developers and Users of MySQL" Oracle commitments are only worth the money Oracle expects earning through them. For example the BEA commitment was "we will support existing customers for 10 years", and the nuances of what exactly "support" means when Oracle has decided a product had no future are only starting to get clear today. This new PR only commits for three years. That's a miser, it would take at least that much time for Oracle to execute a smooth kill (transitioning existing Mysql customers) if it started today. You need to remember Oracle's bread and butter is the Enterprise market where time scales are longer (as evidenced by the 7 years+ RHEL release lifecycle) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mjg at redhat.com Mon Dec 14 18:34:45 2009 From: mjg at redhat.com (Matthew Garrett) Date: Mon, 14 Dec 2009 18:34:45 +0000 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> Message-ID: <20091214183445.GA6202@srcf.ucam.org> On Mon, Dec 14, 2009 at 05:18:47PM +0000, Paul Jakma wrote: > For those who can't sort by thread in their MUA: To ask that > 32-userspace-on-64 be supported (it pretty much all works, except for > yum updating certain things, like the kernel), as there are definite > benefits to a 32-by-default userspace. There's little testing effort done on this. People still occasionally trip over bugs in the ioctl conversion code in the kernel, and there's a couple of other cases where exported ABI doesn't get converted correctly. Now, while it's undeniable that these are bugs that should be fixed, it's also pretty difficult to justify adding a third x86 variant to our list of supported configurations, especially when it's known to be more problematic than the other two that already satisfy almost everybody's needs. -- Matthew Garrett | mjg59 at srcf.ucam.org From jspaleta at gmail.com Mon Dec 14 19:09:22 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Dec 2009 10:09:22 -0900 Subject: Exception request from FESCo for bundled libaries In-Reply-To: <20091214154409.GC3259@clingman.lan> References: <20091206104812.GB8376@lisas.de> <3668e9f50912132306p5c84f16btfbf9f3f207e74555@mail.gmail.com> <12e7eedf454f07ca6af80edfe428020a.squirrel@arekh.dyndns.org> <3668e9f50912140228j69ac5274p9be2fb7d880a7af9@mail.gmail.com> <5f04e2d12012922b93ab8de87c366c93.squirrel@arekh.dyndns.org> <3668e9f50912140345p333c9cd7q658e953714732e67@mail.gmail.com> <866082f338446b25cbcccb131df7c86f.squirrel@arekh.dyndns.org> <20091214154409.GC3259@clingman.lan> Message-ID: <604aa7910912141109l6877ab06ie1f065079c199521@mail.gmail.com> On Mon, Dec 14, 2009 at 6:44 AM, Toshio Kuratomi wrote: > Just to make clear, Nicolas's interpretation is correct. ?Attempting to work > around the problem by language lawyering does not promote better software. Another specific non-library case.... the pytz package was shipping its own timezone definitions separate from the tzdata package that required additional maintenance (stupid shifts in daylight savings time..thanks US congress.) I was told about it, added a patch to pytz and now it reads the tzdata resource files instead of shipping its own. Less work for me as a maintainer long term.. one less aperiodic package update for users...and more consistent timezone handling for users. The intention of the guidelines...is to guide people in using their judgement on how to handle things. Now in the pytz case as soon as I was made aware of the duplication of timezone resource files..it was obvious that I should make a best effort to reuse a common system wide set and it was easily done. But sometimes its not obvious and that's when a peer discussion needs to happen. Or sometimes its obvious but a best effort runs into problems because of upstream customization or tweaking and that's when a peer discussion needs to happen. The guidelines help define the boundary of the grey area when discussion really needs to happen. -jef From fedora at matbooth.co.uk Mon Dec 14 19:13:58 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 14 Dec 2009 19:13:58 +0000 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B267BC5.3090001@gmail.com> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> <4B25E5D5.9080405@fedoraproject.org> <4B266580.1080802@gmail.com> <4B2665BC.4080707@redhat.com> <4B267BC5.3090001@gmail.com> Message-ID: <9497e9990912141113o7e819d2bj6df7be9ca637f1ed@mail.gmail.com> 2009/12/14 Luc?lio Gomes de Freitas : > Nikola Pajkovsky, > > OK.. I am ready to be co-maintainer, it is a pleasure to be part of this > team. > what is the first step/guideline? I hope do not dissapoint. > > Thanks. > Log into the package database and click the "Add myself to this package" button: https://admin.fedoraproject.org/pkgdb Note that you must first be a member of the Fedora Packagers group. -- Mat Booth From jspaleta at gmail.com Mon Dec 14 19:35:10 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Dec 2009 10:35:10 -0900 Subject: Request for help maintaining packages while away. In-Reply-To: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> Message-ID: <604aa7910912141135o7bdca689s5ed96208fdf896f6@mail.gmail.com> On Wed, Dec 9, 2009 at 10:24 AM, Jeff Spaleta wrote: > Good Alaskan Morning! > > In two weeks I'm going to be in Antarctica for a month+ and I'm > looking for other packagers to step in for me and maintain my packages > and prepare them for F13. ?I'm not exactly sure what my time and > bandwidth access will be so I'm planning for the worst and that I'll > be reliably off the grid through mid Feb. ? Please let me know if you > can take on a co-maintainer/primary maintainer role for any of the > packges and see them through the next couple of months. Okay I've processed all the pending packagedb requests that have come in so far. Thanks for the response. I'll try to push development tree builds for the latest releases of all the packages I own in the next week. But no promises. Watch your commit emails. -jef From reich at ulticom.com Mon Dec 14 19:45:50 2009 From: reich at ulticom.com (William Reich) Date: Mon, 14 Dec 2009 14:45:50 -0500 Subject: trouble with signals and skb_rec_datagram() In-Reply-To: <604aa7910912141135o7bdca689s5ed96208fdf896f6@mail.gmail.com> References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <604aa7910912141135o7bdca689s5ed96208fdf896f6@mail.gmail.com> Message-ID: Hello List... I am working on trying to port a LINUX kernel driver from RedHat AS 4/5 to Fedora 11 & 12. Within this driver, I create some threads. The threads call skb_rec_datagram(). When it is time to shut down the system, my main kernel code ( in RH 4 & 5 ) called kill_proc( pid, SIGTERM, 0 ) to terminate the threads created above. The skb_rec_datagram() would return with an error, and the threads would then exit cleanly. Now for Fedora 11 & 12, I understand that kill_proc() is no longer available to use. So, I have performed experiments that replace the kill_proc() with kill_pid() or with send_sig_info(). Neither of these routines are terminating my threads. I have added extra debug to the code. The return codes from kill_pid() and send_sig_info() are zero, implying that what I asked for was accomplished. Yet, my threads did not terminate. I added code after the skb_rec_datagram() call to print out the error value. This printk statement does not execute when the SIGTERM is genereated. Using "crash" on a live Fedora 12 system, I see that my threads are, as expected, sitting inside skb_rec_datagram(). So, I am left with two choices. Either the replacements for kill_proc() are not functioning, or skb_rec_datagram() has changed its behavior that ignores SIGTERM. Interestingly, I can "kill -9 " my threads as ROOT from the command line on a RH 4/5 system. But I can not do so on a Fedora 11/12 system. This would seem to imply that my signals are not masked correctly. However, inspection via 'crash' on a live system seems to indicate that my signal mask is ok. Does anyone know if the behavior of skb_rec_datagram() has changed in the newer kernels ? thanks wr From Matt_Domsch at dell.com Mon Dec 14 19:51:07 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 14 Dec 2009 13:51:07 -0600 Subject: "make update" broken? In-Reply-To: <1260801814.3311.5738.camel@localhost.localdomain> References: <1260798163.3311.5674.camel@localhost.localdomain> <935ead450912140629v7991adafkbba3b09142d45fd7@mail.gmail.com> <1260801814.3311.5738.camel@localhost.localdomain> Message-ID: <20091214195107.GA8029@auslistsprd01.us.dell.com> On Mon, Dec 14, 2009 at 02:43:34PM +0000, Bastien Nocera wrote: > On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: > > On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera wrote: > > > Ideas? > > > > The Fedora Infrastrutcure is being moved to a new datacenter: > > > > https://www.redhat.com/archives/fedora-announce-list/2009-December/msg00008.html > > https://fedorahosted.org/fedora-infrastructure/ticket/1845 > > I though this was finished already. I guess not... Very much still in progress. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mattdm at mattdm.org Mon Dec 14 21:16:10 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 14 Dec 2009 16:16:10 -0500 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: References: <4B185436.4090802@behdad.org> Message-ID: <20091214211610.GA6960@jadzia.bu.edu> On Fri, Dec 04, 2009 at 05:56:02PM +0100, Kevin Kofler wrote: > IMHO, if we want to ship this by default, we really need to fix FreeType for > the case where the font doesn't provide hinting bytecode. AFAICT, currently, > in that case, if FreeType is built with the BCI enabled, it won't do any [...] > It should fall back to the autohinter when the font does not provide hinting > bytecode. Aha! So that's why all the open-source fonts on my screen suddenly got really ugly. Is there an open bugzilla bug for this? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From mattdm at mattdm.org Mon Dec 14 21:27:41 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 14 Dec 2009 16:27:41 -0500 Subject: FreeType patented bytecode interpreter now in rawhide In-Reply-To: <20091214211610.GA6960@jadzia.bu.edu> References: <4B185436.4090802@behdad.org> <20091214211610.GA6960@jadzia.bu.edu> Message-ID: <20091214212741.GA8615@jadzia.bu.edu> On Mon, Dec 14, 2009 at 04:16:10PM -0500, Matthew Miller wrote: > Is there an open bugzilla bug for this? There is now: bug #547532. Thanks. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From eric at christensenplace.us Mon Dec 14 21:32:56 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 14 Dec 2009 16:32:56 -0500 Subject: astronomy-bookmarks conflicts with fedora-bookmarks Message-ID: <4B26AF08.908@christensenplace.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When trying to install astronomy-bookmarks I get the error that "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? Thanks, Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJq8IAAoJEDbiLlqcYamx+sMP/j36892hx9wLAY+dJ1HAaQW0 Kw8TgyfW0sWvkLwcv45wwla9lP7FIvc9yFl5Bh7/84/x0fxApX0j9E50wzepYnaX Xb4MCCEM7FSMpjLRuDkN9xi1ppKr4hUKReY5oa7gfRM1sRepNHXg8pcOHv6Y3zcD NMtEZCcrZzQuPA6kSLF6QG79cS0dXJHSl2DUx8SQOoe48ETnOhSmG6870+CzTp9D 7B4LKPms0zZsnJFLl/YMm1PCgIARWumwIIJ3DQfzMjhRsVj2HF0Dfwz/I7l28pk2 eldHzGuIgfCheAB6SK/TyQzniAM2O43EVDU0e+2oEU6LVFvvlw8yXwraFNJR+Iw2 bM5Xu7bBJhZO0784idC6fMntAqBHZW6WF6I8JOD/VzgQPUs9RZwWTuOXo9kMK2kM FqtlgdzNs8HOt5N64+H45FUMTko2avLspmQuoEQBtNGXtSkpQ/luukn/kja7i812 lwttf/AmA7mzMIxA8OrsE6F9uwi9fcRcJLxHQMmVXBrXhw9kYM0wzv4Xe0IkmP/F 2dn9l/8c2L86xltN+7vpEL1++nitnhM7IPBbZesA0p9eBxH5LXokAnuW0jI/ccjF mLc78O9bIgQqIrHasUSSh/JM5g5n/1TpledJox5LIGb3eQiXUVZBLCXD5VVjN7Dn bnmtJ97j97nowuSmdQh3 =YAJh -----END PGP SIGNATURE----- From mike at miketc.net Mon Dec 14 21:49:44 2009 From: mike at miketc.net (Mike Chambers) Date: Mon, 14 Dec 2009 15:49:44 -0600 Subject: Datacenter, git, and cvs Message-ID: <1260827384.14077.7.camel@localhost> If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? If so, mainly the git move, will we as users/testers/etc notice any changes - via emails sent out, koji and the like - or is it all mostly behind the scenes and package maintainers and the like will be the ones who are affected? Guess a summary of what to expect once it's all GO? -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From stickster at gmail.com Mon Dec 14 21:50:27 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 14 Dec 2009 16:50:27 -0500 Subject: astronomy-bookmarks conflicts with fedora-bookmarks In-Reply-To: <4B26AF08.908@christensenplace.us> References: <4B26AF08.908@christensenplace.us> Message-ID: <20091214215027.GH6035@victoria.internal.frields.org> On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: > When trying to install astronomy-bookmarks I get the error that > "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I > looked at the source (an HTML file) but I can't quite figure out why it > would conflict. Does anyone know? [paul at scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [paul at scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From tmz at pobox.com Mon Dec 14 21:57:03 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 14 Dec 2009 16:57:03 -0500 Subject: Datacenter, git, and cvs In-Reply-To: <1260827384.14077.7.camel@localhost> References: <1260827384.14077.7.camel@localhost> Message-ID: <20091214215702.GO5004@inocybe.localdomain> Mike Chambers wrote: > If I understand what is happening now (and over the past weekend), > the datacenter machines are moving to a new location, AND the > package building is moving from cvs to git (will be, or already in > process)? Only the former is taking place now. A move from cvs to git is being tested but is not imminent. I'm sure that it will be hard to miss once that change is ready and implemented. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A lawyer was visiting a farmer on business, when he stepped out of his Mercedes in the farmyard he stepped into a cow dropping. Looking down he cried "my god I'm melting!" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jeff at ocjtech.us Mon Dec 14 21:57:15 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 14 Dec 2009 15:57:15 -0600 Subject: Datacenter, git, and cvs In-Reply-To: <1260827384.14077.7.camel@localhost> References: <1260827384.14077.7.camel@localhost> Message-ID: <935ead450912141357l7962753cv485c80149dde1552@mail.gmail.com> On Mon, Dec 14, 2009 at 3:49 PM, Mike Chambers wrote: > If I understand what is happening now (and over the past weekend), the > datacenter machines are moving to a new location, AND the package > building is moving from cvs to git (will be, or already in process)? The move from CVS to Git won't happen until post-F13. -- Jeff Ollie From eric at christensenplace.us Mon Dec 14 21:59:08 2009 From: eric at christensenplace.us (Eric Christensen) Date: Mon, 14 Dec 2009 16:59:08 -0500 Subject: astronomy-bookmarks conflicts with fedora-bookmarks In-Reply-To: <20091214215027.GH6035@victoria.internal.frields.org> References: <4B26AF08.908@christensenplace.us> <20091214215027.GH6035@victoria.internal.frields.org> Message-ID: <4B26B52C.3050503@christensenplace.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/14/2009 04:50 PM, Paul W. Frields wrote: > On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: >> When trying to install astronomy-bookmarks I get the error that >> "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I >> looked at the source (an HTML file) but I can't quite figure out why it >> would conflict. Does anyone know? > > [paul at scarlett ~]$ repoquery -q --provides astronomy-bookmarks > astronomy-bookmarks = 1-6.fc12 > system-bookmarks > [paul at scarlett ~]$ repoquery -q --provides fedora-bookmarks > fedora-bookmarks = 11-2 > system-bookmarks > > They both provide 'system-bookmarks'. > Okay, that makes sense. Thanks Paul. - --Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJrUsAAoJEDbiLlqcYamxHlgQAIP7AGOXwGIyvD93YXywRTf/ 9/vEDR9ti92gNjJ21EEw3QRYTD6czsUOZZ/EfJDldIaSQPx6aktZJQT1neBlLlgD lRFvqLY29/ZokPqF0gyBznl5FFpkbVHhClSPsBJzfPkeQ7jb50ZQU5w5z2IUSk7l yzih0lskGCeDT2RGBg3SrKVhWX1sgO8dRdmfVORg0uRRkJgDLgq7i6Fp2mkSIPqT R8iErKs8bAP24FgIZMKJGNGjUW3oUS7NuC0n1sB169y2ProPmLfMzHfagJzR438i PPQHb9QHkXhzd8YedjGGG3ks3OaZ1xoTuj6eDga9UquvZ3gKcX/gqbOH7U7b4nuC LDrCskYOhgoR+rFvP9rpgP13nUj7iK4iWu00jRNS4nvDe/Jh9oI44r4A2v7xwOCI lI1ZNZZYCM2Ci2kzKvIuezS3kOcgKXYVl/Zsio81rLgc3/Kp3RYDErmuRcuvQD9M sIe1QTVw8q0sAMuCxNDH9DuIAB4luHc3hAAdtl+n78qokmS0g4iWSMzvVteBBJB/ Q2GEBl7q4BiLAQe8HnX0bAT496yuIFMGzSbbA7qWv6oeccN16W1fLKWjPFb8xhpO xCjJsVzYsuI8aFFXxO/cXyQuojNoPw34KRi8df/71KIvlIfaQ02DKkiauJfCMIg7 zyl+TSdhiUV4ReUZwAUZ =O57+ -----END PGP SIGNATURE----- From mikeb at redhat.com Mon Dec 14 22:01:56 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 14 Dec 2009 17:01:56 -0500 Subject: astronomy-bookmarks conflicts with fedora-bookmarks In-Reply-To: <20091214215027.GH6035@victoria.internal.frields.org> References: <4B26AF08.908@christensenplace.us> <20091214215027.GH6035@victoria.internal.frields.org> Message-ID: <4B26B5D4.5090104@redhat.com> On 12/14/2009 04:50 PM, Paul W. Frields wrote: > On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: >> When trying to install astronomy-bookmarks I get the error that >> "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I >> looked at the source (an HTML file) but I can't quite figure out why it >> would conflict. Does anyone know? > > [paul at scarlett ~]$ repoquery -q --provides astronomy-bookmarks > astronomy-bookmarks = 1-6.fc12 > system-bookmarks > [paul at scarlett ~]$ repoquery -q --provides fedora-bookmarks > fedora-bookmarks = 11-2 > system-bookmarks > > They both provide 'system-bookmarks'. Multiple packages can Provides: the same thing without problems. The issue here is that astronomy-bookmarks explicitly Conflicts: with fedora-bookmarks: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 From jgarzik at pobox.com Mon Dec 14 22:07:52 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 14 Dec 2009 17:07:52 -0500 Subject: Datacenter, git, and cvs In-Reply-To: <20091214215702.GO5004@inocybe.localdomain> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> Message-ID: <4B26B738.50809@pobox.com> On 12/14/2009 04:57 PM, Todd Zullinger wrote: > Mike Chambers wrote: >> If I understand what is happening now (and over the past weekend), >> the datacenter machines are moving to a new location, AND the >> package building is moving from cvs to git (will be, or already in >> process)? > > Only the former is taking place now. A move from cvs to git is being > tested but is not imminent. I'm sure that it will be hard to miss > once that change is ready and implemented. If done right, the move to git can still service CVS requests in some capacity... that may make the transition a little less abrupt and painful. Jeff From reich at ulticom.com Mon Dec 14 22:12:27 2009 From: reich at ulticom.com (William Reich) Date: Mon, 14 Dec 2009 17:12:27 -0500 Subject: more - trouble with signals and skb_rec_datagram() In-Reply-To: References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com><604aa7910912141135o7bdca689s5ed96208fdf896f6@mail.gmail.com> Message-ID: >Hello List... > >I am working on trying to port a LINUX kernel >driver from RedHat AS 4/5 to Fedora 11 & 12. > >Within this driver, I create some threads. >The threads call skb_rec_datagram(). > >When it is time to shut down the system, >my main kernel code ( in RH 4 & 5 ) called kill_proc( pid, SIGTERM, 0 ) >to terminate the threads created above. >The skb_rec_datagram() would return with an error, >and the threads would then exit cleanly. > >Now for Fedora 11 & 12, I understand that kill_proc() is no >longer available to use. So, I have performed experiments that >replace the kill_proc() with kill_pid() >or with send_sig_info(). >Neither of these routines are terminating my threads. > >I have added extra debug to the code. The return codes from >kill_pid() and send_sig_info() are zero, implying that >what I asked for was accomplished. > >Yet, my threads did not terminate. I added code >after the skb_rec_datagram() call to print out the error value. >This printk statement does not execute when the SIGTERM >is genereated. > >Using "crash" on a live Fedora 12 system, I see that my threads >are, as expected, sitting inside skb_rec_datagram(). > >So, I am left with two choices. Either the >replacements for kill_proc() are not functioning, or >skb_rec_datagram() has changed its behavior that ignores >SIGTERM. >Interestingly, I can "kill -9 " my threads as ROOT from the command >line on a RH 4/5 system. But >I can not do so on a Fedora 11/12 system. This would seem to imply that >my signals are not masked correctly. However, inspection via >'crash' on a live system seems to indicate that my signal mask is ok. > > >Does anyone know if the behavior of skb_rec_datagram() has changed >in the newer kernels ? > >thanks > >wr In Fedora 11 code for net/core/datagram.c, the skb_rec_datagram() and wait_for_packet() functions seem to have changed such that there is a new ( to me anyway ) function named receiver_wake_function(). This function, based on the comments, appears to be filtering signals. Can anyone tell me if this receiver_wake_function() is filtering out SIGTERM and SIGKILL signals ? ( I have not been able to determine how these SIG signals convert to the poll bits in the code... ) wr From kevin.kofler at chello.at Mon Dec 14 22:20:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Dec 2009 23:20:48 +0100 Subject: astronomy-bookmarks conflicts with fedora-bookmarks References: <4B26AF08.908@christensenplace.us> <20091214215027.GH6035@victoria.internal.frields.org> <4B26B5D4.5090104@redhat.com> Message-ID: Mike Bonnet wrote: > The issue here is that astronomy-bookmarks explicitly Conflicts: with > fedora-bookmarks: > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 That Conflicts is probably there because they provide the same file, so without the explicit Conflicts, we'd have a file conflict, which is much worse. Kevin Kofler From kevin.kofler at chello.at Mon Dec 14 22:22:27 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 14 Dec 2009 23:22:27 +0100 Subject: Why pavucontrol is not installed by default? References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260308728.3311.1994.camel@localhost.localdomain> <1260555767.19557.20.camel@adam.local.net> Message-ID: Adam Williamson wrote: > I actually dropped gst-mixer with F12, as we planned all along. So that > one's not an option for F12. Someone could unorphan it, or use the F11 package. (BTW, I don't see why you retired it as it was clearly still useful to some users and it can't hurt to have it in the repository.) Kevin Kofler From tmz at pobox.com Mon Dec 14 22:31:36 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 14 Dec 2009 17:31:36 -0500 Subject: Datacenter, git, and cvs In-Reply-To: <4B26B738.50809@pobox.com> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <4B26B738.50809@pobox.com> Message-ID: <20091214223136.GP5004@inocybe.localdomain> Jeff Garzik wrote: > If done right, the move to git can still service CVS requests in > some capacity... that may make the transition a little less abrupt > and painful. Perhaps. But git-cvsserver is a rather limited crutch that I can't imagine anyone wanting to spend much time on, just to let folks continue to use cvs commands directly. Who knows though, maybe there are more people that actually like cvs than I think and they'll volunteer to implement and run such a service. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L'hypocrisie est un hommage que le vice rend ? la vertu. [Hypocrisy is the tribute which vice pays to virtue.] -- Francois, Duc de La Rochefoucauld, R?flexions ou sentences et maximes morales -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From stickster at gmail.com Mon Dec 14 22:37:52 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 14 Dec 2009 17:37:52 -0500 Subject: astronomy-bookmarks conflicts with fedora-bookmarks In-Reply-To: <4B26B5D4.5090104@redhat.com> References: <4B26AF08.908@christensenplace.us> <20091214215027.GH6035@victoria.internal.frields.org> <4B26B5D4.5090104@redhat.com> Message-ID: <20091214223752.GK6035@victoria.internal.frields.org> On Mon, Dec 14, 2009 at 05:01:56PM -0500, Mike Bonnet wrote: > On 12/14/2009 04:50 PM, Paul W. Frields wrote: > > On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: > >> When trying to install astronomy-bookmarks I get the error that > >> "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I > >> looked at the source (an HTML file) but I can't quite figure out why it > >> would conflict. Does anyone know? > > > > [paul at scarlett ~]$ repoquery -q --provides astronomy-bookmarks > > astronomy-bookmarks = 1-6.fc12 > > system-bookmarks > > [paul at scarlett ~]$ repoquery -q --provides fedora-bookmarks > > fedora-bookmarks = 11-2 > > system-bookmarks > > > > They both provide 'system-bookmarks'. > > Multiple packages can Provides: the same thing without problems. > > The issue here is that astronomy-bookmarks explicitly Conflicts: with > fedora-bookmarks: > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 Thanks for the clarification Mike! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From npajkovs at redhat.com Mon Dec 14 22:53:47 2009 From: npajkovs at redhat.com (Nikola Pajkovsky) Date: Mon, 14 Dec 2009 23:53:47 +0100 Subject: Anyone else want to maintain alltray? In-Reply-To: <4B267BC5.3090001@gmail.com> References: <4B24B822.2060208@fedoraproject.org> <4B25B209.1050105@redhat.com> <4B25E5D5.9080405@fedoraproject.org> <4B266580.1080802@gmail.com> <4B2665BC.4080707@redhat.com> <4B267BC5.3090001@gmail.com> Message-ID: <4B26C1FB.8000003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 14.12.2009 18:54, Luc?lio Gomes de Freitas napsal(a): > Nikola Pajkovsky, > > OK.. I am ready to be co-maintainer, it is a pleasure to be part of this > team. > what is the first step/guideline? I hope do not dissapoint. > > Thanks. > First make account here: https://admin.fedoraproject.org/accounts and bugzilla account(bugzilla.redhat.com) See page: https://admin.fedoraproject.org/pkgdb/packages/name/alltray?_csrf_token=80a4f0d38a86652149f07d678bd10092cf2aaed3 and add yoursef as user who whatch commits and bugzilla. All patches that you will make discuse with upstream and if they refuse it send to huzaifas at redhat.com and discuse with him. Have a nice coding ;) - -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: nikis at isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJsH6AAoJED4+/Vgo+H2XEKYH/3iHdooXpM2Puz1qz5gCwYEP IQHwrph+hG2FOAWXfjX0x2GN5H3iJzfsEARz/vvdGJ3QXW+9Ejy1xeN8DCTD1k9P vpRjMGwDdQDmKWD5C+kJgcqoRry88ME4Euo/EACCs/l0vDZGruhpIUSKamgK4evW Awv8UdOOmd5mUH8P/QgA+EGUrZVeElqXggmlh0Kdjh5+JoOS/FxQUJYjdqqhA0HG 8hxg+v+4lRjfVL7NV68T/eCMnhRz4NkeESYCL1nN0AWhrfgSJUFgmIODcAO4wdtR dgHoCEQAl8zIEJJ2kgC/yZt2DLkvIBj3Ck7n+VRQBNu+4rIjMzW+a51fWGWLkx4= =iMEO -----END PGP SIGNATURE----- From chitlesh.goorah at gmail.com Mon Dec 14 22:58:52 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Mon, 14 Dec 2009 23:58:52 +0100 Subject: astronomy-bookmarks conflicts with fedora-bookmarks In-Reply-To: <4B26AF08.908@christensenplace.us> References: <4B26AF08.908@christensenplace.us> Message-ID: <50baabb30912141458h41418128me9dc34314a3e6b47@mail.gmail.com> On Mon, Dec 14, 2009 at 10:32 PM, Eric Christensen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When trying to install astronomy-bookmarks I get the error that > "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. ?I > looked at the source (an HTML file) but I can't quite figure out why it > would conflict. ?Does anyone know? > Hello there, It's an issue that needs to be addressed _as an example_ . If every SIG turns to create similar bookmarks package, then there will be more conflicts. Every bookmark package will have to conflict other bookmark package being shipped. There was a request to opt for "alternatives" instead and remove all the "conflicts". https://bugzilla.redhat.com/show_bug.cgi?id=508126 Chitlesh From mike at miketc.net Mon Dec 14 23:25:30 2009 From: mike at miketc.net (Mike Chambers) Date: Mon, 14 Dec 2009 17:25:30 -0600 Subject: Evo messages don't refresh when deleting Message-ID: <1260833130.2108.6.camel@localhost> Rawhide system upgraded from F12+updates as of today.. If you go to a folder and on the right side on top of the preview pane, and click on an email and delete it, at times (although it seems not every time, and maybe random), the next email isn't refreshed and/or isn't shown on the bottom of the preview pane. In other words, it stills shows the body of the deleted email and not the new one. But if you were to click on a different email without deleting the one you just left, it shows the correct email/body. Anyone else seeing this? evolution-bogofilter-2.29.3-1.fc13.x86_64 evolution-data-server-2.29.3-3.fc13.x86_64 evolution-help-2.29.3-1.fc13.noarch evolution-2.29.3-1.fc13.x86_64 -- Mike Chambers Madisonville, KY "Best lil town on Earth!" From awilliam at redhat.com Tue Dec 15 00:40:06 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 14 Dec 2009 16:40:06 -0800 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <1260299132.3027.368.camel@tonnant> <1260308728.3311.1994.camel@localhost.localdomain> <1260555767.19557.20.camel@adam.local.net> Message-ID: <1260837606.2414.4.camel@adam.local.net> On Mon, 2009-12-14 at 23:22 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > I actually dropped gst-mixer with F12, as we planned all along. So that > > one's not an option for F12. > > Someone could unorphan it, or use the F11 package. > > (BTW, I don't see why you retired it as it was clearly still useful to some > users and it can't hurt to have it in the repository.) Because I don't see a substantial enough need to keep maintaining it now gnome-volume-control has most of the features most users need. If someone wants to maintain it I'm happy to pass it off to them, though I'd now agree with Lennart and the desktop team that it should not be in the default installed package sets (comps) any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From adam at spicenitz.org Tue Dec 15 00:45:43 2009 From: adam at spicenitz.org (Adam Goode) Date: Mon, 14 Dec 2009 19:45:43 -0500 Subject: mono and snk key files In-Reply-To: <364d303b0912130316g3b64c40ex49c9572bf8bcc4ea@mail.gmail.com> References: <4B1297E5.1030207@smartlink.ee> <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> <4B227781.7080409@spicenitz.org> <364d303b0912130316g3b64c40ex49c9572bf8bcc4ea@mail.gmail.com> Message-ID: <4B26DC37.2090008@spicenitz.org> On 12/13/2009 06:16 AM, Christopher Brown wrote: > 2009/12/11 Adam Goode : >> We should definitely use Debian's key, right? Otherwise some Fedora CLI >> libraries would be unnecessarily incompatible with Debian, and whoever >> else uses Debian's key. >> >> The whole business of not shipping code-signing keys is a little >> contrary to open source. I think this is something that GPLv3 would >> prohibit. We should use a single well-known signing key for any package >> that we don't have the keys for, I think. > > You're right. > > This has already been resolved in devel by added mono.snk to the > mono-devel package. I'm just waiting on commit access to make the > required changes to F-11 and F-12 unless someone else wants to do it. > It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own? Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From jgarzik at pobox.com Tue Dec 15 00:55:24 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Mon, 14 Dec 2009 19:55:24 -0500 Subject: Datacenter, git, and cvs In-Reply-To: <20091214223136.GP5004@inocybe.localdomain> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <4B26B738.50809@pobox.com> <20091214223136.GP5004@inocybe.localdomain> Message-ID: <4B26DE7C.9030709@pobox.com> On 12/14/2009 05:31 PM, Todd Zullinger wrote: > Jeff Garzik wrote: >> If done right, the move to git can still service CVS requests in >> some capacity... that may make the transition a little less abrupt >> and painful. > > Perhaps. But git-cvsserver is a rather limited crutch that I can't > imagine anyone wanting to spend much time on, just to let folks > continue to use cvs commands directly. > > Who knows though, maybe there are more people that actually like cvs > than I think and they'll volunteer to implement and run such a > service. I think of it less as a question of /liking/ CVS, and more an admission that a global workflow change has real costs for each individual developer. A "flag day"-style transition is clean and efficient, but often locks out developers who are not able to march in lock-step with the transition schedule. I am very pro-git (naturally, being a kernel developer) and want this switch, but it nonetheless means my home-written scripts for maintaining related project packages (cld, chunkd, tabled) must be updated and tested. Even without local script updates, developers have to learn new stuff just to keep functioning at the same level as before. Jeff From jkeating at redhat.com Tue Dec 15 03:21:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 19:21:19 -0800 Subject: dist-git proof of concept phase 1 complete Message-ID: <1260847279.21725.3.camel@localhost.localdomain> In my effort to create a proof of concept for using git to manage our package source control, I have completed what I am calling phase one, that is taking our current dist-cvs and converting it into git format. pkgs/rpms//devel is now the git origin/master. All release subdirs have been turned into git branches. History back to F7, as well as the EPEL branches have been converted, from a snapshot of the CVS tree I took last week. Currently I only have anonymous git:// access setup, as we play with some options for authenticated writing. If you wish to play around with the repos, you can access it via: git://publictest5.fedoraproject.org/git/pkgs/ eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Give it a spin, see what you think. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 03:23:12 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 19:23:12 -0800 Subject: Datacenter, git, and cvs In-Reply-To: <4B26DE7C.9030709@pobox.com> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <4B26B738.50809@pobox.com> <20091214223136.GP5004@inocybe.localdomain> <4B26DE7C.9030709@pobox.com> Message-ID: <1260847392.21725.5.camel@localhost.localdomain> On Mon, 2009-12-14 at 19:55 -0500, Jeff Garzik wrote: > I think of it less as a question of /liking/ CVS, and more an admission > that a global workflow change has real costs for each individual developer. > > A "flag day"-style transition is clean and efficient, but often locks > out developers who are not able to march in lock-step with the > transition schedule. > > I am very pro-git (naturally, being a kernel developer) and want this > switch, but it nonetheless means my home-written scripts for maintaining > related project packages (cld, chunkd, tabled) must be updated and > tested. Even without local script updates, developers have to learn new > stuff just to keep functioning at the same level as before. Because we are not just moving source control backends, but also changing workflow, a cvs gateway to the git server wouldn't get you very far, unless it's a pretty hacked up gateway. If somebody wants to work on a gateway that's cool, I'm not considering it a blocker to rolling out the change, once we have a working proof of concept and a solid migration plan blessed by FESCo. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ngompa13 at gmail.com Tue Dec 15 03:48:55 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Mon, 14 Dec 2009 21:48:55 -0600 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <8278b1b0912141948p7912643dt6bf68d7f8922ca79@mail.gmail.com> Do you have the webview set up yet? On Mon, Dec 14, 2009 at 9:21 PM, Jesse Keating wrote: > In my effort to create a proof of concept for using git to manage our > package source control, I have completed what I am calling phase one, > that is taking our current dist-cvs and converting it into git format. > > pkgs/rpms//devel is now the git origin/master. All release > subdirs have been turned into git branches. History back to F7, as well > as the EPEL branches have been converted, from a snapshot of the CVS > tree I took last week. > > Currently I only have anonymous git:// access setup, as we play with > some options for authenticated writing. If you wish to play around with > the repos, you can access it via: > > git://publictest5.fedoraproject.org/git/pkgs/ eg if you wished > to clone the kernel, you'd type: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel > > Give it a spin, see what you think. > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Tue Dec 15 04:05:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 20:05:03 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <8278b1b0912141948p7912643dt6bf68d7f8922ca79@mail.gmail.com> References: <1260847279.21725.3.camel@localhost.localdomain> <8278b1b0912141948p7912643dt6bf68d7f8922ca79@mail.gmail.com> Message-ID: <1260849903.21725.8.camel@localhost.localdomain> On Mon, 2009-12-14 at 21:48 -0600, Sir Gallantmon wrote: > Do you have the webview set up yet? Not as of yet. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 04:22:09 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 20:22:09 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <1260850929.21725.10.camel@localhost.localdomain> On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From john5342 at googlemail.com Tue Dec 15 04:29:56 2009 From: john5342 at googlemail.com (John5342) Date: Tue, 15 Dec 2009 04:29:56 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <6dc6523c0912142029q264ce657k8adf8c57d72457e0@mail.gmail.com> On Tue, Dec 15, 2009 at 03:21, Jesse Keating wrote: > [...] > Currently I only have anonymous git:// access setup, as we play with > some options for authenticated writing.[...] Gitosis which is already in fedora does a pretty good job of this including key based auth as well as multiple authorized users per git repo, gitweb interface etc. Might be a good starting point if you weren't already aware of it... -- There are 10 kinds of people in the world: Those who understand binary and those who don't... From poelstra at redhat.com Tue Dec 15 04:45:36 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 14 Dec 2009 20:45:36 -0800 Subject: Wiki Feature Dashboard Additional Category In-Reply-To: References: Message-ID: <4B271470.9040004@redhat.com> Daniel Hendrycks said the following on 12/12/2009 10:03 AM Pacific Time: > Hi, my name is Daniel Hendrycks . > > I have a suggestion for the Fedora Wiki Feature Request Dashboard: > > The wiki page explaining how to properly request a feature had a link to > another wiki article telling you what to do if you cannot implement a > feature yourself. Within this article it never did state you need a > developer willing to implement but in actuality you do. It is a > requirement in your feature request to have someone willing to implement > your request. Which wiki page is talks about not being able to implement a feature yourself? I'll try to make it clearer. > My request is have a section in the feature process dashboard for > features without a developer. Features would be placed in that category > after being approved by the Feature Wrangler (poelcat). The feature > request must specify that the feature does not have a developer for it > to be put in that category (obviously). This would be more convenient > for the person wanting that feature. Feature request owners would not > have to hunt down developers and ask them to implement the feature for > them (this would annoy some community developers at the same and worsen > the Fedora Community). Instead developers could just look at what > requests have no developer and contact the owner of the feature and > include their name in the request, they would then be re-checked by the > Feature Wrangler and hopefully transfered to FESCo for further evaluation. > > I am suggesting the request would be placed in the "Feature has no > developer" (possible name of the category) section after being approved > by the Feature Wrangler because this will indicate that the request > meets all requirements except that it does not have a developer. Since > it meets all requirements possible developers will not have to read a > broken (incomplete) request, this would make developers more likely to > check. This is an interesting idea. I'm not sure how it would work in reality. Chances are someone deciding to work on a feature will add or make changes to the design proposed by someone else. > Summary: Have a section in the Feature Request Dashboard for features > without a developer. From there developers can volunteer there skills to > implement this feature if later on approved by FESCo. > > Thank you for your time, > Daniel Hendrycks :) > Topics of this nature are best discussed on fedora-devel-list which is where I'm moving this post The websites list has nothing to do with the features process. You have an interesting idea about tagging feature pages needing an owner. In reality that pretty much represents all the pages in 'Category:FeaturePageIncomplete' If they had an active owner or developer working on the feature they wouldn't be there. John From jkeating at redhat.com Tue Dec 15 05:35:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 21:35:45 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <6dc6523c0912142029q264ce657k8adf8c57d72457e0@mail.gmail.com> References: <1260847279.21725.3.camel@localhost.localdomain> <6dc6523c0912142029q264ce657k8adf8c57d72457e0@mail.gmail.com> Message-ID: <1260855345.21725.14.camel@localhost.localdomain> On Tue, 2009-12-15 at 04:29 +0000, John5342 wrote: > Gitosis which is already in fedora does a pretty good job of this > including key based auth as well as multiple authorized users per git > repo, gitweb interface etc. Might be a good starting point if you > weren't already aware of it... gitosis was the first idea, which led me to a rewrite somebody has done, gitolite http://github.com/sitaramc/gitolite which I'm trying to bend to our will. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From lemenkov at gmail.com Tue Dec 15 06:17:13 2009 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 15 Dec 2009 09:17:13 +0300 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: Hello All! 2009/12/15 Jesse Keating : > git://publictest5.fedoraproject.org/git/pkgs/ ?eg if you wished > to clone the kernel, you'd type: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel How to easily clone whole package tree? -- With best regards, Peter Lemenkov. From jkeating at redhat.com Tue Dec 15 06:33:58 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Dec 2009 22:33:58 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <1260858838.21725.16.camel@localhost.localdomain> On Tue, 2009-12-15 at 09:17 +0300, Peter Lemenkov wrote: > How to easily clone whole package tree? Right now? Not all that hard. You'd have to write a script that has all the package names and just cycles over them cloning them one by one. Once we start working on fpkg we'll likely wire something up that gets a list of active packages from pkgdb and does the cycle for you. It'd just be slow. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From martin.langhoff at gmail.com Tue Dec 15 08:00:20 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 15 Dec 2009 09:00:20 +0100 Subject: Datacenter, git, and cvs In-Reply-To: <20091214223136.GP5004@inocybe.localdomain> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <4B26B738.50809@pobox.com> <20091214223136.GP5004@inocybe.localdomain> Message-ID: <46a038f90912150000x1163687cke53d35653996db72@mail.gmail.com> On Mon, Dec 14, 2009 at 11:31 PM, Todd Zullinger wrote: > Jeff Garzik wrote: >> If done right, the move to git can still service CVS requests in >> some capacity... ?that may make the transition a little less abrupt >> and painful. > > Perhaps. ?But git-cvsserver is a rather limited crutch that I can't > imagine anyone wanting to spend much time on, just to let folks > continue to use cvs commands directly. Actually, the biggest issue with it is the somewhat awkward mapping of branches to "cvs modules". But the Fedora CVS repo doesn't use cvs branches AFAIK. (It's not that awkward, but for developers resisting change... ah, every changed comma is a slight :-) ... ). And git-submodules support. And that could be added with a modest effort. > Who knows though, maybe there are more people that actually like cvs > than I think and they'll volunteer to implement and run such a > service. Not so much about liking cvs. In the past, main use cases for git-cvsserver have been (a) users deeply attached to a heavy IDE (Eclipse) that doesn't yet have git support and (b) scripts & misc automation that nobody wants to port. btw, I designed and co-wrote it :-) m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kaboon at gmail.com Tue Dec 15 08:00:27 2009 From: kaboon at gmail.com (Eelko Berkenpies) Date: Tue, 15 Dec 2009 09:00:27 +0100 Subject: Yum "Cannot retrieve repository metadata" error Message-ID: <3f5430b30912150000v39fb1cdbob1d3116a1d0c7da5@mail.gmail.com> Hi all, Since my latest rawhide update, performed on Dec 12 (with --skip-broken enabled because of some broken dependencies and a certain laziness on my side), my yum is giving me the following error: Loaded plugins: presto Error: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again Here's a list of packages which got updated: http://berkenpies.nl/yum.log I'd be more than happy to manually downgrade some packages but does someone have any clue on which package could be causing this? On a side note, yum was also complaining about "/var/cache/yum/i386/13/rpmdb-cache" which didn't exist. To get rid of this one, I manually created the directory. -- With kind regards / Met vriendelijke groet, Eelko Berkenpies http://blog.berkenpies.nl/ From martin.langhoff at gmail.com Tue Dec 15 08:04:46 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 15 Dec 2009 09:04:46 +0100 Subject: Datacenter, git, and cvs In-Reply-To: <46a038f90912150000x1163687cke53d35653996db72@mail.gmail.com> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <4B26B738.50809@pobox.com> <20091214223136.GP5004@inocybe.localdomain> <46a038f90912150000x1163687cke53d35653996db72@mail.gmail.com> Message-ID: <46a038f90912150004r492a0b2amcdc6b5ad7989d5b9@mail.gmail.com> On Tue, Dec 15, 2009 at 9:00 AM, Martin Langhoff wrote: > branches AFAIK. (It's not that awkward, but for developers resisting > change... ah, every changed comma is a slight :-) ... ). To be clear, I mean developers with better things to do with their time than dealing with an SCM change. There is never a good time for an SCM change unfortunately, at least not in any large team. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From dalinhuang at gmail.com Tue Dec 15 09:32:43 2009 From: dalinhuang at gmail.com (phenix) Date: Tue, 15 Dec 2009 17:32:43 +0800 Subject: Yum "Cannot retrieve repository metadata" error In-Reply-To: <3f5430b30912150000v39fb1cdbob1d3116a1d0c7da5@mail.gmail.com> References: <3f5430b30912150000v39fb1cdbob1d3116a1d0c7da5@mail.gmail.com> Message-ID: <1260869563.2881.3.camel@localhost> I have the same problem. This is what i do to solve it. edit /etc/hosts, add the following hosts 80.239.156.215 mirrors.fedoraproject.org 152.46.7.222 download.fedoraproject.org 209.132.183.67 download.fedora.redhat.com use baseurl instead of mirrorlist repos. BUT, when upgrade complete, i can not reboot or bootup On Tue, 2009-12-15 at 09:00 +0100, Eelko Berkenpies wrote: > Hi all, > > Since my latest rawhide update, performed on Dec 12 (with > --skip-broken enabled because of some broken dependencies and a > certain laziness on my side), my yum is giving me the following error: > > Loaded plugins: presto > Error: Cannot retrieve repository metadata (repomd.xml) for > repository: rawhide. Please verify its path and try again > > Here's a list of packages which got updated: > http://berkenpies.nl/yum.log > > I'd be more than happy to manually downgrade some packages but does > someone have any clue on which package could be causing this? > > On a side note, yum was also complaining about > "/var/cache/yum/i386/13/rpmdb-cache" which didn't exist. To get rid of > this one, I manually created the directory. > > -- > With kind regards / Met vriendelijke groet, > > Eelko Berkenpies > http://blog.berkenpies.nl/ > From rjones at redhat.com Tue Dec 15 09:43:33 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Dec 2009 09:43:33 +0000 Subject: Datacenter, git, and cvs In-Reply-To: <20091214215702.GO5004@inocybe.localdomain> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> Message-ID: <20091215094333.GA29705@amd.home.annexia.org> On Mon, Dec 14, 2009 at 04:57:03PM -0500, Todd Zullinger wrote: > Mike Chambers wrote: > > If I understand what is happening now (and over the past weekend), > > the datacenter machines are moving to a new location, AND the > > package building is moving from cvs to git (will be, or already in > > process)? > > Only the former is taking place now. A move from cvs to git is being > tested but is not imminent. I'm sure that it will be hard to miss > once that change is ready and implemented. Is there any documentation about the move to git? In particular I'm interested in whether the whole of Fedora will be in a single git repository, or each package will exist in its own git repository. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Tue Dec 15 09:45:01 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Dec 2009 09:45:01 +0000 Subject: Datacenter, git, and cvs In-Reply-To: <20091215094333.GA29705@amd.home.annexia.org> References: <1260827384.14077.7.camel@localhost> <20091214215702.GO5004@inocybe.localdomain> <20091215094333.GA29705@amd.home.annexia.org> Message-ID: <20091215094501.GB29705@amd.home.annexia.org> On Tue, Dec 15, 2009 at 09:43:33AM +0000, Richard W.M. Jones wrote: > On Mon, Dec 14, 2009 at 04:57:03PM -0500, Todd Zullinger wrote: > > Mike Chambers wrote: > > > If I understand what is happening now (and over the past weekend), > > > the datacenter machines are moving to a new location, AND the > > > package building is moving from cvs to git (will be, or already in > > > process)? > > > > Only the former is taking place now. A move from cvs to git is being > > tested but is not imminent. I'm sure that it will be hard to miss > > once that change is ready and implemented. > > Is there any documentation about the move to git? In particular I'm > interested in whether the whole of Fedora will be in a single git > repository, or each package will exist in its own git repository. Ignore this -- Jesse answers it lower down. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 From rjones at redhat.com Tue Dec 15 09:49:21 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Dec 2009 09:49:21 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <20091215094921.GC29705@amd.home.annexia.org> On Mon, Dec 14, 2009 at 07:21:19PM -0800, Jesse Keating wrote: > In my effort to create a proof of concept for using git to manage our > package source control, I have completed what I am calling phase one, > that is taking our current dist-cvs and converting it into git format. > > pkgs/rpms//devel is now the git origin/master. All release > subdirs have been turned into git branches. History back to F7, as well > as the EPEL branches have been converted, from a snapshot of the CVS > tree I took last week. Why not put everything in a single git repository? Also git remote branches are quite painful, requiring non-obvious changes to .git/config or hard to use commands. I'd rather do this once (for an everything-in-one-repository model) than for every single package I maintain. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From twaugh at redhat.com Tue Dec 15 10:06:42 2009 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 15 Dec 2009 10:06:42 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215094921.GC29705@amd.home.annexia.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> Message-ID: <1260871602.2489.0.camel@localhost.localdomain> On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: > Why not put everything in a single git repository? That would require every packager to check out the entire package set, all revisions, all branches. No thanks. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Tue Dec 15 10:24:52 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 15 Dec 2009 11:24:52 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <20091215112452.6d69ebb3@dhcp03.addix.net> Hi. On Mon, 14 Dec 2009 19:21:19 -0800, Jesse Keating wrote: > In my effort to create a proof of concept for using git to manage our > package source control, I have completed what I am calling phase one, > that is taking our current dist-cvs and converting it into git format. That's just the naked content converted into git, right? All the scripts/ Makefiles in it still assume that CVS is used and thus do not do much? From rjones at redhat.com Tue Dec 15 10:34:04 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Dec 2009 10:34:04 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260871602.2489.0.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <1260871602.2489.0.camel@localhost.localdomain> Message-ID: <20091215103404.GA29955@amd.home.annexia.org> On Tue, Dec 15, 2009 at 10:06:42AM +0000, Tim Waugh wrote: > On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: > > Why not put everything in a single git repository? > > That would require every packager to check out the entire package set, > all revisions, all branches. No thanks. Jesse can probably estimate for us how large this will be. I've found that git deals very well with large repositories that have lots of files and lots of history (kernel, qemu). And you only ever have to download it once, since you can use "git fetch" to make local working copies. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From jwboyer at gmail.com Tue Dec 15 10:50:05 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 15 Dec 2009 05:50:05 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215103404.GA29955@amd.home.annexia.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <1260871602.2489.0.camel@localhost.localdomain> <20091215103404.GA29955@amd.home.annexia.org> Message-ID: <20091215105005.GF16448@hansolo.jdub.homelinux.org> On Tue, Dec 15, 2009 at 10:34:04AM +0000, Richard W.M. Jones wrote: >On Tue, Dec 15, 2009 at 10:06:42AM +0000, Tim Waugh wrote: >> On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: >> > Why not put everything in a single git repository? >> >> That would require every packager to check out the entire package set, >> all revisions, all branches. No thanks. > >Jesse can probably estimate for us how large this will be. > >I've found that git deals very well with large repositories that have >lots of files and lots of history (kernel, qemu). And you only ever >have to download it once, since you can use "git fetch" to make local >working copies. A full git repo was 5.7G. I sure as hell don't want to pull that down when I'm only interested in a few packages. (The CVS repo is 16G on the server side if you are wondering.) josh From jcm at redhat.com Tue Dec 15 10:55:19 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 15 Dec 2009 05:55:19 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260850929.21725.10.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> Message-ID: <1260874519.6151.179.camel@tonnant> On Mon, 2009-12-14 at 20:22 -0800, Jesse Keating wrote: > On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel > > This was the wrong path: > > git clone git://publictest5.fedoraproject.org/pkgs/kernel Can you explain the tags a little Jesse? e.g. F-12-split F-12-start I have absolutely no interest in the idea of doing one giant tree btw, though I doubt that will ever get serious traction :) Also, on the subject of branches, can you include a summary of branches too? Jon. From rjones at redhat.com Tue Dec 15 10:59:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Dec 2009 10:59:52 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215105005.GF16448@hansolo.jdub.homelinux.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <1260871602.2489.0.camel@localhost.localdomain> <20091215103404.GA29955@amd.home.annexia.org> <20091215105005.GF16448@hansolo.jdub.homelinux.org> Message-ID: <20091215105952.GB29955@amd.home.annexia.org> On Tue, Dec 15, 2009 at 05:50:05AM -0500, Josh Boyer wrote: > On Tue, Dec 15, 2009 at 10:34:04AM +0000, Richard W.M. Jones wrote: > >On Tue, Dec 15, 2009 at 10:06:42AM +0000, Tim Waugh wrote: > >> On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: > >> > Why not put everything in a single git repository? > >> > >> That would require every packager to check out the entire package set, > >> all revisions, all branches. No thanks. > > > >Jesse can probably estimate for us how large this will be. > > > >I've found that git deals very well with large repositories that have > >lots of files and lots of history (kernel, qemu). And you only ever > >have to download it once, since you can use "git fetch" to make local > >working copies. > > A full git repo was 5.7G. I sure as hell don't want to pull that down > when I'm only interested in a few packages. > > (The CVS repo is 16G on the server side if you are wondering.) Fair enough - it doesn't make sense since the combined repo would be so large. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jwboyer at gmail.com Tue Dec 15 11:02:30 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 15 Dec 2009 06:02:30 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260874519.6151.179.camel@tonnant> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <1260874519.6151.179.camel@tonnant> Message-ID: <20091215110230.GG16448@hansolo.jdub.homelinux.org> On Tue, Dec 15, 2009 at 05:55:19AM -0500, Jon Masters wrote: >On Mon, 2009-12-14 at 20:22 -0800, Jesse Keating wrote: >> On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: >> > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel >> >> This was the wrong path: >> >> git clone git://publictest5.fedoraproject.org/pkgs/kernel > >Can you explain the tags a little Jesse? > >e.g. >F-12-split >F-12-start Those are straight from CVS. I'm guessing they have to do with when we do a mass 'CVS branch' to create the dirs for the next release. josh From berrange at redhat.com Tue Dec 15 11:11:22 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Dec 2009 11:11:22 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215105952.GB29955@amd.home.annexia.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <1260871602.2489.0.camel@localhost.localdomain> <20091215103404.GA29955@amd.home.annexia.org> <20091215105005.GF16448@hansolo.jdub.homelinux.org> <20091215105952.GB29955@amd.home.annexia.org> Message-ID: <20091215111122.GC9297@redhat.com> On Tue, Dec 15, 2009 at 10:59:52AM +0000, Richard W.M. Jones wrote: > On Tue, Dec 15, 2009 at 05:50:05AM -0500, Josh Boyer wrote: > > On Tue, Dec 15, 2009 at 10:34:04AM +0000, Richard W.M. Jones wrote: > > >On Tue, Dec 15, 2009 at 10:06:42AM +0000, Tim Waugh wrote: > > >> On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: > > >> > Why not put everything in a single git repository? > > >> > > >> That would require every packager to check out the entire package set, > > >> all revisions, all branches. No thanks. > > > > > >Jesse can probably estimate for us how large this will be. > > > > > >I've found that git deals very well with large repositories that have > > >lots of files and lots of history (kernel, qemu). And you only ever > > >have to download it once, since you can use "git fetch" to make local > > >working copies. > > > > A full git repo was 5.7G. I sure as hell don't want to pull that down > > when I'm only interested in a few packages. > > > > (The CVS repo is 16G on the server side if you are wondering.) > > Fair enough - it doesn't make sense since the combined repo would > be so large. I was wondering if you could set up some meta repository, which had a GIT sub-module for each package, but it seems sub-modules always have to specify an explicit commit hash so they wouldn't seemlessly follow changes. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From karlthered at gmail.com Tue Dec 15 11:15:11 2009 From: karlthered at gmail.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=) Date: Tue, 15 Dec 2009 12:15:11 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <4B276FBF.9030500@gmail.com> Do you have any plan about hooks ? Since 1 package = 1 repository, does that mean package maintainers will be able to define their own hooks ? (bad idea) will we have some pre-defined hooks (like bz integration) ? or something like github webhooks or bitbucket brokers ? H. From rawhide at fedoraproject.org Tue Dec 15 12:51:17 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 15 Dec 2009 12:51:17 +0000 Subject: rawhide report: 20091215 changes Message-ID: <20091215125117.GA19419@releng2.fedora.phx.redhat.com> Compose started at Tue Dec 15 08:15:10 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 abrt-1.0.0-1.fc13.i686 requires librpm.so.0 abrt-1.0.0-1.fc13.i686 requires librpmio.so.0 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 gg2-core-2.3.0-13.fc12.i686 requires perl(DynaLoader) = 0:1.08 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 gvfs-afc-1.5.1-2.fc13.i686 requires libplist.so.0 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so ifuse-0.9.4-2.fc13.i686 requires libplist.so.0 inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 libiphone-0.9.4-2.fc13.i686 requires libplist.so.0 libiphone-python-0.9.4-2.fc13.i686 requires libplist.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) abrt-1.0.0-1.fc13.x86_64 requires librpm.so.0()(64bit) abrt-1.0.0-1.fc13.x86_64 requires librpmio.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) gg2-core-2.3.0-13.fc12.x86_64 requires perl(DynaLoader) = 0:1.08 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) gvfs-afc-1.5.1-2.fc13.x86_64 requires libplist.so.0()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) ifuse-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) libiphone-0.9.4-2.fc13.i686 requires libplist.so.0 libiphone-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) libiphone-python-0.9.4-2.fc13.x86_64 requires libplist.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package activemq-cpp C++ implementation of JMS-like messaging client New package compiz-fusion-unsupported Additional plugins for Compiz New package imagej Image Processing and Analysis in Java New package mingw32-gtkhtml3 MinGW library for embedding a lightweight web browser in GTK programs New package mysql-mmm Multi-Master Replication Manager for MySQL New package oflb-dignas-handwriting-fonts Handwriting font New package perl-CGI-Application-Structured-Tools Tools to generate and maintain CGI::Application::Structured based web apps New package php-pear-Spreadsheet-Excel-Writer Package for generating Excel spreadsheets New package usbview USB topology and device viewer Removed package fonts-hebrew-fancy Removed package gpixpod Removed package libscigraphica Removed package scigraphica Updated Packages: GConf2-2.28.0-3.fc13 -------------------- * Mon Dec 14 2009 Matthias Clasen - 2.28.0-3 - Avoid a crash when gconftool-2 can't read the db (#547238) ModemManager-0.2.997-2.git20091214.fc13 --------------------------------------- * Mon Dec 14 2009 Dan Williams - 0.2.997-2.git20091214 - cdma: fix signal strength reporting on some devices - cdma: better registration state detection when dialing (ex Sierra 5275) NetworkManager-0.7.997-2.git20091214.fc13 ----------------------------------------- * Mon Dec 14 2009 Dan Williams - 0.7.997-2.git20091214 - core: fix recognition of standalone 802.1x private keys - applet: clean notification text to ensure it passes libnotify validation NetworkManager-openconnect-0.7.997-1.fc13 ----------------------------------------- * Mon Dec 14 2009 Dan Williams - 1:0.7.997-1 - Correctly handle PEM certificates without an ending newline (rh #507315) NetworkManager-openvpn-0.7.997-1.fc13 ------------------------------------- * Mon Dec 14 2009 Dan Williams - 1:0.7.997-1 - Implement export capability - Fix some import bugs - Correctly handle PEM certificates without an ending newline (rh #507315) NetworkManager-pptp-0.7.997-1.fc13 ---------------------------------- * Mon Dec 14 2009 Dan Williams - 1:0.7.997-1 - Add debugging helpers - Fix saving MPPE-related settings from the properties dialog - Resolve PPTP gateway hostname if necessary NetworkManager-vpnc-0.7.997-1.fc13 ---------------------------------- * Mon Dec 14 2009 Dan Williams - 1:0.7.997-1 - Add some debug options (VPNC_DEBUG, --persist) - Make .desktop file pass validation (rh #489475) aide-0.13.1-15.fc13 ------------------- * Fri Dec 11 2009 Steve Grubb - 0.13.1-15 - Get rid of .dedosify files audio-convert-mod-3.46.0b-1.fc13 -------------------------------- * Sun Dec 13 2009 Stewart Adam 3.46.0b - Update to 3.46.0b (see ChangeLog for details on version changes) authconfig-6.0.0-2.fc13 ----------------------- * Mon Dec 14 2009 Tomas Mraz - 6.0.0-2 - should work fine with sssd >= 0.99.1 (#547344) bash-4.0.35-2.fc13 ------------------ * Fri Dec 11 2009 Roman Rakus - 4.0.35-2 - Don't segfault when TERM=eterm* and EMACS is unset (#530911) bltk-1.0.9-7.fc13 ----------------- * Fri Dec 11 2009 Jiri Skala 1.0.9-7 - fixes #542688 - bltk will run any command as root coreutils-8.2-1.fc13 -------------------- * Fri Dec 11 2009 Ondrej Vasik - 8.2-1 - new upstream release 8.2 - removed applied patches, temporarily do not run dup_cloexec() dependent gnulib tests failing in koji cvs2svn-2.3.0-0.1.r4998svn.fc13 ------------------------------- * Mon Dec 14 2009 Milos Jakubicek - 2.3.0-0.1.r4998svn - Ship also cvs2git from a 2.3.0 prerelease, split common files into a cvs2commons subpackage dalston-0.1.12-1.fc13 --------------------- * Thu Dec 10 2009 Peter Robinson 0.1.12-1 - new upstream 0.1.12 release dhcp-4.1.0p1-15.fc13 -------------------- * Mon Dec 14 2009 Jiri Popelka - 12:4.1.0p1-15 - dhclient logs its pid to make troubleshooting NM managed systems with multiple dhclients running easier (#546792) dracut-modules-olpc-0.3.2-1.fc13 -------------------------------- * Mon Dec 14 2009 Daniel Drake - 0.3.2-1 - New version to fix activation code eclipse-cdt-6.0.1-7.fc13 ------------------------ * Fri Dec 11 2009 Jeff Johnston 1:6.0.1-7 - Rebase Autotools to Linux tools 0.4.0.1 release. - Rebase Libhover to Linux tools 0.4.0 release. - Remove libhover patch which is now part of rebase. egoboo-2.7.5-8.fc13 ------------------- * Sat Dec 12 2009 Rakesh Pandit - 2.7.5-8 - Updated to consume new libenet elinks-0.12-0.20.pre5.fc13 -------------------------- * Mon Dec 14 2009 Ondrej Vasik 0.12-0.20.pre5 - Add buildrequires for gpm-devel to enable gpm support(#547064) enscript-1.6.4-16.fc13 ---------------------- * Mon Dec 14 2009 Adam Tkac - 1.6.4-16 - merge review related fixes (#225729) f-spot-0.6.1.5-2.fc13 --------------------- * Mon Dec 14 2009 Christian Krause - 0.6.1.5-2 - Corrected the permission fix for all .exe and .dll files in order to generate the dependencies correctly (BZ 547063) file-roller-2.29.2-3.fc13 ------------------------- * Mon Dec 14 2009 Matthias Clasen 2.29.2-3 - Fix a wrong use of gdk_property_get (#538535) firmware-addon-dell-2.2.1-2.fc13 -------------------------------- * Fri Dec 11 2009 Matt Domsch - 2.2.1-1 - rebase to latest upstream * Fri Dec 11 2009 Matt Domsch - 2.2.1-2 - remember to upload the tarball first florence-0.4.5-1.fc13 --------------------- * Fri Dec 11 2009 Simon Wesp - 0.4.5-1 - New upstream release freeciv-2.1.10-1.fc13 --------------------- * Fri Dec 11 2009 Brian Pepple - 2.1.10-1 - Update to 2.1.10. gbirthday-0.5.5-1.fc13 ---------------------- * Mon Dec 14 2009 Thomas Spura 0.5.5-1 - new version gc-7.2-0.1.alpha4.fc13 ---------------------- * Fri Dec 11 2009 Rex Dieter - 7.2-0.1.alpha4 - gc-7.2alpha4 - use/package internal libatomic_ops ggz-base-libs-0.99.5-6.fc13 --------------------------- * Sat Dec 12 2009 Rex Dieter 0.99.5-6 - Verify Check ( rpm -V ggz-client-libs ) (#487984) ghc-6.12.1-0.2.fc13 ------------------- * Sat Dec 12 2009 Jens Petersen - 6.12.1-0.2 - remove redundant mingw and perl from ghc-tarballs/ - fix exclusion of ghc internals lib from base packages with -mindepth - rename the final file lists to PKGNAME.files for clarity * Fri Dec 11 2009 Jens Petersen - 6.12.1-0.1 - update to ghc-6.12.1-pre - separate bcond options into enabled and disabled for clarity - only enable shared for intel x86 archs (Lorenzo Villani) - add quick build profile (Lorenzo Villani) - remove package_debugging hack (use "make install-short") - drop sed BR (Lorenzo Villani) - put all build.mk config into one cat block (Lorenzo Villani) - export CFLAGS to configure (Lorenzo Villani) - add dynamic linking test to check section (thanks Lorenzo Villani) - remove old ghc66 obsoletes - subpackage huge ghc internals library (thanks Lorenzo Villani) - BR ghc-rpm-macros >= 0.3.0 - move html docs to docdir/ghc from html subdir (Lorenzo Villani) - disable smp build for now: broken for 8 cpus at least * Wed Nov 18 2009 Jens Petersen - 6.12.0.20091121-1 - update to 6.12.1 rc2 - build shared libs, yay! and package in standalone libs subpackage - add bcond for manual and extralibs - reenable ppc secondary arch - don't provide ghc-haddock-* - remove obsoltete post requires policycoreutils - add vanilla v to GhcLibWays when building without prof - handle without hscolour - can't smp make currently - lots of filelist fixes for handling shared libs - run ghc-pkg recache posttrans - no need to install gen_contents_index by hand - manpage is back * Thu Nov 12 2009 Bryan O'Sullivan - 6.12.0.20091010-3 - fix %check unset DISPLAY * Thu Nov 12 2009 Bryan O'Sullivan - 6.12.0.20091010-5 - try to install man pages * Thu Nov 12 2009 Bryan O'Sullivan - 6.12.0.20091010-6 - give up trying to install man pages * Thu Nov 12 2009 Bryan O'Sullivan - 6.12.0.20091010-7 - fix package.conf stuff * Thu Nov 12 2009 Bryan O'Sullivan - 6.12.0.20091010-8 - comprehensive attempts at packaging fixes * Sun Oct 11 2009 Bryan O'Sullivan - 6.12.0.20091010-1 - Update to 6.12 RC 1 * Sun Oct 11 2009 Bryan O'Sullivan - 6.12.0.20091010-2 - disable ppc for now (seems unsupported) - buildreq ncurses-devel ghc-rpm-macros-0.3.0-1.fc13 --------------------------- * Sat Dec 12 2009 Jens Petersen - 0.3.0-1 - major updates for ghc-6.12, package.conf.d, and shared libraries - add shared support to cabal_configure, ghc_gen_filelists - version ghcdocdir - replace ghc_gen_scripts, ghc_install_scripts, ghc_register_pkg, ghc_unregister_pkg with cabal_pkg_conf - allow (ghc to) override ghc_version ghdl-0.28-0.131svn.2.fc13 ------------------------- * Mon Dec 14 2009 Thomas Sailer - 0.28-0.131svn.2 - Process Timeout Chain bugfix - --trace-signals memory leak fix gimp-2.6.8-1.fc13 ----------------- * Fri Dec 11 2009 Nils Philippsen - 2:2.6.8-1 - version 2.6.8 Overview of Changes from GIMP 2.6.7 to GIMP 2.6.8 ================================================= * Bugs fixed: 470698 - MapObject cannot modify highlight 593848 - FG color changed to black when FG-BG Editor tab created 594651 - layer.scale() raises RuntimeError 594998 - Keyboard shortcuts does not work for first image when dock is focused 599765 - F1 key on gimp-tool-align in menu have wrong link and it open gimp-tool-move 600484 - Gimp BMP Integer Overflow Vulnerability 600741 - "read_channel_data()" Integer Overflow Vulnerability 601891 - gimp_image_get_selection returns None 602761 - plug-in-grid: Parameters Horizontal/Vertical Spacing and Horizontal/Vertical Offset are reversed. 603995 - PCX plugin doesn't sanitize input to avoid allocation overflows. 603998 - PCX: Calculating amount of memory to allocate may overflow. 604000 - SGI: sanitize input 604001 - SGI: Calculating amount of memory to allocate may overflow. 604002 - SGI: RLE encoded input data may write beyond allocated buffers 604004 - SGI: allocate memory consistently 604008 - GBR, PAT: sanitize input data 604078 - Crash when pressing Backspace with Free Select Tool * Updated and new translations: Basque (eu) British English (en_GB) Czech (cs) French (fr) Greek (el) Italian (it) Japanese (ja) Norwegian Nynorsk (nn) Polish (pl) Romanian (ro) Russian (ru) Simplified Chinese (zh_CN) - remove obsolete bmp-hardening, psd-hardening patches glibc-2.11.90-4 --------------- * Mon Dec 14 2009 Andreas Schwab - 2.11.90-4 - Update from master. - Add Requeue-PI support for x86 arch. - Redefine O_SYNC and O_DSYNC to match 2.6.33+ kernels. - Fix a few error cases in *name4_r lookup handling (BZ#11000). - Fix kernel version check in recent ptsname change (BZ#11046). - Add more warnings to exec functions (BZ#11056). - Add recvmmsg interface. - Define SCHED_IDLE and SCHED_RESET_ON_FORK for Linux. gnome-bluetooth-2.29.3-2.fc13 ----------------------------- * Mon Dec 14 2009 Bastien Nocera 2.29.3-2 - Add patch to fix possible crasher in bluetooth-sendto (#544881) gnome-screensaver-2.28.0-9.fc13 ------------------------------- * Fri Dec 11 2009 Matthias Clasen 2.28.0-9 - Properly handle cmdline parsing errors in popsquares (#546656) gourmet-0.15.1-1.fc13 --------------------- * Mon Dec 14 2009 Jef Spaleta - 0.15.1-1 - New upstream release gpodder-2.1-1.fc13 ------------------ * Mon Dec 14 2009 Jef Spaleta - 2.1-1 - New upstream release gtg-0.2-2.fc13 -------------- * Mon Dec 14 2009 Yanko Kaneti 0.2-2 - 0.2 final. http://gtg.fritalk.com/post/2009/12/10/The-new-Getting-Things-GNOME!-0.2-Gorignak-has-landed! hdparm-9.27-1.fc13 ------------------ * Fri Dec 11 2009 Karsten Hopp 9.27-1 - update to 9.27 - enhance security-erase timeout to 12h (#536731) hosts3d-1.07-1.fc13 ------------------- * Fri Dec 11 2009 Simon Wesp - 1.07-1 - New upstream release * Fri Nov 20 2009 Simon Wesp - 1.06-1 - New upstream release hunspell-dsb-1.1.3-1.fc13 ------------------------- * Fri Dec 11 2009 Caolan McNamara - 1.1.3-1 - latest version hunspell-sk-0.20091213-1.fc13 ----------------------------- * Mon Dec 14 2009 Caolan McNamara - 1:0.20091213-1 - latest version hunspell-zu-0.20091210-1.fc13 ----------------------------- * Fri Dec 11 2009 Caolan McNamara - 0.20091210-1 - latest version inn-2.5.1-2.fc13 ---------------- * Fri Dec 11 2009 Nikola Pajkovsky - 2.5.1-2 - #225901 - Merge Review: inn iverilog-0.9.20091212-1.fc13 ---------------------------- * Sat Dec 12 2009 Chitlesh Goorah - 0.9.20091212-1 - New development snapshot - 0.9.2 final prerelease snapshot jakarta-commons-pool-1.3-13.fc13 -------------------------------- * Fri Dec 11 2009 Mary Ellen Foster - 1:1.3-13 - Include Maven metadata - Fix badly auto-incremented release version jd-2.5.5-0.2.svn3231_trunk.fc13 ------------------------------- * Mon Dec 14 2009 Mamoru Tasaka - rev 3231 kdeaccessibility-4.3.80-1.fc13 ------------------------------ * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdeadmin-4.3.80-3.fc13 ---------------------- * Mon Dec 14 2009 Rex Dieter - 4.3.80-3 - Repositioning the KDE Brand (#547361) - omit kpackage - drop old/unused kuser consolehelper files * Fri Dec 04 2009 Than Ngo - 4.3.80-2 - fix rhel conditionals * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdeartwork-4.3.80-1.fc13 ------------------------ * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdebase-workspace-4.3.80-4.fc13 ------------------------------- * Fri Dec 11 2009 Rex Dieter - 4.3.80-4 - SELinux is preventing access to a leaked .xsession-errors-:0 file descriptor (#542312) kdebindings-4.3.80-3.fc13 ------------------------- * Sat Dec 12 2009 Kevin Kofler - 4.3.80-3 - fix NepomukSmoke build (blacklist Nepomuk::ResourceManager::generateUniqueUri) - fix the PyKDE4 Akonadi, kdeui and Phonon bindings to build * Fri Dec 04 2009 Than Ngo - 4.3.80-2 - respin * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdeedu-4.3.80-1.fc13 -------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdegames-4.3.80-2.fc13 ---------------------- * Sat Dec 12 2009 Kevin Kofler - 4.3.80-2 - fix liblogine and libloscript to link (upstream patches) - update description to list new games - update file lists and scriptlets for Palapeli * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdelibs3-3.5.10-21.fc13 ----------------------- * Mon Dec 07 2009 Than Ngo - 3.5.10-21 - fix security issues in libltdl bundle within kdelibs CVE-2009-3736 - backport upstream patches - patch autoconfigury to build with autoconf >= 2.64 (Stepan Kasal) * Mon Nov 02 2009 Luk?? Tinkl - 3.5.10-20 - fix unrestricted XMLHttpRequest access to local URLs (oCERT-2009-015), #532428 kdemultimedia-4.3.80-1.fc13 --------------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdenetwork-4.3.80-1.fc13 ------------------------ * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) - reenable webkitpart support kdepim-4.3.80-5.fc13 -------------------- * Fri Dec 11 2009 Lorenzo Villani - 6:4.3.80-5 - KPilot is no longer part of kdepim (see http://bertjan.broeksemaatjes.nl/node/50) * Wed Dec 09 2009 Than Ngo - 4.3.80-4 - apply upstream patch to fix crash in Kontact+KOrganizer with Qt4.6 * Tue Dec 08 2009 Than Ngo - 4.3.80-2 - drop BR kdelibs-experimental * Tue Dec 08 2009 Michael Schwendt - 4.3.80-3 - Explicitly BR libassuan-static in accordance with the Packaging Guidelines (libassuan-devel is still static-only). * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) * Fri Nov 27 2009 Than Ngo - 4.3.75-0.3.svn1048496 - fix build issue on s390(x) kdepim-runtime-4.3.80-4.fc13 ---------------------------- * Fri Dec 11 2009 Rex Dieter 4.3.80-4 - BR: shared-desktop-ontologies - tighten some deps kdeplasma-addons-4.3.80-1.fc13 ------------------------------ * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdesdk-4.3.80-1.fc13 -------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdetoys-4.3.80-1.fc13 --------------------- * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kdeutils-4.3.80-2.fc13 ---------------------- * Fri Dec 11 2009 Rex Dieter - 4.3.80-2 - BR: xz-devel * Tue Dec 01 2009 Luk?? Tinkl - 4.3.80-1 - KDE 4.4 beta1 (4.3.80) kernel-2.6.32.1-9.fc13 ---------------------- * Mon Dec 14 2009 Kyle McMartin 2.6.32.1-9 - 2.6.32.1 - ext4 patches and more... kobby-1.0-0.3.b4.fc13 --------------------- * Fri Dec 11 2009 Ben Boeckel - 1.0-0.3.b4 - Update to beta4 * Thu Jul 30 2009 Ben Boeckel 1.0-0.2.b3 - Fix summary latex2html-2008-4.fc13 ---------------------- * Fri Dec 11 2009 Jindrich Novy 2008-4 - require netpbm-progs - review fixes (#225980): - include documentation - set executable bit for makeseg and makemap scripts - white-space spec correction - move docs and example directory to %doc - nuke duplicated stuff less-436-4.fc13 --------------- * Sat Dec 12 2009 Nikola Pajkovsky - 436-4 - #546613 - RFE: add *.jar *.nbm to lesspipe.sh libICE-1.0.6-2.fc13 ------------------- * Sat Dec 12 2009 Robert Scheck 1.0.6-2 - Own the /usr/include/X11/ICE directory including its content libXext-1.1-2.fc13 ------------------ * Sat Dec 12 2009 Robert Scheck 1.1-2 - libXext-1.1-XAllocID.patch: call XAllocID with the display lock held. - libXext-1.1-event_vec-smash.patch: don't smash the event processing vector if the server has an older extension version than the client. libdvdread-4.1.4-0.2.svn1188.fc13 --------------------------------- * Sat Dec 12 2009 Dominik Mierzejewski 4.1.4-0.2.svn1188 - updated to SVN r1188 (rhbz#540155) libqinfinity-1.0-0.2.b4.fc13 ---------------------------- * Fri Dec 11 2009 Ben Boeckel - 1.0-0.2.b4 - Update to beta4 libsmbios-2.2.19-1.fc13 ----------------------- * Fri Dec 11 2009 Matt Domsch - 2.2.19-1 - update to upstream 2.2.19 libssh-0.4.0-1.fc13 ------------------- * Fri Dec 11 2009 Jan F. Chadima - 0.4.0-1 - bounce versionn to 0.4.0 (#541010) libuser-0.56.13-1.fc13 ---------------------- * Fri Dec 11 2009 Miloslav Trma? - 0.56.13-1 - Update to libuser-0.56.13. Resolves: #251951 Resolves: #454079 Resolves: #456373 Resolves: #456382 Resolves: #530513 lxappearance-0.3.0-1.fc13 ------------------------- * Fri Dec 11 2009 Christoph Wickert - 0.3.0-1 - Update to 0.3.0 lxde-common-0.5.0-1.fc13 ------------------------ * Fri Dec 11 2009 Christoph Wickert - 0.5.0-1 - Update to 0.5.0 lxpanel-0.5.4-1.fc13 -------------------- * Fri Dec 11 2009 Christoph Wickert - 0.5.4-1 - Update to 0.5.4 - Restore toggle functionality of the show deskop plugin lxsession-0.4.1-1.fc13 ---------------------- * Fri Dec 11 2009 Christoph Wickert - 0.4.1-1 - Update to 0.4.1 * Tue Dec 08 2009 Christoph Wickert - 0.4.0-1 - Update to 0.4.0 - Obsolete lxde-settings-deamon mailx-12.4-4.fc13 ----------------- * Sat Dec 12 2009 Robert Scheck - 12.4-4 - Make OpenSSL support working again if NSS flag is disabled mono-bouncycastle-1.5-5.fc13 ---------------------------- * Fri Dec 11 2009 Kalev Lember - 1.5-5 - Updated mono-nopatents.patch to the version sent upstream munin-1.4.1-3.fc13 ------------------ * Fri Dec 11 2009 Ingvar Hagelund - 1.4.1-3 - More correct fedora and el versions for previous font path fix - Added a patch that fixes a quoting bug in GraphOld.pm, fixing fonts on el4 nabi-0.99.6-1.fc13 ------------------ * Fri Dec 11 2009 Jens Petersen - 0.99.6-1 - update to 0.99.6 - require libhangul >= 0.0.10 network-manager-netbook-1.7.0-1.fc13 ------------------------------------ * Mon Dec 14 2009 Peter Robinson 1.7.0-1 - Update to new upstream 1.7.0 release nfs-utils-1.2.1-7.fc13 ---------------------- * Mon Dec 14 2009 Steve Dickson 1.2.1-7 - Updated to latest upstream RC release: nfs-utils-1-2-2-rc3 olpc-utils-1.0.14-1.fc13 ------------------------ * Fri Dec 11 2009 Daniel Drake - 1.0.14-1 - Bump to v1.0.14 for DDC config openttd-opengfx-0.2.0-1.fc13 ---------------------------- * Fri Dec 11 2009 Felix Kaechele - 0.2.0-1 - update to 0.2.0 - cleaned up docs openvpn-2.1.1-1.fc13 -------------------- * Fri Dec 11 2009 Steven Pritchard 2.1.1-1 - Update to 2.1.1. oprofile-0.9.6-2.fc13 --------------------- * Fri Dec 11 2009 Will Cohen - 0.9.6-2 - Clean up oprofile.spec file. ovaldi-5.5.25-2.fc13 -------------------- * Fri Dec 11 2009 Lubomir Rintel 5.5.25-2 - Rebuild for RPM 4.8.0 passivetex-1.25-11.fc13 ----------------------- * Mon Dec 14 2009 Ondrej Vasik - 1.25-11 - Merge Review(#226231): Fixed sources, license, buildroot, added build section perl-BDB-1.86-3.fc13 -------------------- * Sun Dec 13 2009 Nicolas Chauvet - 1.86-3 - Drop Patch0 perl-Math-Pari-2.010806-3.fc13 ------------------------------ * Fri Dec 11 2009 Paul Howarth - 2.010806-3 - Update to 2.01080603 (see Changes for details) perl-RPM2-0.68-6.fc13 --------------------- * Fri Dec 11 2009 Lubomir Rintel - 0.68-6 - Rebuild for RPM 4.8.0 php-ZendFramework-1.9.6-2.fc13 ------------------------------ * Tue Dec 08 2009 Felix Kaechele - 1.9.6-2 - insert correct provides/obsoletes for tests subpackage removal php-phpunit-phpcpd-1.2.2-1.fc13 ------------------------------- * Sat Dec 12 2009 Christof Damian - 1.2.2-1 - upstream 1.2.2 php-phpunit-phploc-1.4.0-1.fc13 ------------------------------- * Sat Dec 12 2009 Christof Damian - 1.4.0-1 - upstream 1.4.0 pitivi-0.13.3-3.3.837f0d73.fc13 ------------------------------- * Fri Dec 11 2009 Jeffrey C. Ollie - 0.13.3-3.3.837f0d73 - Make sure we have the correct source uploaded. * Thu Dec 10 2009 Jeffrey C. Ollie - 0.13.3-3.2.837f0d73 - Update to git master to see if this fixes anyone's problems - Call update-desktop-database/update-mime-database in post/postun planner-0.14.4-11.fc13 ---------------------- * Mon Dec 14 2009 Caol?n McNamara - 0.14.4-9 - Resolves: rhbz#546850 use different colors for different day types * Mon Dec 14 2009 Caol?n McNamara - 0.14.4-10 - Resolves: rhbz#546846 show date in resource usage statusbar * Mon Dec 14 2009 Caol?n McNamara - 0.14.4-11 - Resolves: rhbz#546844 add tooltips to views * Fri Dec 11 2009 Caol?n McNamara - 0.14.4-8 - Resolves: rhbz#546515 allow scrolling pothana2000-fonts-1.3.2-1.fc13 ------------------------------ * Mon Dec 14 2009 - 1.3.2-1 - Fixed FSType, Preferred Style, UinqueID and Fullname - Fixed Invalid Glyph Names reported by fontlint - with exceptions string added in License python-basemap-0.99.4-1.fc13 ---------------------------- * Fri Dec 11 2009 Jon Ciesla - 0.99.4-1 - Update to latest upstream. - Dropped datadir patch, now handled with environment variable. python-basemap-data-0.99.4-1.fc13 --------------------------------- * Fri Dec 11 2009 Jon Ciesla - 0.99.4-1 - Update to latest upstream. python-dmidecode-3.10.8-1.fc13 ------------------------------ python-feedparser-4.1-11.fc13 ----------------------------- * Mon Dec 14 2009 Ha?kel Gu?mar - 4.1-11 - rebuild for Fedora 13 python-matplotlib-0.99.1.2-1.fc13 --------------------------------- * Fri Dec 11 2009 Jon Ciesla - 0.99.1.2 - Update to 0.99.1.2 python-polib-0.5.1-1.fc13 ------------------------- * Mon Dec 14 2009 Diego B?rigo Zacar?o - 0.5.1-1 - Updated to 0.5.1 release python-rabbyt-0.8.3-1.fc13 -------------------------- * Fri Dec 11 2009 Simon Wesp - 0.8.3-1 - New upstream Release python-setuptools-0.6.8-2.fc13 ------------------------------ * Sun Dec 13 2009 Toshio Kuratomi - 0.6.8-2 - Test rebuild python-telepathy-0.15.13-1.fc13 ------------------------------- * Mon Dec 14 2009 Brian Pepple - 0.15.13-1 - Update to 0.15.13. python-xlib-0.15-0.1.rc1.fc13 ----------------------------- * Mon Dec 14 2009 Jef Spaleta - 0.15-0.1.rc1 - New upstream pre-release and some cherry picked patches from Debian from Fedora bug 537264 rpmreaper-0.1.6-2.fc13 ---------------------- rt3-3.8.7-1.fc13 ---------------- * Mon Dec 14 2009 Ralf Cors?pius - 3.8.7-1 - Upstream update. - Add UPGRADING.mysql, perl(Text::Quoted), R: perl(Text::WikiFormat) (BZ #546786; Thanks to Dale Bewley ) rubygem-marc-0.3.1-1.fc13 ------------------------- * Tue Dec 15 2009 Mamoru Tasaka - 0.3.1-1 - 0.3.1 rubygem-nokogiri-1.4.1-1.fc13 ----------------------------- * Tue Dec 15 2009 Mamoru Tasaka - 1.4.1-1 - 1.4.1 safekeep-1.2.1-1.fc13 --------------------- * Mon Dec 14 2009 Jef Spaleta 1.2.1-1 - Latest upstream release * Sun Jul 26 2009 Fedora Release Engineering - 1.0.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild scipy-0.7.1-1.fc13 ------------------ * Thu Dec 10 2009 Jon Ciesla - 0.7.1-1 - Update to 0.7.1. seahorse-2.29.3-2.fc13 ---------------------- * Mon Dec 14 2009 Matthias Clasen 2.29.3-2 - Fix a wrong use of gdk_property_get that can lead to crashes snownews-1.5.12-2.fc13 ---------------------- * Mon Dec 14 2009 Zing - 1.5.12-2 - Bring back link with ncursesw, set -DUTF_8 for xmlUTF8Strlen #546431 mistakenly dropped when charset patch went upstream sssd-0.99.1-1.fc13 ------------------ * Fri Dec 11 2009 Stephen Gallagher - 0.99.1-1 - New upstream bugfix release 0.99.1 sugar-calculator-30-3.fc13 -------------------------- * Mon Dec 14 2009 Peter Robinson - 30-3 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539143 sugar-clock-5-3.fc13 -------------------- * Mon Dec 14 2009 Peter Robinson - 5-3 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 538921 sugar-connect-22-5.fc13 ----------------------- * Mon Dec 14 2009 Peter Robinson - 22-5 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 538900 sugar-distance-13-4.fc13 ------------------------ * Mon Dec 14 2009 Peter Robinson - 13-4 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539162 sugar-implode-5-5.20090717.fc13 ------------------------------- * Mon Dec 14 2009 Peter Robinson - 5-5 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539177 sugar-infoslicer-6-2.fc13 ------------------------- * Mon Dec 14 2009 Peter Robinson - 6-2 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539177 * Fri Nov 20 2009 Fabian Affolter - 6-1 - Updated to new upstream version 6 sugar-jukebox-11-3.fc13 ----------------------- * Mon Dec 14 2009 Peter Robinson - 11-3 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 538871 sugar-memorize-33-3.fc13 ------------------------ * Mon Dec 14 2009 Peter Robinson - 33-3 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539053 sugar-moon-10-3.fc13 -------------------- * Mon Dec 14 2009 Peter Robinson - 10-3 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539034 sugar-pippy-34-6.fc13 --------------------- * Mon Dec 14 2009 Peter Robinson - 34-6 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539103 sugar-playgo-5-4.fc13 --------------------- * Mon Dec 14 2009 Peter Robinson - 5-4 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539218 sugar-record-64-4.fc13 ---------------------- * Mon Dec 14 2009 Peter Robinson - 64-4 - Add buildreq gettext to fix build issues on F-12/rawhide - fixes # 539221 sysstat-9.0.6-2.fc13 -------------------- * Fri Dec 11 2009 Ivana Hutarova Varekova - 9.0.6-2 - fix the problem in get_nfs_mount_nr function ( iostat -n causes stack smashing) system-config-lvm-1.1.11-1.fc13 ------------------------------- * Mon Dec 14 2009 Marek Grac - 1.1.11 - Resolves: #455945 - resizing a lv results in the fstab entry being altered - Resolves: #475434 - removing swap entries from fstab - Resolves: #522200 - system-config-lvm crashes at startup system-config-printer-1.1.15-8.fc13 ----------------------------------- * Mon Dec 14 2009 Jiri Popelka 1.1.15-8 - Prevent traceback when cancel button in troubleshooter pressed (#546821). systemtap-1.0-3.fc13 -------------------- * Fri Dec 11 2009 Josh Stone - 1.0-3 - Rebuild against rpm-4.8.0 texinfo-4.13a-8.fc13 -------------------- * Mon Dec 14 2009 Vitezslav Crhonek - 4.13a-8 - Fix memory allocation bug when using old-style --section "Foo" arguments totem-pl-parser-2.28.2-1.fc13 ----------------------------- * Fri Dec 11 2009 Bastien Nocera 2.28.2-1 - Update to 2.28.2 tuned-0.2.7-1.fc13 ------------------ * Fri Dec 11 2009 Thomas Woerner 0.2.7-1 - Updated ktune to version 0.4-1 - Supports start and stop options in profile scripts calls - Fixed CMDLINE_ELEVATOR test (rhbz#496940#c9) util-linux-ng-2.17-0.6.fc13 --------------------------- * Mon Dec 14 2009 Karel Zak 2.17-0.6 - minor fixes in spec file (fix URL, add Requires, add LGPLv2+) vemana2000-fonts-1.1.2-1.fc13 ----------------------------- * Mon Dec 14 2009 - 1.1.2-1 - Fixed FSType, Preferred Styles, UniqueID and Fullname - Fixed Invalid Glyph Names reported by fontlint - with exceptions string added in License virt-manager-0.8.2-1.fc13 ------------------------- * Mon Dec 14 2009 Cole Robinson - 0.8.2-1.fc13 - Update to 0.8.2 release - Fix first virt-manager run on a new install - Enable floppy media eject/connect volume_key-0.3.1-1.fc13 ----------------------- * Fri Dec 11 2009 Miloslav Trma? - 0.3.1-1 - Update to volume_key-0.3.1. wv-1.2.7-1.fc13 --------------- * Fri Dec 11 2009 Rahul Sundaram - 1.2.7-1 - New upstream release that fixes a regression - Resolves rhbz#546406,546406 xine-lib-1.1.17-3.fc13 ---------------------- * Sat Dec 12 2009 Rex Dieter - 1.1.17-3 - bump flac_decoder priority (rh#301861,xine#225) xmltex-20020625-16.fc13 ----------------------- * Fri Dec 11 2009 Ondrej Vasik - 20020625-16 - Merge review(#226567) - fix buildroot, source0 location, do not zip readme.txt xorg-x11-util-macros-1.4.1-1.fc13 --------------------------------- * Mon Dec 14 2009 Adam Jackson 1.4.1-1 - util-macros 1.4.1 xterm-253-1.fc13 ---------------- * Fri Dec 11 2009 Miroslav Lichvar 253-1 - update to 253 Summary: Added Packages: 9 Removed Packages: 4 Modified Packages: 147 From kaboon at gmail.com Tue Dec 15 14:10:01 2009 From: kaboon at gmail.com (Eelko Berkenpies) Date: Tue, 15 Dec 2009 15:10:01 +0100 Subject: Yum "Cannot retrieve repository metadata" error In-Reply-To: <1260869563.2881.3.camel@localhost> References: <3f5430b30912150000v39fb1cdbob1d3116a1d0c7da5@mail.gmail.com> <1260869563.2881.3.camel@localhost> Message-ID: <3f5430b30912150610o6698e24ctee05f99230ee3630@mail.gmail.com> On Tue, Dec 15, 2009 at 10:32 AM, phenix wrote: > I have the same problem. This is what i do to solve it. > > edit /etc/hosts, add the following hosts > > 80.239.156.215 ? ? ? ? ?mirrors.fedoraproject.org > 152.46.7.222 ? ? ? ? ? ?download.fedoraproject.org > 209.132.183.67 ? ? ? ? ?download.fedora.redhat.com > > use baseurl instead of mirrorlist repos. > Thanks, that did the trick for me. Problem solved, I guess. :) -- With kind regards / Met vriendelijke groet, Eelko Berkenpies http://blog.berkenpies.nl/ From hun at n-dimensional.de Tue Dec 15 14:50:26 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 15 Dec 2009 15:50:26 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <20091215155026.424ab10e@n-dimensional.de> On Mon, 14 Dec 2009 19:21:19 -0800 Jesse Keating wrote: > pkgs/rpms//devel is now the git origin/master. All release > subdirs have been turned into git branches. History back to F7, as > well as the EPEL branches have been converted, from a snapshot of the > CVS tree I took last week. Will older history be available in the final "production" git repos? This might come in handy for the remaining merge reviews, or for historical purposes, or just be dead weight. I'm not sure which one. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hun at n-dimensional.de Tue Dec 15 14:57:08 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 15 Dec 2009 15:57:08 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215094921.GC29705@amd.home.annexia.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> Message-ID: <20091215155708.76eb7db3@n-dimensional.de> On Tue, 15 Dec 2009 09:49:21 +0000 "Richard W.M. Jones" wrote: > Also git remote branches are quite painful, requiring non-obvious > changes to .git/config or hard to use commands. I'd rather do this > once (for an everything-in-one-repository model) than for every single > package I maintain. I would presume that the to-be-written package handling tool (the code name is "fpkg" AFAIR) would set up local tracking branches when... uhm... needed (the exact triggers need to be worked out). It should work out to fpkg calling $ git branch F-$n origin/F-$n for appropriate values of $n, which is not much magic. -- Hans Ulrich Niedermann From hun at n-dimensional.de Tue Dec 15 15:01:41 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 15 Dec 2009 16:01:41 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215112452.6d69ebb3@dhcp03.addix.net> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215112452.6d69ebb3@dhcp03.addix.net> Message-ID: <20091215160141.71219b8a@n-dimensional.de> On Tue, 15 Dec 2009 11:24:52 +0100 Ralf Ertzinger wrote: > On Mon, 14 Dec 2009 19:21:19 -0800, Jesse Keating wrote: > > > In my effort to create a proof of concept for using git to manage > > our package source control, I have completed what I am calling > > phase one, that is taking our current dist-cvs and converting it > > into git format. > > That's just the naked content converted into git, right? All the > scripts/ Makefiles in it still assume that CVS is used and thus do > not do much? >From what I have read, the Makefiles will be killed off, and a newly (to be) written tool ("fpkg") will take over the job of the soon to be late Makefiles, and then some. -- Hans Ulrich Niedermann From hun at n-dimensional.de Tue Dec 15 15:17:50 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 15 Dec 2009 16:17:50 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <20091215161750.4182bf9d@n-dimensional.de> On Mon, 14 Dec 2009 19:21:19 -0800 Jesse Keating wrote: > git://publictest5.fedoraproject.org/git/pkgs/ > Give it a spin, see what you think. In two of "my" packages which go back some time (id3v2, soundtracker), there are two CVS commit "authors" which are not converted into proper names of the "Firstname Lastname " variety: "cvsextras" and "gafton". Both CVS authors get the default conversion to "$1 <$1>". Is this on purpose? -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Matt_Domsch at dell.com Tue Dec 15 15:31:39 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 15 Dec 2009 09:31:39 -0600 Subject: FUDConF13 videos Message-ID: <20091215153139.GA3091@auslistsprd01.us.dell.com> I've just posted 2 videos shot at FUDConF13 Toronto last week. I'm afraid I haven't done justice though... 1) Moksha, by Luke Macken. My camera cut out after the first 10 minutes, so that's all we've got. http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-moksha.ogg 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins vs. Developers love-in. I'm grateful to whoever shot this, but I've complete blanked on who it was now. I'll be glad to give you attribution, please remind me! http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg If anyone else has video or audio from this or other Fedora events you'd care to share, please contact me and I'll help you get it into proper ogg format, tagged, and posted to Fedora Infrastructure servers for distribution. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Tue Dec 15 15:36:47 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 15 Dec 2009 09:36:47 -0600 Subject: Yum "Cannot retrieve repository metadata" error In-Reply-To: <1260869563.2881.3.camel@localhost> References: <3f5430b30912150000v39fb1cdbob1d3116a1d0c7da5@mail.gmail.com> <1260869563.2881.3.camel@localhost> Message-ID: <20091215153647.GB3091@auslistsprd01.us.dell.com> On Tue, Dec 15, 2009 at 05:32:43PM +0800, phenix wrote: > I have the same problem. This is what i do to solve it. > > edit /etc/hosts, add the following hosts > > 80.239.156.215 mirrors.fedoraproject.org > 152.46.7.222 download.fedoraproject.org > 209.132.183.67 download.fedora.redhat.com > > use baseurl instead of mirrorlist repos. We've had some problems with DNS during the Fedora Infrastructure move, but these should be resolved now, eliminating the need to edit /etc/hosts or the yum .repo files. If you find you still have problems, please file a ticket with Fedora Infrastructure. https://fedorahosted.org/fedora-infrastructure/ Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bruno at wolff.to Tue Dec 15 16:38:31 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 15 Dec 2009 10:38:31 -0600 Subject: Wiki Feature Dashboard Additional Category In-Reply-To: <4B271470.9040004@redhat.com> References: <4B271470.9040004@redhat.com> Message-ID: <20091215163831.GA4063@wolff.to> On Mon, Dec 14, 2009 at 20:45:36 -0800, John Poelstra wrote: > > You have an interesting idea about tagging feature pages needing an > owner. In reality that pretty much represents all the pages in > 'Category:FeaturePageIncomplete' If they had an active owner or > developer working on the feature they wouldn't be there. Or they were just created and aren't ready to propose to FESCO just yet. (For example LZMA_for_Live_Images is waiting for proposed patches to 2.6.33 to actually be accepted by Linus before there is any point in asking FESCO to approve the Feature.) From nathanael at gnat.ca Tue Dec 15 16:50:58 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 15 Dec 2009 09:50:58 -0700 Subject: packages requiring me to reboot... Message-ID: <4B27BE72.5020002@gnat.ca> Hello, I feel like there are an increasing number of packages requiring a system reboot. I'm wondering why. The following updates were installed today, and required a full system reboot. I can't seem to find any package in the list that I can conceivably see requiring a reboot, is it that PK doesn't have the concept of X logout vs reboot? Is it a bug in the packaging or PK or is there anything I can do/file to improve the situation? Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 Wouldn't it be sufficient to logout? Is it a bug? -- Nathanael From pjones at redhat.com Tue Dec 15 16:54:29 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 15 Dec 2009 11:54:29 -0500 Subject: trouble with signals and skb_rec_datagram() In-Reply-To: References: <604aa7910912091124w65f2d0e4nfcd62013275a608e@mail.gmail.com> <604aa7910912141135o7bdca689s5ed96208fdf896f6@mail.gmail.com> Message-ID: <4B27BF45.8040707@redhat.com> It's likely that some people have not noticed this message because you replied to an unrelated thread instead of starting with a new message entirely. This is best avoided. On 12/14/2009 02:45 PM, William Reich wrote: > > Hello List... > > I am working on trying to port a LINUX kernel > driver from RedHat AS 4/5 to Fedora 11 & 12. Is this is a third-party driver that RH doesn't ship in RHEL? I'm going to assume it is, and respond with that in mind. It would probably be better to focus on porting it to the upstream kernel, and getting it submitted there. That helps a great deal to keep you from having to do this again -- when interfaces like skb_rec_datagram() change, the entire upstream kernel tends to get fixed along with the change. [...] > Does anyone know if the behavior of skb_rec_datagram() has changed > in the newer kernels ? Sounds like a question for linux-netdev rather than for fedora-devel. If you actually try to get your driver ready for upstream, the linux-netdev are likely to be quite helpful. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman From paul at dishone.st Tue Dec 15 16:54:07 2009 From: paul at dishone.st (Paul Jakma) Date: Tue, 15 Dec 2009 16:54:07 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091214190316.GD1094301@hiwaay.net> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> Message-ID: On Mon, 14 Dec 2009, Chris Adams wrote: > Have you actually shown any concrete benefits, or has it all just been > hand-waving? Well, the benefits were already known from the introduction of 64bit systems in the mid 90s. E.g. a rule of thumb with AXP systems was that they required at least 30% odd more RAM, compared to other Unix systems (either 32bit, or 32-userspace/64kernel systems - which is what most of the other Unix RISC vendors went with when they went to 64bit CPUs). E.g., a fresh F12 install: 32bit free -m: used +/- buffers/cache at gdm: 71 logged into desktop: 123 +firefox: 183 +OO writer: 203 64bit: at gdm: 113 logged in: 159 Unfortunately, I couldn't get the 64bit one past "logged in" and even then I couldn't get it to display a useful desktop (good bit of GNOME stuff was running, but nothing shown), so it's probably under-representative. That shows a 59% increase for "at GDM", and at least a 29% increase for "logged into desktop". However, to be fair, that's probably /over/-representing the difference, as I didn't do much with any applications. Pure data, like the contents of webpages, your email, etc.. doesn't contain arch-dependent variable width data like pointers. That said, attendent meta-data (e.g. mail indices, data structures for the layout of your rendered webpage, etc..) may have arch-dependent variable-width data. So I'd expect that that 60% figure would go down a bit if you really used the system. I would expect a memory increase, due to 64bit, of somewhere between 30 and 60%, depending on system - or a saving of between 23 to 38%. I can't do this test as running F12 x86-64 under Qemu is just too damn slow, even if did finish login successfully. If someone wants to replicate the above with KVM on x86_64: 1. Install F12 2. After the first boot, reboot again, to eliminate the run of 'firstboot' 3a. login via ssh 3b. login via GDM 4. start firefox 5. switch to the 2nd desktop 6. start oowriter Use the SSH session to note the memory usage with 'free -m' after steps 3b, 4 and 6. You may need to run the command a few times to wait for the usage to stabilise (it probably will spike and decrease again). For certain workloads, e.g. servers dealing in large numbers of instances of small amounts of data, 60% extra could be quite normal (or even low). It was in optimising memory usage for a BGP implementation where I personally noticed just how much bloody space those 64bit pointers can take up. ;) > If somebody shows real benefits (with real data to back it up), and is > willing to put forth the effort to make it work, it might be > interesting. All I'm saying is that it would be nice if: a) an x86_64 kernel was made a supported option for a 32bit Fedora (it pretty much works already) - i.e. its an additional kernel. b) yum grokked out of the box how to upgrade such systems (at the moment you have to tweak some file to make it think it's a 32bit system, and then kernel updates have to be done manually) I'm saying there is at least one very reasonable and rational reason for 32-on-64. I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: If you can't learn to do it well, learn to enjoy doing it badly. From skvidal at fedoraproject.org Tue Dec 15 16:54:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 15 Dec 2009 11:54:23 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B27BE72.5020002@gnat.ca> References: <4B27BE72.5020002@gnat.ca> Message-ID: On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: > Hello, > I feel like there are an increasing number of packages requiring a system > reboot. I'm wondering why. The following updates were installed today, and > required a full system reboot. I can't seem to find any package in the list > that I can conceivably see requiring a reboot, is it that PK doesn't have the > concept of X logout vs reboot? Is it a bug in the packaging or PK or is there > anything I can do/file to improve the situation? > > Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 > Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 > Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 > Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 > Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 > Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 > Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 > Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 > Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 > Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 > Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 > Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 > Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 > Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 > Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 > Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 > Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 > Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 > Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 > Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 > Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 > Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 > Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 > Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 > Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 > Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 > Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 > Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 > Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 > Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 > Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 > Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 > Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 > Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 > Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 > Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 > Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 > Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 > Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 > Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch > Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 > Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch > Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 > Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 > > Wouldn't it be sufficient to logout? Is it a bug? > Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. -sv From nathanael at gnat.ca Tue Dec 15 17:00:41 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 15 Dec 2009 10:00:41 -0700 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> Message-ID: <4B27C0B9.7060403@gnat.ca> On 12/15/2009 09:54 AM, Seth Vidal wrote: > Does gdm entirely restart when you logout? I don't believe so. I suspect > you get the same result by killing X then going back to that runlevel > but for many many many users a reboot is going to be less error-prone. Isn't there gdm-restart for that purpose? I don't really know, but I'm just confused as to why a program that lets me login requires a reboot... I *really* don't want to sound whiny or anything like that, or be one of those that compare us to windows... but one of my favorite things from years ago was that I only had to reboot with a new kernel. Now I feel like I reboot every update. I mean, even the ibus stuff was stating I needed a reboot. As far as I know that is used for alternative language input, which I don't use, fair enough it doesn't know that. But what about it needs a reboot? I'm also curious why gdm is still running once I've logged in. I see the user-switch stuff but I'm just wondering. I mean rebooting isn't the end of the world but man it sure happens a lot now From Matt_Domsch at dell.com Tue Dec 15 17:07:27 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 15 Dec 2009 11:07:27 -0600 Subject: FUDConF13 videos In-Reply-To: <20091215153139.GA3091@auslistsprd01.us.dell.com> References: <20091215153139.GA3091@auslistsprd01.us.dell.com> Message-ID: <20091215170727.GC3091@auslistsprd01.us.dell.com> On Tue, Dec 15, 2009 at 09:31:39AM -0600, Matt Domsch wrote: > 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins > vs. Developers love-in. I'm grateful to whoever shot this, but > I've complete blanked on who it was now. I'll be glad to give you > attribution, please remind me! > > http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg Of course, that was Adam Williamson who made this video. Thanks Adam! -Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From npajkovs at redhat.com Tue Dec 15 17:08:14 2009 From: npajkovs at redhat.com (Nikola Pajkovsky) Date: Tue, 15 Dec 2009 18:08:14 +0100 Subject: packages requiring me to reboot... In-Reply-To: <4B27C0B9.7060403@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> Message-ID: <4B27C27E.9030208@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 15.12.2009 18:00, Nathanael D. Noblet napsal(a): > On 12/15/2009 09:54 AM, Seth Vidal wrote: > >> Does gdm entirely restart when you logout? I don't believe so. I suspect >> you get the same result by killing X then going back to that runlevel >> but for many many many users a reboot is going to be less error-prone. > > Isn't there gdm-restart for that purpose? I don't really know, but I'm > just confused as to why a program that lets me login requires a reboot... > > I *really* don't want to sound whiny or anything like that, or be one of > those that compare us to windows... but one of my favorite things from > years ago was that I only had to reboot with a new kernel. Now I feel > like I reboot every update. I mean, even the ibus stuff was stating I > needed a reboot. As far as I know that is used for alternative language > input, which I don't use, fair enough it doesn't know that. But what > about it needs a reboot? > > I'm also curious why gdm is still running once I've logged in. I see the > user-switch stuff but I'm just wondering. I mean rebooting isn't the end > of the world but man it sure happens a lot now > +1 - -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: nikis at isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJ8J+AAoJED4+/Vgo+H2XtUsIAIzOIdfL5OVS92bLJvFe9Vny RCGKnlnG2TkEztpNZPu0AyU8nNOxAmH5+w+uAmvEpD6jmh5F7QlrSVTJLSamL76G fjWmeuz+4EreSSKwhemlbr7p6vB/CxPkIcivOVYK4OscI7LwJGAQTK74661QvoWr 9BXAP+Wd3KaNere3Ckg4iamSwBDLjSf2fVmVUJjGL4CYnX/mJVnWm7V7VnHy0Rgr lvM9fBUiJAuhOEH5xYScdTdmHmcefDfia1PmlMPVmG7mHlrIxXRF04KhyIJlwirK nEj6mXQk2m0M+KO6zBoV78ROgY4xYk/RmyYbT8icOeojH12pJgo1KZWQ+89iPkI= =Qe52 -----END PGP SIGNATURE----- From debarshi.ray at gmail.com Tue Dec 15 17:10:01 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 15 Dec 2009 19:10:01 +0200 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> Message-ID: <3170f42f0912150910t3b712e92ta14f9320920fca1@mail.gmail.com> > I personally think the model used by many Unixes from the 90s makes a lot of > sense - 32bit userpace by default, 64bit kernel, 64bit for a select few > applications that actually need the benefits of x86_64 (memory/bit more > performance), but hey.. Assuming this was the case and somebody decided to install (say) a 64 bit Epiphany then she will end up with two copies of the entire GNOME stack. That will come with its own storage and network costs, among other things. Running the 64-bit Epiphany will cause two copies of shared libraries to be kept in memory. Is this really worth it? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From deadbabylon at googlemail.com Tue Dec 15 17:17:01 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Tue, 15 Dec 2009 18:17:01 +0100 Subject: KDE-SIG weekly report (51/2009) Message-ID: <200912151817.10649.deadbabylon@googlemail.com> 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: 51/2009 Time: 2009-12-15 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-15 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-15/fedora-meeting.2009-12-15-14.08.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-15/fedora-meeting.2009-12-15-14.08.log.html ---------------------------------------------------------------------------------- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * RexDieter * SebastianVahl * ThanNgo ---------------------------------------------------------------------------------- = Agenda = * kde-4.3.4 status * KDE Rebranding * multilibbing KCMs, i.e. putting them into the -libs subpackages (KCMs can be embedded into applications; if embedded into a 32-bit app, the 32-bit KCM is needed) = Summary = KDE 4.3.4 status: * Update for F-12 will be queued for updates-testing asap. [1] * LukasTinkl was working on updates for F-11. * Early adopters could use kde-testing (at kde-redhat) in the meantime. KDE Rebranding (#547361): [2] * Since upstream proposed a rebranding we have to adopt the new name at various places: o SPECs (JaroslavReznik, RexDieter, ThanNgo) o comps.xml o Wiki (JaroslavReznik) o Spins page (JaroslavReznik) multilibbing KCMs: * KCMs (KDE Configuration Modules, used in System Settings and in the preferences of some applications) will be moved to the -libs subpackages so 32-bit multilibs will be provided. * KParts will need a similar treatment. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-22 ---------------------------------------------------------------------------------- = Links = [1] http://tinyurl.com/kde434-f12-2 [2] https://bugzilla.redhat.com/show_bug.cgi?id=547361 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Dec 15 17:19:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:19:25 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260874519.6151.179.camel@tonnant> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <1260874519.6151.179.camel@tonnant> Message-ID: <1260897565.21725.38.camel@localhost.localdomain> On Tue, 2009-12-15 at 05:55 -0500, Jon Masters wrote: > > Can you explain the tags a little Jesse? > > e.g. > F-12-split > F-12-start > > I have absolutely no interest in the idea of doing one giant tree btw, > though I doubt that will ever get serious traction :) Also, on the > subject of branches, can you include a summary of branches too? There are two types of tags that exist. Tags that reflect when CVS "branches" were made, and tags that reflect the "make tag" action of a maintainer, presumably as part of a build process. F-12-split is a tag that indicates at what point the "F-12" directory on the CVS server was created, and on the F-12 branch there would be an 'F-12-start' tag as well. The build tags exist on whichever branch they were made from. As for branches, there are 2 kinds of branches. One kind has the form of "F-12" or "EL-5" and that reflects the CVS directory in dist-cvs. These are generated by infrastructure, and it will likely not be possible to create branches in this form in git by yourself. The other kind of branch is private-* type branches, which were real CVS branches that allowed developers to work on stuff without messing up HEAD. We'll likely continue to allow remote branches of a specific pretext, such as private- if you wish to work with multiple people on a branch. Otherwise git allows you infinite number of local branches to do your work. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 17:25:41 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:25:41 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215094921.GC29705@amd.home.annexia.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> Message-ID: <1260897941.21725.44.camel@localhost.localdomain> On Tue, 2009-12-15 at 09:49 +0000, Richard W.M. Jones wrote: > > Why not put everything in a single git repository? The cost to clone that repo would be enormous. The kernel alone is 57M once cloned, 44 megs across the wire. > > Also git remote branches are quite painful, requiring non-obvious > changes to .git/config or hard to use commands. I'd rather do this > once (for an everything-in-one-repository model) than for every single > package I maintain. Why would you have to do anything special? Our helper script can check things out for you in a way that git pull/push/whatever does the right thing by tracking the upstream branch. You shouldn't have to touch your .git/config at all. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 17:28:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:28:01 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215111122.GC9297@redhat.com> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <1260871602.2489.0.camel@localhost.localdomain> <20091215103404.GA29955@amd.home.annexia.org> <20091215105005.GF16448@hansolo.jdub.homelinux.org> <20091215105952.GB29955@amd.home.annexia.org> <20091215111122.GC9297@redhat.com> Message-ID: <1260898081.21725.45.camel@localhost.localdomain> On Tue, 2009-12-15 at 11:11 +0000, Daniel P. Berrange wrote: > > I was wondering if you could set up some meta repository, which had a > GIT sub-module for each package, but it seems sub-modules always have > to specify an explicit commit hash so they wouldn't seemlessly follow > changes. I briefly looked at submodule stuff, but it really isn't in a shape we can easily use. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Dec 15 17:38:02 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 15 Dec 2009 12:38:02 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B27C0B9.7060403@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> Message-ID: On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: > On 12/15/2009 09:54 AM, Seth Vidal wrote: > >> Does gdm entirely restart when you logout? I don't believe so. I suspect >> you get the same result by killing X then going back to that runlevel >> but for many many many users a reboot is going to be less error-prone. > > Isn't there gdm-restart for that purpose? I don't really know, but I'm just > confused as to why a program that lets me login requires a reboot... > > I *really* don't want to sound whiny or anything like that, or be one of > those that compare us to windows... but one of my favorite things from years > ago was that I only had to reboot with a new kernel. Now I feel like I reboot > every update. I mean, even the ibus stuff was stating I needed a reboot. As > far as I know that is used for alternative language input, which I don't use, > fair enough it doesn't know that. But what about it needs a reboot? > > I'm also curious why gdm is still running once I've logged in. I see the > user-switch stuff but I'm just wondering. I mean rebooting isn't the end of > the world but man it sure happens a lot now I don't have a good answer. You might want to ask on the fedora-desktop-list and/or in a bug for that component. I was just trying to explain the specific behavior you saw. Now, having said that - how would you feel if the updater stopped you before it ran and said "you're running an app I'm trying to update, please close the app so I can update it". Would that be a pain or ok? -sv From jkeating at redhat.com Tue Dec 15 17:37:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:37:23 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215155708.76eb7db3@n-dimensional.de> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> Message-ID: <1260898643.21725.54.camel@localhost.localdomain> On Tue, 2009-12-15 at 15:57 +0100, Hans Ulrich Niedermann wrote: > I would presume that the to-be-written package handling tool (the > code name is "fpkg" AFAIR) would set up local tracking branches > when... > uhm... needed (the exact triggers need to be worked out). It should > work > out to fpkg calling > > $ git branch F-$n origin/F-$n > > for appropriate values of $n, which is not much magic. Right. fpkg checkout --full kernel that would give you kernel/devel kernel/F-12 kernel/F-11 etc... where each of those subdirs map to the appropriate origin/F-1? (or in the case of devel, to origin/master). Any git push/pull from those dirs would do the right thing. fpkg checkout kernel that would just get you kernel/ and in that directory would be the .spec and all the other stuff. It would be the origin/master. From there if you did: fpkg checkout F-12 It would essentially do a "git checkout -b F-12 --track origin/F-12" (unless the local F-12 branch already existed). So again push/pull would do the right thing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Tue Dec 15 17:40:01 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 15 Dec 2009 17:40:01 +0000 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> Message-ID: <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> 2009/12/15 Seth Vidal : > Now, having said that - how would you feel if the updater stopped you before > it ran and said "you're running an app I'm trying to update, please close > the app so I can update it". Would that be a pain or ok? That's exactly the PackageKit functionality I've added for packages like firefox, that explode internally when they get updated. The trick it to offer to close them down, and bring them back when done. Richard. From stefan at seekline.net Tue Dec 15 17:40:47 2009 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Tue, 15 Dec 2009 18:40:47 +0100 Subject: packages requiring me to reboot... In-Reply-To: <4B27C0B9.7060403@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> Message-ID: <1260898847.14369.31.camel@localhost> On Tue, 2009-12-15 at 10:00 -0700, Nathanael D. Noblet wrote: > On 12/15/2009 09:54 AM, Seth Vidal wrote: > > > Does gdm entirely restart when you logout? I don't believe so. I suspect > > you get the same result by killing X then going back to that runlevel > > but for many many many users a reboot is going to be less error-prone. > > Isn't there gdm-restart for that purpose? I don't really know, but I'm > just confused as to why a program that lets me login requires a reboot... > > I *really* don't want to sound whiny or anything like that, or be one of > those that compare us to windows... but one of my favorite things from > years ago was that I only had to reboot with a new kernel. Now I feel > like I reboot every update. I mean, even the ibus stuff was stating I > needed a reboot. As far as I know that is used for alternative language > input, which I don't use, fair enough it doesn't know that. But what > about it needs a reboot? Because often you cannot tell if a reboot is required or not. Consider a shared library which gets updated. If the old version of the library contains a security bug and you have already say ten apps running using that library, then after the update of the library the apps will still use the old buggy library. Only after closing and restarting the particular apps will help. From a novice point of view you cannot expect that he/she knows what app to close, so a restart is probably the easiest and safest way. Another problem may raise up if you want to update daemons. During the update the daemon shouldn't be restarted because it might be a critical service I'm using right now. Therefore, having a convenient way for novices is just to say "please restart". For all others, just check what gets updated and then decide on your own if you really need to restart the whole system or only some apps/services and then klick on "hide this icon" ;-) Coming back to your fist post: > Wouldn't it be sufficient to logout? In some cases I would say so, but not in all. cheers, Stefan From frankly3d at gmail.com Tue Dec 15 17:41:27 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3D)) Date: Tue, 15 Dec 2009 17:41:27 +0000 Subject: packages requiring me to reboot... In-Reply-To: <4B27BE72.5020002@gnat.ca> References: <4B27BE72.5020002@gnat.ca> Message-ID: <4B27CA47.3060802@gmail.com> On 15/12/09 16:50, Nathanael D. Noblet wrote: > Hello, > I feel like there are an increasing number of packages requiring a > system reboot. I'm wondering why. The following updates were installed > today, and required a full system reboot. I can't seem to find any > package in the list that I can conceivably see requiring a reboot, is it > that PK doesn't have the concept of X logout vs reboot? Is it a bug in > the packaging or PK or is there anything I can do/file to improve the > situation? > > Personally, I just update, ignore the "restart". Shut-down going to bed. Or keep the updates, till bedtime. -- Regards, Frank Murphy UTF_8 Encoded. From jkeating at redhat.com Tue Dec 15 17:40:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:40:44 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215112452.6d69ebb3@dhcp03.addix.net> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215112452.6d69ebb3@dhcp03.addix.net> Message-ID: <1260898844.21725.55.camel@localhost.localdomain> On Tue, 2009-12-15 at 11:24 +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 14 Dec 2009 19:21:19 -0800, Jesse Keating wrote: > > > In my effort to create a proof of concept for using git to manage our > > package source control, I have completed what I am calling phase one, > > that is taking our current dist-cvs and converting it into git format. > > That's just the naked content converted into git, right? All the scripts/ > Makefiles in it still assume that CVS is used and thus do not do much? > That is correct. This is just phase 1, getting the CVS content into git format. As Hans replied, the Makefiles will be going away, and fpkg will be written to take over that job. I hope to have a framework for fpkg up in the next few days to allow people to start hacking on it with me. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Dec 15 17:42:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 15 Dec 2009 12:42:31 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> Message-ID: On Tue, 15 Dec 2009, Richard Hughes wrote: > 2009/12/15 Seth Vidal : >> Now, having said that - how would you feel if the updater stopped you before >> it ran and said "you're running an app I'm trying to update, please close >> the app so I can update it". Would that be a pain or ok? > > That's exactly the PackageKit functionality I've added for packages > like firefox, that explode internally when they get updated. The trick > it to offer to close them down, and bring them back when done. > this is what colin and I talked about at fudcon in toronto. I just added some code to yum so it returns to you a list of all pkgs on the system that own a file that is currently open/used in a running process. should make that part of your lookup easier. YumBase.rpmdb.return_running_packages() -sv From walters at verbum.org Tue Dec 15 17:43:56 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 15 Dec 2009 17:43:56 +0000 Subject: packages requiring me to reboot... In-Reply-To: <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 5:40 PM, Richard Hughes wrote: > 2009/12/15 Seth Vidal : >> Now, having said that - how would you feel if the updater stopped you before >> it ran and said "you're running an app I'm trying to update, please close >> the app so I can update it". Would that be a pain or ok? > > That's exactly the PackageKit functionality I've added for packages > like firefox, that explode internally when they get updated. The trick > it to offer to close them down, and bring them back when done. > This exists? Can you point me to the code? From jkeating at redhat.com Tue Dec 15 17:44:55 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:44:55 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <4B276FBF.9030500@gmail.com> References: <1260847279.21725.3.camel@localhost.localdomain> <4B276FBF.9030500@gmail.com> Message-ID: <1260899095.21725.57.camel@localhost.localdomain> On Tue, 2009-12-15 at 12:15 +0100, Ha?kel Gu?mar wrote: > Do you have any plan about hooks ? > Since 1 package = 1 repository, does that mean package maintainers > will > be able to define their own hooks ? (bad idea) will we have some > pre-defined hooks (like bz integration) ? or something like github > webhooks or bitbucket brokers ? > > We'll definitely have some mandatory hooks. The first one we're looking at is a hook to do branch level ACLs. Also, I seem to recall that you would need shell access to the remote repo in order to add a hook, so it would not be possible for maintainers to add their own remote hooks. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 17:47:48 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:47:48 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215155026.424ab10e@n-dimensional.de> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155026.424ab10e@n-dimensional.de> Message-ID: <1260899268.21725.60.camel@localhost.localdomain> On Tue, 2009-12-15 at 15:50 +0100, Hans Ulrich Niedermann wrote: > Will older history be available in the final "production" git repos? > This might come in handy for the remaining merge reviews, or for > historical purposes, or just be dead weight. I'm not sure which one. I had originally wanted to import history from FC1 forward, but when I thought some more about it, the FC-1 through FC-6 branches wouldn't share a common history with the origin/master made from the external dist-cvs. That would make importing the FC-1~6 stuff rather more difficult. I /might/ be able to do something with a graph point but I honestly haven't looked very hard. If anybody is interested... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 17:50:04 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 09:50:04 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215161750.4182bf9d@n-dimensional.de> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> Message-ID: <1260899404.21725.62.camel@localhost.localdomain> On Tue, 2009-12-15 at 16:17 +0100, Hans Ulrich Niedermann wrote: > > In two of "my" packages which go back some time (id3v2, soundtracker), > there are two CVS commit "authors" which are not converted into proper > names of the "Firstname Lastname " variety: "cvsextras" and > "gafton". > > Both CVS authors get the default conversion to "$1 <$1>". > > Is this on purpose? Ah, yes, there are going to be a few authors missed. The conversion script just looks for a cvs author name in a file, and that file expands that author name out to "Full Name ". The file I have now is not 100% complete, there are some newer offerings from folks that have more data from FAS but I suspect there will be a few names I'll have to add manually. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ottohaliburton at tx.rr.com Tue Dec 15 18:01:35 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Tue, 15 Dec 2009 12:01:35 -0600 Subject: packages requiring me to reboot... In-Reply-To: Message-ID: <0EFA3F7A814C487CB496D7B86522A2E8@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Colin Walters > Sent: Tuesday, December 15, 2009 11:44 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > On Tue, Dec 15, 2009 at 5:40 PM, Richard Hughes > wrote: > > 2009/12/15 Seth Vidal : > >> Now, having said that - how would you feel if the updater stopped you > before > >> it ran and said "you're running an app I'm trying to update, please > close > >> the app so I can update it". Would that be a pain or ok? > > > > That's exactly the PackageKit functionality I've added for packages > > like firefox, that explode internally when they get updated. The trick > > it to offer to close them down, and bring them back when done. > > > This exists? Can you point me to the code? > > -- I am not sure what the argument is, factually there are packages that have files open, locks and etc. that need to be shutdown to update, if they are running and you replace the executable, doesn't mean that the memory image is replaced. It is quicker and simpler to just reboot, also the list of the packages that cause you to reboot is probably longer than the ones that are flagged. I think that a reboot should be made whether necessary or not, clears up a lot of grief. > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From schwab at redhat.com Tue Dec 15 18:01:54 2009 From: schwab at redhat.com (Andreas Schwab) Date: Tue, 15 Dec 2009 19:01:54 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260899404.21725.62.camel@localhost.localdomain> (Jesse Keating's message of "Tue, 15 Dec 2009 09:50:04 -0800") References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> <1260899404.21725.62.camel@localhost.localdomain> Message-ID: Jesse Keating writes: > Ah, yes, there are going to be a few authors missed. The conversion > script just looks for a cvs author name in a file, and that file expands > that author name out to "Full Name ". There are also author names that where expanded to "user ". Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From tmz at pobox.com Tue Dec 15 18:08:16 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 15 Dec 2009 13:08:16 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> <1260899404.21725.62.camel@localhost.localdomain> Message-ID: <20091215180816.GT5004@inocybe.localdomain> Andreas Schwab wrote: > There are also author names that where expanded to "user > ". These are for accounts that have set the private flag, so their name and other data is not available. (Nevermind that they end up putting a name in the rpm changelog most of the time.) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ambition is a poor excuse for not having enough sense to be lazy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at redhat.com Tue Dec 15 18:08:03 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 10:08:03 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> <1260899404.21725.62.camel@localhost.localdomain> Message-ID: <1260900483.21725.65.camel@localhost.localdomain> On Tue, 2009-12-15 at 19:01 +0100, Andreas Schwab wrote: > > There are also author names that where expanded to "user > ". > > Yeah, that might be a privacy thing, not sure if full name can be hidden behind the privacy shield, we might not be able to get to them. That data will be coming from FAS. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Tue Dec 15 18:16:52 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 15 Dec 2009 13:16:52 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260898643.21725.54.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> Message-ID: <20091215181652.GU5004@inocybe.localdomain> Jesse Keating wrote: > fpkg checkout --full kernel > > that would give you kernel/devel kernel/F-12 kernel/F-11 etc... > where each of those subdirs map to the appropriate origin/F-1? (or > in the case of devel, to origin/master). Any git push/pull from > those dirs would do the right thing. I'd like to suggest (again ;) that origin/devel be used. Either that, or use master as the local dir, e.g. kernel/master. Having it differ seems like a recipe for unneeded confusion. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I figure that if God actually does exist, He's big enough to understand an honest difference of opinion. -- Isaac Asimov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at j2solutions.net Tue Dec 15 18:22:35 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 15 Dec 2009 10:22:35 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215181652.GU5004@inocybe.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> Message-ID: <1260901355.21725.67.camel@localhost.localdomain> On Tue, 2009-12-15 at 13:16 -0500, Todd Zullinger wrote: > > I'd like to suggest (again ;) that origin/devel be used. Either that, > or use master as the local dir, e.g. kernel/master. Having it differ > seems like a recipe for unneeded confusion. > > I'm willing to listen to other opinions on this. Personally I'd really rather not change the meaning of origin/master. "devel" would show up as a directory in the "classic" view only to match what CVS did. I'd even be willing to make two directories, one a symlink to the other. You'd get kernel/master and you'd also get kernel/devel as a symlink to kernel/master -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Dec 15 18:24:46 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 Dec 2009 19:24:46 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260900483.21725.65.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> <1260899404.21725.62.camel@localhost.localdomain> <1260900483.21725.65.camel@localhost.localdomain> Message-ID: <1260901486.11017.1.camel@arekh.okg> BTW, please make sure the new system has something like cvs-import (ie "put the files in this srpm as new changeset in the vcs, I don't want to know how your vcs works, this is a good srpm just eat it") -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Tue Dec 15 18:27:35 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 Dec 2009 19:27:35 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> Message-ID: <1260901655.11017.3.camel@arekh.okg> Le mardi 15 d?cembre 2009 ? 16:54 +0000, Paul Jakma a ?crit : > I personally think the model used by many Unixes from the 90s makes a > lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a > select few applications that actually need the benefits of x86_64 > (memory/bit more performance), but hey.. Apples and oranges. 64bit on other arches only changes memory accesses, x86_64 changes a lot more than just that, and the other changes in x86_64 trump the memory costs. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Tue Dec 15 18:29:25 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Dec 2009 13:29:25 -0500 Subject: packages requiring me to reboot... In-Reply-To: <4B27C0B9.7060403@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> Message-ID: <20091215182924.GB3077@nostromo.devel.redhat.com> Nathanael D. Noblet (nathanael at gnat.ca) said: > I'm also curious why gdm is still running once I've logged in. When you start a display manager, you start an X server; the display manager then draws on this. Then, when you log in, you have to stat an user session, as the authenticated user (which has a connection to the X server, so it can know when it goes away.) You also have to tell the init daemon which process it's supposed to be tracking, so it can respawn it when it exits. Having that process be the gdm daemon (which forks and execs both the X server and the user session) is arguably a lot simpler than trying to architect it such that the daemon goes away entirely and init then ends up tracking either the X serve or the user session. Bill From tmz at pobox.com Tue Dec 15 18:33:12 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 15 Dec 2009 13:33:12 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260901355.21725.67.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> Message-ID: <20091215183312.GV5004@inocybe.localdomain> Jesse Keating wrote: > I'm willing to listen to other opinions on this. Personally I'd > really rather not change the meaning of origin/master. "devel" > would show up as a directory in the "classic" view only to match > what CVS did. I'd even be willing to make two directories, one a > symlink to the other. You'd get kernel/master and you'd also get > kernel/devel as a symlink to kernel/master My thinking is that we don't use origin/next or origin/maint either and both are common upstream in git and the kernel. While origin/master is common, for our use, 'git push origin devel' (or rawhide) makes more sense as it matches the use for other branches, git push origin F-12. There's nothing magical or required about using master as the main branch. Whether other users will be more confused by the incongruity of master versus devel or that it differs from what they think git may require, I don't know. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A thing worth having is a thing worth cheating for. -- W. C. Fields -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at redhat.com Tue Dec 15 18:42:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 10:42:16 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260901486.11017.1.camel@arekh.okg> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215161750.4182bf9d@n-dimensional.de> <1260899404.21725.62.camel@localhost.localdomain> <1260900483.21725.65.camel@localhost.localdomain> <1260901486.11017.1.camel@arekh.okg> Message-ID: <1260902536.21725.68.camel@localhost.localdomain> On Tue, 2009-12-15 at 19:24 +0100, Nicolas Mailhot wrote: > BTW, please make sure the new system has something like cvs-import (ie > "put the files in this srpm as new changeset in the vcs, I don't want > to > know how your vcs works, this is a good srpm just eat it") Yep, that functionality would continue to exist. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 15 18:45:54 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 10:45:54 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215183312.GV5004@inocybe.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215183312.GV5004@inocybe.localdomain> Message-ID: <1260902754.21725.71.camel@localhost.localdomain> On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: > > My thinking is that we don't use origin/next or origin/maint either > and both are common upstream in git and the kernel. > > While origin/master is common, origin/master isn't "common", it's the friggin default. Every single git repo I interact with has development happening on origin/master. It's way more than just "common". > for our use, 'git push origin devel' (or > rawhide) makes more sense as it matches the use for other branches, > git push origin F-12. There's nothing magical or required about using > master as the main branch. If our maintainer has to type that out, i think we've failed the conversion. The thought here is that you'd be doing "git push" and stuff will just happen right. But /if/ you wanted to do things manually then it should match just about every other git repo out there, where the main branch is origin/master > > Whether other users will be more confused by the incongruity of master > versus devel or that it differs from what they think git may require, > I don't know. Yep, it's an opinion thing :/ -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dcantrell at redhat.com Tue Dec 15 19:03:04 2009 From: dcantrell at redhat.com (David Cantrell) Date: Tue, 15 Dec 2009 09:03:04 -1000 (HST) Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: On Mon, 14 Dec 2009, Jesse Keating wrote: > In my effort to create a proof of concept for using git to manage our > package source control, I have completed what I am calling phase one, > that is taking our current dist-cvs and converting it into git format. > > pkgs/rpms//devel is now the git origin/master. All release > subdirs have been turned into git branches. History back to F7, as well > as the EPEL branches have been converted, from a snapshot of the CVS > tree I took last week. Having trouble cloning at the moment, but wanting to take a look at a few packages in git. Are there any plans to import history back to FC-1? Since we're changing version control systems, it's a nice opportunity to get this in to the version control system. Complete history is nice to have on occassion. > Currently I only have anonymous git:// access setup, as we play with > some options for authenticated writing. If you wish to play around with > the repos, you can access it via: > > git://publictest5.fedoraproject.org/git/pkgs/ eg if you wished > to clone the kernel, you'd type: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel > > Give it a spin, see what you think. -- David Cantrell Red Hat / Honolulu, HI From ville.skytta at iki.fi Tue Dec 15 19:23:15 2009 From: ville.skytta at iki.fi (Ville =?windows-1252?q?Skytt=E4?=) Date: Tue, 15 Dec 2009 21:23:15 +0200 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260898643.21725.54.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> Message-ID: <200912152123.15918.ville.skytta@iki.fi> On Tuesday 15 December 2009, Jesse Keating wrote: > fpkg checkout --full kernel > fpkg checkout kernel > fpkg checkout F-12 The first two Google hits I get for fpkg are already two different tools that have something to do with software packaging, so I suggest not adding the third but coming up with some other name for this one. http://foxlx.acmesystems.it/?id=157 http://www.freshports.org/sysutils/fpkg/ From cmadams at hiwaay.net Tue Dec 15 19:32:54 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 15 Dec 2009 13:32:54 -0600 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <200912152123.15918.ville.skytta@iki.fi> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <200912152123.15918.ville.skytta@iki.fi> Message-ID: <20091215193254.GD1238825@hiwaay.net> Once upon a time, Ville Skytt? said: > The first two Google hits I get for fpkg are already two different tools that > have something to do with software packaging, so I suggest not adding the > third but coming up with some other name for this one. fedpak fpak -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jcm at redhat.com Tue Dec 15 19:49:49 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 15 Dec 2009 14:49:49 -0500 Subject: FUDConF13 videos In-Reply-To: <20091215153139.GA3091@auslistsprd01.us.dell.com> References: <20091215153139.GA3091@auslistsprd01.us.dell.com> Message-ID: <1260906589.6151.345.camel@tonnant> On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote: > If anyone else has video or audio from this or other Fedora events > you'd care to share, please contact me and I'll help you get it into > proper ogg format, tagged, and posted to Fedora Infrastructure servers > for distribution. You rock :) Jon. From jcm at redhat.com Tue Dec 15 19:57:51 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 15 Dec 2009 14:57:51 -0500 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> Message-ID: <1260907071.6151.360.camel@tonnant> On Tue, 2009-12-15 at 16:54 +0000, Paul Jakma wrote: > On Mon, 14 Dec 2009, Chris Adams wrote: > > > Have you actually shown any concrete benefits, or has it all just been > > hand-waving? > > Well, the benefits were already known from the introduction of 64bit > systems in the mid 90s. E.g. a rule of thumb with AXP systems was > that they required at least 30% odd more RAM, compared to other Unix > systems (either 32bit, or 32-userspace/64kernel systems - which is > what most of the other Unix RISC vendors went with when they went to > 64bit CPUs). But again, Apples to Oranges. x86_64 (we should formally call it "Intel 64", or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. Not that any of it matters when we're already creeping up the minimum memory requirements over time and not so interested in older hardware anyway (e.g. recent i586/i686 changes). I know not everyone is living in the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. I think we should treat it like migrating to i686 and once everyone has a 64-bit capable (x86) CPU just plan to do a gradual migration over. Jon. From cmadams at hiwaay.net Tue Dec 15 20:24:59 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 15 Dec 2009 14:24:59 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <1260907071.6151.360.camel@tonnant> References: <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: <20091215202459.GE1238825@hiwaay.net> Once upon a time, Jon Masters said: > But again, Apples to Oranges. x86_64 (we should formally call it "Intel > 64", or similar, since I'm not aware of x86_64 having a formal blessing) "Intel 64" has no "formal blessing" either (it is Intel's marketing name for their copy of AMD's instruction set). If you want to call it after a vendor, it should be "AMD 64" anyway, since AMD created it. They called it "x86-64" (which is where the "x86_64" name came from), until marketing got in the way and they changed to "AMD 64". "Intel 64" is confusing anyway, since Intel has pushed multiple 64 bit architectures. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Tue Dec 15 20:27:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 12:27:44 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215193254.GD1238825@hiwaay.net> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <200912152123.15918.ville.skytta@iki.fi> <20091215193254.GD1238825@hiwaay.net> Message-ID: <1260908864.21725.72.camel@localhost.localdomain> On Tue, 2009-12-15 at 13:32 -0600, Chris Adams wrote: > Once upon a time, Ville Skytt? said: > > The first two Google hits I get for fpkg are already two different tools that > > have something to do with software packaging, so I suggest not adding the > > third but coming up with some other name for this one. > > fedpak > fpak > Either of those works for me. I hadn't actually done any looking around for "fpkg" uses. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From benny+usenet at amorsen.dk Tue Dec 15 20:30:50 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 15 Dec 2009 21:30:50 +0100 Subject: MariaDB and Fedora In-Reply-To: <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> (Nathanael Noblet's message of "Sun, 13 Dec 2009 20:56:38 -0700") References: <20091210130109.51db0e6b@redhat.com> <4B226DF4.9020603@conversis.de> <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> Message-ID: Nathanael Noblet writes: > However the setup/configuration of postgreSQL compared to MySQL is > basically something easy, versus something where I don't have a clue > what is going on, and there are million ways to do it, and when I'm > done I have no idea if I'm wide open to the entire world, or as secure > as on MySQL. We're on a Fedora list here. Setting up PostgreSQL consists of doing yum install postgresql-server, chkconfig postgresql on, service postgresql start. That will give you an installation with quite reasonable defaults including Unix-socket connectivity. Of course then you discover all the PHP toys written for MySQL which can't be told to connect a) by Unix sockets and b) without a username and password. /Benny From a.badger at gmail.com Tue Dec 15 20:35:16 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Dec 2009 12:35:16 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260901355.21725.67.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> Message-ID: <20091215203516.GF3259@clingman.lan> On Tue, Dec 15, 2009 at 10:22:35AM -0800, Jesse Keating wrote: > On Tue, 2009-12-15 at 13:16 -0500, Todd Zullinger wrote: > > > > I'd like to suggest (again ;) that origin/devel be used. Either that, > > or use master as the local dir, e.g. kernel/master. Having it differ > > seems like a recipe for unneeded confusion. > > > > > > I'm willing to listen to other opinions on this. Personally I'd really > rather not change the meaning of origin/master. "devel" would show up > as a directory in the "classic" view only to match what CVS did. I'd > even be willing to make two directories, one a symlink to the other. > You'd get kernel/master and you'd also get kernel/devel as a symlink to > kernel/master > master makes a lot of sense from a git perspective. devel (or rawhide) makes sense from what we actually call the code that that branch eventually makes. A symlink might alleviate the confusion but it could also add to it. (For instance, I was operating in the kernel/devel branch but when I want to git checkout -b devel git gives me a strange error.) I don't see a clear answer for what's best here, yet. :-( -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lvillani at binaryhelix.net Tue Dec 15 20:39:23 2009 From: lvillani at binaryhelix.net (Lorenzo Villani) Date: Tue, 15 Dec 2009 21:39:23 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260858838.21725.16.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <1260858838.21725.16.camel@localhost.localdomain> Message-ID: <200912152139.30545.lvillani@binaryhelix.net> On Tuesday 15 December 2009 07:33:58 Jesse Keating wrote: > > Right now? Not all that hard. You'd have to write a script that has > all the package names and just cycles over them cloning them one by one. > Once we start working on fpkg we'll likely wire something up that gets a > list of active packages from pkgdb and does the cycle for you. It'd > just be slow. > What about a 'meta-module' referencing all packages using git submodules? -- Lorenzo Villani -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From lvillani at binaryhelix.net Tue Dec 15 20:42:59 2009 From: lvillani at binaryhelix.net (Lorenzo Villani) Date: Tue, 15 Dec 2009 21:42:59 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <200912152139.30545.lvillani@binaryhelix.net> References: <1260847279.21725.3.camel@localhost.localdomain> <1260858838.21725.16.camel@localhost.localdomain> <200912152139.30545.lvillani@binaryhelix.net> Message-ID: <200912152142.59673.lvillani@binaryhelix.net> Already discussed later in thread. Sorry for unnecessary noise. -- Lorenzo Villani -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From davej at redhat.com Tue Dec 15 20:49:44 2009 From: davej at redhat.com (Dave Jones) Date: Tue, 15 Dec 2009 15:49:44 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260850929.21725.10.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> Message-ID: <20091215204943.GA10163@redhat.com> On Mon, Dec 14, 2009 at 08:22:09PM -0800, Jesse Keating wrote: > On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel > > This was the wrong path: > > git clone git://publictest5.fedoraproject.org/pkgs/kernel I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. Dave From john.owen.nixon at gmail.com Tue Dec 15 20:50:10 2009 From: john.owen.nixon at gmail.com (John Nixon) Date: Tue, 15 Dec 2009 20:50:10 +0000 Subject: Yum "Cannot retrieve repository metadata" error Message-ID: <1512d9530912151250g4e181172u27f5a789d5277080@mail.gmail.com> I have this problem too. I believe the problem is in libcurl 7.19.7-8.fc13. If I downgrade to curl/libcurl 7.19.6-10.fc12 the problem goes away. If I run from a command line: $ curl 'https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i386' I now get: curl: (7) Failed to connect to 2610:28:200:1::fed0:2: Network is unreachable despite the fact that IPv6 is disabled. The ifcfg script includes IPV6INIT=no. $ ifconfig eth1 Link encap:Ethernet HWaddr 00:0C:29:38:C9:7E inet addr:10.117.25.148 Bcast:10.117.25.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe38:c97e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1184 errors:0 dropped:0 overruns:0 frame:0 TX packets:1487 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:541164 (528.4 KiB) TX bytes:137185 (133.9 KiB) Interrupt:19 Base address:0x10a4 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:40 errors:0 dropped:0 overruns:0 frame:0 TX packets:40 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2000 (1.9 KiB) TX bytes:2000 (1.9 KiB) My understanding is that Scope:Link means that is it can not be used for internet access. All other networking appears normal and works okay. From jkeating at redhat.com Tue Dec 15 20:54:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 12:54:44 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215204943.GA10163@redhat.com> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <20091215204943.GA10163@redhat.com> Message-ID: <1260910484.21725.74.camel@localhost.localdomain> On Tue, 2009-12-15 at 15:49 -0500, Dave Jones wrote: > I'm on vacation, but I couldn't resist taking a look-see. > > Something looks odd. It appears to have collapsed every CVS branch > onto the master git branch instead of making a new branch for each > CVS branch. > > Running git log on the master branch should only show the commits > that happened to HEAD in cvs. > > This might not matter much for most packages, but the kernel does > have a lot of (mostly useless) branches, so the history looks > a bit messy. That's strange, when I clone and do a git branch -r, I see 142 branches, lots of those private-* branches. What things that were CVS branches are you seeing on origin/master ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Tue Dec 15 21:05:07 2009 From: davej at redhat.com (Dave Jones) Date: Tue, 15 Dec 2009 16:05:07 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260910484.21725.74.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <20091215204943.GA10163@redhat.com> <1260910484.21725.74.camel@localhost.localdomain> Message-ID: <20091215210507.GA20711@redhat.com> On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: > On Tue, 2009-12-15 at 15:49 -0500, Dave Jones wrote: > > I'm on vacation, but I couldn't resist taking a look-see. > > > > Something looks odd. It appears to have collapsed every CVS branch > > onto the master git branch instead of making a new branch for each > > CVS branch. > > > > Running git log on the master branch should only show the commits > > that happened to HEAD in cvs. > > > > This might not matter much for most packages, but the kernel does > > have a lot of (mostly useless) branches, so the history looks > > a bit messy. > > That's strange, when I clone and do a git branch -r, I see 142 branches, > lots of those private-* branches. Right I see those too. But locally, there's just '* master', and all the private-* commits seem to have been squashed onto that. > What things that were CVS branches are you seeing on origin/master ? run git log, and see all the myoung commits for example. Dave From kzak at redhat.com Tue Dec 15 21:05:58 2009 From: kzak at redhat.com (Karel Zak) Date: Tue, 15 Dec 2009 22:05:58 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260902754.21725.71.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215183312.GV5004@inocybe.localdomain> <1260902754.21725.71.camel@localhost.localdomain> Message-ID: <20091215210558.GI12786@nb.net.home> On Tue, Dec 15, 2009 at 10:45:54AM -0800, Jesse Keating wrote: > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: > > > > My thinking is that we don't use origin/next or origin/maint either > > and both are common upstream in git and the kernel. > > > > While origin/master is common, > > origin/master isn't "common", it's the friggin default. Every single > git repo I interact with has development happening on origin/master. > It's way more than just "common". +1 > > for our use, 'git push origin devel' (or > > rawhide) makes more sense as it matches the use for other branches, > > git push origin F-12. There's nothing magical or required about using > > master as the main branch. > > If our maintainer has to type that out, i think we've failed the > conversion. The thought here is that you'd be doing "git push" and > stuff will just happen right. But /if/ you wanted to do things manually > then it should match just about every other git repo out there, where > the main branch is origin/master > > > > > Whether other users will be more confused by the incongruity of master > > versus devel or that it differs from what they think git may require, > > I don't know. > > Yep, it's an opinion thing :/ I did the mistake with origin/devel for util-linux-ng upstream three years ago. People was confused. Now we use origin/master like all other projects. Karel -- Karel Zak From hun at n-dimensional.de Tue Dec 15 21:16:29 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 15 Dec 2009 22:16:29 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215210507.GA20711@redhat.com> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <20091215204943.GA10163@redhat.com> <1260910484.21725.74.camel@localhost.localdomain> <20091215210507.GA20711@redhat.com> Message-ID: <20091215221629.7765f8f0@n-dimensional.de> On Tue, 15 Dec 2009 16:05:07 -0500 Dave Jones wrote: > On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: > > What things that were CVS branches are you seeing on > > origin/master ? > > run git log, and see all the myoung commits for example. Run "git log -p", and you notice that those are empty commits without any actual changes. Smells like the CVS->git conversion tool has confused something. -- Hans Ulrich Niedermann From drago01 at gmail.com Tue Dec 15 21:21:52 2009 From: drago01 at gmail.com (drago01) Date: Tue, 15 Dec 2009 22:21:52 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091215202459.GE1238825@hiwaay.net> References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215202459.GE1238825@hiwaay.net> Message-ID: On Tue, Dec 15, 2009 at 9:24 PM, Chris Adams wrote: > Once upon a time, Jon Masters said: >> But again, Apples to Oranges. x86_64 (we should formally call it "Intel >> 64", or similar, since I'm not aware of x86_64 having a formal blessing) > > "Intel 64" has no "formal blessing" either (it is Intel's marketing name > for their copy of AMD's instruction set). ?If you want to call it after > a vendor, it should be "AMD 64" anyway, since AMD created it. ?They > called it "x86-64" (which is where the "x86_64" name came from), until > marketing got in the way and they changed to "AMD 64". > > "Intel 64" is confusing anyway, since Intel has pushed multiple 64 bit > architectures. Also there is the x64 marketing bullshit floating around.... From jkeating at redhat.com Tue Dec 15 21:23:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Dec 2009 13:23:57 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215221629.7765f8f0@n-dimensional.de> References: <1260847279.21725.3.camel@localhost.localdomain> <1260850929.21725.10.camel@localhost.localdomain> <20091215204943.GA10163@redhat.com> <1260910484.21725.74.camel@localhost.localdomain> <20091215210507.GA20711@redhat.com> <20091215221629.7765f8f0@n-dimensional.de> Message-ID: <1260912237.21725.75.camel@localhost.localdomain> On Tue, 2009-12-15 at 22:16 +0100, Hans Ulrich Niedermann wrote: > On Tue, 15 Dec 2009 16:05:07 -0500 > Dave Jones wrote: > > > On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: > > > > What things that were CVS branches are you seeing on > > > origin/master ? > > > > run git log, and see all the myoung commits for example. > > Run "git log -p", and you notice that those are empty commits without > any actual changes. Smells like the CVS->git conversion tool has > confused something. > Neat! Guess that'll have to be worked on. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Tue Dec 15 21:26:23 2009 From: pjones at redhat.com (Peter Jones) Date: Tue, 15 Dec 2009 16:26:23 -0500 Subject: Wiki Feature Dashboard Additional Category In-Reply-To: <4B271470.9040004@redhat.com> References: <4B271470.9040004@redhat.com> Message-ID: <4B27FEFF.3050609@redhat.com> On 12/14/2009 11:45 PM, John Poelstra wrote: > You have an interesting idea about tagging feature pages needing an > owner. In reality that pretty much represents all the pages in > 'Category:FeaturePageIncomplete' If they had an active owner or > developer working on the feature they wouldn't be there. As somebody who's owned a feature page put into this category, I just don't think this is true at all. There are a couple of reasons for this. Certainly, the cost/benefit of working on updating the wiki, which can sometimes consume a significant amount of time, vs that of working on the feature itself skews heavily towards the decision to work on the feature instead of updating the page immediately, which means the Feature page on the wiki suffers. It's also useful, as a developer, to queue changes to the Feature page instead of re-editing it every time anything on it changes - it's just easier to work on one thing at a time. The form also puts a lot of burden on whomever is developing a feature (and maintaining the form), for several reasons, listed below. Some of these reasons are probably more true for people working in an RH office than for RH remotees or non-RH contributors. To wit: a) The form isn't especially clear - the field names are basically all you've got to go on, and they're not terribly descriptive. It's hard to know what put in several places, and many people have different expectations. If you don't get it right (and it's not possible to get it right) you wind up having people coming to tell you so on a fairly constant basis. And they'll conflict, of course. b) There's a strong pressure to update the forms *very often*, even for features which it's clear will be slow to make progress. c) There's not really a clear audience to the form. Is it for the general population of Fedora users? Fedora developers? FESCo? The Board? RH management? Clearly a feature that's submitted is queued for FESCo's approval, though it's still unclear as to why FESCo has to actually *approve* every feature, or is interested in doing so, especially since it's obvious to everybody that they *don't* approve every feature, nor would they be able to if everybody implementing a feature actually filled out a Feature page and submitted it. Thus raising item d: d) Some member of every group I listed above thinks they're not only the target audience for the form, but also that if there's something on it they don't understand or even just don't see, they're going to lose their livelihood if that's not rectified *immediately*. e) Many of the people mentioned in "d" seem to be basically unwilling to actually read the content of the form in order to get their question answered. If they think something is missing from "Benefit to Fedora", the odds are you'll get an email (or worse, they'll show up at your desk and interrupt you in real time) about the "Benefit to Fedora" section even if the confusion is easily solved by reading the "Summary" or "Detailed Description" sections. Which brings us to: f) There are several fields which are basically redundant. If neither "Summary" nor "Detailed description" adequately include at least some large amount of "Benefit to Fedora", then the form really just isn't filled in. Likewise, if "Scope", "Dependencies", and "User Experience" are left empty or are sparse, it's it's likely because the developer filling out the form thought that had been explained well enough already and was tired of explaining things repeatedly. g) There are fields that don't /actually/ have a purpose. You'll get complaints if "Documentation" is empty, but not if you put in link to a pdf that's irrelevant to the actual Feature. h) There are fields that are essentially punitive. Not every Feature needs a release note (though some would argue that it's the only reason to bother with the Feature process at all...), but if you don't put text there for one, you're back in email-flood land. And it's really there because we don't trust developers to actually submit things for the release notes, anyway. Yes, there's plenty of data to support the fact that we usually won't write release notes, but this isn't a very good way to fix that. It's certainly not a convenient place to track it - especially since you've got to put something in that field even before you've actually implemented the feature, when you basically can't possibly know what would go there. But if you don't put something there when you first propose the Feature, guess whatyour inbox looks like? i) There's a field that's just there for people who don't understand wikis, AFAICT. I randomly sampled some Features in Category:FeatureAcceptedF11 (since that's pretty stable data at this point in time) to see what they said for "Comments and Discussion". All of them just listed a link to the Feature page's "Talk:" page. Surely this field isn't actually helping anybody? As far as I can tell, a slight error on any of these counts that isn't fixed *immediately* (i.e. in less than one day) will get you on Category:FeaturePageIncomplete. So let's stop perpetrating the fiction that a Feature page is in that category because nobody is maintaining it, okay? -- Peter When privacy is outlawed only outlaws will have privacy. -- Zimmermann From bruno at wolff.to Tue Dec 15 21:04:48 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 15 Dec 2009 15:04:48 -0600 Subject: MariaDB and Fedora In-Reply-To: References: <364d303b0912130321y77b15199qf59e2d9bf753f1aa@mail.gmail.com> <1260719966.16370.2.camel@localhost> <385866f0912130939w5dc8da1dp1011adba6ed7528e@mail.gmail.com> <1260738175.4566.13.camel@localhost> <20091213232017.GA12262@wolff.to> <2635.1260750462@sss.pgh.pa.us> <20091214024801.GB26374@wolff.to> <8278b1b0912131852y29f54856qa4ba5c14d87b2f6a@mail.gmail.com> <77FDA968-0649-403A-93EE-DCA1247F5546@gnat.ca> Message-ID: <20091215210448.GA2042@wolff.to> On Tue, Dec 15, 2009 at 21:30:50 +0100, Benny Amorsen wrote: > > That will give you an installation with quite reasonable defaults > including Unix-socket connectivity. > > Of course then you discover all the PHP toys written for MySQL which > can't be told to connect a) by Unix sockets and b) without a username > and password. I am pretty sure Postgres also listens on the loopback interface by default. From paul at dishone.st Tue Dec 15 21:28:10 2009 From: paul at dishone.st (Paul Jakma) Date: Tue, 15 Dec 2009 21:28:10 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <1260907071.6151.360.camel@tonnant> References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: On Tue, 15 Dec 2009, Jon Masters wrote: > But again, Apples to Oranges. x86_64 (we should formally call it "Intel > 64", or similar, since I'm not aware of x86_64 having a formal blessing) > doesn't have the fixed instruction width that you get on most RISC ISAs. It's not about the instruction set. If you look back at the posts, from myself and the poster who gave a toy test case, the extra memory usage is from data, not from programme text. Programme text is not too significant in size when compared to data (about a 10:1 data:text ratio for cases I've looked at). So the instructions being compact is simply not very relevant - pointers and longs in *data* double up in size on 64bit. (This transcends specific ISAs..). > the US, but here at least someone drew my attention to a > ludicrously cheap laptop on sale last weekend that also had 3GB of > RAM installed. Right. I.e. a 64bit *kernel* is very useful (and much faster than a PAE one). That's precisely what I am arguing for. Again, there is a difference between aggregate usage (e.g. of RAM) and per-process memory requirements, similarly for performance. I.e. in the aggregate, a system can make good use of *both* 32 and 64 bit. I.e.: - In the aggregate, systems now need to make efficient use of >3GB of memory - PAE (slow, other problems) - 64bit - more and more systems have this, it'd be nice to be able to use this with a 32bit install. - On a per-process basis, few processes need 64bit pointers - those which do, can easily be 64bit on a 32/64 system. - those which can be 32bit can avoid a circa 30 to 60% memory overhead - On a per-process basis, few processes need the advantages of x86-64 - I am incredulous at the people who keep arguing that "x86-64 is better" because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). - those processes which do, can be 64bit I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. A lot of respondents have argued as if this is a binary matter, approaching the debate as if it's an either-or choice between 32 OR 64, which was not my intention at all. And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. Anyway :) Sorry for extending this thread, but it seemed I miscommunicated in previous emails and failed to get the basic points across properly. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Seeing is believing. You wouldn't have seen it if you hadn't believed it. From mjg at redhat.com Tue Dec 15 21:40:19 2009 From: mjg at redhat.com (Matthew Garrett) Date: Tue, 15 Dec 2009 21:40:19 +0000 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: <20091215214019.GA839@srcf.ucam.org> On Tue, Dec 15, 2009 at 09:28:10PM +0000, Paul Jakma wrote: > And again, far from being some incredibly difficult thing that I'm > asking for, the support is pretty much 99.9% there.. And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. -- Matthew Garrett | mjg59 at srcf.ucam.org From drago01 at gmail.com Tue Dec 15 21:46:27 2009 From: drago01 at gmail.com (drago01) Date: Tue, 15 Dec 2009 22:46:27 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: On Tue, Dec 15, 2009 at 10:28 PM, Paul Jakma wrote: > ?- I am incredulous at the people who keep arguing that "x86-64 is > ? ?better" because it has PC-relative addressing, or because the ABI > ? ?is pass-by-register by default. I am extremely sceptical that > ? ?these respondents would be able to distinguish between a 32bit > ? ?and a 64bit "cp" or "nautilus" or "ls" or "gnome-panel" or ... etc. > > ? ?It'd be interesting to see if this applied even to browsers. > ? ?(E.g. Chrome on 32bit is extremely fast, hard to see that it'd > ? ? get much faster on 64. Firefox is slow on 64bit too). Well while there was no x86_64 chromium build midori (which uses webkit) was faster in every JS while the whole web was praising google's V8 as the fastest JS engine ... Once the 64bit chromium come out, this was indeed the case. So a software that is supposed to be slower than another one was faster only because it was running an x86_64 version. From paul at dishone.st Tue Dec 15 21:54:54 2009 From: paul at dishone.st (Paul Jakma) Date: Tue, 15 Dec 2009 21:54:54 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: On Tue, 15 Dec 2009, Paul Jakma wrote: > I would like to have the advantages of *both* 32 and 64bit, as and where each > one is appropriate. I'd like to be able to use that 30-60% of memory on more > VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a "generally-32bit" userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Your own qualities will help prevent your advancement in the world. From drago01 at gmail.com Tue Dec 15 21:56:44 2009 From: drago01 at gmail.com (drago01) Date: Tue, 15 Dec 2009 22:56:44 +0100 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <4B04ADCD.8060302@pobox.com> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> Message-ID: On Tue, Dec 15, 2009 at 10:54 PM, Paul Jakma wrote: > On Tue, 15 Dec 2009, Paul Jakma wrote: > >> I would like to have the advantages of *both* 32 and 64bit, as and where >> each one is appropriate. I'd like to be able to use that 30-60% of memory on >> more VMs, e.g., rather than bigger gnome-*, etc. processes. > > Ah, and to get the memory benefits, you need a "generally-32bit" userspace > (32bit apps on x86-64 obviously works just fine, but there's no savings > benefit when most of userspace is 64bit). > > Sorry again for the noise. :) There are shops that sells stuff called "ram sticks" ;) (sorry I will shut up already) From williams at redhat.com Tue Dec 15 22:15:57 2009 From: williams at redhat.com (Clark Williams) Date: Tue, 15 Dec 2009 16:15:57 -0600 Subject: packages requiring me to reboot... In-Reply-To: <20091215182924.GB3077@nostromo.devel.redhat.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <20091215182924.GB3077@nostromo.devel.redhat.com> Message-ID: <20091215161557.47d8401d@torg> On Tue, 15 Dec 2009 13:29:25 -0500 Bill Nottingham wrote: > Nathanael D. Noblet (nathanael at gnat.ca) said: > > I'm also curious why gdm is still running once I've logged in. > > When you start a display manager, you start an X server; the display > manager then draws on this. Then, when you log in, you have to > stat an user session, as the authenticated user (which has a connection > to the X server, so it can know when it goes away.) > > You also have to tell the init daemon which process it's supposed to > be tracking, so it can respawn it when it exits. > > Having that process be the gdm daemon (which forks and execs both > the X server and the user session) is arguably a lot simpler than > trying to architect it such that the daemon goes away entirely and > init then ends up tracking either the X serve or the user session. > > Bill > > Isn't GDM just doing a wait(2) on the user-session? Clark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lsof at nodata.co.uk Tue Dec 15 23:24:29 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 Dec 2009 00:24:29 +0100 Subject: packages requiring me to reboot... In-Reply-To: <4B27BE72.5020002@gnat.ca> References: <4B27BE72.5020002@gnat.ca> Message-ID: <4B281AAD.4020706@nodata.co.uk> Am 2009-12-15 17:50, schrieb Nathanael D. Noblet: > Hello, > I feel like there are an increasing number of packages requiring a > system reboot. I'm wondering why. The following updates were installed > today, and required a full system reboot. I can't seem to find any > package in the list that I can conceivably see requiring a reboot, is it > that PK doesn't have the concept of X logout vs reboot? Is it a bug in > the packaging or PK or is there anything I can do/file to improve the > situation? > > Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 > Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 > Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 > Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 > Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 > Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 > Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 > Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 > Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 > Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 > Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 > Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 > Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 > Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 > Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 > Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 > Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 > Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 > Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 > Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 > Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 > Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 > Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 > Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 > Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 > Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 > Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 > Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 > Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 > Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 > Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 > Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 > Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 > Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 > Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 > Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 > Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 > Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 > Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 > Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch > Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 > Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch > Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 > Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 > > Wouldn't it be sufficient to logout? Is it a bug? > I'd like for the icon that reboots to be more difficult to click on. Or to confirm. Or anything. From paul at dishone.st Wed Dec 16 00:30:11 2009 From: paul at dishone.st (Paul Jakma) Date: Wed, 16 Dec 2009 00:30:11 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091215214019.GA839@srcf.ucam.org> References: <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> Message-ID: On Tue, 15 Dec 2009, Matthew Garrett wrote: > And the remaining 0.1% of the work is probably the other 99.9% of > the time. I think you massively underestimate the number of corner > cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard From paul at dishone.st Wed Dec 16 00:35:14 2009 From: paul at dishone.st (Paul Jakma) Date: Wed, 16 Dec 2009 00:35:14 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <20091213213527.GB1479857@hiwaay.net> <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> Message-ID: On Wed, 16 Dec 2009, Paul Jakma wrote: > My data-point is that I ran an x86-64 kernel on i386 F10 for a few > months until I got tired of yum not being able to update kernel > packages. The kernel side apparently works fine AFAICT. The .1% is > yum. Oh, I don't quite remember the details, but I think libvirt also gets a bit confused when its 32bit and the kernel is 64. Another data-point is that I've used and developed on other 32/64 x86-64 systems for a number of years and those manage it just fine. It really shouldn't be hard, if you decide its worth supporting. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Life is like an onion: you peel off layer after layer and then you find there is nothing in it. -- James Huneker From lists at sapience.com Wed Dec 16 01:47:44 2009 From: lists at sapience.com (Mail Lists) Date: Tue, 15 Dec 2009 20:47:44 -0500 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> Message-ID: <4B283C40.4040407@sapience.com> On 12/15/2009 12:42 PM, Seth Vidal wrote: > this is what colin and I talked about at fudcon in toronto. I just added > some code to yum so it returns to you a list of all pkgs on the system > that own a file that is currently open/used in a running process. > > should make that part of your lookup easier. > > YumBase.rpmdb.return_running_packages() > This seems to be compounding the problem rather than try9ing to avoid it all together. As an alternate suggestion: It may make a lot more sense, to instead install apps in a shadow directory (named by version for example) with the usual spot being a link to the right place. When installing a new one simply install it in the shadow area and flip the link. The existing running app will see home base in the same place and have zero problems. The last part is a clean up phase which could be deferred to reboot or perhaps something a little more clever. firefox will work perfectly if done this way for example. gene From cmadams at hiwaay.net Wed Dec 16 04:05:48 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 15 Dec 2009 22:05:48 -0600 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> Message-ID: <20091216040548.GB1554409@hiwaay.net> Once upon a time, Paul Jakma said: > My data-point is that I ran an x86-64 kernel on i386 F10 for a few > months until I got tired of yum not being able to update kernel > packages. The kernel side apparently works fine AFAICT. The .1% is > yum. No, it's the whole development environment. For example, if you need to build a kernel module, gcc on i386 is not capable of building for x86_64 (IIRC it isn't a gcc configuration issue, it is an issue with gcc itself). You could just always install the x86_64 gcc, but then you need all the development tools and libraries to match. "gcc hello.c" is going to generate native code, and native will still be x86_64, so you have to have the x86_64 shared libraries and support in place (and now you're back to a multilib system, which loses on RAM usage, disk space, install time, update downloads, etc.). Also, part of your justification was that in the "real world", people run some 32 bit anyway (like wine). Well, what happens with some of those "real world" binary modules people use, like nVidia? Do they work with a split 32/64 user/kernel space (and development stack somewhere in between)? If they don't, users are going to blame Fedora, not nVidia (or whoever else ships binary modules). Again, most of the Fedora people developing things like yum, anaconda, etc. don't appear to be interested in this; there just doesn't seem to be a significant benefit (okay, you save a little RAM, but for the majority of 64 bit systems, that isn't a big deal). If you think otherwise, nobody is stopping you from doing the work to make it happen, and if it proves to work and be a benefit, I bet it would be accepted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jonathan at jonmasters.org Wed Dec 16 05:19:53 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 16 Dec 2009 00:19:53 -0500 Subject: packages requiring me to reboot... In-Reply-To: <0EFA3F7A814C487CB496D7B86522A2E8@C515816A> References: <0EFA3F7A814C487CB496D7B86522A2E8@C515816A> Message-ID: <1260940793.6151.465.camel@tonnant> On Tue, 2009-12-15 at 12:01 -0600, Otto Haliburton wrote: > I am not sure what the argument is, factually there are packages that have > files open, locks and etc. that need to be shutdown to update, if they are > running and you replace the executable, doesn't mean that the memory image > is replaced. It is quicker and simpler to just reboot, also the list of the > packages that cause you to reboot is probably longer than the ones that are > flagged. I think that a reboot should be made whether necessary or not, > clears up a lot of grief. Wow. That's twice today that the suggestion of forcing the user to reboot whether they like it or not has been made. What a long way we've come since the early days :) Personally, I think a dialog box is pretty simple for most users (no forcing, just persuasion), and allows those who know what they're doing to ignore it. And obviously reducing the number of times you ask to just absolute necessity is a win-win. But please, no more forced reboot suggestions. This isn't MSFT. Jon. From jcm at redhat.com Wed Dec 16 05:33:20 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 16 Dec 2009 00:33:20 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091215203516.GF3259@clingman.lan> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> Message-ID: <1260941600.6151.471.camel@tonnant> On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > master makes a lot of sense from a git perspective. devel (or rawhide) > makes sense from what we actually call the code that that branch eventually > makes. A symlink might alleviate the confusion but it could also add to it. > (For instance, I was operating in the kernel/devel branch but when I want to > git checkout -b devel git gives me a strange error.) > > I don't see a clear answer for what's best here, yet. :-( I think those of us who follow rawhide will quickly realize the change in naming (ok maybe a symbol is vaguely useful, and also needs to be explained somewhere when people inevitably ask) and move on. Conversely, someone who is new or hasn't followed "devel" branches before should just be able to use git how they have elsewhere and it should work. Summary: easier to make life easier for new developers. Jon. From hughsient at gmail.com Wed Dec 16 08:50:36 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Dec 2009 08:50:36 +0000 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> Message-ID: <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> 2009/12/15 Colin Walters : > This exists? ?Can you point me to the code? I only finished this just this morning. It's just been pushed to git master. You want to see this commit http://cgit.freedesktop.org/packagekit/commit/?id=66d3fc26054abd528ee18017d9c67edb6400f239 for the juicy config bits. The UI isn't very pretty at the moment (it just fails with an update error) but I'll work on something a little bit more user friendly. Richard. From hughsient at gmail.com Wed Dec 16 08:51:20 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 16 Dec 2009 08:51:20 +0000 Subject: packages requiring me to reboot... In-Reply-To: <4B283C40.4040407@sapience.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <4B283C40.4040407@sapience.com> Message-ID: <15e53e180912160051i553667d4sd0c7fad4456f4c9b@mail.gmail.com> 2009/12/16 Mail Lists : > ? The last part is a clean up phase which could be deferred to reboot > or perhaps something a little more clever. The devil is in the detail :) Richard. From schwab at redhat.com Wed Dec 16 09:13:33 2009 From: schwab at redhat.com (Andreas Schwab) Date: Wed, 16 Dec 2009 10:13:33 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260902754.21725.71.camel@localhost.localdomain> (Jesse Keating's message of "Tue, 15 Dec 2009 10:45:54 -0800") References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215183312.GV5004@inocybe.localdomain> <1260902754.21725.71.camel@localhost.localdomain> Message-ID: Jesse Keating writes: > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: >> >> My thinking is that we don't use origin/next or origin/maint either >> and both are common upstream in git and the kernel. >> >> While origin/master is common, > > origin/master isn't "common", it's the friggin default. Every single > git repo I interact with has development happening on origin/master. > It's way more than just "common". You can set any branch as default via origin/HEAD, and some do. It is also easy to make origin/devel an alias for origin/master. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From rawhide at fedoraproject.org Wed Dec 16 12:53:57 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 16 Dec 2009 12:53:57 +0000 Subject: rawhide report: 20091216 changes Message-ID: <20091216125357.GA23848@releng2.fedora.phx.redhat.com> Compose started at Wed Dec 16 08:15:08 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 sepostgresql-8.4.1-2464.fc13.i686 requires postgresql-server = 0:8.4.1 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) sepostgresql-8.4.1-2464.fc13.x86_64 requires postgresql-server = 0:8.4.1 tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package artha A handy thesaurus based on WordNet New package emacs-spice-mode SPICE Mode for GNU Emacs New package gscribble A desktop client for blogging New package luci Web-based cluster administration application Updated Packages: ConsoleKit-0.4.1-3.fc13 ----------------------- * Tue Dec 15 2009 Matthias Clasen 0.4.1-3 - Don't daemonize when activated abrt-1.0.2-1.fc13 ----------------- * Mon Dec 14 2009 Jiri Moskovcak 1.0.2-1 - disabled GPG check again (jmoskovc at redhat.com) - abrt-pyhook-helper rename (vda.linux at googlemail.com) - abrt-cli: report success/failure of reporting. closes bug 71 (vda.linux at googlemail.com) - less logging (vda.linux at googlemail.com) - mkde abrt-gui --help and --version behave as expected. closes bug 85 (vda.linux at googlemail.com) - dbus lib: fix parsing of 0-element arrays. Fixes bug 95 (vda.linux at googlemail.com) - make "abrt-cli --delete randomuuid" report that deletion failed. closes bug 59 (vda.linux at googlemail.com) - applet: make animation stop after 1 minute. (closes bug 108) (vda.linux at googlemail.com) - show comment and how to reproduce fields, when BT rating > 3 (jmoskovc at redhat.com) - Gui: make report status window's text wrap. Fixes bug 82 (vda.linux at googlemail.com) - CCpp analyzer: added "info sharedlib" (https://fedorahosted.org/abrt/ticket/90) (vda.linux at googlemail.com) - added link to bugzilla new account page to Bugzilla config dialog (jmoskovc at redhat.com) - GUI: added log window (jmoskovc at redhat.com) * Tue Dec 08 2009 Jiri Moskovcak 1.0.1-1 - PyHook: better logic for checking if abrtd is running rhbz#539987 (jmoskovc at redhat.com) - re-enabled gpg sign checking (jmoskovc at redhat.com) - PyHook: use repr() for displaying variables rhbz#545070 (jmoskovc at redhat.com) - kerneloops: fix the linux kernel version identification (aarapov at redhat.com) - gui review (rrakus at redhat.com) - when we trim the dir, we must delete it from DB too rhbz#541854 (vda.linux at googlemail.com) - improved dupe checking (kklic at redhat.com) - GUI: handle cases when gui fails to start daemon on demand rhbz#543725 (jmoskovc at redhat.com) - Add abrt group only if it is missing; fixes rhbz#543250 (kklic at redhat.com) - GUI: more string fixes rhbz#543266 (jmoskovc at redhat.com) - abrt.spec: straighten out relations between abrt-desktop and abrt-gui (vda.linux at googlemail.com) - refuse to start if some required plugins are missing rhbz#518422 (vda.linux at googlemail.com) - GUI: survive gnome-keyring access denial rhbz#543200 (jmoskovc at redhat.com) - typo fixes rhbz#543266 (jmoskovc at redhat.com) - abrt-debuginfo-install: better fix for incorrect passing double quotes (vda.linux at googlemail.com) - APPLET: stop animation when it's not needed rhbz#542157 (jmoskovc at redhat.com) - ccpp hook: reanme it, and add "crash storm protection" (see rhbz#542003) (vda.linux at googlemail.com) - Hooks/CCpp.cpp: add MakeCompatCore = yes/no directive. Fixes rhbz#541707 (vda.linux at googlemail.com) - SPEC: removed sqlite3 package, fixed some update problems (jmoskovc at redhat.com) - Kerneloops are reported automaticky now when AutoReportUIDs = root is in Kerneloops.conf (npajkovs at redhat.com) - remove word 'detected' from description rhbz#541459 (vda.linux at googlemail.com) - src/Hooks/CCpp.cpp: do save abrtd's own coredumps, but carefully... (vda.linux at googlemail.com) - CCpp.cpp: quote parameters if needed rhbz#540164 (vda.linux at googlemail.com) activemq-cpp-3.0.1-1.fc13 ------------------------- aspell-0.60.6-11.fc13 --------------------- * Tue Dec 15 2009 Ivana Hutarova Varekova - 12:0.60.6-11 - remove obsolete patch augeas-0.6.0-2.fc13 ------------------- * Tue Dec 15 2009 David Lutterkort - 0.6.0-2 - Fix ftdetect file for vim bash-completion-1.1-4.fc13 -------------------------- * Tue Dec 15 2009 Ville Skytt? - 1:1.1-4 - Fix autoinstall of completions named other than the package (#546905). - Use environment-modules upstream completion instead of ours if available. - Autoinstall mysqladmin completion also on MySQL-client-community. bind-9.7.0-0.10.rc1.fc13 ------------------------ * Tue Dec 15 2009 Adam Tkac 32:9.7.0-0.10.rc1 - update to 9.7.0rc1 - bind97-headers.patch merged - update default configuration bind-dyndb-ldap-0.1.0-0.7.a1.20091210git.fc13 --------------------------------------------- * Tue Dec 15 2009 Adam Tkac - 0.1.0-0.7.a1.20091210git - rebuild against new bind bitmap-1.0.3-7.fc13 ------------------- * Tue Dec 15 2009 Stepan Kasal - 1.0.3-7 - silence scriptlets cadaver-0.23.3-1.fc13 --------------------- * Tue Dec 15 2009 Joe Orton - 0.23.3-1 - update to 0.23.3 chronojump-0.8.14-1.fc12 ------------------------ * Sat Dec 12 2009 - 0.8.14-1 - update to 0.8.14 * Fri Dec 11 2009 - 0.8.13-1 - update to 0.8.13 chrony-1.24-0.1.pre1.fc13 ------------------------- * Tue Dec 15 2009 Miroslav Lichvar 1.24-0.1.pre1 - update to 1.24-pre1 chunkd-0.6-0.3.g756ea210.fc13 ----------------------------- * Tue Dec 15 2009 Jeff Garzik - 0.6-0.2.g756ea210 - update source to commit 756ea2108509b69d036c658089fa954815f31945 * Tue Dec 15 2009 Jeff Garzik - 0.6-0.3.g756ea210 - really update source to commit 756ea2108509b69d036c658089fa954815f31945 cld-0.3-0.8.g4806aa08.fc13 -------------------------- * Wed Dec 16 2009 Jeff Garzik - 0.3-0.7.ge9d692a5 - update to 0.3git commit e9d692a54ab2de96bcd1e55b02938c9d35535b27 * Wed Dec 16 2009 Jeff Garzik - 0.3-0.8.g4806aa08 - update to 0.3git commit 4806aa08577e2bf8e90b681b8be3588a647dd67e dnsperf-1.0.1.0-15.fc13 ----------------------- * Tue Dec 15 2009 Adam Tkac - 1.0.1.0-15 - rebuild against new bind dokuwiki-0-0.3.20091202.rc.fc13 ------------------------------- * Tue Dec 15 2009 Andrew Colin Kissa - 0-0.3.20091202.rc - Fix versioning fio-1.36-1.fc13 --------------- * Tue Dec 15 2009 Eric Sandeen 1.36-1 - New upstream version foomatic-4.0.3-8.fc13 --------------------- * Tue Dec 15 2009 Tim Waugh - 4.0.3-8 - Really fixed installation path for perl module (bug #547696). * Fri Dec 04 2009 Stepan Kasal - 4.0.3-6 - rebuild against perl 5.10.1 * Fri Dec 04 2009 Tim Waugh - 4.0.3-7 - Fixed installation path for perl module. gbirthday-0.5.5-2.fc13 ---------------------- * Wed Dec 16 2009 Thomas Spura 0.5.5-2 - upstream tarball was corected, still same version gg2-2.3.0-15.fc13 ----------------- * Tue Dec 15 2009 Stepan Kasal - 2.3.0-15 - replace the perl(DynaLoader) requirement by the standard perl(:MODULE_COMPAT_5.10.1) * Fri Dec 04 2009 Stepan Kasal - 2.3.0-14 - rebuild against perl 5.10.1 ghc-rpm-macros-0.3.1-1.fc13 --------------------------- * Tue Dec 15 2009 Jens Petersen - 0.3.1-1 - use ghc_version_override to override ghc_version - fix pkg .conf filelist match gir-repository-0.6.5-3.fc13 --------------------------- * Wed Dec 09 2009 Bastien Nocera 0.6.5-3 - Install the DBusGlib bindings gnome-bluetooth-2.29.3-3.fc13 ----------------------------- * Tue Dec 15 2009 Bastien Nocera 2.29.3-3 - Enable introspection gnome-panel-2.28.0-17.fc13 -------------------------- * Tue Dec 15 2009 Matthias Clasen 2.28.0-17 - Handle errors returned from PolicyKit in the clock applet (#547624) - Fix clock crash (bug 537798) - Improve the behaviour of the panel when screen resolution changes (gnome #341441) gnome-settings-daemon-2.28.1-9.fc13 ----------------------------------- * Tue Dec 15 2009 Matthias Clasen 2.28.1-9 - Survive when running without XKB (#547780) gvfs-1.5.1-3.fc13 ----------------- * Tue Dec 15 2009 Tomas Bzatek - 1.5.1-3 - Rebuilt against new libiphone hercules-3.06-7.20091214svn5544.fc13 ------------------------------------ * Mon Dec 14 2009 Dan Hor?k 3.06-7.20091214svn5544 - updated to svn revision 5544 - added workaround for booting Fedora kernels requiring z9 or better - spec cleanup - updated default config hmaccalc-0.9.12-1.fc13 ---------------------- * Tue Dec 15 2009 Nalin Dahyabhai 0.9.12-1 - fix regression of #512275 -- we looked for prelink, but didn't record its location properly ibus-1.2.0.20091215-1.fc13 -------------------------- * Tue Dec 15 2009 Peng Huang - 1.2.0.2001215-1 - Update to 1.2.0.20091215 ibus-qt-1.2.0.20091216-1.fc13 ----------------------------- ifuse-0.9.5-1.fc13 ------------------ * Sat Dec 12 2009 Peter Robinson 0.9.4-3 - Rebuild for libplist .so bump * Sat Dec 12 2009 Peter Robinson 0.9.5-1 - Update to 0.9.5 release for new usbmuxd/libplist 1.0.0 final jd-2.5.5-0.2.svn3235_trunk.fc13 ------------------------------- * Wed Dec 16 2009 Mamoru Tasaka - rev 3235 libevent-1.4.13-1.fc13 ---------------------- * Tue Dec 15 2009 Steve Dickson 1.4.13-1 - Updated to latest stable upstream version: 1.4.13 libgnome-2.28.0-4.fc13 ---------------------- * Tue Dec 15 2009 Matthias Clasen - 2.28.0-4 - Remove a useless static library that trips up some rpmlint-type checks libiphone-0.9.5-2.fc13 ---------------------- * Tue Dec 15 2009 Peter Robinson 0.9.5-2 - Update python bindings * Sat Dec 12 2009 Peter Robinson 0.9.4-3 - Rebuild for libplist .so bump * Sat Dec 12 2009 Peter Robinson 0.9.5-1 - Update to 0.9.5 release for new usbmuxd/libplist 1.0.0 final libsoup-2.29.3-2.fc13 --------------------- * Wed Dec 09 2009 Dan Winship - 2.29.3-2 - Add patch from git to fix gir-repository build libspiro-20071029-4.fc13 ------------------------ * Tue Dec 15 2009 Parag - 20071029-4 - Fix rpmlint error "libspiro.src:53: E: files-attr-not-set" libtalloc-2.0.1-1.fc13 ---------------------- * Tue Dec 15 2009 Simo Sorce - 2.0.1-1 - New version from upstream - Also stop building the compat lib, it is not necessary anymore libtdb-1.2.0-1.fc13 ------------------- * Tue Dec 15 2009 Simo Sorce - 1.2.0-1 - New upstream release linuxwacom-0.8.2.2-16.fc12 -------------------------- * Tue Nov 24 2009 Peter Hutterer 0.8.2.2-16 - linuxwacom-0.8.2.2-wacdump-penpartner.patch: teach wacdump about the PenPartner CT-0045R00a (#538097) * Mon Nov 23 2009 Peter Hutterer 0.8.2.2-15 - linuxwacom-0.8.2.2-intuos4-support-backport.patch: add two hunks to include the new files in the Makefiles (#539582) man-pages-ko-20050219-10.fc13 ----------------------------- * Wed Dec 16 2009 Ding-Yi Chen - 2:20050219-10 - Add full URL to source. - Fixed the Source1 path. maxima-5.20.1-1.fc13 -------------------- * Tue Dec 15 2009 Rex Dieter - 5.20.1-1 - maxima-5.20.1 mc-4.7.0-0.8.pre4.fc13 ---------------------- * Tue Dec 15 2009 Jindrich Novy 4.7.0-0.8.pre4 - fix rpmvfs empty directory handling (#529645) - fix bindings (#532784) monkeystudio-1.8.4.0-0.4.20091214svn3482.fc13 --------------------------------------------- * Mon Dec 14 2009 Nicoleau Fabien - 1.8.4.0-0.4.20091214svn3482 - Update svn checkout - Fix #539003 - Add smp_mflags at build step, as it now works with this package neon-0.29.1-1.fc13 ------------------ * Tue Dec 15 2009 Joe Orton - 0.29.1-1 - update to 0.29.1 perl-Math-BigInt-GMP-1.24-5.fc13 -------------------------------- * Tue Dec 15 2009 Stepan Kasal - 1.24-5 - skip check in distributions with perl-5.8 perl-Params-Validate-0.94-1.fc13 -------------------------------- * Tue Dec 15 2009 Ralf Cors?pius - 0.94-1 - Upstream update. - Reflect upstream having reworked author tests to using AUTHOR_TESTING=1. postgresql-8.4.2-1.fc13 ----------------------- * Wed Dec 16 2009 Tom Lane 8.4.2-1 - Update to PostgreSQL 8.4.2, for various fixes described at http://www.postgresql.org/docs/8.4/static/release-8-4-2.html including two security issues Related: #546321 Related: #547662 - Use -N not the obsolete -n in useradd call Resolves: #495727 - Clean up specfile to eliminate rpmlint gripes, mainly by removing no-longer-needed provisions for superseding rh-postgresql python-biopython-1.53-1.fc13 ---------------------------- * Tue Dec 15 2009 Alex Lancaster - 1.53-1 - Update to upstream 1.53 python-dmidecode-3.10.8-2.fc13 ------------------------------ * Tue Dec 15 2009 Nima Talebi - 3.10.8-1 - New Upstream release. - Big-endian and little-endian approved. - Packaged unit-test to tarball. - Rewritten unit-test to be able to run as non-root user, where it will not try to read /dev/mem. - Added two dmidump data files to the unit-test. python-kiwi-1.9.26-1.fc13 ------------------------- * Tue Dec 15 2009 Ha?kel Gu?mar - 1.9.26-1 - Upstream 1.9.26 - Fix kiwi custom distutils to conform fedora python packaging guidelines. * Tue Aug 11 2009 Ville Skytt? - 1.9.25-3 - Use bzipped upstream tarball. python-tgext-crud-0.3.3-1.fc13 ------------------------------ * Mon Dec 14 2009 Luke Macken - 0.3.3-1 - Update to 0.3.3 qbittorrent-2.0.1-1.fc13 ------------------------ * Mon Dec 14 2009 Leigh Scott - 2.0.1-1 - update to 2.0.1 - clean up spec file rhythmbox-0.12.6-5.fc13 ----------------------- * Tue Dec 15 2009 Matthias Clasen 0.12.6-5 - Don't include header files for plugins rsh-0.17-60.fc13 ---------------- * Tue Dec 15 2009 Adam Tkac - 0.17-60 - more merge review related fixes (#226379) sbackup-0.10.5-10.fc13 ---------------------- * Sat Dec 12 2009 Simon Wesp - 0.10.5-10 - Add patch to remember the setting 'Abort backup if destination directory does not exist' (RHBZ#517840) sendmail-8.14.3-9.fc13 ---------------------- * Tue Dec 15 2009 Miroslav Lichvar 8.14.3-9 - fix milter file descriptors leaks (#485426) - skip colon separator when parsing service name in ServiceSwitchFile - return with non-zero exit code when free space is below MinFreeBlocks - fix service stop/restart when only smclient is running - fix submit.cf and helpfile permissions - more merge review fixes (#226407) tabled-0.5-0.3.ge32562b9.fc13 ----------------------------- * Wed Dec 16 2009 Jeff Garzik - 0.5-0.3.ge32562b9 - add sources for git commit e32562b95234a8c221b8a91e8712878ea05cd6b9 * Tue Dec 15 2009 Jeff Garzik - 0.5-0.2.g93f17fe1 - add sources for git commit 93f17fe1396082762447a772287ce9b6b40d389b tcsh-6.17-6.fc13 ---------------- * Tue Dec 15 2009 Vitezslav Crhonek - 6.17-6 - Fix tcsh obeys printexitvalue for back-ticks uucp-1.07-22.fc13 ----------------- * Tue Dec 15 2009 Ondrej Vasik - 1.07-21 - Merge Review(#226521) - add _smp_mflags to make, remove implicit target, fix rpmlint warnings, commented patches, fix build root, use buildrequires/requires instead of prereq * Tue Dec 15 2009 Ondrej Vasik - 1.07-22 - move contrib dir from %doc dir into /usr/share/uucp/ vsftpd-2.2.0-6.fc12 ------------------- * Mon Nov 23 2009 Jiri Skala - 2.2.0-6 - added lost default values of vsftpd.conf (rh patch) wireshark-1.2.4-2.fc13 ---------------------- * Mon Dec 14 2009 Radek Vokal - 1.2.4-2 - enable lua support - http://wiki.wireshark.org/Lua - attempt to fix filter crash on 64bits xfwm4-4.6.1-6.fc13 ------------------ * Sun Dec 13 2009 Kevin Fenzi - 4.6.1-6 - Add patch for multi monitor issue (xfce bug #5795) xkeyboard-config-1.6-4.fc12 --------------------------- * Tue Nov 24 2009 Peter Hutterer 1.6-4 - xkeyboard-config-1.6-abnt2-dot.patch: fix KP dot on abnt2 (#470153) xmlfy-1.5.1-1.fc13 ------------------ * Wed Dec 16 2009 Arthur Gouros 1.5.1-1 - point release, consult RELEASE_NOTES file for details Summary: Added Packages: 4 Removed Packages: 0 Modified Packages: 65 From mkkp4x4 at gmail.com Wed Dec 16 12:58:33 2009 From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=) Date: Wed, 16 Dec 2009 13:58:33 +0100 Subject: safe way to standby sata hdd? Message-ID: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> Hi, I've got a home database/symfony env/etc../file server. It's based on Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power connected through Sata. First drive has / and /home filesystem, second has /home/samba4. On the first drive there are two directories /home/samba2 and /home/samba3 where I'm mounting ecryptfs. /home/samba4 is also crypted by default. I'm wondering if there is a safe way for such configuration to put second harddrive into sleep (or both drives) after some idle time? After some googling I've found some resolutions (haven't tested any of these yet): - hdparm -S - sdparm --set=STANDBY - and laptop_tools I'm really not convinced that these methods are safe for my configuration. Anyone have tried this before? BTW. I'm using F11 on this system - it appears that I even don't have /etc/hdparm.conf... Regards, Michal From andy at warmcat.com Wed Dec 16 14:06:24 2009 From: andy at warmcat.com (Andy Green) Date: Wed, 16 Dec 2009 14:06:24 +0000 Subject: yum-presto behaviour on arm Message-ID: <4B28E960.9040603@warmcat.com> Hi - Is yum-presto known to work on arm? Today I changed our repo to use deltarpms and tested it out. I noticed... 1) On a package where I know the bulk of the unpacked data is some fonts inside an ELF executable that didn't change, the compression result was... not good Old RPM: 25424385 txtr-reader-0.1-417.fc11.armv5tel.rpm New RPM: 25465487 txtr-reader-0.1-420.fc11.armv5tel.rpm Delta RPM: 25465402 txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm So it saved me 85 bytes from 25MByte :-) The actual procedure here is the createrepo is run on an x86_64 box over these arm packages and then rsync'd on a server. 2) Using deltarpms fails Loaded plugins: presto Setting up Update Process Resolving Dependencies There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them. --> Running transaction check ---> Package txtr-reader.armv5tel 0:0.1-420.fc11 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: txtr-reader armv5tel 0.1-420.fc11 txtradevel 24 M Transaction Summary ================================================================================ Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 24 M Downloading Packages: Setting up and reading Presto delta metadata Downloading DeltaRPMs: Rebuilding rpms from deltarpms /var/cache/yum/txtradevel/deltas/txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm: md5 mismatch of result Error rebuilding rpm from txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm! Will download full package. Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : txtr-reader 1/2 Cleanup : txtr-reader 2/2 Updated: txtr-reader.armv5tel 0:0.1-420.fc11 Complete! Any advice welcomed, it would be great to reduce this 25MByte package down since the vast bulk of it is exactly the same each time :-) -Andy From jdieter at gmail.com Wed Dec 16 14:12:32 2009 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 16 Dec 2009 16:12:32 +0200 Subject: yum-presto behaviour on arm In-Reply-To: <4B28E960.9040603@warmcat.com> References: <4B28E960.9040603@warmcat.com> Message-ID: <1260972752.2559.25.camel@localhost> On Wed, 2009-12-16 at 14:06 +0000, Andy Green wrote: > Hi - > > Is yum-presto known to work on arm? Today I changed our repo to use > deltarpms and tested it out. I noticed... > > 1) On a package where I know the bulk of the unpacked data is some fonts > inside an ELF executable that didn't change, the compression result > was... not good > > Old RPM: 25424385 txtr-reader-0.1-417.fc11.armv5tel.rpm > New RPM: 25465487 txtr-reader-0.1-420.fc11.armv5tel.rpm > Delta RPM: 25465402 txtr-reader-0.1-417.fc11_0.1-420.fc11.armv5tel.drpm > > So it saved me 85 bytes from 25MByte :-) > > The actual procedure here is the createrepo is run on an x86_64 box over > these arm packages and then rsync'd on a server. > > 2) Using deltarpms fails > > Any advice welcomed, it would be great to reduce this 25MByte package > down since the vast bulk of it is exactly the same each time :-) > > -Andy > If you can get me ssh access to an arm machine, I'll look into both of these problems. Please also open a bug against deltarpm (otherwise, I'll totally forget about this). Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From andy at warmcat.com Wed Dec 16 14:30:37 2009 From: andy at warmcat.com (Andy Green) Date: Wed, 16 Dec 2009 14:30:37 +0000 Subject: yum-presto behaviour on arm In-Reply-To: <1260972752.2559.25.camel@localhost> References: <4B28E960.9040603@warmcat.com> <1260972752.2559.25.camel@localhost> Message-ID: <4B28EF0D.8000607@warmcat.com> On 12/16/09 14:12, Somebody in the thread at some point said: Hi - >> Is yum-presto known to work on arm? Today I changed our repo to use >> deltarpms and tested it out. I noticed... > If you can get me ssh access to an arm machine, I'll look into both of > these problems. Please also open a bug against deltarpm (otherwise, I'll > totally forget about this). Thanks for the quick reply... I will see about setting something up and get back to you. https://bugzilla.redhat.com/show_bug.cgi?id=548068 -Andy From mjg at redhat.com Wed Dec 16 15:07:48 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 16 Dec 2009 15:07:48 +0000 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> Message-ID: <20091216150748.GA15217@srcf.ucam.org> On Wed, Dec 16, 2009 at 12:30:11AM +0000, Paul Jakma wrote: > On Tue, 15 Dec 2009, Matthew Garrett wrote: > >> And the remaining 0.1% of the work is probably the other 99.9% of the >> time. I think you massively underestimate the number of corner cases >> present in an utterly untested configuration. > > My data-point is that I ran an x86-64 kernel on i386 F10 for a few > months until I got tired of yum not being able to update kernel > packages. The kernel side apparently works fine AFAICT. The .1% is yum. "It works for me" is a poor standard of support. -- Matthew Garrett | mjg59 at srcf.ucam.org From skvidal at fedoraproject.org Wed Dec 16 15:13:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 10:13:12 -0500 (EST) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091216150748.GA15217@srcf.ucam.org> References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> Message-ID: On Wed, 16 Dec 2009, Matthew Garrett wrote: > On Wed, Dec 16, 2009 at 12:30:11AM +0000, Paul Jakma wrote: >> On Tue, 15 Dec 2009, Matthew Garrett wrote: >> >>> And the remaining 0.1% of the work is probably the other 99.9% of the >>> time. I think you massively underestimate the number of corner cases >>> present in an utterly untested configuration. >> >> My data-point is that I ran an x86-64 kernel on i386 F10 for a few >> months until I got tired of yum not being able to update kernel >> packages. The kernel side apparently works fine AFAICT. The .1% is yum. > > "It works for me" is a poor standard of support. > and if running an x86_64 kernel on an i386 install is something we want to do then we can make some changes to make that work. But complaining that yum doesn't work for something it was never designed to work for is a bit silly. -sv "My this camel is not a very fast swimmer." From a.badger at gmail.com Wed Dec 16 15:28:57 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Dec 2009 07:28:57 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260941600.6151.471.camel@tonnant> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> Message-ID: <20091216152857.GG3259@clingman.lan> On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote: > On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > > > master makes a lot of sense from a git perspective. devel (or rawhide) > > makes sense from what we actually call the code that that branch eventually > > makes. A symlink might alleviate the confusion but it could also add to it. > > (For instance, I was operating in the kernel/devel branch but when I want to > > git checkout -b devel git gives me a strange error.) > > > > I don't see a clear answer for what's best here, yet. :-( > > I think those of us who follow rawhide will quickly realize the change > in naming (ok maybe a symbol is vaguely useful, and also needs to be > explained somewhere when people inevitably ask) and move on. Conversely, > someone who is new or hasn't followed "devel" branches before should > just be able to use git how they have elsewhere and it should work. > > Summary: easier to make life easier for new developers. > Not all packagers use git elsewhere. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ssorce at redhat.com Wed Dec 16 15:42:28 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Dec 2009 10:42:28 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091216152857.GG3259@clingman.lan> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> Message-ID: <1260978148.2528.20.camel@willson.li.ssimo.org> On Wed, 2009-12-16 at 07:28 -0800, Toshio Kuratomi wrote: > On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote: > > On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > > > > > master makes a lot of sense from a git perspective. devel (or rawhide) > > > makes sense from what we actually call the code that that branch eventually > > > makes. A symlink might alleviate the confusion but it could also add to it. > > > (For instance, I was operating in the kernel/devel branch but when I want to > > > git checkout -b devel git gives me a strange error.) > > > > > > I don't see a clear answer for what's best here, yet. :-( > > > > I think those of us who follow rawhide will quickly realize the change > > in naming (ok maybe a symbol is vaguely useful, and also needs to be > > explained somewhere when people inevitably ask) and move on. Conversely, > > someone who is new or hasn't followed "devel" branches before should > > just be able to use git how they have elsewhere and it should work. > > > > Summary: easier to make life easier for new developers. > > > Not all packagers use git elsewhere. But for anyone that does not using "master" as the default branch will be a problem. If you never used git you have to learn a lot of things anyway. Simo. -- Simo Sorce * Red Hat, Inc * New York From sandeen at redhat.com Wed Dec 16 15:44:02 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 16 Dec 2009 09:44:02 -0600 Subject: safe way to standby sata hdd? In-Reply-To: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> References: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> Message-ID: <4B290042.6010609@redhat.com> Micha? Piotrowski wrote: > Hi, > > I've got a home database/symfony env/etc../file server. It's based on > Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power > connected through Sata. First drive has / and /home filesystem, second > has /home/samba4. On the first drive there are two directories > /home/samba2 and /home/samba3 where I'm mounting ecryptfs. > /home/samba4 is also crypted by default. > > I'm wondering if there is a safe way for such configuration to put > second harddrive into sleep (or both drives) after some idle time? > After some googling I've found some resolutions (haven't tested any of > these yet): > - hdparm -S I use this for the data drive on my mythbox. I just put this in my /etc/rc.local - # Spin down in 1 hours idle time hdparm -S 240 /dev/sda (yeah, oddly, sda is not my boot drive) :) > - sdparm --set=STANDBY > - and laptop_tools > > I'm really not convinced that these methods are safe for my > configuration. Anyone have tried this before? Yep. What kind of safety are you worried about? It should just work, although you want a long enough idle time that you're not constantly spinning the disk up and down. Is there any nice user-friendly frontend to set this? It'd be nice to expose more power management choices to the users (for anything that can't be easily defaulted, that is). -Eric > BTW. I'm using F11 on this system - it appears that I even don't have > /etc/hdparm.conf... > > Regards, > Michal > From rjones at redhat.com Wed Dec 16 15:47:03 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 16 Dec 2009 15:47:03 +0000 Subject: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide Message-ID: <20091216154703.GA8533@amd.home.annexia.org> Since RPM 4.8 (now in Rawhide / Fedora 13), the external dependency generator that we used to ship with OCaml has now gone upstream into RPM. This is a Good Thing, thanks to the RPM maintainers for adding this. If you own an OCaml library package, then there are some simple adjustments you need to make to your OCaml spec files _in Rawhide_. First of all, remove any lines that are exactly like any of these: %define _use_internal_dependency_generator 0 %global _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh Any remaining calls to ocaml-find-{requires,provides}.sh must be ones which take parameters, and these need to be modified. Change: %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh or: %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh to: %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh and the same for "provides" instead of "requires". For example, if your original spec files contained this block: %define _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh -i Asttypes -i Parsetree %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh then following the rules above it would become: %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh -i Asttypes -i Parsetree If you need any help, please ask on the list or see this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=545116 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tmz at pobox.com Wed Dec 16 15:59:13 2009 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 16 Dec 2009 10:59:13 -0500 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260978148.2528.20.camel@willson.li.ssimo.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> Message-ID: <20091216155913.GW5004@inocybe.localdomain> Simo Sorce wrote: > But for anyone that does not using "master" as the default branch > will be a problem. If you never used git you have to learn a lot of > things anyway. I think the target audience is not mostly git users. Most of the SCM integration will be wrapped up in fedpkg calls anyway. For those who are not long time git users, there seems to be no compelling reason to expose the devel branch as master -- and have to explain or document that "F-n matches origin/F-n, expect for devel, which matches origin/master because that's the default." Those who are long time git users surely ought to know that master is the convention, but is certainly not forced on you by git in any way. Simo, is there a particular problem you are thinking of by not having "master" as the default branch? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes I think I understand everything, then I regain consciousness. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From mattdm at mattdm.org Wed Dec 16 16:06:48 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 16 Dec 2009 11:06:48 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091210203228.GA13743@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> Message-ID: <20091216160648.GA19999@jadzia.bu.edu> On Thu, Dec 10, 2009 at 03:32:29PM -0500, Bill Nottingham wrote: > One notable change that was made is that we were able to simplify the > jobs to the point where the number of login consoles is now configurable, > without editing or removing upstart job definitions. > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; > the default value is "/dev/tty/[1-6]", which means that mingetty > will be started on ttys 1 through 6. Shell globs are accepted. How hard would it be to make this be different in runlevels 3 and 5? I like to have lots in runlevel 3, and few if X is available. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From a.badger at gmail.com Wed Dec 16 16:16:47 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Dec 2009 08:16:47 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260978148.2528.20.camel@willson.li.ssimo.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> Message-ID: <20091216161647.GB26138@clingman.lan> On Wed, Dec 16, 2009 at 10:42:28AM -0500, Simo Sorce wrote: > On Wed, 2009-12-16 at 07:28 -0800, Toshio Kuratomi wrote: > > On Wed, Dec 16, 2009 at 12:33:20AM -0500, Jon Masters wrote: > > > On Tue, 2009-12-15 at 12:35 -0800, Toshio Kuratomi wrote: > > > > > > > master makes a lot of sense from a git perspective. devel (or rawhide) > > > > makes sense from what we actually call the code that that branch eventually > > > > makes. A symlink might alleviate the confusion but it could also add to it. > > > > (For instance, I was operating in the kernel/devel branch but when I want to > > > > git checkout -b devel git gives me a strange error.) > > > > > > > > I don't see a clear answer for what's best here, yet. :-( > > > > > > I think those of us who follow rawhide will quickly realize the change > > > in naming (ok maybe a symbol is vaguely useful, and also needs to be > > > explained somewhere when people inevitably ask) and move on. Conversely, > > > someone who is new or hasn't followed "devel" branches before should > > > just be able to use git how they have elsewhere and it should work. > > > > > > Summary: easier to make life easier for new developers. > > > > > Not all packagers use git elsewhere. > > But for anyone that does not using "master" as the default branch will > be a problem. If you never used git you have to learn a lot of things > anyway. > Yeah, not disagreeing with this at all. Just disagreeing with the idea that following the git conventions is a no brainer that's going to be intuitive to everyone. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Wed Dec 16 16:18:10 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Dec 2009 08:18:10 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215183312.GV5004@inocybe.localdomain> <1260902754.21725.71.camel@localhost.localdomain> Message-ID: <20091216161810.GC26138@clingman.lan> On Wed, Dec 16, 2009 at 10:13:33AM +0100, Andreas Schwab wrote: > Jesse Keating writes: > > > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: > >> > >> My thinking is that we don't use origin/next or origin/maint either > >> and both are common upstream in git and the kernel. > >> > >> While origin/master is common, > > > > origin/master isn't "common", it's the friggin default. Every single > > git repo I interact with has development happening on origin/master. > > It's way more than just "common". > > You can set any branch as default via origin/HEAD, and some do. It is > also easy to make origin/devel an alias for origin/master. So what's an alias? It sounds like a git feature that makes an alternate name for a branch and inside of git the two are 100% equivalent. If that's so, that's a much better solution than a symlink. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nathanael at gnat.ca Wed Dec 16 16:18:31 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 16 Dec 2009 09:18:31 -0700 Subject: packages requiring me to reboot... In-Reply-To: <4B27BE72.5020002@gnat.ca> References: <4B27BE72.5020002@gnat.ca> Message-ID: <4B290857.1000305@gnat.ca> So again today, I see some updates two of which require a full system reboot. nfs-utils and ibus-rawcode. My system seriously needs to be shut down for those to be properly updated? This is what I don't get. nfs-utils never got a system reboot before, it doesn't get one on RHEL/Centos boxes... What requires a reboot here? Again, I don't want the tone of this email to come off as anger, rude or whatever, mainly I'm wondering why so many packages require a reboot, why isn't nfs-utils just restarting any services it has or that depend on it if needed? Is that not reliable? From notting at redhat.com Wed Dec 16 16:23:31 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 Dec 2009 11:23:31 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091216160648.GA19999@jadzia.bu.edu> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> <20091216160648.GA19999@jadzia.bu.edu> Message-ID: <20091216162331.GB16206@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > One notable change that was made is that we were able to simplify the > > jobs to the point where the number of login consoles is now configurable, > > without editing or removing upstart job definitions. > > This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; > > the default value is "/dev/tty/[1-6]", which means that mingetty > > will be started on ttys 1 through 6. Shell globs are accepted. > > How hard would it be to make this be different in runlevels 3 and 5? I like > to have lots in runlevel 3, and few if X is available. Given how it's implemented, you could do something truly disgusting like ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo '/dev/tty2') I'm not sure I really want to *support* people doing that, though. Bill From pmatilai at laiskiainen.org Wed Dec 16 16:34:09 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 16 Dec 2009 18:34:09 +0200 (EET) Subject: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide In-Reply-To: <20091216154703.GA8533@amd.home.annexia.org> References: <20091216154703.GA8533@amd.home.annexia.org> Message-ID: On Wed, 16 Dec 2009, Richard W.M. Jones wrote: > Since RPM 4.8 (now in Rawhide / Fedora 13), the external dependency > generator that we used to ship with OCaml has now gone upstream into > RPM. This is a Good Thing, thanks to the RPM maintainers for adding > this. > > If you own an OCaml library package, then there are some simple > adjustments you need to make to your OCaml spec files _in Rawhide_. > > First of all, remove any lines that are exactly like any of these: > > %define _use_internal_dependency_generator 0 > %global _use_internal_dependency_generator 0 > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh > %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh > %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh > %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh > > Any remaining calls to ocaml-find-{requires,provides}.sh must be ones > which take parameters, and these need to be modified. > > Change: > > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh > or: > %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh > > to: > > %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh Better yet, instead of overriding the __ocaml_requires (and _provides) macros, use the new option passing mechanism. See below... > > and the same for "provides" instead of "requires". > > For example, if your original spec files contained this block: > > %define _use_internal_dependency_generator 0 > %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh -i Asttypes -i Parsetree > %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh > > then following the rules above it would become: > > %global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh -i Asttypes -i Parsetree With the new rpm, all you need to have in the spec for this case is: %global __ocaml_requires_opts -i Asttypes -i Parsetree These will get passed to __ocaml_requires automatically when it runs, and similarly to pass options to provides script, define __ocaml_provides_opts macro to your liking. Oh and this is not ocaml-specific, any of the __foo_requires / __foo_provides helpers accept options in the same manner. - Panu - From skvidal at fedoraproject.org Wed Dec 16 16:43:22 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 11:43:22 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B290857.1000305@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> Message-ID: On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: > So again today, I see some updates two of which require a full system reboot. > > nfs-utils and ibus-rawcode. My system seriously needs to be shut down for > those to be properly updated? This is what I don't get. nfs-utils never got a > system reboot before, it doesn't get one on RHEL/Centos boxes... What > requires a reboot here? Again, I don't want the tone of this email to come > off as anger, rude or whatever, mainly I'm wondering why so many packages > require a reboot, why isn't nfs-utils just restarting any services it has or > that depend on it if needed? Is that not reliable? > you're an experienced user? You're comfortable knowing what does and what does not require a reboot? Then why are you using PK? Disable pk and do the updates directly via yum. Bam - no more requests to reboot. -sv From pjones at redhat.com Wed Dec 16 16:48:19 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 16 Dec 2009 11:48:19 -0500 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> Message-ID: <4B290F53.4000006@redhat.com> On 12/16/2009 11:43 AM, Seth Vidal wrote: > you're an experienced user? You're comfortable knowing what does and > what does not require a reboot? Then why are you using PK? > > Disable pk and do the updates directly via yum. > > Bam - no more requests to reboot. I get what you're saying, and it's kindof a fair point, but there's also some utility to having the system automatically, proactively notify you of updates. -- Peter For some reason it has always seemed to me that the term software engineering contains some very optimistic assumptions about the nature of reality. From skvidal at fedoraproject.org Wed Dec 16 16:51:17 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 11:51:17 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B290F53.4000006@redhat.com> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> Message-ID: On Wed, 16 Dec 2009, Peter Jones wrote: > On 12/16/2009 11:43 AM, Seth Vidal wrote: >> you're an experienced user? You're comfortable knowing what does and >> what does not require a reboot? Then why are you using PK? >> >> Disable pk and do the updates directly via yum. >> >> Bam - no more requests to reboot. > > I get what you're saying, and it's kindof a fair point, but there's also > some utility to having the system automatically, proactively notify you > of updates. And you can do that. Just don't have pk DO the update. There are lots of ways to get notifications of updates not using PK in the system. And again, we're not talking about for the default everyday user. we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. All I'm saying is - we've not taken away any option, the experienced user can do what they want. -sv From cmadams at hiwaay.net Wed Dec 16 16:54:18 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 16 Dec 2009 10:54:18 -0600 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> Message-ID: <20091216165418.GB1153620@hiwaay.net> Once upon a time, Seth Vidal said: > we're talking about the experienced user who is comfortable knowing what > does and does not need a reboot. It seems though that there is a problem with how the "needs a reboot" option is set (and if that is the case, it should be addressed). For example, in the nfs-utils case, what happened to having the %post scriptlet do "service foo condrestart"? Is it impossible to restart the daemons? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at fedoraproject.org Wed Dec 16 16:56:53 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 11:56:53 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <20091216165418.GB1153620@hiwaay.net> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <20091216165418.GB1153620@hiwaay.net> Message-ID: On Wed, 16 Dec 2009, Chris Adams wrote: > Once upon a time, Seth Vidal said: >> we're talking about the experienced user who is comfortable knowing what >> does and does not need a reboot. > > It seems though that there is a problem with how the "needs a reboot" > option is set (and if that is the case, it should be addressed). For > example, in the nfs-utils case, what happened to having the %post > scriptlet do "service foo condrestart"? Is it impossible to restart the > daemons? well nfs restarts have never been likely to work if something is mounted iirc. but I'm not the nfs expert here - maybe steve dickson can better answer this. -sv From rjones at redhat.com Wed Dec 16 17:00:50 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 16 Dec 2009 17:00:50 +0000 Subject: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide In-Reply-To: References: <20091216154703.GA8533@amd.home.annexia.org> Message-ID: <20091216170050.GA9349@amd.home.annexia.org> On Wed, Dec 16, 2009 at 06:34:09PM +0200, Panu Matilainen wrote: > With the new rpm, all you need to have in the spec for this case is: > > %global __ocaml_requires_opts -i Asttypes -i Parsetree > > These will get passed to __ocaml_requires automatically when it runs, > and similarly to pass options to provides script, define > __ocaml_provides_opts macro to your liking. OK, I didn't see that, but that's even better. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 From nathanael at gnat.ca Wed Dec 16 17:08:16 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 16 Dec 2009 10:08:16 -0700 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> Message-ID: <4B291400.1050200@gnat.ca> On 12/16/2009 09:51 AM, Seth Vidal wrote: > > > On Wed, 16 Dec 2009, Peter Jones wrote: > >> On 12/16/2009 11:43 AM, Seth Vidal wrote: >>> you're an experienced user? You're comfortable knowing what does and >>> what does not require a reboot? Then why are you using PK? >>> >>> Disable pk and do the updates directly via yum. >>> >>> Bam - no more requests to reboot. >> >> I get what you're saying, and it's kindof a fair point, but there's also >> some utility to having the system automatically, proactively notify you >> of updates. > > And you can do that. Just don't have pk DO the update. > > There are lots of ways to get notifications of updates not using PK in > the system. > > And again, we're not talking about for the default everyday user. > > we're talking about the experienced user who is comfortable knowing what > does and does not need a reboot. > > All I'm saying is - we've not taken away any option, the experienced > user can do what they want. yeah, I totally get what you mean. I just feel like there are more and more reboot requests because that is easier. Obviously I know when/if I need to reboot based on what I'm running. However I'm questioning the number of packages requesting a reboot I guess. Maybe this is a feature that needs to be addressed in the rpm layer or something so that upgrades can have multiple effects with regards to needing a reboot. I'm not sure how PK gets the request to reboot from a package, but I'm wondering about it. For example, why aren't some of the packages simply a 'log out of X', or 'restart app', or ??? PK could provide that information. However, as it stands, if firefox is updated, I would (under the current way this seems to work) fully expect it to ask for my system to reboot, instead of closing FF and starting it again. I'm not sure if it does or not, but it seems like a package basically has complex upgrade issues, so we reboot. Are there other tags packages can have other than reboot? Should there be? etc etc.. I am an advanced user, and manage a handful of servers and workstations, so yes I don't have to reboot. I'm just wondering about the reboot 'feature' usage patterns I'm seeing. -- Nathanael From skvidal at fedoraproject.org Wed Dec 16 17:11:14 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 12:11:14 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B291400.1050200@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> Message-ID: On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: > Maybe this is a feature that needs to be addressed in the rpm layer or > something so that upgrades can have multiple effects with regards to needing > a reboot. I'm not sure how PK gets the request to reboot from a package, but > I'm wondering about it. It doesn't get it from the pkg. It uses the updateinfo.xml metadata that is generated by our update processing system that is called 'bodhi'. You can see this data using the yum-security plugin. > seems like a package basically has complex upgrade issues, so we reboot. Are > there other tags packages can have other than reboot? Should there be? etc > etc.. No. > I am an advanced user, and manage a handful of servers and workstations, so > yes I don't have to reboot. I'm just wondering about the reboot 'feature' > usage patterns I'm seeing. And again. PK is not designed for you. The 'reboot often' solution is not FOR you. I said this earlier on another subject but you shouldn't be shocked that camels are slow swimmers. -sv From tgl at redhat.com Wed Dec 16 17:15:37 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 16 Dec 2009 12:15:37 -0500 Subject: Fedora update submission page broken for multiple packages Message-ID: <5926.1260983737@sss.pgh.pa.us> I tried to submit an update for both the fc12 and fc11 versions of postgresql. It did not work; I had to file them as separate updates. I'm pretty sure it used to work --- is my memory failing me, or is this new breakage? If the latter, where do I file bugs against the submission webpage? regards, tom lane From lsof at nodata.co.uk Wed Dec 16 17:16:20 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 Dec 2009 18:16:20 +0100 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> Message-ID: <4B2915E4.40107@nodata.co.uk> Am 2009-12-16 17:51, schrieb Seth Vidal: > > > On Wed, 16 Dec 2009, Peter Jones wrote: > >> On 12/16/2009 11:43 AM, Seth Vidal wrote: >>> you're an experienced user? You're comfortable knowing what does and >>> what does not require a reboot? Then why are you using PK? >>> >>> Disable pk and do the updates directly via yum. >>> >>> Bam - no more requests to reboot. >> >> I get what you're saying, and it's kindof a fair point, but there's also >> some utility to having the system automatically, proactively notify you >> of updates. > > And you can do that. Just don't have pk DO the update. > > There are lots of ways to get notifications of updates not using PK in > the system. > > And again, we're not talking about for the default everyday user. > > we're talking about the experienced user who is comfortable knowing what > does and does not need a reboot. > > All I'm saying is - we've not taken away any option, the experienced > user can do what they want. > > -sv > True, but the default should be sensible. From nathanael at gnat.ca Wed Dec 16 17:16:48 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 16 Dec 2009 10:16:48 -0700 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> Message-ID: <4B291600.3060801@gnat.ca> On 12/16/2009 10:11 AM, Seth Vidal wrote: > > > On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: > >> Maybe this is a feature that needs to be addressed in the rpm layer or >> something so that upgrades can have multiple effects with regards to >> needing a reboot. I'm not sure how PK gets the request to reboot from >> a package, but I'm wondering about it. > > It doesn't get it from the pkg. It uses the updateinfo.xml metadata that > is generated by our update processing system that is called 'bodhi'. > > You can see this data using the yum-security plugin. Cool. > >> seems like a package basically has complex upgrade issues, so we >> reboot. Are there other tags packages can have other than reboot? >> Should there be? etc etc.. > > No. The reason for this is that PKs target audience is not someone like me, and as such no need to provide different messages per package? > >> I am an advanced user, and manage a handful of servers and >> workstations, so yes I don't have to reboot. I'm just wondering about >> the reboot 'feature' usage patterns I'm seeing. > > And again. PK is not designed for you. The 'reboot often' solution is > not FOR you. > > I said this earlier on another subject but you shouldn't be shocked that > camels are slow swimmers. So basically, PK is designed for the non-experienced users, as such everything it does is dumbed down, and experienced users should just ignore it, using other tools to keep their system up to date. So one last question then, in the case of nfs-utils, (ignoring for now any nfs specific restart/condrestart issues). The packaging guidlines will continue to require that a post update script does what is sensible for an update, and not just depend on the admin rebooting their server? -- Nathanael From mkkp4x4 at gmail.com Wed Dec 16 17:17:12 2009 From: mkkp4x4 at gmail.com (=?ISO-8859-2?Q?Micha=B3_Piotrowski?=) Date: Wed, 16 Dec 2009 18:17:12 +0100 Subject: safe way to standby sata hdd? In-Reply-To: <4B290042.6010609@redhat.com> References: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> <4B290042.6010609@redhat.com> Message-ID: <596b53e0912160917h4ac17b6fh99f4d02e46b901ec@mail.gmail.com> 2009/12/16 Eric Sandeen : > Micha? Piotrowski wrote: >> Hi, >> >> I've got a home database/symfony env/etc../file server. It's based on >> Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power >> connected through Sata. First drive has / and /home filesystem, second >> has /home/samba4. On the first drive there are two directories >> /home/samba2 and /home/samba3 where I'm mounting ecryptfs. >> /home/samba4 is also crypted by default. >> >> I'm wondering if there is a safe way for such configuration to put >> second harddrive into sleep (or both drives) after some idle time? >> After some googling I've found some resolutions (haven't tested any of >> these yet): >> - hdparm -S > > I use this for the data drive on my mythbox. ?I just put this in my > /etc/rc.local - > > # Spin down in 1 hours idle time > hdparm -S 240 /dev/sda Have you used this for a disk with your rootfs? > > (yeah, oddly, sda is not my boot drive) :) > >> - sdparm --set=STANDBY >> - and laptop_tools >> >> I'm really not convinced that these methods are safe for my >> configuration. Anyone have tried this before? > > Yep. ?What kind of safety are you worried about? I know that ecryptfs is just fs stack on top of my ext3 partition, but still I care about data integrity. > ?It should just work, > although you want a long enough idle time that you're not constantly > spinning the disk up and down. Actually /home/samba4 is not mounted all the time - I'm umountig this fs when I'm not using it. I'm wondering if there will be any problems with data integrity when I forgot to umount ecryptfs and disk will be stopped. > > Is there any nice user-friendly frontend to set this? ?It'd be nice > to expose more power management choices to the users (for anything > that can't be easily defaulted, that is). > > -Eric Regards, Michal From skvidal at fedoraproject.org Wed Dec 16 17:21:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 12:21:46 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B2915E4.40107@nodata.co.uk> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> Message-ID: On Wed, 16 Dec 2009, nodata wrote: >> >> we're talking about the experienced user who is comfortable knowing what >> does and does not need a reboot. >> >> All I'm saying is - we've not taken away any option, the experienced >> user can do what they want. >> >> -sv >> > > True, but the default should be sensible. And the default is sensible for the inexperienced user: Don't try to explain to the user how to restart the apps individually, tell them to bounce the box and it will be the right version when it comes back. -sv From a.badger at gmail.com Wed Dec 16 17:23:52 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Dec 2009 09:23:52 -0800 Subject: Fedora update submission page broken for multiple packages In-Reply-To: <5926.1260983737@sss.pgh.pa.us> References: <5926.1260983737@sss.pgh.pa.us> Message-ID: <20091216172351.GD26138@clingman.lan> On Wed, Dec 16, 2009 at 12:15:37PM -0500, Tom Lane wrote: > I tried to submit an update for both the fc12 and fc11 versions of > postgresql. It did not work; I had to file them as separate updates. > I'm pretty sure it used to work --- is my memory failing me, or is > this new breakage? If the latter, where do I file bugs against the > submission webpage? > It definitely worked prior to the move this weekend. Do you have any error messages or other information to help track this down? There are two places that you could file this: https://fedorahosted.org/bodhi https://fedorahosted.org/fedora-infrastructure -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From skvidal at fedoraproject.org Wed Dec 16 17:28:18 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 12:28:18 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B291600.3060801@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> <4B291600.3060801@gnat.ca> Message-ID: On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: >>> seems like a package basically has complex upgrade issues, so we >>> reboot. Are there other tags packages can have other than reboot? >>> Should there be? etc etc.. >> >> No. > > The reason for this is that PKs target audience is not someone like me, and > as such no need to provide different messages per package? No, the reason for this is there is not more to go on, yet. I would love to require more detailed info on the update including if it is an important/trivial/security/packaging/upstream-update or what not fix. Hands are needed to help advance this. Care to lend one? >> >> And again. PK is not designed for you. The 'reboot often' solution is >> not FOR you. >> >> I said this earlier on another subject but you shouldn't be shocked that >> camels are slow swimmers. > > So basically, PK is designed for the non-experienced users, as such > everything it does is dumbed down, and experienced users should just ignore > it, using other tools to keep their system up to date. If what the experienced user wants to do is not something that PK can do or can be configured to do then, yes, disable it and move along. Hell, same thing is true of yum. If you really know what you're doing and yum is in your way then stop using it. > So one last question then, in the case of nfs-utils, (ignoring for now any > nfs specific restart/condrestart issues). The packaging guidlines will > continue to require that a post update script does what is sensible for an > update, and not just depend on the admin rebooting their server? the post scripts do what is sensible, on many occasions restarting the daemon will not ensure that the new sw is in use and in other occasions there is no graceful way to restart. so your options are: 1. don't restart but ask the user to 2. restart and drop whatever connections are active. neither are great. -sv From lsof at nodata.co.uk Wed Dec 16 17:29:46 2009 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 Dec 2009 18:29:46 +0100 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> Message-ID: <4B29190A.5060504@nodata.co.uk> Am 2009-12-16 18:21, schrieb Seth Vidal: > > > On Wed, 16 Dec 2009, nodata wrote: > >>> >>> we're talking about the experienced user who is comfortable knowing what >>> does and does not need a reboot. >>> >>> All I'm saying is - we've not taken away any option, the experienced >>> user can do what they want. >>> >>> -sv >>> >> >> True, but the default should be sensible. > > And the default is sensible for the inexperienced user: > > Don't try to explain to the user how to restart the apps individually, > tell them to bounce the box and it will be the right version when it > comes back. > > -sv > On the other hand I think requiring more reboots than Windows is a bad thing... From schwab at redhat.com Wed Dec 16 17:33:39 2009 From: schwab at redhat.com (Andreas Schwab) Date: Wed, 16 Dec 2009 18:33:39 +0100 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <20091216161810.GC26138@clingman.lan> (Toshio Kuratomi's message of "Wed, 16 Dec 2009 08:18:10 -0800") References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215183312.GV5004@inocybe.localdomain> <1260902754.21725.71.camel@localhost.localdomain> <20091216161810.GC26138@clingman.lan> Message-ID: Toshio Kuratomi writes: > On Wed, Dec 16, 2009 at 10:13:33AM +0100, Andreas Schwab wrote: >> Jesse Keating writes: >> >> > On Tue, 2009-12-15 at 13:33 -0500, Todd Zullinger wrote: >> >> >> >> My thinking is that we don't use origin/next or origin/maint either >> >> and both are common upstream in git and the kernel. >> >> >> >> While origin/master is common, >> > >> > origin/master isn't "common", it's the friggin default. Every single >> > git repo I interact with has development happening on origin/master. >> > It's way more than just "common". >> >> You can set any branch as default via origin/HEAD, and some do. It is >> also easy to make origin/devel an alias for origin/master. > > So what's an alias? See git-symbolic-ref(1). HEAD is an example. > If that's so, that's a much better solution than a symlink. They used to be implemented with a symlink. Andreas. -- Andreas Schwab, schwab at redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." From skvidal at fedoraproject.org Wed Dec 16 17:34:13 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 12:34:13 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B29190A.5060504@nodata.co.uk> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> Message-ID: On Wed, 16 Dec 2009, nodata wrote: > Am 2009-12-16 18:21, schrieb Seth Vidal: >> >> >> On Wed, 16 Dec 2009, nodata wrote: >> >>>> >>>> we're talking about the experienced user who is comfortable knowing what >>>> does and does not need a reboot. >>>> >>>> All I'm saying is - we've not taken away any option, the experienced >>>> user can do what they want. >>>> >>>> -sv >>>> >>> >>> True, but the default should be sensible. >> >> And the default is sensible for the inexperienced user: >> >> Don't try to explain to the user how to restart the apps individually, >> tell them to bounce the box and it will be the right version when it >> comes back. >> >> -sv >> > > On the other hand I think requiring more reboots than Windows is a bad > thing... Then I can think of a couple of solutions to this problem: 1. Have fewer update pushes per release - this is something I'm actively advocating and I think is possible 2. Match up more updates to a specific running app so we can see if the reboot is really necessary at all. - something else I've wrriten some code in support of. How would you like to help in these goals? -sv From nathanael at gnat.ca Wed Dec 16 17:36:09 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 16 Dec 2009 10:36:09 -0700 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> <4B291600.3060801@gnat.ca> Message-ID: <4B291A89.30102@gnat.ca> On 12/16/2009 10:28 AM, Seth Vidal wrote: > > > On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: > >>>> seems like a package basically has complex upgrade issues, so we >>>> reboot. Are there other tags packages can have other than reboot? >>>> Should there be? etc etc.. >>> >>> No. >> >> The reason for this is that PKs target audience is not someone like >> me, and as such no need to provide different messages per package? > > No, the reason for this is there is not more to go on, yet. I would love > to require more detailed info on the update including if it is an > important/trivial/security/packaging/upstream-update or what not fix. > > > Hands are needed to help advance this. Care to lend one? Yes. I'm attempting to become more involved. I've submitted my first package, and am going through the review process. That doesn't help in this particular case, but I am not complaining for the sake of complaining. I want to help. I fully realize what I use daily for work is the result of many people like you who build this stuff. Thus my desire to become part of it. What can I do here? > the post scripts do what is sensible, on many occasions restarting the > daemon will not ensure that the new sw is in use and in other occasions > there is no graceful way to restart. > > so your options are: > > 1. don't restart but ask the user to > 2. restart and drop whatever connections are active. > > neither are great. For sure. From skvidal at fedoraproject.org Wed Dec 16 17:38:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 16 Dec 2009 12:38:46 -0500 (EST) Subject: packages requiring me to reboot... In-Reply-To: <4B291A89.30102@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> <4B291600.3060801@gnat.ca> <4B291A89.30102@gnat.ca> Message-ID: On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: >> >> >> Hands are needed to help advance this. Care to lend one? > > Yes. I'm attempting to become more involved. I've submitted my first package, > and am going through the review process. That doesn't help in this particular > case, but I am not complaining for the sake of complaining. I want to help. I > fully realize what I use daily for work is the result of many people like you > who build this stuff. Thus my desire to become part of it. > > What can I do here? How much python do you know? We need some time spent on the updateinfo.xml and what information we provide there and tying this in with what info is required from packagers submitting updates to their pkgs. Another good angle to approach is to talk to the folks in fedora-qa and see where they can use a hand. -sv From nathanael at gnat.ca Wed Dec 16 17:41:12 2009 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Wed, 16 Dec 2009 10:41:12 -0700 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> <4B291600.3060801@gnat.ca> <4B291A89.30102@gnat.ca> Message-ID: <4B291BB8.5080303@gnat.ca> On 12/16/2009 10:38 AM, Seth Vidal wrote: > > > On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: >>> >>> >>> Hands are needed to help advance this. Care to lend one? >> >> Yes. I'm attempting to become more involved. I've submitted my first >> package, and am going through the review process. That doesn't help in >> this particular case, but I am not complaining for the sake of >> complaining. I want to help. I fully realize what I use daily for work >> is the result of many people like you who build this stuff. Thus my >> desire to become part of it. >> >> What can I do here? > > How much python do you know? We need some time spent on the > updateinfo.xml and what information we provide there and tying this in > with what info is required from packagers submitting updates to their pkgs. Unfortunately very very little. I can program in C/C++ and PHP. I've used python years ago. However I can learn if I have to. > Another good angle to approach is to talk to the folks in fedora-qa and > see where they can use a hand. Will do. From tgl at redhat.com Wed Dec 16 18:13:05 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 16 Dec 2009 13:13:05 -0500 Subject: Fedora update submission page broken for multiple packages In-Reply-To: <20091216172351.GD26138@clingman.lan> References: <5926.1260983737@sss.pgh.pa.us> <20091216172351.GD26138@clingman.lan> Message-ID: <6835.1260987185@sss.pgh.pa.us> Toshio Kuratomi writes: > On Wed, Dec 16, 2009 at 12:15:37PM -0500, Tom Lane wrote: >> I tried to submit an update for both the fc12 and fc11 versions of >> postgresql. It did not work; I had to file them as separate updates. >> I'm pretty sure it used to work --- is my memory failing me, or is >> this new breakage? If the latter, where do I file bugs against the >> submission webpage? >> > It definitely worked prior to the move this weekend. Do you have any error > messages or other information to help track this down? Thinking back on it, it was probably at least partly user error, but there should have been a way to recover. > There are two places that you could file this: > https://fedorahosted.org/bodhi Thanks for the pointer, filed at https://fedorahosted.org/bodhi/ticket/374 regards, tom lane From paul at dishone.st Wed Dec 16 18:29:17 2009 From: paul at dishone.st (Paul Jakma) Date: Wed, 16 Dec 2009 18:29:17 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091216150748.GA15217@srcf.ucam.org> References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> Message-ID: On Wed, 16 Dec 2009, Matthew Garrett wrote: > "It works for me" is a poor standard of support. There must be something transmogrifying my emails before it reaches other subscribers of this list, either that or I am being unreasonable in thinking that by asking /if/ Fedora would consider *supporting* this configuration (i.e. in the future) that it would be clear that: - I do not expect it to be supported already - I am not complaining about software not working quite right now E.g. I was impressed at how yum pretty much works (with minor tweaking to override which arch it think it's running on). I didn't mean to complain or whinge or intend for people to think I had silly expectations of this being supported already. Apologies if I did and/or if that's how it came across. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: ASHes to ASHes, DOS to DOS. From debarshi.ray at gmail.com Wed Dec 16 18:55:36 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 16 Dec 2009 20:55:36 +0200 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> Message-ID: <3170f42f0912161055s3bd843bchc9022d19224cd8c4@mail.gmail.com> >> "It works for me" is a poor standard of support. > > There must be something transmogrifying my emails before it reaches other > subscribers of this list, either that or I am being unreasonable in thinking He is just pointing out that there is lot more work to do than you think. In other words he is contesting your claim that "The kernel side apparently works fine AFAICT". Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From mzerqung at 0pointer.de Wed Dec 16 18:58:05 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 16 Dec 2009 19:58:05 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> Message-ID: <20091216185805.GH1718@tango.0pointer.de> On Wed, 09.12.09 13:51, Christof Damian (christof at damian.net) wrote: > > On Tue, Dec 8, 2009 at 12:59, Tomasz Torcz wrote: > > On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: > > ?pavucontrol is regarded as advance tool, but also partly > > obsolete. Current gnome-volume-control superseded most of > > its functionality: controlling different streams volume, > > switching profile, outputs, fallback devices. > > I am curious: If pavucontrol is obsolete, is there some other tool to > tell skype to use headsets, while rhythmbox uses the speakers? This is about the only feature still only available in pavucontrol, that we'd like to support in g-v-c as well. During GUADEC we discussed a few possible designs for this, so hopefully this will come soon. > pavucontrol currently crashes (and pulseaudio) for me on one machine > and I need this functionality. File a bug. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mjg at redhat.com Wed Dec 16 19:16:47 2009 From: mjg at redhat.com (Matthew Garrett) Date: Wed, 16 Dec 2009 19:16:47 +0000 Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: References: <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> Message-ID: <20091216191647.GA20799@srcf.ucam.org> On Wed, Dec 16, 2009 at 06:29:17PM +0000, Paul Jakma wrote: > On Wed, 16 Dec 2009, Matthew Garrett wrote: > >> "It works for me" is a poor standard of support. > > There must be something transmogrifying my emails before it reaches > other subscribers of this list, either that or I am being unreasonable in > thinking that by asking /if/ Fedora would consider *supporting* this > configuration (i.e. in the future) that it would be clear that: > - I am not complaining about software not working quite right now The problem here is that you appear to be massively underestimating the amount of work that would be required to actually support this configuration. We'd need to audit every ioctl entry point, every file in proc and every sysfs attribute. We'd need to port every application that uses vm86 over to using x86emu. We'd need to add, test and support a 32-to-64 bit cross building toolchain. yum would need some amount of work that Seth has implied is significant. That's a lot of work for marginal benefits, and nobody seems interested in stepping up to do that work. -- Matthew Garrett | mjg59 at srcf.ucam.org From mattdm at mattdm.org Wed Dec 16 19:35:34 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 16 Dec 2009 14:35:34 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091216162331.GB16206@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> <20091216160648.GA19999@jadzia.bu.edu> <20091216162331.GB16206@nostromo.devel.redhat.com> Message-ID: <20091216193534.GA2220@jadzia.bu.edu> On Wed, Dec 16, 2009 at 11:23:31AM -0500, Bill Nottingham wrote: > > How hard would it be to make this be different in runlevels 3 and 5? I like > > to have lots in runlevel 3, and few if X is available. > Given how it's implemented, you could do something truly disgusting like > ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo '/dev/tty2') > I'm not sure I really want to *support* people doing that, though. You mean, you don't like the idea of having different numbers of consoles running in different runlevels, or you don't like the abusing-shell-script-as-config-file thing? It's not a big deal, but it's something that's trivially done in traditional inittab. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From paul at dishone.st Wed Dec 16 19:35:49 2009 From: paul at dishone.st (Paul Jakma) Date: Wed, 16 Dec 2009 19:35:49 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <3170f42f0912161055s3bd843bchc9022d19224cd8c4@mail.gmail.com> References: <3170f42f0912140326h41f3ebc1j7c218ee1a2944d70@mail.gmail.com> <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> <3170f42f0912161055s3bd843bchc9022d19224cd8c4@mail.gmail.com> Message-ID: On Wed, 16 Dec 2009, Debarshi Ray wrote: > He is just pointing out that there is lot more work to do than you > think. In other words he is contesting your claim that "The kernel > side apparently works fine AFAICT". Well, I don't really know how to else to counter "there may be unknown bugs". Kernel sub-system interfaces generally are well-designed and specified (i.e. explicit widths of fields). Booting a system and using it for a while exercises many of the important ones. Could there be bugs in some lesser-used, oddball interface? Of course (and I am sure there are - I think I gave an example in a thread earlier this year). They're likely to reasonably trivial bugs though (oversights in the interface specification, e.g. a 'long' instead of a __u32, etc). If there really are interfaces that are so messed up that they'd be hard to fix up, then that's probably a warning sign that the code may have deeper, bigger problems. People who run into such bugs can always go back to a 32bit kernel (standard or PAE) until it's fixed, if it even affects them. They're put back in the same position as they're in now, which I'm sure must be acceptable. Anyway.. I'll try look into this again later next year, and see if I can fix the "bugs" (in the RFE sense for yum, libvirt) I found. Was simply hoping to get other people interested in 32-on-64, no more or less. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: "Do you believe in intuition?" "No, but I have a strange feeling that someday I will." From ottohaliburton at tx.rr.com Wed Dec 16 20:43:43 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Wed, 16 Dec 2009 14:43:43 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B29190A.5060504@nodata.co.uk> References: <4B27BE72.5020002@gnat.ca><4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> Message-ID: <1821AEED6D484EB89770040DD7A3842B@ottoPC> ----- Original Message ----- From: "nodata" To: "Development discussions related to Fedora" Sent: Wednesday, December 16, 2009 11:29 AM Subject: Re: packages requiring me to reboot... > Am 2009-12-16 18:21, schrieb Seth Vidal: >> >> >> On Wed, 16 Dec 2009, nodata wrote: >> >>>> >>>> we're talking about the experienced user who is comfortable knowing >>>> what >>>> does and does not need a reboot. >>>> >>>> All I'm saying is - we've not taken away any option, the experienced >>>> user can do what they want. >>>> >>>> -sv >>>> >>> >>> True, but the default should be sensible. >> >> And the default is sensible for the inexperienced user: >> >> Don't try to explain to the user how to restart the apps individually, >> tell them to bounce the box and it will be the right version when it >> comes back. >> >> -sv >> > > On the other hand I think requiring more reboots than Windows is a bad > thing... > windows update will automatically reboot your system when it automatically updates it windows tried the optional stuff but now almost every case it requires a restart. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From notting at redhat.com Wed Dec 16 21:16:15 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 Dec 2009 16:16:15 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091216193534.GA2220@jadzia.bu.edu> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> <20091216160648.GA19999@jadzia.bu.edu> <20091216162331.GB16206@nostromo.devel.redhat.com> <20091216193534.GA2220@jadzia.bu.edu> Message-ID: <20091216211615.GD21037@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > Given how it's implemented, you could do something truly disgusting like > > ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo '/dev/tty2') > > I'm not sure I really want to *support* people doing that, though. > > You mean, you don't like the idea of having different numbers of consoles > running in different runlevels, or you don't like the > abusing-shell-script-as-config-file thing? The latter. :) Bill From przemek.klosowski at nist.gov Wed Dec 16 21:30:00 2009 From: przemek.klosowski at nist.gov (Przemek Klosowski) Date: Wed, 16 Dec 2009 16:30:00 -0500 Subject: packages requiring me to reboot... In-Reply-To: <1821AEED6D484EB89770040DD7A3842B@ottoPC> References: <4B27BE72.5020002@gnat.ca><4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> <1821AEED6D484EB89770040DD7A3842B@ottoPC> Message-ID: <4B295158.8030703@nist.gov> On 12/16/2009 03:43 PM, Otto Haliburton wrote: > windows update will automatically reboot your system when it automatically > updates it windows tried the optional stuff but now almost every case it requires a > restart. Even when it asks, it does that with a modal focus-grabbing dialog window. I was once working on an important server, and was about to click OK on one of my dialog boxes, when a windows update confirmation popped up conveniently located so that my click went to IT, rebooting the server. The queen was not amused. HOWEVER, just because Windows suck doesn't mean that Linux should suck too. My own preference would be a more discriminating dialog that offers three possibilities: 'do nothing', 'bounce the service/application' and 'reboot'. From jcm at redhat.com Wed Dec 16 21:38:05 2009 From: jcm at redhat.com (Jon Masters) Date: Wed, 16 Dec 2009 16:38:05 -0500 Subject: packages requiring me to reboot... In-Reply-To: <4B295158.8030703@nist.gov> References: <4B27BE72.5020002@gnat.ca><4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> <1821AEED6D484EB89770040DD7A3842B@ottoPC> <4B295158.8030703@nist.gov> Message-ID: <1260999485.2793.24.camel@tonnant> On Wed, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote: > HOWEVER, just because Windows suck doesn't mean that Linux should suck > too. My own preference would be a more discriminating dialog > that offers three possibilities: 'do nothing', 'bounce the > service/application' and 'reboot'. Yup, +1 Jon. From awilliam at redhat.com Wed Dec 16 21:50:32 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 16 Dec 2009 21:50:32 +0000 Subject: FUDConF13 videos In-Reply-To: <20091215153139.GA3091@auslistsprd01.us.dell.com> References: <20091215153139.GA3091@auslistsprd01.us.dell.com> Message-ID: <1261000232.3328.12.camel@vaio.local.net> On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote: > 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins > vs. Developers love-in. I'm grateful to whoever shot this, but > I've complete blanked on who it was now. I'll be glad to give you > attribution, please remind me! > > http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg > > If anyone else has video or audio from this or other Fedora events > you'd care to share, please contact me and I'll help you get it into > proper ogg format, tagged, and posted to Fedora Infrastructure servers > for distribution. That was me. :) I actually think Remy DeCausemaker was sitting in that talk with his little recorder box - I don't know if it's only a voice recorder, or also video. But he may have the whole thing. Have you contacted him? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From waustin at speakeasy.net Wed Dec 16 21:54:35 2009 From: waustin at speakeasy.net (William W. Austin) Date: Wed, 16 Dec 2009 21:54:35 -0000 Subject: kernel/accounting question ... Message-ID: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> (I know that this question might be more reasonable on a kernel list, but a while back I posted the question twice and got no answers.) The acct struct is defined in /usr/include/sys/acct.h includes both ac_io and ac_rw for bytes transferred and blocks read or written, respectively. Fair and good - works (on paper) similarly to unix, solaris, hp-ux, etc. However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw (blocks) are always set to 0 by these two lines: ac.ac_io = encode_comp_t(0 /* current->io_usage */); ac.ac_rw = encode_comp_t(ac.ac_io / 1024); For most purposes, this probably wouldn't be an issue, but I also do extensive performance analysis on several platforms and have written a fairly compresive accounting package (as a wraparound for psacct or as a standalone) including both an improved acctcom and a built-in reporter for it. Does anyone know wby the kernel zero's out the bytes transferred data? (Overhead comes to mind.) Not that it makes a huge differnce for my purposes (I had to write some wraparound code to make a "best-guestimate" about the data I'm missing), but curiosity is bugging me now. When I compile my program on other OS's I get useful data for char and block i/o and I'd like to find out whether there is something obvious that I'm just totally missing here...). Thanks -- william w. austin waustin at speakeasy.net "life is just another phase i'm going through. this time, anyway ..." From pjones at redhat.com Wed Dec 16 22:08:10 2009 From: pjones at redhat.com (Peter Jones) Date: Wed, 16 Dec 2009 17:08:10 -0500 Subject: kernel/accounting question ... In-Reply-To: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> References: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> Message-ID: <4B295A4A.6010703@redhat.com> On 10/19/2006 08:23 AM, William W. Austin wrote: > Not that I've got an answer for your question, but you might want to tell your computer that it's not 2006. -- Peter When privacy is outlawed only outlaws will have privacy. -- Zimmermann From kevin at scrye.com Wed Dec 16 22:10:07 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 16 Dec 2009 15:10:07 -0700 Subject: kernel/accounting question ... In-Reply-To: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> References: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> Message-ID: <20091216151007.1e6e3d16@ohm.scrye.com> On Thu, 19 Oct 2006 08:23:49 -0400 "William W. Austin" wrote: > > (I know that this question might be more reasonable on a kernel > list, but a while back I posted the question twice and got no > answers.) Possibly because the system you are sending email from thinks it's 2006, so many people wouldn't notice your old post if they are sorting by date? Fix your date and try the kernel list again? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From awilliam at redhat.com Wed Dec 16 22:26:36 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 16 Dec 2009 22:26:36 +0000 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260978148.2528.20.camel@willson.li.ssimo.org> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215094921.GC29705@amd.home.annexia.org> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> Message-ID: <1261002396.3328.14.camel@vaio.local.net> On Wed, 2009-12-16 at 10:42 -0500, Simo Sorce wrote: > But for anyone that does not using "master" as the default branch will > be a problem. If you never used git you have to learn a lot of things > anyway. I would hope you don't have to. To be a Fedora maintainer you hardly have to know a thing about CVS, after all - you can do all common operations via the Makefiles. I would hope the fpkg (or whatever) tool will do the same for the git-based system; if not, I'd consider that a significant regression. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ottohaliburton at tx.rr.com Wed Dec 16 22:35:04 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Wed, 16 Dec 2009 16:35:04 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B295158.8030703@nist.gov> Message-ID: <9624660CA55D47BCADED79701D72FDD0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Przemek Klosowski > Sent: Wednesday, December 16, 2009 15:30 > To: fedora-devel-list at redhat.com > Subject: Re: packages requiring me to reboot... > > On 12/16/2009 03:43 PM, Otto Haliburton wrote: > > > windows update will automatically reboot your system when it > automatically > > updates it windows tried the optional stuff but now almost every case it > requires a > > restart. > > Even when it asks, it does that with a modal focus-grabbing dialog > window. I was once working on an important server, and was about to > click OK on one of my dialog boxes, when a windows update confirmation > popped up conveniently located so that my click went to IT, rebooting > the server. The queen was not amused. > > HOWEVER, just because Windows suck doesn't mean that Linux should suck > too. My own preference would be a more discriminating dialog > that offers three possibilities: 'do nothing', 'bounce the > service/application' and 'reboot'. There is always the circle jerk argument, well linux reboots more than windows, no, windows abandoned the mandatory restart to end up reinstating it. Then, because windows restarts after update sucks, so linux doesn't need to suck like windows. Rebooting after updates is not a trivial matter, if you are a expert don't use PackageKit. Even tho it notifies you of updates doesn't mean you need to use it, there is synaptic, yum extender, yum, etc. none of those require you to reboot, also I don't think that PackageKit mandates a reboot, just asks and you can cancel out of it, I don't remember now, but I think so I know it flags the packages that cause a restart. Anyway nothing will be solved in this thread, for those of us that have been burned by failing to restart, and those that think that rebooting after updates is trivial, will continue to do the things that are required for us to be satisfied in a update. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From waustin at speakeasy.net Wed Dec 16 22:54:30 2009 From: waustin at speakeasy.net (William W. Austin) Date: Wed, 16 Dec 2009 22:54:30 -0000 Subject: acctcom for linux Message-ID: <1178023106l.10587l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> I recently made several updates to a Linux version of of acctcom (actually another accounting add-on package) which I've been using for several years, and one of the people testing it asked a question which I cannot answer. I'm hoping that someone on this list can give me some info. I have previously (over a year ago) asked on both this and a couple of kernel lists (several times there) about this issue, but nobody has ever answered. So if you have any info about this, I'd really appreciate it. As in many (all?) previous Linux kernels, the struct acct (defined in /usr/include/sys/acct.h) has members ac_io and ac_rw which are presumably counts of characters transferred and blocks read/written respectively. However, in the kernel code, the ac_io is set to 0 and the ac_rw gets set to (ac_io/512) or some such - it is set to 0 as well (and thus these are always reported as 0 in process accounting records. not good if you're trying to measure them...). Does anybody know why this is done that way? A long time ago (IIRC late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the kernel code but was not successful (I finally produced a bootable kernel, but it was unstable. Then I changed jobs, got swamped at work, and eventually gave up). As I said above, I have previously asked about this issue without success, and I have essentially given up changing or "fixing" it. But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's just too much work for too little added value), I'd really appreciate knowing the reason. Curiosity and the cat and all that ... Thanks - Bill -- william w. austin waustin at speakeasy.net "life is just another phase i'm going through. this time, anyway ..." From gmaxwell at gmail.com Wed Dec 16 23:01:42 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 16 Dec 2009 18:01:42 -0500 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> Message-ID: On Wed, Dec 16, 2009 at 11:43 AM, Seth Vidal wrote: > you're an experienced user? You're comfortable knowing what does and what > does not require a reboot? Then why are you using PK? > > Disable pk and do the updates directly via yum. > > Bam - no more requests to reboot. This is a completely bogus rationale but one I commonly hear on this list. I, and many other fedora users would be quite *capable* of running our systems with any help of a distribution, we could go and fetch from source and do all the integration ourselves... ...but we'd actually like to get some work done using our computers and don't want to burn our lives away playing master-of-my-own-distro, though we're willing to spend some time contributing to a shared effort to build a good distribution for many. In exchange for not having to personally micro-manage things, we're willing to tolerate some things being configured in violation of our own preferences or aesthetics, or even a few things being outright broken, but that doesn't mean that it's not important for it to work right. Yes, I'm quite capable of executing some big manual process or changing packagekit to behave like I want. But every such action has costs, it takes time and effort which usually has to be repeated every upgrade. The non-standard configuration carries the risk of triggering bugs in other system components, breaking the upgrade process, etc. The gratuitous reboots are harmful to all users. They diminish a significant advantage our systems can have compared to alternatives like Microsoft Windows. They discourage the reporting of bugs in applications? "System acting weird? Just restart!". When triggered at inconvenient times they can cause significant harm by interrupting people's work. Yes? users with more expertise are more likely to complain about this, but thats not reason to dismiss the issue. If there were truly a disconnect here betweens the needs of the novices and those of the expert users you could argue favouring the novices, but that just isn't applicable here. From jkeating at redhat.com Wed Dec 16 23:02:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Dec 2009 15:02:02 -0800 Subject: Possible wrong versions tagged into f12-final In-Reply-To: <1257765592.2478.211.camel@samson.armitage.org.uk> References: <1257765592.2478.211.camel@samson.armitage.org.uk> Message-ID: <1261004522.2396.74.camel@localhost.localdomain> On Mon, 2009-11-09 at 11:19 +0000, Quentin Armitage wrote: > I've noticed what might be a couple of anomalies regarding which > versions of packages have been tagged into f12-final. > > freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but > 0.9-10.fc11 tagged has been tagged into f12-final. > > gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but > 0.8.14.3.fc11 has been tagged into f12-final. It appears that > 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12 > rebuild). > > Quentin Armitage > > Yeah, looks like some fallout around the mass rebuild and getting things tagged over. Too late to do anything about F12 now, owners of those packages might consider issuing updates (which would then be picked up in F13) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Dec 16 23:08:37 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Dec 2009 14:08:37 -0900 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> Message-ID: <604aa7910912161508t510c8cdet69ef32875d62d090@mail.gmail.com> On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell wrote: > Yes? users with more expertise are more likely to complain about this, > but thats not reason to dismiss the issue. If there were truly a > disconnect here betweens the needs of the novices and those of the > expert users you could argue favouring the novices, but that just > isn't applicable here. Uhm. am I missing something. Aren't we talking about reboot requests that PK is spawning and I can choose to cancel in the UI interaction because I know better instead of mandatory reboots? -jef From jonathan.underwood at gmail.com Wed Dec 16 23:15:34 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 16 Dec 2009 23:15:34 +0000 Subject: Possible wrong versions tagged into f12-final In-Reply-To: <1261004522.2396.74.camel@localhost.localdomain> References: <1257765592.2478.211.camel@samson.armitage.org.uk> <1261004522.2396.74.camel@localhost.localdomain> Message-ID: <645d17210912161515j53e59263ted4ae751761e7b3a@mail.gmail.com> 2009/12/16 Jesse Keating : > On Mon, 2009-11-09 at 11:19 +0000, Quentin Armitage wrote: >> I've noticed what might be a couple of anomalies regarding which >> versions of packages have been tagged into f12-final. >> >> freenx-client: 0.9-9.fc12 was built as part of the dist-f12-rebuild, but >> 0.9-10.fc11 tagged has been tagged into f12-final. >> >> gauche: 0.8.14.3.fc12 was built during the mass F12 rebuild, but >> 0.8.14.3.fc11 has been tagged into f12-final. It appears that >> 0.8.14-2.fc12 was built after 0.8.14-3.fc12 (during the mass F12 >> rebuild). >> >> Quentin Armitage >> >> > > Yeah, looks like some fallout around the mass rebuild and getting things > tagged over. ?Too late to do anything about F12 now, owners of those > packages might consider issuing updates (which would then be picked up > in F13) Bug #548216 filed for freenx-client Bug #548218 filed for gauche From jkeating at redhat.com Wed Dec 16 23:19:17 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Dec 2009 15:19:17 -0800 Subject: acctcom for linux In-Reply-To: <1178023106l.10587l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> References: <1178023106l.10587l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> Message-ID: <1261005557.2396.75.camel@localhost.localdomain> On Tue, 2007-05-01 at 08:38 -0400, William W. Austin wrote: > 05/01/2007 05:38:26 AM (Tue, 01 May 2007 08:38:26 -0400) Your date is still wrong. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From oget.fedora at gmail.com Wed Dec 16 23:35:41 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 16 Dec 2009 18:35:41 -0500 Subject: Fedora update submission page broken for multiple packages In-Reply-To: <5926.1260983737@sss.pgh.pa.us> References: <5926.1260983737@sss.pgh.pa.us> Message-ID: On Wed, Dec 16, 2009 at 12:15 PM, Tom Lane wrote: > I tried to submit an update for both the fc12 and fc11 versions of > postgresql. ?It did not work; I had to file them as separate updates. > I'm pretty sure it used to work --- is my memory failing me, or is > this new breakage? ?If the latter, where do I file bugs against the > submission webpage? > When I tried submitting the same update for different Fedora releases about a year ago, it did not work. I do not remember the error message, but I figured that there was a policy to submit packages to different Fedora releases separately. Since then I probably made hundreds of updates each filed separately. If there is a way to file an update (same version and release except the disttag) to multiple branches, please let me know. Thanks Orcan From tgl at redhat.com Wed Dec 16 23:41:22 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 16 Dec 2009 18:41:22 -0500 Subject: Fedora update submission page broken for multiple packages In-Reply-To: References: <5926.1260983737@sss.pgh.pa.us> Message-ID: <18926.1261006882@sss.pgh.pa.us> Orcan Ogetbil writes: > If there is a way to file an update (same version and release except > the disttag) to multiple branches, please let me know. Usually it works: just add all the package NVRs to the same update submission. (That's what the "add another package" button is for.) The case I was complaining about seems to be that adding a new package to an *existing* update request doesn't work. If you get it right before you hit "submit", it's worked for awhile. regards, tom lane From tonynelson at georgeanelson.com Wed Dec 16 23:51:32 2009 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 16 Dec 2009 18:51:32 -0500 Subject: acctcom for linux In-Reply-To: <1261005557.2396.75.camel@localhost.localdomain> (from jkeating@redhat.com on Wed Dec 16 18:19:17 2009) Message-ID: <1261007492.22030.0@localhost.localdomain> On 09-12-16 18:19:17, Jesse Keating wrote: > On Tue, 2007-05-01 at 08:38 -0400, William W. Austin wrote: > > 05/01/2007 05:38:26 AM (Tue, 01 May 2007 08:38:26 -0400) > > Your date is still wrong. No, the date is correct. That's when the message was sent the first time around -- it's in the list archives. I don't think he reads the list anymore. I don't think he's aware that this is happening, so I've CC'd him. -- ____________________________________________________________________ TonyN.:' ' From ottohaliburton at tx.rr.com Thu Dec 17 00:48:54 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Wed, 16 Dec 2009 18:48:54 -0600 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> Message-ID: ----- Original Message ----- From: "Gregory Maxwell" To: "Development discussions related to Fedora" Sent: Wednesday, December 16, 2009 5:01 PM Subject: Re: packages requiring me to reboot... > On Wed, Dec 16, 2009 at 11:43 AM, Seth Vidal > wrote: >> you're an experienced user? You're comfortable knowing what does and what >> does not require a reboot? Then why are you using PK? >> >> Disable pk and do the updates directly via yum. >> >> Bam - no more requests to reboot. > > This is a completely bogus rationale but one I commonly hear on this list. > > I, and many other fedora users would be quite *capable* of running our > systems with any help of a distribution, we could go and fetch from > source and do all the integration ourselves... > that my friend is the open source concept. The users test, develop, & create new ideas for development. > ...but we'd actually like to get some work done using our computers > and don't want to burn our lives away playing master-of-my-own-distro, > though we're willing to spend some time contributing to a shared > effort to build a good distribution for many. > then go commercial, you pays your money you get your dues > In exchange for not having to personally micro-manage things, we're > willing to tolerate some things being configured in violation of our > own preferences or aesthetics, or even a few things being outright > broken, but that doesn't mean that it's not important for it to work > right. > how much do you pay for Fedora, as I remember I think it is free!!! > Yes, I'm quite capable of executing some big manual process or > changing packagekit to behave like I want. But every such action has > costs, it takes time and effort which usually has to be repeated every > upgrade. The non-standard configuration carries the risk of triggering > bugs in other system components, breaking the upgrade process, etc. > as I said go commercial!! > The gratuitous reboots are harmful to all users. They diminish a > significant advantage our systems can have compared to alternatives > like Microsoft Windows. They discourage the reporting of bugs in > applications? "System acting weird? Just restart!". When triggered at > inconvenient times they can cause significant harm by interrupting > people's work. > If that is so, then you and them are wasting your time with open source > Yes? users with more expertise are more likely to complain about this, > but thats not reason to dismiss the issue. If there were truly a > disconnect here betweens the needs of the novices and those of the > expert users you could argue favouring the novices, but that just > isn't applicable here. > every one contributes. It's free!!!! that is why you need to be more tolerant. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From kevin.kofler at chello.at Thu Dec 17 01:30:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 17 Dec 2009 02:30:30 +0100 Subject: kernel/accounting question ... References: <1161260629l.3496l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> <4B295A4A.6010703@redhat.com> Message-ID: Peter Jones wrote: > Not that I've got an answer for your question, but you might want to > tell your computer that it's not 2006. William W. Austin (or possibly his ISP, Speakeasy) is actually resending mail which was originally sent back in 2006. I got 2 extra copies of a mail I already received back in 2006. Kevin Kofler From waustin at speakeasy.net Thu Dec 17 01:54:27 2009 From: waustin at speakeasy.net (William W. Austin) Date: Thu, 17 Dec 2009 01:54:27 -0000 Subject: Static linking considered harmful Message-ID: <1164203396l.4626l.0l@dsl027-161-055.atl1.dsl.speakeasy.net> On 2006-11-22 05:37:43, Patrice Dumas wrote: > On Wed, Nov 22, 2006 at 10:29:44AM +0000, Andrew Haley wrote: > > > > > > Not only. There are cases when all those issues are moot, > > > a prominent one > > > being for numerical models. Compiling models statically makes > > > it possible > > > to run them on any other linux (including different fedora > > > version) box > > > without recompiling. So all the libraries that can be used for > > > numerical > > > computations should have static libraries kept. > > > > This seems like a non sequitur. What's special about numerical > > computations? > > I already explained it in my mail? To be more precise > > * security considerations are moot > * nss, iconv are not needed > > Other arguments for dynamic linking are not compulsory. > And numerical models are programs we would like to be able to run > on other linux box without recompiling. Imagine that compilation > takes 30 minutes and that you want to start 20 runs in paralell > from nfs mounted filesystem in an heterogeneous linux environment > with some redhat 6.2, 7.x, centos, debian, mandrake and fedora > core (real world example, of course). > > -- > Pat I have to agree with Patrice Dumas. I regularly do extensive numerical analysis and modeling using such a network, and the compilation time for the central program is VERY long, taking over 40 minutes on the fastest machine I have available. While I don't think we have anything older than RH8 in the pool of runtime machines, many of them cannot be upgraded for other reasons (I don't own them - I just get to use them when they are available, so the pool of machines changes probably every time I visit phase space), and if I had to do a compile for every different O/S+release combination I'm using, it would be a nightmare. While my run time is longer than Pat's example (a little over 4 hours using around 30 machines), if I had to recompile for each of the different variations I use, it would be prohibitively time-consuming and would be a reason to stop upgrading several machines here. I don't know whether eliminating static libraries would be a problem for other types of apps, for what I'm doing its elimination would be a disaster. While I don't see a problem with eliminating static linking of system utilities, IMHO eliminating it for user-written utilities is not a "universal benefit." -- william w. austin waustin at speakeasy.net "life is just another phase i'm going through. this time, anyway ..." From mel at redhat.com Thu Dec 17 02:09:55 2009 From: mel at redhat.com (Mel Chua) Date: Wed, 16 Dec 2009 21:09:55 -0500 Subject: FUDCon Toronto: please take the 5-minute feedback survey Message-ID: <4B2992F3.5080205@redhat.com> FUDCon Toronto (http://fedoraproject.org/wiki/FUDCon:Toronto_2009) is over - our largest FUDCon yet! We'd love to get your thoughts on how it went, so: * If you attended FUDCon Toronto, either in-person or remotely via Fedora Live, please take this survey and tell us what you thought. * If you didn't attend FUDCon Toronto but wanted to, please take this survey and tell us how we can help you get to the next one. * If you didn't want to go to FUDCon Toronto, please take this survey and tell us why - it's anonymous. ;-) The survey is available at http://fedoraproject.limequery.org/index.php?sid=34266&lang=en There are 29 questions, most of the yes/no variety; the survey takes less than 5 minutes to complete (I just timed myself). A special thanks to Robyn Bergeron, Yaakov Nemoy, and the rest of the Fedora Marketing team for designing the survey so it *can* be completed in less than 5 minutes! Questions are previewable at https://fedoraproject.org/wiki/FUDCon_survey. The survey will be active from 12/16/2009 through 1/8/2010, and we'll be analyzing and announcing the results shortly after it closes. If you're curious about the process, interested in helping us analyze the results, or have any questions in general, join the conversation on the Fedora Marketing mailing list (https://www.redhat.com/mailman/listinfo/fedora-marketing-list). --Mel From lists at sapience.com Thu Dec 17 02:24:43 2009 From: lists at sapience.com (Mail Lists) Date: Wed, 16 Dec 2009 21:24:43 -0500 Subject: packages requiring me to reboot... In-Reply-To: <15e53e180912160051i553667d4sd0c7fad4456f4c9b@mail.gmail.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <4B283C40.4040407@sapience.com> <15e53e180912160051i553667d4sd0c7fad4456f4c9b@mail.gmail.com> Message-ID: <4B29966B.5010609@sapience.com> On 12/16/2009 03:51 AM, Richard Hughes wrote: > 2009/12/16 Mail Lists : >> The last part is a clean up phase which could be deferred to reboot >> or perhaps something a little more clever. > > The devil is in the detail :) > > Richard. > Yes but how are: (a) Kill app - install - restart (b) install in separate are - on reboot (app is now dead, flip link to new install - delete old) Any different? We have ways now of running things as the system is going down or coming up ... don't we ? From rc040203 at freenet.de Thu Dec 17 04:05:45 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 Dec 2009 05:05:45 +0100 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> Message-ID: <4B29AE19.4020104@freenet.de> On 12/16/2009 06:34 PM, Seth Vidal wrote: > > > On Wed, 16 Dec 2009, nodata wrote: > >> Am 2009-12-16 18:21, schrieb Seth Vidal: >>> >>> >>> On Wed, 16 Dec 2009, nodata wrote: >>> >>>>> >>>>> we're talking about the experienced user who is comfortable knowing >>>>> what >>>>> does and does not need a reboot. >>>>> >>>>> All I'm saying is - we've not taken away any option, the experienced >>>>> user can do what they want. >>>>> >>>>> -sv >>>>> >>>> >>>> True, but the default should be sensible. >>> >>> And the default is sensible for the inexperienced user: >>> >>> Don't try to explain to the user how to restart the apps individually, >>> tell them to bounce the box and it will be the right version when it >>> comes back. >>> >>> -sv >>> >> >> On the other hand I think requiring more reboots than Windows is a bad >> thing... > > Then I can think of a couple of solutions to this problem: > > 1. Have fewer update pushes per release - this is something I'm actively > advocating and I think is possible Depends on what you actually have in mind. Simply letting update pile up would seem a silly idea to me, it contradicts Fedora's goal and removes what makes Fedora "attractive". Letting pile up "updates, which require a reboot, but are not addressig real bugs", could be applicable. > 2. Match up more updates to a specific running app so we can see if the > reboot is really necessary at all. - something else I've wrriten some > code in support of. Yes, this would be helpful - But only in case of non-bugfix updates. Bug-fix updates should be pushed ASAP, IMO. 3. Having better tools to avoid reboots. (Consider daemons, servers). 4. Maintainers to be more careful/reluctant/conservative, when considering to update packages, which require a reboot. Ralf From lsof at nodata.co.uk Thu Dec 17 07:00:55 2009 From: lsof at nodata.co.uk (nodata) Date: Thu, 17 Dec 2009 08:00:55 +0100 Subject: packages requiring me to reboot... In-Reply-To: <604aa7910912161508t510c8cdet69ef32875d62d090@mail.gmail.com> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <604aa7910912161508t510c8cdet69ef32875d62d090@mail.gmail.com> Message-ID: <4B29D727.8050402@nodata.co.uk> Am 2009-12-17 00:08, schrieb Jeff Spaleta: > On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell wrote: >> Yes? users with more expertise are more likely to complain about this, >> but thats not reason to dismiss the issue. If there were truly a >> disconnect here betweens the needs of the novices and those of the >> expert users you could argue favouring the novices, but that just >> isn't applicable here. > > Uhm. am I missing something. Aren't we talking about reboot requests > that PK is spawning and I can choose to cancel in the UI interaction > because I know better instead of mandatory reboots? > > -jef > No, we're talking about requiring fewer reboots for normal users. Prompting a user like this teaches them to ignore recommendations. This isn't a good thing. From christof at damian.net Thu Dec 17 07:16:13 2009 From: christof at damian.net (Christof Damian) Date: Thu, 17 Dec 2009 08:16:13 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <20091216185805.GH1718@tango.0pointer.de> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <20091216185805.GH1718@tango.0pointer.de> Message-ID: On Wed, Dec 16, 2009 at 19:58, Lennart Poettering wrote: >> pavucontrol currently crashes (and pulseaudio) for me on one machine >> and I need this functionality. > > File a bug. Could everyone on this list please assume that I filed a bug or found the bug already reported if I mention a bug. Cheers, Christof From sundaram at fedoraproject.org Thu Dec 17 07:19:09 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 Dec 2009 12:49:09 +0530 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <20091216185805.GH1718@tango.0pointer.de> Message-ID: <4B29DB6D.4040200@fedoraproject.org> On 12/17/2009 12:46 PM, Christof Damian wrote: > On Wed, Dec 16, 2009 at 19:58, Lennart Poettering wrote: >>> pavucontrol currently crashes (and pulseaudio) for me on one machine >>> and I need this functionality. >> >> File a bug. > > Could everyone on this list please assume that I filed a bug or found > the bug already reported if I mention a bug. Useful to add a reference to those bug reports in that case. Rahul From paul at dishone.st Thu Dec 17 09:13:15 2009 From: paul at dishone.st (Paul Jakma) Date: Thu, 17 Dec 2009 09:13:15 +0000 (GMT) Subject: x86-64 on i386 (was Re: Promoting i386 version over x86_64?) In-Reply-To: <20091216191647.GA20799@srcf.ucam.org> References: <20091214190316.GD1094301@hiwaay.net> <1260907071.6151.360.camel@tonnant> <20091215214019.GA839@srcf.ucam.org> <20091216150748.GA15217@srcf.ucam.org> <20091216191647.GA20799@srcf.ucam.org> Message-ID: On Wed, 16 Dec 2009, Matthew Garrett wrote: > The problem here is that you appear to be massively underestimating > the amount of work that would be required to actually support this > configuration. Support is a multi-valued thing as well as a process. Not every i has to be dotted for something to be of use. E.g. there are secondary arches to act as staging grounds. I would not except everything to be magically perfect tomorrow, however there may be low-hanging fruit (like yum having separate notions of default native word-size for userspace and kernel, see below). > We'd need to audit every ioctl entry point, every > file in proc and every sysfs attribute. Or just let people file bugs as they find things.. > We'd need to port every application that uses vm86 over to using > x86emu. Or let people using such apps continue to use a 32bit kernel (such kernel would have to continue to be supported, obv). > We'd need to add, test and support a 32-to-64 bit cross building > toolchain. GCC has a -m64 flag that may or may not help somewhat there (though, it got b0rken, though possibly just in combination with profiling). > yum would need some amount of work that Seth has implied > is significant. That's may be the easiest bit. It updates packages just fine, except it doesn't know I want it to install 64bit kernels, after I forced it to think the machine was 32bit. > That's a lot of work for marginal benefits, and nobody seems > interested in stepping up to do that work. I.e. money meet mouth, mouth likewise, you mean? :) I'll try poke at it later in 2010. I'm more a C programmer than a python programmer, so I'd rather look at stuff like things like the SG_IO interface (which Peter Jones pointed me at in private) than at yum, but I'll see. regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: One of the disadvantages of having children is that they eventually get old enough to give you presents they make at school. -- Robert Byrne From ottohaliburton at tx.rr.com Thu Dec 17 09:36:56 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 17 Dec 2009 03:36:56 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B29D727.8050402@nodata.co.uk> Message-ID: <23500740FD384D88A5AAA0EC85366EBA@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of nodata > Sent: Thursday, December 17, 2009 01:01 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > Am 2009-12-17 00:08, schrieb Jeff Spaleta: > > On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell > wrote: > >> Yes- users with more expertise are more likely to complain about this, > >> but thats not reason to dismiss the issue. If there were truly a > >> disconnect here betweens the needs of the novices and those of the > >> expert users you could argue favouring the novices, but that just > >> isn't applicable here. > > > > Uhm. am I missing something. Aren't we talking about reboot requests > > that PK is spawning and I can choose to cancel in the UI interaction > > because I know better instead of mandatory reboots? > > > > -jef > > > > No, we're talking about requiring fewer reboots for normal users. > > Prompting a user like this teaches them to ignore recommendations. This > isn't a good thing. > there are no mandatory reboots in PackageKit, you are notified what packages will cause a request to reboot and you can exit the process without rebooting!!!!!! Or you can remove the packages from the update processes and install when convenient for you. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From christof at damian.net Thu Dec 17 09:50:48 2009 From: christof at damian.net (Christof Damian) Date: Thu, 17 Dec 2009 10:50:48 +0100 Subject: Why pavucontrol is not installed by default? In-Reply-To: <4B29DB6D.4040200@fedoraproject.org> References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <20091216185805.GH1718@tango.0pointer.de> <4B29DB6D.4040200@fedoraproject.org> Message-ID: On Thu, Dec 17, 2009 at 08:19, Rahul Sundaram wrote: > On 12/17/2009 12:46 PM, Christof Damian wrote: >> On Wed, Dec 16, 2009 at 19:58, Lennart Poettering wrote: >>>> pavucontrol currently crashes (and pulseaudio) for me on one machine >>>> and I need this functionality. >>> >>> File a bug. >> >> Could everyone on this list please assume that I filed a bug or found >> the bug already reported if I mention a bug. > > Useful to add a reference to those bug reports in that case. The thing is that the thread wasn't about this bug and I wasn't complaining about the bug. I just wanted to know in which direction pulseaudio is going. I could as well have said: "In the future there will be no pavucontrol, how will this be possible then". I just find it annoying that some people seem to have "File a bug." in their signature, when one should assume that on fedora-devel everyone would file a bug for valid problems. It might and should be different on fedora or the forums. Christof From sundaram at fedoraproject.org Thu Dec 17 09:53:05 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 Dec 2009 15:23:05 +0530 Subject: Why pavucontrol is not installed by default? In-Reply-To: References: <68720af30912080351v2838230o1a4addfba3f38f1e@mail.gmail.com> <20091208115934.GE6007@mother.pipebreaker.pl> <20091216185805.GH1718@tango.0pointer.de> <4B29DB6D.4040200@fedoraproject.org> Message-ID: <4B29FF81.1040402@fedoraproject.org> On 12/17/2009 03:20 PM, Christof Damian wrote: > I just find it annoying that some people seem to have "File a bug." in > their signature, when one should assume that on fedora-devel everyone > would file a bug for valid problems. It might and should be different > on fedora or the forums. They do that because the assumption that everyone will have filed bugs would have been very wrong considering the past experiences. Rahul From hughsient at gmail.com Thu Dec 17 10:33:05 2009 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 17 Dec 2009 10:33:05 +0000 Subject: packages requiring me to reboot... In-Reply-To: <4B291600.3060801@gnat.ca> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B291400.1050200@gnat.ca> <4B291600.3060801@gnat.ca> Message-ID: <15e53e180912170233h17f2b45aic3e44b2f92505173@mail.gmail.com> 2009/12/16 Nathanael D. Noblet : > So basically, PK is designed for the non-experienced users, as such > everything it does is dumbed down, and experienced users should just ignore > it, using other tools to keep their system up to date. See http://www.packagekit.org/pk-profiles.html Richard. From kaboon at gmail.com Thu Dec 17 11:09:23 2009 From: kaboon at gmail.com (Eelko Berkenpies) Date: Thu, 17 Dec 2009 12:09:23 +0100 Subject: packages requiring me to reboot... In-Reply-To: <1821AEED6D484EB89770040DD7A3842B@ottoPC> References: <4B27BE72.5020002@gnat.ca> <4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> <1821AEED6D484EB89770040DD7A3842B@ottoPC> Message-ID: <3f5430b30912170309o6a5c8063if02c866d7ba842@mail.gmail.com> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton wrote: > > ----- Original Message ----- From: "nodata" > To: "Development discussions related to Fedora" > > Sent: Wednesday, December 16, 2009 11:29 AM > Subject: Re: packages requiring me to reboot... > > >> Am 2009-12-16 18:21, schrieb Seth Vidal: >>> >>> >>> On Wed, 16 Dec 2009, nodata wrote: >>> >>>>> >>>>> we're talking about the experienced user who is comfortable knowing >>>>> what >>>>> does and does not need a reboot. >>>>> >>>>> All I'm saying is - we've not taken away any option, the experienced >>>>> user can do what they want. >>>>> >>>>> -sv >>>>> >>>> >>>> True, but the default should be sensible. >>> >>> And the default is sensible for the inexperienced user: >>> >>> Don't try to explain to the user how to restart the apps individually, >>> tell them to bounce the box and it will be the right version when it >>> comes back. >>> >>> -sv >>> >> >> On the other hand I think requiring more reboots than Windows is a bad >> thing... >> > windows update will automatically reboot your system when it automatically > updates it > windows tried the optional stuff but now almost every case it requires a > restart. I don't like the term "experienced user" and I never feel comfortable adding myself to that group but anyway, - I don't want Windows to automatically reboot so I disable the automatic Windows Update on the machines I'm using. - I don't want my Fedora to reboot automatically so I disable and remove PackageKit on the machines I'm using. There isn't that much I could say about the times Fedora ask for a reboot but at least I think it's kind of "unfair" to compare it with an OS which pushes their updates just once a month. Just my ? 0.02. -- With kind regards / Met vriendelijke groet, Eelko Berkenpies http://blog.berkenpies.nl/ From dtimms at iinet.net.au Thu Dec 17 12:35:27 2009 From: dtimms at iinet.net.au (David Timms) Date: Thu, 17 Dec 2009 23:35:27 +1100 Subject: packages requiring me to reboot - semi-off -topic response In-Reply-To: <1260999485.2793.24.camel@tonnant> References: <4B27BE72.5020002@gnat.ca><4B290857.1000305@gnat.ca> <4B290F53.4000006@redhat.com> <4B2915E4.40107@nodata.co.uk> <4B29190A.5060504@nodata.co.uk> <1821AEED6D484EB89770040DD7A3842B@ottoPC> <4B295158.8030703@nist.gov> <1260999485.2793.24.camel@tonnant> Message-ID: <4B2A258F.6070809@iinet.net.au> On 12/17/2009 08:38 AM, Jon Masters wrote: > On Wed, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote: > >> too. My own preference would be a more discriminating dialog >> that offers three possibilities: 'do nothing', 'bounce the >> service/application' and 'reboot'. > > Yup, +1 Bounce the application would be really cool for eg firefox, thunderbird, that continue to work, but some things sort of don't (like new popups dont open and so forth). In doing so the application would need to return to the identical locations, arrangements that it was bounced from. And really, the above shouldn't be difficult for a computer to do: - have window, pos,size, doc open, caret position and so on, even those pesky web forms with unsubmitted data and so on. Make it part of the freedesktop standards - an app forcibly closed or ?disappears shall reopen as if nothing changed ! (although firefox multi-tab and working out which tab not to reopen after a crash is a good game). Make open documents files etc, be always stored immediately on change with snapshots at each save to disk, few minutes of operation etc. Make it like paper, but actually better, you know: what is written on paper doesn't mysteriously disappear when an update or a power failure, or app crash occurs, nor does it disappear from where you left it. I think the above scenario for user apps would seem to be a reasonable goal. On the other hand, services are not so clear cut. If I'm an external user logged into the web service, filling a form, I don't expect even momentary downtime to cause me to lose information I'm entering, or corrupt a file I have open / editing on network share (though see the works better than paper description). In the first example, would it make sense for the web server to start all new processes using the new updated code, while existing users stay connected to the existing instance, until these timeout/logout and no user's connection is using the old code. When a reboot is really needed, a PK dialog could inform of the need, and ask when that could occur (do at 4:30 am tueday morning) ps: did gnome desktop regain the feature of autologin and rerun apps on desktop capability of pre f-10 ? From mschwendt at gmail.com Thu Dec 17 12:35:44 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 17 Dec 2009 13:35:44 +0100 Subject: Fedora update submission page broken for multiple packages In-Reply-To: <18926.1261006882@sss.pgh.pa.us> References: <5926.1260983737@sss.pgh.pa.us> <18926.1261006882@sss.pgh.pa.us> Message-ID: <20091217133544.37bb0755@gmail.com> On Wed, 16 Dec 2009 18:41:22 -0500, Tom wrote: > Orcan Ogetbil writes: > > If there is a way to file an update (same version and release except > > the disttag) to multiple branches, please let me know. > > Usually it works: just add all the package NVRs to the same update > submission. (That's what the "add another package" button is for.) For "multiple branches"? That has never worked for me either. "Add another package" is to push multiple packages in a single bodhi ticket. That has worked for me. > The case I was complaining about seems to be that adding a new package > to an *existing* update request doesn't work. Not even when "editing" the update request again? That will pull it back into "pending", however. And the package to add must not be part of a different update request ticket already. From rawhide at fedoraproject.org Thu Dec 17 13:14:26 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 17 Dec 2009 13:14:26 +0000 Subject: rawhide report: 20091217 changes Message-ID: <20091217131426.GA2007@releng2.fedora.phx.redhat.com> Compose started at Thu Dec 17 08:15:09 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package mingw32-xerces-c MingGW Windows validating XML parser New package mod_proxy_html Output filter to rewrite HTML links in a proxy situation New package perl-CGI-Application-Plugin-Config-Simple Add Config::Simple support to CGI::Application New package perl-CGI-Application-Plugin-FormState Store Form State without Hidden Fields New package python-couchdb A Python library for working with CouchDB Updated Packages: ModemManager-0.2.997-3.git20091216.fc13 --------------------------------------- * Wed Dec 16 2009 Dan Williams - 0.2.997-3.git20091216 - sierra: ensure CDMA device is powered up when trying to use it - cdma: better signal quality parsing (fixes ex Huawei EC168C) - zte: handle unsolicited messages better during probing alexandria-0.6.6-0.1.alpha.fc13 ------------------------------- * Thu Dec 17 2009 Mamoru Tasaka - 0.6.6-0.1.alpha - Try 0.6.6 alpha * Tue Sep 08 2009 Mamoru Tasaka - Wrong patch of sanity check patch applied on F-10/11, fixing... amsn-0.98.1-4.fc13 ------------------ * Wed Dec 16 2009 Brian Pepple - 0.98.1-4 - Rebuild for new gupnp-igd. * Sat Dec 05 2009 Sander Hoentjen - 0.98.1-3 - add requires on tcl-snack, it is needed for voice-clip support - since we need snack anyway, use it for all audio and drop requirement on alsa-utils anaconda-13.11-1.fc13 --------------------- * Wed Dec 16 2009 Chris Lumens - 13.11-1 - Clean up setting paths on preupgrade (jvonau). (clumens) - And call freetmp, too. (Jerry) - Add a method to remove /tmp/install.img on low memory conditions (jvonau). (clumens) - Make sure /mnt/stage2 is mounted before trying to unmount. (Jerry) - Skip the mediaDevice check before attempting to mount the install.img. (Jerry) - Remove install.img from /boot during preupgrade. (Jerry) - Add __str__ methods to the DeviceFormat classes. (dlehman) - Expand PartitionDevice.__str__ to include partition geometry and flags. (dlehman) - Hide biosraid member devices that contain MDRaidMember formats. (dlehman) - Move disklabel handling into handleUdevDeviceFormat with the others. (dlehman) - DiskDevice.__init__ expects an "exists" parameter, so add it. (clumens) - Fix multipath filtering. (clumens) - Log error messages before displaying dialogs. (clumens) - Include error messages when logging selinux context get/set failures. (dlehman) - Catch failures to set selinux contexts so it doesn't cause a crash. (dlehman) - Fix typo logging failure to get default file context. (dlehman) - Use DiskLabel.alignment instead of getDiskAlignment. (dlehman) - Add an alignment property to DiskLabel. (dlehman) - iscsi.py: Do not translate log messages (hdegoede) - Make iscsi,etc startup use the iscsi,etc Singletons (hdegoede) - kickstart: Move onlining of fcoe/iscsi/zfcp devices to parse phase (hdegoede) - Make the fcoe, iscsi and zfcp classes singletons (hdegoede) - Remove call to no longer existing isys DriveDict method (hdegoede) - Use the correct yum configuration file when searching for the -logos package (kanarip) - Fix two missing closing parens in previous commits. (clumens) - Add an interface to select the fancy filtering UI vs. the regular one. (clumens) - Add a step to prompt for the cleardisks UI. (clumens) - Add a dialog to configure advanced storage devices. (clumens) - Add an early user interface for filtering storage devices. (clumens) - Rework the upgrade vs. install screen a bit to make it look nicer. (clumens) - Add the updated and simplified parttype screen. (clumens) - Add a method to determine whether a device is a CCISS RAID device. (clumens) - Move identifyMultipaths from DeviceTree to devicelibs. (clumens) - Add a method to return a device's WWID. (clumens) - Add a method to get the bus/interconnect from udev and store it on devices. (clumens) - Add a vendor getting udev method, though udev doesn't always know it. (clumens) - Add the serial number to all DiskDevices and subclasses. (clumens) - Put less space between rows and allow text to be longer before wrapping. (clumens) - Allow InstallInterfaces to modify the installation steps. (clumens) - Default /boot to 500 MB. (clumens) - Some iscsi cleanups (hdegoede) - Bring auto discovered drives online before parsing the ks file (hdegoede) - Make a better effort at tearing down everything before action processing. (dlehman) - Tighten restrictions on the type of disklabel on x86 and EFI boot disks. (dlehman) - Use string instead of parted.diskType for disklabel types. (dlehman) - A couple of cleanups to warnings about formatting preexisting devices. (dlehman) - Rework udev_settle timeout handling (#544177) (hdegoede) - Remove smp.c from the Makefile.am, too. (clumens) - Nothing has a kernel-smp anymore so none of this code is useful. (clumens) - Get rid of the goofy nested try statements. (clumens) - update reIPL messages (hamzy) - Change btrfs command line option (josef) arts-1.5.10-11.fc13 ------------------- * Wed Dec 16 2009 Kevin Kofler - 1.5.10-11 - don't pop up a dialog on CPU overload (#361891) banshee-1.5.3-0.1.20091216git.fc13 ---------------------------------- * Wed Dec 16 2009 Christian Krause - 1.5.3-0.1.20091216git - Update to latest snapshot to pick up DeviceKit-disks integration to fix iPod support (BZ 495240) - Add a minor patch to fix the last.fm integration bzr-2.1.0-0.4.b4.fc13 --------------------- * Thu Dec 17 2009 Henrik Nordstrom - 2.1.0-0.4.b4 - Update to 2.1.0b4 coreutils-8.2-3.fc13 -------------------- * Wed Dec 16 2009 Ondrej Vasik - 8.2-2 - fix DIR_COLORS.256color file * Wed Dec 16 2009 Ondrej Vasik - 8.2-3 - use grep instead of deprecated egrep in colorls.sh script (#548174) - remove unnecessary versioned requires - remove non-upstream hack for uname -p eclipse-3.5.1-25.fc13 --------------------- * Tue Dec 15 2009 Alexander Kurtakov 1:3.5.1-25 - Fix o.e.jdt.junit dropins issue. RHBZ#538803 (Thanks to Patrick Higgins). farsight2-0.0.16-2.fc13 ----------------------- * Wed Dec 16 2009 Brian Pepple - 0.0.16-2 - Rebuild for new gupnp-igd. gbirthday-0.5.5-3.fc13 ---------------------- * Thu Dec 17 2009 Thomas Spura 0.5.5-3 - add ebook.patch, applied from upstream git repo, fixes bug #548007 ghc-6.12.1-1.fc13 ----------------- * Wed Dec 16 2009 Jens Petersen - 6.12.1-1 - pre promoted to 6.12.1 final - exclude ghc .conf file from package.conf.d in base package - use ghc_reindex_haddock - add scripts for ghc-ghc-devel and ghc-ghc-doc - add doc bcond - add ghc-6.12.1-gen_contents_index-haddock-path.patch to adjust haddock path since we removed html/ from libraries path - require ghc-rpm-macros-0.3.1 and use ghc_version_override ghdl-0.28-0.133svn.0.fc13 ------------------------- * Wed Dec 16 2009 Thomas Sailer - 0.28-0.133svn.0 - update to svn133, drop upstreamed patches gstreamer-rtsp-0.10.5-1.fc13 ---------------------------- * Wed Dec 16 2009 Bastien Nocera 0.10.5-1 - Update to 0.10.5 gupnp-igd-0.1.5-1.fc13 ---------------------- * Sun Dec 06 2009 Peter Robinson - 0.1.5-1 - Update to 0.1.5. hunspell-ht-0.06-1.fc13 ----------------------- * Wed Dec 16 2009 Caolan McNamara - 0.06-1 - latest version ibus-m17n-1.2.0.20091217-1.fc13 ------------------------------- * Thu Dec 17 2009 Peng Huang - 1.2.0.20091217-1 - Update to 1.2.0.20091217. - Update iok patch. ibus-qt-1.2.0.20091217-1.fc13 ----------------------------- * Thu Dec 17 2009 Peng Huang - 1.2.0.20091217-1 - Update to 1.2.0.20091217. inn-2.5.1-3.fc13 ---------------- * Wed Dec 16 2009 Nikola Pajkovsky - 2.5.1-3 - rebuild - chage licence and remove on rm -f - drop patches inn-2.4.1.perl.patch and inn-2.4.5-dynlib.patch kdeedu-4.3.80-2.fc13 -------------------- * Wed Dec 16 2009 Kevin Kofler - 4.3.80-2 - reenable ocaml-facile support (#546628) kernel-2.6.32.1-10.fc13 ----------------------- * Wed Dec 16 2009 Roland McGrath 2.6.32.1-10 - utrace update, now testing the utrace-based ptrace! libguestfs-1.0.80-2.fc13 ------------------------ * Wed Dec 16 2009 Richard W.M. Jones - 1.0.80-1 - New upstream release 1.0.80. - New Polish translations (RHBZ#502533). - Give a meaningful error if no usable kernels are found (RHBZ#539746). - New tool: virt-list-filesystems * Wed Dec 16 2009 Richard W.M. Jones - 1.0.80-2 - Disable tests because of RHBZ#548121. * Fri Dec 04 2009 Stepan Kasal - 1:1.0.79-3 - rebuild against perl 5.10.1 libnice-0.0.10-2.fc13 --------------------- * Wed Dec 16 2009 Brian Pepple - 0.0.10-2 - Rebuild for new gupnp-igd. libpcap-1.0.0-5.20091201git117cb5.fc13 -------------------------------------- * Wed Dec 16 2009 Miroslav Lichvar 14:1.0.0-5.20091201git117cb5 - update to snapshot 20091201git117cb5 libsemanage-2.0.43-2.fc13 ------------------------- * Wed Dec 16 2009 Dan Walsh - 2.0.43-2 - Rebuild all c programs with -fPIC libtiff-3.9.2-2.fc13 -------------------- * Wed Dec 16 2009 Tom Lane 3.9.2-2 - Apply Warmerdam's partial fix for bug #460322 ... better than nothing. Related: #460322 libvirt-cim-0.5.8-2.fc13 ------------------------ * Mon Dec 07 2009 Kaitlin Rupert - 0.5.8-2 - Add missing namespace unreg bits for root/interop, root/cimv2 - Remove additional reg call of root/virt from postinstall - Do not use /etc directly. Use sysconfigdir instead - Remove additional DESTDIR definition - Fix Xen migration URI to not include 'system' - Change net->name to net->source logwatch-7.3.6-49.fc13 ---------------------- * Wed Dec 02 2009 Karel Klic 7.3.6-49 - Add 802.1q subinterface support to iptables report; iptables.patch (#507743) - Fixed error in the RE that matches "lost connection" lines in postfix script; lost-connection.patch (#525903) - Added patches parsing several unmatched entries (from F-10); audit4.patch modified to make ppid optional; openvpn4.patch modified to make "semi-" optional; pam_unix4.patch modified (user name matched by \S+) lxmusic-0.4.0-2.fc13 -------------------- * Wed Dec 16 2009 Christoph Wickert - 0.4.0-2 - Fix crash when emptying large playlists (#539729) lxpanel-0.5.4.1-1.fc13 ---------------------- * Wed Dec 16 2009 Christoph Wickert - 0.5.4.1-1 - Update to 0.5.4.1 - Remove upstreamed patches midori-0.2.2-1.fc13 ------------------- * Wed Dec 16 2009 Adam Miller - 0.2.2-1 - Update to new upstream release (0.2.2) mutt-1.5.20-2.20091214hg736b6a.fc13 ----------------------------------- * Wed Dec 16 2009 Miroslav Lichvar 5:1.5.20-2.20091214hg736b6a - update to hg snapshot 20091214hg736b6a netpbm-10.47.06-1.fc13 ---------------------- * Mon Dec 14 2009 Jindrich Novy 10.47.06-1 - update to 10.47.06 - fixes the dumb pamtosvg mistake in 10.47.05 - pnmmargin won't create leftovers in /tmp (#547888) nexuiz-2.5.2-2.fc13 ------------------- * Wed Dec 16 2009 Jon Ciesla - 2.5.2-2 - patch to fix crash, BZ 540742. ocaml-3.11.1-8.fc13 ------------------- * Wed Dec 16 2009 Richard W.M. Jones - 3.11.1-7 - Remove ocaml-find-{requires,provides}.sh from this package. These are now in upstream RPM 4.8 (RHBZ#545116). - define -> global in a few places. * Wed Dec 16 2009 Richard W.M. Jones - 3.11.1-8 - Use __ocaml_requires_opts / __ocaml_provides_opts. ocaml-facile-1.1-11.fc13 ------------------------ * Thu Dec 17 2009 Kevin Kofler - 1.1-11 - Use RPM's builtin OCaml dependency generator on F13+ ocaml-findlib-1.2.5-3.fc13 -------------------------- * Wed Dec 16 2009 Richard W.M. Jones - 1.2.5-2 - Update to use RPM dependency generator. * Wed Dec 16 2009 Richard W.M. Jones - 1.2.5-3 - Use __ocaml_requires_opts / __ocaml_provides_opts. ocaml-perl4caml-0.9.5-11.fc13 ----------------------------- * Mon Dec 07 2009 Stepan Kasal - 0.9.5-11 - rebuild against perl 5.10.1 openoffice.org-3.2.0-7.3.fc13 ----------------------------- * Tue Dec 15 2009 Caol?n McNamara - 1:3.2.0-7.3 - Resolves: rhbz#529648 add workspace.fwk132.patch - Resolves: rhbz#547176 add openoffice.org-3.2.0.ooo47279.sd.objectsave.safe.patch perl-POE-Component-Server-Bayeux-0.04-1.fc13 -------------------------------------------- * Wed Dec 16 2009 Yanko Kaneti - 0.04-1 - New upstream release (bugfix) http://cpansearch.perl.org/src/EWATERS/POE-Component-Server-Bayeux-0.04/Changes podsleuth-0.6.6-0.1.20091216git.fc13 ------------------------------------ * Wed Dec 16 2009 Christian Krause - 0.6.6-0.1.20091216git - Update to git snapshot (20091216) for DeviceKit-disks integration (BZ 495240) - Update libdir patch - Use upstream's dbus policy file policycoreutils-2.0.78-5.fc13 ----------------------------- * Wed Dec 16 2009 Dan Walsh 2.0.78-5 - If restorecond running as a user has no files to watch then it should exit. (NFS Homedirs) * Thu Dec 10 2009 Dan Walsh 2.0.78-4 - Move sandbox man page to base package * Tue Dec 08 2009 Dan Walsh 2.0.78-3 - Fix audit2allow to report constraints, dontaudits, types, booleans * Fri Dec 04 2009 Dan Walsh 2.0.78-2 - Fix restorecon -i to ignore enoent preupgrade-1.1.4-1.fc13 ----------------------- * Mon Dec 14 2009 Seth Vidal - 1.1.4-1 - fixes 538118 among others pybackpack-0.5.7-1.fc13 ----------------------- * Wed Dec 16 2009 Adam Miller - 0.5.7-1 - New release from upstream fixing cdburn bug (BZ# 538193) python-setuptools-0.6.9-1.fc13 ------------------------------ * Mon Dec 14 2009 Toshio Kuratomi - 0.6.9-1 - New upstream bugfix release. rpm-4.8.0-0.beta1.4 ------------------- * Thu Dec 17 2009 Panu Matilainen - 4.8.0-0.beta1.4 - permit unexpanded macros when parsing spec (#547997) ruby-cairo-1.8.1-1.fc13 ----------------------- * Wed Dec 16 2009 Allisson Azevedo 1.8.1-1 - Update to 1.8.1 selinux-policy-3.7.4-3.fc13 --------------------------- * Wed Dec 16 2009 Dan Walsh 3.7.4-3 - Fixes for abrt calls * Fri Dec 11 2009 Dan Walsh 3.7.4-2 - Add tgtd policy sepostgresql-8.4.2-2487.fc13 ---------------------------- * Wed Dec 16 2009 KaiGai Kohei - 8.4.2-2487 - upgrade base version 8.4.1->8.4.2 stardict-3.0.1-19.fc13 ---------------------- * Thu Dec 17 2009 Caius 'kaio' Chance - 3.0.1-19 - Resolves: rhbz#475904: Disabled espeak for instance as espeak has problems when it is built with pulseaudio. xchat-2.8.6-15.fc13 ------------------- * Wed Dec 16 2009 Kevin Fenzi - 1:2.8.6-15 - Add patch to allow switching to next channel with activity. zita-convolver-2.0.0-1.fc13 --------------------------- * Wed Dec 16 2009 Orcan Ogetbil - 2.0.0-1 - updated to 2.0.0 Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 52 From ottohaliburton at tx.rr.com Thu Dec 17 14:02:02 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 17 Dec 2009 08:02:02 -0600 Subject: packages requiring me to reboot... In-Reply-To: <3f5430b30912170309o6a5c8063if02c866d7ba842@mail.gmail.com> Message-ID: <059DEDF49D6F4FD4A97140F5463ADAC0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Eelko Berkenpies > Sent: Thursday, December 17, 2009 05:09 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton > wrote: > > > > ----- Original Message ----- From: "nodata" > > To: "Development discussions related to Fedora" > > > > Sent: Wednesday, December 16, 2009 11:29 AM > > Subject: Re: packages requiring me to reboot... > > > > > >> Am 2009-12-16 18:21, schrieb Seth Vidal: > >>> > >>> > >>> On Wed, 16 Dec 2009, nodata wrote: > >>> > >>>>> > >>>>> we're talking about the experienced user who is comfortable knowing > >>>>> what > >>>>> does and does not need a reboot. > >>>>> > >>>>> All I'm saying is - we've not taken away any option, the experienced > >>>>> user can do what they want. > >>>>> > >>>>> -sv > >>>>> > >>>> > >>>> True, but the default should be sensible. > >>> > >>> And the default is sensible for the inexperienced user: > >>> > >>> Don't try to explain to the user how to restart the apps individually, > >>> tell them to bounce the box and it will be the right version when it > >>> comes back. > >>> > >>> -sv > >>> > >> > >> On the other hand I think requiring more reboots than Windows is a bad > >> thing... > >> > > windows update will automatically reboot your system when it > automatically > > updates it > > windows tried the optional stuff but now almost every case it requires a > > restart. > > I don't like the term "experienced user" and I never feel comfortable > adding myself to that group but anyway, > > - I don't want Windows to automatically reboot so I disable the > automatic Windows Update on the machines I'm using. > > - I don't want my Fedora to reboot automatically so I disable and > remove PackageKit on the machines I'm using. > > There isn't that much I could say about the times Fedora ask for a > reboot but at least I think it's kind of "unfair" to compare it with > an OS which pushes their updates just once a month. > > Just my ? 0.02. first of all PackageKit does not do mandatory reboots. If you hadn't disabled it you would know that. In fact the people that are complaining don't seem to have any idea why reboots are necessary. You need to get a grip on file processing, cache, and other processes that speeds up execution then you will know why it is not trivial. i.e. you kill a task that is in the process of writing data to a file after you update it. What happens???? > > -- > With kind regards / Met vriendelijke groet, > > Eelko Berkenpies > http://blog.berkenpies.nl/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From a.badger at gmail.com Thu Dec 17 14:42:13 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 17 Dec 2009 06:42:13 -0800 Subject: Fedora update submission page broken for multiple packages In-Reply-To: <20091217133544.37bb0755@gmail.com> References: <5926.1260983737@sss.pgh.pa.us> <18926.1261006882@sss.pgh.pa.us> <20091217133544.37bb0755@gmail.com> Message-ID: <20091217144213.GI26138@clingman.lan> On Thu, Dec 17, 2009 at 01:35:44PM +0100, Michael Schwendt wrote: > On Wed, 16 Dec 2009 18:41:22 -0500, Tom wrote: > > > Orcan Ogetbil writes: > > > If there is a way to file an update (same version and release except > > > the disttag) to multiple branches, please let me know. > > > > Usually it works: just add all the package NVRs to the same update > > submission. (That's what the "add another package" button is for.) > > For "multiple branches"? That has never worked for me either. > This used to work. Once the update is submitted, bodhi breaks it into two update requests when it saves it. > "Add another package" is to push multiple packages in a single > bodhi ticket. That has worked for me. > This works as well. When bodhi saves this, it saves the set of packages into a single update request so that they all get puhed together. I do not know if there's any bugs when these two features are used together but that doesn't sound like what was attempted here. > > The case I was complaining about seems to be that adding a new package > > to an *existing* update request doesn't work. > I don't know if this has worked in the past but given that you can add multiple builds of a package to multiple branches via the add another package mechanism, this seems like it should work. > Not even when "editing" the update request again? That will pull it > back into "pending", however. And the package to add must not be part > of a different update request ticket already. > -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tvolkert at gmail.com Thu Dec 17 14:43:58 2009 From: tvolkert at gmail.com (Todd Volkert) Date: Thu, 17 Dec 2009 09:43:58 -0500 Subject: autofs not installed by default Message-ID: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> Hi all, The past few Fedora installs, I've specified a NIS server during the Anaconda installation so I don't have to create any local user accounts. However, once installation is complete, I can't log into any NIS accounts because autofs insn't installed, causing the user accounts' home folders to not be mounted. I have to sign in as root, install autofs, then all is well. My question is: shouldn't autofs be installed by default, as part of the base installation? -T -------------- next part -------------- An HTML attachment was scrubbed... URL: From chitlesh.goorah at gmail.com Thu Dec 17 14:54:39 2009 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Thu, 17 Dec 2009 15:54:39 +0100 Subject: Offline for one month or more Message-ID: <50baabb30912170654r2fbb4d71oad0f3c1f7191485c@mail.gmail.com> Hello there, I'm currently relocating to another country and will be fedora-offline for a while, probably one month (probably be on and off). If my packages require immediate actions for any reason, please do the necessary in my place. https://admin.fedoraproject.org/pkgdb/users/packages/chitlesh As far as the FEL spin is concerned, it is still scheduled for F-13 and recent work done by Shakthi Kannan and Arun Sag made microelectronics design even more exciting. If you have any question, please email us on FEL's mailing list. Shakthi Kannan and others would be pleased to answer you. I wish you all Merry Christmas and New Year 2010 ;) Kind regards, Chitlesh Goorah From notting at redhat.com Thu Dec 17 15:09:07 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 Dec 2009 10:09:07 -0500 Subject: autofs not installed by default In-Reply-To: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> Message-ID: <20091217150905.GA1662@nostromo.devel.redhat.com> Todd Volkert (tvolkert at gmail.com) said: > The past few Fedora installs, I've specified a NIS server during the > Anaconda installation so I don't have to create any local user accounts. > However, once installation is complete, I can't log into any NIS accounts > because autofs insn't installed, causing the user accounts' home folders to > not be mounted. I have to sign in as root, install autofs, then all is > well. How have you set up a NIS server as part of the install? It's not part of the anaconda configuration screens. > My question is: shouldn't autofs be installed by default, as part of the > base installation? For many use cases in Fedora, it's not needed; we're trying to keep the core/base groups reasonably small. If you use kickstart, you can both set up NIS and install autofs with directives in your kickstart file. Bill From stickster at gmail.com Thu Dec 17 15:09:51 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 17 Dec 2009 10:09:51 -0500 Subject: Election results for FAmSCo, FESCo coming shortly Message-ID: <20091217150951.GI5536@victoria.internal.frields.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Our election coordinator, Nigel Jones, was too swamped today to process all of the election results, but will be doing so later today (UTC time). Thanks for your patience, and thanks to Nigel for all his work coordinating the voting system and results. - -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLKkm/rNvJN70RNxcRAjY9AKCoRs/EplwBz3kXCbYJlW9heW19TQCgtHmx wmnUs+PWljamrXBKBi1jq/c= =8gZv -----END PGP SIGNATURE----- From sandeen at redhat.com Thu Dec 17 15:28:09 2009 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 17 Dec 2009 09:28:09 -0600 Subject: safe way to standby sata hdd? In-Reply-To: <596b53e0912160917h4ac17b6fh99f4d02e46b901ec@mail.gmail.com> References: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> <4B290042.6010609@redhat.com> <596b53e0912160917h4ac17b6fh99f4d02e46b901ec@mail.gmail.com> Message-ID: <4B2A4E09.8080504@redhat.com> Micha? Piotrowski wrote: > 2009/12/16 Eric Sandeen : >> Micha? Piotrowski wrote: >>> Hi, >>> >>> I've got a home database/symfony env/etc../file server. It's based on >>> Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power >>> connected through Sata. First drive has / and /home filesystem, second >>> has /home/samba4. On the first drive there are two directories >>> /home/samba2 and /home/samba3 where I'm mounting ecryptfs. >>> /home/samba4 is also crypted by default. >>> >>> I'm wondering if there is a safe way for such configuration to put >>> second harddrive into sleep (or both drives) after some idle time? >>> After some googling I've found some resolutions (haven't tested any of >>> these yet): >>> - hdparm -S >> I use this for the data drive on my mythbox. I just put this in my >> /etc/rc.local - >> >> # Spin down in 1 hours idle time >> hdparm -S 240 /dev/sda > > Have you used this for a disk with your rootfs? In the past I have, but lately getting the root to actually get idle is just about impossible it seems. I now have an ssd root and don't bother. >> (yeah, oddly, sda is not my boot drive) :) >> >>> - sdparm --set=STANDBY >>> - and laptop_tools >>> >>> I'm really not convinced that these methods are safe for my >>> configuration. Anyone have tried this before? >> Yep. What kind of safety are you worried about? > > I know that ecryptfs is just fs stack on top of my ext3 partition, but > still I care about data integrity. Ok but what does that have to do with spinning down a disk? :) >> It should just work, >> although you want a long enough idle time that you're not constantly >> spinning the disk up and down. > > Actually /home/samba4 is not mounted all the time - I'm umountig this > fs when I'm not using it. I'm wondering if there will be any problems > with data integrity when I forgot to umount ecryptfs and disk will be > stopped. I don't think so. Any access should just spin up the disk and carry on. -Eric >> Is there any nice user-friendly frontend to set this? It'd be nice >> to expose more power management choices to the users (for anything >> that can't be easily defaulted, that is). >> >> -Eric > > Regards, > Michal > From james at fedoraproject.org Thu Dec 17 15:51:10 2009 From: james at fedoraproject.org (James Antill) Date: Thu, 17 Dec 2009 10:51:10 -0500 Subject: packages requiring me to reboot... In-Reply-To: <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> Message-ID: <1261065070.21633.3.camel@code.and.org> On Wed, 2009-12-16 at 08:50 +0000, Richard Hughes wrote: > 2009/12/15 Colin Walters : > > This exists? Can you point me to the code? > > I only finished this just this morning. > > It's just been pushed to git master. You want to see this commit > http://cgit.freedesktop.org/packagekit/commit/?id=66d3fc26054abd528ee18017d9c67edb6400f239 > for the juicy config bits. Looking at 3cb32ad40af3a38456e09baf1b29b046d82c587e, AIUI the commit with the code bits in it, I'm pretty sure you are now requiring filelists to be downloaded for all updates. > The UI isn't very pretty at the moment (it just fails with an update > error) but I'll work on something a little bit more user friendly. How do you plan on restarting firefox? Or you just planning to kill() and get the user to restart? -- James Antill - james at fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching From tvolkert at gmail.com Thu Dec 17 15:54:13 2009 From: tvolkert at gmail.com (Todd Volkert) Date: Thu, 17 Dec 2009 10:54:13 -0500 Subject: autofs not installed by default In-Reply-To: <20091217150905.GA1662@nostromo.devel.redhat.com> References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> <20091217150905.GA1662@nostromo.devel.redhat.com> Message-ID: <168ef9ac0912170754h278a779di6b50cbebc25cb5c2@mail.gmail.com> Hm - perhaps it was as part of the first boot, post-anaconda. Basically, it was when I was asked to create a user account. I selected "use network login" (paraphrasing) instead of creating a local account. On Thu, Dec 17, 2009 at 10:09 AM, Bill Nottingham wrote: > Todd Volkert (tvolkert at gmail.com) said: > > The past few Fedora installs, I've specified a NIS server during the > > Anaconda installation so I don't have to create any local user accounts. > > However, once installation is complete, I can't log into any NIS > accounts > > because autofs insn't installed, causing the user accounts' home folders > to > > not be mounted. I have to sign in as root, install autofs, then all is > > well. > > How have you set up a NIS server as part of the install? It's not part > of the anaconda configuration screens. > > > My question is: shouldn't autofs be installed by default, as part of the > > base installation? > > For many use cases in Fedora, it's not needed; we're trying to keep the > core/base groups reasonably small. > > If you use kickstart, you can both set up NIS and install autofs with > directives in your kickstart file. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Thu Dec 17 16:08:16 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 Dec 2009 11:08:16 -0500 Subject: review request - rasmol, Molecular Graphics Visualization Tool In-Reply-To: <1259121054.9312.609.camel@adam.local.net> References: <1259103950.32674.82.camel@ns.five-ten-sg.com> <1259121054.9312.609.camel@adam.local.net> Message-ID: <4B2A5770.3000305@redhat.com> On 11/24/2009 10:50 PM, Adam Williamson wrote: > But I dunno if there's a policy > requirement that you should anyway. FWIW, the policy says: "If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window." https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files So, the rasmol app doesn't meet that criteria, so a .desktop file is not required (although, it is worth noting that it is also permitted if the maintainer wishes to do so). ~spot From loganjerry at gmail.com Thu Dec 17 16:13:44 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 17 Dec 2009 09:13:44 -0700 Subject: rpm cpio error: prelink and SBCL Message-ID: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> I'm trying to package up a Common Lisp application that is built with SBCL. Near the end of the rpmbuild run, I see this right before the list of Provides: prelink: /home/jamesjer/rpmbuild/BUILDROOT/pvs-sbcl-4.2-2.svn20091008.fc12.x86_64/usr/lib64/pvs/bin/ix86_64-Linux/runtime/pvs-sbclisp: Section .gnu.version created after prelinking The rpmbuild run appears to complete successfully. However, when I try to rpm -i the resulting rpm, I get this: # rpm -i pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm error: unpacking of archive failed on file /usr/lib64/pvs/bin/ix86_64-Linux/runtime/pvs-sbclisp;4b2a52f1: cpio: Digest mismatch # rpm -K pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm pvs-sbcl-4.2-2.svn20091008.fc12.x86_64.rpm: sha1 md5 OK Is that due to prelink? If so, what is broken? SBCL, because it isn't putting a .gnu.version section in the executable images it creates? Prelink, because it somehow manages to break the rpm? Both? And how do I build an RPM that can be installed successfully? Thanks, -- Jerry James http://www.jamezone.org/ From walters at verbum.org Thu Dec 17 17:05:15 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 17 Dec 2009 12:05:15 -0500 Subject: packages requiring me to reboot... In-Reply-To: <1261065070.21633.3.camel@code.and.org> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> <1261065070.21633.3.camel@code.and.org> Message-ID: On Thu, Dec 17, 2009 at 10:51 AM, James Antill wrote: > > ?How do you plan on restarting firefox? Or you just planning to kill() > and get the user to restart? Trying to send a close button event to the app's windows is probably our best short-term approach; slightly longer term, we could have apps expose a standard interface for Quit (e.g. over dbus). Knowing how to restart is trickier, (though we could use the window-to-app mapping system we need for gnome 3 anyways) but it's also very simple in this case if we require that packages contain at most one .desktop file. From yersinia.spiros at gmail.com Thu Dec 17 17:12:26 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Thu, 17 Dec 2009 18:12:26 +0100 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> Message-ID: On Thu, Dec 17, 2009 at 5:13 PM, Jerry James wrote: > Is that due to prelink? ?If so, what is broken? ?SBCL, because it You probably have a prelinked file in BUILD ROOT (objdump -s | grep prelink) . Try to get rid of this in %install with prelink -u Regards From pbrobinson at gmail.com Thu Dec 17 17:25:51 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 17 Dec 2009 17:25:51 +0000 Subject: Review swaps Message-ID: <5256d0b0912170925q346e769ch24ffe1cec162784b@mail.gmail.com> Hi All, Anyone interested in swapping a couple of package reviews? mx https://bugzilla.redhat.com/show_bug.cgi?id=538465 moblin-app-installer https://bugzilla.redhat.com/show_bug.cgi?id=546301 Regards, Peter From awilliam at redhat.com Thu Dec 17 18:22:20 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 17 Dec 2009 18:22:20 +0000 Subject: packages requiring me to reboot... In-Reply-To: <1261065070.21633.3.camel@code.and.org> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> <1261065070.21633.3.camel@code.and.org> Message-ID: <1261074140.3328.36.camel@vaio.local.net> On Thu, 2009-12-17 at 10:51 -0500, James Antill wrote: > > The UI isn't very pretty at the moment (it just fails with an update > > error) but I'll work on something a little bit more user friendly. > > How do you plan on restarting firefox? Or you just planning to kill() > and get the user to restart? If we're just talking about Firefox (i.e. not the general case), then it has its own 'restart Firefox' hook you might be able to access. It's used, for instance, when you enable or disable an extension. I'm not sure if you can poke it from an external app easily, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From loganjerry at gmail.com Thu Dec 17 18:24:59 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 17 Dec 2009 11:24:59 -0700 Subject: rpm cpio error: prelink and SBCL In-Reply-To: References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> Message-ID: <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> On Thu, Dec 17, 2009 at 10:12 AM, yersinia wrote: > You probably have a prelinked file in BUILD ROOT (objdump -s | > grep prelink) . Try to get rid of this in %install with prelink -u Oh ho! The sbcl executable has already been prelinked. When save-lisp-and-die is called (at least with :executable t), the sbcl executable itself is dumped with the Lisp core written into it. So we wind up with a prelinked image in the build directory, like so: ------------------------------------------------------------------------------ $ objdump -s /usr/bin/sbcl | grep -F prelink Contents of section .gnu.prelink_undo: $ sbcl This is SBCL 1.0.30-2.fc12, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (defun my-fun () "Isn't this fun?") MY-FUN * (save-lisp-and-die "sbcl-test" :executable t) [undoing binding stack and other enclosing state... done] [saving current Lisp image into sbcl-test: writing 6176 bytes from the read-only space at 0x20000000 writing 4064 bytes from the static space at 0x20100000 writing 42983424 bytes from the dynamic space at 0x1000000000 done] $ objdump -s sbcl-test | grep -F prelink Contents of section .gnu.prelink_undo: ------------------------------------------------------------------------------ So this is going to hit anybody who tries to package up an executable produced by SBCL. Perhaps this should be noted on https://fedoraproject.org/wiki/Packaging:Lisp. -- Jerry James http://www.jamezone.org/ From lsof at nodata.co.uk Thu Dec 17 18:50:04 2009 From: lsof at nodata.co.uk (nodata) Date: Thu, 17 Dec 2009 19:50:04 +0100 Subject: packages requiring me to reboot... In-Reply-To: <23500740FD384D88A5AAA0EC85366EBA@C515816A> References: <23500740FD384D88A5AAA0EC85366EBA@C515816A> Message-ID: <4B2A7D5C.6080106@nodata.co.uk> Am 2009-12-17 10:36, schrieb Otto Haliburton: > > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- >> bounces at redhat.com] On Behalf Of nodata >> Sent: Thursday, December 17, 2009 01:01 >> To: Development discussions related to Fedora >> Subject: Re: packages requiring me to reboot... >> >> Am 2009-12-17 00:08, schrieb Jeff Spaleta: >>> On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell >> wrote: >>>> Yes- users with more expertise are more likely to complain about this, >>>> but thats not reason to dismiss the issue. If there were truly a >>>> disconnect here betweens the needs of the novices and those of the >>>> expert users you could argue favouring the novices, but that just >>>> isn't applicable here. >>> >>> Uhm. am I missing something. Aren't we talking about reboot requests >>> that PK is spawning and I can choose to cancel in the UI interaction >>> because I know better instead of mandatory reboots? >>> >>> -jef >>> >> >> No, we're talking about requiring fewer reboots for normal users. >> >> Prompting a user like this teaches them to ignore recommendations. This >> isn't a good thing. >> > there are no mandatory reboots in PackageKit, you are notified what packages > will cause a request to reboot and you can exit the process without > rebooting!!!!!! Or you can remove the packages from the update processes > and install when convenient for you. yep. but all of that assumes I know what I am doing, and the people that this is aimed at don't. windows requires fewer reboots now. From przemek.klosowski at nist.gov Thu Dec 17 19:05:08 2009 From: przemek.klosowski at nist.gov (Przemek Klosowski) Date: Thu, 17 Dec 2009 14:05:08 -0500 Subject: packages requiring me to reboot... In-Reply-To: <4B2A7D5C.6080106@nodata.co.uk> References: <23500740FD384D88A5AAA0EC85366EBA@C515816A> <4B2A7D5C.6080106@nodata.co.uk> Message-ID: <4B2A80E4.8090501@nist.gov> On 12/17/2009 01:50 PM, nodata wrote: > yep. but all of that assumes I know what I am doing, and the people that > this is aimed at don't. windows requires fewer reboots now. +1, and remember that they have an advantage right off the bat: - much fewer subsystems (Windows and a couple of tiny apps, vs. Linux's entire universe of applications) - patch model that pushes large patch sets at long intervals rather than frequent fine-grained patches. I think Linux has to have a better heuristic as to when a reboot is necessary. Actually, any event that breaks the user's work flow is as bad: X crash/logoff is as disruptive as a reboot, unless we had a way to restore the application state in the way Firefox or Emacs or OpenOffice recover from crashes (restarting, opening the windows where they were and recovering the content). From cra at WPI.EDU Thu Dec 17 19:12:07 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 17 Dec 2009 14:12:07 -0500 Subject: Useless setroubleshoot alerts In-Reply-To: <364d303b0912090534o1f181c5dx912709ea8cc0bd70@mail.gmail.com> References: <364d303b0912090534o1f181c5dx912709ea8cc0bd70@mail.gmail.com> Message-ID: <20091217191207.GH25559@angus.ind.WPI.EDU> On Wed, Dec 09, 2009 at 01:34:45PM +0000, Christopher Brown wrote: > SELinux was quite good on F11 and F12. Now it would seem it is > starting to regress again. Your expectations are too high if you think rawhide shouldn't have regressions. From tcallawa at redhat.com Thu Dec 17 19:46:20 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 Dec 2009 14:46:20 -0500 Subject: 190 packages with .la file(s) In-Reply-To: <1259588547.27841.21.camel@localhost.localdomain> References: <1259582170.27841.11.camel@localhost.localdomain> <5ec8ebd50911300403m42004c8ua75464e5617b72a4@mail.gmail.com> <1259584838.27841.19.camel@localhost.localdomain> <5ec8ebd50911300503m5bb7f23p5ae1d2b9964a4976@mail.gmail.com> <1259588547.27841.21.camel@localhost.localdomain> Message-ID: <4B2A8A8C.2030809@redhat.com> On 11/30/2009 08:42 AM, Pierre-Yves wrote: > gambas2-2.18.0-1.fc12.src.rpm Gambas is... special. It needs these .la files to function. ~spot From ottohaliburton at tx.rr.com Thu Dec 17 19:55:23 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 17 Dec 2009 13:55:23 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B2A80E4.8090501@nist.gov> Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Przemek Klosowski > Sent: Thursday, December 17, 2009 13:05 > To: fedora-devel-list at redhat.com > Subject: Re: packages requiring me to reboot... > > On 12/17/2009 01:50 PM, nodata wrote: > > > yep. but all of that assumes I know what I am doing, and the people that > > this is aimed at don't. windows requires fewer reboots now. > > +1, and remember that they have an advantage right off the bat: > > - much fewer subsystems (Windows and a couple of tiny apps, vs. Linux's > entire universe of applications) > > - patch model that pushes large patch sets at long intervals rather than > frequent fine-grained patches. > > I think Linux has to have a better heuristic as to when a reboot is > necessary. Actually, any event that breaks the user's work flow is as > bad: X crash/logoff is as disruptive as a reboot, unless we had a way to > restore the application state in the way Firefox or Emacs or OpenOffice > recover from crashes (restarting, opening the windows where they were > and recovering the content). > I am now getting a picture of why this subject is so hard to grasp, everyone who is for fewer reboots address the issue on a task by task bases, while those who support reboots think of it on a system bases. Windows now restarts each time a patch occurs, at the current time I can't think of any patch in the last 3 months which hasn't required a reboot. Another reason is that some of the windows operating systems are coming to their end of life cycle, and windows is choosing to do a lot of patches in one update, but believe me, it is startling to come in the next morning to see your computer restarted with a message that a update was performed and you were restarted and that occurs with all of the windows operating systems that are currently supported. Linux has many applications that are running and on each update you can have as many as many as 65(the last update) task being updated each week and how you will avoid reboots will be amazing to me. I think then people will complain that it takes 6 hours to update now and it use to take 30 minutes. At the present time you have apps that run across logoff and login, so trying to get into starting and stopping task in update situations will be a nightmare, but if there are some ambitious people out there go at it, there are only 5000 apps that need to be updated to solve the problem. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From ewan at macmahon.me.uk Thu Dec 17 20:21:51 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Thu, 17 Dec 2009 20:21:51 +0000 Subject: packages requiring me to reboot... In-Reply-To: References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> <1261065070.21633.3.camel@code.and.org> Message-ID: <20091217202150.GE4126@macmahon.me.uk> On Thu, Dec 17, 2009 at 12:05:15PM -0500, Colin Walters wrote: > On Thu, Dec 17, 2009 at 10:51 AM, James Antill wrote: > > > > ?How do you plan on restarting firefox? Or you just planning to kill() > > and get the user to restart? > > Trying to send a close button event to the app's windows is probably > our best short-term approach; That would fail pretty badly in the case of Firefox with multiple windows open. Firefox's session support can restore multiple tabs to multiple windows if you quit it and restart, but if you have two windows open, close one, then close the second causing the browser to quit, then on restart the session that is restored will only contain the tabs from the second window. The logic goes that the first window was no longer part of the session when the app quit. Simply killing the process is actually less disruptive. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From loganjerry at gmail.com Thu Dec 17 20:48:20 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 17 Dec 2009 13:48:20 -0700 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> Message-ID: <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> On Thu, Dec 17, 2009 at 11:24 AM, Jerry James wrote: > So this is going to hit anybody who tries to package up an executable > produced by SBCL. ?Perhaps this should be noted on > https://fedoraproject.org/wiki/Packaging:Lisp. And it's even worse than I thought: "prelink -u saved-image" strips out the dumped Lisp image! I had a saved image go from 43MB to 171552 bytes when I did that. It looks like putting this in the spec file works: %global __prelink_undo_cmd %{nil} -- Jerry James http://www.jamezone.org/ From walters at verbum.org Thu Dec 17 20:52:46 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 17 Dec 2009 15:52:46 -0500 Subject: packages requiring me to reboot... In-Reply-To: <20091217202150.GE4126@macmahon.me.uk> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> <1261065070.21633.3.camel@code.and.org> <20091217202150.GE4126@macmahon.me.uk> Message-ID: On Thu, Dec 17, 2009 at 3:21 PM, Ewan Mac Mahon wrote: > > That would fail pretty badly in the case of Firefox with multiple > windows open. True; there's nothing stopping us from adding something Firefox-specific as a short term measure, since how it does session saving is fairly unique right now (ideally we add a nice API for this to GTK+ which then has to be mirrored in XUL). Killing the process though has the downside of triggering the "Well, that was embarassing..." which is arguably a Firefox bug though. Anyways, "the perfect is the enemy of the good", etc. From jakub at redhat.com Thu Dec 17 20:54:06 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 17 Dec 2009 15:54:06 -0500 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> Message-ID: <20091217205406.GF29158@hs20-bc2-1.build.redhat.com> On Thu, Dec 17, 2009 at 01:48:20PM -0700, Jerry James wrote: > On Thu, Dec 17, 2009 at 11:24 AM, Jerry James wrote: > > So this is going to hit anybody who tries to package up an executable > > produced by SBCL. ?Perhaps this should be noted on > > https://fedoraproject.org/wiki/Packaging:Lisp. > > And it's even worse than I thought: "prelink -u saved-image" strips > out the dumped Lisp image! I had a saved image go from 43MB to 171552 > bytes when I did that. It looks like putting this in the spec file > works: You need to first prelink -u on a copy of the program, then run it and let it dump itself, then package it up. I'd actually argue that such packaging is broken anyway, because you didn't compile the binary you are packaging from source, you copied it from /usr/bin. Jakub From mschwendt at gmail.com Thu Dec 17 21:07:04 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 17 Dec 2009 22:07:04 +0100 Subject: Electric Fence - still reliable? Message-ID: <20091217220704.523d5c06@gmail.com> Fedora 12 with LD_PRELOAD=libefence.so.0.0 EF_ALLOW_MALLOC_0=1, what is more likely that these are false positives or real bugs? --- $ gnome-terminal Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens Segmentation fault (core dumped) ==> in ORBit corba-any.c $ geeqie Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens Geeqie 1.0beta2, This is an alpha release. Could not init LIRC support ElectricFence Aborting: free(86c6e00): address not from malloc(). Illegal instruction (core dumped) ==> in glib2 gslice.c $ gnome-calculator Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens Segmentation fault (core dumped) ==> in ORBit iop-profiles.c $ audacious Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens ** (audacious:2106): WARNING **: Could not open file:///home/misc/.adplug/adplug.db for reading or writing: Error opening file: No such file or directory ElectricFence Aborting: free(910c700): address not from malloc(). Illegal instruction (core dumped) ==> gtkicontheme.c -> glib2 gsplice.c $ gnote Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens ElectricFence Aborting: free(91d1600): address not from malloc(). Illegal instruction (core dumped) ==> ? (didn't wait in ABRT for further 32 debuginfos to download) From lsof at nodata.co.uk Thu Dec 17 21:08:50 2009 From: lsof at nodata.co.uk (nodata) Date: Thu, 17 Dec 2009 22:08:50 +0100 Subject: packages requiring me to reboot... In-Reply-To: <059DEDF49D6F4FD4A97140F5463ADAC0@C515816A> References: <059DEDF49D6F4FD4A97140F5463ADAC0@C515816A> Message-ID: <4B2A9DE2.3030801@nodata.co.uk> Am 2009-12-17 15:02, schrieb Otto Haliburton: > > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- >> bounces at redhat.com] On Behalf Of Eelko Berkenpies >> Sent: Thursday, December 17, 2009 05:09 >> To: Development discussions related to Fedora >> Subject: Re: packages requiring me to reboot... >> >> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton >> wrote: >>> >>> ----- Original Message ----- From: "nodata" >>> To: "Development discussions related to Fedora" >>> >>> Sent: Wednesday, December 16, 2009 11:29 AM >>> Subject: Re: packages requiring me to reboot... >>> >>> >>>> Am 2009-12-16 18:21, schrieb Seth Vidal: >>>>> >>>>> >>>>> On Wed, 16 Dec 2009, nodata wrote: >>>>> >>>>>>> >>>>>>> we're talking about the experienced user who is comfortable knowing >>>>>>> what >>>>>>> does and does not need a reboot. >>>>>>> >>>>>>> All I'm saying is - we've not taken away any option, the experienced >>>>>>> user can do what they want. >>>>>>> >>>>>>> -sv >>>>>>> >>>>>> >>>>>> True, but the default should be sensible. >>>>> >>>>> And the default is sensible for the inexperienced user: >>>>> >>>>> Don't try to explain to the user how to restart the apps individually, >>>>> tell them to bounce the box and it will be the right version when it >>>>> comes back. >>>>> >>>>> -sv >>>>> >>>> >>>> On the other hand I think requiring more reboots than Windows is a bad >>>> thing... >>>> >>> windows update will automatically reboot your system when it >> automatically >>> updates it >>> windows tried the optional stuff but now almost every case it requires a >>> restart. >> >> I don't like the term "experienced user" and I never feel comfortable >> adding myself to that group but anyway, >> >> - I don't want Windows to automatically reboot so I disable the >> automatic Windows Update on the machines I'm using. >> >> - I don't want my Fedora to reboot automatically so I disable and >> remove PackageKit on the machines I'm using. >> >> There isn't that much I could say about the times Fedora ask for a >> reboot but at least I think it's kind of "unfair" to compare it with >> an OS which pushes their updates just once a month. >> >> Just my ? 0.02. > first of all PackageKit does not do mandatory reboots. If you hadn't > disabled it you would know that. In fact the people that are complaining > don't seem to have any idea why reboots are necessary. You need to get a > grip on file processing, cache, and other processes that speeds up execution > then you will know why it is not trivial. i.e. you kill a task that is in > the process of writing data to a file after you update it. What happens???? >> >> -- >> With kind regards / Met vriendelijke groet, >> >> Eelko Berkenpies >> http://blog.berkenpies.nl/ >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I wish mailing list discussions were point-for-point for-and-against. It would be so much easier. Here is my point: Windows requires a reboot less often than Linux. Argue all you want, it's true. Linux has quicker security updates than Linux. That's an advantage. ksplice can patch a running kernel... From loganjerry at gmail.com Thu Dec 17 21:09:35 2009 From: loganjerry at gmail.com (Jerry James) Date: Thu, 17 Dec 2009 14:09:35 -0700 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <20091217205406.GF29158@hs20-bc2-1.build.redhat.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> <20091217205406.GF29158@hs20-bc2-1.build.redhat.com> Message-ID: <870180fe0912171309x11a35c53obdec7c33926661aa@mail.gmail.com> On Thu, Dec 17, 2009 at 1:54 PM, Jakub Jelinek wrote: > You need to first prelink -u on a copy of the program, then > run it and let it dump itself, then package it up. Ah, thanks. > I'd actually argue that such packaging is broken anyway, because you didn't > compile the binary you are packaging from source, you copied it from > /usr/bin. True, so future sbcl updates wouldn't be reflected in the saved image. How should I deal with that? I can think of a few approaches. 1. Put an explicit versioned dependency on the sbcl used to build. Then every sbcl update breaks upgrades for anyone with my package installed until I get around to rebuilding it. It looks like maxima has taken this approach. 2. Don't dump an executable, but instead store individual FASL files that are loaded at runtime by whatever version of sbcl happens to be installed. The application I'm working with did not take this approach because of the large size of the application, which would lead to a significant startup delay. Plus, the SBCL documentation explicitly doesn't guarantee that FASL files generated by one version can be loaded and used without error by another version. 3. Compile sbcl AND the application I really want to build from source. Not only will that make my spec file significantly more complex, but then I have to stay on top of future sbcl updates so I can update my package, too. That doesn't seem any better than what I'm doing now (embedding the existing sbcl binary into my application). Even with its faults, #1 seems best to me. Does anybody see another approach that will work better? -- Jerry James http://www.jamezone.org/ From ottohaliburton at tx.rr.com Thu Dec 17 21:17:52 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 17 Dec 2009 15:17:52 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B2A9DE2.3030801@nodata.co.uk> Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of nodata > Sent: Thursday, December 17, 2009 15:09 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > Am 2009-12-17 15:02, schrieb Otto Haliburton: > > > > > >> -----Original Message----- > >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > >> bounces at redhat.com] On Behalf Of Eelko Berkenpies > >> Sent: Thursday, December 17, 2009 05:09 > >> To: Development discussions related to Fedora > >> Subject: Re: packages requiring me to reboot... > >> > >> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton > >> wrote: > >>> > >>> ----- Original Message ----- From: "nodata" > >>> To: "Development discussions related to Fedora" > >>> > >>> Sent: Wednesday, December 16, 2009 11:29 AM > >>> Subject: Re: packages requiring me to reboot... > >>> > >>> > >>>> Am 2009-12-16 18:21, schrieb Seth Vidal: > >>>>> > >>>>> > >>>>> On Wed, 16 Dec 2009, nodata wrote: > >>>>> > >>>>>>> > >>>>>>> we're talking about the experienced user who is comfortable > knowing > >>>>>>> what > >>>>>>> does and does not need a reboot. > >>>>>>> > >>>>>>> All I'm saying is - we've not taken away any option, the > experienced > >>>>>>> user can do what they want. > >>>>>>> > >>>>>>> -sv > >>>>>>> > >>>>>> > >>>>>> True, but the default should be sensible. > >>>>> > >>>>> And the default is sensible for the inexperienced user: > >>>>> > >>>>> Don't try to explain to the user how to restart the apps > individually, > >>>>> tell them to bounce the box and it will be the right version when it > >>>>> comes back. > >>>>> > >>>>> -sv > >>>>> > >>>> > >>>> On the other hand I think requiring more reboots than Windows is a > bad > >>>> thing... > >>>> > >>> windows update will automatically reboot your system when it > >> automatically > >>> updates it > >>> windows tried the optional stuff but now almost every case it requires > a > >>> restart. > >> > >> I don't like the term "experienced user" and I never feel comfortable > >> adding myself to that group but anyway, > >> > >> - I don't want Windows to automatically reboot so I disable the > >> automatic Windows Update on the machines I'm using. > >> > >> - I don't want my Fedora to reboot automatically so I disable and > >> remove PackageKit on the machines I'm using. > >> > >> There isn't that much I could say about the times Fedora ask for a > >> reboot but at least I think it's kind of "unfair" to compare it with > >> an OS which pushes their updates just once a month. > >> > >> Just my ? 0.02. > > first of all PackageKit does not do mandatory reboots. If you hadn't > > disabled it you would know that. In fact the people that are > complaining > > don't seem to have any idea why reboots are necessary. You need to get > a > > grip on file processing, cache, and other processes that speeds up > execution > > then you will know why it is not trivial. i.e. you kill a task that is > in > > the process of writing data to a file after you update it. What > happens???? > >> > >> -- > >> With kind regards / Met vriendelijke groet, > >> > >> Eelko Berkenpies > >> http://blog.berkenpies.nl/ > >> > >> -- > >> fedora-devel-list mailing list > >> fedora-devel-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > I wish mailing list discussions were point-for-point for-and-against. It > would be so much easier. > > Here is my point: Windows requires a reboot less often than Linux. Argue > all you want, it's true. I have three computers running windows XP Windows Vista and Windows Vista Premium 24 hours per day, I have 2 computers dedicated to Linux so I know what I am talking about. Windows is a commercial system, it gets paid for what it produces and so it would be nice for them to boot less, but now they reboot on every update and that is once a week generally on Tuesday. > > Linux has quicker security updates than Linux. That's an advantage. > > ksplice can patch a running kernel... If you really want that then you can design and use it yourself. I don't believe that anyone wants to patch a running Kernel especially without testing and not be able to recover the old kernel. Are you really thinking and considering the reasons for a reboot, #1 is simplicity!!! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From ottohaliburton at tx.rr.com Thu Dec 17 21:23:29 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Thu, 17 Dec 2009 15:23:29 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B2A9DE2.3030801@nodata.co.uk> Message-ID: <42CC46A77C6C42B699BA5AC1E4694D0A@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of nodata > Sent: Thursday, December 17, 2009 15:09 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > Am 2009-12-17 15:02, schrieb Otto Haliburton: > > > > > >> -----Original Message----- > >> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > >> bounces at redhat.com] On Behalf Of Eelko Berkenpies > >> Sent: Thursday, December 17, 2009 05:09 > >> To: Development discussions related to Fedora > >> Subject: Re: packages requiring me to reboot... > >> > >> On Wed, Dec 16, 2009 at 9:43 PM, Otto Haliburton > >> wrote: > >>> > >>> ----- Original Message ----- From: "nodata" > >>> To: "Development discussions related to Fedora" > >>> > >>> Sent: Wednesday, December 16, 2009 11:29 AM > >>> Subject: Re: packages requiring me to reboot... > >>> > >>> > >>>> Am 2009-12-16 18:21, schrieb Seth Vidal: > >>>>> > >>>>> > >>>>> On Wed, 16 Dec 2009, nodata wrote: > >>>>> > >>>>>>> > >>>>>>> we're talking about the experienced user who is comfortable > knowing > >>>>>>> what > >>>>>>> does and does not need a reboot. > >>>>>>> > >>>>>>> All I'm saying is - we've not taken away any option, the > experienced > >>>>>>> user can do what they want. > >>>>>>> > >>>>>>> -sv > >>>>>>> > >>>>>> > >>>>>> True, but the default should be sensible. > >>>>> > >>>>> And the default is sensible for the inexperienced user: > >>>>> > >>>>> Don't try to explain to the user how to restart the apps > individually, > >>>>> tell them to bounce the box and it will be the right version when it > >>>>> comes back. > >>>>> > >>>>> -sv > >>>>> > >>>> > >>>> On the other hand I think requiring more reboots than Windows is a > bad > >>>> thing... > >>>> > >>> windows update will automatically reboot your system when it > >> automatically > >>> updates it > >>> windows tried the optional stuff but now almost every case it requires > a > >>> restart. > >> > >> I don't like the term "experienced user" and I never feel comfortable > >> adding myself to that group but anyway, > >> > >> - I don't want Windows to automatically reboot so I disable the > >> automatic Windows Update on the machines I'm using. > >> > >> - I don't want my Fedora to reboot automatically so I disable and > >> remove PackageKit on the machines I'm using. > >> > >> There isn't that much I could say about the times Fedora ask for a > >> reboot but at least I think it's kind of "unfair" to compare it with > >> an OS which pushes their updates just once a month. > >> > >> Just my ? 0.02. > > first of all PackageKit does not do mandatory reboots. If you hadn't > > disabled it you would know that. In fact the people that are > complaining > > don't seem to have any idea why reboots are necessary. You need to get > a > > grip on file processing, cache, and other processes that speeds up > execution > > then you will know why it is not trivial. i.e. you kill a task that is > in > > the process of writing data to a file after you update it. What > happens???? > >> > >> -- > >> With kind regards / Met vriendelijke groet, > >> > >> Eelko Berkenpies > >> http://blog.berkenpies.nl/ > >> > >> -- > >> fedora-devel-list mailing list > >> fedora-devel-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > I wish mailing list discussions were point-for-point for-and-against. It > would be so much easier. > > Here is my point: Windows requires a reboot less often than Linux. Argue > all you want, it's true. > > Linux has quicker security updates than Linux. That's an advantage. > > ksplice can patch a running kernel... LOL, you have to be joking with all the stuff that blows up around here you would trust someone patch you kernel while it was running and especially if like me you run a custom built kernel. I applaud your trust and guts if you will stand for that. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From josephine.tannhauser at googlemail.com Thu Dec 17 21:47:01 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Thu, 17 Dec 2009 22:47:01 +0100 Subject: Review swaps In-Reply-To: <5256d0b0912170925q346e769ch24ffe1cec162784b@mail.gmail.com> References: <5256d0b0912170925q346e769ch24ffe1cec162784b@mail.gmail.com> Message-ID: <3668e9f50912171347l53dd8a1bi3212042eafbfd601@mail.gmail.com> 2009/12/17, Peter Robinson : > Anyone interested in swapping a couple of package reviews? I currently try to review 2 of your previous review request. you should finish them first.... -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From awilliam at redhat.com Thu Dec 17 23:25:49 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 17 Dec 2009 23:25:49 +0000 Subject: packages requiring me to reboot... In-Reply-To: <4B2A9DE2.3030801@nodata.co.uk> References: <059DEDF49D6F4FD4A97140F5463ADAC0@C515816A> <4B2A9DE2.3030801@nodata.co.uk> Message-ID: <1261092349.3328.47.camel@vaio.local.net> On Thu, 2009-12-17 at 22:08 +0100, nodata wrote: > Here is my point: Windows requires a reboot less often than Linux. Argue > all you want, it's true. It's entirely false, because Linux *never* requires a reboot. Fedora (not Linux, you are generalizing too far) *advises* reboots, it never requires them. Windows forces you to reboot - literally, you cannot prevent it from rebooting when it decides you have to. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From christoph.wickert at googlemail.com Fri Dec 18 00:23:27 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 18 Dec 2009 01:23:27 +0100 Subject: 190 packages with .la file(s) In-Reply-To: <1259588547.27841.21.camel@localhost.localdomain> References: <1259582170.27841.11.camel@localhost.localdomain> <5ec8ebd50911300403m42004c8ua75464e5617b72a4@mail.gmail.com> <1259584838.27841.19.camel@localhost.localdomain> <5ec8ebd50911300503m5bb7f23p5ae1d2b9964a4976@mail.gmail.com> <1259588547.27841.21.camel@localhost.localdomain> Message-ID: <1261095807.2646.38.camel@wicktop.localdomain> Am Montag, den 30.11.2009, 14:42 +0100 schrieb Pierre-Yves: > If I run: > for i in $(repoquery --disablerepo=rpmfusion\* -f "*.la" > --qf="%{name}.%{arch}" | grep "x86_64" | sort | uniq); do repoquery -s > $i; done | sort | uniq > exo-0.3.105-1.fc12.src.rpm fixed > gtkglextmm-1.2.0-10.fc12.src.rpm I took it over while ago because it's a dep of one of my packages. Need to look into that deeper. > xfce4-session-4.6.1-3.fc12.src.rpm fixed Christoph From mmcgrath at redhat.com Fri Dec 18 03:34:51 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Dec 2009 21:34:51 -0600 (CST) Subject: Outage Notification - 2009-12-18 02:00 UTC Message-ID: There will be an outage starting at 2009-12-18 02:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-12-18 02:00 UTC' Affected Services: Buildsystem CVS / Source Control Database Fedora Hosted Mail Mirror System Translation Services Websites Unaffected Services: Torrent DNS Fedora People Fedora Talk Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1884 Reason for Outage: We have a lot of temporary solutions in place from the move, we're moving things back to their more permanents solutions. The main outages won't last the full two hours. The vpn setup should only takes 10-20 minutes. The db1 migration will take at least an hour though. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to trackthe status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mmcgrath at redhat.com Fri Dec 18 03:55:10 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Dec 2009 21:55:10 -0600 (CST) Subject: Outage Notification - 2009-12-19 02:00 UTC In-Reply-To: References: Message-ID: Sorry everyone, I was off by a day. I've updated it. -Mike On Thu, 17 Dec 2009, Mike McGrath wrote: > There will be an outage starting at 2009-12-19 02:00 UTC, which will last > approximately 2 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2009-12-19 02:00 UTC' > > Affected Services: > > Buildsystem > CVS / Source Control > Database > Fedora Hosted > Mail > Mirror System > Translation Services > Websites > > Unaffected Services: > Torrent > DNS > Fedora People > Fedora Talk > > Ticket Link: > > https://fedorahosted.org/fedora-infrastructure/ticket/1884 > > Reason for Outage: > We have a lot of temporary solutions in place from the move, we're moving > things back to their more permanents solutions. The main outages won't > last the full two hours. The vpn setup should only takes 10-20 minutes. > The db1 migration will take at least an hour though. > > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to > trackthe status of this outage. > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jkeating at redhat.com Fri Dec 18 05:16:50 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 Dec 2009 21:16:50 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1260847279.21725.3.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> Message-ID: <1261113410.19834.21.camel@localhost.localdomain> On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: > git://publictest5.fedoraproject.org/git/pkgs/ eg if you wished > to clone the kernel, you'd type: > > git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Just an FYI, the hostname (and path) changed slightly. git clone git://pkgs.stg.fedoraproject.org/kernel I hope to have ssh authenticated push support ready in the next day or so, complete with the same ACLs we have currently with CVS. I could use a lot of people cloning and committing to test the performance of the ACL system. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From maxamillion at gmail.com Fri Dec 18 05:28:44 2009 From: maxamillion at gmail.com (Adam Miller) Date: Thu, 17 Dec 2009 23:28:44 -0600 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1261002396.3328.14.camel@vaio.local.net> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> <1261002396.3328.14.camel@vaio.local.net> Message-ID: +1 to Adam W because I'm an ultra git neophyte (and a CVS one for that matter) but the current make file automation essentially removes that as an issue. I'm not saying I'm against learning git if need be, but I agree that it would be an unfortunate regression. -Adam (From Android - CM) On Dec 16, 2009 4:27 PM, "Adam Williamson" wrote: On Wed, 2009-12-16 at 10:42 -0500, Simo Sorce wrote: > But for anyone that does not using "master" ... I would hope you don't have to. To be a Fedora maintainer you hardly have to know a thing about CVS, after all - you can do all common operations via the Makefiles. I would hope the fpkg (or whatever) tool will do the same for the git-based system; if not, I'd consider that a significant regression. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/list... -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at shmuelhome.mine.nu Fri Dec 18 08:07:06 2009 From: fedora at shmuelhome.mine.nu (shmuel siegel) Date: Fri, 18 Dec 2009 10:07:06 +0200 Subject: packages requiring me to reboot... In-Reply-To: References: Message-ID: <4B2B382A.5040408@shmuelhome.mine.nu> Otto Haliburton wrote: > > Windows now > restarts each time a patch occurs, at the current time I can't think of any > patch in the last 3 months which hasn't required a reboot. Another reason is > that some of the windows operating systems are coming to their end of life > cycle, and windows is choosing to do a lot of patches in one update, but > believe me, it is startling to come in the next morning to see your computer > restarted with a message that a update was performed and you were restarted > and that occurs with all of the windows operating systems that are currently > supported. Please be consistent. Windows also doesn't *have* to auto restart. My systems are set to manual update of predownloaded files. Besides, since my systems are dual (or more) boot, they wouldn't auto reboot into the running version of windows. Would be very annoying. From pbrobinson at gmail.com Fri Dec 18 09:21:49 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 18 Dec 2009 09:21:49 +0000 Subject: 190 packages with .la file(s) In-Reply-To: <1259588547.27841.21.camel@localhost.localdomain> References: <1259582170.27841.11.camel@localhost.localdomain> <5ec8ebd50911300403m42004c8ua75464e5617b72a4@mail.gmail.com> <1259584838.27841.19.camel@localhost.localdomain> <5ec8ebd50911300503m5bb7f23p5ae1d2b9964a4976@mail.gmail.com> <1259588547.27841.21.camel@localhost.localdomain> Message-ID: <5256d0b0912180121r4a2f609du2ceac6623436d0db@mail.gmail.com> > sugar-base-0.86.0-1.fc12.src.rpm > sugar-datastore-0.86.1-1.fc12.src.rpm > sugar-toolkit-0.86.2-1.fc12.src.rpm I've fixed these 3 up. Cheers, Peter From ottohaliburton at tx.rr.com Fri Dec 18 10:11:56 2009 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Fri, 18 Dec 2009 04:11:56 -0600 Subject: packages requiring me to reboot... In-Reply-To: <4B2B382A.5040408@shmuelhome.mine.nu> Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of shmuel siegel > Sent: Friday, December 18, 2009 02:07 > To: Development discussions related to Fedora > Subject: Re: packages requiring me to reboot... > > Otto Haliburton wrote: > > > > Windows now > > restarts each time a patch occurs, at the current time I can't think of > any > > patch in the last 3 months which hasn't required a reboot. Another > reason is > > that some of the windows operating systems are coming to their end of > life > > cycle, and windows is choosing to do a lot of patches in one update, but > > believe me, it is startling to come in the next morning to see your > computer > > restarted with a message that a update was performed and you were > restarted > > and that occurs with all of the windows operating systems that are > currently > > supported. > Please be consistent. Windows also doesn't *have* to auto restart. My > systems are set to manual update of predownloaded files. Besides, since > my systems are dual (or more) boot, they wouldn't auto reboot into the > running version of windows. Would be very annoying. > you don't follow the list very well, and obviously didn't read the post that this replies to so don't go around calling people inconsistent. Windows forces you to reboot and there is no mandatory reboots in Linux and windows does force you to restart, don't restart when it ask you and see what happens, it will not continue without insisting that you restart. Where do you get this crap? With windows you cannot avoid a restart. And there is no auto-restart in windows it is auto-update and with auto-update you have no choice it will restart for you. Try it then tell me about it. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From awilliam at redhat.com Fri Dec 18 10:28:57 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 18 Dec 2009 10:28:57 +0000 Subject: packages requiring me to reboot... In-Reply-To: References: Message-ID: <1261132137.2437.14.camel@vaio.local.net> On Fri, 2009-12-18 at 04:11 -0600, Otto Haliburton wrote: > you don't follow the list very well, and obviously didn't read the post that > this replies to so don't go around calling people inconsistent. Windows > forces you to reboot and there is no mandatory reboots in Linux and windows > does force you to restart, don't restart when it ask you and see what > happens, it will not continue without insisting that you restart. Where do > you get this crap? With windows you cannot avoid a restart. And there is no > auto-restart in windows it is auto-update and with auto-update you have no > choice it will restart for you. Try it then tell me about it. You're arguing from different starting points, and there's no need to be uncivil about it. Shmuel's point is that you can disable automatic updates on Windows (which is quite true), and hence you won't then be forced to restart until you manually choose to install the updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From mschwendt at gmail.com Fri Dec 18 10:55:30 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 18 Dec 2009 11:55:30 +0100 Subject: Electric Fence - still reliable? In-Reply-To: <20091217220704.523d5c06@gmail.com> References: <20091217220704.523d5c06@gmail.com> Message-ID: <20091218115530.27c882b7@gmail.com> On Thu, 17 Dec 2009 22:07:04 +0100, I wrote: > Fedora 12 with LD_PRELOAD=libefence.so.0.0 EF_ALLOW_MALLOC_0=1, what is > more likely that these are false positives or real bugs? It's hard to find GNOME/GTK apps that don't crash. One that works fine in efence is "gnome-about". Many non-GUI tools also pass. procps's w doesn't, and that's not a false positive: $ w Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens Segmentation fault (core dumped) ==> setlocale() usage bug, https://bugzilla.redhat.com/548711 $ eog Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens Segmentation fault (core dumped) ==> in ORBit corba-any.c once more $ evince Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens ElectricFence Aborting: free(91dcd80): address not from malloc(). Illegal instruction (core dumped) ==> in glib2 gslice.c once more $ emacs Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens ElectricFence Aborting: realloc(84203b8, 2037): address not from malloc(). Fatal error (4)Illegal instruction (core dumped) From bnocera at redhat.com Fri Dec 18 11:18:30 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 18 Dec 2009 11:18:30 +0000 Subject: Electric Fence - still reliable? In-Reply-To: <20091218115530.27c882b7@gmail.com> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> Message-ID: <1261135110.12311.3512.camel@localhost.localdomain> On Fri, 2009-12-18 at 11:55 +0100, Michael Schwendt wrote: > On Thu, 17 Dec 2009 22:07:04 +0100, I wrote: > > > Fedora 12 with LD_PRELOAD=libefence.so.0.0 EF_ALLOW_MALLOC_0=1, what is > > more likely that these are false positives or real bugs? > > It's hard to find GNOME/GTK apps that don't crash. One that works fine > in efence is "gnome-about". > > Many non-GUI tools also pass. procps's w doesn't, and that's not a false > positive: > > $ w > > Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens > Segmentation fault (core dumped) > > ==> setlocale() usage bug, https://bugzilla.redhat.com/548711 > > > $ eog > > Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens > Segmentation fault (core dumped) > > ==> in ORBit corba-any.c once more All the GNOME apps that use GConf or ORBit will fail because you need to set the alignment to 8. Same problem under valgrind. From pknirsch at redhat.com Fri Dec 18 11:21:43 2009 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 18 Dec 2009 12:21:43 +0100 Subject: safe way to standby sata hdd? In-Reply-To: <4B2A4E09.8080504@redhat.com> References: <596b53e0912160458s39725262g28e5885e28fd6867@mail.gmail.com> <4B290042.6010609@redhat.com> <596b53e0912160917h4ac17b6fh99f4d02e46b901ec@mail.gmail.com> <4B2A4E09.8080504@redhat.com> Message-ID: <4B2B65C7.7090107@redhat.com> On 12/17/2009 04:28 PM, Eric Sandeen wrote: > Micha? Piotrowski wrote: >> 2009/12/16 Eric Sandeen: >>> Micha? Piotrowski wrote: >>>> Hi, >>>> >>>> I've got a home database/symfony env/etc../file server. It's based on >>>> Intel D945GCLF2D Atom board. I've got a two hard drives WD Green Power >>>> connected through Sata. First drive has / and /home filesystem, second >>>> has /home/samba4. On the first drive there are two directories >>>> /home/samba2 and /home/samba3 where I'm mounting ecryptfs. >>>> /home/samba4 is also crypted by default. >>>> >>>> I'm wondering if there is a safe way for such configuration to put >>>> second harddrive into sleep (or both drives) after some idle time? >>>> After some googling I've found some resolutions (haven't tested any of >>>> these yet): >>>> - hdparm -S >>> I use this for the data drive on my mythbox. I just put this in my >>> /etc/rc.local - >>> >>> # Spin down in 1 hours idle time >>> hdparm -S 240 /dev/sda >> >> Have you used this for a disk with your rootfs? > > In the past I have, but lately getting the root to actually get idle > is just about impossible it seems. I now have an ssd root and > don't bother. > Hm, have you tried running the diskdevstat available in tuned-utils? It should give you a pretty good idea whats causing the most wakeups. And if you find any, could you please open bugzillas for them and add them to the wakeup tracker for drivers: https://bugzilla.redhat.com/show_bug.cgi?id=454582 Thanks! Also, are you using a fresh install with relatime active for your system partitions? I've personally seen quite a difference if relatime was active as we do have occasional reads on idle systems that previously caused metadata writes due to atime changes. >>> (yeah, oddly, sda is not my boot drive) :) >>> >>>> - sdparm --set=STANDBY >>>> - and laptop_tools >>>> >>>> I'm really not convinced that these methods are safe for my >>>> configuration. Anyone have tried this before? >>> Yep. What kind of safety are you worried about? >> >> I know that ecryptfs is just fs stack on top of my ext3 partition, but >> still I care about data integrity. > > Ok but what does that have to do with spinning down a disk? :) > >>> It should just work, >>> although you want a long enough idle time that you're not constantly >>> spinning the disk up and down. >> >> Actually /home/samba4 is not mounted all the time - I'm umountig this >> fs when I'm not using it. I'm wondering if there will be any problems >> with data integrity when I forgot to umount ecryptfs and disk will be >> stopped. > > I don't think so. Any access should just spin up the disk and carry on. > > -Eric > >>> Is there any nice user-friendly frontend to set this? It'd be nice >>> to expose more power management choices to the users (for anything >>> that can't be easily defaulted, that is). >>> >>> -Eric >> >> Regards, >> Michal >> > -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From mschwendt at gmail.com Fri Dec 18 11:58:33 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 18 Dec 2009 12:58:33 +0100 Subject: Electric Fence - still reliable? In-Reply-To: <1261135110.12311.3512.camel@localhost.localdomain> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> <1261135110.12311.3512.camel@localhost.localdomain> Message-ID: <20091218125833.2663dfc3@gmail.com> On Fri, 18 Dec 2009 11:18:30 +0000, Bastien wrote: > > $ eog > > > > Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens > > Segmentation fault (core dumped) > > > > ==> in ORBit corba-any.c once more > > All the GNOME apps that use GConf or ORBit will fail because you need to > set the alignment to 8. Same problem under valgrind. Okay, different crash then. If I do that, it also ends up with the glib2 gslice.c crash instead: > ElectricFence Aborting: free(8941480): address not from malloc(). > Illegal instruction (core dumped) Even "irssi" runs into that one. From rawhide at fedoraproject.org Fri Dec 18 13:20:12 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 18 Dec 2009 13:20:12 +0000 Subject: rawhide report: 20091218 changes Message-ID: <20091218132012.GA21413@releng2.fedora.phx.redhat.com> Compose started at Fri Dec 18 08:15:14 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 chunkd-0.6-0.3.g756ea210.fc13.i686 requires libtokyocabinet.so.8 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tokyotyrant-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) chunkd-0.6-0.3.g756ea210.fc13.i686 requires libtokyocabinet.so.8 chunkd-0.6-0.3.g756ea210.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.i686 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-devel-0.5.0.0-10.fc12.x86_64 requires ghc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-doc-0.5.0.0-10.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-zlib-prof-0.5.0.0-10.fc12.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tokyotyrant-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package hostname Utility to set/show the host name or domain name New package perl-PDF-Create Create PDF files New package symkey Symmetric Key JNI Package Updated Packages: 389-ds-base-1.2.5-0.4.rc3.fc13 ------------------------------ * Thu Dec 17 2009 Rich Megginson - 1.2.5-0.4.rc3 - 1.2.5.rc3 release * Mon Dec 07 2009 Rich Megginson - 1.2.5-0.3.rc2 - 1.2.5.rc2 release Miro-2.5.4-1.fc13 ----------------- * Thu Dec 17 2009 Alex Lancaster - 2.5.4-1 - Update to upstream 2.5.4. - Hopefully fixes a whole slew of crashes (#540301, #540535, #540543) (#544047, #545681, #546141, #528036, #540207, #544889, #547062) PyQuante-1.6.3-3.fc13 --------------------- * Thu Dec 17 2009 Jussi Lehtola - 1.6.3-3 - Fix FTBFS on Fedora 13. R-Biobase-2.6.1-1.fc13 ---------------------- * Thu Dec 17 2009 pingou 2.6.1-1 - Update to 2.6.1 R-IRanges-1.4.9-1.fc13 ---------------------- * Thu Dec 17 2009 pingou 1.4.9-1 - Update to 1.4.9 R-RUnit-0.4.25-1.fc13 --------------------- * Thu Dec 17 2009 pingou 0.4.25-1 - Update to 0.4.25 TurboGears-1.0.9-2.fc13 ----------------------- * Thu Dec 17 2009 Toshio Kuratomi - 1.0.9-2 - Update sql create patch for traceback when used in development mode RHBZ#548594 alexandria-0.6.6-0.2.alpha.fc13 ------------------------------- * Fri Dec 18 2009 Mamoru Tasaka - 0.6.6-0.2.alpha - Use "rake install_package_staging" as explained by the upstream (in alexandria-Bugs-27578) - Kill the creation of 64/128 icons as scalable svg is already installed asunder-1.9.1-1.fc13 -------------------- * Thu Dec 10 2009 Marcin Zajaczkowski - 1.9.1-1 - updated to 1.9.1 binutils-2.20.51.0.2-10.fc13 ---------------------------- * Thu Dec 17 2009 Nick Clifton - 2.20.51.0.2-10 - Apply patch for PR 11088. (BZ 544149) docbook-dtds-1.0-50.fc13 ------------------------ * Thu Dec 17 2009 Ondrej Vasik - 1.0-50 - comment patches - License: Copyright only * Tue Oct 27 2009 Ondrej Vasik - 1.0-49 - do not obsolete self drupal-6.15-1.fc13 ------------------ * Thu Dec 17 2009 Jon Ciesla - 6.15-1 - Update to 6.15, SA-CORE-2009-009. eclipse-birt-2.5.1-1.fc13 ------------------------- * Thu Dec 17 2009 Alexander Kurtakov 2.5.1-1 - Update to 2.5.1. eclipse-mylyn-3.3.1-1.fc13 -------------------------- * Thu Dec 17 2009 Alexander Kurtakov 3.3.1-1 - Update to 3.3.1 version. efte-1.1-1.fc13 --------------- emacs-spice-mode-1.2.25-3.fc12 ------------------------------ * Wed Dec 16 2009 Arun SAG - 1.2.25-3 - Exculded ppc64 which caused broken dependencies espeak-1.42.04-1.fc13 --------------------- * Thu Dec 17 2009 Francois Aucamp - 1.42.04-1 - Update to version 1.42.04 - Revert: build against PortAudio instead of native PulseAudio (RHBZ #512190, #532674) evolution-rss-0.1.4-12.fc12 --------------------------- * Tue Dec 08 2009 Lucian Langa - 0.1.4-11 - fix for bug #542206 * Tue Dec 08 2009 Lucian Langa - 0.1.4-12 - upstream patch to fix status icon crash * Thu Nov 26 2009 Lucian Langa - 0.1.4-10 - add 2 upstream patches that fixes possible crashes * Tue Nov 24 2009 Lucian Langa - 0.1.4-9 - new patch from upstream to fix reading feeds for evo > 2.28.1 * Mon Nov 23 2009 Lucian Langa - 0.1.4-8 - upstream patch to fix a crash in displaying folder icons (#539649) * Thu Nov 05 2009 Lucian Langa - 0.1.4-7 - add new upstream fix for feeds fetching for evolution > 2.28.1 * Mon Oct 26 2009 Lucian Langa - 0.1.4-6 - add upstream patch to fix loading of feeds for evo >= 2.28.1 exo-0.3.106-2.fc13 ------------------ * Thu Dec 17 2009 Christoph Wickert - 0.3.106-1 - Update to 0.3.106 - Remove upstreamed sync patch * Thu Dec 17 2009 Christoph Wickert - 0.3.106-2 - Remove libtool archive from python-exo package firefox-3.6.1-0.6.b4.fc13 ------------------------- gnome-keyring-2.28.2-1.fc12 --------------------------- * Wed Dec 16 2009 Tomas Bzatek - 2.28.2-1 - Update to 2.28.2 gnomecatalog-0.3.4.2-3.fc12 --------------------------- * Thu Oct 22 2009 Marc Wiriadisastra - 0.3.4.2-3 - Patch for permissions added thanks to Alexander Ovcharenko - Closes bug bz 509237 - Clean up the spec file removing the F9 python-setuptools buildrequires hunspell-pl-0.20091217-1.fc13 ----------------------------- * Thu Dec 17 2009 Caolan McNamara - 0.20091217-1 - latest version jna-3.2.4-3.fc13 ---------------- * Thu Dec 17 2009 Alexander Kurtakov 3.2.4-2 - Comment rhel ExclusiveArchs - not correct applies on Fedora. * Thu Dec 17 2009 Levente Farkas - 3.2.4-3 - add proper ExclusiveArch kernel-2.6.32.1-11.fc13 ----------------------- * Thu Dec 17 2009 Jarod Wilson 2.6.32.1-11 - Split off onboard decode imon devices into pure input driver, leaving lirc_imon for the ancient imon devices only - Fix NULL ptr deref in lirc_serial (#543886) - Assorted lirc_mceusb fixups suggested by Mauro - Dropped compat ioctls from lirc_dev, main ioctls should now be compatible between 32-bit and 64-bit (also at Mauro's suggestion) ktorrent-3.3.2-1.fc13 --------------------- * Thu Dec 17 2009 Rex Dieter - 3.3.2-1 - ktorrent-3.3.2 libassuan-1.0.5-4.fc13 ---------------------- * Thu Dec 17 2009 Tomas Mraz - 1.0.5-3 - Fix license tag - the documentation is GPLv3+ * Thu Dec 17 2009 Rex Dieter - 1.0.5-4 - better versioning for Obsoletes - better (upstreamable) multilib patch libksba-1.0.6-4.fc13 -------------------- * Thu Dec 17 2009 Rex Dieter - 1.0.6-4 - better (upstreamable) multilib patch - tighten %files a bit libpreludedb-0.9.15.3-1.fc13 ---------------------------- * Thu Dec 17 2009 Steve Grubb 0.9.15.3-1 - new upstream bugfix release libpst-0.6.45-1.fc13 -------------------- * Wed Nov 18 2009 Carl Byington - 0.6.45-1 - patch from Hugo DesRosiers to export categories and notes into vcards. lm_sensors-3.1.1-7.fc13 ----------------------- * Thu Dec 17 2009 Nikola Pajkovsky - 3.1.1-7 - Resovles: #226101 - Merge Review: lm_sensors logrotate-3.7.8-6.fc13 ---------------------- * Wed Dec 09 2009 Henrique Martins 3.7.8-6 - fix #545919 (rotate non-writable files when copy is set) m17n-db-1.5.5-2.fc13 -------------------- * Fri Dec 18 2009 Jens Petersen - 1.5.5-2 - add common-cjk option to mk_pkg for zh and ko - use mk_pkg for zh, el, ka, ug - bring back ja-anthy and en-ispell - cleanup trailing whitespace mailx-12.4-5.fc13 ----------------- * Fri Dec 18 2009 Ivana Hutarova Varekova - 12.4-5 - fix license tag metacity-2.28.0-14.fc13 ----------------------- * Thu Dec 17 2009 Owen Taylor - 2.28.0-14 - Fix crash in in tooltip on_style_set() (rhbz 546509) - Fix Crash in SmcSetProperties() on exit (rhbz 539905, gnome 604867) mingw32-gcc-4.4.2-2.fc13 ------------------------ * Thu Dec 17 2009 Chris Bagwell - 4.4.2-2 - Enable libgomp support. mpich2-1.2.1-4.fc13 ------------------- * Wed Dec 16 2009 Jay Fenlason - 1.2.1-4 - add the m_option macro to replace hardcoding -m{__isa_bits} and define it correctly for s390, where __isa_bits is 32, but the option to pass to gcc et all is -m31. * Thu Dec 10 2009 Deji Akingunola - 1.2.1-4 - Remove the *.a libs that have the shared version - Place the rpm macro in the -devel subpackage - Move the module file around (again!) to /etc/modufiles/. munin-1.4.2-1.fc13 ------------------ * Thu Dec 17 2009 Ingvar Hagelund - 1.4.2-1 - New upstream release - Removed upstream packaged fonts - Added a patch that makes rrdtool use the system bitstream vera fonts on rhel < 6 and fedora < 11 mutt-1.5.20-2.20091214hg736b6a.fc13.1 ------------------------------------- * Thu Dec 17 2009 Deji Akingunola - 5:1.5.20-2.20091214hg736b6a.1 - Rebuild for tokyocabinet new release soname bump mysql-5.1.41-2.fc13 ------------------- * Thu Dec 17 2009 Tom Lane 5.1.41-2 - Stop waiting during "service mysqld start" if mysqld_safe exits Resolves: #544095 mythes-es-0.20091217-1.fc13 --------------------------- * Thu Dec 17 2009 Caol?n McNamara - 0.20091217-1 - latest version mythes-sl-0.20091217-1.fc13 --------------------------- * Thu Dec 17 2009 Caolan McNamara - 0.20091217-1 - latest version notification-daemon-engine-slider-0.2.0-2.fc13 ---------------------------------------------- * Thu Dec 17 2009 Matthias Clasen - 0.2.0-2 - Fix a sporadic crash (#548504) ocaml-omake-0.9.8.5-10.fc13 --------------------------- * Thu Dec 17 2009 Richard W.M. Jones - 0.9.8.5-10 - Add 'Provides: omake' (RHBZ#548536). - Remove OCaml from the summary, since omake is not an OCaml-specific tool. openoffice.org-3.2.0-8.1.fc13 ----------------------------- * Thu Dec 17 2009 Caol?n McNamara - 1:3.2.0-8.1 - latest milestone - drop integrated openoffice.org-3.1.0.ooo90439.sfx2.qstart.hackaround.patch - drop integrated workspace.fwk132.patch - drop unnecessary openoffice.org-2.4.0.rh133741.alwaysgtk.vcl.patch - drop integrated openoffice.org-3.2.0.ooo105988.svx.a11ycrash.patch - drop integrated openoffice.org-3.2.0.ooo107151.sc.pop-empty-cell.patch pam-1.1.1-1.fc13 ---------------- * Thu Dec 17 2009 Tomas Mraz 1.1.1-1 - new upstream version with minor changes perl-File-Find-Rule-0.32-1.fc13 ------------------------------- * Mon Dec 14 2009 Ralf Cors?pius - 0.32-1 - Upstream update. perl-Test-Script-1.07-1.fc13 ---------------------------- * Tue Dec 15 2009 Ralf Cors?pius - 1.07-1 - Upstream update. - Reflect Source0-URL having changed. * Fri Dec 04 2009 Stepan Kasal - 1.06-2 - rebuild against perl 5.10.1 php-phpunit-File-Iterator-1.1.1-2.fc13 -------------------------------------- * Thu Dec 17 2009 Christof Damian 1.1.1-1 - upstream 1.1.1 * Thu Dec 17 2009 Christof Damian 1.1.1-2 - version 1.1.1 lowered the php requirement policycoreutils-2.0.78-6.fc13 ----------------------------- * Thu Dec 17 2009 Dan Walsh 2.0.78-6 - Add setools-libs-python to requires for gui pytc-0.8-4.fc13 --------------- * Thu Dec 17 2009 Deji Akingunola - 0.8-4 - Rebuild for tokyocabinet new release soname bump python-2.6.4-4.fc13 ------------------- * Wed Dec 16 2009 David Malcolm - 2.6.4-4 - automatically disable arena allocator when run under valgrind (upstream issue 2422; patch 52) - add patch from Josh Boyer containing diff against upstream PyBSDDB to make the bsddb module compile against db-4.8 (patch 53, #544275); bump the necessary version of db4-devel to 4.8 - patch setup.py so that it searches for db-4.8, and enable debug output for said search; make Setup.dist use db-4.8 (patch 54) python-markdown-2.0.3-1.fc13 ---------------------------- * Thu Oct 08 2009 Thomas Moschny - 2.0.3-1 - Update to 2.0.3. python-pip-0.6.1-1.fc13 ----------------------- python-suds-0.3.8-1.fc13 ------------------------ * Wed Dec 09 2009 jortel - 0.3.8-1 - Includeds Windows NTLM Transport. - Add missing self.messages in Client.clone(). - Changed default behavior for WSDL PartElement to be optional. - Add support for services/ports defined without
element in WSDL. - Fix sax.attribute.Element.attrib() to find by name only when ns is not specified; renamed to Element.getAttribute(). - Update HttpTransport to pass timeout parameter to urllib2 open() methods when supported by urllib2. - Add null class to pass explicit NULL values for parameters and optional elements. - Soap encoded array (soap-enc:Array) enhancement for rpc/encoded. Arrays passed as python arrays - works like document/literal now. No more using the factory to create the Array. Automatically includes arrayType attribute. Eg: soap-enc:arrayType="Array[2]". Reintroduced ability to pass complex (objects) using python dict instead of suds object via factory. - Fixed tickets: #84, #261, #262, #263, #265, #266, #278, #280, #282. rsh-0.17-61.fc13 ---------------- * Thu Dec 17 2009 Adam Tkac - 0.17-61 - include README and BUGS files as documentation (#226379) samba-3.5.0-51pre2.fc13 ----------------------- * Tue Dec 15 2009 Guenther Deschner - 3.5.0pre2-51 - Update to 3.5.0pre2 - Remove umount.cifs * Wed Nov 25 2009 Guenther Deschner - 3.4.3-49 - Various updates to inline documentation in default smb.conf file - resolves: #483703 * Thu Oct 29 2009 Guenther Deschner - 3.4.3-48 - Update to 3.4.3 scummvm-tools-1.0.0-1.fc12 -------------------------- * Sat Nov 28 2009 Lucian Langa - 1.0.0-1 - new upstream release seamonkey-2.0.1-1.fc13 ---------------------- * Thu Dec 17 2009 Jan Horak - 2.0.1-1 - Update to 2.0.1 selinux-policy-3.7.4-4.fc13 --------------------------- setup-2.8.12-1.fc13 ------------------- * Thu Dec 17 2009 Ondrej Vasik 2.8.12-1 - speed up pathmunge inside bashrc (#544652) - do not use deprecated egrep in profile syslinux-3.83-2.fc13 -------------------- * Thu Dec 17 2009 Peter Jones - 3.83-2 - Split out -devel tokyocabinet-1.4.41-1.fc13 -------------------------- * Thu Dec 17 2009 Deji Akingunola - 1.4.41-1 - Update to 1.4.41 transmission-1.80b3-1.fc13 -------------------------- * Thu Dec 17 2009 Rahul Sundaram - 1.80b3-1 - 1.80 Beta 3 - Enable sounds via libcanberra - http://trac.transmissionbt.com/wiki/Changes#version-1.80b3 uim-1.5.7-1.fc13 ---------------- * Fri Dec 18 2009 Akira TAGOH - 1.5.7-1 - New upstream release. - Fix a crash in firefox. (#543813) - uim-1.4.2-emacs23.patch: removed. it's not needed anymore. vsftpd-2.2.2-2.fc13 ------------------- * Thu Dec 17 2009 Jiri Skala - 2.2.2-1 - update to latest upstream * Thu Dec 17 2009 Jiri Skala - 2.2.2-2 - corrected two patches due to fuzz 0 webkit-sharp-0.3-1.fc13 ----------------------- * Thu Dec 17 2009 Paul Lange - 0.3-1 - Update to version 0.3 wireshark-1.2.4-3.fc13 ---------------------- * Thu Dec 17 2009 Radek Vokal - 1.2.4-3 - split -devel package (#547899, #203642, #218451) - removing root warning dialog (#543709) xdg-utils-1.0.2-16.20091217cvs.fc13 ----------------------------------- * Thu Dec 17 2009 Rex Dieter - 1.0.2-16.20091217cvs - xdg-mime: line 531: kde-config: command not found (#545702) - xdg-email calls gconftool which doesn't exist (#548529) xfce4-session-4.6.1-5.fc13 -------------------------- * Thu Dec 17 2009 Christoph Wickert - 4.6.1-5 - Remove libtool archives of splash engines xine-ui-0.99.6-0.1.20091217hg.fc13 ---------------------------------- * Thu Dec 17 2009 Jussi Lehtola - 0.99.6-0.1.20091217hg - Switch to development branch by suggestion of upstream to fix some bugs. xulrunner-1.9.2.1-0.7.b4.fc13 ----------------------------- * Thu Dec 17 2009 Martin Stransky 1.9.2.1-0.7.b4 - Added fix for mozbz#543585 - jemalloc alignment assertion and abort on Linux Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 72 From debarshi.ray at gmail.com Fri Dec 18 14:35:07 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 18 Dec 2009 16:35:07 +0200 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <200912131652.17135.bjorn@xn--rombobjrn-67a.se> References: <1260503641.30425.45.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> <200912131652.17135.bjorn@xn--rombobjrn-67a.se> Message-ID: <3170f42f0912180635k51865196x486cf3e6457d1164@mail.gmail.com> > What happens now? Not much I guess, as the list archive obfuscates email > [...] > that give you a feeling of accomplishment? Just trying to point out the futility of trying to avoid publishing your Fedora ID. It took me less than a minute to find it without asking any human. One might even put up a web page with your Fedora email address all over it. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig From loupgaroublond at gmail.com Fri Dec 18 14:40:44 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 18 Dec 2009 15:40:44 +0100 (CET) Subject: autofs not installed by default In-Reply-To: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> Message-ID: Hi Todd, 2009/12/17 Todd Volkert : > Hi all, > The past few Fedora installs, I've specified a NIS server during the > Anaconda installation so I don't have to create any local user accounts. > ?However, once installation is complete, I can't log into any NIS accounts > because autofs insn't installed, causing the user accounts' home folders to > not be mounted. ?I have to sign in as root, install autofs, then all is > well. > My question is: shouldn't autofs be installed by default, as part of the > base installation? Sounds like you're running Fedora on a bunch of machines. How are you doing the installs? Are you using a simple install DVD for every machine that comes your way? Since your environment is running a setup that's different than 95% of the end user environments, it might be more prudent to use a kickstart file with your installs. This will guarantee that autofs is present on every machine from the beginning. Depending on your environment, there are a number of different ways you can deliver your kickstart to your machines at install time. -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: OpenPGP digital signature URL: From bnocera at redhat.com Fri Dec 18 15:57:31 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 18 Dec 2009 15:57:31 +0000 Subject: Electric Fence - still reliable? In-Reply-To: <20091218125833.2663dfc3@gmail.com> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> <1261135110.12311.3512.camel@localhost.localdomain> <20091218125833.2663dfc3@gmail.com> Message-ID: <1261151851.12311.3793.camel@localhost.localdomain> On Fri, 2009-12-18 at 12:58 +0100, Michael Schwendt wrote: > On Fri, 18 Dec 2009 11:18:30 +0000, Bastien wrote: > > > > $ eog > > > > > > Electric Fence 2.2.2 Copyright (C) 1987-1999 Bruce Perens > > > Segmentation fault (core dumped) > > > > > > ==> in ORBit corba-any.c once more > > > > All the GNOME apps that use GConf or ORBit will fail because you need to > > set the alignment to 8. Same problem under valgrind. > > Okay, different crash then. If I do that, it also ends up with the glib2 > gslice.c crash instead: And you'll need to disable GSlice memory allocation as well, with G_SLICE=always-malloc I'm not sure even trying to use ElectricFence is such a good idea anyway, when we have valgrind available. From jkeating at redhat.com Fri Dec 18 16:16:50 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Dec 2009 08:16:50 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> <20091215155708.76eb7db3@n-dimensional.de> <1260898643.21725.54.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> <1261002396.3328.14.camel@vaio.local.net> Message-ID: <1261153010.19834.22.camel@localhost.localdomain> On Thu, 2009-12-17 at 23:28 -0600, Adam Miller wrote: > +1 to Adam W because I'm an ultra git neophyte (and a CVS one for that > matter) but the current make file automation essentially removes that as an > issue. I'm not saying I'm against learning git if need be, but I agree that > it would be an unfortunate regression. You guys do realize that there is really only 2 things the Make system handles on the CVS side for you? Creating a tag (which we won't need in dist-git), and importing an srpm. Other than that you've been using the real cvs directly. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Fri Dec 18 16:19:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 18 Dec 2009 17:19:10 +0100 Subject: Electric Fence - still reliable? In-Reply-To: <1261151851.12311.3793.camel@localhost.localdomain> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> <1261135110.12311.3512.camel@localhost.localdomain> <20091218125833.2663dfc3@gmail.com> <1261151851.12311.3793.camel@localhost.localdomain> Message-ID: <20091218171910.31314701@gmail.com> On Fri, 18 Dec 2009 15:57:31 +0000, Bastien wrote: > I'm not sure even trying to use ElectricFence is such a good idea > anyway, when we have valgrind available. Yeah, likely. I examined some uninitialised variables with Valgrind yesterday. For a couple of other cases (including Audacious), comparison is the goal here, $ valgrind w 2>&1|wc -l 238 $ valgrind --leak-check=full w 2>&1|wc -l 249 versus $ ef w 2>&1|wc -l 3 with the latter triggering ABRT activity, whereas the former requires increased effort to make sense of undetailed traces such as the following (which is bug 548711): ==13516== Invalid read of size 1 ==13516== at 0x400730E: strcmp (mc_replace_strmem.c:426) ==13516== by 0x8D63A6: _nl_find_locale (findlocale.c:94) ==13516== by 0x8D597B: setlocale (setlocale.c:409) ==13516== by 0xA348D1: loadavg (in /lib/libproc-3.2.8.so) ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) ==13516== by 0x80497E4: ??? (in /usr/bin/w) ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) ==13516== Address 0x4053528 is 0 bytes inside a block of size 12 free'd ==13516== at 0x40057F6: free (vg_replace_malloc.c:325) ==13516== by 0x8D5A1B: setlocale (setlocale.c:203) ==13516== by 0xA3488E: loadavg (in /lib/libproc-3.2.8.so) ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) ==13516== by 0x80497E4: ??? (in /usr/bin/w) ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) ==13516== I'm sure I could install lots of missing -debuginfo packages manually and tweak valgrind options. It just reported way too much here. From nicoleau.fabien at gmail.com Fri Dec 18 17:03:27 2009 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Fri, 18 Dec 2009 18:03:27 +0100 Subject: Question about a lib requires Message-ID: <20091218180327.6f74e29d@gmail.com> Hi, I'm packaging a software that requires : /usr/bin/jpegtran (provided by libjpeg) and /usr/bin/tiffinfo (provided by libtiff). If I explicitely put libjpeg and libtiff in Requires, rpmlint complains because I don't let RPM find the libs. Is there a way to include these requires properly ? (like adding directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). Regards, Fabien NICOLEAU From limb at jcomserv.net Fri Dec 18 17:01:26 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Dec 2009 11:01:26 -0600 Subject: Question about a lib requires In-Reply-To: <20091218180327.6f74e29d@gmail.com> References: <20091218180327.6f74e29d@gmail.com> Message-ID: <4B2BB566.4080404@jcomserv.net> Nicoleau Fabien wrote: > Hi, > I'm packaging a software that requires : > /usr/bin/jpegtran (provided by libjpeg) and /usr/bin/tiffinfo (provided > by libtiff). > > If I explicitely put libjpeg and libtiff in Requires, rpmlint complains > because I don't let RPM find the libs. > > Is there a way to include these requires properly ? (like adding > directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). > > Regards, > > Fabien NICOLEAU > > Yes. Requires: /usr/bin/jpegtran Requires: /usr/bin/tiffinfo Does it really just need the binaries and not the libs, just that rpm would auto-Require the libjpeg and libtiff RPMs? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From nicoleau.fabien at gmail.com Fri Dec 18 17:12:27 2009 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Fri, 18 Dec 2009 18:12:27 +0100 Subject: Create a -cli package without a different executable Message-ID: <20091218181227.2f6da87e@gmail.com> Hi, I'm packaging phatch that provides /usr/bin/phatch, a graphical application to manage some operations on photos. It handles command line parameters so that it can be used in a script, without a GUI : if no parameters are given, a GUI is displayed, otherwise it acts as a console application. Upstream asked me if it's possible to keep "phatch" package, containing the graphical requirements (and requires) and requires phatch-cli, and create a phatch-cli, that provides /usr/bin/phatch. With this way, people could just install phatch-cli on a server and use it with command line parameters (but it would crash if it's not launched with parameters). My question is : is it good to provide a -cli package that does not provides a separate script or executable file, and that will work only if the user is carefull to not launch it in a way that it does not require a graphic lib (without parameters in that context) ? Regards, Fabien NICOLEAU From jussilehtola at fedoraproject.org Fri Dec 18 17:11:14 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 18 Dec 2009 19:11:14 +0200 Subject: Question about a lib requires In-Reply-To: <4B2BB566.4080404@jcomserv.net> References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> Message-ID: <1261156274.22231.6.camel@localhost> On Fri, 2009-12-18 at 11:01 -0600, Jon Ciesla wrote: > Nicoleau Fabien wrote: > > I'm packaging a software that requires : > > /usr/bin/jpegtran (provided by libjpeg) and /usr/bin/tiffinfo (provided > > by libtiff). > > > > If I explicitely put libjpeg and libtiff in Requires, rpmlint complains > > because I don't let RPM find the libs. > > > > Is there a way to include these requires properly ? (like adding > > directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). > Yes. > > Requires: /usr/bin/jpegtran > Requires: /usr/bin/tiffinfo > > Does it really just need the binaries and not the libs, just that rpm > would auto-Require the libjpeg and libtiff RPMs? And if it actually needs the binaries, then you can just put in Requires: libjpeg, libtiff and safely ignore the rpmlint warning. AFAIK resolving file dependencies is a lot slower than resolving explicit dependencies. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jussilehtola at fedoraproject.org Fri Dec 18 17:14:24 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Fri, 18 Dec 2009 19:14:24 +0200 Subject: Create a -cli package without a different executable In-Reply-To: <20091218181227.2f6da87e@gmail.com> References: <20091218181227.2f6da87e@gmail.com> Message-ID: <1261156464.22231.9.camel@localhost> On Fri, 2009-12-18 at 18:12 +0100, Nicoleau Fabien wrote: > My question is : > is it good to provide a -cli package that does not provides a separate > script or executable file, and that will work only if the user is > carefull to not launch it in a way that it does not require a graphic > lib (without parameters in that context) ? The design seems idiotic. Anyway, you have to weigh the surplus of admins not having to install graphical stuff on their servers versus the possible problems caused by new users trying to work the package in a way it isn't supposed to be used. I'd say: it's up to the packager. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From limb at jcomserv.net Fri Dec 18 17:16:03 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Dec 2009 11:16:03 -0600 Subject: Create a -cli package without a different executable In-Reply-To: <1261156464.22231.9.camel@localhost> References: <20091218181227.2f6da87e@gmail.com> <1261156464.22231.9.camel@localhost> Message-ID: <4B2BB8D3.50809@jcomserv.net> Jussi Lehtola wrote: > On Fri, 2009-12-18 at 18:12 +0100, Nicoleau Fabien wrote: > >> My question is : >> is it good to provide a -cli package that does not provides a separate >> script or executable file, and that will work only if the user is >> carefull to not launch it in a way that it does not require a graphic >> lib (without parameters in that context) ? >> > > The design seems idiotic. > > Anyway, you have to weigh the surplus of admins not having to install > graphical stuff on their servers versus the possible problems caused by > new users trying to work the package in a way it isn't supposed to be > used. > > I'd say: it's up to the packager. > > Or, package it , er, twice, with two copies with different options. See: Ettercap Warning: This is the most annoying choice, and I sometimes regret it. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From opensource at till.name Fri Dec 18 17:18:12 2009 From: opensource at till.name (Till Maas) Date: Fri, 18 Dec 2009 18:18:12 +0100 Subject: Help wanted with dist-cvs to git conversion In-Reply-To: <3170f42f0912180635k51865196x486cf3e6457d1164@mail.gmail.com> References: <1260503641.30425.45.camel@localhost.localdomain> <200912122030.26756.bjorn@xn--rombobjrn-67a.se> <3170f42f0912121404y527c9abare2d36d14e03b7127@mail.gmail.com> <200912131652.17135.bjorn@xn--rombobjrn-67a.se> <3170f42f0912180635k51865196x486cf3e6457d1164@mail.gmail.com> Message-ID: <20091218171812.GA1565@genius.kawo2.rwth-aachen.de> On Fri, Dec 18, 2009 at 04:35:07PM +0200, Debarshi Ray wrote: > > What happens now? Not much I guess, as the list archive obfuscates email > > [...] > > that give you a feeling of accomplishment? > > Just trying to point out the futility of trying to avoid publishing > your Fedora ID. It took me less than a minute to find it without > asking any human. One might even put up a web page with your Fedora > email address all over it. He did not wrote about his Fedora ID, but about publishing the e-mail address not obfuscated. Also he clearly stated that he wishes that nobody publishes it obfuscated. If you just want to point out, that you can research the address, you still do not need to post it. For me it was only rude behaviour. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From stickster at gmail.com Fri Dec 18 17:19:47 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 18 Dec 2009 12:19:47 -0500 Subject: FESCo election results December 2009 Message-ID: <20091218171947.GF20625@victoria.internal.frields.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Election Results for FESCo - Fedora 13 Cycle Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC Nominations: * Adam Jackson (ajax) * Christoph Wickert (cwickert) * Justin M. Forbes (jforbes) * Matthew Garrett (mjg59) * Peter Jones (pjones) * Richard June (rjune) * Robert Scheck (rsc) Outcomes: As defined in the election text, the four (4) candidate(s) with the greatest number of votes will be elected for full 2 release term. Information: At close of voting there were: 216 valid ballots Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 2. Christoph Wickert (cwickert) 934 3. Peter Jones (pjones) 820 4. Matthew Garrett (mjg59) 753 * * * * * 5. Robert Scheck (rsc) 663 6. Justin M. Forbes (jforbes) 535 7. Richard June (rjune) 415 As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew Garrett are elected to FESCo for a full 2 release term. - -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLK7mzrNvJN70RNxcRAvCNAKDvrCQTbqX5AnUwZ7yOIstqY9Kw6gCgwx4Y iChaOSEv0FdG1kOXPgWcGXI= =2kq6 -----END PGP SIGNATURE----- From jreiser at bitwagon.com Fri Dec 18 17:47:02 2009 From: jreiser at bitwagon.com (John Reiser) Date: Fri, 18 Dec 2009 09:47:02 -0800 Subject: Electric Fence - still reliable? In-Reply-To: <20091218171910.31314701@gmail.com> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> <1261135110.12311.3512.camel@localhost.localdomain> <20091218125833.2663dfc3@gmail.com> <1261151851.12311.3793.camel@localhost.localdomain> <20091218171910.31314701@gmail.com> Message-ID: <4B2BC016.90808@bitwagon.com> On 12/18/2009 08:19 AM, Michael Schwendt wrote: > On Fri, 18 Dec 2009 15:57:31 +0000, Bastien wrote: > >> I'm not sure even trying to use ElectricFence is such a good idea >> anyway, when we have valgrind available. > > Yeah, likely. Both can be useful. The speed overhead of ElectricFence is a couple percent, whereas valgrind(memcheck) slows execution by a *factor* of 10 to 20. > > [ElectricFence] triggering ABRT activity, whereas [Valgrind] requires > increased effort to make sense of undetailed traces such as the following > (which is bug 548711): > > ==13516== Invalid read of size 1 > ==13516== at 0x400730E: strcmp (mc_replace_strmem.c:426) > ==13516== by 0x8D63A6: _nl_find_locale (findlocale.c:94) > ==13516== by 0x8D597B: setlocale (setlocale.c:409) > ==13516== by 0xA348D1: loadavg (in /lib/libproc-3.2.8.so) > ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) > ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) > ==13516== by 0x80497E4: ??? (in /usr/bin/w) > ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) > ==13516== Address 0x4053528 is 0 bytes inside a block of size 12 free'd > ==13516== at 0x40057F6: free (vg_replace_malloc.c:325) > ==13516== by 0x8D5A1B: setlocale (setlocale.c:203) > ==13516== by 0xA3488E: loadavg (in /lib/libproc-3.2.8.so) > ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) > ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) > ==13516== by 0x80497E4: ??? (in /usr/bin/w) > ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) > ==13516== > > I'm sure I could install lots of missing -debuginfo packages manually > and tweak valgrind options. It just reported way too much here. This complaint is way off base. It complains "undetailed" and "reported way too much" for the same case, which is contradictory. The report gives traceback both for the immediate error and for the cause which happened long ago. Some file and line numbers have been omitted, but those are not needed to pinpoint the error: setlocale() called free() but afterwards setlocale() still used the block which was freed. The bug is in setlocale or in the parameters passed to it by loadavg(). If the problem is in loadavg(), then the tracebacks provide clues to the environment in which loadavg() erred. This report from memcheck is close to ideal. -- From mjg at redhat.com Fri Dec 18 17:58:26 2009 From: mjg at redhat.com (Matthew Garrett) Date: Fri, 18 Dec 2009 17:58:26 +0000 Subject: FESCo election results December 2009 In-Reply-To: <20091218171947.GF20625@victoria.internal.frields.org> References: <20091218171947.GF20625@victoria.internal.frields.org> Message-ID: <20091218175826.GB29522@srcf.ucam.org> On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: > Using the Fedora Range Voting method, each candidate could attain a > maximum of 864 votes (4*216). > > Results: > > 1. Adam Jackson (ajax) 1028 I think there's a discrepency here :) -- Matthew Garrett | mjg59 at srcf.ucam.org From limb at jcomserv.net Fri Dec 18 18:01:10 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Dec 2009 12:01:10 -0600 Subject: FESCo election results December 2009 In-Reply-To: <20091218175826.GB29522@srcf.ucam.org> References: <20091218171947.GF20625@victoria.internal.frields.org> <20091218175826.GB29522@srcf.ucam.org> Message-ID: <4B2BC366.60507@jcomserv.net> Matthew Garrett wrote: > On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: > > >> Using the Fedora Range Voting method, each candidate could attain a >> maximum of 864 votes (4*216). >> >> Results: >> >> 1. Adam Jackson (ajax) 1028 >> > > I think there's a discrepency here :) > > This one too: 2. Christoph Wickert (cwickert) 934 :) I thought RedHat was in NC, not FL. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From awilliam at redhat.com Fri Dec 18 18:04:27 2009 From: awilliam at redhat.com (Adam Williamson) Date: Fri, 18 Dec 2009 18:04:27 +0000 Subject: Question about a lib requires In-Reply-To: <1261156274.22231.6.camel@localhost> References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> <1261156274.22231.6.camel@localhost> Message-ID: <1261159467.2437.66.camel@vaio.local.net> On Fri, 2009-12-18 at 19:11 +0200, Jussi Lehtola wrote: > > > Is there a way to include these requires properly ? (like adding > > > directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). > > Yes. > > > > Requires: /usr/bin/jpegtran > > Requires: /usr/bin/tiffinfo > > > > Does it really just need the binaries and not the libs, just that rpm > > would auto-Require the libjpeg and libtiff RPMs? > > And if it actually needs the binaries, then you can just put in > Requires: libjpeg, libtiff > and safely ignore the rpmlint warning. AFAIK resolving file dependencies > is a lot slower than resolving explicit dependencies. +1: just requiring the library packages and ignoring the rpmlint warning seems correct here, to me. You are smarter than rpmlint, after all. rpmlint is just considering the case where you're adding a library dependency, not realizing it will be automatically generated. It is not considering the case where the library package includes a binary that you need to depend on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From ajax at redhat.com Fri Dec 18 18:06:12 2009 From: ajax at redhat.com (Adam Jackson) Date: Fri, 18 Dec 2009 13:06:12 -0500 Subject: FESCo election results December 2009 In-Reply-To: <20091218171947.GF20625@victoria.internal.frields.org> References: <20091218171947.GF20625@victoria.internal.frields.org> Message-ID: <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: > Information: > > At close of voting there were: > 216 valid ballots > > Using the Fedora Range Voting method, each candidate could attain a > maximum of 864 votes (4*216). > > Results: > > 1. Adam Jackson (ajax) 1028 That's right, I'm so awesome I got more than the maximum number of votes. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Fri Dec 18 18:07:48 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Dec 2009 12:07:48 -0600 Subject: FESCo election results December 2009 In-Reply-To: <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> References: <20091218171947.GF20625@victoria.internal.frields.org> <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> Message-ID: <4B2BC4F4.9050809@jcomserv.net> Adam Jackson wrote: > On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: > > >> Information: >> >> At close of voting there were: >> 216 valid ballots >> >> Using the Fedora Range Voting method, each candidate could attain a >> maximum of 864 votes (4*216). >> >> Results: >> >> 1. Adam Jackson (ajax) 1028 >> > > That's right, I'm so awesome I got more than the maximum number of > votes. > > - ajax > Or, now that I reread, max_votes == number_of_candidates * valid_ballots, or 7*216=1512. QED I think. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From notting at redhat.com Fri Dec 18 18:07:54 2009 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Dec 2009 13:07:54 -0500 Subject: FESCo election results December 2009 In-Reply-To: <20091218175826.GB29522@srcf.ucam.org> References: <20091218171947.GF20625@victoria.internal.frields.org> <20091218175826.GB29522@srcf.ucam.org> Message-ID: <20091218180754.GB20147@nostromo.devel.redhat.com> Matthew Garrett (mjg at redhat.com) said: > On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: > > > Using the Fedora Range Voting method, each candidate could attain a > > maximum of 864 votes (4*216). > > > > Results: > > > > 1. Adam Jackson (ajax) 1028 > > I think there's a discrepency here :) With seven candidates, the actual maximum number is 1512 (7*216). Bill From bmr at redhat.com Fri Dec 18 18:09:42 2009 From: bmr at redhat.com (Bryn M. Reeves) Date: Fri, 18 Dec 2009 18:09:42 +0000 Subject: FESCo election results December 2009 In-Reply-To: <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> References: <20091218171947.GF20625@victoria.internal.frields.org> <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> Message-ID: <1261159782.11367.1830.camel@localhost> Fri, 2009-12-18 at 13:06 -0500, Adam Jackson wrote: > On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: > > > Information: > > > > At close of voting there were: > > 216 valid ballots > > > > Using the Fedora Range Voting method, each candidate could attain a > > maximum of 864 votes (4*216). > > > > Results: > > > > 1. Adam Jackson (ajax) 1028 > > That's right, I'm so awesome I got more than the maximum number of > votes. > Was this tabulated in Florida? Bryn. From tvolkert at gmail.com Fri Dec 18 18:20:48 2009 From: tvolkert at gmail.com (Todd Volkert) Date: Fri, 18 Dec 2009 13:20:48 -0500 Subject: autofs not installed by default In-Reply-To: References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> Message-ID: <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> Hi Yaakov, Thanks for the response. I'm actually only installing it on one local machine, but I upgrade every Fedora release and have noticed this behavior the past few releases. I work at VMware, where every developer can install whatever OS they want to work in, and in Linux, you use ypbind to get access to your network login and shared folders. Thus, I'm using a simple install DVD. I'll look into a kickstart file, though for one machine, it sounds like it might not be worth it. It just makes me wonder if perhaps the ypbind package should depend on the autofs package... -T On Fri, Dec 18, 2009 at 9:40 AM, Yaakov Nemoy wrote: > Hi Todd, > > 2009/12/17 Todd Volkert : > > Hi all, >> The past few Fedora installs, I've specified a NIS server during the >> Anaconda installation so I don't have to create any local user accounts. >> However, once installation is complete, I can't log into any NIS accounts >> because autofs insn't installed, causing the user accounts' home folders >> to >> not be mounted. I have to sign in as root, install autofs, then all is >> well. >> My question is: shouldn't autofs be installed by default, as part of the >> base installation? >> > > Sounds like you're running Fedora on a bunch of machines. How are you doing > the installs? Are you using a simple install DVD for every machine that > comes your way? > > Since your environment is running a setup that's different than 95% of the > end user environments, it might be more prudent to use a kickstart file with > your installs. This will guarantee that autofs is present on every machine > from the beginning. Depending on your environment, there are a number of > different ways you can deliver your kickstart to your machines at install > time. > > -Yaakov > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewan at macmahon.me.uk Fri Dec 18 18:31:20 2009 From: ewan at macmahon.me.uk (Ewan Mac Mahon) Date: Fri, 18 Dec 2009 18:31:20 +0000 Subject: autofs not installed by default In-Reply-To: <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> Message-ID: <20091218183119.GG4126@macmahon.me.uk> On Fri, Dec 18, 2009 at 01:20:48PM -0500, Todd Volkert wrote: > > It just makes me wonder if perhaps the ypbind package should depend on the > autofs package... > Clearly it shouldn't because it does not, in fact, depend on autofs. It's quite possible to use nis on machines that don't use or need autofs. Ewan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tvolkert at gmail.com Fri Dec 18 18:38:58 2009 From: tvolkert at gmail.com (Todd Volkert) Date: Fri, 18 Dec 2009 13:38:58 -0500 Subject: autofs not installed by default In-Reply-To: <20091218183119.GG4126@macmahon.me.uk> References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> <20091218183119.GG4126@macmahon.me.uk> Message-ID: <168ef9ac0912181038t8f578dbg3b91412ef03a073d@mail.gmail.com> > > Clearly it shouldn't because it does not, in fact, depend on autofs. > It's quite possible to use nis on machines that don't use or need > autofs. > Fair enough -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Fri Dec 18 18:47:50 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 18 Dec 2009 19:47:50 +0100 Subject: Electric Fence - still reliable? In-Reply-To: <4B2BC016.90808@bitwagon.com> References: <20091217220704.523d5c06@gmail.com> <20091218115530.27c882b7@gmail.com> <1261135110.12311.3512.camel@localhost.localdomain> <20091218125833.2663dfc3@gmail.com> <1261151851.12311.3793.camel@localhost.localdomain> <20091218171910.31314701@gmail.com> <4B2BC016.90808@bitwagon.com> Message-ID: <20091218194750.11d81bbb@gmail.com> On Fri, 18 Dec 2009 09:47:02 -0800, John wrote: > > [ElectricFence] triggering ABRT activity, whereas [Valgrind] requires > > increased effort to make sense of undetailed traces such as the following > > (which is bug 548711): > > > > ==13516== Invalid read of size 1 > > ==13516== at 0x400730E: strcmp (mc_replace_strmem.c:426) > > ==13516== by 0x8D63A6: _nl_find_locale (findlocale.c:94) > > ==13516== by 0x8D597B: setlocale (setlocale.c:409) > > ==13516== by 0xA348D1: loadavg (in /lib/libproc-3.2.8.so) > > ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) > > ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) > > ==13516== by 0x80497E4: ??? (in /usr/bin/w) > > ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) > > ==13516== Address 0x4053528 is 0 bytes inside a block of size 12 free'd > > ==13516== at 0x40057F6: free (vg_replace_malloc.c:325) > > ==13516== by 0x8D5A1B: setlocale (setlocale.c:203) > > ==13516== by 0xA3488E: loadavg (in /lib/libproc-3.2.8.so) > > ==13516== by 0xA35C4B: sprint_uptime (in /lib/libproc-3.2.8.so) > > ==13516== by 0xA35CF7: print_uptime (in /lib/libproc-3.2.8.so) > > ==13516== by 0x80497E4: ??? (in /usr/bin/w) > > ==13516== by 0x8CBBB5: (below main) (libc-start.c:226) > > ==13516== > > > > I'm sure I could install lots of missing -debuginfo packages manually > > and tweak valgrind options. It just reported way too much here. > > This complaint is way off base. It complains "undetailed" and "reported > way too much" for the same case, which is contradictory. I need to correct myself then. With "It just reported way too much here" I wanted to refer to its output in general, not only to the output quoted above. For example, with some programs I examined with valgrind with default options, I saw multiple hundreds of such sections, referring to several libraries. Compared with that I liked it that efence stopped at the first error and ABRT collected the crash details. From maxamillion at fedoraproject.org Fri Dec 18 20:02:35 2009 From: maxamillion at fedoraproject.org (Adam Miller) Date: Fri, 18 Dec 2009 14:02:35 -0600 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1261153010.19834.22.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> <1261002396.3328.14.camel@vaio.local.net> <1261153010.19834.22.camel@localhost.localdomain> Message-ID: On Fri, Dec 18, 2009 at 10:16 AM, Jesse Keating wrote: > You guys do realize that there is really only 2 things the Make system > handles on the CVS side for you? ?Creating a tag (which we won't need in > dist-git), and importing an srpm. ?Other than that you've been using the > real cvs directly. > True, but the only two commands I need to know are 'cvs up' and 'cvs commit'. It just seems as though from the conversation in this thread there will be a bit more knowledge needed with the git branching and what not (or could potentially be needed). Again, I'm not against this ... I've been looking for an excuse to force myself to learn git a bit better, but I do think this is something that might want to be taken into consideration. I'm a big fan of mercurial and I've been told that it would be an easy transition to git, so I'm really not trying give push back on this. Just wanted to point out that I agree with AdamW that there is potential for a regression. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jkeating at redhat.com Fri Dec 18 20:18:44 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Dec 2009 12:18:44 -0800 Subject: dist-git proof of concept phase 1 complete In-Reply-To: References: <1260847279.21725.3.camel@localhost.localdomain> <20091215181652.GU5004@inocybe.localdomain> <1260901355.21725.67.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> <1261002396.3328.14.camel@vaio.local.net> <1261153010.19834.22.camel@localhost.localdomain> Message-ID: <1261167524.19834.35.camel@localhost.localdomain> On Fri, 2009-12-18 at 14:02 -0600, Adam Miller wrote: > True, but the only two commands I need to know are 'cvs up' and 'cvs > commit'. It just seems as though from the conversation in this thread > there will be a bit more knowledge needed with the git branching and > what not (or could potentially be needed). Again, I'm not against this > ... I've been looking for an excuse to force myself to learn git a bit > better, but I do think this is something that might want to be taken > into consideration. It has been in the plans all along to hide most/all of git behind fedpkg calls, even more than cvs was hidden. I just wanted to make the point that very very little of CVS was hidden. The only added potentially sticky point is how to get from the rawhide view of content to say the F-12 view. But as I said, that'll be hidden behind fedpkg for those that don't want to use git directly. > > I'm a big fan of mercurial and I've been told that it would be an easy > transition to git, so I'm really not trying give push back on this. > Just wanted to point out that I agree with AdamW that there is > potential for a regression. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Fri Dec 18 20:26:45 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 18 Dec 2009 20:26:45 +0000 Subject: Add extra generated RPM requires - how? Message-ID: <20091218202645.GA30070@amd.home.annexia.org> For libguestfs [RHBZ#547496] I want to add some extra 'Requires' dependencies by running a shell script over a particular file that gets generated during the build. What's the best way, or a way, to do this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From ajax at redhat.com Fri Dec 18 20:54:53 2009 From: ajax at redhat.com (Adam Jackson) Date: Fri, 18 Dec 2009 15:54:53 -0500 Subject: Add extra generated RPM requires - how? In-Reply-To: <20091218202645.GA30070@amd.home.annexia.org> References: <20091218202645.GA30070@amd.home.annexia.org> Message-ID: <1261169693.7251.32086.camel@atropine.boston.devel.redhat.com> On Fri, 2009-12-18 at 20:26 +0000, Richard W.M. Jones wrote: > For libguestfs [RHBZ#547496] I want to add some extra 'Requires' > dependencies by running a shell script over a particular file that > gets generated during the build. > > What's the best way, or a way, to do this? It's... not easy. You want to overload the %__find_provides macro to invoke your script as well as the standard script for things like library sonames. If you get it working let me know, I want basically the same thing for the X server and have so far been defeated. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri Dec 18 21:06:07 2009 From: opensource at till.name (Till Maas) Date: Fri, 18 Dec 2009 22:06:07 +0100 Subject: Add extra generated RPM requires - how? In-Reply-To: <1261169693.7251.32086.camel@atropine.boston.devel.redhat.com> References: <20091218202645.GA30070@amd.home.annexia.org> <1261169693.7251.32086.camel@atropine.boston.devel.redhat.com> Message-ID: <20091218210607.GA20223@genius.kawo2.rwth-aachen.de> On Fri, Dec 18, 2009 at 03:54:53PM -0500, Adam Jackson wrote: > On Fri, 2009-12-18 at 20:26 +0000, Richard W.M. Jones wrote: > > For libguestfs [RHBZ#547496] I want to add some extra 'Requires' > > dependencies by running a shell script over a particular file that > > gets generated during the build. > > > > What's the best way, or a way, to do this? > > It's... not easy. You want to overload the %__find_provides macro to > invoke your script as well as the standard script for things like > library sonames. If you get it working let me know, I want basically > the same thing for the X server and have so far been defeated. I once created this for ghc/haskell packages, but I believe it was never used. I got inspired by a pythondeps.sh script. The "trick" here is to run the rpm default dependency script from within the new script. My attempt is available here: http://till.fedorapeople.org/ghcdeps.sh Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From tgl at redhat.com Fri Dec 18 21:17:01 2009 From: tgl at redhat.com (Tom Lane) Date: Fri, 18 Dec 2009 16:17:01 -0500 Subject: autofs not installed by default In-Reply-To: References: Message-ID: <11692.1261171021@sss.pgh.pa.us> Yaakov Nemoy writes: > Since your environment is running a setup that's different than 95% of > the end user environments, it might be more prudent to use a kickstart > file with your installs. This will guarantee that autofs is present on > every machine from the beginning. Depending on your environment, there > are a number of different ways you can deliver your kickstart to your > machines at install time. I've never actually used kickstart. I wonder if anyone would offer an opinion on how easy it is to learn/use? The only real use that I would have for it is that I have a couple of machines that I install each new Fedora release on. Currently I have a manual checklist I go through ("make sure autofs is installed" is one of the items). I find that the checklist tends to change a bit with each Fedora release, so I'm wondering just how useful it would be to try to automate it. Comments? regards, tom lane From stickster at gmail.com Fri Dec 18 20:01:01 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 18 Dec 2009 15:01:01 -0500 Subject: FESCo election results December 2009 In-Reply-To: <1261159782.11367.1830.camel@localhost> References: <20091218171947.GF20625@victoria.internal.frields.org> <1261159572.7251.32084.camel@atropine.boston.devel.redhat.com> <1261159782.11367.1830.camel@localhost> Message-ID: <20091218200101.GJ20625@victoria.internal.frields.org> On Fri, Dec 18, 2009 at 06:09:42PM +0000, Bryn M. Reeves wrote: > Fri, 2009-12-18 at 13:06 -0500, Adam Jackson wrote: > > On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: > > > > > Information: > > > > > > At close of voting there were: > > > 216 valid ballots > > > > > > Using the Fedora Range Voting method, each candidate could attain a > > > maximum of 864 votes (4*216). > > > > > > Results: > > > > > > 1. Adam Jackson (ajax) 1028 > > > > That's right, I'm so awesome I got more than the maximum number of > > votes. > > Was this tabulated in Florida? Didn't "Vote early, vote often" originate in Chicago? Wait a second, our Infrastructure team lead's in Chicago.... ;-) Just a simple human error of using "4" instead of "7". I've sent a GPG-signed correction as followup. Thanks to all who caught the error -- I've entered an RFE for the voting system: https://fedorahosted.org/elections/ticket/32 -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From stickster at gmail.com Fri Dec 18 19:57:32 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 18 Dec 2009 14:57:32 -0500 Subject: FESCo election results December 2009 In-Reply-To: <20091218171947.GF20625@victoria.internal.frields.org> References: <20091218171947.GF20625@victoria.internal.frields.org> Message-ID: <20091218195732.GI20625@victoria.internal.frields.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: > Election Results for FESCo - Fedora 13 Cycle > > Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC > > Nominations: > > * Adam Jackson (ajax) > * Christoph Wickert (cwickert) > * Justin M. Forbes (jforbes) > * Matthew Garrett (mjg59) > * Peter Jones (pjones) > * Richard June (rjune) > * Robert Scheck (rsc) > > Outcomes: > > As defined in the election text, the four (4) candidate(s) with the > greatest number of votes will be elected for full 2 release term. > > Information: > > At close of voting there were: > 216 valid ballots > > Using the Fedora Range Voting method, each candidate could attain a > maximum of 864 votes (4*216). > > Results: > > 1. Adam Jackson (ajax) 1028 > 2. Christoph Wickert (cwickert) 934 > 3. Peter Jones (pjones) 820 > 4. Matthew Garrett (mjg59) 753 > * * * * * > 5. Robert Scheck (rsc) 663 > 6. Justin M. Forbes (jforbes) 535 > 7. Richard June (rjune) 415 > > As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew > Garrett are elected to FESCo for a full 2 release term. As Bill Nottingham and others correctly pointed out, the maximum vote numbers above were incorrect. The number should be 7*216, or 1512. - -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLK96srNvJN70RNxcRAiZ4AKDRs3eVUpyJSNHx5e5byjDFkM3aXwCfeiGA SYGmwpZvMnya5hDu2IOnXpc= =Jofb -----END PGP SIGNATURE----- From sgrubb at redhat.com Fri Dec 18 21:25:49 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 18 Dec 2009 16:25:49 -0500 Subject: Add extra generated RPM requires - how? In-Reply-To: <1261169693.7251.32086.camel@atropine.boston.devel.redhat.com> References: <20091218202645.GA30070@amd.home.annexia.org> <1261169693.7251.32086.camel@atropine.boston.devel.redhat.com> Message-ID: <200912181625.49289.sgrubb@redhat.com> On Friday 18 December 2009 03:54:53 pm Adam Jackson wrote: > On Fri, 2009-12-18 at 20:26 +0000, Richard W.M. Jones wrote: > > For libguestfs [RHBZ#547496] I want to add some extra 'Requires' > > dependencies by running a shell script over a particular file that > > gets generated during the build. > > > > What's the best way, or a way, to do this? > > It's... not easy. You want to overload the %__find_provides macro to > invoke your script as well as the standard script for things like > library sonames. I used something like this: #%_use_internal_dependency_generator 0 #%__find_requires /home/sgrubb/bin/find-requires and then ran a shell script that had this piece in it where $1 was a file suspected of being a bash script by running the file command. Since people have a habit of using a script name and not its full path, it uses which to resolve the full path. This might be better done using the full rpm database that yum operates off of. Anyways...this was the core of it: # Then check its requirements cmds=`/bin/bash --rpm-requires "$1" | sort | uniq | tr '()' ' ' | awk '{ print $2 }'` for c in $cmds do tgt=`which $c 2>/dev/null` if [ x"$tgt" = x ] ; then echo "$c cannot be resolved" 1>&2 continue fi tmp_r="`rpm -qf $tgt`" if [ $? -eq 0 -a $RPM -eq 1 ] ; then # Only use good results for rpms r="$r\n$tmp_r" else r="$r\n$tgt" fi done echo -e $r | sort | uniq exit 0 -Steve From julian.fedoralists at googlemail.com Fri Dec 18 21:39:18 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Fri, 18 Dec 2009 22:39:18 +0100 Subject: Create a -cli package without a different executable In-Reply-To: <20091218181227.2f6da87e@gmail.com> References: <20091218181227.2f6da87e@gmail.com> Message-ID: <1261172358.7053.12.camel@localhost.localdomain> Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien: > Hi, > > I'm packaging phatch that provides /usr/bin/phatch, a graphical > application to manage some operations on photos. It handles command > line parameters so that it can be used in a script, without a GUI : > if no parameters are given, a GUI is displayed, otherwise it acts as a > console application. > > Upstream asked me if it's possible to keep "phatch" package, containing > the graphical requirements (and requires) and requires phatch-cli, and > create a phatch-cli, that provides /usr/bin/phatch. With this way, > people could just install phatch-cli on a server and use it with > command line parameters (but it would crash if it's not launched with > parameters). > > My question is : > is it good to provide a -cli package that does not provides a separate > script or executable file, and that will work only if the user is > carefull to not launch it in a way that it does not require a graphic > lib (without parameters in that context) ? > > > Regards, > > Fabien NICOLEAU > I see phatch is a python package, so I think a little trick could be possible: %package cli: BuildRequires: python-devel Requires: non-gui-dependencies %files {_bindir}/phatch and for the main package: Requires: phatch-cli Requires: pygtk2, [install desktop file etc...] This way users could explicitly install phatch-cli, and it would "only" not start up properly if called without arguments on a terminal, and the main package (gui version) would contain the program and pull in the graphical dependencies. I don't know the program though, and if the cli version depends on gui libraries to work properly as well it wouldn't work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From maxamillion at gmail.com Fri Dec 18 22:11:58 2009 From: maxamillion at gmail.com (Adam Miller) Date: Fri, 18 Dec 2009 16:11:58 -0600 Subject: dist-git proof of concept phase 1 complete In-Reply-To: <1261167524.19834.35.camel@localhost.localdomain> References: <1260847279.21725.3.camel@localhost.localdomain> <20091215203516.GF3259@clingman.lan> <1260941600.6151.471.camel@tonnant> <20091216152857.GG3259@clingman.lan> <1260978148.2528.20.camel@willson.li.ssimo.org> <1261002396.3328.14.camel@vaio.local.net> <1261153010.19834.22.camel@localhost.localdomain> <1261167524.19834.35.camel@localhost.localdomain> Message-ID: On Fri, Dec 18, 2009 at 2:18 PM, Jesse Keating wrote: > It has been in the plans all along to hide most/all of git behind fedpkg > calls, even more than cvs was hidden. ?I just wanted to make the point > that very very little of CVS was hidden. ?The only added potentially > sticky point is how to get from the rawhide view of content to say the > F-12 view. ?But as I said, that'll be hidden behind fedpkg for those > that don't want to use git directly. > Ohhhh ok, I completely misunderstood. In that case, +1 :) -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From poelstra at redhat.com Fri Dec 18 22:17:44 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 18 Dec 2009 14:17:44 -0800 Subject: Release Milestones for the Masses Message-ID: <4B2BFF88.7050407@redhat.com> One of the complaints heard during the last release cycle was that some maintainers where unclear what all the schedule milestones meant. Before we reach any of these milestones for Fedora 13 I wanted to send this out for feedback. What I have created represents our current process as I understand it. Hopefully people on the list will have enough courage to speak up if they disagree ;-) https://fedoraproject.org/wiki/User:Poelstra/Key_Milestones Are there any other milestones missing that we need to describe? Once we get closer to these milestones advanced reminders will be sent to fedora-devel-announce for them. Thanks, John From nicoleau.fabien at gmail.com Fri Dec 18 23:41:32 2009 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Sat, 19 Dec 2009 00:41:32 +0100 Subject: Create a -cli package without a different executable In-Reply-To: <1261172358.7053.12.camel@localhost.localdomain> References: <20091218181227.2f6da87e@gmail.com> <1261172358.7053.12.camel@localhost.localdomain> Message-ID: <20091219004132.11b17485@gmail.com> Le Fri, 18 Dec 2009 22:39:18 +0100, Julian Aloofi a ?crit : > Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien: > > Hi, > > > > I'm packaging phatch that provides /usr/bin/phatch, a graphical > > application to manage some operations on photos. It handles command > > line parameters so that it can be used in a script, without a GUI : > > if no parameters are given, a GUI is displayed, otherwise it acts > > as a console application. > > > > Upstream asked me if it's possible to keep "phatch" package, > > containing the graphical requirements (and requires) and requires > > phatch-cli, and create a phatch-cli, that provides /usr/bin/phatch. > > With this way, people could just install phatch-cli on a server and > > use it with command line parameters (but it would crash if it's not > > launched with parameters). > > > > My question is : > > is it good to provide a -cli package that does not provides a > > separate script or executable file, and that will work only if the > > user is carefull to not launch it in a way that it does not require > > a graphic lib (without parameters in that context) ? > > > > > > Regards, > > > > Fabien NICOLEAU > > > I see phatch is a python package, so I think a little trick could be > possible: > > %package cli: > BuildRequires: python-devel > Requires: non-gui-dependencies > %files > {_bindir}/phatch > > and for the main package: > Requires: phatch-cli > Requires: pygtk2, > [install desktop file etc...] > > > This way users could explicitly install phatch-cli, and it would > "only" not start up properly if called without arguments on a > terminal, and the main package (gui version) would contain the > program and pull in the graphical dependencies. > I don't know the program though, and if the cli version depends on gui > libraries to work properly as well it wouldn't work. Yes, I'll probably use this way :) thx From nicoleau.fabien at gmail.com Fri Dec 18 23:42:48 2009 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Sat, 19 Dec 2009 00:42:48 +0100 Subject: Question about a lib requires In-Reply-To: <1261159467.2437.66.camel@vaio.local.net> References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> <1261156274.22231.6.camel@localhost> <1261159467.2437.66.camel@vaio.local.net> Message-ID: <20091219004248.33d56659@gmail.com> Le Fri, 18 Dec 2009 18:04:27 +0000, Adam Williamson a ?crit : > On Fri, 2009-12-18 at 19:11 +0200, Jussi Lehtola wrote: > > > > > Is there a way to include these requires properly ? (like adding > > > > directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). > > > Yes. > > > > > > Requires: /usr/bin/jpegtran > > > Requires: /usr/bin/tiffinfo > > > > > > Does it really just need the binaries and not the libs, just that > > > rpm would auto-Require the libjpeg and libtiff RPMs? > > > > And if it actually needs the binaries, then you can just put in > > Requires: libjpeg, libtiff > > and safely ignore the rpmlint warning. AFAIK resolving file > > dependencies is a lot slower than resolving explicit dependencies. > > +1: just requiring the library packages and ignoring the rpmlint > warning seems correct here, to me. You are smarter than rpmlint, > after all. rpmlint is just considering the case where you're adding a > library dependency, not realizing it will be automatically generated. > It is not considering the case where the library package includes a > binary that you need to depend on. I think I'll use : Requires: /usr/bin/jpegtran Requires: /usr/bin/tiffinfo so if one day these files are put in a different package than the lib, I won't be "surprised" Fabien Nicoleau From jkeating at redhat.com Fri Dec 18 23:31:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Dec 2009 15:31:49 -0800 Subject: dist-git proof of concept phase 2 ready for testing Message-ID: <1261179109.19834.48.camel@localhost.localdomain> Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. Thanks again for your help in this project! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jaredsmith at jaredsmith.net Fri Dec 18 23:59:41 2009 From: jaredsmith at jaredsmith.net (Jared Smith) Date: Fri, 18 Dec 2009 17:59:41 -0600 Subject: autofs not installed by default In-Reply-To: <11692.1261171021@sss.pgh.pa.us> References: <11692.1261171021@sss.pgh.pa.us> Message-ID: <1261180781.7018.13.camel@hockey.jaredsmith.net> On Fri, 2009-12-18 at 16:17 -0500, Tom Lane wrote: > I've never actually used kickstart. I wonder if anyone would offer an > opinion on how easy it is to learn/use? It's very easy to learn and use. In fact, go to your /root directory and look for a file called anaconda-ks.cfg. It's a kickstart file already created for you, based on the installation via anaconda. Use that a base, and go adding your package requirements, post-install scripts, etc. -Jared Smith From hun at n-dimensional.de Sat Dec 19 00:37:31 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sat, 19 Dec 2009 01:37:31 +0100 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261179109.19834.48.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> Message-ID: <20091219013731.236dd5ef@n-dimensional.de> On Fri, 18 Dec 2009 15:31:49 -0800 Jesse Keating wrote: > Phase two, write access with ACLs, is ready for testing. Please not > that URLs have changed since my original announcement. > > git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ git clone ssh://[fedoraaccount@]pkgs.stg.fedoraproject.org/ as far as I can tell. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Dec 19 00:44:19 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 18 Dec 2009 16:44:19 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091219013731.236dd5ef@n-dimensional.de> References: <1261179109.19834.48.camel@localhost.localdomain> <20091219013731.236dd5ef@n-dimensional.de> Message-ID: <87AB3E57-80C9-4150-A2A9-565D1F574C91@j2solutions.net> On Dec 18, 2009, at 16:37, Hans Ulrich Niedermann wrote: > On Fri, 18 Dec 2009 15:31:49 -0800 > Jesse Keating wrote: > >> Phase two, write access with ACLs, is ready for testing. Please not >> that URLs have changed since my original announcement. >> >> git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ > > git clone ssh://[fedoraaccount@]pkgs.stg.fedoraproject.org/ > > as far as I can tell. Crap. I did it again. Thanks for catching that. That is what I get for rushing a message out before taking off. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrobinson at gmail.com Sat Dec 19 06:50:32 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 19 Dec 2009 06:50:32 +0000 Subject: Release Milestones for the Masses In-Reply-To: <4B2BFF88.7050407@redhat.com> References: <4B2BFF88.7050407@redhat.com> Message-ID: <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> On Fri, Dec 18, 2009 at 10:17 PM, John Poelstra wrote: > One of the complaints heard during the last release cycle was that some > maintainers where unclear what all the schedule milestones meant. > > Before we reach any of these milestones for Fedora 13 I wanted to send this > out for feedback. ?What I have created represents our current process as I > understand it. ?Hopefully people on the list will have enough courage to > speak up if they disagree ;-) > > https://fedoraproject.org/wiki/User:Poelstra/Key_Milestones > > Are there any other milestones missing that we need to describe? > > Once we get closer to these milestones advanced reminders will be sent to > fedora-devel-announce for them. I think there should also be a Spin Request / Approved deadlines as well. Regards, Peter From kevin.kofler at chello.at Sat Dec 19 06:52:49 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Dec 2009 07:52:49 +0100 Subject: Question about a lib requires References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> <1261156274.22231.6.camel@localhost> <1261159467.2437.66.camel@vaio.local.net> <20091219004248.33d56659@gmail.com> Message-ID: Nicoleau Fabien wrote: > I think I'll use : > Requires: /usr/bin/jpegtran > Requires: /usr/bin/tiffinfo > > so if one day these files are put in a different package than the lib, > I won't be "surprised" Yeah, I've seen some libs grow a -tools subpackage for that sort of binaries. Plus, /usr/bin is one of the directories covered by primary.sqlite.bz2. Kevin Kofler From peter at thecodergeek.com Sat Dec 19 08:15:55 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 19 Dec 2009 00:15:55 -0800 Subject: Offline Until the New Year! Message-ID: <1261210555.2214.14.camel@localhost> Hi, all. Sincerest apologies for the lack of recent activity and the short notice here, but I'm going to be vacationing with family for the next couple of weeks. I'll return to active Fedora duty on January 2, 2010. Until then, I would very much appreciate others taking care of my packages: https://admin.fedoraproject.org/pkgdb/users/packages/pgordon Thanks very much, and have a great holiday season! :) -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From loupgaroublond at gmail.com Sat Dec 19 09:59:46 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sat, 19 Dec 2009 10:59:46 +0100 (CET) Subject: autofs not installed by default In-Reply-To: <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> Message-ID: 2009/12/18 Todd Volkert : > Hi Yaakov, > > Thanks for the response.? I'm actually only installing it on one local > machine, but I upgrade every Fedora release and have noticed this behavior > the past few releases.? I work at VMware, where every developer can install > whatever OS they want to work in, and in Linux, you use ypbind to get access > to your network login and shared folders.? Thus, I'm using a simple install > DVD.? I'll look into a kickstart file, though for one machine, it sounds > like it might not be worth it. Writing a kickstart is pretty easy, there are enough examples around, but going through the trouble for a once every six month process doesn't seem worth it. How do you normally install Fedora? Are you using the DVD Installer or a Live setup? With the DVD installer, you can customize the packages at install time, so you can make sure autofs is present before the machine boots up the first time. For your particular edge case, this seems like the safest bet. Kickstart is more useful for deploying larger rollouts, for example when you have three desktop machines that should all behave the same. The time it costs to set up your workflow, namely how you get the bits to the machine, say via a respun DVD via revisor or via a cobbler server makes more sense when you're doing this more than twice a year. It can turn a point and click festival into a press a button and wait experience. How much is your time at VMWare worth? -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: OpenPGP digital signature URL: From abo at root.snowtree.se Sat Dec 19 10:08:16 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 19 Dec 2009 11:08:16 +0100 Subject: packages requiring me to reboot... In-Reply-To: <4B2A9DE2.3030801@nodata.co.uk> References: <059DEDF49D6F4FD4A97140F5463ADAC0@C515816A> <4B2A9DE2.3030801@nodata.co.uk> Message-ID: <1261217296.7366.13.camel@tempo.alexander.bostrom.net> tor 2009-12-17 klockan 22:08 +0100 skrev nodata: > I wish mailing list discussions were point-for-point for-and-against. It > would be so much easier. You can easily accomplish this by quoting only the necessary text of the parent post and commenting between the lines. My Evolution preview window shows 38 lines of text. When _all_ of those are quoted text, the person who sent that mail did something wrong. (I'm not picking on you specifically, I think it's a general problem on this list.) > Here is my point: Windows requires a reboot less often than Linux. Argue > all you want, it's true. Like has been pointed out before, Fedora does not force a reboot at all. All it does is show an icon in the corner, telling me I need to log out or I need to reboot. It could gain more options, like "need to restart Firefox". > Linux has quicker security updates than Linux. That's an advantage. > > ksplice can patch a running kernel... I want suspend and resume with a new kernel. Also, ponies. :) /abo From mschwendt at gmail.com Sat Dec 19 10:20:24 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 19 Dec 2009 11:20:24 +0100 Subject: Question about a lib requires In-Reply-To: <1261159467.2437.66.camel@vaio.local.net> References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> <1261156274.22231.6.camel@localhost> <1261159467.2437.66.camel@vaio.local.net> Message-ID: <20091219112024.35494373@gmail.com> On Fri, 18 Dec 2009 18:04:27 +0000, Adam wrote: > On Fri, 2009-12-18 at 19:11 +0200, Jussi Lehtola wrote: > > > > > Is there a way to include these requires properly ? (like adding > > > > directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). > > > Yes. > > > > > > Requires: /usr/bin/jpegtran > > > Requires: /usr/bin/tiffinfo > > > > > > Does it really just need the binaries and not the libs, just that rpm > > > would auto-Require the libjpeg and libtiff RPMs? > > > > And if it actually needs the binaries, then you can just put in > > Requires: libjpeg, libtiff > > and safely ignore the rpmlint warning. AFAIK resolving file dependencies > > is a lot slower than resolving explicit dependencies. > > +1: just requiring the library packages and ignoring the rpmlint warning > seems correct here, to me. You are smarter than rpmlint, after all. > rpmlint is just considering the case where you're adding a library > dependency, not realizing it will be automatically generated. It is not > considering the case where the library package includes a binary that > you need to depend on. Well, there are guidelines for such explicit Requires: http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires If you apply this, a comment should be added to the spec file to explain explicit dependencies. Together with http://fedoraproject.org/wiki/Packaging:Guidelines#Requires that section of the guidelines covers more than just library dependencies. The file dependencies, which are preferred in this case, are covered, too: http://fedoraproject.org/wiki/Packaging:Guidelines#File_Dependencies From belegdol at gmail.com Sat Dec 19 10:36:56 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Sat, 19 Dec 2009 11:36:56 +0100 Subject: moonlight and the new covenant Message-ID: Hi, according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? Julian [1] http://tirania.org/blog/archive/2009/Dec-17.html From fedora at alexhudson.com Sat Dec 19 10:47:49 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Sat, 19 Dec 2009 10:47:49 +0000 Subject: moonlight and the new covenant In-Reply-To: References: Message-ID: <4B2CAF55.7060703@alexhudson.com> On 19/12/09 10:36, Julian Sikorski wrote > according to Miguel [1], the moonlight covenant was updated and now > allows for redistribution by third parties. Does it change anything wrt. > its inclusion in Fedora? > I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. If what they are saying, that people who get Moonlight without being a Novell customer are covered by the patent covenant, I would hope that removes whatever stumbling block remains. Cheers Alex. From julian.fedoralists at googlemail.com Sat Dec 19 10:54:25 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Sat, 19 Dec 2009 11:54:25 +0100 Subject: moonlight and the new covenant In-Reply-To: References: Message-ID: <1261220065.6025.5.camel@localhost.localdomain> Am Samstag, den 19.12.2009, 11:36 +0100 schrieb Julian Sikorski: > Hi, > > according to Miguel [1], the moonlight covenant was updated and now > allows for redistribution by third parties. Does it change anything wrt. > its inclusion in Fedora? > > Julian > > [1] http://tirania.org/blog/archive/2009/Dec-17.html > I've read that as well and was asking myself the same question. This link may be of interest as well: http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From julian.fedoralists at googlemail.com Sat Dec 19 11:00:53 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Sat, 19 Dec 2009 12:00:53 +0100 Subject: moonlight and the new covenant In-Reply-To: <4B2CAF55.7060703@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> Message-ID: <1261220453.6025.11.camel@localhost.localdomain> Am Samstag, den 19.12.2009, 10:47 +0000 schrieb Alex Hudson: > On 19/12/09 10:36, Julian Sikorski wrote > > according to Miguel [1], the moonlight covenant was updated and now > > allows for redistribution by third parties. Does it change anything wrt. > > its inclusion in Fedora? > > > > I doubt it's worth asking until the new covenant is actually published, > which is supposed to happen next week. > > If what they are saying, that people who get Moonlight without being a > Novell customer are covered by the patent covenant, I would hope that > removes whatever stumbling block remains. > > Cheers > > Alex. > The covenant is published as far as I can see here: http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx I'm not a lawyer, but this does not read like it is very permissive. Just a short quote: "Microsoft reserves the right to update (including discontinue) the foregoing covenant pursuant to the terms of the Moonlight for Linux Collaboration Agreement between Novell and Microsoft that was publicly announced on September 5, 2007 (the ?Agreement?); however, the foregoing covenant will continue as to specific copies of Moonlight Implementations distributed by Novell before any such update." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora at alexhudson.com Sat Dec 19 11:03:26 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Sat, 19 Dec 2009 11:03:26 +0000 Subject: moonlight and the new covenant In-Reply-To: <1261220453.6025.11.camel@localhost.localdomain> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> Message-ID: <4B2CB2FE.902@alexhudson.com> On 19/12/09 11:00, Julian Aloofi wrote: > Am Samstag, den 19.12.2009, 10:47 +0000 schrieb Alex Hudson: > >> I doubt it's worth asking until the new covenant is actually published, >> which is supposed to happen next week. >> > The covenant is published as far as I can see here: > No, that's the previous one which was not good enough. The new one is not yet published. Thanks Alex. From julian.fedoralists at googlemail.com Sat Dec 19 12:37:17 2009 From: julian.fedoralists at googlemail.com (Julian Aloofi) Date: Sat, 19 Dec 2009 13:37:17 +0100 Subject: moonlight and the new covenant In-Reply-To: <4B2CB2FE.902@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> Message-ID: <1261226237.2025.0.camel@localhost.localdomain> Am Samstag, den 19.12.2009, 11:03 +0000 schrieb Alex Hudson: > On 19/12/09 11:00, Julian Aloofi wrote: > > Am Samstag, den 19.12.2009, 10:47 +0000 schrieb Alex Hudson: > > > >> I doubt it's worth asking until the new covenant is actually published, > >> which is supposed to happen next week. > >> > > The covenant is published as far as I can see here: > > > > No, that's the previous one which was not good enough. > > The new one is not yet published. > > Thanks > > Alex. > OK, thank you for clarification. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rawhide at fedoraproject.org Sat Dec 19 13:40:03 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 19 Dec 2009 13:40:03 +0000 Subject: rawhide report: 20091219 changes Message-ID: <20091219134003.GA28369@releng2.fedora.phx.redhat.com> Compose started at Sat Dec 19 08:15:03 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kdebase-workspace-python-applet-4.3.85-1.fc13.i686 requires PyKDE4 >= 0:4.3.85 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tokyotyrant-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kdebase-workspace-python-applet-4.3.85-1.fc13.x86_64 requires PyKDE4 >= 0:4.3.85 kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tokyotyrant-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package php-phpunit-bytekit A command-line tool built on the PHP Bytekit extension Removed package tetex-perltex Updated Packages: 389-admin-1.1.10-0.2.a2.fc13 ---------------------------- * Fri Dec 18 2009 Rich Megginson - 1.1.10.a2-0.2 - the 1.1.10.a2 release - fix problem with genrb path on F-12 and later * Thu Oct 08 2009 Rich Megginson - 1.1.10.a1-1 - the 1.1.10.a1 release ModemManager-0.2.997-4.git20091218.fc13 --------------------------------------- * Fri Dec 18 2009 Dan Williams - 0.2.997-4.git20091218 - sierra: fix CDMA registration detection in some cases (rh #547513) abby-0.4.7-1.fc13 ----------------- * Fri Dec 18 2009 Nicoleau Fabien 0.4.7-1 - Update to 0.4.7 anaconda-13.12-1.fc13 --------------------- * Fri Dec 18 2009 David Cantrell - 13.12-1 - Use the per-disk flag to disable cylinder alignment for msdos disklabels. (dlehman) - Don't include advanced devices in the total count on the basic filter UI. (clumens) - For iSCSI devices, put the path into the UI instead of a WWID. (clumens) - Add udev_device_get_path. (clumens) - Make Callbacks._update_size_label callable from outside the object. (clumens) - Do not show the "Add Advanced" button on the basic filtering screen. (clumens) - Log into program.log through the standard python logging (part of - Fix typo from commit 13022cc2. (dlehman) - Restore accidentally removed line in backend.py (hdegoede) - yuminstall: Fix indentation error (hdegoede) - No need to special case ignoring of dmraid sets (hdegoede) attica-0.1.1-1.fc13 ------------------- * Fri Dec 18 2009 Rex Dieter - 0.1.1-1 - attica-0.1.1 babl-0.1.0-5.fc13 ----------------- * Fri Dec 18 2009 Deji Akingunola - 0.1.0-5 - Remove the *.la files * Thu Aug 13 2009 Nils Philippsen - explain patch status binutils-2.20.51.0.2-11.fc13 ---------------------------- * Fri Dec 18 2009 Nick Clifton - 2.20.51.0.2-11 - Add missing part of PR 11088 patch. cclive-0.5.7-1.fc13 ------------------- * Fri Dec 18 2009 Nicoleau Fabien 0.5.7-1 - Update to 0.5.7 chunkd-0.6-0.4.g756ea210.fc13 ----------------------------- * Fri Dec 18 2009 Jeff Garzik - 0.6-0.4.g756ea210 - rebuild for tokyocabinet dependency clive-2.2.8-1.fc13 ------------------ * Fri Dec 18 2009 Nicoleau Fabien 2.2.8-1 - Update to 2.2.8 crda-1.1.0_2009.11.25-2.fc13 ---------------------------- * Fri Dec 18 2009 John W. Linville 1.1.0_2009.11.25-2 - Specify patch to iw in setregdomain docbook-style-dsssl-1.79-9.fc13 ------------------------------- * Fri Dec 18 2009 Ondrej Vasik - 1.79-9 - License Copyright only docbook-style-xsl-1.75.2-5.fc13 ------------------------------- * Fri Dec 18 2009 Ondrej Vasik 1.75.3-5 - comment patches purpose - License Copyright only dovecot-1.2.9-1.fc13 -------------------- * Fri Dec 18 2009 Michal Hlavinka - 1:1.2.9-1 - updated to 1.2.9 - maildir: When saving, filenames now always contain ,S=. Previously this was done only when quota plugin was loaded. It's required for zlib plugin and may be useful for other things too. - maildir: v1.2.7 and v1.2.8 caused assert-crashes in maildir_uidlist_records_drop_expunges() - maildir_copy_preserve_filename=yes could have caused crashes. - Maildir++ quota: % limits weren't updated when limits were read from maildirsize. - virtual: v1.2.8 didn't fully fix the "lots of mailboxes" bug - virtual: Fixed updating virtual mailbox based on flag changes. - fts-squat: Fixed searching multi-byte characters. * Wed Nov 25 2009 Michal Hlavinka - 1:1.2.8-4 - spec cleanup doxygen-1.6.1-4.fc13 -------------------- * Fri Dec 18 2009 Than Ngo - 1:1.6.1-3 - bz#225709, merged review * Fri Dec 18 2009 Than Ngo - 1:1.6.1-4 - drop _default_patch_fuzz * Fri Dec 11 2009 Than Ngo - 1:1.6.1-2 - bz#225709, merged review gallery2-2.3.1-1.fc13 --------------------- * Thu Dec 17 2009 Jon Ciesla - 2.3.1-1 - 2.3.1, fix for upgrader in PHP 5.3.x. - smtp patch upstreamed. gbirthday-0.5.6-1.fc13 ---------------------- * Fri Dec 18 2009 Thomas Spura 0.5.6-1 - new version - delete ebook.patch again ghc-zlib-0.5.0.0-11.fc13 ------------------------ * Wed Dec 16 2009 Jens Petersen - 0.5.0.0-11 - build for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 - use cabal_pkg_conf to generate package.conf.d file and use ghc-pkg recache gnome-power-manager-2.29.1-2.fc13 --------------------------------- * Fri Dec 18 2009 Matthias Clasen - 2.29.1-2 - Avoid warning messages at startup gnome-settings-daemon-2.28.1-10.fc13 ------------------------------------ * Fri Dec 18 2009 Matthias Clasen 2.28.1-10 - Avoid warning messages from the OSD code graphviz-2.26.0-1.fc13 ---------------------- * Fri Dec 18 2009 Patrick "Jima" Laughton 2.26.0-1 - Updated to latest release - Removed patches that have been applied upstream - Fixed man page paths (mann -> man3) - Disabled mono and ocaml for ARM (Jitesh Shah, BZ#532047) - Disabled regression tests on sparc64 as well as ppc/ppc64 (Dennis Gilmore) kdeaccessibility-4.3.85-1.fc13 ------------------------------ * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdeadmin-4.3.85-1.fc13 ---------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdeartwork-4.3.85-1.fc13 ------------------------ * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdebase-4.3.85-1.fc13 --------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-4 - Repositioning the KDE Brand (#547361) kdebase-runtime-4.3.85-1.fc13 ----------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-4 - Repositioning the KDE Brand (#547361) kdebase-workspace-4.3.85-1.fc13 ------------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-5 - Repositioning the KDE Brand (#547361) kdeedu-4.3.85-1.fc13 -------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdegames-4.3.85-2.fc13 ---------------------- * Sat Dec 19 2009 Kevin Kofler - 4.3.85-2 - drop kdegames-4.3.85-fix_liblogine_link.patch, should not be needed anymore * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-3 - Repositioning the KDE Brand (#547361) kdegraphics-4.3.85-1.fc13 ------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdelibs-4.3.85-3.fc13 --------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - 4.3.85 (4.4 beta2) * Fri Dec 18 2009 Rex Dieter - 4.3.85-2 - plasma_scrollwidget patch * Fri Dec 18 2009 Rex Dieter - 4.3.85-3 - -devel: Requires: attica-devel * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-5 - Repositioning the KDE Brand (#547361) kdemultimedia-4.3.85-1.fc13 --------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdenetwork-4.3.85-1.fc13 ------------------------ * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdepim-4.3.85-1.fc13 -------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-6 - Repositioning the KDE Brand (#547361) kdepim-runtime-4.3.85-1.fc13 ---------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdepimlibs-4.3.85-1.fc13 ------------------------ * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - 4.3.85 (4.4 beta2) - tighten deps * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdeplasma-addons-4.3.85-1.fc13 ------------------------------ * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdesdk-4.3.85-1.fc13 -------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdetoys-4.3.85-1.fc13 --------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-2 - Repositioning the KDE Brand (#547361) kdeutils-4.3.85-1.fc13 ---------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) * Wed Dec 16 2009 Jaroslav Reznik - 4.3.80-3 - Repositioning the KDE Brand (#547361) kernel-2.6.32.2-14.fc13 ----------------------- * Fri Dec 18 2009 Roland McGrath - 2.6.32.1-13 - minor utrace update * Fri Dec 18 2009 Kyle McMartin 2.6.32.2-14 - Linux 2.6.32.2 - dropped upstream patches. klavaro-1.4.0-1.fc13 -------------------- * Fri Dec 18 2009 Fabian Affolter - 1.4.0-1 - BR libsexy-devel removed - Updated to new upstream version 1.4.0 libgphoto2-2.4.7-3.fc13 ----------------------- * Fri Dec 18 2009 Jindrich Novy 2.4.7-3 - remove circular symlink in /usr/include/gphoto2 (#460807) libguestfs-1.0.80-3.fc13 ------------------------ * Fri Dec 18 2009 Richard W.M. Jones - 1.0.80-3 - Work around udevsettle command problem (RHBZ#548121). - Enable tests. libsidplay-1.36.57-21.fc13 -------------------------- * Thu Dec 17 2009 Michael Schwendt - 1.36.57-21 - apply minor patch to avoid uninitialised values linuxdoc-tools-0.9.66-4.fc13 ---------------------------- * Fri Dec 18 2009 Ondrej Vasik 0.9.66-2 - License Copyright only * Fri Dec 18 2009 Ondrej Vasik 0.9.66-3 - do not obsolete self * Fri Dec 18 2009 Ondrej Vasik 0.9.66-4 - fix perl5 dir paths mpfr-2.4.2-1.fc13 ----------------- * Fri Dec 18 2009 Ivana Hutarova Varekova 2.4.2-1 - update to 2.4.2 nforenum-3.4.7-0.3.r2275.fc13 ----------------------------- * Fri Dec 18 2009 Felix Kaechele - 3.4.7-0.3.r2275 - new snapshot nss-3.12.5-1.fc13.7 ------------------- * Fri Dec 18 2009 Elio Maldonado - 3.12.5-2.7 - Fix a misconstructed patch * Thu Dec 17 2009 Elio Maldonado - 3.12.5-1.6 - Fix nsssysinit to enable applications to use the system database (#546221) - Fix spec so sysinit requires coreutils for post install scriplet (#547067) - Fix segmentation fault when listing keys or certs in the database (#540387) * Thu Dec 10 2009 Elio Maldonado - 3.12.5-1.5 - Fix nsssysinit to set the default flags on the crypto module (#545779) - Remove redundant header from the pem module openttd-0.7.5-0.1.rc1.fc13 -------------------------- * Thu Dec 17 2009 Felix Kaechele - 0.7.5-0.1.rc1 - bump to 0.7.5-RC1 - omitting 0.7.4 because it has a bug oxygen-icon-theme-4.3.85-1.fc13 ------------------------------- * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - 4.3.85 (4.4 beta2) par2cmdline-0.4.tbb.20090203-3.fc13 ----------------------------------- * Sat Dec 12 2009 Erik van Pienbroek - 0.4.tbb.20090203-3 - Rebuild for new tbb parted-1.9.0-24.fc13 -------------------- * Fri Dec 18 2009 Hans de Goede 1.9.0-24 - Allow partitioning of loopback devices (#546622) - Add libparted function to query maximum partition length and start addresses for a given disk (#533417) - Add per disk flags functions from upstream, this is the way upstream has implemented the disable cylinder alignment functionality - Add --align cmdline option to specify how to align new partitions see the parted man page for details (#361951) - Make the default alignment for new partitions optimal (#361951) - When cylinder alignment is disabled, allow use of the last (incomplete) cylinder of the disk (#533328) - Don't crash when printing partition tables in Russian (#543029) - Make parted work correctly with new lvm (#525095) perl-5.10.1-106.fc13 -------------------- * Sat Dec 19 2009 Ralf Cors?pius - 4:5.10.1-105 - exclude Parse-CPAN-Meta. * Sat Dec 19 2009 Ralf Cors?pius - 4:5.10.1-106 - exclude "parent". perl-Catalyst-Controller-HTML-FormFu-0.06001-1.fc13 --------------------------------------------------- * Fri Dec 18 2009 Iain Arnell 0.06001-1 - update to latest upstream version perl-HTML-FormFu-0.05004-2.fc13 ------------------------------- * Fri Dec 18 2009 Iain Arnell 0.05004-2 - fix silly typo in requires filtering perl-Lingua-Flags-0.07-1.fc13 ----------------------------- * Fri Dec 18 2009 Iain Arnell 0.07-1 - update to latest upstream version perl-WWW-Curl-4.11-1.fc13 ------------------------- * Fri Dec 18 2009 Nicoleau Fabien - 4.11-1 - Update to 4.11 php-channel-phpunit-1.3-2.fc13 ------------------------------ * Fri Dec 18 2009 Remi Collet - 1.3-1 - update for REST 1.3 and new URL (#542417) - rename pear.phpunit.de.xml to php-channel-phpunit.xml * Fri Dec 18 2009 Remi Collet - 1.3-2 - missing Requires for post/postun php-pecl-ncurses-1.0.1-1.fc13 ----------------------------- * Sat Dec 19 2009 Remi Collet 1.0.1-1 - update to 1.0.1 - enable wide char support php-phpunit-phpcpd-1.2.2-2.fc13 ------------------------------- * Fri Dec 18 2009 Guillaume Kulakowski - 1.2.2-2 - /usr/share/pear/PHPCPD wasn't owned php-phpunit-phploc-1.4.0-2.fc13 ------------------------------- * Fri Dec 18 2009 Guillaume Kulakowski - 1.4.0-2 - /usr/share/pear/PHPLOC wasn't owned purple-msn-pecan-0.1.0-0.3.rc1.fc13 ----------------------------------- * Fri Dec 18 2009 Edouard Bourguignon - 0.1.0-0.3.rc1 - patch to handle malformed data was not complete (bz #547836) * Mon Dec 14 2009 Edouard Bourguignon - 0.1.0-0.2.rc1 - Add Simone Contini's patch to handle malformed data in process_body_receive (bz #547078) pybackpack-0.5.7-2.fc13 ----------------------- python-pip-0.6.1-3.fc13 ----------------------- * Fri Dec 18 2009 Peter Halliday - 0.6.1-2 - fix spec file * Thu Dec 17 2009 Peter Halliday - 0.6.1-1 - upgrade to 0.6.1 of pip qbittorrent-2.0.2-1.fc13 ------------------------ * Fri Dec 18 2009 Leigh Scott - 2.0.2-1 - update to 2.0.2 - add gcc patch to fix #548491 quake3-1.36-5.fc13 ------------------ * Fri Dec 18 2009 Hans de Goede 1.36-5 - Modify Urban Terror launch script to allow downloading of maps by default rapid-photo-downloader-0.1.0-1.fc13 ----------------------------------- * Fri Dec 18 2009 Fabian Affolter - 0.1.0-1 - Updated to new upstream version 0.1.0 rednotebook-0.9.0-1.fc13 ------------------------ * Fri Dec 18 2009 Christoph Wickert - 0.9.0-1 - Update to 0.9.0 * Thu Nov 19 2009 Fabian Affolter - 0.8.9-2 - Updated the URL after a request from the upstream maintainer rsyslog-4.4.2-3.fc13 -------------------- * Thu Dec 17 2009 Tomas Heinrich 4.4.2-3 - change exec-prefix to / rtkit-0.5-1.fc13 ---------------- * Fri Dec 18 2009 Lennart Poettering - 0.5-1 - New release - By default don't demote unknown threads - Make messages less cute - Fixes 530582 rubygem-marc-0.3.3-1.fc13 ------------------------- * Sat Dec 19 2009 Mamoru Tasaka - 0.3.3-1 - 0.3.3 shotwell-0.4.0-0.1.20091218svn.fc13 ----------------------------------- * Fri Dec 18 2009 Matthias Clasen - 0.4.0-0.1.20091218svn * Thu Nov 12 2009 Matthias Clasen - 0.3.2-1 - Update to 0.3.2 sipwitch-0.5.12-0.fc13 ---------------------- * Wed Dec 09 2009 David Sugar - 0.5.12-0 - redefined internal user & service permissions and profiles. - fixed anonymous inbound. - added missing manpages. * Wed Nov 18 2009 David Sugar - 0.5.9-0 - removed snmp/mib from this package - removed unused swig support and complex packaging it required. spamassassin-3.3.0-0.23.rc1.fc13 -------------------------------- * Fri Dec 18 2009 Warren Togami - 3.3.0-0.23.rc1 - 3.3.0-rc1 - Bug #103401: portreserve protect spamd port 783 on F-10+ sssd-1.0.0-1.fc13 ----------------- * Fri Dec 18 2009 Stephen Gallagher - 1.0.0-1 - New upstream stable release 1.0.0 sugar-base-0.87.1-2.fc13 ------------------------ * Fri Dec 18 2009 Peter Robinson 0.87.1-2 - Remove libtool archives sugar-datastore-0.87.1-2.fc13 ----------------------------- * Fri Dec 18 2009 Peter Robinson 0.87.1-2 - Remove libtool archives sugar-toolkit-0.87.1-2.fc13 --------------------------- * Fri Dec 18 2009 Peter Robinson 0.87.1-2 - Remove libtool archives system-config-printer-1.1.15-9.fc13 ----------------------------------- * Fri Dec 18 2009 Jiri Popelka 1.1.15-9 - Prevent traceback when no downloadable driver selected (#548449). transmission-1.80-0.1.b3.fc13 ----------------------------- ucommon-2.0.7-1.fc13 -------------------- * Fri Dec 18 2009 - David Sugar - 2.0.7-1 - fixed install script handling upstream and fixed pedantic gcc 4.4 issues. wireshark-1.2.5-1.fc13 ---------------------- * Fri Dec 18 2009 Radek Vokal - 1.2.5-1 - upgrade to 1.2.5 - fixes security vulnaribilities, see http://www.wireshark.org/security/wnpa-sec-2009-09.html Summary: Added Packages: 1 Removed Packages: 1 Modified Packages: 83 From mcepl at redhat.com Sat Dec 19 15:13:05 2009 From: mcepl at redhat.com (=?ISO-8859-2?Q?Mat=ECj_Cepl?=) Date: Sat, 19 Dec 2009 16:13:05 +0100 Subject: Etherpad for Fedora? Message-ID: http://code.google.com/p/etherpad/ ... is anybody tempted? Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Our lives are spectacles of powerlessness. -- Richard Rohr From snecklifter at gmail.com Sat Dec 19 16:03:55 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Sat, 19 Dec 2009 16:03:55 +0000 Subject: mono and snk key files In-Reply-To: <4B26DC37.2090008@spicenitz.org> References: <4B1297E5.1030207@smartlink.ee> <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> <4B227781.7080409@spicenitz.org> <364d303b0912130316g3b64c40ex49c9572bf8bcc4ea@mail.gmail.com> <4B26DC37.2090008@spicenitz.org> Message-ID: <364d303b0912190803r30a86869j794a269ac117fff6@mail.gmail.com> 2009/12/15 Adam Goode : > On 12/13/2009 06:16 AM, Christopher Brown wrote: >> 2009/12/11 Adam Goode : >>> We should definitely use Debian's key, right? Otherwise some Fedora CLI >>> libraries would be unnecessarily incompatible with Debian, and whoever >>> else uses Debian's key. >>> >>> The whole business of not shipping code-signing keys is a little >>> contrary to open source. I think this is something that GPLv3 would >>> prohibit. We should use a single well-known signing key for any package >>> that we don't have the keys for, I think. >> >> You're right. >> >> This has already been resolved in devel by added mono.snk to the >> mono-devel package. I'm just waiting on commit access to make the >> required changes to F-11 and F-12 unless someone else wants to do it. >> > > It looks like spot generated a new mono.snk. I was arguing to use > Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone > should use Debian's key unless a package provides its own? Ideally we (Fedora and Debian) should use a single key generated by upstream but as this issue is only problematic due to cyclic dep problems in the build process I think that using our own is enough. Unfortunately I don't care enough to chase this issue further. -- Christopher Brown From tim.lauridsen at googlemail.com Sat Dec 19 16:04:24 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Sat, 19 Dec 2009 17:04:24 +0100 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261179109.19834.48.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> Message-ID: <4B2CF988.6040007@googlemail.com> On 12/19/2009 12:31 AM, Jesse Keating wrote: > Phase two, write access with ACLs, is ready for testing. Please not > that URLs have changed since my original announcement. > > git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ > > will get you a cone via ssh, in which you can git pull and git push. > > The repos are the same from phase1, although I've done a few commits > here and there to test things. They are not tied to the CVS repos, so > changes you make here are truly throw away. > > Please test cloning and writing to packages and branches of packages > that you would normally have write access to, or normally would /not/ > have write access to. I'm interested in seeing both of those cases > tried. > > Thanks again for your help in this project! > > Checked that I can checkout yumex and commit at change to yumex.spec to master and F-12 branch. Checked hat I can checkout kernel (F-10 and master) and i get a W access for kernel DENIED to timlau fatal: The remote end hung up unexpectedly If i try to commit some changes to the kernel.spec So it look like it work as expected. Tim From jonathan.underwood at gmail.com Sat Dec 19 16:42:30 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 19 Dec 2009 16:42:30 +0000 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261179109.19834.48.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> Message-ID: <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> 2009/12/18 Jesse Keating : > Phase two, write access with ACLs, is ready for testing. ?Please not > that URLs have changed since my original announcement. > > git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ > > will get you a cone via ssh, in which you can git pull and git push. > > The repos are the same from phase1, although I've done a few commits > here and there to test things. ?They are not tied to the CVS repos, so > changes you make here are truly throw away. > > Please test cloning and writing to packages and branches of packages > that you would normally have write access to, or normally would /not/ > have write access to. ?I'm interested in seeing both of those cases > tried. I checked out emacs-vm and the commited and pushed a change to the spec file and was quite surprised to find that the change was pushed to all branches. Is that intended ? From abo at root.snowtree.se Sat Dec 19 16:42:30 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 19 Dec 2009 17:42:30 +0100 Subject: packages requiring me to reboot... In-Reply-To: <20091217202150.GE4126@macmahon.me.uk> References: <4B27BE72.5020002@gnat.ca> <4B27C0B9.7060403@gnat.ca> <15e53e180912150940o19990479y87d41e6248fa5328@mail.gmail.com> <15e53e180912160050r3eb78fc1k149b63a87f4803b7@mail.gmail.com> <1261065070.21633.3.camel@code.and.org> <20091217202150.GE4126@macmahon.me.uk> Message-ID: <1261240950.7366.24.camel@tempo.alexander.bostrom.net> tor 2009-12-17 klockan 20:21 +0000 skrev Ewan Mac Mahon: > Simply killing the process is > actually less disruptive. Yes. Please do not send close events to my Firefox windows. Do keep in mind that Firefox is pretty much broken and might not even be able to show a "Do you want to restart?" dialog by the time the RPM transaction is rolling, so if it's going to involve user interaction, that will have to happen in the PackageKit GUI. Another option is to make Firefox notice internally how broken it is and try to restart itself. It would need to somehow wait until the transaction is done, though. /abo From jonathan.underwood at gmail.com Sat Dec 19 16:55:57 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 19 Dec 2009 16:55:57 +0000 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> References: <1261179109.19834.48.camel@localhost.localdomain> <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> Message-ID: <645d17210912190855h1ad36ae1n4f35d6b6c2bc8753@mail.gmail.com> 2009/12/19 Jonathan Underwood : > I checked out emacs-vm and the commited and pushed a change to the > spec file and was quite surprised to find that the change was pushed > to all branches. Is that intended ? > Er, ignore that, I was confusing myself. From tgl at redhat.com Sat Dec 19 17:00:19 2009 From: tgl at redhat.com (Tom Lane) Date: Sat, 19 Dec 2009 12:00:19 -0500 Subject: Question about a lib requires In-Reply-To: References: <20091218180327.6f74e29d@gmail.com> <4B2BB566.4080404@jcomserv.net> <1261156274.22231.6.camel@localhost> <1261159467.2437.66.camel@vaio.local.net> <20091219004248.33d56659@gmail.com> Message-ID: <11607.1261242019@sss.pgh.pa.us> Kevin Kofler writes: > Nicoleau Fabien wrote: >> I think I'll use : >> Requires: /usr/bin/jpegtran >> Requires: /usr/bin/tiffinfo >> >> so if one day these files are put in a different package than the lib, >> I won't be "surprised" > Yeah, I've seen some libs grow a -tools subpackage for that sort of > binaries. ... as, indeed, libtiff just did a few days ago. regards, tom lane From jonathan.underwood at gmail.com Sat Dec 19 17:02:24 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 19 Dec 2009 17:02:24 +0000 Subject: Koji stuck? Message-ID: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> Hi, I kicked off a couple of builds last night which appear stuck on koji. I had checked they build locally with a make mockbuild before submitting and all was fine. The builds are: http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 Should I just cancel and resubmit, or? Cheers, Jonathan From jkeating at j2solutions.net Sat Dec 19 17:28:13 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 19 Dec 2009 09:28:13 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> References: <1261179109.19834.48.camel@localhost.localdomain> <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> Message-ID: <4F5B0DE7-07E9-4B4F-B81C-DCE776713FF1@j2solutions.net> On Dec 19, 2009, at 8:42, Jonathan Underwood wrote: > 2009/12/18 Jesse Keating : >> Phase two, write access with ACLs, is ready for testing. Please not >> that URLs have changed since my original announcement. >> >> git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ >> >> will get you a cone via ssh, in which you can git pull and git push. >> >> The repos are the same from phase1, although I've done a few commits >> here and there to test things. They are not tied to the CVS repos, >> so >> changes you make here are truly throw away. >> >> Please test cloning and writing to packages and branches of packages >> that you would normally have write access to, or normally would /not/ >> have write access to. I'm interested in seeing both of those cases >> tried. > > I checked out emacs-vm and the commited and pushed a change to the > spec file and was quite surprised to find that the change was pushed > to all branches. Is that intended ? > Um, no. I'll look at this module and see what happened. -- Jes From halfline at gmail.com Sat Dec 19 17:41:50 2009 From: halfline at gmail.com (Ray Strode) Date: Sat, 19 Dec 2009 12:41:50 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261179109.19834.48.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> Message-ID: <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> Hi, On Fri, Dec 18, 2009 at 6:31 PM, Jesse Keating wrote: > Phase two, write access with ACLs, is ready for testing. ?Please not > that URLs have changed since my original announcement. > > git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ > > will get you a cone via ssh, in which you can git pull and git push. > > The repos are the same from phase1, although I've done a few commits > here and there to test things. ?They are not tied to the CVS repos, so > changes you make here are truly throw away. > > Please test cloning and writing to packages and branches of packages > that you would normally have write access to, or normally would /not/ > have write access to. ?I'm interested in seeing both of those cases > tried. So one thing I tried is to create a custom topic branch (a la private- branches in pkgs cvs), and pushing it failed. Is this something we want to support? Or should topic branches be pushed to separate private respositories? --Ray From jonathan.underwood at gmail.com Sat Dec 19 17:54:13 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 19 Dec 2009 17:54:13 +0000 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4F5B0DE7-07E9-4B4F-B81C-DCE776713FF1@j2solutions.net> References: <1261179109.19834.48.camel@localhost.localdomain> <645d17210912190842x7a15578fxf7a39e07da585529@mail.gmail.com> <4F5B0DE7-07E9-4B4F-B81C-DCE776713FF1@j2solutions.net> Message-ID: <645d17210912190954v2c91aaa2rb91d8eebbc2643ae@mail.gmail.com> 2009/12/19 Jesse Keating : > Um, no. I'll look at this module and see what happened. Sorry - false alarm, I was confusing myself. J. From paul at all-the-johnsons.co.uk Sat Dec 19 18:33:38 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 19 Dec 2009 18:33:38 +0000 Subject: Pulseaudio problem with xine, xmms and mplayer Message-ID: <1261247618.3375.4.camel@PB3.linux> Hi, Whenever I try to run xine, xmms or mplayer from the command line, I keep getting an error from pulseaudio Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. It makes no difference if I try to use ogg, mp3 or wav files, they all fail and die with the same error. I'm using pulseaudio-0.9.21-3.fc13 and the 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel PAM fires up and reports all the audio devices are running fine. Any ideas? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Dec 19 18:56:57 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 19 Dec 2009 10:56:57 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> Message-ID: <1261249017.2271.5.camel@localhost.localdomain> On Sat, 2009-12-19 at 12:41 -0500, Ray Strode wrote: > So one thing I tried is to create a custom topic branch (a la private- > branches in pkgs cvs), and pushing it failed. > > Is this something we want to support? Or should topic branches be > pushed to separate private respositories? We definitely want to allow topic branches pushed to the main repo. I think we'll have to agree on a namespace to use for these, perhaps following the dist-cvs example and call them private-* The way the ACL system works is that it matches on the refs you're pushing up, so for packages that have per-branch ACLs only the refs that match the branch have ACLs on them, and the assumption is that without an ACL you have no rights to it. That's likely why your push failed, but I'd like to see the message to confirm. It shouldn't be too hard to tweak the ACL creation script to add W access to anybody who has W access already to the private-* namespace. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From cassmodiah at fedoraproject.org Sat Dec 19 20:44:51 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Sat, 19 Dec 2009 21:44:51 +0100 Subject: Orphaned some packages Message-ID: <1261255491.3341.67.camel@localhost.localdomain> Hi all, fresh orphaned packages: (EL-4,EL-5) (Fedora) apt-mirror: APT sources mirroring tool Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/apt-mirror backintime: Simple backup system Bugs: 3 https://admin.fedoraproject.org/pkgdb/packages/bugs/backintime barrage: Kill and destroy as many targets as possible within 3 minutes Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/barrage bastet: An evil falling bricks game Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/bastet bauble: Biodiversity collection manager Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/bauble biniax: A unique arcade logic game Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/biniax fbpanel: A lightweight X11 desktop panel Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/fbpanel griffith: Media collection manager Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/griffith griv: A GTK-Chat based on the RIV-Chat-protocol Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/griv libwps: Library for reading and converting Microsoft Works word processor documents Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/libwps (EL-5) (Fedora) nssbackup: (Not so) Simple Backup Suite for desktop use Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/nssbackup peppy: Editor written in python Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/peppy python-rabbyt: Sprite library for Python Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/python-rabbyt (EL-5) (Fedora) sbackup: Simple Backup Suite for desktop use Bugs: 1 (2 on QA) https://admin.fedoraproject.org/pkgdb/packages/bugs/sbackup (EL-5) tor: Anonymizing overlay network for TCP (The onion router) Bugs: 0 (for EPEL) https://admin.fedoraproject.org/pkgdb/packages/bugs/tor (EL-5) vidalia: Controller GUI for the Tor Onion Routing Network Bugs: 0 (for epel) https://admin.fedoraproject.org/pkgdb/packages/bugs/vidalia xpad: Sticky notepad for GTK+2 Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/xpad xqf: A server browser for many popular games Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/xqf -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp From halfline at gmail.com Sat Dec 19 21:02:52 2009 From: halfline at gmail.com (Ray Strode) Date: Sat, 19 Dec 2009 16:02:52 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261249017.2271.5.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> Message-ID: <45abe7d80912191302o2ef13005kfff46badb9e1d0fa@mail.gmail.com> Hi, > We definitely want to allow topic branches pushed to the main repo. ?I > think we'll have to agree on a namespace to use for these, perhaps > following the dist-cvs example and call them private-* > > The way the ACL system works is that it matches on the refs you're > pushing up, so for packages that have per-branch ACLs only the refs that > match the branch have ACLs on them, and the assumption is that without > an ACL you have no rights to it. ?That's likely why your push failed, > but I'd like to see the message to confirm. $ git push origin private-topic-branch Total 0 (delta 0), reused 0 (delta 0) W refs/heads/private-topic-branch plymouth rstrode DENIED by fallthru error: hooks/update exited with error code 255 error: hook declined to update refs/heads/private-topic-branch To ssh://rstrode at pkgs.stg.fedoraproject.org/plymouth ! [remote rejected] private-topic-branch -> private-topic-branch (hook declined) error: failed to push some refs to 'ssh://rstrode at pkgs.stg.fedoraproject.org/plymouth' --Ray From kevin at scrye.com Sat Dec 19 21:11:42 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Sat, 19 Dec 2009 14:11:42 -0700 Subject: Koji stuck? In-Reply-To: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> Message-ID: <20091219141142.1624c977@ohm.scrye.com> On Sat, 19 Dec 2009 17:02:24 +0000 Jonathan Underwood wrote: > Hi, > > I kicked off a couple of builds last night which appear stuck on koji. > I had checked they build locally with a make mockbuild before > submitting and all was fine. > > The builds are: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 > http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 > > Should I just cancel and resubmit, or? I've seen this same thing in some other emacs packages builds. Something just causes them to get stuck. ;( I guess I would say try canceling and re-submitting, if that doesn't work, try a local mock and see if you can see where it's getting stuck. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From oget.fedora at gmail.com Sat Dec 19 22:19:37 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 19 Dec 2009 17:19:37 -0500 Subject: Koji stuck? In-Reply-To: <20091219141142.1624c977@ohm.scrye.com> References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> Message-ID: On Sat, Dec 19, 2009 at 4:11 PM, Kevin Fenzi wrote: > On Sat, 19 Dec 2009 17:02:24 +0000 > Jonathan Underwood wrote: > >> Hi, >> >> I kicked off a couple of builds last night which appear stuck on koji. >> I had checked they build locally with a make mockbuild before >> submitting and all was fine. >> >> The builds are: >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 >> http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 >> >> Should I just cancel and resubmit, or? > > I've seen this same thing in some other emacs packages builds. > Something just causes them to get stuck. ;( > There is a -O2 flag issue that causes some builds to hang. Maybe those emacs hangs are related to this bug in gcc It happened to 2 of my packages. Removing -O2 makes things compile in my packages. (No I didn't do official builds without -O2 flag) Someone filed a bug about this a while ago but unfortunately gcc maintainers don't seem to care much. Anything we can do about this? Can we use -O1 instead? The fact is these packages will not compile if there will be a mass rebuild. And this needs to be fixed at some point before F-13 is out. Orcan PS: Some references: https://bugzilla.redhat.com/show_bug.cgi?id=548826 https://bugzilla.redhat.com/show_bug.cgi?id=531218 https://bugzilla.redhat.com/show_bug.cgi?id=538233 https://bugzilla.redhat.com/show_bug.cgi?id=539636 There are a couple more. Just search for gcc+hangs+slow etc. From jgarzik at pobox.com Sat Dec 19 23:02:02 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sat, 19 Dec 2009 18:02:02 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261249017.2271.5.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> Message-ID: <4B2D5B6A.1040602@pobox.com> Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. Jeff From christoph.wickert at googlemail.com Sat Dec 19 23:05:23 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 20 Dec 2009 00:05:23 +0100 Subject: Orphaned some packages In-Reply-To: <1261255491.3341.67.camel@localhost.localdomain> References: <1261255491.3341.67.camel@localhost.localdomain> Message-ID: <1261263923.2573.1.camel@wicktop.localdomain> Am Samstag, den 19.12.2009, 21:44 +0100 schrieb Simon Wesp: > Hi all, > fresh orphaned packages: ... > xpad: Sticky notepad for GTK+2 > Bugs: 0 > https://admin.fedoraproject.org/pkgdb/packages/bugs/xpad I have taken xpad (at least on F11 and F12, package-db wouldn't let me take it on rawhide). Regards, Christoph From mschwendt at gmail.com Sat Dec 19 23:30:02 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 20 Dec 2009 00:30:02 +0100 Subject: Koji stuck? In-Reply-To: References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> Message-ID: <20091220003002.16a17ebe@gmail.com> On Sat, 19 Dec 2009 17:19:37 -0500, Orcan wrote: > On Sat, Dec 19, 2009 at 4:11 PM, Kevin Fenzi wrote: > > On Sat, 19 Dec 2009 17:02:24 +0000 > > Jonathan Underwood wrote: > > > >> Hi, > >> > >> I kicked off a couple of builds last night which appear stuck on koji. > >> I had checked they build locally with a make mockbuild before > >> submitting and all was fine. > >> > >> The builds are: > >> > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 > >> > >> Should I just cancel and resubmit, or? > > > > I've seen this same thing in some other emacs packages builds. > > Something just causes them to get stuck. ;( > > > > There is a -O2 flag issue that causes some builds to hang. Maybe those > emacs hangs are related to this bug in gcc They just seem to hang. > It happened to 2 of my packages. Removing -O2 makes things compile in > my packages. (No I didn't do official builds without -O2 flag) > > Someone filed a bug about this a while ago but unfortunately gcc > maintainers don't seem to care much. There has been activity in bugzilla.redhat.com related to this, however. See e.g. http://bugz.fedoraproject.org/gcc and look for "eternity": http://bugzilla.redhat.com/532763 The temporary work-around is to compile with -fno-var-tracking-assignments and that also works for lv2-c++-tools in the review queue, btw. From tonynelson at georgeanelson.com Sat Dec 19 23:32:30 2009 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sat, 19 Dec 2009 18:32:30 -0500 Subject: Koji stuck? In-Reply-To: (from oget.fedora@gmail.com on Sat Dec 19 17:19:37 2009) Message-ID: <1261265550.12314.1@localhost.localdomain> On 09-12-19 17:19:37, Orcan Ogetbil wrote: ... > There is a -O2 flag issue that causes some builds to hang. Maybe > those emacs hangs are related to this bug in gcc > It happened to 2 of my packages. Removing -O2 makes things compile in > my packages. (No I didn't do official builds without -O2 flag) > > Someone filed a bug about this a while ago but unfortunately gcc > maintainers don't seem to care much. Anything we can do about this? > Can we use -O1 instead? The fact is these packages will not compile > if there will be a mass rebuild. And this needs to be fixed at some > point before F-13 is out. `man gcc` suggests that one can find out the differences between -On levels with: $ gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts $ gcc -c -Q -O1 --help=optimizers > /tmp/O1-opts $ diff /tmp/O{1,2}-opts | grep enabled (and the man page also lists differences). Perhaps only one of the added optimizations is the problem and disabling that one will fix it. A bug report about that particular optimization on a particular file might get better results. I suppose I'd disable half of the added optimizations at a time on a problem file until I found the one that causes the hangs. -- ____________________________________________________________________ TonyN.:' ' From oget.fedora at gmail.com Sun Dec 20 00:40:36 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Sat, 19 Dec 2009 19:40:36 -0500 Subject: Koji stuck? In-Reply-To: <20091220003002.16a17ebe@gmail.com> References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> <20091220003002.16a17ebe@gmail.com> Message-ID: On Sat, Dec 19, 2009 at 6:30 PM, Michael Schwendt wrote: > > The temporary work-around is to compile with > > ?-fno-var-tracking-assignments > > and that also works for lv2-c++-tools in the review queue, btw. > Thanks! Yes, with that flag I was able to finish compiling muse and lv2-c++-tools. Will that break the debuginfo package or anything else? Orcan From maxamillion at gmail.com Sun Dec 20 00:51:46 2009 From: maxamillion at gmail.com (Adam Miller) Date: Sat, 19 Dec 2009 18:51:46 -0600 Subject: Offline Until the New Year! In-Reply-To: <1261210555.2214.14.camel@localhost> References: <1261210555.2214.14.camel@localhost> Message-ID: Safe travels! See you next year. :) -Adam (From Android - CM) On Dec 19, 2009 2:16 AM, "Peter Gordon" wrote: Hi, all. Sincerest apologies for the lack of recent activity and the short notice here, but I'm going to be vacationing with family for the next couple of weeks. I'll return to active Fedora duty on January 2, 2010. Until then, I would very much appreciate others taking care of my packages: https://admin.fedoraproject.org/pkgdb/users/packages/pgordon Thanks very much, and have a great holiday season! :) -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Sun Dec 20 01:04:17 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 19 Dec 2009 17:04:17 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B2D5B6A.1040602@pobox.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <4B2D5B6A.1040602@pobox.com> Message-ID: <248BE678-B24E-4E34-9B3C-985AFFAFB45A@j2solutions.net> On Dec 19, 2009, at 15:02, Jeff Garzik wrote: > > Sorry, if I missed this in previous messages... > > Are the cvs tags going to become git tags, or git branches? When I > checked out ~48 hours ago, it seemed like everything was a git > branch, which is not what I expected for the build tags. > > kernel.org admins recommend either 'git tag -a' or 'git tag -s' > tags, and not plain 'git tag'. > > The cvs tags should become gi tags. If they aren't I'll have to look into it. -- Jes From bruno at wolff.to Sun Dec 20 03:08:17 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 19 Dec 2009 21:08:17 -0600 Subject: Pulseaudio problem with xine, xmms and mplayer In-Reply-To: <1261247618.3375.4.camel@PB3.linux> References: <1261247618.3375.4.camel@PB3.linux> Message-ID: <20091220030817.GA17154@wolff.to> On Sat, Dec 19, 2009 at 18:33:38 +0000, Paul wrote: > > Whenever I try to run xine, xmms or mplayer from the command line, I > keep getting an error from pulseaudio > > Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at > pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. > > It makes no difference if I try to use ogg, mp3 or wav files, they all > fail and die with the same error. > > I'm using pulseaudio-0.9.21-3.fc13 and the > 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel > > PAM fires up and reports all the audio devices are running fine. > > Any ideas? This has been reported as: https://bugzilla.redhat.com/show_bug.cgi?id=548989 It isn't specifically tied to the 2.6.32 kernel, as I am using the 2.6.31 due to problems with the rawhide kernel. From jarod at redhat.com Sun Dec 20 05:07:54 2009 From: jarod at redhat.com (Jarod Wilson) Date: Sun, 20 Dec 2009 00:07:54 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B2CF988.6040007@googlemail.com> References: <1261179109.19834.48.camel@localhost.localdomain> <4B2CF988.6040007@googlemail.com> Message-ID: <4B2DB12A.9030107@redhat.com> On 12/19/09 11:04 AM, Tim Lauridsen wrote: > On 12/19/2009 12:31 AM, Jesse Keating wrote: >> Phase two, write access with ACLs, is ready for testing. Please not >> that URLs have changed since my original announcement. >> >> git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/ >> >> will get you a cone via ssh, in which you can git pull and git push. >> >> The repos are the same from phase1, although I've done a few commits >> here and there to test things. They are not tied to the CVS repos, so >> changes you make here are truly throw away. >> >> Please test cloning and writing to packages and branches of packages >> that you would normally have write access to, or normally would /not/ >> have write access to. I'm interested in seeing both of those cases >> tried. >> >> Thanks again for your help in this project! >> >> > > Checked that I can checkout yumex and commit at change to yumex.spec to > master and F-12 branch. > > Checked hat I can checkout kernel (F-10 and master) and i get a > > W access for kernel DENIED to timlau > fatal: The remote end hung up unexpectedly > > If i try to commit some changes to the kernel.spec > > So it look like it work as expected. Already talked with Jesse about it on irc, but for the benefit of the list, I was able to pull, commit and push changes to the kernel just fine, and was properly denied push on firefox. And man, just 'git diff' performance vs. 'cvs diff' performance almost on its own makes going forward with this change worth it, let alone all the other reasons its so much better... :) -- Jarod Wilson jarod at redhat.com From jarod at redhat.com Sun Dec 20 05:13:29 2009 From: jarod at redhat.com (Jarod Wilson) Date: Sun, 20 Dec 2009 00:13:29 -0500 Subject: FESCo election results December 2009 In-Reply-To: <20091218171947.GF20625@victoria.internal.frields.org> References: <20091218171947.GF20625@victoria.internal.frields.org> Message-ID: <4B2DB279.8050906@redhat.com> On 12/18/09 12:19 PM, Paul W. Frields wrote: > Election Results for FESCo - Fedora 13 Cycle > > Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC > > Nominations: > > * Adam Jackson (ajax) > * Christoph Wickert (cwickert) > * Justin M. Forbes (jforbes) > * Matthew Garrett (mjg59) > * Peter Jones (pjones) > * Richard June (rjune) > * Robert Scheck (rsc) > > Outcomes: > > As defined in the election text, the four (4) candidate(s) with the > greatest number of votes will be elected for full 2 release term. > > Information: > > At close of voting there were: > 216 valid ballots > > Using the Fedora Range Voting method, each candidate could attain a > maximum of 864 votes (4*216). > > Results: > > 1. Adam Jackson (ajax) 1028 > 2. Christoph Wickert (cwickert) 934 > 3. Peter Jones (pjones) 820 > 4. Matthew Garrett (mjg59) 753 > * * * * * > 5. Robert Scheck (rsc) 663 > 6. Justin M. Forbes (jforbes) 535 > 7. Richard June (rjune) 415 > > As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew > Garrett are elected to FESCo for a full 2 release term. As others have said to *me* recently for other reasons... Congrats and condolences to the new FESCo members. ;) -- Jarod Wilson jarod at redhat.com From jgarzik at pobox.com Sun Dec 20 05:25:23 2009 From: jgarzik at pobox.com (Jeff Garzik) Date: Sun, 20 Dec 2009 00:25:23 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <248BE678-B24E-4E34-9B3C-985AFFAFB45A@j2solutions.net> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <4B2D5B6A.1040602@pobox.com> <248BE678-B24E-4E34-9B3C-985AFFAFB45A@j2solutions.net> Message-ID: <4B2DB543.8000600@pobox.com> On 12/19/2009 08:04 PM, Jesse Keating wrote: > > > On Dec 19, 2009, at 15:02, Jeff Garzik wrote: > >> >> Sorry, if I missed this in previous messages... >> >> Are the cvs tags going to become git tags, or git branches? When I >> checked out ~48 hours ago, it seemed like everything was a git branch, >> which is not what I expected for the build tags. >> >> kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, >> and not plain 'git tag'. >> >> > > The cvs tags should become gi tags. If they aren't I'll have to look > into it. Yep, current pull looks fine that way. Everything is git tags, with zero git branches. Jeff From ry at n.rix.si Sun Dec 20 05:58:26 2009 From: ry at n.rix.si (Ryan Rix) Date: Sat, 19 Dec 2009 22:58:26 -0700 Subject: Pyclutter Timelines -- what am I missing? Message-ID: <200912192258.32177.ry@n.rix.si> Hello everyone, I am trying to use Pyclutter to get a nice working interface for Fedora-tour since standard pygtk doesn't really fit the needs for the dynamic user interface we want to create. Unfortunately, the code I'm trying to use to create a Timeline doesn't work, and the documentation on pyclutter seems to be fairly sparse. self.timeline = clutter.Timeline() self.timeline.set_duration(500) self.timeline.set_speed(20) This should create a working timeline according to [1] but it doesn't, with python complaining about the set_duration method and, I'd assume, the set_speed method. The constructor for the Timeline should support setting these, but that also dies horribly... Could someone with some expertise in pyclutter give me a helping hand with this code? [1]: http://www.clutter-project.org/docs/pyclutter/0.9/class- cluttertimeline.html Ryan Rix -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Sun Dec 20 06:08:45 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 19 Dec 2009 22:08:45 -0800 Subject: Create a -cli package without a different executable In-Reply-To: <1261172358.7053.12.camel@localhost.localdomain> References: <20091218181227.2f6da87e@gmail.com> <1261172358.7053.12.camel@localhost.localdomain> Message-ID: <20091220060845.GC18018@clingman.lan> On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote: > Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien: > > Hi, > > > > I'm packaging phatch that provides /usr/bin/phatch, a graphical > > application to manage some operations on photos. It handles command > > line parameters so that it can be used in a script, without a GUI : > > if no parameters are given, a GUI is displayed, otherwise it acts as a > > console application. > > > > Upstream asked me if it's possible to keep "phatch" package, containing > > the graphical requirements (and requires) and requires phatch-cli, and > > create a phatch-cli, that provides /usr/bin/phatch. With this way, > > people could just install phatch-cli on a server and use it with > > command line parameters (but it would crash if it's not launched with > > parameters). > > > > My question is : > > is it good to provide a -cli package that does not provides a separate > > script or executable file, and that will work only if the user is > > carefull to not launch it in a way that it does not require a graphic > > lib (without parameters in that context) ? > > Sounds like the goal is good but the implementation is not. > > > I see phatch is a python package, so I think a little trick could be > possible: > > %package cli: > BuildRequires: python-devel > Requires: non-gui-dependencies > %files > {_bindir}/phatch > > and for the main package: > Requires: phatch-cli > Requires: pygtk2, > [install desktop file etc...] > > > This way users could explicitly install phatch-cli, and it would "only" > not start up properly if called without arguments on a terminal, and the > main package (gui version) would contain the program and pull in the > graphical dependencies. > I don't know the program though, and if the cli version depends on gui > libraries to work properly as well it wouldn't work. This is not ideal but it needs some coding to come up with something better. Possibilities: * phatch with no options can attempt to import a gui lib. If that succeeds it launches the graphical interface. If it does not succeed, it displays the usage/help message. * phatch is a command line app. When invoked as gphatch it starts as a gui app instead. The phatch-gui subpackage installs a symlink from /usr/bin/gpatch to /usr/bin/phatch as well as .desktop files. Basically, it's great to have the option to get the functionality of the program without having to install the GUI environment. But the program tracebacking when the GUI environment is not present and the user typed the command name without options is not good behaviour for a program. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Dec 20 08:46:55 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 20 Dec 2009 09:46:55 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > We definitely want to allow topic branches pushed to the main repo. I > think we'll have to agree on a namespace to use for these, perhaps > following the dist-cvs example and call them private-* What about build branches? Let's say you have these committed to the F-12 branch: foo-1.0-1.fc12 foo-1.0-2.fc12 foo-1.0-3.fc12 foo-1.1-1.fc12 foo-1.1-2.fc12 Now you see 1.1 is not ready to be queued as a Bodhi update yet (you may or may not have it built for dist-f12-updates-candidate, it doesn't matter), so you'd like to branch from foo-1.0-3.fc12 and create these: foo-1.0-3.fc12.1 foo-1.0-3.fc12.2 ? or maybe these: foo-1.0-4.fc12 foo-1.0-5.fc12 ? Either way, you want to branch from an old revision, create new ones in the branch, and, what's different from a private topic branch, build the packages from the branch for dist-f12-updates-candidate and eventually queue them in Bodhi. What's the best way to handle this? Right now, in CVS, you can create a CVS branch within the F-12 branch as long as you manage to create a branch name which passes validation and build from there. (AFAIK, private-* branches can be abused for builds, and it's also possible to create branches with names which look like build tags, which also get through validation.) Kevin Kofler From kevin.kofler at chello.at Sun Dec 20 08:48:09 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 20 Dec 2009 09:48:09 +0100 Subject: Koji stuck? References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> <20091220003002.16a17ebe@gmail.com> Message-ID: Michael Schwendt wrote: > The temporary work-around is to compile with > > -fno-var-tracking-assignments We also need that for some of our KDE packages. GCC really needs to get fixed! Kevin Kofler From hun at n-dimensional.de Sun Dec 20 09:28:16 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 20 Dec 2009 10:28:16 +0100 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261249017.2271.5.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> Message-ID: <20091220102816.658487f6@n-dimensional.de> On Sat, 19 Dec 2009 10:56:57 -0800 Jesse Keating wrote: > We definitely want to allow topic branches pushed to the main repo. I > think we'll have to agree on a namespace to use for these, perhaps > following the dist-cvs example and call them private-* private/* would have the advantage of allowing easier branch name wildcards in git ("git push origin 'private/*'"). OTOH, branch or tag names with slashes in them have the potential to confuse tools and people. > The way the ACL system works is that it matches on the refs you're > pushing up, so for packages that have per-branch ACLs only the refs > that match the branch have ACLs on them, and the assumption is that > without an ACL you have no rights to it. That's likely why your push > failed, but I'd like to see the message to confirm. It shouldn't be > too hard to tweak the ACL creation script to add W access to anybody > who has W access already to the private-* namespace. Currently, it appears that I can push arbitrarily named branches, at least if the package does not have per branch ACLs: $ git push origin moo private/moo private-moo Counting objects: 11, done. Delta compression using 2 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 759 bytes, done. Total 9 (delta 8), reused 0 (delta 0) To ssh://ndim at pkgs.stg.fedoraproject.org/cstream * [new branch] moo -> moo * [new branch] private/moo -> private/moo * [new branch] private-moo -> private-moo $ And the same happens with (non-signed, non-annotated) tags: $ git push origin meh private/meh private-meh Total 0 (delta 0), reused 0 (delta 0) To ssh://ndim at pkgs.stg.fedoraproject.org/cstream * [new tag] meh -> meh * [new tag] private/meh -> private/meh * [new tag] private-meh -> private-meh $ I guess even without per branch ACLs, the ACL system should take a look at what I am actually pushing and verify its tag/branch names match some kind of wildcard whitelist. For tags, it might also check their type (annotated, signed). -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mschwendt at gmail.com Sun Dec 20 10:23:06 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 20 Dec 2009 11:23:06 +0100 Subject: Koji stuck? In-Reply-To: References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> <20091220003002.16a17ebe@gmail.com> Message-ID: <20091220112306.33b8ea34@gmail.com> On Sat, 19 Dec 2009 19:40:36 -0500, Orcan wrote: > On Sat, Dec 19, 2009 at 6:30 PM, Michael Schwendt wrote: > > > > The temporary work-around is to compile with > > > > ?-fno-var-tracking-assignments > > > > and that also works for lv2-c++-tools in the review queue, btw. > > > > Thanks! Yes, with that flag I was able to finish compiling muse and > lv2-c++-tools. Will that break the debuginfo package or anything else? Well, it switches something off that is supposed to be an attempt at improving debug information when using optimisations. How important (read "how successful in practice") this feature is, I don't know, and I could rather quit writing this mail and delete it instead. ;) [Our default %optflags are just a compromise with regard to debug information anyway.] From jonathan.underwood at gmail.com Sun Dec 20 10:40:44 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 20 Dec 2009 10:40:44 +0000 Subject: Koji stuck? In-Reply-To: <20091219141142.1624c977@ohm.scrye.com> References: <645d17210912190902i774dbc5asdcc5932e9d8619ff@mail.gmail.com> <20091219141142.1624c977@ohm.scrye.com> Message-ID: <645d17210912200240m6d8965b8u3fb6522f47435fbe@mail.gmail.com> 2009/12/19 Kevin Fenzi : > I've seen this same thing in some other emacs packages builds. > Something just causes them to get stuck. ;( > > I guess I would say try canceling and re-submitting, if that doesn't > work, try a local mock and see if you can see where it's getting stuck. Well, strangely, I did a mockbuild locally before dropping the job into koji and it completed fine. I see later posts refer to a gcc problem, so I'll try playing with those - I think I'll need to rebuild emacs locally as well though with different debug options to really get to the bottom of it. J From rawhide at fedoraproject.org Sun Dec 20 12:46:19 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 20 Dec 2009 12:46:19 +0000 Subject: rawhide report: 20091220 changes Message-ID: <20091220124619.GA6089@releng2.fedora.phx.redhat.com> Compose started at Sun Dec 20 08:15:04 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tokyotyrant-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.x86_64 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tokyotyrant-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package php-ezc-EventLogDatabaseTiein Contains the database writer backend for the EventLog component Updated Packages: EMBOSS-6.1.0-6.fc13 ------------------- * Sun Dec 13 2009 Julian Sikorski - 6.1.0-6 - Added the upstream 1-3 patch - Fixed bogus Patch3 description - Jemboss is still disabled, but some improvements have been made - Backported patch enabling jemboss rebuild from CVS - Added ant and jpackage-utils to BuildRequires - Made java-devel dependency versioned - Switched to build-jar-repository to fill the dependencies - Replaced versioned log4j calls with latest version - Renamed EMBOSS-java to jemboss - Added a desktop entry for jemboss from Debian asterisk-1.6.2.0-1.fc13 ----------------------- * Sat Dec 19 2009 Jeffrey C. Ollie - 1.6.2.0-1 - Released version of 1.6.2.0 audacious-plugins-2.2-3.fc13 ---------------------------- * Sat Dec 19 2009 Michael Schwendt - 2.2-3 - Beat bluetooth plugin a bit. - Fix missing aud_cfg_db_close calls. - Avoid that neon's ne_request_destroy() is called with a NULL ptr. ccache-2.4-17.fc13 ------------------ * Sat Dec 19 2009 Ville Skytt? - 2.4-17 - Minor profile.d script performance improvements. - Fix hardcoded /var/cache/ccache in profile.d scripts. coreutils-8.2-4.fc13 -------------------- * Sat Dec 19 2009 Ondrej Vasik - 8.2-4 - bring back uname -p/-i functionality except of the athlon hack(#548834) - comment patches cups-1.4.2-18.fc13 ------------------ * Sat Dec 19 2009 Tim Waugh - 1:1.4.2-18 - Fixed patch for STR #3425 by adding in back-ported change from svn revision 8936 (bug #548904). fet-5.12.0-1.fc13 ----------------- * Fri Dec 18 2009 Fabian Affolter - 5.12.0-1 - Some doc files removed - Updated to new upstream version 5.12.0 flexdock-0.5.1-17.fc13 ---------------------- * Sat Dec 19 2009 0.5.1-15 - Fix patch to match sed expression - Don't modify jni patch in-place * Sat Dec 19 2009 0.5.1-16 - tag bump * Sat Dec 19 2009 0.5.1-17 - tag bump geos-3.2.0-1.fc13 ----------------- * Sun Dec 20 2009 Devrim GUNDUZ - 3.2.0-1 - Update to 3.2.0 gtk+extra-2.1.1-13.fc13 ----------------------- * Sun Dec 20 2009 Roy Rankin - 2.1.1-13 - Fix crash issue with gtk2-2.18 BZ 546648 jack-keyboard-2.5-5.fc13 ------------------------ * Sat Dec 19 2009 Orcan Ogetbil - 2.5-5 - Add dvorak keyboard support kdebindings-4.3.85-2.fc13 ------------------------- * Sat Dec 19 2009 Kevin Kofler - 4.3.85-2 - fix NepomukSmoke not getting built, breaking the Ruby and C# bindings - fix its build (missing #include ) - fix phpqt_internals.cpp for the current smoke.h - Qyoto/Kimono DLLs are now in mono/qyoto rather than mono/2.0 * Fri Dec 18 2009 Rex Dieter - 4.3.85-1 - kde-4.3.85 (4.4beta2) kdelibs-4.3.85-4.fc13 --------------------- * Sat Dec 19 2009 Rex Dieter - 4.3.85-4 - tarball respin kvirc-4.0.0-0.20.rc2.fc13 ------------------------- * Sat Dec 19 2009 Alexey Kurov - 4.0.0-0.20.rc2 - KVIrc 4.0 release candidate 2 - added BR cryptopp-devel and -DWANT_NO_EMBEDDED_CODE=ON - re-enabled pyhton module -DWITHOUT_PYTHON=OFF - added BR python-devel lxmusic-0.4.1-1.fc13 -------------------- * Sun Dec 20 2009 Christoph Wickert - 0.4.1-1 - New upstream release to fix #539729, so we drop the patches mr-0.46-1.fc13 -------------- * Fri Dec 18 2009 Fabian Affolter - 0.46-1 - Updated to new upstream version 0.46 nss-3.12.5-1.fc13.9 ------------------- * Sat Dec 19 2009 Elio maldonado - 3.12.5-1.9 - Remove left over trace statements from nsssysinit patching openbox-3.4.9-1.fc13 -------------------- * Sat Dec 19 2009 Miroslav Lichvar - 3.4.9-1 - Update to 3.4.9 php-ezc-DatabaseSchema-1.4.3-1.fc13 ----------------------------------- * Sat Dec 12 2009 Guillaume Kulakowski - 1.4.3-1 - Update to 1.4.3 pyparted-2.5-2.fc13 ------------------- * Sat Dec 19 2009 David Cantrell - 2.5-1 - Update release instructions. (dcantrell) - Remove old cylinder alignment test cases for _ped. (dcantrell) - Add tests for max partition length / start sector (hdegoede) - Add _pedmodule and parted functions for max partition length / start sector (hdegoede) - Remove align_to_cylinders function bindings (hdegoede) - Add tests for disk flag methods (hdegoede) - Add _pedmodule and parted functions for per disk flags (hdegoede) - Every tuple member requires a comma after it. (dcantrell) - Fill out a lot of simple _ped.Disk test cases. (dcantrell) - Disable DeviceDestroyTestCase for now. (dcantrell) - Add RequiresLabeledDevice to tests/_ped/baseclass.py. (dcantrell) - Attempt at fixing _ped.Device.destroy(), no dice. (dcantrell) - Fix UnitFormatCustomTestCase and UnitFormatTestCase. (dcantrell) - Fix UnitFormatCustomByteTestCase and UnitFormatByteTestCase. (dcantrell) - Add DeviceStrTestCase, disable DeviceDestroyTestCase. (dcantrell) - Add DeviceDestroyTestCase and DeviceCacheRemoveTestCase. (dcantrell) - Implemented ConstraintIsSolutionTestCase(). (dcantrell) - Implement ConstraintSolveMaxTestCase(). (dcantrell) - Implement ConstraintSolveNearestTestCase(). (dcantrell) - Correct py_ped_file_system_probe_specific() for NULL returns. (dcantrell) - Implement FileSystemProbeSpecificTestCase(). (dcantrell) - Implement FileSystemProbeTestCase(). (dcantrell) - Add RequiresFileSystem to tests/_ped/baseclass.py. (dcantrell) - Add disk alignment test cases in test_ped.py. (dcantrell) - Fix CHSGeometryStrTestCase(). (dcantrell) - Fix ConstraintDuplicateTestCase...finally. (dcantrell) - Put a deprecation warning in py_ped_constraint_duplicate(). (dcantrell) - Note that we need parted from Fedora for pyparted. (dcantrell) - Fix UnitGetSizeTestCase in _ped test cases for _ped.UNIT_PERCENT. (dcantrell) - Add testcase for new _ped disk get_partition_alignment method (hdegoede) * Sat Dec 19 2009 David Cantrell - 2.5-2 - Exclude pyparted-2.4.tar.gz from source RPM (oops) pysnmp-4.1.12-1.a.fc13 ---------------------- * Fri Dec 18 2009 Fabian Affolter - 4.1.12-1.a - Updated to new upstream version 4.1.12.a towhee-6.2.7-1.fc13 ------------------- * Sat Dec 19 2009 Jussi Lehtola - 6.2.7-1 - Adopt MPI guidelines, fixing FTBFS in rawhide. unixODBC-2.2.14-9.fc13 ---------------------- * Sat Dec 19 2009 Tom Lane 2.2.14-9 - Fix bug preventing drivers from being selected in ODBCConfig Resolves: #544852 wine-1.1.35-1.fc13 ------------------ * Sat Dec 19 2009 Andreas Bierfert - 1.1.35-1 - version upgrade * Fri Dec 18 2009 Andreas Bierfert - 1.1.34-1 - version upgrade (#546749) * Mon Nov 16 2009 Andreas Bierfert - 1.1.33-1 - version upgrade - winepulse update (.33) - require gnutls (#538694) - use separate WINEPREFIX on x86_64 per default (workaround for #533806) - drop explicit xmessage require (#537610) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 24 From promac at gmail.com Sun Dec 20 12:56:23 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 20 Dec 2009 10:56:23 -0200 Subject: v4l applications In-Reply-To: <68720af30912111135s4f3ad9ecr6621fa568e6e6346@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <68720af30912111135s4f3ad9ecr6621fa568e6e6346@mail.gmail.com> Message-ID: <68720af30912200456u30734618u124caeb006a75884@mail.gmail.com> On Fri, Dec 11, 2009 at 5:35 PM, Paulo Cavalcanti wrote: > > > On Sun, Dec 6, 2009 at 1:53 PM, Nicolas Chauvet wrote: > >> 2009/12/5 Paulo Cavalcanti : >> > There are some old v4l applications that do not work in Fedora 12. >> > >> > I found so far fmtools and gnomeradio. >> I will have a look on fmtools in ew days, but until then, patches >> welcomed. >> >> > The current fmtools developer, Ben Pfaff, told me he would send me a patch > soon. I will test it and then forward it to you. > > > Well, Ben Pfaff sent me a new version, and I have a src.rpm here: http://orion.lcg.ufrj.br/RPMS/src/fmtools-2.0-2.fc12.src.rpm http://orion.lcg.ufrj.br/RPMS/SPECS/fmtools.spec I also rewrote the spec file for including tkradio, a tcl/tk wrapper for fmtools. In my case, I need to call /usr/bin/v4lctl -c /dev/radio0 volume mute off to unmute my radio (v4ctl is from xawtv). I reported this issue to Ben Pfaff, but at least fmtools is up again. If someone with a different capture card could test this new version, it would be great. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mzerqung at 0pointer.de Sun Dec 20 13:33:33 2009 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 20 Dec 2009 14:33:33 +0100 Subject: Pulseaudio problem with xine, xmms and mplayer In-Reply-To: <1261247618.3375.4.camel@PB3.linux> References: <1261247618.3375.4.camel@PB3.linux> Message-ID: <20091220133332.GA16451@tango.0pointer.de> On Sat, 19.12.09 18:33, Paul (paul at all-the-johnsons.co.uk) wrote: > Hi, Heya, > Whenever I try to run xine, xmms or mplayer from the command line, I > keep getting an error from pulseaudio > > Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at > pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. > > It makes no difference if I try to use ogg, mp3 or wav files, they all > fail and die with the same error. > > I'm using pulseaudio-0.9.21-3.fc13 and the > 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel > > PAM fires up and reports all the audio devices are running fine. > > Any ideas? Yes. Firstly, next time please report bugs to bugzilla, that's why we have it. https://bugzilla.redhat.com/show_bug.cgi?id=548989 Secondly, this is not a PA problem. The RT folks broke PI mutexes again, this is a kernel/glibc problem. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From kwizart at gmail.com Sun Dec 20 15:36:26 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Sun, 20 Dec 2009 16:36:26 +0100 Subject: v4l applications In-Reply-To: <68720af30912200456u30734618u124caeb006a75884@mail.gmail.com> References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <68720af30912111135s4f3ad9ecr6621fa568e6e6346@mail.gmail.com> <68720af30912200456u30734618u124caeb006a75884@mail.gmail.com> Message-ID: 2009/12/20 Paulo Cavalcanti : > > > On Fri, Dec 11, 2009 at 5:35 PM, Paulo Cavalcanti wrote: >> >> >> On Sun, Dec 6, 2009 at 1:53 PM, Nicolas Chauvet wrote: >>> >>> 2009/12/5 Paulo Cavalcanti : >>> > There are some old v4l applications that do not work in Fedora 12. >>> > >>> > I found so far fmtools and gnomeradio. >>> I will have a look on fmtools in ew days, but until then, patches >>> welcomed. >>> >> >> The current fmtools developer, Ben Pfaff, told me he would send me a patch >> soon. I will test it and then forward it to you. >> > > > Well, Ben Pfaff sent me a new version, and I have a src.rpm here: > > http://orion.lcg.ufrj.br/RPMS/src/fmtools-2.0-2.fc12.src.rpm > > http://orion.lcg.ufrj.br/RPMS/SPECS/fmtools.spec > > I also rewrote the spec file for including tkradio, a tcl/tk wrapper for > fmtools. > > In my case, I need to call > > ?/usr/bin/v4lctl -c /dev/radio0 volume mute off > > to unmute my radio (v4ctl is from xawtv). > > I reported this issue to Ben Pfaff, but at least fmtools is up again. > > If someone with a different capture card could test this new version, > it would be great. > > Thanks. Hi Paula, and thx for your work, Have you made a cvs request, so you can commit the spec directly? Once that said there are few things I dislike in your src.rpm: - The original source code of fmtools-2.0 doesn't seems present. (same problem as fmcontrol), but I expect it to be present when the release will be made official. - You don't install with -p - the desktop file could be bundled within the original source code and : X-Desktop-File-Install-Version=0.15 should only be added by desktop-file-install on %install - Requires: tk seems a big dependency for a simple cmd line tool as fmtools, Can you sub-package tkradio ? (or submit another package for it ?) - You haven't keept the changelog from the fedora package, Can you rebase on it ? Thx From promac at gmail.com Sun Dec 20 17:29:30 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Sun, 20 Dec 2009 15:29:30 -0200 Subject: v4l applications In-Reply-To: References: <68720af30912050648m546613fap3a5fd6476a7b7334@mail.gmail.com> <68720af30912111135s4f3ad9ecr6621fa568e6e6346@mail.gmail.com> <68720af30912200456u30734618u124caeb006a75884@mail.gmail.com> Message-ID: <68720af30912200929s29bf317fsce9de4735849006e@mail.gmail.com> Have you made a cvs request, so you can commit the spec directly? > Not yet. > > Once that said there are few things I dislike in your src.rpm: > - The original source code of fmtools-2.0 doesn't seems present. > It is not on the site yet. > (same problem as fmcontrol), fmcontrol just has a dead link on fmtools site. > but I expect it to be present when the > release will be made official. > > - You don't install with -p > Fixed. > - the desktop file could be bundled within the original source code and : > X-Desktop-File-Install-Version=0.15 should only be added by > desktop-file-install on %install > - Requires: tk seems a big dependency for a simple cmd line tool as > fmtools, Can you sub-package tkradio ? (or submit another package for > it ?) > I created fmtools-tkradio, a noarch subpackage. > - You haven't keept the changelog from the fedora package, Can you > rebase on it ? > The changelog is back. http://orion.lcg.ufrj.br/RPMS/SPECS/fmtools.spec http://orion.lcg.ufrj.br/RPMS/src/fmtools-2.0-3.fc12.src.rpm -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at all-the-johnsons.co.uk Sun Dec 20 19:42:26 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 20 Dec 2009 19:42:26 +0000 Subject: Pulseaudio problem with xine, xmms and mplayer In-Reply-To: <20091220133332.GA16451@tango.0pointer.de> References: <1261247618.3375.4.camel@PB3.linux> <20091220133332.GA16451@tango.0pointer.de> Message-ID: <1261338146.1494.0.camel@PB3.linux> Hi, > > Any ideas? > > Yes. > > Firstly, next time please report bugs to bugzilla, that's why we have > it. https://bugzilla.redhat.com/show_bug.cgi?id=548989 > > Secondly, this is not a PA problem. The RT folks broke PI mutexes > again, this is a kernel/glibc problem. Soooo, don't ask if anyone else has seen it or report it under the wrong application then? Sounds like a cunning plan to me... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Sun Dec 20 20:11:42 2009 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 20 Dec 2009 15:11:42 -0500 Subject: upstart-0.6.3 in rawhide, tomorrow 2009-12-10 In-Reply-To: <20091216211615.GD21037@nostromo.devel.redhat.com> References: <20091209224610.GA20658@nostromo.devel.redhat.com> <20091210203228.GA13743@nostromo.devel.redhat.com> <20091216160648.GA19999@jadzia.bu.edu> <20091216162331.GB16206@nostromo.devel.redhat.com> <20091216193534.GA2220@jadzia.bu.edu> <20091216211615.GD21037@nostromo.devel.redhat.com> Message-ID: <20091220201142.GA22976@jadzia.bu.edu> On Wed, Dec 16, 2009 at 04:16:15PM -0500, Bill Nottingham wrote: > > > Given how it's implemented, you could do something truly disgusting like > > > ACTIVE_CONSOLES=$([ "$RUNLEVEL" = 3 ] && echo '/dev/tty[1-6]' || echo '/dev/tty2') > > > I'm not sure I really want to *support* people doing that, though. > > You mean, you don't like the idea of having different numbers of consoles > > running in different runlevels, or you don't like the > > abusing-shell-script-as-config-file thing? > The latter. :) Cool, then. :) -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs / Instructional & Research Computing Computing & Information Technology Harvard School of Engineering & Applied Sciences From ry at n.rix.si Mon Dec 21 00:13:09 2009 From: ry at n.rix.si (Ryan Rix) Date: Sun, 20 Dec 2009 17:13:09 -0700 Subject: Pyclutter Timelines -- what am I missing? In-Reply-To: <200912192258.32177.ry@n.rix.si> References: <200912192258.32177.ry@n.rix.si> Message-ID: <200912201713.15765.ry@n.rix.si> On Sat 19 December 2009 10:58:26 pm you wrote: > Hello everyone, > > I am trying to use Pyclutter to get a nice working interface for > Fedora-tour since standard pygtk doesn't really fit the needs for the > dynamic user interface we want to create. > > Unfortunately, the code I'm trying to use to create a Timeline doesn't > work, and the documentation on pyclutter seems to be fairly sparse. > Alright, so I dropped the timeline for now, working to get a simple UI to at least show up, without the timeline support; now I have a segfault (wonderful!) in the _clutter.so which pyclutter calls. I'm not sure how to get a useful backtrace out of this from python code, unfortunately. What follows is my code: window is created in the method that calls this constructor, it's a fresh window with only window.show() called on it. def __init__(self,window): pdb.set_trace() self.window = window self.window.set_decorated(False) self.window.resize(400,200) self.window.set_position(gtk.WIN_POS_CENTER_ALWAYS) embed = cluttergtk.Embed() fedoraLogoActor = clutter.Texture("../data/fedora-tour-splash.svg") self.window.add(embed) embed.realize() embed.set_size_request(400,200) stage = embed.get_stage() stage.add(fedoraLogoActor) self.window.show_all() gtk.main() the pdb trace tells me that the segfault occurs at self.window.show_all()... Any ideas/guidance would be MUCH appreciated :) thanks Ryan -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bojan at rexursive.com Mon Dec 21 00:33:23 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 21 Dec 2009 11:33:23 +1100 Subject: Kernel security update required or not? Message-ID: <1261355603.1981.3.camel@shrek.rexursive.com> According to this: http://lwn.net/Articles/367443/, latest kernel updates have security fixes (the second one appears on the 2.6.31.9 list). Is this something that has been backported to current F-12 kernels (I don't see it in changelog), or do we need a security update for F-12 here? -- Bojan From bruno at wolff.to Mon Dec 21 01:16:42 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 20 Dec 2009 19:16:42 -0600 Subject: Kernel security update required or not? In-Reply-To: <1261355603.1981.3.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> Message-ID: <20091221011642.GA1288@wolff.to> On Mon, Dec 21, 2009 at 11:33:23 +1100, Bojan Smojver wrote: > According to this: http://lwn.net/Articles/367443/, latest kernel > updates have security fixes (the second one appears on the 2.6.31.9 > list). > > Is this something that has been backported to current F-12 kernels (I > don't see it in changelog), or do we need a security update for F-12 > here? There is a 2.6.31.9 build in Koji. From ry at n.rix.si Mon Dec 21 01:29:13 2009 From: ry at n.rix.si (Ryan Rix) Date: Sun, 20 Dec 2009 18:29:13 -0700 Subject: Pyclutter Timelines -- what am I missing? In-Reply-To: <200912201713.15765.ry@n.rix.si> References: <200912192258.32177.ry@n.rix.si> <200912201713.15765.ry@n.rix.si> Message-ID: <200912201829.23202.ry@n.rix.si> On Sun 20 December 2009 5:13:09 pm Ryan Rix wrote: > Alright, so I dropped the timeline for now, working to get a simple UI to > at least show up, without the timeline support; now I have a segfault > (wonderful!) in the _clutter.so which pyclutter calls. I'm not sure how to > get a useful backtrace out of this from python code, unfortunately. > I ran it as root to try to get at least some core dump out of it, and it runs flawlessly... :/ Not sure exactly why this is, does anyone have an idea? -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bojan at rexursive.com Mon Dec 21 01:34:06 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 21 Dec 2009 12:34:06 +1100 Subject: Kernel security update required or not? In-Reply-To: <20091221011642.GA1288@wolff.to> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> Message-ID: <1261359246.1981.5.camel@shrek.rexursive.com> On Sun, 2009-12-20 at 19:16 -0600, Bruno Wolff III wrote: > There is a 2.6.31.9 build in Koji. Yeah, I've seen it. But, it's not in updates. Hence the question. -- Bojan From lists at sapience.com Mon Dec 21 02:17:46 2009 From: lists at sapience.com (Mail Lists) Date: Sun, 20 Dec 2009 21:17:46 -0500 Subject: Kernel security update required or not? In-Reply-To: <1261359246.1981.5.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> Message-ID: <4B2EDACA.5060309@sapience.com> On 12/20/2009 08:34 PM, Bojan Smojver wrote: > On Sun, 2009-12-20 at 19:16 -0600, Bruno Wolff III wrote: >> There is a 2.6.31.9 build in Koji. > > Yeah, I've seen it. But, it's not in updates. Hence the question. > Sure wish 2.6.32 would come soon ... anyone know when ? From ry at n.rix.si Mon Dec 21 02:24:08 2009 From: ry at n.rix.si (Ryan Rix) Date: Sun, 20 Dec 2009 19:24:08 -0700 Subject: Pyclutter Timelines -- what am I missing? [SOLVED] In-Reply-To: <200912201829.23202.ry@n.rix.si> References: <200912192258.32177.ry@n.rix.si> <200912201713.15765.ry@n.rix.si> <200912201829.23202.ry@n.rix.si> Message-ID: <200912201924.13281.ry@n.rix.si> On Sun 20 December 2009 6:29:13 pm Ryan Rix wrote: > On Sun 20 December 2009 5:13:09 pm Ryan Rix wrote: > > Alright, so I dropped the timeline for now, working to get a simple UI to > > at least show up, without the timeline support; now I have a segfault > > (wonderful!) in the _clutter.so which pyclutter calls. I'm not sure how > > to get a useful backtrace out of this from python code, unfortunately. > > I ran it as root to try to get at least some core dump out of it, and it > runs flawlessly... :/ Not sure exactly why this is, does anyone have an > idea? > Go figure, a reboot solved things... *clueless* oh well -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Mon Dec 21 03:11:11 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 20 Dec 2009 22:11:11 -0500 Subject: mono and snk key files In-Reply-To: <364d303b0912190803r30a86869j794a269ac117fff6@mail.gmail.com> References: <4B1297E5.1030207@smartlink.ee> <364d303b0911290829j2b7ebe58uff8a3cc8e524a136@mail.gmail.com> <4B227781.7080409@spicenitz.org> <364d303b0912130316g3b64c40ex49c9572bf8bcc4ea@mail.gmail.com> <4B26DC37.2090008@spicenitz.org> <364d303b0912190803r30a86869j794a269ac117fff6@mail.gmail.com> Message-ID: <4B2EE74F.3000006@redhat.com> On 12/19/2009 11:03 AM, Christopher Brown wrote: > 2009/12/15 Adam Goode : >> On 12/13/2009 06:16 AM, Christopher Brown wrote: >>> 2009/12/11 Adam Goode : >>>> We should definitely use Debian's key, right? Otherwise some Fedora CLI >>>> libraries would be unnecessarily incompatible with Debian, and whoever >>>> else uses Debian's key. >>>> >>>> The whole business of not shipping code-signing keys is a little >>>> contrary to open source. I think this is something that GPLv3 would >>>> prohibit. We should use a single well-known signing key for any package >>>> that we don't have the keys for, I think. >>> >>> You're right. >>> >>> This has already been resolved in devel by added mono.snk to the >>> mono-devel package. I'm just waiting on commit access to make the >>> required changes to F-11 and F-12 unless someone else wants to do it. >>> >> >> It looks like spot generated a new mono.snk. I was arguing to use >> Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone >> should use Debian's key unless a package provides its own? > > Ideally we (Fedora and Debian) should use a single key generated by > upstream but as this issue is only problematic due to cyclic dep > problems in the build process I think that using our own is enough. > Unfortunately I don't care enough to chase this issue further. Yeah, I think there is very little merit in giving any amount of trust to that key, nor is there any real value in picking up mono bits built for Debian and putting them on Fedora and expecting them to work (or vice versa). ~spot From jkeating at redhat.com Mon Dec 21 03:30:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Dec 2009 19:30:35 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> Message-ID: <1261366235.2271.11.camel@localhost.localdomain> On Sun, 2009-12-20 at 09:46 +0100, Kevin Kofler wrote: > Either way, you want to branch from an old revision, create new ones in the > branch, and, what's different from a private topic branch, build the > packages from the branch for dist-f12-updates-candidate and eventually queue > them in Bodhi. > > What's the best way to handle this? > > Right now, in CVS, you can create a CVS branch within the F-12 branch as > long as you manage to create a branch name which passes validation and build > from there. (AFAIK, private-* branches can be abused for builds, and it's > also possible to create branches with names which look like build tags, > which also get through validation.) > I'm not a real fan of allowing official builds to happen from branches like this. I'm ok with them being created and shared for various topics, but the official builds should come from origin/master or origin/F-?? Coming up with namespaces that we allow for shared repo branches will be a discussion to have. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Dec 21 03:31:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Dec 2009 19:31:30 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091220102816.658487f6@n-dimensional.de> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> Message-ID: <1261366290.2271.12.camel@localhost.localdomain> On Sun, 2009-12-20 at 10:28 +0100, Hans Ulrich Niedermann wrote: > Currently, it appears that I can push arbitrarily named branches, at > least if the package does not have per branch ACLs: > Yes, that makes sense given the way the ACL system works, it just wasn't fully expected by me. A small change to the ACL generation script will make sure that this sort of loophole is closed. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon Dec 21 04:06:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 21 Dec 2009 05:06:21 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <1261366235.2271.11.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > I'm not a real fan of allowing official builds to happen from branches > like this. So what do you suggest doing in such a case? Temporarily reverting the F-n branch to the old release, build, then bump it up again? This sounds really suboptimal to me (in addition to being a regression from our current CVS setup, which does allow creating such branches)! Branching is really part of what VCSs are for. Kevin Kofler From bruno at wolff.to Mon Dec 21 04:16:35 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 20 Dec 2009 22:16:35 -0600 Subject: Kernel security update required or not? In-Reply-To: <4B2EDACA.5060309@sapience.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <4B2EDACA.5060309@sapience.com> Message-ID: <20091221041635.GA22789@wolff.to> On Sun, Dec 20, 2009 at 21:17:46 -0500, Mail Lists wrote: > On 12/20/2009 08:34 PM, Bojan Smojver wrote: > > On Sun, 2009-12-20 at 19:16 -0600, Bruno Wolff III wrote: > >> There is a 2.6.31.9 build in Koji. > > > > Yeah, I've seen it. But, it's not in updates. Hence the question. > > > > Sure wish 2.6.32 would come soon ... anyone know when ? Be careful what you wish for. 2.6.32 isn't working for me. I have to use 2.6.31 kernels from F12 on my otherwise rawhide system, to get it to boot. From bruno at wolff.to Mon Dec 21 04:21:32 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 20 Dec 2009 22:21:32 -0600 Subject: Kernel security update required or not? In-Reply-To: <1261359246.1981.5.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> Message-ID: <20091221042132.GB22789@wolff.to> On Mon, Dec 21, 2009 at 12:34:06 +1100, Bojan Smojver wrote: > On Sun, 2009-12-20 at 19:16 -0600, Bruno Wolff III wrote: > > There is a 2.6.31.9 build in Koji. > > Yeah, I've seen it. But, it's not in updates. Hence the question. I didn't see any of the recent previous spec file comments indicate back ported security fixes. So its unlikely the latest security fixes are in any earlier version. If you want them now, grab the kernel from koji. Otherise you can wait for the kernel to push to updates or updates-testing depending on how much you want to wait for other people to test it before you try it out. From jkeating at redhat.com Mon Dec 21 04:40:27 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Dec 2009 20:40:27 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <1261366235.2271.11.camel@localhost.localdomain> Message-ID: <1261370427.2271.19.camel@localhost.localdomain> On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote: > So what do you suggest doing in such a case? Temporarily reverting the F-n > branch to the old release, build, then bump it up again? This sounds really > suboptimal to me (in addition to being a regression from our current CVS > setup, which does allow creating such branches)! Branching is really part of > what VCSs are for. You're right, branching is a real part, that's why you would start the foo-1.1 work on a topic branch, and only merge it into origin/F-12 when you're ready to build it and push it through bodhi. Just like you'd work on a new feature on a feature branch and only bring it over to origin/master when you're ready to merge it with everything else. Treat the origin/F-?? as the master for that release, do your long running not immediately ready for build work on topic branches thereof and only merge them when you're ready to build. This reduces the surprise should another developer need to quickly build out an update that is unrelated to any major change you may have cooking. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Dec 21 05:01:06 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Dec 2009 21:01:06 -0800 Subject: dist-git help wanted: write me a regex! Message-ID: <1261371666.2271.24.camel@localhost.localdomain> The kernel module is full of changelogs that start with: Thu Dec 17 2009 Jarod Wilson 2.6.32.1-11 of course the date, name, email and revision will change, but the format is the same. This data is not really necessary in git, as we have all of that already, and it makes shortlog rather useless. parsecvs has a feature that allows one to filter out parts of log messages, and it requires a perl regex to find the lines to strip out. I'm no regex hacker, but I bet some of you are. Can somebody please write me a regex that will catch the above line, and others like it? Thanks! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bojan at rexursive.com Mon Dec 21 05:02:20 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 21 Dec 2009 16:02:20 +1100 Subject: Kernel security update required or not? In-Reply-To: <20091221042132.GB22789@wolff.to> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <20091221042132.GB22789@wolff.to> Message-ID: <1261371740.1981.8.camel@shrek.rexursive.com> On Sun, 2009-12-20 at 22:21 -0600, Bruno Wolff III wrote: > I didn't see any of the recent previous spec file comments indicate > back ported security fixes. So its unlikely the latest security fixes > are in any earlier version. If you want them now, grab the kernel from > koji. Otherise you can wait for the kernel to push to updates or > updates-testing depending on how much you want to wait for other > people to test it before you try it out. I understand what I can do. That is not the issue. The question is, should Fedora get a security update or not - you know - for all the users out there that are unaware of Koji etc. I'm sure Fedora kernel folks reading the list will know. -- Bojan From fedoraproject at cyberpear.com Mon Dec 21 05:25:06 2009 From: fedoraproject at cyberpear.com (James Cassell) Date: Mon, 21 Dec 2009 00:25:06 -0500 Subject: dist-git help wanted: write me a regex! In-Reply-To: <1261371666.2271.24.camel@localhost.localdomain> References: <1261371666.2271.24.camel@localhost.localdomain> Message-ID: On Mon, 21 Dec 2009 00:01:06 -0500, Jesse Keating wrote: > The kernel module is full of changelogs that start with: > > Thu Dec 17 2009 Jarod Wilson 2.6.32.1-11 > > of course the date, name, email and revision will change, but the format > is the same. This data is not really necessary in git, as we have all > of that already, and it makes shortlog rather useless. > > parsecvs has a feature that allows one to filter out parts of log > messages, and it requires a perl regex to find the lines to strip out. > I'm no regex hacker, but I bet some of you are. Can somebody please > write me a regex that will catch the above line, and others like it? > Thanks! > This should do it: /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ -- James Cassell From bruno at wolff.to Mon Dec 21 05:41:38 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 20 Dec 2009 23:41:38 -0600 Subject: Kernel security update required or not? In-Reply-To: <1261371740.1981.8.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <20091221042132.GB22789@wolff.to> <1261371740.1981.8.camel@shrek.rexursive.com> Message-ID: <20091221054138.GA2592@wolff.to> On Mon, Dec 21, 2009 at 16:02:20 +1100, Bojan Smojver wrote: > > I understand what I can do. That is not the issue. > > The question is, should Fedora get a security update or not - you know - > for all the users out there that are unaware of Koji etc. I'm sure > Fedora kernel folks reading the list will know. Should they all get a potentially broken kernel? The risk of known vulnerabilities that are purported to be fixed, needs to balanced against the risk that there are regressions in the kernel. It's pretty normal for local root fixes not to get pushed out for a week or so, to give time for some testing. From bojan at rexursive.com Mon Dec 21 05:55:22 2009 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 21 Dec 2009 16:55:22 +1100 Subject: Kernel security update required or not? In-Reply-To: <20091221054138.GA2592@wolff.to> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <20091221042132.GB22789@wolff.to> <1261371740.1981.8.camel@shrek.rexursive.com> <20091221054138.GA2592@wolff.to> Message-ID: <1261374922.1981.10.camel@shrek.rexursive.com> On Sun, 2009-12-20 at 23:41 -0600, Bruno Wolff III wrote: > Should they all get a potentially broken kernel? The risk of known > vulnerabilities that are purported to be fixed, needs to balanced > against the risk that there are regressions in the kernel. This is what Fedora kernel developers do, yes. > It's pretty normal for local root fixes not to get pushed out for a > week or so, to give time for some testing. Ditto. -- Bojan From bruno at wolff.to Mon Dec 21 06:53:42 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 21 Dec 2009 00:53:42 -0600 Subject: dist-git help wanted: write me a regex! In-Reply-To: References: <1261371666.2271.24.camel@localhost.localdomain> Message-ID: <20091221065342.GA8213@wolff.to> On Mon, Dec 21, 2009 at 00:25:06 -0500, James Cassell wrote: > > This should do it: > /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ I don't think this will catch a period in the comment part of the email address (as people often do after initials). Also if anyone is using hyphenated names, I don't think those will get picked up. Since those entries are utf-8, you need to worry about nonascii letters in the name. I am not sure how those collate compared to ascii letters, but it might be safer to use [^<]+ (instead of [A-Za-z0-9\s]+) since I think being more liberal in what get's matched is less likely to match something you don't want than being picky is going to not match something (either that has a typo or unusual characters in it). From josephine.tannhauser at googlemail.com Mon Dec 21 07:28:38 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 21 Dec 2009 08:28:38 +0100 Subject: Orphaned some packages In-Reply-To: <1261255491.3341.67.camel@localhost.localdomain> References: <1261255491.3341.67.camel@localhost.localdomain> Message-ID: <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> 2009/12/19, Simon Wesp : > griv: A GTK-Chat based on the RIV-Chat-protocol > Bugs: 0 > https://admin.fedoraproject.org/pkgdb/packages/bugs/griv > > python-rabbyt: Sprite library for Python > Bugs: 0 > https://admin.fedoraproject.org/pkgdb/packages/bugs/python-rabbyt I will take these 2! -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From paul at all-the-johnsons.co.uk Mon Dec 21 07:39:57 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 21 Dec 2009 07:39:57 +0000 Subject: Mono 2.6 - heads up Message-ID: <1261381197.1494.8.camel@PB3.linux> Hi, Sometime today or tomorrow I'll be uploading Mono-2.6 and the final release of MD-2.2 with all the fun that it will bring. There are lots of changes under the hood of mono and while the likes of gtk-sharp2 et al are still working on my test boxes, it might be wise to rebuild to take advantage of the improved facilities. The only thing holding up proceedings is that mono-debugger is failing to build for me which may be the debugger or mono. I'm waiting on something from Novell on that. There are a pile of changes under the hood for mono and monodevelop... http://www.mono-project.com/Release_Notes_Mono_2.6 and this time, I've added a new subpackage for the preview of C# 4.0 TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From josephine.tannhauser at googlemail.com Mon Dec 21 07:48:00 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 21 Dec 2009 08:48:00 +0100 Subject: Orphaned some packages In-Reply-To: <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> Message-ID: <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> 2009/12/21, Josephine Tannh?user : > 2009/12/19, Simon Wesp : >> griv: A GTK-Chat based on the RIV-Chat-protocol >> Bugs: 0 >> https://admin.fedoraproject.org/pkgdb/packages/bugs/griv >> >> python-rabbyt: Sprite library for Python >> Bugs: 0 >> https://admin.fedoraproject.org/pkgdb/packages/bugs/python-rabbyt > I will take these 2! I can't take these 2. Please help me! -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From oget.fedora at gmail.com Mon Dec 21 08:36:16 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 21 Dec 2009 03:36:16 -0500 Subject: Orphaned some packages In-Reply-To: <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> Message-ID: On Mon, Dec 21, 2009 at 2:48 AM, Josephine Tannh?user wrote: > 2009/12/21, Josephine Tannh?user : >> 2009/12/19, Simon Wesp : >>> griv: A GTK-Chat based on the RIV-Chat-protocol >>> Bugs: 0 >>> https://admin.fedoraproject.org/pkgdb/packages/bugs/griv >>> >>> python-rabbyt: Sprite library for Python >>> Bugs: 0 >>> https://admin.fedoraproject.org/pkgdb/packages/bugs/python-rabbyt >> I will take these 2! > I can't take these 2. Please help me! > I tried to push the "Take ownership" button on python-rabbyt's devel branch and it worked. Then I pushed "Release Ownership". That worked too. Do you get an error message when you use those buttons? Are you logged in? Sometimes there is a "Verify Login" button that pops up on upper right of the page for some reason. You need to click on that. Orcan From josephine.tannhauser at googlemail.com Mon Dec 21 08:54:01 2009 From: josephine.tannhauser at googlemail.com (=?UTF-8?Q?Josephine_Tannh=C3=A4user?=) Date: Mon, 21 Dec 2009 09:54:01 +0100 Subject: Orphaned some packages In-Reply-To: References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> Message-ID: <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> 2009/12/21, Orcan Ogetbil : > I tried to push the "Take ownership" button on python-rabbyt's devel > branch and it worked. Then I pushed "Release Ownership". That worked > too. Do you get an error message when you use those buttons? Are you > logged in? Sometimes there is a "Verify Login" button that pops up on > upper right of the page for some reason. You need to click on that. Hi Orcan, I tried it until it works. "Request failed" was the message. I had to click in "Take ownership" about 5 times. -- Josephine "Fine" Tannh?user 2.6.31.5-127.fc12.i686.PAE From pbrobinson at gmail.com Mon Dec 21 09:26:20 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 21 Dec 2009 09:26:20 +0000 Subject: Mono 2.6 - heads up In-Reply-To: <1261381197.1494.8.camel@PB3.linux> References: <1261381197.1494.8.camel@PB3.linux> Message-ID: <5256d0b0912210126g3c90f8d4s33144ca7682ce651@mail.gmail.com> On Mon, Dec 21, 2009 at 7:39 AM, Paul wrote: > Hi, > > Sometime today or tomorrow I'll be uploading Mono-2.6 and the final > release of MD-2.2 with all the fun that it will bring. There are lots of > changes under the hood of mono and while the likes of gtk-sharp2 et al > are still working on my test boxes, it might be wise to rebuild to take > advantage of the improved facilities. > > The only thing holding up proceedings is that mono-debugger is failing > to build for me which may be the debugger or mono. I'm waiting on > something from Novell on that. > > There are a pile of changes under the hood for mono and monodevelop... > > http://www.mono-project.com/Release_Notes_Mono_2.6 > > and this time, I've added a new subpackage for the preview of C# 4.0 I presume that will only be for rawhide? Peter From andre at bwh.harvard.edu Mon Dec 21 10:19:20 2009 From: andre at bwh.harvard.edu (Andre Robatino) Date: Mon, 21 Dec 2009 05:19:20 -0500 Subject: Mass rebuild for F13? Message-ID: <4B2F4BA8.9010501@bwh.harvard.edu> Is there expected to be a mass rebuild for F13 - for example, to include GCC 4.5 (which will probably be released the first half of 2010, judging by past release dates)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From rakesh.pandit at gmail.com Mon Dec 21 10:39:44 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Mon, 21 Dec 2009 16:09:44 +0530 Subject: Package Review Stats for last 21 days (3 weeks) ending 20th Dec Message-ID: Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last 21 days ending 20th Dec were Parag AN(????), Mamoru Tasaka and David Nalley. Parag AN(????) : 17 https://bugzilla.redhat.com/show_bug.cgi?id=536737 https://bugzilla.redhat.com/show_bug.cgi?id=538296 https://bugzilla.redhat.com/show_bug.cgi?id=522204 https://bugzilla.redhat.com/show_bug.cgi?id=522208 https://bugzilla.redhat.com/show_bug.cgi?id=541666 https://bugzilla.redhat.com/show_bug.cgi?id=543861 https://bugzilla.redhat.com/show_bug.cgi?id=547016 https://bugzilla.redhat.com/show_bug.cgi?id=547017 https://bugzilla.redhat.com/show_bug.cgi?id=522895 https://bugzilla.redhat.com/show_bug.cgi?id=541792 https://bugzilla.redhat.com/show_bug.cgi?id=541793 https://bugzilla.redhat.com/show_bug.cgi?id=541992 https://bugzilla.redhat.com/show_bug.cgi?id=543863 https://bugzilla.redhat.com/show_bug.cgi?id=541661 https://bugzilla.redhat.com/show_bug.cgi?id=541662 https://bugzilla.redhat.com/show_bug.cgi?id=541664 https://bugzilla.redhat.com/show_bug.cgi?id=541668 Mamoru Tasaka : 10 https://bugzilla.redhat.com/show_bug.cgi?id=530198 https://bugzilla.redhat.com/show_bug.cgi?id=532309 https://bugzilla.redhat.com/show_bug.cgi?id=533725 https://bugzilla.redhat.com/show_bug.cgi?id=530301 https://bugzilla.redhat.com/show_bug.cgi?id=541491 https://bugzilla.redhat.com/show_bug.cgi?id=541512 https://bugzilla.redhat.com/show_bug.cgi?id=541807 https://bugzilla.redhat.com/show_bug.cgi?id=543337 https://bugzilla.redhat.com/show_bug.cgi?id=524379 https://bugzilla.redhat.com/show_bug.cgi?id=542754 David Nalley : 5 https://bugzilla.redhat.com/show_bug.cgi?id=511998 https://bugzilla.redhat.com/show_bug.cgi?id=542075 https://bugzilla.redhat.com/show_bug.cgi?id=542077 https://bugzilla.redhat.com/show_bug.cgi?id=542084 https://bugzilla.redhat.com/show_bug.cgi?id=542087 Karel Kl?? : 4 https://bugzilla.redhat.com/show_bug.cgi?id=225980 https://bugzilla.redhat.com/show_bug.cgi?id=226441 https://bugzilla.redhat.com/show_bug.cgi?id=226101 https://bugzilla.redhat.com/show_bug.cgi?id=226213 Miroslav Lichvar : 4 https://bugzilla.redhat.com/show_bug.cgi?id=225851 https://bugzilla.redhat.com/show_bug.cgi?id=226102 https://bugzilla.redhat.com/show_bug.cgi?id=226165 https://bugzilla.redhat.com/show_bug.cgi?id=226442 Peter Lemenkov : 4 https://bugzilla.redhat.com/show_bug.cgi?id=494695 https://bugzilla.redhat.com/show_bug.cgi?id=548092 https://bugzilla.redhat.com/show_bug.cgi?id=548203 https://bugzilla.redhat.com/show_bug.cgi?id=529423 Chitlesh GOORAH : 3 https://bugzilla.redhat.com/show_bug.cgi?id=544745 https://bugzilla.redhat.com/show_bug.cgi?id=517366 https://bugzilla.redhat.com/show_bug.cgi?id=543383 Jochen Schmitt : 3 https://bugzilla.redhat.com/show_bug.cgi?id=530090 https://bugzilla.redhat.com/show_bug.cgi?id=452636 https://bugzilla.redhat.com/show_bug.cgi?id=534168 Remi Collet : 3 https://bugzilla.redhat.com/show_bug.cgi?id=542028 https://bugzilla.redhat.com/show_bug.cgi?id=541694 https://bugzilla.redhat.com/show_bug.cgi?id=542500 Rex Dieter : 3 https://bugzilla.redhat.com/show_bug.cgi?id=543248 https://bugzilla.redhat.com/show_bug.cgi?id=547988 https://bugzilla.redhat.com/show_bug.cgi?id=544569 Adam Goode : 2 https://bugzilla.redhat.com/show_bug.cgi?id=226049 https://bugzilla.redhat.com/show_bug.cgi?id=226552 Adam Tkac : 2 https://bugzilla.redhat.com/show_bug.cgi?id=225901 https://bugzilla.redhat.com/show_bug.cgi?id=226521 Dennis Gilmore : 2 https://bugzilla.redhat.com/show_bug.cgi?id=547427 https://bugzilla.redhat.com/show_bug.cgi?id=521989 Felix Kaechele : 2 https://bugzilla.redhat.com/show_bug.cgi?id=476359 https://bugzilla.redhat.com/show_bug.cgi?id=544821 Jussi Lehtola : 2 https://bugzilla.redhat.com/show_bug.cgi?id=530772 https://bugzilla.redhat.com/show_bug.cgi?id=542740 Kalev Lember : 2 https://bugzilla.redhat.com/show_bug.cgi?id=525540 https://bugzilla.redhat.com/show_bug.cgi?id=525927 Lubomir Rintel : 2 https://bugzilla.redhat.com/show_bug.cgi?id=539863 https://bugzilla.redhat.com/show_bug.cgi?id=541589 Marek Mahut : 2 https://bugzilla.redhat.com/show_bug.cgi?id=532709 https://bugzilla.redhat.com/show_bug.cgi?id=540708 Mattias Ellert : 2 https://bugzilla.redhat.com/show_bug.cgi?id=538172 https://bugzilla.redhat.com/show_bug.cgi?id=533899 Michal Hlavinka : 2 https://bugzilla.redhat.com/show_bug.cgi?id=226546 https://bugzilla.redhat.com/show_bug.cgi?id=226567 Ondrej Vasik : 2 https://bugzilla.redhat.com/show_bug.cgi?id=225729 https://bugzilla.redhat.com/show_bug.cgi?id=226379 Thomas Spura : 2 https://bugzilla.redhat.com/show_bug.cgi?id=225709 https://bugzilla.redhat.com/show_bug.cgi?id=502556 Yanko Kaneti : 2 https://bugzilla.redhat.com/show_bug.cgi?id=544299 https://bugzilla.redhat.com/show_bug.cgi?id=545433 Alexander Kurtakov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=540653 Brennan Ashton : 1 https://bugzilla.redhat.com/show_bug.cgi?id=499476 Christoph Wickert : 1 https://bugzilla.redhat.com/show_bug.cgi?id=528150 Dan Hor??k : 1 https://bugzilla.redhat.com/show_bug.cgi?id=225693 Dan Hor?k : 1 https://bugzilla.redhat.com/show_bug.cgi?id=544384 Dominic Hopf : 1 https://bugzilla.redhat.com/show_bug.cgi?id=544540 Gerd Pokorra : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539480 Gianluca Sforna : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542027 Hans Ulrich Niedermann : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542518 Ivana Varekova : 1 https://bugzilla.redhat.com/show_bug.cgi?id=226661 Jarod Wilson : 1 https://bugzilla.redhat.com/show_bug.cgi?id=513896 Jaroslav Reznik : 1 https://bugzilla.redhat.com/show_bug.cgi?id=544570 Matthias Clasen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=543608 Nicolas Mailhot : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542461 Orcan 'oget' Ogetbil : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539983 Richard W.M. Jones : 1 https://bugzilla.redhat.com/show_bug.cgi?id=545132 Roman Rakus : 1 https://bugzilla.redhat.com/show_bug.cgi?id=225286 Ruben Kerkhof : 1 https://bugzilla.redhat.com/show_bug.cgi?id=526311 Sandro Mathys : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539912 Simon Wesp : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541902 Terje R??sten : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541355 Thomas Fitzsimmons : 1 https://bugzilla.redhat.com/show_bug.cgi?id=526426 Thomas Janssen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=537431 manuel wolfshant : 1 https://bugzilla.redhat.com/show_bug.cgi?id=538190 Total reviews modified: 106 Merge Reviews: 25 Review Requests: 81 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first From jakub at redhat.com Mon Dec 21 10:50:55 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 21 Dec 2009 05:50:55 -0500 Subject: Mass rebuild for F13? In-Reply-To: <4B2F4BA8.9010501@bwh.harvard.edu> References: <4B2F4BA8.9010501@bwh.harvard.edu> Message-ID: <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote: > Is there expected to be a mass rebuild for F13 - for example, to include > GCC 4.5 (which will probably be released the first half of 2010, judging > by past release dates)? I do not intend to jump to GCC 4.5 for F13, that would mean I and others would have to spend almost all our time on that already by now, while there is still a lot of work on GCC 4.4 bugfixing. GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we can leave GCC 4.5 as a new feature to F14. Jakub From ndbecker2 at gmail.com Mon Dec 21 11:17:26 2009 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 21 Dec 2009 06:17:26 -0500 Subject: Mass rebuild for F13? References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> Message-ID: Jakub Jelinek wrote: > On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote: >> Is there expected to be a mass rebuild for F13 - for example, to include >> GCC 4.5 (which will probably be released the first half of 2010, judging >> by past release dates)? > > I do not intend to jump to GCC 4.5 for F13, that would mean I and others > would have to spend almost all our time on that already by now, while > there is still a lot of work on GCC 4.4 bugfixing. > GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we > can leave GCC 4.5 as a new feature to F14. > > Jakub > How could I learn what 4.5 features are backported? From jakub at redhat.com Mon Dec 21 11:37:12 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 21 Dec 2009 06:37:12 -0500 Subject: Mass rebuild for F13? In-Reply-To: References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> Message-ID: <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> On Mon, Dec 21, 2009 at 06:17:26AM -0500, Neal Becker wrote: > > On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote: > >> Is there expected to be a mass rebuild for F13 - for example, to include > >> GCC 4.5 (which will probably be released the first half of 2010, judging > >> by past release dates)? > > > > I do not intend to jump to GCC 4.5 for F13, that would mean I and others > > would have to spend almost all our time on that already by now, while > > there is still a lot of work on GCC 4.4 bugfixing. > > GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we > > can leave GCC 4.5 as a new feature to F14. > > How could I learn what 4.5 features are backported? >From gcc %changelog? To list some of them: - VTA - -gdwarf-3, -gstrict-dwarf support, defaults to -gdwarf-3 - various other debuginfo related backports - epilogue unwinding support - __builtin_unreachable () support - asm goto support - power7 support - SSE5 support removal, AMD Orochi support added (-mfma4, -mxop, -mlwp) - -freorder-blocks-and-partitions unwind fixes - STB_GNU_UNIQUE support - C++ typeinfo comparison changes - C++ constructor and destructor code size optimizations (aliasing identical base/complete cdtors together when no virtual bases, wrapper version of deleting dtor) - -D_FORTIFY_SOURCE={1,2} changes - some small Fortran speed optimization backports - -mcrc32 support on ix86/x86_64 - more accurate ix86/x86_64 insn length info, ix86/x86_64 machine reorg improvements - -march=atom/-mtune=atom support - -masm=intel mode fixes - raw string support, u/U/u8 string literal support - assorted bugfixes Jakub From jonathan.underwood at gmail.com Mon Dec 21 11:50:57 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 21 Dec 2009 11:50:57 +0000 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261370427.2271.19.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <1261366235.2271.11.camel@localhost.localdomain> <1261370427.2271.19.camel@localhost.localdomain> Message-ID: <645d17210912210350j57f3f34aqc0ab6e8ef4bd963@mail.gmail.com> 2009/12/21 Jesse Keating : > On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote: >> So what do you suggest doing in such a case? Temporarily reverting the F-n >> branch to the old release, build, then bump it up again? This sounds really >> suboptimal to me (in addition to being a regression from our current CVS >> setup, which does allow creating such branches)! Branching is really part of >> what VCSs are for. > > You're right, branching is a real part, that's why you would start the > foo-1.1 work on a topic branch, and only merge it into origin/F-12 when > you're ready to build it and push it through bodhi. ?Just like you'd > work on a new feature on a feature branch and only bring it over to > origin/master when you're ready to merge it with everything else. > > Treat the origin/F-?? as the master for that release, do your long > running not immediately ready for build work on topic branches thereof > and only merge them when you're ready to build. ?This reduces the > surprise should another developer need to quickly build out an update > that is unrelated to any major change you may have cooking. Something that would be really nice on top of this would be allowing *any* contributor to create and push private/topic branches while only allowing contributors allowed by the ACL to push to the branches from which builds occur. Use case: I see a problem with a package. I fix it and push to a topic branch, and then contact the package owners and ask them to merge it. Faster workflow than going through bugzilla. This might all be one pony too far at this stage though, and might be phase 10 wishlist stuff. J From oget.fedora at gmail.com Mon Dec 21 12:03:13 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 21 Dec 2009 07:03:13 -0500 Subject: Mass rebuild for F13? In-Reply-To: <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> Message-ID: On Mon, Dec 21, 2009 at 6:37 AM, Jakub Jelinek wrote: > On Mon, Dec 21, 2009 at 06:17:26AM -0500, Neal Becker wrote: >> How could I learn what 4.5 features are backported? > > >From gcc %changelog? > > To list some of them: > > - VTA > - -gdwarf-3, -gstrict-dwarf support, defaults to -gdwarf-3 > - various other debuginfo related backports > - epilogue unwinding support > - __builtin_unreachable () support > - asm goto support > - power7 support > - SSE5 support removal, AMD Orochi support added (-mfma4, -mxop, -mlwp) > - -freorder-blocks-and-partitions unwind fixes > - STB_GNU_UNIQUE support > - C++ typeinfo comparison changes > - C++ constructor and destructor code size optimizations (aliasing > ?identical base/complete cdtors together when no virtual bases, > ?wrapper version of deleting dtor) > - -D_FORTIFY_SOURCE={1,2} changes > - some small Fortran speed optimization backports > - -mcrc32 support on ix86/x86_64 > - more accurate ix86/x86_64 insn length info, ix86/x86_64 machine reorg improvements > - -march=atom/-mtune=atom support > - -masm=intel mode fixes > - raw string support, u/U/u8 string literal support > - assorted bugfixes > It would be nice if you folks add these little explanations as comments next to the patches of the gcc SPEC file. (this is also a packaging requirement [1]). Orcan [1] http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment From jakub at redhat.com Mon Dec 21 12:21:56 2009 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 21 Dec 2009 07:21:56 -0500 Subject: Mass rebuild for F13? In-Reply-To: References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> Message-ID: <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote: > It would be nice if you folks add these little explanations as > comments next to the patches of the gcc SPEC file. (this is also a > packaging requirement [1]). 1) gcc-4.4-RH has its own svn branch in upstream repository, so the src.rpm contains only very few patches, most of the changes are simply committed to the svn branch. svn commit logs contain all relevant info. 2) the patches (~ 20) that are left have comments in their bodies, rather than in the spec file, which is much more maintainable. Jakub From oget.fedora at gmail.com Mon Dec 21 12:38:55 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 21 Dec 2009 07:38:55 -0500 Subject: Mass rebuild for F13? In-Reply-To: <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> Message-ID: On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote: > On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote: >> It would be nice if you folks add these little explanations as >> comments next to the patches of the gcc SPEC file. (this is also a >> packaging requirement [1]). > > 1) gcc-4.4-RH has its own svn branch in upstream repository, so the > ? src.rpm contains only very few patches, most of the changes are > ? simply committed to the svn branch. ?svn commit logs contain > ? all relevant info. > 2) the patches (~ 20) that are left have comments in their bodies, > ? rather than in the spec file, which is much more maintainable. > Yeah, those comments in the patches are quite informative, like "libtool sucks". Seriously, this "comment about the patch in the specfile" is a packaging requirement, not a personal request. Orcan From sundaram at fedoraproject.org Mon Dec 21 12:46:19 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 21 Dec 2009 18:16:19 +0530 Subject: autofs not installed by default In-Reply-To: <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> References: <168ef9ac0912170643l345592cfo178f20310c5d86ae@mail.gmail.com> <168ef9ac0912181020p25b8c056u990c5027dc069f2f@mail.gmail.com> Message-ID: <4B2F6E1B.5060206@fedoraproject.org> On 12/18/2009 11:50 PM, Todd Volkert wrote: > Hi Yaakov, > > Thanks for the response. I'm actually only installing it on one local > machine, but I upgrade every Fedora release and have noticed this > behavior the past few releases. I work at VMware, where every developer > can install whatever OS they want to work in, and in Linux, you use > ypbind to get access to your network login and shared folders. Thus, > I'm using a simple install DVD. I'll look into a kickstart file, though > for one machine, it sounds like it might not be worth it. It might be. Just reuse the kickstart file that Anaconda generates and writes to /root for every Fedora (and RHEL) installation and it will save you a lot of post-installation customization. Rahul From rawhide at fedoraproject.org Mon Dec 21 13:08:20 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 21 Dec 2009 13:08:20 +0000 Subject: rawhide report: 20091221 changes Message-ID: <20091221130820.GA15758@releng2.fedora.phx.redhat.com> Compose started at Mon Dec 21 08:15:07 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 beagle-0.3.9-15.fc12.i686 requires libwv-1.2.so.3 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-2.fc13.i686 requires libwv-1.2.so.3 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 pyabiword-0.8.0-1.fc13.i686 requires libwv-1.2.so.3 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so qle-0.0.17-1.fc13.noarch requires perl(PDF-Create) sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tokyotyrant-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) beagle-0.3.9-15.fc12.x86_64 requires libwv-1.2.so.3()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-devel-1.4.6.1-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-doc-1.4.6.1-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-prof-1.4.6.1-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.i686 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-devel-0.3-4.fc13.x86_64 requires ghc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-doc-0.3-4.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-X11-xft-prof-0.3-4.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.i686 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-devel-1.9-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-doc-1.9-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-cpphs-prof-1.9-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.i686 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-devel-0.2.1.0-11.fc12.x86_64 requires ghc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-doc-0.2.1.0-11.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-editline-prof-0.2.1.0-11.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.i686 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-devel-1.15-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-doc-1.15-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-hscolour-prof-1.15-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.i686 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-devel-0.3.5-3.fc12.x86_64 requires ghc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-doc-0.3.5-3.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-utf8-string-prof-0.3.5-3.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-2.fc13.x86_64 requires libwv-1.2.so.3()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) pyabiword-0.8.0-1.fc13.x86_64 requires libwv-1.2.so.3()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) qle-0.0.17-1.fc13.noarch requires perl(PDF-Create) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tokyotyrant-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) tokyotyrant-libs-1.1.35-1.fc13.i686 requires libtokyocabinet.so.8 tokyotyrant-libs-1.1.35-1.fc13.x86_64 requires libtokyocabinet.so.8()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package synfigstudio Vector-based 2D animation studio New package vanessa_logger Generic logging layer Updated Packages: acl-2.2.49-1.fc13 ----------------- * Sun Dec 20 2009 Kamil Dudka 2.2.49-1 - new upstream bugfix release - big cleanup in patches anthy-9100h-10.fc13 ------------------- * Mon Dec 21 2009 Akira TAGOH - 9100h-10 - Fix more typos in dictionary. (#548078) - correct the source URL. * Thu Sep 03 2009 Dennis Gregorovic - 9100h-9 - Do not build against xemacs on RHEL curl-7.19.7-9.fc13 ------------------ * Sun Dec 20 2009 Kamil Dudka 7.19.7-9 - temporary workaround for #548269 (restored behavior of 7.19.7-4) ferm-2.0.6-7.fc13 ----------------- * Mon Dec 21 2009 Pavel Alexeev - 2.0.6-7 - Update to upstream 2.0.6 version. gkrellm-2.3.2-8.fc13 -------------------- * Sun Dec 20 2009 Hans de Goede 2.3.2-8 - Don't crash on laptops with dead batteries (#545987) - Don't crash with transparent themes (#549005) gnome-doc-utils-0.18.1-1.fc13 ----------------------------- * Sun Dec 20 2009 Matthew Barnes - 0.18.1-1 - Update to 0.18.1 jd-2.5.5-0.3.beta091220.fc13 ---------------------------- * Sun Dec 20 2009 Mamoru Tasaka - 2.5.5-0.3.beta091220 - 2.5.5 beta 091220 kcm-gtk-0.5.3-2.fc13 -------------------- * Sun Dec 20 2009 Kevin Kofler 0.5.3-2 - fix missing umlauts and sharp s in the German translation kde-plasma-ihatethecashew-0.4-1.fc13 ------------------------------------ * Mon Dec 21 2009 Eli Wapniarski 0.4-1 - Version Upgrade - support KDE 4.4 kile-2.1-0.5.b3.fc13 -------------------- * Sun Dec 20 2009 Kevin Kofler - 2.1-0.5.b3 - add translations from l10n-kde4 SVN (revision 1055480 from Nov 28) * Mon Nov 30 2009 Rex Dieter - 2.1-0.4.b3 - kile-2.1b3 libdrm-2.4.17-1.fc13 -------------------- * Mon Dec 21 2009 Dave Airlie 2.4.17-0.1 - new radeon API from upstream rebase * Mon Dec 21 2009 Dave Airlie 2.4.17-1 - upstream released 2.4.17 libkate-0.3.7-1.fc13 -------------------- * Wed Nov 25 2009 Nicolas Chauvet - 0.3.7-1 - Update to 0.3.7 libsoup22-2.2.105-6.fc13 ------------------------ mesa-7.8-0.6.fc13 ----------------- * Mon Dec 21 2009 Dave Airlie 7.8-0.1 - resnapshot from upstream for libdrm_radeon changes * Mon Dec 21 2009 Dave Airlie 7.8-0.2 - add GLSL build fix from upstream + bump libdrm requires * Mon Dec 21 2009 Dave Airlie 7.8-0.3 - another attempt at GLSL build fix * Mon Dec 21 2009 Dave Airlie 7.8-0.4 - fix OSmesa builds hopefully * Mon Dec 21 2009 Dave Airlie 7.8-0.5 - one more libOSMesa build fix * Mon Dec 21 2009 Dave Airlie 7.8-0.6 - mesa fix link shared to actually link * Mon Oct 19 2009 Adam Jackson - xdriinfo 1.0.3 mimedefang-2.67-3.fc13 ---------------------- * Mon Dec 21 2009 Robert Scheck 2.67-3 - Rebuilt against perl 5.10.1 parted-1.9.0-25.fc13 -------------------- * Sun Dec 20 2009 Hans de Goede 1.9.0-25 - Fix crash when partitioning loopback devices (#546622) - Drop no-cylinder-align patch: - its functionality is superseeded by the per disk flags - its only user (pyparted) has been updated to use those - this is not upstream so we don't want other programs to start using it perl-Convert-BinHex-1.119-11.fc13 --------------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.119-11 - rebuild against perl 5.10.1 perl-Devel-FindRef-1.42-8.fc13 ------------------------------ * Sun Dec 20 2009 Nicolas Chauvet - 1.42-8 - Add BR perl(common::sense) perl-IO-stringy-2.110-11.fc13 ----------------------------- * Sun Dec 20 2009 Robert Scheck 2.110-11 - Rebuilt against perl 5.10.1 perl-Text-Iconv-1.7-7.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 1.7-7 - rebuild against perl 5.10.1 perl-TimeDate-1.16-12.fc13 -------------------------- * Fri Dec 04 2009 Stepan Kasal - 1:1.16-12 - rebuild against perl 5.10.1 php-pecl-gmagick-1.0.2b1-3.fc13 ------------------------------- python-distutils-extra-2.12-2.fc13 ---------------------------------- * Sun Dec 20 2009 Fabian Affolter - 2.12-2 - Bumped release * Mon Dec 14 2009 Fabian Affolter - 2.12-1 - Updated to new upstream version 2.12 qbittorrent-2.1.0-0.1.beta1.fc13 -------------------------------- * Sun Dec 20 2009 Leigh Scott - 2.1.0-0.1.beta1 - update to 2.1.0beta1 - disable extra debugging to gcc patch qle-0.0.17-1.fc13 ----------------- * Fri Nov 27 2009 Lucian Langa - 0.0.17-1 - improve desktop icon file (#530837) - update patch0 - new upstream release solang-0.3-5.1fa4f602dd79f8be1f4c6e4be4f86e42970d84a9git.fc13 ------------------------------------------------------------- * Sun Dec 20 2009 Hicham HAOUARI - 0.3-5.1fa4f602dd79f8be1f4c6e4be4f86e42970d84a9git - Dropped patch porting to libgdamm-4.x (merged upstream) - Dropped patch silencing gtk+ warnings (merged upstream) - Patch adding a basic functional brasero destination - Changes from upstream since last release : + Enlarged and slideshow renderer improvements + Added French translation + Fixed the title of ExporterDialog + Ported to libgdamm-4.x + Added solang.doap: http://live.gnome.org/MaintainersCorner#maintainers + Fixed internationalization + Updated French translation + Added an expanded toolbar separator to solang.ui + Moved the Zoomer's functionality to the main Gtk::Toolbar + Carried out some housekeeping + Sanitized ProgressObserver usage + Correctly detect failure in extracting thumbnails using Exiv2 + ContentTypeRepo::is_gdk_supported should take a content-type + Automatic rotation according to Exif tags + Use ThumbbufMaker in Thumbnail::generate_using_gdkpixbuf + Improved content-type guessing and Gdk::PixbufLoader selection + Added a PixbufMaker with both async and sync capabilities + Removed zoomer.cpp from POTFILES.in stalonetray-0.8.0-1.fc13 ------------------------ * Thu Nov 26 2009 Lorenzo Villani - 0.8.0-1 - 0.8.0 - Introduces the 'slot_size' option which defines the size of a slot containing an icon - Changed the way the 'geometry' option works: now it's expressed in slot_size multiples instead of pixels. See the ChangeLog for more information. stormbaancoureur-2.1.5-6.fc13 ----------------------------- * Sun Dec 20 2009 Hans de Goede 2.1.5-6 - Don't crash on network failures when trying to post scores to the internet (#547551) synfig-0.62.00-2.fc13 --------------------- * Sun Dec 20 2009 Lubomir Rintel - 0.62.00-2 - Work around a segfault w/o urw-fonts wqy-zenhei-fonts-0.8.38-4.fc13 ------------------------------ * Mon Dec 21 2009 Jens Petersen - 0.8.38-4 - add a fedora fontconfig file for zh (#476459) xfce4-notes-plugin-1.7.2-1.fc13 ------------------------------- * Sun Dec 20 2009 Christoph Wickert - 1.7.2-1 - Update to 1.7.2 - New build dep: unique-devel xfdesktop-4.6.1-4.fc13 ---------------------- * Sun Dec 20 2009 Christoph Wickert - 4.6.1-4 - Menu fixes xorg-x11-drv-ati-6.13.0-0.18.20091221git4b05c47ac.fc13 ------------------------------------------------------ * Mon Dec 21 2009 Dave Airlie 6.13.0-0.18.20091221git4b05c47ac - rebase for latest libdrm_radeon API changes - should be final API. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 33 From mclasen at redhat.com Mon Dec 21 13:57:14 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 21 Dec 2009 08:57:14 -0500 Subject: Mass rebuild for F13? In-Reply-To: References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> Message-ID: <1261403834.1773.23.camel@planemask> On Mon, 2009-12-21 at 07:38 -0500, Orcan Ogetbil wrote: > On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote: > > On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote: > >> It would be nice if you folks add these little explanations as > >> comments next to the patches of the gcc SPEC file. (this is also a > >> packaging requirement [1]). > > > > 1) gcc-4.4-RH has its own svn branch in upstream repository, so the > > src.rpm contains only very few patches, most of the changes are > > simply committed to the svn branch. svn commit logs contain > > all relevant info. > > 2) the patches (~ 20) that are left have comments in their bodies, > > rather than in the spec file, which is much more maintainable. > > > > Yeah, those comments in the patches are quite informative, like "libtool sucks". > > Seriously, this "comment about the patch in the specfile" is a > packaging requirement, not a personal request. Keeping comments in patches is perfectly fine; if the packaging guidelines don't reflect that, they ought to be clarified. From gmaxwell at gmail.com Mon Dec 21 15:21:20 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 21 Dec 2009 10:21:20 -0500 Subject: Mass rebuild for F13? In-Reply-To: <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> Message-ID: On Mon, Dec 21, 2009 at 5:50 AM, Jakub Jelinek wrote: > I do not intend to jump to GCC 4.5 for F13, that would mean I and others > would have to spend almost all our time on that already by now, while there > is still a lot of work on GCC 4.4 bugfixing. > GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we > can leave GCC 4.5 as a new feature to F14. Has any thought been given to the changes needed to make use of LTO when the switch to 4.5 is eventually made? From limb at jcomserv.net Mon Dec 21 15:26:09 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 21 Dec 2009 09:26:09 -0600 Subject: Orphaned some packages In-Reply-To: <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> Message-ID: <4B2F9391.9050403@jcomserv.net> Josephine Tannh?user wrote: > 2009/12/21, Orcan Ogetbil : > >> I tried to push the "Take ownership" button on python-rabbyt's devel >> branch and it worked. Then I pushed "Release Ownership". That worked >> too. Do you get an error message when you use those buttons? Are you >> logged in? Sometimes there is a "Verify Login" button that pops up on >> upper right of the page for some reason. You need to click on that. >> > Hi Orcan, > I tried it until it works. "Request failed" was the message. I had to > click in "Take ownership" about 5 times. > Trying to take biniax and bastet, same problems. -- in your fear, seek only peace in your fear, seek only love -d. bowie From jkeating at j2solutions.net Mon Dec 21 15:52:03 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 21 Dec 2009 07:52:03 -0800 Subject: Mass rebuild for F13? In-Reply-To: References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> Message-ID: <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote: > On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote: >> On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote: >>> It would be nice if you folks add these little explanations as >>> comments next to the patches of the gcc SPEC file. (this is also a >>> packaging requirement [1]). >> >> 1) gcc-4.4-RH has its own svn branch in upstream repository, so the >> src.rpm contains only very few patches, most of the changes are >> simply committed to the svn branch. svn commit logs contain >> all relevant info. >> 2) the patches (~ 20) that are left have comments in their bodies, >> rather than in the spec file, which is much more maintainable. >> > > Yeah, those comments in the patches are quite informative, like > "libtool sucks". > > Seriously, this "comment about the patch in the specfile" is a > packaging requirement, not a personal request. > > With git style patches (and others) where there is lots of context and info in the patch file itself, duplicating it into the spec file is rather pointless. Let's have some thinking about the guidelines instead of blind following. The guideline is there so that we don't just have raw diffs without any context. -- Jes From boni.vivek at gmail.com Mon Dec 21 16:06:59 2009 From: boni.vivek at gmail.com (Vivek Shah) Date: Mon, 21 Dec 2009 21:36:59 +0530 Subject: Orphaned some packages In-Reply-To: <4B2F9391.9050403@jcomserv.net> References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> <4B2F9391.9050403@jcomserv.net> Message-ID: Hi, > Trying to take biniax and bastet, same problems. Tried taking up peppy (successful on the devel branch) but the same problem occurred on the other branches and for xpad as well. Thanks and Regards, Vivek From fedoraproject at cyberpear.com Mon Dec 21 16:07:40 2009 From: fedoraproject at cyberpear.com (James Cassell) Date: Mon, 21 Dec 2009 11:07:40 -0500 Subject: dist-git help wanted: write me a regex! In-Reply-To: <20091221065342.GA8213@wolff.to> References: <1261371666.2271.24.camel@localhost.localdomain> <20091221065342.GA8213@wolff.to> Message-ID: On Mon, 21 Dec 2009 01:53:42 -0500, Bruno Wolff III wrote: > >> /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ > I don't think this will catch a period in the comment part of the email > address (as people often do after initials). Also if anyone is using > hyphenated > names, I don't think those will get picked up. Since those entries are > utf-8, > you need to worry about nonascii letters in the name. I am not sure how > those > collate compared to ascii letters, but it might be safer to use [^<]+ > (instead of [A-Za-z0-9\s]+) You are correct. Here's the improved version: /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ -- James Cassell From boni.vivek at gmail.com Mon Dec 21 16:09:57 2009 From: boni.vivek at gmail.com (Vivek Shah) Date: Mon, 21 Dec 2009 21:39:57 +0530 Subject: Orphaned some packages In-Reply-To: References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> <4B2F9391.9050403@jcomserv.net> Message-ID: Hi, On Mon, Dec 21, 2009 at 9:36 PM, Vivek Shah wrote: > Hi, >> Trying to take biniax and bastet, same problems. > Tried taking up peppy (successful on the devel branch) but the same > problem occurred on the other branches and for xpad as well. Oops did not see Christoph's comments that he has picked up xpad. Won't try picking it up. Regards, Vivek From sundaram at fedoraproject.org Mon Dec 21 16:46:57 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 21 Dec 2009 22:16:57 +0530 Subject: Vala programs and compiling from source Message-ID: <4B2FA681.4070800@fedoraproject.org> Hi, I recently submitting Deja-dup, a backup program written in Vala for review at https://bugzilla.redhat.com/show_bug.cgi?id=540761 Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup like many Vala programs include both the Vala source code and the C "source code" to avoid a build time requirement of Vala and also because Vala is still in a rapidly evolving stage. Do I need to build from the original Vala source code or can I consider the machine generated C as "source"? Rahul From loganjerry at gmail.com Mon Dec 21 16:55:59 2009 From: loganjerry at gmail.com (Jerry James) Date: Mon, 21 Dec 2009 09:55:59 -0700 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <870180fe0912171309x11a35c53obdec7c33926661aa@mail.gmail.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> <20091217205406.GF29158@hs20-bc2-1.build.redhat.com> <870180fe0912171309x11a35c53obdec7c33926661aa@mail.gmail.com> Message-ID: <870180fe0912210855m31c6546u530c71d056abbca6@mail.gmail.com> On Thu, Dec 17, 2009 at 2:09 PM, Jerry James wrote: > On Thu, Dec 17, 2009 at 1:54 PM, Jakub Jelinek wrote: >> You need to first prelink -u on a copy of the program, then >> run it and let it dump itself, then package it up. > > Ah, thanks. FWIW, this didn't work. It solved the problem with generating uninstallable RPMs, but the binary RPM contains a pristine SBCL image. I know a good image was dumped, because it is executed during the build to generate some auxiliary files. I see it running in the log, so something about the binary RPM generation stripped out all the built stuff and threw it away. So far, the only successful build came from a spec file with this entry: %global __prelink_undo_cmd %{nil} -- Jerry James http://www.jamezone.org/ From gtwilliams at gmail.com Mon Dec 21 16:57:16 2009 From: gtwilliams at gmail.com (Garry Williams) Date: Mon, 21 Dec 2009 11:57:16 -0500 Subject: dist-git help wanted: write me a regex! In-Reply-To: References: <1261371666.2271.24.camel@localhost.localdomain> Message-ID: On Mon, Dec 21, 2009 at 12:25 AM, James Cassell wrote: > On Mon, 21 Dec 2009 00:01:06 -0500, Jesse Keating > wrote: >> The kernel module is full of changelogs that start with: >> >> Thu Dec 17 2009 Jarod Wilson 2.6.32.1-11 ... >> Can somebody please >> write me a regex that will catch the above line, and others like it? > > This should do it: > /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ "The grammar described in RFC 822 is surprisingly complex." http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html :-) -- Garry Williams +1 678 656-4579 From tgl at redhat.com Mon Dec 21 16:58:44 2009 From: tgl at redhat.com (Tom Lane) Date: Mon, 21 Dec 2009 11:58:44 -0500 Subject: Mass rebuild for F13? In-Reply-To: <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> Message-ID: <16786.1261414724@sss.pgh.pa.us> Jesse Keating writes: > On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote: >> Seriously, this "comment about the patch in the specfile" is a >> packaging requirement, not a personal request. > With git style patches (and others) where there is lots of context and > info in the patch file itself, duplicating it into the spec file is > rather pointless. Let's have some thinking about the guidelines > instead of blind following. The guideline is there so that we don't > just have raw diffs without any context. Yeah, I much prefer to put comments in the patch file too. For one thing, they're much more likely to get updated when the patch changes that way. The packaging guideline seems to be written with one-liner comments in mind, but my comments often run to more than that. regards, tom lane From pbrobinson at gmail.com Mon Dec 21 17:00:58 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 21 Dec 2009 17:00:58 +0000 Subject: Vala programs and compiling from source In-Reply-To: <4B2FA681.4070800@fedoraproject.org> References: <4B2FA681.4070800@fedoraproject.org> Message-ID: <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> Hi, > I recently submitting Deja-dup, a backup program written in Vala for > review at > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > like many Vala programs include both the Vala source code and the C > "source code" to avoid a build time requirement of Vala and also because > Vala is still in a rapidly evolving stage. ?Do I need to build from the > original Vala source code or can I consider the machine generated C as > "source"? For rygel to date I've used the C as "source" unless I've needed to patch a bug or build issue with it when you then need to regenerate it. Regards, Peter From fedoraproject at cyberpear.com Mon Dec 21 17:12:19 2009 From: fedoraproject at cyberpear.com (James Cassell) Date: Mon, 21 Dec 2009 12:12:19 -0500 Subject: dist-git help wanted: write me a regex! In-Reply-To: References: <1261371666.2271.24.camel@localhost.localdomain> Message-ID: On Mon, 21 Dec 2009 11:57:16 -0500, Garry Williams wrote: > > "The grammar described in RFC 822 is surprisingly complex." > http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html yeah, no kidding, and so is a proper regex to match it. I figured anything not a space or '@' followed by '@' followed by anything not a space, '@', or '>' should catch most cases. -- James Cassell From linuxguy123 at gmail.com Mon Dec 21 17:13:26 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Mon, 21 Dec 2009 10:13:26 -0700 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... Message-ID: <1261415606.2469.26.camel@localhost.localdomain> digiKam 1.0.0 was released today. I think a lot of us are running 1.0-beta 6 installed via yum. Would it be possible to get 1.0.0 into F12 stable prior to Christmas ? I know I can build it from source, but I need to install it on several machines and it would be much easier to do it via a yum update. I'm also behind on my Christmas shopping... Thanks for listening. Season's Greetings ! LG From maxamillion at gmail.com Mon Dec 21 17:16:36 2009 From: maxamillion at gmail.com (Adam Miller) Date: Mon, 21 Dec 2009 11:16:36 -0600 Subject: Vala programs and compiling from source In-Reply-To: <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> Message-ID: On Mon, Dec 21, 2009 at 11:00 AM, Peter Robinson wrote: > Hi, > >> I recently submitting Deja-dup, a backup program written in Vala for >> review at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=540761 >> >> Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup >> like many Vala programs include both the Vala source code and the C >> "source code" to avoid a build time requirement of Vala and also because >> Vala is still in a rapidly evolving stage. ?Do I need to build from the >> original Vala source code or can I consider the machine generated C as >> "source"? > > For rygel to date I've used the C as "source" unless I've needed to > patch a bug or build issue with it when you then need to regenerate > it. > > Regards, > Peter > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'd probably compile the Vala source since that's what the upstream project is written in and just have the build require Vala. Just my opinion though. C is definitely the safe choice, but I think the more Vala is used and tested the better it will get. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jkeating at redhat.com Mon Dec 21 17:24:08 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Dec 2009 09:24:08 -0800 Subject: dist-git help wanted: write me a regex! In-Reply-To: References: <1261371666.2271.24.camel@localhost.localdomain> <20091221065342.GA8213@wolff.to> Message-ID: <1261416248.2271.30.camel@localhost.localdomain> On Mon, 2009-12-21 at 11:07 -0500, James Cassell wrote: > On Mon, 21 Dec 2009 01:53:42 -0500, Bruno Wolff III wrote: > > > > >> /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[A-Za-z0-9\s]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ > > I don't think this will catch a period in the comment part of the email > > address (as people often do after initials). Also if anyone is using > > hyphenated > > names, I don't think those will get picked up. Since those entries are > > utf-8, > > you need to worry about nonascii letters in the name. I am not sure how > > those > > collate compared to ascii letters, but it might be safer to use [^<]+ > > (instead of [A-Za-z0-9\s]+) > > You are correct. Here's the improved version: > /((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s+[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/ > > -- > James Cassell > I'm having some difficulty applying this. It's going into a perl file thusly: $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s +[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/|mg But that gives me Unmatched ( in regex; marked by <-- HERE in m/(( <-- HERE or something along those lines. The added "s|...|mg" is coming from other lines in this script which look like: $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^<\n]*<[^>\n]*>\s*$|* \n|mg; so I'm sure I'm screwing something up when putting it in the script. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Mon Dec 21 17:40:45 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 21 Dec 2009 11:40:45 -0600 Subject: dist-git help wanted: write me a regex! In-Reply-To: <1261416248.2271.30.camel@localhost.localdomain> References: <1261371666.2271.24.camel@localhost.localdomain> <20091221065342.GA8213@wolff.to> <1261416248.2271.30.camel@localhost.localdomain> Message-ID: <935ead450912210940p7c54edc0q222db889c6da1c79@mail.gmail.com> On Mon, Dec 21, 2009 at 11:24 AM, Jesse Keating wrote: > > I'm having some difficulty applying this. ?It's going into a perl file > thusly: > > $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| > May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s > +[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/|mg > > But that gives me Unmatched ( in regex; marked by <-- HERE in m/(( <-- > HERE ?or something along those lines. > > The added "s|...|mg" is coming from other lines in this script which > look like: > > $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^<\n]*<[^>\n]*>\s*$|* \n|mg; > > so I'm sure I'm screwing something up when putting it in the script. You can't use "|" in the "s|||mg" command since it's used inside the regex. IIRC you should be able to use "%": "s%%%mg". -- Jeff Ollie From rdieter at math.unl.edu Mon Dec 21 17:46:51 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 21 Dec 2009 11:46:51 -0600 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... References: <1261415606.2469.26.camel@localhost.localdomain> Message-ID: Linuxguy123 wrote: > digiKam 1.0.0 was released today. I think a lot of us are running > 1.0-beta 6 installed via yum. Would it be possible to get 1.0.0 into > F12 stable prior to Christmas ? https://admin.fedoraproject.org/updates/digikam-1.0.0-1.fc12 stable that quickly? I'd feel a bit uncomfortable without at least some testing and positive feedback. -- Rex From loganjerry at gmail.com Mon Dec 21 18:22:35 2009 From: loganjerry at gmail.com (Jerry James) Date: Mon, 21 Dec 2009 11:22:35 -0700 Subject: rpm cpio error: prelink and SBCL In-Reply-To: <870180fe0912210855m31c6546u530c71d056abbca6@mail.gmail.com> References: <870180fe0912170813r45f1d35fk232d6c4f4b07f962@mail.gmail.com> <870180fe0912171024y2ffd2c07w39a23500657f9a@mail.gmail.com> <870180fe0912171248s4d9f1275t950dadc4ed51912d@mail.gmail.com> <20091217205406.GF29158@hs20-bc2-1.build.redhat.com> <870180fe0912171309x11a35c53obdec7c33926661aa@mail.gmail.com> <870180fe0912210855m31c6546u530c71d056abbca6@mail.gmail.com> Message-ID: <870180fe0912211022h3ae2b61dp2f689cc76efe2654@mail.gmail.com> > FWIW, this didn't work. ?It solved the problem with generating > uninstallable RPMs, but the binary RPM contains a pristine SBCL image. > ?I know a good image was dumped, because it is executed during the > build to generate some auxiliary files. ?I see it running in the log, > so something about the binary RPM generation stripped out all the > built stuff and threw it away. ?So far, the only successful build came > from a spec file with this entry: > > %global __prelink_undo_cmd %{nil} Nope, ignore that. The real problem is that the dumped image is being stripped. So to successfully build a project that uses SBCL to generate a dumped executable, I have to: (1) Add an explicit requires on the version of SBCL that creates the image; (2) Use an unprelinked copy of the SBCL binary to build; and (3) Disable stripping of the dumped image. This is probably the case for at least some of the other Common Lisps. Who approves changes to the Lisp packaging requirements page? -- Jerry James http://www.jamezone.org/ From jkeating at redhat.com Mon Dec 21 18:25:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Dec 2009 10:25:32 -0800 Subject: dist-git help wanted: write me a regex! In-Reply-To: <935ead450912210940p7c54edc0q222db889c6da1c79@mail.gmail.com> References: <1261371666.2271.24.camel@localhost.localdomain> <20091221065342.GA8213@wolff.to> <1261416248.2271.30.camel@localhost.localdomain> <935ead450912210940p7c54edc0q222db889c6da1c79@mail.gmail.com> Message-ID: <1261419932.2271.31.camel@localhost.localdomain> On Mon, 2009-12-21 at 11:40 -0600, Jeffrey Ollie wrote: > On Mon, Dec 21, 2009 at 11:24 AM, Jesse Keating wrote: > > > > I'm having some difficulty applying this. It's going into a perl file > > thusly: > > > > $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| > > May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s > > +[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/|mg > > > > But that gives me Unmatched ( in regex; marked by <-- HERE in m/(( <-- > > HERE or something along those lines. > > > > The added "s|...|mg" is coming from other lines in this script which > > look like: > > > > $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^<\n]*<[^>\n]*>\s*$|* \n|mg; > > > > so I'm sure I'm screwing something up when putting it in the script. > > You can't use "|" in the "s|||mg" command since it's used inside the > regex. IIRC you should be able to use "%": "s%%%mg". > Ricky helped me get this regex going, thanks all! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Mon Dec 21 18:32:18 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 21 Dec 2009 10:32:18 -0800 Subject: Release Milestones for the Masses In-Reply-To: <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> Message-ID: <4B2FBF32.7010307@redhat.com> On 12/18/2009 10:50 PM, Peter Robinson wrote: > On Fri, Dec 18, 2009 at 10:17 PM, John Poelstra wrote: >> One of the complaints heard during the last release cycle was that some >> maintainers where unclear what all the schedule milestones meant. >> >> Before we reach any of these milestones for Fedora 13 I wanted to send this >> out for feedback. What I have created represents our current process as I >> understand it. Hopefully people on the list will have enough courage to >> speak up if they disagree ;-) >> >> https://fedoraproject.org/wiki/User:Poelstra/Key_Milestones >> >> Are there any other milestones missing that we need to describe? >> >> Once we get closer to these milestones advanced reminders will be sent to >> fedora-devel-announce for them. > > I think there should also be a Spin Request / Approved deadlines as well. > > Regards, > Peter > Great idea. I need someone from the Spins SIG to tell me what those dates are. It would also be really helpful to have a link to a wiki page explaining the process I can give out when questions arise. Thanks, John From cmadams at hiwaay.net Mon Dec 21 18:36:04 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Dec 2009 12:36:04 -0600 Subject: dist-git help wanted: write me a regex! In-Reply-To: <1261416248.2271.30.camel@localhost.localdomain> References: <1261371666.2271.24.camel@localhost.localdomain> <20091221065342.GA8213@wolff.to> <1261416248.2271.30.camel@localhost.localdomain> Message-ID: <20091221183604.GD1336662@hiwaay.net> Once upon a time, Jesse Keating said: > $logmsg =~ s|/((Mon|Tues?|Wed|Thu(rs?)?|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr| > May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s+[0-3]?[0-9]\s+(19|20)[0-9][0-9]\s > +[^<]+<[^\s@]+@[^\s@>]+>\s+2.[4-6].[0-9.-]+\s*)/|mg The first character after the "=~ s" is the delimiter, so you are saying search for "/((Mon" and replace it with "Tues?" and then "Wed..." are arguments. The regexp as sent (delimited with "/") was just a match, not a search/replace. I don't know the code; what exactly are you trying to do here? Strip out date/email lines? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kevin.kofler at chello.at Mon Dec 21 18:56:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 21 Dec 2009 19:56 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <1261366235.2271.11.camel@localhost.localdomain> <1261370427.2271.19.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Treat the origin/F-?? as the master for that release, do your long > running not immediately ready for build work on topic branches thereof > and only merge them when you're ready to build. This requires us to know in advance that the work will be long running. In my experience, this is usually only noticed once the new version has been imported (with the intent to build it right away), or even once it made it to testing and got massive negative karma (after all, that's what testing is for: as the name says, stuff there needs to get tested and can fail). One case where I had to branch off an old build: I noticed on December 14 that the September 30 kde-plasma-networkmanagement snapshot had been pushed only to F11 updates and not to F12, breaking the upgrade path. By then, the F-12 branch had moved on to an October 24 snapshot, but I didn't want to rush out a newer, untested snapshot to fix the upgrade path, but instead queue the same one as on F11. (In addition, the October 24 snapshot is outdated too, Rawhide has a newer one, but current snapshots require Qt 4.6.) But the corresponding F12 build had already been deleted by Koji, so I had to branch and rebuild a new one. I used the "create a branch with a name which looks like a build tag to the tag validator" hack and branched kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that branch. Kevin Kofler From loupgaroublond at gmail.com Mon Dec 21 18:57:28 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 21 Dec 2009 19:57:28 +0100 (CET) Subject: Vala programs and compiling from source In-Reply-To: <4B2FA681.4070800@fedoraproject.org> Message-ID: 2009/12/21 Rahul Sundaram : > Hi, > > I recently submitting Deja-dup, a backup program written in Vala for > review at > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > like many Vala programs include both the Vala source code and the C > "source code" to avoid a build time requirement of Vala and also because > Vala is still in a rapidly evolving stage. ?Do I need to build from the > original Vala source code or can I consider the machine generated C as > "source"? Is the C code something that is intended to be edited by humans later? Or is the only place changes ever supposed to happen is in the Vala code? If it's the latter case, it's not really the spirit of free and open to work with only the C code unless the Vala code is included. There's enough case precedence for including it, since autotools does more or less the same thing with the source code that is used to build packages. Still, it's an issue that's heavily debated, and it's something you might want to make a goal to avoid in the future. -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: OpenPGP digital signature URL: From kdudka at redhat.com Mon Dec 21 19:12:11 2009 From: kdudka at redhat.com (Kamil Dudka) Date: Mon, 21 Dec 2009 20:12:11 +0100 Subject: libssh2 - nonresponsive package maintainer Message-ID: <200912212012.11901.kdudka@redhat.com> Hello, does anybody know how to contact Chris Weyl? He is the current maintainer of libssh2 Fedora package, which still breaks (lib)curl in Fedora. However the fix is already available and the same issue has been successfully resolved in RHEL-6: https://bugzilla.redhat.com/523796 https://bugzilla.redhat.com/539444 I am going to take over the package according to http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Thanks in advance! Kamil From oget.fedora at gmail.com Mon Dec 21 19:41:16 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 21 Dec 2009 14:41:16 -0500 Subject: Mass rebuild for F13? In-Reply-To: <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> Message-ID: On Mon, Dec 21, 2009 at 10:52 AM, Jesse Keating wrote: > On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote: >> >> Yeah, those comments in the patches are quite informative, like "libtool >> sucks". >> >> Seriously, this "comment about the patch in the specfile" is a >> packaging requirement, not a personal request. >> >> > > With git style patches (and others) where there is lots of context and info > in the patch file itself, duplicating it into the spec file is rather > pointless. Let's have some thinking about the guidelines instead of blind > following. The guideline is there so that we don't just have raw diffs > without any context. > Then I would say, let's have a look at the comments of gcc's patches before blindly believing in that they all have explanatory comments in them. Many don't. Some do, but those comments are sometimes 2 word comments such as the one given above. I fail to see the consistency here. Orcan From jkeating at redhat.com Mon Dec 21 19:59:50 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Dec 2009 11:59:50 -0800 Subject: Mass rebuild for F13? In-Reply-To: References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> <2A7D1904-5AE6-4B30-8B55-7F785B21EB2B@j2solutions.net> Message-ID: <1261425590.2271.36.camel@localhost.localdomain> On Mon, 2009-12-21 at 14:41 -0500, Orcan Ogetbil wrote: > On Mon, Dec 21, 2009 at 10:52 AM, Jesse Keating wrote: > > On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote: > >> > >> Yeah, those comments in the patches are quite informative, like "libtool > >> sucks". > >> > >> Seriously, this "comment about the patch in the specfile" is a > >> packaging requirement, not a personal request. > >> > >> > > > > With git style patches (and others) where there is lots of context and info > > in the patch file itself, duplicating it into the spec file is rather > > pointless. Let's have some thinking about the guidelines instead of blind > > following. The guideline is there so that we don't just have raw diffs > > without any context. > > > > Then I would say, let's have a look at the comments of gcc's patches > before blindly believing in that they all have explanatory comments in > them. Many don't. Some do, but those comments are sometimes 2 word > comments such as the one given above. > > I fail to see the consistency here. > > Orcan > Whether they do or don't have the comments wasn't what I was replying to. Whether the comments could exist in the patch files or whether they are required to be in the .spec file is the issue I was addressing. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Dec 21 20:01:38 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Dec 2009 12:01:38 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <1261366235.2271.11.camel@localhost.localdomain> <1261370427.2271.19.camel@localhost.localdomain> Message-ID: <1261425698.2271.37.camel@localhost.localdomain> On Mon, 2009-12-21 at 19:56 +0100, Kevin Kofler wrote: > Jesse Keating wrote: > > Treat the origin/F-?? as the master for that release, do your long > > running not immediately ready for build work on topic branches thereof > > and only merge them when you're ready to build. > > This requires us to know in advance that the work will be long running. In > my experience, this is usually only noticed once the new version has been > imported (with the intent to build it right away), or even once it made it > to testing and got massive negative karma (after all, that's what testing is > for: as the name says, stuff there needs to get tested and can fail). > > One case where I had to branch off an old build: I noticed on December 14 > that the September 30 kde-plasma-networkmanagement snapshot had been pushed > only to F11 updates and not to F12, breaking the upgrade path. By then, the > F-12 branch had moved on to an October 24 snapshot, but I didn't want to > rush out a newer, untested snapshot to fix the upgrade path, but instead > queue the same one as on F11. (In addition, the October 24 snapshot is > outdated too, Rawhide has a newer one, but current snapshots require Qt > 4.6.) But the corresponding F12 build had already been deleted by Koji, so I > had to branch and rebuild a new one. I used the "create a branch with a name > which looks like a build tag to the tag validator" hack and branched > kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that > branch. > > Kevin Kofler > While I need to digest this a bit more, it really sounds like you're trying to do waaaay to active development on /released/ Fedora branches, eg a problem of your own creation. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon Dec 21 20:31:42 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 21 Dec 2009 21:31:42 +0100 Subject: Mass rebuild for F13? References: <4B2F4BA8.9010501@bwh.harvard.edu> <20091221105055.GK29158@hs20-bc2-1.build.redhat.com> <20091221113712.GL29158@hs20-bc2-1.build.redhat.com> <20091221122156.GN29158@hs20-bc2-1.build.redhat.com> Message-ID: Orcan Ogetbil wrote: > Seriously, this "comment about the patch in the specfile" is a > packaging requirement, not a personal request. It's not a requirement, it's only a SHOULD. If there are good reasons not to do it, it's OK not to do it. Kevin Kofler From bruno at wolff.to Mon Dec 21 20:30:53 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 21 Dec 2009 14:30:53 -0600 Subject: Release Milestones for the Masses In-Reply-To: <4B2FBF32.7010307@redhat.com> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> Message-ID: <20091221203053.GA15997@wolff.to> On Mon, Dec 21, 2009 at 10:32:18 -0800, John Poelstra wrote: > > Great idea. I need someone from the Spins SIG to tell me what those > dates are. It would also be really helpful to have a link to a wiki > page explaining the process I can give out when questions arise. I think the end of https://fedoraproject.org/wiki/Spins_Process covers what you want. In theory we have a meeting in a half hour, but I don't know what the turnout is going to be. From ry at n.rix.si Mon Dec 21 22:15:30 2009 From: ry at n.rix.si (Ryan Rix) Date: Mon, 21 Dec 2009 15:15:30 -0700 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... In-Reply-To: References: <1261415606.2469.26.camel@localhost.localdomain> Message-ID: <200912211515.37353.ry@n.rix.si> On Mon 21 December 2009 10:46:51 am Rex Dieter wrote: > I'd feel a bit uncomfortable without at least some > testing and positive feedback. > Big +1 there. -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From poelstra at redhat.com Mon Dec 21 23:37:00 2009 From: poelstra at redhat.com (John Poelstra) Date: Mon, 21 Dec 2009 15:37:00 -0800 Subject: Release Milestones for the Masses In-Reply-To: <20091221203053.GA15997@wolff.to> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> <20091221203053.GA15997@wolff.to> Message-ID: <4B30069C.5020808@redhat.com> On 12/21/2009 12:30 PM, Bruno Wolff III wrote: > On Mon, Dec 21, 2009 at 10:32:18 -0800, > John Poelstra wrote: >> >> Great idea. I need someone from the Spins SIG to tell me what those >> dates are. It would also be really helpful to have a link to a wiki >> page explaining the process I can give out when questions arise. > > I think the end of https://fedoraproject.org/wiki/Spins_Process covers > what you want. > In theory we have a meeting in a half hour, but I don't know what the > turnout is going to be. This https://fedoraproject.org/wiki/Spins_Process#Timeline is ambiguous about the deadline for when spins have to be submitted (three weeks before feature freeze or feature freeze?) Previously Spins followed the regular "Feature Freeze" milestone. With the introduction of a "Submission Deadline" do Spins follow this or not? What I'd really like is for someone from the Spins SIG to reply with what the milestones should be or update the wiki page. https://fedoraproject.org/wiki/User:Poelstra/Key_Milestones We should also get the Spins dates into the master schedule which we have not done before. I would need to know from the Spins SIG what task names and tasks to reflect in the schedule. Then I can use this information as part of the "reminder campaign" during Fedora 13. John From kanarip at kanarip.com Mon Dec 21 23:45:49 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 22 Dec 2009 00:45:49 +0100 Subject: (huge) Ruby packaging changes Message-ID: <4B3008AD.8050002@kanarip.com> Hi there, Not that anything is set in stone yet, but I wanted to give you a heads-up on packaging changes in Ruby that we (the Ruby SIG) are trying to figure out. The ultimate goal is to make Fedora the best development platform out there no matter what it is exactly you target. Core features of the current plan are: - Use the alternatives system to point to one stack or the other for the system default stack (think standalone applications). - Enable running multiple different versions of the Ruby stack on one system (e.g. 1.8.5, 1.8.6, 1.9.1 and possibly 1.8.7 and 1.9.2), as these versions are still pretty current (think Enterprise Linux), pretty easily maintainable (once we do it right) and very much needed -in special cases :P If you're interested in it's developments, which are targeted for Fedora 13, may I invite you to the Ruby SIG mailing list for a more detailed discussion? The Ruby SIG mailing list is at: https://admin.fedoraproject.org/mailman/listinfo/ruby-sig/ One particular message of interest may be: http://lists.fedoraproject.org/pipermail/ruby-sig/2009-December/000033.html Cya soon! -- Jeroen From a.badger at gmail.com Mon Dec 21 23:50:09 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Dec 2009 15:50:09 -0800 Subject: Orphaned some packages In-Reply-To: References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> <4B2F9391.9050403@jcomserv.net> Message-ID: <20091221235009.GI18018@clingman.lan> On Mon, Dec 21, 2009 at 09:36:59PM +0530, Vivek Shah wrote: > Hi, > > Trying to take biniax and bastet, same problems. > Tried taking up peppy (successful on the devel branch) but the same > problem occurred on the other branches and for xpad as well. > If people could try again I'd appreciate it -- we had an issue with the python-bugzilla library and the new bugzilla earlier. Was fixed this morning. If this is still occurring it's something different. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Mon Dec 21 23:53:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Dec 2009 15:53:33 -0800 Subject: Vala programs and compiling from source In-Reply-To: <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> Message-ID: <20091221235333.GJ18018@clingman.lan> On Mon, Dec 21, 2009 at 05:00:58PM +0000, Peter Robinson wrote: > Hi, > > > I recently submitting Deja-dup, a backup program written in Vala for > > review at > > > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > > > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > > like many Vala programs include both the Vala source code and the C > > "source code" to avoid a build time requirement of Vala and also because > > Vala is still in a rapidly evolving stage. ?Do I need to build from the > > original Vala source code or can I consider the machine generated C as > > "source"? > You should be building from the vala source. > For rygel to date I've used the C as "source" unless I've needed to > patch a bug or build issue with it when you then need to regenerate > it. > Sounds like rygel should as well. When in doubt, build from the source that upstream is going to be modifying, fixing bugs in directly, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Eddie.So at equifax.com Mon Dec 21 23:56:04 2009 From: Eddie.So at equifax.com (Eddie.So at equifax.com) Date: Mon, 21 Dec 2009 18:56:04 -0500 Subject: Eddie So is out of the office. Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 08648223.gif Type: image/gif Size: 1678 bytes Desc: not available URL: From kanarip at kanarip.com Tue Dec 22 00:45:59 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 22 Dec 2009 01:45:59 +0100 Subject: Release Milestones for the Masses In-Reply-To: <4B2FBF32.7010307@redhat.com> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> Message-ID: <4B3016C7.2060009@kanarip.com> On 12/21/2009 07:32 PM, John Poelstra wrote: > On 12/18/2009 10:50 PM, Peter Robinson wrote: >> >> I think there should also be a Spin Request / Approved deadlines as well. >> > Great idea. I need someone from the Spins SIG to tell me what those > dates are. It would also be really helpful to have a link to a wiki > page explaining the process I can give out when questions arise. > As we stick close to the feature process, the Spin submission deadline is the Feature submission deadline, and the final Approved deadline is the Feature Freeze (which I believe is only one or two weeks later?) -- Jeroen From pbrobinson at gmail.com Tue Dec 22 01:04:32 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 22 Dec 2009 01:04:32 +0000 Subject: Release Milestones for the Masses In-Reply-To: <4B30069C.5020808@redhat.com> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> <20091221203053.GA15997@wolff.to> <4B30069C.5020808@redhat.com> Message-ID: <5256d0b0912211704o5e0f8daata60fcdc970004352@mail.gmail.com> On Mon, Dec 21, 2009 at 11:37 PM, John Poelstra wrote: > On 12/21/2009 12:30 PM, Bruno Wolff III wrote: >> >> On Mon, Dec 21, 2009 at 10:32:18 -0800, >> ? John Poelstra ?wrote: >>> >>> Great idea. ?I need someone from the Spins SIG to tell me what those >>> dates are. ?It would also be really helpful to have a link to a wiki >>> page explaining the process I can give out when questions arise. >> >> I think the end of https://fedoraproject.org/wiki/Spins_Process covers >> what you want. >> In theory we have a meeting in a half hour, but I don't know what the >> turnout is going to be. > > This > https://fedoraproject.org/wiki/Spins_Process#Timeline is ambiguous about the > deadline for when spins have to be submitted (three weeks before feature > freeze or feature freeze?) > > Previously Spins followed the regular "Feature Freeze" milestone. ?With the > introduction of a "Submission Deadline" do Spins follow this or not? > > What I'd really like is for someone from the Spins SIG to reply with what > the milestones should be or update the wiki page. > https://fedoraproject.org/wiki/User:Poelstra/Key_Milestones > > We should also get the Spins dates into the master schedule which we have > not done before. ?I would need to know from the Spins SIG what task names > and tasks to reflect in the schedule. ?Then I can use this information as > part of the "reminder campaign" during Fedora 13. The ambiguity of the spins process threw me somewhat in F-12 with Moblin being very new to all the process (well having seen it and never participated) as I couldn't find anything that really outlined it well and there was nothing in the way of notifications and nothing in the schedule. I would have thought it was submitted by alpha and completely approved by beta (including a beta release) but even though my wiki search skills are crap, even google never provided me with anything close. But then I failed by not actually asking so ultimately it was my own fault as I plain ran out of time but it would be useful on the main schedule none the less! Peter From jkeating at redhat.com Tue Dec 22 02:10:55 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Dec 2009 18:10:55 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261366290.2271.12.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> Message-ID: <1261447855.2271.43.camel@localhost.localdomain> On Sun, 2009-12-20 at 19:31 -0800, Jesse Keating wrote: > On Sun, 2009-12-20 at 10:28 +0100, Hans Ulrich Niedermann wrote: > > Currently, it appears that I can push arbitrarily named branches, at > > least if the package does not have per branch ACLs: > > > > Yes, that makes sense given the way the ACL system works, it just wasn't > fully expected by me. A small change to the ACL generation script will > make sure that this sort of loophole is closed. > This has been done. The way the ACLs now work, if you are a packager, you can create branches in any package that start with "private-". This makes it even easier to pass changes around as you can tell the maintainer to pull from or merge from a private branch you've created. Nobody should be able to create any branches that do not start with "private-". If we wanted to lock this down more, and only allow you to commit to a private- branch only if you already have write access to some other branch (F-12, master, EL-5, whatever) then I'll have to add more logic to the ACL generation tool. But for now, I like the freedom we have. We'll make sure that the buildsystem will not allow any official (non-scratch) builds to happen from a private-* branch. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Tue Dec 22 02:52:41 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 21 Dec 2009 20:52:41 -0600 Subject: Release Milestones for the Masses In-Reply-To: <5256d0b0912211704o5e0f8daata60fcdc970004352@mail.gmail.com> References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> <20091221203053.GA15997@wolff.to> <4B30069C.5020808@redhat.com> <5256d0b0912211704o5e0f8daata60fcdc970004352@mail.gmail.com> Message-ID: <20091222025241.GB24951@wolff.to> On Tue, Dec 22, 2009 at 01:04:32 +0000, Peter Robinson wrote: > > The ambiguity of the spins process threw me somewhat in F-12 with > Moblin being very new to all the process (well having seen it and > never participated) as I couldn't find anything that really outlined > it well and there was nothing in the way of notifications and nothing > in the schedule. I would have thought it was submitted by alpha and > completely approved by beta (including a beta release) but even though > my wiki search skills are crap, even google never provided me with > anything close. But then I failed by not actually asking so ultimately > it was my own fault as I plain ran out of time but it would be useful > on the main schedule none the less! It didn't help that the names changed for F12. Generally getting an early start and asking lots of questions is a good idea. If you like managing process and want to help out the Spins SIG could use some help. Jeroen gets busy at times and a number of the rest of us are more tech oriented and are really there because we maintain spins rather than being about the whole spin process. I try to help a little with that, but it's outside of what I am really looking to do. I'd rather work on getting lzma compression used for live images or other things like that. From jistone at redhat.com Tue Dec 22 02:59:53 2009 From: jistone at redhat.com (Josh Stone) Date: Mon, 21 Dec 2009 18:59:53 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261447855.2271.43.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> Message-ID: <4B303629.2080804@redhat.com> On 12/21/2009 06:10 PM, Jesse Keating wrote: > This has been done. The way the ACLs now work, if you are a packager, > you can create branches in any package that start with "private-". This > makes it even easier to pass changes around as you can tell the > maintainer to pull from or merge from a private branch you've created. Perhaps this should be locked down to private-$USERNAME-*? Otherwise, anyone could push into a branch that I'm trying to work with. Also, I wasn't able to delete a branch that I had pushed -- not sure if you meant to allow that. Josh From ry at n.rix.si Tue Dec 22 04:51:10 2009 From: ry at n.rix.si (Ryan Rix) Date: Mon, 21 Dec 2009 21:51:10 -0700 Subject: Opinion on Logo usage? Message-ID: <200912212151.23410.ry@n.rix.si> Hey everyone; I need some advice on how to use the Fedora logo. According to https://fedoraproject.org/wiki/Logo/UsageGuidelines it's okay to use change the typeface of the Fedora text to white if the color backing it is Fedora blue (under "Never Use the Logo on Similarly-Colored Backgrounds"); Now, if I wanted put the logo on top of the Constantine wallpaper, the contrast is very bad, and nearly illegible, since it's very close to Pantone 2935 in many places. Would it be a grey area to make the Fedora typeface white in this case? See [1] for a screenshot of what we are talking about.. What would be the best way to do this? The code currently loads the png from /usr/share/pixmaps/fedora-logo-small.png and generates the "Welcome to" text from MgOpen Modata Bold in the same Panotone 2935 of the logo typeface. If the logo typeface was made white, it would constitute keeping a separate image in the Fedora-tour data directory or adding another image to the fedora-logos package, I'd assume? The former is not a Good Thing, and the latter would probably take some intervention with Fedora-legal? I'm not sure of the details, tbh. What are everyone's thoughts? Any workarounds come to mind? Background: This is for Fedora-tour; the idea is to have it, at the option of the spin teams who choose to use it, have the application start up full screen, with the background that of the default Fedora wallpaper, and give users the option to take a tour of Fedora, etc from there. We think that there should be some sort of Fedora logo being displayed "Welcome to Fedora" or somesuch, which brings us to using the logo. Unfortunately, the blue backgrounds often conflict with the blue logo :o [1] http://rrix.fedorapeople.org/fedora-tour/bad-contrast.png -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ian at ianweller.org Tue Dec 22 06:40:54 2009 From: ian at ianweller.org (Ian Weller) Date: Tue, 22 Dec 2009 00:40:54 -0600 Subject: Opinion on Logo usage? In-Reply-To: <200912212151.23410.ry@n.rix.si> References: <200912212151.23410.ry@n.rix.si> Message-ID: <20091222064010.GA12029@deathray.ianweller.org> On Mon, Dec 21, 2009 at 09:51:10PM -0700, Ryan Rix wrote: > Hey everyone; > > I need some advice on how to use the Fedora logo. According to > https://fedoraproject.org/wiki/Logo/UsageGuidelines it's okay to use change > the typeface of the Fedora text to white if the color backing it is Fedora > blue (under "Never Use the Logo on Similarly-Colored Backgrounds"); Now, if I > wanted put the logo on top of the Constantine wallpaper, the contrast is very > bad, and nearly illegible, since it's very close to Pantone 2935 in many > places. > > Would it be a grey area to make the Fedora typeface white in this case? See > [1] for a screenshot of what we are talking about.. What would be the best way > to do this? CCing design-team's list -- good idea to ask logo-related questions there. It's definitely recommended to make the Fedora typeface white in this case -- if you can't read "Fedora" without squinting, change it. > The code currently loads the png from /usr/share/pixmaps/fedora-logo-small.png > and generates the "Welcome to" text from MgOpen Modata Bold in the same > Panotone 2935 of the logo typeface. If the logo typeface was made white, it > would constitute keeping a separate image in the Fedora-tour data directory or > adding another image to the fedora-logos package, I'd assume? The former is > not a Good Thing, and the latter would probably take some intervention with > Fedora-legal? I'm not sure of the details, tbh. What are everyone's thoughts? > Any workarounds come to mind? Filing a bug against fedora-logos and attaching the proposed PNG with a rationale would probably do the trick. -- Ian Weller () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ry at n.rix.si Tue Dec 22 07:27:13 2009 From: ry at n.rix.si (Ryan Rix) Date: Tue, 22 Dec 2009 00:27:13 -0700 Subject: Opinion on Logo usage? In-Reply-To: <20091222064010.GA12029@deathray.ianweller.org> References: <200912212151.23410.ry@n.rix.si> <20091222064010.GA12029@deathray.ianweller.org> Message-ID: <200912220027.34082.ry@n.rix.si> On Mon 21 December 2009 11:40:54 pm Ian Weller wrote: > > The code currently loads the png from > > /usr/share/pixmaps/fedora-logo-small.png and generates the "Welcome to" > > text from MgOpen Modata Bold in the same Panotone 2935 of the logo > > typeface. If the logo typeface was made white, it would constitute > > keeping a separate image in the Fedora-tour data directory or adding > > another image to the fedora-logos package, I'd assume? The former is not > > a Good Thing, and the latter would probably take some intervention with > > Fedora-legal? I'm not sure of the details, tbh. What are everyone's > > thoughts? Any workarounds come to mind? > > Filing a bug against fedora-logos and attaching the proposed PNG with a > rationale would probably do the trick. > Cool beans; https://bugzilla.redhat.com/show_bug.cgi?id=549628 Thanks Ian -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Dec 22 07:41:28 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Dec 2009 08:41:28 +0100 Subject: Release Milestones for the Masses References: <4B2BFF88.7050407@redhat.com> <5256d0b0912182250y2d725b21y26fc0a6d17f98566@mail.gmail.com> <4B2FBF32.7010307@redhat.com> <20091221203053.GA15997@wolff.to> <4B30069C.5020808@redhat.com> <5256d0b0912211704o5e0f8daata60fcdc970004352@mail.gmail.com> <20091222025241.GB24951@wolff.to> Message-ID: Bruno Wolff III wrote: > It didn't help that the names changed for F12. Yeah, I think that name change was a mistake, but sadly my proposal to revert it was voted down in FESCo. Kevin Kofler From nicu_fedora at nicubunu.ro Tue Dec 22 07:48:47 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 22 Dec 2009 09:48:47 +0200 Subject: Opinion on Logo usage? In-Reply-To: <20091222064010.GA12029@deathray.ianweller.org> References: <200912212151.23410.ry@n.rix.si> <20091222064010.GA12029@deathray.ianweller.org> Message-ID: <4B3079DF.3030100@nicubunu.ro> On 12/22/2009 08:40 AM, Ian Weller wrote: > On Mon, Dec 21, 2009 at 09:51:10PM -0700, Ryan Rix wrote: >> I need some advice on how to use the Fedora logo. According to >> https://fedoraproject.org/wiki/Logo/UsageGuidelines it's okay to use change >> the typeface of the Fedora text to white if the color backing it is Fedora >> blue (under "Never Use the Logo on Similarly-Colored Backgrounds"); Now, if I >> wanted put the logo on top of the Constantine wallpaper, the contrast is very >> bad, and nearly illegible, since it's very close to Pantone 2935 in many >> places. >> >> Would it be a grey area to make the Fedora typeface white in this case? See >> [1] for a screenshot of what we are talking about.. What would be the best way >> to do this? > > CCing design-team's list -- good idea to ask logo-related questions > there. > > It's definitely recommended to make the Fedora typeface white in this > case -- if you can't read "Fedora" without squinting, change it. +1, this is that the Usage Guidelines practically says. >> The code currently loads the png from /usr/share/pixmaps/fedora-logo-small.png >> and generates the "Welcome to" text from MgOpen Modata Bold in the same >> Panotone 2935 of the logo typeface. I bet you wanted to say here "the same hex value" -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ From kevin.kofler at chello.at Tue Dec 22 07:45:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Dec 2009 08:45:26 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Nobody should be able to create any branches that do not start with > "private-". I really don't see the point of this, why can't we just allow any branch name that isn't a reserved name (master or F-[0-9]+)? > We'll make sure that the buildsystem will not allow any official > (non-scratch) builds to happen from a private-* branch. And as I wrote before, I don't like this at all, it's a regression from our current workflow and it defeats the point of the much-touted easy branching with git. Kevin Kofler From ry at n.rix.si Tue Dec 22 08:18:06 2009 From: ry at n.rix.si (Ryan Rix) Date: Tue, 22 Dec 2009 01:18:06 -0700 Subject: Opinion on Logo usage? In-Reply-To: <4B3079DF.3030100@nicubunu.ro> References: <200912212151.23410.ry@n.rix.si> <20091222064010.GA12029@deathray.ianweller.org> <4B3079DF.3030100@nicubunu.ro> Message-ID: <200912220118.07682.ry@n.rix.si> On Tue 22 December 2009 12:48:47 am Nicu Buculei wrote: > > I bet you wanted to say here "the same hex value" > Yup, sorry, it's bedtime for me :^) -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonaleash at gmail.com -> ry at n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From choeger at cs.tu-berlin.de Tue Dec 22 10:45:52 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 22 Dec 2009 11:45:52 +0100 Subject: Texlive schemes? Message-ID: <1261478752.2249.3.camel@choeger5.umpa.netz> Hi all, after texlive 2009 crashed my latex compiling process one day before I wanted to print my dipl-thesis (kpsewhich hanging indefinitely), I erased all texlive* files. From my last installation experience I learned that installing only texlive leaves you with a non-working system (for my needs), so I wanted to simplify things by installing the full or medium scheme. [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-scheme-full Loaded plugins: presto, refresh-packagekit Setting up Install Process No package texlive-scheme-full available. Nothing to do Shouldn't that work? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From choeger at cs.tu-berlin.de Tue Dec 22 11:10:30 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 22 Dec 2009 12:10:30 +0100 Subject: Texlive schemes? In-Reply-To: <1261478752.2249.3.camel@choeger5.umpa.netz> References: <1261478752.2249.3.camel@choeger5.umpa.netz> Message-ID: <1261480230.2249.6.camel@choeger5.umpa.netz> Am Dienstag, den 22.12.2009, 11:45 +0100 schrieb Christoph H?ger: > Hi all, > > after texlive 2009 crashed my latex compiling process one day before I > wanted to print my dipl-thesis (kpsewhich hanging indefinitely), I > erased all texlive* files. > > From my last installation experience I learned that installing only > texlive leaves you with a non-working system (for my needs), so I wanted > to simplify things by installing the full or medium scheme. > > [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-scheme-full > Loaded plugins: presto, refresh-packagekit > Setting up Install Process > No package texlive-scheme-full available. > Nothing to do > > Shouldn't that work? Ok, basically it looks like _everything_ is broken currently. e.g.: > [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-bibtex-bin > Loaded plugins: presto, refresh-packagekit > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package texlive-bibtex-bin.x86_64 0:2009-2.16044.fc12 set to be updated > --> Processing Dependency: texlive-bibtex = 2009 for package: texlive-bibtex-bin-2009-2.16044.fc12.x86_64 > --> Processing Dependency: texlive = 2009 for package: texlive-bibtex-bin-2009-2.16044.fc12.x86_64 > --> Processing Dependency: libkpathsea.so.5()(64bit) for package: texlive-bibtex-bin-2009-2.16044.fc12.x86_64 > --> Running transaction check > ---> Package texlive.x86_64 0:2009-3.20091219.fc12 set to be updated > --> Processing Dependency: texlive-scheme-basic for package: texlive-2009-3.20091219.fc12.x86_64 > --> Processing Dependency: texlive-collection-latexrecommended for package: texlive-2009-3.20091219.fc12.x86_64 > ---> Package texlive-bibtex-bin.x86_64 0:2009-2.16044.fc12 set to be updated > --> Processing Dependency: texlive-bibtex = 2009 for package: texlive-bibtex-bin-2009-2.16044.fc12.x86_64 > ---> Package texlive-kpathsea-lib.x86_64 0:2009-3.20091219.fc12 set to be updated > --> Finished Dependency Resolution > texlive-2009-3.20091219.fc12.x86_64 from texlive has depsolving problems > --> Missing Dependency: texlive-collection-latexrecommended is needed by package texlive-2009-3.20091219.fc12.x86_64 (texlive) > texlive-2009-3.20091219.fc12.x86_64 from texlive has depsolving problems > --> Missing Dependency: texlive-scheme-basic is needed by package texlive-2009-3.20091219.fc12.x86_64 (texlive) > texlive-bibtex-bin-2009-2.16044.fc12.x86_64 from texlive has depsolving problems > --> Missing Dependency: texlive-bibtex = 2009 is needed by package texlive-bibtex-bin-2009-2.16044.fc12.x86_64 (texlive) > Error: Missing Dependency: texlive-scheme-basic is needed by package texlive-2009-3.20091219.fc12.x86_64 (texlive) > Error: Missing Dependency: texlive-collection-latexrecommended is needed by package texlive-2009-3.20091219.fc12.x86_64 (texlive) > Error: Missing Dependency: texlive-bibtex = 2009 is needed by package texlive-bibtex-bin-2009-2.16044.fc12.x86_64 (texlive) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dtimms at iinet.net.au Tue Dec 22 12:33:32 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 22 Dec 2009 23:33:32 +1100 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... In-Reply-To: <200912211515.37353.ry@n.rix.si> References: <1261415606.2469.26.camel@localhost.localdomain> <200912211515.37353.ry@n.rix.si> Message-ID: <4B30BC9C.7040707@iinet.net.au> On 12/22/2009 09:15 AM, Ryan Rix wrote: > On Mon 21 December 2009 10:46:51 am Rex Dieter wrote: >> I'd feel a bit uncomfortable without at least some >> testing and positive feedback. Once people try testing Rex's updated package, please provide feedback at Rex's link about it, eg what's working, not working about this build ? From hun at n-dimensional.de Tue Dec 22 13:02:11 2009 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 22 Dec 2009 14:02:11 +0100 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B303629.2080804@redhat.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B303629.2080804@redhat.com> Message-ID: <20091222140211.66ab4aba@n-dimensional.de> On Mon, 21 Dec 2009 18:59:53 -0800 Josh Stone wrote: > On 12/21/2009 06:10 PM, Jesse Keating wrote: > > This has been done. The way the ACLs now work, if you are a > > packager, you can create branches in any package that start with > > "private-". This makes it even easier to pass changes around as > > you can tell the maintainer to pull from or merge from a private > > branch you've created. > > Perhaps this should be locked down to private-$USERNAME-*? Otherwise, > anyone could push into a branch that I'm trying to work with. Good catch IMHO. My first thought also would be to separate the branches the package (co-)maintainers create, and those that every contributor can create to reduce conflicts. However, I would try to make them distinguishable, e.g.: private-foo for branches where all people in the pkg ACLs can push to private/${FAS_ACCOUNT}/* for the "any contributor can push" branches Having private-foo-baar for feature foo-bar and private-foo-bar for user foo's bar branch could end up being quite confusing. -- Hans Ulrich Niedermann From limb at jcomserv.net Tue Dec 22 13:35:33 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 22 Dec 2009 07:35:33 -0600 Subject: Orphaned some packages In-Reply-To: <20091221235009.GI18018@clingman.lan> References: <1261255491.3341.67.camel@localhost.localdomain> <3668e9f50912202328i11cab4bre3e64f25b1115bf4@mail.gmail.com> <3668e9f50912202348rcd4048fx57c22ad705cb0a74@mail.gmail.com> <3668e9f50912210054o7da3fb98wfda640ba0682a8a0@mail.gmail.com> <4B2F9391.9050403@jcomserv.net> <20091221235009.GI18018@clingman.lan> Message-ID: <4B30CB25.6080305@jcomserv.net> Toshio Kuratomi wrote: > On Mon, Dec 21, 2009 at 09:36:59PM +0530, Vivek Shah wrote: > >> Hi, >> >>> Trying to take biniax and bastet, same problems. >>> >> Tried taking up peppy (successful on the devel branch) but the same >> problem occurred on the other branches and for xpad as well. >> >> > If people could try again I'd appreciate it -- we had an issue with the > python-bugzilla library and the new bugzilla earlier. Was fixed this > morning. If this is still occurring it's something different. > > -Toshio > I just tried taking barrage. Flawless victory. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From jnovy at redhat.com Tue Dec 22 14:09:33 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 22 Dec 2009 15:09:33 +0100 Subject: Texlive schemes? In-Reply-To: <1261478752.2249.3.camel@choeger5.umpa.netz> References: <1261478752.2249.3.camel@choeger5.umpa.netz> Message-ID: <20091222140933.GA14307@dhcp-lab-133.englab.brq.redhat.com> On Tue, Dec 22, 2009 at 11:45:52AM +0100, Christoph H?ger wrote: > Hi all, > > after texlive 2009 crashed my latex compiling process one day before I > wanted to print my dipl-thesis (kpsewhich hanging indefinitely), I > erased all texlive* files. > > From my last installation experience I learned that installing only > texlive leaves you with a non-working system (for my needs), so I wanted > to simplify things by installing the full or medium scheme. > > [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-scheme-full > Loaded plugins: presto, refresh-packagekit > Setting up Install Process > No package texlive-scheme-full available. > Nothing to do > > Shouldn't that work? Confirmed. I rewrote the the upstream -> Fedora repo script from scratch where an error occured. It is fixed so please try again now. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From bnocera at redhat.com Tue Dec 22 14:16:13 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 22 Dec 2009 14:16:13 +0000 Subject: Vala programs and compiling from source In-Reply-To: <20091221235333.GJ18018@clingman.lan> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> Message-ID: <1261491373.2608.10.camel@localhost.localdomain> On Mon, 2009-12-21 at 15:53 -0800, Toshio Kuratomi wrote: > On Mon, Dec 21, 2009 at 05:00:58PM +0000, Peter Robinson wrote: > > Hi, > > > > > I recently submitting Deja-dup, a backup program written in Vala for > > > review at > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > > > > > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > > > like many Vala programs include both the Vala source code and the C > > > "source code" to avoid a build time requirement of Vala and also because > > > Vala is still in a rapidly evolving stage. Do I need to build from the > > > original Vala source code or can I consider the machine generated C as > > > "source"? > > > You should be building from the vala source. > > > For rygel to date I've used the C as "source" unless I've needed to > > patch a bug or build issue with it when you then need to regenerate > > it. > > > Sounds like rygel should as well. That won't work. The upstream uses Vala git, which didn't allow recompiling rygel from the version of Vala in Fedora. > When in doubt, build from the source that upstream is going to be modifying, > fixing bugs in directly, etc. When in doubt, use the sources that upstream is providing as the sources to build from, in this case the C files rather than the Vala ones (even if both are actually in the tarball). From linuxguy123 at gmail.com Tue Dec 22 15:01:30 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Tue, 22 Dec 2009 08:01:30 -0700 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... In-Reply-To: References: <1261415606.2469.26.camel@localhost.localdomain> Message-ID: <1261494090.30994.2.camel@localhost.localdomain> On Mon, 2009-12-21 at 11:46 -0600, Rex Dieter wrote: > Linuxguy123 wrote: > > > digiKam 1.0.0 was released today. I think a lot of us are running > > 1.0-beta 6 installed via yum. Would it be possible to get 1.0.0 into > > F12 stable prior to Christmas ? > > https://admin.fedoraproject.org/updates/digikam-1.0.0-1.fc12 > > stable that quickly? I'd feel a bit uncomfortable without at least some > testing and positive feedback. Nice job providing a means for installation without building from source and so quickly. Good work. As for installation, doing a straight rpm -i over the -beta6 install resulted in a slew of error messages regarding file conflicts. I did a yum remove digikam and then an rpm -i and everything worked fine. Thanks again. From jeff at ocjtech.us Tue Dec 22 15:18:09 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 22 Dec 2009 09:18:09 -0600 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... In-Reply-To: <1261494090.30994.2.camel@localhost.localdomain> References: <1261415606.2469.26.camel@localhost.localdomain> <1261494090.30994.2.camel@localhost.localdomain> Message-ID: <935ead450912220718m62beab50pfb00399b1f0c21f2@mail.gmail.com> On Tue, Dec 22, 2009 at 9:01 AM, Linuxguy123 wrote: > > As for installation, doing a straight rpm -i over the -beta6 install > resulted in a slew of error messages regarding file conflicts. ?I did a > yum remove digikam and then an rpm -i and everything worked fine. That's to be expected, as "rpm -i" installs a package without removing the old one. Unless the package is specially designed (like the kernel) you'll get conflicts. Normally, you'd want to use "rpm -U" which will remove the old package before installing the new one. -- Jeff Ollie From jarod at redhat.com Tue Dec 22 15:35:54 2009 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 22 Dec 2009 10:35:54 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> Message-ID: <4B30E75A.500@redhat.com> On 12/22/09 2:45 AM, Kevin Kofler wrote: > Jesse Keating wrote: >> Nobody should be able to create any branches that do not start with >> "private-". > > I really don't see the point of this, why can't we just allow any branch > name that isn't a reserved name (master or F-[0-9]+)? > >> We'll make sure that the buildsystem will not allow any official >> (non-scratch) builds to happen from a private-* branch. > > And as I wrote before, I don't like this at all, it's a regression from our > current workflow Define "our". In my personal opinion, Jesse is spot-on, we should NOT allow official builds from a private branch. That's just insane. Scratch builds are fine. Official builds need to be from the main branch, or a common non-private branch (such as the kernel has done for maintaining both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). If you get eaten by raptors, you can't expect another maintainer to come in after you and have to dig around for a private branch to update a build. -- Jarod Wilson jarod at redhat.com From skvidal at fedoraproject.org Tue Dec 22 15:37:32 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 22 Dec 2009 10:37:32 -0500 (EST) Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B30E75A.500@redhat.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> Message-ID: On Tue, 22 Dec 2009, Jarod Wilson wrote: > On 12/22/09 2:45 AM, Kevin Kofler wrote: >> Jesse Keating wrote: >>> Nobody should be able to create any branches that do not start with >>> "private-". >> >> I really don't see the point of this, why can't we just allow any branch >> name that isn't a reserved name (master or F-[0-9]+)? >> >>> We'll make sure that the buildsystem will not allow any official >>> (non-scratch) builds to happen from a private-* branch. >> >> And as I wrote before, I don't like this at all, it's a regression from our >> current workflow > > Define "our". In my personal opinion, Jesse is spot-on, we should NOT > allow official builds from a private branch. That's just insane. Scratch > builds are fine. Official builds need to be from the main branch, or a > common non-private branch (such as the kernel has done for maintaining > both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). If you get > eaten by raptors, you can't expect another maintainer to come in after > you and have to dig around for a private branch to update a build. > FWIW - I agree with both jesse and jarod. Official builds are from main branch. Anything built anywhere else will never be official. -sv From a.badger at gmail.com Tue Dec 22 15:47:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Dec 2009 07:47:14 -0800 Subject: Vala programs and compiling from source In-Reply-To: <1261491373.2608.10.camel@localhost.localdomain> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> <1261491373.2608.10.camel@localhost.localdomain> Message-ID: <20091222154713.GL18018@clingman.lan> On Tue, Dec 22, 2009 at 02:16:13PM +0000, Bastien Nocera wrote: > On Mon, 2009-12-21 at 15:53 -0800, Toshio Kuratomi wrote: > > On Mon, Dec 21, 2009 at 05:00:58PM +0000, Peter Robinson wrote: > > > Hi, > > > > > > > I recently submitting Deja-dup, a backup program written in Vala for > > > > review at > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > > > > > > > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > > > > like many Vala programs include both the Vala source code and the C > > > > "source code" to avoid a build time requirement of Vala and also because > > > > Vala is still in a rapidly evolving stage. Do I need to build from the > > > > original Vala source code or can I consider the machine generated C as > > > > "source"? > > > > > You should be building from the vala source. > > > > > For rygel to date I've used the C as "source" unless I've needed to > > > patch a bug or build issue with it when you then need to regenerate > > > it. > > > > > Sounds like rygel should as well. > > That won't work. The upstream uses Vala git, which didn't allow > recompiling rygel from the version of Vala in Fedora. > So this is interesting. Alternatives that I see here: * Build rygel from the generated C * Build vala from a snapshot so it can be used to build rygel * Drop rygel from Fedora until we can build from source. There's limited precedent for all of these. We've shipped packages where C source had been precompiled from yacc, for instance. The question is whether that was a bug to be addressed when we find it happening or something we want to accept as okay. > > When in doubt, build from the source that upstream is going to be modifying, > > fixing bugs in directly, etc. > > When in doubt, use the sources that upstream is providing as the sources > to build from, in this case the C files rather than the Vala ones (even > if both are actually in the tarball). > This is plainly an insufficient definition. For instance, mono packages sometimes ship with .dll files that their build scripts rely on "linking" into the build. Those are not source no matter what upstream's build requires. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From pbrobinson at gmail.com Tue Dec 22 15:52:14 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 22 Dec 2009 15:52:14 +0000 Subject: Vala programs and compiling from source In-Reply-To: <20091222154713.GL18018@clingman.lan> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> <1261491373.2608.10.camel@localhost.localdomain> <20091222154713.GL18018@clingman.lan> Message-ID: <5256d0b0912220752u1ef89344u7284a9a08167754d@mail.gmail.com> >> > > Hi, >> > > >> > > > I recently submitting Deja-dup, a backup program written in Vala for >> > > > review at >> > > > >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 >> > > > >> > > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup >> > > > like many Vala programs include both the Vala source code and the C >> > > > "source code" to avoid a build time requirement of Vala and also because >> > > > Vala is still in a rapidly evolving stage. ?Do I need to build from the >> > > > original Vala source code or can I consider the machine generated C as >> > > > "source"? >> > > >> > You should be building from the vala source. >> > >> > > For rygel to date I've used the C as "source" unless I've needed to >> > > patch a bug or build issue with it when you then need to regenerate >> > > it. >> > > >> > Sounds like rygel should as well. >> >> That won't work. The upstream uses Vala git, which didn't allow >> recompiling rygel from the version of Vala in Fedora. >> > So this is interesting. ?Alternatives that I see here: > > * Build rygel from the generated C > * Build vala from a snapshot so it can be used to build rygel > * Drop rygel from Fedora until we can build from source. > > There's limited precedent for all of these. ?We've shipped packages > where C source had been precompiled from yacc, for instance. ?The question > is whether that was a bug to be addressed when we find it happening or > something we want to accept as okay. > >> > When in doubt, build from the source that upstream is going to be modifying, >> > fixing bugs in directly, etc. >> >> When in doubt, use the sources that upstream is providing as the sources >> to build from, in this case the C files rather than the Vala ones (even >> if both are actually in the tarball). >> > This is plainly an insufficient definition. ?For instance, mono packages > sometimes ship with .dll files that their build scripts rely on "linking" > into the build. ?Those are not source no matter what upstream's build > requires. Some what different in that vala is source code that generates plainly readable C code. A .dll is a binary library. Its not exactly the same arguement. Peter From clydekunkel7734 at cox.net Tue Dec 22 15:56:26 2009 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Tue, 22 Dec 2009 10:56:26 -0500 Subject: Kernel security update required or not? In-Reply-To: <20091221041635.GA22789@wolff.to> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <4B2EDACA.5060309@sapience.com> <20091221041635.GA22789@wolff.to> Message-ID: <4B30EC2A.3060801@cox.net> On 12/20/2009 11:16 PM, Bruno Wolff III wrote: > On Sun, Dec 20, 2009 at 21:17:46 -0500, > Mail Lists wrote: >> On 12/20/2009 08:34 PM, Bojan Smojver wrote: >>> On Sun, 2009-12-20 at 19:16 -0600, Bruno Wolff III wrote: >>>> There is a 2.6.31.9 build in Koji. >>> >>> Yeah, I've seen it. But, it's not in updates. Hence the question. >>> >> >> Sure wish 2.6.32 would come soon ... anyone know when ? > > Be careful what you wish for. 2.6.32 isn't working for me. I have to use > 2.6.31 kernels from F12 on my otherwise rawhide system, to get it to > boot. > does adding nomodeset to kernel parm line in grub.conf work? From choeger at cs.tu-berlin.de Tue Dec 22 16:03:21 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 22 Dec 2009 17:03:21 +0100 Subject: Texlive schemes? In-Reply-To: <20091222140933.GA14307@dhcp-lab-133.englab.brq.redhat.com> References: <1261478752.2249.3.camel@choeger5.umpa.netz> <20091222140933.GA14307@dhcp-lab-133.englab.brq.redhat.com> Message-ID: <1261497801.2249.8.camel@choeger5.umpa.netz> Am Dienstag, den 22.12.2009, 15:09 +0100 schrieb Jindrich Novy: > On Tue, Dec 22, 2009 at 11:45:52AM +0100, Christoph H?ger wrote: > > Hi all, > > > > after texlive 2009 crashed my latex compiling process one day before I > > wanted to print my dipl-thesis (kpsewhich hanging indefinitely), I > > erased all texlive* files. > > > > From my last installation experience I learned that installing only > > texlive leaves you with a non-working system (for my needs), so I wanted > > to simplify things by installing the full or medium scheme. > > > > [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-scheme-full > > Loaded plugins: presto, refresh-packagekit > > Setting up Install Process > > No package texlive-scheme-full available. > > Nothing to do > > > > Shouldn't that work? > > Confirmed. I rewrote the the upstream -> Fedora repo script from > scratch where an error occured. It is fixed so please try again now. Installation seems to work now, but the installation of texlive-kpathsea-2009-3.16044.fc12.noarch (and possibly much more packages) hangs because kpsewhich hangs forever (using 100% cpu). Do you have any clue whats going on? Any chance to get this fixed before christmas? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jkeating at redhat.com Tue Dec 22 16:04:05 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Dec 2009 08:04:05 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091222140211.66ab4aba@n-dimensional.de> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B303629.2080804@redhat.com> <20091222140211.66ab4aba@n-dimensional.de> Message-ID: <1261497845.2271.44.camel@localhost.localdomain> On Tue, 2009-12-22 at 14:02 +0100, Hans Ulrich Niedermann wrote: > On Mon, 21 Dec 2009 18:59:53 -0800 > Josh Stone wrote: > > > On 12/21/2009 06:10 PM, Jesse Keating wrote: > > > This has been done. The way the ACLs now work, if you are a > > > packager, you can create branches in any package that start with > > > "private-". This makes it even easier to pass changes around as > > > you can tell the maintainer to pull from or merge from a private > > > branch you've created. > > > > Perhaps this should be locked down to private-$USERNAME-*? Otherwise, > > anyone could push into a branch that I'm trying to work with. > > Good catch IMHO. My first thought also would be to separate the > branches the package (co-)maintainers create, and those that > every contributor can create to reduce conflicts. However, I would > try to make them distinguishable, e.g.: > > private-foo > for branches where all people in the pkg ACLs can push to > > private/${FAS_ACCOUNT}/* > for the "any contributor can push" branches > > Having private-foo-baar for feature foo-bar and private-foo-bar for user > foo's bar branch could end up being quite confusing. > Having ACLs based on the username committing would take a fair amount of hacking on the ACL tool, but not impossible. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 22 16:09:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Dec 2009 08:09:49 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B303629.2080804@redhat.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B303629.2080804@redhat.com> Message-ID: <1261498190.2271.45.camel@localhost.localdomain> On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote: > Perhaps this should be locked down to private-$USERNAME-*? Otherwise, > anyone could push into a branch that I'm trying to work with. > > Also, I wasn't able to delete a branch that I had pushed -- not sure if > you meant to allow that. If the ACL system were to keep everybody in their own $username namespace, no two people could collaborate on a single branch, which kinda defeats the purpose of having the server side branch. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From linuxguy123 at gmail.com Tue Dec 22 16:33:55 2009 From: linuxguy123 at gmail.com (Linuxguy123) Date: Tue, 22 Dec 2009 09:33:55 -0700 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... In-Reply-To: <935ead450912220718m62beab50pfb00399b1f0c21f2@mail.gmail.com> References: <1261415606.2469.26.camel@localhost.localdomain> <1261494090.30994.2.camel@localhost.localdomain> <935ead450912220718m62beab50pfb00399b1f0c21f2@mail.gmail.com> Message-ID: <1261499635.31951.67.camel@localhost.localdomain> On Tue, 2009-12-22 at 09:18 -0600, Jeffrey Ollie wrote: > On Tue, Dec 22, 2009 at 9:01 AM, Linuxguy123 wrote: > > > > As for installation, doing a straight rpm -i over the -beta6 install > > resulted in a slew of error messages regarding file conflicts. I did a > > yum remove digikam and then an rpm -i and everything worked fine. > > That's to be expected, as "rpm -i" installs a package without removing > the old one. Unless the package is specially designed (like the > kernel) you'll get conflicts. Normally, you'd want to use "rpm -U" > which will remove the old package before installing the new one. DOH, what the heck was I thinking ? I KNEW that. Sheesh ! :smacks forehead with open hand: I was thinking it was an install because I had downloaded the rpms. I don't usually have to download rpms to do updates because I just use yum. Thanks for the reply. From jistone at redhat.com Tue Dec 22 16:41:30 2009 From: jistone at redhat.com (Josh Stone) Date: Tue, 22 Dec 2009 08:41:30 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261498190.2271.45.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B303629.2080804@redhat.com> <1261498190.2271.45.camel@localhost.localdomain> Message-ID: <4B30F6BA.1060205@redhat.com> On 12/22/2009 08:09 AM, Jesse Keating wrote: > On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote: >> Perhaps this should be locked down to private-$USERNAME-*? Otherwise, >> anyone could push into a branch that I'm trying to work with. >> >> Also, I wasn't able to delete a branch that I had pushed -- not sure if >> you meant to allow that. > > If the ACL system were to keep everybody in their own $username > namespace, no two people could collaborate on a single branch, which > kinda defeats the purpose of having the server side branch. Not entirely, as those two people could still pull from each other's branches. Or as Hans said, some other namespace could be pushable for the maintainers to collaborate on. Either we trust that no packager will ever misbehave, or we need to lock this down... Josh From a.badger at gmail.com Tue Dec 22 17:03:13 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Dec 2009 09:03:13 -0800 Subject: Vala programs and compiling from source In-Reply-To: <5256d0b0912220752u1ef89344u7284a9a08167754d@mail.gmail.com> References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> <1261491373.2608.10.camel@localhost.localdomain> <20091222154713.GL18018@clingman.lan> <5256d0b0912220752u1ef89344u7284a9a08167754d@mail.gmail.com> Message-ID: <20091222170313.GM18018@clingman.lan> On Tue, Dec 22, 2009 at 03:52:14PM +0000, Peter Robinson wrote: > >> > > Hi, > >> > > > >> > > > I recently submitting Deja-dup, a backup program written in Vala for > >> > > > review at > >> > > > > >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 > >> > > > > >> > > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup > >> > > > like many Vala programs include both the Vala source code and the C > >> > > > "source code" to avoid a build time requirement of Vala and also because > >> > > > Vala is still in a rapidly evolving stage. ?Do I need to build from the > >> > > > original Vala source code or can I consider the machine generated C as > >> > > > "source"? > >> > > > >> > You should be building from the vala source. > >> > > >> > > For rygel to date I've used the C as "source" unless I've needed to > >> > > patch a bug or build issue with it when you then need to regenerate > >> > > it. > >> > > > >> > Sounds like rygel should as well. > >> > >> That won't work. The upstream uses Vala git, which didn't allow > >> recompiling rygel from the version of Vala in Fedora. > >> > > So this is interesting. ?Alternatives that I see here: > > > > * Build rygel from the generated C > > * Build vala from a snapshot so it can be used to build rygel > > * Drop rygel from Fedora until we can build from source. > > > > There's limited precedent for all of these. ?We've shipped packages > > where C source had been precompiled from yacc, for instance. ?The question > > is whether that was a bug to be addressed when we find it happening or > > something we want to accept as okay. > > > >> > When in doubt, build from the source that upstream is going to be modifying, > >> > fixing bugs in directly, etc. > >> > >> When in doubt, use the sources that upstream is providing as the sources > >> to build from, in this case the C files rather than the Vala ones (even > >> if both are actually in the tarball). > >> > > This is plainly an insufficient definition. ?For instance, mono packages > > sometimes ship with .dll files that their build scripts rely on "linking" > > into the build. ?Those are not source no matter what upstream's build > > requires. > > Some what different in that vala is source code that generates plainly > readable C code. A .dll is a binary library. Its not exactly the same > arguement. > 'm asking for a better definition of source. If your new definition is any plainly readable code that upstream builds with, define "plainly readable". Should we allow swig generated C code for instance? Pyrex? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From deadbabylon at googlemail.com Tue Dec 22 17:11:39 2009 From: deadbabylon at googlemail.com (Sebastian Vahl) Date: Tue, 22 Dec 2009 18:11:39 +0100 Subject: KDE-SIG meeting report (52/2009) Message-ID: <200912221811.53585.deadbabylon@googlemail.com> 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: 52/2009 Time: 2009-12-22 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-22 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-22/fedora-meeting.2009-12-22-14.03.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-22/fedora-meeting.2009-12-22-14.03.log.html ---------------------------------------------------------------------------------- = Participants = * JaroslavReznik * KevinKofler * RexDieter * SebastianVahl * StevenParrish ---------------------------------------------------------------------------------- = Agenda = * topics to discuss: o kcm_touchpad in defaults for comps? o kde-4.3.85 and kdevplatform/kdevelop4 for kde-redhat? o current live image issues [1] o comps: cyrus-sasl-gssapi or maybe as direct requirement for kdepim(kmail) o http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal [2] * recent bugs: o kde-plasma-* : yawp, stasks needed rebuilds for 4.3.85, need to test all kde-plasma-* bits o nepomuk tracker: for kde-4.3.x dup or block ? [3] o F13Blocker-kde [4] = Summary = kcm_touchpad in defaults for comps?: * kcm_touchpad will be added as default in comps (Voting result: 5/0/0) kde-4.3.85 and kdevplatform/kdevelop4 for kde-redhat? (#549713): * KDE 4.3.85 is available at kde-unstable repository at kde-redhat. * A file conflict in kdevplatform has to be sorted out: #541690. comps: cyrus-sasl-gssapi or maybe as direct requirement for kdepim(kmail): * JaroslavReznik asked if cyrus-sasl-gssapi could be installed by default to satisfy kmail with Kerberos. * ATM cyrus-sasl-gssapi isn't present in comps at all. * RexDieter will ask other comps-ninja's for advice. current live image issues: * SebastianVahl listed some current issues of the KDE live images: [1] o KDM doesn't autologin (#549687) o Global shortcut notifications need to be silenced. o Space on live images is rare as usual (even with no qt3/kdelibs3 on it). o Autostarted plasmoids are not working (due to missing kdeplasma-addons). SIGs/KDE/Stability_Proposal: [2] * Postponed for an upcoming meeting. == recent bugs == kde-plasma-*: yawp, stasks needed rebuilds for 4.3.85, need to test all kde- plasma-* bits: * All plasmoids need to be tested with KDE 4.4 (beta) and/or incompatibilities with Qt-4.6. * At least yawp and stasks need a rebuild to be functional. nepomuk tracker for kde-4.3.x dup or block ?: [3] * KDE 4.3 in Fedora doesn't have a working nepomuk backend. * All open bugs against nepomuk and KDE 4.3 will be closed with an advice to reopen them if they could be reproduced with KDE 4.4. F13Blocker-kde: * RexDieter announced a tracker bug for all KDE related bugs in upcoming Fedora 13. [4] * Tracker bugs for Qt-4.6 and KDE 4.4 are also part of this tracker bug. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-05 ---------------------------------------------------------------------------------- = Links = [1] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-22/current_live_image_issues [2] http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal [3] https://bugzilla.redhat.com/show_bug.cgi?id=nepomuk_disabled [4] https://bugzilla.redhat.com/showdependencytree.cgi?id=F13Blocker-kde = Buglist = https://bugzilla.redhat.com/show_bug.cgi?id=541690 https://bugzilla.redhat.com/show_bug.cgi?id=549713 https://bugzilla.redhat.com/show_bug.cgi?id=549687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Dec 22 17:15:31 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Dec 2009 09:15:31 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B30F6BA.1060205@redhat.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B303629.2080804@redhat.com> <1261498190.2271.45.camel@localhost.localdomain> <4B30F6BA.1060205@redhat.com> Message-ID: <1261502131.2271.46.camel@localhost.localdomain> On Tue, 2009-12-22 at 08:41 -0800, Josh Stone wrote: > On 12/22/2009 08:09 AM, Jesse Keating wrote: > > On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote: > >> Perhaps this should be locked down to private-$USERNAME-*? Otherwise, > >> anyone could push into a branch that I'm trying to work with. > >> > >> Also, I wasn't able to delete a branch that I had pushed -- not sure if > >> you meant to allow that. > > > > If the ACL system were to keep everybody in their own $username > > namespace, no two people could collaborate on a single branch, which > > kinda defeats the purpose of having the server side branch. > > Not entirely, as those two people could still pull from each other's > branches. Or as Hans said, some other namespace could be pushable for > the maintainers to collaborate on. > > Either we trust that no packager will ever misbehave, or we need to lock > this down... > > Josh > Since no official builds would be able to come from the private branches, and since you can create other branches from other devel points along the way, I think I'm going to fall on the side of "trust" here, since we can relatively easily clean up from either mistakes or malicious intent. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Dec 22 17:36:13 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 22 Dec 2009 19:36:13 +0200 Subject: (huge) Ruby packaging changes In-Reply-To: <4B3008AD.8050002@kanarip.com> References: <4B3008AD.8050002@kanarip.com> Message-ID: <200912221936.13747.ville.skytta@iki.fi> On Tuesday 22 December 2009, Jeroen van Meeuwen wrote: > - Use the alternatives system to point to one stack or the other for the > system default stack (think standalone applications). Not that I'm anywhere near an expert in ruby matters, but I have some (bad) experience with alternatives, so: If this means running different individual applications with different stacks/stack versions, I strongly suggest reconsidering using the alternatives system for that. Alternatives is for (easily) changing the system default stack, not at all for changing per-application ones. And getting it right is not an easy task. FWIW in fact I'd recommend not doing any alternatives stuff unless there are very strong, valid reasons for doing so. We have an example with the current Java alternatives system in Fedora which in my opinion no longer has any real benefits but rather has a negative net effect and it'd be good to start planning for getting rid of it altogether. On the other hand, if I got your intent right, environment-modules might be something to look into here. From loupgaroublond at gmail.com Tue Dec 22 18:39:54 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Dec 2009 19:39:54 +0100 (CET) Subject: Vala programs and compiling from source In-Reply-To: <1261491373.2608.10.camel@localhost.localdomain> Message-ID: 2009/12/22 Bastien Nocera : > On Mon, 2009-12-21 at 15:53 -0800, Toshio Kuratomi wrote: >> On Mon, Dec 21, 2009 at 05:00:58PM +0000, Peter Robinson wrote: >> > Hi, >> > >> > > I recently submitting Deja-dup, a backup program written in Vala for >> > > review at >> > > >> > > https://bugzilla.redhat.com/show_bug.cgi?id=540761 >> > > >> > > Vala is described in more detail at http://live.gnome.org/Vala. Deja-dup >> > > like many Vala programs include both the Vala source code and the C >> > > "source code" to avoid a build time requirement of Vala and also because >> > > Vala is still in a rapidly evolving stage. ?Do I need to build from the >> > > original Vala source code or can I consider the machine generated C as >> > > "source"? >> > >> You should be building from the vala source. >> >> > For rygel to date I've used the C as "source" unless I've needed to >> > patch a bug or build issue with it when you then need to regenerate >> > it. >> > >> Sounds like rygel should as well. > > That won't work. The upstream uses Vala git, which didn't allow > recompiling rygel from the version of Vala in Fedora. > >> When in doubt, build from the source that upstream is going to be modifying, >> fixing bugs in directly, etc. > > When in doubt, use the sources that upstream is providing as the sources > to build from, in this case the C files rather than the Vala ones (even > if both are actually in the tarball). This makes me uneasy in a worse way than autotools. Even if the C is human editable, it really makes it harder for the user to fix and rebuild code, especially in a way that upstream will accept it. With autotools and similar systems, the generated code is used to compile code, but isn't part of the codebase that is actually running in the binary. Even if this is valid within the GPL, it goes against Fedora's mission to provide a codebase that is completely self hosting. Toshio mentioned a bit further down one option is to ship a checkout from Vala instead of the upstream release. Perhaps we need to put pressure on the Vala community to make more frequent releases and to focus on sticking to releases when developing applications. -Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: OpenPGP digital signature URL: From bruno at wolff.to Tue Dec 22 18:24:33 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 22 Dec 2009 12:24:33 -0600 Subject: dist-git help wanted: write me a regex! In-Reply-To: References: <1261371666.2271.24.camel@localhost.localdomain> Message-ID: <20091222182433.GA6030@wolff.to> On Mon, Dec 21, 2009 at 12:12:19 -0500, James Cassell wrote: > On Mon, 21 Dec 2009 11:57:16 -0500, Garry Williams > wrote: > > > > >"The grammar described in RFC 822 is surprisingly complex." > >http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html > > yeah, no kidding, and so is a proper regex to match it. I figured > anything not a space or '@' followed by '@' followed by anything not > a space, '@', or '>' should catch most cases. People aren't really using valid rfc822 addresses there anyway and you want liberal matching. From jlaska at redhat.com Tue Dec 22 21:19:30 2009 From: jlaska at redhat.com (James Laska) Date: Tue, 22 Dec 2009 16:19:30 -0500 Subject: [ANNOUNCEMENT] Red Hat Bugzilla 3.4 RC Message-ID: <1261516770.2456.41.camel@localhost> I am sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Please forward this on to any appropriate lists that were missed. ======== FINAL CHANGEOVER DATE: Friday, January 8th, 2010 6:00pm EST (23:00:00 UTC) Mark your calendars! We are expecting the migration to take no more than 6 hours. Please let us know at bugzilla-owner at redhat.com if this date is in conflict with any release schedules, etc. Greetings, The Red Hat Bugzilla team is happy to announce the release candidate of the next version of Red Hat Bugzilla based on the upstream 3.4 code base. So far there has been little to no feedback on our betas so please use this last opportunity to test drive at: https://partner-bugzilla.redhat.com Over the years Red Hat has made substantial customizations to Bugzilla to fit into the Engineering tool chain. Over time the upstream has incorporated some of these customizations or solved them in different ways. Upgrading reduces our customization footprint (and thus maintenance) while bringing many bug fixes & enhancements. The main area of focus for our public betas are stability. Functionality that currently works in our 3.2 code base should continue to work as expected in the new 3.4 release. These include various ajax optimizations, needinfo actor support, frontpage.cgi, product browser, several various UI enhancements, and of course the XMLRPC API. Please feel free to point your various scripts and third party applications that use the XMLRPC API at the test server to make sure they continue to function properly. There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 3.2 is possible in the new system. There are also numerous new features/fixes that are part of the upstream 3.4 release. For more detailed information on what has changed since the last release, check out release notes here: https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html The database is a recent snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Also with a full snapshot it is possible to test for any performance related issues. Email has been disabled so that unnecessary spam is not sent out. So feel free to make changes to bugs to verify proper working order. We are asking for everyone to get involved as much as possible with testing and feedback on the beta releases to help us make this the most robust and stable release possible. Please file any enhancement requests or bug reports in our current Bugzilla system go here: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.4 To see current list of 3.4 related bugs as well as blockers for release, go here: https://bugzilla.redhat.com/buglist.cgi?product=Bugzilla&version=3.4 Thanks The Red Hat Bugzilla Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Wed Dec 23 00:06:41 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Dec 2009 00:06:41 +0000 Subject: Can't rebuild emacs RPM in F12 Message-ID: <4B315F11.9070701@redhat.com> I have installed emacs-23.1-10.fc12.src.rpm Then, when I run $ rpmbuild -ba emacs.spec I get ... + /usr/bin/make bootstrap (cd src; /usr/bin/make bootstrap-clean) make[1]: Entering directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' Makefile:103: *** commands commence before first target. Stop. make[1]: Leaving directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' I can't understand this at all. I tried it on two F12 installations. Surely someone must have built emacs? This is x86_64, BTW. Andrew. From paul at all-the-johnsons.co.uk Wed Dec 23 00:12:23 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 23 Dec 2009 00:12:23 +0000 Subject: Mono 2.6 - heads up In-Reply-To: <5256d0b0912210126g3c90f8d4s33144ca7682ce651@mail.gmail.com> References: <1261381197.1494.8.camel@PB3.linux> <5256d0b0912210126g3c90f8d4s33144ca7682ce651@mail.gmail.com> Message-ID: <1261527143.3525.1.camel@PB3.linux> Hi, > > There are a pile of changes under the hood for mono and > monodevelop... > > > > http://www.mono-project.com/Release_Notes_Mono_2.6 > > > > and this time, I've added a new subpackage for the preview of C# 4.0 > > I presume that will only be for rawhide? Correct :-) Uploading now... Watch this space! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kklic at redhat.com Wed Dec 23 00:21:12 2009 From: kklic at redhat.com (Karel Klic) Date: Wed, 23 Dec 2009 01:21:12 +0100 Subject: Can't rebuild emacs RPM in F12 In-Reply-To: <4B315F11.9070701@redhat.com> References: <4B315F11.9070701@redhat.com> Message-ID: <4B316278.8060403@redhat.com> Andrew, this problem is already fixed in the latest version; please see https://bugzilla.redhat.com/show_bug.cgi?id=540921 Karel Dne 23.12.2009 01:06, Andrew Haley napsal(a): > I have installed emacs-23.1-10.fc12.src.rpm > > Then, when I run > > $ rpmbuild -ba emacs.spec > > I get > > ... > + /usr/bin/make bootstrap > (cd src; /usr/bin/make bootstrap-clean) > make[1]: Entering directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' > Makefile:103: *** commands commence before first target. Stop. > make[1]: Leaving directory `/home/aph/rpmbuild/BUILD/emacs-23.1/src' > > I can't understand this at all. I tried it on two F12 installations. > Surely someone must have built emacs? > > This is x86_64, BTW. > > Andrew. > From aph at redhat.com Wed Dec 23 00:41:07 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Dec 2009 00:41:07 +0000 Subject: Can't rebuild emacs RPM in F12 In-Reply-To: <4B316278.8060403@redhat.com> References: <4B315F11.9070701@redhat.com> <4B316278.8060403@redhat.com> Message-ID: <4B316723.4040402@redhat.com> On 12/23/2009 12:21 AM, Karel Klic wrote: > Andrew, this problem is already fixed in the latest version; please see > > https://bugzilla.redhat.com/show_bug.cgi?id=540921 OK, ta. Andrew. From jnovy at redhat.com Wed Dec 23 09:08:12 2009 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 23 Dec 2009 10:08:12 +0100 Subject: Texlive schemes? In-Reply-To: <1261497801.2249.8.camel@choeger5.umpa.netz> References: <1261478752.2249.3.camel@choeger5.umpa.netz> <20091222140933.GA14307@dhcp-lab-133.englab.brq.redhat.com> <1261497801.2249.8.camel@choeger5.umpa.netz> Message-ID: <20091223090812.GA31058@dhcp-lab-133.englab.brq.redhat.com> On Tue, Dec 22, 2009 at 05:03:21PM +0100, Christoph H?ger wrote: > Am Dienstag, den 22.12.2009, 15:09 +0100 schrieb Jindrich Novy: > > On Tue, Dec 22, 2009 at 11:45:52AM +0100, Christoph H?ger wrote: > > > Hi all, > > > > > > after texlive 2009 crashed my latex compiling process one day before I > > > wanted to print my dipl-thesis (kpsewhich hanging indefinitely), I > > > erased all texlive* files. > > > > > > From my last installation experience I learned that installing only > > > texlive leaves you with a non-working system (for my needs), so I wanted > > > to simplify things by installing the full or medium scheme. > > > > > > [choeger at choeger5 ~]$ LC_ALL=C sudo yum install texlive-scheme-full > > > Loaded plugins: presto, refresh-packagekit > > > Setting up Install Process > > > No package texlive-scheme-full available. > > > Nothing to do > > > > > > Shouldn't that work? > > > > Confirmed. I rewrote the the upstream -> Fedora repo script from > > scratch where an error occured. It is fixed so please try again now. > > Installation seems to work now, but the installation of > > texlive-kpathsea-2009-3.16044.fc12.noarch > > (and possibly much more packages) hangs because kpsewhich hangs forever > (using 100% cpu). This is upstream bug in kpathsea and the repo is now updated with the fixed kpathsea. > > Do you have any clue whats going on? Any chance to get this fixed before > christmas? It is now fixed. Please do the following: rpm -qa | grep texlive-kpathsea | xargs rpm -e --noscripts --nodeps followed by yum update and you should get working TeX Live environment back again. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From fedora at alexhudson.com Wed Dec 23 10:07:48 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Wed, 23 Dec 2009 10:07:48 +0000 Subject: New covenant published (was: Re: moonlight and the new covenant) In-Reply-To: <4B2CB2FE.902@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> Message-ID: <4B31EBF4.5010906@alexhudson.com> On 19/12/09 11:03, Alex Hudson wrote: >> The covenant is published as far as I can see here: >> > > > No, that's the previous one which was not good enough. > > The new one is not yet published. Correction: it's now published here - http://www.microsoft.com/interop/msnovellcollab/newmoonlight.mspx To my untrained eye, it seems to cover Moonlight fully, the termination clause doesn't work retroactively, it includes coverage for the Mono portions and it seems to apply for everyone - hopefully this is a good thing. It seems to remove previous objections about Novell-only-ness. Thanks Alex. From sergio.pasra at gmail.com Wed Dec 23 14:57:50 2009 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Wed, 23 Dec 2009 15:57:50 +0100 Subject: License change: sextractor Message-ID: <89b36810912230657q32d728c5h25348441df71913c@mail.gmail.com> Hi all: the new version of sextractor in rawhide (2.8.6) will have a CeCILL license. Previously, sextractor was distributed under GPLv2 Regards From rawhide at fedoraproject.org Wed Dec 23 15:17:20 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 23 Dec 2009 15:17:20 +0000 Subject: rawhide report: 20091223 changes Message-ID: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Compose started at Wed Dec 23 08:15:12 UTC 2009 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.8.1-3.fc13.i686 requires libwv-1.2.so.4 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 1:libabiword-2.8.1-3.fc13.i686 requires libwv-1.2.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.8.1-3.fc13.x86_64 requires libwv-1.2.so.4()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) 1:libabiword-2.8.1-3.fc13.x86_64 requires libwv-1.2.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package clac Command Line Advanced Calculator New package emacs-goodies Miscellaneous add-ons for Emacs New package emacs-haskell-mode Haskell editing mode for Emacs New package gdata-sharp .NET library for the Google Data API New package ghc-HUnit Haskell HUnit library New package hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator New package kpilot Sync PIM data with PalmOS devices New package openvas-libnasl OpenVAS Libraries module for support of the NASL scripting language New package perl-Pod-PseudoPod Framework for extending the POD tags for book manuscripts New package pki-util Dogtag Certificate System - PKI Utility Framework New package planner2html Convert planner files to html New package poky-scripts Poky platform builder utility scripts New package python-djblets A collection of useful classes and functions for Django New package qjson A qt-based library that maps JSON data to QVariant objects New package qutim Multiprotocol (ICQ, Jabber, IRC etc) instant messenger with modern Qt4 interface New package rubygem-columnize Sorts an array in column order New package rubygem-linecache Caches (Ruby source) files New package rubygem-ruby-net-ldap A full-featured pure-Ruby LDAP client New package shared-color-targets Shared color targets for creating color profiles New package testng Java-based testing framework New package yum-langpacks Langpacks plugin for yum New package zaz A puzzle game where the player has to arrange balls in triplets Removed package perl-Class-XSAccessor-Array Removed package perl-Parse-CPAN-Meta Updated Packages: R-2.10.1-1.fc13 --------------- * Mon Dec 21 2009 Tom "spot" Callaway - 2.10.1-1 - update to 2.10.1 - enable static html pages abiword-2.8.1-3.fc13 -------------------- * Mon Dec 21 2009 Peter Robinson - 1:2.8.1-3 - Rebuild against new libwv alex-2.3.1-7.fc13 ----------------- * Mon Dec 21 2009 Jens Petersen - 2.3.1-7 - build dynamically with ghc-6.12.1 alexandria-0.6.6-0.3.beta1.fc13 ------------------------------- * Wed Dec 23 2009 Mamoru Tasaka - 0.6.6-0.3.beta1 - Try 0.6.6 beta1 atk-1.29.4-2.fc13 ----------------- * Tue Dec 22 2009 Matthias Clasen - 1.29.4-1 - Update to 1.29.4 * Tue Dec 22 2009 Matthias Clasen - 1.29.4-2 - Enable introspection blitz-0.9-13.fc13 ----------------- * Tue Dec 22 2009 Sergio Pascual - 0.9-13 - Using pregenerated documentation brasero-2.29.4-1.fc13 --------------------- * Tue Dec 22 2009 Matthias Clasen 2.29.4-1 - Update to 2.29.4 cpphs-1.9-3.fc13 ---------------- * Wed Dec 23 2009 Jens Petersen - 1.9-3 - devel package requires shared library not base * Tue Dec 22 2009 Jens Petersen - 1.9-2 - update spec for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 - drop -dynamic for now since Cabal chokes with prof looking for p_dyn - use ghc-cpphs for ghc_gen_filelists crda-1.1.0_2009.11.25-5.fc13 ---------------------------- * Mon Dec 21 2009 John W. Linville 1.1.0_2009.11.25-3 - Add man page for setregdomain (from Andrew Hecox ) - Change $RPM_BUILD_ROOT to /builddir/build/BUILDROOT/crda-1.1.0_2009.11.25-5.fc13.x86_64 * Mon Dec 21 2009 John W. Linville 1.1.0_2009.11.25-4 - Add libgcrypt and libnl to Requires * Mon Dec 21 2009 John W. Linville 1.1.0_2009.11.25-5 - Remove unnecessary explicit Requries for libgcrypt and libnl -- oops! createrepo-0.9.8-3.fc13 ----------------------- * Tue Dec 22 2009 Seth Vidal - 0.9.8-3 - patch to latest HEAD from upstream cscope-15.6-8.fc12 ------------------ * Sat Dec 19 2009 Neil Horman 15.6-8 - Added back missing help/version options (bz 528463) * Fri Dec 18 2009 Neil Horman 15.6-7 - Fixed adjustment of argv that led to bad commandline behavior (bz 547023) - Added missing linemode operations to parse_options (bz 546993) cups-1.4.2-20.fc13 ------------------ * Tue Dec 22 2009 Tim Waugh - 1:1.4.2-20 - Fixed ipp authentication for servers requiring authentication for IPP-Get-Printer-Attributes (bug #548873, STR #3458). * Mon Dec 21 2009 Tim Waugh - 1:1.4.2-19 - Ensure proper thread-safety in gnutls's use of libgcrypt (bug #544619). cvsps-2.2-0.5.b1.fc13 --------------------- * Tue Dec 22 2009 Ville Skytt? - 2.2-0.5.b1 - Build with -DLINUX to fix --cvs-direct on 64-bit platforms (#539765). - Use patch instead of sed for man page fixes. cyrus-imapd-2.3.16-1.fc13 ------------------------- * Tue Dec 22 2009 Michal Hlavinka - 2.3.16-1 - updated to 2.3.16 debmirror-2.4-1.fc13 -------------------- * Mon Dec 21 2009 Ruben Kerkhof 2.4-1 - New upstream release - Change license to GPLv2+ according to copyright file digikam-1.0.0-1.fc13 -------------------- * Mon Dec 21 2009 Rex Dieter - 1.0.0-1 - digikam-1.0.0 * Mon Nov 30 2009 Rex Dieter - 1.0.0-0.11.rc - digikam-1.0.0-rc dovecot-1.2.9-2.fc13 -------------------- * Tue Dec 22 2009 Michal Hlavinka - 1:1.2.9-2 - sieve updated to 0.1.14 - managesieve updated to 0.11.10 ecj-3.4.2-7.fc13 ---------------- * Mon Dec 21 2009 Deepak Bhole - 1:3.4.2-7 - Fix RHBZ# 490936. If CLASSPATH is not set, add . to default classpath. eclipse-3.5.1-27.fc13 --------------------- * Tue Dec 22 2009 Andrew Overholt 1:3.5.1-26 - Backport eclipse-build patch for e.o#291128. * Tue Dec 22 2009 Andrew Overholt 1:3.5.1-27 - Fix patch application. emelfm2-0.7.1-1.fc13 -------------------- * Mon Dec 21 2009 Christoph Wickert - 0.7.1-1 - Update to 0.7.1 empathy-2.29.4-1.fc13 --------------------- * Mon Dec 21 2009 Brian Pepple - 2.29.4-1 - Update to 2.29.4. evince-2.29.4-1.fc13 -------------------- * Tue Dec 22 2009 Matthias Clasen - 2.29.4-1 - Update to 2.29.4 evolution-2.29.4-2.fc13 ----------------------- * Tue Dec 22 2009 Matthew Barnes - 2.29.4-2.fc13 - Update Scrollkeeper and Icon Cache scriptlets to conform to guidelines. (see: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets) * Mon Dec 21 2009 Milan Crha - 2.29.4-1.fc13 - Update to 2.29.4 - Remove patch for missing m4 files from tarball (fixed upstream). evolution-data-server-2.29.4-1.fc13 ----------------------------------- * Mon Dec 21 2009 Milan Crha - 2.29.4-1.fc13 - Update to 2.29.4 - Remove patch for GNOME bug #487988 (fixed upstream). evolution-exchange-2.29.4-1.fc13 -------------------------------- * Mon Dec 21 2009 Milan Crha - 2.29.4-1.fc13 - Update to 2.29.4 evolution-mapi-0.29.4-1.fc13 ---------------------------- * Mon Dec 21 2009 Milan Crha - 0.29.4-1 - Update to 0.29.4 fife-2009.0-0.27.r3111svn.fc13 ------------------------------ * Sat Dec 12 2009 Simon Wesp - 2009.0-0.27.r3111svn - Update to r3111 file-roller-2.29.3-1.fc13 ------------------------- * Tue Dec 22 2009 Matthias Clasen 2.29.3-1 - Update to 2.29.3 firefox-3.6.1-0.7.b5.fc13 ------------------------- * Mon Dec 21 2009 Martin Stransky - 3.6.1-0.7.b4 - Update to 3.6.1 Beta 5 fsarchiver-0.6.2-1.fc13 ----------------------- * Tue Dec 22 2009 Adel Gadllah - 0.6.2-1 - Update to 0.6.2 - Apply fix as requested by upstream gamin-0.1.10-6.fc13 ------------------- * Mon Dec 21 2009 Tomas Bzatek - 0.1.10-6 - Cleanup for package review (#225776) gcalctool-5.29.4-1.fc13 ----------------------- * Tue Dec 22 2009 Matthias Clasen - 5.29.4-1 - Update to 5.29.4 gcc-4.4.2-20.fc13 ----------------- * Tue Dec 22 2009 Jakub Jelinek 4.4.2-20 - fix MEM_SIZE of reload created stack slots (#548825, PR rtl-optimization/42429) - remove gappletviewer, gcjwebplugin and related files for F13 (#548783) - fix addition of one character long filenames in fastjar (#549493) * Thu Dec 17 2009 Jakub Jelinek 4.4.2-18 - update from gcc-4_4-branch - PRs c++/42387 - another C++ virtual dtors fix (PR c++/42386) - VTA mode and COND_EXEC fixes (PR debug/41679) - fix ICE in chrec_convert_1 (#547775) - fix debuginfo for optimized out TLS vars - use DW_AT_location with DW_OP_addr + DW_OP_stack_value instead of DW_AT_const_value with address in it, use DW_OP_addr + DW_OP_stack_value instead of DW_OP_implicit_value with address (#546017) * Mon Dec 14 2009 Jakub Jelinek 4.4.2-17 - propagate TREE_NOTHROW/TREE_READONLY/DECL_PURE_P from ipa-pure-const and EH opt to all same body aliases (#547286) - don't emit DWARF location list entries with no location or DW_AT_location with empty blocks (PR debug/41473) - fix up AMD LWP support - don't crash when mangling C++ decls inside of middle-end generated functions (PR c++/41183) * Fri Dec 11 2009 Jakub Jelinek 4.4.2-16 - update from gcc-4_4-branch - PRs c++/27425, c++/34274, c++/42301, fortran/42268, java/41991, libstdc++/42273, rtl-optimization/41574, target/41196, target/41939 target/42263 * Wed Dec 09 2009 Jakub Jelinek 4.4.2-15 - VTA backports - PRs debug/42166, debug/42234, debug/42244, debug/42299 - fix handling of C++ COMDAT virtual destructors - some x86/x86_64 FMA4, XOP, ABM and LWP fixes - fix a decltype handling bug in templates (PR c++/42277) * Fri Dec 04 2009 Jakub Jelinek 4.4.2-14 - update from gcc-4_4-branch - PRs libstdc++/42261, middle-end/42049 - backport C++0x ICE fix from trunk (PR c++/42266) - fortran !$omp workshare improvements (PR fortran/35423) - FMA4 and XOP fixes * Wed Dec 02 2009 Jakub Jelinek 4.4.2-12 - update from gcc-4_4-branch - PRs c++/42234, fortran/41278, fortran/41807, fortran/42162, target/42113, target/42165 - don't ICE on -O256 (#539923) - fix -mregnames on ppc/ppc64 - optimize even COMDAT constructors and destructors without virtual bases (PR c++/3187) * Wed Dec 02 2009 Jakub Jelinek 4.4.2-13 - fix security issues in libltdl bundled within libgcj (CVE-2009-3736) * Mon Nov 23 2009 Jakub Jelinek 4.4.2-11 - update from gcc-4_4-branch - PRs c++/42059, c++/42061, libgfortran/42090 - VTA backports - PRs debug/41886, debug/41888, debug/41926, tree-optimization/42078 - optimize non-COMDAT constructors and destructors without virtual bases by making the base and complete ctor or dtor aliases of each other (PR c++/3187) * Sat Nov 14 2009 Jakub Jelinek 4.4.2-10 - update from gcc-4_4-branch - PRs c++/21008, c++/37037, c++/41972, c++/41994, middle-end/40946, middle-end/42029 - VTA backports - PR middle-end/41930 - optimize deleting destructors for size (PR c++/3187) - try to avoid file Requires by requiring package%{?_isa} (#533947) gdb-7.0-13.fc12 --------------- * Mon Dec 21 2009 Jan Kratochvil - 7.0-12.fc12 - Workaround build on native ppc64 host. - More RHEL-5 compatibility updates. - Disable warning messages new for gdb-6.8+ for RHEL-5 backward compatibility. - Workaround RHEL-5 kernels for detaching SIGSTOPped processes (BZ 498595). - Serialize the testsuite output to keep the order for regression checks. - Re-enable python for all non-ppc* arches. - More gcc44 stack exceptions when running the testsuite on RHEL-5. - Fix backward compatibility with G++ 4.1 namespaces "::". - Fix regression on re-setting the single ppc watchpoint slot. - Update snapshot of FSF gdb-7.0.x branch. - Backport fix of dcache invalidation locking up GDB on ppc64 targets. * Mon Dec 21 2009 Jan Kratochvil - 7.0-13.fc12 - [pie] Fix a race in testcase gdb.base/valgrind-db-attach.exp. - Fix regression by python on ia64 due to stale current frame. - Disable python iff RHEL-5 && (Brew || ppc64). * Fri Dec 18 2009 Jan Kratochvil - 7.0-11.fc12 - [pie] Fix general ppc64 regression due to a function descriptors bug. - [pie] Fix also keeping breakpoints disabled in PIE mode. - Import upstream -completion crash fix. - Drop some unused patches from the repository. - More RHEL-5 build compatibility updates. - Use gfortran44 when running the testsuite on RHEL-5. - Disable python there due to insufficient ppc multilib. - Fix orphanripper hangs and thus enable it again. * Mon Dec 14 2009 Jan Kratochvil - 7.0-10.fc12 - Make gdb-6.3-rh-testversion-20041202.patch to accept both RHEL and Fedora GDB. - Adjust BuildRequires for Fedora-12, RHEL-6 and RHEL-5 builds. - [vla] Fix compatibility of dynamic arrays with iFort (BZ 514287). - Fix stepping through OMP parallel Fortran sections (BZ 533176). - New fix of bp conditionals [bp_location-accel] regression (BZ 538626). gdm-2.29.4-1.fc13 ----------------- * Tue Dec 22 2009 Matthias Clasen - 2.29.4-1 - Update to 2.29.4 ghc-X11-1.5.0.0-1.fc13 ---------------------- * Mon Dec 21 2009 Yaakov M. Nemoy - 1.5.0.0-1 - updated to latest upstream - updates spec to use shared libraries and new ghc ghc-X11-xft-0.3-5.fc13 ---------------------- * Wed Dec 23 2009 Jens Petersen - 0.3-5 - update packaging for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 - rebuild for ghc-X11-1.5.0.0 ghc-editline-0.2.1.0-12.fc13 ---------------------------- * Tue Dec 22 2009 Jens Petersen - 0.2.1.0-12 - build for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 ghc-time-1.1.2.4-3.fc13 ----------------------- * Wed Dec 23 2009 Jens Petersen - 1.1.2.4-3 - update packaging for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 - note part of haskell-platform ghc-utf8-string-0.3.6-1.fc13 ---------------------------- * Wed Dec 23 2009 Jens Petersen - 0.3.6-1 - update to 0.3.6 - update packaging for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 gir-repository-0.6.5-4.fc13 --------------------------- * Tue Dec 22 2009 Matthias Clasen 0.6.5-4 - Drop atk and gtk gkrellm-2.3.3-1.fc13 -------------------- * Tue Dec 22 2009 Hans de Goede 2.3.3-1 - New upstream release 2.3.3 - Fixes the gkrellm client crash when the gkrellm server reboots (#545327) - Drop a number of upstreamed patches glib2-2.23.1-1.fc13 ------------------- * Sun Dec 20 2009 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 glpk-4.41-1.fc13 ---------------- * Tue Dec 22 2009 Conrad Meyer 4.41-1 - Bump to 4.41. gnome-desktop-2.29.4-1.fc13 --------------------------- * Tue Dec 22 2009 Matthias Clasen - 2.29.4-1 - Update to 2.29.4 gnome-do-0.8.3.1-1.fc13 ----------------------- * Wed Nov 18 2009 Juan Rodriguez - 0.8.2-5 - Restored "Docky", but removed Icon Zoom due to potential violation of patents. gnome-games-2.29.4-1.fc13 ------------------------- * Tue Dec 22 2009 Matthias Clasen 2.29.4-1 - Update to 2.29.4 gnome-terminal-2.29.1-1.fc13 ---------------------------- * Tue Dec 22 2009 Matthias Clasen - 2.29.1-1 - Update to 2.29.1 gnote-0.6.3-2.fc13 ------------------ * Tue Dec 22 2009 Rahul Sundaram - 0.6.3-2 - Several patches from upstream for additional translations - Gnote now confirm to XDG specification gobject-introspection-0.6.7-1.fc13 ---------------------------------- * Tue Dec 22 2009 Matthias Clasen - 0.6.7-1 - Update to 0.6.7 grsync-0.9.3-1.fc13 ------------------- * Tue Dec 22 2009 Sebastian Vahl - 0.9.3-1 - new upstream release gtk-doc-1.13-1.fc13 ------------------- * Tue Dec 22 2009 Matthias Clasen - 1.13-1 - Update to 1.13 gtk2-2.19.2-1.fc13 ------------------ * Mon Dec 21 2009 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 gtkhtml3-3.29.4-1.fc13 ---------------------- * Mon Dec 21 2009 Milan Crha - 3.29.4-1.fc13 - Update to 3.29.4 hplip-3.9.12-1.fc13 ------------------- * Tue Dec 22 2009 Tim Waugh - 3.9.12-1 - 3.9.12. No longer need hpcups-plugin patch. hscolour-1.15-3.fc13 -------------------- * Wed Dec 23 2009 Jens Petersen - 1.15-2 - update spec for ghc-6.12.1 - added shared library support: needs ghc-rpm-macros 0.3.1 * Wed Dec 23 2009 Jens Petersen - 1.15-3 - devel package requires shared library not base hunspell-1.2.8-14.fc13 ---------------------- * Mon Dec 21 2009 Caolan McNamara - 1.2.8-14 - Preserve timestamps hyperestraier-1.4.13-6.fc13 --------------------------- * Wed Dec 23 2009 Mamoru Tasaka - 1.4.13-6 - F-13: rebuild for new perl incron-0.5.9-1.fc13 ------------------- * Mon Dec 21 2009 Ruben Kerkhof 0.5.9-1 - Upstream released new version indi-apogee-1.0-4.fc13 ---------------------- * Tue Dec 22 2009 Sergio Pascual - 1.0-4 - Adding libindi-devel to build requires iw-0.9.18-4.fc13 ---------------- * Mon Dec 21 2009 John W. Linville 0.9.18-3 - Add libnl to Requires * Mon Dec 21 2009 John W. Linville 0.9.18-4 - Remove unnecessary explicit Requires of libnl -- oops! * Fri Dec 18 2009 John W. Linville 0.9.18-2 - BuildRequires kernels-headers instead of kernel-devel kde-plasma-networkmanagement-0.9-0.9.20091220.fc13 -------------------------------------------------- * Mon Dec 21 2009 Rex Dieter 1:0.9-0.9.20091220svn - 20091220 snapshot - -libs: use/tighten qt4/kdelibs4 deps kde-plasma-stasks-0.5.1-7.fc13 ------------------------------ * Tue Dec 22 2009 Sven Lankes 0.5.1-7 - Rebuild against KDE SC 4.3.85 kde-plasma-translatoid-1.1-1.fc13 --------------------------------- * Tue Dec 22 2009 Eli Wapniarski 1.1 -1.1 - 1.1beta - MAJOR CORRECTION - Now Translatoid use extender - Add Reminder extender to remind you some word after clicking on the star - Replace parsing by Json parsing. YOU NEED TO INSTALL libqjson - Clear some code and probably add some new bug.. :) - If you have some probs, contact me! -1.1 - Add new language - Afrikaans - Albanais - Albanais - Belarusian - Irish - Icelandic - Macedonian - Malaysia - Maltese - Persan - Swahili - Turkish kde-plasma-yawp-0.3.2-2.fc13 ---------------------------- * Tue Dec 22 2009 Rex Dieter - 0.3.2-2 - rebuild against kde-4.4beta1 (#549620) kdepim-4.3.85-3.fc13 -------------------- * Mon Dec 21 2009 Rex Dieter - 4.3.85-2 - Obsoletes/Provides: bilbo - %description: +blogilo * Mon Dec 21 2009 Rex Dieter - 4.3.85-3 - Requires: kdepim-runtime (unconditionally) kipi-plugins-1.0.0-1.fc13 ------------------------- * Tue Dec 22 2009 Rex Dieter 1.0.0-1 - kipi-plugins-1.0.0 * Wed Dec 02 2009 Rex Dieter 0.9.0-1 - kipi-plugins-0.9.0 kpackagekit-0.5.2-2.fc13 ------------------------ * Thu Dec 10 2009 Steven M. Parrish - 0.5.2-2 - Clean up spec file * Mon Dec 07 2009 Steven M. Parrish - 0.5.2-1 - New upstream release * Thu Nov 19 2009 Steven M. Parrish - 0.5.1.1-2 - Remove no longer need patches krb5-1.7-14.fc13 ---------------- * Mon Dec 21 2009 Nalin Dahyabhai - 1.7-14 - refresh patch for #542868 from trunk * Thu Dec 10 2009 Nalin Dahyabhai - move man pages that live in the -libs subpackage into the regular %{_mandir} tree where they'll still be found if that package is the only one installed (#529319) ktorrent-4.0-0.1.beta1.fc13 --------------------------- * Mon Dec 21 2009 Rex Dieter - 4.0-0.1.beta1 - ktorrent-4.0beta1 libgcrypt-1.4.5-1.fc13 ---------------------- * Mon Dec 21 2009 Tomas Mraz 1.4.5-1 - workaround for build on S390 (#548825) - spec file cleanups - upgrade to new minor upstream release libgdiplus-2.6-2.fc13 --------------------- * Wed Dec 16 2009 Paul F. Johnson 2.6-2 - Update to 2.6 libguestfs-1.0.80-9.fc13 ------------------------ * Mon Dec 21 2009 Richard W.M. Jones - 1.0.80-9 - Generate additional requires for supermin (RHBZ#547496). libgweather-2.29.4-1.fc13 ------------------------- * Tue Dec 22 2009 Matthias Clasen 2.29.4-1 - Update to 2.29.4 libindi-0.6-9.fc13 ------------------ * Tue Dec 22 2009 Sergio Pascual - 0.6-9 - Static library moved to its own subpackage linuxwacom-0.8.2.2-17.fc12 -------------------------- * Tue Dec 01 2009 Peter Hutterer 0.8.2.2-17 - linuxwacom-0.8.2-2-wacdump-timeout.patch: time out the select if no reply is received (#538096) lpsolve-5.5.0.15-3.fc13 ----------------------- * Mon Dec 21 2009 Caol?n McNamara - 5.5.0.15-3 - Preserve timestamps mailman-2.1.12-13.fc13 ---------------------- * Tue Dec 22 2009 Daniel Novotny 3:2.1.12-13 - the service is now not on by default (change for merge review, #226117) mailx-12.4-6.fc13 ----------------- * Mon Dec 21 2009 Ivana Hutarova Varekova - 12.4-6 - fix source tag man-pages-ru-0.97-7.fc13 ------------------------ * Fri Dec 18 2009 Ivana Hutarova Varekova - 0.97-7 - fix the source tags maven-archiver-2.2-3.fc13 ------------------------- * Mon Dec 21 2009 Alexander Kurtakov 0:2.2-3 - BR maven-surefire-provider-junit. maven-doxia-1.0-0.8.a10.4.fc13 ------------------------------ * Mon Dec 21 2009 Alexander Kurtakov 0:1.0-0.8.a10.2 - BR maven-surefire-provider-junit. * Mon Dec 21 2009 Alexander Kurtakov 0:1.0-0.8.a10.3 - BR maven2-plugin-assembly. * Mon Dec 21 2009 Alexander Kurtakov 0:1.0-0.8.a10.4 - BR maven2-plugin-plugin. maven-doxia-sitetools-1.0-0.2.a10.2.fc13 ---------------------------------------- * Mon Dec 21 2009 Alexander Kurtakov 1.0-0.2.a10.2 - BR maven-surefire-provider-junit. maven-scm-1.2-4.fc13 -------------------- maven-shared-8-4.fc13 --------------------- * Thu Nov 26 2009 Lubomir Rintel 8-4 - Fix build maven2-common-poms-1.0-12.fc13 ------------------------------ * Tue Dec 22 2009 Alexander Kurtakov 0:1.0-12 - Drop common-codec and commons-digester. Packaged with the jars now. maven2-plugin-shade-1.2.2-2.fc13 -------------------------------- * Mon Dec 21 2009 Alexander Kurtakov 0:1.2.2-1 - Update to 1.2.2 upstream release. * Mon Dec 21 2009 Alexander Kurtakov 0:1.2.2-2 - BR/R maven-shared-dependency-tree. mc-4.7.0-0.9.pre4.20091221git.fc13 ---------------------------------- * Mon Dec 21 2009 Jindrich Novy 4.7.0-0.9.pre4.20091221git - provide yum-repo.syntax (#549014) - avoid occasional crash while reading panels (#548987) - remove duplicates from filelist - enable mcvfs, disable rpath mingw32-nsiswrapper-5-1.fc13 ---------------------------- * Mon Dec 21 2009 Richard W.M. Jones - 5-1 - Add dnsapi.dll to list of system libraries (RHBZ#548965). mod_mono-2.6-2.fc13 ------------------- * Tue Dec 22 2009 Paul F. Johnson 2.6-2 - Bump to 2.6 release mono-2.6.1-1.fc13 ----------------- * Mon Dec 21 2009 Paul F. Johnson 2.6.1-1 - Minor fixes * Wed Dec 16 2009 Paul F. Johnson 2.6-4 - Add in the version 4 previews (subpackage) - Add in new soft debugger mono-basic-2.6-2.fc13 --------------------- * Wed Dec 16 2009 Paul F. Johnson 2.6-2 - Bump to 2.6 release mono-debugger-2.6-2.fc13 ------------------------ * Wed Dec 16 2009 Paul F. Johnson 2.6-2 - Bump to 2.6 release * Sat Oct 03 2009 Paul F. Johnson 2.6-1 - Bump to 2.6 preview 1 mono-tools-2.6.1-1.fc13 ----------------------- * Wed Dec 23 2009 Paul F. Johnson - 2.6.1-1 - Bump to the 2.6.1 release - Removed webkit patch monodevelop-2.2-1.fc13 ---------------------- * Tue Dec 22 2009 Paul F. Johnson 2.2-1 - Bump to 2.2 release - Fix unbundle-cecil patch - Copy system mono-cecil to build/bin mousetweaks-2.29.4-1.fc13 ------------------------- * Tue Dec 22 2009 Matthias Clasen 2.29.4-1 - Update to 2.29.4 nautilus-2.29.1-1.fc13 ---------------------- * Fri Dec 18 2009 Tomas Bzatek - 2.29.1-1 - Update to 2.29.1 net-snmp-5.5-7.fc13 ------------------- * Mon Dec 21 2009 Jan Safranek - 1:5.5-7 - fix crash with interfaces without broadcast addresses (like OpenVPN's tun0) (#544849) net-tools-1.60-100.fc13 ----------------------- * Mon Dec 21 2009 Jiri Popelka - 1.60-100 - Move hostname to separate package obexd-0.21-1.fc13 ----------------- * Tue Dec 22 2009 Bastien Nocera 0.21-1 - Update to 0.21 ocsinventory-agent-1.1.1-1.fc13 ------------------------------- * Tue Dec 22 2009 Remi Collet 1.1.1-1 - update to 1.1.1 openoffice.org-3.2.0-8.2.fc13 ----------------------------- * Tue Dec 22 2009 Caol?n McNamara - 1:3.2.0-8.2 - Resolves: rhbz#545824 bustage in writer with emboldened fonts opensc-0.11.12-1.fc13 --------------------- * Mon Dec 21 2009 Kalev Lember - 0.11.12-1 - new upstream version - replaced %define with %global - BR clean up from items not applicable to current Fedora releases opensips-1.6.1-1.fc13 --------------------- * Tue Dec 22 2009 John Khvatov - 1.6.1-1: - Updated to 1.6.1 - Dropped upstreamed patches openslide-2.3.1-1.fc13 ---------------------- * Mon Dec 21 2009 Adam Goode - 2.3.1-1 - New upstream release + Support for generic tiled TIFF + Bug fixes + Try to be less chatty with TIFF output * Thu Nov 12 2009 Adam Goode - 2.2.1-1 - New upstream release + Fix thread safety problems from 2.2.0 openssh-5.3p1-13.fc13 --------------------- * Mon Dec 21 2009 Jan F. Chadima - 5.3p1-13 - Update the audit patch orca-2.29.4-1.fc13 ------------------ * Tue Dec 22 2009 Matthias Clasen - 2.29.4-1 - Update to 2.29.4 pcsc-lite-1.5.5-2.fc13 ---------------------- * Mon Dec 21 2009 Kalev Lember - 1.5.5-2 - Require -libs subpackage from main pcsc-lite package - Build -doc subpackage as noarch - Dropped --enable-runpid configure option which was removed in 1.4.99 - Dropped obsolete provides - Spec file cleanup pem-0.7.8-1.fc12 ---------------- * Tue Sep 15 2009 P J P - 0.7.8-1 - Pem became an official GNU package, GNU Pem. perl-5.10.1-109.fc13 -------------------- * Tue Dec 22 2009 Marcela Ma?l??ov? - 4:5.10.1-109 - 547656 CVE-2009-3626 perl: regexp matcher crash on invalid UTF-8 characters - 549306 version::Internals should be packaged in perl-version subpackage - Parse-CPAN-Meta updated and separate package is dead * Mon Dec 21 2009 Chris Weyl - 4:5.10.1-107 - subpackage parent and Parse-CPAN-Meta; add them to core's dep list perl-Bio-Graphics-1.994-2.fc13 ------------------------------ * Tue Dec 22 2009 Alex Lancaster - 1.994-1 - Update to upstream 1.994 * Tue Dec 22 2009 Alex Lancaster - 1.994-2 - Fix disabling of tests perl-Class-XSAccessor-1.05-4.fc13 --------------------------------- * Tue Dec 22 2009 Marcela Ma?l??ov? - 1.05-3 - Class::XSAccessor::Array became a part of this package - fixes conflict of man * Tue Dec 22 2009 Marcela Ma?l??ov? - 1.05-4 - rebuild with obsoletes in spec perl-GD-SVG-0.33-1.fc13 ----------------------- * Tue Dec 22 2009 Alex Lancaster - 0.33-1 - Update to upstream 0.33 perl-Verilog-Perl-3.223-1.fc13 ------------------------------ * Mon Dec 21 2009 Chitlesh Goorah 3.223-1 - New upstream release perl-mecab-0.98-2.fc13 ---------------------- * Wed Dec 23 2009 Mamoru Tasaka - 0.98-2 - F-13: rebuild for new perl planner-0.14.4-12.fc13 ---------------------- * Mon Dec 21 2009 Caol?n McNamara - 0.14.4-12 - Resolves: rhbz#548830 crash in print preview plexus-ant-factory-1.0-0.4.a2.1.2.fc13 -------------------------------------- * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.4.a2.1.1 - Update to 1.0 alpha 2.1. - Drop gcj_support. * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.4.a2.1.2 - BR maven-doxia-sitetools. plexus-digest-1.1-1.fc13 ------------------------ * Tue Dec 22 2009 Alexander Kurtakov 0:1.0-10 - Drop not needed depmap. - Build with maven. * Tue Dec 22 2009 Alexander Kurtakov 0:1.1-1 - Update to upstream 1.1. plexus-registry-1.0-0.3.a3.fc13 ------------------------------- * Mon Nov 23 2009 Alexander Kurtakov 0:1.0-0.3.a3 - BR maven-doxia-sitetools. plexus-velocity-1.1.8-5.fc13 ---------------------------- * Tue Dec 22 2009 Alexander Kurtakov 0:1.1.8-1 - Update to upstream 1.1.8. * Tue Dec 22 2009 Alexander Kurtakov 0:1.1.8-2 - BR plexus-maven-plugin. * Tue Dec 22 2009 Alexander Kurtakov 0:1.1.8-3 - BR maven-doxia-sitetools. * Tue Dec 22 2009 Alexander Kurtakov 0:1.1.8-4 - BR maven-surefire-provider-junit. * Tue Dec 22 2009 Alexander Kurtakov 0:1.1.8-5 - BR java-devel 1.6. plymouth-0.8.0-0.2009129.1.fc13 ------------------------------- * Tue Dec 22 2009 Dave Airlie 0.8.0-0.2009129.1 - rebuild for API bump in libdrm policycoreutils-2.0.78-7.fc13 ----------------------------- * Fri Dec 18 2009 Dan Walsh 2.0.78-7 - Fixes to sandbox man page postgis-1.4.1-1.fc13 -------------------- * Sun Dec 20 2009 Devrim G?ND?Z - 1.4.1-1 - Update to 1.4.1 psacct-6.5.1-1.fc13 ------------------- * Fri Dec 18 2009 Ivana Hutarova Varekova - 6.5-1 - update to 6.5 remove unnecessary patches, spec file changes pybackpack-0.5.7-3.fc13 ----------------------- * Tue Dec 22 2009 Adam Miller - 0.5.7-3 - Patch to fix default selection of user backup image (also part of BZ 538193) * Fri Dec 18 2009 Adam Miller - 0.5.7-2 - Patch to supplement upstream release as a proposed solution to BZ 538193 pycryptopp-0.5.17-5.fc13 ------------------------ * Mon Dec 21 2009 Ruben Kerkhof 0.5.17-5 - Rebuild for new cryptopp pypar-2.1.4_94-1.fc13 --------------------- * Tue Dec 22 2009 Jussi Lehtola - 2.1.4_94-1 - Update to 2.1.4_94, fixing MPICH2 build issue. * Mon Dec 21 2009 Jussi Lehtola - 2.1.3_91-1 - Implement MPI guidelines, adding MPICH2 package. - Update to 2.1.3_91. python-virtualenv-1.4.3-1.fc13 ------------------------------ * Tue Dec 22 2009 Steve 'Ashcrow' Milner - 1.4.3-1 - Updated for upstream release. qdbm-1.8.77-6.fc13 ------------------ * Wed Dec 23 2009 Mamoru Tasaka - 1.8.77-6 - F-13: rebuild for new perl qle-0.0.17-2.fc13 ----------------- * Mon Dec 21 2009 Lucian Langa - 0.0.17-2 - fix build requires qt3-3.3.8b-29.fc13 ------------------ * Tue Dec 22 2009 Rex Dieter - 3.3.8b-29 - sane defaults (#549820) rainbow-0.8.6-1.fc13 -------------------- * Mon Dec 21 2009 Michael Stone - 0.8.6-1 - Michael Stone (many): Helpers for resume and gc. Bug fixes. ... roxterm-1.16.3-1.fc13 --------------------- * Tue Dec 22 2009 Sebastian Vahl - 1.16.3-1 - new upstream release: 1.16.3 rubygem-facets-2.8.0-2.fc13 --------------------------- * Tue Dec 22 2009 Jeroen van Meeuwen - 2.8.0-2 - New upstream version rubygem-git-1.2.5-1.fc13 ------------------------ * Tue Dec 22 2009 Jeroen van Meeuwen - 1.2.5-1 - New upstream version rubygem-highline-1.5.1-1.fc13 ----------------------------- * Tue Dec 22 2009 Jeroen van Meeuwen - 1.5.1-1 - New upstream version rygel-0.4.8-1.fc13 ------------------ * Sun Nov 22 2009 Peter Robinson 0.4.8-1 - Update to 0.4.8 sbcl-1.0.32-2.fc13 ------------------ * Mon Dec 21 2009 Rex Dieter - 1.0.32-2 - %check: (re)enable run-tests.sh scsi-target-utils-0.9.11-1.20091205snap.fc13 -------------------------------------------- * Mon Dec 21 2009 Hans de Goede - 0.9.11-1.20091205snap - Rebase to 0.9.11 + some fixes from git (git id 97832d8dcd00202a493290b5d134b581ce20885c) - Rewrite initscript, make it follow: http://fedoraproject.org/wiki/Packaging/SysVInitScript And merge in RHEL-5 initscript improvements: - Parse /etc/tgt/targets.conf, which allows easy configuration of targets - Better initiator status checking in stop - Add force-stop, to stop even when initiators are still connected - Make reload reload configuration from /etc/tgt/targets.conf without stopping tgtd (but only for unused targets) - Add force-reload (reloads configs for all targets including busy ones) selinux-policy-3.7.5-3.fc13 --------------------------- * Tue Dec 22 2009 Dan Walsh 3.7.5-3 - Add back xserver_manage_home_fonts * Mon Dec 21 2009 Dan Walsh 3.7.5-2 - Dontaudit sandbox trying to read nscd and sssd * Fri Dec 18 2009 Dan Walsh 3.7.5-1 - Update to upstream * Thu Dec 17 2009 Dan Walsh 3.7.4-4 - Rename udisks-daemon back to devicekit_disk_t policy slim-1.3.1-9.fc13 ----------------- * Tue Dec 22 2009 Lorenzo Villani - 1.3.1-9 - Fix CVE-2009-1756 (bugzilla: 544024) - Fix MIT insecure cookie generation (patch from Debian) - Fix build with GCC 4.4 smc-fonts-04.2-4.fc13 --------------------- * Mon Dec 21 2009 Pravin Satpute 04.2-4 - updated meera conf file spamassassin-3.3.0-0.26.rc1.fc13 -------------------------------- * Mon Dec 21 2009 Nick Bebout - 3.3.0-0.24.beta1 - Revert to beta1 to fix major error where spamc does nothing and mail is lost into black hole. * Mon Dec 21 2009 Warren Togami - 3.3.0-0.26.rc1 - 3.3.0-rc1.proposed2 with fixed spamc sssd-1.0.0-2.fc13 ----------------- * Mon Dec 21 2009 Stephen Gallagher - 1.0.0-2 - Patch SSSDConfig API to address - https://bugzilla.redhat.com/show_bug.cgi?id=549482 surl-0.7.0-1.fc13 ----------------- * Mon Dec 21 2009 Fabian Affolter - 0.7.0-1 - Updated to new upstream version 0.7.0 system-config-printer-1.1.16-1.fc13 ----------------------------------- * Tue Dec 22 2009 Tim Waugh - 1.1.16-1 - Updated pycups to 1.9.47. - 1.1.16: - Ignore com.apple.print.recoverable state reason. - Prevent traceback in found_network_printer_callback (bug #547765). - Use asynchronous connection class for fetching device lists (bug #549749). - Prefer Foomatic/hpijs to hpcups for the time being. - Clear device screen each time a new dialog is presented. - Constraints handling fix. telepathy-gabble-0.8.9-3.fc13 ----------------------------- * Tue Dec 22 2009 Brian Pepple - 0.8.9-2 - Backport some patches to prevent gabble from setting your VCard on every login. * Tue Dec 22 2009 Brian Pepple - 0.8.9-3 - Bump. tigervnc-1.0.90-0.1.20091221svn3929.fc13 ---------------------------------------- * Mon Dec 21 2009 Adam Tkac 1.0.90-0.1.20091221svn3929 - update to 1.0.90 snapshot - patches merged - tigervnc10-compat.patch - tigervnc10-rh510185.patch - tigervnc10-rh524340.patch - tigervnc10-rh516274.patch * Mon Oct 26 2009 Adam Tkac 1.0.0-3 - create Xvnc keyboard mapping before first keypress (#516274) tmpwatch-2.9.17-1.fc13 ---------------------- * Tue Dec 22 2009 Miloslav Trma? - 2.9.17-1 - Update to tmpwatch-2.9.17. Resolves: #548932 tokyotyrant-1.1.35-2.fc13 ------------------------- * Tue Dec 22 2009 Deji Akingunola - 1.1.35-2 - Rebuild for tokyocabinet soname bump tomcat6-6.0.20-2.fc13 --------------------- * Tue Dec 22 2009 Alexander Kurtakov 0:6.0.20-2 - Drop file requires on /usr/share/java/ecj.jar. transifex-0.7.3-3.fc13 ---------------------- * Tue Dec 22 2009 Rakesh Pandit - 0.7.3 - (patched by petersen) Updated to 0.7.3, for details: - http://code.transifex.org/index.cgi/tx-0.7.x/file/0fafc780e303/docs/releases/0.7.txt * Tue Dec 22 2009 Diego B?rigo Zacar?o - 0.7.3-2 - Changed SPEC for copying the SQLite database. - Do not try to build the docs, once the 0.7.3 tarball does not have a Makefile for it. - It is not necessary anymore to create the .mo files manually. The management command txcompilemessages does it. * Tue Dec 22 2009 Diego B?rigo Zacar?o - 0.7.3-3 - Django-south seems to raise a specific NotImplementedError exception for some migration operations using SQLite. Dropped database creation. tuned-0.2.7-2.fc13 ------------------ * Mon Dec 21 2009 Jan Vcelak 0.2.7-2 - Fixed 542305 - [abrt] crash detected in tuned-0.2.5-2.fc12 Some ethernet cards are not supported by 'ethtool'. upstart-0.6.3-4.fc13 -------------------- * Wed Dec 16 2009 Petr Lautrbach 0.6.3-4 - audit events patch rebased for 0.6 (#470661) varnish-2.0.6-1.fc13 -------------------- * Mon Dec 14 2009 Ingvar Hagelund - 2.0.6-1 - New upstream release viewvc-1.1.3-1.fc13 ------------------- * Wed Dec 23 2009 Bojan Smojver - 1.1.3-1 - bump up to 1.1.3 - drop patch for upstream issue #427 vte-0.23.2-1.fc13 ----------------- * Tue Dec 22 2009 Matthias Clasen - 0.23.2-1 - Update to 0.23.2 whatsup-1.9-4.fc13 ------------------ * Mon Dec 21 2009 Ruben Kerkhof 1.9-4 - Rebuild to pick up new opensm wireshark-1.2.5-2.fc13 ---------------------- writer2latex-1.0-3.fc13 ----------------------- * Mon Dec 21 2009 Caol?n McNamara 1.0-3 - Preserve time stamps wv-1.2.7-2.fc13 --------------- * Tue Dec 22 2009 Rahul Sundaram - 1.2.7-2 - Workaround a incorrect soname bump wxMaxima-0.8.4-1.fc13 --------------------- * Tue Dec 22 2009 Rex Dieter - 0.8.4-1 - wxMaxima-0.8.4 * Fri Nov 13 2009 Rex Dieter - 0.8.3a-1.1 - Requires: maxima >= 5.19 (#521722) xemacs-21.5.29-10.fc13 ---------------------- * Mon Dec 21 2009 Jerry James - 21.5.29-10 - Don't crash with a Persian keyboard layout (bz 547840) xkeyboard-config-1.7-1.fc12 --------------------------- * Tue Dec 01 2009 Peter Hutterer 1.7-1 - xkeyboard-config 1.7 - drop patches already upstream xorg-x11-drv-nouveau-0.0.15-14.20091217gitbb19478.fc13 ------------------------------------------------------ * Wed Dec 23 2009 Ben Skeggs 0.0.15-14.20091217gitbb19478 - update to latest upstream code xpa-2.1.11-1.fc13 ----------------- * Tue Dec 22 2009 Sergio Pascual - 2.1.11-1 - New upstream source xsp-2.6-2.fc13 -------------- * Tue Dec 22 2009 Paul F. Johnson 2.6-2 - Bump to release version xulrunner-1.9.2.1-0.8.b5.fc13 ----------------------------- * Mon Dec 21 2009 Martin Stransky 1.9.2.1-0.8.b5 - Update to 1.9.2.1 Beta 5 Summary: Added Packages: 22 Removed Packages: 2 Modified Packages: 168 From sundaram at fedoraproject.org Wed Dec 23 15:20:11 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Dec 2009 20:50:11 +0530 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> Message-ID: <4B32352B.30000@fedoraproject.org> On 12/22/2009 09:07 PM, Seth Vidal wrote: > FWIW - I agree with both jesse and jarod. Official builds are from main > branch. Anything built anywhere else will never be official. How about scratch builds? Rahul From jwboyer at gmail.com Wed Dec 23 15:34:01 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 23 Dec 2009 10:34:01 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B32352B.30000@fedoraproject.org> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <4B32352B.30000@fedoraproject.org> Message-ID: <20091223153401.GT16448@hansolo.jdub.homelinux.org> On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote: >On 12/22/2009 09:07 PM, Seth Vidal wrote: > >> FWIW - I agree with both jesse and jarod. Official builds are from main >> branch. Anything built anywhere else will never be official. > >How about scratch builds? What about them? Scratch builds are not official by definition. They don't show up in repos, are only available for a couple weeks, etc. josh From sundaram at fedoraproject.org Wed Dec 23 15:38:04 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Dec 2009 21:08:04 +0530 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091223153401.GT16448@hansolo.jdub.homelinux.org> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <4B32352B.30000@fedoraproject.org> <20091223153401.GT16448@hansolo.jdub.homelinux.org> Message-ID: <4B32395C.7020307@fedoraproject.org> On 12/23/2009 09:04 PM, Josh Boyer wrote: > On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote: >> On 12/22/2009 09:07 PM, Seth Vidal wrote: >> >>> FWIW - I agree with both jesse and jarod. Official builds are from main >>> branch. Anything built anywhere else will never be official. >> >> How about scratch builds? > > What about them? Scratch builds are not official by definition. They > don't show up in repos, are only available for a couple weeks, etc. The question was, are they ok to build from private branches? How does this tie into http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos Rahul From jkeating at j2solutions.net Wed Dec 23 16:31:11 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 23 Dec 2009 08:31:11 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B32352B.30000@fedoraproject.org> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <4B32352B.30000@fedoraproject.org> Message-ID: On Dec 23, 2009, at 7:20, Rahul Sundaram wrote: > On 12/22/2009 09:07 PM, Seth Vidal wrote: > >> FWIW - I agree with both jesse and jarod. Official builds are from >> main >> branch. Anything built anywhere else will never be official. > > How about scratch builds? > > Those can come from anywhere, even srpms for packages no enev in our source control. -- Jes From jkeating at j2solutions.net Wed Dec 23 16:45:19 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 23 Dec 2009 08:45:19 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B32395C.7020307@fedoraproject.org> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <4B32352B.30000@fedoraproject.org> <20091223153401.GT16448@hansolo.jdub.homelinux.org> <4B32395C.7020307@fedoraproject.org> Message-ID: On Dec 23, 2009, at 7:38, Rahul Sundaram wrote: > On 12/23/2009 09:04 PM, Josh Boyer wrote: >> On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote: >>> On 12/22/2009 09:07 PM, Seth Vidal wrote: >>> >>>> FWIW - I agree with both jesse and jarod. Official builds are >>>> from main >>>> branch. Anything built anywhere else will never be official. >>> >>> How about scratch builds? >> >> What about them? Scratch builds are not official by definition. >> They >> don't show up in repos, are only available for a couple weeks, etc. > > The question was, are they ok to build from private branches? Yes > How does > this tie into > > http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos > > It doesn't really. -- jes From paul at xelerance.com Wed Dec 23 17:31:27 2009 From: paul at xelerance.com (Paul Wouters) Date: Wed, 23 Dec 2009 12:31:27 -0500 (EST) Subject: Power Management caused 2 second instant poweroff on Desktop In-Reply-To: <4AE9DBDE.7090805@cchtml.com> References: <4AE99B4D.3060002@redhat.com> <4AE99D1E.6040601@cchtml.com> <8EA0BF74.4060706@redhat.com> <4AE9A59E.8080306@cchtml.com> <1256840039.2314.37.camel@adam.local.net> <4AE9DBDE.7090805@cchtml.com> Message-ID: Hey, I just had the weirdest thing ever, on Fedora 12 I was working on my desktop, running F-12, KVM and like 10 VM's up and running. I had clicked on the "update" button, but since I was using a voip (hardware) phone had not yet clicked on "download updates". I iconified the window to get rid of it while on my call and forgot about it. Later, while just doing some file editing, a (gnome power management?) popup appears with a power button on the left side, stating "Paul Wouters is logged on. System will shut down in 60 seconds". Looking at the popup kinda surprised, I move my hand to my mouse to hit cancel and before I reached my mouse, the machine does an instant poweroff, leaving me stunned in a very quiet room pondering about my 10 VM's that just crashed along with it. After the boot, it seems I have no new updates left to install :P Also, kernel did not change, still 2.6.31.6-166.fc12.x86_64, so even if this was some automatic update effect timed badly, I am not sure why it needed to poweroff my machine. I'm not sure which component to bug report for, or whose Christmas present to take away :P Paul From nicoleau.fabien at gmail.com Wed Dec 23 18:19:44 2009 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Wed, 23 Dec 2009 19:19:44 +0100 Subject: Create a -cli package without a different executable In-Reply-To: <20091220060845.GC18018@clingman.lan> References: <20091218181227.2f6da87e@gmail.com> <1261172358.7053.12.camel@localhost.localdomain> <20091220060845.GC18018@clingman.lan> Message-ID: <20091223191944.326c22cf@gmail.com> Le Sat, 19 Dec 2009 22:08:45 -0800, Toshio Kuratomi a ?crit : > On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote: > > Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien: > > > Hi, > > > > > > I'm packaging phatch that provides /usr/bin/phatch, a graphical > > > application to manage some operations on photos. It handles > > > command line parameters so that it can be used in a script, > > > without a GUI : if no parameters are given, a GUI is displayed, > > > otherwise it acts as a console application. > > > > > > Upstream asked me if it's possible to keep "phatch" package, > > > containing the graphical requirements (and requires) and requires > > > phatch-cli, and create a phatch-cli, that > > > provides /usr/bin/phatch. With this way, people could just > > > install phatch-cli on a server and use it with command line > > > parameters (but it would crash if it's not launched with > > > parameters). > > > > > > My question is : > > > is it good to provide a -cli package that does not provides a > > > separate script or executable file, and that will work only if > > > the user is carefull to not launch it in a way that it does not > > > require a graphic lib (without parameters in that context) ? > > > > Sounds like the goal is good but the implementation is not. > > > > > > I see phatch is a python package, so I think a little trick could be > > possible: > > > > %package cli: > > BuildRequires: python-devel > > Requires: non-gui-dependencies > > %files > > {_bindir}/phatch > > > > and for the main package: > > Requires: phatch-cli > > Requires: pygtk2, > > [install desktop file etc...] > > > > > > This way users could explicitly install phatch-cli, and it would > > "only" not start up properly if called without arguments on a > > terminal, and the main package (gui version) would contain the > > program and pull in the graphical dependencies. > > I don't know the program though, and if the cli version depends on > > gui libraries to work properly as well it wouldn't work. > > This is not ideal but it needs some coding to come up with something > better. Possibilities: > > * phatch with no options can attempt to import a gui lib. If that > succeeds it launches the graphical interface. If it does not > succeed, it displays the usage/help message. > * phatch is a command line app. When invoked as gphatch it starts as > a gui app instead. The phatch-gui subpackage installs a symlink > from /usr/bin/gpatch to /usr/bin/phatch as well as .desktop files. > > Basically, it's great to have the option to get the functionality of > the program without having to install the GUI environment. But the > program tracebacking when the GUI environment is not present and the > user typed the command name without options is not good behaviour for > a program. > > -Toshio In fact I was wrong about the fact that phatch will crash if it's called with no params (so as the gui version). A message is displayed and tells and explain that the user has to install 'phatch' (containing gui stuff). So its seems pretty clean to me, and easy to manage. Fabien Nicoleau From kevin.kofler at chello.at Wed Dec 23 18:28:00 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 23 Dec 2009 19:28 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> Message-ID: Jarod Wilson wrote: > On 12/22/09 2:45 AM, Kevin Kofler wrote: >> And as I wrote before, I don't like this at all, it's a regression from >> our current workflow > > Define "our". "Our current workflow" = what Fedora's current CVS setup allows. > In my personal opinion, Jesse is spot-on, we should NOT allow official > builds from a private branch. That's just insane. Scratch builds are fine. > Official builds need to be from the main branch, or a common non-private > branch (such as the kernel has done for maintaining both e.g. 2.6.29 and > 2.6.30 trees simultaneously for F10). The whole problem is that such branches do not exist at all in the new git setup! > If you get eaten by raptors, you can't expect another maintainer to come > in after you and have to dig around for a private branch to update a > build. That's why we need non-private branches (more than one per release), as allowed by our current CVS setup. Kevin Kofler From kevin.kofler at chello.at Wed Dec 23 18:38:58 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 23 Dec 2009 19:38:58 +0100 Subject: New covenant published (was: Re: moonlight and the new covenant) References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> Message-ID: Alex Hudson wrote: > Correction: it's now published here - > > http://www.microsoft.com/interop/msnovellcollab/newmoonlight.mspx > > To my untrained eye, it seems to cover Moonlight fully, the termination > clause doesn't work retroactively, it includes coverage for the Mono > portions and it seems to apply for everyone - hopefully this is a good > thing. It seems to remove previous objections about Novell-only-ness. This is still non-Free: > Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not > to sue End Users for infringement under Necessary Claims of Microsoft and > its Subsidiaries on account of such End Users? use of Moonlight > Implementations to the extent originally provided by Novell during the > Term and, if applicable, the Extension or Post-Extension Period, but only > to the extent such Moonlight Implementations are used as Conforming > Runtimes. [...] > ?Conforming Runtime? means plug-in or other runtime functionality hosted > by a Conforming Host for receiving and rendering, wholly within such > Conforming Host, media and interactive applications compatible with > Silverlight 3 or Silverlight 4. [...] > ?Moonlight Implementation? means only those specific portions of Moonlight > 3 or Moonlight 4 that run only as Conforming Runtimes within a Conforming > Host on a Personal Computer and are not licensed under GPLv3 or a Similar > License. This appears to be a classical "The license only applies if you comply to our standard" restriction, which is non-Free because it doesn't allow using the code for a different purpose (nor to extend the standard, which is kinda ironic coming from a company which keeps extending everyone ELSE's standards with proprietary extensions). As the patent license is non-Free, Moonlight still has to be considered non- Free wherever software patents apply. So as far as I can tell, this is not acceptable for Fedora, sorry. (But of course spot and/or RH Legal will have the final word.) Kevin Kofler From tcallawa at redhat.com Wed Dec 23 18:46:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 13:46:14 -0500 Subject: New covenant published In-Reply-To: References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> Message-ID: <4B326576.9080504@redhat.com> On 12/23/2009 01:38 PM, Kevin Kofler wrote: > As the patent license is non-Free, Moonlight still has to be considered non- > Free wherever software patents apply. So as far as I can tell, this is not > acceptable for Fedora, sorry. (But of course spot and/or RH Legal will have > the final word.) Well, patent licenses don't necessarily have to be Free, not at least in the way that we think of copyright licenses. With that said, this new "covenant" does NOT change our stance on Moonlight. It is still not permissible in Fedora. ~spot From kevin.kofler at chello.at Wed Dec 23 18:42:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 23 Dec 2009 19:42:21 +0100 Subject: Vala programs and compiling from source References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> <1261491373.2608.10.camel@localhost.localdomain> <20091222154713.GL18018@clingman.lan> <5256d0b0912220752u1ef89344u7284a9a08167754d@mail.gmail.com> Message-ID: Peter Robinson wrote: > Some what different in that vala is source code that generates plainly > readable C code. A .dll is a binary library. Its not exactly the same > arguement. So if I encode a Mono DLL as: unsigned char dll_data[]={...}; and generate the .dll from that, is that source code??? Some of the generated C code is not that different from the above. IMHO generated code does not belong into source tarballs at all. Kevin Kofler From kevin.kofler at chello.at Wed Dec 23 18:45:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 23 Dec 2009 19:45:05 +0100 Subject: All I want for Christmas is digiKam 1.0 in F12-stable... References: <1261415606.2469.26.camel@localhost.localdomain> <1261494090.30994.2.camel@localhost.localdomain> <935ead450912220718m62beab50pfb00399b1f0c21f2@mail.gmail.com> Message-ID: Jeffrey Ollie wrote: > That's to be expected, as "rpm -i" installs a package without removing > the old one. Unless the package is specially designed (like the > kernel) you'll get conflicts. Normally, you'd want to use "rpm -U" > which will remove the old package before installing the new one. Actually, it installs the new package first, replacing any files from the old one without reporting them as a conflict, then removes the files from the old package which are not in the new one. Kevin Kofler From fedora at alexhudson.com Wed Dec 23 18:56:07 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Wed, 23 Dec 2009 18:56:07 +0000 Subject: New covenant published In-Reply-To: <4B326576.9080504@redhat.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> Message-ID: <4B3267C7.6050301@alexhudson.com> On 23/12/09 18:46, Tom "spot" Callaway wrote: > With that said, this new "covenant" does NOT change our stance on > Moonlight. It is still not permissible in Fedora. > Can I ask on what grounds? Is the patent license insufficient, or is there some other problem? It's difficult to fix things if we don't know what's broken. Thanks Alex. From tcallawa at redhat.com Wed Dec 23 18:58:01 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 13:58:01 -0500 Subject: New covenant published In-Reply-To: <4B3267C7.6050301@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> Message-ID: <4B326839.6030808@redhat.com> On 12/23/2009 01:56 PM, Alex Hudson wrote: > On 23/12/09 18:46, Tom "spot" Callaway wrote: >> With that said, this new "covenant" does NOT change our stance on >> Moonlight. It is still not permissible in Fedora. >> > > Can I ask on what grounds? Is the patent license insufficient, or is > there some other problem? > > It's difficult to fix things if we don't know what's broken. The most obvious issue is that it does not cover Distributors besides Novell. ~spot From fedora at alexhudson.com Wed Dec 23 19:10:14 2009 From: fedora at alexhudson.com (Alex Hudson) Date: Wed, 23 Dec 2009 19:10:14 +0000 Subject: New covenant published In-Reply-To: <4B326839.6030808@redhat.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> Message-ID: <4B326B16.4000606@alexhudson.com> On 23/12/09 18:58, Tom "spot" Callaway wrote: > On 12/23/2009 01:56 PM, Alex Hudson wrote: > >> Can I ask on what grounds? Is the patent license insufficient, or is >> there some other problem? >> >> It's difficult to fix things if we don't know what's broken. >> > The most obvious issue is that it does not cover Distributors besides > Novell. > I thought that was the whole reason a new covenant has been issued, so that people other than Novell could distribute it. Looking over it, I don't really see where any distinction between Novell and anyone else is made. It would be useful to have some response from legal people about the exact issues which remain. It seems to me highly unlikely that problems are going to be resolved unless the problems are made clear; and the movement on this issue appears to be in the right direction. I realise a number of people don't care for Mono-related technologies, but it would be sad to see Fedora left out in the cold for this stuff. Cheers Alex. From qdlacz at gmail.com Wed Dec 23 19:10:16 2009 From: qdlacz at gmail.com (Krzesimir Nowak) Date: Wed, 23 Dec 2009 20:10:16 +0100 Subject: Vala programs and compiling from source In-Reply-To: References: <4B2FA681.4070800@fedoraproject.org> <5256d0b0912210900o36ca9791t3d7999f93d067c1b@mail.gmail.com> <20091221235333.GJ18018@clingman.lan> <1261491373.2608.10.camel@localhost.localdomain> <20091222154713.GL18018@clingman.lan> <5256d0b0912220752u1ef89344u7284a9a08167754d@mail.gmail.com> Message-ID: 2009/12/23 Kevin Kofler : > IMHO generated code does not belong into source tarballs at all. gtkmm tarballs distribute generated C++ source code to avoid using maintainer tools like mm-common or gmmproc by distro packagers. and that is for a long long time. Are we going to build gtkmm from templates? Krzesimir From tcallawa at redhat.com Wed Dec 23 19:22:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 14:22:14 -0500 Subject: New covenant published In-Reply-To: <4B326B16.4000606@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> Message-ID: <4B326DE6.5050007@redhat.com> On 12/23/2009 02:10 PM, Alex Hudson wrote: > On 23/12/09 18:58, Tom "spot" Callaway wrote: >> On 12/23/2009 01:56 PM, Alex Hudson wrote: >> >>> Can I ask on what grounds? Is the patent license insufficient, or is >>> there some other problem? >>> >>> It's difficult to fix things if we don't know what's broken. >>> >> The most obvious issue is that it does not cover Distributors besides >> Novell. >> > > I thought that was the whole reason a new covenant has been issued, so > that people other than Novell could distribute it. Looking over it, I > don't really see where any distinction between Novell and anyone else is > made. The new "covenant" is specifically worded to apply only to end-users, and makes the following noteworthy distinction: "an entity or individual cannot qualify both as an End User and a Distributor for use of the same copy of a Moonlight Implementation." It grants no patent rights to Distributors, aside from those already granted to Novell in the previous covenant. What it practically means is that once you distribute, you stop being considered an "End User" by Microsoft, and are no longer protected by this "covenant" (unless you're Novell or Microsoft). > It would be useful to have some response from legal people about the > exact issues which remain. It seems to me highly unlikely that problems > are going to be resolved unless the problems are made clear; and the > movement on this issue appears to be in the right direction. It is very very unlikely (I'll go so far as to say impossible) for any Red Hat Legal people to discuss this issue in unprivileged forums. Lawyers rarely like going on the record, especially when patent concerns are involved, because any statements that they make in public could be used later to reflect varying degrees of intent in a patent trial, triggering possible issues such as treble damages. I would encourage interested parties to review Rob Tiller's slides from SCALE 7x, to gain a better understanding of the complexities and risks around software patents: http://www.socallinuxexpo.org/scale7x/conference-info/speakers/rob-tiller http://www.socallinuxexpo.org/scale7x-audio/Saturday/TrackA/Talk%235RobTiller.mp3 (Yes, the irony of a talk on software patents being offered in MP3 format is not lost on me.) If Microsoft was serious about encouraging adoption of the Silverlight/Moonlight technology in FOSS, they would do so with an unrestricted patent grant for all end-users and distributors for code under any FOSS license (not just some). They are clearly unwilling to do that. From sundaram at fedoraproject.org Wed Dec 23 19:29:49 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 24 Dec 2009 00:59:49 +0530 Subject: New covenant published In-Reply-To: <4B326DE6.5050007@redhat.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <4B326DE6.5050007@redhat.com> Message-ID: <4B326FAD.1070004@fedoraproject.org> On 12/24/2009 12:52 AM, Tom "spot" Callaway wrote: > > It grants no patent rights to Distributors, aside from those already > granted to Novell in the previous covenant. What it practically means is > that once you distribute, you stop being considered an "End User" by > Microsoft, and are no longer protected by this "covenant" (unless you're > Novell or Microsoft). This means, when you copy SUSE CD and give it a friend, you are not covered under this covenant either? That's... interesting. Rahul From mike at cchtml.com Wed Dec 23 20:04:11 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 23 Dec 2009 14:04:11 -0600 Subject: New covenant published In-Reply-To: <4B326DE6.5050007@redhat.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <4B326DE6.5050007@redhat.com> Message-ID: <4B3277BB.2010200@cchtml.com> Tom "spot" Callaway wrote: > (Yes, the irony of a talk on software patents being offered in MP3 > format is not lost on me.) > Just think... one more year... one more year... From jkeating at redhat.com Wed Dec 23 20:21:46 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Dec 2009 12:21:46 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> Message-ID: <1261599706.11511.11.camel@localhost.localdomain> On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote: > > The whole problem is that such branches do not exist at all in the new git > setup! > > > If you get eaten by raptors, you can't expect another maintainer to come > > in after you and have to dig around for a private branch to update a > > build. > > That's why we need non-private branches (more than one per release), as > allowed by our current CVS setup. > Perhaps we have a terminology clash. The dist-git proof of concept allows branches to be created by maintainers, and pushed to the central repo, so long as the branch name starts with "private-". These repos can be written to by anybody with file system write access, that is anybody in the 'packager' group. At this time, I am not planning to allow official tagged builds to come from these branches, instead they can only come from origin/master or origin/F-?? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Wed Dec 23 19:57:09 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 23 Dec 2009 13:57:09 -0600 Subject: Kernel security update required or not? In-Reply-To: <4B30EC2A.3060801@cox.net> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <4B2EDACA.5060309@sapience.com> <20091221041635.GA22789@wolff.to> <4B30EC2A.3060801@cox.net> Message-ID: <20091223195709.GA9126@wolff.to> On Tue, Dec 22, 2009 at 10:56:26 -0500, "Clyde E. Kunkel" wrote: > > > does adding nomodeset to kernel parm line in grub.conf work? It gets me back to the other problem. So yeah it does seem like we are seeing the same thing. I update the bug to mention this. From cmadams at hiwaay.net Wed Dec 23 20:34:10 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Dec 2009 14:34:10 -0600 Subject: New covenant published In-Reply-To: <4B3277BB.2010200@cchtml.com> References: <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <4B326DE6.5050007@redhat.com> <4B3277BB.2010200@cchtml.com> Message-ID: <20091223203410.GB1393920@hiwaay.net> Once upon a time, Michael Cronenworth said: > Tom "spot" Callaway wrote: > >(Yes, the irony of a talk on software patents being offered in MP3 > >format is not lost on me.) > > Just think... one more year... one more year... It doesn't look like that is the case: http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues http://en.wikipedia.org/wiki/Talk:MP3#Patents -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jarod at redhat.com Wed Dec 23 20:46:26 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 23 Dec 2009 15:46:26 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261599706.11511.11.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> Message-ID: <4B3281A2.4080508@redhat.com> On 12/23/09 3:21 PM, Jesse Keating wrote: > On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote: >> >> The whole problem is that such branches do not exist at all in the new git >> setup! >> >>> If you get eaten by raptors, you can't expect another maintainer to come >>> in after you and have to dig around for a private branch to update a >>> build. >> >> That's why we need non-private branches (more than one per release), as >> allowed by our current CVS setup. >> > > Perhaps we have a terminology clash. > > The dist-git proof of concept allows branches to be created by > maintainers, and pushed to the central repo, so long as the branch name > starts with "private-". These repos can be written to by anybody with > file system write access, that is anybody in the 'packager' group. > > At this time, I am not planning to allow official tagged builds to come > from these branches, instead they can only come from origin/master or > origin/F-?? Okay, we've definitely got some slight misunderstanding here... :) I was objecting to Kevin's suggestion that we should be able to build official packages from branches named ^private-*. But building from a branch tagged something !^private- is actually necessary sometimes. The kernel folks have had to do just that from time to time. For example, say the F12 cvs head moves on towards 2.6.32 and an official build is submitted to updates-testing. Meanwhile, a security update for the already-released-to-users 2.6.31.x kernel needs to get pushed out. We create an F12-specific 2.6.31.x branch and build an *official* kernel to push to updates post-haste to fix the security issue. This *does* need to be allowed. But it wouldn't be on a branch named "private-*", it would be quite blatant and obvious in naming, such as f12-2_6_31_x-kernel-branch or similar. I think there was some confusion in my use of "private branch", where I was referring to branches with a name ^private-*, while Kevin was thinking in a more general sense, which would encompass the above kernel example. -- Jarod Wilson jarod at redhat.com From snecklifter at gmail.com Wed Dec 23 20:47:42 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 23 Dec 2009 20:47:42 +0000 Subject: Kernel security update required or not? In-Reply-To: <1261371740.1981.8.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> <20091221011642.GA1288@wolff.to> <1261359246.1981.5.camel@shrek.rexursive.com> <20091221042132.GB22789@wolff.to> <1261371740.1981.8.camel@shrek.rexursive.com> Message-ID: <364d303b0912231247qcbd3b83q6a764a88cbcc7988@mail.gmail.com> 2009/12/21 Bojan Smojver : > On Sun, 2009-12-20 at 22:21 -0600, Bruno Wolff III wrote: >> I didn't see any of the recent previous spec file comments indicate >> back ported security fixes. So its unlikely the latest security fixes >> are in any earlier version. If you want them now, grab the kernel from >> koji. Otherise you can wait for the kernel to push to updates or >> updates-testing depending on how much you want to wait for other >> people to test it before you try it out. > > I understand what I can do. That is not the issue. > > The question is, should Fedora get a security update or not - you know - > for all the users out there that are unaware of Koji etc. I'm sure > Fedora kernel folks reading the list will know. Ask on Fedora-kernel. Its got a better SNR and you don't need to subscribe. -- Christopher Brown From asm at linux.com Wed Dec 23 21:00:22 2009 From: asm at linux.com (Alan Milnes) Date: Wed, 23 Dec 2009 21:00:22 +0000 Subject: New covenant published In-Reply-To: <4B326B16.4000606@alexhudson.com> References: <4B2CAF55.7060703@alexhudson.com> <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> Message-ID: 2009/12/23 Alex Hudson : > I realise a number of people don't care for Mono-related technologies, but > it would be sad to see Fedora left out in the cold for this stuff. Actually it makes me very *happy* to have a distro untainted by this stuff. Never forget their MO:- Embrace - Extend - Extinguish Alan All thoughts are my own From ngompa13 at gmail.com Wed Dec 23 21:14:40 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Wed, 23 Dec 2009 15:14:40 -0600 Subject: New covenant published In-Reply-To: References: <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> Message-ID: <8278b1b0912231314xd108454hba327d3069411bde@mail.gmail.com> On Wed, Dec 23, 2009 at 3:00 PM, Alan Milnes wrote: > 2009/12/23 Alex Hudson : > > > I realise a number of people don't care for Mono-related technologies, > but > > it would be sad to see Fedora left out in the cold for this stuff. > > Actually it makes me very *happy* to have a distro untainted by this stuff. > > Never forget their MO:- Embrace - Extend - Extinguish > > Alan > > All thoughts are my own > > Then I guess we shouldn't have AJAX either, since Microsoft developed one of the core technologies behind AJAX. Their MO may be Embrace, Extend, Extinguish, but they are not in a landscape where they can do that without severe backlash. We get angry a lot over Linux FUD, but that doesn't mean you are given the right to spread FUD against Microsoft too. Mono is based on an open standard, a standard that is being updated periodically too. The parts that aren't part of the standard can easily be placed in separate packages and not installed, if you are really concerned about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Dec 23 21:17:35 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Dec 2009 13:17:35 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <4B3281A2.4080508@redhat.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> Message-ID: <1261603055.11511.13.camel@localhost.localdomain> On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote: > Okay, we've definitely got some slight misunderstanding here... :) > > I was objecting to Kevin's suggestion that we should be able to build > official packages from branches named ^private-*. But building from a > branch tagged something !^private- is actually necessary sometimes. > > The kernel folks have had to do just that from time to time. For > example, say the F12 cvs head moves on towards 2.6.32 and an official > build is submitted to updates-testing. Meanwhile, a security update for > the already-released-to-users 2.6.31.x kernel needs to get pushed out. > We create an F12-specific 2.6.31.x branch and build an *official* kernel > to push to updates post-haste to fix the security issue. This *does* > need to be allowed. But it wouldn't be on a branch named "private-*", it > would be quite blatant and obvious in naming, such as > f12-2_6_31_x-kernel-branch or similar. > > I think there was some confusion in my use of "private branch", where I > was referring to branches with a name ^private-*, while Kevin was > thinking in a more general sense, which would encompass the above kernel > example. > I understand the use case, I'm still not super keen on having official built packages come out of a branch. Makes discovery somewhat difficult, and leads to problems if we have to bump+build something and don't realize that the real live code is actually on a branch. So this needs some more thinking, and discussion, which is happening here, which is a good thing. Healthy debate is good, lets just endeavor to keep it healthy (: -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From fnasser at redhat.com Wed Dec 23 21:26:55 2009 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 23 Dec 2009 16:26:55 -0500 (EST) Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261603055.11511.13.camel@localhost.localdomain> Message-ID: <496586471.2874591261603615092.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Jesse Keating" wrote: > On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote: > > Okay, we've definitely got some slight misunderstanding here... :) > > > > I was objecting to Kevin's suggestion that we should be able to > build > > official packages from branches named ^private-*. But building from > a > > branch tagged something !^private- is actually necessary sometimes. > > > > The kernel folks have had to do just that from time to time. For > > example, say the F12 cvs head moves on towards 2.6.32 and an > official > > build is submitted to updates-testing. Meanwhile, a security update > for > > the already-released-to-users 2.6.31.x kernel needs to get pushed > out. > > We create an F12-specific 2.6.31.x branch and build an *official* > kernel > > to push to updates post-haste to fix the security issue. This > *does* > > need to be allowed. But it wouldn't be on a branch named > "private-*", it > > would be quite blatant and obvious in naming, such as > > f12-2_6_31_x-kernel-branch or similar. > > > > I think there was some confusion in my use of "private branch", > where I > > was referring to branches with a name ^private-*, while Kevin was > > thinking in a more general sense, which would encompass the above > kernel > > example. > > > > I understand the use case, I'm still not super keen on having > official > built packages come out of a branch. Makes discovery somewhat > difficult, and leads to problems if we have to bump+build something > and > don't realize that the real live code is actually on a branch. > +1 We used branches for a temporary setup recently and it got two people crazy looking for the sources for the builds. They ended up starting from scratch because they couldn't find it. > So this needs some more thinking, and discussion, which is happening > here, which is a good thing. Healthy debate is good, lets just > endeavor > to keep it healthy (: > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From roland at redhat.com Wed Dec 23 22:23:24 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Dec 2009 14:23:24 -0800 (PST) Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: Jesse Keating's message of Wednesday, 23 December 2009 13:17:35 -0800 <1261603055.11511.13.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> Message-ID: <20091223222324.68BC1722F@magilla.sf.frob.com> > I understand the use case, I'm still not super keen on having official > built packages come out of a branch. Makes discovery somewhat > difficult, and leads to problems if we have to bump+build something and > don't realize that the real live code is actually on a branch. Surely all previous builds will be easy to "discover" in koji and that will tell you the exact commit id. AIUI there should be an automagic git tag pushed by koji so that just directly in git alone it is trivial and reliable to find the commit matching a given build. In git the idea of a branch is not inherently a permanent thing, and only the ancestry graph of a particular commit is truly meaningful as historical information. Just the commit id of interest is what you need to ascertain whether it is the head or ancestor of which branches at the time you ask the question. Thanks, Roland From jkeating at redhat.com Wed Dec 23 22:32:09 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Dec 2009 14:32:09 -0800 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091223222324.68BC1722F@magilla.sf.frob.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> <20091223222324.68BC1722F@magilla.sf.frob.com> Message-ID: <1261607529.11511.17.camel@localhost.localdomain> On Wed, 2009-12-23 at 14:23 -0800, Roland McGrath wrote: > > I understand the use case, I'm still not super keen on having official > > built packages come out of a branch. Makes discovery somewhat > > difficult, and leads to problems if we have to bump+build something and > > don't realize that the real live code is actually on a branch. > > Surely all previous builds will be easy to "discover" in koji and that will > tell you the exact commit id. AIUI there should be an automagic git tag > pushed by koji so that just directly in git alone it is trivial and > reliable to find the commit matching a given build. In git the idea of a > branch is not inherently a permanent thing, and only the ancestry graph of > a particular commit is truly meaningful as historical information. Just > the commit id of interest is what you need to ascertain whether it is the > head or ancestor of which branches at the time you ask the question. > > Right, but when I as a releng person need to bump something in an emergency or when a maintainer is out, I expect origin/master to be "live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect that I'd have to go hunting down where the commit hash for the previous build came from, then try to discover which branch that commit hash currently lives on, so that I can commit on top of it and keep going. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From alexl at users.sourceforge.net Wed Dec 23 22:34:53 2009 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 23 Dec 2009 17:34:53 -0500 Subject: major ghc breakage: anybody working on fixing them? (was Re: rawhide report: 20091223 changes) In-Reply-To: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> (Rawhide Report's message of "Wed, 23 Dec 2009 15:17:20 +0000") References: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Message-ID: >>>>> Rawhide Report writes: So these huge slew of broken deps (seems like more than 10 packages) for ghc have been in the rawhide reports for over a week now, is anybody actively maintaining and/or planning to fix these packages? If not, please let us know so a provenpackager can fix these, they overwhelm the rawhide log and make it more likely that people ignore the entire broken dep log. It seems like it is only a version number in a subpackage that needs building or somesuch, so hopefully it is trivial to fix. Alex > Compose started at Wed Dec 23 08:15:12 UTC 2009 Broken deps for i386 > ---------------------------------------------------------- [...] > ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 > ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 > ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 > ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 > ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 > ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 > ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 > ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 > ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 > ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 > ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = > 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires > ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 > requires ghc = 0:6.10.4 > ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = > 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires > ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 > requires ghc-prof = 0:6.10.4 > ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 > ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 > ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = > 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 > ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 > ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 > ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 > ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 > ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 > ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 > ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 > ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires > ghc-utf8-string-devel = 0:0.3.5 > ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 > ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 > ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = > 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = > 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires > ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 > requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 > requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc > = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 > ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 > ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 > ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 From alexl at users.sourceforge.net Wed Dec 23 22:45:00 2009 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 23 Dec 2009 17:45:00 -0500 Subject: major ghc breakage: anybody working on fixing them? In-Reply-To: (Alex Lancaster's message of "Wed, 23 Dec 2009 17:34:53 -0500") References: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Message-ID: >>>>> Alex Lancaster writes: >>>>> Rawhide Report writes: > So these huge slew of broken deps (seems like more than 10 packages) > for ghc have been in the rawhide reports for over a week now, is > anybody actively maintaining and/or planning to fix these packages? > If not, please let us know so a provenpackager can fix these, they > overwhelm the rawhide log and make it more likely that people ignore > the entire broken dep log. It seems like it is only a version number > in a subpackage that needs building or somesuch, so hopefully it is > trivial to fix. Hmm, this is odd, I noticed that according to: http://koji.fedoraproject.org/mash/rawhide-20091223/logs/repodiff abiword was successfully rebuilt: abiword-2.8.1-3.fc13 -------------------- * Mon Dec 21 2009 Peter Robinson - 1:2.8.1-3 - Rebuild against new libwv but the depcheck shows it still broken: http://koji.fedoraproject.org/mash/rawhide-20091223/logs/depcheck 1:abiword-2.8.1-3.fc13.i686 requires libwv-1.2.so.4 Similarly it looks like parts of ghc were rebuilt: ghc-X11-1.5.0.0-1.fc13 ---------------------- * Mon Dec 21 2009 Yaakov M. Nemoy - 1.5.0.0-1 - updated to latest upstream - updates spec to use shared libraries and new ghc Is there something perhaps wrong with the dep check script? Alex From sundaram at fedoraproject.org Wed Dec 23 22:52:02 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 24 Dec 2009 04:22:02 +0530 Subject: major ghc breakage: anybody working on fixing them? In-Reply-To: References: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Message-ID: <4B329F12.7050507@fedoraproject.org> On 12/24/2009 04:15 AM, Alex Lancaster wrote: >>>>>> Alex Lancaster writes: > >>>>>> Rawhide Report writes: >> So these huge slew of broken deps (seems like more than 10 packages) >> for ghc have been in the rawhide reports for over a week now, is >> anybody actively maintaining and/or planning to fix these packages? >> If not, please let us know so a provenpackager can fix these, they >> overwhelm the rawhide log and make it more likely that people ignore >> the entire broken dep log. It seems like it is only a version number >> in a subpackage that needs building or somesuch, so hopefully it is >> trivial to fix. > > Hmm, this is odd, I noticed that according to: > > http://koji.fedoraproject.org/mash/rawhide-20091223/logs/repodiff > > abiword was successfully rebuilt: Abiword situation is explained at https://www.redhat.com/archives/fedora-test-list/2009-December/msg00357.html Rahul From roland at redhat.com Wed Dec 23 23:07:48 2009 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Dec 2009 15:07:48 -0800 (PST) Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: Jesse Keating's message of Wednesday, 23 December 2009 14:32:09 -0800 <1261607529.11511.17.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> <20091223222324.68BC1722F@magilla.sf.frob.com> <1261607529.11511.17.camel@localhost.localdomain> Message-ID: <20091223230748.4EAC8901@magilla.sf.frob.com> > Right, but when I as a releng person need to bump something in an > emergency or when a maintainer is out, I expect origin/master to be > "live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect > that I'd have to go hunting down where the commit hash for the previous > build came from, then try to discover which branch that commit hash > currently lives on, so that I can commit on top of it and keep going. Ok. But, chances are that builds from branches are for temporary situations (emergency updates while bigger updates are in testing, etc.) and the circumstance where the obvious tip is not the same as the last build will be rare. My real point was that such situations will be entirely well-defined in a mechanical sense. So it's always possible to automate an "F-n/master is not an ancestor of most recent dist-fn build" check, make it autoflame maintainers every day, etc. Certainly I don't think that releng people should be expected to do commits on random branches that maintainers happen to be using. I can't really imagine that a maintainer really ever wants that. But once each of those "go hunting down" and "try to discover" steps is entirely automated with 100% reliably correct answers in an instant, as should certainly be quite simple in git, then the picture of absolute necessity for a priori controls on how maintainers do all their business looks a bit thinner. That's all. Thanks, Roland From kanarip at kanarip.com Thu Dec 24 00:19:33 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 24 Dec 2009 01:19:33 +0100 Subject: (huge) Ruby packaging changes In-Reply-To: <200912221936.13747.ville.skytta@iki.fi> References: <4B3008AD.8050002@kanarip.com> <200912221936.13747.ville.skytta@iki.fi> Message-ID: <4B32B395.1040006@kanarip.com> On 12/22/2009 06:36 PM, Ville Skytt? wrote: > On Tuesday 22 December 2009, Jeroen van Meeuwen wrote: > >> - Use the alternatives system to point to one stack or the other for the >> system default stack (think standalone applications). > > Not that I'm anywhere near an expert in ruby matters, but I have some (bad) > experience with alternatives, so: > Neither am I an expert in Ruby, I'm just the maintainer of the package (partly in company time, which is just wow!). My primary point was to have the switching of stacks be available for standalone applications (such as puppet, facter or other Ruby programs installed in %{_bindir}/%{_sbindir}) that use #!/usr/bin/ruby, so that we don't have to create a specific version of all those programs for each ruby stack, and the user could choose - but shouldn't have to. > If this means running different individual applications with different > stacks/stack versions, I strongly suggest reconsidering using the alternatives > system for that. Alternatives is for (easily) changing the system default > stack, not at all for changing per-application ones. Being able to switch to a different stack would only be supported on a per-system basis, but of course a single program can #!/usr/bin/ruby-1.8.6 if it really wanted to. FWIW, the ability would primarily be intended to be available for developers. And getting it right is > not an easy task. FWIW in fact I'd recommend not doing any alternatives stuff > unless there are very strong, valid reasons for doing so. We have an example > with the current Java alternatives system in Fedora which in my opinion no > longer has any real benefits but rather has a negative net effect and it'd be > good to start planning for getting rid of it altogether. > The beast that is Java ;-) A very successful example where alternatives is used heavily is of course a system's mail stack. I think it can be done right, but the question is how. > On the other hand, if I got your intent right, environment-modules might be > something to look into here. > Care to explain the term environment-modules for me please? -- Jeroen From sundaram at fedoraproject.org Thu Dec 24 00:30:34 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 24 Dec 2009 06:00:34 +0530 Subject: (huge) Ruby packaging changes In-Reply-To: <4B32B395.1040006@kanarip.com> References: <4B3008AD.8050002@kanarip.com> <200912221936.13747.ville.skytta@iki.fi> <4B32B395.1040006@kanarip.com> Message-ID: <4B32B62A.8040902@fedoraproject.org> On 12/24/2009 05:49 AM, Jeroen van Meeuwen wrote: > > Care to explain the term environment-modules for me please? http://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules Rahul From tcallawa at redhat.com Thu Dec 24 03:37:57 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 22:37:57 -0500 Subject: New covenant published In-Reply-To: <20091223203410.GB1393920@hiwaay.net> References: <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <4B326DE6.5050007@redhat.com> <4B3277BB.2010200@cchtml.com> <20091223203410.GB1393920@hiwaay.net> Message-ID: <4B32E215.8070407@redhat.com> On 12/23/2009 03:34 PM, Chris Adams wrote: > Once upon a time, Michael Cronenworth said: >> Tom "spot" Callaway wrote: >>> (Yes, the irony of a talk on software patents being offered in MP3 >>> format is not lost on me.) >> >> Just think... one more year... one more year... > > It doesn't look like that is the case: > > http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues > http://en.wikipedia.org/wiki/Talk:MP3#Patents It's not one more year. I've got the dates written down somewhere, I could dig them out if you want them, but it isn't soon. ~spot From ngompa13 at gmail.com Thu Dec 24 04:17:44 2009 From: ngompa13 at gmail.com (Sir Gallantmon) Date: Wed, 23 Dec 2009 22:17:44 -0600 Subject: New covenant published In-Reply-To: <4B32E215.8070407@redhat.com> References: <1261220453.6025.11.camel@localhost.localdomain> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <4B326DE6.5050007@redhat.com> <4B3277BB.2010200@cchtml.com> <20091223203410.GB1393920@hiwaay.net> <4B32E215.8070407@redhat.com> Message-ID: <8278b1b0912232017na141e9fm8f867cad3ad81aed@mail.gmail.com> On Wed, Dec 23, 2009 at 9:37 PM, Tom "spot" Callaway wrote: > On 12/23/2009 03:34 PM, Chris Adams wrote: > > Once upon a time, Michael Cronenworth said: > >> Tom "spot" Callaway wrote: > >>> (Yes, the irony of a talk on software patents being offered in MP3 > >>> format is not lost on me.) > >> > >> Just think... one more year... one more year... > > > > It doesn't look like that is the case: > > > > http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues > > http://en.wikipedia.org/wiki/Talk:MP3#Patents > > It's not one more year. I've got the dates written down somewhere, I > could dig them out if you want them, but it isn't soon. > > ~spot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'm not sure, but I think the mp3 patents would have all expired by 2021. So we have a LONG time to wait... Here's where I got the list: http://en.wikipedia.org/wiki/Talk:MP3#Expiration_of_Patents -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Thu Dec 24 04:32:24 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 23:32:24 -0500 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <20091223230748.4EAC8901@magilla.sf.frob.com> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> <20091223222324.68BC1722F@magilla.sf.frob.com> <1261607529.11511.17.camel@localhost.localdomain> <20091223230748.4EAC8901@magilla.sf.frob.com> Message-ID: <4B32EED8.4070205@redhat.com> On 12/23/2009 06:07 PM, Roland McGrath wrote: >> Right, but when I as a releng person need to bump something in an >> emergency or when a maintainer is out, I expect origin/master to be >> "live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect >> that I'd have to go hunting down where the commit hash for the previous >> build came from, then try to discover which branch that commit hash >> currently lives on, so that I can commit on top of it and keep going. > > Ok. But, chances are that builds from branches are for temporary > situations (emergency updates while bigger updates are in testing, etc.) > and the circumstance where the obvious tip is not the same as the last > build will be rare. Yeah, but in the situation where I need to make a quick legal change, I would really prefer to know for sure where to make that change, and not have to worry about which of the numerous branches I should apply it to. ~spot From loupgaroublond at gmail.com Thu Dec 24 09:04:23 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 24 Dec 2009 10:04:23 +0100 Subject: major ghc breakage: anybody working on fixing them? (was Re: rawhide report: 20091223 changes) In-Reply-To: References: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Message-ID: <7f692fec0912240104j66a2d0baw75b9d354e5e7a2@mail.gmail.com> 2009/12/23 Alex Lancaster : >>>>>> Rawhide Report ?writes: > > So these huge slew of broken deps (seems like more than 10 packages) for > ghc have been in the rawhide reports for over a week now, is anybody > actively maintaining and/or planning to fix these packages? ?If not, > please let us know so a provenpackager can fix these, they overwhelm the > rawhide log and make it more likely that people ignore the entire broken > dep log. ?It seems like it is only a version number in a subpackage that > needs building or somesuch, so hopefully it is trivial to fix. Sorry for making the noise. The biggest problem is that alot of libraries have been migrated out of the default compiler install and into many subpackages. All i can say is that we're working on it slowly. In short though, it's not a trivial fix. -Yaakov From abo at root.snowtree.se Thu Dec 24 09:11:32 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 24 Dec 2009 10:11:32 +0100 Subject: dist-git proof of concept phase 2 ready for testing In-Reply-To: <1261607529.11511.17.camel@localhost.localdomain> References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> <20091223222324.68BC1722F@magilla.sf.frob.com> <1261607529.11511.17.camel@localhost.localdomain> Message-ID: <1261645892.9123.12.camel@tempo.alexander.bostrom.net> ons 2009-12-23 klockan 14:32 -0800 skrev Jesse Keating: > I don't expect > that I'd have to go hunting down where the commit hash for the previous > build came from, then try to discover which branch that commit hash > currently lives on, so that I can commit on top of it and keep going. Automate it in fedpkg? "fedpkg checkout emacs F12 stable" or something. /abo From rawhide at fedoraproject.org Thu Dec 24 13:37:54 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 24 Dec 2009 13:37:54 +0000 Subject: rawhide report: 20091224 changes Message-ID: <20091224133754.GA7613@releng2.fedora.phx.redhat.com> Compose started at Thu Dec 24 08:15:08 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package bluemodem A bluetooth modem configuration utility New package dmenu Generic menu for X New package dogtag-pki-ca-ui Dogtag Certificate System - Certificate Authority User Interface New package dogtag-pki-common-ui Dogtag Certificate System - PKI Common Framework User Interface New package gummi A simple LaTeX editor New package jconvolver Real-time Convolution Engine New package mingw32-libzip C library for reading, creating, and modifying zip archives New package perl-Format-Human-Bytes Format a bytecount and make it human readable New package pki-native-tools Dogtag Certificate System - Native Tools New package pki-setup Dogtag Certificate system - PKI Instance Creation and Removal Scripts New package plexus-interpolation Plexus Interpolation API New package plexus-io Plexus IO Components New package python-minimock The simplest possible mock library Updated Packages: abiword-2.8.1-4.fc13 -------------------- * Wed Dec 23 2009 Rahul Sundaram -1:2.8.1-4 - Rebuild again since the wv soname bump was accidental - Remove superflous BuildRoot definitions and removals anaconda-13.13-1.fc13 --------------------- * Wed Dec 23 2009 Chris Lumens - 13.13-1 - lsreipl from s390-utils uses incorrect path (hamzy). - fix for a bug in 05ce88b2 that split one line over several in program.log (akozumpl) - Dump the initial and final state of the system's storage devices. (dlehman) - Add a "dict" attribute to Device and DeviceFormat classes. (dlehman) - Sort Storage.devices by name (not path) for consistency. (dlehman) - Put fsprofile support back in. (dlehman) - Fix reset of lvm filtering (#527711) (rvykydal) - Fix bootloader driveorder dialog. (rvykydal) - Fix selection of default boot target in UI (#548695) (rvykydal) - 'cleardiskssel' typos that made it impossible to run text install. (akozumpl) cherokee-0.99.37-1.fc13 ----------------------- * Wed Dec 23 2009 Lorenzo Villani - 0.99.37-1 - 0.99.37 cups-1.4.2-21.fc13 ------------------ * Wed Dec 23 2009 Tim Waugh - 1:1.4.2-21 - Fixed patch for STR #3425 again by adding in back-ported change from svn revision 8929 (bug #549899). No longer need delete-active-printer patch. fped-0-0.2.r5760.fc13 --------------------- * Wed Dec 23 2009 Chitlesh Goorah 0-0.2.r5760 - new upstream snapshot funtools-1.4.4-2.fc13 --------------------- * Wed Dec 23 2009 Sergio Pascual - 1.4.4-1 - New upstream source * Wed Dec 23 2009 Sergio Pascual - 1.4.4-2 - EVR bump garmindev-0.3.1-1.fc13 ---------------------- * Wed Dec 23 2009 Dan Hor?k 0.3.1-1 - update to version 0.3.1 ghc-rpm-macros-0.4.0-1.fc13 --------------------------- * Thu Dec 24 2009 Jens Petersen - 0.4.0-1 - add cabal_configure_dynamic - add ghc_requires, ghc_doc_requires, ghc_prof_requires guitarix-0.05.5-1.fc13 ---------------------- * Thu Dec 24 2009 Orcan Ogetbil - 0.05.5-1 - Update to 0.05.5 - Add Requires: qjackctl. RHBZ #549566 istanbul-0.2.2-13.fc13 ---------------------- * Fri Dec 18 2009 Jef Spaleta - 0.2.2-13 - Initial patch provided by Colin Walters and Dave Malcolm to address bug 543278 jd-2.5.5-0.3.svn3257_trunk.fc13 ------------------------------- * Thu Dec 24 2009 Mamoru Tasaka - rev 3257 jmol-11.8.14-1.fc13 ------------------- * Wed Dec 23 2009 Jussi Lehtola - 11.8.14-1 - Build from stable release tarballs works now, switch to using stable releases. - Update to 11.8.14. kde-settings-4.4-4 ------------------ * Wed Dec 23 2009 Rex Dieter 4.4-4 - enable nepomuk, with some conservative defaults (#549436) kdebindings-4.3.85-3.fc13 ------------------------- * Wed Dec 23 2009 Rex Dieter - 4.3.85-3 - tarball respin, includes build-fix'es libvirt-0.7.5-1.fc13 -------------------- * Wed Dec 23 2009 Daniel Veillard - 0.7.5-1 - Add new API virDomainMemoryStats - Public API and domain extension for CPU flags - vbox: Add support for version 3.1 - Support QEMU's virtual FAT block device driver - a lot of fixes m17n-db-1.5.5-3.fc13 -------------------- * Wed Dec 23 2009 Jens Petersen - 1.5.5-3 - separate .flt files to flt subpackage for m17n-lib-flt m17n-lib-1.5.5-2.fc13 --------------------- * Wed Dec 23 2009 Jens Petersen - 1.5.5-2 - add bcond for otf, anthy, and gui - subpackage flt for emacs, etc - add subpackages for anthy and ispell modules - disable new gui subpackage (and hence ispell) man-pages-ja-20091215-1.fc13 ---------------------------- * Thu Dec 24 2009 Akira TAGOH - 20091215-1 - updates to 20091215. - apply some patches to correct typos: - man-pages-ja-486655-mkfs.8.patch - man-pages-ja-509048-less.1.patch - man-pages-ja-515467-strings.1.patch - man-pages-ja-527638-chgrp.1.patch - man-pages-ja-537103-ip.7.patch - man-pages-ja-fix-mdoc.patch - clean up the spec file. maven-archiver-2.4-1.fc13 ------------------------- * Wed Dec 23 2009 Alexander Kurtakov 0:2.4-1 - Update to 2.4. mbuffer-20091122-1.fc13 ----------------------- * Wed Dec 23 2009 Fabian Affolter - 20091122-1 - Updated to new upstream version 20091122 mcs-0.7.1-7.fc13 ---------------- * Thu Dec 24 2009 Michael Schwendt - 0.7.1-7 - Fix floating point exception in mcs-walk-config tool. * Wed Dec 23 2009 Michael Schwendt - 0.7.1-6 - Add --disable-kconfig to fix build requirements usage (#529696). The kconfig backend has never been built or included before. - Fix MCS_SYSCONFDIR build config value, so /etc/mcs-backend file is found. Don't provide a default site-wide config file anymore. Making it default to "gconf" would switch backends for everyone from "default". mock-1.0.2-1.fc13 ----------------- * Wed Dec 23 2009 Clark Williams - 1.0.2-1 - added IPv6 localhost entry for default /etc/hosts (BZ# 545435) - removed output of gethostname() in IPv4 localhost entry as this caused koji problems and cause 'localhost' to be put into generated rpms, rather than the output of hostname - add code to setup /dev/pts differently on EL* than on FC* hosts openoffice.org-3.2.0-8.3.fc13 ----------------------------- * Wed Dec 23 2009 Caol?n McNamara - 1:3.2.0-8.3 - python bits should be site-arch perl-File-Next-1.06-1.fc13 -------------------------- * Wed Dec 23 2009 Marcela Ma?l??ov? - 1.06-1 - update perl-MailTools-2.05-1.fc13 -------------------------- * Mon Dec 21 2009 Paul Howarth 2.05-1 - Update to 2.05 - Fix de-ref error when index out of range in Mail::Header::get() - Repair fixed selection of smtp for non-unix systems - Do not run pod.t in devel environment - Set default output filename for Mail::Mailer::testfile::PRINT - Warn when no mailers were found (CPAN RT#52901) - Tidy up %files list perl-Text-FindIndent-0.06-1.fc13 -------------------------------- * Wed Dec 23 2009 Marcela Ma?l??ov? - 0.06-1 - update * Fri Dec 04 2009 Stepan Kasal - 0.03-4 - rebuild against perl 5.10.1 perl-TimeDate-1.20-1.fc13 ------------------------- * Wed Dec 23 2009 Paul Howarth - 1:1.20-1 - update to 1.20 - recode documentation as UTF-8 - fix bogus exec permissions to placate rpmlint perl-Wx-Perl-ProcessStream-0.22-1.fc13 -------------------------------------- * Wed Dec 23 2009 Marcela Ma?l??ov? - 0.22-1 - update plexus-archiver-1.0-0.4.a12.3.fc13 ---------------------------------- * Thu Dec 24 2009 Alexander Kurtakov 0:1.0-0.4.a12.2 - Ignore test failures. * Thu Dec 24 2009 Alexander Kurtakov 0:1.0-0.4.a12.3 - Really ignore test failures. * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.4.a12.1 - Update to alpha 12. plexus-i18n-1.0-0.b10.2.fc13 ---------------------------- * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.b10.1 - Update to beta 10. - Drop gcj and fix BRs. * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.b10.2 - BR java-devel 1.6.0. poco-1.3.6p1-1.fc13 ------------------- * Wed Dec 23 2009 Maxim Udushlivy - 1.3.6p1-1 - The package was upgraded for the use of POCO version 1.3.6p1. - A new binary package (poco-pagecompiler) is now produced by the rpmbuild process. - The syslibs patch was considerably simplified (based on a new "configure" script option which was introduced by POCO developers for the maintainers of the POCO Debian package). python-daemon-1.5.2-1.fc13 -------------------------- * Wed Dec 23 2009 Thomas Spura - 1.5.1-2 - add missing BR: minimock and lockfile -> testsuite works again - remove patch, use sed instead * Wed Dec 23 2009 Thomas Spura - 1.5.2-1 - add missing BR: python-nose - also add lockfile as R (bug #513546) - update to 1.5.2 python-wifi-0.5.0-2.fc13 ------------------------ * Thu Dec 24 2009 Fabian Affolter - 0.5.0-2 - Removed the convert to utf-8 part - Added license for examples - Fixed tarball URL - Added man pages * Wed Dec 23 2009 Fabian Affolter - 0.5.0-1 - Updated docs - Updated BR - Updated to new upstream version 0.5.0 qbittorrent-2.1.0-0.2.beta2.fc13 -------------------------------- * Wed Dec 23 2009 Leigh Scott - 2.1.0-0.2.beta1 - update to 2.1.0beta2 qgis-1.0.2-4.fc13 ----------------- * Wed Dec 23 2009 Rex Dieter - 1.0.2-4 - qgis rebuild for sip-4.9.x (#538119) * Fri Dec 04 2009 Devrim G?ND?Z - 1.0.2-3 - Rebuild for new Geos. * Tue Nov 17 2009 Rex Dieter - 1.0.2-2 - -python: Requires: sip-api(%_sip_api_major) >= %_sip_api (#538119) * Thu Oct 22 2009 Alex Lancaster - 1.0.2-1.1 - Rebuilt to fix python problem (#518121) qlandkartegt-0.16.1-1.fc13 -------------------------- * Wed Dec 23 2009 Dan Hor?k 0.16.1-1 - update to 0.16.1 qt-4.6.0-3.fc13 --------------- * Wed Dec 23 2009 Kevin Kofler - 4.6.0-3 - disable QtWebKit JavaScript JIT again, incompatible with SELinux (#549994) rst2pdf-0.12.3-1.fc13 --------------------- * Wed Dec 23 2009 Sergio Pascual - 0.12.3-1 - New upstream source selinux-policy-3.7.5-4.fc13 --------------------------- * Wed Dec 23 2009 Dan Walsh 3.7.5-4 - Cleanups from dgrift sextractor-2.8.6-1.fc13 ----------------------- * Wed Aug 26 2009 Sergio Pascual - 2.8.6-1 - New upstream source sugar-0.87.2-1.fc13 ------------------- * Wed Dec 23 2009 Sebastian Dziallas - 0.87.2-1 - New upstream release sugar-datastore-0.87.2-1.fc13 ----------------------------- * Wed Dec 23 2009 Sebastian Dziallas - 0.87.2-1 - New upstream release sugar-jukebox-13-1.fc13 ----------------------- * Wed Dec 23 2009 Sebastian Dziallas - 13-1 - New upstream release sugar-read-78-1.fc13 -------------------- * Wed Dec 23 2009 Sebastian Dziallas - 78-1 - New upstream release sugar-toolkit-0.87.2-1.fc13 --------------------------- * Wed Dec 23 2009 Sebastian Dziallas - 0.87.2-1 - New upstream release sugar-turtleart-81-1.fc13 ------------------------- * Wed Dec 23 2009 Sebastian Dziallas - 81-1 - New upstream release symkey-1.3.0-4.fc13 ------------------- synfig-0.62.00-3.fc13 --------------------- * Thu Dec 24 2009 Lubomir Rintel - 0.62.00-3 - Actually apply the optflags patch - Drop bundled libltdl synfigstudio-0.62.00-2.fc13 --------------------------- * Thu Dec 24 2009 Lubomir Rintel - 0.62.00-2 - Fix optflags use (Ville Skytt?, #549420) system-config-printer-1.1.16-2.fc13 ----------------------------------- * Wed Dec 23 2009 Tim Waugh - 1.1.16-2 - Prefer foomatic-recommended drivers (bug #550108). - Pre-select correct driver when adding or changing a queue (bug #550075). - Fixed typo (bug #550096). ugene-1.6.0-2.fc13 ------------------ * Wed Dec 23 2009 Ivan Efremov - 1.6.0-1 - Upstream version change uget-1.5.0.1-1.fc13 ------------------- * Wed Dec 23 2009 Mamoru Tasaka - 1.5.0.1-1 - 1.5.0.1 (which should fix bug 546289) varnish-2.0.6-2.fc13 -------------------- * Wed Dec 23 2009 Ingvar Hagelund - 2.0.6-2 - Added a test that enables jemalloc on ppc if the kernel is not a rhel5 kernel (as on redhat builders) - Removed tests c00031.vtc and r00387on rhel4/ppc as they fail on the Red Hat ppc builders (but works on my rhel4 ppc instance) - Added a patch that fixes broken changes-2.0.6.html in doc yokadi-0.11.2-1.fc13 -------------------- * Wed Dec 23 2009 Fabian Affolter - 0.11.2-1 - Updated to new upstream version 0.11.2 * Fri Nov 20 2009 Fabian Affolter - 0.11.1-1 - Updated to new upstream version 0.11.1 Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 54 From kyle at mcmartin.ca Thu Dec 24 18:49:49 2009 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 24 Dec 2009 13:49:49 -0500 Subject: Kernel security update required or not? In-Reply-To: <1261355603.1981.3.camel@shrek.rexursive.com> References: <1261355603.1981.3.camel@shrek.rexursive.com> Message-ID: <20091224184949.GD11593@bombadil.infradead.org> On Mon, Dec 21, 2009 at 11:33:23AM +1100, Bojan Smojver wrote: > According to this: http://lwn.net/Articles/367443/, latest kernel > updates have security fixes (the second one appears on the 2.6.31.9 > list). > > Is this something that has been backported to current F-12 kernels (I > don't see it in changelog), or do we need a security update for F-12 > here? > Sorry, I forgot to push it to bodhi after the build completed (blame ppc, it takes far too long.) They should be pushed now (with an extra fix to fuse.) In the future, if you want to ask such questions, fedora-kernel-list would be much more appropriate. I for one, don't have time to read fedora-devel-list often. regards, Kyle. From bruno at wolff.to Thu Dec 24 21:14:04 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 24 Dec 2009 15:14:04 -0600 Subject: New covenant published In-Reply-To: <8278b1b0912231314xd108454hba327d3069411bde@mail.gmail.com> References: <1261220453.6025.11.camel@localhost.localdomain> <4B2CB2FE.902@alexhudson.com> <4B31EBF4.5010906@alexhudson.com> <4B326576.9080504@redhat.com> <4B3267C7.6050301@alexhudson.com> <4B326839.6030808@redhat.com> <4B326B16.4000606@alexhudson.com> <8278b1b0912231314xd108454hba327d3069411bde@mail.gmail.com> Message-ID: <20091224211404.GA24549@wolff.to> On Wed, Dec 23, 2009 at 15:14:40 -0600, Sir Gallantmon wrote: > Then I guess we shouldn't have AJAX either, since Microsoft developed one of > the core technologies behind AJAX. And for the running foreign code on your machine adds extra risk above just running a complicated beast like a graphical web browser. From paul at all-the-johnsons.co.uk Thu Dec 24 22:58:23 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 24 Dec 2009 22:58:23 +0000 Subject: Mono.Cecil & monodevelop-debugger-mdb Message-ID: <1261695503.2989.324.camel@PB3.linux> Hi, MD-debugger-mdb is currently broken for rawhide. I've tried many ways to get it to build and have finally asked for help from the the md mailing list. The big problem is that we're using a system wide Mono.Cecil rather than individual packages having their own version of Mono.Cecil. Here's the conversation followed by a request from me... 8--> On Wed, Dec 23, 2009 at 4:14 PM, Paul wrote: > I've got MD-2.2 installed from Fedora rawhide and am trying to build the > MD debugger plugin. Problem is that it's looking for Mono.Cecil in the > MD addins. > > With Fedora, we use a system wide Mono.Cecil instead of having a pile of > them around the place. We use a local copy of Cecil because Cecil API is (was?) not guaranteed to be stable and therefor the library is *supposed* to be bundled with apps. This also allows us to rely on the exact behaviour of the version we ship. By upgrading MD's Cecil to one it has not been tested with, Fedora is potentially exposing their users to bugs that we will be unable to reproduce and fix. See http://www.mono-project.com/Cecil#Using_Cecil <--8 Given this, should we change the approach we currently have for using the system wide Mono.Cecil and allow the likes of MD to ship with it's own version of Mono.Cecil? Mono.Cecil is not added into GAC so having different versions of Mono.Cecil for different applications should not cause conflicts. "Should" is being used in it's lightest sense! TTFN Paul P.S. Going off until Boxing Day now, so Merry Christmas to you all! -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Fri Dec 25 13:09:44 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 25 Dec 2009 13:09:44 +0000 Subject: rawhide report: 20091225 changes Message-ID: <20091225130944.GA12281@releng2.fedora.phx.redhat.com> Compose started at Fri Dec 25 08:15:09 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.i686 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-devel-2.1.1.2-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-doc-2.1.1.2-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-GLUT-prof-2.1.1.2-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.i686 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-devel-2.2.1.1-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-doc-2.2.1.1-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-OpenGL-prof-2.2.1.1-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.i686 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-devel-0.3.1.0-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-doc-0.3.1.0-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-tar-prof-0.3.1.0-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package python-jabberbot A simple jabber (XMPP) bot framework New package python-zdaemon Python Daemon Process Control Library Updated Packages: CGAL-3.5.1-1.fc13 ----------------- * Thu Dec 24 2009 - 3.5.1-1 - New upstream release cabal2spec-0.20.1-1.fc13 ------------------------ * Fri Dec 25 2009 Jens Petersen - 0.20.1-1 - add support for shared libraries and updates for ghc-6.12: - lib and binlib package now have shared library subpackages - bin packages link dynamically (not binlib due to prof conflict) - new common_summary and common_description simplify subpackaging - library packages have debugging for stripping - specify BR ghc-rpm-macros >= 0.4.0 for new macros: ghc_requires, ghc_doc_requires, ghc_prof_requires, cabal_pkg_conf (replaces ghc_gen_scripts and ghc_install_scripts), and "ghc-pkg recache" replaces ghc_register_pkg and ghc_unregister_pkg. - cabal2spec version now appears in changelog cups-1.4.2-22.fc13 ------------------ * Thu Dec 24 2009 Tim Waugh - 1:1.4.2-22 - Removed use of prereq and buildprereq. - Fixed use of '%' in changelog. - Versioned explicit obsoletes/provides. - Use tabs throughout. ejabberd-2.1.1-1.fc13 --------------------- * Thu Dec 24 2009 Peter Lemenkov 2.1.1-1 - Ver. 2.1.1 - Dropped patches 9,11,12,13 (accepted upstream) exim-4.71-1.fc13 ---------------- * Thu Dec 24 2009 David Woodhouse - 4.69-20 - Update to 4.71 fswebcam-20091224-1.fc13 ------------------------ * Thu Dec 24 2009 Fabian Affolter - 20091224-1 - Updated to new upstream version 20091224 gant-1.8.1-2.fc13 ----------------- * Thu Dec 24 2009 Lubomir Rintel - 1.8.1-2 - Add manual - Add bash completion configuration - Add startup script ghostscript-8.70-3.fc13 ----------------------- * Thu Dec 24 2009 Tim Waugh 8.70-3 - Don't ship libtool la files (bug #542674). - Fix debugging output from gdevcups (CVE-2009-4270, bug #540760). - Harden ghostscript's debugging output functions (bug #540760). git-1.6.6-1.fc13 ---------------- * Wed Dec 23 2009 Todd Zullinger - 1.6.6-1 - git-1.6.6 * Fri Dec 11 2009 Todd Zullinger - 1.6.5.6-1 - git-1.6.5.6 ibus-1.2.0.20091225-1.fc13 -------------------------- * Fri Dec 25 2009 Peng Huang - 1.2.0.2001225-1 - Update to 1.2.0.20091225 - Fix bug 513895 - new IME does not show up in ibus-setup - Fix bug 531857 - applet order should correspond with preferences order - Fix bug 532856 - should not list already added input-methods in Add selector kernel-2.6.32.2-15.fc13 ----------------------- * Thu Dec 24 2009 Kyle McMartin 2.6.32.2-15 - Add patch from dri-devel to fix vblanks on r600. [http://marc.info/?l=dri-devel&m=126137027403059&w=2] lohit-assamese-fonts-2.4.3-3.fc13 --------------------------------- * Thu Dec 24 2009 Pravin Satpute - 2.4.3-3 - fixes bug 548686 and 549319 lohit-bengali-fonts-2.4.3-4.fc13 -------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-4 - fixed bug 548686, license field lohit-gujarati-fonts-2.4.4-2.fc13 --------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-4 - fixed bug 548686, license field lohit-hindi-fonts-2.4.3-3.fc13 ------------------------------ * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-kannada-fonts-2.4.4-3.fc13 -------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-kashmiri-fonts-2.4.3-3.fc13 --------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field - corrected source url lohit-konkani-fonts-2.4.3-3.fc13 -------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-maithili-fonts-2.4.3-3.fc13 --------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field - corrected source link lohit-malayalam-fonts-2.4.4-4.fc13 ---------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.4-4 - fixed bug 548686, license field lohit-marathi-fonts-2.4.3-3.fc13 -------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-nepali-fonts-2.4.3-3.fc13 ------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-oriya-fonts-2.4.3-3.fc13 ------------------------------ * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field - corrected source url lohit-punjabi-fonts-2.4.3-3.fc13 -------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-sindhi-fonts-2.4.3-3.fc13 ------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.3-3 - fixed bug 548686, license field lohit-tamil-fonts-2.4.5-2.fc13 ------------------------------ * Sun Dec 13 2009 Pravin Satpute - 2.4.5-2 - fixed bug 548686, license field lohit-telugu-fonts-2.4.5-2.fc13 ------------------------------- * Sun Dec 13 2009 Pravin Satpute - 2.4.5-2 - fixed bug 548686, license field mcs-0.7.1-8.fc13 ---------------- mscore-0.9.5-3.fc13 ------------------- * Tue Dec 22 2009 Orcan Ogetbil 0.9.5-2 - Add default soundfont support for exported audio files - Rebuild against new libsndfile for additional functionality - Drop F-10 related bits from specfile - Make fonts subpackage noarch - Fix build failure on arm architecture * Tue Dec 22 2009 Orcan Ogetbil 0.9.5-3 - Fix build flags on F-11 muse-1.0-1.fc13 --------------- * Thu Dec 24 2009 Orcan Ogetbil 1:1.0-1 - Update to 1.0 nted-1.9.13-1.fc13 ------------------ * Thu Dec 24 2009 Hans Ulrich Niedermann - 1.9.13-1 - Update to 1.9.13 openoffice.org-3.2.0-8.4.fc13 ----------------------------- * Thu Dec 24 2009 Caol?n McNamara - 1:3.2.0-8.4 - Resolves: rhbz#489489 enable Romanian translations patch-2.6-2.fc13 ---------------- * Thu Dec 24 2009 Tim Waugh 2.6-2 - Applied upstream patch to prevent incorrect filename being chosen when adding a new file (bug #549122). php-ezc-Archive-1.4-1.fc13 -------------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.4-1 - Upstream 1.4 php-ezc-Base-1.8-1.fc13 ----------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.8-1 - upstream 1.8 php-ezc-Cache-1.5-1.fc13 ------------------------ * Thu Dec 24 2009 Guillaume Kulakowski - 1.5-1 - Upstream 1.5 php-ezc-ConsoleTools-1.6-1.fc13 ------------------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.6-1 - Upstream 1.6 php-ezc-Feed-1.3-1.fc13 ----------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.3-1 - Upstream 1.3 php-ezc-Mail-1.7-1.fc13 ----------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.7-1 - Upstream 1.7 php-ezc-PersistentObject-1.7-1.fc13 ----------------------------------- * Thu Dec 24 2009 Guillaume Kulakowski - 1.7-1 - Upstream 1.7 teeworlds-0.5.2-2.fc13 ---------------------- * Thu Dec 24 2009 Simon Wesp 0.5.2-1 - New upstream release * Thu Dec 24 2009 Simon Wesp 0.5.2-2 - convert iso files to utf8 xqf-1.0.5-9.fc12 ---------------- * Sun Nov 08 2009 Simon Wesp - 1.0.5-9 - Fix RHBZ #533704 #533705 - Cosmetical changes Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 42 From kevin.kofler at chello.at Fri Dec 25 15:49:08 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Dec 2009 16:49:08 +0100 Subject: dist-git proof of concept phase 2 ready for testing References: <1261179109.19834.48.camel@localhost.localdomain> <45abe7d80912190941k54574375m843c4c5572030bc7@mail.gmail.com> <1261249017.2271.5.camel@localhost.localdomain> <20091220102816.658487f6@n-dimensional.de> <1261366290.2271.12.camel@localhost.localdomain> <1261447855.2271.43.camel@localhost.localdomain> <4B30E75A.500@redhat.com> <1261599706.11511.11.camel@localhost.localdomain> <4B3281A2.4080508@redhat.com> <1261603055.11511.13.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > I understand the use case, I'm still not super keen on having official > built packages come out of a branch. Makes discovery somewhat > difficult, and leads to problems if we have to bump+build something and > don't realize that the real live code is actually on a branch. At least the kernel and KDE folks want this, that's a significant proportion of Fedora in terms of LOC. For KDE, we've done the "temp revert" hack at times, but IMHO that really sucks, this is what branches are for. It's basically impossible to properly maintain a large project without doing either temp reverts (yuck!) or branches (what we had hoped the switch to git would make easier, not harder or outright impossible ? our CVS setup allows it, perhaps accidentally, but whether this was intended or not, it is being used in the wild and a few of us rely on this in their workflow). One branch per distro version is not enough. Kevin Kofler From kevin.kofler at chello.at Fri Dec 25 15:55:57 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Dec 2009 16:55:57 +0100 Subject: Mono.Cecil & monodevelop-debugger-mdb References: <1261695503.2989.324.camel@PB3.linux> Message-ID: Paul wrote: > Given this, should we change the approach we currently have for using > the system wide Mono.Cecil and allow the likes of MD to ship with it's > own version of Mono.Cecil? No, we should patch the broken packages to work with the current Mono.Cecil. And upstream deserves a beating for this attitude. :-/ Why am I not surprised this is coming from the M$-loving Mono community? In any case, if you do think an exception should be granted, this will have to go through FESCo. But I doubt we will approve it, at least not if you don't provide evidence that somebody competent in C# tried to patch MonoDebugger to work with the new Mono.Cecil and failed due to some unsurmountable obstacle. If none of you Mono SIG folks is fluent in C#, then that's a problem that needs solving first of all. Kevin Kofler From mschwendt at gmail.com Fri Dec 25 21:33:16 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 25 Dec 2009 22:33:16 +0100 Subject: rpms/i3/devel .cvsignore, 1.2, 1.3 i3.spec, 1.1, 1.2 import.log, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <20091225212916.DE10D11C00E6@cvs1.fedora.phx.redhat.com> References: <20091225212916.DE10D11C00E6@cvs1.fedora.phx.redhat.com> Message-ID: <20091225223316.76ef2c0a@gmail.com> On Fri, 25 Dec 2009 21:29:16 +0000 (UTC), Simon wrote: > Author: cassmodiah > > Update of /cvs/pkgs/rpms/i3/devel > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21345/devel > > Modified Files: > .cvsignore i3.spec import.log sources > Log Message: > 3.d -> 3.d-bf1 > Name: i3 > Version: 3.d > -Release: 1%{?dist} > +Release: bf1_1%{?dist} Caution! 1 is higher than bf1_1 Use "rpmdev-vercmp" from rpmdevtools package to verify. From cassmodiah at fedoraproject.org Fri Dec 25 23:14:14 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Sat, 26 Dec 2009 00:14:14 +0100 Subject: rpms/i3/devel .cvsignore, 1.2, 1.3 i3.spec, 1.1, 1.2 import.log, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <20091225223316.76ef2c0a@gmail.com> References: <20091225212916.DE10D11C00E6@cvs1.fedora.phx.redhat.com> <20091225223316.76ef2c0a@gmail.com> Message-ID: <1261782854.1858.4.camel@localhost.localdomain> Am Freitag, den 25.12.2009, 22:33 +0100 schrieb Michael Schwendt: > On Fri, 25 Dec 2009 21:29:16 +0000 (UTC), Simon wrote: > > > Author: cassmodiah > > > > Update of /cvs/pkgs/rpms/i3/devel > > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21345/devel > > > > Modified Files: > > .cvsignore i3.spec import.log sources > > Log Message: > > 3.d -> 3.d-bf1 > > > Name: i3 > > Version: 3.d > > -Release: 1%{?dist} > > +Release: bf1_1%{?dist} > > Caution! 1 is higher than bf1_1 > Use "rpmdev-vercmp" from rpmdevtools package to verify. Fixed, thank you for this hint! -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rawhide at fedoraproject.org Sat Dec 26 15:41:06 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 26 Dec 2009 15:41:06 +0000 Subject: rawhide report: 20091226 changes Message-ID: <20091226154106.GA21023@releng2.fedora.phx.redhat.com> Compose started at Sat Dec 26 08:15:05 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Updated Packages: audacious-plugins-2.2-4.fc13 ---------------------------- * Fri Dec 25 2009 Michael Schwendt - 2.2-4 - Let bluetooth plugin access "alsa-gapless" config values not "alsa" as it will be called in post-2.2. bluez-4.59-1.fc13 ----------------- * Fri Dec 25 2009 Bastien Nocera 4.59-1 - Update to 4.59 file-5.03-17.fc13 ----------------- * Fri Dec 25 2009 Robert Scheck 5.03-17 - removed broken install of example.py (%doc is much enough) ghc-GLUT-2.1.1.2-3.fc13 ----------------------- * Sat Dec 26 2009 Jens Petersen - 2.1.1.2-3 - update for ghc-6.12.1: add shared library support - use new ghc*_requires macros: needs ghc-rpm-macros 0.4.0 - add common_summary and common_description ghc-OpenGL-2.2.1.1-2.fc13 ------------------------- * Sat Dec 26 2009 Jens Petersen - 2.2.1.1-2 - update for ghc-6.12.1: add shared library support - use new ghc*_requires macros: needs ghc-rpm-macros 0.4.0 - add common_summary and common_description ghc-tar-0.3.1.0-2.fc13 ---------------------- * Sat Dec 26 2009 Jens Petersen - 0.3.1.0-2 - update for ghc-6.12.1: add shared library support - use new ghc*_requires macros: needs ghc-rpm-macros 0.4.0 - add common_summary and common_description ghc-zlib-0.5.0.0-12.fc13 ------------------------ * Sat Dec 26 2009 Jens Petersen - 0.5.0.0-12 - update to cabal2spec-0.20 and ghc-rpm-macros-0.4.0: - use common_summary and common_description - reenable debuginfo for stripping - use ghc_requires, ghc_doc_requires, and ghc_prof_requires * Tue Dec 22 2009 Jens Petersen - fix base Group and devel Summary - only include docdir in devel if not shared build hamster-applet-2.29.4-1.fc13 ---------------------------- * Fri Dec 25 2009 Mads Villadsen - 2.29.4-1 - Update to 2.29.4 - Rework some dependencies towards HalRemoval (https://fedoraproject.org/wiki/Features/HalRemoval) i3-3.d.bf1-1.fc13 ----------------- * Fri Dec 25 2009 Simon Wesp - 3.d-bf1_1 - New upstream release * Fri Dec 25 2009 Simon Wesp - 3.d.bf1-1 - Correct version (https://www.redhat.com/archives/fedora-devel-list/2009-December/msg01102.html) Thank you Michael - Add more documentation (generated with asciidoc) jd-2.5.5-0.4.rc091225.fc13 -------------------------- * Sat Dec 26 2009 Mamoru Tasaka - 2.5.5-0.4.beta091225 - 2.5.5 rc 091225 kcm-gtk-0.5.3-3.fc13 -------------------- * Fri Dec 25 2009 Rex Dieter 0.5.3-3 - GTK2_RC_FILES handling moved to kde-settings (#547700) kde-settings-4.4-6 ------------------ * Fri Dec 25 2009 Rex Dieter 4.4-6 - use qtcurve-gtk2 by default (#547700) mapserver-5.6.0-1.fc13 ---------------------- * Fri Dec 25 2009 Devrim GUNDUZ - 5.6.0-1 - Update to 5.6.0 memtest86+-4.00-3.fc13 ---------------------- * Fri Dec 25 2009 Robert Scheck - 4.00-3 - Removed obsolete build requirement to compat-gcc-34 (#442285) mysqltuner-1.1.1-1.fc13 ----------------------- * Fri Dec 25 2009 Ville Skytt? - 1.1.1-1 - Update to 1.1.1. - Improve summary. nntpgrab-0.5.90-1.fc13 ---------------------- * Fri Dec 25 2009 Erik van Pienbroek - 0.5.90-1 - Update to 0.5.90 (0.6 Beta 1) osutil-1.3.1-1.fc13 ------------------- * Mon Dec 14 2009 Kevin Wright 1.3.1-1 - Removed BuildRequires bash - Removed 'with exceptions' from License postgresql-pgpool-II-2.3.1-1.fc13 --------------------------------- * Fri Dec 25 2009 Devrim GUNDUZ - 2.3.1-1 - Update to 2.3.1 - Adjust order of startup and kill, per RH bugzilla #545739. pyabiword-0.8.0-3.fc13 ---------------------- * Wed Dec 23 2009 Rahul Sundaram - 0.8.0-3 - Rebuild agains since the wv soname bump was accidental - Remove superflous BuildRoot definitions and removals * Mon Dec 21 2009 Peter Robinson - 0.8.0-2 - Rebuild against new libwv zfs-fuse-0.6.0-5.fc13 --------------------- * Sat Dec 26 2009 Uwe Kubosh - 0.6.0-4 - Updated to upstream version 0.6.0 STABLE * Sat Dec 26 2009 Uwe Kubosh - 0.6.0-5 - Removed chckconfig on and service start commands from install script See https://fedoraproject.org/wiki/Packaging:SysVInitScript#Why_don.27t_we Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 20 From kondo8 at hotmail.com Sat Dec 26 18:33:43 2009 From: kondo8 at hotmail.com (Daniel Hendrycks) Date: Sat, 26 Dec 2009 12:33:43 -0600 Subject: Wiki Feature Dashboard Additional Category Message-ID: Who would implement this, if this is approved by many would someone do it or do I need to find an employee to do it? Is this mailing list a suggestion forum for those that can do or can some do it themselves? How does this work? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From abo at root.snowtree.se Sat Dec 26 18:34:21 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 26 Dec 2009 19:34:21 +0100 Subject: (huge) Ruby packaging changes In-Reply-To: <4B32B395.1040006@kanarip.com> References: <4B3008AD.8050002@kanarip.com> <200912221936.13747.ville.skytta@iki.fi> <4B32B395.1040006@kanarip.com> Message-ID: <1261852461.16688.13.camel@tempo.alexander.bostrom.net> tor 2009-12-24 klockan 01:19 +0100 skrev Jeroen van Meeuwen: > The beast that is Java ;-) A very successful example where alternatives > is used heavily is of course a system's mail stack. I think it can be > done right, but the question is how. > > > On the other hand, if I got your intent right, environment-modules might be > > something to look into here. > > > > Care to explain the term environment-modules for me please? See Rahul's link, but it's a way to modify PATH, MANPATH etc. in a structured way. The alternatives system is configured by root and applies to everyone, the modules system is per-user or even per-process. It sounds like your use case needs a per-user or per-process choice, so I suggest you either use environment-modules or forego both modules and the alternatives system and just teach users and packagers to call ruby-1.8 instead of ruby when they need this version. As mentioned, two typical uses of alternatives are: Which MTA to use: Sendmail or something else? This is naturally root's domain. Users shouldn't have to care. Which Java to use: Mostly it's automatic. You install a bunch of Java implementations and alternatives then picks the "best" one based on priorities. Neither root nor users usually need to override it, but if they want to they can, by adding /usr/lib/jvm/java-1.6.0-openjdk/bin or similar to PATH, which is basically what modules does. /abo From paul at all-the-johnsons.co.uk Sat Dec 26 22:41:26 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 26 Dec 2009 22:41:26 +0000 Subject: Mono.Cecil & monodevelop-debugger-mdb In-Reply-To: References: <1261695503.2989.324.camel@PB3.linux> Message-ID: <1261867286.24974.3.camel@PB3.linux> Hi, > No, we should patch the broken packages to work with the current > Mono.Cecil. > And upstream deserves a beating for this attitude. :-/ Why am I not > surprised this is coming from the M$-loving Mono community? I quite agree - there should be a universal mono.cecil. > In any case, if you do think an exception should be granted, this will > have > to go through FESCo. But I doubt we will approve it, at least not if > you > don't provide evidence that somebody competent in C# tried to patch > MonoDebugger to work with the new Mono.Cecil and failed due to some > unsurmountable obstacle. If none of you Mono SIG folks is fluent in > C#, then > that's a problem that needs solving first of all. MD itself works fine with Mono.Cecil as provided by other packages. The problem is MD also copies Mono.Cecil to %{_libdir}/monodevelop/bin which is what is being picked up on when -pkg:monodevelop is referenced in the make file. It's not a problem with MD or Mono.Cecil really... Oh well. I'll look at it (again) on the 28th. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Sun Dec 27 12:56:34 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 27 Dec 2009 12:56:34 +0000 Subject: rawhide report: 20091227 changes Message-ID: <20091227125634.GA2019@releng2.fedora.phx.redhat.com> Compose started at Sun Dec 27 08:15:07 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package python-olpcgames Utilities for developing games on the OLPC platform Updated Packages: acl-2.2.49-2.fc13 ----------------- * Sat Dec 26 2009 Kamil Dudka 2.2.49-2 - tweaked setfacl tree walk flags (#488674), thanks to Markus Steinborn bash-completion-1.1-5.fc13 -------------------------- * Sat Dec 26 2009 Ville Skytt? - 1:1.1-5 - Apply upstream post 1.1 generic vncviewer fixes. - Autoinstall vncviewer completion also on tigervnc. - Autoinstall chsh completion also on util-linux. colossus-0.10.0-1.fc13 ---------------------- * Sat Dec 26 2009 Bruno Wolff III - 0.10.0-1 - Rebase to 0.10.0 - Fixed undo that reblocks a split - Fix AI crash - Enable public game server alpha feature - See http://colossus.sourceforge.net/docs/RecentChangesDetails.html - Include post release typo fix as a patch compizconfig-backend-gconf-0.8.2-3.fc13 --------------------------------------- * Sat Dec 26 2009 Leigh Scott - 0.8.2-3 - add patch to fix keybindings. (bug #550691) duplicity-0.6.06-1.fc13 ----------------------- * Sat Dec 26 2009 Robert Scheck 0.6.06-1 - Upgrade to 0.6.06 (#550663) em8300-0.17.4-1.fc12 -------------------- * Fri Dec 25 2009 Ville Skytt? - 0.17.4-1 - Update to 0.17.4. emacs-bbdb-2.35-4.fc13 ---------------------- * Sat Dec 26 2009 Jonathan G. Underwood - 1:2.35-4 - Update spec file to use macros installed with the emacs package rather than pkgconfig stuff - Remove BuildRoot and rm -rf buildroot from install section emacs-vm-8.1.0-0.1.beta.fc13 ---------------------------- * Sat Dec 26 2009 Jonathan G. Underwood - 8.0.14-2 - Add -fno-var-tracking-assignments to CFLAGS to allow build to complete (gcc bug http://gcc.gnu.org/PR41371) * Sat Dec 26 2009 Jonathan G. Underwood - 8.1.0-0.1.beta - Update to 8.1.0 beta version * Fri Dec 18 2009 Jonathan G. Underwood - 8.0.14-1 - Update to 8.0.14 - Drop old macros for emacspackaging and use _emacs macros - Remove BuildRoot definition - No longer delete buildroot at beginning of install * Wed Sep 16 2009 Jonathan G. Underwood - 8.0.12-5 - Add patch to fix charset recognition with emacs 23 - Bump minimum emacs to version 23.1 - Rebuild against emacs 23.1 * Wed Sep 16 2009 Jonathan G. Underwood - 8.0.12-6 - Bump release to fix up cvs problem fbzx-2.2.0-1.fc13 ----------------- * Sat Dec 26 2009 Andrea Musuruane 2.2.0-1 - Updated to new upstream release fedora-setup-keyboard-0.6-1.fc13 -------------------------------- * Sat Dec 26 2009 Adel Gadllah 0.6-1 - 0.6 release - Fixes RH #545970 kde-plasma-smooth-tasks-0.0.1-0.1.wip20091206.fc13 -------------------------------------------------- * Sun Dec 27 2009 Thomas Janssen 0.0.1-0.1.wip20091206 - NEW: also do middle click action on tooltip - FIX: chinese translation by Weng Xuetian (hurricanek) kdelibs-4.3.85-5.fc13 --------------------- * Sat Dec 26 2009 Rex Dieter - 4.3.85-5 - move kdecmake,makekdewidgets manpages to -devel (#549947) mc-4.7.0-1.fc13 --------------- * Sat Dec 26 2009 Jindrich Novy 4.7.0-1 - update to official 4.7.0 mkvtoolnix-3.0.0-1.fc13 ----------------------- * Sat Dec 26 2009 Dominik Mierzejewski 3.0.0-1 - updated to 3.0.0 - dropped upstream'd patches mono-debugger-2.6-3.fc13 ------------------------ * Sun Dec 27 2009 Paul F. Johnson 2.6-3 - Fix mono-debugger.pc.in file for x86_64 monodevelop-2.2-2.fc13 ---------------------- * Sat Dec 26 2009 Paul F. Johnson 2.2-2 - Patch monodevelop.pc file for more monocecil fixes nano-2.2.1-1.fc13 ----------------- * Sun Dec 27 2009 Kamil Dudka - 2.2.1-1 - new upstream release perl-CGI-Application-Plugin-DevPopup-1.04-1.fc13 ------------------------------------------------ * Sat Dec 26 2009 Emmanuel Seyman - 1.04-1 - Update to 1.04 php-pear-Log-1.11.6-1.fc13 -------------------------- * Sat Dec 26 2009 Remi Collet 1.11.6-1 - update to 1.11.6 pygtk2-2.17.0-1.fc13 -------------------- * Sat Dec 26 2009 Matthew Barnes - 2.17.0-1.fc13 - Update to 2.17.0 rygel-0.4.8-2.fc13 ------------------ * Sat Dec 26 2009 Peter Robinson 0.4.8-2 - Update description * Tue Dec 22 2009 Peter Robinson 0.4.8-1 - Update to 0.4.8 stardict-3.0.1-21.fc13 ---------------------- * Sun Dec 27 2009 Caius 'kaio' Chance - 3.0.1-20 - Disable netdict by default and set warning for security. * Sun Dec 27 2009 Caius 'kaio' Chance - 3.0.1-21 - rebuilt tachyon-0.98.7-2.fc13 --------------------- * Sat Dec 26 2009 Dominik 'Rathann' Mierzejewski 0.98.7-2 - drop LAM support - add shared library (based on Debian patch) - simplify some specfile constructs - improve descriptions virtaal-0.5.1-1.fc13 -------------------- * Sat Dec 26 2009 Dwayne Bailey - 0.5.1-1 - Update to 0.5.1 - Fixed URI-handling bug for opening files. - New translations: Chinese (Taiwan) and Lithuanian. vnstat-1.9-2.fc13 ----------------- * Sat Dec 26 2009 Robert Scheck - 1.9-1 - Upgrade to 1.9 and make rpmlint more silent - Make %pre script with useradd more conform to guidelines - Replace %{_initddir} macro for more easy EPEL support - Preserve timestamps when using sed to manipulate files * Sat Dec 26 2009 Robert Scheck - 1.9-2 - Work around a buffer overflow in vnstati until 1.10 (#550635) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 25 From jussilehtola at fedoraproject.org Sun Dec 27 15:52:44 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 27 Dec 2009 17:52:44 +0200 Subject: Pondus license change GPLv3+ -> MIT Message-ID: <1261929164.4887.5.camel@localhost> Hi all, pondus was previously licensed under GPLv3+; now starting from 0.7.0 the license is MIT. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From lists at sapience.com Sun Dec 27 17:10:42 2009 From: lists at sapience.com (Mail Lists) Date: Sun, 27 Dec 2009 12:10:42 -0500 Subject: realtex 8172 / 8192 Message-ID: <4B379512.8030508@sapience.com> As posted on fedora-list (sorry for x-post) A friend of mine has a lenovo with a RT 8172 wireless ... neither ubuntu 9.10 nor f12 seems to support this. Seems its available in 2.6.32 ... Ok - so anyone know when 2.6.32 will be available in f12 / f11 ? From paul at all-the-johnsons.co.uk Sun Dec 27 17:20:42 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 27 Dec 2009 17:20:42 +0000 Subject: rawhide report: 20091227 changes In-Reply-To: <20091227125634.GA2019@releng2.fedora.phx.redhat.com> References: <20091227125634.GA2019@releng2.fedora.phx.redhat.com> Message-ID: <1261934442.3496.0.camel@PB3.linux> Hi, > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.Debugger) = 0:2.1.0.0 > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.Core) = 0:2.1.0.0 > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires > mono(MonoDevelop.AspNet) = 0:2.1.0.0 Fixed. Grab it from koji now or wait until tomorrows rawhide update. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ikem.krueger at googlemail.com Sun Dec 27 17:43:05 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Sun, 27 Dec 2009 17:43:05 +0000 Subject: Pondus license change GPLv3+ -> MIT In-Reply-To: <1261929164.4887.5.camel@localhost> References: <1261929164.4887.5.camel@localhost> Message-ID: > Hi all, > pondus was previously licensed under GPLv3+; now starting from 0.7.0 the license is MIT. That's doable? o.O From ikem.krueger at googlemail.com Sun Dec 27 18:16:16 2009 From: ikem.krueger at googlemail.com (Ikem Krueger) Date: Sun, 27 Dec 2009 18:16:16 +0000 Subject: Wiki Feature Dashboard Additional Category In-Reply-To: References: Message-ID: > Wiki Feature Dashboard Additional Category > Who would implement this, if this is approved by many would someone do it or do I need to find an employee to do it? > Is this mailing list a suggestion forum for those that can do or can some do it themselves? Well, I think it's better you post your idea here: http://my.opera.com/community/forums/forum.dml?id=24 From bruno at wolff.to Sun Dec 27 18:35:10 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 27 Dec 2009 12:35:10 -0600 Subject: realtex 8172 / 8192 In-Reply-To: <4B379512.8030508@sapience.com> References: <4B379512.8030508@sapience.com> Message-ID: <20091227183510.GA15451@wolff.to> On Sun, Dec 27, 2009 at 12:10:42 -0500, Mail Lists wrote: > > As posted on fedora-list (sorry for x-post) > > > A friend of mine has a lenovo with a RT 8172 wireless ... neither > ubuntu 9.10 nor f12 seems to support this. > > Seems its available in 2.6.32 ... > > Ok - so anyone know when 2.6.32 will be available in f12 / f11 ? You might try the rawhide kernel in f12. There is a reasonable chance that will work. I have been having some problems with it myself and am running the f12 kernel on a rawhide system. The issues I am seeing are a hang requiring nomodeset (ATI r200 video card) and another hang related to udev with encrypted devices requiring a modified dm rule. I also see traceback warnings during the boot, so some other things are probably broken as well. From fedora at camperquake.de Sun Dec 27 20:25:45 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 27 Dec 2009 21:25:45 +0100 Subject: Pondus license change GPLv3+ -> MIT In-Reply-To: References: <1261929164.4887.5.camel@localhost> Message-ID: <20091227212545.5563d391@fred.camperquake.de> Hi. On Sun, 27 Dec 2009 17:43:05 +0000, Ikem Krueger wrote > That's doable? o.O The copyright holder can relicense the code however they see fit. What they cannot do is retroactively remove the GPL license from old versions. From kondo8 at hotmail.com Sun Dec 27 22:18:57 2009 From: kondo8 at hotmail.com (Daniel Hendrycks) Date: Sun, 27 Dec 2009 16:18:57 -0600 Subject: Wiki Feature Dashboard Additional Category Message-ID: "Well, I think it's better you post your idea here: http://my.opera.com/community/forums/forum.dml?id=24" Why don't you be helpful rather than point me to an irrelevant link (although I do love that place)? Please actually help. :( -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From mail at robertoragusa.it Sun Dec 27 22:32:04 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 27 Dec 2009 23:32:04 +0100 Subject: Pondus license change GPLv3+ -> MIT In-Reply-To: <20091227212545.5563d391@fred.camperquake.de> References: <1261929164.4887.5.camel@localhost> <20091227212545.5563d391@fred.camperquake.de> Message-ID: <4B37E064.3050106@robertoragusa.it> Ralf Ertzinger wrote: > Hi. > > On Sun, 27 Dec 2009 17:43:05 +0000, Ikem Krueger wrote > >> That's doable? o.O > > The copyright holder can relicense the code however they see fit. > What they cannot do is retroactively remove the GPL license from > old versions. Relicensing is complicated when there are a lot of authors (copyright holders), because it is necessary to get the approval of everyone of them, with complications for unreachable people and dead people; in the past discussions on the GPLv2-GPLv3 relicensing for the kernel, there was an additional opinion that this requirement is not as stringent as it appears. In any case, relicensing a small project with a few authors (or just one) is as easy as editing a couple of files (source, webpage, ...). -- Roberto Ragusa mail at robertoragusa.it From cepreu.mail at gmail.com Mon Dec 28 02:17:36 2009 From: cepreu.mail at gmail.com (=?KOI8-R?B?88XSx8XKIPfB0sDIyc4=?=) Date: Mon, 28 Dec 2009 12:17:36 +1000 Subject: New plugin for system-config-network (PPTP) Message-ID: <12414a820912271817s7a7ce9a4g686405500c86eb83@mail.gmail.com> Hi, i created new plugin for system-config-network (PPTP-connection type) and posted my patch in RFE report to bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=550054). Also i have send patches to email of maintainer (harald at redhat.com) few weeks ago. But there still no any answer. In bugzilla and in email too. On https://fedorahosted.org/system-config-network/ writed that, if you create some patch, you must send it on harald at redhat.com. Does anybody know, is this page are actual? Does anybody know also, how i can contact with developers of system-config-network? Thanks in advance. Cepreu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From no-reply at dropbox.com Mon Dec 28 11:29:20 2009 From: no-reply at dropbox.com (Dropbox) Date: Mon, 28 Dec 2009 11:29:20 +0000 Subject: Jian Huang has invited you to Dropbox Message-ID: <20091228112920.E9D4E5DE8B3@web6.dropbox.com> We're excited to let you know that Jian Huang has invited you to Dropbox! Jian Huang has been using Dropbox to sync and share files online and across computers, and thought you might want it too. Visit http://www.dropbox.com/link/20.NeUs4HyprI/NjcwMTAxMTQ3 to get started. - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/6d2402c3f4dc/fedora-devel-list%40redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Mon Dec 28 12:50:29 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 28 Dec 2009 12:50:29 +0000 Subject: rawhide report: 20091228 changes Message-ID: <20091228125029.GA10826@releng2.fedora.phx.redhat.com> Compose started at Mon Dec 28 08:15:05 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package tomcatjss JSSE implementation using JSS for Tomcat Updated Packages: agedu-0-1.r8768.fc13 -------------------- * Sun Dec 27 2009 Jussi Lehtola - 0-1.r8768 - Update to upstream r8768. aria2-1.8.0-1.fc13 ------------------ * Mon Dec 28 2009 Rahul Sundaram - 1.8.0-1 - Many new features including XML RPC improvements and other bug fixes - http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1778 audacity-1.3.10-0.2.beta.fc13 ----------------------------- * Mon Dec 28 2009 Michael Schwendt - 1.3.10-0.2.beta - Patch resampling call to not set end_of_input flag for all sample buffers. bash-4.1.0-0.2.rc1.fc13 ----------------------- * Sun Dec 27 2009 Roman Rakus - 4.1-0.1.rc1 - Upstream 4.1.rc1 * Sun Dec 27 2009 Roman Rakus - 4.1-0.2.rc1 - Fixed patch for fuzz=0 coreutils-8.2-5.fc13 -------------------- * Sun Dec 27 2009 Ondrej Vasik - 8.2-5 - fix misc/selinux root-only test(#550494) cppcheck-1.39-1.fc13 -------------------- * Sun Dec 27 2009 Jussi Lehtola - 1.39-1 - Update to 1.39. elinks-0.12-0.21.pre5.fc13 -------------------------- * Sun Dec 27 2009 Kamil Dudka 0.12-0.21.pre5 - add buildrequires for js-devel (#550717) and zlib-devel - build support for 256 color terminal fbzx-2.3.0-1.fc13 ----------------- * Sun Dec 27 2009 Andrea Musuruane 2.3.0-1 - Updated to new upstream release gausssum-2.2.0-2.fc13 --------------------- * Sun Dec 27 2009 Jussi Lehtola - 2.2.0-1 - Update to 2.2.0. * Sun Dec 27 2009 Jussi Lehtola - 2.2.0-2 - Bump release. gnome-packagekit-2.28.3-0.1.20091211git.fc12 -------------------------------------------- * Fri Dec 11 2009 Richard Hughes - 2.28.3-0.1.20091211git - New snapshot from the gnome-2-28 branch - Don't show the selected packages as deps of the to be updated packages. Note, this only affects PackageKit >= 0.5.5. Fixes rh#546247 - Check the GpkDbusTask object only replies once to each session request * Mon Dec 07 2009 Richard Hughes - 2.28.2-1 - Update to 2.28.2 - Remove the original package from the dep-confirmation screen - Ignore generic errors such as 'Failed' and do not show UI in this case - Use the desktop icon when we unselect the installed application in gpk-application. Fixes fd#25098 gtkwave-3.3.0-1.fc13 -------------------- * Sat Dec 26 2009 Paul Howarth 3.3.0-1 - update to 3.3.0 - added tk support - bundled old liblzma replaced by system xz (add BR: xz-devel) - tcl/tk support require Fedora >= 2 or RHEL >= 4 (tcl 8.4) healpix-2.13a-1.fc13 -------------------- * Sun Dec 27 2009 Jussi Lehtola - 2.13a-1 - Update to upstream 2.13a. hercules-3.06-8.20091227svn5570.fc13 ------------------------------------ * Sun Dec 27 2009 Dan Hor?k 3.06-8.20091227svn5570 - updated to svn revision 5570 - dropped the force-hfp-unnormalized patch, because the feature is now implemented i3-3.d.bf1-2.fc13 ----------------- * Sun Dec 27 2009 Simon Wesp - 3.d.bf1-2 - Add missing Requires for a functional minimal (not comfortable) i3-system. (The requirements provides functions which are used in the standard configfile) - Build manpages and add them to main-pkg - Build doxygen generated documentation and add them to the documentation subpackage kdelibs-4.3.85-6.fc13 --------------------- * Sun Dec 27 2009 Rex Dieter - 4.3.85-6 - Conflicts: kdebase-workspace(-libs,-devel) < 4.3.80 lohit-telugu-fonts-2.4.5-3.fc13 ------------------------------- * Mon Dec 28 2009 Pravin Satpute - 2.4.5-3 - corrected patch moin-1.9.0-1.fc13 ----------------- * Sat Dec 26 2009 Ville-Pekka Vainio - 1.9.0-1 - 1.9.0 - Don't remove any FCKeditor directories, all known security issues in it should be fixed by now - Updated README-rpm, only give an example on mod_wsgi configuration, Moin is a pure WSGI application now - Change the Python magic encoding comment in wiki/config/wikiconfig.py to UTF-8 - Change url_prefix_static in wiki/config/wikiconfig.py to better suit the configuration example in README-rpm, where the wiki is served from example.tld/mywiki - wiki/server/moin.wsgi adds the directory it is in to the Python search path, as the wikiconfig.py file will be in the same directory as moin.wsgi if Moin is set up according to the example in README-rpm monodevelop-debugger-mdb-2.2-4.fc13 ----------------------------------- * Sun Dec 27 2009 Paul F. Johnson 2.2-3 - Fix for x86_64 * Sun Dec 27 2009 Paul F. Johnson 2.2-4 - Another attempt at getting 64 bit working by fixing the spec file! * Sat Dec 26 2009 Paul F. Johnson 2.2-2 - Change exclusivearch to reflect the archs for monodevelop - Rebuild against mono-debugger-2.6 release - Remove BR monodevelop * Wed Dec 16 2009 Paul F. Johnson 2.2-1 - Bump to 2.2 release ocsinventory-agent-1.1.1-2.fc13 ------------------------------- * Sun Dec 27 2009 Remi Collet 1.1.1-2 - missing perl(Net::IP) requires (+ some EL3 stuff: yes, I know) olpc-utils-1.0.15-1.fc13 ------------------------ * Sun Dec 27 2009 Daniel Drake - 1.0.15-1 - Bump to v1.0.15 to enable python optimizations par2cmdline-0.4.tbb.20090203-4.fc13 ----------------------------------- * Sun Dec 27 2009 Erik van Pienbroek - 0.4.tbb.20090203-4 - Fixed PPC build failure (BZ #550818) perl-Net-UPnP-1.4.2-1.fc13 -------------------------- * Sun Dec 27 2009 Jussi Lehtola - 1:1.4.2-1 - Update to 1.4.2. - Fix spelling in rpm version: 1.4.1 instead of previous 1.41. perl-Test-Refcount-0.06-1.fc13 ------------------------------ * Sun Dec 27 2009 Nicolas Chauvet - 0.06-1 - Update to 0.06 - Remove workaround at make test for perl with debug - rhbz#514942 * Fri Dec 04 2009 Stepan Kasal - 0.05-3 - rebuild against perl 5.10.1 plexus-archiver-1.0-0.4.a7.1.2.fc12 ----------------------------------- polkit-qt-0.95-0.3.20091119svn.fc13 ----------------------------------- * Sun Dec 27 2009 Rex Dieter - 0.95-0.3.20091119svn - Provides: polkit-qt-1(-devel) ... - doc: make noarch pondus-0.7.0-1.fc13 ------------------- * Sun Dec 27 2009 Jussi Lehtola - 0.7.0-1 - Update to 0.7.0. - License has changed to MIT. rubber-1.1-7.fc13 ----------------- * Mon Dec 28 2009 Sergio Pascual - 1.1-7 - Adding virtual dependency on latex (bz #550792) skrooge-0.5.5-1.fc13 -------------------- * Sun Dec 27 2009 Thomas Janssen 0.5.5-1 - Update to new upstream release - Corrects a lot of bugs and problems. See the CHANGELOG for details. spamassassin-3.3.0-0.27.rc1.fc13 -------------------------------- * Mon Dec 28 2009 Warren Togami - 3.3.0-0.27.rc1 - sa-update runs in cron automatically if spamd or amavisd is running If you use neither, you may force sa-update by editing /etc/sysconfig/sa-update. sympy-0.6.6-1.fc13 ------------------ * Sun Dec 27 2009 Jussi Lehtola - 0.6.6-1 - Update to 0.6.6. Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 30 From fedora at matbooth.co.uk Mon Dec 28 14:28:52 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 28 Dec 2009 14:28:52 +0000 Subject: New plugin for system-config-network (PPTP) In-Reply-To: <12414a820912271817s7a7ce9a4g686405500c86eb83@mail.gmail.com> References: <12414a820912271817s7a7ce9a4g686405500c86eb83@mail.gmail.com> Message-ID: <9497e9990912280628x5d44be5al4b99911cbaa5b3da@mail.gmail.com> 2009/12/28 ?????? ??????? : > Hi, i created new plugin for system-config-network (PPTP-connection type) > and posted my patch in RFE report to bugzilla > (https://bugzilla.redhat.com/show_bug.cgi?id=550054). Also i have send > patches to email of maintainer (harald at redhat.com) few weeks ago. But there > still no any answer. In bugzilla and in email too. On > https://fedorahosted.org/system-config-network/ writed that, if you create > some patch, you must send it on harald at redhat.com. Does anybody know, is > this page are actual? > Does anybody know also, how i can contact with developers of > system-config-network? > Thanks in advance. Cepreu. > You only filed the bug the day before Christmas Eve, please give him a chance. Most people don't check their work email over the holiday period ;-) -- Mat Booth From rakesh.pandit at gmail.com Tue Dec 29 05:46:24 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 29 Dec 2009 11:16:24 +0530 Subject: Package Review Stats for last 7 days ending 27th Dec Message-ID: Top three FAS account holders who have completed reviewing "Package review" components on bugzilla for last 7 days ending 27th Dec were Fabian Affolter, Peter Lemenkov and tomspur. fabian at bernewireless.net : 7 https://bugzilla.redhat.com/show_bug.cgi?id=545188 https://bugzilla.redhat.com/show_bug.cgi?id=547118 https://bugzilla.redhat.com/show_bug.cgi?id=546868 https://bugzilla.redhat.com/show_bug.cgi?id=476527 https://bugzilla.redhat.com/show_bug.cgi?id=544581 https://bugzilla.redhat.com/show_bug.cgi?id=546212 https://bugzilla.redhat.com/show_bug.cgi?id=550100 lemenkov at gmail.com : 4 https://bugzilla.redhat.com/show_bug.cgi?id=549980 https://bugzilla.redhat.com/show_bug.cgi?id=550234 https://bugzilla.redhat.com/show_bug.cgi?id=225769 https://bugzilla.redhat.com/show_bug.cgi?id=549809 tomspur at fedoraproject.org : 4 https://bugzilla.redhat.com/show_bug.cgi?id=550369 https://bugzilla.redhat.com/show_bug.cgi?id=544628 https://bugzilla.redhat.com/show_bug.cgi?id=532813 https://bugzilla.redhat.com/show_bug.cgi?id=549198 mtasaka at ioa.s.u-tokyo.ac.jp : 2 https://bugzilla.redhat.com/show_bug.cgi?id=542559 https://bugzilla.redhat.com/show_bug.cgi?id=547993 panemade at gmail.com : 2 https://bugzilla.redhat.com/show_bug.cgi?id=521995 https://bugzilla.redhat.com/show_bug.cgi?id=521993 akurtako at redhat.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542165 chitlesh at gmail.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=545895 cwickert at fedoraproject.org : 1 https://bugzilla.redhat.com/show_bug.cgi?id=510376 dmalcolm at redhat.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=487097 hdegoede at redhat.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=527059 jussi.lehtola at iki.fi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542747 kwizart at gmail.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=548180 lkundrak at v3.sk : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541978 oget.fedora at gmail.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=549884 overholt at redhat.com : 1 https://bugzilla.redhat.com/show_bug.cgi?id=549863 rdieter at math.unl.edu : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541346 th0br0 at mkdir.name : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529253 xavier at bachelot.org : 1 https://bugzilla.redhat.com/show_bug.cgi?id=542463 Total reviews modified: 32 Merge Reviews: 0 Review Requests: 32 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first From rakesh.pandit at gmail.com Tue Dec 29 05:58:59 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 29 Dec 2009 11:28:59 +0530 Subject: Package Review Stats for last 7 days ending 27th Dec In-Reply-To: References: Message-ID: 2009/12/29 Rakesh Pandit wrote: > Top three FAS account holders who have completed reviewing "Package > review" components on bugzilla for last 7 days ending 27th Dec were > Fabian Affolter, Peter Lemenkov and tomspur. > > fabian at bernewireless.net : 7 [..] Seems bug info from bugzilla does not give full names from 'reporter' field. Will investigate and fix accordingly. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first From josephine.tannhauser at googlemail.com Mon Dec 28 17:56:56 2009 From: josephine.tannhauser at googlemail.com (Josephine Tannhauser) Date: Mon, 28 Dec 2009 17:56:56 +0000 (UTC) Subject: rawhide report: 20091228 changes References: <20091228125029.GA10826@releng2.fedora.phx.redhat.com> Message-ID: why are there so many broken deps? From promac at gmail.com Tue Dec 29 09:17:40 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Tue, 29 Dec 2009 07:17:40 -0200 Subject: sound, amixer and pulseaudio Message-ID: <68720af30912290117we73dc80pf0f3696f3fdae704@mail.gmail.com> Hi, since I installed Fedora 12, I realized that I have no more an "Analog Loopback" available in alsa, which allowed me to route the capture sources on my sound card back in as PCM audio. I tried upgrading alsa-driver to 1.0.22, but nothing changed. The only option I have now is using arecord and aplay to simulate the loopback. Although this scheme woks fine, arecord / aplay just die from time to time (kind of randomly), with no apparent reason. This is the command I use: arecord -D hw:0,0,0 -d 0 -f S16_LE -c2 -r128000 | aplay -f S16_LE -c2 -r128000 -D default & Another question is how to use amixer to control the volume of an application in a way that allowed me change the volume of any sound card installed on my system. Since I must specify the card using "-c 0", for instance, if I switch the sound to another card using pulseaudio, I can no longer control the volume of this new card. Unfortunately, there is no "-c default" in amixer ... amixer -q -c 0 set PCM 80% Would there be a better way of doing that? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsd at laptop.org Tue Dec 29 10:52:54 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 29 Dec 2009 10:52:54 +0000 Subject: packaging a static library Message-ID: <1262083974.2056.7.camel@localhost.localdomain> Hi, OLPC's security system uses libtomcrypt / tomsfastmath, both at the Linux level and the firmware level. OLPC has previously had a specific version of tomcrypt/tommath profesionally audited for security reasons. So we obviously want to stick with that version. A few packages we have in Fedora currently use this frozen, audited version - we do so by shipping duplicate copies of that source code within the individual packages, rather than linking against the dynamic systemwide equivalents. As we're now looking at making another package which uses yet another duplicate copy of this code base I'm wondering if we can do it better. Could I add a package, named olpc-bios-crypto-devel (a subpackage of the to-be-packaged olpc-bios-crypto), which installs the .a files for the audited libraries somewhere on the system? Then the individual components that rely on this library (e.g. bitfrost, olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency on olpc-bios-crypto-devel and build against the 'systemwide' static .a library files. Or am I going too far against common packaging practice at this point? Any alternative suggestions? Thanks, Daniel From rawhide at fedoraproject.org Tue Dec 29 12:46:53 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 29 Dec 2009 12:46:53 +0000 Subject: rawhide report: 20091229 changes Message-ID: <20091229124653.GA20547@releng2.fedora.phx.redhat.com> Compose started at Tue Dec 29 08:15:11 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so rpy-2.0.6-7.fc13.i686 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 1:libguestfs-1.0.80-9.fc13.x86_64 requires /lib64/libgcc_s-4.4.2-20091027.so.1 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) rpy-2.0.6-7.fc13.x86_64 requires R-core = 0:2.10.0 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package clutter-gesture Gesture Library for Clutter New package earcandy Sound level manager Updated Packages: EekBoek-1.04.05-2.fc13 ---------------------- * Mon Dec 28 2009 Johan Vromans - 1.04.05-1 - Upgrade to upstream 1.04.05. * Mon Dec 28 2009 Johan Vromans - 1.04.05-2 - Fix for table detection with newer SQLite. GraphicsMagick-1.3.7-4.fc13 --------------------------- * Mon Dec 28 2009 Rex Dieter - 1.3.7-4 - CVE-2009-1882 (#503017) * Fri Dec 04 2009 Stepan Kasal - 1.3.7-3 - rebuild against perl 5.10.1 * Fri Nov 06 2009 Rex Dieter - 1.3.7-2 - cleanup/uncruftify .spec alsa-lib-1.0.22-1.fc13 ---------------------- * Mon Dec 28 2009 Jaroslav Kysela - 1.0.22-1 - Updated to 1.0.22 final - Fix file descriptor leak in pcm_hw plugin - Fix sound distortions for S24_LE - softvol plugin cherokee-0.99.38-1.fc13 ----------------------- * Mon Dec 28 2009 Lorenzo Villani - 0.99.38-1 - 0.99.38 common-lisp-controller-6.20-1.fc13 ---------------------------------- * Sun Dec 27 2009 Anthony Green 6.20-1 - Upgrade. fsarchiver-0.6.3-1.fc13 ----------------------- * Mon Dec 28 2009 Adel Gadllah - 0.6.3-1 - Update to 0.6.3 gnote-0.6.3-3.fc13 ------------------ * Tue Dec 29 2009 Rahul Sundaram - 0.6.3-3 - Upstream patches adding a fix for Bugzilla add-in and other minor bug fixes gv-3.6.8-1.fc13 --------------- * Mon Dec 28 2009 Orion Poplawski 3.6.8-1 - Update to 3.6.8 jd-2.5.5-1.fc13 --------------- * Mon Dec 28 2009 Mamoru Tasaka - 2.5.5-1 - 2.5.5 openal-soft-1.10.622-5.3793919892e6d61e5fec3abeaaeebc3f2332be13git.fc13 ----------------------------------------------------------------------- * Mon Dec 28 2009 Thomas Kowaliczek - 1.10.622-4.3793919892e6d61e5fec3abeaaeebc3f2332be13 - Fixed broken upgrade paths. * Mon Dec 28 2009 Thomas Kowaliczek - 1.10.622-5.3793919892e6d61e5fec3abeaaeebc3f2332be13 - Fixed small spec verion info. * Wed Nov 11 2009 Thomas Kowaliczek - 1.10.622-3 - F12 and devel only release. plexus-archiver-1.0-0.4.a12.4.fc13 ---------------------------------- * Mon Dec 28 2009 Alexander Kurtakov 0:1.0-0.4.a12.4 - Install depmap and pom to override common poms. * Thu Dec 24 2009 Alexander Kurtakov 0:1.0-0.4.a12.2 - Ignore test failures. * Thu Dec 24 2009 Alexander Kurtakov 0:1.0-0.4.a12.3 - Really ignore test failures. * Wed Dec 23 2009 Alexander Kurtakov 0:1.0-0.4.a12.1 - Update to alpha 12. python-jabberbot-0.9-1.fc13 --------------------------- * Mon Dec 28 2009 Fabian Affolter - 0.9-1 - Added COPYING - Updated to new upstream version 0.9 ruby-RMagick-2.13.0-1.fc13 -------------------------- * Tue Dec 29 2009 Mamoru Tasaka - 2.13.0 - 2.13.0 spamassassin-3.3.0-0.29.rc1.fc13 -------------------------------- spring-0.80.5.2-1.fc13 ---------------------- * Sat Nov 21 2009 Aurelien Bompard - 0.80.5.2-1 - New release: 0.80.5.2 squeak-vm-3.10.5-4.fc13 ----------------------- * Mon Dec 28 2009 Daniel Drake - 3.10.5-3 - Add (already upstream) patch to fix crackly sound output * Mon Dec 28 2009 Daniel Drake - 3.10.5-4 - forgot to add patch to cvs; retag sugar-implode-9-1.20091228.fc13 ------------------------------- * Mon Dec 28 2009 Fabian Affolter - 9-1.20090717 - Added python-olpcgames as requirement - Prepared translations - Updated to new upstream version 9 Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 17 From rc040203 at freenet.de Tue Dec 29 13:41:18 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 29 Dec 2009 14:41:18 +0100 Subject: packaging a static library In-Reply-To: <1262083974.2056.7.camel@localhost.localdomain> References: <1262083974.2056.7.camel@localhost.localdomain> Message-ID: <4B3A06FE.6050705@freenet.de> On 12/29/2009 11:52 AM, Daniel Drake wrote: > Hi, > > OLPC's security system uses libtomcrypt / tomsfastmath, both at the > Linux level and the firmware level. > > OLPC has previously had a specific version of tomcrypt/tommath > profesionally audited for security reasons. So we obviously want to > stick with that version. > > A few packages we have in Fedora currently use this frozen, audited > version - we do so by shipping duplicate copies of that source code > within the individual packages, rather than linking against the dynamic > systemwide equivalents. > > As we're now looking at making another package which uses yet another > duplicate copy of this code base I'm wondering if we can do it better. > > Could I add a package, named olpc-bios-crypto-devel (a subpackage of the > to-be-packaged olpc-bios-crypto), which installs the .a files for the > audited libraries somewhere on the system? > > Then the individual components that rely on this library (e.g. bitfrost, > olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency > on olpc-bios-crypto-devel and build against the 'systemwide' static .a > library files. > > Or am I going too far against common packaging practice at this point? Yes. You are outsmarting yourselves and not doing good to other users of the libraries, IMO. If all users of the library were using the same, identical shared versions, everybody would benefit from your "auditing", maintainers would benefit from "issues being fixed" at one place, users would benefit from you not shipping statically linked packages. > Any alternative suggestions? Use system-wide, shared versions only, unless there are technical reasons for not doing so - Your rationale doesn't provide such. Ralf From mschwendt at gmail.com Tue Dec 29 13:44:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 29 Dec 2009 14:44:25 +0100 Subject: packaging a static library In-Reply-To: <1262083974.2056.7.camel@localhost.localdomain> References: <1262083974.2056.7.camel@localhost.localdomain> Message-ID: <20091229144425.38bc1be9@gmail.com> On Tue, 29 Dec 2009 10:52:54 +0000, Daniel wrote: > Hi, > > OLPC's security system uses libtomcrypt / tomsfastmath, both at the > Linux level and the firmware level. > > OLPC has previously had a specific version of tomcrypt/tommath > profesionally audited for security reasons. So we obviously want to > stick with that version. > > A few packages we have in Fedora currently use this frozen, audited > version - we do so by shipping duplicate copies of that source code > within the individual packages, rather than linking against the dynamic > systemwide equivalents. > > As we're now looking at making another package which uses yet another > duplicate copy of this code base I'm wondering if we can do it better. > > Could I add a package, named olpc-bios-crypto-devel (a subpackage of the > to-be-packaged olpc-bios-crypto), which installs the .a files for the > audited libraries somewhere on the system? > > Then the individual components that rely on this library (e.g. bitfrost, > olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency > on olpc-bios-crypto-devel and build against the 'systemwide' static .a > library files. > > Or am I going too far against common packaging practice at this point? > Any alternative suggestions? There is https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries and https://fedoraproject.org/wiki/Packaging:Guidelines#Staticly_Linking_Executables already. These guidelines explain how to name static library packages and how to build-require them. You didn't comment on those guidelines at all. From rjones at redhat.com Tue Dec 29 14:11:52 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 29 Dec 2009 14:11:52 +0000 Subject: Add extra generated RPM requires - how? In-Reply-To: <20091218202645.GA30070@amd.home.annexia.org> References: <20091218202645.GA30070@amd.home.annexia.org> Message-ID: <20091229141152.GA32058@amd.home.annexia.org> On Fri, Dec 18, 2009 at 08:26:45PM +0000, Richard W.M. Jones wrote: > > For libguestfs [RHBZ#547496] I want to add some extra 'Requires' > dependencies by running a shell script over a particular file that > gets generated during the build. As a follow-up, here is what I did: http://cvs.fedoraproject.org/viewvc/devel/libguestfs/ Specifically, adding this to the spec file: Source1: libguestfs-find-requires.sh %global _use_internal_dependency_generator 0 %global __find_provides %{_rpmconfigdir}/find-provides %global __find_requires %{SOURCE1} %{_rpmconfigdir}/find-requires along with my custom find-requires shell script: http://cvs.fedoraproject.org/viewvc/devel/libguestfs/libguestfs-find-requires.sh?view=markup Rich. PS. I'm convinced I posted the above information before, but now I don't see it on the list. Maybe I'm going mad, or maybe you'll see two messages about this ... -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From fedora at matbooth.co.uk Tue Dec 29 14:16:59 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 29 Dec 2009 14:16:59 +0000 Subject: rawhide report: 20091228 changes In-Reply-To: References: <20091228125029.GA10826@releng2.fedora.phx.redhat.com> Message-ID: <9497e9990912290616t27948b8p969a2184c2d7cbd4@mail.gmail.com> 2009/12/28 Josephine Tannhauser : > why are there so many broken deps? > See https://www.redhat.com/archives/fedora-devel-list/2009-December/msg01093.html -- Mat Booth From rjones at redhat.com Tue Dec 29 17:41:39 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 29 Dec 2009 17:41:39 +0000 Subject: rawhide report: 20091223 changes In-Reply-To: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> References: <20091223151720.GA14927@releng2.fedora.phx.redhat.com> Message-ID: <20091229174139.GB32058@amd.home.annexia.org> On Wed, Dec 23, 2009 at 03:17:20PM +0000, Rawhide Report wrote: > 1:libguestfs-1.0.80-9.fc13.i686 requires /lib/libgcc_s-4.4.2-20091027.so.1 This one should be fixed now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 From mschwendt at gmail.com Tue Dec 29 18:56:57 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 29 Dec 2009 19:56:57 +0100 Subject: ABRT considered painful Message-ID: <20091229195657.4000ce26@gmail.com> What's wrong with ABRT? Originally, with stock F-12, I had received a couple of good backtraces in bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. And later? - Recently, in all the backtraces dozens of debuginfo packages are missing. :-( From bos at serpentine.com Tue Dec 29 20:40:23 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 29 Dec 2009 12:40:23 -0800 Subject: ABRT considered painful In-Reply-To: <20091229195657.4000ce26@gmail.com> References: <20091229195657.4000ce26@gmail.com> Message-ID: On Tue, Dec 29, 2009 at 10:56 AM, Michael Schwendt wrote: > > Originally, with stock F-12, I had received a couple of good backtraces in > bugzilla. I can't comment on its usefulness to developers, but as a user of the thing, it's horrid. It's extremely hard to figure out what it's for, then how to use it (if only to make that red flashing light go away), and then it's quite often unreliable in delivering bug reports or making it clear that any particular crash has or has not been reported correctly. I applaud the idea behind it, but what a mess from an implementation standpoint :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From icon at fedoraproject.org Tue Dec 29 21:37:28 2009 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 29 Dec 2009 16:37:28 -0500 Subject: ABRT considered painful In-Reply-To: <20091229195657.4000ce26@gmail.com> References: <20091229195657.4000ce26@gmail.com> Message-ID: 2009/12/29 Michael Schwendt : > What's wrong with ABRT? > > Originally, with stock F-12, I had received a couple of good backtraces in > bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. > > And later? - Recently, in all the backtraces dozens of debuginfo packages > are missing. :-( That's been my experience. Starting off, ABRT worked great (except for the bug where it couldn't submit any bugs), but then it stopped being able to download debuginfo packages -- no matter how often I hit "Refresh". Then that went away with an updated version and ABRT worked well again for a bit, but now it's back to not being able to download any debuginfo packages, so all traces it generates are useless. I'm not sure what caused/causes it to go wonky that way. Unfortunately, if this goes on, I'm afraid it'll pass the "useless annoyance" barrier and most people will remove it upon install, thus negating the reason it was created in the first place. Cheers, -- McGill University IT Security Konstantin Ryabitsev Montr?al, Qu?bec From snecklifter at gmail.com Tue Dec 29 22:20:56 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 29 Dec 2009 22:20:56 +0000 Subject: Fedora Linux Format software review: January 2010 Message-ID: <364d303b0912291420o4af25d92je96cf6a905e8f497@mail.gmail.com> Hi folks, Linux Format is a popular magazine in the U.K but which ships all over the world. It regularly reviews interesting bits of software and I thought: a) It would be interesting to see how much of what they review is included in Fedora b) It would be a good idea to get that which is not in and/or up to date c) If there is enough interest I would like to form a SIG to do the monthly reviews - a kind of packaging wishlist on steroids perhaps :) I blogged about this recently and you can read the basic idea there: http://chruz.wordpress.com/2009/12/23/ive-got-the-music-on-my-radio/ The editor has expressed his willingness to send details of software which they will review to us so we have a head start. I have conducted the first review of the January 2010 issue which you can read here: https://fedoraproject.org/wiki/LinuxFormatPackaging There are some interesting omissions, for example Recoll, the desktop search tool which came out ahead of Beagle and Google Desktop and which doesn't even have a review request opened for it yet. A few points that need mentioning: 1) I do not and have never worked for Linux Format nor has anyone I know :) 2) There may be some glaring errors - this is why this is on the wiki so please feel free to update/change etc. For example I have not undertaken rigorous reviews for the software's suitability. 3) This is not intended as anything other than a distillation of what would be good to have in the repositories. I welcome your comments as ever. -- Christopher Brown From paul at all-the-johnsons.co.uk Tue Dec 29 23:38:25 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 29 Dec 2009 23:38:25 +0000 Subject: BZ 523646 - F13Blocker? Message-ID: <1262129905.3496.12.camel@PB3.linux> Hi, I originally reported this bug in September 2009 when f12 was rawhide. It was fixed but has recently resurfaced for both F12 and rawhide users leaving anyone with an intel chipset for video with unusable systems. Given that this kills quite a few laptop users, can this be escalated to F13Blocker? It is already listed as high for both priority and severity. I've not tried booting a live distro that is not a fedora one as to be honest, I'd rather not sully my machines! However, I've not heard of anyone using Ubuntu with the same kernel and xorg-x11-drv-intel version having the same problems. Thoughts folks? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From darrellpf at gmail.com Tue Dec 29 23:52:36 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 29 Dec 2009 15:52:36 -0800 Subject: BZ 523646 - F13Blocker? In-Reply-To: <1262129905.3496.12.camel@PB3.linux> References: <1262129905.3496.12.camel@PB3.linux> Message-ID: On Tue, Dec 29, 2009 at 15:38, Paul wrote: > Hi, > > I originally reported this bug in September 2009 when f12 was rawhide. > It was fixed but has recently resurfaced for both F12 and rawhide users > leaving anyone with an intel chipset for video with unusable systems. > > Given that this kills quite a few laptop users, can this be escalated to > F13Blocker? It is already listed as high for both priority and severity. > > I've not tried booting a live distro that is not a fedora one as to be > honest, I'd rather not sully my machines! However, I've not heard of > anyone using Ubuntu with the same kernel and xorg-x11-drv-intel version > having the same problems. > > Thoughts folks? > > You're lucky to have X working slowly on your Intel card. It has been broken completely for me and others on all the 2.6.32 kernels in rawhide (but apparently not in the stock kernel) https://bugzilla.redhat.com/show_bug.cgi?id=542264 https://bugzilla.redhat.com/show_bug.cgi?id=546721 Given the Christmas season, I wasn't expecting any resolution until the new year. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From ismael at olea.org Wed Dec 30 00:01:48 2009 From: ismael at olea.org (Ismael Olea) Date: Wed, 30 Dec 2009 01:01:48 +0100 Subject: Mono 2.6 - heads up In-Reply-To: <1261381197.1494.8.camel@PB3.linux> References: <1261381197.1494.8.camel@PB3.linux> Message-ID: <22a365930912291601k33525af7k33edbda3572ab400@mail.gmail.com> On Mon, Dec 21, 2009 at 8:39 AM, Paul wrote: > Hi, > > Sometime today or tomorrow I'll be uploading Mono-2.6 and the final > release of MD-2.2 with all the fun that it will bring. I got an error avoiding chronojump to compile in rawhide. I've reported at upstream{1] but I'm really suspecting in our mono 2.6. [1] https://bugzilla.gnome.org/show_bug.cgi?id=599719 The same release builds fine in f11 and f12. and this time, I've added a new subpackage for the preview of C# 4.0 > Are all 4.0/* contents supposed to be packaged here? I've found a lot of 4.0 files outside mono-4-preview and not sure if this is the cause of my CJ build problem. Any suggestion? -- Ismael Olea http://olea.org/diario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From huzaifas at redhat.com Wed Dec 30 03:21:58 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 30 Dec 2009 08:51:58 +0530 Subject: ABRT considered painful In-Reply-To: <20091229195657.4000ce26@gmail.com> References: <20091229195657.4000ce26@gmail.com> Message-ID: <4B3AC756.7070007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > What's wrong with ABRT? > > Originally, with stock F-12, I had received a couple of good backtraces in > bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. > > And later? - Recently, in all the backtraces dozens of debuginfo packages > are missing. :-( > I agree, Most of the abrt crash bugzilla i am assigned too, have missing debuginfo packages, kind of use less for debuging. I can ask the user to install debuginfo packages and get back to me. But without that i will have to close those bzs - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLOsdWzHDc8tpb2uURAgCXAJ9wtE+AsAwTwRs/zh/l3wWjJqOtkgCbB5RR feqGm/5gDfJn4OOdhpeWEy0= =f/Mh -----END PGP SIGNATURE----- From huzaifas at redhat.com Wed Dec 30 03:25:05 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 30 Dec 2009 08:55:05 +0530 Subject: Can some provenpackager bump openvpn in EL-5 Message-ID: <4B3AC811.8070101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have this bz open for some time now, with no response. https://bugzilla.redhat.com/show_bug.cgi?id=544944 Can some one with proven packager access bump the EL-5 version to the latest one in devel. Thanks. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLOsgRzHDc8tpb2uURAj7nAJ9IsE1qHV+TzaG0S+Mz3DgAimhkoACgjN/y 5SKpIFhDa4YB9JEFW1ERZz8= =PCW0 -----END PGP SIGNATURE----- From jonathan at jonmasters.org Wed Dec 30 06:29:29 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 30 Dec 2009 07:29:29 +0100 Subject: packaging a static library In-Reply-To: <4B3A06FE.6050705@freenet.de> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> Message-ID: <1262154569.28331.12.camel@tonnant> On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote: > On 12/29/2009 11:52 AM, Daniel Drake wrote: > > OLPC has previously had a specific version of tomcrypt/tommath > > profesionally audited for security reasons. So we obviously want to > > stick with that version. > > > > A few packages we have in Fedora currently use this frozen, audited > > version - we do so by shipping duplicate copies of that source code > > within the individual packages, rather than linking against the dynamic > > systemwide equivalents. > > Or am I going too far against common packaging practice at this point? > Yes. You are outsmarting yourselves and not doing good to other users of > the libraries, IMO. I think the argument could go both ways. In the case of OLPC, they're providing Open Source pieces that are similar to things like the TPM technologies in other systems. If a certain major PC chip manufacturer decided to release all of the design and code schematics for their TPM chips, the community would probably praise them...and then wonder what the potential could be for a bad library release to undermine them. > If all users of the library were using the same, identical shared > versions, everybody would benefit from your "auditing", maintainers > would benefit from "issues being fixed" at one place, users would > benefit from you not shipping statically linked packages. One presumes that such auditing is expensive, lengthy, and not often to be repeated. Committing to undertaking a full code audit on every update would seem to be a little unreasonable of a request. So I think it's obvious that if they want to use an audited version, there will have to be a separate audited version. Jon. From rc040203 at freenet.de Wed Dec 30 07:05:19 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 30 Dec 2009 08:05:19 +0100 Subject: packaging a static library In-Reply-To: <1262154569.28331.12.camel@tonnant> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> Message-ID: <4B3AFBAF.90600@freenet.de> On 12/30/2009 07:29 AM, Jon Masters wrote: > On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote: >> On 12/29/2009 11:52 AM, Daniel Drake wrote: > >>> OLPC has previously had a specific version of tomcrypt/tommath >>> profesionally audited for security reasons. So we obviously want to >>> stick with that version. >>> >>> A few packages we have in Fedora currently use this frozen, audited >>> version - we do so by shipping duplicate copies of that source code >>> within the individual packages, rather than linking against the dynamic >>> systemwide equivalents. >> If all users of the library were using the same, identical shared >> versions, everybody would benefit from your "auditing", maintainers >> would benefit from "issues being fixed" at one place, users would >> benefit from you not shipping statically linked packages. > > One presumes that such auditing is expensive, lengthy, and not often to > be repeated. Committing to undertaking a full code audit on every update > would seem to be a little unreasonable of a request. So I think it's > obvious that if they want to use an audited version, there will have to > be a separate audited version. Well, I disagree: If they want to use "their auditied version", they haven't understood how open source works. They qualify as jerks who prefer to use proprietary forks instead of "paying back" to "upstream" and the wider user-base. Ralf From gmaxwell at gmail.com Wed Dec 30 09:07:04 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 30 Dec 2009 04:07:04 -0500 Subject: packaging a static library In-Reply-To: <4B3AFBAF.90600@freenet.de> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> Message-ID: On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius wrote: > On 12/30/2009 07:29 AM, Jon Masters wrote: >> One presumes that such auditing is expensive, lengthy, and not often to >> be repeated. Committing to undertaking a full code audit on every update >> would seem to be a little unreasonable of a request. So I think it's >> obvious that if they want to use an audited version, there will have to >> be a separate audited version. > > Well, I disagree: If they want to use "their auditied version", they haven't > understood how open source works. They qualify as jerks who prefer to use > proprietary forks instead of "paying back" to "upstream" and the wider > user-base. I'm sure any fixes have been contributed back and that any difference in /functionality/ are inconsequential. This reality invalidates your hostile accusation. On that point? please tone down the rhetoric, even if "haven't", "jerks", and "proprietary forks" are fair labels it's rather premature in the conversation to pull them out. This kind of name calling shuts down rational thinking. The concern here has nothing to do with the material functionality or directly measurable quality of libtommath, but instead it has everything to do with the color of the bits (http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php). The audited version has a quality which is not held by any other version, but the quality in question is not an aspect of the functionality. It's the quality of being assured. There is nothing incompatible between assurance and open-source, although assurance is something that few open source packages bother providing today, partially because assurance is so costly. Thus the interest in formal methods (http://www.dwheeler.com/essays/oss_software_assurance.pdf), as they can theoretically lower the lifetime costs of high assurance. Crypto/bignum libraries evolve slowly enough that it isn't at all surprising to see even soft-assurances being seen as more valuable than improvements to the code. From rjones at redhat.com Wed Dec 30 09:40:13 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 30 Dec 2009 09:40:13 +0000 Subject: OCaml in Rawhide upgraded to 3.11.2-rc1 Message-ID: <20091230094013.GC32058@amd.home.annexia.org> All the existing ocaml-* packages in Rawhide depend on ocaml(runtime) = 3.11.1 which means they will all have broken deps and need rebuilding. A simple bumpspec + rebuild should be sufficient. If any provenpackagers are feeling particularly bored this week ... Otherwise I'll try to do it in my spare time this week or next. Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From jussilehtola at fedoraproject.org Wed Dec 30 10:52:25 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 30 Dec 2009 12:52:25 +0200 Subject: Can some provenpackager bump openvpn in EL-5 In-Reply-To: <4B3AC811.8070101@redhat.com> References: <4B3AC811.8070101@redhat.com> Message-ID: <1262170345.11901.7.camel@localhost> On Wed, 2009-12-30 at 08:55 +0530, Huzaifa Sidhpurwala wrote: > Hi, > I have this bz open for some time now, with no response. > https://bugzilla.redhat.com/show_bug.cgi?id=544944 > > Can some one with proven packager access bump the EL-5 version to the > latest one in devel. Even though any proven packager could do the change, that bug does not fall in the items listed in the proven packager policy [1]. You haven't listed any problems with the current package, you're just requesting a version upgrade. Version upgrades should be performed by the package maintainer. This especially holds in EPEL, which should be a slowly moving distribution. [1] http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From huzaifas at redhat.com Wed Dec 30 11:05:05 2009 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 30 Dec 2009 16:35:05 +0530 Subject: Can some provenpackager bump openvpn in EL-5 In-Reply-To: <1262170345.11901.7.camel@localhost> References: <4B3AC811.8070101@redhat.com> <1262170345.11901.7.camel@localhost> Message-ID: <4B3B33E1.7020505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jussi Lehtola wrote: > On Wed, 2009-12-30 at 08:55 +0530, Huzaifa Sidhpurwala wrote: >> Hi, >> I have this bz open for some time now, with no response. >> https://bugzilla.redhat.com/show_bug.cgi?id=544944 >> >> Can some one with proven packager access bump the EL-5 version to the >> latest one in devel. > > Even though any proven packager could do the change, that bug does not > fall in the items listed in the proven packager policy [1]. You haven't > listed any problems with the current package, you're just requesting a > version upgrade. > The version of openvpn in EPEL is an upstream rc version. The Changelog file upstream shows a lot of bugs have been fixed and it would be nice to have it fixed in EPEL too. > Version upgrades should be performed by the package maintainer. This > especially holds in EPEL, which should be a slowly moving distribution. > In this case the bz is around 2.5 weeks old, with absolutely no response. What is the policy to get the package updated in this case? > [1] > http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLOzPgzHDc8tpb2uURAkRbAJ9fEMK2uOwbaeoDPb0f5FWPAt0NzACfX5Ue BtBtFPMo3x2Pe9SPdWZTLVM= =w3lz -----END PGP SIGNATURE----- From martin.langhoff at gmail.com Wed Dec 30 11:25:04 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 30 Dec 2009 12:25:04 +0100 Subject: packaging a static library In-Reply-To: <4B3AFBAF.90600@freenet.de> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> Message-ID: <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> On Wed, Dec 30, 2009 at 8:05 AM, Ralf Corsepius wrote: > Well, I disagree: If they want to use "their auditied version", they haven't > understood how open source works. They qualify as jerks who prefer to use > proprietary forks instead of "paying back" to "upstream" and the wider > user-base. Um - the audited version is just frozen. It's not hidden, it's not proprietary, and it would be nice if you look at things before calling people jerks. TomsFastMath ( http://tfm.libtomcrypt.com/ ) has been a public FOSS project for a while, it is packaged in a number of distros (FreeBSD seems to carry a version, Debian has it, etc). The special "frozen" version we carry is publicly available in our git repo, and AFAIK the upstream author was 100% involved in our audit process. The results are definitely openly available too. So put down the pitchfork already. Let's focus on the important bit: we need a frozen version of a library (that, btw, is useful, and is not in Fedora yet :-) ). What's the best practice for that? I don't see why we'd need to embed it statically anywhere (except OFW of course). cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From jussilehtola at fedoraproject.org Wed Dec 30 12:11:57 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 30 Dec 2009 14:11:57 +0200 Subject: Can some provenpackager bump openvpn in EL-5 In-Reply-To: <4B3B33E1.7020505@redhat.com> References: <4B3AC811.8070101@redhat.com> <1262170345.11901.7.camel@localhost> <4B3B33E1.7020505@redhat.com> Message-ID: <1262175117.11901.9.camel@localhost> On Wed, 2009-12-30 at 16:35 +0530, Huzaifa Sidhpurwala wrote: > Jussi Lehtola wrote: > > Even though any proven packager could do the change, that bug does not > > fall in the items listed in the proven packager policy [1]. You haven't > > listed any problems with the current package, you're just requesting a > > version upgrade. > > > The version of openvpn in EPEL is an upstream rc version. > The Changelog file upstream shows a lot of bugs have been fixed and it > would be nice to have it fixed in EPEL too. OK, that's starting to sound better. > > Version upgrades should be performed by the package maintainer. This > > especially holds in EPEL, which should be a slowly moving distribution. > > > In this case the bz is around 2.5 weeks old, with absolutely no response. > What is the policy to get the package updated in this case? See the nonresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From sebastian at when.com Wed Dec 30 12:24:14 2009 From: sebastian at when.com (Sebastian Dziallas) Date: Wed, 30 Dec 2009 13:24:14 +0100 Subject: Thinking of contributing to Sugar? Message-ID: <4B3B466E.1050706@when.com> Here's your chance! Join us for the upcoming weekly Fedora Sugar meetings in #fedora-olpc starting tomorrow, Dec 31 on 1500 UTC [1]. We're going to talk about packaging (especially Sugar Activities) and all kinds of stuff that helps us making the F13 Sugar experience better. You don't know how to package things for Fedora? Don't worry, we've a Fedora Classroom session coming up on Jan 6 - more details here [2]. --Sebastian [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=31&year=2009&hour=15&min=0&sec=0&p1=0 [2] https://fedoraproject.org/wiki/Classroom#Upcoming_Classes From rawhide at fedoraproject.org Wed Dec 30 12:54:25 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 30 Dec 2009 12:54:25 +0000 Subject: rawhide report: 20091230 changes Message-ID: <20091230125425.GA24451@releng2.fedora.phx.redhat.com> Compose started at Wed Dec 30 08:15:08 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 graphviz-ocaml-2.26.0-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 graphviz-ocaml-2.26.0-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 ocaml-SDL-0.7.2-20.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-SDL-0.7.2-20.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ancient-0.9.0-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-augeas-0.4-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 1:ocaml-cairo-1.0.0-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 1:ocaml-cairo-1.0.0-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 1:ocaml-cairo-1.0.0-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-calendar-2.01.1-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-calendar-2.01.1-2.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-calendar-2.01.1-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camlidl-1.05-10.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camlidl-1.05-10.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlimages-3.0.1-14.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlimages-3.0.1-14.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlimages-3.0.1-14.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlimages-3.0.1-14.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camlimages-3.0.1-14.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camomile-0.7.2-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camomile-0.7.2-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camomile-0.7.2-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camomile-0.7.2-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camomile-0.7.2-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-cil-1.3.7-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-cil-1.3.7-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-cil-1.3.7-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-cil-1.3.7-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-cil-1.3.7-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-cryptokit-1.3-10.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-cryptokit-1.3-10.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-cryptokit-1.3-10.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-csv-1.1.7-6.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-csv-1.1.7-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-csv-1.1.7-6.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-curl-0.5.1-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-curl-0.5.1-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-curses-1.0.3-7.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-dbus-0.24-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-dbus-0.24-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-dbus-0.24-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-deriving-0.1.1a-9.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-deriving-0.1.1a-9.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-deriving-0.1.1a-9.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-deriving-0.1.1a-9.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-expat-0.9.1-17.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-extlib-1.5.1-8.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-extlib-1.5.1-8.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-extlib-1.5.1-8.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-extlib-1.5.1-8.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-facile-1.1-11.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-facile-1.1-11.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-facile-1.1-11.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-fileutils-0.4.0-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-fileutils-0.4.0-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-fileutils-0.4.0-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-gettext-0.3.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gettext-camomile-0.3.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-gettext-camomile-0.3.3-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gettext-camomile-0.3.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gettext-camomile-0.3.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-gettext-camomile-0.3.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gsl-0.6.0-9.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gsl-0.6.0-9.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gsl-0.6.0-9.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-gsl-0.6.0-9.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-static-0.9.8-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-static-0.9.8-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-static-0.9.8-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-json-static-0.9.8-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-json-static-0.9.8-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgl-1.04-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lablgl-1.04-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgl-1.04-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lablgtk-2.14.0-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgtk-devel-2.14.0-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgtk-devel-2.14.0-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lacaml-5.4.7-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lacaml-5.4.7-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lacaml-5.4.7-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lacaml-5.4.7-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-libvirt-0.6.1.0-6.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-libvirt-0.6.1.0-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-mysql-1.0.4-11.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mysql-1.0.4-11.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-mysql-1.0.4-11.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-newt-0.9-7.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-newt-0.9-7.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-newt-0.9-7.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-openin-20070524-9.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-openin-20070524-9.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ounit-1.0.3-6.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ounit-1.0.3-6.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ounit-1.0.3-6.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ounit-1.0.3-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pa-do-0.8.10-2.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-do-0.8.10-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-do-0.8.10-2.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-do-0.8.10-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-do-0.8.10-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pcre-6.0.1-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-react-0.9.0-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-res-3.2.0-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-res-3.2.0-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ssl-0.4.3-5.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-type-conv-1.6.10-2.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-type-conv-1.6.10-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-type-conv-1.6.10-2.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-type-conv-1.6.10-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-type-conv-1.6.10-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ulex-1.1-8.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ulex-1.1-8.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ulex-1.1-8.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ulex-1.1-8.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ulex-1.1-8.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-xml-light-2.2.cvs20070817-13.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xml-light-2.2.cvs20070817-13.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-xml-light-2.2.cvs20070817-13.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-xml-light-2.2.cvs20070817-13.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-zip-1.04-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) graphviz-ocaml-2.26.0-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 graphviz-ocaml-2.26.0-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) ocaml-SDL-0.7.2-20.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-SDL-0.7.2-20.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ancient-0.9.0-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-augeas-0.4-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 1:ocaml-cairo-1.0.0-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 1:ocaml-cairo-1.0.0-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 1:ocaml-cairo-1.0.0-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-calendar-2.01.1-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-calendar-2.01.1-2.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-calendar-2.01.1-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-camlidl-1.05-10.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-camlidl-1.05-10.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlimages-3.0.1-14.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlimages-3.0.1-14.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlimages-3.0.1-14.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlimages-3.0.1-14.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-camlimages-3.0.1-14.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camomile-0.7.2-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camomile-0.7.2-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camomile-0.7.2-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camomile-0.7.2-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camomile-0.7.2-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-cil-1.3.7-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-cil-1.3.7-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-cil-1.3.7-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-cil-1.3.7-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-cil-1.3.7-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-cryptokit-1.3-10.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-cryptokit-1.3-10.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-cryptokit-1.3-10.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-csv-1.1.7-6.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-csv-1.1.7-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-csv-1.1.7-6.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-curl-0.5.1-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-curl-0.5.1-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-curses-1.0.3-7.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-dbus-0.24-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-dbus-0.24-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-dbus-0.24-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-deriving-0.1.1a-9.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-deriving-0.1.1a-9.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-deriving-0.1.1a-9.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-deriving-0.1.1a-9.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-expat-0.9.1-17.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-extlib-1.5.1-8.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-extlib-1.5.1-8.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-extlib-1.5.1-8.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-extlib-1.5.1-8.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-facile-1.1-11.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-facile-1.1-11.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-facile-1.1-11.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-fileutils-0.4.0-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-fileutils-0.4.0-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-fileutils-0.4.0-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-gettext-0.3.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gettext-camomile-0.3.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-gettext-camomile-0.3.3-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gettext-camomile-0.3.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gettext-camomile-0.3.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-gettext-camomile-0.3.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-gsl-0.6.0-9.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-gsl-0.6.0-9.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-gsl-0.6.0-9.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-gsl-0.6.0-9.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-static-0.9.8-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-static-0.9.8-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-static-0.9.8-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-json-static-0.9.8-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-json-static-0.9.8-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgl-1.04-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lablgl-1.04-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgl-1.04-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgtk-2.14.0-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgtk-devel-2.14.0-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgtk-devel-2.14.0-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lablgtk-devel-2.14.0-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lablgtk-devel-2.14.0-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lacaml-5.4.7-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lacaml-5.4.7-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lacaml-5.4.7-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lacaml-5.4.7-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-libvirt-0.6.1.0-6.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-libvirt-0.6.1.0-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-mysql-1.0.4-11.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mysql-1.0.4-11.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-mysql-1.0.4-11.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ounit-1.0.3-6.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ounit-1.0.3-6.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ounit-1.0.3-6.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ounit-1.0.3-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-do-0.8.10-2.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-do-0.8.10-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-do-0.8.10-2.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-do-0.8.10-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-do-0.8.10-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pcre-6.0.1-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-react-0.9.0-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-res-3.2.0-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-res-3.2.0-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ssl-0.4.3-5.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-type-conv-1.6.10-2.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-type-conv-1.6.10-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-type-conv-1.6.10-2.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-type-conv-1.6.10-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-type-conv-1.6.10-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ulex-1.1-8.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ulex-1.1-8.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ulex-1.1-8.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ulex-1.1-8.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ulex-1.1-8.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-xml-light-2.2.cvs20070817-13.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xml-light-2.2.cvs20070817-13.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-xml-light-2.2.cvs20070817-13.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-xml-light-2.2.cvs20070817-13.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-zip-1.04-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package mediawiki-LdapAccount Use LDAP as account source for medaiwiki New package sugar-visualmatch A visual matching game Updated Packages: bibletime-2.5-1.fc13 -------------------- * Tue Dec 29 2009 Deji Akingunola - 2.5-1 - New upstream version cfengine-2.2.10-5.fc13 ---------------------- * Tue Dec 29 2009 Jeff Sheltren - 2.2.10-5 - Move docs into a -doc subpackage (#523538) * Sat Dec 12 2009 Jeff Sheltren - 2.2.10-4 - Patch for class definitions using shellcommands (#530458) cherokee-0.99.39-1.fc13 ----------------------- * Tue Dec 29 2009 Lorenzo Villani - 0.99.39-1 - 0.99.39 cln-1.3.1-1.fc13 ---------------- * Tue Dec 29 2009 Deji Akingunola - 1.3.1-1 - New upstream version - Apply patch by Jitesh Shah to fix build on arm em8300-0.18.0-1.fc13 -------------------- * Tue Dec 29 2009 Ville Skytt? - 0.18.0-1 - Update to 0.18.0. - Don't create the video group, require udev >= 136-1 for it. - Drop mostly obsolete README-modprobe.conf. ghdl-0.28-0.133svn.2.fc13 ------------------------- * Wed Dec 30 2009 Thomas Sailer - 0.28-0.133svn.1 - fix crash when running ./tb --stats * Wed Dec 30 2009 Thomas Sailer - 0.28-0.133svn.2 - fix the Process Timeout Chain bugfix gnumeric-1.9.17-3.fc13 ---------------------- * Thu Dec 31 2009 Huzaifa Sidhpurwala 1:1.9.17-3 - Upstream bump to 1.9.17 - Apply gnome bz patch #605043 - BR goffice-devel >= 1.7.17 - Change goffice plugins to 0.7.17 * Fri Dec 04 2009 Stepan Kasal - 1:1.9.16-2 - rebuild against perl 5.10.1 goffice-0.7.17-1.fc13 --------------------- * Thu Dec 31 2009 Huzaifa Sidhpurwala 0.7.17-1 - New upstream version gridengine-6.2u5-1.fc13 ----------------------- * Mon Dec 28 2009 - Orion Poplawski - 6.2u5-1 - Update to 6.2u5 ikiwiki-3.20091218-1.fc13 ------------------------- * Tue Dec 22 2009 Thomas Moschny - 3.20091218-1 - Update to 3.20091218. * Fri Dec 04 2009 Stepan Kasal - 3.20091113-2 - rebuild against perl 5.10.1 json-glib-0.10.0-1.fc13 ----------------------- * Tue Dec 29 2009 Brian Pepple - 0.10.0-1 - Update to 0.10.0. kvirc-4.0.0-0.21.rc2.fc13 ------------------------- * Tue Dec 29 2009 Alexey Kurov - 4.0.0-0.21.rc2 - fix log files date format from svn 3762 latexmk-4.12-1.fc13 ------------------- * Tue Dec 29 2009 Jerry James - 4.12-1 - Update to 4.12 to get new option to not run bibtex. - Add a missing semicolon to the conf file (bz 551082). libguestfs-1.0.80-10.fc13 ------------------------- * Tue Dec 29 2009 Richard W.M. Jones - 1.0.80-10 - Remove some debugging statements which were left in the requires script by accident. lohit-telugu-fonts-2.4.5-4.fc13 ------------------------------- * Wed Dec 30 2009 Pravin Satpute - 2.4.5-4 - fixes bug 551317 lxmusic-0.4.2-1.fc13 -------------------- * Tue Dec 29 2009 Christoph Wickert - 0.4.2-1 - Update to 0.4.2 mcs-0.7.1-9.fc13 ---------------- * Tue Dec 29 2009 Michael Schwendt - 0.7.1-9 - Apply safety fix to keyfile set_string function. ocaml-3.11.2-0.rc1.1.fc13 ------------------------- * Tue Dec 29 2009 Richard W.M. Jones - 3.11.2-0.rc1.1 - Update to (release candidate) 3.11.2+rc1. ocaml-findlib-1.2.5-4.fc13 -------------------------- * Tue Dec 29 2009 Richard W.M. Jones - 1.2.5-4 - Rebuild for OCaml 3.11.2. papyon-0.4.3-2.fc13 ------------------- * Tue Dec 29 2009 Brian Pepple - 0.4.3-2 - Add patch to fix a crasher with TypeError in b64decode. perl-CGI-Application-Plugin-SuperForm-0.5-1.fc13 ------------------------------------------------ * Tue Dec 29 2009 Emmanuel Seyman - 0.5-1 - Update to 0.5 python-markdown2-1.0.1.16-1.fc13 -------------------------------- * Fri Dec 18 2009 Thomas Moschny - 1.0.1.16-1 - Update to 1.0.1.16. rpy-2.0.6-8.fc13 ---------------- * Tue Dec 29 2009 Alex Lancaster - 2.0.6-7 - Rebuild for new R (2.10.1) sane-backends-1.0.20-11.fc13 ---------------------------- * Tue Dec 29 2009 Nils Philippsen - 1.0.20-11 - genesys_gl841: always send registers before trying to acquire a line (#527935) * Mon Dec 28 2009 Nils Philippsen - build v4l backend (#550119) - don't use lockdir, fix make install surfraw-2.2.6-1.fc13 -------------------- * Tue Dec 29 2009 Thomas Moschny - 2.2.6-1 - Update to 2.2.6. - Configuration is now in /etc/xdg/surfraw. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 25 From dsd at laptop.org Wed Dec 30 13:37:27 2009 From: dsd at laptop.org (Daniel Drake) Date: Wed, 30 Dec 2009 13:37:27 +0000 Subject: packaging a static library In-Reply-To: <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> Message-ID: <1262180247.2243.1.camel@localhost.localdomain> On Wed, 2009-12-30 at 12:25 +0100, Martin Langhoff wrote: > Let's focus on the important bit: we need a frozen version of a > library (that, btw, is useful, and is not in Fedora yet :-) ). What's > the best practice for that? I don't see why we'd need to embed it > statically anywhere (except OFW of course). The upstream library is already in Fedora as a shared library. I guess the approach I will take is to install our audited version as a shared library under a different name (libtommath_olpc?) which the components will then dynamically link against. Daniel From martin.langhoff at gmail.com Wed Dec 30 13:54:07 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 30 Dec 2009 14:54:07 +0100 Subject: packaging a static library In-Reply-To: <1262180247.2243.1.camel@localhost.localdomain> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> Message-ID: <46a038f90912300554x4e882fbeg1b32cf71b88ebddd@mail.gmail.com> On Wed, Dec 30, 2009 at 2:37 PM, Daniel Drake wrote: > The upstream library is already in Fedora as a shared library. Is it now? Great -- I had seen some failed attempts to get it into Fedora long ago. > I guess the approach I will take is to install our audited version as a > shared library under a different name (libtommath_olpc?) which the > components will then dynamically link against. Sounds right. And we control the package tightly to ensure we have what we want. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From rjones at redhat.com Wed Dec 30 14:54:55 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 30 Dec 2009 14:54:55 +0000 Subject: OCaml in Rawhide upgraded to 3.11.2-rc1 In-Reply-To: <20091230094013.GC32058@amd.home.annexia.org> References: <20091230094013.GC32058@amd.home.annexia.org> Message-ID: <20091230145455.GA22685@amd.home.annexia.org> On Wed, Dec 30, 2009 at 09:40:13AM +0000, Richard W.M. Jones wrote: > If any provenpackagers are feeling particularly bored this week ... > Otherwise I'll try to do it in my spare time this week or next. I did all but about 10 of them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From abo at root.snowtree.se Wed Dec 30 18:47:20 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 30 Dec 2009 19:47:20 +0100 Subject: packaging a static library In-Reply-To: <1262180247.2243.1.camel@localhost.localdomain> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> Message-ID: <1262198840.6749.417.camel@localhost> ons 2009-12-30 klockan 13:37 +0000 skrev Daniel Drake: > I guess the approach I will take is to install our audited version as a > shared library under a different name (libtommath_olpc?) which the libtommath-audited No sense making it look like it's only for OLPC use. If others want audit-coloured bits they can use it too. /abo From kevin.kofler at chello.at Wed Dec 30 20:56:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Dec 2009 21:56:33 +0100 Subject: packaging a static library References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> Message-ID: Martin Langhoff wrote: > Let's focus on the important bit: we need a frozen version of a > library (that, btw, is useful, and is not in Fedora yet :-) ). What's > the best practice for that? I don't see why we'd need to embed it > statically anywhere (except OFW of course). It's just not allowed. Use the system version, audited or not. If you need frozen, audited software, you need to go back to maintaining your own OLPC branch of Fedora, just like RHEL branches off Fedora. Working directly with upstream Fedora means working the upstream Fedora way. Using old components just because they're audited is not the Fedora way, sorry. Kevin Kofler From kevin.kofler at chello.at Wed Dec 30 20:58:07 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Dec 2009 21:58:07 +0100 Subject: packaging a static library References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> Message-ID: Daniel Drake wrote: > The upstream library is already in Fedora as a shared library. > I guess the approach I will take is to install our audited version as a > shared library under a different name (libtommath_olpc?) which the > components will then dynamically link against. While that at least conforms to our packaging guidelines, I think this is still against Fedora policies, in particular the Fedora Objectives. We want to ship the current software, not old audited one. Fedora is not a certified distribution, it's an up-to-date distribution. Kevin Kofler From kevin.kofler at chello.at Wed Dec 30 21:02:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Dec 2009 22:02:30 +0100 Subject: packaging a static library References: <1262083974.2056.7.camel@localhost.localdomain> Message-ID: Daniel Drake wrote: > OLPC has previously had a specific version of tomcrypt/tommath > profesionally audited for security reasons. So we obviously want to > stick with that version. This is a bad idea and inconsistent with what Fedora is about. If you want that sort of things, you need to go back to maintaining separate OLPC branches. In Fedora, you're supposed to use the current version whenever technically possible. > A few packages we have in Fedora currently use this frozen, audited > version - we do so by shipping duplicate copies of that source code > within the individual packages, rather than linking against the dynamic > systemwide equivalents. This is not allowed and the packages MUST be fixed ASAP (in fact they should never have passed review in the first place, this is a failure of our review process). (And if you refuse to fix it, I'll have to escalate it to FESCo.) > As we're now looking at making another package which uses yet another > duplicate copy of this code base I'm wondering if we can do it better. Yes, just use the system version. > Could I add a package, named olpc-bios-crypto-devel (a subpackage of the > to-be-packaged olpc-bios-crypto), which installs the .a files for the > audited libraries somewhere on the system? Static libraries suck, your later suggestion of a shared audited version is better, but still the right solution is to just use the current version. > Then the individual components that rely on this library (e.g. bitfrost, > olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency > on olpc-bios-crypto-devel and build against the 'systemwide' static .a > library files. > > Or am I going too far against common packaging practice at this point? Yes. Common practice in Fedora is to just use current software and forget about audits. Fedora is not a certified distribution. > Any alternative suggestions? See above. Kevin Kofler From kevin.kofler at chello.at Wed Dec 30 21:04:59 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Dec 2009 22:04:59 +0100 Subject: ABRT considered painful References: <20091229195657.4000ce26@gmail.com> Message-ID: Michael Schwendt wrote: > What's wrong with ABRT? My main beef with it is that it reports its crashes to the downstream bug tracker when really the right people to fix them are the upstream developers. KCrash/DrKonqi is much better there. Kevin Kofler From tcallawa at redhat.com Wed Dec 30 21:42:35 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 Dec 2009 16:42:35 -0500 Subject: packaging a static library In-Reply-To: References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> Message-ID: <4B3BC94B.90801@redhat.com> On 12/30/2009 03:58 PM, Kevin Kofler wrote: > Daniel Drake wrote: >> The upstream library is already in Fedora as a shared library. >> I guess the approach I will take is to install our audited version as a >> shared library under a different name (libtommath_olpc?) which the >> components will then dynamically link against. > > While that at least conforms to our packaging guidelines, I think this is > still against Fedora policies, in particular the Fedora Objectives. We want > to ship the current software, not old audited one. Fedora is not a certified > distribution, it's an up-to-date distribution. FWIW, I'm pretty sure this is not against current Fedora policies, assuming that the libtommath maintainer signs off on it and there is no conflict between the two packages. ~spot From kevin.kofler at chello.at Wed Dec 30 22:01:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Dec 2009 23:01:43 +0100 Subject: packaging a static library References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> <4B3BC94B.90801@redhat.com> Message-ID: Tom "spot" Callaway wrote: > FWIW, I'm pretty sure this is not against current Fedora policies, > assuming that the libtommath maintainer signs off on it and there is no > conflict between the two packages. I guess it's indeed not against the letter of the policies, it's still against their spirit though. Compat packages make sense where they're required for technical or licensing reasons (the latter case being particularly annoying though). In this case, they're neither. And our objectives are to ship the latest software, not an old version just because it went through some sort of formal audit and/or certification. Kevin Kofler From pertusus at free.fr Wed Dec 30 22:04:58 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 30 Dec 2009 23:04:58 +0100 Subject: packaging a static library In-Reply-To: <4B3BC94B.90801@redhat.com> References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> <4B3BC94B.90801@redhat.com> Message-ID: <20091230220458.GA5701@free.fr> On Wed, Dec 30, 2009 at 04:42:35PM -0500, Tom spot Callaway wrote: > > FWIW, I'm pretty sure this is not against current Fedora policies, > assuming that the libtommath maintainer signs off on it and there is no > conflict between the two packages. Indeed, it is just a compat library (and I think that having a rightly packaged static library alongside wouldn't be bad). Nothing in fedora, however, should link against it, that would be against the guidelines, and also not very fedora-like. -- Pat From tcallawa at redhat.com Wed Dec 30 22:22:25 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 Dec 2009 17:22:25 -0500 Subject: packaging a static library In-Reply-To: References: <1262083974.2056.7.camel@localhost.localdomain> <4B3A06FE.6050705@freenet.de> <1262154569.28331.12.camel@tonnant> <4B3AFBAF.90600@freenet.de> <46a038f90912300325vbfa33daua7660bfe25975586@mail.gmail.com> <1262180247.2243.1.camel@localhost.localdomain> <4B3BC94B.90801@redhat.com> Message-ID: <4B3BD2A1.3090608@redhat.com> On 12/30/2009 05:01 PM, Kevin Kofler wrote: > Tom "spot" Callaway wrote: >> FWIW, I'm pretty sure this is not against current Fedora policies, >> assuming that the libtommath maintainer signs off on it and there is no >> conflict between the two packages. > > I guess it's indeed not against the letter of the policies, it's still > against their spirit though. Compat packages make sense where they're > required for technical or licensing reasons (the latter case being > particularly annoying though). In this case, they're neither. And our > objectives are to ship the latest software, not an old version just because > it went through some sort of formal audit and/or certification. Well, my concerns around this are: 1. That this library will be impossible to bugfix without losing its "audit approval" 2. (A) That the OLPC dependent packages in Fedora which depend on this library will want to link against this compat package rather than the current revision OR 2. (B) That the OLPC dependent packages in Fedora will also need to be forked to link against this compat package rather than the current revision. However, it is worth noting that the OLPC OS build is a Fedora Remix, rather than a spin, so they may be able to get by with simply having the compat libtommath-audited package (containing shared rather than static libs) present, and not making any other changes in Fedora. ~spot From jussilehtola at fedoraproject.org Thu Dec 31 12:20:39 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Thu, 31 Dec 2009 14:20:39 +0200 Subject: Bodhi CA problem Message-ID: <1262262039.16195.1.camel@localhost> Hi, for some time now I've been experiencing the following problem with bodhi: $ make update Creating a new update for gromacs-4.0.7-1.el4 gromacs-4.0.7-1.el5 Traceback (most recent call last): File "/usr/bin/bodhi", line 360, in main() File "/usr/bin/bodhi", line 153, in main data = bodhi.save(**update_args) File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111, in save 'bugs': bugs, File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line 316, in send_request req_params = req_params, auth_params = auth_params) File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line 275, in send_request request.perform() pycurl.error: (60, 'Peer certificate cannot be authenticated with known CA certificates') make: *** [bodhi] Error 1 What's the problem and how do I fix it? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rawhide at fedoraproject.org Thu Dec 31 12:52:49 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 31 Dec 2009 12:52:49 +0000 Subject: rawhide report: 20091231 changes Message-ID: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> Compose started at Thu Dec 31 08:15:06 UTC 2009 Broken deps for i386 ---------------------------------------------------------- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.i686 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.i686 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.i686 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.i686 requires ghc-prof = 0:6.10.4 1:gnash-cygnal-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 1:gnash-devel-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 1:gnash-klash-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 1:gnash-plugin-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevview.so.1 gnome-python2-evince-2.28.0-2.fc12.i686 requires libevdocument.so.1 graphviz-ocaml-2.26.0-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 graphviz-ocaml-2.26.0-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 haskell-platform-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.i686 requires libzita-convolver.so.1 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 libextractor-plugins-rpm-0.5.23-1303.fc13.i686 requires librpm.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 ocaml-SDL-0.7.2-20.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-SDL-0.7.2-20.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-camlp5-5.12-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-json-wheel-1.0.6-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-newt-0.9-7.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-newt-0.9-7.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-newt-0.9-7.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-2.2.9-15.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-openin-20070524-9.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-openin-20070524-9.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-openin-20070524-9.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-perl4caml-0.9.5-11.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-preludeml-0.1-0.13.20090113.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-pxp-1.2.1-2.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-react-0.9.0-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-zip-1.04-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-perl-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-python-0.5.5-1.fc13.i686 requires librpm.so.0 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 python-basemap-0.99.4-1.fc13.i686 requires libgeos-3.2.0rc3.so 1:python-gnash-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 sectool-0.9.4-3.fc13.i686 requires librpm.so.0 sectool-0.9.4-3.fc13.i686 requires librpmio.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 ---------------------------------------------------------- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) cduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.x86_64 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.x86_64 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.x86_64 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-devel-1.3.0-2.fc13.x86_64 requires ghc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-doc-1.3.0-2.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-haskell-src-exts-prof-1.3.0-2.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-devel-2.2.1.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-doc-2.2.1.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-network-prof-2.2.1.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-soegtk-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-devel-0.10.1-5.fc12.x86_64 requires ghc = 0:6.10.4 ghc-svgcairo-prof-0.10.1-5.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.i686 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-devel-1.2.0.3-6.fc12.x86_64 requires ghc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-doc-1.2.0.3-6.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-uniplate-prof-1.2.0.3-6.fc12.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc-utf8-string-devel = 0:0.3.5 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-devel-0.9-1.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-contrib-doc-0.9-1.fc13.x86_64 requires ghc-utf8-string-doc = 0:0.3.5 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-prof = 0:6.10.4 ghc-xmonad-contrib-prof-0.9-1.fc13.x86_64 requires ghc-utf8-string-prof = 0:0.3.5 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.i686 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc-X11-devel = 0:1.4.6.1 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-devel-0.9-3.fc13.x86_64 requires ghc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-doc = 0:6.10.4 ghc-xmonad-doc-0.9-3.fc13.x86_64 requires ghc-X11-doc = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-X11-prof = 0:1.4.6.1 ghc-xmonad-prof-0.9-3.fc13.x86_64 requires ghc-prof = 0:6.10.4 1:gnash-cygnal-0.8.6-7.fc13.x86_64 requires gnash = 0:0.8.6-7.fc13 1:gnash-devel-0.8.6-7.fc13.i686 requires gnash = 0:0.8.6-7.fc13 1:gnash-devel-0.8.6-7.fc13.x86_64 requires gnash = 0:0.8.6-7.fc13 1:gnash-klash-0.8.6-7.fc13.x86_64 requires gnash = 0:0.8.6-7.fc13 1:gnash-plugin-0.8.6-7.fc13.x86_64 requires gnash = 0:0.8.6-7.fc13 gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevdocument.so.1()(64bit) gnome-python2-evince-2.28.0-2.fc12.x86_64 requires libevview.so.1()(64bit) graphviz-ocaml-2.26.0-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 graphviz-ocaml-2.26.0-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 haskell-platform-2009.2.0.2-3.fc13.x86_64 requires ghc = 0:6.10.4 hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jconv-0.8.1-2.fc12.x86_64 requires libzita-convolver.so.1()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) libextractor-plugins-rpm-0.5.23-1303.fc13.x86_64 requires librpm.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) ocaml-SDL-0.7.2-20.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-SDL-0.7.2-20.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-bisect-1.0-0.6.alpha.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-bitstring-2.0.0-10.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-camlp5-5.12-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-json-wheel-1.0.6-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-lwt-2.0.0-0.2.rc1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-mikmatch-1.0.2-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-mlgmpidl-1.1-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-newt-0.9-7.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlgraph-1.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-2.2.9-15.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-ocamlnet-nethttpd-2.2.9-15.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-openin-20070524-9.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-p3l-2.03-4.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pa-monad-6.0-3.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-perl4caml-0.9.5-11.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-perl4caml-0.9.5-11.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pgocaml-1.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-postgresql-1.12.3-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-preludeml-0.1-0.13.20090113.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-pxp-1.2.1-2.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-react-0.9.0-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-reins-0.1a-6.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-sexplib-4.2.15-1.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-sqlite-1.5.6-2.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 ocaml-xmlrpc-light-0.6.1-3.fc12.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 ocaml-zip-1.04-3.fc12.x86_64 requires ocaml(runtime) = 0:3.11.1 openscap-0.5.5-1.fc13.i686 requires librpm.so.0 openscap-0.5.5-1.fc13.i686 requires librpmio.so.0 openscap-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-0.5.5-1.fc13.x86_64 requires librpmio.so.0()(64bit) openscap-perl-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) openscap-python-0.5.5-1.fc13.x86_64 requires librpm.so.0()(64bit) player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 player-2.1.1-13.fc12.x86_64 requires libml.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcv.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcxcore.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libcvaux.so.2()(64bit) player-2.1.1-13.fc12.x86_64 requires libhighgui.so.2()(64bit) python-basemap-0.99.4-1.fc13.x86_64 requires libgeos-3.2.0rc3.so()(64bit) 1:python-gnash-0.8.6-7.fc13.x86_64 requires gnash = 0:0.8.6-7.fc13 sectool-0.9.4-3.fc13.x86_64 requires librpm.so.0()(64bit) sectool-0.9.4-3.fc13.x86_64 requires librpmio.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package rubygem-thor Scripting framework that replaces rake, sake and rubigen Updated Packages: audacious-2.2-3.fc13 -------------------- * Wed Dec 30 2009 Michael Schwendt - 2.2-3 - Patch Audacious so that filename_find_decoder only considers enabled input plugins (disabled modplug plugin effectively disabled also the xmp plugin). audacious-plugins-2.2-6.fc13 ---------------------------- * Wed Dec 30 2009 Michael Schwendt - 2.2-6 - Fix the alarm plugin. balsa-2.4.2-1.fc13 ------------------ * Wed Dec 30 2009 Pawel Salek - 2.4.2-1 - update to upstream 2.4.2 bluefish-2.0.0-0.1.rc1.fc13 --------------------------- * Wed Dec 30 2009 Paul Howarth - 2.0.0-0.1.rc1 - Update to major new version - 2.0.0-rc1 (#549552) - Drop all patches - No longer need buildreqs gail-devel, gnome-mime-data, gnome-vfs2-devel - Buildreq gucharmap-devel >= 2.20 for charmap plugin - Buildreq intltool for translations - Buildreq man to check man pages - Buildreq python-devel for python plugin - Req findutils and grep for the Advanced Open function - Use %{name} macro for spec file compatibility with bluefish-unstable - Call %find_lang multiple times for plugin translations - Filter provides for plugin shared objects - Desktop file now installed as part of upstream install process, so use desktop-file-validate instead of desktop-file-install - Explicitly enable python plugin (disabled by default despite docs to contrary) - All supported releases now have noarch subpackages, so drop conditionals cryptsetup-luks-1.1.0-0.5.fc13 ------------------------------ * Wed Dec 30 2009 Milan Broz - 1.1.0-0.5 - Update to cryptsetup 1.1.0-rc4 ghdl-0.28-0.135svn.0.fc13 ------------------------- gigolo-0.4.0-1.fc13 ------------------- * Thu Dec 31 2009 Christoph Wickert - 0.4.0-1 - Update to 0.4.0 gnash-0.8.6-7.fc13 ------------------ * Wed Dec 30 2009 Tomeu Vizoso - 0.8.6-7 - One more try at using the correct dir * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-1 - Update to 0.8.6, increase epoch. * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-2 - Add cygnal plugins * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-3 - Install python modules in the right dir * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-4 - Pick up python modules from the right dir * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-5 - Patch Makefile.in, not Makefile.am * Tue Dec 29 2009 Tomeu Vizoso - 0.8.6-6 - Patch was reversed * Thu Sep 10 2009 Tomeu Vizoso 0.9.0-0.7.20090910bzr11505 - update to HEAD * Thu Sep 10 2009 Tomeu Vizoso 0.9.0-0.8.20090910bzr11506 - update to HEAD gnome-chemistry-utils-0.10.9-3.fc13 ----------------------------------- * Wed Dec 30 2009 Julian Sikorski - 0.10.9-3 - Rebuilt for goffice 0.7.17 guimup-0.2.1-2.fc13 ------------------- * Wed Dec 30 2009 Andreas Osowski 0.2.1-2 - Libtool fixes * Tue Dec 08 2009 Andreas Osowski 0.2.1-1 - Updated to version 0.2.1 iverilog-0.9.20091230-1.fc13 ---------------------------- * Wed Dec 30 2009 Chitlesh Goorah - 0.9.20091230-1 - New stable snapshot - 0.9.2 kde-settings-4.4-6.1 -------------------- * Wed Dec 30 2009 Rex Dieter 4.4-6.1 - -kdm: Requires: kdm kdebindings-4.3.85-4.fc13 ------------------------- * Wed Dec 30 2009 Rex Dieter - 4.3.95-4 - upstream enum patch kdeedu-4.3.85-2.fc13 -------------------- * Wed Dec 30 2009 Kevin Kofler - 4.3.85-2 - rebuild for new OCaml (3.11.2 rc1) libtar-1.2.11-16.fc13 --------------------- * Thu Dec 31 2009 Huzaifa Sidhpurwala - 1.2.11-16 - Fix invalid memory de-reference issue in BZ #380965 lmms-0.4.6-1.fc13 ----------------- * Wed Dec 30 2009 Thomas Moschny - 0.4.6-1 - Update to 0.4.6. - Rebase patches. - Minor specfile fixes. netpbm-10.47.07-1.fc13 ---------------------- * Wed Dec 30 2009 Jindrich Novy 10.47.07-1 - update to 10.47.07 ocaml-ancient-0.9.0-4.fc13 -------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.9.0-4 - Rebuild for OCaml 3.11.2. ocaml-augeas-0.4-7.fc13 ----------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.4-7 - Rebuild for OCaml 3.11.2. ocaml-autoconf-1.1-3.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.1-3 - Rebuild for OCaml 3.11.2. ocaml-cairo-1.2.0-0.2.gita5c5ee9f.fc13 -------------------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1:1.2.0-0.2.gita5c5ee9f - Rebuild for OCaml 3.11.2. * Mon Dec 07 2009 Richard W.M. Jones - 1:1.2.0-0.1.gita5c5ee9f - So we are wrong, version numbers did NOT roll backwards. - Revert to current git head (a5c5ee9f) which is a pre-release of 1.2.0 (RHBZ#541542). - Replace %define with %global. - Patch0 is now upstream. - Checked package with rpmlint - no problems. ocaml-calendar-2.01.1-3.fc13 ---------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 2.01.1-3 - Rebuild for OCaml 3.11.2. ocaml-camlidl-1.05-11.fc13 -------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.05-11 - Rebuild for OCaml 3.11.2. ocaml-camlimages-3.0.1-15.fc13 ------------------------------ * Wed Dec 30 2009 Richard W.M. Jones - 3.0.1-15 - Rebuild for OCaml 3.11.2. ocaml-camomile-0.7.2-2.fc13 --------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.7.2-2 - Rebuild for OCaml 3.11.2. ocaml-cil-1.3.7-5.fc13 ---------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.3.7-5 - Rebuild for OCaml 3.11.2. * Mon Dec 07 2009 Stepan Kasal - 1.3.7-4 - rebuild against perl 5.10.1 ocaml-cryptokit-1.3-11.fc13 --------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.3-11 - Rebuild for OCaml 3.11.2. ocaml-csv-1.1.7-7.fc13 ---------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.1.7-7 - Rebuild for OCaml 3.11.2. ocaml-curl-0.5.1-3.fc13 ----------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.5.1-3 - Rebuild for OCaml 3.11.2. ocaml-curses-1.0.3-8.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.0.3-8 - Rebuild for OCaml 3.11.2. ocaml-dbus-0.24-2.fc13 ---------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.24-2 - Rebuild for OCaml 3.11.2. ocaml-deriving-0.1.1a-10.fc13 ----------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.1.1a-10 - Rebuild for OCaml 3.11.2. ocaml-expat-0.9.1-18.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.9.1-18 - Rebuild for OCaml 3.11.2. ocaml-extlib-1.5.1-9.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.5.1-9 - Rebuild for OCaml 3.11.2. ocaml-facile-1.1-12.fc13 ------------------------ * Wed Dec 30 2009 Richard W.M. Jones - 1.1-12 - Rebuild for OCaml 3.11.2. ocaml-fileutils-0.4.0-3.fc13 ---------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.4.0-3 - Rebuild for OCaml 3.11.2. ocaml-gettext-0.3.3-2.fc13 -------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.3.3-2 - Rebuild for OCaml 3.11.2. ocaml-gsl-0.6.0-10.fc13 ----------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.6.0-10 - Rebuild for OCaml 3.11.2. ocaml-json-static-0.9.8-2.fc13 ------------------------------ * Wed Dec 30 2009 Richard W.M. Jones - 0.9.8-2 - Rebuild for OCaml 3.11.2. ocaml-lablgl-1.04-3.fc13 ------------------------ * Wed Dec 30 2009 Richard W.M. Jones - 1.04-3 - Rebuild for OCaml 3.11.2. ocaml-lablgtk-2.14.0-3.fc13 --------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 2.14.0-3 - Rebuild for OCaml 3.11.2. ocaml-lacaml-5.4.7-2.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 5.4.7-2 - Rebuild for OCaml 3.11.2. ocaml-libvirt-0.6.1.0-7.fc13 ---------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.6.1.0-7 - Rebuild for OCaml 3.11.2. ocaml-mysql-1.0.4-12.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.0.4-12 - Rebuild for OCaml 3.11.2. ocaml-ounit-1.0.3-7.fc13 ------------------------ * Wed Dec 30 2009 Richard W.M. Jones - 1.0.3-7 - Rebuild for OCaml 3.11.2. ocaml-pa-do-0.8.10-3.fc13 ------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.8.10-3 - Rebuild for OCaml 3.11.2. ocaml-pcre-6.0.1-2.fc13 ----------------------- * Wed Dec 30 2009 Richard W.M. Jones - 6.0.1-2 - Rebuild for OCaml 3.11.2. ocaml-res-3.2.0-4.fc13 ---------------------- * Wed Dec 30 2009 Richard W.M. Jones - 3.2.0-4 - Rebuild for OCaml 3.11.2. ocaml-ssl-0.4.3-6.fc13 ---------------------- * Wed Dec 30 2009 Richard W.M. Jones - 0.4.3-6 - Rebuild for OCaml 3.11.2. ocaml-type-conv-1.6.10-3.fc13 ----------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.6.10-3 - Rebuild for OCaml 3.11.2. ocaml-ulex-1.1-9.fc13 --------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.1-9 - Rebuild for OCaml 3.11.2. ocaml-xml-light-2.2.cvs20070817-14.fc13 --------------------------------------- * Wed Dec 30 2009 Richard W.M. Jones - 2.2.cvs20070817-14 - Rebuild for OCaml 3.11.2. olpc-utils-1.0.16-1.fc13 ------------------------ * Thu Dec 31 2009 Sayamindu Dasgupta - 1.0.16-1 - Bump to v1.0.16 for disabling imsettings-daemon php-pear-Mail-Mime-1.5.3-1.fc13 ------------------------------- * Wed Dec 30 2009 Remi Collet - 1.5.3-1 - update to new upstream version - remove circular dependency on Mail_mimeDecode - rename Mail_Mime.xml to php-pear-Mail-Mime.xml - fix License (BSD, not PHP, since 1.4.0) - fix missing URL phpwapmail-0.9.3-1.fc13 ----------------------- * Wed Dec 30 2009 Dmitry Butskoy - 0.9.3-1 - update to 0.9.3 postgresql-odbc-08.04.0200-1.fc13 --------------------------------- * Wed Dec 30 2009 Tom Lane 08.04.0200-1 - Update to version 08.04.0200 qbittorrent-2.1.0-0.3.beta3.fc13 -------------------------------- * Wed Dec 30 2009 Leigh Scott - 2.1.0-0.3.beta3 - update to 2.1.0beta3 vdradmin-am-3.6.5-1.fc13 ------------------------ * Wed Dec 30 2009 Ville Skytt? - 3.6.5-1 - Update to 3.6.5. - Log to syslog by default. virt-top-1.0.4-3.fc13 --------------------- * Wed Dec 30 2009 Richard W.M. Jones - 1.0.4-3 - Force rebuild against latest ocaml-gettext 0.3.3 (RHBZ#508197#c10). xfce4-dict-0.6.0-1.fc13 ----------------------- * Thu Dec 31 2009 Christoph Wickert - 0.6.0-1 - Update to 0.6.0 - Drop OnlyShowIn xfce4-panel-4.6.3-1.fc13 ------------------------ * Wed Dec 30 2009 Christoph Wickert - 4.6.3-1 - Update to 4.6.3 znc-0.078-1.fc13 ---------------- * Wed Dec 30 2009 Nick Bebout - 0.078-1 - Update to znc 0.078 * Sun Dec 13 2009 Nick Bebout - 0.078-0.1.rc1 - Update to znc 0.078.rc1 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 62 From rjones at redhat.com Thu Dec 31 13:16:18 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 31 Dec 2009 13:16:18 +0000 Subject: rawhide report: 20091231 changes In-Reply-To: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> References: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> Message-ID: <20091231131618.GA28385@amd.home.annexia.org> On Thu, Dec 31, 2009 at 12:52:49PM +0000, Rawhide Report wrote: [...] I got half way through doing these yesterday, but a combination of being distracted and a mistake in my script means I forgot some. One annoying thing about Koji is I can't seem to tell when a previous rawhide build becomes available to build against. Here I'll just update the status of each. Feel free to jump in with fixes ... I won't have time to work on these until Jan 6th. > cduce I think needs an upstream fix. > graphviz-ocaml Not my package and quite a complicated package, so I didn't dare to rebuild this one. > ocaml-camlp5 Needs an upstream fix. > ocaml-ocamlnet Strange build regression: http://koji.fedoraproject.org/koji/getfile?taskID=1895926&name=build.log Possibly an upstream problem. > ocaml-json-wheel Requires ocaml-ocamlnet -- see above. > ocaml-preludeml Requires ocaml-ocamlnet -- see above. > ocaml-pxp Requires ocaml-ocamlnet -- see above. ---- The following packages were missed by my hacky build script for some reason. I'm going to rebuild them right now: > ocaml-SDL-0.7.2-20.fc12.i686 requires ocaml(runtime) = 0:3.11.1 > ocaml-bisect-1.0-0.6.alpha.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-bitstring-2.0.0-10.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-lwt-2.0.0-0.2.rc1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-mikmatch-1.0.2-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-mlgmpidl-1.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-newt-0.9-7.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 > ocaml-ocamlgraph-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-openin-20070524-9.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-p3l-2.03-4.fc12.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 > ocaml-pa-monad-6.0-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-perl4caml-0.9.5-11.fc13.i686 requires ocaml(runtime) = 0:3.11.1 > ocaml-pgocaml-1.3-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-postgresql-1.12.3-1.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 > ocaml-react-0.9.0-2.fc13.i686 requires ocaml(runtime) = 0:3.11.1 > ocaml-reins-0.1a-6.fc12.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 > ocaml-sexplib-4.2.15-1.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-sqlite-1.5.6-2.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 > ocaml-xmlrpc-light-0.6.1-3.fc12.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb > ocaml-zip-1.04-3.fc12.i686 requires ocaml(runtime) = 0:3.11.1 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Thu Dec 31 14:33:40 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 31 Dec 2009 14:33:40 +0000 Subject: rawhide report: 20091231 changes In-Reply-To: <20091231131618.GA28385@amd.home.annexia.org> References: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> <20091231131618.GA28385@amd.home.annexia.org> Message-ID: <20091231143340.GA30122@amd.home.annexia.org> On Thu, Dec 31, 2009 at 01:16:18PM +0000, Richard W.M. Jones wrote: > ocaml-reins Strange failure -- can't find libfam.so.0? http://koji.fedoraproject.org/koji/getfile?taskID=1896852&name=build.log I couldn't reproduce this on my local machine. > > ocaml-xmlrpc-light Needs ocaml-ocamlnet, see previous email. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.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 From bruno at wolff.to Thu Dec 31 14:38:24 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 31 Dec 2009 08:38:24 -0600 Subject: rawhide report: 20091231 changes In-Reply-To: <20091231131618.GA28385@amd.home.annexia.org> References: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> <20091231131618.GA28385@amd.home.annexia.org> Message-ID: <20091231143824.GA17682@wolff.to> On Thu, Dec 31, 2009 at 13:16:18 +0000, "Richard W.M. Jones" wrote: > On Thu, Dec 31, 2009 at 12:52:49PM +0000, Rawhide Report wrote: > [...] > > I got half way through doing these yesterday, but a combination of > being distracted and a mistake in my script means I forgot some. One > annoying thing about Koji is I can't seem to tell when a previous > rawhide build becomes available to build against. They need to be built near the start of the process, which seems to be on the order of 6 hours before the builds have finished. If you are building stuff in F12 and hoping for it to be inherited by rawhide, note that it needs to make it to updates (not updates-testing) to be picked up for rawhide. From mschwendt at gmail.com Thu Dec 31 14:41:07 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 31 Dec 2009 15:41:07 +0100 Subject: rawhide report: 20091231 changes In-Reply-To: <20091231131618.GA28385@amd.home.annexia.org> References: <20091231125249.GA3467@releng2.fedora.phx.redhat.com> <20091231131618.GA28385@amd.home.annexia.org> Message-ID: <20091231154107.35ab573a@gmail.com> On Thu, 31 Dec 2009 13:16:18 +0000, Richard wrote: > On Thu, Dec 31, 2009 at 12:52:49PM +0000, Rawhide Report wrote: > [...] > > I got half way through doing these yesterday, but a combination of > being distracted and a mistake in my script means I forgot some. One > annoying thing about Koji is I can't seem to tell when a previous > rawhide build becomes available to build against. koji wait-repo --target dist-f13 --build foo-1.0-1.fc13 From snecklifter at gmail.com Thu Dec 31 15:13:07 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 31 Dec 2009 15:13:07 +0000 Subject: ABRT considered painful In-Reply-To: References: <20091229195657.4000ce26@gmail.com> Message-ID: <364d303b0912310713k145e1ba5k758c41744375f5f7@mail.gmail.com> 2009/12/30 Kevin Kofler : > Michael Schwendt wrote: >> What's wrong with ABRT? > > My main beef with it is that it reports its crashes to the downstream bug > tracker when really the right people to fix them are the upstream > developers. KCrash/DrKonqi is much better there. Probably because we need to determine whether the issue is Fedora-specific (packaging bug) or is also replicated in the vanilla version before we create more noise on upstream's bug tracker. Hence why kernel developers usually ask if bugs can be reproduced from Linus' tree. Cheers -- Christopher Brown From j.w.r.degoede at hhs.nl Wed Dec 30 07:15:04 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Dec 2009 08:15:04 +0100 Subject: Fedora Linux Format software review: January 2010 In-Reply-To: <364d303b0912291420o4af25d92je96cf6a905e8f497@mail.gmail.com> References: <364d303b0912291420o4af25d92je96cf6a905e8f497@mail.gmail.com> Message-ID: <4B3AFDF8.9000803@hhs.nl> Hi, On 12/29/2009 11:20 PM, Christopher Brown wrote: > Hi folks, > > Linux Format is a popular magazine in the U.K but which ships all over > the world. It regularly reviews interesting bits of software and I > thought: > > a) It would be interesting to see how much of what they review is > included in Fedora > b) It would be a good idea to get that which is not in and/or up to date > c) If there is enough interest I would like to form a SIG to do the > monthly reviews - a kind of packaging wishlist on steroids perhaps :) > > I blogged about this recently and you can read the basic idea there: > > http://chruz.wordpress.com/2009/12/23/ive-got-the-music-on-my-radio/ > > The editor has expressed his willingness to send details of software > which they will review to us so we have a head start. I have conducted > the first review of the January 2010 issue which you can read here: > > https://fedoraproject.org/wiki/LinuxFormatPackaging > > There are some interesting omissions, for example Recoll, the desktop > search tool which came out ahead of Beagle and Google Desktop and > which doesn't even have a review request opened for it yet. > > A few points that need mentioning: > > 1) I do not and have never worked for Linux Format nor has anyone I know :) > 2) There may be some glaring errors - this is why this is on the wiki > so please feel free to update/change etc. For example I have not > undertaken rigorous reviews for the software's suitability. > 3) This is not intended as anything other than a distillation of what > would be good to have in the repositories. > > I welcome your comments as ever. > blob and conquer is no longer in Fedora (and not being updated), because it contains various non free resources. I'm working together with the Debian packager on replacement textures, sound and music, as time allows, until this is fixed it cannot be included in Fedora. I've been discussing doing a "development sprint" focussing solely on resource replacement together with the debian packager, as we are both Dutch the idea was to get together and work an entire day on this, hopefully making some good progress. It would be nice if others could join in (be it virtual not necessarily physically). So are there any takers for this ? Regards, Hans From tcallawa at redhat.com Thu Dec 31 15:31:01 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 31 Dec 2009 10:31:01 -0500 Subject: Fedora Linux Format software review: January 2010 In-Reply-To: <4B3AFDF8.9000803@hhs.nl> References: <364d303b0912291420o4af25d92je96cf6a905e8f497@mail.gmail.com> <4B3AFDF8.9000803@hhs.nl> Message-ID: <4B3CC3B5.5070702@redhat.com> On 12/30/2009 02:15 AM, Hans de Goede wrote: > It would be nice if others could join in (be it virtual not necessarily > physically). So are there any takers for this ? It might be useful to have a wiki page listing out the specific content items which need to be replaced. ~spot From rdieter at math.unl.edu Thu Dec 31 15:49:36 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 Dec 2009 09:49:36 -0600 Subject: Bodhi CA problem References: <1262262039.16195.1.camel@localhost> Message-ID: Jussi Lehtola wrote: > Hi, > > > for some time now I've been experiencing the following problem with > bodhi: > > $ make update > Creating a new update for gromacs-4.0.7-1.el4 gromacs-4.0.7-1.el5 > Traceback (most recent call last): > File "/usr/bin/bodhi", line 360, in > main() > File "/usr/bin/bodhi", line 153, in main > data = bodhi.save(**update_args) > File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line > 111, in save > 'bugs': bugs, > File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", > line 316, in send_request > req_params = req_params, auth_params = auth_params) > File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", > line 275, in send_request > request.perform() > pycurl.error: (60, 'Peer certificate cannot be authenticated with known > CA certificates') > make: *** [bodhi] Error 1 > > > What's the problem and how do I fix it? I saw that the other day too... a broken nss update was to blame, https://admin.fedoraproject.org/updates/F12/FEDORA-2009-13060 Either downgrade or upgrade to a newer one from koji. From jonathan.underwood at gmail.com Thu Dec 31 18:11:20 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 31 Dec 2009 18:11:20 +0000 Subject: ABRT considered painful In-Reply-To: <20091229195657.4000ce26@gmail.com> References: <20091229195657.4000ce26@gmail.com> Message-ID: <645d17210912311011v609a705ei62b1fbbd0a3d905f@mail.gmail.com> 2009/12/29 Michael Schwendt : > What's wrong with ABRT? > > Originally, with stock F-12, I had received a couple of good backtraces in > bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. > > And later? - Recently, in all the backtraces dozens of debuginfo packages > are missing. :-( Locally, for the past few days, debuginfo packages have failed to install for me because I have the rpmfusion-{free,nonfree} repositories activated, and the main mirrorlist for rpmfusion seems to have gone down, so debuginfo never completes, and abrt carries on its merry way. I suspect others are seeing this. From jonathan.underwood at gmail.com Thu Dec 31 18:12:09 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 31 Dec 2009 18:12:09 +0000 Subject: ABRT considered painful In-Reply-To: <645d17210912311011v609a705ei62b1fbbd0a3d905f@mail.gmail.com> References: <20091229195657.4000ce26@gmail.com> <645d17210912311011v609a705ei62b1fbbd0a3d905f@mail.gmail.com> Message-ID: <645d17210912311012m44e44859x38a4cecdcc357600@mail.gmail.com> 2009/12/31 Jonathan Underwood : > 2009/12/29 Michael Schwendt : >> What's wrong with ABRT? >> >> Originally, with stock F-12, I had received a couple of good backtraces in >> bugzilla. Incredibly useful. A wonderful improvement over F-11 and older. >> >> And later? - Recently, in all the backtraces dozens of debuginfo packages >> are missing. :-( > > Locally, for the past few days, debuginfo packages have failed to > install for me because I have the rpmfusion-{free,nonfree} > repositories activated, and the main mirrorlist for rpmfusion seems to > have gone down, so debuginfo never completes, and abrt carries on its ^^^^^^ debuginfo-install