Re: ABRT useful for this user
On Mon, Jan 18, 2010 at 01:59:27PM -0700, Stephen John Smoogen wrote: > I just wanted to say thanks to the guys who integrated ABRT into F12. > It has rough edges and I know it needs improvement, but I have filed > more 'bugs' than in many past releases where instead I just let things > slide. Most of the items I have run into have been fixed and I have > tried to help the engineers who have asked for info. > > Thankyou. I don't think anyone, including the guys working on ABRT, would claim it's perfect. *Except* in that it's 100% better than what we had before. ;-) I'm in the same boat as Smooge; ABRT is a huge time saver for me for filing bugs, which means I can contribute more, even when filing bugs is really outside my daily work. That tells me it's a significant step down the right path. I know the developers are grateful for constructive input and want to improve ABRT. Thanks to *everyone* for being a part of that process. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mirrorlist problems?
On Tue, Jan 19, 2010 at 09:10:01PM -0600, Mike McGrath wrote: > On Wed, 20 Jan 2010, Robert 'Bob' Jensen wrote: > > > > > - "Andrew McNabb" wrote: > > > > > I just installed a new machine with Fedora 12 this evening, and > > > Anaconda > > > gave an error about not being able to get the repository metadata. I > > > ended up switching the URL from the default mirrorlist to a specific > > > mirror, and the installation worked. Now that the system is > > > installed, > > > I tried to use yum and got the error: "Error: Cannot retrieve > > > repository > > > metadata (repomd.xml) for repository: fedora. Please verify its path > > > and > > > try again". Are there any known infrastructure problems right now? > > > Thanks. > > > > > > > A user in #fedora reported an issue like this with the RPM Fusion repo > > however his was a 503 error. > > > > I couldn't recreate, can anyone else? Could it have been this problem? http://lists.fedoraproject.org/pipermail/users/2010-January/364162.html http://lists.fedoraproject.org/pipermail/users/2010-January/364174.html The solution Richard Hughes gave appears to have worked for the OP in that thread, but I don't know the particular cause. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New merge review tickets being opened
On Wed, Jan 27, 2010 at 05:49:07PM -0600, Jason L Tibbitts III wrote: > >>>>> "BN" == Bill Nottingham writes: > > BN> There is a new internal process that encourages that packages have > BN> existing Fedora reviews. > > Please define "internal". If this is some Red Hat internal thing, don't > you think the community who is being asked to do this work should at > least be informed? > > BN> They're reviews of Fedora packages. > > Fedora doesn't have any policy which requires reviews of these > packages. Fedora doesn't have the manpower to do re-reviews of packages > at this time. > > BN> If the queue's not being processed quickly, the queue won't be > BN> processed quickly. > > And you don't see any negative effects from this? Really? What about > people with submissions just sitting around? > > BN> If these reviews need quick attention, then I suspect resources will > BN> need to be assigned to them. > > Assigned by whom? Again, if this is a Red Hat internal thing, please > handle it within Red Hat or please at least talk to the community about > it. > > BN> I'm not convinced that adding 12 packages to the queue (the current > BN> count of these) is anything to worry about, given that we get more > BN> new submissions than that per week already without any other > BN> controls. > > Because we get a lot of submissions we're buried under, throwing a bunch > of pointless ones on top won't hurt? Come on, at least get someone to > talk to us about this. I've discussed this with the team that filed these reviews, and all these bugs should now be assigned to Red Hat people, where they properly belong. The intention was never to dump these reviews on volunteers, but rather for the engineers in the process to collaborate with each other on the reviews. The net benefit to Fedora is that hopefully we get packages in Fedora the upstream that are incrementally improved. So if you see that any of these new tickets *aren't* assigned, please let the list know and either Bill or I will get that taken care of immediately. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines
On Thu, Jan 28, 2010 at 12:50:31PM -0500, Matthias Clasen wrote: > On Wed, 2010-01-27 at 12:00 -0800, John Poelstra wrote: > > A friendly reminder that yesterday, January 26, 2010, we reached the > > Feature and Spin submission deadline. Any new features or spins > > submitted after yesterday will be targeted for Fedora 14. > > > > A summary of the Fedora 13 milestones and exception process is here: > > https://fedoraproject.org/wiki/Important_Release_Milestones > > > > The next significant schedule milestone is Feature Freeze on February 9, > > 2010. At Feature Freeze it is expected that all features are > > *significantly* "feature complete" and ready for testing. > > https://fedoraproject.org/wiki/Feature_Freeze_Policy. > > > > Features which are not significantly feature complete at Feature Freeze > > will be reviewed on an exception basis by FESCo or deferred to Fedora 14. > > > > There is at least one feature which missed this deadline by a day or so, > simply because nobody noticed that it was still sitting on the > FeaturePageIncomplete category: > > http://fedoraproject.org/wiki/Features/NetworkManagerCmdline > > Can we still have that considered for F13, please ? > The code is in rawhide already... Yes, you can file a ticket with FESCo requesting an exception. https://fedoraproject.org/wiki/Features/Policy/Exceptions -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
On Mon, Feb 01, 2010 at 11:16:54AM -0600, Chris Adams wrote: > Once upon a time, Ralf Corsepius said: > > IMO, you are facing a hen-and-egg problem: You've never seen such a > > complaint, because using a separate /usr partition has never worked on > > RH-based distros. > > Please stop repeating this untrue statement. As I told you already, I > have used separate /usr since RHL 3.0.3. I've done this for a long time as well, though only on local disk, no exotic configuration. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- 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 06, 2010 at 11:21:26AM +0100, pbrobin...@gmail.com wrote: > 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? 'man pulse-daemon.conf' reports that using 'trivial' is worst quality but easier on slow machines. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On Thu, Aug 19, 2010 at 01:40:10AM +0200, Lennart Poettering wrote: > On Wed, 18.08.10 19:35, Dave Jones (da...@redhat.com) wrote: > > > > > On Wed, Aug 18, 2010 at 07:00:16PM -0400, Dave Jones wrote: > > > On Thu, Aug 19, 2010 at 12:53:44AM +0200, Lennart Poettering wrote: > > > > > > > > > > It tells me to see the logs for details, but there's not a > > single message > > > > > > > from systemd in the logs. > > > > > > > > > > > > There should be an explanation in dmesg, that it cannot find > > default.target. > > > > > > > > > > at the stage that it stopped, I guess syslog wasn't running, so it > > never made > > > > > it into the boot logs. > > > > > > > > Hmm, could be. Note that we log to kmsg as long as syslog isn't up, so > > > > nothing should get lost -- as long as you manage to get a shell > > somehow. > > > > > > > > BTW, as a side note: a simply fix to bypass the problem with a missing > > > > default.target is to pass "5" on the kernel command line. This will > > then > > > > boot into gdm regardless whether default.target exists or not. > > > > > > > > the git version of systemd will automatically enter signle user mode > > if > > > > default.target is missing or borked. > > > > > > So I got it booting after creating the default.target symlink, but the > > network > > > no longer comes up automatically (nor services dependant upon it, like > > sshd). > > > Did I miss another mail ? > > > > related to this I guess ? > > > > [ 44.659412] init[1]: Failed to load configuration for > > NetworkManager-by-dbus.service: No such file or directory > > [ 44.659596] init[1]: D-Bus activation failed for > > NetworkManager-by-dbus.service: Invalid argument > > Yupp, If any of the problems being discussed are common to people who will install F14 Alpha, can I ask you guys to put some information on the Common F14 bugs page please? https://fedoraproject.org/wiki/Common_F14_bugs Thanks. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 12:59:57PM -0700, Adam Williamson wrote: > On Tue, 2010-08-24 at 15:40 -0400, Matthew Miller wrote: > > > This *is* happening, and we need to tread carefully, because once you loose > > respect and reputation, it is very, very hard to get back. > > I really think you're extrapolating too far from some very limited data > here. You have some statistics which indicate that Fedora usage is > declining. You are extrapolating from this to the conclusion that this > is happening because Fedora changes too rapidly. I don't think your data > support your conclusion; I haven't seen you cite any data in support of > your assumption as to the *reason* Fedora usage is declining. I don't think anyone can generalize that the usage of Fedora is declining. What we can prove, and certainly is troublesome, is that yum check-ins of successive releases have been dropping by a couple percent each release (although downloads are actually up), compared on a per-week basis. It's no less likely that this decrease is due to people just staying on a stable release, even past EOL. I've heard anecdotal evidence to support that, which is no more or less valuable than any other anecdotal evidence being presented, I suppose (IOW, probably not worth a thing). If someone can present a hard analysis that points to only one possible scenario, fantastic -- we can start looking at causes. None of the foregoing paragraph is meant to write off concern about watching out for our users. We can innovate, and we can do it with proper care for a wide group of people, including people like Matt who are experienced sysadmins not opposed to change "a priori" (lifting your words, Matt). But we can't innovate at all without trying new things at some point. That point ought to be based on something solid like the acceptance criteria Bill's already writing up. Then FESCo can have more confidence in making a decision about it. I'd rather concentrate on that constructive effort than epidemiologically questionable generalizations. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 08:41:45PM -0500, Mike McGrath wrote: > On Tue, 24 Aug 2010, Jeff Spaleta wrote: > > > On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields > > wrote: > > > I don't think anyone can generalize that the usage of Fedora is > > > declining. What we can prove, and certainly is troublesome, is that > > > yum check-ins of successive releases have been dropping by a couple > > > percent each release (although downloads are actually up), compared on > > > a per-week basis. It's no less likely that this decrease is due to > > > people just staying on a stable release, even past EOL. I've heard > > > anecdotal evidence to support that, which is no more or less valuable > > > than any other anecdotal evidence being presented, I suppose (IOW, > > > probably not worth a thing). If someone can present a hard analysis > > > that points to only one possible scenario, fantastic -- we can start > > > looking at causes. > > > > One additional metric which I'd like to see is the raw number of yum > > check-ins per week regardless of ip-addresses as an historic trend. > > As a stand alone metric its prone to both over and under counting like > > the other metrics but in a different way. It would be interesting to > > see if the raw yum check-in counts as an historic trend followed the > > download trending or the unique-ip trending. > > > > Ask and ye' shall receive. > > http://mmcgrath.fedorapeople.org/yum_hits.html > > I'm not quite sure what to make of it all yet except that this trend does > conflict with the "current release" numbers we have on the statistics page > (indicating people are using Fedora even after EOL) and that security > incidents requiring a rebuild of everything is bad for business, at least > temporarily :) This past week for instance, over 20,000 unique new IPs appeared for Fedora 11: https://fedoraproject.org/w/index.php?title=Statistics&diff=194190&oldid=193660 My hunch is that a couple thousand a week are probably due to cable modems or laptops moving to addresses we simply haven't seen before. That's about how many new IPs appear for Fedora 7 or Rawhide each week. But there's just no way to tell cause other than hunches. The folks who hang out in IRC #fedora as well as users@ list susbscribers can confirm people show up pretty frequently with newly-installed EOL Fedora. My scripts are always available here for reference. http://pfrields.fedorapeople.org/scripts/fedora-log1-statistics-scripts.tar.gz They're based on the command templates that Max originally worked out with Mike, and linked from the [[Statistics]] wiki page: https://fedoraproject.org/wiki/Statistics/Commands If you guys find discrepancies or differences there, let me know; I'm always looking to make these as accurate as possible. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: If you cannot boot after installing systemd v8...
FYI, Fedora 14 Alpha testers: Please read the following, since this update issue will hit you after you install Fedora 14 Alpha and then update. We probably need to spread this news out wider and add to the Common F14 bugs page. On Thu, Aug 26, 2010 at 10:07:42AM +0200, Vaclav Misek wrote: > On 08/26/2010 01:58 AM, Lennart Poettering wrote: > > Heya! > > > > We shifted a few files around and most likely your > > /etc/systemd/system/default.target link will now point into the void, in > > case anaconda wrote it. If that happens to you and you end up in a > > rescue shell instead of a full system after booting with v8, then please > > execute the following: > > > > # ln -sf /lib/systemd/system/graphical.target > > /etc/systemd/systemd/default.target > > > > or > > > > # ln -sf /lib/systemd/system/multi-user.target > > /etc/systemd/systemd/default.target > > > > You can also choose to boot up into a normal system without the correct > > default.target link, by passing "5" resp "3" on the kernel cmdline. > > > > Sorry for breaking this (again), but with this in place things should be > > at the appropriate places now for F14. > > > > The bug against anaconda is already filed. > > > > Lennart > > > Hello Lennart, > it should be > > # ln -sf /lib/systemd/system/graphical.target > /etc/systemd/system/default.target > > or > > # ln -sf /lib/systemd/system/multi-user.target > /etc/systemd/system/default.target > > isn't it? :-) > BTW thanks for systemd. > Kind regards > > sHINOBI > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who broke fedoraproject.org usability?
On Wed, Oct 27, 2010 at 05:37:15PM +0100, Richard W.M. Jones wrote: > On Wed, Oct 27, 2010 at 11:27:07AM -0500, Chris Adams wrote: > > Once upon a time, Michał Piotrowski said: > > > I visited fedoraproject.org site to visit "Fedora Project Wiki". Where > > > is the link to the wiki? It's in page footer. Fedora wiki is > > > _important_ source of information (is the only place known to me where > > > I can find a link to the page when I can find a link to systemd git > > > repo url :)) link should be visible. > > > > > > In any case, a new page looks very nice and modern :) > > > > Well, I went to see what you are talking about, from a F13 system with > > Firefox 3.6.11, and the page is pretty garbled. > > And that picture of Paul Frields (I think) is pretty scary too :-) You didn't see the one they didn't use. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On Thu, Jul 14, 2011 at 01:06:45PM -0400, John Dulaney wrote: > > On Wed, Jul 13, 2011 at 10:06 PM, Reindl Harald wrote: > > > > > > Am 14.07.2011 03:57, schrieb Eric Sandeen: > >>> bleeeding edge / modern technology is not the same as dangerous defaults > >>> unstable / unfinsihed packages should never be default in GA nor replace > >>> existing and over a long time well working things - never! > >> > >> You might have said the same thing about ext4 in F > >> and yet, here we are, shipping it as default for many releases now, with > >> little trouble. > > > > ext4 is not written from scratch and it is a hughe difference > > if we are speaking from a improvement of ext2/ext3 with many > > years history on all sorts of setups (desktop, server, notebook) > > > > the troubles of lost kde settings was enough on crashes and yes > > i had the luck of a system-disk hangig some times exactly as > > this was discussed in a way "POSIX do not say what exactly > > happens after that, it says only the FS must be clean and > > not what data are there or not" > > > > virtual machines this time are really a normal thing and if > > there are hughe troubles now a FS should NOT be DEFAULT in a > > few months - why everytime this hurry? jesus one of the biggest > > benefits of open source is that there ar eno marketing idiots > > with release plans which forcing a release without enough testing > > > > so why do we not need this benefits and fire out permanently > > new technologies in a not understandable hurry? > > > > Dude, what's with always being so negative? All this negative energy > almost makes one think that you're using a Microsoft product to > compose your emails, and that's just not groovy, man. Fedora doesn't > flow with long stable technologies, it embraces the new. And, if you > cannot embrace the new with Fedora (whether it be systemd or btrfs) > then why not go with something archaic, like CentOS? At least > expunge all that negativity, ya know? If you don't like all the new > cool in Fedora, don't go say that things are 'being shoved down our > throats' like you said about systemd. That's just not happening, man. > And, when it comes down to it, you can go join the Cool Cats over at > Slackware; Patrick Volkerding is one very, very cool dude. Then again, > they might not dig the negatrons that you seem to extrude from every > bit of your soul. I agree with keeping things positive; let's also keep the thread oriented on the technical and not the personal. (Informed by facts wherever possible would also be great!) Thanks for pointing out the fact that Fedora's mission includes promoting innovation and rapid advancement. More information is found here: https://fedoraproject.org/wiki/Overview -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to switch branch
On Fri, Jul 15, 2011 at 12:41:50PM +0200, Alain Portal wrote: > Le vendredi 15 juillet 2011 11:16:18, Michał Piotrowski a écrit : > > 2011/7/15 Alain Portal : > > > Le vendredi 15 juillet 2011 10:49:55, Michał Piotrowski a écrit : > > > > > >> What > > >> git show-branch -a > > >> says? > > > > > > Many things! > > > See the attached file. > > > > ! [origin/f15] Don't forget the file... > > This is a previous commit message. > > > > > > >> Can you switch branch with git > > >> git checkout f15 > > >> ? > > > > > > [alain@phoenix kicad]$ git show-branch -a > show-branch.txt > > > [alain@phoenix kicad]$ git checkout f15 > > > Branch f15 set up to track remote branch f15 from origin. > > > Switched to a new branch 'f15' > > > [alain@phoenix kicad]$ git checkout el6 > > > Branch el6 set up to track remote branch el6 from origin. > > > Switched to a new branch 'el6' > > > [alain@phoenix kicad]$ fedpkg switch-branch f15 > > > Switched to branch 'f15' > > > [alain@phoenix kicad]$ fedpkg switch-branch el6 > > > Switched to branch 'el6' > > > > > > So, after a "git checkout $branch" for all branches, a "fedpkg > > > switch-branch $branch" works... > > > > fedpkg switch-branch should be tweaked/fixed IMO. > > Perhaps I have to say that I'm still under F-12. Chances are you're not running the latest fedora-packager code, then. You probably want to either move up to something more recent, or install a VM guest you can use for packaging until you're inclined to move to a later release. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please rebuild your package with latest translation
On Mon, Aug 22, 2011 at 11:26:29AM +0100, Peter Robinson wrote: > On Mon, Aug 22, 2011 at 1:42 AM, Noriko Mizumoto > wrote: > > Dear Fedora package maintainers > > > > To have Fedora 16 high standard in non-English versions, Fedora > > Localization will have our review packages process using the image > > composed specifically for this purpose. This image will be composed > > between 25-26 August. Then many different languages' translators can > > actually install the image, review your package translation quality and > > modify it or file a bug if any before translation deadline. > > > > Therefore, could you please take your latest translation from Transifex > > and rebuild your package with it by then for composing? > > Is there a link to a process on how to do this in wiki? I believe the best docs are probably available at the Transifex help site: http://help.transifex.net/user-guide/ -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 12:18:57PM +, JB wrote: > Richard Hughes gmail.com> writes: > > > > > On 24 August 2011 01:35, JB gmail.com> wrote: > > > ...do not expect them to accept your sick "world domination" drive > > > > ...and this is why some upstream developers have unsubscribed from > > fedora-devel list. Ever wonder why people like David Zeuthen > > unsubscribed? People like you. > > > > I'm also ---> <--- this close to unsubscribing also. > > > > Richard. > > Richard, > > before you do it, read his post again and his insinuations about conspiracies > and other staff ! [...snip...] This thread really is starting to sound like personal vendetta and not worthwhile discussion of technical details. Seriously, cut it out. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCEMENT] Apache HTTP Server 2.2.20 Released
On Wed, Aug 31, 2011 at 05:39:14PM +0200, Reindl Harald wrote: > this update should be really fast pushed out > > the demo-exploit brings down a 4x2.50GHz machine with 8 GB > RAM in some seconds without having the known workarounds > or explicit mod_security-Rules in front > > Original-Nachricht > Betreff: [ANNOUNCEMENT] Apache HTTP Server 2.2.20 Released > Datum: Wed, 31 Aug 2011 07:21:33 -0400 > Von: Jim Jagielski > Antwort an: d...@httpd.apache.org > An: d...@httpd.apache.org > > Apache HTTP Server 2.2.20 Released [...snip...] The security bug is already being tracked: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-3192 I'd expect a new package to be issued shortly. Once that happens, if you want to contribute to pushing this out, be ready to test the fixed package and add karma. The process works when people participate. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCEMENT] Apache HTTP Server 2.2.20 Released
On Wed, Aug 31, 2011 at 08:28:20PM +0200, Reindl Harald wrote: > > > Am 31.08.2011 19:31, schrieb Paul W. Frields: > > On Wed, Aug 31, 2011 at 05:39:14PM +0200, Reindl Harald wrote: > >> this update should be really fast pushed out > >> > >> the demo-exploit brings down a 4x2.50GHz machine with 8 GB > >> RAM in some seconds without having the known workarounds > >> or explicit mod_security-Rules in front > >> > >> Original-Nachricht > >> Betreff: [ANNOUNCEMENT] Apache HTTP Server 2.2.20 Released > >> Datum: Wed, 31 Aug 2011 07:21:33 -0400 > >> Von: Jim Jagielski > >> Antwort an: d...@httpd.apache.org > >> An: d...@httpd.apache.org > >> > >> Apache HTTP Server 2.2.20 Released > > [...snip...] > > > > The security bug is already being tracked: > > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-3192 > > > > I'd expect a new package to be issued shortly. Once that happens, if > > you want to contribute to pushing this out, be ready to test the fixed > > package and add karma. The process works when people participate > > we are in production with > 20 servers on F14 since some hours > own packages with optimized build-flags based on the Fedora-SPEC-File Not sure what this had to do with my reply, but in the meantime you can use the mitigation that Apache sent out. I'm doing that on my own servers for now. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taking a two-week holiday
On Thu, Oct 13, 2011 at 09:19:19PM +0300, Jussi Lehtola wrote: > Hi, > > just to let you know - I'm taking a two-week holiday starting > tomorrow, during which time I probably won't have internet access. So, > don't wonder why I'm not, e.g., attending anything in bugzilla. Thanks Jussi. For your and other contributors' reference, we have a [[Vacation]] wiki page where this information can be added as well. I took the liberty of inserting Jussi's information on the page. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed special F15 schedule meeting
On Wed, Mar 23, 2011 at 12:28:00PM -0700, Adam Williamson wrote: > On Wed, 2011-03-23 at 12:16 -0700, Adam Williamson wrote: > > Hey, all. I'd like to propose a special F15 schedule meeting for later > > today or tomorrow; we'd need representation from QA and releng at a > > minimum, ideally also devel and fpl and rbergeron. > > OK, we're doing this meeting in #fedora-meeting in 3 minutes. :) Sorry > for the absurdly short notice, but it's basically a rubber stamp, the > need to slip is pretty obvious at this point. Do feel free to come > along, especially if you have an alternative perspective to offer. Would be good to post meeting notes as a reply or to the same lists for people to find easily: http://meetbot.fedoraproject.org/fedora-meeting/2011-03-23/fedora-meeting.2011-03-23-19.30.log.html Meeting summary --- * intro / roll call (adamw, 19:30:25) * The Situation (adamw, 19:32:58) * AGREED: we will slip F15 schedule, from Beta TC delivery onwards, * by a week (adamw, 19:38:08) * Implementing slip (adamw, 19:38:18) * ACTION: jsmith to announce slip to appropriate lists etc (adamw, 19:38:51) * ACTION: rbergeron adjust schedules (http://rbergero.fedorapeople.org/schedules/f-15/ ) (adamw, 19:39:25) * any other business (adamw, 19:41:05) Meeting ended at 19:42:04 UTC. Action Items * jsmith to announce slip to appropriate lists etc * rbergeron adjust schedules (http://rbergero.fedorapeople.org/schedules/f-15/ ) Action Items, by person --- * jsmith * jsmith to announce slip to appropriate lists etc * rbergeron * rbergeron adjust schedules (http://rbergero.fedorapeople.org/schedules/f-15/ ) * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (29) * jsmith (7) * dgilmore (5) * liknus (4) * zodbot (2) * rbergeron (2) * Venemo (1) * jlaska (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: shouldn't download directory for install images be called "Install" instead of "Fedora"?
On Sat, Apr 09, 2011 at 04:52:03AM +, Andre Robatino wrote: > Currently the download directories for install and live images are called > "Fedora" and "Live", resp. Shouldn't the former be "Install" instead? After > all, > everything in both directories is Fedora's, so calling one of them "Fedora" > doesn't appear helpful. I'm guessing this isn't the ideal time in the schedule to make this change. But it's worth discussing -- is there a place to capture this such as a rel-eng retrospective or wish list? Side note: any change would also need to make it into other places such as the formal guides produced by Docs team, the wiki, etc. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Red Hat Summit/JBossWorld -- Register now! http://.theredhatsummit.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora-release-notes changing hands
Pursuant to a conversation on the Docs team list, the fedora-release-notes package is going to change ownership hands to its true and rightful owner, jjmcd (John McDonough). He's really been taking care of this package for some time so this is a formality. There are a number of other people on the ACL and commits list so I thought it was worth a heads-up. Don't panic when you see the orphan notices; John has agreed to take ownership already. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Red Hat Summit/JBossWorld -- Register now! http://.theredhatsummit.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need a python3 person for docutils
On Mon, May 16, 2011 at 09:08:07AM -0700, Toshio Kuratomi wrote: > Hey all, Currently docutils is unable to update in Fedora 15 because of bugs > in the python3 compatibility. Is there anyone who cares about python3 here > who is willing to take a look at fixing it? Otherwise, we're stuck on the > current version of docutils (for both python2 and python3) and the python3 > package will be non-functional. > > https://bugzilla.redhat.com/show_bug.cgi?id=579567 FWIW, the build log for the task referenced in the last few comments has possibly expired from Koji, so the actual problem's hard to see. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Red Hat Summit/JBossWorld -- Register now! http://.theredhatsummit.com ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Installing bash-completion by default in F-16
On Fri, Jun 03, 2011 at 07:06:27AM +1000, Brendan Jones wrote: > On 06/03/2011 12:47 AM, Bill Nottingham wrote: > > Moving it to default in @system-tools seems fine to me as a first step. > > However, that's not in the 'default' install (but it would place it on > > the install media.) If it's wanted in the default install, the @base > > group is the best place for it (it doesn't belong in @core.) > > > > systemd includes a bash-completion script for systmctl. Enabling bash > completion by default would then benefit those making the transition to > systemd Similarly for gsettings and dconf. However, I think the trick is mitigating the problems that plague network-connected users. The type of user who opens up a shell to make use of completion functions starts looking a lot more like the type of user who will run into those problems. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Red Hat Summit/JBossWorld -- Register now! http://.theredhatsummit.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning istanbul ahead of F-16.
On Fri, Jun 17, 2011 at 10:48:26AM -0400, Bill Nottingham wrote: > Jeff Spaleta (jspal...@gmail.com) said: > > If you want to pick up maintainership for istanbul let me know. I'm > > going to be retiring this package in about a week. > > What's the preferred screen recorder these days (outside of the shell > easter egg?) There's an excellent tool called byzanz which is written by desktop developer Benjamin Otte. It can record to a variety of formats and I've found it pretty stable. However, it's pretty clearly deprecated by the shell's built-in recorder. (Just wanted to give botte a shout for his work, though.) :-) -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 09:31:39PM +0800, Américo Wang wrote: > Hello, Fedora people, > > Would any of you kindly help to review my proposed feature > for Fedora 16? > > https://fedoraproject.org/wiki/Features/NewMkdumprd In case anyone was wondering, Américo also addressed this to me because I previously gave him some tips on constructing a Fedora feature page. :-) Discuss away! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New feature for Fedora 16: new mkdumprd
On Wed, Jul 13, 2011 at 09:46:30AM -0400, Paul W. Frields wrote: > On Wed, Jul 13, 2011 at 09:31:39PM +0800, Américo Wang wrote: > > Hello, Fedora people, > > > > Would any of you kindly help to review my proposed feature > > for Fedora 16? > > > > https://fedoraproject.org/wiki/Features/NewMkdumprd > > In case anyone was wondering, Américo also addressed this to me > because I previously gave him some tips on constructing a Fedora > feature page. :-) Discuss away! *sigh* Never mind -- I got a copy of this and thought it was addressed to me personally. Need more coffee. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Notice: dnssec-conf updates in Fedora 11 and 12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Fedora Project recently issued an update to the dnssec-conf package, to fix an issue that caused Fedora 11 and 12 systems using BIND (named) to put an inordinately heavy load on RIPE nameservers. However, this update has been found to break some BIND configurations as seen in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=563232 The problem occurs in these packages: dnssec-conf-1.21-3.fc11 dnssec-conf-1.21-7.fc12 To determine if your system is affected, run the following command: rpm -q dnssec-conf If one of the above package descriptors does not appear, your system is not affected and you may safely ignore this message. If you are affected, please continue reading. == Workaround == If you have already accepted this update, you can downgrade the package and start the failed BIND (named) daemon again using these commands: su -c 'yum downgrade dnssec-conf' su -c 'service named start' == Solution == System owners running BIND name servers on Fedora 11 or 12 systems are advised not to accept the specific dnssec-conf pacakge updates listed above. There are several ways to avoid these specific updates. * If you use the PackageKit graphical client, or another graphical client, deselect the dnssec-conf update in the dialog that lists package updates. * If you use the yum command-line client, use this command to exclude dnssec-conf from the list of packages to be updated: su -c 'yum --exclude=dnssec-conf update' == Remediation == A new update is being prepared to address this problem for Fedora 11 and 12 users, and will be pushed to our mirrors as soon as possible. Users who are not running BIND nameservers (named) on their Fedora 11 and 12 can safely disregard this notice. When the new updates are pushed, a follow-up announcement will be made here. At that time, affected system owners can safely accept the replacement updates. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLceHHrNvJN70RNxcRAoY1AKDGuYgvJvoRi6sYpBsl3vbYyiMy2QCg3Beh KNbq55w4R2A4qtLCwQosJPg= =zRrs -END PGP SIGNATURE- ___ 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: Notice: dnssec-conf updates in Fedora 11 and 12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 09, 2010 at 05:29:27PM -0500, Paul W. Frields wrote: > == Remediation == > > A new update is being prepared to address this problem for Fedora 11 > and 12 users, and will be pushed to our mirrors as soon as possible. > Users who are not running BIND nameservers (named) on their Fedora 11 > and 12 can safely disregard this notice. When the new updates are > pushed, a follow-up announcement will be made here. At that time, > affected system owners can safely accept the replacement updates. Packages are now available in the updates-testing repository, and most mirrors should include them at this point. Community testing for these packages would be appreciated. To install them: su -c 'yum --enablerepo=updates-testing update dnssec-conf' To report findings: Fedora 11: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-1696 Fedora 12: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1748 - -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLdCzArNvJN70RNxcRAiFeAJ9mmfLcFDhM88cCR3Dxhc0krS8luACg0t58 GVWFdZpHU3ekakLbHktXXwE= =r4Bk -END PGP SIGNATURE- ___ 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: Call for Participation - Fedora 13 Talking Points
On Mon, Feb 22, 2010 at 10:06:09PM -0500, Jens Petersen wrote: > Perhaps I missed it but I didn't see any clear indication that > a Talking Point has to be a Feature. Is that the case? It doesn't. A Talking Point should be clearly advantageous to the latest release or somehow contemporaneous with the release. For example, the public debut of the Fedora Community portal, which was not technically a feature of Fedora 11, was still a Talking Point. Since the TPs will be used quite a bit in formulating release-specific marketing material, they'll naturally favor features. But there should be room for one or two non-feature related, important things going on around the release. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 04:22:37PM +0100, Kevin Kofler wrote: > Jaroslav Reznik wrote: > > Maybe some package rating included in PackageKit would be nice - for > > stable packages it's indicator that this package is worth to install, for > > testing package it would mean it's working (but again - who's going to > > rate it in pkgkit once installed). > > That won't solve the problem that people aren't using updates-testing in the > first place. We can't force them to. I had a fair (i.e. non-zero) response to my call for testing this package: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0916 How'd it happen? I commented directly in the Bugzilla bugs with the link and told the subscribers to the bugs that the package would not be issued until some of them tested it and posted feedback to tell me their bugs were fixed. That's a lot harder to do if you maintain hundreds of packages, sure. So we ought to have some more visible and helpful automations: * A notification mechanism for people who have a package installed that has known bugs. The notification mechanism should "pleasantly coerce" the user to test, but letting them know we can't promise it will work. If it doesn't, our tools should be able to undo that transaction gracefully -- start from current updates, try test, if failing 'yum history undo' back to current update. * The Bugzilla comments that Bodhi sends probably need some work. They're currently very complete and factual but they don't include any information for the less experienced users who are often filing bugs. Those people have reached out to contribute something, they want to continue that engagement (i.e. get a fix), and we could have a mutually positive exchange with them. By not giving them clear information we're putting that opportunity at risk. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Mar 03, 2010 at 06:47:23AM +0100, Ralf Corsepius wrote:
> On 03/03/2010 05:54 AM, Kevin Kofler wrote:
> > Ralf Corsepius wrote:
> >
> >> On 03/03/2010 05:17 AM, Jesse Keating wrote:
> >>> On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
> >>>> Where is the mock update?
> >>>>
> >>>> It's been nearly 2 weeks since you've promissed to do so, but this
> >>>> hasn't happened.
> >>>>
> >>>> There still are no mock configurations providing setups for fedora-13
> >>>> (/etc/mock/fedora-13-{i386,x86_64}.cfg)
> >>>
> >>> mock-1.0.5 was pushed into updates-testing a number of days ago that
> >>> includes the new 13 configs. They'll get moved over to the various
> >>> stables shortly.
> >>
> >> Too late, you failed to provide them in time.
> >
> > +1
> >
> > Yet another perfect example of an update which should have been pushed
> > directly to stable.
> No, this package should have been in place ("in updates") at the same
> time, the F-13 branch had been activated in Fedora's CVS.
>
> This wasn't the case, and thus likely caused:
>
> * maintainers wanting to "make mockbuild" F-13 package in CVS to hit
> build failures (I did so) or to test-build against the wrong repository
> (building against rawhide instead of F-13).
>
> * maintainers having to waste their time on reimplementing local
> versions of /etc/mock/fedora-13-<*>.cfgs (I did so).
>
> * third parties (e.g. rpmfusion) building packages against the wrong
> repos, because they didn't notice they need to branch and away from rawhide.
>
>
> It's a mistake, ... mistakes happen, ...
>
> The only things making me angry about this, is this particular mistake
> (mock *.cfg not being in place in time) not having happened for the
> first time and when taking into account the responsible person's
> attitude and position in Fedora.
I looked up the rel-eng SOP for mass branching and added this item to
it, which I'm betting took no more time than writing unnecessarily
hostile email. Be part of the solution.
https://fedoraproject.org/w/index.php?title=Mass_Branching_SOP&diff=157055&oldid=152747
--
Paul W. Frieldshttp://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: non-responsive maintainer: thomasvs
On Tue, Apr 06, 2010 at 08:53:10PM +0200, Julian Sikorski wrote: > W dniu 06.04.2010 15:56, Thomas Vander Stichele pisze: > > On Sat, 2010-04-03 at 20:10 +0200, Julian Sikorski wrote: > >> Dear all, > >> > >> it seems like thomasvs became unresponsive. I have filed a bug asking > >> about python-twisted update [1] on 6th of February. It was then duped by > >> a similar bug [2] on 23rd of March. I have also emailed Thomas on 26th > >> of March. None of the queries met any response. Should I initiate the > >> non-responsive maintainer process? > > > > Hi Julian, > > > > I'm still around, but a direct mail to me is the easiest way to get my > > attention (as I suspect is the case for most developers). I saw you did > > two weeks ago asking about an update, but that's a different beast then > > marking me as unresponsive :) > > > > I think in general it would be good that when people want to initiate > > the non-responsive maintainer process, they first of all mail the person > > involved saying so. > > > > For practical reasons contacting me over IRC doesn't always work since > > I'm on three different machines regularly, and I only check bugzilla > > stuff once a month relying on getting a mail or poke if something is > > critical. > > > > As for the issue at hand, Twisted is a complex beast to upgrade and > > validate, so I sure could use help there! I see in the bug report you > > made a list of current dependendants, we could divide them up and verify > > them ? > > > > Thomas > > > Sorry if I acted to quickly, but the lack of response to my email made > me afraid that you might be gone. > Anyway, when it comes to the update, I'm happy to help. The total number > of downstream packages dependent on twisted is 33. Should we expect > breakage? Were there any API changes in twisted? > I think we could start by dividing the list of the packages fifty-fifty, > and check if they work at all. Then, I think it would be a good idea to > bring maintainers into the loop since they actually know what the > packages are supposed to do. The cleaned-up list follows below: > > buildbot-0:0.7.12-1.fc12.noarch > cnucnu-0:0-0.3.20100110.fc12.noarch > desktopcouch-0:0.6.3-3.fc12.noarch > elisa-base-0:0.5.35-2.fc12.noarch > elisa-plugins-bad-0:0.5.35-2.fc12.noarch > elisa-plugins-ugly-0:0.5.35-1.fc11.noarch > entertainer-0:0.4.2-7.fc12.noarch > flumotion-0:0.6.1-1.fc12.x86_64 > gadget-0:0.0.3-4.fc12.noarch > itaka-0:0.2.2-1.fc12.noarch > jabbim-0:0.5-0.12.svn20091030.fc12.noarch > londonlaw-0:0.2.1-7.fc12.noarch > nwsserver-0:2.0.0-1.fc12.noarch > openxcap-0:1.1.2-1.fc12.noarch > orbited-0:0.7.10-3.fc12.noarch > poker-network-0:1.7.3-3.fc12.noarch > postr-0:0.12.3-8.fc12.x86_64 > pyicq-t-0:0.8.1.5-5.fc12.noarch > pyjigdo-0:0.4.0.1-2.fc12.noarch > python-Coherence-0:0.6.4-1.fc12.noarch > python-desktopcouch-0:0.6.3-3.fc12.noarch > python-foolscap-0:0.4.2-3.fc12.noarch > python-gnutls-0:1.1.9-1.fc12.x86_64 > python-morbid-0:0.8.7.3-1.fc12.noarch > python-nevow-0:0.9.32-3.fc12.noarch > python-pyrad-0:1.1-3.fc12.noarch > python-sippy-0:1.0.1-1.fc12.noarch > python-wokkel-0:0.6.3-1.fc12.noarch > pyutil-0:1.6.1-4.fc12.noarch > pywbem-0:0.7.0-3.fc12.noarch > rhythmbox-upnp-0:0.12.5-8.fc12.x86_64 > supybot-0:0.83.4.1-2.fc12.noarch > telepathy-sunshine-0:0.1.6-1.fc12.noarch The python-mwlib package is dependent on twisted-core; will packages like that one be affected too? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13-Beta Go/No-Go Meeting #2 @ 2010-04-08 00:00 UTC Recap
On Thu, Apr 08, 2010 at 11:30:12AM +0100, Mat Booth wrote: > On 8 April 2010 01:33, James Laska wrote: > > Greetings, > > > > Representatives from Fedora QA, Rel-Eng and Development met on IRC to > > review whether the Fedora 13 Beta release criteria [1] have been met. > > The team agreed that the Beta criteria *have* been met with > > F-13-Beta-RC5. For additional details, please refer to the attached > > minutes. > > > > Thanks, > > James > > > > [1] https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > > > -- > > Hi, is there a Known or Common Problems page for F13? https://fedoraproject.org/wiki/Common_F13_bugs -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCo feature drop task
I'd like to request that upon dropping features, FESCo notify the Marketing and Docs lists. Both of these teams maintain content that describe features for the upcoming release. In the event a feature is dropped, that content often needs to be changed by maintainers who may not be watching the devel@ list for FESCo notes. Whether a feature is dropped at a milestone point or during the cycle, this kind of notification would be very helpful for the many volunteers working on those teams. Thanks for your consideration, and for maintaining the feature process! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo feature drop task
On Fri, Apr 09, 2010 at 10:58:02AM -0400, Bill Nottingham wrote: > Paul W. Frields (sticks...@gmail.com) said: > > I'd like to request that upon dropping features, FESCo notify the > > Marketing and Docs lists. Both of these teams maintain content that > > describe features for the upcoming release. In the event a feature is > > dropped, that content often needs to be changed by maintainers who may > > not be watching the devel@ list for FESCo notes. > > I don't see a problem with this. Is bouncing of the meeting notes > sufficient? A quick trim and a "Here's a list of changes to the feature list" would be helpful, but not required. Bouncing would work OK. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 Beta release notes
The Documentation team has prepared and posted a draft of the Fedora 13 Release Notes for the Beta release: http://docs.fedoraproject.org/drafts.html It's recommended that developers check out sections that are relevant or important to them. If you find that a page needs changes, you can use the link at the start of each major section, provided in rather startling magenta, to get to the wiki page that houses the content source for that part of the document. Make your changes on the wiki. Please keep in mind that to make our translators' jobs easier, it is best to add or delete a paragraph, as opposed to making minor tweaks inside a paragraph. Sometimes this may not be possible, so just give it your best shot. Documentation folks are almost always available on IRC Freenode #fedora-docs to help if needed. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: potentially unmaintained packages
On Wed, Apr 14, 2010 at 12:20:05PM +0200, Felix Kaechele wrote: > Hi Michael, > > On 14.04.2010 09:19, Michael Schwendt wrote: > > > Why would it need to be rebuilt manually? > > You don't need to. If a package is working perfectly fine and no update > is available there's no need to rebuild. > > >> "Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you > >> should 1. check that out and 2. if the pkg is dead or unmaintained > >> consider retiring it." > > > > It's stable, works, and is still being used by dependencies. Would I > > rebuild just for fun (and possibly introduce bugs related to temporary > > issues with compilation, RPM, or other build deps)? > > Again, there really is no need to. And Seth didn't say that there is a > need to do so. I think he really tried hard to make his point of the > list not having any implications. > For my part I found this list quite useful because I almost forgot that > I took over rubyripper some time ago. > I had some issues with it lately and I almost filed a bug for it. I can > just imagine the hilarity if that bug would have been assigned to myself > directly ;) > > So just see this list as a service that you _can_ use. But you aren't > required to use this service. > > Thanks Seth. That's how I took it too -- My packages in that list that are similar, slow moving packages. Except for one that I think I should take a closer look at massively upgrading in Rawhide or orphaning. So thanks from me, too. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Beta release notes
On Wed, Apr 14, 2010 at 06:33:38PM +0200, drago01 wrote: > On Wed, Apr 14, 2010 at 5:52 PM, Michael Cronenworth wrote: > > drago01 wrote: > >> PPC is no longer a primary arch, so the wording about supporting it > >> should be removed. > > > > Sony recently removed "Other OS" support from all PS3 units. Should the > > Playstation line be removed as well? > > The Playstation is PPC anyway so regardless of what Sony is doing with > the firmware update it should be removed. Please visit the wiki and make the change. Thanks! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Beta release notes
On Wed, Apr 14, 2010 at 11:47:50AM -0700, Adam Williamson wrote: > On Wed, 2010-04-14 at 10:20 -0400, Paul W. Frields wrote: > > The Documentation team has prepared and posted a draft of the Fedora > > 13 Release Notes for the Beta release: > > > > http://docs.fedoraproject.org/drafts.html > > Thanks for updating the system requirements. However, this looks like a > typo: > > Minimum RAM for graphical: 348 MiB > > 348 is a fairly odd amount, I suspect it's meant to be 384. If so, then > the cited 32-bit and 64-bit requirements are identical, and they could > be combined into a single section. Done. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Elections - nominations open Sat 2010-04-24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With a Fedora release coming soon, it's also time for Fedora Elections. Both the Fedora Project Board and the Fedora Engineering Steering Committee (FESCo) will have open seats during this election cycle. Nominations for these seats open tomorrow, Saturday, April 24, 2010. You can nominate yourself, or someone else. It's recommended that if you intend to nominate someone else that you consult with that person first. The entire election schedule, and other important information for all nominees, is posted on the wiki's main Elections page, and the specific nomination pages for the Board and FESCo: https://fedoraproject.org/wiki/Elections https://fedoraproject.org/wiki/Board_nominations https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations You can also find more information about both these at their main wiki pages: https://fedoraproject.org/wiki/Board https://fedoraproject.org/wiki/FESCo Please thoughtfully consider how you can best contribute to Fedora by serving on one of these important committees, or encourage someone you know who can make a difference to serve. Thank you! - -- Paul (25 days to Fedora 13!) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQFL0huhrNvJN70RNxcRAi+2AKDN36pLiBgca75+PoNkpx/30av/lACePcSE 5tfX27I9Mxbs/JmGrRTuNOM= =WQTH -END PGP SIGNATURE- ___ 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
qrencode in critical path?
https://admin.fedoraproject.org/pkgdb/acls/name/qrencode Is this package supposed to be critical path?[1] It's marked that way for f16 and devel branch, but it was surprising to me. * * * [1] https://fedoraproject.org/wiki/Critical_Path_Packages -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with GNOME ?
On Mon, Mar 12, 2012 at 09:49:18AM -0400, Adam Jackson wrote: > On Sun, 2012-03-11 at 19:03 -0700, Adam Williamson wrote: > > On Sun, 2012-03-11 at 18:49 -0700, Adam Williamson wrote: > > > On Sun, 2012-03-11 at 15:48 -0400, Cole Robinson wrote: > > > > > > > which has a lot of people tacked on as well (not sure why abrt couldn't > > > > handle > > > > the other 60 though...) It ain't glamorous, but all those extra bugs > > > > should > > > > probably just be duped to that report. > > > > > > You could do that in about ten seconds with python-bugzilla, I think. > > > > Huh. I take that back. Seems neither python-bugzilla nor Bugzilla's own > > 'modify several bugs at once' page is capable of marking multiple bugs > > as duplicates of one other bug. You can close a big set of bugs with any > > other resolution, but DUPLICATE does not appear to be possible. > > Interesting. > > I actually have a patch for this in my local copy of python-bugzilla, > so, thank you for reminding me to get that upstreamed. Bug filed: > > https://fedorahosted.org/python-bugzilla/ticket/40 We should ask Will Woods when we can expect a new release -- it's been ~9 months since the last one, and several fixes I'd like are either in the repo or waiting in tickets. This is a great one, thanks ajax. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why are is subversion 1.7 for F16/F17 removed
On Mon, Mar 12, 2012 at 12:46:08PM -0500, Jon Ciesla wrote: > On Mon, Mar 12, 2012 at 12:44 PM, Jesse Keating > wrote: > > On 3/12/12 10:43 AM, Jon Ciesla wrote: > >> > >> No, it looks like it stayed in testing because the version was > >> updated. I don't see where it was ever in stable. > >> > >> https://admin.fedoraproject.org/updates/FEDORA-2012-2673 > > > > > > He expected that it /would/ be pushed to stable. > > Well, yes. And I can understand that. But as you said, that's no > guarantee it'll ever hit stable. If needed, the OP should be able to scratch-build the 1.7.0-2 packages from the package git repository, or (hopefully) some later and presumably improved 1.7.x version. +1 on the guarantee, but that doesn't help the OP if he has converted repos. Caveat emptor. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security incident on Fedora infrastructure on 23 Jan 2011
On Wed, Jan 26, 2011 at 09:30:24AM -0700, Kevin Fenzi wrote: > On Wed, 26 Jan 2011 15:25:40 +1300 > Al Reay wrote: > > > Looks like it's made the news > > > > http://news.slashdot.org/story/11/01/25/1723259/Fedora-Infrastructure-Compromised > > Disappointingly the slashdot story paraphrased another site that went > with a sensationalized headline and was low on facts. They didn't even > point to the actual announcement for folks to read for themselves. ;( > (They also seem to be using the opensource.org logo for Fedora stories > instead of the Fedora logo?) They used to use the Red Hat logo -- would that count as a modest improvement? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security incident on Fedora infrastructure on 23 Jan 2011
On Thu, Jan 27, 2011 at 01:35:05AM +0530, Rahul Sundaram wrote: > On 01/27/2011 01:12 AM, Paul W. Frields wrote: > > On Wed, Jan 26, 2011 at 09:30:24AM -0700, Kevin Fenzi wrote: > >> > >> Disappointingly the slashdot story paraphrased another site that went > >> with a sensationalized headline and was low on facts. They didn't even > >> point to the actual announcement for folks to read for themselves. ;( > >> (They also seem to be using the opensource.org logo for Fedora stories > >> instead of the Fedora logo?) > > They used to use the Red Hat logo -- would that count as a modest > > improvement? > > Don't think so. It only increases the chances of confusion for the > general community and Red Hat customers. They should use the Fedora Logo. Sorry I left out the tag. I agree, of course. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
On Mon, Feb 07, 2011 at 03:59:42PM -0500, Bill Nottingham wrote: > Orphan odfpy > comaintained by: pfrields > Orphan python-mwlib > comaintained by: pfrields I don't foresee a problem maintaining the first, and I'll take that over for now. The calibre package depends on it, and I want to help Kevin Fenzi out. :-) The second is *much* more problematic. Steadily increasing numbers of odd requirements make python-mwlib decidedly un-fun and time consuming to maintain. Some of the requirements drag in large dependency stacks, others are not yet packaged for Fedora, and some of those are tiny, one-off code drops that I worry will go unmaintained upstream in the long run. So in short, I don't think I'll be taking over python-mwlib. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Marc Wiriadisastra orphaning some packages
Hi Fedora paackager community, Marc asked me to forward this to the list because of some mail account issues. He's released ownership of the packages listed below. Paul - Forwarded message from Marc Wiriadisastra - Date: Mon, 10 May 2010 23:59:27 +0800 From: Marc Wiriadisastra To: Paul Frields Subject: Packages Hi Paul, I was if you could please could do me a favor? The packages that I own I am not doing justice to as I am unable to spend time monitoring and updating them. Some of the packages have updates available and I haven't got the time to update or do any work on them. I would like to hand them off to someone however I'm not on the mailing list anymore, are you able to post to the list so I can hand the packages over? Correct me if I'm wrong but is the process to remove myself from the package, this would then allow someone to assume ownership of the package or is the prcoess to wait for someone to become part of the package and then release ownership? The packages are: [1]diveintopython -- Dive into Python - a python book [2]drpython -- A simple Python IDE designed with teaching in mind [3]gnome-themes-extras -- Collection of metathemes for the Gnome desktop environment [4]gnomecatalog -- Catalog Software for Gnome Desktop [5]libmspack -- Library for CAB and related files compression and decompression [6]mediatomb -- MediaTomb - UPnP AV Mediaserver for Linux Thanks and Regards, Marc Wiriadisastra - End forwarded message - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
One week slip of Fedora 13 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The F13 final readiness meeting, also known as the "go/no-go" meeting, was held this evening. As the meeting notes indicate, there are bugs remaining on the blocker list: http://lists.fedoraproject.org/pipermail/test/2010-May/090880.html According to the release criteria[1], the decision was made to slip the release of Fedora 13 by one week, to Tuesday 2010-05-25. During composition of any further release candidates, the Fedora Release Engineering and Quality Assurance teams plan to be conservative in accepting fixes for the release, and will limit these to blocker items and critical fixes. The Fedora 13 release schedule[2] has been updated to reflect the new release date. We regret any inconvenience to the community. Thank you for your patience as we try to ensure the best possible Fedora release. * * * [1] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria [2] https://fedoraproject.org/wiki/Releases/13/Schedule - -- Paul W. Frields -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQFL6gZfrNvJN70RNxcRAovhAJ4gCqmdpUPjxqcUeZT/9Rufm2T1gQCgjHKw d3Iuc1YktqutAtkkB/zI3l0= =TpN+ -END PGP SIGNATURE- ___ 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: One week slip of Fedora 13 release
On Tue, May 11, 2010 at 09:36:31PM -0500, Bruno Wolff III wrote: > On Tue, May 11, 2010 at 21:37:35 -0400, > "Paul W. Frields" wrote: > > > > According to the release criteria[1], the decision was made to slip > > the release of Fedora 13 by one week, to Tuesday 2010-05-25. > > Even though the end result was a slip, I'd still want to thank the people > that worked hard over the last couple of weeks on getting blocker bugs > cleared. I really liked the users@ list thread you started in this regard, Bruno. I kept the announcement terse, but I wrote more here: http://marilyn.frields.org:8080/~paul/wordpress/?p=3175 -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Board and FESCo Election results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Fedora elections for the Fedora Project Board and the Fedora Engineering Steering Committee (FESCo) have concluded, and the results follow: The Board is electing 3 seats this cycle. A total of 229 ballots were cast, meaning a candidate could accumulate up to 1374 votes (229 * 6). The results for the Fedora Board election are as follows: name | # votes - --+- Tom Callaway (spot) |1001 Máirín Duffy (mizmo) | 978 Rex Dieter (rdieter) | 772 - --+- Stephen Smoogen (smooge) | 559 John McDonough (jjmcd) | 437 Larry Cafiero (lcafiero) | 430 Therefore, Tom Callaway, Máirín Duffy, and Rex Dieter are elected to the Board for a full two-release term. * * * FESCo is electing 5 seats this cycle. A total of 180 ballots were cast, meaning a candidate could accumulate up to 1260 votes (180 * 7). The results for the FESCo election are as follows: name | # votes - --+- Bill Nottingham (notting)| 937 Kevin Fenzi (kevin) | 749 Matthias Clasen (mclasen)| 681 Kyle McMartin (kyle) | 545 Steven M. Parrish (tuxbrewr) | 516 - --+- Bruno Wolff III (bruno) | 492 Justin M. Forbes (jforbes) | 460 Therefore, Bill Nottingham, Kevin Fenzi, Matthias Clasen, Kyle McMartin, and Steven M. Parrish are elected to FESCo for a full two-release term. * * * Congratulations to the winning candidates, and thank you to each of the nominees for running, and our volunteers and team members for their assistance. - -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQFL/nuQrNvJN70RNxcRAnU4AKDxQ2osyntcQGmh8BNZ+l+9bWsBwACgtUnQ 5jCCWRWT9tMiuyolChtzJLg= =xI7D -END PGP SIGNATURE- ___ 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: concept of package "ownership"
On Thu, Jul 01, 2010 at 11:28:09PM -0500, Adam Miller wrote: > I don't think it really matters what we call it, I just think that > package maintainers are starting to get a sense of entitlement and I > feel that's counter productive to the open environment we're used to > and are trying to help continue to grow. > > The package "owner" gets emails about cvs commits, so they are always > aware of what's going on and can review the changes to packages they > maintain. In the event of a discrepancy then the person receiving the > email obviously has an email account and can easily email the person > who made the edit in order to extend a friendly inquiry as to the > change. It doesn't need to be any more complicated than that. > > I for one welcome co-maintainers because I'm a big fan of > collaboration and a sense of community, and if I can't trust my fellow > community member and contributor to help in the maintenance of > packages that I just so happen to have a bit flipped for in the pkgdb, > then I'm in the wrong place. Good points all, Adam. My personal experience with a couple of my packages, where for example Matthias Clasen found and stomped a bug, or Jesse Keating took care of a rebuild when I wasn't around[1], gave me confidence that fellow contributors have my back, as opposed to sneaking around behind it. I prefer to presume goodwill. At worst I've caused them to grumble for taking up my slack -- in which case they know where to find my inbox to complain. :-) * * * [1] These happened both when I was a volunteer, and when I was a Red Hat employee, FWIW. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Partial mass rebuild for Python 2.7 coming soon (I hope)
On Thu, Jul 22, 2010 at 02:00:45AM -0400, David Malcolm wrote: > On Tue, 2010-07-20 at 20:02 -0400, David Malcolm wrote: > > I'm planning to do a partial mass-rebuild for Python 2.7. > > > > This would cover all Python 2 users within the distribution, roughly > > 1000 src.rpms. > > > > Some notes can be seen at: > > https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild > > > [snip] > > Status: IN PROGRESS > - IRC chat with nirik, pjones and others confirmed not to wait for gold > - the infrastructure outage took somewhat longer that expected, so I > didn't start until about 6pm EDT iirc. > - The mass-rebuild script is running, and has done about 600 out of 1000 > packages. All of this is into dist-f14-py27-rebuild, so it won't hit > rawhide until rel-eng push it there. > - We're at a roughly 50:50 success/fail rate > - build ordering was much more important than I hoped; most of the > failures in this run seem to be due to incomplete deps in root.log. I > intend to retry these from the now-existing CVS tags, with a better > build ordering (but I need to sleep first). > - numpy is segfaulting during %check; am waiting on a gdb build to > finish (linked against 2.7) before I debug; this blocks pygtk2 which > blocks various things > - I've applied some fixes directly to some packages to get things to > build. I hope my changes are acceptable. > - Sorry about all of the email notification spam some of you will have > received > > Notes: > - There was a snag with python-nose: I needed to cherrypick 2.7 compat > fixes from upstream: DONE > - There are some loops in the dep graph: python-nose and python-jinja2 > both BR: python-sphinx but are in the BR for that package. I've turned > off doc generation for these for now; am waiting on repo to rebuild > before I can build python-sphinx (deps appear to be ready). > > [snip] > > Hope this makes sense It does -- in my case (and probably many others) the pygtk2 rebuild and reordering should take care of what went wrong. Thanks for taking this on Dave! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, Jul 22, 2010 at 07:31:22AM -0500, Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
> > if [ $1 -eq 0 ] ; then
> > /usr/bin/systemd-install disable --realize=yes %{unit name}.service
> > > /dev/null 2>&1 || :
> > fi
>
> Umm, that's copying one of the much-mocked things of Windows, where you
> click "Start" to shutdown. "systemd-install" to remove?
Shouldn't it be possible to have a similar "systemd-remove" that
resolves to the appropriate option?
--
Paul W. Frieldshttp://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, Jul 22, 2010 at 11:11:31AM -0400, Matthew Miller wrote: > On Thu, Jul 22, 2010 at 03:52:06PM +0200, drago01 wrote: > > Everyone has to pay this cost and everyone gets something in return. > > And the way you present this as an _overall win_ is by emphasizing the > returns and decreasing the costs. > > What I hear is discounting the costs as real, rather than actually trying to > decrease them. This makes enemies out of your would-be supporters. Congratulations on a not-very-charged statement of how to use this thread constructively. When the experienced system administrators in this thread bring in their real-world cases of "How should we deal with common situation ?", that should be answered with "You can do that in the following ways: . And if that doesn't work, let's discuss *how* it doesn't work," all of which can be done without attacking people's skills, intelligence, foresight, or motives on either side. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, Jul 22, 2010 at 10:37:20AM -0800, Jeff Spaleta wrote: [...] > I'd wager that if we were having this discussion in a room with the > very same people, I think the emotional reactions over the areas of > conflict would be much reduced and personality quirk mismatches > wouldn't cause so much static. [...] ISTR this was much the case when we discussed Upstart at the FUDCon in Raleigh, NC in 2008. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- 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 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. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Validity of i686 as a release blocker
On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: [...snip...] > Perhaps it is time that we evaluate where i686 stands in Fedora more > closely. For a starting suggestion, I would recommend that we do not > treat it as a release blocking architecture. This is not the same as > demotion to secondary architecture status. That has broader > implications in both buildsys and ecosystem. My suggestion is > narrowly focused so that builds still proceed as today, but if there > is something broken for i686 it does not block the release of whatever > milestone we are pursuing. > > (To be clear, I would support a move to secondary arch status for > i686, but I am not suggesting it at this time.) So to put a finer point on this, our shipping i686 images depends on a broader community effort beyond the kernel maintainers in the Fedora Engineering team. That needs to precisely not mean more heroics on the part of e.g. QE, rel-eng, etc. I have no idea what the pushback on this issue is, but I'm sure this thread will tell us. But given that Fedora is supposed to encourage such community effort, it would be good to see what people are willing to do to build it. > Making i686 non-release blocking would actually match reality. None > of the Fedora Editions appear at all concerned with i686. Cloud is > demoting[3] i686 from its offering. Workstation has been fairly > ambivalent about it and recommends x86_64. Server does the same. > Given the lack of focus on it, and the fact that the broader community > is not testing the development releases for i686, I believe this would > be a good first step. "Ambivalent" is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 > [2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html > [3] https://fedorahosted.org/cloud/ticket/106 -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On Thu, Aug 20, 2015 at 10:40:40AM -0700, Adam Williamson wrote: > On Thu, 2015-08-20 at 12:33 -0500, Michael Cronenworth wrote: > > On 08/20/2015 12:02 PM, Ralf Corsepius wrote: > > > > > > To me any non fedora/redhat supplied account system is > > > inacceptable, > > > > > > This applies to github, sourceforge, farcebook, nitter, goggle, or > > > else - period. > > > > The last time a non-Fedora hosted / closed source service was > > suggested it was shot > > down. > > > > https://lists.fedoraproject.org/pipermail/devel/2013-October/191012.h > > tml > > > > Have times changed? Using github is acceptable? > > (following on from previous mail) that specific link, though, is > talking about something completely different. That would be using the > non-free software *as part of infra*, not just hosting some open source > code we run in infra on a service that is not free. This is correct. The infra team discussed this some time ago and since Github does nothing to lock up the resources we care about, and exposes our code to a much wider (*1000 at least) group of developers, among other reasons, judged it OK. Having a PR-based workflow has helped the team be a lot more agile at no cost to the freedom of our code. Be that as it may, there is now pagure, and I imagine many if not all of these repos will be moving there. Incidentally, pagure has some functionality to allow bidirectional code movement with Github, which gets the best of both worlds. If someone doesn't like making a Github account, in the interim they're still free to fork as would be usual for any repo (including hundreds of projects we carry in Fedora repositories), and send a patch to the list. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On Thu, Aug 20, 2015 at 02:40:10PM -0600, Kevin Fenzi wrote: > On Thu, 20 Aug 2015 22:24:18 +0200 > Kevin Kofler wrote: > > > But this is a project where Fedora *is* upstream! > > I assume you mean "bodhi" by "this". > > The primary bodhi developers are heavily involved in Fedora, but are > also involved in other communities. When is a project "Fedora" ? > There are other installs of bodhi out in the world (at least there > were) where we get contributions from. Right, considering Fedora as equivalent to the upstream here is incorrect. These projects are meant to be forkable to any project (free or not), of which Fedora is only one. > > One thing is the standards we require for being packaged in Fedora or > > used in Fedora infrastructure. Another is what we expect from our > > *own* projects. And there, requiring Fedora infrastructure to be used > > is very reasonable. > > Well, I guess we will agree to disagree then. Agreed with kfenzi. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements
On Thu, Sep 10, 2015 at 04:18:00PM +0200, Ralf Corsepius wrote: > On 09/10/2015 04:06 PM, Stephen Gallagher wrote: > >On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote: > >> > >> > >>On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher >>om> wrote: > >>>I assume that subject line got your attention. > >>> > >>Most definitely. :) > >> > >>So it's basically the same but without FPC as a gatekeeper? Do you > >>have any proposals for enforcement? A periodic query of Provides > >>(bundled-foo) and a BZ requesting a review? Sometime projects > >>enable unbundling over time. > >> > > > > > >I don't know that enforcement is strictly necessary. Maintainers that > >care will self-enforce. Maintainers that don't care won't be aided by > >this. > > Are you talking about upstream maintainers of fedora maintainers? I took this to mean Fedora maintainers, not upstream, but on second read it seems equally true in both cases. > The cause of the majority of cases of bundling is upstream maintainers who > violently refuse to comprehend the evilness of bundling and who use bundling > because "it's so convenient" to them. Use of terms like "violent" and "evil" belies an attitude toward upstream developers that I don't believe helps either upstream or Fedora. > >"Enforcement" implies adding more heavy process, which is part of the > >problem this is trying to avoid. > You don't seem to be aware about the fact FPC already tries to enforce > unbundling. Yes, this is a heavy and time-consuming process, esp. on > occasions upstream's behave stubborn and refuse to listen. I doubt OP is unaware of this. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements
On Thu, Sep 10, 2015 at 02:59:41PM -0400, Simo Sorce wrote: > On Thu, 2015-09-10 at 12:39 -0500, Jason L Tibbitts III wrote: > > >>>>> "MM" == Matthew Miller writes: > > > > MM> That said, I do recognize that "provides high-quality packages" has > > MM> also always been an underlying Fedora value even if unstated. But, I > > MM> think that _that_ value should be in support of the Big Four, and in > > MM> support of our mission in general, not a sacred beast for its own > > MM> sake. > > > > Well, for the FPC, high quality packaging is pretty much our only > > mission. I'm trying to avoid veering off into hyperbole here, but if we > > can't be focused on our specific mission then that kind of complicates > > our job. > > > > But if FESCo or the board or whoever wants to say that we no longer > > really care about bundling, then FPC will stop caring. Right now we've > > been told to care about bundling and so we developed all of this process > > and rules to implement that directive. > > Hi Jason, > I have the impression (which may be totally wrong) that you are taking > the binary approach here: either we care maximally or we do not care at > all. I took Jason's statement to mean the FPC would stop caring *about bundling* if that's what FESCo (or someone) agrees on. If one change in the guidelines meant the difference between caring at all about packaging, I'd think that ship would have sailed by now! :-) > It seem to me Stephen is making a proposal to tweak just one specific > aspect of packaging rule, that is a softer enforcement model. FPC still > has a truckload other good rules about packaging and nobody believes FPC > should stop caring about overall package quality. > > I have mixed opinions myself about allowing bundling, on the one side it > makes some things worse, on the other hand, however it is sometimes a > way too step barrier to entrance. I've come to the conclusion I'd rather > see a softer approach with strong encouragement to use unbundled > libraries and a need to justify credibly why a bundled library is used > but not a hard rule against it in all cases with hard exceptions to be > doled out by the FPC, I think package review should be able to handle > it. > > This risks making somewhat harder to police egregious mis-behavior, but > I am sure there are other ways to deal with offenders that willfully > break reasonable rules. Agreed. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements
On Thu, Sep 10, 2015 at 03:50:27PM -0400, Matthew Miller wrote: > On Thu, Sep 10, 2015 at 02:41:13PM -0500, Jason L Tibbitts III wrote: > > Anyway, what I don't get is why we're to the point of tossing out the > > primary anti-bundling rule when FESCo has always had the power to > > override any FPC decision. So FPC says "this isn't good packaging" and > > FESCo can say "we understand, but quality packaging here is subservient > > to the distro's mission". That's always been the case, even when the > > "E" stood for "Extras", and I suspect it would have worked just fine for > > this situation. Instead we're here debating whether FPC should be in > > the business of reviewing bundling issues at all. > > I think it's because overriding a different group seems hostile, even > if it isn't meant that way. And FESCo doesn't want to feel like they're > second-guessing other groups all the time. But, if FESCo and FPC want > to (more, I guess) explicitly spell out that FPC takes a purist > approach and that it's FESCo's place to make exceptions when they serve > greater Fedora goals, maybe that could work? While that doesn't seem hostile, it seems just as unsustainable. Setting a better baseline expectation for bundling makes more sense. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Comps fails to validate (patch inside!)
On Sun, Jul 13, 2014 at 11:40:52PM -0400, Bill Nottingham wrote:
> As the guilty party in many cases for not updating the .rng file...
>
> Kevin Fenzi (ke...@scrye.com) said:
> > > The comps-el4.xml.in and comps-el5.xml.in changes remove a nearly
> > > empty named "editors". The description claims that the group
> > > contains emacs and vi, but it doesn't. All it contains is an XEmacs
> > > metapkg. As an XEmacs developer, I am flattered that our product was
> > > included, but the current comps.rng knows nothing of . This
> > > looks like it was mistakenly included, or mistakenly not removed all
> > > the way, hence the removal.
> >
> > Seems fine.
>
> As Kevin said, EPEL groups are additive to RHEL groups; the descriptions are
> supposed to match what they are in RHEL/CentOS if they share the name of a
> group in EL. Hence, you can remove an empty 'editors' group, but I wouldn't
> change the description.
>
> > > In comps-epel7.xml.in, we currently have an prior to any
> > > . That is not allowed by comps.rng, which wants all s
> > > first, then s. This patch moves the to
> > > satisfy that restriction. But there is something odd here. That is
> > > the one and only in the file. Is this a mistake?
> > > Should there be s in comps-epel7.xml.in at all? If so,
> > > where are the rest of them?
> >
> > epel comps files are additive to rhel comps files. So, they will be
> > much smaller in general and not have any of the base env stuff.
> > I don't know off hand if rhel7 uses env's, but I think so.
>
> It does.
>
> > > In addition to the dangling "clustering" reference that started this
> > > thread, comps-f18.xml.in, comps-f19.xml.in, comps-f20.xml.in,
> > > comps-f21.xml.in, and comps-f22.xml.in all have a libreoffice group
> > > that is missing and elements. i took my best
> > > guess at what the values of those elements should be. In addition,
> > > all but comps-f18.xml.in have a named "3d-printing". However,
> > > that is not a valid ID, because it starts with a digit. I changed it
> > > to "three-d-printing", but somebody can probably come up with a better
> > > name than that.
> >
> > Fun.
>
> Please don't change group names in released releases - it's essentially an
> ABI for kickstart files, and we don't want to break those. I suspect the fix
> here is to change the definition to allow groups that start with a number -
> yum handles this OK.
>
> > > There are quite a few elements that do not carry a "type"
> > > attribute. It looks like comps.rng is supposed to support this, and
> > > that those elements are supposed to default to the type "optional".
> > > However, the "type" attribute has to be for that to work.
>
> It's not optional - having no type set makes the type 'mandatory'. From the
> yum code:
>
> genre = child.attrib.get('type')
> if not genre:
> genre = u'mandatory'
>
> The logic is that for groups that are used as building blocks of
> environments, they're not intended to be modified - so all packages are
> mandatory, and there are no optional/defualt ones.
>
>
> > > In the "core" group, there is a package declared like this:
> > >
> > >> > type="mandatory">uboot-tools
> > >
> > > but comps.rng doesn't know anything about an "arch" attribute.
> > > Assuming that this is actually correct, and that consuming tools know
> > > to expect such an attribute, I added support for this to comps.rng.
> >
> > No idea here. Dennis and/or other arm folks might know more.
>
> yum doesn't use arch= here, but it's used by some tools that process comps
> files to write new ones. It's fine to add it to comps.rng.
>
> > > Finally, in some 's 's s, a
> > > "default" attribute has appeared. The current comps.rng does not
> > > allow that. Once again, assuming that this is actually correct and
> > > that consuming tools expect that attribute, I added support for it.
>
> Yes, that's correct.
It seems like there are a couple non-obvious gotchas here (additive
nature, kickstart dependency, et al.); would it make sense to put a
README in the comps repo pointing some of this out for posterity?
--
Paul W. Frieldshttp://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Are we still translating things?
On Wed, Aug 13, 2014 at 10:05:35PM +0100, David Woodhouse wrote: > On Wed, 2014-08-13 at 14:56 -0600, Kevin Fenzi wrote: > > > > Well, I'm not sure why this is suddenly confusing. > > Because I misunderstood and thought that the trans@ list might actually > be somewhere that people should post to for one-off advice and > assistance (or to point out broken links on the web page), without > wanting to subscribe and take a daily interest in l10n matters. > > If it doesn't serve that purpose, do we have something that *does*? IRC Freenode at #fedora-l10n perhaps? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RETRACTION] Re: Unofficial Poll: Flock 2015 (North America) Bids
On Thu, Sep 25, 2014 at 09:50:14AM +0200, Ralf Corsepius wrote: > On 09/25/2014 08:22 AM, Matthias Runge wrote: > >On 24/09/14 19:54, Máirín Duffy wrote: > >>>E.g. in June, flights to Boston are US$ 850 vs US$ 1400 in August. Maybe > >>>it's a good idea to move the conference out of main holiday season? > >> > >>Are you located in EMEA or APAC? Because Flock alternates between North > >>America and EMEA I think partially because of this reason... > >> > > > >I missed last two Flocks, because they were in main holiday season. It's > >way easier for me to travel, when kids are in school. > > Similar for me. Travel at least in EU is easier outside the main holiday > seasons. I was at least one of the people who mentioned the vacation wrinkle to Mo, which I had on hearsay. I'm sorry if that created any issue, and I'm happy to hear that people in the EU have flexibility outside summer. Would it be worth asking organizers to allow anyone who thought August was a harder requirement to update their bid? It should only take a few days and it's hard to think that would be make or break for deciding the winner. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RETRACTION] Re: Unofficial Poll: Flock 2015 (North America) Bids
On Thu, Sep 25, 2014 at 04:45:54PM -0400, Simo Sorce wrote: > On Thu, 25 Sep 2014 16:12:30 -0400 > Stephen Gallagher wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 09/25/2014 04:02 PM, Paul W. Frields wrote: > > > On Thu, Sep 25, 2014 at 09:50:14AM +0200, Ralf Corsepius wrote: > > >> On 09/25/2014 08:22 AM, Matthias Runge wrote: > > >>> On 24/09/14 19:54, Máirín Duffy wrote: > > >>>>> E.g. in June, flights to Boston are US$ 850 vs US$ 1400 in > > >>>>> August. Maybe it's a good idea to move the conference out > > >>>>> of main holiday season? > > >>>> > > >>>> Are you located in EMEA or APAC? Because Flock alternates > > >>>> between North America and EMEA I think partially because of > > >>>> this reason... > > >>>> > > >>> > > >>> I missed last two Flocks, because they were in main holiday > > >>> season. It's way easier for me to travel, when kids are in > > >>> school. > > >> > > >> Similar for me. Travel at least in EU is easier outside the main > > >> holiday seasons. > > > > > > I was at least one of the people who mentioned the vacation wrinkle > > > to Mo, which I had on hearsay. I'm sorry if that created any > > > issue, and I'm happy to hear that people in the EU have flexibility > > > outside summer. > > > > > > Would it be worth asking organizers to allow anyone who thought > > > August was a harder requirement to update their bid? It should > > > only take a few days and it's hard to think that would be make or > > > break for deciding the winner. > > > > > > > If "the end of August" wasn't a hard requirement, then I actually have > > another bid that we ruled out because of that (University of > > Massachusetts at Lowell). If I put that together by tomorrow, is there > > still time? They weren't able to accommodate the end of August or > > early September due to returning students, but late July or early > > August would be wide open. > > Hi Stephen, > late July or early August is much worse travel wise. > That full holiday season and plane ticket prices skyrocket through the > roof and availability is scarce. > > In my experience the months that are best (price-wise) for > transatlantic (not sure if transpacific is similar) flights are > March-June, October-November with exceptions of course (ie around > Easter in bad for most US/Europe, and thanksgiving time it is bad for > inbound US). Right, I thought the point was the possibility of holding the conference slighly *later* if that improves EU folks' ability to attend. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Engineering Representiatve for the new Fedora Council
On Mon, Oct 13, 2014 at 04:52:08PM +0200, Haïkel wrote: > I'll be speaking in my own name: > > The Eng. Rep. is not necessarily a Fesco member but should be > someone willing to collaborate regularly with them. She should have > a fairly broad overview of Fedora Engineering and be an active > contributor. > > The ideal candidate should be someone who has experience in the > technical committees, and able to communicate effectively with > various groups. You don't need to be a "super contributor", but > this is no role for a rookie as the time commitment will be > important. About the selection, since it will take a lot of your > time, I think that interested people should nominate themselves. > Then, either fesco choose to hold an election or not is up to them. > > Though I have few names in mind, I won't disclose them before > speaking with them. Some are obvious, the others may surprise you > ;) Although I may not have all the deep technical knowledge of some FESCo members, I'd be willing to serve in this capacity. I do have experience working with different groups in Fedora, including the Board and FESCo, and release related groups like Rel-Eng, Docs, L10n, and Websites. I also manage the team in Red Hat that supports our infrastructure and applications. That could come in handy in helping the Council direct resources to work on the priorities needed for Fedora to succeed. However, I want to be clear that my being involved is *not* a pre-requisite for that support. I would expect to support Matthew and the Council regardless. I'm sure there are other worthy candidates, and I'd work with any of them who fill this role. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: Re: Release Notes Update
From the docs@ list, FYI, in case someone has some time in which they can contribute to release notes for desktop, system daemons, web servers, or for that matter any other existing beats: - Forwarded message from "John J. McDonough" - On Tue, 2012-03-20 at 23:27 -0400, Christopher R. Antila wrote: > Hi: > > I have some unexpected extra time today, so I'll finish the Desktop beat. That would be much appreciated. I need to get cracking on the RPM or it won't make it into beta. I see we have KDE there but no GNOME. Without some help there will be no mention of GNOME 3.4 in the RNs (other than a word in Overview). Also, there are some minimal notes in Musicians. Do they need to be embellished or will we leave that beat blank? On https://fedoraproject.org/wiki/Documentation_Beats I have marked as empty those beats that I think will be empty in the release notes. If anyone feels like that is a problem you only have a few hours to fix it. I'm going to get working on the Multimedia beat. If anyone could grab the Daemons beat it would be much appreciated. Or the other way around, if someone wants to take Multimedia while I work on Daemons that would work, too. Also, Yuri made some notes in Web Servers. If he or someone else could embellish those it would be good. I anticipate building the RPM around 1800Z. I will then be looking for folks to quickly give it some karma. --McD - End forwarded message - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The Forgotten "F": A Tale of Fedora's Foundations
On Mon, Apr 21, 2014 at 08:40:03AM -0600, Kevin Fenzi wrote: > ...snip... > > IMHO, it feels wrong to call this it's own foundation. A foundation is > a core value of our community, and this seems like a harsh reality we > have to live with. I also have a hard time envisioning functionality at the level of the other core values. But I certainly think it's important. Fedora has carved out specific space for functionality in areas like kernel firmware in the past. Those were the right decisions to ensure users can make use of the platform in a world we don't control (e.g. where firmware is an increasingly key part of OEM TTM strategy). > I guess I would prefer to have the 'freedom' foundation clarified some > rather than adding this as a foundation. +1. > I guess it depends on where we draw the line how we clarify too. Is it > anything remote is allowed to be nonfree? Or anything thats a client > that interacts with something non free? I think forcing our users to eschew nonfree web services increasingly sidelines the Fedora platform. For example, making it harder for developers to use preferred services like github (operational) or Twitter (social/advertising) doesn't help Fedora improve as a hospitable platform. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PkgDB2 is now in production
On Thu, May 15, 2014 at 07:12:11AM -0400, Jaroslav Reznik wrote: > - Original Message - > > After more than 15 months in development, today we deployed pkgdb2 > > into production at https://admin.fedoraproject.org/pkgdb/ > > > > pkgdb is the application that manages package metadata for Fedora, including > > commit access for packagers, bugzilla assignment, and scm changes > > notifications. > > > > A few of the more notable changes in this new version of pkgdb: > > > > * Redesigned interface: faster and cleaner > > * Packages no longer have 'owners', instead > > there is now a 'point of contact' who is assigned bugs in bugzilla. > > * Now uses Fedora OpenID for authentication > > * Provide a clearly defined and documented API > > (but completely different from the pkgdb1 one) > > * Re-written in the flask framework > > > > There might still be minor bugs or un-expected features, if you face some of > > them please let us know. > > > > > > For more information, see: > > > > Project page: https://fedorahosted.org/pkgdb2/ > > Documentation: http://pkgdb2.rtfd.org > > Git repository: http://git.fedorahosted.org/git/pkgdb2 > > Github mirror: https://github.com/fedora-infra/pkgdb2 > > Mailing list: https://lists.fedorahosted.org/mailman/listinfo/packagedb > > > > > > Many thanks to the hard work of the Fedora Infrastructure development team > > Amazing, > thank you guys! +1 -- congratulations on the new deployment and thanks for the superb effort! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request to co-maintain f22-background
On Fri, Oct 09, 2015 at 10:37:56AM -0500, Michael Catanzaro wrote: > On Thu, 2015-10-08 at 23:32 -0700, Luya Tshimbalanga wrote: > > I built an update for f22-backgrounds package which includes the > > missing > > supplemental backgrounds. > > Isn't it rather late to be adding wallpapers to F22? Even if it's a bug > that they're missing, that's the sort of thing that should be fixed in > the next release, not released as a big update to download If I remember correctly the supplemental backgrounds are subpackaged as -extra, so IIUC they shouldn't automatically be foisted on any user, just available for download. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Stop please
On Fri, Jan 08, 2016 at 03:00:13PM +0100, Reindl Harald wrote: > > > Am 08.01.2016 um 14:53 schrieb Mark Bidewell: > >Unfortunately GMail's web interface does not seem to recognize those > >headers :(. So a fair number of uses will have issues. > > what is the purpose of breaking DMARC by add a list-footer pointing to a > site with no unsubscribe-information > > why can't the list-footer contain that information at all or just be removed > when it has no real use besides breaking DMARC/DKIM and get quoted by > careless people making read posts harder? > > FIX THAT HEADERS IN GENERAL - THE "--"-line needs to be "-- " for MUA's > recognize it as signature and don't quote it all the time Did you file this bug upstream? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
On Wed, Jan 20, 2016 at 08:22:29PM -0500, Josh Boyer wrote: > On Wed, Jan 20, 2016 at 7:38 PM, Luke Macken wrote: > > On Wed, Jan 20, 2016 at 07:17:10AM -0500, Josh Boyer wrote: > >> On Wed, Jan 20, 2016 at 5:55 AM, Richard Fearn > >> wrote: > >> > Hi, > >> > > >> >> https://github.com/fedora-infra/bodhi/issues/763 > >> > > >> > You beat me to it :) Thanks for doing that! > >> > > >> > And Luke seems to have fixed the problem already. Thanks Luke! > >> > >> He fixed the code, but it isn't merged yet nor is it deployed in > >> Fedora Infrastructure from what I can tell. > > > > The fix is now in production. > > > > Sorry about the annoying regression, folks. Bodhi previously would avoid > > obsoleting updates that had an open request, even if it hasn't gotten > > pulled into a push yet. A recent improvement to this logic allows for > > updates with a testing request to get obsoleted if a newer update gets > > submitted before it gets "locked" into a push. The bug that snuck in > > allowed this to happen to unlocked updates with a stable request too. > > Thanks for the explanation and the quick fix, Luke. +1, thanks Luke! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Tue, Oct 30, 2012 at 11:45:02AM -0700, Adam Williamson wrote: > On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote: > > > I don't know if it's impossible to revert to the F17 anaconda at this > > time, however it is clear that F18 is going to be the longest release > > cycle we had in 9 years and somehow we need to avoid this in the > > future. > > It's not impossible, well, nothing is impossible, but at this point it's > almost certainly more of a disruption than just plowing on with newui. Also, I believe we haven't got close to the length of the Fedora Core 5 development cycle, which was more than 9 months.[1] Not that we should aim for it either, but it's certainly not a given we'll even get to that point. Thanks for pointing out that everyone is trying their best to avoid taking that prize. * * * [1] https://fedoraproject.org/wiki/Releases/HistoricalSchedules -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora development of Snap packages
On Wed, Jun 15, 2016 at 09:08:35AM -0700, Adam Williamson wrote: > On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote: > > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote: > > > So I was rather surprised by this Softpaedia article today: > > > http://news.softpedia.com/news/snap-packages-become-the-universal-bin > > > ary-format-for-all-gnu-linux-distributions-505241.shtml > > > It claims that Canonical state that they have been working with > > > Fedora developers to make this the universal packaging format. > > > The snapcraft.io site instructions say to use a COPR by a Canonical > > > employee who is not a Fedora packager. > > > Does anyone in marketing or development now what the article is > > > referring to and what's going on? > > > > Snappy fundamentally relies on apparmour to do confinement (i.e. it > > doesn't use filesystem namespaces like flatpak), how does this work on > > fedora? You can't use selinux and apparmour at the same time, so this > > shouldn't be able to work, unless they disable the containment feature. > > Right now, apparently, their install instructions tell you to disable > SELinux. Permissive mode is what they require: https://copr.fedorainfracloud.org/coprs/zyga/snapcore/ -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Schedule for Friday's FESCo Meeting (2016-08-19)
On Fri, Aug 19, 2016 at 10:58:06AM -0400, Josh Boyer wrote: > On Thu, Aug 18, 2016 at 5:43 PM, Adam Miller > wrote: > > Following is the list of topics that will be discussed in the > > FESCo meeting Friday at 16:00UTC in #fedora-meeting on > > irc.freenode.net. > We should handle https://fedorahosted.org/fesco/ticket/1612 too. Given the timing/schedule issue, would it be improper to ask about https://fedorahosted.org/fesco/ticket/1615 in this meeting? (I know the meeting's underway already and apologize for not seeing this thread in time.) -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Non-fatal error messages in Koji scratch build
http://paste.fedoraproject.org/157737/18064529 I had a bunch of 'sh: git: command not found' messages in a scratch build I did from an SRPM I uploaded, testing an epel7 build before submitting the real thing. It's been a while -- are these messages expected behavior? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Non-fatal error messages in Koji scratch build
On Mon, Dec 08, 2014 at 11:55:58AM -0700, Orion Poplawski wrote: > On 12/08/2014 11:51 AM, Paul W. Frields wrote: > > http://paste.fedoraproject.org/157737/18064529 > > > > I had a bunch of 'sh: git: command not found' messages in a scratch > > build I did from an SRPM I uploaded, testing an epel7 build before > > submitting the real thing. It's been a while -- are these messages > > expected behavior? > > > > looks like some (probably custom) autotool macros in that package want to make > use of git, probably to check if the build is a repo checkout. This is a > pretty package specific issue. Add a BR on git if it really needs it. Sure enough in configure.ac: AC_INIT([XMLStarlet], [m4_esyscmd_s([git describe --tags --dirty])], [http://sourceforge.net/projects/xmlstar/support], [], [http://xmlstar.sourceforge.net/]) Thanks for the tip, Orion. Seems I should add the BR to remove those issues, even though they're cosmetic. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Migration to Zanata
On Wed, Nov 26, 2014 at 11:41:10AM -0500, David Cantrell wrote: > On Wed, Nov 26, 2014 at 03:13:59PM +1000, Noriko Mizumoto wrote: > > Hi Fedora developers > > > > Having the consensus with FESCo [1], we FLP (aka translation team) have > > started the process of migration to new fedora.zanata.org instance from > > Transifex [2]. First all translators started to migrate in November 2014 > > (still going on). > > > > Now it is time to migrate all projects. This is expected to start after > > F21 GA. For the owners of the projects, there are two options to choose > > for the migration below. > > > > One: Delegate us to implement migration > > If this option is chosen, partially automated migration will be > > performed by Zanata team. Once it completes, then the owner visits new > > place and confirms everything intact (Some manual adjustment may be > > required). > > > > Two: Manual migration > > If this option is chosen, the owner performs all the migration process > > by his/her self. Please advise the estimated completion date. > > > > I have attached the list of all the target projects below. If any > > package is missing and it should be added into the list, please let me know. > > > > Could all Fedora developers please go through the list and advise which > > option is preferred for your project, so that we will be able to > > schedule them? For option One, we need to know current > > maintainer's/owner's contact. > > > > Package NameGroup > > Anacondamain > > Blivet main > > Firstboot main > > initial-setup main > > pykickstart main > > python-meh main > > system-config-kickstart main > > These are all installer team projects. What are we required to do with the > move to Zanata? I never saw an answer to this question on the devel@ list. David, did you get what you needed offlist somewhere? cc'ing Noriko since AIUI she is managing/leading the translation migration here. It needs to be clear to developers what they need to do in their toolchain. Without that clarity, the migration creates an additional risk to Fedora 22 release. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deleting f20-gnome-3-12 copr
On Wed, Jan 07, 2015 at 03:23:27PM +0100, drago01 wrote: > On Wed, Jan 7, 2015 at 3:13 PM, Pete Travis wrote: > > > > On Jan 7, 2015 6:00 AM, "Richard Hughes" wrote: > >> > >> I'm planning to delete > >> https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this > >> week. The original description always had "This COPR will be updated > >> until Fedora 21 has been released or until the entropy death of the > >> universe, whichever happens first." so I don't altogether feel too > >> guilty about abandoning it. Does anyone have any objections or wants > >> to volunteer to take it over before I delete the repo? > >> > >> Richard > >> -- > > > > While recognizing the massive maintenance burden of this COPR, I suspect the > > majority of objections will come from the enthusiast end user type - you > > know, the ones that are so eager to try the new thing they read about that > > they blow right past the description. > > Well one might think that those kind of users have updated to F21 to > get the "new shiny stuff" anyway. Announcing to the following should do the trick for those who haven't boarded the F21 boat: (1) announce@ (echoed to users@) (2) Fedora Magazine (echoed per usual to social media) -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: deadline for fedora org to appy in google summer of code 2015
On Tue, Feb 17, 2015 at 10:21:47AM -0500, Josh Boyer wrote: > On Tue, Feb 17, 2015 at 9:48 AM, Pierre-Yves Chibon > wrote: > > On Tue, Feb 17, 2015 at 09:43:45AM -0500, Josh Boyer wrote: > >> On Tue, Feb 17, 2015 at 9:36 AM, Pierre-Yves Chibon > >> wrote: > >> > On Tue, Feb 17, 2015 at 08:13:49AM -0500, Josh Boyer wrote: > >> >> On Tue, Feb 17, 2015 at 8:07 AM, Itamar Reis Peixoto > >> >> wrote: > >> >> > https://www.google-melange.com/gsoc/homepage/google/gsoc2015 > >> >> > > >> >> > 3 days, 5 hours remaining > >> >> > >> >> I don't believe Fedora will be applying to this any longer in an > >> >> official capacity. > >> > > >> > Is this an official statement or is there a discussion going on > >> > somewhere? > >> > >> No, it isn't official. I've heard a few comments to that effect over > >> the past few weeks, but I'm not aware of any on-list discussion. > > > > Anything public? > > I am asking as I was in close contact and helping the admins managing the > > Fedora organization for GSoC last year and I have not heard anything and > > thought > > we were going to apply as usual. > > I may have misunderstood the conversation I'm remembering. Apologies > for any confusion. > > I think someone needs to step up as the main coordinator for Fedora > and work with OSAS to make sure this is set. That was similar to the note I was writing just now. If we have trusted folks who've stepped up to own the coordination effort, just make sure the Fedora component of OSAS also knows who they are, and can contribute as needed to the application process. Regardless of how critical the GSoC projects are, they're a good way to mentor open source contribution. And as they say, the rising tide lifts all ships. If there are questions about the admin side, where's the best place to have such discussions? Seems OT for this list. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 08:05:30PM +0100, Reindl Harald wrote: > > Am 17.02.2015 um 17:54 schrieb Mathieu Bridon: > >Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : > >>On 02/17/2015 05:18 PM, Petr Pisar wrote: > >> > >>>Why not to create a new repository with reduced policy as > >>>Stephen proposed with the one-way dependency rule (between current > >>>Fedora and the new easy-for-beginners repository)? > >> > >>Because this would establish a 2-class society, with double > >>standards standards and so on. > >> > >>Also RH and other distros history repeatedly has told the lesson > >>such will not fly and are doomed to fail. > > > >It seems to have been working just fine in RPMFusion, where the free > >and nonfree repositories have different standards for inclusion, and > >where packages in nonfree can depend on packages in free, but not the > >other way > > maybe you are newer to Fedora than me > > what you describe is what was changed around Fedora 7 > http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#History > > * Fedora Core: Only Redhat > * Fedora Extras: Community > > not that i say that was bad *but* it was changed intentional > after the distribution is now claaed jsut "Fedora" > > you can turn and name it how you like but at the end of the day it would > mean going back to the state of Fedora Core 6 This isn't correct. The division of Core/Extras was based on who was allowed to touch packages which isn't part of this proposal. That wasn't a sustainable way to build community. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 04:52:20PM +, Peter Robinson wrote: > >> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, > >> >> > which are > >> >> > caused by systemd changes and have to be fixed in other components. > >> >> > >> >> Are you going to start notifying deve@ of upcoming changes that may > >> >> impact other areas of the distro too rather than just land them > >> >> without notification or discussion? > >> > > >> > Oh god, stop this, will you? > >> > >> No, I mean the above in general for general changes you make that > >> affect the distro as a whole. You generally land them without > >> notification. > > > > I "generally" do that? Can you be more precise? > > > >> > The folks in question knew I would drop the patch. In the original bug > >> > I even said I would remove the work-around from systemd.rpm after TC1 > >> > of the last cycle. I was nice, left it in for the whole cycle, only > >> > dropped it now. > >> > >> Yes, and it looks like it affects dhcpd too... just because you > >> notified one dev team on a single bug it's not the same as a wider > >> announcement to the wider community. There's all sorts of things that > >> this can affect, and while yes it may be a bug in their software, it > >> should be as widely notified as possible. People have priorities that > >> may not be the same as yours. > > > > Hey! Come on. Everything that systemd does is create a symlink for > > /etc/resolv.conf if nothing else has created on for that. If something > > else created and owned that file, it leaves the thing alone. That's > > all. It's very defensively written. Anaconda's file copy routine > > tripped up on it though, since it follows symlinks on the destination > > (which is a really bad idea, and needs to be fixed). > > > >> > There is no news in all of this, I just removed the work-around now, as > >> > indicated back then. > >> > >> Again, I'm not just referring to this single incident, it would be > >> nice if you notified people widely of changes. It's a community, > >> people don't all follow closely the upstream development of all > >> upstream components. > > > > Ok, then please list all those numerous incidents please. > > > >> > How many months would you like me to notify people in advance of a > >> > simple change like this? Isn't 6 month *ample* time? > >> > >> Likely not, not everyone has the same schedule as upstream systemd, in > >> a lot of cases they don't know it's broken until things land and teams > >> have other priorities. > > > > OK, got it, will let everybody know now of changes 5 years in > > advance. Would that suit your needs? > > Not what I'm saying at all. There's no need to throw toys to the > extreme just because someone is asking for a certain level of reason > and engagement. > > > Anyway, I have the suspicion you just want to make a fuss, and this is > > where it ends for me hence. > > Nope, I don't, I just want engagement, generally and overall I'm > actively positive for systemd and a big advocate for it. You just need > to engage in the community and if something isn't done in six months > because another team has other priorities and other deadlines and > people push back because it's actually breaking other areas of the > distribution there's no need to throw toys from the pram and storm > off. It's a large distro of moving parts and we need flexibility as a > result, things get pushed due to delays. It's not the end of the > world! I think we can do better than this level of communication. Yes, it would have been good to avoid a surprise here. There are issues on both sides. Blaming the situation on either impatience or sloth doesn't do any justice to the good efforts everyone makes. On one side, it may not be reasonable to expect that all teams track or follow up on every bug. It's right to expect some explicit notice and, more importantly, collaboration across teams -- talking to each other, not just filing a bug without clear expectations. On the other hand, Fedora is supposed to be innovative and we need to take a positive approach to change. When teams see a change coming up they know will cause them work or breakage, they can proactively reach out to engage. In fact, anyone can facilitate such a conversation. Also, a side not
Beta of new RH Bugzilla coming soon
I wanted to let the Fedora devel/maintainer community know that a public beta of Red Hat Bugzilla, based on upstream v5, is coming soon. There will be an official announcement with the URL and more details to accompany the beta when it's introduced. There will be a minimum two-week testing period (subject to extension) so the community can check scripts and other tooling for compatibility and file bugs for any issues discovered. Some work has already gone into python-bugzilla compatibility to make the transition easier. Please stay tuned for more information soon. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Beta of new RH Bugzilla coming soon
> On 02/06/2017 04:32 PM, Paul W. Frields wrote: > > Note, I'll likely be cutting a python-bugzilla release this week which fixes > some issues communicating with bugzilla 5. That's great Cole. Thanks for keeping up with this update. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The future of the packager group for dist-git
On Fri, Jun 02, 2017 at 09:42:48PM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > With pagure becoming a front-end to dist-git, I have been wondering about the > future of the packager group. > > The packager group is currently used for a few things: > - tracking purpose, it's one of our biggest groups and also one of the most > active > - members of the packager group can do official package review > - members of the packager group can become maintainer of a package > > Someone can join this packager group in a few ways: > - Being sponsored by someone after having submitted one or more packages for > review > - Being sponsored by someone after having offered to help maintaining a > package > (it is then left at the discretion of the sponsor to teach and help the new >packager to our workflow and procedures) > > Currently pagure does not check which group you are in when you log > in, so it has no idea about packager. We could make pagure only > allow people that are in the packager group to log in, but this > would defeat one of the main idea of pagure's type of workflow: > encourage drive-by/one-off contributions. > > With the deprecation of pkgdb2, pagure will make it even easier to > give someone access to a package, if someone wants to help you > maintain a package, you can just grant them access to the project on > pagure. They will only have access to that project and not anything > else. > > We could of course adjust pagure is such a way that it will enforce > being member of the packager group to be allowed to be added to a > project but this seems more pain than gain. (Note: pagure can and > will enforce the FPCA for dist-git) > > So I would like to ask if we are fine with stopping to require the > membership of the packager group to contributors? > > I do not see the packager group disappearing entirely since it will > still be needed for package reviews and we have given rel-eng > tooling to check and enforce this on new package requests, but I > think it makes sense to stop this requirement to commit on dist-git > repos. > > What do you think? The way I see it, this doesn't make maintaines give up control but avoids over-enforcement of controls that may no longer be useful. +1. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The future of the packager group for dist-git
On Sun, Jun 04, 2017 at 11:35:46PM +0100, Richard W.M. Jones wrote: > On Sun, Jun 04, 2017 at 07:24:36PM +0200, Pierre-Yves Chibon wrote: > > On Sun, Jun 04, 2017 at 02:42:20PM +0100, Tom Hughes wrote: > > > On 04/06/17 14:22, Richard W.M. Jones wrote: > > > > > > > > Sorry to push on this some more, but I'm still unclear on the details. > > > > > > > > Will the second Pagure instance store exploded trees of the upstream > > > > software? Will the dist-git RPM source + patches form be generated > > > > from that? > > > > > > As I understand it the repos will remain the same, there will just be a > > > new > > > web interface in front of them, and pkgdb will go away and instead you > > > will > > > be able to grant people push access in the pagure interface. > > > > That is correct, nothing is changing on the disk side but instead of the > > cgit > > interface we will have pagure on the top of the repo, allowing the use the > > fork/pull-request workflow. > > But we're still going to be able to use plain git, right? > Anything that requires a non-command-line interface for ordinary > procedures would be a step backwards IMHO. Plain git still usable the same ways, yes. The things Pagure is doing are additive (fork/PR, CI hooks, etc.). -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Coming soon: Pagure service for dist-git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For some time, the Fedora Infrastructure team and fellow community members have been working on service upgrades for package dist-git. This includes creating a Pagure front end like the one at <https://pagure.io>, a separate instance that enables forks and pull requests on dist-git. This change solves multiple problems -- both common, current ones, and predicted future ones -- that stymie community growth and contribution. Examples include proposing simple packaging fixes, changes to the dist-git branching model, and enabling better, more continuous production models for Fedora. These changes will *not* require packagers to change their workflows for existing processes. Using fedpkg and git at the command line to manage packaging will work just as before. However, it will now be possible for other contributors to suggest changes in a fork/pull-request model. WE'VE TALKED ABOUT THIS FOR A LONG TIME. WHY NOW? - - If you've been paying attention to release tooling efforts in Fedora, you know we're trying to accelerate the release of the Atomic Host deliverable. Part of this effort is establishing a pipeline for continuous integration and delivery (CI/CD) in Fedora[1]. This and the modularity effort also are driving the establishment of services like this dist-git front end. The hooks and capabilities of Pagure are part of enabling CI/CD. In early phases, these efforts will target the packages that comprise the Atomic Host, rather than the entire universe of Fedora packages. This temporary measure will prove out the pipeline in an open source, iterative way. In later phases, packagers throughout Fedora will be able to opt-in to the pipeline as well. The benefit is that we will know more often whether a package has problems before either breaking the distro or impacting users. In the future, we hope this will have a positive impact on Rawhide, making it usable by more of the community, more often. WHAT TO EXPECT - -- One of the contributions expected in this early phase is testing. The standard interface[2] developed as part of the CI effort provides a framework for test contributions. Shortly after Pagure/dist-git shows up, we hope to receive test contributions from quality engineers for packages that comprise the Atomic Host. These should come in the form of pull requests for the package maintainers, following the established standards. This is a benefit for Fedora not only because it kickstarts the CI effort, but because it provides examples the whole Fedora community can use in later phases. The intention is that maintainers and co-maintainers continue to control these tests so they can modify or add to them as needed. If you're a packager with a package in the Atomic Host, you may receive pull requests soon after the new Pagure instance is deployed, with these tests included. We encourage you to review and merge these pull requests (provided they look good), so your package can take advantage of the CI work. If you have problems with the pull request, you can use the Pagure instance to work with the contributor to fix it. It is possible to turn off PRs for your dist-git repo in the repo settings. However, we strongly encourage you to allow PRs because this is a strong source of potential contributions with little or no downside. We plan to work with FESCo on a project-wide policy that makes sense and fits Fedora's values. WANT TO TRY IT OUT? - --- If you're interested to see what this new capability looks like, and want to test a working version, visit <https://src.stg.fedoraproject.org/pagure/>. Changes here won't affect the actual Fedora RPMs, but the staging instance lets you explore the new functionality. Note that the staging content is updated on a schedule, so some newer package data may not appear there. It will be at least a few more weeks before the production instance is ready. We appreciate your constructive feedback and bugs[3], as always. * * * [1] https://fedoraproject.org/wiki/CI [2] https://fedoraproject.org/wiki/Changes/InvokingTests [3] https://pagure.io/pagure/issues - -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -BEGIN PGP SIGNATURE- iD8DBQFZXmrvrNvJN70RNxcRAv2CAJsHL66rtcFl6z/ooEOyfexkye3gBQCeOpHF LQjAwhGOmVD2kjCD4W5Ql0c= =AyX9 -END PGP SIGNATURE- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproje
Re: Coming soon: Pagure service for dist-git
On Mon, Jul 10, 2017 at 05:02:25PM +0200, Pierre-Yves Chibon wrote: > On Mon, Jul 10, 2017 at 04:49:32PM +0200, Miroslav Suchý wrote: > > Dne 8.7.2017 v 20:43 Zbigniew Jędrzejewski-Szmek napsal(a): > > > Nah, most likely stg.fp.o is just some rpi on somebody's desk or a vm > > > stuck in the corner of the infrastructure. I don't think you can make > > > any conjectures about performance or reliability based on the staging > > > instance. > > > > Nope. AFAIK Stg machines are real machines in proper infrastructure. They > > may be slow by few percent, but moving to prod > > will not make it much faster. So if anything is slow in STG then it is > > valid issue. > > They are real machines but may have less memory or cpus than prod ones. So it > is > at this stage a little hard to figure how better or worse it will be in prod. Although also fair to point out there've been numerous performance improvements thus far, and no reason to think there won't be more. Pagure is eminently hackable so we are still encouraging contribution upstream (of which there has been a lot already). -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora engineering manager
Hi Fedora folks, Hopefully some of you know me, possibly as a previous Fedora Project Leader at Red Hat. If you don't, then salutations, and please feel free to check out my Fedora wiki page[1] for my background. :-) As of next Monday, I'll be the reporting manager for Fedora Engineering team members -- those folks who work on Fedora full time in the Engineering department of Red Hat, other than the Fedora Project Leader, Robyn Bergeron. This doesn't really affect anything in the community, but I want to ensure that change is transparent to the community. These folks previously reported to Tom 'spot' Callaway, who remains at Red Hat, and has kindly given me his good wishes in the new job. Of course, we fully expect to continue working together around the Fedora community. I'm lucky to be coming on board with an awesome team full of great people, and I'm excited about working with all of them! Of course there will be some transition time while I manage the backfill for my other work at Red Hat, but you'll start seeing more of me around here in the near future. Sorry for the interruption -- now back to the normal Fedora stuff. = = = [1] https://fedoraproject.org/wiki/User:Pfrields -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora engineering manager
On Thu, Oct 31, 2013 at 09:47:36PM -0500, Dennis Gilmore wrote: > El Thu, 31 Oct 2013 22:42:52 -0400 > "Paul W. Frields" escribió: > > Hi Fedora folks, > > > > Hopefully some of you know me, possibly as a previous Fedora Project > > Leader at Red Hat. If you don't, then salutations, and please feel > > free to check out my Fedora wiki page[1] for my background. :-) > > > > As of next Monday, I'll be the reporting manager for Fedora > > Engineering team members -- those folks who work on Fedora full time > > in the Engineering department of Red Hat, other than the Fedora > > Project Leader, Robyn Bergeron. This doesn't really affect anything > > in the community, but I want to ensure that change is transparent to > > the community. > > Just so its clear, I think I'm the only other person who works full > time on Fedora at Red Hat, but I'm in a different part of the > organisation and have a different reporting structure. Oops! You know, it would be easier if I just list the people that will be reporting to me as of Monday: Ralph Bean Aurelien Bompard Josh Boyer Pierre Chibon Mo Duffy Ricky Elrod Kevin Fenzi Justin Forbes Dave Jones Toshio Kuratomi Ryan Lerch Luke Macken Stephen Smoogen Ian Weller -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 09:21:15AM -0500, Ray Strode wrote: > I think this is a pretty good starting point for our development > direction, and sets the stage for us making positive progress in the > new working group model. > > I do think we should keep it open to tweaks in the future as things > play out, (at the discretion of the 9 members on the working group). > In other words, I think it lays a solid outline for enabling us all > to know which direction to go, but i want to make sure if it doesn't > ever "get in the way". The working group should treat it as a living > document that gets updated as necessary to reflect changes in the > landscape. Agreed, it's a good start. One question... > > Case 2: Independent Developer > > Personal development system for an independent software developer doing > > contract work or developing apps for a new opportunity. > > > > Desktop Apps: Up to date desktop with email client, browser, productivity > > suite, messaging, and complete set of desktop apps and utilities. Desktop > > apps should be sufficient to make this system the developer's only > > computer. > s/and complete/and a complete/ > s/make this/make this/ > > [... snip other use cases that sound good ...] > > > Other users > > While the developer workstation is the main target of this system and what > > we > > try to design this for, we do of course also welcome other users to the > > Fedora Workstation. In fact many of the changes and improvements we expect > > to > > implement for developers will be equally beneficial to other user segments, > I think this is a really important point. Developers are users, too, > just trying > to get their work done. We should make sure the OS doesn't get in the way, > and > that it doesn't enforce artificial barriers to entry. Just because a user may > know how the sausage is made, doesn't mean we should make them stuff their own > (so to speak). And if a user/developer doesn't know the inner workings of > Fedora, that's okay, too. We should be enabling the user to get the things > done he/she cares about, not forcing them to learn the things we care about. > > There should be no "You must be this tall to ride Fedora Workstation" signs. [...snip...] Is it the intent that the developer cases here completely subsume the case of a developer who is working primarily on Fedora itself (including the Worsktation)? Perhaps we should call that out to correctly prioritize integration of the various developer tools currently available or planned for the Workstation. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, Nov 01, 2013 at 10:24:20AM -0400, Christian Fredrik Kalager Schaller wrote: > Hi everyone, > Attached is the draft PRD for the Workstation working group. The > proposal tries to be relatively high level and focus on goals and > principles, but I have included some concrete examples at times to try > to provide some clarity on how the goals and principles could play out > in practice. > > I hope the community at large will take the time to read through it and > provide feedback so that when the working group meet next we can use > that feedback to start tuning in on the final form of the PRD. Here's a statement we may need to better clarify on p. 3: "The working group will also specify policies in terms of branding, themeing and desktop graphics." I think we should be clear that any branding efforts need to fit into the overall branding framework of Fedora. We should be careful to avoid having branding diverge between the products to an extent that makes it harder for us to identify them as part of a family of Fedora products. In my time as an FPL, I worked extensively with Fedora folks on trademark and brand guidelines. I suspect Robyn has done quite the same wherever possible. It would be a step backward to make it harder for people to readily identify any of the Fedora products with Fedora. This is really a suggestion for all the working groups, so I'm cc'ing server@ and cloud@ lists too. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 04:09:11PM +0100, Robert Mayr wrote: > 2014-01-30 Johannes Lips : > > > > > > > > On Thu, Jan 30, 2014 at 2:33 PM, Frank Murphy wrote: > >> > >> On Thu, 30 Jan 2014 14:15:56 +0100 > >> Tomasz Torcz wrote: > >> > >> > Personally I always felt that this symbiotic relationship was a big > >> > part of > >> > > what made Fedora interesting. > >> > > >> > Yes, but please don't paint Red Hat bussiness goals as "Fedora > >> > community goals". There is some intersection, but not equality. > >> > >> I would love to see alt Desktops stay, > >> but at the end of the day. > >> The old saying comes to mind: > >> > >> http://dictionary.cambridge.org/dictionary/british/he-who-pays-the-piper-calls-the-tune > >> > >> That's a fact of life in any business relationship. > > > > Well, but it's not only about money and a lot of contributors use their > > spare time to contribute, so I wouldn't stress this money thing too much. > > +1 > > I feel also it is not ok that people, who spend their spare time to > contribute *without* getting money for that, get treated without > respect. Persoanlly I read Christian's post as an insult, but I'm sure > he didn't want to be so rough. [...snip...] Knowing Christian personally, I don't think he intended it that way. But I think some people (I don't know about Christian) are frustrated by the idea that any discussion of change is motivated by trying to disenfranchise people, rather than figure out how Fedora can generate product that increases its relevance and value to the FOSS ecosystem. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 02:22:59PM +, "Jóhann B. Guðmundsson" wrote: > > On 01/30/2014 02:02 PM, Frank Murphy wrote: > >On Thu, 30 Jan 2014 14:59:44 +0100 > >Johannes Lips wrote: > > > >>Well, but it's not only about money and a lot of contributors use > >>their spare time to contribute, so I wouldn't stress this money thing > >>too much. > >> > >I didn't introduce the money angle, > >just putting into Common language, > >what has been inferred. > > One would think that Red Hat's community sponsorship is not a > “venture capital” or "Investment" sponsorship but that it is a > community sponsorship as it so clearly states everywhere but > apparently Red Hat looks at it that way that it "owns" the > community. From your posts I undersetand that you believe that there is an entity "Red Hat" that has a single thought process and attitude. This is patently untrue since Red Hat is a company made up of many people and they have differing opinions. Please stop painting everyone with one brush. It's not only non-constructive but it makes it less likely over time that people interested in constructive discussion will listen or participate. It would have been nice had the conversation started with a less incendiary idea than "pay to play," but hyperbole doesn't help. Now, that being said, I can tell you from personal experience that past Boards have debated the value of Spins too, and there's nothing sacred about questioning that value. One could argue OLPC, a Fedora Remix, achieved better visibilty and prominence than any Fedora spin. A million laptops out there boot with "Fedora Remix" on their startup screen, after all -- although certainly they are aging out. Coupled with better hosting and creation options, along with solving potential legal issues, I think a community could be just as easily built (maybe more so) around a Remix. So let's not start by putting too much sacred value on the term "Spin." Rather, let's think about what specific technical and community-building problems are caused by using Remixes, how to solve them, and then consider that effort on balance against status quo. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 09:58:51AM -0600, inode0 wrote: > On Thu, Jan 30, 2014 at 9:31 AM, Paul W. Frields wrote: > > So let's not start by putting too much sacred value on the term > > "Spin." Rather, let's think about what specific technical and > > community-building problems are caused by using Remixes, how to solve > > them, and then consider that effort on balance against status quo. > > Paul, my personal problem with all this remix talk is more of a > branding thing. While a spin can be called a remix in the same sense > that a square can be called a rectangle we lose important information > by doing that. Spins are special cases of remixes that assert values > about the spin and its creators that are important both to the > creators and to the consumers. Saying this image is all free software > from Fedora matters to people. And I think it matters to Fedora too > which is why we allow spins to use trademarks differently than > remixes. > > I can imagine a new organization of things. Perhaps a different way to > build and distribute what we now call spins. But I'm having a real > hard time calling them remixes or treating them in the same way as > remixes. And I think deciding the "fate" of spins before we even see > the "product" that will be all that is left to replace them is putting > the cart before the horse. That's fair. I'm not advocating at this point that such a fate even needs to be decided immediately. What I tried to advocate was that we not proceed in discussions about change from presumptions that things can't. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Preparing a new release of Fedora Developer Portal - asking for feedback
On Wed, Apr 20, 2016 at 12:53:44PM -0400, Joe Brockmeier wrote: > On 04/20/2016 12:52 PM, Pete Travis wrote: > > This might also be interesting for Docs people. > > > How can we have these sorts of conversations without the multi-list problem? > > There are several discussions that ought to involve marketing, docs, > design, etc. We definitely need to remove barriers to communications here. There's a lightly used list called logistics@ that was originally intended to allow contributors from multiple teams to have a discussion concerning all involved without cross posting. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora 24 background is unsuitable
On Mon, Apr 25, 2016 at 02:59:00PM +0100, Richard Hughes wrote: > For the upgrade feature the designers [sensibly] want me to use the > default background for the release we're upgrading to. When doing > F23->F24 this makes the upgrade UI look like a big boring black > square: http://imgur.com/dRY5iL6 > > Additionally, when upgraded, the darkness makes the GNOME Shell top > bar almost disappear visually which really doesn't work at all given > the special status it has. Is there any way we can either: > > * Lighten up the background we have now so it's less black and soul-consuming > * Choose another background we can use for all spins > * Just use the existing awesome upstream GNOME artwork for the workstation > > We already brand the workstation spin with the fedora background logo > on the wallpaper, in GDM, in the control center and in various other > places so I'm really confused why we've gone back to the days where we > needed to replace the background every cycle for all desktops when we > really only have one official workstation product. Can we take this to the design-team@ list? That would make more sense since the designers tend to congregate there. It seems to me it shouldn't be too difficult to find a suitable solution. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora on Macs, removing the release criterion
On Fri, Nov 11, 2016 at 07:55:06AM -0500, Josh Boyer wrote: > On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro > wrote: > > My $0.02 is that none of the reasons we requested the blocker criterion > > have changed. Dual boot with macOS is very important to attracting new > > users -- we're explicitly targeting macOS users, that's the user group > > where we think we have real potential for significant growth -- and I > > continue to prefer we block the release indefinitely if it's not > > working. We can't afford for our next Ars review to say "the installer > > is broken, try again next year." > > Then we, as a project, need to back that up with sufficient hardware > and test resources. Otherwise it is nothing more than a wish and will > continue to lead to problems like this. Adam W pinpointed an issue with "burner" Macs. I have a MBP myself that I treat as an appliance. I use it for Pro Tools and my non-FOSS related creative pursuits. I'm well aware of Apple's tactics when it comes to tight integration and OS/HW integrity. I don't mess with it at a low level, and don't test bare-metal installation on it (although I do test the live OS from USB). Also Michael pointed out something about a certain big company ;-) needing to provide hardware for the QA team. To the best of my knowledge, that company doesn't have a stake in putting products on e.g. Mac laptops. This is a community project, so let's see how we can handle this as a community, starting with the Workstation WG (as opposed to QA). That being said, I arranged to get an additional drive with some small $$ available from said company. I can use it to help with testing, since I happen to have hardware. My hope is other Workstation WG members will join me. Else we *do* look at removing criteria, not just throw them over the wall and expect QA to deal with it. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Infrastructure move -- thanks
I might be a bit biased from my perspective as the guy who manages the folks on the Infrastructure team. But I wanted to take a moment to say thank you to all the team members and everyone involved for conducting the recent colo move, a complex and critical process, in an outstanding manner. There were some difficulties along the way and the team dealt with them in their usual professional way. Kudos to all, and well done! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
