Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/10 Orcan Ogetbil > > Yeah that is one of the only two swami commits in the last 2 years. > > Anyway, do we have a Fedora policy to remove software just because > they are old and unmaintained upstream? If there is a happy userbase > and a maintainer willing to take care of the package, what is the big > deal? > > It seems fedora don't have a such policy to retire a package unless the maintainer wants to do it. I started this discussion because debian droped gtk+ 1.2 in squeeze and RHEL 6 also dropped gtk+ 1.2 in its package collections. When rhel updates to a new big release, it always drops some deprecated packages compared to the previous release. Considering fedora 13 just remove ppc arch to secondary arch, it's meaningful for fedora to retire some long dead upstream packages as well. Maybe it's suitable to retire gtk 1.2 in F14 or F15, then remove it to rpmfusion for a compatible reason as python 2.4. Regards. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Sun 9 May 2010 11:31:21 pm Michael Cronenworth wrote: > On 05/10/2010 01:23 AM, Léon Keijser wrote: > > I still use an old nethack-like game that unfortunately depends on gtk > > 1.2. Since i'll never be able to get it into Fedora, i just install gtk > > myself then i'm good to go again. I would regret it if my favorite > > distro drops the package simply because it's not being maintaned > > upstream. > > You should be pressuring the author of the game you use to use GTK 2.0. > If your game is no longer maintained, then you should update it yourself. > > Fedora is based on a principle of being First with software. GTK 1.0 > does not fit into this category any more and hasn't for several Fedora > releases. That doesn't mean we should throw it to the wayside. If it works, it works. As long as someone is there to maintain it, let them maintain it. If the maintainer is willing to keep it going, who cares whether it's in the distro? In fact, why is this discussion occuring without the gtk+ maintainer involved? You'd think he'd have a say in it before the crowd wantonly decided to drop his packages. Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Mon 10 May 2010 12:01:01 am Chen Lei wrote: > Considering fedora 13 just remove ppc arch to secondary arch, it's > meaningful for fedora to retire some long dead upstream packages as well. > Maybe it's suitable to retire gtk 1.2 in F14 or F15, then remove it to > rpmfusion for a compatible reason as python 2.4. We retired PPC because there wasn't enough manpower behind it. Not because it was obsolete. There are still people who have ppc machines, just as there are probably still people using gtk+ 1.2-dependant packages. -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
2010/5/10 Ryan Rix > On Sun 9 May 2010 11:31:21 pm Michael Cronenworth wrote: > > On 05/10/2010 01:23 AM, Léon Keijser wrote: > > > I still use an old nethack-like game that unfortunately depends on gtk > > > 1.2. Since i'll never be able to get it into Fedora, i just install > gtk > > > myself then i'm good to go again. I would regret it if my favorite > > > distro drops the package simply because it's not being maintaned > > > upstream. > > > > You should be pressuring the author of the game you use to use GTK 2.0. > > If your game is no longer maintained, then you should update it yourself. > > > > Fedora is based on a principle of being First with software. GTK 1.0 > > does not fit into this category any more and hasn't for several Fedora > > releases. > > That doesn't mean we should throw it to the wayside. If it works, it works. > As > long as someone is there to maintain it, let them maintain it. If the > maintainer is willing to keep it going, who cares whether it's in the > distro? > In fact, why is this discussion occuring without the gtk+ maintainer > involved? > You'd think he'd have a say in it before the crowd wantonly decided to drop > his packages. > > Ryan > > This is a discussion for gtk+ 1.2 just like some other distributions, retiring gtk+ 1.2 is not an easy thing and worth discussion between several people. It'll be great if the gtk+ maintainer can involve in the discussion. Retiring long dead upstram packages will be helpful to keep yum metadata in an accept size and encourage developers switch from old toolkits to modern tookits. Fedora always updates its gcc/python to the newest release and breaks a few packages in repos, so it's the same case to treat development toolkits as well if most of the applications can work compile with subsequent toolkits. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sunday 09 May 2010 19:13:57 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > I think it would be better to drop ntp support completely from s-c-d once > > chrony becomes default in Fedora. We aim to support default Fedora > > configuration tools. Radek Novacek is now working on date/time DBus > > interface under FMCI umbrella. > > Speaking of configuration tools, we also need to have a look at KDE's > date/time dialog. Currently, there is an option to enable NTP support, but > 1. it doesn't notice that it's already enabled by system-config-date or > Anaconda :-(, 2. it's quite lacking in options (you can only enable/disable > it and pick one server (not even a list of servers), no other options), and > 3. it obviously doesn't support Chrony at this time. > > Kevin Kofler I was thinking about it and I talked to Mirek Lichvar about it. We will probably need a custom distribution path if we'd like to reuse system config interface Radek Novacek is working right now. I don't like it but it's not going to be upstreamable :( Same for other configuration modules... Another possibility is to have own custom KCM (next to system-config-date). Jaroslav -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outdated Wine versions in koji?
Andreas Bierfert írta: > On Sat, 2010-05-08 at 12:20 +0200, drago01 wrote: > >> 2010/5/8 Zoltan Boszormenyi : >> >>> Hi, >>> >>> the latest version of Wine found in koji is 1.1.38, which was released >>> in february this year. The latest mainstream Wine is 1.1.44. >>> >>> Why isn't there a newer version compiled for Fedora? >>> >> You'd have to ask the maintainer ... there is a bug open here >> https://bugzilla.redhat.com/show_bug.cgi?id=580024 >> > > Updates are delayed due to some legal questions. I will push an upgrade > as soon as this is resolved. > > - Andreas > I guess the legal problem(s) may come from the fact that newer Wine has cut out its own MP3 decoder and instead, it uses dlopened libmpg123. How does it differ from the DVD playing situation? Xine, MPlayer, etc. uses libdvdcss via dlopen if available. And the user, not the distributor adds the decoding facility... Best regards, Zoltán Böszörményi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sun, May 09, 2010 at 01:15:03PM -0700, Ryan Rix wrote: > I find that having NTP enabled in most cases for mobile systems is simply > unnecessary; there is a large (I would say upwards of 95% in my most > unscientific guessings) chance that these users aren't going to be doing > anything which requires their clocks to be synced with any amount of > precision. And if they are, they should _know_ that and be able to set up > a tool (whether it is NTP or Crony) themselves. I guess you've never had to debug Kerberos before. Luckily, neither have i, so i'm not one to talk. There are a number of apps that are pretty dependent on the clocks being in sync with each other to a degree. Granted, not everyone is running all those apps, but then it begs the question why Fedora provides so much out of the box in the first place. Let's assume that NTP is probably a good thing to support out of the box on most machines, assuming we can support it right in the first place. -Yaakov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/09/2010 02:28 PM, Frank Murphy wrote: > On 09/05/10 13:34, Hedayat Vatankhah wrote: >> If you have not see this at all, I've seen this frequently. Fedora >> sucks in this area for many years. I've seen it, so whatever >> arguments you bring; I KNOW that this bug IS very important and >> should be fixed. > > Currently there are various threads, about what Fedora is targeted at, > those questions as yet rmein without a proper answr. > >> Excuse me, I'm looking for a solution, not for wiping the problem >> statement. > > The solution for a new user to Linux, give hime Ubuntu-LTS. > When he knows some more, give him Fedora. This is a bad argument IMO. Many users are advanced in some areas, but not others. The whole idea that "Fedora is a distro for advanced users therefore it should be hard to use" is absurd. The ability to install packages from a DVD just as easily as from the repos would be useful to a great many. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 10:08, Andrew Haley wrote: --snip-- > > This is a bad argument IMO. Many users are advanced in some areas, > but not others. The whole idea that "Fedora is a distro for advanced > users therefore it should be hard to use" is absurd. How is it hard to use? excl. patented stuff. I can use it! I am not a Programmer\Packager. Never used a PC growing up or at school. Was with Windows up to and incl Vista. The ability to > install packages from a DVD just as easily as from the repos would be > useful to a great many. > Look earlier in the thread, how to mount a DVD as a repo has been demonstrated. All it takes is adding method to wiki. "How to use DVD\CD as repo" Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 10.5.2010 06:54, Ralf Corsepius napsal(a): > Have you ever talked to Ubuntu/openSUSE users and listened to their > replies when telling them you are using Fedora? > > You will hear answers along the line of too much inconvenience to get > multimedia working, too unstable (in the sense of low MTBF), "I tried > Fedora once, but had suffered from -failures", no usable > system-config GUI, ... I heard these arguments many times and some of them are fair, but some of them just are not ... how less difficult it could be to get multimedia working than clicking on two links (http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm and http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm) and agreeing on the inserting new repository? Matěj -- This is a test of the emergency signature system. Were this an actual signature, you would see amusing mottos, disclaimers, a zillion net addresses, or edifying philosophical statements. this is only test. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 11:18 AM, Matěj Cepl wrote: > Dne 10.5.2010 06:54, Ralf Corsepius napsal(a): >> Have you ever talked to Ubuntu/openSUSE users and listened to their >> replies when telling them you are using Fedora? >> >> You will hear answers along the line of too much inconvenience to get >> multimedia working, too unstable (in the sense of low MTBF), "I tried >> Fedora once, but had suffered from -failures", no usable >> system-config GUI, ... > > I heard these arguments many times and some of them are fair, but some > of them just are not ... how less difficult it could be to get > multimedia working than clicking on two links > (http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm > and > http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm) > and agreeing on the inserting new repository? To have stuff just work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 10.5.2010 11:26, drago01 napsal(a): > To have stuff just work. Go to http://senate.gov/ and ask your congressman to fix it. Otherwise (for example if you don't have your congressman because you are not a U.S. citizen), you can also try to move Red Hat's headquarters outside of U.S. (although I am not sure, it would be enough, you would probably ask its biggest clients to move). Matěj -- A man once asked Mozart how to write a symphony. Mozart told him to study at the conservatory for six or eight years, then apprentice with a composer for four or five more years, then begin writing a few sonatas, pieces for string quartets, piano concertos, etc. and in another four or five years he would be ready to try a full symphony. The man said, "But Mozart, didn't you write a symphony at age eight?" Mozart replied, "Yes, but I didn't have to ask how." -- ripped from another sig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 11:33 AM, Matěj Cepl wrote: > Dne 10.5.2010 11:26, drago01 napsal(a): >> To have stuff just work. > > Go to http://senate.gov/ and ask your congressman to fix it. Otherwise > (for example if you don't have your congressman because you are not a > U.S. citizen), you can also try to move Red Hat's headquarters outside > of U.S. (although I am not sure, it would be enough, you would probably > ask its biggest clients to move). I didn't say that we can fix it; just that it *is* easier in other distributions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/10/2010 11:18 AM, Matěj Cepl wrote: > Dne 10.5.2010 06:54, Ralf Corsepius napsal(a): >> Have you ever talked to Ubuntu/openSUSE users and listened to their >> replies when telling them you are using Fedora? >> >> You will hear answers along the line of too much inconvenience to get >> multimedia working, too unstable (in the sense of low MTBF), "I tried >> Fedora once, but had suffered from -failures", no usable >> system-config GUI, ... > > I heard these arguments many times and some of them are fair, but some > of them just are not ... how less difficult it could be to get > multimedia working than clicking on two links ... I know this ... It's them who don't know ... It seems to be a high enough hurdle for some beginners to take and enough reason for to abstain from Fedora ;) ... unfortunately can't avoid having to agree to the "MTBF accusations" and the "-failures". Interestingly most of the packages I am personally facing "real malfunctions" in Fedora with, are almost identical to what Ubuntu ships :) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 10.5.2010 11:35, drago01 napsal(a): > I didn't say that we can fix it; just that it *is* easier in other > distributions. Which don't have principal headquarters of their sponsor in US (but on the Isle of Man, which was chosen exactly because of its lax legal and especially tax, true, regime). Instead of comparing with Ubuntu, how is our configuration more complicated than OpenSuSE, which is in different situation (Novell being US company)? Matěj -- Science is meaningless because it gives no answer to our question, the only question important to us: ``What shall we do and how shall we live?'' -- Lev Nikolaevich Tolstoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 10:16 AM, Frank Murphy wrote: > On 10/05/10 10:08, Andrew Haley wrote: > --snip-- >> >> This is a bad argument IMO. Many users are advanced in some areas, >> but not others. The whole idea that "Fedora is a distro for advanced >> users therefore it should be hard to use" is absurd. > > How is it hard to use? excl. patented stuff. > I can use it! > I am not a Programmer\Packager. > Never used a PC growing up or at school. > Was with Windows up to and incl Vista. > >> The ability to >> install packages from a DVD just as easily as from the repos would be >> useful to a great many. >> > > Look earlier in the thread, > how to mount a DVD as a repo has been demonstrated. Yes, it has. And it's more difficult that installing from the repos. Which was my point. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sun, May 09, 2010 at 11:45:49AM -0600, Stephen John Smoogen wrote: > On Wed, May 5, 2010 at 7:35 AM, Miroslav Lichvar wrote: > > With the latest improvements in the chrony package related to > > NetworkManager and name resolving I think it is now good enough to > > replace ntpd in the default configuration and the configurations > > supported by system-config-date. > > Hi Miroslav, > > lets go over a couple of things to help lower the grumpiness of others. > > 1) Who are you? > 2) What is your position in regards to knowing ntpd and/or chrony in > stability and other things? I'm the maintainer of the ntp and chrony packages, for 4 and 1.5 years respectively. I'm also an upstream maintainer of chrony and I'm familiar with internal designs of both applications. > I think most people do not know who maintains ntpd, and do not know if > this is a "Oh wow I just found this really great software program and > we should change to it right away" kind of email. Well, that's exactly what I thought when I first discovered chrony :). > > I'm proposing to add a support for chrony to system-config-date and > > change the dependency. As chrony supports only a subset of the NTP > > protocol and misses many of the ntpd features, users will have to > > install the ntp package manually if they have a specific requirement > > or need to use a more complicated configuration. > > Ok time is one of those touchstone security tools that people get all > kinds of crazy about when things get changed. Here are a couple of > questions that might help: > > > 1) Why chrony? Why not OpenNTPD [fill in the blank here] I think the most important chrony features are covered in the original mail. OpenNTPD is not able to compensate for drift, i.e. it's not much better than running ntpdate from cron. Currently, the only other NTP client I know that might have enough features and good perfomance to be considered as a default client (if it worked on Linux) is dntpd from DragonFly BSD. > 2) Where is the data that chrony actually controls the clock better? One comparison is here: http://axion.physics.ubc.ca/chrony/chrony.html An old test I did with a GPS reference clock (this may better demonstrate clock control abilities): http://fedorapeople.org/~mlichvar/chrony/chrony_vs_ntp.png > 3) How far have you/others tested it in comparison with ntpd? I'm using chrony on most of my machines, some of them are running 24x7, some are rebooted/suspended daily, quality of the network connection varies from wireless to fiber. > 4) A release plan should probably look like the following: > > > Fedora-14 we add chrony into alternatives or other commands needed to > get it to work. System-config-date has pathways to configure one or > the other when it is seen. Test days and reviews are done to see how > it is going. Organize a short-term sig and get Mo to make a design for > shirts (melting clocks sounds a good idea). People who test, find > bugs, etc etc qualify for a drawing of stuff. > > Fedora-15 from feedback we have gotten on chrony, we go through the > plan of making chrony default (or not) and make ntpd optional. > > This is one alternative plan ( a bit slow but for security related > things probably better.). To speed it up we need to move get people > motivated towards 12/13 testing and feedback. If anyone wants to help with testing now - enable "statistics loopstats peerstats" in ntp.conf and "log measurements tracking" in chrony.conf - run each for few days or weeks in your typical workload and network conditions - send me the logs from /var/log/ntpstats and /var/log/chrony Or you can make your own analysis. The most important value is the offset reported in the 3rd field in loopstats and the last field in tracking.log. With gnuplot you can compare them (after concatenating the rotated logs): plot "tracking.log" using 7 with lines, "loopstats" using 3 with lines -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 10:54, Andrew Haley wrote: > On 05/10/2010 10:16 AM, Frank Murphy wrote: --snip-- >> >> Look earlier in the thread, >> how to mount a DVD as a repo has been demonstrated. > > Yes, it has. And it's more difficult that installing from the repos. > Which was my point. > > Andrew. But there is no need to change PackageKIt. PK, doesn't come in the equation (bringing it back to the o.post (bug) Compromise ;) add your dvd(media).repo to fedora-release-xx? May be worked in easier, maybe an RFE? Less messing, and those that need it have it. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Mon, 10 May 2010 02:09:45 -0400, Orcan wrote: > On Mon, May 10, 2010 at 1:27 AM, Chen Lei wrote: > > > > As I mentoned below, some packges need update to the > > lastest release badly to get rid of gtk+ 1.2. And some packages can safely > > retire from fedora, e.g. xmms. > > > > At that point you break a cult. xmms still has a stubbornly loyal fan > base (just go to #fedora and start talking about it). Why don't they take care of http://bugz.fedoraproject.org/xmms and additional tickets that have been "hidden" by EOL scripts already? > Unlike almost > everything else, xmms never fails to work. A smiley missing? > We don't want to get people > upset, do we? Well, seems to become a common trend in Fedora-land to do that more often. I support Chen Lei here, as offering a growing number of out-dated apps (both with regard to their maintenance/development state, look'n'feel, and unhandled problem reports) is neither beneficial to Fedora nor to the app itself. Those app users, who are left, will abandon the app [silently!] when they face problems, especially if those problems won't be fixed in Fedora. As has been mentioned, XMMS has various successors such as XMMS2 and Audacious. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Realtek 8192se on F12/F13
Hi, What is the status of support for the Realtek 8192se WiFi controller in F12 and F13? I see in some wiki page a reference to the Realtek website, at least for (stock) F12. Is this chipset in the meantime supported in the F12 kernel and/or will it be supported in F13? Thanks, -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On So, 2010-05-09 at 11:45 -0600, Stephen John Smoogen wrote: [...] > 1) Why chrony? Why not OpenNTPD [fill in the blank here] Dunno if this is important for this discussion but the portable version of OpenNTPD is stuck. The last portable version was made available in May 2006 while the OpenBSD version was released in November 2009. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, 2010-05-10 at 11:33 +0200, Matěj Cepl wrote: > Dne 10.5.2010 11:26, drago01 napsal(a): > > To have stuff just work. > > Go to http://senate.gov/ and ask your congressman to fix it. Otherwise > (for example if you don't have your congressman because you are not a > U.S. citizen), you can also try to move Red Hat's headquarters outside > of U.S. (although I am not sure, it would be enough, you would probably > ask its biggest clients to move). That's the wrong argument. We all know why we _can't_ make it just work, but that doesn't excuse us. Sorry to take a well-worn analogy, but if two guys are trying to sell you cars, and one doesn't have an engine, would the fact that the guy selling the car with no engine has a *really good and inarguable reason* why it doesn't have an engine make you buy that car? Hell no. You'd buy the car with the engine. Just because we have a *really good reason* we can't ship this stuff doesn't mean we are excused from the fact that it's a distinct negative for the use of our operating system as a general-purpose desktop operating system. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Mon, May 10, 2010 at 6:23 AM, Michael Schwendt wrote: > On Mon, 10 May 2010 02:09:45 -0400, Orcan wrote: > >> On Mon, May 10, 2010 at 1:27 AM, Chen Lei wrote: >> > >> > As I mentoned below, some packges need update to the >> > lastest release badly to get rid of gtk+ 1.2. And some packages can safely >> > retire from fedora, e.g. xmms. >> > >> >> At that point you break a cult. xmms still has a stubbornly loyal fan >> base (just go to #fedora and start talking about it). > > Why don't they take care of http://bugz.fedoraproject.org/xmms and > additional tickets that have been "hidden" by EOL scripts already? > That's because #fedora is a channel for users. Not many users can fix bugs. I consider the number of open bugs pretty low for a classic software. And from the magnitude of the bug ID numbers, I can tell that xmms is still popular. Why are they not fixed by the xmms maintainers? I don't know, and I wonder about that too. >> Unlike almost >> everything else, xmms never fails to work. > > A smiley missing? > Here :) >> We don't want to get people >> upset, do we? > > Well, seems to become a common trend in Fedora-land to do that more often. > I support Chen Lei here, as offering a growing number of out-dated apps > (both with regard to their maintenance/development state, look'n'feel, and > unhandled problem reports) is neither beneficial to Fedora nor to the app > itself. Those app users, who are left, will abandon the app [silently!] when > they face problems, especially if those problems won't be fixed in Fedora. > As has been mentioned, XMMS has various successors such as XMMS2 and > Audacious. > Fanaticism is a subjective concept. I am sure if it gets dropped, some people will start using other applications, some will resort to a 3rd party repo for xmms. Another subjective topic is taste; there is no point in debating about taste. I like the look'n'feel of gtk applications better than gtk2 ones. Other people might disagree. The reason why we still have xmms is a cumulative sum of subjective decisions. The benefit of it to Fedora is, well, people can exercise their freedom. :) Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Realtek 8192se on F12/F13
On 05/10/2010 12:38 PM, Jos Vos wrote: > What is the status of support for the Realtek 8192se WiFi > controller in F12 and F13? staging drivers are out of Fedora kernel, only crystalhd is included. see http://linuxwireless.org/en/users/Drivers/rtl819x -- «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.» -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Login problem after yum update
Hi, After I did yum update today morning(May 10'Th), I'm facing a weird login problem. None of the authentications - gdm login, su - user, or ssh from a remote host etc. are being resolved. Even passwd(1) segfaluts while changing password. I just can't login to the machine, in any way. did anyone had the same experience? Below is the yum history of the last update transaction. Thanks. --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails --- Loaded plugins: presto Transaction ID : 117 Begin time : Mon May 10 10:21:41 2010 Begin rpmdb: 1563:a1f216d158d5c5e3f6d87b0731a9603ce0697ddc End time :10:23:22 2010 (101 seconds) End rpmdb : 1563:1a2db0c1eeb38807145bad96a7cd9800ba241e9b User : pjp Return-Code: Success Transaction performed with: Installedrpm-4.7.2-1.fc12.i686 Installedyum-3.2.27-3.fc12.noarch Installedyum-presto-0.6.2-1.fc12.noarch Packages Altered: Updated evince-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated evince-djvu-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated evince-libs-2.28.2-1.fc12.i686 Update 2.28.2-2.fc12.i686 Updated libblkid-2.16.2-7.fc12.i686 Update2.16.2-9.fc12.i686 Updated libblkid-devel-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated libchamplain-0.4.3-1.fc12.i686 Update0.4.5-1.fc12.i686 Updated libchamplain-gtk-0.4.3-1.fc12.i686 Update0.4.5-1.fc12.i686 Updated libuuid-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated libuuid-devel-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 Updated nss-softokn-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated nss-softokn-devel-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated nss-softokn-freebl-3.12.4-15.fc12.i686 Update 3.12.4-17.fc12.i686 Updated perl-Digest-HMAC-1.01-21.fc12.noarch Update1.02-1.fc12.noarch Updated perl-URI-1.40-1.fc12.noarch Update1.54-1.fc12.noarch Updated python-fedora-0.3.18-1.fc12.noarch Update 0.3.20-1.fc12.noarch Updated python-virtinst-0.500.1-2.fc12.noarch Update 0.500.1-3.fc12.noarch Updated tigervnc-1.0.0-3.fc12.i686 Update1.0.1-1.fc12.i686 Updated util-linux-ng-2.16.2-7.fc12.i686 Update 2.16.2-9.fc12.i686 --- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 02:46 PM, Frank Murphy wrote: > Look earlier in the thread, > how to mount a DVD as a repo has been demonstrated. > > All it takes is adding method to wiki. > "How to use DVD\CD as repo > Frank, We are trying to make the process easier by making it a click through process. It doesn't help if you insist that it can be done manually. Everyone is already aware of that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login problem after yum update
On Mon, 2010-05-10 at 16:25 +0530, P J P wrote: > > Updated nss-softokn-3.12.4-15.fc12.i686 > Update 3.12.4-17.fc12.i686 > Updated nss-softokn-devel-3.12.4-15.fc12.i686 > Update 3.12.4-17.fc12.i686 > Updated nss-softokn-freebl-3.12.4-15.fc12.i686 > Update 3.12.4-17.fc12.i686 Downgrade this. https://bugzilla.redhat.com/show_bug.cgi?id=504949 -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 12:10, Rahul Sundaram wrote: --snip-- >> All it takes is adding method to wiki. >> "How to use DVD\CD as repo >> > > Frank, > > We are trying to make the process easier by making it a click through > process. It doesn't help if you insist that it can be done manually. > Everyone is already aware of that. > > Rahul > Hi Rahul, Check my reply from 11:04 http://lists.fedoraproject.org/pipermail/devel/2010-May/135944.html Should work for F13+ even for new users. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Dne 10.5.2010 12:48, Adam Williamson napsal(a): > That's the wrong argument. We all know why we _can't_ make it just work, > but that doesn't excuse us. Sorry to take a well-worn analogy, but if > two guys are trying to sell you cars, and one doesn't have an engine, > would the fact that the guy selling the car with no engine has a *really > good and inarguable reason* why it doesn't have an engine make you buy > that car? Hell no. You'd buy the car with the engine. Sure, it is no excuse, and a) I was not the one trying to make Fedora into "general-purpose desktop OS", b) if this is really really important to you, there is enough Linux distros where you can spend your effort. I think we have nothing else to say, so let's just not saying that. Matěj -- Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must realise that once the signal is given, he is no longer the master of policy but the slave of unforeseeable and uncontrollable events. -- Winston Churchill, 1930 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 04:48 PM, Frank Murphy wrote > Hi Rahul, > Check my reply from 11:04 > http://lists.fedoraproject.org/pipermail/devel/2010-May/135944.html > Should work for F13+ > even for new users. > What you describe is not as easy as enabling any other repository and there is no reason it should not be. We can make it easier and we are close to that. Just a single step needs to be complete. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning Calibre
Hello, I don't have the time to maintain calibre any more so I'm orphaning it. I fell behind on bugzilla, too. Beware, it requires a lot of love. Upstream moves very fast. Releases happen weekly and there are always new features and sometimes new bundled libs (yeah...). Whoever picks this up, feel free to contact me with questions. Thanks! -- Ionuț -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 12:25, Rahul Sundaram wrote: --snip-- >> http://lists.fedoraproject.org/pipermail/devel/2010-May/135944.html >> Should work for F13+ >> even for new users. >> > > What you describe is not as easy as enabling any other repository How is it not as easy? fedora-release*rpm contains repos and keys basically. is repodir="/media/Fedora N arch" that difficult. Which PK(F13) will enable\disable if DVD Mounted and > there is no reason it should not be. We can make it easier and we are > close to that. So can above. Just a single step needs to be complete. > At the moment it looks like a long step. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, 2010-05-10 at 13:21 +0200, Matěj Cepl wrote: > Dne 10.5.2010 12:48, Adam Williamson napsal(a): > > That's the wrong argument. We all know why we _can't_ make it just work, > > but that doesn't excuse us. Sorry to take a well-worn analogy, but if > > two guys are trying to sell you cars, and one doesn't have an engine, > > would the fact that the guy selling the car with no engine has a *really > > good and inarguable reason* why it doesn't have an engine make you buy > > that car? Hell no. You'd buy the car with the engine. > > Sure, it is no excuse, and > > a) I was not the one trying to make Fedora into "general-purpose desktop > OS", > b) if this is really really important to you, there is enough Linux > distros where you can spend your effort. > > I think we have nothing else to say, so let's just not saying that. I think we're arguing the same point - that that is not where Fedora's strengths lie. But it's important not to get lost in the knee-jerk rationalizations and point-scoring when it comes to discussing Fedora compared to other OSes or distributions, because then it starts to sound like we _are_ trying to argue that people who'd be better off running something else should just run Fedora and suck up the inconveniences. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 05:06 PM, Frank Murphy wrote: > On 10/05/10 12:25, Rahul Sundaram wrote: > --snip-- > >>> http://lists.fedoraproject.org/pipermail/devel/2010-May/135944.html >>> Should work for F13+ >>> even for new users. >>> >>> >> What you describe is not as easy as enabling any other repository >> > How is it not as easy? > It is not a click through process. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 12:48, Rahul Sundaram wrote: --snipp-- >>> >> How is it not as easy? >> > > It is not a click through process. > > Rahul How can you not click if it shows up in gnome-packagekit-extra? (admin/software/sources) Will not the packages be availabel in add\remove? They are on my tests. No user intervention required. (allow for the fact my test repo not incl. in f*release*) Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Mon, 10 May 2010 06:49:23 -0400, Orcan wrote: > >> At that point you break a cult. xmms still has a stubbornly loyal fan > >> base (just go to #fedora and start talking about it). > > > > Why don't they take care of http://bugz.fedoraproject.org/xmms and > > additional tickets that have been "hidden" by EOL scripts already? > > > > That's because #fedora is a channel for users. Not many users can fix bugs. Users -- particulary those from "a stubbornly loyal fan base" as you call it -- could and should become bug triagers and testers and give good support to the "xmms*" packages in bugzilla. > I consider the number of open bugs pretty low for a classic software. > And from the magnitude of the bug ID numbers, I can tell that xmms is > still popular. Doubtful. It's still installed by some people, because web pages (including very old HOWTOs/FAQs) refer to it. In other words, it's still being advertised in questionable ways, e.g. as one way to add MP3 support to Fedora/RHL or as an app similar to Winamp. There are users, who give it a try (and some of them may have used it before), but it would be adventurous to conclude that they belong to a user base that would make the packages "popular". It could also be that those bug reporters don't return, and they won't tell in bugzilla. It's likely that once they see themselves forced to look into a different audio player, they won't use XMMS ever again. One can only hope that with the majority of default installs, a different audio player is available and won't give Fedora users a false impression. Such as that XMMS would be considered sort of a "standard" audio solution for Fedora. > Why are they not fixed by the xmms maintainers? I don't know, and I > wonder about that too. There is a pattern -- not limited to xmms*. Package owners don't respond in bugzilla, bug reporters don't add any other comment, EOL scripts eventually close the tickets, package owners and bug reporters don't reopen the tickets. What do they do? Do they live with work-arounds? http://bugzilla.redhat.com/525277 reported on 2009-09-23 - it's the PulseAudio volume decrease problem that affects xmms-pulse, too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 05:22 PM, Frank Murphy wrote: > On 10/05/10 1 > How can you not click if it shows up in > gnome-packagekit-extra? > (admin/software/sources) > > Will not the packages be availabel in add\remove? > > They are on my tests. > > No user intervention required. > (allow for the fact my test repo not incl. in f*release*) > DVD repo does NOT show up automatically in the repository listing when you install gnome-packagekit-extras. There are manual fiddling involved in setting up a repo. That shouldn't be necessary. Try not to derail the discussions, please. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 13:02, Rahul Sundaram wrote: --snipp-- > > DVD repo does NOT show up automatically in the repository listing when > you install gnome-packagekit-extras. I said if DVD.repo is releases with fedora-release* it *will* show up in default There are manual fiddling involved > in setting up a repo. No, as above. That shouldn't be necessary. Try not to derail > the discussions, please. Please read first, before judging. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 05:36 PM, Frank Murphy wrote: > On 10/05/10 13:02, Rahul Sundaram wrote: > --snipp-- > > >> DVD repo does NOT show up automatically in the repository listing when >> you install gnome-packagekit-extras. >> > I said if DVD.repo is releases with fedora-release* > it *will* show up in defaul > DVD repo is clearly not part of fedora-release at the moment. We are talking about the current reality. If you file a RFE and get fedora-release updated, then it will become easier but that is not the case now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: planet.fedoraproject.org blog addition weirdness
On Mon, 10 May 2010, Peter Lemenkov wrote: > Hello! > > Not sure that people are still unaware of that issue, but, anyway, > here is my problem: I added RSS-filter to my blog, to properly sort > out off-topic or unappropriate content from my diary and make it > suitable for inclusion into Fedoraplanet, and listed address of new > filtered RSS at my ~/.planet file (cat /home/fedora/peter/.planet for > details and compare with the address of feed, listed at the > Fedoraplanet page). But, instead of using this filtered feed, > planet.fedoraproject.org switches to unfiltered original RSS. > Looking at the planet config it is only storing the old cached blog entry until it ages out. In the future please post these items to a fedora infrastructure ticket. https://fedorahosted.org/fedora-infrastructure/ thanks, -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Login problem after yum update
--- On Mon, 10/5/10, David Woodhouse wrote: > Downgrade this. > https://bugzilla.redhat.com/show_bug.cgi?id=504949 Hey thanks, it worked. Thank you. --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 10/05/10 13:10, Rahul Sundaram wrote: --snip-- > > DVD repo is clearly not part of fedora-release at the moment. We are > talking about the current reality. If you file a RFE and get > fedora-release updated, then it will become easier but that is not the > case now. > > Rahul Neither is fixing the RFE for PK, as it's notabug. But I firmly believe creting a text file, is the easier\maybe safer challenge. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo was Re: How this bug can come out of its dead-end? Any suggestions?!
On 05/10/2010 05:43 PM, Frank Murphy wrote: > Neither is fixing the RFE for PK, as it's notabug. > But I firmly believe > creting a text file, is the easier\maybe safer challenge. > PackageKit developers disagree with you. Since they are the ones doing the work involved, their opinion has more weight. Besides a static repo file is less flexible than the ability for PackageKit to handle media dynamically. Meanwhile, you can push for the solution you recommend by filling a RFE against fedora-release. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo
On 10/05/10 13:28, Rahul Sundaram wrote: > > PackageKit developers disagree with you. Since they are the ones doing > the work involved, their opinion has more weight. Besides a static repo > file is less flexible than the ability for PackageKit to handle media > dynamically. Meanwhile, you can push for the solution you recommend by > filling a RFE against fedora-release. > > Rahul RFE filed against f*release https://bugzilla.redhat.com/show_bug.cgi?id=590658 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100510 changes
Compose started at Mon May 10 08:15:15 UTC 2010 Broken deps for i386 -- almanah-0.7.2-1.fc13.i686 requires libedataserver-1.2.so.11 almanah-0.7.2-1.fc13.i686 requires libedataserverui-1.2.so.8 anjal-0.3.2-2.fc14.i686 requires libedataserver-1.2.so.11 anjal-0.3.2-2.fc14.i686 requires libcamel-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libcamel-provider-1.2.so.14 anjal-0.3.2-2.fc14.i686 requires libedataserverui-1.2.so.8 clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 dcbd-0.9.19-3.fc14.i686 requires libconfig.so.8 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-provider-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libcamel-1.2.so.14 evolution-couchdb-0.3.2-2.fc13.i686 requires libedataserver-1.2.so.11 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 glabels-2.2.7-1.fc14.i686 requires libedataserver-1.2.so.11 gnome-launch-box-0.4-17.fc13.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gpsdrive-2.10-0.5.pre7.fc13.i686 requires libgps.so.18 1:libopensync-plugin-evolution2-0.22-3.fc13.i686 requires libedataserver-1.2.so.11 pygsl-0.9.5-1.fc14.i686 requires gsl = 0:1.13 pygsl-devel-0.9.5-1.fc14.i686 requires gsl-devel = 0:1.13 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.9-1.fc12.i686 requires libgps.so.18 Broken deps for x86_64 -- almanah-0.7.2-1.fc13.x86_64 requires libedataserverui-1.2.so.8()(64bit) almanah-0.7.2-1.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-provider-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserverui-1.2.so.8()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libcamel-1.2.so.14()(64bit) anjal-0.3.2-2.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) clutter-gtkmm-0.9.4-3.fc12.i686 requires libcluttermm-0.9.so.3 clutter-gtkmm-0.9.4-3.fc12.x86_64 requires libcluttermm-0.9.so.3()(64bit) clutter-gtkmm-devel-0.9.4-3.fc12.i686 requires pkgconfig(cluttermm-0.9) clutter-gtkmm-devel-0.9.4-3.fc12.x86_64 requires pkgconfig(cluttermm-0.9) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) dcbd-0.9.19-3.fc14.x86_64 requires libconfig.so.8()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-provider-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcouchdb-glib-1.0.so.1()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcamel-1.2.so.14()(64bit) evolution-couchdb-0.3.2-2.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) glabels-2.2.7-1.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-launch-box-0.4-17.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-telepathy-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gpsdrive-2.10-0.5.pre7.fc13.x86_64 requires libgps.so.18()(64bit) 1:libopensync-plugin-evolution2-0.22-3.fc13.x86_64 requires libedataserver-1.2.so.11()(64bit) pygsl-0.9.5-1.fc14.x86_64 requires gsl = 0:1.13 pygsl-devel-0.9.5-1.fc14.i686 requires gsl-devel = 0:1.13 pygsl-devel-0.9.5-1.fc14.x86_64 requires gsl-devel = 0:1.13 qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) >= 0:1.2.4 vfrnav-0.4-1.fc13.x86_64 requires libgps.so.18()(64bit) vifir-0.4-2.fc14.x86_64 requires libgps.so.18()(64bit) viking-0.9.9-1.fc12.x86_64 requires libgps.so.18()(64bit) New package glyphtracer Program for creating fonts from images New package python-ipaddr A python library for working with IP addresses, both IPv4 and IPv6 New package rubygem-amqp AMQP client implementation in Ruby/EventMachine Updated Packages: NetworkManager-0.8.0-13.git20100509.fc14 * Sun May 09 2010 Dan Williams - 0.8-13.git20100509 - core: restore initial accept_ra value for IPv6 ignored connections (rh #588619) - bluetooth: fix bad timeout on PAN conn
Re: Realtek 8192se on F12/F13
On Mon, May 10, 2010 at 12:38:15PM +0200, Jos Vos wrote: > Hi, > > What is the status of support for the Realtek 8192se WiFi > controller in F12 and F13? > > I see in some wiki page a reference to the Realtek website, > at least for (stock) F12. > > Is this chipset in the meantime supported in the F12 kernel > and/or will it be supported in F13? https://bugzilla.redhat.com/show_bug.cgi?id=558337 Short answer, not supported yet. I build the wireless driver on my netbook whenever updating the vendor driver with the patch attached here: https://bugzilla.redhat.com/show_bug.cgi?id=558337#c4 It's a bit of a pain, but once built it works great. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo
/*Frank Murphy */ wrote on 05/10/2010 5:11:13 PM +0450: On 10/05/10 13:28, Rahul Sundaram wrote: PackageKit developers disagree with you. Since they are the ones doing the work involved, their opinion has more weight. Besides a static repo file is less flexible than the ability for PackageKit to handle media dynamically. Meanwhile, you can push for the solution you recommend by filling a RFE against fedora-release. Rahul RFE filed against f*release https://bugzilla.redhat.com/show_bug.cgi?id=590658 Thanks for the RFE, and just to make you sure that I am in touch with the bug you can see: http://hedayatvk.wordpress.com/2009/02/22/using-fedora-dvd-not-a-solution-but-a-bit-better/ But it is still not that good. And the implementation by Muayyad handles removable media much better. As it is 99% complete, it is really reasonable to get it 100% and make many users happy. Anyway, thinking about the problem with DeviceKit system policies, I really feel that the current situation is flawed: a process running as root is able to mount a device either by calling mount system call or by running the mount command, but it is unable to mount a device using DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it should be fixed anyway. Any comments? Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo
On Mon, 2010-05-10 at 17:58 +0430, Hedayat Vatankhah wrote: > > Anyway, thinking about the problem with DeviceKit system policies, I > really feel that the current situation is flawed: a process running as > root is able to mount a device either by calling mount system call or > by running the mount command, but it is unable to mount a device using > DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it > should be fixed anyway. Any comments? > Can you explain this or point to a bug ? I'm positive that this is supposed to work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo
On 10/05/10 14:28, Hedayat Vatankhah wrote: --snip-- > > Anyway, thinking about the problem with DeviceKit system policies, I > really feel that the current situation is flawed: a process running as > root is able to mount a device either by calling mount system call or by > running the mount command, but it is unable to mount a device using > DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it > should be fixed anyway. Any comments? > Policy, I can't help with. But, I summise each process has it pros and cons, as do most foss projects, that is why there are various apps to do the same\similar job. Frank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Sun, May 9, 2010 at 4:15 PM, Ryan Rix wrote: > Here is how I see this: The user installs their system for the first time, > they set their clock using NTP while they have the connection to the > internet when they installed their packageset/updates. Now they have an > accurate clock. > > How much drift can happen that each and every time they connect to the > internet, even if it's only for five minutes, would they need to resync > their clock? I have NTP disabled altogether on this machine, and since > I've installed it, it's still within about 5 seconds of my mother's > Windows machine which _does_ have ntp disabled. The amount of drift you may see is highly dependant on your hardware. A mere 1% frequency offset will gain or lose almost two hours per week. Arguably a system which drifts unacceptably is broken yet depending on your definition of unacceptably all of the available PC hardware is broken. And a constant frequency offset like that is trivially fixable. My last laptop lost a minute or two per week of uncorrected operation. At the time I was travelling a lot— and ending up habitually a late for a conference calls would remind me to unwedge it. The current laptop has, fortunately, only lost 2 seconds since Friday. Two headless systems of mine with "good" clocks in a temperature controlled environment show drift of 16 and 37 ppm (0.7 and 1.6 minutes per month respectively). A typical decent crystal oscillator simply running 10 deg C off its design temperature might be ~20 ppm off on its own. > I find that having NTP enabled in most cases for mobile systems is simply > unnecessary; there is a large (I would say upwards of 95% in my most > unscientific guessings) chance that these users aren't going to be doing > anything which requires their clocks to be synced with any amount of > precision. And if they are, they should _know_ that and be able to set up > a tool (whether it is NTP or Crony) themselves. > > Imo the use cases for having a constantly synced-to-the-second clock are > minimal at best. "I find that having non-root accounts enabled in most cases for mobile systems is simply unnecessary"(...) But really— having accurate time is important for all systems: Have you never had the experience of trying to debug a networked system only to eventually discover that there was a few seconds clock skew confusing your troubleshooting? At least in my world there are increasingly only two kinds of machines: mobile devices and headless servers, in that context what you're saying is that only servers need correct time, and I think that is quite wrong. Errors at the level of minutes are easily accumulated on common hardware and will impact human affairs. Sub-minute errors will frustrate technical troubleshooting— confusing the mutual ordering of events between systems even when the timestamps look quite different. An inaccurate clock even reduces user privacy on the internet as it makes hosts more easily distinguishable when the client's time is available over the network. If timekeeping really hard to fix on the lossy hardware we use I might buy an argument that fixing it wasn't worth the cost, but fortunately it is easily fixed to sub-second levels by running a simple daemon. Though, unfortunately, the NTP package will often fail to do anything useful when used on the increasingly common configurations with highly intermittent network connectivity. Perhaps you may not care about these things— but other people do for good reason, and you ought not oppose their efforts to advance the usefulness of the system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
/*Adam Williamson */ wrote on 05/10/2010 3:18:06 PM +0450: On Mon, 2010-05-10 at 11:33 +0200, Matěj Cepl wrote: Dne 10.5.2010 11:26, drago01 napsal(a): To have stuff just work. Go to http://senate.gov/ and ask your congressman to fix it. Otherwise (for example if you don't have your congressman because you are not a U.S. citizen), you can also try to move Red Hat's headquarters outside of U.S. (although I am not sure, it would be enough, you would probably ask its biggest clients to move). That's the wrong argument. We all know why we _can't_ make it just work, but that doesn't excuse us. Sorry to take a well-worn analogy, but if two guys are trying to sell you cars, and one doesn't have an engine, would the fact that the guy selling the car with no engine has a *really good and inarguable reason* why it doesn't have an engine make you buy that car? Hell no. You'd buy the car with the engine. Just because we have a *really good reason* we can't ship this stuff doesn't mean we are excused from the fact that it's a distinct negative for the use of our operating system as a general-purpose desktop operating system. Just my 0.2 cents in this regard: well, we have a car without engine, and a suitable engine is built somewhere which we can't use. But, I wonder why there is nobody to pick our car and the engine and sell the car with engine to people who don't want to do that themselves? RPMFusion is a very well-known engine builder! While there were/are some efforts to ship our car with its engine, there is no well-known Fedora remix which contains the extra stuff (it is probably because most of the current users have already adopted with using rpmfusion if they want it). If we can come up with enough people to provide and maintain a Fedora remix for awhile, it can become well-known and something which is always there, so we can point beginners to that one instead of other distros if they want such a distro. We (I and a very few others) are going to create a remix, but our current target users are a bit more restricted (mostly because of lack of manpower) (Also we are currently targeting a DVD installation media rather than live media). But if there are some other interested people out there, we can go for the mentioned remix (and we will probably base our custom remix on that). Good luck, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 10/05/10 15:05, Hedayat Vatankhah wrote: --snipp-- http://omega.dgplug.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Realtek 8192se on F12/F13
On Mon, 2010-05-10 at 12:38 +0200, Jos Vos wrote: > Hi, > > What is the status of support for the Realtek 8192se WiFi > controller in F12 and F13? > > I see in some wiki page a reference to the Realtek website, > at least for (stock) F12. > > Is this chipset in the meantime supported in the F12 kernel > and/or will it be supported in F13? > > Thanks, As far as I know, the 8192se is yet to enter the main kernel tree. For now, I'm using the latest version of realtek.com [1] (it builds cleanly on F12), which more-or-less works. (Performance is a bit slow, but the connection is solid) - Gilboa [1] http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
Patrice Dumas wrote: > * xdialog is build twice, once agains gtk+ and then against Gtk2. I think > it would be nice to keep it that way, though you could also convince the > current maintainer to keep only the Gtk2 stuff. also xdialog seems to be > pretty dead upstream too, though I still haven't seen a perfect > substitute (zenity is close, but not compatible). Not to mention that zenity drags in quite a few dependencies which, for just a dialog box, I don't need nor want (zenity -> libnotify -> xfce libs). --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On ۱۰/۰۵/۱۰ 06:38, Frank Murphy wrote: > On 10/05/10 15:05, Hedayat Vatankhah wrote: > --snipp-- > > http://omega.dgplug.org/ > Thanks, I thought that the project is dead (IIRC, it was not provided for F11 last time I checked, but apparently I'm wrong). I'll contact him to see if he is interested in providing DVD's too. Thanks again, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire glib and gtk+ 1.2 from rawhide?
On Mon, 2010-05-10 at 00:04 -0700, Ryan Rix wrote: > > That doesn't mean we should throw it to the wayside. If it works, it works. > As > long as someone is there to maintain it, let them maintain it. If the > maintainer is willing to keep it going, who cares whether it's in the distro? > In fact, why is this discussion occuring without the gtk+ maintainer > involved? > You'd think he'd have a say in it before the crowd wantonly decided to drop > his packages. If you want my opinion as the upstream GTK+ maintainer (thankfully, I got out of being the gtk+ package maintainer a few years ago), I don't particularly care if some people enjoy maintaining long-obsolete software from the 90s in some dark corner of the repository, but I certainly don't want to see any of it close to the default install. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
On Mon, May 10, 2010 at 2:45 AM, Yaakov M. Nemoy wrote: > On Sun, May 09, 2010 at 01:15:03PM -0700, Ryan Rix wrote: >> I find that having NTP enabled in most cases for mobile systems is simply >> unnecessary; there is a large (I would say upwards of 95% in my most >> unscientific guessings) chance that these users aren't going to be doing >> anything which requires their clocks to be synced with any amount of >> precision. And if they are, they should _know_ that and be able to set up >> a tool (whether it is NTP or Crony) themselves. > > I guess you've never had to debug Kerberos before. Luckily, neither > have i, so i'm not one to talk. There are a number of apps that are I have. The users who end up with the most problems are laptop users. I wonder if windows basically does a forced 'get my time right from sources' when it awakes as I rarely had issues with AD/windows boxes on it... but other OS's have that problem. I believe that SSL will also have problems in some use cases if the clocks are too off.. but that might have been Kerb related also. > pretty dependent on the clocks being in sync with each other to a > degree. Granted, not everyone is running all those apps, but then it > begs the question why Fedora provides so much out of the box in the > first place. Let's assume that NTP is probably a good thing to support > out of the box on most machines, assuming we can support it right in > the first place. > > -Yaakov > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 4:05 PM, Hedayat Vatankhah wrote: > > Adam Williamson wrote on 05/10/2010 3:18:06 PM +0450: > > On Mon, 2010-05-10 at 11:33 +0200, Matěj Cepl wrote: > > > Dne 10.5.2010 11:26, drago01 napsal(a): > > > To have stuff just work. > > > Go to http://senate.gov/ and ask your congressman to fix it. Otherwise > (for example if you don't have your congressman because you are not a > U.S. citizen), you can also try to move Red Hat's headquarters outside > of U.S. (although I am not sure, it would be enough, you would probably > ask its biggest clients to move). > > > That's the wrong argument. We all know why we _can't_ make it just work, > but that doesn't excuse us. Sorry to take a well-worn analogy, but if > two guys are trying to sell you cars, and one doesn't have an engine, > would the fact that the guy selling the car with no engine has a *really > good and inarguable reason* why it doesn't have an engine make you buy > that car? Hell no. You'd buy the car with the engine. > > Just because we have a *really good reason* we can't ship this stuff > doesn't mean we are excused from the fact that it's a distinct negative > for the use of our operating system as a general-purpose desktop > operating system. > > > Just my 0.2 cents in this regard: well, we have a car without engine, and a > suitable engine is built somewhere which we can't use. But, I wonder why > there is nobody to pick our car and the engine and sell the car with engine > to people who don't want to do that themselves? > RPMFusion is a very well-known engine builder! While there were/are some > efforts to ship our car with its engine, there is no well-known Fedora remix > which contains the extra stuff (it is probably because most of the current > users have already adopted with using rpmfusion if they want it). If we can > come up with enough people to provide and maintain a Fedora remix for > awhile, it can become well-known and something which is always there, so we > can point beginners to that one instead of other distros if they want such a > distro. > We (I and a very few others) are going to create a remix, but our current > target users are a bit more restricted (mostly because of lack of manpower) > (Also we are currently targeting a DVD installation media rather than live > media). But if there are some other interested people out there, we can go > for the mentioned remix (and we will probably base our custom remix on > that). Trademarks ... you can't call it Fedora anymore and would effectively be a different distro. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
On Monday 10 May 2010 11:18:26 am Itamar Reis Peixoto wrote:
> Author: itamarjp
>
> Update of /cvs/pkgs/rpms/redir/EL-6
> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv20463/EL-6
>
> Modified Files:
> import.log redir.spec
> Log Message:
> - fix building for EL-6
>
>
>
> Index: import.log
> ===
> RCS file: /cvs/pkgs/rpms/redir/EL-6/import.log,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -p -r1.2 -r1.3
> --- import.log25 Sep 2009 22:51:24 - 1.2
> +++ import.log10 May 2010 16:18:25 - 1.3
> @@ -1,2 +1,3 @@
> redir-2_2_1-3_fc11:HEAD:redir-2.2.1-3.fc11.src.rpm:1239099294
> redir-2_2_1-5_fc12:HEAD:redir-2.2.1-5.fc12.src.rpm:1253918869
> +redir-2_2_1-6_fc13:EL-6:redir-2.2.1-6.fc13.src.rpm:1273508246
>
>
> Index: redir.spec
> ===
> RCS file: /cvs/pkgs/rpms/redir/EL-6/redir.spec,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -p -r1.3 -r1.4
> --- redir.spec25 Sep 2009 22:51:24 - 1.3
> +++ redir.spec10 May 2010 16:18:26 - 1.4
> @@ -1,6 +1,6 @@
> Name: redir
> Version:2.2.1
> -Release:5%{?dist}
> +Release:6%{?dist}
> Summary:Redirect TCP connections
>
> Group: Applications/Internet
> @@ -13,8 +13,10 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
> BuildRequires: tcp_wrappers-devel
> %endif
>
> -%if 0%{?rhel}
> +%if 0%{?rhel} < 5
> BuildRequires: tcp_wrappers
> +%else
> +BuildRequires: tcp_wrappers-devel
> %endif
this fix is incorrect. because "%if 0%{?rhel} < 5" becomes if 0<5 on fedora
since rhel is undefined. you need to add a check for fedora also.
>
>
> @@ -118,6 +120,9 @@ rm -rf $RPM_BUILD_ROOT
> %{_mandir}/man1/%{name}.1*
>
> %changelog
> +* Mon May 10 2010 Itamar Reis Peixoto - 2.2.1-6
> +- fix building for EL-6
> +
> * Fri Sep 25 2009 Itamar Reis Peixoto - 2.2.1-5
> - start building for EPEL
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
EL-6 mono build
mono requires bootstrapping ? http://koji.fedoraproject.org/koji/buildinfo?buildID=172787 how to build it ? -- Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EL-6 mono build
On Mon, May 10, 2010 at 6:50 PM, Itamar Reis Peixoto wrote: > mono requires bootstrapping ? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=172787 > > how to build it ? Hopefully you can disable enough features on one package such that it will build so it can then become a dependency to the next package. Then reenable the missing features on the original package. You just bump the .spec release at each build. Steve. > > > > -- > > > Itamar Reis Peixoto > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Steve Traylen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outdated Wine versions in koji?
On 05/10/2010 04:01 AM, Zoltan Boszormenyi wrote: > I guess the legal problem(s) may come from the fact that > newer Wine has cut out its own MP3 decoder and instead, > it uses dlopened libmpg123. How does it differ from the > DVD playing situation? Xine, MPlayer, etc. uses libdvdcss > via dlopen if available. And the user, not the distributor adds > the decoding facility... This is not the legal issue at issue here. As you've noted, dlopening libraries is not a problem for Fedora (including those troublesome libraries is the problem). ~spot P.S. Please don't ask me what the legal issue is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On 05/10/2010 08:20 PM, Hedayat Vatankhah wrote: > > On ۱۰/۰۵/۱۰ 06:38, Frank Murphy wrote: > >> On 10/05/10 15:05, Hedayat Vatankhah wrote: >> --snipp-- >> >> http://omega.dgplug.org/ >> >> > Thanks, I thought that the project is dead (IIRC, it was not provided > for F11 last time I checked, but apparently I'm wrong). I'll contact him > to see if he is interested in providing DVD's too. > The Fedora 12 image is a Live image of 1.3 GB size. As the FAQ would tell you, I am not interested in maintaining more variants but I welcome you to contribute if you are interested in maintaining them. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, 2010-05-10 at 07:28 +0300, Gilboa Davara wrote: > I do not agree that that working with zero community input is the way to > achieve a working compromise. (And input does not equal vote) > What makes you think that no community input is considered? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 2:48 AM, Adam Williamson wrote: > That's the wrong argument. We all know why we _can't_ make it just work, > but that doesn't excuse us. You are right. The answer is clearly to export US legal rules to the rest of the world so we can have an equally unfriendly playing field. > Sorry to take a well-worn analogy, but if > two guys are trying to sell you cars, and one doesn't have an engine, > would the fact that the guy selling the car with no engine has a *really > good and inarguable reason* why it doesn't have an engine make you buy > that car? Hell no. You'd buy the car with the engine. 1) Are we talking about purchased products.. where money changes hands? 2) There are laws concerning the purchasing of illicit goods..stolen engines are no different. 3) OEM Ubuntu customers _are_ _paying_ licensing fees for the stuff that end users can find for free in Ubuntu preinstalls. http://www.h-online.com/open/news/item/Canonical-clarifies-its-H-264-licence-993182.html The reality is Canonical's customers are not end-users. Canonical's customers are OEMs. general Ubuntu interest, and the media hype that can produce in places like twitter, are leveraged to entice the target audience..the OEMs...to contract with Canonical. > Just because we have a *really good reason* we can't ship this stuff > doesn't mean we are excused from the fact that it's a distinct negative > for the use of our operating system as a general-purpose desktop > operating system Yes, principled approaches to product production can look like a negative in the short term. You want an analogy proprietary media is the computing equivalent of ready to eat,mass marketed processed convenience food. Its the software version of junkfood and soda and pizza rolls and dinosaur shaped chicken nuggets. It's unsustainable, and unhealthand tastes so very good. So even though sugary salty brightly colored food-like cubes are clearly popular and in demand.. is catering to this in the best interest of anyone? Some people don't think so and choose to support a better way to produce and distribute food...going as far as to limit what they choose to consume in supporting an overall more sustainable pattern of behavior. Fedora is that better, sustainable way. It's not elitist, everyone is welcome to participate with the understanding that part of making that choice can involve the giving up some conveniences in the short term in the commitment to the larger goals of a sustainable free software ecosystem. If your not comfortable with that expectation, then we'll warmly let you pass through on your way to another community that will better cater to your desires. But we aren't going to cater to unsustainable convenience food. And if that principled approach is not the most popular.. it doesn't mean its worth giving up. We need to shake loose the idea that being the most popular matters. What I want is contributor targets to shoot for. I want a clear vision by which we can recruit contributors...not users. Maybe Mike is right and we are going to see a big dip in users when RHEL 6 comes out and people junk to that stable offering. And where he sees a negative. I see success. We position this project as leading edge. If people have been using Fedora as a forerunner to RHEL 6 and now find they want long term stability...then great. We did exactly what we said we would do for those people and now their needs are such that a stable base makes mroe sense. We are NOT all things to all people. Its GOOD to see people who need stability moving to RHEL instead of asking us to be that as well as leading edge. And since we don't promise to provide everything to everyone then I fully expect to see a cyclic process in our contributor and user base. I expect to see periods of die-off as well as growrth. I expect that in any system which aims to be sustainable. The issue for me is are we prepared for the cycle of renewal. Are we prepared to recruit contributors into participating into new leading edge directions? -jef"Would you like fries with that?"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 8:11 PM, Jeff Spaleta wrote: > On Mon, May 10, 2010 at 2:48 AM, Adam Williamson wrote: >> That's the wrong argument. We all know why we _can't_ make it just work, >> but that doesn't excuse us. > > You are right. The answer is clearly to export US legal rules to the > rest of the world so we can have an equally unfriendly playing field. No thanks ;) Fix what is broken and not break everything else so that you can pretend that it isn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
Jeff Spaleta (jspal...@gmail.com) said: > On Mon, May 10, 2010 at 2:48 AM, Adam Williamson wrote: > > That's the wrong argument. We all know why we _can't_ make it just work, > > but that doesn't excuse us. > > You are right. The answer is clearly to export US legal rules to the > rest of the world so we can have an equally unfriendly playing field. That solution boils down to 'contact your senator', as well. Or possibly 'contact your local general.' Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upcoming Schedule Tasks
Start End Name Tue 04-May Tue 18-May Final Infrastructure Change Freeze Tue 11-May Tue 11-May Fedora 13 Final Go/No-Go Meeting (20:00 EST) Wed 12-May Wed 12-May Fedora 13 Final Release Readiness Meeting Thu 13-May Thu 13-May Start Stage & Sync RC to Mirrors Thu 13-May Tue 18-May Stage & Sync RC to Mirrors Fri 14-May Fri 14-May Final Export Control Reporting Tue 18-May Tue 18-May Final (GA) Release -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 10:36 AM, drago01 wrote: > Fix what is broken and not break everything else so that you can > pretend that it isn't. Think of that opening remark as a modern twitter-friendly version of "A Modest Proposal" given in the very same spirit of Jonathon Swift's original. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
On Mon, 10 May 2010 11:37:16 -0500
Dennis Gilmore wrote:
> On Monday 10 May 2010 11:18:26 am Itamar Reis Peixoto wrote:
> > Author: itamarjp
> >
> > Update of /cvs/pkgs/rpms/redir/EL-6
> > In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv20463/EL-6
> >
> > Modified Files:
> > import.log redir.spec
> > Log Message:
> > - fix building for EL-6
> >
> >
> >
> > Index: import.log
> > ===
> > RCS file: /cvs/pkgs/rpms/redir/EL-6/import.log,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -p -r1.2 -r1.3
> > --- import.log 25 Sep 2009 22:51:24 - 1.2
> > +++ import.log 10 May 2010 16:18:25 - 1.3
> > @@ -1,2 +1,3 @@
> > redir-2_2_1-3_fc11:HEAD:redir-2.2.1-3.fc11.src.rpm:1239099294
> > redir-2_2_1-5_fc12:HEAD:redir-2.2.1-5.fc12.src.rpm:1253918869
> > +redir-2_2_1-6_fc13:EL-6:redir-2.2.1-6.fc13.src.rpm:1273508246
> >
> >
> > Index: redir.spec
> > ===
> > RCS file: /cvs/pkgs/rpms/redir/EL-6/redir.spec,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -p -r1.3 -r1.4
> > --- redir.spec 25 Sep 2009 22:51:24 - 1.3
> > +++ redir.spec 10 May 2010 16:18:26 - 1.4
> > @@ -1,6 +1,6 @@
> > Name: redir
> > Version:2.2.1
> > -Release:5%{?dist}
> > +Release:6%{?dist}
> > Summary:Redirect TCP connections
> >
> > Group: Applications/Internet
> > @@ -13,8 +13,10 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
> > BuildRequires: tcp_wrappers-devel
> > %endif
> >
> > -%if 0%{?rhel}
> > +%if 0%{?rhel} < 5
> > BuildRequires: tcp_wrappers
> > +%else
> > +BuildRequires: tcp_wrappers-devel
> > %endif
>
> this fix is incorrect. because "%if 0%{?rhel} < 5" becomes if 0<5
> on fedora since rhel is undefined. you need to add a check for fedora
> also.
Or you can just use:
BuildRequires: /usr/include/tcpd.h
which works everywhere and you don't need conditionals.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, May 10, 2010 at 8:56 PM, Jeff Spaleta wrote: > On Mon, May 10, 2010 at 10:36 AM, drago01 wrote: >> Fix what is broken and not break everything else so that you can >> pretend that it isn't. > > Think of that opening remark as a modern twitter-friendly version of > "A Modest Proposal" given in the very same spirit of Jonathon Swift's > original. My mail wasn't really serious ... but well that is not really visible over the internet ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
> > Or you can just use: > > BuildRequires: /usr/include/tcpd.h > > which works everywhere and you don't need conditionals. > > Paul. > seems to be interesting, but using filenames instead package names in yum appears to be more slow, I think only in build time should not be a problem. -- Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EL-6 mono build
On 10 May 2010 17:50, Itamar Reis Peixoto wrote: > mono requires bootstrapping ? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=172787 > > how to build it ? No, if you build against the mono.snk strong name key in /etc/pki then there should be no bootstrapping required. This is provided by mono-devel I think. Regards -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EL-6 mono build
On Mon, May 10, 2010 at 5:08 PM, Christopher Brown wrote: > On 10 May 2010 17:50, Itamar Reis Peixoto wrote: >> mono requires bootstrapping ? >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=172787 >> >> how to build it ? > > No, if you build against the mono.snk strong name key in /etc/pki then > there should be no bootstrapping required. This is provided by > mono-devel I think. > > Regards > > -- > Christopher Brown there are no mono-devel in EL-6, EL-6 not inherited EL-5 packages. -- Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Module-Signature/EL-6 .cvsignore, 1.9, 1.10 perl-Module-Signature.spec, 1.13, 1.14 sources, 1.9, 1.10
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-Module-Signature/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv30480
Modified Files:
.cvsignore perl-Module-Signature.spec sources
Log Message:
Update to 0.64
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Module-Signature/EL-6/.cvsignore,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- .cvsignore 28 Aug 2006 16:09:54 - 1.9
+++ .cvsignore 10 May 2010 20:13:14 - 1.10
@@ -1 +1 @@
-Module-Signature-0.55.tar.gz
+Module-Signature-0.64.tar.gz
Index: perl-Module-Signature.spec
===
RCS file: /cvs/pkgs/rpms/perl-Module-Signature/EL-6/perl-Module-Signature.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-Module-Signature.spec 26 Jul 2009 11:20:45 - 1.13
+++ perl-Module-Signature.spec 10 May 2010 20:13:14 - 1.14
@@ -1,72 +1,83 @@
Name: perl-Module-Signature
-Version:0.55
-Release:5%{?dist}
+Version:0.64
+Release:1%{?dist}
Summary:CPAN signature management utilities and modules
-
Group: Development/Libraries
-License:MIT
+License:CC0
URL:http://search.cpan.org/dist/Module-Signature/
-Source0:
http://www.cpan.org/authors/id/A/AU/AUDREYT/Module-Signature-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Module-Signature-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
BuildRequires: gnupg
+BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Digest::SHA1)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
Requires: gnupg
+Requires: perl(Digest::SHA)
Requires: perl(Digest::SHA1)
Requires(hint): perl(PAR::Dist)
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%description
This package contains command line tools and utilities a module for
checking and creating SIGNATURE files for Perl CPAN distributions.
-
%prep
-%setup -q -n Module-Signature-%{version}
+%setup -q -c -n Module-Signature
+# Copy up documentation for convenience with %%doc
+cp -a Module-Signature-%{version}/{AUTHORS,Changes,README,*.pub} .
+
+# Create a GPG directory for testing, to avoid using ~/.gnupg
+mkdir --mode=0700 gnupghome
+export GNUPGHOME=$(pwd)/gnupghome
+gpg --import *.pub
%build
-PERL_AUTOINSTALL=--skipdeps \
-%{__perl} Makefile.PL INSTALLDIRS=vendor --installdeps
+cd Module-Signature-%{version}
+PERL_AUTOINSTALL=--skipdeps perl Makefile.PL INSTALLDIRS=vendor --installdeps
make %{?_smp_mflags}
-
+cd -
%install
-rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -a -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+rm -rf %{buildroot}
+make -C Module-Signature-%{version} pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
+chmod -R u+w %{buildroot}
%check
-make test
-
+export GNUPGHOME=$(pwd)/gnupghome
+make -C Module-Signature-%{version} test TEST_SIGNATURE=1
%clean
-rm -rf $RPM_BUILD_ROOT
-
+rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc AUTHORS Changes README *.pub
%{_bindir}/cpansign
%{perl_vendorlib}/Module/
-%{_mandir}/man[13]/*.[13]*
-
+%{_mandir}/man1/cpansign.1*
+%{_mandir}/man3/Module::Signature.3pm*
%changelog
-* Sun Jul 26 2009 Fedora Release Engineering
- 0.55-5
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering
- 0.55-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Wed Mar 5 2008 Tom "spot" Callaway - 0.55-3
-- rebuild for new perl
+* Mon May 10 2010 Paul Howarth - 0.64-1
+- Update to 0.64
+ - Avoid creating gnupg config files when invoking Makefile.PL (CPAN RT#41978)
+ - Correctly detect the gnupg version on cygwin (CPAN RT#39258)
+
+* Wed May 5 2010 Paul Howarth - 0.63-1
+- Update to 0.63
+ - Fix Makefile.PL diagnostic message when gnupg and Crypt::OpenPGP missing
+ - Default keyserver changed from pgp.mit.edu to pool.sks-keyservers.net
+ - Added "=encoding utf8" to POD to fix author name display
+ - License changed to nullary CC0 1.0 Universal terms
+- Run signature test in %%check
+- BR/R: perl(Digest::SHA)
+- License changed to CC0
+- This release by FLORA -> update source URL
* Tue Apr 17 2007 Ville Skyttä - 0.55-2
- BuildRequire perl(ExtUtils::MakeMaker) and perl(Test::More).
Index: sources
===
[Bug 577790] perl-X11-Protocol - Request for EL-5 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=577790 --- Comment #4 from Fedora Update System 2010-05-10 16:15:14 EDT --- perl-X11-Protocol-0.56-5.el5, clusterssh-3.26-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 574409] request for perl-Net-SSH EPEL build
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574409 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Net-SSH-0.09-4.el5 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 574431] perl-Sys-SigAction - request for EL-5 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574431 --- Comment #3 from Fedora Update System 2010-05-10 16:15:53 EDT --- perl-Sys-SigAction-0.11-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 574409] request for perl-Net-SSH EPEL build
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574409 --- Comment #3 from Fedora Update System 2010-05-10 16:15:36 EDT --- perl-Net-SSH-0.09-4.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 574431] perl-Sys-SigAction - request for EL-5 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=574431 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Sys-SigAction-0.11-3.e ||l5 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 577790] perl-X11-Protocol - Request for EL-5 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=577790 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-X11-Protocol-0.56-5.el ||5 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
On Mon, 10 May 2010 16:40:24 -0300 Itamar Reis Peixoto wrote: > > > > Or you can just use: > > > > BuildRequires: /usr/include/tcpd.h > > > > which works everywhere and you don't need conditionals. > > > > Paul. > > > > seems to be interesting, but using filenames instead package names in > yum appears to be more slow, I think only in build time should not be > a problem. Yes, yum downloads the filelists, which is slow. But this only happens on the builder (koji) where it's not *that* slow, and has no impact at all on the users of the resulting package. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EL-6 mono build
Itamar Reis Peixoto wrote: > On Mon, May 10, 2010 at 5:08 PM, Christopher Brown >> No, if you build against the mono.snk strong name key in /etc/pki then >> there should be no bootstrapping required. This is provided by >> mono-devel I think. > there are no mono-devel in EL-6, > > EL-6 not inherited EL-5 packages. EL-5 builds can be (temporarily) tagged into the buildroot, if needed. I did that for bootstrapping sbcl. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: s/redhat/system in package names
On Sat, May 08, 2010 at 01:10:18AM +0200, Xose Vazquez Perez wrote: > hi, > > Long time ago, all *redhat* packages were renamed to "system*". > But three of them are still alive: redhat-lsb, redhat-menus and > redhat-rpm-config > > Should they switch to "system-" ? > > -thanks- > I think s/redhat/fedora/ is the better choice for these particular instances. --CJD > -- > «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.» > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: s/redhat/system in package names
On 5/10/2010 15:46, Casey Dahlin wrote: > On Sat, May 08, 2010 at 01:10:18AM +0200, Xose Vazquez Perez wrote: >> Long time ago, all *redhat* packages were renamed to "system*". >> But three of them are still alive: redhat-lsb, redhat-menus and >> redhat-rpm-config >> >> Should they switch to "system-" ? > > I think s/redhat/fedora/ is the better choice for these particular > instances. If they aren't specific to only Fedora like fedora-release and fedora-release-notes are, why put "fedora" in the package names at all? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: s/redhat/system in package names
On 05/11/2010 02:20 AM, Garrett Holmstrom wrote: > If they aren't specific to only Fedora like fedora-release and > fedora-release-notes are, why put "fedora" in the package names at all? > Besides switching from Red Hat to Fedora is fairly pointless since both names have trademark requirements. Calling it by a generic name encourages broader adoption as well c.f system-config-printer which is the default for all major distributions now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-05-11)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #351 Create a policy for updates - status report on implementation = New Business = #373 erlang provides/requires explosion #374 Modify Cloture rule #376 change provenpackager, sponsor acceptance procedure = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = 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 topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DVD as repo
/*Matthias Clasen */ wrote on 05/10/2010 5:59:56 PM +0450: On Mon, 2010-05-10 at 17:58 +0430, Hedayat Vatankhah wrote: Anyway, thinking about the problem with DeviceKit system policies, I really feel that the current situation is flawed: a process running as root is able to mount a device either by calling mount system call or by running the mount command, but it is unable to mount a device using DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it should be fixed anyway. Any comments? Can you explain this or point to a bug ? I'm positive that this is supposed to work. According to https://bugzilla.redhat.com/show_bug.cgi?id=435625#c21 policykit doesn't allow the yum backend of PackageKit (which is running as root) to mount devices. Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-05-11)
On Mon, 10 May 2010 15:00:18 -0600 Kevin Fenzi wrote: > > Following is the list of topics that will be discussed in the FESCo > meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on > irc.freenode.net. > > = Followups = > > #351 Create a policy for updates - status report on implementation > > = New Business = > > #373 erlang provides/requires explosion > #374 Modify Cloture rule > #376 change provenpackager, sponsor acceptance procedure I missed a ticket: #375: Bundled library exception for Zikula kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Mon, 2010-05-10 at 11:05 -0700, Jesse Keating wrote: > On Mon, 2010-05-10 at 07:28 +0300, Gilboa Davara wrote: > > I do not agree that that working with zero community input is the way to > > achieve a working compromise. (And input does not equal vote) > > > What makes you think that no community input is considered? Let me reverse the question: How did they gather the community input? >From whom it was gathered? What was the question? What was the answer? - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
On Mon, May 10, 2010 at 11:37:16AM -0500, Dennis Gilmore wrote:
> On Monday 10 May 2010 11:18:26 am Itamar Reis Peixoto wrote:
> > Index: redir.spec
> > ===
> > RCS file: /cvs/pkgs/rpms/redir/EL-6/redir.spec,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -p -r1.3 -r1.4
> > --- redir.spec 25 Sep 2009 22:51:24 - 1.3
> > +++ redir.spec 10 May 2010 16:18:26 - 1.4
> > @@ -1,6 +1,6 @@
> > Name: redir
> > Version:2.2.1
> > -Release:5%{?dist}
> > +Release:6%{?dist}
> > Summary:Redirect TCP connections
> >
> > Group: Applications/Internet
> > @@ -13,8 +13,10 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
> > BuildRequires: tcp_wrappers-devel
> > %endif
> >
> > -%if 0%{?rhel}
> > +%if 0%{?rhel} < 5
> > BuildRequires: tcp_wrappers
> > +%else
> > +BuildRequires: tcp_wrappers-devel
> > %endif
>
> this fix is incorrect. because "%if 0%{?rhel} < 5" becomes if 0<5 on
> fedora
> since rhel is undefined. you need to add a check for fedora also.
>
This is also wrong because we want 0%{?rhel} <= 5.
To avoid having to specify negation I'd also reverse the condition:
%if 0%{?rhel} >= 5 || 0%{?fedora}
BuildRequires: tcp_wrappers-devel
%else
BuildRequires: tcp_wrappers
%endif
-Toshio
pgpK3uq9Hbt3p.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 13 Release Candidate Phase
Fedora 13 has released Release Candidate stage. We have reached a state where the known blockers were fixed and were able to make a release candidate. This happened last Thursday, and almost immediately we found a need to spin a second release candidate. From this point on, only items critical to the release will be tagged into the branched Fedora 13 repo. I'm currently doing the first push of Fedora 13 stable updates. These will be what we call "0-day" updates, that is updates available at release time. Things in the bodhi update system for Fedora 13 can now be pushed "stable" to this updates repo. This allows our maintainers to continue to improve Fedora 13 as release engineering and QA finalize the release bits. If you have a bug that you think is critical to the release of Fedora 13 and must be fixed on the media, please make your bug block "F13Blocker". We will be reviewing the contents of this blocker bug frequently throughout the days as we near our go / no go decision. Thank you for your hard work in making Fedora 13 an awesome release! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Macbook Pro 13.3" (5,5) Fedora 12 notes
On Thu, Apr 8, 2010 at 11:41 PM, Jon Masters wrote: >> > but conversely >> > there's some weirdness with the sound driver resulting in no sound (for >> > which I will collate some data before blindly filing a bug on that). Ok then if no one does it (or my search skills suck...): https://bugzilla.redhat.com/show_bug.cgi?id=590907 It is just that the "Front Sp" is muted by default and set to quiet after (every) boot. Fixing that with alsamixer -c 0 results in sound working perfectly (with PulseAudio enabled). This is on F13 btw. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
On Tue, 2010-05-11 at 01:28 +0300, Gilboa Davara wrote: > On Mon, 2010-05-10 at 11:05 -0700, Jesse Keating wrote: > > On Mon, 2010-05-10 at 07:28 +0300, Gilboa Davara wrote: > > > I do not agree that that working with zero community input is the way to > > > achieve a working compromise. (And input does not equal vote) > > > > > What makes you think that no community input is considered? > > Let me reverse the question: How did they gather the community input? > >From whom it was gathered? > What was the question? > What was the answer? > > - Gilboa > > Most likely by reading or participating in the various threads on subjects that have happened on this list and the FAB list and the desktop list and others. It seems to be a rather big assumption that board decisions are made in a vacuum. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning Calibre
On Mon, 10 May 2010 14:25:02 +0300 "Ionuț C. Arțăriși" wrote: > > Hello, > > I don't have the time to maintain calibre any more so I'm orphaning > it. I fell behind on bugzilla, too. > > Beware, it requires a lot of love. Upstream moves very fast. Releases > happen weekly and there are always new features and sometimes new > bundled libs (yeah...). > > Whoever picks this up, feel free to contact me with questions. My time is pretty short these days, but I use and like calibre a lot. ;) Perhaps some other folks are in the same boat and we could get 3-4 of us to all work on it as our time permits? Who's in? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: s/redhat/system in package names
Garrett Holmstrom writes: > On 5/10/2010 15:46, Casey Dahlin wrote: >> On Sat, May 08, 2010 at 01:10:18AM +0200, Xose Vazquez Perez wrote: >>> Long time ago, all *redhat* packages were renamed to "system*". >>> But three of them are still alive: redhat-lsb, redhat-menus and >>> redhat-rpm-config >> >> I think s/redhat/fedora/ is the better choice for these particular >> instances. > If they aren't specific to only Fedora like fedora-release and > fedora-release-notes are, why put "fedora" in the package names at all? The rpm-config package is certainly pretty specific to RHEL/Fedora. Can't speak to the other two of my own knowledge ... but if they weren't renamed the first time around, it's probably because people thought they were distro-specific. s/redhat/fedora/ seems a plausible solution to me. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100510 changes
Compose started at Mon May 10 21:49:13 UTC 2010 Broken deps for i386 -- 1:mojito-devel-0.21.7-3.fc13.i686 requires mojito = 0:0.21.7-3.fc13 Broken deps for x86_64 -- 1:mojito-devel-0.21.7-3.fc13.i686 requires mojito = 0:0.21.7-3.fc13 1:mojito-devel-0.21.7-3.fc13.x86_64 requires mojito = 0:0.21.7-3.fc13 Updated Packages: mojito-0.21.7-3.fc13 * Sun May 09 2010 Peter Robinson 0.21.7-3 - Add the source file * Sun May 09 2010 Peter Robinson 0.21.7-2 - Revert to 0.21.7 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Blockers via flags?
So, I know a lot of you out there hate bugzilla flags, but I think we
have problem with the current way we manage release blocker issues, and
flags offer a potential solution.
First the problem:
Right now, anybody can propose a release blocker bug. This is not the
problem though, the problem is that developers (and testers) have no
good queryable method to determine whether the proposed blocker has been
accepted or not. Why is this important? Well some (all?) developers
have finite time, and our release cycle is also finite. Therefor its
important that they work on the issues we would actually stop the
release for. As a reporter it's also worth knowing if the bug in
question will delay the release or not, so that a workaround could be
researched and documented.
A second problem is that we (qa, releng, devel) spend a looong time
processing all the proposed blockers. This is typically done during
marathon Friday meetings that can last up to 6 hours or more. That's a
long time to devote to the mind numbing action of going through bug
after bug after bug.
A solution, flags!
(our?) Bugzilla already has a method for proposal and acceptance. This
is done via flags. We currently use this for package reviews and CVS
admin tasks. What I propose is that we introduce a new flag once we've
branched a release and created a bugzilla version for a Fedora release.
That flag would be release_blocker or just blocker, or maybe
{alpha,beta,final}_blocker. Anybody who has rights to modify bugs could
set this flag to ?. As far as acceptance, we already look to releng,
QA, and development to agree on whether a bug is a blocker or not,
therefor we can express this transparently as a QA ack, a releng ack,
and a devel ack. Should a bug receive these acks, the blocker flag
would automatically move from ? to + and we'd have ourselves a blocker!
Some of you may find this familiar if you've dealt with RHEL products.
Is this going to prevent work from being done? Absolutely not. Unlike
that other product, we will not be blocking our source control and
buildsystem on whether or not a bug has gotten all the acks it needs or
not. If you have a fix for an issue, by all means get it committed and
built and proposed as an update, don't let process stand in your way.
How does it solve the problem(s)? We can query against flags and find
the bugs that have been accepted as blockers, which will help developers
find issues which are critical to be worked on. It'll help our testers
find issues which are determined to be blockers and have a fix that
needs to be verified. It'll help our qa/releng folks focus on issues
that are proposed but not yet accepted as blockers. It will also allow
us to process potential blockers as they come up asynchronously as
opposed to waiting for the next Friday grind and spend hours working
through the list synchronously. Ideally that will allow us to reach a
conclusion about a proposed blocker faster and with less overhead, so
that we can spend the meeting time discussing the truly interesting and
difficult issues that require discussion.
But why releng, QA, and devel acks? Good question. 3 might be wholly
unnecessary, but I believe that it is important to have voice of at
least the developer and QA involved. QA can help determine if an issue
touches on release criteria, or at least form the opinion that an issue
is worthy of slipping a release. At the same time, QA is not
omnipotent, and thus they do require input from subject matter experts,
such as the developer. The releng vote could probably get tossed,
releng could always just state opinion and ask for reconsideration if
the outcome isn't to our liking.
Anyway, there are little bits of detail here and there to work out, but
I wanted to float this idea while the current blocker process was still
fresh in people's minds. And it would be nice to have a different
discussion on this list. Please keep in mind that the idea behind this
isn't to stifle work in any way; The intent is to help developers make
decisions on what issues have higher priority than others, and to add
more openness and transparency to one of the things we do which seems
like a black hole to some people.
What say you?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100510 changes
On Tue, 2010-05-11 at 02:12 +, Branched Report wrote: > > Broken deps for i386 > -- > 1:mojito-devel-0.21.7-3.fc13.i686 requires mojito = > 0:0.21.7-3.fc13 I've fixed this and have a new compose going. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Blockers via flags?
On 5/10/2010 22:23, Jesse Keating wrote:
> (our?) Bugzilla already has a method for proposal and acceptance. This
> is done via flags. We currently use this for package reviews and CVS
> admin tasks. What I propose is that we introduce a new flag once we've
> branched a release and created a bugzilla version for a Fedora release.
This sounds like a decent idea to me, but I have a couple
questions/suggestions.
> That flag would be release_blocker or just blocker, or maybe
> {alpha,beta,final}_blocker. Anybody who has rights to modify bugs could
> set this flag to ?.
Fedora only has one branched, yet unreleased release at a time. Can we
recycle the same tag(s) for every release instead of creating new ones
every time?
> How does it solve the problem(s)? We can query against flags and find
> the bugs that have been accepted as blockers, which will help developers
> find issues which are critical to be worked on. It'll help our testers
> find issues which are determined to be blockers and have a fix that
> needs to be verified. It'll help our qa/releng folks focus on issues
> that are proposed but not yet accepted as blockers. It will also allow
> us to process potential blockers as they come up asynchronously as
> opposed to waiting for the next Friday grind and spend hours working
> through the list synchronously. Ideally that will allow us to reach a
> conclusion about a proposed blocker faster and with less overhead, so
> that we can spend the meeting time discussing the truly interesting and
> difficult issues that require discussion.
I don't understand how using a flag instead of a tracking bug makes this
less work. Under the current system proposed blockers show up, get
discussed, then possibly shot down. Under your proposed system proposed
blockers will show up, get discussed, then possibly acknowledged as
such. Where is the time savings?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
