Re: Is PulseAudio dead?
On Tue, Aug 3, 2010 at 2:06 AM, Lennart Poettering wrote: > On Mon, 02.08.10 23:50, pbrobin...@gmail.com (pbrobin...@gmail.com) wrote: > >> > So, I guess what I want to say is: I will return full-time to PA not so >> > far away. And I have a queue of patches in my checkout (including volume >> > ramping and plug-in effects and similar). Also note that I'll run the >> > track about audio at plumbersconf again, so there's really no reason to >> > believe that I moved on or PA was dead. >> >> Which is great and I understand that but systemd will basically cover >> the release time frame for F-13 and F-14 and in that timeframe the >> support and issues for PA are going unfixed or even un triaged. Not >> great for a core sub system. So maybe it would be a good idea to train >> up a few people that can do the boring trage so you can get on with >> the upstream PA and systemd stuff so that the average end user doesn't >> need to wait for the bottle neck of a single person because presumably >> with other distros using it Fedora isn't the only distro demanding >> your time. > > Audio hackers unfortunately don't grow on trees. In my counting, there > are 3 people paid in the whole industry who work on general purpose > audio infrastructure of Linux. Two of them are basically busy with > keeping the HDA driver up-to-date, if I am correctly informed. The third > one is me. > > As long as things are that way the entire weight of fixing bugs all > across our consumer audio stack are basically lying on three pairs of > shoulders, and that defines the speed in which we process bugs. So, > please be patient. > > One would wish that a certain other company with a clear focus on > desktop Linux (where consumer audio is a key part of) would want to > actually hire more folks in this area, but well, ... > > I not sure whether it should be considered a failure of us consumer > audio hackers that we never managed to attract a bigger number of core > contributors. But well, I am not a Jono Bacon, and I have done quite a > number of talks about PA and related techs on many conferences, both > about the technical details and from a more user-related > perspective. While I like to believe that people did enjoy my talks they > didn't really have the effect of boasting the numbers of core hackers of > our audio infrastructure. > > Audio hacking is often quite complex unfortunately. You need to have a > basic idea of signal processsing and RT stuff. The code involved is time > critical and usually very low-level. That makes the learning curve > steep, and doesn't help growing audio hackers. > > Then again, something similar can probably be written about every other > part of our Linux infrastructure. I am still waiting for the project > that doesn't have too feww, but too many people making contributions > ;-). > > But anyway. We have come quite far in the last years, and I actually > think the status quo is not bad at all anymore. I have a pretty > positive view on things, so while it of course would be great if we > could fix all open bugs tomorrow, I don't think it should be considered > a catastrophic desaster if we didn't. I think we've done very well over the last couple of years. There's also the MeeGo to go with the Ubuntu and no doubt suse and other distros. But I was more talking about people that know a little that can assist in QA and triage of bugs rather than core develops. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 status: python2.7 is in dist-f14
On Wed, Aug 4, 2010 at 9:55 AM, Tomasz Torcz wrote: > On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote: >> Rawhide (dist-f14) now has python 2.7 > > I have a machine which run rawhide since F11 times. Recently upgrade to > python2.7 failed because of "rhpl" package. rhpl was removed from Fedora > some time ago, so it wasn't rebuild lately. > Now the question: what package should cause rhpl to be removed during update? > Is there any obsoletes or conflicts that should cause rhpl to be removed > during upgrades (F11→F15 time frame)? I noticed this the other day as well. It should have been obsoleted by something so that it was removed on upgrade. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Thu, Aug 5, 2010 at 12:37 AM, Kevin Kofler wrote: > Bill Nottingham wrote: >> Orphan: nas >> gstreamer-plugins-bad-free requires nas-devel = 1.9.1-6.fc12 >> gstreamer-plugins-bad-free-extras requires libaudio.so.2 >> speech-dispatcher requires libaudio.so.2 >> speech-dispatcher requires nas-devel = 1.9.1-6.fc12 > > I suggest that these be just built without NAS support. NAS is basically an > older competitor to PulseAudio with fewer features (it focuses on network > transparency, which is just one of the things PulseAudio does), it is not > compatible with PulseAudio, few to no people use it. I was already planning on doing that for speech-dispatcher. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Fri, Aug 6, 2010 at 2:04 AM, Adam Williamson wrote: > On Thu, 2010-08-05 at 10:46 +, Petr Pisar wrote: > >> PulseAudio is interresting project, but it's absolutely unusable on old >> slow hardware. Last time I checked it out on Pentium TSC (no MMX) >> running at 200 MHz, it consumed 20 % of CPU just in idle mode. While >> `playing', it congested CPU, printed some warnings about stream buffer >> overflow and terminated gracefully complaining about no CPU cycles. NAS >> or Esound work on the machine fluently. > > PA uses a more correct but more CPU-intensive resampling method than > ALSA by default. On very slow systems it's a good idea to > edit /etc/pulse/daemon.conf and change the 'resample-method' parameter. Is there a recommended value for slow machines or a way to tell PA just to use the HW? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Mon, Aug 9, 2010 at 5:43 PM, Bill Nottingham wrote: > Petr Pisar (ppi...@redhat.com) said: >> > I suggest that these be just built without NAS support. NAS is basically an >> > older competitor to PulseAudio with fewer features (it focuses on network >> > transparency, which is just one of the things PulseAudio does), it is not >> > compatible with PulseAudio, few to no people use it. >> > >> I agree NAS is very old audio system, but it has history. It works (or >> should work) across operating systems (do not think only about Linux). >> In addition it supports bidirectional sound transmission (from >> microphone). >> >> PulseAudio is interresting project, but it's absolutely unusable on old >> slow hardware. Last time I checked it out on Pentium TSC (no MMX) >> running at 200 MHz, it consumed 20 % of CPU just in idle mode. While >> `playing', it congested CPU, printed some warnings about stream buffer >> overflow and terminated gracefully complaining about no CPU cycles. NAS >> or Esound work on the machine fluently. > > Given that that's not the hardware target we're looking at in Fedora, > perhaps some effort could be spent in determining where the performance > issues lie in PA in an effort to fix the experience for everyone, rather than > maintaining parallel implementations that provide little benefit to the > userbase as a whole? While the XO-1 is a comparitatively relative higher HW spec (433 mhz from memory, so not massive but still double) it might be a worthwhile canditdate as there's quite a few of them around the community for testing, its not overly powerful and sees similar issues as well. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Mon, Aug 9, 2010 at 10:56 PM, Kevin Kofler wrote: > pbrobin...@gmail.com wrote: >> While the XO-1 is a comparitatively relative higher HW spec (433 mhz >> from memory, so not massive but still double) it might be a worthwhile >> canditdate as there's quite a few of them around the community for >> testing, its not overly powerful and sees similar issues as well. > > The N900 also uses PulseAudio (though not on Fedora). Yes, so it seems. It has a lot of config options set in /etc/pulse/daemon.conf but then it seems we don't. Something that I'll add to my list to look at. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Fri, Aug 13, 2010 at 9:19 PM, Matthias Runge wrote: > Hello all, > > currently I'm looking for a review for two of my packages: > lockfile-progs: https://bugzilla.redhat.com/show_bug.cgi?id=601115 > is a dependency of > logcheck: https://bugzilla.redhat.com/show_bug.cgi?id=589867 > > liblockfile (needed for lockfile-progs) is included in rawhide and in > updates-testing for F-13 resp. F-14. > > Those packages are quite small and I appreciate each help. > > I would like to trade reviews. I'll swap you them for: meego-help https://bugzilla.redhat.com/show_bug.cgi?id=624205 gupnp-dlna https://bugzilla.redhat.com/show_bug.cgi?id=617141 Both fairly basic reviews as well. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
drop default MTA for Fedora 14
Hi All, I know its been discussed in the past but there's been reasons not to drop a default MTA but now that cronie (the last actual dependency) has support for logging to system logs is there any reason to include an MTA by default for F-14? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Sun, Aug 22, 2010 at 6:45 PM, Rex Dieter wrote: > pbrobin...@gmail.com wrote: > >> I know its been discussed in the past but there's been reasons not to >> drop a default MTA but now that cronie (the last actual dependency) >> has support for logging to system logs is there any reason to include >> an MTA by default for F-14? > > A bit late to consider for F-14 imo (I'd argue something like should in > place and testable by or near feature freeze), F-15 is doable. It was discussed as part of F-12 and F-13 and we now have all the pieces in place. BTW Why change the subject line? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Mon, Aug 23, 2010 at 8:15 PM, Jon Masters wrote: > On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: >> On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter wrote: >> > pbrobin...@gmail.com wrote: >> > >> >> I know its been discussed in the past but there's been reasons not to >> >> drop a default MTA but now that cronie (the last actual dependency) >> >> has support for logging to system logs is there any reason to include >> >> an MTA by default for F-14? >> > >> > A bit late to consider for F-14 imo (I'd argue something like should in >> > place and testable by or near feature freeze), F-15 is doable. >> >> Test what? That no MTA is present? >> >> I'd say we should stop arguing forever and just do it. > > What's the benefit of having no default MTA at all? Is it that Desktop > users don't care about MTAs being installed? what about those of us who > care more about server installations than Desktop? In a server config I'm sure the person configuring the server would know how to install a MTA, and in a lot of cases they might not want sendmail but rather say postfix/exim etc. All its doing is removing it from the base and core groups in comps. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Mon, Aug 23, 2010 at 8:30 PM, Jon Ciesla wrote: > On 08/23/2010 02:21 PM, pbrobin...@gmail.com wrote: >> On Mon, Aug 23, 2010 at 8:15 PM, Jon Masters wrote: >>> On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: >>>> On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter wrote: >>>>> pbrobin...@gmail.com wrote: >>>>> >>>>>> I know its been discussed in the past but there's been reasons not to >>>>>> drop a default MTA but now that cronie (the last actual dependency) >>>>>> has support for logging to system logs is there any reason to include >>>>>> an MTA by default for F-14? >>>>> A bit late to consider for F-14 imo (I'd argue something like should in >>>>> place and testable by or near feature freeze), F-15 is doable. >>>> Test what? That no MTA is present? >>>> >>>> I'd say we should stop arguing forever and just do it. >>> What's the benefit of having no default MTA at all? Is it that Desktop >>> users don't care about MTAs being installed? what about those of us who >>> care more about server installations than Desktop? >> In a server config I'm sure the person configuring the server would >> know how to install a MTA, and in a lot of cases they might not want >> sendmail but rather say postfix/exim etc. All its doing is removing it >> from the base and core groups in comps. >> >> Peter > I use it on desktop installs. I know how to install it, but might there > be packages that require local MTA functionality that have heretofore > assumed it would be there, but don't Require it? Might someone be able > to find this out, someone with greater RPM-fu than my own? Well the default installed MTA, which is sendmail, requires configuration to send mail for anything other than local delivery and all the daemons send mail to root which also requires further configuration. Also anything that requires a MTA should require it as per standard package guidelines. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 9:36 AM, Rudolf Kastl wrote: > my desktop runs on software mirror raid below an lvm. not for > performance but for data recovery reasons. mdmonitor does mail > notification. will this be fixed? how about logwatch, it is really > useful to have to get an overview what happened on the system in a > neat summary. also handy for desktops but just not recognized and > presented in an end user compatible way. just my opinion. Neither of those need to run a MTA locally to work, you just need to point them to a mail server, even then they need to be configured to send the mail to something other than root anyway. Removing the default MTA won't change these out of the box and if you still want to run a local MTA its as simple as selecting it during install. I use all of the above on dozens of servers and none of them run a mail server locally. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 12:43 PM, Andrew Haley wrote: > On 08/23/2010 08:15 PM, Jon Masters wrote: >> On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: >>> On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter wrote: >>>> pbrobin...@gmail.com wrote: >>>> >>>>> I know its been discussed in the past but there's been reasons not to >>>>> drop a default MTA but now that cronie (the last actual dependency) >>>>> has support for logging to system logs is there any reason to include >>>>> an MTA by default for F-14? >>>> >>>> A bit late to consider for F-14 imo (I'd argue something like should in >>>> place and testable by or near feature freeze), F-15 is doable. >>> >>> Test what? That no MTA is present? >>> >>> I'd say we should stop arguing forever and just do it. >> >> What's the benefit of having no default MTA at all? Is it that Desktop >> users don't care about MTAs being installed? what about those of us who >> care more about server installations than Desktop? > > Even the web page proposing its deletion acknowledges that "The > presence of a Mail Transfer Agent (MTA) like sendmail has long been > the de facto standard." Indeed it has: the ability to send mail from > a program has been an entitlement for as long as UNIX has been around. > In comparison with this, the benefit is very feeble: "One less > required package in the critical path, and we clear the way for > removing the MTA from the default install." Removing it doesn't stop applications in unix from sending mail! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 5:37 PM, Till Maas wrote: > On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote: > >> The problem with delivering this to a user's mailbox via an MTA is that >> in the typical case it doesn't result in the user noticing anything >> until they've logged in as root and find out that the "you have new >> mail" message actually means "Your RAID is fucked" and not just "Here's > > In the typical case users do not use RAID. And how does this change > with the new not MTA feauture? And in case a RAID is used, how is the > user notified when the RAID is broken? How are they notified now? By default the local mta delivers everything to root because there's no way to know what user is going to exisit. How many people check the local root users mail. So for desktop it should be a notification to the screen, for a server it would need to be configured anyway for smart relay hosts and real users to send it to. So its currently broken as it standard. This change is not going to make that any better or worse. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 3:19 PM, Jon Masters wrote: > On Tue, 2010-08-24 at 10:09 -0400, Matthew Miller wrote: >> On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: >> > Why are you complaining? If your package needs an MTA - put in a Requires! >> >> If we follow the general state of things: "if a package might need >> something, toss it in as a requires!", this will totally defeat the purpose >> of the comps change, since it will get pulled in by something important at >> some point. Rsyslog, for example, can send output via e-mail. >> >> Having a very simple mail-queue-and-relay program as an alternative to >> sendmail seems like a better choice than just ditching it. > > My previous objection was based on the precedent it sets. I don't want a > "Desktop" distribution in Fedora. I want a server-usable distribution. > Sure, it's just a dep and one can go install an MTA. But today it's > killing the MTA, tomorrow it's removing something else that's useful on > the server side of things. I want to see that trend stop and reverse. Its NOT killing the MTA. In most cases you won't see any difference. Its removing the mandatory option in the comps. There are dozens of packages that depend on /usr/bin/sendmail and they will install a MTA as a dependency. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 3:09 PM, Matthew Miller wrote: > On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: >> Why are you complaining? If your package needs an MTA - put in a Requires! > > If we follow the general state of things: "if a package might need > something, toss it in as a requires!", this will totally defeat the purpose > of the comps change, since it will get pulled in by something important at > some point. Rsyslog, for example, can send output via e-mail. yes, but in the case that something needs it such as logwatch it will automatically install an MTA as part of the dependencies. So just because its not there by default doesn't mean that it won't necessarily be installed. It just means that for a minimal install or possibly a desktop spin if there's not a dependency on it it won't unnecessarily get installed. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
>> > > My previous objection was based on the precedent it sets. I don't want a >> > > "Desktop" distribution in Fedora. I want a server-usable distribution. >> > > Sure, it's just a dep and one can go install an MTA. But today it's >> > > killing the MTA, tomorrow it's removing something else that's useful on >> > > the server side of things. I want to see that trend stop and reverse. >> > >> > How about you become involved in the 'Server' SIG [1] then >> >> Happy to do so. I also happen to believe that Fedora should have certain >> server-useful characteristics out of the box (like Linux always has >> done). That's my opinion, I've made it known, and now I'm done. > > FWIW, I'm with Jon and Adam on this one. I just don't see how not having > an MTA by default is a win, except in disk space terms, and it takes up > a tiny amount of disk space (especially if we pick a lighter-weight one > than sendmail to be the default). I think it makes sense to keep one, > for all the good reasons they cited. I have no problems with leaving it default in the shipped releases, what I would like to see is it removed from core/base (why does it need to be in both). It would be nice to be able to do the "minimal" without it in something like 256Mb of storage. Its like having "printing" in base-x why? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 10:52 PM, Matthew Garrett wrote: > On Tue, Aug 24, 2010 at 05:43:49PM -0400, seth vidal wrote: > >> that seems like a bit of odd logic. The logs are emitted to syslog with >> the same thought in mind - that someone will read them - but that is >> also not necessarily true. But I would not want to see us discarding >> syslog, either. > > We have a range of utilities that perform useful syslog parsing. The > fact that most of them then seem to pass that output to sendmail leaves > me a little less convinced that anyone pays the slightest bit of > attention to them. > > More realistically, we install syslog because it gives us debug > information that we (as developers) wouldn't otherwise be able to get. I see syslog as the equivalent of the event log in that other OS. You can easily view it with a basic "less /var/log/someLog" or a gui viewer (not sure if we install that by default) or even some notification method. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Wed, Aug 25, 2010 at 12:34 AM, Jon Masters wrote: > On Tue, 2010-08-24 at 17:54 -0400, seth vidal wrote: >> On Tue, 2010-08-24 at 22:52 +0100, Matthew Garrett wrote: >> > On Tue, Aug 24, 2010 at 05:43:49PM -0400, seth vidal wrote: >> > >> > > that seems like a bit of odd logic. The logs are emitted to syslog with >> > > the same thought in mind - that someone will read them - but that is >> > > also not necessarily true. But I would not want to see us discarding >> > > syslog, either. >> > >> > We have a range of utilities that perform useful syslog parsing. The >> > fact that most of them then seem to pass that output to sendmail leaves >> > me a little less convinced that anyone pays the slightest bit of >> > attention to them. >> > >> > More realistically, we install syslog because it gives us debug >> > information that we (as developers) wouldn't otherwise be able to get. >> >> Maybe that's why you do it - but I don't. And we have a lot of utilities >> that parse and handle logs and send proper notifications on events we >> need to worry about. > > I have an MTA installed because I expect to get emailed logs, and root@ > does go somewhere. Now, there are a couple of things I should admit: > > 1). I did replace the out-of-the-box MTA, because it was sendmail. I > don't actually care too much about using sendmail, I happened to have > configuration files that just work, because the entire mail subsystem > wasn't rewritten recently, so I could just copy those files in place. > > 2). I care more about the "server" experience on this machine than > pretty GUI stuff. I know that's no longer the default here :( I also > like to think about what I want to base upon Fedora in the future. But my point still remains that it doesn't work out of the box and you have to do stuff to make it work, so if your in that situation its not hard to do "yum install someMTA" Peter >> And the first person who mentions snmptrap events gets slapped. :) > > Well, I use SNMP for power control, etc. but even I am not anal enough > to use it at home for logging. > > Jon. > > > -- > 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: a note on order of arguements to systemctl command
On Tue, Aug 24, 2010 at 9:22 PM, Tom "spot" Callaway wrote: > On 08/24/2010 03:53 PM, Lennart Poettering wrote: >> On Tue, 24.08.10 14:59, Matthew Miller (mat...@mattdm.org) wrote: >> >>> The service command has a syntax like this: >>> >>> service servicename action >>> >>> where as systemctl has a syntax like this: >>> >>> systemctl action servicename.service >>> >>> This is inconvienient for the common case where more than one action is >>> performed in sequence on the same service, since with the first ordering, >>> one just hits the up arrow, ctrl-w, and then types the new action (with >>> tab-completion). >>> >>> With the systemctl order, one must first skip back over the first word, >>> which due to the awesome emacsness of bash keybindings is more of a pain. >>> >>> I'm not saying that systemctl's syntax needs to be changed. I am saying, >>> however, that it's important to get the service command working with >>> systemctl so that people can use that instead. >> >> Interesting definition of "important". > > FWIW, Lennart, I agree with him here. The smoother the transition we can > provide for existing admins, the better, and this is an obvious place > where we can do that. So do I. I deal with literally 1000s of RH/Fedora servers and derivatives every day so its quite important for me and the dozens of other people that I work with that don't follow upstream so closely so may not be aware of the changes. I'm still trying to work out how to get systemctl to boot my netbook into run level 5. The usual way of changing this seems to have no effect and that is a problem. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Wed, Aug 25, 2010 at 7:36 AM, Jon Masters wrote: > On Wed, 2010-08-25 at 07:23 +0100, pbrobin...@gmail.com wrote: >> On Wed, Aug 25, 2010 at 12:34 AM, Jon Masters >> wrote: > >> > I have an MTA installed because I expect to get emailed logs, and root@ >> > does go somewhere. Now, there are a couple of things I should admit: >> > >> > 1). I did replace the out-of-the-box MTA, because it was sendmail. I >> > don't actually care too much about using sendmail, I happened to have >> > configuration files that just work, because the entire mail subsystem >> > wasn't rewritten recently, so I could just copy those files in place. >> > >> > 2). I care more about the "server" experience on this machine than >> > pretty GUI stuff. I know that's no longer the default here :( I also >> > like to think about what I want to base upon Fedora in the future. >> >> But my point still remains that it doesn't work out of the box and you >> have to do stuff to make it work, so if your in that situation its not >> hard to do "yum install someMTA" > > To be clear, I'm in the "but I don't want Fedora to be just a GNOME > desktop" camp. So I see removing the MTA by default as just another step > in the wrong direction. Even if I will replace it with something else. I > know I'm not alone in that particular train of thought. Its got nothing to do with gnome what so ever. I don't see what that has to do with the discussion. I actually want it so its easy to make tiny appliances and routers without having to manually strip a whole lot of crap out. As I mentioned above there's nothing to stop it being included in another comps group, but moving it out of core AND base as being mandatory (when its not). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning a few packages
I've orphaned the following packages if anyone wants to pick them up. They are primarily dead upstream but some might still use them. libmatchbox matchbox-window-manager twitter-glib Regards, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning a few packages
On Tue, Aug 31, 2010 at 1:47 PM, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/30/2010 06:07 PM, pbrobin...@gmail.com wrote: >> I've orphaned the following packages if anyone wants to pick them up. >> They are primarily dead upstream but some might still use them. >> >> libmatchbox >> matchbox-window-manager >> twitter-glib >> >> Regards, >> Peter > I guess I will have to take matchbox-window-manager, since I use it in > sandbox, unless someone else wants to take it, or has a reasonable > replacement. Well Sugar use to use it for their WM but it worked out that it was easier to use metacity. In the time I've had it the maintenance has been very low so it seems its pretty stable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: > Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 > (master) branch. I've tested GNOME Shell and quadrapassel, feel free > to CC me for other fallout. This will break meego. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Tue, Aug 31, 2010 at 8:04 PM, Bastien Nocera wrote: > On Tue, 2010-08-31 at 19:57 +0100, pbrobin...@gmail.com wrote: >> On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: >> > Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >> > (master) branch. I've tested GNOME Shell and quadrapassel, feel free >> > to CC me for other fallout. >> >> This will break meego. > > Well, it's F15 :) Yes, but its generally considered to be good form to give heads up before it happens rather than once its on its way and pretty much too late for those that it does impact to have a say. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Tue, Aug 31, 2010 at 8:16 PM, Colin Walters wrote: > On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com > wrote: >> On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: >>> Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >>> (master) branch. I've tested GNOME Shell and quadrapassel, feel free >>> to CC me for other fallout. >> >> This will break meego. > > Okay, is there a schedule for meego supporting 1.3? That would give > guidance about creating a temporary clutter-1.2 package or not. It not in MeeGo 1.1 and after that there's no published schedule. So for 1.2 (or what ever its called) which should come around F-15 I suspect it might happen but I've no idea. I also don't know about backwards compatibility between the releases. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Wed, Sep 1, 2010 at 9:55 AM, Rudolf Kastl wrote: > 2010/8/31 pbrobin...@gmail.com : >> On Tue, Aug 31, 2010 at 8:16 PM, Colin Walters wrote: >>> On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com >>> wrote: >>>> On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: >>>>> Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >>>>> (master) branch. I've tested GNOME Shell and quadrapassel, feel free >>>>> to CC me for other fallout. >>>> >>>> This will break meego. >>> >>> Okay, is there a schedule for meego supporting 1.3? That would give >>> guidance about creating a temporary clutter-1.2 package or not. >> >> It not in MeeGo 1.1 and after that there's no published schedule. So >> for 1.2 (or what ever its called) which should come around F-15 I >> suspect it might happen but I've no idea. I also don't know about >> backwards compatibility between the releases. >> >> Peter >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > > you cannot install both gnome-shell and meego at once since a whole > while because of: > > Error: mutter-mbl conflicts with mutter > > it would be really nice to have that conflict sorted out after ages now. That requires the two upstreams to actually merge their differences. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Wed, Sep 1, 2010 at 9:59 AM, Ankur Sinha wrote: > On Tue, 2010-08-31 at 14:52 -0400, Colin Walters wrote: >> Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >> (master) branch. I've tested GNOME Shell and quadrapassel, feel free >> to CC me for other fallout. > > Hey, > > Does this mean pyclutter and other bindings will see an update as well? Only when and if a new version is released. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100901 changes
On Wed, Sep 1, 2010 at 1:35 PM, Martin Sourada wrote: > On Wed, 2010-09-01 at 12:20 +, Rawhide Report wrote: > >> entangle-0.1.0-7.fc14.x86_64 requires libmozjs.so()(64bit) >> ethos-0.2.2-7.fc15.i686 requires libmozjs.so >> ethos-0.2.2-7.fc15.x86_64 requires libmozjs.so()(64bit) > >> gjs-0.7.1-3.fc14.i686 requires libmozjs.so >> gjs-0.7.1-3.fc14.x86_64 requires libmozjs.so()(64bit) > >> gnome-shell-2.31.5-5.fc14.x86_64 requires libmozjs.so()(64bit) > >> gxine-0.5.905-3.fc13.x86_64 requires libmozjs.so()(64bit) > >> libproxy-mozjs-0.4.4-7.fc14.x86_64 requires libmozjs.so()(64bit) > >> openvrml-javascript-0.18.6-1.fc14.x86_64 requires libmozjs.so()(64bit) > >> xulrunner-python-1.9.2-4.20100111hg.fc14.x86_64 requires >> libmozjs.so()(64bit) >> > > So, it looks like somewhere between xulrunner-1.9.2.7 and 1.9.3.0 > libmozjs.so was lost. Why no HEADS UP? Is this a bug or should we just > rebuild against new xulrunner or even switch to different js altogether? It doesn't build against the new xulrunner I've tried. I suspect its because of the major changes is JS but I'm not sure what the plans are for it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap?
Hi All, Anyone want to do package review swapsies? meego-panel-datetime https://bugzilla.redhat.com/show_bug.cgi?id=624204 Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-09-01 i386
On Tue, Sep 7, 2010 at 10:34 PM, Matt Domsch wrote: > On Tue, Sep 07, 2010 at 02:02:05PM -0600, Orion Poplawski wrote: >> On 09/06/2010 08:24 PM, Matt Domsch wrote: >> > paraview-3.8.0-4.fc14 (build/make) orion,pertusus >> >> Sorry [Errno 28] No space left on device >> >> Looks like a check for that is in order. > > Holy cow. So, 8GB RAM, 16GB swap, over 4 hours to compile (5 on i386), and it > ran out of memory in the tmpfs. Repeatedly. > > Perhaps I need a way to specially build some apps, or just skip them. That might explain why most of the ones that I have bugs against build fine (in both rawhide and F-14), and the ones that didn't I'm aware of the issues already. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi time management?
Hi All, How do the bodhi 7 days timeframes for updates work? My understanding is that an update is required to be in updates for 7 days. I have an update that according to bodhi was submitted as an update on the 29th Aug at 18:13. It was pushed to updates-testing at 19:42 the following day (Aug 30th) yet 9 full days later I still can't push it to stable. According to the link that bodhi provides me in blazen orange across my browser I don't meet the requirements, yet according to the documentation I do. WTF!! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How long is a week?
On Wed, Sep 8, 2010 at 9:22 AM, Richard W.M. Jones wrote: > On Wed, Sep 08, 2010 at 12:25:29AM +0200, Björn Persson wrote: >> Quote from https://fedoraproject.org/wiki/Package_update_acceptance_criteria: >> >> All other updates must either: >> · reach the criteria laid out in the previous section OR >> · reach the positive Bodhi karma threshold specified by the updates >> submitter OR >> · spend some minimum amount of time in updates-testing, currently one >> week >> >> So spending one week in updates-testing is supposed to be sufficient to >> proceed >> to updates, right? >> >> It has now been over eight days since GtkAda-2.14.0-8.fc14 was pushed to F-14 >> updates-testing, and over nine days since I submitted it, but when I try to >> submit it to stable I get the message "This update has not yet met the >> minimum >> testing requirements defined in the Package Update Acceptance Criteria". >> >> I don't understand this. How does Bodhi count weeks, or what other criteria >> does this update need to meet? > > The fault is with Bodhi. "One week" is somehow defined as just over 8 > days. I had the exact same problem with some of my packages. Amusingly I have one update where bodhi states "this update has reached 8 days and can be pushed to stable" and another where it says 7 days. Its like a moving bloody target! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broadcom wifi drivers in F-14?
Hi All, Does anyone know if the new Broadcom drivers are in a state where they would be in the Fedora 14 kernel? I've seen the release but i've not seen any comment as to the state of them other than they already support mac80211. These are quite a common device and I think it would be nice to see them available in F-14. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Tue, Sep 14, 2010 at 3:13 PM, John W. Linville wrote: > On Tue, Sep 14, 2010 at 12:31:44PM +0100, David Woodhouse wrote: >> On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: >> > IIRC they require a firmware blob that has a license that we cannot >> > distribute >> > unlike say the Intel firmwares. I could be wrong though. >> >> That's still true of the b43 firmware for older (pre-802.11n) devices, >> but the firmware to go with their new driver is now in >> linux-firmware.git. >> >> Their *original* offering of that new firmware had a stupid licence -- >> you could only distribute it if you promised to indemnify and defend >> Broadcom from all related third-party lawsuits. They fixed that though, >> and I merged it. > > Nevertheless, everyone I know that has reviewed the newly released > driver code is being treated for eye cancer. I wouldn't expect to > see it in F-14. Thanks for the update. That's what I suspected as it seems to be the norm for vendor code dumps. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Tue, Sep 14, 2010 at 8:31 PM, Rahul Sundaram wrote: > On 09/15/2010 12:49 AM, Matthew Miller wrote: >> On Tue, Sep 14, 2010 at 12:04:04PM -0700, Jesse Keating wrote: >>> Which OEMs care enough about Linux support to use a more expensive part? >> Seriously. I will go buy their stuff right now. > > I read that HP was doing this but haven't verified. >From supporting Sugar related deployments using the Fedora Sugar on a Stick with HP laptops I've not exactly seen that but I'm not sure if its pertaining to particular models. I know Dell in the past has offered their re branded Broadcom wifi with an option of Intel wifi for a £5 premium. No idea if HP does similar. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
On Tue, Sep 14, 2010 at 7:40 PM, Rahul Sundaram wrote: > On 09/14/2010 08:33 PM, pbrobin...@gmail.com wrote: >> >> Thanks for the update. That's what I suspected as it seems to be the >> norm for vendor code dumps. > > It is nevertheless a massive step forward. I heard OEM systems were > favouring other, even slightly more expensive wireless cards because of > the poor Linux support from Broadcom in this particular area and their > change removes one of the major barriers in the near future. I'm not denying the massive step forward, its certainly a valued contribution. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
heads up libchamplain 0.6 headed to rawhide
Subject says it all. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
(lack of) maintainership of epiphany?
I wonder about the maintainer ship of epiphany. The ownership of it is gecko-maint but in none of the current versions of fedora is epiphany gecko based and of the 18 other maintainers not a single person is on the bugzilla watch ACL. There's a bug that was introduced at some point in the F-13 time frame where it crashes on all the machines I attempt to use it on when it first tries to load a page, there's quite a few dupes. I'm really surprised that no one has picked this up. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outage: PHX2 outage - 2010-07-05 01:00 UTC
On Tue, Jul 6, 2010 at 6:02 PM, Mike McGrath wrote: > > There is an ongoing outage at this time in PHX2. The exact start time is > not yet known and the ETA to be fixed is not yet known. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2010-07-05 01:00' > > Reason for outage: > > Several people are experiencing issues connecting to various Fedora > services (see below). The cause for these issues seems to be network > related and it is impacting different people differently. Some see packet > loss, other see complete connectivity loss and other still aren't having > any issues at all. > > Some services listed as unaffected would have been impacted previously to > this announcement but as we became aware of the issue have made some > changes to bring those services back online. Those services include > bodhi, the account system, pkgdb, main website/wiki, community and > mirrormanager. > > Affected Services: > > Bodhi - https://admin.fedoraproject.org/updates/ > Buildsystem - http://koji.fedoraproject.org/ > CVS / Source Control > DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Wouldn't having the two only primary DNS servers involved in the outage affect the services below as well? Is there a reason both DNS servers are in the one DC? > Unaffected Services: > > Fedora Account System - https://admin.fedoraproject.org/accounts/ > Fedora Community - https://admin.fedoraproject.org/community/ > BFO - http://boot.fedoraproject.org/ > Docs - http://docs.fedoraproject.org/ > Fedora Hosted - https://fedorahosted.org/ > Fedora People - http://fedorapeople.org/ > Fedora Talk - http://talk.fedoraproject.org/ > Main Website - http://fedoraproject.org/ > Mirror List - https://mirrors.fedoraproject.org/ > Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ > Package Database - https://admin.fedoraproject.org/pkgdb/ > Smolt - http://smolts.org/ > Spins - http://spins.fedoraproject.org/ > Start - http://start.fedoraproject.org/ > Torrent - http://torrent.fedoraproject.org/ > Translation Services - http://translate.fedoraproject.org/ > Wiki - http://fedoraproject.org/wiki/ > > > Ticket Link: > > https://fedorahosted.org/fedora-infrastructure/ticket/2255 > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to > track the status of this outage. Regards, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap: 612384, 612076
On Fri, Jul 9, 2010 at 9:33 AM, Shakthi Kannan wrote: > Hi, > > I have two new packages for review: > > teal: > https://bugzilla.redhat.com/show_bug.cgi?id=612384 > > ghc-feldspar-language: > https://bugzilla.redhat.com/show_bug.cgi?id=612076 > > Anyone interested in review swap? I'm happy to take them if you could take 610842 and 610794. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
Hi Chen, As I'm the MeeGo maintainer let me outline my thoughts and reasoning behind my MeeGo strategy. > I intend to review two meego-related packages[1][2], but I'm confused > with which package name will be more appropiate. > [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 > [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 All moblin packages will be renamed to meego. Whether that is all during the F-14 timeframe or isn't completed until F-15 I'm not sure yet. All new packages I intend to call meego as I don't see the point in reviewing them now and renaming them in a month or two, possibly less. > The packager is determined to package meego 1.0 packages for F14 which > means we need to package old versions instead of latest upstream > version. Meego 1.0 still use old package name moblin-* the same as > moblin 2.1 for all of its packages. Howerver, upstream renamed all of > those package to meego-* in meego 1.1 which will be released in Oct. > 2010. No I'm not determined to package MeeGo 1.0 for F-14. So please don't change what I have said. In the short term I plan to package MeeGo 1.0 for the alpha so that there is something for people to start testing with. There's currently very little in the MeeGo 1.1 release and there's a lot of churn due to the renaming upstream which is and will cause us problems. So once F-14 alpha is out and the F-14/rawhide branch has taken place I can then do all the rename breakage in F-15 and get the 1.1 package deps shake up stabilized there while people can continue to test some stuff in MeeGo 1.0 in the F-14 branch where its hopefully slightly stable and some of the other things that have changed from Moblin 2.1 to 1.0 have changed and can be closely tested. Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build and tag it quickly and simply into F-14. > I want to ask if it's appropiate to use new package name meego-* > instead of moblin-* for meego 1.0 packages. > > e.g. > meego-panel-devices > Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to > meego-panel-devices[4] in meego 1.1. If we intend to package version > 0.1.30, then which name will be more appropriate? > > [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-panel-devices-0.1.30-1.1.src.rpm > [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-devices-0.2.1-1.2.src.rpm > > Note: > It seems upstream will not rename those packages to meego-* in meego 1.0. No, but that was due to time and QA in the lead up to release. We don't need to follow 100% what they do and I don't see the point in 2 package reviews for the one package in less than a month. The upstream git even for the 1.0 release is called meego, its clearly stated in the upstream the direction the package names are going so I don't see what the issue is. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
Hi Chen, As I'm the MeeGo maintainer let me outline my thoughts and reasoning behind my MeeGo strategy. > I intend to review two meego-related packages[1][2], but I'm confused > with which package name will be more appropiate. > [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 > [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 All moblin packages will be renamed to meego. Whether that is all during the F-14 timeframe or isn't completed until F-15 I'm not sure yet. All new packages I intend to call meego as I don't see the point in reviewing them now and renaming them in a month or two, possibly less. > The packager is determined to package meego 1.0 packages for F14 which > means we need to package old versions instead of latest upstream > version. Meego 1.0 still use old package name moblin-* the same as > moblin 2.1 for all of its packages. Howerver, upstream renamed all of > those package to meego-* in meego 1.1 which will be released in Oct. > 2010. No I'm not determined to package MeeGo 1.0 for F-14. So please don't change what I have said. In the short term I plan to package MeeGo 1.0 for the alpha so that there is something for people to start testing with. There's currently very little in the MeeGo 1.1 release and there's a lot of churn due to the renaming upstream which is and will cause us problems. So once F-14 alpha is out and the F-14/rawhide branch has taken place I can then do all the rename breakage in F-15 and get the 1.1 package deps shake up stabilized there while people can continue to test some stuff in MeeGo 1.0 in the F-14 branch where its hopefully slightly stable and some of the other things that have changed from Moblin 2.1 to 1.0 have changed and can be closely tested. Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build and tag it quickly and simply into F-14. > I want to ask if it's appropiate to use new package name meego-* > instead of moblin-* for meego 1.0 packages. > > e.g. > meego-panel-devices > Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to > meego-panel-devices[4] in meego 1.1. If we intend to package version > 0.1.30, then which name will be more appropriate? > > [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-panel-devices-0.1.30-1.1.src.rpm > [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-devices-0.2.1-1.2.src.rpm > > Note: > It seems upstream will not rename those packages to meego-* in meego 1.0. No, but that was due to time and QA in the lead up to release. We don't need to follow 100% what they do and I don't see the point in 2 package reviews for the one package in less than a month. The upstream git even for the 1.0 release is called meego, its clearly stated in the upstream the direction the package names are going so I don't see what the problem is. Hopefully the outline above will give you further insight into my strategy. Regards, Peter BTW this discussion is better off for the mini list as I mentioned previously so I'ved added it as a CC Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
On Fri, Jul 9, 2010 at 2:21 PM, Chen Lei wrote:
> 2010/7/9 pbrobin...@gmail.com :
>> Hi Chen,
>>
>> As I'm the MeeGo maintainer let me outline my thoughts and reasoning
>> behind my MeeGo strategy.
>>
>>> I intend to review two meego-related packages[1][2], but I'm confused
>>> with which package name will be more appropiate.
>>> [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794
>>> [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842
>>
>> All moblin packages will be renamed to meego. Whether that is all
>> during the F-14 timeframe or isn't completed until F-15 I'm not sure
>> yet. All new packages I intend to call meego as I don't see the point
>> in reviewing them now and renaming them in a month or two, possibly
>> less.
>>
>>> The packager is determined to package meego 1.0 packages for F14 which
>>> means we need to package old versions instead of latest upstream
>>> version. Meego 1.0 still use old package name moblin-* the same as
>>> moblin 2.1 for all of its packages. Howerver, upstream renamed all of
>>> those package to meego-* in meego 1.1 which will be released in Oct.
>>> 2010.
>>
>> No I'm not determined to package MeeGo 1.0 for F-14. So please don't
>> change what I have said. In the short term I plan to package MeeGo 1.0
>> for the alpha so that there is something for people to start testing
>> with. There's currently very little in the MeeGo 1.1 release and
>> there's a lot of churn due to the renaming upstream which is and will
>> cause us problems. So once F-14 alpha is out and the F-14/rawhide
>> branch has taken place I can then do all the rename breakage in F-15
>> and get the 1.1 package deps shake up stabilized there while people
>> can continue to test some stuff in MeeGo 1.0 in the F-14 branch where
>> its hopefully slightly stable and some of the other things that have
>> changed from Moblin 2.1 to 1.0 have changed and can be closely tested.
>> Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build
>> and tag it quickly and simply into F-14.
>>
>>> I want to ask if it's appropiate to use new package name meego-*
>>> instead of moblin-* for meego 1.0 packages.
>>>
>>> e.g.
>>> meego-panel-devices
>>> Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to
>>> meego-panel-devices[4] in meego 1.1. If we intend to package version
>>> 0.1.30, then which name will be more appropriate?
>>>
>>> [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-panel-devices-0.1.30-1.1.src.rpm
>>> [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-devices-0.2.1-1.2.src.rpm
>>>
>>> Note:
>>> It seems upstream will not rename those packages to meego-* in meego 1.0.
>>
>> No, but that was due to time and QA in the lead up to release. We
>> don't need to follow 100% what they do and I don't see the point in 2
>> package reviews for the one package in less than a month. The upstream
>> git even for the 1.0 release is called meego, its clearly stated in
>> the upstream the direction the package names are going so I don't see
>> what the issue is.
>>
>> Peter
>> --
>
> Sounds reasonable to me, but the version you packaged actually are
> still moblin-* [1] instead of meego-* regardless of what repo names
> they use, it's unacceptable under most circumstance.
I don't believe it is unacceptable and you didn't read my points above.
> [1]http://pbrobinson.fedorapeople.org/meego-panel-zones.spec
> %files -f moblin-panel-zones.lang
> %defattr(-,root,root,-)
> %doc COPYING README
> %{_libexecdir}/moblin-panel-zones
> %{_datadir}/dbus-1/services/org.moblin.UX.Shell.Panels.zones.service
> %{_datadir}/mutter-moblin/panels/moblin-panel-zones.desktop
> %{_datadir}/moblin-panel-zones/
>
>
> Another thing confused me is why you want to use git snapshot instead
> of upstream tarball in src.rpm. It seems like you rely on the git SHA1
> on the particular tags in the meego 1.0 branch, but it's very hard to
> track upstream in this way.
I'm using the tags from git due to the lack of properly URL
referenceable tar file releases as required by the packaging
guidelines. git is actually generally easier to follow and I'm working
with upstream to ensure consistent tagging. Scripts help there.
> e.g. meego-panel-zones
>
> The latest tag in meego 1.0 branch is 0.1.18[2] which is also the
> version you choose to package. Howerver, up
Re: Naming issue for meego 1.0 related packages
On Sun, Jul 11, 2010 at 12:52 PM, Michel Alexandre Salim wrote: > On Sat, Jul 10, 2010 at 9:27 PM, Chen Lei wrote: >> 2010/7/10 pbrobin...@gmail.com : >>> Yes, but most of the Netbook side of things are from Moblin. Also if >>> you look at a lot of the clutter/mx and other stuff they now do make >>> tarballs and in some cases only in the last weeks. Don't rule it out. >>> After all they cut tar files for the rpms, all they have to do it >>> publish them separately. In the Moblin case it was just resources that >>> stopped them originally and they eventually started to do it. >>> >> Historically, moblin VCS have the function of making tarballs >> automatically, but they don't publish them to some other places for >> downloading. Meego moved all those packages to gitorious now, it seems >> like gitorious don't have the same function, so I think we can hardly >> assume meego will publish all tarballs soon based on the fact that a >> few widely-used packages(e.g. clutter mx qt pyside) in gitorious >> release tarballs publicly now. By the way, those well-known packages >> don't belong to meego project now, they all have seperate website. >> Except there's a change in the infrastructure of gitorious, I think >> using tarballs from upstream's SRPM is a better choice than pulling >> source from git repo directly. >> > I experienced this recently with another project (openSUSE's build > service client) -- GitHub lets you download a project's tagged > snapshots as tarballs, but Gitorious does not have this functionality. > > I'll have to agree with Chen Lei here. It would be much easier to > upstream bug reports -- so people running MeeGo can easily verify them > -- if the same tarball is used to build the software in the first > place. I don't agree with the easier, and the releases are all built on tags. Well someone will have to get the policy added to the packaging guidelines. There's guidelines for using VC repos but not for using tar files from other distros source packages. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, Jul 7, 2010 at 9:29 PM, Tom "spot" Callaway wrote: > Hello Fedora! > == > > Okay. Here's the list of packages that I think might be affected by > this. Reminder: You need to check these packages and fix any which need > fixing, then email me and let me know which ones you checked/fixed. > Thanks! > [pbrobinson] csound: csound-javadoc-5.10.1-17.fc13.x86_64 > [pbrobinson] xapian-core: xapian-core-libs-1.2.0-3.fc14.x86_64 Both of the above are fixed. > [pbrobinson] xapian-bindings: xapian-bindings-python-1.2.0-2.fc14.x86_64 > xapian-bindings-ruby-1.2.0-2.fc14.x86_64 These two both have license files included. > [pbrobinson] syncevolution: 1:syncevolution-libs-1.0-2.fc14.x86_64 This one is fixed and the fix committed to cvs but there's issues with builds due to moving around of include files in gtk2 and associated for gnome-3. Once I have confirmation that issue is fixed I'll push a new build. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (lack of) maintainership of epiphany?
On Mon, Jul 19, 2010 at 11:14 AM, Bastien Nocera wrote: > On Fri, 2010-07-09 at 23:28 +0200, Andreas Tunek wrote: >> 2010/7/7 Andreas Tunek : >> > On Tue, 2010-07-06 at 16:24 -0700, Adam Williamson wrote: >> >> On Tue, 2010-07-06 at 13:59 +0100, pbrobin...@gmail.com wrote: >> >> > I wonder about the maintainer ship of epiphany. The ownership of it is >> >> > gecko-maint but in none of the current versions of fedora is epiphany >> >> > gecko based and of the 18 other maintainers not a single person is on >> >> > the bugzilla watch ACL. There's a bug that was introduced at some >> >> > point in the F-13 time frame where it crashes on all the machines I >> >> > attempt to use it on when it first tries to load a page, there's quite >> >> > a few dupes. I'm really surprised that no one has picked this up. >> >> >> >> I thought I had, but it may have been something I filed under 'poke >> >> someone about later when I'm not so busy'... >> >> >> >> To me it would seem to make sense for the desktop team to own it, since >> >> it's a part of GNOME. >> >> -- >> > >> > I can't use Epiphany at all in F12 due to this bug: >> > https://bugzilla.redhat.com/show_bug.cgi?id=592685 >> > >> > Haven't had any problems in F13 yet though... >> > >> >> Now I get problems in F13, see >> https://bugzilla.redhat.com/show_bug.cgi?id=603358 > > FWIW, it looks like a WebKitGTK bug when launching pretty much any > plugin. Best to try and reproduce the problem with another WebKitGTK > browser, and update the bug with actual reproducer instructions. Its certainly related to plugins. I don't have flash installed but I did have java installed. Now I don't and it doesn't crash. It worked fine with the original F-13 release so its regressed along the way but it does work with no plugins OK. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc heads up
On Thu, Jul 22, 2010 at 7:51 AM, Mamoru Tasaka wrote: > Richard W.M. Jones wrote, at 07/22/2010 03:45 PM +9:00: >> On Wed, Jul 21, 2010 at 10:54:32AM -0500, Dennis Gilmore wrote: >>> right now a glibc build is going on that has --enablekernel=2.6.32 >>> >>> from Jakub >>> >>> Bumping that from 2.6.18 used currently means e.g. to get rid of compat >>> bloat for private futexes, utimensat, fallocate, O_CLOEXEC/pipe2 etc. (lots >>> of cloexec/nonblocking stuff), ADJ_OFFSET_SS_READ, accept4, realtime clocks >>> in futexes, missing AT_RANDOM, preadv/pwritev, F_GETOWN_EX. >>> >>> Especially private futexes and the cloexec/nonblock stuff affects quite a >>> lot of glibc code. >> >> At least it'll indirectly "fix" the broken preadv emulation bug: >> >> http://www.mail-archive.com/qemu-de...@nongnu.org/msg25242.html >> >>> what this does mean is that you can no longer use rhel5 to build fedora 14 >>> and newer packages. though you had to jump though hoops already to do this >> >> Won't this break Koji builds? I thought they were still done on >> RHEL 5. >> >> Rich. >> > > Well, as I firstly thought so, I tried scratch build with adding "uname -a" > and > it returned the below, for example. > > Linux x86-09.phx2.fedoraproject.org 2.6.32-44.el6.x86_64 #1 SMP Wed Jul 7 > 15:47:50 EDT 2010 i686 i686 i386 GNU/Linux I seem to remember they are running RHEL-5 with a customer later kernel version. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Tue, Jul 27, 2010 at 11:08 PM, Mike McGrath wrote: > On Tue, 27 Jul 2010, Athmane Madjoudj wrote: > >> On 07/27/2010 10:53 PM, Rahul Sundaram wrote: >> > Hi, >> > >> > Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released >> > recently and I am wondering if we can go with it if it fits into the >> > schedule. There are dozens of new features including WebM support that >> > would be nice to have. >> > >> > Rahul >> >> The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at >> 26 Oct 2010 >> >> I think, it's OK to have ff4 in F14, and better is IMHO is to have a >> parallel installation, something like: >> >> firefox3-3.x.x >> firefox-4.x.x >> >> Sources: >> >> [1] https://wiki.mozilla.org/Releases >> [2] http://fedoraproject.org/wiki/Releases/14/Schedule >> > > -1 didn't the last time we started using a pre-release from Mozilla turn > out pretty bad for us? well the last beta I presume your talking about is a certain mail client. The last time we shipped a beta firefox for release I think was for firefox 3 and it was something like beta6 with the official release coming out shortly after and from my memory the beta was relatively stable and a reasonable win in terms of performance. There was some discussion about it but I don't remember anything to the tune of thunderbird. The xulrunner dependents are obviously an issue but with gnome 3 and the move to webkit it rules out the vast majority of them and I'm not even sure thunderbird uses the offset xulrunner (but its likely there are others that do need review). Peter Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/23/2010 11:54 PM, Jesse Keating wrote: >> The conversion will take a couple days, which means our normal short >> outage for branching will be a bit extended. I wish there was another >> way, but converting over 9K cvs repos into git repos does take some >> time. I really feel that this move is worth the extended outage. > > The conversion process has begun. We have just over 10K repos to > convert, and nearly 200 are done already. I'm employing a second host > to help conversion to cut down on the over all outage time. > > I was not able to get a fedpkg (fedora-packager) build out today, > however as soon as that repo is converted and we get the koji changes in > place to build from git we will use that as a test build and get the > updated fedpkg into your hands. > > I've also started on some wiki work to change some CVS pages, but much > more will come. Any help here is appreciated. So once the package is converted is the git repo read/write so we can begin updates or is it all down until the conversion is complete? Also is there a wiki page outlining the rough conversion from old to new commands and other such policy/procedure changes? Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
On Wed, Jul 28, 2010 at 4:37 PM, Paul W. Frields wrote: > On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote: >> On 28/07/2010 14:52, Mike McGrath wrote: >> > In my opinion including software that even upstream says is not ready is >> > for a distribution that's "lost their way". We can still be a leading >> > distribution and not include pre-release software. Especially pre-release >> > software that's not only in our critical path, but also something that >> > almost all of us use every day. >> I agree, but doesn't that mean that Firefox 4.0 won't be available in >> F14 at all and will only be in F15? >> I think it would be a huge drawback for Fedora 14. > > It would be huge if there people who can't live without it didn't have > any other way of getting it than having it pre-packaged. I think > Firefox 4 looks to be fantastic, but the truth is that people only > have to wait a few months for a release with it pre-packaged, if > they're not able to add it on their own. Well if the mozilla maintainers would get it into rawhide shortly after the F-14 branch it would mean that people could get it from the F-15 repos. For years I've used or recompiled srpm rawhide packages that I've wanted/needed in a stable release. This has included firefox and even evolution. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/23/2010 11:54 PM, Jesse Keating wrote: >> The conversion will take a couple days, which means our normal short >> outage for branching will be a bit extended. I wish there was another >> way, but converting over 9K cvs repos into git repos does take some >> time. I really feel that this move is worth the extended outage. > > The conversion process has begun. We have just over 10K repos to > convert, and nearly 200 are done already. I'm employing a second host > to help conversion to cut down on the over all outage time. Is there a running status report somewhere? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Thu, Jul 29, 2010 at 7:04 PM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/29/2010 07:14 AM, pbrobin...@gmail.com wrote: >> On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 07/23/2010 11:54 PM, Jesse Keating wrote: >>>> The conversion will take a couple days, which means our normal short >>>> outage for branching will be a bit extended. I wish there was another >>>> way, but converting over 9K cvs repos into git repos does take some >>>> time. I really feel that this move is worth the extended outage. >>> >>> The conversion process has begun. We have just over 10K repos to >>> convert, and nearly 200 are done already. I'm employing a second host >>> to help conversion to cut down on the over all outage time. >> >> Is there a running status report somewhere? >> >> Peter > > Not really, but I can give a quick update. > > Over 10K repos have been converted, but I do have to run a script over > those repos and make sure the conversion actually "succeeded". We've > also gotten dist-f14, dist-f13, dist-f12, and el6 in a state that we can > build with, however we do have to do some bootstrapping of el4/5. I > have yet to look at OLPC-2/3. Completely ignore OLPC* they are historical and are no longer used. > We have run into some trouble with the kernel repo so I'm attempting > some different conversion options, with a final fallback position of > creating empty git repos and importing the last built srpms for each branch. > > We've also identified some issues with gitweb that we are working on, > however this is not critical functionality and can be set aside until > after the outage. > > Today's work will consist of getting el4/5 buildable, getting updates > pushed with a good production build of fedpkg, mass branching git and > turning on the buildsystem again. Cool. With the last moment of python there's some breakages that would be nice to get fixed. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Thu, Jul 29, 2010 at 8:15 PM, Jesse Keating wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/29/2010 11:48 AM, pbrobin...@gmail.com wrote:
>> Completely ignore OLPC* they are historical and are no longer used.
>
> I see active build targets in koji for dist-olpc{2,3,4},
> olpc2-{ship2,trail3,update1}. Are you saying we could remove all of
> these targets?
active build targets in koji?
OLPC-2 from memory was Fedora 7 based. OLPC-3 was possibly Fedora 9
and OLPC-4 was aimed from memory at F-10 but was the one that was
cancelled. The current supported build is based on F-11.
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 4:55 AM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten a number of > contributions. More will come as it starts to be more widely used. The > biggest challenge with fedpkg is removing the need to update something > on the end user's system every single time we added a new Fedora release > and changed what happens when you build for rawhide. I'll spare you the > details but I'm fairly happy with what we have. The end result should > be far fewer misfires and
Re: Fedora 14 branching and dist-git roll out
On Fri, Jul 30, 2010 at 10:08 AM, Chen Lei wrote: > 2010/7/30 Remi Collet : >> Le 30/07/2010 01:07, Jesse Keating a écrit : >> >>> https://fedoraproject.org/wiki/Using_Fedora_GIT >>> >>> We just might finish up before the 48 hour window is up! >>> >> >> Thanks for that great work ! >> >> Just updated my first package. No issue :) >> >> >> >> Could be usefull to have a tips (in the wiki page) on how to apply >> change from a branch to another. >> >> I'm not a git expert, but I used >> >> fedpkg switch-branch f14 >> git cherry-pick -e xx >> git push origin f14:f14/master >> fedpkg build >> >> I don't know if this is the better solution, but it works. >> It seems I can't do this using fedpkg command. >> > > It seems there's a small bug in fedpkg, when we switch to a branch > using 'fedpkg switch-branch', we can't use 'git push' directly. I > think 'fedpkg switch-branch f14' should set up brancn f14/master > instead of f14, otherwise we can't push changes easily. Its a known problem. There's a means to work around it listed in the yellow box at the top of this page https://fedoraproject.org/wiki/Using_Fedora_GIT Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 11:06 AM, Peter Lemenkov wrote: > Great news! > > Few questions still remains unanswered for me: > > * Should I use git now? > * May I still use cvs? > * If I'll add some changes right now using git/cvs will they be > available in cvs/git respectively? > * I just noticed that some freshly cloned git repositories are about > one month old (namely, couchdb) - do I need to wait until final > synchronization before using git for them? I think you need to get the latest package from koji so it points to the live git repos and not the test ones. I had similar issues when I tested it first up but fedora-packager-0.5.1.0-1 seems to have fixed it. I believe its all git now and cvs is read only. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wordpress testers needed!
On Mon, Aug 2, 2010 at 6:31 PM, Jon Ciesla wrote: > In an effort to try to reduce and eliminate Wordpress's reliance on > bundled PHP libraries, I've produced some test builds. If someone > familiar with administering Wordpress and Wordpress-mu could test to > make sure the changes don't break anything and let me know, what would > be wonderful and appreciated. What build in what tree do you want tested? Also I think that with wordpress 3 the separate wordpress-mu release fork has been merged into mainline. So wouldn't it be better to concentrate on wordpress 3? Peter > https://fedorahosted.org/fesco/ticket/314 > https://bugzilla.redhat.com/show_bug.cgi?id=544720 > https://bugzilla.redhat.com/show_bug.cgi?id=544721 > http://zanoni.jcomserv.net/fedora/wordpress/ > http://zanoni.jcomserv.net/fedora/wordpress-mu/ > > -- > - in your fear, speak only peace > in your fear, seek only love > > -d. bowie > > -- > 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: Is PulseAudio dead?
On Mon, Aug 2, 2010 at 6:25 PM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/2/10 9:52 AM, Robert 'Bob' Jensen wrote: >> People have had this complaint since PA was forced on to the Fedora users. > > > Language such as this is not being excellent to each other. It's > unnecessarily antagonistic. Please stop. Nor was Lennart's BTW message either to be fair. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
On Mon, Aug 2, 2010 at 8:50 PM, Mike McGrath wrote: > On Mon, 2 Aug 2010, Robert 'Bob' Jensen wrote: > >> >> - "Carl G." wrote: >> > Well, i'm happy to be a bug triager so >> > you can get "real work" done. /s >> > >> > Let me know if you need some help to >> > make the stats looks pretty. >> >> Thank You Carl, this will help the community a lot and is a perfect example >> of why public emails work. >> > > I think what Bob is meaning to point out is that it does seem like risky > behavior for the upstream of a core system in Fedora to stop developing it > and start developing a new core system. It's not 100% clear that's what > is going on, but the thread that's been started does provide evidence that > might be happening. > > Do we know if PulseAudio upstream is still self sustaining and healthy and > that this lapse response is just a temporary thing? It's a legitimate > concern considering how critical PA is. While Lennart has moved onto bigger and better things, which isn't a bad thing, it seems that the maintainership of PA in Fedora hasn't moved on to other maintianers or at least if Lennart is interested in maintaining it he hasn't aquired someone to assist in co-maintenance. Nor does it seem the case with alot of other fedora desktop packages. If you want to look at other main line desktop packages that don't seem to have active maintainer ship look at the webkit thread from the last day or so. And there are others that come to mind that don't seem to be actively maintained. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
On Mon, Aug 2, 2010 at 11:37 PM, Lennart Poettering wrote: > On Mon, 02.08.10 23:09, pbrobin...@gmail.com (pbrobin...@gmail.com) wrote: > >> >> On Mon, Aug 2, 2010 at 8:50 PM, Mike McGrath wrote: >> > On Mon, 2 Aug 2010, Robert 'Bob' Jensen wrote: >> > >> >> >> >> - "Carl G." wrote: >> >> > Well, i'm happy to be a bug triager so >> >> > you can get "real work" done. /s >> >> > >> >> > Let me know if you need some help to >> >> > make the stats looks pretty. >> >> >> >> Thank You Carl, this will help the community a lot and is a perfect >> >> example of why public emails work. >> >> >> > >> > I think what Bob is meaning to point out is that it does seem like risky >> > behavior for the upstream of a core system in Fedora to stop developing it >> > and start developing a new core system. It's not 100% clear that's what >> > is going on, but the thread that's been started does provide evidence that >> > might be happening. >> > >> > Do we know if PulseAudio upstream is still self sustaining and healthy and >> > that this lapse response is just a temporary thing? It's a legitimate >> > concern considering how critical PA is. >> >> While Lennart has moved onto bigger and better things, which isn't a >> bad thing, it seems that the maintainership of PA in Fedora hasn't >> moved on to other maintianers or at least if Lennart is interested in >> maintaining it he hasn't aquired someone to assist in co-maintenance. >> Nor does it seem the case with alot of other fedora desktop packages. >> If you want to look at other main line desktop packages that don't >> seem to have active maintainer ship look at the webkit thread from the >> last day or so. And there are others that come to mind that don't seem >> to be actively maintained. > > I haven't "moved on". > > In contrast to PA systemd is a project whith an "end". i.e. there's a > certain point not so far away, where it is "complete", i.e. where it > will go into maintaince mode where additional features will be added > only every now and then. This is different for PA which is basically an > "endless" project where constantly a module for a new policy, a new > device type, a new effect, a new codec, or other piece of infrastructure > will have to be added and worked on. > > It's basically the dichotomy of "cat" vs. a text editor. When "cat" is > implemented, then there's very little to add to it over the years. OTOH > text editors will gain features all the time. > > I have been working continously on PA and related techs for the last > years. And now I have this smaller side project called "systemd", whose > feature set is already complete. What's missing is cleaning it up for > the distros and fixing the bugs. When that is done I will return > full-time to work on PA. > > So, I guess what I want to say is: I will return full-time to PA not so > far away. And I have a queue of patches in my checkout (including volume > ramping and plug-in effects and similar). Also note that I'll run the > track about audio at plumbersconf again, so there's really no reason to > believe that I moved on or PA was dead. Which is great and I understand that but systemd will basically cover the release time frame for F-13 and F-14 and in that timeframe the support and issues for PA are going unfixed or even un triaged. Not great for a core sub system. So maybe it would be a good idea to train up a few people that can do the boring trage so you can get on with the upstream PA and systemd stuff so that the average end user doesn't need to wait for the bottle neck of a single person because presumably with other distros using it Fedora isn't the only distro demanding your time. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
