Re: Major wiki revisions: release process documentation, package maintenance instructions, repository documentation, Changes...
On Thu, 25 Sep 2014 19:58:19 -0700 Adam Williamson wrote: ...snip.. > I hope people find these contributions useful and not the contrary! > I'm hoping the Life Cycle page, the Repositories page, and the updated > Package update HOWTO and Package maintenance guide particularly will > be useful for folks, and the more reality-reflecting Updates Policy > page and the new Milestone freezes page will make the freeze process > clearer to people (which was my motivation coming into this whole > thing). It all just seemed like such a damn mess that burning it > down, fixing it, and asking forgiveness seemed like the best plan :) > and of course it's a wiki, so it's not like anything I changed is > lost forever. > > Thanks folks! Thanks for all the editing. ;) I've been trying to watch along in the wiki rss feed as you have made changes and from a quick glance it all looks great and much more readable. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Major wiki revisions: release process documentation, package maintenance instructions, repository documentation, Changes...
Hi, folks. As I hinted a bit, and as some of you might know from IRC, I've spent the last ~24 hours on something of an epic Wiki revision spree. I made some fairly major and possibly significant changes, so under the 'ask forgiveness' principle I thought I'd post a quick summary here. * As already mentioned, the "Change Deadlines" are no more. They are now "Milestone Freezes". See https://fedoraproject.org/wiki/Milestone_freezes . (Yeah, I can't decide on the capitalization). All (I think) significant linking pages have been updated appropriately. The new page should, I hope, form a useful and succinct guide to how the milestone freezes actually work. * https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle has been extensively updated and overhauled to reflect the current Fedora release process. I have added links to it to quite a lot of pages as I went along. * https://fedoraproject.org/wiki/Repositories is an entirely new page which specifically documents the Fedora repositories. Again, I have added links to this page from several other pages. * https://fedoraproject.org/wiki/Package_update_HOWTO is extensively overhauled. I ditched the huge, weird tables full of Xs which didn't appear to convey any useful information at all. Stuff that was about using the SCM, not actually about doing updates, was removed (see next line item). The rest of the content has been heavily modified and updated to reflect current practice and policies and, well, just be better. * https://fedoraproject.org/wiki/Package_maintenance_guide has been created from three (and a bit) sources: the package maintenance bits from the "Package update HOWTO", the "Using Fedora GIT" page which it is a rename of, and the "Using_git_FAQ_for_package_maintainers" page which now redirects to it. Having stuff about using the SCM in three different places, and half of it outdated since Fedora 14, seemed a bad idea. I believe it subsumes all the still-valid and useful content from all three sources, and adds some new and updated information. I like the format for the main guide/walkthrough, with the expandable notes for each step, but yell if you don't. * Various pages were adjusted to link or redirect to the above two pages. * There's a "Change Wrangler" page now - https://fedoraproject.org/wiki/Change_Wrangler - and some things which used to link to Jaroslav personally now link there (or to https://fedoraproject.org/wiki/Fedora_Program_Management , whichever is appropriate). * https://fedoraproject.org/wiki/ReleaseEngineering/Overview was extensively overhauled. * https://fedoraproject.org/wiki/Updates_Policy was adjusted to match the other changes. Nothing about the actual *policy it sets* was adjusted (at least not intentionally, please do check for mistakes), but various names were changed, links were redirected, and so on. Some of its descriptions of procedures were adjusted to reflect reality, principally in regards to Bodhi enabling and the early Branched period. * The old "Feature Freeze Policy" (which had been search-and-replaced to the "Change Freeze Policy", which caused it to finally cease to bear *any* resemblance to reality whatsoever) and "Branch Freeze Policy" pages have been effectively factored out of existence. The "Feature Freeze" is replaced by the Change "freezes" / checkpoints described at https://fedoraproject.org/wiki/Changes/Policy and by the milestone freezes. The "Branch Freeze" is replaced by the concept of the "Bodhi enabling point", documented at https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling (it now redirects to that page), and invoked in various other places where appropriate. The changes freeze policy page - https://fedoraproject.org/wiki/Changes_Freeze_Policy - is a kind of 'manual redirect' pointing to the other pages, as it's not clear which one someone who wound up at it would be looking for. * https://fedoraproject.org/wiki/Releases/Branched was somewhat overhauled. * I did a whole ton of smaller stuff as I went through - various pages got small updates, links were redirected and added (e.g. https://fedoraproject.org/wiki/Category:Package_Maintainers has rather more useful links in "Procedures, Policies and Guides" now), etc etc etc. You can check my Contributions page - https://fedoraproject.org/w/index.php?title=Special:Contributions/Adamwill&offset=&limit=500&target=Adamwill - for the whole record, and to check my work. * I also just did a quick blast through the QA space making some updates here and there - some light touches to pretty much all the 'primary' pages, QA, QA/Join, the Test Day and release validation SOPs, etc etc. Again, check my contribution history for the details. I hope people find these contributions useful and not the contrary! I'm hoping the Life Cycle page, the Repositories page, and the updated Package update HOWTO and Package maintenance guide particularly will be useful for folks, and the more reality-reflecting Updates Policy page and the new Milesto
Intent to orphan pdfbox
I need to give up maintaining pdfbox. Hopefully someone else will pick it up. Dependent packages are: # repoquery --whatrequires pdfbox --source | sort -u jabref-2.9.2-2.fc20.src.rpm solr-4.10.0-1.fc22.src.rpm tika-1.5-1.fc21.src.rpm Let me know if you want to take it. It currently FTBFS, but some patches have been posted: https://bugzilla.redhat.com/show_bug.cgi?id=1100445 - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
80x25 vtty video corruption
[plymouth either not installed (Fedora, openSUSE), or disabled via cmdline option (Mageia)] Adam Jackson wrote on 2014-09-24 12:28 (UCT-0400): > On Tue, 2014-09-23 at 21:35 -0400, Felix Miata wrote: >> with neither VGA= nor video= on cmdline, ttys are in a legacy 80x25 >> video mode that is broken. Trailing spaces are written to screen as high >> ASCII characters both in bash and parts of mc. Some program output that >> should be in text is also these junk characters. > That's probably a bug. It might be in your kernel, it might be in your > firmware. As a text mode issue it is sort of by definition not a > graphics bug, so if anyone else feels like investigating it be my guest. Reproduces using (non-KMS) gfxchips g400 (Dell BIOS) and Z7/Z9 (XG20 core)(sis in Xorg)(Phoenix CSS cME BIOS) in Rawhide (3.17rcx) & F21 (3.16.1-300). Does not occur using (KMS) gfxchips from Intel (945G), ATI (rv200) or Nvidia (nv11), nor with g400 or Z7/Z9 on Factory (3.16.2), nor with Z7/Z9 on Cauldron (3.17rc5). As there are no X drivers for the non-KMS gfxchips in the repos, would a bug filed on this just go in the wontfix bin anyway? If not, what component should it most likely go into? IOW, where's the bug? Clue?: On fresh boot, initial login on tty did thus: # ll / ... Output seemed OK until about the middle screen row, after reaching a directory with a timestamp Dec 23 2008. Subsequent lines all ended with the gibberish characters. On further study, I noticed that most lines output no filename or dirname. The few shown did output correctly the filename characters. # clear just fills the screen past the bash prompt with "Ĝ" characters. Editing cmdline, BS key also draws Ĝ. font= or not on cmdline makes no difference. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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: [RETRACTION] Re: Unofficial Poll: Flock 2015 (North America) Bids
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). Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQkdy4ACgkQeiVVYja6o6OktACdHIcXXkEFuuaN/gfWqmsPb3w0 NxQAoIN8vmNY/ccY8cGMgyTyAK38iTh0 =85Y+ -END PGP SIGNATURE- -- 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: 'Branch freeze policy' and 'Change deadline' naming change proposal
On Wed, 2014-09-24 at 12:41 -0700, Adam Williamson wrote: > Again, I'd recommend a renaming here. If we call the "Branch freeze" > something else then we can simply call those points the "Alpha Freeze", > "Beta Freeze" and "Final Freeze", which are the terms used informally in > any case, and would line up with the "freeze exception policy" which > determines what stuff can break those freezes. So since this email I've been engaged in a monumental wiki slash-n-burn expedition, but I just found some history I thought might be fun to share. I found that these points were actually called "Alpha Freeze", "Beta Freeze" and "Final Freeze" up until Fedora 13, then changed for Fedora 14 as a consequence of No Frozen Rawhide. The decision was documented by John Poelstra, but actually taken rather in passing in a FESCo meeting: http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-05-18-19.03.log.html there's some suggestion that No Frozen Rawhide means there isn't really strictly speaking a "freeze" any more (as Branched uses Bodhi and has an updates-testing repo which does not freeze; under the old system, Rawhide's single repository was frozen and you simply could not send builds anywhere without a freeze exception). Then notting (j'accuse!) somewhat desultorily suggests "Change deadline", it gets a couple of half-hearted acks, a vote on the entire release schedule (which is what was under discussion) is passed and the meeting moves on. So, it wasn't exactly a heartfelt choice in the first place :) Given that, and the rather unfortunate collision with the "Change" process, I feel fairly comfortable about going ahead and renaming them back to "Alpha freeze", "Beta freeze", "Final freeze", with the generic term "Milestone freeze". I've run this by jreznik, dgilmore, nirik, mattdm, and pjones (who was at the initial FESCo meeting) and they're all OK with (or in support of) the change. This doesn't affect policy in any way, it's purely a naming issue. The most prominent page that actually talks about them is probably Updates_Testing in any case, and that page still uses the 'milestone freeze' names today, it links to the "Change deadlines" page but names the links as "Alpha freeze", "Beta freeze" etc. It's also the name I've observed most people actually using in blocker meetings and suchlike, and matches the name of the "Freeze exception policy", which seemed to get much better reviews than the old "nice-to-have policy". So I think it's a pretty sensible change. I'm going ahead and doing it right now, as part of my larger wiki overhauls. I'd figure it'd be easy enough to change the names for the rest of F21 (so Beta Change Deadline becomes Beta Freeze and Final Change Deadline becomes Final Freeze) on the schedules, but we don't have to if we don't want to, it'd be easy enough to just explain that it's in transition. I take the argument about there not strictly speaking being a 'freeze' of the entire product, but it seems reasonable to simply explain in the relevant documentation (Updates_Policy, the update HOWTO, etc) that it is a freeze of the ''stable'' repository/state, not a freeze of the entire tree. We could call them "Alpha stable freeze", "Beta stable freeze" etc but I'm not sure that's really any clearer. I'll drop a mail about the other significant changes I've made to the Wiki once I'm done with it, you can follow live on my Contributions page and yell at me on IRC if you like :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: F-21 Branched report: 20140924 changes
Hi Jerry, On Thu, Sep 25, 2014 at 9:47 PM, Jerry James wrote: > On Wed, Sep 24, 2014 at 7:19 AM, Richard W.M. Jones wrote: >> I'm snowed under with work at the moment. >> >> These Fedora 21 packages should just need a bump release and rebuild, >> if any proven packager wants to give that a go. There are about 10 of them. >> >> Rich. > > I did ocaml-ulex last night. I'll try to get a couple more of them today. I have done first 8 broken package rebuilds in Fedora 21. You can do rest of the 6 packages :) Regards, Parag. -- 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: F-21 Branched report: 20140924 changes
Hi Richard, On Wed, Sep 24, 2014 at 6:49 PM, Richard W.M. Jones wrote: > On Wed, Sep 24, 2014 at 10:12:14AM +, Fedora Branched Report wrote: >> [cduce] >> cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = >> 0:ebd368022fd2bc7b305a42902efa4c90 >> [ocaml-bisect] >> ocaml-bisect-1.3-3.fc21.armv7hl requires ocaml(Camlp4) = >> 0:ebd368022fd2bc7b305a42902efa4c90 >> [ocaml-bitstring] >> ocaml-bitstring-2.0.4-5.fc21.armv7hl requires ocaml(Camlp4) = >> 0:ebd368022fd2bc7b305a42902efa4c90 > > etc etc > > I'm snowed under with work at the moment. > > These Fedora 21 packages should just need a bump release and rebuild, > if any proven packager wants to give that a go. There are about 10 of them. Let me help here by just rebuilding these packages in Fedora 21. Parag. -- 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: F-21 Branched report: 20140924 changes
On Wed, Sep 24, 2014 at 7:19 AM, Richard W.M. Jones wrote: > I'm snowed under with work at the moment. > > These Fedora 21 packages should just need a bump release and rebuild, > if any proven packager wants to give that a go. There are about 10 of them. > > Rich. I did ocaml-ulex last night. I'll try to get a couple more of them today. -- Jerry James http://www.jamezone.org/ -- 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: EPEL CentOS curator group proposal
Excerpts from Antonio Trande's message of 2014-09-25 17:15:45 +0200: > Hi Jim. > > On 09/25/2014 04:36 PM, Jim Perrin wrote: > > Earlier this week on the CentOS devel list I proposed an interim method > > to help make it easier for centos contributions to flow into epel. > > > > Essentially the proposal is that CentOS would like a 'curator' group > > (name can be determined later) similar to the wrangler's group. > > > > Members of this group would be responsible for shepherding packages > > designated by the various SIG efforts in CentOS through the process of > > getting these packages in epel. This means that rather than having an > > individual owner, packages would have group ownership. Members of this > > group will be required to have access to make package modifications on > > the CentOS side so that they meet the packaging standards for EPEL. > > Additionally, it would help to have an EPEL proven packager as part of > > the group as well in order to help make things move a little quicker. > > > > Would this be acceptable from an EPEL standpoint? What would be required > > from an EPEL perspective to make this happen? > > > EPEL is for RHEL, Scientific Linux, Oracle Enterprice other than CentOS; > would we need of special "curator" group for every distro? > CentOS contributions could flow simply by taking part on EPEL and by > integrating any special (previously discussed) packaging need . > This would be my take also, getting pkgs into EPEL is a pretty well defined process as is a becoming a packager. I don't see an extra step/group is needed within CentOS is needed. Group ownership of pkgs in EPEL? So many people can own a package already. I am unsure what the 'wrangler' group example is. -- -- Steve Traylen, CERN IT. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: planned bind-pkcs11 changes in F20+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2014 05:18 PM, Paul Wouters wrote: > On Thu, 25 Sep 2014, Tomas Hozza wrote: > > > I would like to inform everyone about changes I plan to do > > in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11 > > interface - needed by FreeIPA). > > > > Currently there is a bind-pkcs11 package which includes > > couple of utilities needed for working with PKCS#11. > > > > - From the user feedback I got during the past year or so, utilities > > from PKCS#11 didn't work much. I backported the native > > PKCS#11 functionality from Bind 9.10 and plan to add/change > > the following sub-packages: > > Sounds good to me. The only people this would affect are those running > bind with an hsm, and we'd hope they would be on rhel/centos to begin > with. But even if this moves gradually into there, it looks good. Good to hear that. I think Fedora is a great place for people wanting to try it out. I don't expect someone to run it in production enterprise environment on Fedora. > I was hoping bind 9.10+ would be able to do runtime pkcs#11 hsm stuff :/ > without the need for hacking and recompiling. Yeah, I was hoping for the same thing. Unfortunately it is not possible even with BIND 9.10 (which will be in F22). Upstream is opened to patches, but don't have time and interest to do it themselves. - From my point of view the ideal situation would be if BIND could fall back to using OpenSSL if there is no HSM configured (or working). Well, I might look into it in the future, but it is a low priority item for me, too. Unfortunately this adds "yet another" compiled version of named (there is already named-sdb). However the positive thing is that this way it will not change anything for current named users. Thanks for your opinion. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUJDRtAAoJEMWIetUdnzwtU/YIAMwMqdz7p2SUVvDXl46TfAb8 W+kyKxdyYLCyM5Am85bEN70FkLiMMaP1Y1VsGh3IpQr/j67/mX39iZSp8qyMsig0 Z0ooCV1TyupqnYzBzQoHjJE7zMHz/50MNhEkrrBHwel1iXa0As6H2Wiexn/enqQe CkzMnR9fvVNs2kY/htx40MSqSXELegQk0W90XhrvXG7QUx4kcraPAAhJwRjkNezp rrad1Xb19WUDkv2/990bppnkja6lN1I9efKyLDO7jIQ5JVYc4pNK4C6769uP95RO K1WaIEh089XwmVa0JkdiGNRQTId1OtqsSNiKIodsMoBYeoukl85cMi3ldYYoYqk= =N1i5 -END PGP SIGNATURE- -- 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: planned bind-pkcs11 changes in F20+
On Thu, 25 Sep 2014, Tomas Hozza wrote: I would like to inform everyone about changes I plan to do in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11 interface - needed by FreeIPA). Currently there is a bind-pkcs11 package which includes couple of utilities needed for working with PKCS#11. - From the user feedback I got during the past year or so, utilities from PKCS#11 didn't work much. I backported the native PKCS#11 functionality from Bind 9.10 and plan to add/change the following sub-packages: Sounds good to me. The only people this would affect are those running bind with an hsm, and we'd hope they would be on rhel/centos to begin with. But even if this moves gradually into there, it looks good. I was hoping bind 9.10+ would be able to do runtime pkcs#11 hsm stuff :/ without the need for hacking and recompiling. Paul -- 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: Review swap: python-pyngus
2014-09-25 16:36 GMT+02:00 Darryl L. Pierce : > I have a package I'd like to get reviewed and will swap a review with > someone else to get it done. > > https://bugzilla.redhat.com/show_bug.cgi?id=1146575 > If you can't find anybody to swap with, take *any* pending review and ping me, I'll review your package. H. > -- > Darryl L. Pierce > http://mcpierce.blogspot.com/ > Famous last words: >"I wonder what happens if we do it this way?" > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap: python-pyngus
I have a package I'd like to get reviewed and will swap a review with someone else to get it done. https://bugzilla.redhat.com/show_bug.cgi?id=1146575 -- Darryl L. Pierce http://mcpierce.blogspot.com/ Famous last words: "I wonder what happens if we do it this way?" pgpaSfOxFf7KV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] More bash security fixes incoming: stand by to test
One last thing before I sign off - I'm reliably informed the updates shipped yesterday don't entirely resolve the bash security issues, so more build(s) can be expected today. if people can stand ready to test and karma them ASAP, that'd be just awesome. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
planned bind-pkcs11 changes in F20+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all. I would like to inform everyone about changes I plan to do in Fedora 20+ due to Bug 1097752 (Support for native PKCS#11 interface - needed by FreeIPA). Currently there is a bind-pkcs11 package which includes couple of utilities needed for working with PKCS#11. - From the user feedback I got during the past year or so, utilities from PKCS#11 didn't work much. I backported the native PKCS#11 functionality from Bind 9.10 and plan to add/change the following sub-packages: bind-pkcs11 - will contain special version of named (named-pkcs11) which is compiled with the native PKCS#11 and doesn't use OpenSSL, for crypto, but some HSM. bind-pkcs11-libs - libdns and libisc compiled with native PKCS#11 functionality. These will be distributed as libdns-pkcs11 and libisc-pkcs11. bind-pkcs11-devel - development files for the native PKCS#11 versions of libisc and libdns. bind-pkcs11-utils - will provide utilities previously provided by the bind-pkcs11 package. The update path will be solved as described in Packaging guidelines. These utilities are compiled with native PKCS#11, too. If this changes could break someone's setup, please let me know so we can work on some solution. Otherwise I'll do the changes some day next week. Thank you. Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUJBjZAAoJEMWIetUdnzwti44H/11yHgr1tpvPOYuyqrnP3+wl UV5yiB5f8ygZdal9IclU7b9F/MrsB/lpsXVmyHHB3tPEF2ed9yTMyhNM3MrAV/pe Fu8VygUqkiL3ZC1R5jVL/qLK590RO374oLD7UTaHfC1zfu1MnVf3G+2NwtSlXUP1 SAHTU5jCgBf3/9sqykPjuxZ4nwiImpAziMaMrzDzqTVGHmwgO7+W02HVo0wAD9dl VJbdOL+HXIKQFIHyLDLJq+Zfn+qR06vG2L+aIPkAjkIsOM2ied9TtIuT+NQZQEs0 k0ccAL59Nr1aUtBDaNVWhf+AZ6cZBcWvKxYqooiRh2BaWs4JbWrm81PnIa/a4PU= =2KjZ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Virtualization Test Day today!
Just a quick reminder that it's virtualization test day today, folks - hop over to #fedora-test-day to join in the fun! https://fedoraproject.org/wiki/Test_Day:2014-09-25_Virtualization -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Xorg hangs/freeze frequently caused by deadlock - Fedora 21 Alpha
Hi guys, I'm not sure if it's kernel related, but I need some help to investigate this issue. There are any procedure that can I follow to collect more information about it? It's clear for me that's a regression between Fedora 20 and this first F21 alpha release. https://bugzilla.redhat.com/show_bug.cgi?id=1146246 Cheers, Filipe -- 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: Multiple directory ownership including filesystem package
On Wed, Sep 24, 2014 at 10:36 PM, Till Maas wrote: > I noticed that mulitple packages own /etc/bash_completion.d/ [...] On a side note, that's the legacy location for bash completion snippets. The modern one from which they're loaded on demand is: $ pkg-config --variable=completionsdir bash-completion More info in /usr/share/doc/bash-completion/README -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140925 changes
Broken deps for i386 -- [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [askbot] askbot-0.7.48-13.fc21.noarch requires python-django14 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [check-mk] check-mk-agent-1.2.4p5-1.fc22.i686 requires /usr/bin/ksh check-mk-multisite-1.2.4p5-1.fc22.noarch requires /usr/bin/ksh [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [lcg-util] lcg-util-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-libs-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-python-1.16.0-3.fc21.i686 requires libgfal.so.1 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [llvm] llvm-ocaml-3.4-15.fc22.i686 requires ocaml(Pervasives) = 0:4329e57fde14cc94b02a739d2595516b [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.5-8.fc21.i686 requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nodejs-w3cjs] nodejs-w3cjs-0.1.25-2.fc22.noarch requires npm(superagent-proxy) < 0:0.3 [nwchem]
F-21 Branched report: 20140925 changes
Compose started at Thu Sep 25 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [askbot] askbot-0.7.48-13.fc21.noarch requires python-django14 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freemedforms] freemedforms-0.9.0-0.3.beta1.fc21.armv7hl requires freediams(armv7hl-32) >= 0:0.9.0-0.3.beta1.fc21 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hgettext] ghc-hgettext-devel-0.1.30-2.fc21.armv7hl requires ghc-devel(setlocale-0.0.3-3cf3e7ebddb81827019e2578a9fb3114) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [js-of-ocaml] js-of-ocaml-1.3.2-4.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nodejs-w3cjs] nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(superagent-proxy) < 0:0.3 nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(superagent-proxy) >= 0:0.2.0 nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(commander) < 0:2.1 [ocaml-bin-prot] ocaml-bin-prot-2.0.9-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-bisect] ocaml-bisect-1.3-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-bitstring] ocaml-bitstring-2.0.4-5.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-gettext] ocaml-g
Re: [RETRACTION] Re: Unofficial Poll: Flock 2015 (North America) Bids
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. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
