https://fedoraproject.org/w/api.php?action=feedcontributions&user=Germano&feedformat=atomFedora Project Wiki - User contributions [en]2024-03-28T15:45:55ZUser contributionsMediaWiki 1.39.4https://fedoraproject.org/w/index.php?title=FOSDEM_2023&diff=667131FOSDEM 20232023-02-02T20:15:17Z<p>Germano: /* Fedora Project attendees & stand personnel */</p>
<hr />
<div>= FOSDEM 2023 in Brussels, Belgium =<br />
<br />
<br />
== About ==<br />
<br />
[https://fosdem.org FOSDEM] is the biggest free and non-commercial event organized by and for the community. Its goal is to provide Free and Open Source developers a place to meet. FOSDEM 2023 will be held on 4-5 February.<br />
<br />
<br />
== Location & transportation ==<br />
<br />
Attendance is free.<br />
<br />
ULB Campus Solbosh<br><br />
Avenue Franklin D. Roosevelt, 50<br><br />
1050 Bruxelles<br><br />
<br />
{|<br />
| [[Image:Map.png|Location ULB|thumb|440px]]<br> || [[File:Fosdem2023campus.png|ULB campus|thumb|350px]] <br />
|}<br />
<br />
The event is easily reachable by public transportation. For details, see below. If you are afraid of getting lost, the following links might help you:<br />
<br />
* [http://openstreetmap.org/?lat=50.81284&lon=4.3805&zoom=15&layers=B000FTF OpenStreetMap]<br />
* [http://maps.google.com/maps?ie=UTF8&z=17&ll=50.812375,4.380734&spn=0.005369,0.011373&om=1 Google Maps] <br />
* [http://www.map24.com/search?q=m24flnlFR7MvZTgC/iBlrIDJ9q_zns46z5JHE6pTcT2YkZz4Ym0spDlm7H0Gn1g5hzB0ySchZzndK22JfctXHKdV1J1y80brc5lwUnawdlLVoVOYIsWanA4z7CBlG98O5NTTU5ew7IpBWTG_vAi_qY7zQK_Pao6HCOoOfUvre3zDLsF68o1pXca/41GC_1l5aWa/yWIQ4RGzqDydGGiV0zKQT0f89Tbe0YU5sIsr4TFfEUr_GCG_GIvKDFyp2UPnNdVd/xma/ Map24] <br />
* [http://www.viamichelin.fr/viamichelin/int/dyn/controller/Cartes-plans?mapId=-tg6r70e5ejn8cp&dx=352.5&dy=179&empriseW=989&empriseH=702 ViaMichelin]<br />
<br />
<br />
== First time at FOSDEM? ==<br />
<br />
Read those excellent resources to learn more:<br />
<br />
* [https://talkweb.eu/openweb/3728/ FOSDEM 2023 – hotels, information, and facts]<br />
* [https://fosdem.org/2023/practical/ FOSDEM practical info]<br />
<br />
<br />
== Fedora Project attendees & stand personnel ==<br />
<br />
We should have 6-8 Ambassadors (or other contributors) so that at least three Ambassadors are always present at the stand. Some others will assist with the [https://fosdem.org/2023/schedule/track/distributions/ Distributions Devroom]. Sponsored participants are expected to stay at the stand/devroom for at least X hours per day.<br />
<br />
* If you're willing to volunteer for a shift at the Fedora stand, please put "stand staff" in the Comments column. Otherwise, put "attendee" there.<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| ''' No ''' || '''Name''' || '''Friday''' ||''' Saturday ''' || ''' Sunday ''' || ''' Comments ''' || ''' Languages ''' || ''' Travel funding ''' || ''' Need Lodging ''' || Topics<br />
|-<br />
|| 1 || [[User:bogomil|Bogomil Shopov]] || {{question}} || {{check}} || {{check}} || Stand staff || bg, en || No || No ||L10n, community building, ethical design, SDR<br />
|-<br />
|| 2 || [[User:suve|Artur Frenszek-Iwicki]] || {{check}} || {{check}} || {{check}} || Stand staff || en, pl, de (beginner) || No || No ||<br />
|-<br />
|| 3 || [[User:bittin]] || {{check}} || {{check}} || {{check}} || Stand staff || en, sv|| Yes || No ||<br />
|-<br />
|| 4 || [[User:t0xic0der|Akashdeep Dhar]] || {{check}} || {{check}} || {{check}} || Stand staff and Containers Devroom speaker || en, hi, bn || || || Containers, Virtual Machines, Video gaming, Websites and applications, Mentorship, Selfhosting<br />
|-<br />
|| 5 || [[User:ekidney|Emma Kidney]] || {{check}} || {{check}} || {{check}} || Stand staff || en || || || Open source design<br />
|-<br />
|| 6 || [[User:Jflory7|Justin W. Flory]] || {{check}} || {{check}} || {{check}} || Stand & Distro Devroom || en || n/a || n/a || Fedora Council, Fedora Mindshare, i3, how Fedora works and how to get involved<br />
|-<br />
|| 7 || [[User:ffmancera|Fernando F. Mancera]] || {{question}} || {{check}} || {{check}} || Stand staff || en , es || n/a || n/a || Networking, Rust, Mentorship, community<br />
|-<br />
|| 8 || [[User:smeragoel|Smera Goel]] || {{check}} || {{check}} || {{question}} || Stand staff || en , hi|| || || Mentorship, Outreachy, Fedora Badges, Open Source Design<br />
|-<br />
|| 9 || [[User:germano|Germano Massullo]] || || || || Attendee || en , it|| No || No || <br />
|-<br />
|| A || [[User:zbyszek|Zbigniew Jędrzejewski-Szmek]] || || || || Attendee || en , pl|| || || systemd, packaging, rust, rpmautospec<br />
|-<br />
|}<br />
<br />
{{check}} : available<br />
{{caution}} : unavailable<br />
{{question}} : pending / undecided<br />
<br />
== Satellite events ==<br />
<br />
Two events will take place on the Friday, 3 February before FOSDEM. Fedora Ambassadors and friends of Fedora are welcome to attend either:<br />
<br />
* '''[https://connect.centos.org/ CentOS Connect]''': Free to attend. "CentOS Connect is a free mini-conference focusing on CentOS Stream, the CentOS SIGs, and the entire Enterprise Linux ecosystem. CentOS Connect at FOSDEM happens February 3, 2023, the day before FOSDEM."<br />
* '''[https://chaoss.community/chaosscon-2023-eu/ CHAOSScon EU]''': $10 USD ticket. "Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, OSPO Metrics, Common Metrics, and Metric Models."<br />
<br />
<br />
== FOSDEM presentations involving Fedora ==<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| '''Date''' || ''' Time (CET) ''' || '''Topic''' || ''' Name ''' || '''Location/Devroom/Matrix''' || ''' URL ''' <br />
|-<br />
| Feb-4 || 1130 - 1200 || Fedora CoreOS - Your Next Multiplayer Homelab Distro || [[User:t0xic0der]] and [[User:sumantrom]] || Containers Devroom, Room UB2.252A (Lameere) || https://fosdem.org/2023/schedule/event/container_fedora_coreos/ and https://github.com/t0xic0der/fcos-workshop-fosdemcd-2023<br />
|-<br />
|Feb-5 || 1130 - 1155 || Modularity, ALP and the dream of the modular-distribution || [[User:defolos]] || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/modular_distro/<br />
|-<br />
|Feb-5 || 1430 - 1455 || Creative Freedom Summit Retrospective || [[User:ekidney]] and [[User:jchitas]] || Open Source Design Devroom, Room UB4.132 || https://fosdem.org/2023/schedule/event/creative_freedom_summit_retrospective/ <br />
|-<br />
| Feb-5||12:00 - 12:25||Building a Web UI for the Fedora installer: the reasons, the tools, and progress so far || Martin Kolman || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/anaconda_web_ui/<br />
|-<br />
| Feb-5 || 1400 -1425 || From Linux to Cloud to Edge and beyond: Evolution of women contributors in distros & FOSS || [[User:Amsharma|Amita Sharma]] || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/women_in_linux_foss/<br />
|-<br />
|}<br />
<br />
<br />
== Items to bring ==<br />
<br />
Want to bring something for the stand? Add it below!<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| ''' Quantity''' || '''Item''' || '''Person Responsible''' || '''Particulars'''<br />
|-<br />
|| 100x || Fedora Stickers || [[User:t0xic0der]] || Originally purchased for [https://fedoraproject.org/wiki/Hatch_Pune_India_2022 Fedora Hatch Pune India 2022] <br />
|-<br />
|| 1x || Raspberry Pi 4B (with protective case, power supply + cable, HDMI2MiniHDMI converter, 32GB MicroSD card with Fedora Linux, Flash card reader etc.) || [[User:sumantrom]] and [[User:t0xic0der]] || Subjected to the availability of a monitor, keyboard and mouse on the desk <br />
|-<br />
|| 1x || NooElec SDR dongle + some antennas || [[User:bogomil|Bogomil Shopov]] || I might demonstrate hot to intercept radio signals with this SDR while on "duty" at the booth.<br />
|}<br />
<br />
<br />
== More information ==<br />
<br />
Mailing list: fosdem at lists.fosdem.org. We will inform you when news about FOSDEM is available.<br />
<br />
* [https://signal.group/#CjQKILoPh43aEo220H4R2CLBRyGizZUSO6MuSu1Rdcg2KDWPEhBLXpC7gRTb9K7hBe8VBSbi Attendee chat on Signal]<br />
* Official Site: http://fosdem.org<br />
* RSS feed: http://fosdem.org/rss.xml<br />
<br />
<br />
== Pictures and Reports ==<br />
<br />
Coming soon.<br />
<br />
[[Category:Events]]<br />
[[Category:Events 2023]]<br />
[[Category:FOSDEM]]<br />
[[Category:Marketing]]</div>Germanohttps://fedoraproject.org/w/index.php?title=FOSDEM_2023&diff=667128FOSDEM 20232023-02-02T19:09:55Z<p>Germano: /* Fedora Project attendees & stand personnel */</p>
<hr />
<div>= FOSDEM 2023 in Brussels, Belgium =<br />
<br />
<br />
== About ==<br />
<br />
[https://fosdem.org FOSDEM] is the biggest free and non-commercial event organized by and for the community. Its goal is to provide Free and Open Source developers a place to meet. FOSDEM 2023 will be held on 4-5 February.<br />
<br />
<br />
== Location & transportation ==<br />
<br />
Attendance is free.<br />
<br />
ULB Campus Solbosh<br><br />
Avenue Franklin D. Roosevelt, 50<br><br />
1050 Bruxelles<br><br />
<br />
{|<br />
| [[Image:Map.png|Location ULB|thumb|440px]]<br> || [[File:Fosdem2023campus.png|ULB campus|thumb|350px]] <br />
|}<br />
<br />
The event is easily reachable by public transportation. For details, see below. If you are afraid of getting lost, the following links might help you:<br />
<br />
* [http://openstreetmap.org/?lat=50.81284&lon=4.3805&zoom=15&layers=B000FTF OpenStreetMap]<br />
* [http://maps.google.com/maps?ie=UTF8&z=17&ll=50.812375,4.380734&spn=0.005369,0.011373&om=1 Google Maps] <br />
* [http://www.map24.com/search?q=m24flnlFR7MvZTgC/iBlrIDJ9q_zns46z5JHE6pTcT2YkZz4Ym0spDlm7H0Gn1g5hzB0ySchZzndK22JfctXHKdV1J1y80brc5lwUnawdlLVoVOYIsWanA4z7CBlG98O5NTTU5ew7IpBWTG_vAi_qY7zQK_Pao6HCOoOfUvre3zDLsF68o1pXca/41GC_1l5aWa/yWIQ4RGzqDydGGiV0zKQT0f89Tbe0YU5sIsr4TFfEUr_GCG_GIvKDFyp2UPnNdVd/xma/ Map24] <br />
* [http://www.viamichelin.fr/viamichelin/int/dyn/controller/Cartes-plans?mapId=-tg6r70e5ejn8cp&dx=352.5&dy=179&empriseW=989&empriseH=702 ViaMichelin]<br />
<br />
<br />
== First time at FOSDEM? ==<br />
<br />
Read those excellent resources to learn more:<br />
<br />
* [https://talkweb.eu/openweb/3728/ FOSDEM 2023 – hotels, information, and facts]<br />
* [https://fosdem.org/2023/practical/ FOSDEM practical info]<br />
<br />
<br />
== Fedora Project attendees & stand personnel ==<br />
<br />
We should have 6-8 Ambassadors (or other contributors) so that at least three Ambassadors are always present at the stand. Some others will assist with the [https://fosdem.org/2023/schedule/track/distributions/ Distributions Devroom]. Sponsored participants are expected to stay at the stand/devroom for at least X hours per day.<br />
<br />
* If you're willing to volunteer for a shift at the Fedora stand, please put "stand staff" in the Comments column. Otherwise, put "attendee" there.<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| ''' No ''' || '''Name''' || '''Friday''' ||''' Saturday ''' || ''' Sunday ''' || ''' Comments ''' || ''' Languages ''' || ''' Travel funding ''' || ''' Need Lodging ''' || Topics<br />
|-<br />
|| 1 || [[User:bogomil|Bogomil Shopov]] || {{question}} || {{check}} || {{check}} || Stand staff || bg, en || No || No ||L10n, community building, ethical design, SDR<br />
|-<br />
|| 2 || [[User:suve|Artur Frenszek-Iwicki]] || {{check}} || {{check}} || {{check}} || Stand staff || en, pl, de (beginner) || No || No ||<br />
|-<br />
|| 3 || [[User:bittin]] || {{check}} || {{check}} || {{check}} || Stand staff || en, sv|| Yes || No ||<br />
|-<br />
|| 4 || [[User:t0xic0der|Akashdeep Dhar]] || {{check}} || {{check}} || {{check}} || Stand staff and Containers Devroom speaker || en, hi, bn || || || Containers, Virtual Machines, Video gaming, Websites and applications, Mentorship, Selfhosting<br />
|-<br />
|| 5 || [[User:ekidney|Emma Kidney]] || {{check}} || {{check}} || {{check}} || Stand staff || en || || || Open source design<br />
|-<br />
|| 6 || [[User:Jflory7|Justin W. Flory]] || {{check}} || {{check}} || {{check}} || Stand & Distro Devroom || en || n/a || n/a || Fedora Council, Fedora Mindshare, i3, how Fedora works and how to get involved<br />
|-<br />
|| 7 || [[User:ffmancera|Fernando F. Mancera]] || {{question}} || {{check}} || {{check}} || Stand staff || en , es || n/a || n/a || Networking, Rust, Mentorship, community<br />
|-<br />
|| 8 || [[User:smeragoel|Smera Goel]] || {{check}} || {{check}} || {{question}} || Stand staff || en , hi|| || || Mentorship, Outreachy, Fedora Badges, Open Source Design<br />
|-<br />
|| 9 || [[User:germano|Germano Massullo]] || || || || Attendee || en , it|| || || <br />
|-<br />
|}<br />
<br />
{{check}} : available<br />
{{caution}} : unavailable<br />
{{question}} : pending / undecided<br />
<br />
== Satellite events ==<br />
<br />
Two events will take place on the Friday, 3 February before FOSDEM. Fedora Ambassadors and friends of Fedora are welcome to attend either:<br />
<br />
* '''[https://connect.centos.org/ CentOS Connect]''': Free to attend. "CentOS Connect is a free mini-conference focusing on CentOS Stream, the CentOS SIGs, and the entire Enterprise Linux ecosystem. CentOS Connect at FOSDEM happens February 3, 2023, the day before FOSDEM."<br />
* '''[https://chaoss.community/chaosscon-2023-eu/ CHAOSScon EU]''': $10 USD ticket. "Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, OSPO Metrics, Common Metrics, and Metric Models."<br />
<br />
<br />
== FOSDEM presentations involving Fedora ==<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| '''Date''' || ''' Time (CET) ''' || '''Topic''' || ''' Name ''' || '''Location/Devroom/Matrix''' || ''' URL ''' <br />
|-<br />
| Feb-4 || 1130 - 1200 || Fedora CoreOS - Your Next Multiplayer Homelab Distro || [[User:t0xic0der]] and [[User:sumantrom]] || Containers Devroom, Room UB2.252A (Lameere) || https://fosdem.org/2023/schedule/event/container_fedora_coreos/ and https://github.com/t0xic0der/fcos-workshop-fosdemcd-2023<br />
|-<br />
|Feb-5 || 1130 - 1155 || Modularity, ALP and the dream of the modular-distribution || [[User:defolos]] || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/modular_distro/<br />
|-<br />
|Feb-5 || 1430 - 1455 || Creative Freedom Summit Retrospective || [[User:ekidney]] and [[User:jchitas]] || Open Source Design Devroom, Room UB4.132 || https://fosdem.org/2023/schedule/event/creative_freedom_summit_retrospective/ <br />
|-<br />
| Feb-5||12:00 - 12:25||Building a Web UI for the Fedora installer: the reasons, the tools, and progress so far || Martin Kolman || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/anaconda_web_ui/<br />
|-<br />
| Feb-5 || 1400 -1425 || From Linux to Cloud to Edge and beyond: Evolution of women contributors in distros & FOSS || [[User:Amsharma|Amita Sharma]] || Distributions DevRoom - UA2.114 (Baudoux) || https://fosdem.org/2023/schedule/event/women_in_linux_foss/<br />
|-<br />
|}<br />
<br />
<br />
== Items to bring ==<br />
<br />
Want to bring something for the stand? Add it below!<br />
<br />
{| class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="100%" <br />
| ''' Quantity''' || '''Item''' || '''Person Responsible''' || '''Particulars'''<br />
|-<br />
|| 100x || Fedora Stickers || [[User:t0xic0der]] || Originally purchased for [https://fedoraproject.org/wiki/Hatch_Pune_India_2022 Fedora Hatch Pune India 2022] <br />
|-<br />
|| 1x || Raspberry Pi 4B (with protective case, power supply + cable, HDMI2MiniHDMI converter, 32GB MicroSD card with Fedora Linux, Flash card reader etc.) || [[User:sumantrom]] and [[User:t0xic0der]] || Subjected to the availability of a monitor, keyboard and mouse on the desk <br />
|-<br />
|| 1x || NooElec SDR dongle + some antennas || [[User:bogomil|Bogomil Shopov]] || I might demonstrate hot to intercept radio signals with this SDR while on "duty" at the booth.<br />
|}<br />
<br />
<br />
== More information ==<br />
<br />
Mailing list: fosdem at lists.fosdem.org. We will inform you when news about FOSDEM is available.<br />
<br />
* [https://signal.group/#CjQKILoPh43aEo220H4R2CLBRyGizZUSO6MuSu1Rdcg2KDWPEhBLXpC7gRTb9K7hBe8VBSbi Attendee chat on Signal]<br />
* Official Site: http://fosdem.org<br />
* RSS feed: http://fosdem.org/rss.xml<br />
<br />
<br />
== Pictures and Reports ==<br />
<br />
Coming soon.<br />
<br />
[[Category:Events]]<br />
[[Category:Events 2023]]<br />
[[Category:FOSDEM]]<br />
[[Category:Marketing]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661973Thinkpad X13s2022-11-29T17:38:16Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Wi-Fi ====<br />
Working<br />
<br />
==== Similar pages ====<br />
https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661972Thinkpad X13s2022-11-29T17:37:29Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Wi-Fi ====<br />
Working</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661971Thinkpad X13s2022-11-29T16:57:57Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Wi-Fi ====<br />
Working</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661970Thinkpad X13s2022-11-29T16:45:50Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Wi-Fi ====<br />
Working</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661969Thinkpad X13s2022-11-29T16:45:03Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Wi-Fi ====<br />
Working</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661968Thinkpad X13s2022-11-29T16:33:14Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Wi-Fi ====<br />
Working</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661967Thinkpad X13s2022-11-29T16:14:52Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC and #fedora-arm on Libera.chat. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== General kernel informations ====<br />
<br />
==== GPU ====<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661535Thinkpad X13s2022-11-22T01:15:54Z<p>Germano: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s, the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC and #fedora-arm on Libera.chat<br />
<br />
===== general kernel informations =====<br />
<br />
===== GPU =====<br />
<br />
===== sound =====<br />
<br />
===== virtualization =====</div>Germanohttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=661534Thinkpad X13s2022-11-22T01:14:07Z<p>Germano: Created page with "Page to keep track of Linux support development for Thinkpad X13s, the first Thinkpad with ARM CPU. Most of following informations come from #aarch64-laptops on OFTC and #fedora-arm on Libera.chat ===== general kernel informations ===== ===== GPU ===== ===== sound ===== ===== virtualization ====="</p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s, the first Thinkpad with ARM CPU.<br />
Most of following informations come from #aarch64-laptops on OFTC and #fedora-arm on Libera.chat<br />
<br />
===== general kernel informations =====<br />
<br />
===== GPU =====<br />
<br />
===== sound =====<br />
<br />
===== virtualization =====</div>Germanohttps://fedoraproject.org/w/index.php?title=EPEL&diff=597607EPEL2020-12-14T12:03:12Z<p>Germano: Fixed PowerTools name in bash command</p>
<hr />
<div>{{autolang|base=yes}}<br />
<br />
[[Image:banner468x120.png]]<br />
<br />
= Extra Packages for Enterprise Linux (EPEL) =<br />
<br />
Welcome to the home of the EPEL Special Interest Group.<br />
<br />
== Quickstart ==<br />
<br />
* {{packagelink|https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm|epel-release-latest-6}}<br />
* {{packagelink|https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm|epel-release-latest-7}}<br />
* {{packagelink|https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm|epel-release-latest-8}}<br />
<br />
You may retrieve signed binary configuration files from one the above two links (varying by the major release number of the installation target machine). They may be automatically installed by root thus:<br />
<br />
* RHEL/CentOS 6:<br />
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm<br />
* RHEL/CentOS 7:<br />
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm<br />
* on RHEL 7 it is recommended to also enable the optional, extras, and HA repositories since EPEL packages may depend on packages from these repositories:<br />
# subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms"<br />
* RHEL/CentOS 8:<br />
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm<br />
* on RHEL 8 it is required to also enable the codeready-builder-for-rhel-8-*-rpms repository since EPEL packages may depend on packages from it:<br />
# ARCH=$( /bin/arch )<br />
# subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms"<br />
* on CentOS 8 it is recommended to also enable the PowerTools repository since EPEL packages may depend on packages from it:<br />
# dnf config-manager --set-enabled powertools<br />
<br />
== What is Extra Packages for Enterprise Linux (or EPEL)? ==<br />
<br />
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, [[Red_Hat_Enterprise_Linux | Red Hat Enterprise Linux]] (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). <br />
<br />
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.<br />
<br />
Learn more about EPEL in the following pages:<br />
<br />
* [[EPEL/FAQ | EPEL FAQ]]<br />
<br />
* [[About_EPEL |About EPEL]]<br />
<br />
* [[EPEL/GuidelinesAndPolicies|EPEL Guidelines and Policies]]<br />
<br />
== What packages and versions are available in EPEL? ==<br />
<br />
You can take a look on any of the available EPEL mirrors from our [https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL mirror list]<br />
<br />
Alternately, you can browse the package set:<br />
<br />
* EPEL 8: [https://download.fedoraproject.org/pub/epel/8/Everything/x86_64/ x86_64], [https://download.fedoraproject.org/pub/epel/8/Everything/s390x/ s390x],[https://download.fedoraproject.org/pub/epel/8/Everything/ppc64le/ ppc64le], [https://download.fedoraproject.org/pub/epel/8/Everything/aarch64/ aarch64], [https://download.fedoraproject.org/pub/epel/8/Everything/SRPMS/ sources]<br />
* EPEL 7: [https://download.fedoraproject.org/pub/epel/7/x86_64/ x86_64], [https://download.fedoraproject.org/pub/epel/7/ppc64le/ ppc64le], [https://download.fedoraproject.org/pub/epel/7/SRPMS/ sources] (EPEL-7 for aarch64 is no longer supported as Red Hat ended support for this architecture).<br />
* EPEL 6 ('''End of Life 2020-11'''): [https://download.fedoraproject.org/pub/epel/6/i386/ i386], [https://download.fedoraproject.org/pub/epel/6/x86_64/ x86_64], [https://download.fedoraproject.org/pub/epel/6/SRPMS/ sources]<br />
<br />
== END OF LIFE RELEASES ==<br />
<br />
'''THESE ARE NO LONGER SUPPORTED'''<br />
<br />
* EPEL 5: [https://download.fedoraproject.org/pub/archive/epel/5/ ],<br />
* EPEL 4: [https://download.fedoraproject.org/pub/archive/epel/4/ ]<br />
<br />
== How can I use these extra packages? ==<br />
<br />
EPEL has an 'epel-release' package that includes gpg keys for package signing and repository information. Installing this package for your Enterprise Linux version should allow you to use normal tools such as yum to install packages and their dependencies. By default the stable EPEL repo is enabled, there is also a [[EPEL/testing|'epel-testing' repository]] that contains packages that are not yet deemed stable. <br />
<br />
{{admon/tip|NOTE for RHN users|You need to also enable the ''''optional'''' repository to use EPEL packages as they depend on packages in that repository. This can be done by enabling the RHEL optional [https://access.redhat.com/kb/docs/DOC-11313 subchannel] for RHN-Classic. For certificate-based subscriptions see [https://access.redhat.com/site/documentation/en-US/Red_Hat_Subscription_Management/1/html/RHSM/entitlements-and-yum.html#supplementary-repos Red Hat Subscription Management Guide].}}<br />
{{admon/tip|NOTE for RHEL 7 users with certificate subscriptions|EPEL 7 packages assume that the ''''optional'''' repository (rhel-7-server-optional-rpms for servers) and the ''''extras'''' repository (rhel-7-server-extras-rpms for servers) are enabled. You can do this with: <code>subscription-manager repos --enable rhel-7-server-optional-rpms --enable rhel-7-server-extras-rpms</code>}}<br />
{{admon/tip|NOTE for RHEL 8 users with certificate subscriptions|EPEL packages assume that the ''''codeready-builder'''' repository is enabled. You can do this with: <code>subscription-manager repos --enable "codeready-builder-for-rhel-8-$(arch)-rpms"</code>}}<br />
{{admon/tip|NOTE for CentOS 8 users|EPEL packages assume that the ''''PowerTools'''' repository is enabled. You can do this with: <code>dnf config-manager --set-enabled PowerTools</code>}}<br />
{{admon/tip|NOTE for CentOS users|You can install EPEL by running '''yum install epel-release'''. The package is included in the CentOS Extras repository, enabled by default.}}<br />
<br />
You can verify these packages and their keys from the Fedora project's keys page: https://fedoraproject.org/keys<br />
<br />
== Can I rely on these packages? ==<br />
<br />
The EPEL project strives to provide packages with both high quality and stability. However, EPEL is maintained by a community of people who generally volunteer their time and no commercial support is provided. It is the nature of such a project that packages will come and go from the EPEL repositories over the course of a single release. In addition, it is possible that occasionally an incompatible update will be released such that administrator action is required. By policy these are announced in advance in order to give administrators time to test and provide suggestions.<br />
<br />
It is strongly recommended that if you make use of EPEL, and especially if you rely upon it, that you subscribe to the {{fplist|epel-announce}} list. Traffic on this list is kept to a minimum needed to notify administrators of important updates.<br />
<br />
== History and background of the project ==<br />
<br />
The EPEL project was born when Fedora maintainers realized that the same infrastructure that builds and maintains packages for Fedora would be great to also maintain add on packages for Enterprise Linux. Much of the early need was driven by what Fedora infrastructure needed on the RHEL machines that built and maintained Fedora. From there things have grown to a large collection of varied packages. See [[History_and_Philosophy_of_EPEL|our history and Philosophy page]] for more information. <br />
<br />
== How can I contribute? ==<br />
<br />
The EPEL SIG is always looking for interested folks to help out. We always need package maintainers, qa/testers, bug triagers, marketing and documentation writers. Please see our [[Joining_EPEL | Joining EPEL]] page for more information on how to join the SIG. <br />
<br />
== Communicating with the EPEL SIG ==<br />
<br />
There are many ways to communicate with the EPEL SIG and its members: <br />
<br />
* The {{fpchat|#epel}} IRC channel on [https://freenode.net freenode] offers real-time support for EPEL users and developers. <br />
<br />
* The {{fplist|epel-devel}} is for general developer and SIG discussion. <br />
<br />
* The {{fplist|epel-announce}} mailing list is a low volume mailing list for only important announcements. <br />
<br />
* The {{fplist|epel-package-announce}} list is a list that gets information about package updates as they happen in the stable repository. <br />
<br />
* If you find a bug in a EPEL maintained package, please report it to [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+EPEL https://bugzilla.redhat.com/] under the "Fedora EPEL" product.<br />
<br />
* The EPEL SIG meets on Friday every week in the {{fpchat|#fedora-meeting}} channel at 21:00 UTC. Please check the time on the [https://apps.fedoraproject.org/calendar/epel/ epel calendar]; sometimes it can change or a meeting can be skipped. Feel free to join us! Logs of past meetings can be viewed in [https://meetbot.fedoraproject.org/sresults/?group_id=epel&type=team meetbot].<br />
<br />
<br />
[[Category:EPEL]]<br />
[[Category:SIGs]]<br />
[[Category:Fedora special-interest groups]]<br />
[[Category:Fedora sub-projects]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Events&diff=526830Events2018-10-10T07:24:44Z<p>Germano: </p>
<hr />
<div>{{Header|events}}<br />
{{autolang|base=yes}}<br />
<br />
The purpose of this page is to build '''a global Fedora events calendar''', and to identify '''responsible Ambassadors''' for each event.<br />
<br />
This page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning.<br />
<br />
Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding.<br />
<br />
Additional information:<br />
* '''[[Reimbursements]] -- reimbursement guidelines.'''<br />
* '''[[FAmSCo_budget|Budget]] -- budget for the current quarter (as distributed by FAMSCo).'''<br />
* '''[[Sponsoring event attendees|Sponsorship]] -- how decisions are made to subsidize travel by community members.'''<br />
* [[How_to_organize_a_Fedora_event|Organization]] -- event organization, budget information, and regional responsibility.<br />
* [[Event reports]] -- guidelines and suggestions.<br />
* [[Event Wiki Template]] -- template for Event pages<br />
* [[Linux_Events|Linux events]] -- a collection of calendars of Linux events.<br />
<br />
<br />
<br />
== North America (NA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|NA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| March 8-11, 2018 || [http://www.socallinuxexpo.org/scale/16x// SCaLE 16x 2018] || Pasadena CA || [[User:lajuggler| Perry Rivera]] || [[SCaLE_16X_Event | Fedora @ SCALE 16X]] || 1000 || yes || yes || [[SCaLE_16X_Event#Event_Reports|Reports]] <br />
|-<br />
| April 28-29, 2018 || [https://linuxfestnorthwest.org/conferences/lfnw18 LFNW 2018] || Bellingham, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/LinuxFest_Northwest_(LFNW)_2018#Event_Reports Fedora @ LFNW 2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/2018/03/linuxfest-northwest-2018.html reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|NA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Aug 17-19, 2018 || [https://devconf.info/us/ DevConf.US] || Boston, MA, USA || [[User:spot|Tom Callaway]] || [[DevConf_US_2018_Event | Fedora @ DevConf.US 2018]] || ? ||Yes || Yes || [[DevConf_US_2018_Event#Event_Reports|Reports]]<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|NA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| November 9-10, 2018 || [https://seagl.org SeaGL 2018] || Seattle, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/SeaGL_2018 SeaGL_2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/ Reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Central & South America (LATAM) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|LATAM-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|LATAM-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|LATAM-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Europe, Middle East, and Africa (EMEA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|EMEA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|EMEA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-08-08}} - {{#formatdate:2018-08-11}}<br />
| [[Flock/2018]]<br />
| Germany, Dresden, The Radisson Blu Park Hotel & Conference Centre, Dresden Radebeul<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|EMEA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Still unknown<br />
| Fedora release party<br />
| CERN<br />
| [[User:Germano | Germano Massullo]]<br />
|<br />
| 50<br />
| Yes<br />
| No<br />
|<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|EMEA-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-12-27}} - {{#formatdate:2018-12-30}}<br />
| [[Chaos Communication Congress/2018]] (aka [[35C3]])<br />
| Germany, Leipzig, Leipziger Messe (aka MCCL)<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
== India, Asia, and Australia (India/APAC) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|APAC-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| April 18, 2018 || Fedora meetup || Pune, In || Pravins || [https://communityblog.fedoraproject.org/fedora-meetup-pune-march-2018/ blog] || 15 ||<br />
|-<br />
|| April 23, 2018 || Document Freedom Day || Coimbatore || woohuiren || [https://communityblog.fedoraproject.org/document-freedom-day-singapore-2018/ blog] || - ||<br />
|-<br />
|| May 11, 2018 || Fedora 28 Release Party BLR || Bangalore || sumantrom || [http://sumantrom.blogspot.in/2018/05/fedora-28-release-party-bangalore.html blog] || 50 ||<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|APAC-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| June 30, 2018 || Fedora Pune Meetup || India || pravins || [http://yadav-pooja.blogspot.com/2018/07/fedora-pune-meetup-and-fedora-28.html blog]|| 30 ||<br />
|-<br />
|-<br />
|| June 03, 2018 ||Fedora 28 Release Party Beijing || China || pany || [https://pany.fedorapeople.org/f28rp/report.html blog]|| -- ||<br />
|-<br />
|-<br />
|| Aug 04-05, 2018 ||DevconfIN|| India|| sumantrom || ---|| -- ||<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|APAC-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|APAC-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
<br />
<br />
== Past Events ==<br />
<br />
The old events can be found in the [[Past Fedora events|archive]].<br />
<br />
[[Category:Marketing]] [[Category:Events]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Events&diff=526829Events2018-10-10T07:23:25Z<p>Germano: </p>
<hr />
<div>{{Header|events}}<br />
{{autolang|base=yes}}<br />
<br />
The purpose of this page is to build '''a global Fedora events calendar''', and to identify '''responsible Ambassadors''' for each event.<br />
<br />
This page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning.<br />
<br />
Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding.<br />
<br />
Additional information:<br />
* '''[[Reimbursements]] -- reimbursement guidelines.'''<br />
* '''[[FAmSCo_budget|Budget]] -- budget for the current quarter (as distributed by FAMSCo).'''<br />
* '''[[Sponsoring event attendees|Sponsorship]] -- how decisions are made to subsidize travel by community members.'''<br />
* [[How_to_organize_a_Fedora_event|Organization]] -- event organization, budget information, and regional responsibility.<br />
* [[Event reports]] -- guidelines and suggestions.<br />
* [[Event Wiki Template]] -- template for Event pages<br />
* [[Linux_Events|Linux events]] -- a collection of calendars of Linux events.<br />
<br />
<br />
<br />
== North America (NA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|NA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| March 8-11, 2018 || [http://www.socallinuxexpo.org/scale/16x// SCaLE 16x 2018] || Pasadena CA || [[User:lajuggler| Perry Rivera]] || [[SCaLE_16X_Event | Fedora @ SCALE 16X]] || 1000 || yes || yes || [[SCaLE_16X_Event#Event_Reports|Reports]] <br />
|-<br />
| April 28-29, 2018 || [https://linuxfestnorthwest.org/conferences/lfnw18 LFNW 2018] || Bellingham, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/LinuxFest_Northwest_(LFNW)_2018#Event_Reports Fedora @ LFNW 2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/2018/03/linuxfest-northwest-2018.html reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|NA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Aug 17-19, 2018 || [https://devconf.info/us/ DevConf.US] || Boston, MA, USA || [[User:spot|Tom Callaway]] || [[DevConf_US_2018_Event | Fedora @ DevConf.US 2018]] || ? ||Yes || Yes || [[DevConf_US_2018_Event#Event_Reports|Reports]]<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|NA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| November 9-10, 2018 || [https://seagl.org SeaGL 2018] || Seattle, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/SeaGL_2018 SeaGL_2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/ Reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Central & South America (LATAM) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|LATAM-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|LATAM-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|LATAM-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Europe, Middle East, and Africa (EMEA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|EMEA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|EMEA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-08-08}} - {{#formatdate:2018-08-11}}<br />
| [[Flock/2018]]<br />
| Germany, Dresden, The Radisson Blu Park Hotel & Conference Centre, Dresden Radebeul<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|EMEA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Still unknown<br />
| Fedora release party<br />
| CERN<br />
| [[User:Germano | Germano Massullo]]<br />
|<br />
| 50<br />
|<br />
|<br />
|<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|EMEA-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-12-27}} - {{#formatdate:2018-12-30}}<br />
| [[Chaos Communication Congress/2018]] (aka [[35C3]])<br />
| Germany, Leipzig, Leipziger Messe (aka MCCL)<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
== India, Asia, and Australia (India/APAC) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|APAC-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| April 18, 2018 || Fedora meetup || Pune, In || Pravins || [https://communityblog.fedoraproject.org/fedora-meetup-pune-march-2018/ blog] || 15 ||<br />
|-<br />
|| April 23, 2018 || Document Freedom Day || Coimbatore || woohuiren || [https://communityblog.fedoraproject.org/document-freedom-day-singapore-2018/ blog] || - ||<br />
|-<br />
|| May 11, 2018 || Fedora 28 Release Party BLR || Bangalore || sumantrom || [http://sumantrom.blogspot.in/2018/05/fedora-28-release-party-bangalore.html blog] || 50 ||<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|APAC-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| June 30, 2018 || Fedora Pune Meetup || India || pravins || [http://yadav-pooja.blogspot.com/2018/07/fedora-pune-meetup-and-fedora-28.html blog]|| 30 ||<br />
|-<br />
|-<br />
|| June 03, 2018 ||Fedora 28 Release Party Beijing || China || pany || [https://pany.fedorapeople.org/f28rp/report.html blog]|| -- ||<br />
|-<br />
|-<br />
|| Aug 04-05, 2018 ||DevconfIN|| India|| sumantrom || ---|| -- ||<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|APAC-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|APAC-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
<br />
<br />
== Past Events ==<br />
<br />
The old events can be found in the [[Past Fedora events|archive]].<br />
<br />
[[Category:Marketing]] [[Category:Events]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Events&diff=526828Events2018-10-10T07:22:35Z<p>Germano: added CERN Fedora release party</p>
<hr />
<div>{{Header|events}}<br />
{{autolang|base=yes}}<br />
<br />
The purpose of this page is to build '''a global Fedora events calendar''', and to identify '''responsible Ambassadors''' for each event.<br />
<br />
This page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning.<br />
<br />
Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding.<br />
<br />
Additional information:<br />
* '''[[Reimbursements]] -- reimbursement guidelines.'''<br />
* '''[[FAmSCo_budget|Budget]] -- budget for the current quarter (as distributed by FAMSCo).'''<br />
* '''[[Sponsoring event attendees|Sponsorship]] -- how decisions are made to subsidize travel by community members.'''<br />
* [[How_to_organize_a_Fedora_event|Organization]] -- event organization, budget information, and regional responsibility.<br />
* [[Event reports]] -- guidelines and suggestions.<br />
* [[Event Wiki Template]] -- template for Event pages<br />
* [[Linux_Events|Linux events]] -- a collection of calendars of Linux events.<br />
<br />
<br />
<br />
== North America (NA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|NA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| March 8-11, 2018 || [http://www.socallinuxexpo.org/scale/16x// SCaLE 16x 2018] || Pasadena CA || [[User:lajuggler| Perry Rivera]] || [[SCaLE_16X_Event | Fedora @ SCALE 16X]] || 1000 || yes || yes || [[SCaLE_16X_Event#Event_Reports|Reports]] <br />
|-<br />
| April 28-29, 2018 || [https://linuxfestnorthwest.org/conferences/lfnw18 LFNW 2018] || Bellingham, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/LinuxFest_Northwest_(LFNW)_2018#Event_Reports Fedora @ LFNW 2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/2018/03/linuxfest-northwest-2018.html reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|NA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Aug 17-19, 2018 || [https://devconf.info/us/ DevConf.US] || Boston, MA, USA || [[User:spot|Tom Callaway]] || [[DevConf_US_2018_Event | Fedora @ DevConf.US 2018]] || ? ||Yes || Yes || [[DevConf_US_2018_Event#Event_Reports|Reports]]<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|NA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| November 9-10, 2018 || [https://seagl.org SeaGL 2018] || Seattle, WA || [[User:steelaworkn| Jeff Fitzmaurice ]] || [https://fedoraproject.org/wiki/SeaGL_2018 SeaGL_2018 ] || 600 || Yes || Yes || [http://steelaworkn.blogspot.com/ Reports]<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Central & South America (LATAM) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|LATAM-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|LATAM-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|LATAM-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|LATAM-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
== Europe, Middle East, and Africa (EMEA) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|EMEA-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|EMEA-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-08-08}} - {{#formatdate:2018-08-11}}<br />
| [[Flock/2018]]<br />
| Germany, Dresden, The Radisson Blu Park Hotel & Conference Centre, Dresden Radebeul<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|EMEA-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| Still unknown<br />
| Fedora release party<br />
| CERN<br />
| [[User:Germano]]<br />
|<br />
| 50<br />
|<br />
|<br />
|<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|EMEA-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
! Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
| {{#formatdate:2018-12-27}} - {{#formatdate:2018-12-30}}<br />
| [[Chaos Communication Congress/2018]] (aka [[35C3]])<br />
| Germany, Leipzig, Leipziger Messe (aka MCCL)<br />
| || || || || || <br />
|-<br />
|}<br />
<br />
== India, Asia, and Australia (India/APAC) ==<br />
'''NOTE''': Please do not remove events from the list until the end of the quarter. This helps the planning for following quarters.<br />
<br />
=== FY19 Q1 (March 2018 - May 2018) ===<br />
{{Anchor|APAC-FY19Q1}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| April 18, 2018 || Fedora meetup || Pune, In || Pravins || [https://communityblog.fedoraproject.org/fedora-meetup-pune-march-2018/ blog] || 15 ||<br />
|-<br />
|| April 23, 2018 || Document Freedom Day || Coimbatore || woohuiren || [https://communityblog.fedoraproject.org/document-freedom-day-singapore-2018/ blog] || - ||<br />
|-<br />
|| May 11, 2018 || Fedora 28 Release Party BLR || Bangalore || sumantrom || [http://sumantrom.blogspot.in/2018/05/fedora-28-release-party-bangalore.html blog] || 50 ||<br />
|}<br />
<br />
=== FY19 Q2 (June 2018 - August 2018) ===<br />
{{Anchor|APAC-FY19Q2}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|| June 30, 2018 || Fedora Pune Meetup || India || pravins || [http://yadav-pooja.blogspot.com/2018/07/fedora-pune-meetup-and-fedora-28.html blog]|| 30 ||<br />
|-<br />
|-<br />
|| June 03, 2018 ||Fedora 28 Release Party Beijing || China || pany || [https://pany.fedorapeople.org/f28rp/report.html blog]|| -- ||<br />
|-<br />
|-<br />
|| Aug 04-05, 2018 ||DevconfIN|| India|| sumantrom || ---|| -- ||<br />
|-<br />
|}<br />
<br />
=== FY19 Q3 (September 2018 - November 2018) ===<br />
{{Anchor|APAC-FY19Q3}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
=== FY19 Q4 (December 2018 - February 2019) ===<br />
{{Anchor|APAC-FY19Q4}}<br />
<br />
{|class="wikitable sortable"<br />
!Date !! Event !! Location !! Owner !! Description !! Estimated Attendance !! Event Box !! Vertical Banners !! Report Link<br />
|-<br />
|}<br />
<br />
<br />
<br />
== Past Events ==<br />
<br />
The old events can be found in the [[Past Fedora events|archive]].<br />
<br />
[[Category:Marketing]] [[Category:Events]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Package_Review_Process&diff=511570Package Review Process2018-02-22T22:44:15Z<p>Germano: fed-req-* is obsolete, now fedpkg must be used</p>
<hr />
<div>{{autolang|base=yes}}<br />
<br />
== Review Purpose ==<br />
<br />
In order for a new package to be added to Fedora, the package must first undertake a formal review. The purpose of this formal review is to try to ensure that the package meets the quality control requirements for Fedora. This does not mean that the package (or the software being packaged) is perfect, but it should meet baseline minimum requirements for quality.<br />
<br />
Reviews are currently done for totally new packages, [[Package_Renaming_Process#Re-review_required|package renames]], old packages that were once deprecated returning to the collection, and packages merged from the old Fedora Core repository.<br />
<br />
Note that some new packages may be exempt from the review process. Please see [[Packaging:ReviewGuidelines#Package_Review_Process]] for a list of criteria. If an exemption is warranted, the contributor can skip directly to step 8 of the process: filing a [[PackageDB_admin_requests|request]] in the package database. But note that a bugzilla ticket will still be required in order to complete that process; please use [[rhbug:1376885|this bug]] for this purpose and follow the instructions there.<br />
<br />
== Review Process ==<br />
<br />
There are two roles in the review process, that of the contributor and that of the reviewer. In this document, we'll present both perspectives.<br />
<br />
=== Contributor ===<br />
<br />
A Contributor is defined as someone who wants to submit (and maintain) a new package in Fedora. To become a contributor, you must follow the detailed instructions to [[Join the package collection maintainers]].<br />
<br />
As a Contributor, you should have already made a package which adheres to the [[Packaging:NamingGuidelines| Package Naming Guidelines]] and [[Packaging:Guidelines| Packaging Guidelines]]. There are also some packages that cannot be included in Fedora, to check if your package applies, check if it contains any [[Forbidden items]].<br />
<br />
When you're happy with your spec file, you should then submit that SRPM to a package review.<br />
Currently, this is done by following these steps:<br />
<br />
* Put your spec file and SRPM somewhere on the Internet where it can be directly downloaded (just HTTP(s), no registration pages or special download methods, please). If you have no place to put your spec and SRPM, use copr: [https://copr.fedorainfracloud.org/].<br />
* Fill out a [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review request for review in bugzilla]. For guidance, a [[:Image:PackageReviewProcess_review.png|screenshot of a sample bugzilla request is available for review]]. <br />
[[Image:PackageReviewProcess_review.png|right|x400px]]<br />
* If you do not have any package already in Fedora, this means you need a sponsor and to add FE-NEEDSPONSOR (Bugzilla id:177841) to the bugs being blocked by your review request. For more information read the [[How to get sponsored into the packager group]] wiki page.<br />
* Wait for someone to review your package! At this point in the process, the '''fedora-review''' flag is blank, meaning that no reviewer is assigned.<br />
{{admon/tip|Review Swaps| If nobody comments on your review request, you might want to mail to a mailing list (for example, {{fplist|devel}}) asking for a "review swap". This is an offer to do a review of someone else's package in exchange for them reviewing your package. This is usually one-for-one, or can be some other private arrangement depending on the difficulty of the respective packages. }}<br />
* There may be comments from people that are not formally reviewing the package, they may add NotReady to the Whiteboard field, indication that the review request is not yet ready, because of some issues they report. After you have addressed them, please post the URLs to the updated SPEC and SRPM file and remove it from the Whiteboard. It is expected that you will respond to commentary, including updating your submission to address it; if you do not, your ticket will be closed.<br />
* A reviewer takes on the task of reviewing your package. They will set the '''fedora-review''' flag to '''?'''<br />
* The reviewer will review your package. You should fix any blockers that the reviewer identifies. Once the reviewer is happy with the package, the '''fedora-review''' flag will be set to '''+''', indicating that the package has passed review.<br />
* If you have not yet been sponsored, you will not be able to progress past this point.<br />
* When your package pass the review, you should use the fedpkg tool to request a git repository for it. Before doing that you will need your [https://pagure.io/fedrepo_req pagure_api_token] configured and added into <code>~/.config/rpkg/fedpkg.conf</code><br />
[fedpkg.pagure]<br />
token = whatever<br />
For example, if your bugzilla review ticket is 12345 and you want your package in Fedora 27, use: <code>fedpkg --module-name <package-name> request-repo 12345</code> <br />
* As following, if you want to add your package into more Fedora releases, you can use the following command to request additional branches: <code>fedpkg --module-name <package-name> request-branch f27</code><br />
* When this is complete (tickets in Paquire for requests above are closed as processed), you can [[Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package|import your SRPM package]] into the SCM.<br />
* Checkout the package using <code>fedpkg clone <package-name></code> do a final check of spec file tags, etc.<br />
* Request a Koji build by running <code>fedpkg build</code>. (You will need to set up [[Infrastructure/Kerberos|Kerberos for Fedora project]])<br />
* Repeat the process for other branches you may have requested above:<br />
** Checkout given branch: <code>fedpkg switch-branch f26</code><br />
** Lets Koji build the package for this branch: <code>fedpkg build</code><br />
* Request updates for Fedora release branches, if necessary, using <code>fedpkg update</code> or another Bodhi interface as detailed in [[Bodhi]].<br />
* If possible, add your package to [[Upstream_release_monitoring|Upstream Release Monitoring]].<br />
* You should make sure the review ticket is closed. You are welcome to close it once the package has been built on the requested branches, or if you built for one of the Fedora release branches you can ask Bodhi to close the ticket for you when it completes the process. If you close the ticket yourself, use '''NEXTRELEASE''' as the resolution.<br />
<br />
You do not need to go through the review process again for subsequent package changes, and should not reference the review ticket in subsequent updates you create in Bodhi.<br />
<br />
=== Reviewer ===<br />
<br />
The Reviewer is the person who chooses to review a package.<br />
<br />
{{admon/note|fedora-review tool|<br />
fedora-review is a very useful tool for handling some grunt work in the review process and it is highly recommended that you take advantage of it. <code>dnf install fedora-review</code> and refer to the man page for more details. Note, however that it is not a replacement for human input and you still need to understand the [[Packaging:Guidelines|Packaging Guidelines]] thoroughly.}}<br />
<br />
{{admon/note|Comments by other people|<br />
Other people are encouraged to comment on the review request as well. Especially people searching for sponsorship should comment other review requests to show, that they know the [[Packaging:Guidelines|Packaging Guidelines]].}}<br />
<br />
The Reviewer can be any Fedora account holder who is a member of the [https://admin.fedoraproject.org/accounts/group/members/packager/* packager group]. (If the Contributor is not yet sponsored, the review can still proceed to completion but they will need to find a sponsor at some point.)<br />
<br />
* Search for a review request that needs a reviewer: http://fedoraproject.org/PackageReviewStatus/ ('''fedora-review''' flag is blank or the bug is assigned to nobody@fedoraproject.org) <br />
* If you notice some issues that need to be solved before you want to start a formal review, add these issues in a comment and set the Whiteboard of the bug to contain NotReady. This helps other possible reviewers to notice that the review request is not yet ready for further review action.<br />
* if you want to formally review the package, set the '''fedora-review''' flag to '''?''' and assign the bug to yourself.<br />
{{admon/note|Stepping back from a Review|If you want to step back from the review for any reason, reset the '''fedora-review''' flag to be blank '''and''' reassign the bug to the default owner of the component, which is '''nobody@fedoraproject.org'''}}<br />
* Review the package ...<br />
** Go through the MUST items listed in [[Packaging:ReviewGuidelines| Review Guidelines]] .<br />
** Go through the SHOULD items in [[Packaging:ReviewGuidelines| Review Guidelines]] .<br />
** The [https://fedorahosted.org/FedoraReview/ FedoraReview] tool (packaged as fedora-review) can help to automate this process.<br />
* Include the text of your review in a comment in the ticket. For easy readability, simply use a regular comment instead of an attachment.<br />
* Take one of the following actions:<br />
** '''ACCEPT''' - If the package is good, set the '''fedora-review''' flag to '''+''' <br />
{{admon/question|Time to sponsor?|If the Reviewer is also acting as Sponsor for the Contributor, then this is the time to sponsor the Contributor in the [https://admin.fedoraproject.org/accounts/ account system]}}<br />
** '''FAIL, LEGAL''' - If the package is legally risky for whatever reason (known patent or copyright infringement, trademark concerns) close the bug WONTFIX and leave an appropriate comment (i.e. we don't ship mp3, so stop submitting it). Set the '''fedora-review''' flag to '''-''', and have the review ticket block FE-Legal.<br />
** '''FAIL, OTHER''' - If the package is just way off or unsuitable for some other reason, and there is no simple fix, then close the bug WONTFIX and leave an appropriate comment (i.e. we don't package pornography for redistribution, sorry. Or, this isn't a specfile, it's a McDonald's menu, sorry.) Set the '''fedora-review''' flag to '''-'''.<br />
** '''NEEDSWORK''' - Anything that isn't explicitly failed should be left open while the submitter and reviewer work together to fix any potential issues. Mark the bug as NEEDINFO while waiting for the reviewer to respond to improvement requests; this makes it easier for reviewers to find open reviews which require their input.<br />
* Once a package is flagged as '''fedora-review +''' (or '''-'''), the Reviewer's job is done although they may be called upon to assist the Contributor with the import/build/update process and to ensure that the Contributor closes the ticket out when the process is complete.<br />
<br />
== Definitions for fedora-review Flag Settings ==<br />
{| border="1"<br />
|-<br />
|fedora-review||(BLANK)||Package Needs Review<br />
|-<br />
|fedora-review||?||Package Under Review<br />
|-<br />
|fedora-review||-||Package Failed Review, dropped for legal or other issues.<br />
|-<br />
|fedora-review||+||Package Approved<br />
|}<br />
<br />
== Special blocker tickets ==<br />
There are a few tickets which can be placed in the "Blocks" field to indicate specific ticket statuses:<br />
{| border="1"<br />
|-<br />
|FE-NEEDSPONSOR||The submitter requires a sponsor; the review can be done by anyone, but a sponsor will need to come and sponsor the submittor.<br />
|-<br />
|FE-DEADREVIEW||The review has been closed out because the submitter has left; users looking for packages to submit may find some possibilities in these dead tickets.<br />
|-<br />
|FE-Legal||The package is currently awaiting review by the legal team.<br />
|}<br />
<br />
== The Whiteboard ==<br />
To save time for reviewers, the page at http://fedoraproject.org/PackageReviewStatus/NEW.html will hide certain tickets which are not reviewable. The Whiteboard field can be used to mark a ticket with various additional bits of status which will cause it to be hidden or displayed differently.<br />
<br />
{| border="1"<br />
|-<br />
|NotReady||The package is not yet ready for review. It is possible to open a review ticket, mark it as NotReady, and continue to work on it until it's ready to be seen by a reviewer.<br />
|-<br />
|BuildFails||The package fails to build.<br />
|-<br />
|AwaitingSubmitter||The package review is stalled and cannot proceed without input from the submitter.<br />
|-<br />
|Trivial||The package is trivial to review. See below.<br />
|}<br />
<br />
The "Trivial" status is intended to indicate packages which, as an aid to new reviewers, are especially uncomplicated and easy to review. A ticket should not be marked as being trivial unless:<br />
* The package is known to build and a link to a scratch build is included.<br />
* The ticket explains any rpmlint output which is present.<br />
* The spec contains nothing which is unnecessary in modern Fedora (such as BuildRoot:, a %clean section or %defattr).<br />
* The spec is free from excessive or complicated macro usage.<br />
* The spec uses only the least complicated scriptlets which are taken directly from the [[Packaging:Scriptlets]] page.<br />
* The package contains no daemons.<br />
* The package is not especially security sensitive.<br />
* The code has undergone a thorough inspection for licensing issues. Anomalies which would be found by licensecheck should be explained.<br />
In short, this should be reserved only for those tickets which should be easily approachable by someone doing their first package review.<br />
<br />
== Tracking of Package Requests ==<br />
<br />
The [http://fedoraproject.org/PackageReviewStatus cached Package Review Tracker] provides various review-related reports and a simple way to search for reviews by package name or reporter name or others.<br />
<br />
== Authorship ==<br />
This document was originally authored by [[TomCallaway|Tom 'spot' Callaway]] in 2007 and has since been modified by many others.<br />
<br />
[[Category:Package Maintainers]]</div>Germanohttps://fedoraproject.org/w/index.php?title=DNF_system_upgrade&diff=511462DNF system upgrade2018-02-21T18:35:15Z<p>Germano: fixfiles onboot does a `touch /.autorelabel` for you so both are reasonable but fixfiles onboot is better. Source: grift from #selinux IRC channel</p>
<hr />
<div>{{autolang|base=yes}}<br />
<br />
== What is DNF system upgrade? ==<br />
<br />
[https://github.com/rpm-software-management/dnf-plugin-system-upgrade dnf-plugin-system-upgrade] is a plugin for the [[Dnf|dnf]] package manager which handles system upgrades. It is the recommended command line upgrade method for Fedora 21 and later (Except Atomic Host, which uses rpm-ostree; for that see [[Atomic_Host_upgrade]]).<br />
<br />
== What does DNF system upgrade do? ==<br />
<br />
DNF system upgrade can upgrade your system to a newer release of Fedora, using a mechanism similar to that used for offline package updates. The updated packages are downloaded while the system is running normally, then the system reboots to a special environment (implemented as a systemd target) to install them. Once installation of the updated packages is complete, the system reboots again to the new Fedora release.<br />
<br />
== How do I use it? ==<br />
<br />
<ol><br />
<li> '''Back up''' your important data. Every system change is potentially risky, be prepared. In case you update your workstation, it is also wise to download a [https://getfedora.org/en/workstation/ Workstation Live image] and make sure your hardware (graphics card, wifi, etc) works well with the latest kernel and drivers.<br />
<li> Update your system using the standard updater for your desktop or {{command|dnf}}:<br />
<pre>$ sudo dnf upgrade --refresh</pre><br />
(Don't type the <code>$</code> in these commands; that just indicates that you type this at a terminal prompt as a non-root user.)<br />
<br />
After updating, we recommend you reboot your computer, especially if you've just installed a new kernel.<br><br />
<ul><br />
<li>Please note that there is [[Common_F23_bugs#plymouth-theme-upgrade|an issue]] if you use a non-default plymouth boot theme. If you do, please follow the issue description to make sure your upgrade will not be affected.<br />
<li>Double check your DNF configuration in {{filename|/etc/dnf/dnf.conf}}, if you have done any custom configuration (either manually or via third-party tool), it's recommended to revert it to default before updating and upgrading your system.<br />
</ul><br />
<li> Install {{package|dnf-plugin-system-upgrade}} package:<br />
<pre>$ sudo dnf install dnf-plugin-system-upgrade</pre><br />
<br />
<li> Download the updated packages:<br />
{{#tag:pre|$ sudo dnf system-upgrade download --refresh --releasever={{FedoraVersionNumber}}}}<br />
Change the <code>--releasever=</code> number if you want to upgrade to a different system release. Most people will want to upgrade to the latest stable release, which is '''{{FedoraVersionNumber}}''', but if you're running Fedora {{FedoraVersionNumber|previous2}}, you might want to upgrade just to Fedora {{FedoraVersionNumber|previous}}. You can also use <code>{{FedoraVersionNumber|next}}</code> for upgrading to [[Branched]] or <code>rawhide</code> for upgrading to [[Rawhide]] (warning: those are not stable releases).<br />
<ul><br />
<li>If you are upgrading to Rawhide, you will need to import the rpm gpg key for it. This will be the highest numbered key version in {{filename|/etc/pki/rpm-gpg/}}. For example if there is a Branched release that is {{FedoraVersionNumber|next}}, then you should look for a {{FedoraVersionNumber|next2}}, and if there is <br />
currently no Branched release, it will be {{FedoraVersionNumber|next}}.<br />
{{#tag:pre|$ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-{{FedoraVersionNumber|next2}}-primary}}<br />
</ul><br />
<li>If some of your packages have unsatisfied dependencies, the upgrade will refuse to continue until you run it again with an extra {{code|--allowerasing}} option. This often happens with packages installed from third-party repositories for which an updated repositories hasn't been yet published. Please study the output very carefully and examine which packages are going to be removed. None of them should be essential for system functionality, but some of them might be important for your productivity.<br />
<ul><br />
<li>In case of unsatisfied dependencies, you can sometimes see more details if you add {{code|--best}} option to the command line.<br />
<li>If you want to remove/install some packages manually before running <code>dnf system-upgrade download</code> again, it's advisable to perform those operations with <code>--setopt=keepcache=1</code> dnf command line option. Otherwise the whole package cache will be removed after your operation, and you'll need to download all the packages once again.<br />
</ul><br />
<li>Trigger the upgrade process:<br />
<pre> $ sudo dnf system-upgrade reboot</pre><br />
This will reboot your machine immediately. The system should boot again into Fedora using the same kernel, but this time, the upgrade process appears on the boot screen.<br />
<li> Wait for the upgrade process to complete.<br />
</ol><br />
<br />
== Frequently Asked Questions ==<br />
<br />
=== How do I report issues that I find with upgrades? ===<br />
First see [[Common F{{FedoraVersionNumber}} bugs]] or [[Common F{{FedoraVersionNumber|next}} bugs]] to check if the problem is a very prominent issue we already know of. If it is not there, [https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=dnf-plugin-system-upgrade&resolution=--- search for an existing bug report]. If you do not see a report that matches your symptoms, you can file a new report from the search page. Please follow the bug reporting instructions mentioned in [https://github.com/rpm-software-management/dnf-plugin-system-upgrade this README] and in <code>man dnf.plugin.system-upgrade</code>.<br />
<br />
If you hit issues after upgrade with a specific package, file a bug against the package with which you are having issues.<br />
<br />
=== Does DNF system upgrade verify the software it runs or installs during upgrade? ===<br />
<br />
Yes. The package signing keys for newer Fedora releases are sent to older Fedora releases in order to allow DNF to verify the integrity of the packages it downloads. You can disable this function with the {{code|--nogpgcheck}} parameter if you need to do so for any reason (not recommended, you're then opened to attacks from malicious software).<br />
<br />
=== Will packages in third party repositories be upgraded? ===<br />
<br />
Yes, if they are set up like regular DNF repositories and do not hard code the repository path. Commonly-used third party repositories usually work fine, but if you attempt to upgrade prior to or soon after an official Fedora release, they may not have updated their repository paths yet, and DNF may be unable to find their packages. This will usually not prevent the upgrade running successfully, though, and you can update the packages from the third-party repository later.<br />
<br />
{{anchor|eol}}<br />
=== Can I upgrade from an [[End of life]] release? ===<br />
<br />
Note that Fedora strongly recommends against ever running an end-of-life release on any production system, or any system connected to the public internet, in any circumstances. You should never allow a production Fedora deployment to reach end-of-life in the first place.<br />
<br />
With that in mind, if you do have an end-of-life release newer than Fedora 20 installed on a system you cannot just discard or re-deploy, you can attempt to upgrade it, though this is a less-tested and less-supported operation. You can try to upgrade through intermediate releases until you reach a currently-supported release, or try to upgrade to a currently-supported release in a single operation. It is not possible to state with certainty which approach is more likely to be successful.<br />
<br />
If you attempt to upgrade across more than two releases in one operation, please also read the [[#multi|next answer]].<br />
<br />
If you have Fedora 20 or earlier installed, you cannot upgrade with DNF system upgrade alone. You must upgrade at least part of the way [[Upgrading_Fedora_using_package_manager|using bare {{command|dnf}} or {{command|yum}}]]. You can either upgrade to Fedora 21 that way and then upgrade the rest of the way using DNF system upgrade, or you can attempt the entire upgrade using bare {{command|dnf}} or {{command|yum}}. Note this method is in itself not an officially recommended upgrade mechanism. To be frank, any upgrade from Fedora 20 or earlier is very much done 'at your own risk'.<br />
<br />
{{anchor|multi}}<br />
=== How many releases can I upgrade across at once? ===<br />
<br />
The most common scenario is an upgrade across just one release (e.g. {{FedoraVersion|long|previous}} to {{FedoraVersion|long}}). However, for the first month or so after a new release comes out, upgrades from the last-but-one release to that release are 'supported', in the sense that we include this scenario in the [[Fedora Release Criteria]], test it for at least clean installs of supported package sets, and will treat bugs discovered in such upgrades as significant. The [[Fedora Release Life Cycle]] is specifically designed to provide this approximate one month 'grace period' so you can choose to upgrade long-lived systems only once every two releases, rather than having to do it every release.<br />
<br />
Around a month after the new release comes out, the last-but-one release goes [[End of life]], at which point the [[#eol|previous question]] applies. Still, that upgrade is still pretty likely to work successfully for some time after the release goes end-of-life.<br />
<br />
Upgrades across more than two releases are not 'supported', and issues encountered in such upgrades may not be considered significant bugs. Note that any upgrade across more than two releases must by definition be an upgrade from an end-of-life release, and so the [[#eol|previous question]] applies here too.<br />
<br />
When upgrading across multiple releases, you may find you need to [[Upgrading_Fedora_using_package_manager#packagekey|import the target release package signing key manually]]. Fedora releases usually only have the package signing keys for the next two releases installed (because they go end-of-life before the N+3 release is branched). Before Fedora 22, it was not consistently the case that every release had keys for the next two releases, either. If dnf complains about a missing key, this is what you must do.<br />
<br />
=== Can I use DNF system upgrade to upgrade to a pre-release (e.g. a Beta)? ===<br />
<br />
Yes. It should always be possible to attempt such an upgrade. Of course, this function is as subject to temporary breakage as is any other aspect of a pre-release, and generally speaking, the earlier the release in question, the less likely it is to work without problems.<br />
<br />
== Optional post-upgrade tasks ==<br />
<br />
These are tasks you can do after a successful upgrade. '''They are mostly intended for power users. If you are a general user who doesn't use terminal daily, you don't need to worry about this.'''<br />
<br />
=== Update system configuration files ===<br />
<br />
Most configuration files are stored in <code>/etc</code>. If there are any updates to them and you touched some of those files before, RPM creates new files with either <code>.rpmnew</code> suffix (the new default config file), or <code>.rpmsave</code> suffix (your old config file backed up). You can search for these files, go through the changes and make sure your custom changes are still included and the new defaults are applied as well. A tool that tried to simplify this is {{pkg|rpmconf}}. Install the package, and then use it as:<br />
$ sudo rpmconf -a<br />
See more information in its manual page. <br />
<br />
=== Clean up old packages ===<br />
<br />
You can see list of packages with broken dependencies like this:<br />
$ sudo dnf repoquery --unsatisfied<br />
Ideally there should be none. If there are some, consider removing them, because they are not likely to work properly anyway.<br />
<br />
You can see duplicated packages (packages with multiple versions installed) like this:<br />
$ sudo dnf repoquery --duplicated<br />
For ordinary packages, just the latest version should be installed. But there can be exceptions to the rule, only remove what you are sure you no longer need.<br />
<br />
Some packages might stay on your system while they have been removed from the repositories. See them using:<br />
$ sudo dnf list extras<br />
If you don't use these, you can consider removing them: <code>dnf remove $(dnf repoquery --extras --exclude=kernel,kernel-\*)</code>. Please note that this list is only valid if you have a fully updated system. Otherwise you'll see all installed packages which are no longer in the repositories, because there is a newer update available. So before acting on these, make sure you have run <code>sudo dnf update</code> and generate the list of extra packages again. Also, this list might contain packages installed from third-party repositories for which an updated repository hasn't been published yet. This often involves e.g. RPM Fusion or Dropbox.<br />
<br />
You can remove no-longer-needed packages using:<br />
$ sudo dnf autoremove<br />
but '''beware''' that dnf decides that a package is no longer needed if you haven't explicitly asked to install it and nothing else requires it. That doesn't mean that package is not useful or that you don't use it. '''Only remove what you are certain you don't need'''. There's a known bug in PackageKit which doesn't mark packages as user-installed, see [https://bugzilla.redhat.com/show_bug.cgi?id=1259865 bug 1259865]. If you use PackageKit (or GNOME Software, Apper, etc) for installation, this output might list even important apps and system packages, so beware.<br />
<br />
== Resolving post-upgrade issues ==<br />
<br />
'''Only follow up these steps if you have troubles with your upgraded system. It should not be needed in the vast majority of upgrades.'''<br />
<br />
=== Rebuilding RPM database ===<br />
<br />
If you see warnings when working with RPM/DNF tools, your database might have gotten corrupted for some reason. It is possible to rebuild it and see if resolves your issues. Always back up <code>/var/lib/rpm/</code> first. To rebuild the database, run:<br />
$ sudo rpm --rebuilddb<br />
<br />
=== Using distro-sync to resolve dependency issues ===<br />
<br />
The system upgrade tool uses distro-sync method by default. If your system stayed partly unupgraded or you see some package dependency issues, you might try to fix it by running another distro-sync manually. This tries to make your installed packages exactly the same version as in currently enabled repositories, even if it meant downgrading some packages:<br />
$ sudo dnf distro-sync<br />
<br />
A stronger variant also allows to remove package for which package dependencies can't be satisfied. Always carefully review which packages are going to be removed before confirming this:<br />
$ sudo dnf distro-sync --allowerasing<br />
<br />
=== Relabel files with latest SELinux policy ===<br />
<br />
If you see warnings that some actions were not allowed because of current SELinux policy, it might be a case of having some files incorrectly label with SELinux permissions. This might happen in case of some bug or if you had SELinux disabled in some point of time in the past. You can relabel the whole system by running:<br />
$ sudo fixfiles onboot<br />
and rebooting. The next boot will take a long time and will check and fix all SELinux labels on all your files.</div>Germanohttps://fedoraproject.org/w/index.php?title=PackagingDrafts/Go&diff=510718PackagingDrafts/Go2018-02-01T23:47:21Z<p>Germano: compiler(go-compilers) is wrong, compiler(go-compiler) is correct</p>
<hr />
<div>{{Draft}}<br />
<br />
{{Admon/caution|Future plans|The [[More_Go_packaging|More Go Packaging]] proposal would replace the guidelines here.}}<br />
<br />
{{Admon/note|Consider starting with gofed| The gofed tool, available as a Fedora package or at https://github.com/gofed/gofed, automates many of these steps. Try <code>gofed repo2spec</code> first before<br />
trying to write a specfile by hand.}}<br />
<br />
= Naming =<br />
<br />
== Package Names ==<br />
<br />
The package name idiom for the golang is that the import paths of libraries are fully qualified domain names. This way you have clarity to the precise upstream being used. We'll acknowledge this qualified path in the Provides, but also the package name should indicate the upstream project as much as possible. Truncating domain names and using '-' instead of '/'. For example, 'github.com/gorilla/context' would be 'golang-github-gorilla-context' for the base RPM name. Similarly, the 'code.google.com/p/go.net' repository would be 'golang-googlecode-net' base RPM name.<br />
<br />
== Import Path ==<br />
<br />
In the golang library, paths are referenced in full URLs. Since this URL is referenced in several places throughout the rpmspec, as a standard, set the base import path as a global define at the top of the spec file<br />
<br />
<pre><br />
%global import_path code.google.com/p/go.net<br />
</pre><br />
<br />
== Versions ==<br />
<br />
Many Go libraries do not use package versions or have regular releases, and are instead maintained in public version control. In this case, follow the [https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning standard Fedora version conventions]. This means that often Go packages will have a version number of "0" and a release number like "0.10.git27435c6".<br />
<br />
To make that version and release string easier to manage, set global defines for the project's revision (and short revision if needed).<br />
<br />
=== Hashed revisions ===<br />
Projects can be hosted in hashed version control systems, e.g. git, hg/mercurial. For hg/mercurial, the defines would look like:<br />
<br />
<pre><br />
%global rev 84a4013f96e01fdd14b65d260a78b543e3702ee1 <br />
%global shortrev %(r=%{rev}; echo ${r:0:12})<br />
</pre><br />
<br />
For git, the defines would look like:<br />
<br />
<pre><br />
%global commit 84a4013f96e01fdd14b65d260a78b543e3702ee1<br />
%global commitdate 20150502<br />
%global shortcommit %(c=%{commit}; echo ${c:0:7})<br />
</pre><br />
<br />
Then the Release: can be set as:<br />
<pre><br />
Release: 0.10.%{commitdate}hg%{shortrev}%{?dist}<br />
</pre><br />
<br />
Or as:<br />
<pre><br />
Release: 0.10.%{commitdate}git%{shortcommit}%{?dist}<br />
</pre><br />
<br />
=== Numerical revisions ===<br />
For projects that use a numerical version control (bzr), then the defines would look like:<br />
<br />
<pre><br />
%global rev 53 <br />
</pre><br />
<br />
Then the Release: can be set as:<br />
<pre><br />
Release: 0.10.bzr%{rev}%{?dist}<br />
</pre><br />
<br />
<br />
= Packaging Binaries =<br />
<br />
Applications that have a 'main' package name, are compiled to a binary. These should be named after the upstream project, and do not need a "golang" prefix.<br />
<br />
If that project does also include source libraries, then a subpackage can be produced with the "golang" prefix and Provides: for the import paths that are packaged.<br />
<br />
By default, the golang compiler produces static binaries (in Go sense) for all native golang source code. There is a C bridge logic CGo that allows golang source to dynamically or statically link to C compiled shared objects (e.g. libssl).<br />
All golang binary packages have an automatic exception to the standard policy.<br />
<br />
The GCC-Go compiler by default produces dynamically-linked binaries and is capable of statically linking as well.<br />
<br />
At this stage, the reference compiler is the golang compiler("GC"), though gccgo is ready for use, and has demonstrated performance benefits for isolated use-cases.<br />
<br />
== Build ID ==<br />
<br />
The golang compiler (`gc`) does '''not''' provide by default the ".note.gnu.build-id" section that GCC does. Though, if the binary being built supports being compiled with `gccgo`, the gccgo compiler does support and include the .note.gnu.build-id.<br />
<br />
== Debuginfo ==<br />
<br />
If you are using golang, DWZ is currently incompatible with binaries produced by it ([https://bugzilla.redhat.com/show_bug.cgi?id=995136#c12 Bug 995136]). To get at least partial DWZ optimization use:<br />
<pre><br />
# https://bugzilla.redhat.com/show_bug.cgi?id=995136#c12<br />
%global _dwz_low_mem_die_limit 0<br />
</pre><br />
<br />
If you are using golang, it does not produce build ID by default. Use this compilation command otherwise build ID packaging check would stop the package build:<br />
<pre><br />
# *** ERROR: No build ID note found in /.../BUILDROOT/etcd-2.0.0-1.rc1.fc22.x86_64/usr/bin/etcd<br />
function gobuild { go build -a -ldflags "-B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n')" -v -x "$@"; }<br />
</pre><br />
<br />
On Fedora, buildroots installing golang also installs go-compilers-golang-compiler rpm, which provides %gobuild macro.<br />
It automatically sets the build ID.<br />
If the ldflags needs to be extended further, you can set LDFLAGS environment variable.<br />
<br />
<pre><br />
export LDFLAGS="-X %{import_path}/version.GitSHA=%{shortcommit}"<br />
%gobuild -o bin/BINARY %{import_path}/cmd/CMD<br />
</pre><br />
<br />
There is a historical bug for the debug-info [https://bugzilla.redhat.com/show_bug.cgi?id=1184221 Bug 1184221] that is fixed now.<br />
If you hit a new bug, please fill a new ticket.<br />
<br />
== Dependencies ==<br />
Most of the golang-* packages are source code only. The *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes ''(without single or double quotes)''.<br />
Binary builds that include these imports will use BuildRequires:<br />
<pre><br />
BuildRequires: golang(github.com/gorilla/context) >= 0-0.13<br />
</pre><br />
<br />
== Go Language Architectures ==<br />
<br />
To compile on various architectures, golang and gcc-go compilers are available. The golang compiler currently supports x86, x86_64, ppc64le, ppc64(partially, [https://github.com/golang/go/issues/13192 see upstream issue#13192]), s390x, armv7hl and aarch64. Binaries should set <code>ExclusiveArch</code> so that we only attempt to build packages on those arches. The <code>go-srpm-macros</code> package provides the <code>%{go_arches}</code> macro for this:<br />
<br />
<pre><br />
ExclusiveArch: %{go_arches}<br />
</pre><br />
<br />
{{Admon/note|ppc64 Big-endian only|Please note that since Fedora 27, ppc64 is dropped from the macros, effectively disabling build on ppc64 for all packages adhering to this guidelines. This has been done due to move of GC to support only Power8 and up and general feature miss-parity of GC port. Switch to gcc-go hasn't been done as it potentially require non trivial amount of packaging work from packagers. Both golang and gcc-go are still available for those architectures, although with the mentioned limitation on golang("GC") side.}}<br />
<br />
To make choose of given compiler independent of an architecture, go-compilers package is introduced. It provides compiler(go-compiler) virtual provide that can be used:<br />
<br />
<pre><br />
BuildRequires: compiler(go-compiler)<br />
</pre><br />
<br />
It installs the correct compiler (golang or gcc-go). If the package is to be compiled only by golang or gcc-go, compiler(golang) and compiler(gcc-go) are available as well. This way there is no need to set a minimal version for each compiler (gcc-go is provided by gcc >= 5.0.0) as it is already enforced in go-compiler package itself. go-compilers package also defines %gobuild (with generating Build ID when debug is enabled) and %gotest macros that can be used to build and test golang project:<br />
<br />
<pre><br />
%gobuild -o bin/NAME %{import_path}<br />
</pre><br />
<br />
<pre><br />
%gotest %{import_path}/package<br />
</pre><br />
<br />
%gobuild macro can be used with -o option. It is not recommended to use any other options as they can be compiler specific. For compiler specific options use corresponding virtual provide and 'go build', resp. 'go build -compiler gccgo' build command. The same reasoning for testing options holds here. In most cases it should be sufficient.<br />
<br />
Example of spec file with support for available architectures:<br />
<pre><br />
# [...]<br />
<br />
Name: golang-%{provider}-%{project}-%{repo}<br />
Version: 1<br />
Release: 13%{?dist}<br />
Summary: Process markdown into manpages<br />
License: MIT<br />
URL: https://%{import_path}<br />
Source0: https://%{import_path}/archive/%{commit}/%{repo}-%{shortcommit}.tar.gz<br />
<br />
# e.g. el6 has ppc64 arch without gcc-go, so EA tag is required<br />
ExclusiveArch: %{?go_arches:%{go_arches}}%{!?go_arches:%{ix86} x86_64 %{arm}}<br />
# If go_compiler is not set to 1, there is no virtual provide. Use golang instead.<br />
BuildRequires: %{?go_compiler:compiler(go-compiler)}%{!?go_compiler:golang}<br />
<br />
# [...]<br />
<br />
%prep<br />
%setup -q -n %{repo}-%{commit}<br />
<br />
%build<br />
mkdir -p src/github.com/cpuguy83<br />
ln -s ../../../ src/github.com/cpuguy83/go-md2man<br />
<br />
%if ! 0%{?with_bundled}<br />
export GOPATH=$(pwd):%{gopath}<br />
%else<br />
echo "Unable to build from bundled deps. No Godeps nor vendor directory"<br />
exit 1<br />
%endif<br />
<br />
%gobuild -o bin/go-md2man %{import_path}<br />
<br />
%install<br />
# install go-md2man binary<br />
install -d %{buildroot}%{_bindir}<br />
install -p -m 755 bin/%{repo} %{buildroot}%{_bindir}<br />
<br />
# [...]<br />
<br />
%endif<br />
<br />
# [...]<br />
<br />
%check<br />
%if 0%{?with_check} && 0%{?with_unit_test} && 0%{?with_devel}<br />
export GOPATH=%{buildroot}/%{gopath}:%{gopath}<br />
<br />
%gotest %{import_path}/generator<br />
%gotest %{import_path}/parser<br />
%endif<br />
<br />
# [...]<br />
<br />
</pre><br />
<br />
== Bundled or de-bundled ==<br />
<br />
At the moment golang projects packaged in Fedora (resp. epel6) branches are de-bundled by default.<br />
It means projects are built from dependencies packaged in Fedora (resp. epel6).<br />
For other branches (and projects) it can be reasonable to build from bundled dependencies.<br />
For epel7, there is a chance a package will get into RHEL7.<br />
Thus, causing removal of the package from epel7 repository.<br />
Be aware, this is not a general rule. Every bundling needs a proper justification!!!<br />
See https://fedorahosted.org/fesco/ticket/1483#comment:17 and https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy for more information.<br />
<br />
= Packaging Libraries =<br />
<br />
At this time, Go libraries packaged in Fedora are primarily for the purpose of being BuildRequires for building Fedora binary RPMs, and not meant to be developed against otherwise -- for that, we encourage the upstream "go get" idiom and a per-user $GOPATH.<br />
<br />
As mentioned we do not provide or recommend a system-wide GOPATH that users should inherit and there is no notion of a "site" or "vendor" path for system libraries. Although you can set GOPATH in a way that will include the system path in per-user GOPATH (e.g. export GOPATH=$HOME/go:/usr/share/gocode). This way a call to `go get ...` would land new source in the $HOME/go directory. But be aware the system libraries may change significantly during live of the release, as mentioned.<br />
<br />
GOROOT is reserved for golang standard library only.<br />
<br />
By default, the standard golang compiler produces static libraries. There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler. Instead, each library package should consist of a -devel subpackage which installs .go source code to /usr/share/gocode/src, under the appropriate import path.<br />
<br />
Binary packages which build against this source will set $GOPATH to '%{_datadir}/gocode' ( or '%{gopath}' in golang > 1.2.1-1)<br />
<br />
== Shared-object libraries ==<br />
<br />
Presently the shared object libraries produced by GCC-Go are not usable [https://gcc.gnu.org/ml/gcc-help/2011-06/msg00239.html].<br />
<br />
It is not an blocker for supported architectures using cgo to have dynamic links to a C/C++ compiled shared-object library [http://golang.org/cmd/cgo/].<br />
<br />
== Dependencies ==<br />
<br />
To match the fully qualified import paths of the projects and source, utilize the meta wrapper / virtual provides in the golang namespace to provide the import paths being packaged. <br />
<br />
Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes. ''(without single or double quotes)''<br />
<pre><br />
Provides: golang(%{go_import_path}) = %{version}-%{release}<br />
</pre><br />
<br />
Then other source packages that reference these imports can have Requires: matching that:<br />
<pre><br />
Requires: golang(github.com/gorilla/context)<br />
</pre><br />
<br />
<br />
== Libraries and Arch ==<br />
<br />
Because these packages contain no compiled code, they should be made noarch. However, since they require golang, they need to only be built on the architectures supported by the language. For that reason, follow the [https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies standard guidelines for noarch packages with unported dependencies]:<br />
<br />
<pre><br />
BuildArch: noarch<br />
ExclusiveArch: %{go_arches} noarch<br />
</pre><br />
<br />
= Security in Go Language Packages =<br />
<br />
If there is a security issue in the standard Go library or in a library built into binary Go programs, all affected RPMs will need to be rebuilt.<br />
<br />
In the event that a security issue is found in a library, all packages which have that library as a BuildRequires must be identified and rebuilt with the version and release of the fixed library added to the BuildRequires.<br />
<br />
<br />
<code><br />
repoquery -q --disablerepo='*' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'golang($SOME_IMPORT_PATH)'<br />
</code><br />
<br />
<br />
Additionally, other golang-*-devel packages may directly require their own dependencies; check for such packages with<br />
<br />
<code><br />
repoquery -q --disablerepo='*' --enablerepo=fedora --enablerepo=updates --enablerepo=updates-testing --whatrequires 'golang($SOME_IMPORT_PATH)'<br />
</code><br />
<br />
and, if any of the results are golang-*-devel RPMs, repeat the previous step to find packages which may have ''that'' as a BuildRequires.<br />
<br />
= Optional =<br />
<br />
== List of dependencies ==<br />
<br />
Some projects like kubernetes, cadvisor or etcd ship a list of dependencies they require for building. The list is located under Godeps directory in Godeps.json file.<br />
It maps each imported path to its corresponding commit. The list can be used by scripts to automatically check if all imported paths are packaged and up-to-date in Fedora.<br />
<br />
Other projects like docker use vendor directory to store a list of dependencies instead of Godeps.<br />
<br />
If the list of dependencies is provided it is good to include it in %doc in %files section of the spec file.<br />
<br />
== Branching macros ==<br />
<br />
For some packaged binaries it is impossible to provide debugging information, some binaries can not be built from de-bundled dependencies, provided tests need internet connection in order to work properly. For these use cases it is convenient to add with_debug, with_bundled and with_check macros, wrap parts of spec file and set the macros accordingly. Other macros as with_devel can be used to wrap devel subpackage parts and install commands. E.g.<br />
<br />
<pre><br />
# If any of the following macros should be set otherwise,<br />
# you can wrap any of them with the following conditions:<br />
# - %%if 0%%{centos} == 7<br />
# - %%if 0%%{?rhel} == 7<br />
# - %%if 0%%{?fedora} == 23<br />
# Or just test for particular distribution:<br />
# - %%if 0%%{centos}<br />
# - %%if 0%%{?rhel}<br />
# - %%if 0%%{?fedora}<br />
#<br />
# Be aware, on centos, both %%rhel and %%centos are set. If you want to test<br />
# rhel specific macros, you can use %%if 0%%{?rhel} && 0%%{?centos} == 0 condition.<br />
# (Don't forget to replace double percentage symbol with single one in order to apply a condition)<br />
<br />
# Generate devel rpm<br />
%global with_devel 1<br />
# Build project from bundled dependencies<br />
%global with_bundled 0<br />
# Build with debug info rpm<br />
%global with_debug 0<br />
# Run tests in check section<br />
%global with_check 1<br />
# Generate unit-test rpm<br />
%global with_unit_test 1<br />
<br />
<br />
# [...]<br />
<br />
%if 0%{?with_debug}<br />
%global _dwz_low_mem_die_limit 0<br />
%else<br />
%global debug_package %{nil}<br />
%endif<br />
<br />
# [...]<br />
<br />
%if 0%{?with_devel}<br />
%package devel<br />
BuildArch: noarch<br />
# [...]<br />
<br />
%description devel<br />
# [...]<br />
%endif<br />
<br />
# [...]<br />
<br />
%build<br />
%if ! 0%{?with_bundled}<br />
# Make link for etcd itself<br />
mkdir -p src/github.com/coreos<br />
ln -s ../../../ src/github.com/coreos/etcd<br />
# [...]<br />
%gobuild -o bin/etcd %{import_path}<br />
%gobuild -o bin/etcdctl %{import_path}/etcdctl<br />
%gobuild -o bin/etcd-migrate %{import_path}/tools/%{name}-migrate<br />
%else<br />
./build<br />
%endif<br />
<br />
# [...]<br />
<br />
%install<br />
# [...]<br />
%if 0%{?with_devel}<br />
# Install files for devel sub-package<br />
install -d %{buildroot}/%{gopath}/src/%{import_path}<br />
cp -pav main.go %{buildroot}/%{gopath}/src/%{import_path}/<br />
for dir in client discovery error; do<br />
cp -rpav ${dir} %{buildroot}/%{gopath}/src/%{import_path}/<br />
done<br />
%endif<br />
<br />
# [...]<br />
<br />
%check<br />
%if 0%{?with_check}<br />
%if 0%{?with_bundled}<br />
export GOPATH=$(pwd)/Godeps/_workspace:%{gopath}<br />
%else<br />
export GOPATH=%{buildroot}%{gopath}:%{gopath}<br />
%endif<br />
go test %{import_path}/client<br />
go test %{import_path}/discovery<br />
%endif<br />
<br />
# [...]<br />
</pre><br />
<br />
== Check of dependencies ==<br />
<br />
After an update of a package a list of provided and imported packages can change. In order to get a list of missing or superfluous provided and imported packages, one can use [https://github.com/ingvagabund/gofed gofed tool] by runing 'gofed lint' in a repository directory:<br />
<br />
<pre><br />
$ basename $(pwd)<br />
golang-googlecode-net<br />
$ ls<br />
golang-googlecode-net.spec net-7dbad50.tar.gz sources<br />
$ gofed lint<br />
1 golang specfile checked; 0 errors, 0 warnings.<br />
</pre><br />
<br />
If some 'Provides' or 'BuildRequires' are missing:<br />
<br />
<pre><br />
$ gofed lint<br />
W: Missing BuildRequires: golang(golang.org/x/text/encoding/korean)<br />
W: Missing BuildRequires: golang(golang.org/x/text/encoding/simplifiedchinese)<br />
W: Missing BuildRequires: golang(golang.org/x/text/encoding/traditionalchinese)<br />
W: Missing Provides: golang(golang.org/x/net/internal/iana)<br />
W: Missing Provides: golang(golang.org/x/net/internal/nettest)<br />
W: Missing Provides: golang(golang.org/x/net/ipv4)<br />
W: Missing Provides: golang(golang.org/x/net/ipv6)<br />
1 golang specfile checked; 0 errors, 7 warnings.<br />
</pre><br />
<br />
The command inspects project's tarball, sources file and compares a list of provided/imported packages in spec file with those in tarball.<br />
As some packages have different name for a devel subpackage (e.g. golang-googlecode-net package has golang-golangorg-net-devel devel subpackage), which subpackage is the devel subpackage has to be specified by setting devel_main macro. At the same time if a devel subpackage has different import path than the one specified in %{import_path} macro, devel_prefix macro has to be set in order for 'gofed lint' to check the correct subpackage.<br />
<br />
<pre><br />
%global provider_tld com<br />
%global provider github<br />
%global project golang<br />
%global repo net<br />
%global import_path code.google.com/p/go.net<br />
%global commit 7dbad50ab5b31073856416cdcfeb2796d682f844<br />
%global shortcommit %(c=%{commit}; echo ${c:0:7})<br />
<br />
# primary devel subpackage<br />
%global x_provider golang<br />
%global x_provider_tld org<br />
%global x_repo net<br />
%global x_import_path %{x_provider}.%{x_provider_tld}/x/%{x_repo}<br />
%global x_name golang-%{x_provider}%{x_provider_tld}-%{repo}<br />
<br />
# here the package name is golang-googlecode-net<br />
# but the devel subpackage is golang-golangorg-net-devel<br />
%global devel_main golang-golangorg-net-devel<br />
# all macros belonging to golang-golangorg-net-devel subpackage<br />
# are defined by the same macros names as for main package<br />
# but prefixed with x_, i.e. x_provider, x_import_path, ...<br />
%global devel_prefix x<br />
<br />
# [...]<br />
<br />
Name: golang-googlecode-net<br />
Version: 0<br />
Release: 0.21.git%{shortcommit}%{?dist}<br />
Summary: Supplementary Go networking libraries<br />
<br />
# [...]<br />
</pre><br />
<br />
If your package has different devel subpackage or use different %{import_path} macro, please specify devel_main and devel_prefix macros.<br />
<br />
= Spec file generators =<br />
<br />
Spec files for 'packaging a library' as described above can be generated via [https://github.com/ingvagabund/gofed gofed tool].<br />
At the moment it supports generators for github.com, code.google.com and bitbucket.org. Generated spec files conform to the current golang packaging guidelines and are ready to use.<br />
Summary and License has to be modified manually. Generated spec file can be further extended based on a specific projects (some directories has to be removed,<br />
description or summary extended, %doc extended for other important documents, etc.). Some projects provide main packages which can be built.<br />
As a building process for each project is specific (via go build, make, hack/make.sh etc.) the generator keeps %build section empty. Neither debuginfo nor with_* macros are generated.<br />
<br />
= Sample RPM Spec=<br />
<br />
Following a couple of example RPM spec files to give a sample layout for future packagers of libraries or applications written in golang.<br />
<br />
== Packaging a library ==<br />
<pre><br />
%global import_path code.google.com/p/go.net<br />
%global rev 84a4013f96e01fdd14b65d260a78b543e3702ee1<br />
%global shortrev %(r=%{rev}; echo ${r:0:12})<br />
<br />
Name: golang-googlecode-net<br />
Version: 0<br />
Release: 0.15.hg%{shortrev}%{?dist}<br />
Summary: Supplementary Go networking libraries<br />
License: BSD<br />
URL: http://%{import_path}<br />
Source0: https://net.go.googlecode.com/archive/%{rev}.zip<br />
<br />
# e.g. el6 has ppc64 arch without gcc-go, so EA tag is required<br />
ExclusiveArch: %{ix86} x86_64 %{arm} aarch64 ppc64le s390x<br />
# If go_compiler is not set to 1, there is no virtual provide. Use golang instead.<br />
BuildRequires: %{?go_compiler:compiler(go-compiler)}%{!?go_compiler:golang}<br />
<br />
%description<br />
%{summary}<br />
<br />
%package devel<br />
Summary: Supplementary Go networking libraries<br />
<br />
Provides: golang(%{import_path}) = %{version}-%{release}<br />
Provides: golang(%{import_path}/dict) = %{version}-%{release}<br />
# [...]<br />
<br />
%description devel<br />
%{summary}<br />
<br />
This package contains library source intended for building other packages<br />
which use the supplementary Go networking libraries.<br />
<br />
<br />
%prep<br />
<br />
%setup -n net.go-%{shortrev}<br />
cp html/testdata/webkit/README README-webkit<br />
<br />
%build<br />
<br />
%install<br />
install -d %{buildroot}/%{gopath}/src/%{import_path}<br />
for d in dict html idna ipv4 ipv6 proxy publicsuffix spdy websocket; do<br />
cp -avp $d %{buildroot}/%{gopath}/src/%{import_path}/<br />
done<br />
<br />
%check<br />
GOPATH=%{buildroot}/%{gopath} go test %{import_path}/html<br />
# [...]<br />
<br />
%files devel<br />
%defattr(-,root,root,-)<br />
%doc AUTHORS CONTRIBUTORS LICENSE PATENTS README<br />
%doc README-webkit<br />
%dir %attr(755,root,root) %{gopath}/src/%{import_path}<br />
%dir %attr(755,root,root) %{gopath}/src/%{import_path}/dict<br />
%dir %attr(755,root,root) %{gopath}/src/%{import_path}/html<br />
# [...]<br />
%{gopath}/src/%{import_path}/dict/*.go<br />
%{gopath}/src/%{import_path}/html/*.go<br />
# [...]<br />
<br />
%changelog<br />
* Fri Jul 11 2014 Jill User <jill.user@fedoraproject.org> - 0-0.15.hg84a4013f96e0<br />
- don't fail on ipv6 test bz1056185<br />
# [...]<br />
</pre><br />
<br />
== Packaging a binary ==<br />
<pre><br />
%global commit 63fe64c471e7d76be96a625350468dfc65c06c31<br />
%global shortcommit %(c=%{commit}; echo ${c:0:7})<br />
<br />
Name: example-app<br />
Version: 1.0.0<br />
Release: 6%{?dist}<br />
Summary: This application is an example for the golang binary RPM spec<br />
License: ASL 2.0 <br />
URL: http://www.example-app.io<br />
Source0: https://github.com/example/app/archive/v%{version}.tar.gz<br />
Source1: example-app.service<br />
Source2: example-app.sysconfig<br />
<br />
BuildRequires: gcc<br />
<br />
BuildRequires: golang >= 1.2-7<br />
<br />
# pull in golang libraries by explicit import path, inside the meta golang()<br />
BuildRequires: golang(github.com/gorilla/mux) >= 0-0.13<br />
[...]<br />
<br />
%description<br />
# include your full description of the application here.<br />
<br />
%prep<br />
%setup -q -n example-app-%{version}<br />
<br />
# many golang binaries are "vendoring" (bundling) sources, so remove them. Those dependencies need to be packaged independently.<br />
rm -rf vendor<br />
<br />
%build<br />
# set up temporary build gopath, and put our directory there<br />
mkdir -p ./_build/src/github.com/example<br />
ln -s $(pwd) ./_build/src/github.com/example/app<br />
<br />
export GOPATH=$(pwd)/_build:%{gopath}<br />
go build -o example-app .<br />
<br />
%install<br />
install -d %{buildroot}%{_bindir}<br />
install -p -m 0755 ./example-app %{buildroot}%{_bindir}/example-app<br />
<br />
%files<br />
%defattr(-,root,root,-)<br />
%doc AUTHORS CHANGELOG.md CONTRIBUTING.md FIXME LICENSE MAINTAINERS NOTICE README.md<br />
%{_bindir}/example-app<br />
<br />
%changelog<br />
* Tue Jul 01 2014 Jill User <jill.user@fedoraproject.org> - 1.0.0-6<br />
- package the example-app<br />
<br />
</pre><br />
= Thanks =<br />
<br />
These guidelines are Fedora-specific but are intended to match [http://pkg-go.alioth.debian.org/packaging.html Debian practice] where that is reasonable.<br />
<br />
= Discussion =<br />
<br />
See [[Talk:PackagingDrafts/Go]] and https://fedorahosted.org/fpc/ticket/382 for discussion.<br />
<br />
[[Category:Packaging guidelines drafts]]</div>Germanohttps://fedoraproject.org/w/index.php?title=SELinux_FAQ&diff=494214SELinux FAQ2017-06-03T08:29:31Z<p>Germano: </p>
<hr />
<div>{{autolang|base=yes}}<br />
= Frequently Asked Questions =<br />
<br />
{{Admon/note |The following content is under review and may be removed soon or otherwise inaccurate or out-dated. Visit http://docs.fedoraproject.org/ for a complete and recent FAQ regarding SELinux) .}}<br />
<br />
== What is SELinux? ==<br />
<br />
SE (Security Enhanced) Linux is a security feature in the Linux kernel and enabled by default in Fedora that provides more fine grained access control compared to traditional file permissions. A centralized policy determines which software can access what resources. For example, network services can be confined to a particular port and Apache web server can be restricted to be able to connect to only 80 by default.<br />
<br />
== Where can I go to provide feedback or ask for help? ==<br />
<br />
You can provide feedback via http://bugzilla.redhat.com for bugs and issues and ask for help and clarify doubts in fedora-selinux mailing list at https://lists.fedoraproject.org/mailman/listinfo/selinux<br />
<br />
== Who developed SELinux? ==<br />
<br />
NSA (National Security Agency) developed SELinux initially. It has partnered with Red Hat to continue development and carry out integration of SELinux into Fedora and Red Hat Enterprise Linux. It is not specific to Red Hat however and other Linux distributions and other operating systems have adopted SELinux and similar frameworks.<br />
<br />
== Is it a firewall? ==<br />
<br />
Though often confused with one, SELinux is not a firewall. A firewall controls the flow of traffic to and from a computer to the network. SELinux can confine access of programs within a computer and hence can be conceptually thought of a internal firewall between programs. Security works best when multiple layers are used and SELinux is complimentary to a firewall and other security features used in Fedora. <br />
<br />
== Is it useful on a desktop? ==<br />
<br />
Yes. SELinux policies in Fedora were initially focused on network facing services. However several dozens of desktop software including Firefox, HAL, D-Bus etc are protected by default using SELinux policies in current releases of Fedora. <br />
<br />
== How do I find out if SELinux is enabled on my system? ==<br />
<br />
Run the sestatus command to find out the current status of SELinux. SELinux can be in three different modes<br />
<br />
* Enabled: SELinux is enabled and SELinux policy is enforced<br />
* Disabled: SELinux is disabled and has no effect on your system<br />
* Permissive: SELinux is enabled but but merely logs warnings instead of enforcing access. This mode is useful for troubleshooting. <br />
<br />
== How do I find out whether SELinux is denying access for any software? ==<br />
<br />
When SELinux prevents any software from accessing a particular resource, for example when Firefox is denied access to /etc/shadow, it generates a message and logs it in /var/log/audit/audit.log or /var/log/messages if audit service is disabled. If the log contains "avc: denied" that means it is a SELinux policy denial. Note that you would need administrator privileges (root access) on your system to be able to read this log file. An example denial would look like<br />
<br />
<pre><br />
<br />
type=AVC msg=audit(1214965667.121:635): avc: denied { unix_read unix_write } for pid=15524 comm="npviewer.bin" <br />
key=59918130 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023 <br />
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s<br />
<br />
</pre><br />
<br />
== How do I understand SELinux denials? ==<br />
<br />
[https://fedorahosted.org/setroubleshoot setroubleshoot] is a utility that parses the messages from SELinux and provides comprehensive help on what it means and possible actions to take. It has both a graphical utility for your desktop and a server side component that can send email alerts. It is installed by default on Fedora. If you wish to install it on your system, use Add/Remove programs or run the following command as root user. <br />
<br />
<pre><br />
dnf install setroubleshoot<br />
</pre><br />
<br />
== How do I enable or disable SELinux ? ==<br />
<br />
=== Temporarily ===<br />
<br />
$ sestatus<br />
(...)<br />
Current mode: enforcing<br />
<br />
$ sudo setenforce 0<br />
<br />
$ sestatus <br />
(...)<br />
Current mode: permissive<br />
<br />
Changes made with setenforce will revert on the next reboot. <br />
<br />
<br />
=== Permanently ===<br />
<br />
SELinux is enabled by default in Fedora. SELinux policy has booleans that can be used to disable SELinux for specific services or you can disable SELinux entirely. If you want to disable SELinux entirely, you can use system-config-selinux (install the policycoreutils-gui package if you don't have it) to do this graphically or set the value of SELINUX in /etc/selinux/config to disabled. You'll have to cold restart for this change to become effective.<br />
<br />
However it is highly recommended that you set it to permissive instead since it will show you the denials and setting it to permissive does not requiring relabeling the entire system when you enable it again. You can pass selinux=0 in the installation boot prompt to disable SELinux during installation or refer to [[Anaconda/Kickstart|kickstart]] documentation for automated installations.<br />
<br />
== How does SELinux work? ==<br />
<br />
<br />
== What are SELinux booleans ? ==<br />
<br />
SELinux booleans enable runtime customization of the SELinux policy. SELinux policy in Fedora has several booleans that allow you to quickly toggle a particular change in the policy. For example, httpd_enable_cgi allows the httpd (Apache) web server to run cgi scripts if it is enabled. system-config-selinux offers a graphical utility to manage SELinux booleans. You can get a comprehensive list of SELinux booleans in the current policy using the getsebool -a command. You can also change the value of a boolean at runtime using the setsebool or togglesebool command. Inorder for the change in booleans to be permanent instead of for just the current session, you need to pass -P paramater while setting the value of a boolean, for example, running the following command as root user will disable the ability for httpd web server to run cgi scripts. <br />
<br />
<pre><br />
<br />
setsebool -P httpd_enable_cgi=0<br />
<br />
</pre><br />
<br />
== What is SELinux policy ? ==<br />
<br />
<br />
== What is mandatory access control ? ==<br />
<br />
SELinux (Security-Enhanced Linux) in Fedora is an implementation of mandatory access control in the Linux kernel using the Linux Security Modules (LSM) framework. Discretionary access control (DAC) is standard Linux security, and it provides no protection from broken software or malware running as a normal user or root. Users can grant risky levels of access to files they own. Mandatory access control (MAC) provides full control over all interactions of software. Administratively defined policy closely controls user and process interactions with the system, and can provide protection from broken software or malware running as any user. <br />
<br />
In a DAC model, file and resource decisions are based solely on user identity and ownership of the objects. Each user and program run by that user has complete discretion over the user's objects. Malicious or flawed software can do anything with the files and resources it controls through the user that started the process. If the user is the super-user or the application is setuid or setgid to root, the process can have root level control over the entire file system.<br />
<br />
A MAC system does not suffer from these problems. First, you can administratively define a security policy over all processes and objects. Second, you control all processes and objects, in the case of SELinux through the kernel. Third, decisions are based on all the security relevant information available, and not just authenticated user identity.<br />
<br />
MAC under SELinux allows you to provide granular permissions for all subjects (users, programs, processes) and objects (files, devices). In practice, think of subjects as processes, and objects as the target of a process operation. You can safely grant a process only the permissions it needs to perform its function, and no more.<br />
<br />
The SELinux implementation uses role-based access control (RBAC), which provides abstracted user-level control based on roles, and Type Enforcement® (TE). TE uses a table, or matrix to handle access controls, enforcing policy rules based on the types of processes and objects. Process types are called domains, and a cross-reference on the matrix of the process's domain and the object's type defines their interaction. This system provides extremely granular control for actors in a Linux system. <br />
<br />
== How can I back up files from an SELinux file system? ==<br />
<br />
Use the star utility, which supports the extended attributes that store the security context labels. Specify the -xattr and -H=exustar options when creating archives.<br />
<br />
<pre><br />
<br />
ls -Z /var/log/maillog<br />
-rw------- root root system_u:object_r:var_log_t /var/log/maillog<br />
cd /var/log<br />
star -xattr -H=exustar -c -f maillog.star ./maillog*<br />
<br />
</pre><br />
<br />
{{Template:Warning}} Absolute paths can overwrite existing data<br />
<br />
If you use an absolute path, such as /var/log/maillog, when you unpack the archive with star -c -f, the files are restored on the same path they were archived with. The maillog file attempts to write to /var/log/maillog. You should received a warning from star if the files about to be overwritten have a later date, but you cannot rely on this behavior.<br />
<br />
Consider carefully how you construct your archiving argument. <br />
<br />
== What is the performance impact of SELinux? ==<br />
<br />
This is a variable that is hard to measure, and is heavily dependent on the tuning and usage of the system running SELinux. For desktop usage, there should be no measurable impact. If you are interested in doing more precise benchmarks, post to fedora-selinux list. <br />
<br />
== Which Linux distributions have adopted SELinux? ==<br />
<br />
Fedora and Fedora derived distributions such as Red Hat Enterprise Linux have been leading the effort. However several other Linux distirbutions such as Debian, Gentoo, Ubuntu etc have adopted SELinux too. A comprehensive list is available at http://selinux.sf.net<br />
<br />
== What about other operating systems? ==<br />
<br />
SELinux is based on the flask security model which has been adopted by other operating systems such as FreeBSD and OpenSolaris<br />
<br />
* http://www.trustedbsd.org/sebsd.html<br />
* http://www.sedarwin.org/<br />
* http://www.opensolaris.org/os/project/fmac/<br />
<br />
== Where can I find more information? ==<br />
<br />
*http://fedoraproject.org/wiki/SELinux has links to more documentation and other references. <br />
* http://www.coker.com.au/selinux/play.html for an effective SE Linux machine to play and learn from.<br />
<br />
[[Category:FAQ]]<br />
[[Category:Draft Documentation]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Nextcloud&diff=488090Nextcloud2017-03-17T08:40:50Z<p>Germano: /* Configuration of self generated SSL certificate */</p>
<hr />
<div>==Introduction==<br />
Nextcloud is a software that permits users to create a personal cloud system<br />
<br />
==Installation==<br />
To install Nextcloud, run:<br />
# dnf install nextcloud<br />
<br />
===Configuration of self generated SSL certificate===<br />
to encrypt communications between clients and host you need an encryption certificate<br />
<br />
# dnf install crypto-utils<br />
<br />
# genkey ''hostname''<br />
<br />
Answer no to question "Would you like to send a Certificate Request (CSR) to a Certificate Authority (CA)?" <br />
<br />
To let httpd service using SSL, the following dependencies need to be installed<br />
# dnf install mod_ssl openssl<br />
and edit<br />
/etc/httpd/conf.d/ssl.conf<br />
adding to the bottom<br />
<br />
SSLCertificateFile /etc/pki/tls/certs/hostname.crt<br />
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key<br />
<br />
To force SSL usage in server Nextcloud follow Apache documentation about Virtual Hosts. '''A "Let's Encrypt" certificate is highly recommended instead of a self generated SSL certificate'''.<br />
Also read [https://docs.nextcloud.com/server/10/admin_manual/configuration_server/harden_server.html Nextcloud server hardening guide]<br />
<br />
===Installation MariaDB/MySQL===<br />
# dnf install mariadb-server<br />
# systemctl enable --now mariadb<br />
$ mysql_secure_installation<br />
<br />
when you will be prompted for root password, simply press Enter without writing anything. Answer yes to the question about creating a root user, then enter a password.<br />
Now you have to create an user and the database for Nextcloud usage<br />
$ mysql -u root -p<br />
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';<br />
CREATE DATABASE IF NOT EXISTS nextcloud;<br />
GRANT ALL PRIVILEGES ON nextcloud.* TO 'username'@'localhost' IDENTIFIED BY 'password';<br />
FLUSH PRIVILEGES;<br />
quit<br />
<br />
taking care of replacing username with the proper username. A good candidate could be nextcloud_user. Do not forget to insert datas into '' symbols.<br />
In case password contain symbols, be careful because certain characters could be interpreted as escape chars (like />). In that case the procedure will look to be ended flawlessly, but next time you will try to authenticate you will get authentication errors in connecting to the DB.<br />
<br />
==Nextcloud server initialization==<br />
<br />
# cd /usr/share/nextcloud/<br />
# sudo -u apache php occ maintenance:install --data-dir /var/lib/nextcloud/data/ --database "mysql" --database-name "nextcloud" --database-user "nextcloud" --database-pass "database_password" --admin-user "nextcloud_admin" --admin-pass "nextcloud_admin_password"<br />
<br />
===Firewall configuration===<br />
<br />
# firewall-cmd --list-all-zones | grep active<br />
In our case<br />
public (default, active)<br />
so we will use public zone and following commands to enable http e https services access<br />
<br />
# firewall-cmd --permanent --zone=public --add-service=http<br />
# firewall-cmd --permanent --zone=public --add-service=https<br />
# firewall-cmd --reload<br />
<br />
===Grant access to remote hosts===<br />
<br />
To let Nextcloud be reached from remote hosts, you have to edit<br />
<br />
# /etc/nextcloud/config.php<br />
<br />
adding server IP address in 'trusted_domains' section. Finally run<br />
<br />
# ln -s /etc/httpd/conf.d/nextcloud-access.conf.avail /etc/httpd/conf.d/z-nextcloud-access.conf</div>Germanohttps://fedoraproject.org/w/index.php?title=Nextcloud&diff=488089Nextcloud2017-03-17T08:39:36Z<p>Germano: /* Configuration of self generated SSL certificate */</p>
<hr />
<div>==Introduction==<br />
Nextcloud is a software that permits users to create a personal cloud system<br />
<br />
==Installation==<br />
To install Nextcloud, run:<br />
# dnf install nextcloud<br />
<br />
===Configuration of self generated SSL certificate===<br />
to encrypt communications between clients and host you need an encryption certificate<br />
<br />
# dnf install crypto-utils<br />
<br />
# genkey ''hostname''<br />
<br />
Answer no to question "Would you like to send a Certificate Request (CSR) to a Certificate Authority (CA)?" <br />
<br />
To let httpd service using SSL, the following dependencies need to be installed<br />
# dnf install mod_ssl openssl<br />
and edit<br />
/etc/httpd/conf.d/ssl.conf<br />
adding to the bottom<br />
<br />
SSLCertificateFile /etc/pki/tls/certs/hostname.crt<br />
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key<br />
<br />
To force SSL usage in server Nextcloud follow Apache documentation about Virtual Hosts. A "Let's Encrypt" certificate is highly recommended instead of a self generated SSL certificate<br />
Also read [https://docs.nextcloud.com/server/10/admin_manual/configuration_server/harden_server.html Nextcloud server hardening guide]<br />
<br />
===Installation MariaDB/MySQL===<br />
# dnf install mariadb-server<br />
# systemctl enable --now mariadb<br />
$ mysql_secure_installation<br />
<br />
when you will be prompted for root password, simply press Enter without writing anything. Answer yes to the question about creating a root user, then enter a password.<br />
Now you have to create an user and the database for Nextcloud usage<br />
$ mysql -u root -p<br />
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';<br />
CREATE DATABASE IF NOT EXISTS nextcloud;<br />
GRANT ALL PRIVILEGES ON nextcloud.* TO 'username'@'localhost' IDENTIFIED BY 'password';<br />
FLUSH PRIVILEGES;<br />
quit<br />
<br />
taking care of replacing username with the proper username. A good candidate could be nextcloud_user. Do not forget to insert datas into '' symbols.<br />
In case password contain symbols, be careful because certain characters could be interpreted as escape chars (like />). In that case the procedure will look to be ended flawlessly, but next time you will try to authenticate you will get authentication errors in connecting to the DB.<br />
<br />
==Nextcloud server initialization==<br />
<br />
# cd /usr/share/nextcloud/<br />
# sudo -u apache php occ maintenance:install --data-dir /var/lib/nextcloud/data/ --database "mysql" --database-name "nextcloud" --database-user "nextcloud" --database-pass "database_password" --admin-user "nextcloud_admin" --admin-pass "nextcloud_admin_password"<br />
<br />
===Firewall configuration===<br />
<br />
# firewall-cmd --list-all-zones | grep active<br />
In our case<br />
public (default, active)<br />
so we will use public zone and following commands to enable http e https services access<br />
<br />
# firewall-cmd --permanent --zone=public --add-service=http<br />
# firewall-cmd --permanent --zone=public --add-service=https<br />
# firewall-cmd --reload<br />
<br />
===Grant access to remote hosts===<br />
<br />
To let Nextcloud be reached from remote hosts, you have to edit<br />
<br />
# /etc/nextcloud/config.php<br />
<br />
adding server IP address in 'trusted_domains' section. Finally run<br />
<br />
# ln -s /etc/httpd/conf.d/nextcloud-access.conf.avail /etc/httpd/conf.d/z-nextcloud-access.conf</div>Germanohttps://fedoraproject.org/w/index.php?title=Nextcloud&diff=488087Nextcloud2017-03-17T08:36:48Z<p>Germano: Nextcloud server installation</p>
<hr />
<div>==Introduction==<br />
Nextcloud is a software that permits users to create a personal cloud system<br />
<br />
==Installation==<br />
To install Nextcloud, run:<br />
# dnf install nextcloud<br />
<br />
===Configuration of self generated SSL certificate===<br />
affinché le comunicazioni tra host e server siano crittografate, occorre generare una chiave ed un certificato<br />
<br />
# dnf install crypto-utils<br />
<br />
# genkey ''hostname''<br />
<br />
Answer no to question "Would you like to send a Certificate Request (CSR) to a Certificate Authority (CA)?" <br />
<br />
To let httpd service using SSL, the following dependencies need to be installed<br />
# dnf install mod_ssl openssl<br />
and edit<br />
/etc/httpd/conf.d/ssl.conf<br />
adding to the bottom<br />
<br />
SSLCertificateFile /etc/pki/tls/certs/hostname.crt<br />
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key<br />
<br />
To force SSL usage in server Nextcloud follow Apache documentation about Virtual Hosts. A "Let's Encrypt" certificate is highly recommended instead of a self generated SSL certificate<br />
Also read [https://docs.nextcloud.com/server/10/admin_manual/configuration_server/harden_server.html Nextcloud server hardening guide]<br />
<br />
<br />
===Installation MariaDB/MySQL===<br />
# dnf install mariadb-server<br />
# systemctl enable --now mariadb<br />
$ mysql_secure_installation<br />
<br />
when you will be prompted for root password, simply press Enter without writing anything. Answer yes to the question about creating a root user, then enter a password.<br />
Now you have to create an user and the database for Nextcloud usage<br />
$ mysql -u root -p<br />
CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';<br />
CREATE DATABASE IF NOT EXISTS nextcloud;<br />
GRANT ALL PRIVILEGES ON nextcloud.* TO 'username'@'localhost' IDENTIFIED BY 'password';<br />
FLUSH PRIVILEGES;<br />
quit<br />
<br />
taking care of replacing username with the proper username. A good candidate could be nextcloud_user. Do not forget to insert datas into '' symbols.<br />
In case password contain symbols, be careful because certain characters could be interpreted as escape chars (like />). In that case the procedure will look to be ended flawlessly, but next time you will try to authenticate you will get authentication errors in connecting to the DB.<br />
<br />
==Nextcloud server initialization==<br />
<br />
# cd /usr/share/nextcloud/<br />
# sudo -u apache php occ maintenance:install --data-dir /var/lib/nextcloud/data/ --database "mysql" --database-name "nextcloud" --database-user "nextcloud" --database-pass "database_password" --admin-user "nextcloud_admin" --admin-pass "nextcloud_admin_password"<br />
<br />
===Firewall configuration===<br />
<br />
# firewall-cmd --list-all-zones | grep active<br />
In our case<br />
public (default, active)<br />
so we will use public zone and following commands to enable http e https services access<br />
<br />
# firewall-cmd --permanent --zone=public --add-service=http<br />
# firewall-cmd --permanent --zone=public --add-service=https<br />
# firewall-cmd --reload<br />
<br />
===Grant access to remote hosts===<br />
<br />
To let Nextcloud be reached from remote hosts, you have to edit<br />
<br />
# /etc/nextcloud/config.php<br />
<br />
adding server IP address in 'trusted_domains' section. Finally run<br />
<br />
# ln -s /etc/httpd/conf.d/nextcloud-access.conf.avail /etc/httpd/conf.d/z-nextcloud-access.conf</div>Germanohttps://fedoraproject.org/w/index.php?title=User:Germano&diff=484636User:Germano2017-01-23T10:22:13Z<p>Germano: /* Activities within Fedora */</p>
<hr />
<div>= Germano Massullo =<br />
<br />
<!-- Use code like this to put your hackergotchi or whatnot on the right side of the page. --><br />
<!-- Upload the file and edit the code below to match. --><br />
<!-- [[Image:|right]] --><br />
<br />
I started to use Linux around 2003 and I am a Fedora user since 2009.<br />
<br />
I mostly use Fedora with the KDE Plasma Desktop Environment.<br />
<br />
== Contact ==<br />
<br />
* '''Email''': my name DOT my surname AT gmail DOT com<br />
* '''IRC Channels''': I'm usually logged in #fedora-it, #fedora-kde<br />
* '''Fedora Account''': germano<br />
* '''Languages:''' Italian, English, French, and studying German :-)<br />
<br />
== Activities within Fedora ==<br />
<br />
* Ambassador;<br />
* [https://admin.fedoraproject.org/pkgdb/packager/germano/ packages maintainer];<br />
* involved in translations for the Italian language;<br />
* general bugreporting (downstream and upstream);<br />
* Fedora pre-releases tester to catch and report bugs related to the hardware I own;<br />
* patches tester;<br />
* user support in chat and forums;<br />
* Fedora and FOSS promotion among universities, public administrations and companies.<br />
<br />
== Badges ==<br />
{{ #fedorabadges: germano }}<br />
<br />
== Various FOSS communities I partecipate in ==<br />
<br />
* OpenStreetMap<br />
* Ninux.org<br />
* BOINC Italy<br />
<br />
== Some of my interests ==<br />
<br />
* [https://www.flickr.com/photos/130387494@N02/ photography];<br />
* 20th century history;<br />
* technology (not only information technology);<br />
* surfing;<br />
* swimming</div>Germanohttps://fedoraproject.org/w/index.php?title=User:Germano&diff=475803User:Germano2016-10-01T16:52:14Z<p>Germano: /* Activities within Fedora */</p>
<hr />
<div>= Germano Massullo =<br />
<br />
<!-- Use code like this to put your hackergotchi or whatnot on the right side of the page. --><br />
<!-- Upload the file and edit the code below to match. --><br />
<!-- [[Image:|right]] --><br />
<br />
I started to use Linux around 2003 and I am a Fedora user since 2009.<br />
<br />
I mostly use Fedora with the KDE Plasma Desktop Environment.<br />
<br />
== Contact ==<br />
<br />
* '''Email''': my name DOT my surname AT gmail DOT com<br />
* '''IRC Channels''': I'm usually logged in #fedora-it, #fedora-kde<br />
* '''Fedora Account''': germano<br />
* '''Languages:''' Italian, English, French, and studying German :-)<br />
<br />
== Activities within Fedora ==<br />
<br />
* Ambassador;<br />
* [https://admin.fedoraproject.org/pkgdb/packager/germano/ BOINC, Darktable, Owncloud-client, and various Python libaries packages co-mantainer];<br />
* involved in translations for the Italian language;<br />
* general bugreporting (downstream and upstream);<br />
* Fedora pre-releases tester to catch and report bugs related to the hardware I own;<br />
* patches tester;<br />
* user support in chat and forums;<br />
* Fedora and FOSS promotion among universities, public administrations and companies.<br />
<br />
== Badges ==<br />
{{ #fedorabadges: germano }}<br />
<br />
== Various FOSS communities I partecipate in ==<br />
<br />
* OpenStreetMap<br />
* Ninux.org<br />
* BOINC Italy<br />
<br />
== Some of my interests ==<br />
<br />
* [https://www.flickr.com/photos/130387494@N02/ photography];<br />
* 20th century history;<br />
* technology (not only information technology);<br />
* surfing;<br />
* swimming</div>Germanohttps://fedoraproject.org/w/index.php?title=Upgrading_Fedora_using_package_manager/it&diff=475046Upgrading Fedora using package manager/it2016-09-25T10:27:40Z<p>Germano: </p>
<hr />
<div>{{old}}<br />
{{autolang}}<br />
<br />
{{admon/warning|Sebbene gli upgrade con yum funzionino, non sono esplicitamente testati come parte del processo di rilascio dal [[QA|Fedora QA]] e non sono documentati nella [http://docs.fedoraproject.org/en-US/Fedora/{{FedoraVersion}}/html/Installation_Guide/index.html Guida all'installazione di Fedora]. Se non si è preparati a risolvere eventuali problemi, è meglio usare il [[Upgrading/it|metodo d'installazione raccomandato]].}}<br />
<br />
Questa pagina contiene informazioni su come aggiornare online Fedora usando {{command|yum}} o {{command|dnf}} (senza il DNF system upgrade plugin): in generale le istruzioni sono valide per entrambi gli strumenti. [[Dnf]] è quello predefinito in Fedora 22 e superiori, [[Yum]] in Fedora 21 e precedenti.<br />
<br />
== Aggiornamento di Fedora usando direttamente yum o direttamente con dnf ==<br />
<br />
Per gli upgrade il metodo raccomandato prevede l'uso dello strumento chiamato [[FedUp/it]]. [[FedUp/it#Come_posso_aggiornare_il_mio_sistema_con_FedUp.3F|Questa sezione]] contiene istruzioni sull'uso di FedUp.<br />
<br />
Quando si fa un upgrade con [[Yum]] o con [[Dnf]] non si avranno aiuti dagli stessi Anaconda o FedUp, ma con un sistema tipico si potrebbe essere in grado di aggiornare da remoto tramite SSH e con un downtime (tempo di inattività) limitato. (Si avrà ancora la necessità di riavviare per utilizzare il nuovo kernel ed i servizi attivi).<br />
<br />
L'aggiornamento live funziona bene sia con [[Yum]] che con [[Dnf]]; seguire i consigli seguenti.<br />
<br />
== Partecipare ==<br />
<br />
Se si sta facendo un upgrade usando [[Yum]] o [[Dnf]] e si notano problemi generici di dipendenza, si prega di segnalarli in http://bugzilla.redhat.com. Leggere la presente pagina wiki, tutte le pagine di riferimento e fare una ricerca nall'archivio della mailing list.<br />
<br />
Se si vuole aiutare a mantenere gli upgrade live funzionanti regolarmente, c'é il [[SIGs/LiveUpgrade | Live Upgrade Special Interest Group]].<br />
<br />
== Istruzioni per l'aggiornamento usando yum o dnf ==<br />
<br />
=== 1. Backup del sistema ===<br />
<br />
Eseguire un backup di tutti i dati personali su un disco esterno o un altro computer. Se si verificherà un errore irrecuperabile, un'installazione fresca non permetterà il recupero dei propri dati.<br />
<br />
=== 2. Leggi i problemi ricorrenti ===<br />
<br />
In una sezione successiva di questa pagina c'è un elenco di problemi comuni relativi alle specifiche versioni. Alcuni di questi richiedono attenzione prima di eseguire l'aggiornamento.<br />
<br />
Consigli generali sull'aggiornamento di Fedora possono essere trovati alla pagina [[Upgrading/it|Upgrading]]. Si dovrebbe inoltre leggere la [http://docs.fedoraproject.org/install-guide/ guida all'installazione] e le [http://docs.fedoraproject.org/release-notes/ note di rilascio] della versione verso alla quale si intende aggiornare - questi documenti contengono importanti informazioni riguardo i problemi di aggiornamento. Infine, controllare l'elenco dei [[Common bugs]] (bug conosciuti).<br />
<br />
=== 3. Fare pulizia ===<br />
<br />
Verificare ed eliminare tutti i file .rpmsave e .rpmnew prima e dopo l'aggiornamento. (Se è abilitato selinux, controllare il security context dei file di configurazione spostati.)<br />
<br />
{{admon/tip|Effettuare il merge e risolvere le modifiche determinate dallo script seguente: <code>yum install rpmconf; rpmconf -a</code>.<br />
Ora trovare e rimuovere le vecchie configurazioni che non appartengono a nessuno: <code>find /etc /var -name '*?.rpm?*'</code>}}<br />
<br />
A questo punto è consigliabile rimuovere tutti i pacchetti non utilizzati - in particolare quelli non standard.<br />
<br />
{{admon/tip|Trovare e verificare i pacchetti "inutilizzati"| E' possibile trovare i pacchetti non richiesti da altri pacchetti con il tool <code>package-cleanup</code> da <code>yum-utils</code>: <code>yum install yum-utils; package-cleanup --leaves</code>. Questi pacchetti potrebbero essere rimossi ma controllare se sono usati direttamente o da altre applicazioni non sostenute da pacchetti rpm. Possono essere rimossi con <code>yum remove package-name-and-version</code>.<br/><br />
Un altro strumento utile per la pulizia dai pacchetti non usati è <code>rpmreaper</code>. E' un'applicazione ncurses che permette di vedere un grafico delle dipendenze e di marcare i pacchetti da rimuovere. Marcando un pacchetto si ottengono le dipendenze relative che possono essere viste immediatamente così da non avviare più volte lo stesso strumento per sbarazzarsi del substrato di pacchetti dipendenti inutilizzati. Installalo con: <code>yum install rpmreaper</code>.<br />
}}<br />
<br />
{{admon/tip| Trovare e rivedere i pacchetti "perduti"| E' possibile trovare i pacchetti orfano (cioé non più presenti nei repository) con: <code>package-cleanup --orphans</code>. Mostrerà anche i pacchetti parzialmente disinstallati ma dove lo script "%postun" fallisce.}}<br />
<br />
=== 4. Fare l'aggiornamento ===<br />
<br />
Se si hanno configurati repository da terzi, devono essere impostati per la nuova versione di Fedora. Passando da una versione all'altra di Fedora, spesso non c'é nulla da fare. Se si passa da una Fedora standard ad una rawhide (o viceversa), inoltre molto tempo servirà per installare gli RPM rawhide dai repository da terzi (o quelli standard, viceversa).<br />
<br />
Da notare che l'upgrade può fallire in presenza di dipendenze obsolete da pacchetti non forniti dai repository di yum o da pacchetti non pronti per la nuova versione.<br />
<br />
E' buona norma operare l'upgrade al di fuori della modalità grafica. Disconnettersi per poi<br />
<br />
==== fedora-upgrade ====<br />
<br />
E' possibile usare lo script fedora-upgrade per automatizzare tutti i passaggi. Come per il metodo manuale, non è raccomandato come metodo d'aggiornamento da Fedora.<br />
<br />
<pre>$ sudo yum install fedora-upgrade <br />
$ sudo fedora-upgrade<br />
</pre><br />
<br />
In alternativa, effettuare i passaggi manualmente:<br />
<br />
==== Usare una console testuale ====<br />
<br />
<pre><br />
ctrl + alt + F2<br />
</pre><br />
<br />
oppure<br />
<br />
accedere come root nella modalità ''multi-user.target''<br />
<pre><br />
# systemctl isolate multi-user.target<br />
</pre><br />
<br />
==== Aggiornare yum all'ultima versione disponibile ====<br />
<br />
<pre><br />
# yum update yum<br />
</pre><br />
<br />
==== Installare le nuove chiavi gpg per la versione Fedora alla quale aggiornare ====<br />
<br />
Le chiavi possono essere trovate e verificate in <br />
<br />
https://fedoraproject.org/keys<br />
<br />
o vedere le istruzioni per uno specifico aggiornamento in basso.<br />
<br />
==== Pulizia della cache ====<br />
<br />
Rimuovere tutte le tracce della versione Fedora che si sta per lasciare nella cache di yum in <code>/var/cache/yum</code>.<br />
<br />
<pre><br />
# yum clean all<br />
</pre><br />
<br />
==== Upgrade di tutti i pacchetti ====<br />
<br />
{{admon/warning| Una volta iniziato l'upgrade live, non cercare di bloccarlo con un riavvìo, con il blocco del processo o con qualsiasi altro metodo finché non è completo. Interromperlo significherebbe ottenere un sistema misto -- parzialmente della vecchia versione e parzialmente nuovo. In questo stato non sarà affidabile e non funzionerà come ci si aspetta. E' possibile cercare di risolvere i problemi avviando 'yum distro-sync' o 'package-cleanup --problems'. }}<br />
<br />
<pre><br />
# yum --releasever=<versione alla quale si vuole sincronizzare> distro-sync<br />
</pre><br />
<br />
{{admon/warning| Se si riscontrano problemi con le dipendenze si è soli e bisogna risolverli manualmente. Se non si è capaci, usare il preupgrade.<br />
}}<br />
<br />
'''Note:''' Nonostante sia raccomandato fare upgrade a versioni intermedie, se si aggiorna da versioni vecchie (ad esempio da Fedora 19 a 20, poi da 20 a 21), dipende da quale versione si parte, questo passaggio potrebbe fallire con errore sulla chiave gpg con formato sbagliato. Per superarlo, aggiungere l'opzione "--nogpgcheck" al comando 'yum distro-sync'.<br />
<br />
=== 5. Assicurarsi che Fedora sia aggiornata ===<br />
<br />
Distro-sync solitamente assicura gli upgrade da repository da terzi abilitati. <pre> yum repolist </pre> conferma dopo il termine dell'upgrade. <code>yum</code> potrebbe segnalare conflitti o richieste aggiuntive, probabilmente perché si sono usati repository o pacchetti non standard installati manualmente. Tentare di scovare quali creano i problemi (o almeno parte della catena di dipendenze), disinstallarli e provare ancora. Ricordarsi di installare nuovamente quelli essenziali.<br />
<br />
Assicurarsi che tutti i (nuovi) pacchetti essenziali dalla nuova versione siano installati con<br />
<br />
<pre><br />
# yum groupupdate 'Minimal Install'<br />
</pre><br />
<br />
Verficare anche gli altri gruppi<br />
<br />
<pre><br />
# yum grouplist<br />
</pre><br />
<br />
Per esempio<br />
<br />
<pre><br />
# yum groupupdate "GNOME Desktop" \<br />
"Development Tools" "Sound and Video" \<br />
"Games and Entertainment" "Administration Tools" \<br />
"Office/Productivity" "System Tools"<br />
</pre><br />
<br />
=== 6. Preparazione al riavvìo ===<br />
<br />
{{Anchor|bootloader}}<br />
<br />
Prima di riavviare, di solito si installa il bootloader dal nuovo Grub con<br />
<br />
<pre><br />
/usr/sbin/grub2-install BOOTDEVICE<br />
</pre><br />
<br />
- dove BOOTDEVICE solitamente è <code>/dev/sda</code> ( se si ottiene errore allora '/dev/sda non ha un corrispondente dispositivo BIOS', allora provare <tt>/sbin/grub-install --recheck /dev/sda</tt>).<br />
<br />
Potrebbe essere necessario aggiornare il file di configurazione di Grub:<br />
<br />
<pre><br />
cp --backup=numbered -a /boot/grub2/grub.cfg{,.bak} # crea una copia di backup<br />
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg # aggiorna il file ''config''<br />
</pre><br />
<br />
Inoltre, l'ordine degli script init potrebbe essere cambiato dalla versione precedente. Un comando per reimpostarlo è <br />
<br />
<pre> cd /etc/rc.d/init.d; for f in *; do /sbin/chkconfig $f resetpriorities; done </pre><br />
<br />
Ancora, avviare <code>package-cleanup --orphans</code> per trovare i pacchetti che non sono stati aggiornati.<br />
<br />
=== 7. Pulizia del sistema ===<br />
Ancora, pulire il sistema come descritto nella sezione 2. Inoltre può servire rimuovere alcuni file della cache non più utilizzati, ad esempio quelli della versione precedente di Fedora nelle seguenti directory:<br />
<br />
* <nowiki>/var/cache/yum</nowiki><br />
* <nowiki>/var/cache/dnf</nowiki><br />
* <nowiki>/var/cache/mock</nowiki><br />
* <nowiki>/var/lib/mock</nowiki><br />
<br />
== Note su versioni specifiche ==<br />
<br />
=== Aggiornamento da una pre-release ===<br />
<br />
Se si sta aggiornando ad una versione finale da una alpha, da una beta, da una anteprima o da altre [[Releases/Rawhide|Rawhide]] versioni, si prega di vedere [[Upgrading from pre-release to final]] (Aggiornamento da una pre-release ad una finale).<br />
<br />
{{Anchor|Rawhide}}<br />
<br />
=== Aggiornamento ad una rawhide ===<br />
<br />
{{admon/warning| Rawhide è il ramo di sviluppo di Fedora. E' pensato per essere utilizzato da sviluppatori e tester per fornire feedback al Fedora Project.}}<br />
<br />
Vedere la pagina [[Releases/Rawhide|Rawhide]] per maggiori informazioni sulla Rawhide. <br />
<br />
<pre><br />
# dnf install dnf-plugins-core fedora-repos-rawhide<br />
# dnf config-manager --set-disabled fedora updates updates-testing<br />
# dnf config-manager --set-enabled rawhide<br />
# dnf clean -q dbcache plugins metadata<br />
# dnf --releasever=rawhide --setopt=deltarpm=false distro-sync --nogpgcheck<br />
<br />
## Opzionale: generalmente è suggerito fare un #autorelabel con #SELinux<br />
<br />
# touch /.autorelabel<br />
</pre><br />
<br />
{{Anchor|20-21}}<br />
<br />
=== Fedora 22 -> Fedora 23 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-$(uname -i)<br />
# dnf upgrade<br />
# dnf clean all<br />
# dnf --releasever=23 --setopt=deltarpm=false distro-sync<br />
<br />
=== Fedora 21 -> Fedora 22 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-22-$(uname -i)<br />
# yum update yum<br />
# yum clean all<br />
# yum --releasever=22 distro-sync<br />
<br />
=== Fedora 20 -> Fedora 21 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-21-$(uname -i)<br />
# yum update yum<br />
# yum clean all<br />
# yum --releasever=21 distro-sync<br />
<br />
Fedora 21 è divisa in prodotti differenti. Eseguire '''uno solo''' di questi comandi:<br />
<br />
# yum install system-release-workstation<br />
# yum install system-release-cloud<br />
# yum install system-release-server<br />
<br />
o quello non rivolto ad alcun dei tre precedenti<br />
<br />
# yum install system-release-nonproduct<br />
<br />
E' possibile modificare il prodotto precedentemente installato con<br />
<br />
# yum swap system-release-cloud system-release-workstation<br />
<br />
Cambiare in ''workstation'' a volte potrebbe richiedere di usare {{command|yum shell}} in quanto alcuni pacchetti possono essere scambiati.<br />
<br />
Qualcuno ha segnalato (e.g. bugs 1035326, 1044184, 1002331) che dopo gli upgrade alcuni file erano segnati male da SELinux. Si raccomanda quindi di avviare:<br />
<br />
# restorecon -R /<br />
<br />
Riavvìo:<br />
<br />
# shutdown -h now<br />
Failed to start poweroff.target: Connection timed out<br />
Failed to open /dev/initctl: No such device or address<br />
Failed to talk to init daemon.<br />
<br />
=== Upgrade da una Fedora ufficialmente in Fine Vita (End Of Life EOL) ===<br />
<br />
{{admon/note| Upgrade con yum da versioni più datate | Gli aggiornamenti dalle versioni più vecchie di Fedora sono archiviati in [[Upgrading from EOL Fedora using yum]]}}<br />
<br />
[[Category:FAQ]]<br />
[[Category:How to]]<br />
[[Category:Documentation]]<br />
[[Category:Italiano]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Upgrading_Fedora_using_package_manager&diff=475045Upgrading Fedora using package manager2016-09-25T10:27:07Z<p>Germano: The page is obsolete but {{old}} is missing</p>
<hr />
<div>{{old}}<br />
{{autolang|base=yes}}<br />
<br />
{{admon/warning| This page is obsolete. Refer to [[Upgrading]] page on the current official methods to upgrade Fedora.}}<br />
<br />
This page contains information explaining how to upgrade Fedora online using {{command|yum}} or {{command|dnf}} (without the DNF system upgrade plugin): in general the instructions apply equally to both tools, you may substitute one for the other at any point. [[Dnf]] is the default tool for Fedora 22 and later, [[Yum]] for Fedora 21 and earlier.<br />
<br />
== Upgrading Fedora using yum or dnf directly ==<br />
<br />
== Participate ==<br />
<br />
If you are upgrading using [[Yum]] or [[Dnf]] and it shows any general dependency issues, please file them in [http://bugzilla.redhat.com Bugzilla]. But please read this page, all references pages and search the mailing list archives before filing bugs. And of course, please help keep this page updated.<br />
<br />
If you want to help make live upgrades work smoothly, join the [[SIGs/LiveUpgrade | Live Upgrade Special Interest Group]].<br />
<br />
== Instructions to upgrade using yum or dnf==<br />
<br />
=== 1. Backup your system ===<br />
<br />
Backup any personal data to an external hard drive or to another machine. If there is some unrecoverable error that requires a fresh install, you don't want to lose any data.<br />
<br />
=== 2. Read about common problems ===<br />
<br />
Further down in this page there is a list of common problems specific to yum or dnf upgrades for specific versions. Some of them require attention before the upgrade.<br />
<br />
General advice on upgrading Fedora can be found on the [[Upgrading]] page. You should also read the [http://docs.fedoraproject.org/install-guide/ Installation Guide] and [http://docs.fedoraproject.org/release-notes/ Release Notes] for the version you plan to upgrade to - they contain important information regarding upgrading issues. Finally, check the list of [[Common bugs]].<br />
<br />
=== 3. Clean Stuff ===<br />
<br />
Review and remove all .rpmsave and .rpmnew files before and after upgrading. (And if you have selinux enabled then remember to check security context if you move config files around.)<br />
<br />
{{admon/tip|Find unused config files|Merge and resolve the changes found by the following script: <code>yum install rpmconf; rpmconf -a</code><br />
Now find and remove old config which nobody owns: <code>find /etc /var -name '*?.rpm?*'</code>}}<br />
<br />
Now is a good time to remove packages you don't use - especially non-standard packages.<br />
<br />
{{admon/tip|Find and review "unused" packages| You can find packages not required by other packages with the tool <code>package-cleanup</code> from the <code>yum-utils</code> package: <code>yum install yum-utils; package-cleanup --leaves</code>. These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages. Remove them with <code>yum remove package-name-and-version</code>.<br/><br />
Another useful tool for cleaning up unused packages is <code>rpmreaper</code>. It's an ncurses application that lets you view rpm dependency graph and mark packages for deletion. Marking one package can make other packages leaf, which you can see immediately, so you don't have to run the tool several times to get rid of whole sub-tree of unused packages. Install with: <code>yum install rpmreaper</code>.<br />
}}<br />
<br />
{{admon/tip|Find and review "lost" packages| You can find orphaned packages (ie packages not in the repositories anymore) with: <code>package-cleanup --orphans</code>. This will also show packages which have been partially uninstalled but where the "%postun" script failed.}}<br />
<br />
=== 4. Do the upgrade ===<br />
<br />
If you have 3rd party repositories configured, you may need to adjust them for the new Fedora version. If you switch from one Fedora release to another there is often nothing that needs to be done. If you switch to Rawhide from a standard Fedora release (or vice versa) then most of the time you will need to install the Rawhide release RPMs from the 3rd party repository as well (or the standard ones, if switching back).<br />
<br />
Note that the upgrade is likely to fail if there are outdated dependencies from packages not backed by a yum repository or backed by a repository which isn't ready for the new version.<br />
<br />
It is a good idea to do the upgrade outside the graphical environment. Log out of your graphical desktop and then<br />
<br />
==== fedora-upgrade ====<br />
<br />
A small script named fedora-upgrade is available which aims to automate the process outlined below. To run it, do the following<br />
<br />
<pre>$ sudo yum install fedora-upgrade <br />
$ sudo fedora-upgrade<br />
</pre><br />
<br />
When performing upgrade via remote shell, it is good idea to use screen or tmux utility to be able to get back to running transaction in case your connection drops.<br />
<br />
Alternatively, follow the manual steps:<br />
<br />
==== Go to a text console ====<br />
<br />
<pre><br />
ctrl + alt + F2<br />
</pre><br />
<br />
(or)<br />
<br />
log in as root, and go into multi-user.target<br />
<br />
<pre><br />
systemctl isolate multi-user.target<br />
</pre><br />
<br />
==== Update yum to latest version available in your Fedora version ====<br />
<br />
<pre><br />
# yum update yum<br />
</pre><br />
<br />
==== Install the new fedora gpg key for the version you are updating to ====<br />
<br />
Keys you may find and verify at<br />
<br />
https://fedoraproject.org/keys<br />
<br />
or see a version specific update instructions at the bottom.<br />
<br />
==== Clean the cache ====<br />
<br />
Then remove all traces of the version you are leaving from the yum cache in <code>/var/cache/yum</code>.<br />
<br />
<pre><br />
# yum clean all<br />
</pre><br />
<br />
==== Upgrade all packages ====<br />
<br />
{{admon/warning|Once a live upgrade is started, do not stop the upgrade by rebooting, killing the process, or by any other method until it is complete. Interrupting an upgrade will cause the affected system to be in a mixed state -- partially the old release and partially the new release. In this state, the system will not be reliable and will not operate as expected. You can try running yum distro-sync and package-cleanup --problems to try and fix the problems. }}<br />
<br />
<pre><br />
# yum --releasever=<release_number_you_want_to_sync_to> distro-sync<br />
</pre><br />
<br />
{{admon/warning|If you experience any dependency problems, you have to solve them manually. Most often it is enough to remove several problematic package(s). Be very careful when doing so however.<br />
}}<br />
<br />
'''Note:''' While it is recommended to upgrade to intermediate releases if upgrading from an older release (for example upgrading from Fedora 19 to 20, then 20 to 21), depending on what version you are upgrading from, this step may fail with an error about GPG keys being in the wrong format. To overcome this, you can add the "--nogpgcheck" switch to the above yum distro-sync command.<br />
<br />
=== 5. Make sure Fedora is upgraded ===<br />
<br />
Distro-sync will usually take care of upgrades for the third party repositories you have enabled as well. Confirm with <pre> yum repolist </pre> after the upgrade process is over. <code>yum</code> might complain about conflicts or requirements. That is probably because you have used non-standard repositories or installed non-standard packages manually. Try to guess which packages cause the problem (or at least is a part of the dependency chain) - uninstall them and try again. Remember to install the packages again if they are essential. <br />
<br />
Ensure that all (new) essential packages from the new version are installed with<br />
<br />
<pre><br />
# yum groupupdate 'Minimal Install'<br />
</pre><br />
<br />
You might want to update other groups too, see<br />
<br />
<pre><br />
# yum grouplist<br />
</pre><br />
<br />
For example<br />
<br />
<pre><br />
# yum groupupdate "GNOME Desktop" \<br />
"Development Tools" "Sound and Video" \<br />
"Games and Entertainment" "Administration Tools" \<br />
"Office/Productivity" "System Tools"<br />
</pre><br />
<br />
=== 6. Preparing for reboot ===<br />
<br />
{{Anchor|bootloader}}<br />
<br />
Before booting you should usually install the bootloader from your new grub by running<br />
<pre><br />
/usr/sbin/grub2-install BOOTDEVICE<br />
</pre><br />
- where BOOTDEVICE is usually <code>/dev/sda</code> (If you get an error '/dev/sda does not have any corresponding BIOS drive' from that, then try <tt>/usr/sbin/grub2-install --recheck /dev/sda</tt>).<br />
<br />
It might also be necessary to update the grub config file:<br />
<pre><br />
cp --backup=numbered -a /boot/grub2/grub.cfg{,.bak} # create backup copy<br />
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg # update config file<br />
</pre><br />
<br />
Also, the order of init scripts could have changed from the previous version. A command to reset the order is:<br />
<pre><br />
cd /etc/rc.d/init.d; for f in *; do [ -x $f ] && /sbin/chkconfig $f resetpriorities; done<br />
</pre><br />
<br />
=== 7. Cleanup your system ===<br />
Again, cleanup your system as described in section 2. Also you might want to remove some cache files that are no longer used, for example files from older Fedora releases in the following directories:<br />
<br />
* <nowiki>/var/cache/yum</nowiki><br />
* <nowiki>/var/cache/dnf</nowiki><br />
* <nowiki>/var/cache/mock</nowiki><br />
* <nowiki>/var/lib/mock</nowiki><br />
<br />
== Version specific notes ==<br />
<br />
=== From pre-release ===<br />
<br />
If you are upgrading to a final release from an alpha, beta, preview, or other [[Releases/Rawhide|Rawhide]] release, please see [[Upgrading from pre-release to final]].<br />
<br />
{{Anchor|Rawhide}}<br />
=== To rawhide ===<br />
<br />
{{admon/warning| Rawhide is the development branch of Fedora. It is meant to be used by developers and testers to provide feedback to the Fedora Project.}}<br />
<br />
See the [[Releases/Rawhide|Rawhide]] release page for more information on Rawhide. <br />
<br />
<pre><br />
# dnf upgrade<br />
# dnf install dnf-plugins-core fedora-repos-rawhide<br />
# dnf config-manager --set-disabled fedora updates updates-testing<br />
# dnf config-manager --set-enabled rawhide<br />
# dnf clean -q dbcache packages metadata<br />
# dnf --releasever=rawhide --setopt=deltarpm=false distro-sync --nogpgcheck<br />
<br />
## Optional: it is generally advised to do a selinux autorelabel and reboot<br />
# touch /.autorelabel<br />
</pre><br />
<br />
<br />
{{Anchor|24-25}}<br />
<br />
=== Fedora 24 -> Fedora 25 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-$(uname -i)<br />
# dnf upgrade<br />
# dnf clean all<br />
# dnf --releasever=25 --setopt=deltarpm=false distro-sync<br />
<br />
{{Anchor|23-24}}<br />
<br />
=== Fedora 23 -> Fedora 24 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-$(uname -i)<br />
# dnf upgrade<br />
# dnf clean all<br />
# dnf --releasever=24 --setopt=deltarpm=false distro-sync<br />
<br />
{{Anchor|22-23}}<br />
=== Fedora 22 -> Fedora 23 ===<br />
<br />
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-$(uname -i)<br />
# dnf upgrade<br />
# dnf clean all<br />
# dnf --releasever=23 --setopt=deltarpm=false distro-sync<br />
<br />
=== Upgrading from legacy end of life (EOL) Fedoras ===<br />
{{admon/note|Yum upgrading from older versions|Upgrading from older versions of Fedora is archived here: [[Upgrading from EOL Fedora using yum]]}}<br />
<br />
[[Category:FAQ]]<br />
[[Category:How to]]<br />
[[Category:Documentation]]</div>Germanohttps://fedoraproject.org/w/index.php?title=EPEL/it&diff=463892EPEL/it2016-07-10T06:03:07Z<p>Germano: /* Quali pacchetti e versioni sono disponibili in EPEL? */</p>
<hr />
<div>{{autolang}}<br />
<br />
[[Image:banner468x120.png]]<br />
<br />
= Extra Packages for Enterprise Linux (EPEL) =<br />
<br />
Benvenuti nella home dell'EPEL Special Interest Group.<br />
<br />
== Cosa è Extra Packages for Enterprise Linux (o EPEL)? ==<br />
<br />
'Extra Packages for Enterprise Linux' (o EPEL) è un gruppo speciale di utenti (Fedora Special Interest Group) che si interessa di creare, mantenere e gestire pacchetti RPM addizionali di alta qualità per Enterprise Linux, includendo, ma non limitato, [[Red_Hat_Enterprise_Linux | Red Hat Enterprise Linux]] (RHEL), CentOS e Scientific Linux (SL), Oracle Linux (OL).<br />
<br />
I pacchetti EPEL sono solitamente basati sulla loro controparte in Fedora, non saranno mai in conflitto né un rimpiazzo con quelli base per le distribuzioni Enterprise Linux. EPEL usa parte della stessa infrastruttura usata per Fedora, inclusi buildsystem, bugzilla instance, update manager, mirror manager ed altro.<br />
<br />
Per saperne di più su EPEL, seguire le seguenti pagine:<br />
<br />
* [[EPEL/FAQ | EPEL FAQ]]<br />
<br />
* [[About_EPEL |About EPEL]]<br />
<br />
* [[EPEL/GuidelinesAndPolicies|Politiche e Linee guida di EPEL]]<br />
<br />
== Quali pacchetti e versioni sono disponibili in EPEL? ==<br />
<br />
E' possibile saperlo visitando uno qualsiasi dei mirror EPEL: [https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL Lista mirror]<br />
<br />
In alternativa, è possibile visualizzare i pacchetti usando repoview:<br />
<br />
* EPEL 7: [http://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/ x86_64], [http://dl.fedoraproject.org/pub/epel/7/ppc64/repoview/ ppc64], [http://dl.fedoraproject.org/pub/epel/7/SRPMS/repoview/ sources]<br />
* EPEL 6: [http://dl.fedoraproject.org/pub/epel/6/i386/repoview/ i386], [http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/ x86_64], [http://dl.fedoraproject.org/pub/epel/6/ppc64/repoview/ ppc64], [http://dl.fedoraproject.org/pub/epel/6/SRPMS/repoview/ sources]<br />
* EPEL 5: [http://dl.fedoraproject.org/pub/epel/5/i386/repoview/ i386], [http://dl.fedoraproject.org/pub/epel/5/x86_64/repoview/ x86_64], [http://dl.fedoraproject.org/pub/epel/5/ppc/repoview/ ppc], [http://dl.fedoraproject.org/pub/epel/5/SRPMS/repoview/ sources]<br />
<br />
== Come posso usare questi pacchetti ? ==<br />
<br />
EPEL dispone di un pacchetto 'epel-release' che include chiavi gpg per la firma ed informazioni sul repository. Installandolo per la propria versione Enterprise Linux permetterà di usare i normali strumenti come yum per installare altri pacchetti e le loro dipendenze. Normalmente, il repo stabile EPEL è già abilitato; esiste anche un [[EPEL/testing|'epel-testing' repository]] che contiene pacchetti non ancora considerati stabili. <br />
<br />
{{admon/tip|NOTA per utenti RHN.|per usare gli EPEL serve anche abilitare il repository ''''optional'''' visto che contiene utili dipendenze. Questo può essere fatto abilitando 'RHEL optional' [https://access.redhat.com/kb/docs/DOC-11313 subchannel] per RHN-Classic. Per le sottoscrizioni basate su certificati, vedi [https://access.redhat.com/kb/docs/DOC-11313 subchannel] for RHN-Classic. For certificate-based subscriptions see [https://access.redhat.com/site/documentation/en-US/Red_Hat_Subscription_Management/1/html/RHSM/entitlements-and-yum.html#supplementary-repos Red Hat Subscription Management Guide].<br />
<br />
Per EPEL7, oltre ai repository ''''optional'''' (rhel-7-server-optional-rpms), è possibile abilitare anche quelli ''''extras'''' (rhel-7-server-extras-rpms).}}<br />
<br />
{{admon/tip|NOTA per utenti CentOS|E' possibile installare con il comando '''yum install epel-release'''. Il pacchetto è incluso nei repo CentOS Extras, abilitato di default.}}<br />
<br />
Se si usa la versione EL7, si prega di visitare il seguente link per ottenere il pacchetto 'epel-release' più recente: [http://download.fedoraproject.org/pub/epel/7/x86_64/repoview/epel-release.html 'epel-release' per EL7 più aggiornato]<br />
<br />
Se si usa la versione EL6, si prega di visitare il seguente link per ottenere quelli più aggiornati per EL6: [http://download.fedoraproject.org/pub/epel/6/i386/repoview/epel-release.html 'epel-release' EL6 più aggiornato]<br />
<br />
Se si usa la versione EL5, si prega di visitare il seguente link per ottenere quelli più aggiornati per EL5: [http://download.fedoraproject.org/pub/epel/5/i386/repoview/epel-release.html 'epel-release' EL5 più aggiornato]<br />
<br />
E' possibile verificare pacchetti e chiavi da questa pagina del Fedora project: https://fedoraproject.org/keys<br />
<br />
== Storia e retroscena del progetto ==<br />
<br />
Il progetto EPEL nacque quando i manutentori Fedora capirono che la stessa infrastruttura che costruisce e mantiene i pacchetti per Fedora potesse essere utile anche per il mantenimento di pacchetti addizionali per Enterprise Linux. La maggior parte delle necessità iniziali erano basate su cosa serviva all'infrastruttura Fedora sulle macchine RHEL. Da lì il tutto è cresciuto fino ad avere una vasta collezione di pacchetti. Vedere la [[History_and_Philosophy_of_EPEL|pagina sulla nostra storia]] per maggiori informazioni.<br />
<br />
== Come si può contribuire ? ==<br />
<br />
EPEL SIG è sempre attento ad aiutare persone interessate. Necessitiamo sempre di package maintainer, qa/tester, bug triager, marketing e redattori per la documentazione. Si prega di vedere la nostra pagina [[Joining_EPEL | Partecipare ad EPEL]] per maggiori informazioni su come iniziare a contribuire a SIG.<br />
<br />
== Comunicare col SIG EPEL ==<br />
<br />
Ci sono molti modi per comunicare con il SIG EPEL ed i suoi membri: <br />
<br />
* Il canale IRC {{fpchat|#epel}} su irc.freenode.net offre supporto in tempo reale per utenti e sviluppatori. <br />
<br />
* La lista mail {{fplist|epel-devel}} è per discussioni generali degli sviluppatori. <br />
<br />
* La lista mail {{fplist|epel-announce}} è a bassa frequenza di invio mail ed è solo per annunci importanti. <br />
<br />
* La lista mail {{fplist|epel-package-announce}} è usata per scambiare informazioni sugli aggiornamenti dei pacchetti nel repository stabile. <br />
<br />
* Se si incontra un bug in un pacchetto EPEL, si prega di riportarlo in [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+EPEL https://bugzilla.redhat.com/] come prodotto "Fedora EPEL".<br />
<br />
* Il SIG EPEL organizza incontri settimanali ogni venerdì nel canale {{fpchat|#epel}} alle ora 16:00 UTC. Si è liberi di partecipare. I log degli incontri passati può essere trovato all'indirizzo http://meetbot.fedoraproject.org/teams/epel/<br />
<br />
<br />
[[Category:Da revisionare]]<br />
[[Category:Italiano]]<br />
[[Category:EPEL]]<br />
[[Category:Fedora sub-projects]]</div>Germanohttps://fedoraproject.org/w/index.php?title=User:Germano&diff=461224User:Germano2016-07-04T09:52:39Z<p>Germano: /* Activities within Fedora */</p>
<hr />
<div>= Germano Massullo =<br />
<br />
<!-- Use code like this to put your hackergotchi or whatnot on the right side of the page. --><br />
<!-- Upload the file and edit the code below to match. --><br />
<!-- [[Image:|right]] --><br />
<br />
I started to use Linux around 2003 and I am a Fedora user since 2009.<br />
<br />
I mostly use Fedora with the KDE Plasma Desktop Environment.<br />
<br />
== Contact ==<br />
<br />
* '''Email''': my name DOT my surname AT gmail DOT com<br />
* '''IRC Channels''': I'm usually logged in #fedora-it, #fedora-kde<br />
* '''Fedora Account''': germano<br />
* '''Languages:''' Italian, English, French, and studying German :-)<br />
<br />
== Activities within Fedora ==<br />
<br />
* [https://admin.fedoraproject.org/pkgdb/packager/germano/ BOINC, Darktable, Owncloud-client, and various Python libaries packages co-mantainer];<br />
* involved in translations for the Italian language;<br />
* general bugreporting (downstream and upstream);<br />
* Fedora pre-releases tester to catch and report bugs related to the hardware I own;<br />
* patches tester;<br />
* user support in chat and forums;<br />
* Fedora and FOSS promotion among universities, public administrations and companies.<br />
<br />
== Badges ==<br />
{{ #fedorabadges: germano }}<br />
<br />
== Various FOSS communities I partecipate in ==<br />
<br />
* OpenStreetMap<br />
* Ninux.org<br />
* BOINC Italy<br />
<br />
== Some of my interests ==<br />
<br />
* [https://www.flickr.com/photos/130387494@N02/ photography];<br />
* 20th century history;<br />
* technology (not only information technology);<br />
* surfing;<br />
* swimming</div>Germanohttps://fedoraproject.org/w/index.php?title=Initiatives/University_Involvement_Initiative&diff=449225Initiatives/University Involvement Initiative2016-06-03T16:16:16Z<p>Germano: /* Europe, Middle East, and Africa (EMEA) */</p>
<hr />
<div>== Objective: Proposed University Involvement Initiative ==<br />
<br />
=== Overview ===<br />
Increase Fedora's exposure in university environments, particularly engineering universities.<br />
<br />
[[File:Fedora-council_edu-logic-model1.png|1000px]]<br />
<br />
=== Expected Impact ===<br />
Increased user base with a specific focus on future contributors.<br />
<br />
=== Timeframe ===<br />
For maximum effect, this should kick into gear at the beginning of the (Northern Hemisphere) academic summer, with the intent of having events planned during the 2016-2017 school year.<br />
<br />
=== Aspects ===<br />
* Coordinate Marketing, Ambassador and Outreach groups to focus on university needs<br />
* Work with universities to provide install-fests during student orientation periods<br />
* Work with universities to regularly run Fedora-focused hackfests<br />
* Work with university IT departments to co-maintain one or more Fedora computer labs (and help them upgrade them during breaks)<br />
* Establish work-study, co-op and for-credit programs at universities<br />
<br />
=== Metrics ===<br />
* Increased contributions from university programs<br />
* Increased bug reports and feature requests<br />
* Increased mind-share among potential contributors (not easily measured)<br />
<br />
=== Realized Impact: FY16 ===<br />
<br />
* Establishment of Letters@fedoraproject.org has enabled us to formally support academic credit to students in India and other countries where these letters can be of use.<br />
* Fedora Has been Accepted to Google Summer of Code 2016!<br />
* Fedora has participated in both rounds of Outreachy this year. Though we were not able to field eligible candidates in the winter, numerous applicants have remained active contributors.<br />
* After Software Freedom Day 2016, we now have a model for offering a "badge-a-thon" at Universities and other events.<br />
* Though hubs has not been under as much active development as we anticipated in 2015, 2016 is ramping up. There are tickets filed related to the EDU Hub now.<br />
<br />
=== Additional Notes ===<br />
Some prototypes of this have been performed at Brno universities over the last few years, with very positive results. We should coordinate with the contributors involved in those efforts and learn from their successes and failures.<br />
<br />
There is also a University Outreach program run by Red Hat's "Open Source and Standards" department which was involved in the RIT partnership from which we eventually acquired Remy DeCausemaker. I assume he will have plenty to add to this discussion as well as contacts in the university world.<br />
<br />
== Proposed Program: Campus Ambassadors ==<br />
<br />
=== Outline ===<br />
<br />
After having a conversation with Red Hat's University Relations Team, we have drafted a proposal for a program that looks/feels more like traditional EDU outreach. Below is a description of the particulars. A rough outline of the program would be:<br />
<br />
* Develop materials for EDU-specific outreach to be used in our efforts, regardless of a Representatives program<br />
* Hold a Fedora Activity Day (FAD) for EDU material development and [[Campus Ambassadors]] training<br />
* Search for and select (3) Campus Ambassadors from each region of Fedora Ambassadors (NA, EMEA, APAC, LATAM)<br />
* Hold a [[Campus Ambassadors]] training FAD where we work with the 12 student representatives on how to run on campus workshops/events<br />
* Organize (3) events at schools in each region (12 total)<br />
* Re-evaluate the program after AY2016<br />
<br />
=== Quaid's Funnel of Contributor Engagement ===<br />
[[User:Quaid | Karsten Wade]] has described in the past the "funnel" of contributor engagement.<br />
<br />
* Tier 1 events are '''Introductory''', and will expose students to both FOSS in general, and increase *awareness* of Fedora's role in the FOSS community. Our first year of the program will target Tier 1 events exclusively.<br />
<br />
* Tier 2 events will target '''Power Users''' and be organized on-site. This will require commitments from a [[Campus Ambassadors|Campus Ambassador]], at least one dedicated staff / faculty member, and 25 students.<br />
<br />
* Tier 3 events will target '''Contributors''' and be organized on-site through the same manner and scope as we organize Fedora Activity Days. At this point, it is expected that the [[Campus Ambassadors]] will be fully integrated into the Fedora community.<br />
<br />
=== Schools and [[Campus Ambassadors]] ===<br />
<br />
The program's focus will be on a '''minimum of three schools''' per region (APAC, EMEA, LATAM, North America). The schools should have:<br />
* Computer science program, OR<br />
* Active Linux User Group, OR<br />
* Large student audience<br />
<br />
Owing to the number of schools, one Campus Ambassador will be identified for each selected school. <br />
<br />
==== Campus Ambassadors kit ====<br />
<br />
* Stickers<br />
* Exclusive swag<br />
* [[Campus Ambassadors]] budget (Travel + Food)<br />
<br />
=== Metrics ===<br />
<br />
The EDU team currently tracks:<br />
* Schools we visit<br />
* Number of attendees<br />
<br />
The data recovered will help in determining the level of impact each event had. This will be instrumental in planning and managing future events. Data visualizations and reports will be generated based on the raw data collected.<br />
<br />
=== Quaid's triangle ===<br />
<br />
==== 1. Awareness ====<br />
<br />
The awareness program will focus on imparting knowledge by answering the questions<br />
* '''What is Linux?''' <br />
* '''Why Linux?''' <br />
<br />
The answers to these questions will form a formidable base for the complete program. Along with the aforementioned questions, the attendees could also be enlightened about '''Open Source''' in general and its principles. Further, this will facilitate the understanding of the answer to the question: '''Why Fedora?''' (without being disparaging to other Linux distributions). <br />
<br />
==== 2. Power User ====<br />
<br />
Power users could be defined as avid learners aiming to elevate their productivity by using available tools. The workshops held in this program will focus on teaching advanced tools and how Fedora can be easily set up to use these tools.<br />
<br />
In a nutshell:<br />
* Git tutorial on GitHub (Pagure?)<br />
* Git + OpenShift tutorial<br />
* [https://www.gnupg.org/ GPG]<br />
* [http://www.openssh.com/ SSH]<br />
* Showing off advanced features in Fedora<br />
* Installing Fedora on the VM<br />
* [https://www.ansible.com/ Ansible]<br />
* [http://www.openstack.org/ OpenStack]<br />
* [https://owncloud.org/ ownCloud]<br />
<br />
==== 3. Contributor ====<br />
<br />
* Personal guidance to lead the contributor towards the contribution pathways owing to his/her preferences or liking towards certain contribution areas.<br />
* Badgeathons<br />
* Hackathons<br />
* FADs<br />
<br />
== Campus Ambassadors ==<br />
To help identify regions and locations that Fedora may have an opportunity to influence, it is helpful to have an idea of what Ambassadors across all regions of Fedora actively have a position of influence in either a university, high school, or other education environment. This is regardless of role, whether as a student or a faculty member. Ambassadors with connections to education institutions are encouraged to fill in their information below.<br />
<br />
= Campus Presence Inventory = <br />
<br />
=== Asia and Pacific (APAC) ===<br />
{|<br />
! FAS Username !! Name !! Institution !! Location !! Role<br />
|-<br />
| [[User:Woohuiren| woohuiren]] || Huiren Woo || [http://np.edu.sg Ngee Ann Polytechnic] || Singapore || Student<br />
|-<br />
| [[User:hardwyrd| Hardwyrd]] || Romar Micabalo || Cagayan de Oro || Philippines || Teacher/coordinator<br />
|-<br />
| [[User:Dhanesh95| Dhanesh95]] || Dhanesh Sabane || [http://zcoer.in/ ZES's ZCOER] || Pune, Maharashtra, India || Student<br />
|-<br />
|}<br />
<br />
=== Europe, Middle East, and Africa (EMEA) ===<br />
{|<br />
! FAS Username !! Name !! Institution !! Location !! Role<br />
|-<br />
| [[User:nmilosev | nmilosev]] || Nemanja Milošević || [https://www.dmi.uns.ac.rs/ University of Novi Sad, Faculty of Science, Department of Mathematics and Informatics] || Novi Sad, RS || MSc Student<br />
|-<br />
| [[User:churchyard | churchyard]] || Miro Hrončok || [https://fit.cvut.cz/en Czech Technical University in Prague, Faculty of Information Technology] || Prague, Czech Republic || MSc Student, Teacher<br />
|-<br />
| [[User:ardian | ardian]] || Ardian Haxha || [https://ubt-uni.net University for Business and Technology] || Pristina, Kosovo || BSc Student<br />
|-<br />
| [[User:jonatoni| jonatoni]] || Jona Azizaj || [http://feut.edu.al/ University of Tirana, Faculty of Economics] || Tirana, Albania || Business Informatics Student<br />
|-<br />
| [[User:germano| germano]] || Germano Massullo || [http://web.uniroma2.it University of Rome Tor Vergata] || Rome, Italy || <br />
|}<br />
<br />
=== Latin America and South America (LATAM) ===<br />
{|<br />
! FAS Username !! Name !! Institution !! Location !! Role<br />
|-<br />
| [[User:Username | username]] || Example Name || [http://www.harvard.edu/ Harvard University] || Cambridge, MA || Student<br />
|}<br />
<br />
=== North America ===<br />
{|<br />
! FAS Username !! Name !! Institution !! Location !! Role<br />
|-<br />
| [[User:Jflory7 | jflory7]] || Justin W. Flory || [https://www.rit.edu/ Rochester Institute of Technology] || Rochester, New York, USA || Student<br />
|-<br />
| [[User:viorel | viorel ]] || Viorel Tabara || [http://www.athabascau.ca/ Athabasca University ] || Athabasca, Alberta, Canada || Staff<br />
|-<br />
|[[User:corey84 | corey84]] || Corey Sheldon || Various Makerspaces || Northern Va, USA || Community Member <br />
|-<br />
|[[User:swilson| swilson]] || Stephen Wilson || Colleges || Mississippi, USA || Ambassador/ Facilitator <br />
|-<br />
|}<br />
<br />
== Objective Lead ==<br />
<br />
[[user:decause|Remy DeCausemaker]]<br />
<br />
== History ==<br />
<br />
Initial council approval: [https://fedorahosted.org/council/ticket/22 April 27, 2015]<br />
<br />
<!-- Original concept art for workflow --><br />
<!-- fedora-council_edu-logic-model.svg --></div>Germanohttps://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package/it&diff=443084How to create an RPM package/it2016-04-13T08:52:23Z<p>Germano: implementare è una deformazione dell'Inglese "to implement" che significa "to make real", quindi "realizzare"</p>
<hr />
<div>{{autolang}}<br />
<br />
== Introduzione ==<br />
<br />
Questa pagina descrive in dettaglio i meccanismi di base su come creare un pacchetto RPM ed in particolare come creare uno SPEC file. A differenza di altre guide su RPM, questa pagina spiega le specifiche per Fedora legate alle linee guida ufficiali. Da quando è mantenuta su Fedora wiki, è probabile che sia più aggornata rispetto ad altre guide. Nonostante tutto, non tutto l'intero documento è applicabile anche ad altre distro basate su RPM. Se "si vogliono stringere i tempi" leggere [[How to create a GNU Hello RPM package]].<br />
<br />
'''Attualmente la Documentazione Fedora ha rilasciato una bozza di guida per i packager: [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide Packagers Guide]'''<br />
<br />
Da notare che questa pagina ''NON'' mostra le '''linee guida''' ufficiali sulla creazione dei pacchetti per Fedora; a questo proposito, il [[Packaging:Committee| Packaging Committee]] gestisce le regole e le linee guida stesse per il packaging in Fedora. Quelle più importanti:<br />
<br />
* [[Packaging:Guidelines| Packaging Guidelines]]<br />
<br />
* [[Packaging:LicensingGuidelines |Licensing Guidelines]]<br />
<br />
* [[Packaging:NamingGuidelines| Package Naming Guidelines]]<br />
<br />
* [[Packaging:DistTag| Dist Tag Guidelines]]<br />
<br />
* [[Packaging:ReviewGuidelines| Package Review Guidelines]]<br />
<br />
* [[Packaging:ScriptletSnippets| Recipes for RPM post scripts]]<br />
<br />
<br />
<br />
'''[[Packaging:Guidelines|Packaging Guidelines]] e [[Packaging:NamingGuidelines|Package Naming Guidelines]] sono le principali. Detto ciò, questa pagina dovrebbe essere compatibile con loro.<br />
<br />
Se si prevede di creare un pacchetto RPM per il repository di Fedora, seguire la procedura [[Join the package collection maintainers|Come diventare manutentori dei pacchetti Fedora Collection]].<br />
<br />
== Impostazione del sistema ==<br />
<br />
Prima di creare pacchetti RPM in Fedora, bisogna installare alcuni strumenti di sviluppo e settare l'account (o gli account) che si userà. Come root (non digitare il '#' !) <br />
<br />
# dnf install @development-tools<br />
# dnf install fedora-packager<br />
# dnf install rpmdevtools<br />
<br />
E' possibile creare un "utente dedicato" appositamente per costruire pacchetti rpm. In questo modo, se qualcosa dovesse andare male, il programma o il processo di costruzione non cancellerà dati personali e non invierà file o chiavi private al mondo esterno.<br />
<br />
{{admon/caution|Non si dovrebbe MAI creare un pacchetto usando l'utente <code>root</code>. Farlo è pericoloso, poiché i file binari vengono installati nel sistema prima di essere impacchettati, quindi bisogna sempre operare come utente normale in modo da non inquinare accidentalmente il proprio sistema.}} <br />
<br />
Creare un nuovo utente chiamato semplicemente "makerpm", aggiungerlo al gruppo 'mock', impostarne la password eseguendo:<br />
# /usr/sbin/useradd makerpm<br />
# usermod -a -G mock makerpm<br />
# passwd makerpm<br />
Poi loggarsi come utente speciale (makerpm).<br />
<br />
Una volta loggatosi, si dovrà creare una struttura nella propria cartella home eseguendo (non digitare il '$'):<br />
$ rpmdev-setuptree<br />
<br />
Il programma "rpm-setuptree" creerà una cartella ~/rpmbuild. All'interno di "rpmbuild" ci sono una serie di sottocartelle (come SPECS e BUILD) che si useranno per creare i propri pacchetti. Sarà inoltre creato il file <code>~/.rpmmacros</code>, usato per impostare opzioni aggiuntive. <br />
<br />
[[Packaging:Guidelines#Timestamps|Le linee guida per il packaging raccomandano l'uso di comandi che preservano il timestamps dei file]]; è possibile farlo automaticamente usando wget o curl per procurarsi i file sorgente.<br />
Se si usa wget assicurarsi di aggiungere il comando "<code>timestamping = on</code>" al file <code>~/.wgetrc</code>. allo stesso modo se si usa curl, nel file <code>~/.curlrc</code> dev'essere presente il testo <code>"-R"</code>.<br />
<br />
Una volta fatto questi passaggi per la creazione dell'account, normalmente non sarà necessario rifarli ancora.<br />
<br />
== Le basi della creazione di pacchetti RPM ==<br />
<br />
Per creare un pacchetto RPM, è necessario creare un file di testo ".spec" che fornisce informazioni sul software che viene pacchettizzato.<br />
<br />
Quindi si esegue il comando "rpmbuild" sul file spec, che completa una serie di passi per produrre il pacchetto.<br />
<br />
Normalmente si opera collocando il sorgente originale (incontaminato), ad esempio un file tar.gz degli sviluppatori originali, in "~ /rpmbuild/SOURCES". Si consiglia di inserire il file .spec in "~/rpmbuild/SPECS" chiamandolo "''NAME''.spec" , dove ''NAME'' è il nome base del pacchetto. Per creare tutti i pacchetti (sia binari che pacchetti sorgenti), si deve passare alla directory "~/rpmbuild/SPECS" ed eseguire:<br />
$ rpmbuild -ba ''NAME''.spec<br />
<br />
Quando viene richiamato in questo modo rpmbuild legge il file .spec e tenta di passare attraverso le seguenti fasi in questo ordine (i nomi che iniziano con <code>%</code> sono macro predefinite come descritto di seguito):<br />
<br />
Alcune directory hanno determinati funzioni per <code>rpmbuild</code> che possono essere sostituiti nel file <code>.spec</code> in base alle macro predefinite (iniziano per <code>%</code>):<br />
<br />
Come si può vedere, alcune directory hanno scopi particolari per <code>rpmbuild</code>. Queste sono:<br />
{|border="1" cellspacing="0"<br />
! Nome della Macro !! Nome !! Predefinito !! Funzione<br />
|-<br />
|<code>%_specdir</code>||Specification directory||<code>~/rpmbuild/SPECS</code>||File SPEC degli RPM (.spec)<br />
|-<br />
|<code>%_sourcedir</code>||Source directory||<code>~/rpmbuild/SOURCES</code>||Pacchetto dei sorgenti incontaminati (es: tarballs) e patch<br />
|-<br />
|<code>%_builddir</code>||Build directory||<code>~/rpmbuild/BUILD</code>||I file sorgente vengono spacchettati e compilati nella sua subdirectory.<br />
|-<br />
|<code>%_buildrootdir</code>||Build root directory||<code>~/rpmbuild/BUILDROOT</code>||I file vengono installati qui durante la fase <code>%install</code>.<br />
|-<br />
|<code>%_rpmdir</code>||Binary RPM directory||<code>~/rpmbuild/RPMS</code>||Binari RPM sono creati e immagazzinati qui sotto.<br />
|-<br />
|<code>%_srcrpmdir</code>||Source RPM directory||<code>~/rpmbuild/SRPMS</code>||Gli RPM sorgente sono creati e immagazzinati qui sotto.<br />
|}<br />
<br />
Per creare i pacchetti binario e sorgente, dalla directory <code>~/rpmbuild/SPECS</code> avviare:<br />
$ rpmbuild -ba ''NAME''.spec<br />
<br />
Quando invocato in questo modo <code>rpmbuild</code> legge il file <code>.spec</code> e segue le seguenti fasi di lavoro:<br />
<br />
{|border="1" cellspacing="0"<br />
! Nome dela Macro !! Nome !! Predefinito !! Funzione<br />
|-<br />
|<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Legge i sorgenti e le patch nella directory <code>%_sourcedir</code>. Questa fase scompatta il sorgente in una sotto-directory inferiore alla directory di build <code>%_builddir</code> (di solito ~/rpmbuild/BUILD/) e applica le patch.<br />
|-<br />
|<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Compila i file nella directory sotto quella di build <code>%_builddir</code>. Di solito si possono realizzare qui alcune variazioni di "<code>./configure && make</code>".<br />
|-<br />
|<code>%check</code>||<code>%_builddir</code>||<code>%_builddir</code>||Verifica che il software funziona propriamente. Fase spesso realizzata per eseguire alcune variazioni di "<code>make test</code>". Molti pacchetti non realizzano questa fase.<br />
|-<br />
|<code>%install</code>||<code>%_builddir</code>||<code>%_buildrootdir</code>||Questa fase legge i file nella directory sotto quella di build <code>%_builddir</code> e scrive in una directory sotto la root build directory <code>%_buildrootdir</code>. I file che sono scritti si suppone che saranno installati quando il pacchetto dei binari viene installato dall'utente finale. Attenzione alla strana terminologia: La directory ''build root'' '''non''' è la stessa della ''build directory''. Questa fase è realizzata da "<code>make install</code>".<br />
|-<br />
|<code>bin</code>||<code>%_buildrootdir</code>||<code>%_rpmdir</code>||Legge la directory sotto la build root directory <code>%_buildrootdir</code> per creare un pacchetto RPM binario sotto la directory RPM <code>%_rpmdir</code>. All'interno della directory RPM vi è una directory per ogni architettura ed una denominata "<code>noarch</code>" per pacchetti che si possono applicare a molte architetture. Questi file RPM sono i pacchetti che gli utenti andranno ad installare.<br />
|-<br />
|<code>src</code>||<code>%_sourcedir</code>||<code>%_srcrpmdir</code>||Questa crea un pacchetto sorgente RPM (<code>.src.rpm</code>) all'interno della directory RPM sorgente <code>%_srcrpmdir</code>. Questi file sono necessari per una revisione e un aggiornamento del pacchetto.<br />
|}<br />
<br />
<!-- Note: The words "in" and "underneath" in the table above have different meanings. Given file /a/b/c, c is "underneath" but not "in" a. --><br />
<br />
Se una fase si interrompe prematuramente, è necessario guardare l'output per capire ''perché'' è fallita, cambiare il file <code>.spec</code> (o altri file di input) a seconda delle necessità.<br />
<br />
== Prepararsi per pacchettizzare un programma in particolare ==<br />
<br />
Se ci sono programmi speciali richiesti per costruire o avviare il programma da pacchettizzare, installarli<br />
e prendere nota di cosa sono (queste informazioni serviranno).<br />
<br />
Per pacchettizzare un programma per i repository Fedora, si devono pacchettizzare i sorgenti incontaminati (originali), insieme a patch e istruzioni di costruzione; ''non'' va bene cominciare con codice precompilato.<br />
Salvare il file con il sorgente originale (solitamente un file <code>.tar.gz</code>) nella cartella "<code>~/rpmbuild/SOURCES</code>" (dell'utente costruttore di rpm).<br />
<br />
Leggere dal manuale le istruzioni d'installazione del programma; si deve rendere automatizzato il tutto editando uno ".spec" file, <br />
quindi capire cosa si deve fare prima.<br />
Probabilmente è meglio fare una prova di compilazione attraverso la procedura di costruzione/installazione senza usare l'RPM per prima (è consigliato specialmente se non si ha dimistichezza con gli rpm).<br />
Con qualche eccezione, tutti i programmi binari e le librerie incluse nei pacchetti Fedora devono essere costruiti dal codice sorgente contenuto nei pacchetti sorgente.<br />
<br />
=== Suddividere il programma ===<br />
<br />
Il codice sorgente delle applicazioni è spesso rilasciato con il codice sorgente di librerie esterne incorporate.<br />
[[Packaging:No_Bundled_Libraries|Non incorporare insieme librerie esterne e applicazione che le usa in un singolo pacchetto]]. Al contrario separarle in più pacchetti.<br />
<br />
=== Licenza ===<br />
<br />
Usare solo software che può essere pacchettizzato legalmente.<br />
<br />
Leggere [[Packaging:Guidelines#Legal]], [[Licensing:Main]] and [[Packaging:LicensingGuidelines]].<br />
In generale, serve ai soli pacchetti software rilasciati come open source software (OSS) con una licenza approvata (così come le GNU GPL, GNU LGPL, BSD-new, MIT/X o Apache 2.0). <br />
Assicurarsi che il software sia realmente licenziato in questo modo (ad esempio controlli casuali del codice sorgente degli header, README file e così via).<br />
Se ci sono pacchetti di librerie, assicurarsi che anch'esse siano OSS.<br />
<br />
=== Riusare informazioni esistenti ===<br />
<br />
Provare a riutilizzare quello che si può. <br />
Ovviamente, assicurarsi che non si stia pacchettizzando qualcosa che già esiste; <br />
nella Fedora Package Collection [https://admin.fedoraproject.org/pkgdb/ Fedora Package Database] c'é una lista dei pacchetti esistenti.<br />
Inoltre controllare la [[PackageMaintainers/InProgressReviewRequests | In Progress Review Requests]] (per pacchetti in fase di revisione)<br />
e la lista [[PackageMaintainers/RetiredPackages | Retired Packages]].<br />
E' possibile usare <br />
[http://pkgs.fedoraproject.org/cgit Fedora Packages Git Repositories]<br />
per vedere direttamente gli .spec file (e patch) di qualsiasi pacchetto esistente in Fedora.<br />
<br />
E' possibile scaricare gli RPM sorgenti usando il DNF download Plugin:<br><br />
$ dnf download --source sourcepackage-name<br />
In alternativa, un rpm sorgente può essere recuperato manualmente visitando la pagina web [http://mirrors.fedoraproject.org/publiclist Fedora mirror] http o ftp,<br />
selezionando la cartella <code>releases/{{FedoraVersion}}/Everything/source/SRPMS</code>. <br />
(rimpiazzare "<code>{{FedoraVersion}}</code>" con la versione di Fedora desiderata),<br />
e scaricare l'rpm sorgente voluto (il nome termina con .src.rpm).<br />
<br />
Ottenuto l'rpm sorgente, installarlo in <code>~/rpmbuild</code>:<br />
$ rpm -ivh sourcepackage-name*.src.rpm<br />
<br />
E' possibile inoltre depacchettizzare il .src.rpm in una directory con <code>rpm2cpio</code>:<br />
$ mkdir PROGRAMNAME_src_rpm<br />
$ cd PROGRAMNAME_src_rpm<br />
$ rpm2cpio ../PROGRAMNAME-*.src.rpm | cpio -i<br />
<br />
''Qualche volta'' è più facile iniziare con un pacchetto esistente, per poi ripulirlo per Fedora;<br />
[http://rpmfind.net/ RPM Find] e [http://pkgs.org PKGS.org] potrebbero aiutare a trovare RPM per sistemi non-Fedora<br />
(si possono installare rpm sorgenti di altri sistemi come in Fedora).<br />
In caso, si potrebbe vedere per pacchetti sorgente (non pacchetti <code>.deb</code> binari) per [http://packages.ubuntu.com/ Ubuntu]<br />
o [http://www.debian.org/distrib/packages Debian] (pacchetti sorgente sono degli standard tarball con una<br />
sottocartella ''<code>debian/</code>'', possibilmente associata con delle patch).<br />
Se [http://www.freebsd.org/ports/installing.html FreeBSD ports collection] dovesse averlo, <br />
si potrebbe [ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz scaricare il FreeBSD ports tarball] <br />
e vedere se le loro informazioni di pacchettizzazione possono aiutare come inizio.<br />
'''Tuttavia''', questo potrebbe non essere di aiuto a tutti.<br />
Differenti distribuzioni hanno differenti regole e quello che fanno potrebbe essere inappropriato per Fedora.<br />
<br />
== Creare un file spec ==<br />
<br />
E' necessario creare ora il file ".spec" nella directory "<code>~/rpmbuild/SPECS</code>".<br />
E' consigliato dare al file il nome del programma (es: "<code>program.spec</code>"). Usare il nome dell'archivio oppure il nome sostenuto dall'autore del programma dove possibile, ma assicurarsi di rispettare le <br />
[[Packaging/NamingGuidelines| Linee guida per il Naming dei pacchetti]].<br />
<br />
=== Modelli ed esempi di SPEC === <br />
==== Modelli ====<br />
<br />
Quando si crea uno .spec file per la prima volta, è possibile usare editor come ''vim'' o ''emacs'' che creeranno automaticamente uno .spec iniziale:<br />
$ cd ~/rpmbuild/SPECS<br />
$ vi program.spec<br />
<br />
Di seguito un esempio di questo template ('''Nota:''' il modello fornito sotto non necessariamente è conforme con le linee guida del Fedora Packaging):<br />
Name: <br />
Version: <br />
Release: 1%{?dist}<br />
Summary: <br />
Group: <br />
License: <br />
URL: <br />
Source0: <br />
<br />
BuildRequires: <br />
Requires: <br />
<br />
%description<br />
<br />
%prep<br />
%autosetup<br />
<br />
%build<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
%install<br />
%make_install<br />
<br />
%files<br />
%doc<br />
%license<br />
<br />
%changelog<br />
<br />
<br />
E' possibile usare <code>$RPM_BUILD_ROOT</code> al posto di <code>%{buildroot}</code>; basta che siano coerenti.<br />
<br />
E' possibile usare il comando <code>rpmdev-newspec</code> per creare un file di .spec . <code>rpmdev-newspec NOME-DEL-NUOVO-PACCHETTO</code> crea un file spec iniziale per un nuovo pacchetto, su misura per vari tipi di pacchetti. Il programma individuerà il tipo di modello da usare dal nome del pacchetto, oppure specificare un particolare tipo di modello. Controllare <code>/etc/rpmdevtools/spectemplate-*.spec</code> per consultare i modelli disponibili e <code>rpmdev-newspec --help</code> per maggiori informazioni. Per esempio, per creare un nuovo file di spec per un modulo python:<br />
<br />
cd ~/rpmbuild/SPECS<br />
rpmdev-newspec python-antigravity<br />
vi python-antigravity.spec<br />
<br />
==== Esempi ====<br />
===== eject =====<br />
<br />
L'esempio di seguito mostra uno .spec per Fedora 16 per il programma <code>eject</code>:<br />
<br />
<pre><br />
Summary: A program that ejects removable media using software control<br />
Name: eject<br />
Version: 2.1.5<br />
Release: 21%{?dist}<br />
License: GPLv2+<br />
Group: System Environment/Base<br />
Source: %{name}-%{version}.tar.gz<br />
Patch1: eject-2.1.1-verbose.patch<br />
Patch2: eject-timeout.patch<br />
Patch3: eject-2.1.5-opendevice.patch<br />
Patch4: eject-2.1.5-spaces.patch<br />
Patch5: eject-2.1.5-lock.patch<br />
Patch6: eject-2.1.5-umount.patch<br />
URL: http://www.pobox.com/~tranter<br />
ExcludeArch: s390 s390x<br />
BuildRequires: gettext<br />
BuildRequires: libtool<br />
<br />
%description<br />
The eject program allows the user to eject removable media (typically<br />
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software<br />
control. Eject can also control some multi-disk CD changers and even<br />
some devices' auto-eject features.<br />
<br />
Install eject if you'd like to eject removable media using software<br />
control.<br />
<br />
%prep<br />
%autosetup -n %{name}<br />
<br />
%build<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
%install<br />
%make_install<br />
<br />
install -m 755 -d %{buildroot}/%{_sbindir}<br />
ln -s ../bin/eject %{buildroot}/%{_sbindir}<br />
<br />
%find_lang %{name}<br />
<br />
%files -f %{name}.lang<br />
%doc README TODO ChangeLog<br />
%license COPYING<br />
%{_bindir}/*<br />
%{_sbindir}/*<br />
%{_mandir}/man1/*<br />
<br />
%changelog<br />
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21<br />
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild<br />
<br />
* Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20<br />
- handle multi-partition devices with spaces in mount points properly (#608502)<br />
</pre><br />
<br />
{{Anchor|Spec_file_pieces_explained}}<br />
<br />
== Panoramica del file SPEC ==<br />
<br />
Altre utili guide: <br />
* La [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html Guida RPM] descrive nei dettagli come riempire uno spec file.<br />
* La serie IBM "Packaging software with RPM" [http://www.ibm.com/developerworks/library/l-rpm1/ Parte 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Parte 2] e [http://www.ibm.com/developerworks/library/l-rpm3 Parte 3] è altrettanto utile.<br />
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM] ha informazioni più complete ma è datata.<br />
<br />
Seguire la linee guida [[Packaging/NamingGuidelines| Package Naming Guidelines]], [[Packaging/Guidelines| Packaging Guidelines]] e [[Packaging/ReviewGuidelines|Package review guidelines]].<br />
<br />
Si possono inserire commenti con il carattere "#", ma<br />
non inserire le potentially-multiline-macros (parole che iniziano con "%") in un commento<br />
(le macro vengono espanse prima); se si decommenta una linea, raddoppiare il segno percentuale ("%%"). Inoltre, non usare "#" sulla stessa linea dopo un comando script.<br />
<br />
I principali tag sono listati di seguito. Notare che le macro <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code> possono essere usate come riferimanto a Nome, Versione e Release rispettivamente. Quando si cambia un tag, la macro automaticamente aggiorna al nuovo valore.<br />
* '''Name''': Il nome del pacchetto, che dovrebbe coincidere con quello dello SPEC file. Deve seguire le [[Packaging/NamingGuidelines|Linee Guida]] e generalmente usa caratteri minuscoli.<br />
* '''Version''': Il numero di versione dall'upstream. Vedere la [[Packaging/NamingGuidelines#Version_Tag|Sezione Version tag]] delle linee guida sulla pacchettizzazione. Se il numero di versione contiene tag non numerici, è necessario includere il carattere non numerico nel tag Release. Se l'upstream usa la data per intero per distinguere le versioni, considerare l'uso di numeri di versione nella forma <code>yy.mm[dd]</code> (ad esempio <code>2008-05-01</code> diventa <code>8.05</code>).<br />
* '''Release''': Il valore iniziale dovrebbe essere <code>1%{?dist}</code>. Incrementare il numero ad ogni nuovo rilascio della stessa versione. Quando arriva un nuovo rilascio, cambiare il tag Version per abbinare e reimpostare in numero Release a <code>1</code>. Controllare la [[Packaging/NamingGuidelines#Release_Tag|sezione Release]] delle linee guida. L'opzionale [[Packaging/DistTag|Dist tag]] potrebbe essere utile.<br />
* '''Summary''': Un breve sommario one-line del pacchetto. Usare l'inglese americano. '''NON finisce con una sola frase'''.<br />
* '''Group''': Necessita di un gruppo preesistente, come "Applications/Engineering"; avviare "<code>less /usr/share/doc/rpm/GROUPS</code>" per conoscere la lista completa. Usare il gruppo "Documentation" per qualsiasi sotto pacchetto (ad esempio <code>kernel-doc</code>) contenente documentazione. '''''Nota: Questo tag è disapprovato a partire da Fedora 17. Vedere [[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html| Introduzione di riferimento Spec File]] '''''<br />
* '''License''': La licenza che deve essere open source. ''Non'' usare vecchi tag Copyright. Usare abbreviazioni standard ("<code>GPLv2+</code>") e specifiche (usare "<code>GPLv2+</code>" per la GPL versione 2 o successive invece del solo "<code>GPL</code>" oppure "<code>GPLv2</code>"). Vedere [[Licensing]] e le [[Packaging/LicensingGuidelines|Licensing Guidelines]]. E' possibile listare più licenze combinandole con "<code>and</code>" e "<code>or</code>" (ad esempio "<code>GPLv2 and BSD</code>").<br />
* '''URL''': L'intero URL per avere maggiori informazioni sul programma (ad esempio il sito del progetto). '''''Nota: Non è un collegamento al codice sorgente originale che invece appare al tag Source0'''''.<br />
* '''Source0''': L'intero URL all'archivio compresso contenente il codice sorgente originale, come rilasciato dall'upstream. "<code>Source</code>" è sinonimo di "<code>Source0</code>". Se si fornisce l'URL completo (come dovrebbe essere), il suo nome verrà utilizzato nella cartella <code>SOURCES</code>. Se possibile, incorporare <code>%{name}</code> e <code>%{version}</code>, così che le modifiche possano andare al posto giusto. [[Packaging:Guidelines#Timestamps|Preservare il timestamps]] quando si scaricano i file sorgente. Se esistono più sorgenti, nominarli <code>Source1</code>, <code>Source2</code> e così via. Se si aggiungono nuovi file, listarli come sorgenti ''dopo'' quelli originali. Una copia di ognuno di questi verrà inclusa in un SRPM, se non diversamente specificato. Vedere [[Packaging/SourceURL|Source URL]] per maggiori informazioni su casi speciali (ad esempio sulla revisione).<br />
* '''Patch0''': Il nome della prima patch da applicare al sorgente. Se serve applicare una patch dopo la decompressione, si dovrebbero editare i file e salvarne le modifiche come "file .patch" nella cartella <code>~/rpmbuild/SOURCES</code>. Le Patch dovrebbero fare una modifica alla volta, quindi è possibile avere più file .patch .<br />
* '''BuildArch''': Se i file da pacchettizzare sono indipendenti dall'architettura (ad esempio shell script, file data), allora aggiungere "<code>BuildArch: noarch</code>". L'architettura per gli RPM binari sarà "<code>noarch</code>".<br />
* '''BuildRoot''': La cartella "d'installazione" durante il processo %install (dopo %build). E'aggiuntivo in Fedora mentre è necessario in EPEL5. Normalmente la root build è in "<code>%{_topdir}/BUILDROOT/</code>".<br />
* '''BuildRequires''': Lista dei pacchetti richiesti per la compilazione del programma. Questo campo può essere (e lo è comunemente) ripetuto su più linee. Queste dipendenze ''non'' sono automaticamente determinate così serve includerle tutte. [[HOWTOFindMissingBuildRequires#Exceptions|Alcuni pacchetti comuni possono essere omessi]], come <code>gcc</code>. E' possibile specificarle in minima parte se necessario (ad esempio "<code>ocaml >= 3.08</code>"). Se serve il file <code>/EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf /EGGS</code>". Se serve il programma <code>EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf `which EGGS`</code>". Mantenere le dipendenze ad un numero minimo (ad esempio usare <code>sed</code> invece di <code>perl</code> se non serve realmente perl), ma attenzione poiché alcune applicazioni disabilitano permanente le funzioni associate a dipendenze mancanti; in questi casi serve includere i pacchetti addizionali. Il pacchetto {{package|auto-buildrequires}} può essere utile.<br />
* '''Requires''': Lista di pacchetti richiesti quando in programma è installato. Notare che il tag BuildRequires lista ciò che serve per la compilazione dell'RPM binario, mentre il tag Requires lista ciò che è necessario per installare e far funzionare il software; un pacchetto può essere presente in entrambe le liste. In molti casi <code>rpmbuild</code> recupera automaticamente le dipendenze quindi il Requires tag non è sempre utile. Tuttavia è possibile evidenziare pacchetti specifici richiesti.<br />
* '''%description''': Una lunga descrizione del programma. Usare l'inglese americano. Tutte le linee devono essere al massimo di 80 caratteri. Le linee vuote indicano un nuovo paragrafo. Alcune interfaccie grafiche d'installazione software riformatteranno i paragrafi; le linee che iniziano con uno spazio vuoto verranno trattate come testo preformattato e visualizzate come sono, normalmente con caratteri fixed-width. Vedere la [http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s03.html Guida RPM].<br />
* '''%prep''': Comandi script per "preparare" il programma (ad esempio decomprimere) così che tutto sia pronto per la compilazione. Tipcamente "<code>%autosetup</code>"; una comune variante è "<code>%autosetup -n NAME</code>" se il file sorgente spacchetta in <code>NAME</code>. Vedere la sezione %prep.<br />
* '''%build''': Comandi script per "costruire" il programma (ad esempio compilare) ed ottenerlo pronto per l'installazione. Incluse le istruzion su come farlo. Vedere la sezione %build.<br />
* '''%check''': Comandi script per "testare" il programma. E' avviato tra le procedure %build e %install, quindi piazzarlo tra le due se serve. Spesso contiene semplicemente "<code>make test</code>" oppure "<code>make check</code>". E' separato da %build così da poter essere saltato a discrezione dell'utente.<br />
* '''%install''': Comandi script per "installare" il programma. I comandi dovrebbero copiare file dalla cartella <code>BUILD</code> <code>%{_builddir}</code> nella buildroot <code>%{buildroot}</code>. Vedere la sezione %install.<br />
* '''%clean''': Istruzioni su come ripulire la build root. Notare che questa sezione è ridondante in Fedora mentre è necessaria per EPEL. Tipicamente contiene solo:<br />
rm -rf %{buildroot} # ridondante eccetto per RHEL 5<br />
* '''%files''': Lista di file che saranno installati. Vedere la sezione %files.<br />
* '''%changelog''': Modifiche nel pacchetto. Usare l'esempio sopra. '''NON inserire il changelog storico del software. Questo riguarda solo quello dell'RPM stesso.'''<br />
* '''ExcludeArch''': Se il pacchetto non compila, costruisce o funziona correttamente in una particolare architettura, listare le architetture coinvolte sotto questo tag.<br />
* E' possibile aggiungere sezioni in modo da avviare codice quando i pacchetti vengono installati o rimossi nel sistema reale (piuttosto che avviare soltanto lo script %install, che opera soltanto una pseudo-installazione nella build root). Queste sono chiamate "scriptlets" e solitamente sono usate per aggiornare il sistema avviato con informazioni dal pacchetto. Vedere la sezione "Scriptlets".<br />
<br />
RPM inoltre supporta la creazione di diversi pacchetti (detti [[How_to_create_an_RPM_package#Subpackages|subpackage]]) da un singolo SPEC file, come <code>name-libs</code> e <code>name-devel</code>.<br />
<br />
{{admon/caution|'''NON''' usare questi tag:<br />
* Packager<br />
* Vendor<br />
* Copyright}}<br />
<br />
'''Non''' creare un pacchetto "ricollocabile"; non valgono in Fedora e sono complicati.<br />
<br />
== Approfondimento sezioni SPEC file ==<br />
=== Sezione %prep ===<br />
La sezione "%prep" descrive come spacchettare gli archivi compressi così da poter iniziare la compilazione.<br />
Di solito include i comandi "%autosetup"; in alternativa di usano i comandi "%setup" e/o "%patch" con riferimenti alle linee Source0:, Source1:, etc.<br />
Vedere la [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html sezione su %setup e %patch in Maximum RPM] per maggiori dettagli.<br />
<br />
Le macro %{patches} e %{sources} sono disponibili da RPM 4.4.2; se si usa una lunga lista di patch o sorgenti ed %autosetup non è vi è utile, è possibile fare qualcosa del genere:<br />
for p in %{patches}; do<br />
...<br />
done<br />
<br />
Tuttavia tener presente che usandole si otterranno .spec file incompatibli con RPM usati in RHEL ed altre distro basate su RPM.<br />
<br />
==== Sezione %prep: comando %autosetup ====<br />
<br />
Il comando "<code>%autosetup</code>" spacchetta i sorgente.<br />
* '''<code>-n</code> ''name''''' : Se il tarball Source decomprime in una directory non nominata come l'RPM, questa opzione può essere usata per specificare il corretto nome. Per esempio, se il file .tar decomprime nella cartella FOO, allora usare "<code>%autosetup -n FOO</code>".<br />
* '''<code>-c</code> ''name''''' : Se il tarball Source in più cartelle invece di una singola, l'opzione può essere usata per crearne una chiamata ''name''.<br />
<br />
Se si usa il comando "<code>%setup</code>" invece, allora l'opzione ''<code>-q</code>'' è comunemente usata per sopprimere gli output non necessari. <br />
<br />
Ci sono [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html più opzioni %setup], utili principalmente se si stanno creando sottopacchetti. <br />
Quelle principali sono:<br />
<br />
{|<br />
|-<br />
| <code>-a number</code> || Decomprime il Source dato dal numero indicato dopo aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0).<br />
|-<br />
| <code>-b number</code> || Decomprime il Source dato dal numero indicato prima aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0).<br />
|-<br />
| <code>-D</code> || Non cancella la cartella dopo la decompressione.<br />
|-<br />
| <code>-T</code> || Disabilita la decompressione automatica dell'archivio.<br />
|}<br />
<br />
==== Sezione %prep: comando %patch ====<br />
<br />
Se è stato usato il comando "<code>%autosetup</code>", le nozioni sotto indicate non servono. <br />
Se si hanno necessità più complesse o di compatibilità con EPEL, allora possono servire.<br />
<br />
Il comando "<code>%patch0</code>" applica Patch0 (e %patch1 applica Patch1 etc.). Le patch sono normali metodi di modifica necessari per "aggiustare" il codice sorgente. Si applica la solita opzione "<code>-pNUMBER</code>" che passa l'argomento al programma <code>patch</code>.<br />
<br />
I file Patch sono nominati spesso come "<code>telnet-0.17-env.patch</code>", nel formato <code>%{name} - %{version} - REASON.patch</code>" (a volte la versione è omessa). I file Patch sono il risultato di "<code>diff -u</code>"; se si fa dalla subdirectory di <code>~/rpmbuild/BUILD</code> allora non è necessario specificare un livello <code>-p</code>.<br />
<br />
Questa è la tipica procedura per creare una patch da un singolo file:<br />
cp foo/bar foo/bar.orig<br />
vim foo/bar<br />
diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch<br />
<br />
Se si editano molti file, un metodo facile è la copia dell'intera subdirectory sotto <code>BUILD</code> per poi avviare il <code>diff</code>. Dopo aver cambiato cartella a "<code>~rpmbuild/BUILD/NAME</code>", allora:<br />
cp -pr ./ ../PACKAGENAME.orig/<br />
... modifiche ...<br />
diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/''NAME''.''REASON''.patch<br />
<br />
Se si modificano più file in una sola patch, è possibile anche copiare quelli originali usando alcune desinenze come "<code>.orig</code>" prima di modificarle. Per poi usare "<code>gendiff</code>" (nel pacchetto <code>rpm-build</code>) per creare una patch con le modifiche.<br />
<br />
Assicurarsi che le patch corrispondano correttamente al contesto. Il valore predefinito "fuzz" è "<code>0</code>". Ci si può lavorare aggiungendo "<code>%global _default_patch_fuzz 2</code>" per ripristinare il valore trovato nelle vecchie versioni dell'RPM in Fedora, ma generalmente è raccomandato evitarlo.<br />
<br />
Come spiegato in [[Packaging/PatchUpstreamStatus]], tutte le patch dovrebbero avere un commento nello .spec file sul loro stato nell'upstream, includendo il bug, la data e la mail. Se è unico si dovrebbe menzionarne il motivo. Il Fedora Project non vuole allontanarsi dagli sviluppi dell'upstream; vedere [[PackageMaintainers/WhyUpstream]].<br />
<br />
==== Sezione %prep: file non modificati ====<br />
<br />
A volte uno o più file del Source non necessitano d'essere decompressi. Si possono "prep" (prepararli) nella cartella build come (dove <code>SOURCE1</code> si riferisce al corrispondente file Source):<br />
cp -p %SOURCE1 .<br />
<br />
=== Sezione %build ===<br />
<br />
La sezione "%build" è qualche volta complicata; in essa si può configurare e compilare/costruire i file che saranno installati.<br />
<br />
Molti programmi seguono la GNU <code>configure</code> (o alcune varianti). Come predefinito, installeranno in un prefix "<code>/usr/local</code>", ragionevolmente per dei file spacchettati. Tuttavia una volta impacchettati, cambia in "<code>/usr</code>". Le librerie dovrebbero essere installate o in <code>/usr/lib</code> oppure in <code>/usr/lib64</code> in base all'architettura.<br />
<br />
Dal momento che GNU <code>configure</code> è così comune, la macro "<code>%configure</code>" può essere usata per invocare automaticamente le corrette opzioni (ad esempio cambiare il prefix a <code>/usr</code>). Alcune sue varianti funzionano spesso:<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
Per sostituire le variabili del makefile, passarle come parametro a <code>make</code>:<br />
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}<br />
<br />
Per maggiori informazioni vedere [http://sourceware.org/autobook/ "GNU autoconf, automake, and libtool"].<br />
<br />
Alcuni programmi usano <code>cmake</code>. Vedi [[Packaging/cmake]].<br />
<br />
=== Sezione %check ===<br />
<br />
Se disponibili dei self-test, è buona idea includerli. Dovrebbero essere piazzati nella sezione %check (che segue la sezione %build) invece che all'interno della %build stessa, così da poter essere facilmente saltati se necessario.<br />
<br />
Spesso questa sezione contiene:<br />
make test<br />
<br />
A volte può essere:<br />
make check<br />
<br />
Osservare il file Makefile per sapere il modo più appropriato.<br />
<br />
=== Sezione %install ===<br />
<br />
Questa sezione coinvolge degli script per "install" (installare) il programma, copiando i file rilevanti da <code>%{_builddir}</code> a <code>%{buildroot}</code> (che solitamente significa da <code>~/rpmbuild/BUILD</code> a <code>~/rpmbuild/BUILDROOT</code>) e creando e cartelle all'interno di <code>%{buildroot}</code>.<br />
<br />
Parte della terminologìa può essere fuorviante:<br />
* La "build directory", anche conosciuta come <code>%{_builddir}</code>, non è la stessa della "build root", conosciuta anche come <code>%{buildroot}</code>. La compilazione avviene nella prima, mentre i file da impacchettare sono copiati dalla prima alla seconda.<br />
* Durante la sezione %build, la cartella di partenza è <code>%{buildsubdir}</code>, sottocartella all'interno di <code>%{_builddir}</code>, creata precedentemente durante il %prep. Di solito è qualcosa del genere <code>~/rpmbuild/BUILD/%{name}-%{version}</code>.<br />
* La sezione %install '''non''' parte quando l'RPM binario è installato dall'utente finale, ma è avviata solo nella creazione del pacchetto.<br />
<br />
Alcune varianti di "<code>make install</code>":<br />
%install<br />
<br />
rm -rf %{buildroot} # ridondante ad eccezione di RHEL5<br />
%make_install<br />
<br />
<br />
Idealmente si dovrebbe usare [http://www.gnu.org/prep/standards/html_node/DESTDIR.html <code>DESTDIR=%{buildroot}</code>] se il programma lo supporta, dato che redirige i file d'installazione alla specifica cartella ed è esattamente ciò che ci si aspetta che faccia durante la sezione %install.<br />
<br />
Se il programma non supporta <code>DESTDIR</code> (e solo se), è possibile in alternativa una delle seguenti strade:<br />
* ''Patchare'' il makefile così che possa supportare <code>DESTDIR</code>. Creare cartelle all'interno di <code>DESTDIR</code> dove necessario e includerne la patch dall' upstream.<br />
* Usare la macro "<code>%makeinstall</code>". Questo metodo potrebbe funzionare, ma può portare a fallimenti. Tramite la macro si arriva a qualcosa del genere "<code>make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install</code>", che in alcuni programmi pu non funzionare. Creare cartelle all'interno di <code>%{buildroot}</code> dove serve.<br />
* Considerare l'uso del pacchetto <code>auto-destdir</code>. Richiede "<code>BuildRequires: auto-destdir</code>" and di cambiare "<code>make install</code>" in "<code>make-redir DESTDIR=%{buildroot} install</code>". Funziona bene se l'installazione usa solo certi comandi comuni per installare i file, come <code>cp</code> e <code>install</code>.<br />
* Installare manualmente. Dovrbbe includere la creazione delle necessarie cartelle sotto <code>%{buildroot}</code> e la copia dei file da <code>%{_builddir}</code> a <code>%{buildroot}</code>. Bisogna essere cauti con gli aggiornamenti, contengono spesso nuovi filename. Un esempio di questa procedura:<br />
%install<br />
rm -rf %{buildroot}<br />
mkdir -p %{buildroot}%{_bindir}/<br />
cp -p mycommand %{buildroot}%{_bindir}/<br />
<br />
=== Sezione %files ===<br />
Questa sezione dichiara i file e le cartelle proprietà del pacchetto quindi incorporati nell'RPM binario.<br />
<br />
==== Nozioni sulla sezione %files ====<br />
<br />
Il <code>%defattr</code> imposta i permessi predefiniti del file e spesso appare all'inizio della sezione <code>%files</code>. Da notare che non è più necessario a meno che non bisogna i permessi. Il formato è:<br />
%defattr(<file permissions>, <user>, <group>, <directory permissions>)<br />
Il quarto parametro è solitamente omesso. Si usa <code>%defattr(-,root,root,-)</code>, dove "<code>-</code>" usa i permessi predefiniti.<br />
<br />
Si dovrebbero poi elencare i file e le cartelle che saranno di proprietà del pacchetto. A tal proposito usare le macro per i nomi delle cartelle, mostrate in [[Packaging:RPMMacros]] (ad esempio usare <code>%{_bindir}/mycommand</code> invece di <code>/usr/bin/mycommand</code>). Se la stringa inizia con "<code>/</code>" (o quando esteso da una macro) allora viene prelevato dalla cartella <code>%{buildroot}</code>. Oppure, si presume che il file sia nella cartella corrente (ad esempio dentro <code>%{_builddir}</code> come per i file di documentazione da includere). Se il pacchetto installa un solo file <code>/usr/sbin/mycommand</code>, la sezione <code>%files</code> può semplicemente essere:<br />
%files<br />
%{_sbindir}/mycommand<br />
<br />
Per ottenere un rpm meno soggetto ai cambiamenti dell'upstream, dichiarare tutti i file all'interno di una cartella di proprietà del pacchetto con la stringa:<br />
%{_bindir}/*<br />
<br />
Per includere una singola cartella:<br />
%{_datadir}/%{name}/<br />
<br />
Notare che <code>%{_bindir}/*</code> non dice che il pacchetto in oggetto sia proprietario della cartella <code>/usr/bin</code>, ma solo dei file contenuti all'interno. Se si elenca una cartella, allora si richiede la proprietà di quella cartella e dei file e sottocartelle contenute. Quindi '''non''' si elenca <code>%{_bindir}</code> assicurardosi anche delle cartelle condivise con altri rpm.<br />
<br />
Si verificheranno errori se:<br />
* una stringa non incontra alcun file o cartella<br />
* file o cartelle sono elencate più volte<br />
* file o cartelle in <code>%{buildroot}</code> non listate<br />
<br />
E' inoltre possibile escludere file usando <code>%exclude</code>. Può aiutare per includere quasi tutti i file da differenti stringhe ma fallirà se non incontra nulla.<br />
<br />
==== %files prefix ====<br />
Potrebbe essere necessario aggiungere uno o più prefissi alle linee della sezione <code>%files</code>; separate da uno spazio. Vedi [http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html Max RPM section on %files directives].<br />
<br />
Solitamente "<code>%doc</code>" è usato per elencare file di documentazione dentro <code>%{_builddir}</code> che non sono stati copiati in <code>%{buildroot}</code>. I file <code>README</code> e <code>INSTALL</code> sono di solito inclusi. Saranno piazzati nella cartella <code>/usr/share/doc</code>, la cui proprietà non ha bisogna d'essere dichiarata.<br />
<br />
'''Nota:''' Se si specifica una voce <code>%doc</code>, rpmbuild < 4.9.1 rimuove la cartella doc, nella quale piazza i file prima di installarli. Ciò significa che i file già all'interno, ad esempio installati nella sezione <code>%install</code>, sono rimossi e non finiranno nel pacchetto. Se si vuole installare alcuni file in nella sezione <code>%install</code>, farlo in una cartella temporanea all'interno della build dir (non in build root), ad esempio <code>_docs_staging</code>, ed includerli nella sezione <code>%files</code> come <code>%doc _docs_staging/*</code>.<br />
<br />
I file di configurazione dovrebbero essere posti in <code>/etc</code> e sono normalmente specificati così (che preserva le modifiche durante gli aggiornamenti):<br />
%config(noreplace) %{_sysconfdir}/foo.conf<br />
Se l'aggiornamento usa un formato di configurazione non-retrocompatibile, specificarli così:<br />
%config %{_sysconfdir}/foo.conf<br />
<br />
"<code>%attr(mode, user, group)</code>" può essere usato per controlli più precisi sui permessi, dove "<code>-</code>" significa usare il predefinito:<br />
%attr(0644, root, root) FOO.BAR<br />
<br />
"<code>%caps(capabilities)</code>" può essere usato per dare certe [http://linux.die.net/man/7/capabilities capacità] POSIX ad un file. Ad esempio:<br />
<br />
%caps(cap_net_admin=pe) FOO.BAR<br />
<br />
Se un file è in lingua naturale, usare <code>%lang</code> per annotarlo:<br />
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*<br />
<br />
I programmi che utilizzano file di localizzazione dovrebbero seguire i [[Packaging:Guidelines#Handling_Locale_Files|metodi raccomandati per gestire i file i18n]]:<br />
<br />
* trovare i filename nel passaggio <code>%install</code>: <code> %find_lang ${name}</code><br />
* aggiungere le dipendenze per la costruzione richieste: <code>BuildRequires: gettext</code><br />
* usare i filename trovati: <code>%files -f ${name}.lang</code><br />
<br />
<code>%readme</code> '''non''' è valido in Fedora.<br />
<br />
==== %files e Filesystem Hierarchy Standard (FHS) ====<br />
<br />
Riferimento a [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)].<br />
<br />
Gli eseguibili vanno in <code>/usr/bin</code>, i file di configurazione globali vanno in <code>/etc</code>, le librerie in <code>/usr/lib</code> (o <code>/usr/lib64</code>) e così via. C'é un'eccezione: eseguibili non eseguiti normalmente direttamente dall'utente o dall'amministratore dovrebbero andare nella sottocartella di <code>/usr/libexec</code>, denominata con <code>%{_libexecdir}/%{name}</code>.<br />
<br />
'''Non''' installare file in <code>/opt</code> o in <code>/usr/local</code>.<br />
<br />
Sfortunatamente molt programmi non rispettano la FHS. In particolare, librerie indipendenti dall'architettura vengono inserite in <code>/usr/lib</code> invece di <code>/usr/share</code>. Il primo è per librerie diendenti dall'architettura, mentre il secondo è per quelle indipendenti; significa che i sistemi con differenti architetture di CPU possono condividere la <code>/usr/share</code>. Ci sono molte eccezioni in Fedora (Python e Perl), ma Fedora applica queste regole più rigidamente rispetto ad alcune altre distro. <code>rpmlint</code> generalmente segnala se si mette qualcosa di diverso dai file ELF in <code>/usr/lib</code>.<br />
<br />
==== Esempio di %files ====<br />
<br />
Di seguito un esempio di sezione %files:<br />
%files<br />
%doc README<br />
%license LICENSE COPYING<br />
%{_bindir}/*<br />
%{_sbindir}/*<br />
%{_datadir}/%{name}/<br />
%config(noreplace) %{_sysconfdir}/*.conf<br />
<br />
==== Trovare duplicati ====<br />
<br />
Per listare qualsiasi duplicato di un rpm:<br />
cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture<br />
rpm -qlp PACKAGE1.*.rpm | sort > ,1<br />
rpm -qlp PACKAGE2.*.rpm | sort > ,2<br />
comm -12 ,1 ,2<br />
<br />
=== Scriptlet ===<br />
<br />
Quando un utente installa l'rpm, si consigliano alcuni comandi da eseguire. Questo si può ottenere con gli scriptlet. Vedi [[Packaging/ScriptletSnippets]].<br />
<br />
Gli scriptlet si eseguono:<br />
* prima ('''<code>%pre</code>''') o dopo ('''<code>%post</code>''') l'installazione di un pacchetto<br />
* prima ('''<code>%preun</code>''') o dopo ('''<code>%postun</code>''') la disinstallazione di un pacchetto<br />
* all'avvìo ('''<code>%pretrans</code>''') o alla fine ('''<code>%posttrans</code>''') di una transazione<br />
<br />
Per esempio, ogni rpm binario che immagazzina file di librerie condivise in qualsiasi percorso di dynamic linker, deve richiamare <code>ldconfig</code> in <code>%post</code> e <code>%postun</code>. Se il pacchetto ha molti sottopacchetti con librerie, ognuno di essi dovrebbe fare la stessa cosa.<br />
%post -p /sbin/ldconfig<br />
%postun -p /sbin/ldconfig<br />
<br />
Se si esegue un solo comando, l'opzione "<code>-p</code>" avvìa il comando adiacente senza invocare la shell. Tuttavia, per diversi comandi, ometterla e aggiungere tutti i comandi shell.<br />
<br />
Se si avvìa un programma negli scriptlet, qualsiasi richiesta va specificata nella forma "<code>Requires(CONTEXT)</code>" (ad esempio <code>Requires(post)</code>).<br />
<br />
<code>%pre</code>, <code>%post</code>, <code>%preun</code> e <code>%postun</code> forniscono l'argomento <code>$1</code>, che è il numero di pacchetti di questo nome che saranno lasciati nel sistema. Non confrontare per uguaglianza con <code>2</code>, controlla invece se sono meggiori o uguali a <code>2</code>. Per <code>%pretrans</code> e <code>%posttrans</code>, <code>$1</code> è sempre <code>0</code>.<br />
<br />
Per esempio se il pacchetto installa un manuale il quale indice deve essere aggiornato con <code>install-info</code> dal pacchetto <code>info</code>, innanzitutto non è garantita la presenza del pacchetto <code>info</code> senza una sua richiesta specifica e poi non si può fallire completamente se <code>install-info</code> non funziona:<br />
Requires(post): info<br />
Requires(preun): info<br />
...<br />
%post<br />
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :<br />
%preun<br />
if [ $1 = 0 ] ; then<br />
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :<br />
fi<br />
<br />
Esiste un altro problema tecnico relativo all'installazione dei manuali. Il comando <code>install-info</code> aggiornerà la certella delle informazioni, quindi si dovrebbero cancellare le cartelle vuote inutilizzate da %{buildroot} durante la sezione <code>%install</code>:<br />
<br />
rm -f %{buildroot}%{_infodir}/dir<br />
<br />
Un'altra abilità simile agli scriptlet è "trigger", avviabile quando altri pacchetti sono installati o disinstallati. Vedi [http://rpm.org/api/4.4.2.2/triggers.html RPM Triggers].<br />
<br />
=== Macro ===<br />
<br />
La macro è un testo nel formato <code>%{string}</code>. Tipiche macro:<br />
<br />
{|<br />
! Macro !! Estensione tipica !! Significato<br />
|-<br />
| <code>%{_bindir}</code> || <code>/usr/bin</code> || Cartella dei binari: dove gli eseguibili vengono solitamente localizzati.<br />
|-<br />
| <code>%{_builddir}</code> || <code>~/rpmbuild/BUILD</code> || Cartella per il build: i file sono compilati all'interno della sua sottocartella. Vedere <code>%buildsubdir</code>.<br />
|-<br />
| <code>%{buildroot}</code> || <code>~/rpmbuild/BUILDROOT</code> || Build root: dove i file vengono "installati" durante <code>%install</code>, che li copia dalla sottocartella di <code>%{_builddir}</code> a quella di <code>%{buildroot}</code>. (Storicamente, <code>%{buildroot}</code> era in "/var/tmp/".)<br />
|-<br />
| <code>%{buildsubdir}</code> || <code>%{_builddir}/%{name}</code> || Sottocartella build: interna a <code>%{_builddir}</code> dove i file sono compilati durante <code>%build</code>. E' impostata dopo <code>%autosetup</code>.<br />
|-<br />
| <code>%{_datadir}</code> || <code>/usr/share</code> || Cartella condivisa.<br />
|-<br />
| <code>%{_defaultdocdir}</code> || <code>/usr/share/doc</code> || Cartella predefinita della documentazione.<br />
|-<br />
| <code>%{dist}</code> || <code>.fc''NUMBER''</code> || Versione della distro (ad esempio "<code>.fc{{FedoraVersion}}</code>")<br />
|-<br />
| <code>%{fedora}</code> || <code>''NUMBER''</code> || Numero di rilascio di Fedora (e.g. "<code>{{FedoraVersion}}</code>")<br />
|-<br />
| <code>%{_includedir}</code> || <code>/usr/include</code><br />
|-<br />
| <code>%{_infodir}</code> || <code>/usr/share/info</code><br />
|-<br />
| <code>%{_initrddir}</code> || <code>/etc/rc.d/init.d</code><br />
|-<br />
| <code>%{_libdir}</code> || <code>/usr/lib</code><br />
|-<br />
| <code>%{_libexecdir}</code> || <code>/usr/libexec</code><br />
|-<br />
| <code>%{_localstatedir}</code> || <code>/var</code><br />
|-<br />
| <code>%{_mandir}</code> || <code>/usr/share/man</code><br />
|-<br />
| <code>%{name}</code> || || Name of package, set by Name: tag<br />
|-<br />
| <code>%{_sbindir}</code> || <code>/usr/sbin</code><br />
|-<br />
| <code>%{_sharedstatedir}</code> || <code>/var/lib</code><br />
|-<br />
| <code>%{_sysconfdir}</code> || <code>/etc</code><br />
|-<br />
| <code>%{version}</code> || || Versione del pacchetto, impostata tramite il tag Version:<br />
|}<br />
<br />
Se ne può sapere di più sulle macro guardando in <code>/etc/rpm/*</code> e <code>/usr/lib/rpm</code>, specialmente <code>/usr/lib/rpm/macros</code>. Inoltre usare <code>rpm --showrc</code> per saperne i valori che RPM userà per le macro (alterate da <code>rpmrc</code> e i file di configurazione delle macro).<br />
<br />
E' possibile impostare le proprie macro usando %global, ma assicurarsi di definirle prima dell'uso. (Le definizioni possono riferirsi anche ad altre macro.) Per esempio:<br />
%global date 2012-02-08<br />
<br />
Usare l'opzione "<code>-E</code>"di <code>rpmbuild</code> per trovare il valore della macro nello .spec file:<br />
rpmbuild -E '%{_bindir}' myfile.spec<br />
<br />
Vedere anche [[Packaging/RPMMacros]] e [https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s07.html RPM Guide capitolo 9].<br />
<br />
=== Altri tag ===<br />
<br />
In aggiunta ai tag Requires e BuildRequires, esistono questi per il controllo delle dipendenze:<br />
* '''Provides''': lista i nomi dei pacchetti virtuali forniti. Ad esempio, ci potrebbe essere un pacchetto "<code>foo</code>" che esige una particolare funzionalità "bar" da un altro programma. Se esistono parecchi pacchetti che epossono soddisfarla, è possibile specificarli con "<code>Provides: bar</code>" e il pacchetto "<code>foo</code>" può specificare "<code>Requires: bar</code>". Si potrebbero anche usare [http://dailypackage.fedorabook.com/index.php?/archives/6-Wednesday-Why-The-Alternatives-System.html metodi "alternativi"], ma evitare se più utenti hanno necessità differenti, visto che queste impostazioni sono a livello di sistema. Usare "<code>rpm -q --provides PACKAGENAME</code>" per vedere cosa fornisce un determinato pacchetto. Alcuni esempi di pacchetti virtuali in Fedora:<br />
** MTA: Usato per i mail transport agents come sendmail.<br />
** tex(latex): Usato per latex<br />
* '''Obsoletes''': rimuove un altro pacchetto(i) nominato(i) se installato(i). Usare se il nome del pacchetto cambia o se è totalmente rimpiazzato da un differente paccehtto.<br />
* '''Conflicts''': specifica quali altri pacchetti non possono essere installati simultaneamente a quello in oggetto. Evitarlo se possibile. Vedere [[Packaging/Conflicts]].<br />
* '''BuildConflicts''': specifica quali pacchetti non possono essere installati se si costruisce il pacchetto in oggetto. Evitarlo se possibile.<br />
<br />
Per gestire differenti architetture, ci sono due tag:<br />
* '''ExcludeArch''': per escluderne una nella quale la costruzione del pacchetto non avviene. Ad esempio:<br />
ExcludeArch: ppc<br />
* '''ExclusiveArch''': per includere solo quella specificata. Evitarlo se non assolutamente corretto.<br />
Architetture valide sono listate in [[Architectures]].<br />
<br />
=== Subpackage ===<br />
<br />
Uno SPEC file può definire diversi binari. In altre parole, un SRPM con uno SPEC file può risultare in più RPM. Notare che c'é ancora un solo processo di creazione (%prep, %build, %install etc.). Sottopacchetti <code>name-doc</code> e <code>name-devel</code> sono comuni per la documentazionee i file di sviluppo rispettivamente.<br />
<br />
Usare la direttiva <code>%package</code> per iniziare la definizione di un sottopacchetto:<br />
%package subpackage_name<br />
<br />
Dopo ogni direttiva <code>%package</code>, listarne i tag. Dovrebbe almeno includere i tag Summary e Group, oltre a <code>%description subpackage_name</code> e <code>%files subpackage_name</code>:<br />
<br />
Tutto quanto non specificato dal sottopacchetto sarà ereditato dal suo genitore.<br />
<br />
Come predefinito, se il nome del pacchetto è "<code>foo</code>" e quello del sottopacchetto è "<code>bar</code>", allora i nomi risultanti saranno <code>foo-bar</code>". E' possibile evitarlo con l'opzione "<code>-n</code>" (ma servirà usarlo in tutte le altre direttive una volta qui specificato):<br />
%package -n new_subpackage_name<br />
<br />
[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s04.html Leggere la sezione sui sottopacchetti della Guida RPM] per maggiori informazioni.<br />
<br />
=== Condizionali ===<br />
<br />
E' possibile inserire stati di condizione, ad esempio per verificare se si sta creando un binario per una certa architettura:<br />
%ifarch ARCHITECTURE_NAME<br />
versione negata con:<br />
%ifnarch ARCHITECTURE_NAME<br />
o più condizioni generiche:<br />
%if TRUE_OR_FALSE<br />
<br />
C'é una sezione opzionale "<code>%else</code>"; tutte queste vengono chiuse con "<code>%endif</code>".<br />
<br />
=== Linee guida specifiche ===<br />
<br />
Ci sono molte linee guida specifiche che sono di aiuto (ad esempio per i linguaggi di programmazione specifici, per applicazioni, librerie e sistemi di build). Molte di loro sono elencate come parte delle [[Packaging/Guidelines#Application_Specific_Guidelines|Application Specific Guidelines of Packaging/Guidelines]]. Esempi di linee guida:<br />
* [[Packaging:Cmake|Cmake]]<br />
* [[Packaging:Emacs|Emacs]]<br />
<br />
Altre sono:<br />
* Il comando 'SEARCH' di Fedoraproject.org.<br />
* [[PackagingDrafts]]<br />
* [[SIGs|Special Interest Group (SIG)]]<br />
* [http://fedoraproject.org/wiki/Special:PrefixIndex/Packaging Pagine Wiki con prefisso 'Packaging']<br />
<br />
=== Suggerimenti vari ===<br />
<br />
[[Packaging/FrequentlyMadeMistakes]] contiene informazioni sugli errori più comuni commessi. Ci sono anche altre raccomandazioni e trucchi controversi in [[PackageMaintainers/Packaging Tricks]].<br />
<br />
Provare a scrivere i propri .sepc files così da funzonare quando nuove versioni dall'upstream sono pronte, senza nessuna modifica a parte il numero di versione e l'aggiornamento dei sorgenti. Per esempio, se contiene file *.txt con istruzioni d'esecuzione, invece di fare<br />
chmod a-x Filename1.txt Filename2.txt Filename3.txt<br />
considerare comandi come il seguente:<br />
chmod a-x *.txt<br />
<br />
Se si vogliono vedere un sacco di esempi di scriptlet, è possibile mostrarli tutti dai pacchetti installati con:<br />
rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less<br />
<br />
Non cercare di interagire con l'utente; RPM è designato per supportare tante installazioni. Se un'applicazione necessita di mostrare un EULA (End User License Agreement), quest'ultima dev'essere parte dell'esecuzione iniziale e non dell'installazione.<br />
<br />
Non si dovrebbero avviare servizi poiché potrebbero rallentare il tutto. Se si installa uno script init e systemd, considerare l'uso di <code>chkconfig</code> o di <code>systemctl</code> per far sì che gli stessi vengano avviati o arrestati al successivo riavvìo. Prima di disinstallare, si dovrebbe normalmente tentare di fermare i suoi servizi se in esecuzione in quel momento.<br />
<br />
La disinstallazione dovrebbe togliere tutte le modifiche fatte nell'installazione, ma non i file creati dall'utente.<br />
<br />
Normalmente, se ci sono binari eseguibili, i simboli di debugging sono tolti dall'rpm binario normale e piazzati in un sottopacchetto <code>name-debug</code>. Se non dovesse succedere, si può disabilitare la creazione dell'rpm-debug aggiungendo in cima allo .spec file:<br />
%global _enable_debug_package 0<br />
%global debug_package %{nil}<br />
%global __os_install_post /usr/lib/rpm/brp-compress %{nil}<br />
<br />
mentre nella sezione <code>%install</code>:<br />
export DONT_STRIP=1<br />
<br />
Un modo per controllare la versione di Fedora in uno .spec file per i build condizionali è:<br />
%if 0%{?fedora} <= <version><br />
Il <code>?</code> permette il riconoscimento della versione se <code>%fedora</code> non è definito. Fa sì che il risultato finale sia <code>0</code>, pur non interferendo sul risultato se presente un valore per <code>%fedora</code>. (Notare che questo metodo non funziona nelle build "scratch" in Koji, dove <code>%fedora</code> è impostato durante la creazione di un SRPM.)<br />
<br />
Le GUI devono avere una voce desktop così da permetterne l'uso dal menu grafico. Per i file <code>.desktop</code>, vedere [[Packaging/Guidelines#Desktop_files|Fedora packaging guidelines for desktop files]] e [http://standards.freedesktop.org/desktop-entry-spec/latest/ desktop entry spec]. Per le icone in <code>/usr/share/icons</code>, vedere [http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html icon theme spec].<br />
<br />
== Costruzione del pacchetto binario ==<br />
=== Test con rpmlint ===<br />
<br />
Prima di provare a costruire qualsiasi cosa, si dovrebbe eseguire <code>rpmlint</code> sullo spec file:<br />
$ rpmlint program.spec<br />
Troverà molti errori velocemente. Se l'errore riportato non ha molto senso,<br />
ridare lo stesso comando aggiungendo l'opzione "-i" (questo darà maggiori informazioni).<br />
<br />
L'ideale sarebbe quello d'avere il minor numero di errori, ma talvolta rpmlint riporta dei falsi positivi.<br />
Le [http://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint linee guida Fedora packaging] spiega quali sono da ignorare.<br />
<br />
=== Creazione degli RPM dallo spec file ===<br />
<br />
Una volta creato uno spec file, chiamato program.spec, è possibile creare<br />
l'rpm sorgente e l'rpm binario semplicemente avviando: <br />
$ rpmbuild -ba program.spec<br />
Se funziona, i file binari RPM verranno creati nella sottocartella ~/rpmbuild/RPMS/ e l'RPM sorgente in ~/rpmbuild/SRPMS.<br />
<br />
Quando qualcosa va male, è possibile entrare ("cd") nella directory appropriata e vedere cosa contiene.<br />
Se si vogliono saltare i passaggi precedenti, usare l'opzione "--short-circuit"; è utile quando si è avuto un build con successo, ma si ha un errore nella sezione %install. Ad esempio, per reiniziare lo stage %install (saltando i passaggi precedenti):<br />
$ rpmbuild -bi --short-circuit program.spec<br />
Se si vuole creare l'rpm sorgente (.src.rpm), entrare nella cartella SPECS e:<br />
$ rpmbuild -bs program.spec <br />
Verrà creato l'rpm sorgente nella cartella ~/rpmbuild/SRPMS. Creare ''solo'' l'rpm sorgente è abbastanza veloce, poiché non fa altro che associare lo .spec file e i file SOURCES nel .src.rpm . Creare un rpm binario tipicamente prende più tempo perché richiede l'avvìo degli script %prep, %build e %install.<br />
<br />
=== Testare con rpmlint gli RPM creati ===<br />
<br />
Avviato rpmlint sullo spec file, generato l'RPM ''binario'' e generato l'RPM sorgente. rpmlint lavora sugli spec, sugli rpm binari o sorgente, trovando cose differenti in ognuno. E' necessario eliminare o modificare degli "rpmlint warning" prima di rilasciare un pacchetto. [[Common_Rpmlint_issues|Questa pagina]] offre spiegazioni per alcuni dei problemi comuni che potrebbero saltare fuori. <br/><br />
Dalla cartella SPECS:<br />
$ rpmlint ''NAME''.spec ../RPMS/*/''NAME''*.rpm ../SRPMS/''NAME''*.rpm<br />
Generalmente rpmbuild costruisce rpm binari con informazioni di debug, anche questi possono essere sottoposti al test.<br />
<br />
Spostandosi nella cartella "~/rpmbuild/RPMS" poi nella sottocartella denominata dall'architettura (32 o 64 bit)<br />
si troveranno alcuni rpm binari. E' possibile vederne facilmente i file ed i permessi con rpmls<br />
(assicurarsi di trovare ciò che ci si aspetta):<br />
$ rpmls *.rpm<br />
Se corretti, provare ad installarli diventando root:<br />
$ su<br />
# rpm -ivp package1.rpm package2.rpm package3.rpm ...<br />
Per poi testarli, utilizzandoli in differenti modi. Se si decide di usare uno strumento ad interfaccia grafica (GUI), assicurarsi che venga mostrato nel menu (se non lo è, allora qualcosa è sbagliato alla voce .desktop).<br />
<br />
Successivamente è possibile disinstallarli:<br />
# rpm -e package1 package2 package3<br />
<br />
== Mock and Koji ==<br />
<br />
[[Projects/Mock|Mock]] è un potente tool che usa gli SRPM creati per costruire pacchetti binari all'interno di un ambiente appositamente creato. Questo può essere d'aiuto per la rilevazione delle dipendenze tra pacchetti. Se fallisce, potrebbe mancare qualcosa alla voce BuildRequires. Vedere [[Using Mock to test package builds]] per ulteriori info sull'utilizzo di <code>mock</code>; una volta che il proprio account rientra nel gruppo "<code>mock</code>", è possibile avviare comandi come il seguente per eseguire test in locale:<br />
$ mock -r fedora-9-i386 rebuild path_to_source_RPM<br />
<br />
Una volta che Mock ha funzionato correttamente, si può usare Koji (il quale usa Mock) per costruire in<br />
differenti sistemi. [[PackageMaintainers/Join]] e [[PackageMaintainers/UsingKoji]] hanno molte informazioni su Koji.<br />
Una volta settati, si possono eseguire test sul proprio rpm sorgente con differenti sistemi<br />
$ koji build --scratch dist-f9 path_to_source_RPM<br />
Si può sostituire la voce "<code>%fc9</code>" con qualsiasi altra release successiva di Fedora, ma non usare <code>dist-rawhide</code>. Ricordarsi che i valori di <code>%fedora</code>, %fc9, ... non saranno giusti per una scratch build, quindi non funzioneranno se il proprio .spec file fa qualcosa di diverso basato su quei valori.<br />
I build koji possono solo dipendere dai pacchetti che sono attualmente disponibili nei repository TARGET. Quindi non si può usare Koji per costruire per distribuzioni rilasciate se il proprio pacchetto dipende da altri nuovi pacchetti che Bodhi non ha ancora rilasciato.<br />
Se si vuole costruire un pacchetto che non è ancora una versione aggiornata stabile, presentare una richiesta "buildroot override" via Bodhi. Se il pacchetto non è a proprio carico, contattare il/i maintainer. [Prima dell'attuale metodo che prevede una richiesta "buildroot override", si poteva aprire un ticket con rel-eng a https://fedorahosted.org/rel-eng/newticket e chiedere che il pacchetto venisse aggiunto come buildroot override]<br />
<br />
== Strumenti utili ==<br />
<br />
Il pacchetto <code>rpmdevtools</code> fornisce diversi strumenti utili; "<code>rpm -qil rpmdevtools</code>" mostra ciò che verrà installato.<br />
<br />
* <code>rpmdev-bumpspec : dal tag release dello spec file, aggiunge un commento al changelog con la data e la versione del software:</code><br />
$ rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES<br />
<br />
DNF download plugin (dal core DNF plugins) contiene molti strumenti utili:<br />
<br />
* <code>dnf download</code>: scarica il pacchetto sorgente<br />
<br />
$ dnf download --source PACKAGENAME<br />
<br />
Il pacchetto <code>auto-buildrequires</code> ha un paio di buoni strumenti d'aiuto per configurare correttamente la voce BuildRequires. Dopo averlo installato, rimpiazzare "<code>rpmbuild</code>" con "<code>auto-br-rpmbuild</code>" e si vedrà automaticamente generata la lista buildrequires.<br />
<br />
Potrebbe essere utile [http://rust.sourceforge.net/ RUST] (GPL), anche se non crea rpm di adeguata qualità per i repository Fedora. [http://kitenet.net/~joey/code/alien/ Alien] converte pacchetti di diverso formato. Non produce rpm sorgente puliti ma potrebbe essere utile per la conversione di pacchetti esistenti dai quali trarre informazioni preziose.<br />
<br />
Se si ha intenzione di creare un pacchetto RPM per Fedora, assicurarsi di sottoporre il proprio file ad una [https://fedorahosted.org/FedoraReview/ Fedora Review], che aiuta a garantire che ci si attenga alle [https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines Linee-guida sul Packaging].<br />
<br />
Finalmente, [https://github.com/alanfranz/docker-rpm-builder docker-rpm-builder] (APL 2.0) usa [http://www.docker.com Docker] per costruire i pacchetti RPM; mentre l'uso di 'rpmbuild' richiede di lavorare nella stessa distro del target, e 'mock' funziona bene su distribuzioni Fedora/Centos/RHEL per qualsiasi target, '''quest'ultimo strumento lavora con Docker'''.<br />
<br />
Se si preferisce costruire RPM per altre distribuzioni o architetture avendo accesso pubblico ai repository, è possibile usare [https://copr.fedoraproject.org Copr].<br />
<br />
Per firmare il pacchetto, usare <code>rpmsign</code>.<br />
<br />
== Linee guida e regole ==<br />
<br />
Una volta creato il proprio pacchetto, bisogna seguire queste regole e linee guida:<br />
* [[Join the package collection maintainers| How to join the Fedora Package Collection Maintainers]] - Descrive il processo per diventare Fedora package maintainer<br />
* [[Packaging:Guidelines | Packaging Guidelines]]<br />
* [[Packaging:NamingGuidelines| Package Naming Guidelines]] <br />
* [[Packaging:DistTag| Dist Tag Guidelines]] <br />
* [[Packaging:ReviewGuidelines| Package Review Guidelines]]<br />
<br />
Ci sono molte linee guida ufficiali che possono essere d'aiuto in circostanze particolari<br />
(Java programs, OCaml programs, GNOME programs, etc.).<br />
Si può inoltre imparare molto dalle sezioni [[SIGs]] e <br />
[[:Category:Package Maintainers|Package Maintainers]].<br />
[https://fedoraproject.org/wiki/Special:Prefixindex/Packaging Lista delle pagine wiki sul Packaging].<br />
<br />
Inoltre, si potrebbero trovare utili quelle non ufficiali<br />
[https://fedoraproject.org/wiki/Special:Search?ns0=1&search=PackagingDrafts%2F&searchx=Search Packaging Drafts] e [https://fedoraproject.org/wiki/PackagingDrafts Packaging Drafts To Do].<br />
<br />
Si potrebbero trovare spunti da [http://en.opensuse.org/Packaging SuSE],<br />
[http://www.debian.org/doc/debian-policy/ Debian], ma<br />
[http://www.mail-archive.com/distributions@lists.freedesktop.org/msg00156.html ci sono differenze tra le distribuzioni], quindi si presume che non possono essere usate direttamente.<br />
<br />
'''I file .spec creati devono riguardare software opensource come previsto dal [[Legal:Fedora_Project_Contributor_Agreement|FPCA]].'''<br />
<br />
== Mantenimento del pacchetto ==<br />
<br />
Quando il pacchetto viene accettato, dev'essere mantenuto dal maintainer (o dal co-maintainer).<br />
Vedere [[Package update HOWTO]] e [[Package update guidelines]] per maggiori informazioni.<br />
Se si aggiorna a più di una release Fedora, farlo a ritroso nel tempo; ad esempio, release per Fedora N, una volta accettato, Fedora N -1<br />
( il sistema presuppone che versioni successive di Fedora hanno versioni uguali o più aggiornate dei programmi).<br />
<br />
Incoraggiare gli sviluppatori upstream ad usare convenzioni stardard nel rilascio del codice sorgente; questo renderà più facile il packaging del software. Per maggiori informazioni, vedere:<br />
* [http://www.dwheeler.com/essays/releasing-floss-software.html Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation] (sommario veloce)<br />
* [http://www.gnu.org/prep/standards/html_node/Managing-Releases.html GNU Coding Standards release process]<br />
* [http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO]<br />
* [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)]<br />
* [http://offog.org/articles/packaging/ Packaging Unix software]<br />
<br />
== Per maggiori informazioni ==<br />
<br />
La pagina [[:Category:Package Maintainers|Package Maintainers]] è collegata a molte altre pagine utili e<br />
[[Package update HOWTO]] descrive come aggiornare un pacchetto esistente già mantenuto in Fedora.<br />
<br />
Per maggiori informazioni, fuori dal wiki Fedora, vedere:<br />
* [http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-on-fedora/ How to build RPM packages on Fedora] - ripasso veloce<br />
* Packaging software con RPM (developerWorks) [http://www.ibm.com/developerworks/library/l-rpm1/ Part 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Part 2] e [http://www.ibm.com/developerworks/library/l-rpm3.html Part 3]<br />
* Fedora Classroom ha avuto una sessione IRC sul packaging e si può far riferimento al log su https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29<br />
* [http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html Manuale Fedora Packager]<br />
* [http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-package-story/ When Sally met Eddie] - Un semplice testo con pochi dettagli<br />
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM Book] - Molte informazioni complete, ma in alcuni casi obsolete<br />
* [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html RPM Guide, section on creating RPMs] - Ha parecchie buone informazioni leggermente più aggiornate, ma è una bozza<br />
* [http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html Guida per sviluppatori, sezione building RPM]<br />
* [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Creating RPMS slides] da Guru Labs<br />
* [http://freshrpms.net/docs/fight/ La lotta, il mio primo tentativo di fare un'introduzione leggibile sull'rpm building.]<br />
* [http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html RPM Tutorial (Fullhart)]<br />
* [http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf Cambridge RPM tutorial] è una presentazione sulla creazione basilare degli RPM<br />
* [http://en.tldp.org/HOWTO/RPM-HOWTO/index.html] RPM HOWTO: RPM al Minimo di Donnie Barnes<br />
* [http://home.fnal.gov/~dawson/rpms/howto/index.html] RPM HowTo di Dawson<br />
* [http://en.opensuse.org/SUSE_Build_Tutorial SuSE build tutorial] - ma su SuSE, non per Fedora. [http://en.opensuse.org/Build_Service/cross_distribution_package_how_to Cross-distribution package HOWTO] contiene suggerimenti se si fanno rpm per diverse distribuzioni.<br />
* [http://wiki.mandriva.com/en/Development/Howto/RPM Mandriva Rpm HowTo (en)] ([http://www.mandrivaclub.com/xwiki/bin/view/KB/MandrivaRpmHowTo alt]) è un tutorial RPM anche se per Mandriva. Da notare che in Fedora ''non'' si ricomprimono i tarball originali, come Mandriva suggerisce, perché questo avrebbe cambiato le loro hash crittografate.<br />
* [http://linuxshellaccount.blogspot.com/2008/03/creating-your-own-linux-rpms-initial.html Creazione del proprio Linux RPM - Software Building Iniziale] è un'altra introduzione ma fa il punto su "Il processo per costruire RPM è più facile della creazione dei pacchetti per Solaris... Meno passaggi, e l'abilità di aggiungere tutte le informazioni sul software in uno specifico file, fatti per una maggiore essenzialità (più facile da modificare e riprodurre) del sistema di packaging".<br />
* [http://fedoranews.org/alex/tutorial/rpm/ Tutto ciò che bisogna sapere su RPM] (più sull'installazione che sulla creazione)<br />
* The [http://wiki.rpm.org/ rpm.org Wiki] ha alcune informazioni utili, come la [http://wiki.rpm.org/Problems lista dei problemi conosciuti]<br />
<br />
Da notare: il sito [http://rpm5.org/ rpm5.org] ha alcuni documenti ma non dipende da loro; è la casa di un fork di RPM mantenuto da Jeff Johnson. L'RPM usato da Fedora (e da Novell/SuSE) ha invece la sede in [http://www.rpm.org rpm.org].<br><br />
[http://lwn.net/Articles/236029/ lwn.net] contiene un articolo a riguardo.<br />
<br />
[[Category:Package Maintainers]]<br />
[[Category:How to]]<br />
[[Category:Italiano]]<br />
[[Category:Da revisionare]]</div>Germanohttps://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package/it&diff=442737How to create an RPM package/it2016-04-10T10:02:50Z<p>Germano: </p>
<hr />
<div>{{autolang}}<br />
<br />
== Introduzione ==<br />
<br />
Questa pagina descrive in dettaglio i meccanismi di base su come creare un pacchetto RPM ed in particolare come creare uno SPEC file. A differenza di altre guide su RPM, questa pagina spiega le specifiche per Fedora legate alle linee guida ufficiali. Da quando è mantenuta su Fedora wiki, è probabile che sia più aggornata rispetto ad altre guide. Nonostante tutto, non tutto l'intero documento è applicabile anche ad altre distro basate su RPM. Se "si vogliono stringere i tempi" leggere [[How to create a GNU Hello RPM package]].<br />
<br />
'''Attualmente la Documentazione Fedora ha rilasciato una bozza di guida per i packager: [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide Packagers Guide]'''<br />
<br />
Da notare che questa pagina ''NON'' mostra le '''linee guida''' ufficiali sulla creazione dei pacchetti per Fedora; a questo proposito, il [[Packaging:Committee| Packaging Committee]] gestisce le regole e le linee guida stesse per il packaging in Fedora. Quelle più importanti:<br />
<br />
* [[Packaging:Guidelines| Packaging Guidelines]]<br />
<br />
* [[Packaging:LicensingGuidelines |Licensing Guidelines]]<br />
<br />
* [[Packaging:NamingGuidelines| Package Naming Guidelines]]<br />
<br />
* [[Packaging:DistTag| Dist Tag Guidelines]]<br />
<br />
* [[Packaging:ReviewGuidelines| Package Review Guidelines]]<br />
<br />
* [[Packaging:ScriptletSnippets| Recipes for RPM post scripts]]<br />
<br />
<br />
<br />
'''[[Packaging:Guidelines|Packaging Guidelines]] e [[Packaging:NamingGuidelines|Package Naming Guidelines]] sono le principali. Detto ciò, questa pagina dovrebbe essere compatibile con loro.<br />
<br />
Se si prevede di creare un pacchetto RPM per il repository di Fedora, seguire la procedura [[Join the package collection maintainers|Come diventare manutentori dei pacchetti Fedora Collection]].<br />
<br />
== Impostazione del sistema ==<br />
<br />
Prima di creare pacchetti RPM in Fedora, bisogna installare alcuni strumenti di sviluppo e settare l'account (o gli account) che si userà. Come root (non digitare il '#' !) <br />
<br />
# dnf install @development-tools<br />
# dnf install fedora-packager<br />
# dnf install rpmdevtools<br />
<br />
E' possibile creare un "utente dedicato" appositamente per costruire pacchetti rpm. In questo modo, se qualcosa dovesse andare male, il programma o il processo di costruzione non cancellerà dati personali e non invierà file o chiavi private al mondo esterno.<br />
<br />
{{admon/caution|Non si dovrebbe MAI creare un pacchetto usando l'utente <code>root</code>. Farlo è pericoloso, poiché i file binari vengono installati nel sistema prima di essere impacchettati, quindi bisogna sempre operare come utente normale in modo da non inquinare accidentalmente il proprio sistema.}} <br />
<br />
Creare un nuovo utente chiamato semplicemente "makerpm", aggiungerlo al gruppo 'mock', impostarne la password eseguendo:<br />
# /usr/sbin/useradd makerpm<br />
# usermod -a -G mock makerpm<br />
# passwd makerpm<br />
Poi loggarsi come utente speciale (makerpm).<br />
<br />
Una volta loggatosi, si dovrà creare una struttura nella propria cartella home eseguendo (non digitare il '$'):<br />
$ rpmdev-setuptree<br />
<br />
Il programma "rpm-setuptree" creerà una cartella ~/rpmbuild. All'interno di "rpmbuild" ci sono una serie di sottocartelle (come SPECS e BUILD) che si useranno per creare i propri pacchetti. Sarà inoltre creato il file <code>~/.rpmmacros</code>, usato per impostare opzioni aggiuntive. <br />
<br />
[[Packaging:Guidelines#Timestamps|Le linee guida per il packaging raccomandano l'uso di comandi che preservano il timestamps dei file]]; è possibile farlo automaticamente usando wget o curl per procurarsi i file sorgente.<br />
Se si usa wget assicurarsi di aggiungere il comando "<code>timestamping = on</code>" al file <code>~/.wgetrc</code>. allo stesso modo se si usa curl, nel file <code>~/.curlrc</code> dev'essere presente il testo <code>"-R"</code>.<br />
<br />
Una volta fatto questi passaggi per la creazione dell'account, normalmente non sarà necessario rifarli ancora.<br />
<br />
== Le basi della creazione di pacchetti RPM ==<br />
<br />
Per creare un pacchetto RPM, è necessario creare un file di testo ".spec" che fornisce informazioni sul software che viene pacchettizzato.<br />
<br />
Quindi si esegue il comando "rpmbuild" sul file spec, che completa una serie di passi per produrre il pacchetto.<br />
<br />
Normalmente si opera collocando il sorgente originale (incontaminato), ad esempio un file tar.gz degli sviluppatori originali, in "~ /rpmbuild/SOURCES". Si consiglia di inserire il file .spec in "~/rpmbuild/SPECS" chiamandolo "''NAME''.spec" , dove ''NAME'' è il nome base del pacchetto. Per creare tutti i pacchetti (sia binari che pacchetti sorgenti), si deve passare alla directory "~/rpmbuild/SPECS" ed eseguire:<br />
$ rpmbuild -ba ''NAME''.spec<br />
<br />
Quando viene richiamato in questo modo rpmbuild legge il file .spec e tenta di passare attraverso le seguenti fasi in questo ordine (i nomi che iniziano con <code>%</code> sono macro predefinite come descritto di seguito):<br />
<br />
Alcune directory hanno determinati funzioni per <code>rpmbuild</code> che possono essere sostituiti nel file <code>.spec</code> in base alle macro predefinite (iniziano per <code>%</code>):<br />
<br />
Come si può vedere, alcune directory hanno scopi particolari per <code>rpmbuild</code>. Queste sono:<br />
{|border="1" cellspacing="0"<br />
! Nome della Macro !! Nome !! Predefinito !! Funzione<br />
|-<br />
|<code>%_specdir</code>||Specification directory||<code>~/rpmbuild/SPECS</code>||File SPEC degli RPM (.spec)<br />
|-<br />
|<code>%_sourcedir</code>||Source directory||<code>~/rpmbuild/SOURCES</code>||Pacchetto dei sorgenti incontaminati (es: tarballs) e patch<br />
|-<br />
|<code>%_builddir</code>||Build directory||<code>~/rpmbuild/BUILD</code>||I file sorgente vengono spacchettati e compilati nella sua subdirectory.<br />
|-<br />
|<code>%_buildrootdir</code>||Build root directory||<code>~/rpmbuild/BUILDROOT</code>||I file vengono installati qui durante la fase <code>%install</code>.<br />
|-<br />
|<code>%_rpmdir</code>||Binary RPM directory||<code>~/rpmbuild/RPMS</code>||Binari RPM sono creati e immagazzinati qui sotto.<br />
|-<br />
|<code>%_srcrpmdir</code>||Source RPM directory||<code>~/rpmbuild/SRPMS</code>||Gli RPM sorgente sono creati e immagazzinati qui sotto.<br />
|}<br />
<br />
Per creare i pacchetti binario e sorgente, dalla directory <code>~/rpmbuild/SPECS</code> avviare:<br />
$ rpmbuild -ba ''NAME''.spec<br />
<br />
Quando invocato in questo modo <code>rpmbuild</code> legge il file <code>.spec</code> e segue le seguenti fasi di lavoro:<br />
<br />
{|border="1" cellspacing="0"<br />
! Nome dela Macro !! Nome !! Predefinito !! Funzione<br />
|-<br />
|<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Legge i sorgenti e le patch nella directory <code>%_sourcedir</code>. Questa fase scompatta il sorgente in una sotto-directory inferiore alla directory di build <code>%_builddir</code> (di solito ~/rpmbuild/BUILD/) e applica le patch.<br />
|-<br />
|<code>%prep</code>||<code>%_sourcedir</code>||<code>%_builddir</code>||Compila i file nella directory sotto quella di build <code>%_builddir</code>. Di solito si possono implementare qui alcune variazioni di "<code>./configure && make</code>".<br />
|-<br />
|<code>%check</code>||<code>%_builddir</code>||<code>%_builddir</code>||Verifica che il software funziona propriamente. Fase spesso implementata per eseguire alcune variazioni di "<code>make test</code>". Molti pacchetti non implementano questa fase.<br />
|-<br />
|<code>%install</code>||<code>%_builddir</code>||<code>%_buildrootdir</code>||Questa fase legge i file nella directory sotto quella di build <code>%_builddir</code> e scrive in una directory sotto la root build directory <code>%_buildrootdir</code>. I file che sono scritti si suppone che saranno installati quando il pacchetto dei binari viene installato dall'utente finale. Attenzione alla strana terminologia: La directory ''build root'' '''non''' è la stessa della ''build directory''. Questa fase è implementata da "<code>make install</code>".<br />
|-<br />
|<code>bin</code>||<code>%_buildrootdir</code>||<code>%_rpmdir</code>||Legge la directory sotto la build root directory <code>%_buildrootdir</code> per creare un pacchetto RPM binario sotto la directory RPM <code>%_rpmdir</code>. All'interno della directory RPM vi è una directory per ogni architettura ed una denominata "<code>noarch</code>" per pacchetti che si possono applicare a molte architetture. Questi file RPM sono i pacchetti che gli utenti andranno ad installare.<br />
|-<br />
|<code>src</code>||<code>%_sourcedir</code>||<code>%_srcrpmdir</code>||Questa crea un pacchetto sorgente RPM (<code>.src.rpm</code>) all'interno della directory RPM sorgente <code>%_srcrpmdir</code>. Questi file sono necessari per una revisione e un aggiornamento del pacchetto.<br />
|}<br />
<br />
<!-- Note: The words "in" and "underneath" in the table above have different meanings. Given file /a/b/c, c is "underneath" but not "in" a. --><br />
<br />
Se una fase si interrompe prematuramente, è necessario guardare l'output per capire ''perché'' è fallita, cambiare il file <code>.spec</code> (o altri file di input) a seconda delle necessità.<br />
<br />
== Prepararsi per pacchettizzare un programma in particolare ==<br />
<br />
Se ci sono programmi speciali richiesti per costruire o avviare il programma da pacchettizzare, installarli<br />
e prendere nota di cosa sono (queste informazioni serviranno).<br />
<br />
Per pacchettizzare un programma per i repository Fedora, si devono pacchettizzare i sorgenti incontaminati (originali), insieme a patch e istruzioni di costruzione; ''non'' va bene cominciare con codice precompilato.<br />
Salvare il file con il sorgente originale (solitamente un file <code>.tar.gz</code>) nella cartella "<code>~/rpmbuild/SOURCES</code>" (dell'utente costruttore di rpm).<br />
<br />
Leggere dal manuale le istruzioni d'installazione del programma; si deve rendere automatizzato il tutto editando uno ".spec" file, <br />
quindi capire cosa si deve fare prima.<br />
Probabilmente è meglio fare una prova di compilazione attraverso la procedura di costruzione/installazione senza usare l'RPM per prima (è consigliato specialmente se non si ha dimistichezza con gli rpm).<br />
Con qualche eccezione, tutti i programmi binari e le librerie incluse nei pacchetti Fedora devono essere costruiti dal codice sorgente contenuto nei pacchetti sorgente.<br />
<br />
=== Suddividere il programma ===<br />
<br />
Il codice sorgente delle applicazioni è spesso rilasciato con il codice sorgente di librerie esterne incorporate.<br />
[[Packaging:No_Bundled_Libraries|Non incorporare insieme librerie esterne e applicazione che le usa in un singolo pacchetto]]. Al contrario separarle in più pacchetti.<br />
<br />
=== Licenza ===<br />
<br />
Usare solo software che può essere pacchettizzato legalmente.<br />
<br />
Leggere [[Packaging:Guidelines#Legal]], [[Licensing:Main]] and [[Packaging:LicensingGuidelines]].<br />
In generale, serve ai soli pacchetti software rilasciati come open source software (OSS) con una licenza approvata (così come le GNU GPL, GNU LGPL, BSD-new, MIT/X o Apache 2.0). <br />
Assicurarsi che il software sia realmente licenziato in questo modo (ad esempio controlli casuali del codice sorgente degli header, README file e così via).<br />
Se ci sono pacchetti di librerie, assicurarsi che anch'esse siano OSS.<br />
<br />
=== Riusare informazioni esistenti ===<br />
<br />
Provare a riutilizzare quello che si può. <br />
Ovviamente, assicurarsi che non si stia pacchettizzando qualcosa che già esiste; <br />
nella Fedora Package Collection [https://admin.fedoraproject.org/pkgdb/ Fedora Package Database] c'é una lista dei pacchetti esistenti.<br />
Inoltre controllare la [[PackageMaintainers/InProgressReviewRequests | In Progress Review Requests]] (per pacchetti in fase di revisione)<br />
e la lista [[PackageMaintainers/RetiredPackages | Retired Packages]].<br />
E' possibile usare <br />
[http://pkgs.fedoraproject.org/cgit Fedora Packages Git Repositories]<br />
per vedere direttamente gli .spec file (e patch) di qualsiasi pacchetto esistente in Fedora.<br />
<br />
E' possibile scaricare gli RPM sorgenti usando il DNF download Plugin:<br><br />
$ dnf download --source sourcepackage-name<br />
In alternativa, un rpm sorgente può essere recuperato manualmente visitando la pagina web [http://mirrors.fedoraproject.org/publiclist Fedora mirror] http o ftp,<br />
selezionando la cartella <code>releases/{{FedoraVersion}}/Everything/source/SRPMS</code>. <br />
(rimpiazzare "<code>{{FedoraVersion}}</code>" con la versione di Fedora desiderata),<br />
e scaricare l'rpm sorgente voluto (il nome termina con .src.rpm).<br />
<br />
Ottenuto l'rpm sorgente, installarlo in <code>~/rpmbuild</code>:<br />
$ rpm -ivh sourcepackage-name*.src.rpm<br />
<br />
E' possibile inoltre depacchettizzare il .src.rpm in una directory con <code>rpm2cpio</code>:<br />
$ mkdir PROGRAMNAME_src_rpm<br />
$ cd PROGRAMNAME_src_rpm<br />
$ rpm2cpio ../PROGRAMNAME-*.src.rpm | cpio -i<br />
<br />
''Qualche volta'' è più facile iniziare con un pacchetto esistente, per poi ripulirlo per Fedora;<br />
[http://rpmfind.net/ RPM Find] e [http://pkgs.org PKGS.org] potrebbero aiutare a trovare RPM per sistemi non-Fedora<br />
(si possono installare rpm sorgenti di altri sistemi come in Fedora).<br />
In caso, si potrebbe vedere per pacchetti sorgente (non pacchetti <code>.deb</code> binari) per [http://packages.ubuntu.com/ Ubuntu]<br />
o [http://www.debian.org/distrib/packages Debian] (pacchetti sorgente sono degli standard tarball con una<br />
sottocartella ''<code>debian/</code>'', possibilmente associata con delle patch).<br />
Se [http://www.freebsd.org/ports/installing.html FreeBSD ports collection] dovesse averlo, <br />
si potrebbe [ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz scaricare il FreeBSD ports tarball] <br />
e vedere se le loro informazioni di pacchettizzazione possono aiutare come inizio.<br />
'''Tuttavia''', questo potrebbe non essere di aiuto a tutti.<br />
Differenti distribuzioni hanno differenti regole e quello che fanno potrebbe essere inappropriato per Fedora.<br />
<br />
== Creare un file spec ==<br />
<br />
E' necessario creare ora il file ".spec" nella directory "<code>~/rpmbuild/SPECS</code>".<br />
E' consigliato dare al file il nome del programma (es: "<code>program.spec</code>"). Usare il nome dell'archivio oppure il nome sostenuto dall'autore del programma dove possibile, ma assicurarsi di rispettare le <br />
[[Packaging/NamingGuidelines| Linee guida per il Naming dei pacchetti]].<br />
<br />
=== Modelli ed esempi di SPEC === <br />
==== Modelli ====<br />
<br />
Quando si crea uno .spec file per la prima volta, è possibile usare editor come ''vim'' o ''emacs'' che creeranno automaticamente uno .spec iniziale:<br />
$ cd ~/rpmbuild/SPECS<br />
$ vi program.spec<br />
<br />
Di seguito un esempio di questo template ('''Nota:''' il modello fornito sotto non necessariamente è conforme con le linee guida del Fedora Packaging):<br />
Name: <br />
Version: <br />
Release: 1%{?dist}<br />
Summary: <br />
Group: <br />
License: <br />
URL: <br />
Source0: <br />
<br />
BuildRequires: <br />
Requires: <br />
<br />
%description<br />
<br />
%prep<br />
%autosetup<br />
<br />
%build<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
%install<br />
%make_install<br />
<br />
%files<br />
%doc<br />
%license<br />
<br />
%changelog<br />
<br />
<br />
E' possibile usare <code>$RPM_BUILD_ROOT</code> al posto di <code>%{buildroot}</code>; basta che siano coerenti.<br />
<br />
E' possibile usare il comando <code>rpmdev-newspec</code> per creare un file di .spec . <code>rpmdev-newspec NOME-DEL-NUOVO-PACCHETTO</code> crea un file spec iniziale per un nuovo pacchetto, su misura per vari tipi di pacchetti. Il programma individuerà il tipo di modello da usare dal nome del pacchetto, oppure specificare un particolare tipo di modello. Controllare <code>/etc/rpmdevtools/spectemplate-*.spec</code> per consultare i modelli disponibili e <code>rpmdev-newspec --help</code> per maggiori informazioni. Per esempio, per creare un nuovo file di spec per un modulo python:<br />
<br />
cd ~/rpmbuild/SPECS<br />
rpmdev-newspec python-antigravity<br />
vi python-antigravity.spec<br />
<br />
==== Esempi ====<br />
===== eject =====<br />
<br />
L'esempio di seguito mostra uno .spec per Fedora 16 per il programma <code>eject</code>:<br />
<br />
<pre><br />
Summary: A program that ejects removable media using software control<br />
Name: eject<br />
Version: 2.1.5<br />
Release: 21%{?dist}<br />
License: GPLv2+<br />
Group: System Environment/Base<br />
Source: %{name}-%{version}.tar.gz<br />
Patch1: eject-2.1.1-verbose.patch<br />
Patch2: eject-timeout.patch<br />
Patch3: eject-2.1.5-opendevice.patch<br />
Patch4: eject-2.1.5-spaces.patch<br />
Patch5: eject-2.1.5-lock.patch<br />
Patch6: eject-2.1.5-umount.patch<br />
URL: http://www.pobox.com/~tranter<br />
ExcludeArch: s390 s390x<br />
BuildRequires: gettext<br />
BuildRequires: libtool<br />
<br />
%description<br />
The eject program allows the user to eject removable media (typically<br />
CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software<br />
control. Eject can also control some multi-disk CD changers and even<br />
some devices' auto-eject features.<br />
<br />
Install eject if you'd like to eject removable media using software<br />
control.<br />
<br />
%prep<br />
%autosetup -n %{name}<br />
<br />
%build<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
%install<br />
%make_install<br />
<br />
install -m 755 -d %{buildroot}/%{_sbindir}<br />
ln -s ../bin/eject %{buildroot}/%{_sbindir}<br />
<br />
%find_lang %{name}<br />
<br />
%files -f %{name}.lang<br />
%doc README TODO ChangeLog<br />
%license COPYING<br />
%{_bindir}/*<br />
%{_sbindir}/*<br />
%{_mandir}/man1/*<br />
<br />
%changelog<br />
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 2.1.5-21<br />
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild<br />
<br />
* Fri Jul 02 2010 Kamil Dudka <kdudka@redhat.com> 2.1.5-20<br />
- handle multi-partition devices with spaces in mount points properly (#608502)<br />
</pre><br />
<br />
{{Anchor|Spec_file_pieces_explained}}<br />
<br />
== Panoramica del file SPEC ==<br />
<br />
Altre utili guide: <br />
* La [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html Guida RPM] descrive nei dettagli come riempire uno spec file.<br />
* La serie IBM "Packaging software with RPM" [http://www.ibm.com/developerworks/library/l-rpm1/ Parte 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Parte 2] e [http://www.ibm.com/developerworks/library/l-rpm3 Parte 3] è altrettanto utile.<br />
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM] ha informazioni più complete ma è datata.<br />
<br />
Seguire la linee guida [[Packaging/NamingGuidelines| Package Naming Guidelines]], [[Packaging/Guidelines| Packaging Guidelines]] e [[Packaging/ReviewGuidelines|Package review guidelines]].<br />
<br />
Si possono inserire commenti con il carattere "#", ma<br />
non inserire le potentially-multiline-macros (parole che iniziano con "%") in un commento<br />
(le macro vengono espanse prima); se si decommenta una linea, raddoppiare il segno percentuale ("%%"). Inoltre, non usare "#" sulla stessa linea dopo un comando script.<br />
<br />
I principali tag sono listati di seguito. Notare che le macro <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code> possono essere usate come riferimanto a Nome, Versione e Release rispettivamente. Quando si cambia un tag, la macro automaticamente aggiorna al nuovo valore.<br />
* '''Name''': Il nome del pacchetto, che dovrebbe coincidere con quello dello SPEC file. Deve seguire le [[Packaging/NamingGuidelines|Linee Guida]] e generalmente usa caratteri minuscoli.<br />
* '''Version''': Il numero di versione dall'upstream. Vedere la [[Packaging/NamingGuidelines#Version_Tag|Sezione Version tag]] delle linee guida sulla pacchettizzazione. Se il numero di versione contiene tag non numerici, è necessario includere il carattere non numerico nel tag Release. Se l'upstream usa la data per intero per distinguere le versioni, considerare l'uso di numeri di versione nella forma <code>yy.mm[dd]</code> (ad esempio <code>2008-05-01</code> diventa <code>8.05</code>).<br />
* '''Release''': Il valore iniziale dovrebbe essere <code>1%{?dist}</code>. Incrementare il numero ad ogni nuovo rilascio della stessa versione. Quando arriva un nuovo rilascio, cambiare il tag Version per abbinare e reimpostare in numero Release a <code>1</code>. Controllare la [[Packaging/NamingGuidelines#Release_Tag|sezione Release]] delle linee guida. L'opzionale [[Packaging/DistTag|Dist tag]] potrebbe essere utile.<br />
* '''Summary''': Un breve sommario one-line del pacchetto. Usare l'inglese americano. '''NON finisce con una sola frase'''.<br />
* '''Group''': Necessita di un gruppo preesistente, come "Applications/Engineering"; avviare "<code>less /usr/share/doc/rpm/GROUPS</code>" per conoscere la lista completa. Usare il gruppo "Documentation" per qualsiasi sotto pacchetto (ad esempio <code>kernel-doc</code>) contenente documentazione. '''''Nota: Questo tag è disapprovato a partire da Fedora 17. Vedere [[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html| Introduzione di riferimento Spec File]] '''''<br />
* '''License''': La licenza che deve essere open source. ''Non'' usare vecchi tag Copyright. Usare abbreviazioni standard ("<code>GPLv2+</code>") e specifiche (usare "<code>GPLv2+</code>" per la GPL versione 2 o successive invece del solo "<code>GPL</code>" oppure "<code>GPLv2</code>"). Vedere [[Licensing]] e le [[Packaging/LicensingGuidelines|Licensing Guidelines]]. E' possibile listare più licenze combinandole con "<code>and</code>" e "<code>or</code>" (ad esempio "<code>GPLv2 and BSD</code>").<br />
* '''URL''': L'intero URL per avere maggiori informazioni sul programma (ad esempio il sito del progetto). '''''Nota: Non è un collegamento al codice sorgente originale che invece appare al tag Source0'''''.<br />
* '''Source0''': L'intero URL all'archivio compresso contenente il codice sorgente originale, come rilasciato dall'upstream. "<code>Source</code>" è sinonimo di "<code>Source0</code>". Se si fornisce l'URL completo (come dovrebbe essere), il suo nome verrà utilizzato nella cartella <code>SOURCES</code>. Se possibile, incorporare <code>%{name}</code> e <code>%{version}</code>, così che le modifiche possano andare al posto giusto. [[Packaging:Guidelines#Timestamps|Preservare il timestamps]] quando si scaricano i file sorgente. Se esistono più sorgenti, nominarli <code>Source1</code>, <code>Source2</code> e così via. Se si aggiungono nuovi file, listarli come sorgenti ''dopo'' quelli originali. Una copia di ognuno di questi verrà inclusa in un SRPM, se non diversamente specificato. Vedere [[Packaging/SourceURL|Source URL]] per maggiori informazioni su casi speciali (ad esempio sulla revisione).<br />
* '''Patch0''': Il nome della prima patch da applicare al sorgente. Se serve applicare una patch dopo la decompressione, si dovrebbero editare i file e salvarne le modifiche come "file .patch" nella cartella <code>~/rpmbuild/SOURCES</code>. Le Patch dovrebbero fare una modifica alla volta, quindi è possibile avere più file .patch .<br />
* '''BuildArch''': Se i file da pacchettizzare sono indipendenti dall'architettura (ad esempio shell script, file data), allora aggiungere "<code>BuildArch: noarch</code>". L'architettura per gli RPM binari sarà "<code>noarch</code>".<br />
* '''BuildRoot''': La cartella "d'installazione" durante il processo %install (dopo %build). E'aggiuntivo in Fedora mentre è necessario in EPEL5. Normalmente la root build è in "<code>%{_topdir}/BUILDROOT/</code>".<br />
* '''BuildRequires''': Lista dei pacchetti richiesti per la compilazione del programma. Questo campo può essere (e lo è comunemente) ripetuto su più linee. Queste dipendenze ''non'' sono automaticamente determinate così serve includerle tutte. [[HOWTOFindMissingBuildRequires#Exceptions|Alcuni pacchetti comuni possono essere omessi]], come <code>gcc</code>. E' possibile specificarle in minima parte se necessario (ad esempio "<code>ocaml >= 3.08</code>"). Se serve il file <code>/EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf /EGGS</code>". Se serve il programma <code>EGGS</code>, determinarne il pacchetto che lo possiede con "<code>rpm -qf `which EGGS`</code>". Mantenere le dipendenze ad un numero minimo (ad esempio usare <code>sed</code> invece di <code>perl</code> se non serve realmente perl), ma attenzione poiché alcune applicazioni disabilitano permanente le funzioni associate a dipendenze mancanti; in questi casi serve includere i pacchetti addizionali. Il pacchetto {{package|auto-buildrequires}} può essere utile.<br />
* '''Requires''': Lista di pacchetti richiesti quando in programma è installato. Notare che il tag BuildRequires lista ciò che serve per la compilazione dell'RPM binario, mentre il tag Requires lista ciò che è necessario per installare e far funzionare il software; un pacchetto può essere presente in entrambe le liste. In molti casi <code>rpmbuild</code> recupera automaticamente le dipendenze quindi il Requires tag non è sempre utile. Tuttavia è possibile evidenziare pacchetti specifici richiesti.<br />
* '''%description''': Una lunga descrizione del programma. Usare l'inglese americano. Tutte le linee devono essere al massimo di 80 caratteri. Le linee vuote indicano un nuovo paragrafo. Alcune interfaccie grafiche d'installazione software riformatteranno i paragrafi; le linee che iniziano con uno spazio vuoto verranno trattate come testo preformattato e visualizzate come sono, normalmente con caratteri fixed-width. Vedere la [http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s03.html Guida RPM].<br />
* '''%prep''': Comandi script per "preparare" il programma (ad esempio decomprimere) così che tutto sia pronto per la compilazione. Tipcamente "<code>%autosetup</code>"; una comune variante è "<code>%autosetup -n NAME</code>" se il file sorgente spacchetta in <code>NAME</code>. Vedere la sezione %prep.<br />
* '''%build''': Comandi script per "costruire" il programma (ad esempio compilare) ed ottenerlo pronto per l'installazione. Incluse le istruzion su come farlo. Vedere la sezione %build.<br />
* '''%check''': Comandi script per "testare" il programma. E' avviato tra le procedure %build e %install, quindi piazzarlo tra le due se serve. Spesso contiene semplicemente "<code>make test</code>" oppure "<code>make check</code>". E' separato da %build così da poter essere saltato a discrezione dell'utente.<br />
* '''%install''': Comandi script per "installare" il programma. I comandi dovrebbero copiare file dalla cartella <code>BUILD</code> <code>%{_builddir}</code> nella buildroot <code>%{buildroot}</code>. Vedere la sezione %install.<br />
* '''%clean''': Istruzioni su come ripulire la build root. Notare che questa sezione è ridondante in Fedora mentre è necessaria per EPEL. Tipicamente contiene solo:<br />
rm -rf %{buildroot} # ridondante eccetto per RHEL 5<br />
* '''%files''': Lista di file che saranno installati. Vedere la sezione %files.<br />
* '''%changelog''': Modifiche nel pacchetto. Usare l'esempio sopra. '''NON inserire il changelog storico del software. Questo riguarda solo quello dell'RPM stesso.'''<br />
* '''ExcludeArch''': Se il pacchetto non compila, costruisce o funziona correttamente in una particolare architettura, listare le architetture coinvolte sotto questo tag.<br />
* E' possibile aggiungere sezioni in modo da avviare codice quando i pacchetti vengono installati o rimossi nel sistema reale (piuttosto che avviare soltanto lo script %install, che opera soltanto una pseudo-installazione nella build root). Queste sono chiamate "scriptlets" e solitamente sono usate per aggiornare il sistema avviato con informazioni dal pacchetto. Vedere la sezione "Scriptlets".<br />
<br />
RPM inoltre supporta la creazione di diversi pacchetti (detti [[How_to_create_an_RPM_package#Subpackages|subpackage]]) da un singolo SPEC file, come <code>name-libs</code> e <code>name-devel</code>.<br />
<br />
{{admon/caution|'''NON''' usare questi tag:<br />
* Packager<br />
* Vendor<br />
* Copyright}}<br />
<br />
'''Non''' creare un pacchetto "ricollocabile"; non valgono in Fedora e sono complicati.<br />
<br />
== Approfondimento sezioni SPEC file ==<br />
=== Sezione %prep ===<br />
La sezione "%prep" descrive come spacchettare gli archivi compressi così da poter iniziare la compilazione.<br />
Di solito include i comandi "%autosetup"; in alternativa di usano i comandi "%setup" e/o "%patch" con riferimenti alle linee Source0:, Source1:, etc.<br />
Vedere la [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html sezione su %setup e %patch in Maximum RPM] per maggiori dettagli.<br />
<br />
Le macro %{patches} e %{sources} sono disponibili da RPM 4.4.2; se si usa una lunga lista di patch o sorgenti ed %autosetup non è vi è utile, è possibile fare qualcosa del genere:<br />
for p in %{patches}; do<br />
...<br />
done<br />
<br />
Tuttavia tener presente che usandole si otterranno .spec file incompatibli con RPM usati in RHEL ed altre distro basate su RPM.<br />
<br />
==== Sezione %prep: comando %autosetup ====<br />
<br />
Il comando "<code>%autosetup</code>" spacchetta i sorgente.<br />
* '''<code>-n</code> ''name''''' : Se il tarball Source decomprime in una directory non nominata come l'RPM, questa opzione può essere usata per specificare il corretto nome. Per esempio, se il file .tar decomprime nella cartella FOO, allora usare "<code>%autosetup -n FOO</code>".<br />
* '''<code>-c</code> ''name''''' : Se il tarball Source in più cartelle invece di una singola, l'opzione può essere usata per crearne una chiamata ''name''.<br />
<br />
Se si usa il comando "<code>%setup</code>" invece, allora l'opzione ''<code>-q</code>'' è comunemente usata per sopprimere gli output non necessari. <br />
<br />
Ci sono [http://rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html più opzioni %setup], utili principalmente se si stanno creando sottopacchetti. <br />
Quelle principali sono:<br />
<br />
{|<br />
|-<br />
| <code>-a number</code> || Decomprime il Source dato dal numero indicato dopo aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0).<br />
|-<br />
| <code>-b number</code> || Decomprime il Source dato dal numero indicato prima aver cambiato cartella (ad esempio "<code>–a 0</code>" per Source0).<br />
|-<br />
| <code>-D</code> || Non cancella la cartella dopo la decompressione.<br />
|-<br />
| <code>-T</code> || Disabilita la decompressione automatica dell'archivio.<br />
|}<br />
<br />
==== Sezione %prep: comando %patch ====<br />
<br />
Se è stato usato il comando "<code>%autosetup</code>", le nozioni sotto indicate non servono. <br />
Se si hanno necessità più complesse o di compatibilità con EPEL, allora possono servire.<br />
<br />
Il comando "<code>%patch0</code>" applica Patch0 (e %patch1 applica Patch1 etc.). Le patch sono normali metodi di modifica necessari per "aggiustare" il codice sorgente. Si applica la solita opzione "<code>-pNUMBER</code>" che passa l'argomento al programma <code>patch</code>.<br />
<br />
I file Patch sono nominati spesso come "<code>telnet-0.17-env.patch</code>", nel formato <code>%{name} - %{version} - REASON.patch</code>" (a volte la versione è omessa). I file Patch sono il risultato di "<code>diff -u</code>"; se si fa dalla subdirectory di <code>~/rpmbuild/BUILD</code> allora non è necessario specificare un livello <code>-p</code>.<br />
<br />
Questa è la tipica procedura per creare una patch da un singolo file:<br />
cp foo/bar foo/bar.orig<br />
vim foo/bar<br />
diff -u foo/bar.orig foo/bar > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch<br />
<br />
Se si editano molti file, un metodo facile è la copia dell'intera subdirectory sotto <code>BUILD</code> per poi avviare il <code>diff</code>. Dopo aver cambiato cartella a "<code>~rpmbuild/BUILD/NAME</code>", allora:<br />
cp -pr ./ ../PACKAGENAME.orig/<br />
... modifiche ...<br />
diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/''NAME''.''REASON''.patch<br />
<br />
Se si modificano più file in una sola patch, è possibile anche copiare quelli originali usando alcune desinenze come "<code>.orig</code>" prima di modificarle. Per poi usare "<code>gendiff</code>" (nel pacchetto <code>rpm-build</code>) per creare una patch con le modifiche.<br />
<br />
Assicurarsi che le patch corrispondano correttamente al contesto. Il valore predefinito "fuzz" è "<code>0</code>". Ci si può lavorare aggiungendo "<code>%global _default_patch_fuzz 2</code>" per ripristinare il valore trovato nelle vecchie versioni dell'RPM in Fedora, ma generalmente è raccomandato evitarlo.<br />
<br />
Come spiegato in [[Packaging/PatchUpstreamStatus]], tutte le patch dovrebbero avere un commento nello .spec file sul loro stato nell'upstream, includendo il bug, la data e la mail. Se è unico si dovrebbe menzionarne il motivo. Il Fedora Project non vuole allontanarsi dagli sviluppi dell'upstream; vedere [[PackageMaintainers/WhyUpstream]].<br />
<br />
==== Sezione %prep: file non modificati ====<br />
<br />
A volte uno o più file del Source non necessitano d'essere decompressi. Si possono "prep" (prepararli) nella cartella build come (dove <code>SOURCE1</code> si riferisce al corrispondente file Source):<br />
cp -p %SOURCE1 .<br />
<br />
=== Sezione %build ===<br />
<br />
La sezione "%build" è qualche volta complicata; in essa si può configurare e compilare/costruire i file che saranno installati.<br />
<br />
Molti programmi seguono la GNU <code>configure</code> (o alcune varianti). Come predefinito, installeranno in un prefix "<code>/usr/local</code>", ragionevolmente per dei file spacchettati. Tuttavia una volta impacchettati, cambia in "<code>/usr</code>". Le librerie dovrebbero essere installate o in <code>/usr/lib</code> oppure in <code>/usr/lib64</code> in base all'architettura.<br />
<br />
Dal momento che GNU <code>configure</code> è così comune, la macro "<code>%configure</code>" può essere usata per invocare automaticamente le corrette opzioni (ad esempio cambiare il prefix a <code>/usr</code>). Alcune sue varianti funzionano spesso:<br />
%configure<br />
make %{?_smp_mflags}<br />
<br />
Per sostituire le variabili del makefile, passarle come parametro a <code>make</code>:<br />
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}<br />
<br />
Per maggiori informazioni vedere [http://sourceware.org/autobook/ "GNU autoconf, automake, and libtool"].<br />
<br />
Alcuni programmi usano <code>cmake</code>. Vedi [[Packaging/cmake]].<br />
<br />
=== Sezione %check ===<br />
<br />
Se disponibili dei self-test, è buona idea includerli. Dovrebbero essere piazzati nella sezione %check (che segue la sezione %build) invece che all'interno della %build stessa, così da poter essere facilmente saltati se necessario.<br />
<br />
Spesso questa sezione contiene:<br />
make test<br />
<br />
A volte può essere:<br />
make check<br />
<br />
Osservare il file Makefile per sapere il modo più appropriato.<br />
<br />
=== Sezione %install ===<br />
<br />
Questa sezione coinvolge degli script per "install" (installare) il programma, copiando i file rilevanti da <code>%{_builddir}</code> a <code>%{buildroot}</code> (che solitamente significa da <code>~/rpmbuild/BUILD</code> a <code>~/rpmbuild/BUILDROOT</code>) e creando e cartelle all'interno di <code>%{buildroot}</code>.<br />
<br />
Parte della terminologìa può essere fuorviante:<br />
* La "build directory", anche conosciuta come <code>%{_builddir}</code>, non è la stessa della "build root", conosciuta anche come <code>%{buildroot}</code>. La compilazione avviene nella prima, mentre i file da impacchettare sono copiati dalla prima alla seconda.<br />
* Durante la sezione %build, la cartella di partenza è <code>%{buildsubdir}</code>, sottocartella all'interno di <code>%{_builddir}</code>, creata precedentemente durante il %prep. Di solito è qualcosa del genere <code>~/rpmbuild/BUILD/%{name}-%{version}</code>.<br />
* La sezione %install '''non''' parte quando l'RPM binario è installato dall'utente finale, ma è avviata solo nella creazione del pacchetto.<br />
<br />
Alcune varianti di "<code>make install</code>":<br />
%install<br />
<br />
rm -rf %{buildroot} # ridondante ad eccezione di RHEL5<br />
%make_install<br />
<br />
<br />
Idealmente si dovrebbe usare [http://www.gnu.org/prep/standards/html_node/DESTDIR.html <code>DESTDIR=%{buildroot}</code>] se il programma lo supporta, dato che redirige i file d'installazione alla specifica cartella ed è esattamente ciò che ci si aspetta che faccia durante la sezione %install.<br />
<br />
Se il programma non supporta <code>DESTDIR</code> (e solo se), è possibile in alternativa una delle seguenti strade:<br />
* ''Patchare'' il makefile così che possa supportare <code>DESTDIR</code>. Creare cartelle all'interno di <code>DESTDIR</code> dove necessario e includerne la patch dall' upstream.<br />
* Usare la macro "<code>%makeinstall</code>". Questo metodo potrebbe funzionare, ma può portare a fallimenti. Tramite la macro si arriva a qualcosa del genere "<code>make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install</code>", che in alcuni programmi pu non funzionare. Creare cartelle all'interno di <code>%{buildroot}</code> dove serve.<br />
* Considerare l'uso del pacchetto <code>auto-destdir</code>. Richiede "<code>BuildRequires: auto-destdir</code>" and di cambiare "<code>make install</code>" in "<code>make-redir DESTDIR=%{buildroot} install</code>". Funziona bene se l'installazione usa solo certi comandi comuni per installare i file, come <code>cp</code> e <code>install</code>.<br />
* Installare manualmente. Dovrbbe includere la creazione delle necessarie cartelle sotto <code>%{buildroot}</code> e la copia dei file da <code>%{_builddir}</code> a <code>%{buildroot}</code>. Bisogna essere cauti con gli aggiornamenti, contengono spesso nuovi filename. Un esempio di questa procedura:<br />
%install<br />
rm -rf %{buildroot}<br />
mkdir -p %{buildroot}%{_bindir}/<br />
cp -p mycommand %{buildroot}%{_bindir}/<br />
<br />
=== Sezione %files ===<br />
Questa sezione dichiara i file e le cartelle proprietà del pacchetto quindi incorporati nell'RPM binario.<br />
<br />
==== Nozioni sulla sezione %files ====<br />
<br />
Il <code>%defattr</code> imposta i permessi predefiniti del file e spesso appare all'inizio della sezione <code>%files</code>. Da notare che non è più necessario a meno che non bisogna i permessi. Il formato è:<br />
%defattr(<file permissions>, <user>, <group>, <directory permissions>)<br />
Il quarto parametro è solitamente omesso. Si usa <code>%defattr(-,root,root,-)</code>, dove "<code>-</code>" usa i permessi predefiniti.<br />
<br />
Si dovrebbero poi elencare i file e le cartelle che saranno di proprietà del pacchetto. A tal proposito usare le macro per i nomi delle cartelle, mostrate in [[Packaging:RPMMacros]] (ad esempio usare <code>%{_bindir}/mycommand</code> invece di <code>/usr/bin/mycommand</code>). Se la stringa inizia con "<code>/</code>" (o quando esteso da una macro) allora viene prelevato dalla cartella <code>%{buildroot}</code>. Oppure, si presume che il file sia nella cartella corrente (ad esempio dentro <code>%{_builddir}</code> come per i file di documentazione da includere). Se il pacchetto installa un solo file <code>/usr/sbin/mycommand</code>, la sezione <code>%files</code> può semplicemente essere:<br />
%files<br />
%{_sbindir}/mycommand<br />
<br />
Per ottenere un rpm meno soggetto ai cambiamenti dell'upstream, dichiarare tutti i file all'interno di una cartella di proprietà del pacchetto con la stringa:<br />
%{_bindir}/*<br />
<br />
Per includere una singola cartella:<br />
%{_datadir}/%{name}/<br />
<br />
Notare che <code>%{_bindir}/*</code> non dice che il pacchetto in oggetto sia proprietario della cartella <code>/usr/bin</code>, ma solo dei file contenuti all'interno. Se si elenca una cartella, allora si richiede la proprietà di quella cartella e dei file e sottocartelle contenute. Quindi '''non''' si elenca <code>%{_bindir}</code> assicurardosi anche delle cartelle condivise con altri rpm.<br />
<br />
Si verificheranno errori se:<br />
* una stringa non incontra alcun file o cartella<br />
* file o cartelle sono elencate più volte<br />
* file o cartelle in <code>%{buildroot}</code> non listate<br />
<br />
E' inoltre possibile escludere file usando <code>%exclude</code>. Può aiutare per includere quasi tutti i file da differenti stringhe ma fallirà se non incontra nulla.<br />
<br />
==== %files prefix ====<br />
Potrebbe essere necessario aggiungere uno o più prefissi alle linee della sezione <code>%files</code>; separate da uno spazio. Vedi [http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html Max RPM section on %files directives].<br />
<br />
Solitamente "<code>%doc</code>" è usato per elencare file di documentazione dentro <code>%{_builddir}</code> che non sono stati copiati in <code>%{buildroot}</code>. I file <code>README</code> e <code>INSTALL</code> sono di solito inclusi. Saranno piazzati nella cartella <code>/usr/share/doc</code>, la cui proprietà non ha bisogna d'essere dichiarata.<br />
<br />
'''Nota:''' Se si specifica una voce <code>%doc</code>, rpmbuild < 4.9.1 rimuove la cartella doc, nella quale piazza i file prima di installarli. Ciò significa che i file già all'interno, ad esempio installati nella sezione <code>%install</code>, sono rimossi e non finiranno nel pacchetto. Se si vuole installare alcuni file in nella sezione <code>%install</code>, farlo in una cartella temporanea all'interno della build dir (non in build root), ad esempio <code>_docs_staging</code>, ed includerli nella sezione <code>%files</code> come <code>%doc _docs_staging/*</code>.<br />
<br />
I file di configurazione dovrebbero essere posti in <code>/etc</code> e sono normalmente specificati così (che preserva le modifiche durante gli aggiornamenti):<br />
%config(noreplace) %{_sysconfdir}/foo.conf<br />
Se l'aggiornamento usa un formato di configurazione non-retrocompatibile, specificarli così:<br />
%config %{_sysconfdir}/foo.conf<br />
<br />
"<code>%attr(mode, user, group)</code>" può essere usato per controlli più precisi sui permessi, dove "<code>-</code>" significa usare il predefinito:<br />
%attr(0644, root, root) FOO.BAR<br />
<br />
"<code>%caps(capabilities)</code>" può essere usato per dare certe [http://linux.die.net/man/7/capabilities capacità] POSIX ad un file. Ad esempio:<br />
<br />
%caps(cap_net_admin=pe) FOO.BAR<br />
<br />
Se un file è in lingua naturale, usare <code>%lang</code> per annotarlo:<br />
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*<br />
<br />
I programmi che utilizzano file di localizzazione dovrebbero seguire i [[Packaging:Guidelines#Handling_Locale_Files|metodi raccomandati per gestire i file i18n]]:<br />
<br />
* trovare i filename nel passaggio <code>%install</code>: <code> %find_lang ${name}</code><br />
* aggiungere le dipendenze per la costruzione richieste: <code>BuildRequires: gettext</code><br />
* usare i filename trovati: <code>%files -f ${name}.lang</code><br />
<br />
<code>%readme</code> '''non''' è valido in Fedora.<br />
<br />
==== %files e Filesystem Hierarchy Standard (FHS) ====<br />
<br />
Riferimento a [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)].<br />
<br />
Gli eseguibili vanno in <code>/usr/bin</code>, i file di configurazione globali vanno in <code>/etc</code>, le librerie in <code>/usr/lib</code> (o <code>/usr/lib64</code>) e così via. C'é un'eccezione: eseguibili non eseguiti normalmente direttamente dall'utente o dall'amministratore dovrebbero andare nella sottocartella di <code>/usr/libexec</code>, denominata con <code>%{_libexecdir}/%{name}</code>.<br />
<br />
'''Non''' installare file in <code>/opt</code> o in <code>/usr/local</code>.<br />
<br />
Sfortunatamente molt programmi non rispettano la FHS. In particolare, librerie indipendenti dall'architettura vengono inserite in <code>/usr/lib</code> invece di <code>/usr/share</code>. Il primo è per librerie diendenti dall'architettura, mentre il secondo è per quelle indipendenti; significa che i sistemi con differenti architetture di CPU possono condividere la <code>/usr/share</code>. Ci sono molte eccezioni in Fedora (Python e Perl), ma Fedora applica queste regole più rigidamente rispetto ad alcune altre distro. <code>rpmlint</code> generalmente segnala se si mette qualcosa di diverso dai file ELF in <code>/usr/lib</code>.<br />
<br />
==== Esempio di %files ====<br />
<br />
Di seguito un esempio di sezione %files:<br />
%files<br />
%doc README<br />
%license LICENSE COPYING<br />
%{_bindir}/*<br />
%{_sbindir}/*<br />
%{_datadir}/%{name}/<br />
%config(noreplace) %{_sysconfdir}/*.conf<br />
<br />
==== Trovare duplicati ====<br />
<br />
Per listare qualsiasi duplicato di un rpm:<br />
cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture<br />
rpm -qlp PACKAGE1.*.rpm | sort > ,1<br />
rpm -qlp PACKAGE2.*.rpm | sort > ,2<br />
comm -12 ,1 ,2<br />
<br />
=== Scriptlet ===<br />
<br />
Quando un utente installa l'rpm, si consigliano alcuni comandi da eseguire. Questo si può ottenere con gli scriptlet. Vedi [[Packaging/ScriptletSnippets]].<br />
<br />
Gli scriptlet si eseguono:<br />
* prima ('''<code>%pre</code>''') o dopo ('''<code>%post</code>''') l'installazione di un pacchetto<br />
* prima ('''<code>%preun</code>''') o dopo ('''<code>%postun</code>''') la disinstallazione di un pacchetto<br />
* all'avvìo ('''<code>%pretrans</code>''') o alla fine ('''<code>%posttrans</code>''') di una transazione<br />
<br />
Per esempio, ogni rpm binario che immagazzina file di librerie condivise in qualsiasi percorso di dynamic linker, deve richiamare <code>ldconfig</code> in <code>%post</code> e <code>%postun</code>. Se il pacchetto ha molti sottopacchetti con librerie, ognuno di essi dovrebbe fare la stessa cosa.<br />
%post -p /sbin/ldconfig<br />
%postun -p /sbin/ldconfig<br />
<br />
Se si esegue un solo comando, l'opzione "<code>-p</code>" avvìa il comando adiacente senza invocare la shell. Tuttavia, per diversi comandi, ometterla e aggiungere tutti i comandi shell.<br />
<br />
Se si avvìa un programma negli scriptlet, qualsiasi richiesta va specificata nella forma "<code>Requires(CONTEXT)</code>" (ad esempio <code>Requires(post)</code>).<br />
<br />
<code>%pre</code>, <code>%post</code>, <code>%preun</code> e <code>%postun</code> forniscono l'argomento <code>$1</code>, che è il numero di pacchetti di questo nome che saranno lasciati nel sistema. Non confrontare per uguaglianza con <code>2</code>, controlla invece se sono meggiori o uguali a <code>2</code>. Per <code>%pretrans</code> e <code>%posttrans</code>, <code>$1</code> è sempre <code>0</code>.<br />
<br />
Per esempio se il pacchetto installa un manuale il quale indice deve essere aggiornato con <code>install-info</code> dal pacchetto <code>info</code>, innanzitutto non è garantita la presenza del pacchetto <code>info</code> senza una sua richiesta specifica e poi non si può fallire completamente se <code>install-info</code> non funziona:<br />
Requires(post): info<br />
Requires(preun): info<br />
...<br />
%post<br />
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :<br />
%preun<br />
if [ $1 = 0 ] ; then<br />
/sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :<br />
fi<br />
<br />
Esiste un altro problema tecnico relativo all'installazione dei manuali. Il comando <code>install-info</code> aggiornerà la certella delle informazioni, quindi si dovrebbero cancellare le cartelle vuote inutilizzate da %{buildroot} durante la sezione <code>%install</code>:<br />
<br />
rm -f %{buildroot}%{_infodir}/dir<br />
<br />
Un'altra abilità simile agli scriptlet è "trigger", avviabile quando altri pacchetti sono installati o disinstallati. Vedi [http://rpm.org/api/4.4.2.2/triggers.html RPM Triggers].<br />
<br />
=== Macro ===<br />
<br />
La macro è un testo nel formato <code>%{string}</code>. Tipiche macro:<br />
<br />
{|<br />
! Macro !! Estensione tipica !! Significato<br />
|-<br />
| <code>%{_bindir}</code> || <code>/usr/bin</code> || Cartella dei binari: dove gli eseguibili vengono solitamente localizzati.<br />
|-<br />
| <code>%{_builddir}</code> || <code>~/rpmbuild/BUILD</code> || Cartella per il build: i file sono compilati all'interno della sua sottocartella. Vedere <code>%buildsubdir</code>.<br />
|-<br />
| <code>%{buildroot}</code> || <code>~/rpmbuild/BUILDROOT</code> || Build root: dove i file vengono "installati" durante <code>%install</code>, che li copia dalla sottocartella di <code>%{_builddir}</code> a quella di <code>%{buildroot}</code>. (Storicamente, <code>%{buildroot}</code> era in "/var/tmp/".)<br />
|-<br />
| <code>%{buildsubdir}</code> || <code>%{_builddir}/%{name}</code> || Sottocartella build: interna a <code>%{_builddir}</code> dove i file sono compilati durante <code>%build</code>. E' impostata dopo <code>%autosetup</code>.<br />
|-<br />
| <code>%{_datadir}</code> || <code>/usr/share</code> || Cartella condivisa.<br />
|-<br />
| <code>%{_defaultdocdir}</code> || <code>/usr/share/doc</code> || Cartella predefinita della documentazione.<br />
|-<br />
| <code>%{dist}</code> || <code>.fc''NUMBER''</code> || Versione della distro (ad esempio "<code>.fc{{FedoraVersion}}</code>")<br />
|-<br />
| <code>%{fedora}</code> || <code>''NUMBER''</code> || Numero di rilascio di Fedora (e.g. "<code>{{FedoraVersion}}</code>")<br />
|-<br />
| <code>%{_includedir}</code> || <code>/usr/include</code><br />
|-<br />
| <code>%{_infodir}</code> || <code>/usr/share/info</code><br />
|-<br />
| <code>%{_initrddir}</code> || <code>/etc/rc.d/init.d</code><br />
|-<br />
| <code>%{_libdir}</code> || <code>/usr/lib</code><br />
|-<br />
| <code>%{_libexecdir}</code> || <code>/usr/libexec</code><br />
|-<br />
| <code>%{_localstatedir}</code> || <code>/var</code><br />
|-<br />
| <code>%{_mandir}</code> || <code>/usr/share/man</code><br />
|-<br />
| <code>%{name}</code> || || Name of package, set by Name: tag<br />
|-<br />
| <code>%{_sbindir}</code> || <code>/usr/sbin</code><br />
|-<br />
| <code>%{_sharedstatedir}</code> || <code>/var/lib</code><br />
|-<br />
| <code>%{_sysconfdir}</code> || <code>/etc</code><br />
|-<br />
| <code>%{version}</code> || || Versione del pacchetto, impostata tramite il tag Version:<br />
|}<br />
<br />
Se ne può sapere di più sulle macro guardando in <code>/etc/rpm/*</code> e <code>/usr/lib/rpm</code>, specialmente <code>/usr/lib/rpm/macros</code>. Inoltre usare <code>rpm --showrc</code> per saperne i valori che RPM userà per le macro (alterate da <code>rpmrc</code> e i file di configurazione delle macro).<br />
<br />
E' possibile impostare le proprie macro usando %global, ma assicurarsi di definirle prima dell'uso. (Le definizioni possono riferirsi anche ad altre macro.) Per esempio:<br />
%global date 2012-02-08<br />
<br />
Usare l'opzione "<code>-E</code>"di <code>rpmbuild</code> per trovare il valore della macro nello .spec file:<br />
rpmbuild -E '%{_bindir}' myfile.spec<br />
<br />
Vedere anche [[Packaging/RPMMacros]] e [https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s07.html RPM Guide capitolo 9].<br />
<br />
=== Altri tag ===<br />
<br />
In aggiunta ai tag Requires e BuildRequires, esistono questi per il controllo delle dipendenze:<br />
* '''Provides''': lista i nomi dei pacchetti virtuali forniti. Ad esempio, ci potrebbe essere un pacchetto "<code>foo</code>" che esige una particolare funzionalità "bar" da un altro programma. Se esistono parecchi pacchetti che epossono soddisfarla, è possibile specificarli con "<code>Provides: bar</code>" e il pacchetto "<code>foo</code>" può specificare "<code>Requires: bar</code>". Si potrebbero anche usare [http://dailypackage.fedorabook.com/index.php?/archives/6-Wednesday-Why-The-Alternatives-System.html metodi "alternativi"], ma evitare se più utenti hanno necessità differenti, visto che queste impostazioni sono a livello di sistema. Usare "<code>rpm -q --provides PACKAGENAME</code>" per vedere cosa fornisce un determinato pacchetto. Alcuni esempi di pacchetti virtuali in Fedora:<br />
** MTA: Usato per i mail transport agents come sendmail.<br />
** tex(latex): Usato per latex<br />
* '''Obsoletes''': rimuove un altro pacchetto(i) nominato(i) se installato(i). Usare se il nome del pacchetto cambia o se è totalmente rimpiazzato da un differente paccehtto.<br />
* '''Conflicts''': specifica quali altri pacchetti non possono essere installati simultaneamente a quello in oggetto. Evitarlo se possibile. Vedere [[Packaging/Conflicts]].<br />
* '''BuildConflicts''': specifica quali pacchetti non possono essere installati se si costruisce il pacchetto in oggetto. Evitarlo se possibile.<br />
<br />
Per gestire differenti architetture, ci sono due tag:<br />
* '''ExcludeArch''': per escluderne una nella quale la costruzione del pacchetto non avviene. Ad esempio:<br />
ExcludeArch: ppc<br />
* '''ExclusiveArch''': per includere solo quella specificata. Evitarlo se non assolutamente corretto.<br />
Architetture valide sono listate in [[Architectures]].<br />
<br />
=== Subpackage ===<br />
<br />
Uno SPEC file può definire diversi binari. In altre parole, un SRPM con uno SPEC file può risultare in più RPM. Notare che c'é ancora un solo processo di creazione (%prep, %build, %install etc.). Sottopacchetti <code>name-doc</code> e <code>name-devel</code> sono comuni per la documentazionee i file di sviluppo rispettivamente.<br />
<br />
Usare la direttiva <code>%package</code> per iniziare la definizione di un sottopacchetto:<br />
%package subpackage_name<br />
<br />
Dopo ogni direttiva <code>%package</code>, listarne i tag. Dovrebbe almeno includere i tag Summary e Group, oltre a <code>%description subpackage_name</code> e <code>%files subpackage_name</code>:<br />
<br />
Tutto quanto non specificato dal sottopacchetto sarà ereditato dal suo genitore.<br />
<br />
Come predefinito, se il nome del pacchetto è "<code>foo</code>" e quello del sottopacchetto è "<code>bar</code>", allora i nomi risultanti saranno <code>foo-bar</code>". E' possibile evitarlo con l'opzione "<code>-n</code>" (ma servirà usarlo in tutte le altre direttive una volta qui specificato):<br />
%package -n new_subpackage_name<br />
<br />
[http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s04.html Leggere la sezione sui sottopacchetti della Guida RPM] per maggiori informazioni.<br />
<br />
=== Condizionali ===<br />
<br />
E' possibile inserire stati di condizione, ad esempio per verificare se si sta creando un binario per una certa architettura:<br />
%ifarch ARCHITECTURE_NAME<br />
versione negata con:<br />
%ifnarch ARCHITECTURE_NAME<br />
o più condizioni generiche:<br />
%if TRUE_OR_FALSE<br />
<br />
C'é una sezione opzionale "<code>%else</code>"; tutte queste vengono chiuse con "<code>%endif</code>".<br />
<br />
=== Linee guida specifiche ===<br />
<br />
Ci sono molte linee guida specifiche che sono di aiuto (ad esempio per i linguaggi di programmazione specifici, per applicazioni, librerie e sistemi di build). Molte di loro sono elencate come parte delle [[Packaging/Guidelines#Application_Specific_Guidelines|Application Specific Guidelines of Packaging/Guidelines]]. Esempi di linee guida:<br />
* [[Packaging:Cmake|Cmake]]<br />
* [[Packaging:Emacs|Emacs]]<br />
<br />
Altre sono:<br />
* Il comando 'SEARCH' di Fedoraproject.org.<br />
* [[PackagingDrafts]]<br />
* [[SIGs|Special Interest Group (SIG)]]<br />
* [http://fedoraproject.org/wiki/Special:PrefixIndex/Packaging Pagine Wiki con prefisso 'Packaging']<br />
<br />
=== Suggerimenti vari ===<br />
<br />
[[Packaging/FrequentlyMadeMistakes]] contiene informazioni sugli errori più comuni commessi. Ci sono anche altre raccomandazioni e trucchi controversi in [[PackageMaintainers/Packaging Tricks]].<br />
<br />
Provare a scrivere i propri .sepc files così da funzonare quando nuove versioni dall'upstream sono pronte, senza nessuna modifica a parte il numero di versione e l'aggiornamento dei sorgenti. Per esempio, se contiene file *.txt con istruzioni d'esecuzione, invece di fare<br />
chmod a-x Filename1.txt Filename2.txt Filename3.txt<br />
considerare comandi come il seguente:<br />
chmod a-x *.txt<br />
<br />
Se si vogliono vedere un sacco di esempi di scriptlet, è possibile mostrarli tutti dai pacchetti installati con:<br />
rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less<br />
<br />
Non cercare di interagire con l'utente; RPM è designato per supportare tante installazioni. Se un'applicazione necessita di mostrare un EULA (End User License Agreement), quest'ultima dev'essere parte dell'esecuzione iniziale e non dell'installazione.<br />
<br />
Non si dovrebbero avviare servizi poiché potrebbero rallentare il tutto. Se si installa uno script init e systemd, considerare l'uso di <code>chkconfig</code> o di <code>systemctl</code> per far sì che gli stessi vengano avviati o arrestati al successivo riavvìo. Prima di disinstallare, si dovrebbe normalmente tentare di fermare i suoi servizi se in esecuzione in quel momento.<br />
<br />
La disinstallazione dovrebbe togliere tutte le modifiche fatte nell'installazione, ma non i file creati dall'utente.<br />
<br />
Normalmente, se ci sono binari eseguibili, i simboli di debugging sono tolti dall'rpm binario normale e piazzati in un sottopacchetto <code>name-debug</code>. Se non dovesse succedere, si può disabilitare la creazione dell'rpm-debug aggiungendo in cima allo .spec file:<br />
%global _enable_debug_package 0<br />
%global debug_package %{nil}<br />
%global __os_install_post /usr/lib/rpm/brp-compress %{nil}<br />
<br />
mentre nella sezione <code>%install</code>:<br />
export DONT_STRIP=1<br />
<br />
Un modo per controllare la versione di Fedora in uno .spec file per i build condizionali è:<br />
%if 0%{?fedora} <= <version><br />
Il <code>?</code> permette il riconoscimento della versione se <code>%fedora</code> non è definito. Fa sì che il risultato finale sia <code>0</code>, pur non interferendo sul risultato se presente un valore per <code>%fedora</code>. (Notare che questo metodo non funziona nelle build "scratch" in Koji, dove <code>%fedora</code> è impostato durante la creazione di un SRPM.)<br />
<br />
Le GUI devono avere una voce desktop così da permetterne l'uso dal menu grafico. Per i file <code>.desktop</code>, vedere [[Packaging/Guidelines#Desktop_files|Fedora packaging guidelines for desktop files]] e [http://standards.freedesktop.org/desktop-entry-spec/latest/ desktop entry spec]. Per le icone in <code>/usr/share/icons</code>, vedere [http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html icon theme spec].<br />
<br />
== Costruzione del pacchetto binario ==<br />
=== Test con rpmlint ===<br />
<br />
Prima di provare a costruire qualsiasi cosa, si dovrebbe eseguire <code>rpmlint</code> sullo spec file:<br />
$ rpmlint program.spec<br />
Troverà molti errori velocemente. Se l'errore riportato non ha molto senso,<br />
ridare lo stesso comando aggiungendo l'opzione "-i" (questo darà maggiori informazioni).<br />
<br />
L'ideale sarebbe quello d'avere il minor numero di errori, ma talvolta rpmlint riporta dei falsi positivi.<br />
Le [http://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint linee guida Fedora packaging] spiega quali sono da ignorare.<br />
<br />
=== Creazione degli RPM dallo spec file ===<br />
<br />
Una volta creato uno spec file, chiamato program.spec, è possibile creare<br />
l'rpm sorgente e l'rpm binario semplicemente avviando: <br />
$ rpmbuild -ba program.spec<br />
Se funziona, i file binari RPM verranno creati nella sottocartella ~/rpmbuild/RPMS/ e l'RPM sorgente in ~/rpmbuild/SRPMS.<br />
<br />
Quando qualcosa va male, è possibile entrare ("cd") nella directory appropriata e vedere cosa contiene.<br />
Se si vogliono saltare i passaggi precedenti, usare l'opzione "--short-circuit"; è utile quando si è avuto un build con successo, ma si ha un errore nella sezione %install. Ad esempio, per reiniziare lo stage %install (saltando i passaggi precedenti):<br />
$ rpmbuild -bi --short-circuit program.spec<br />
Se si vuole creare l'rpm sorgente (.src.rpm), entrare nella cartella SPECS e:<br />
$ rpmbuild -bs program.spec <br />
Verrà creato l'rpm sorgente nella cartella ~/rpmbuild/SRPMS. Creare ''solo'' l'rpm sorgente è abbastanza veloce, poiché non fa altro che associare lo .spec file e i file SOURCES nel .src.rpm . Creare un rpm binario tipicamente prende più tempo perché richiede l'avvìo degli script %prep, %build e %install.<br />
<br />
=== Testare con rpmlint gli RPM creati ===<br />
<br />
Avviato rpmlint sullo spec file, generato l'RPM ''binario'' e generato l'RPM sorgente. rpmlint lavora sugli spec, sugli rpm binari o sorgente, trovando cose differenti in ognuno. E' necessario eliminare o modificare degli "rpmlint warning" prima di rilasciare un pacchetto. [[Common_Rpmlint_issues|Questa pagina]] offre spiegazioni per alcuni dei problemi comuni che potrebbero saltare fuori. <br/><br />
Dalla cartella SPECS:<br />
$ rpmlint ''NAME''.spec ../RPMS/*/''NAME''*.rpm ../SRPMS/''NAME''*.rpm<br />
Generalmente rpmbuild costruisce rpm binari con informazioni di debug, anche questi possono essere sottoposti al test.<br />
<br />
Spostandosi nella cartella "~/rpmbuild/RPMS" poi nella sottocartella denominata dall'architettura (32 o 64 bit)<br />
si troveranno alcuni rpm binari. E' possibile vederne facilmente i file ed i permessi con rpmls<br />
(assicurarsi di trovare ciò che ci si aspetta):<br />
$ rpmls *.rpm<br />
Se corretti, provare ad installarli diventando root:<br />
$ su<br />
# rpm -ivp package1.rpm package2.rpm package3.rpm ...<br />
Per poi testarli, utilizzandoli in differenti modi. Se si decide di usare uno strumento ad interfaccia grafica (GUI), assicurarsi che venga mostrato nel menu (se non lo è, allora qualcosa è sbagliato alla voce .desktop).<br />
<br />
Successivamente è possibile disinstallarli:<br />
# rpm -e package1 package2 package3<br />
<br />
== Mock and Koji ==<br />
<br />
[[Projects/Mock|Mock]] è un potente tool che usa gli SRPM creati per costruire pacchetti binari all'interno di un ambiente appositamente creato. Questo può essere d'aiuto per la rilevazione delle dipendenze tra pacchetti. Se fallisce, potrebbe mancare qualcosa alla voce BuildRequires. Vedere [[Using Mock to test package builds]] per ulteriori info sull'utilizzo di <code>mock</code>; una volta che il proprio account rientra nel gruppo "<code>mock</code>", è possibile avviare comandi come il seguente per eseguire test in locale:<br />
$ mock -r fedora-9-i386 rebuild path_to_source_RPM<br />
<br />
Una volta che Mock ha funzionato correttamente, si può usare Koji (il quale usa Mock) per costruire in<br />
differenti sistemi. [[PackageMaintainers/Join]] e [[PackageMaintainers/UsingKoji]] hanno molte informazioni su Koji.<br />
Una volta settati, si possono eseguire test sul proprio rpm sorgente con differenti sistemi<br />
$ koji build --scratch dist-f9 path_to_source_RPM<br />
Si può sostituire la voce "<code>%fc9</code>" con qualsiasi altra release successiva di Fedora, ma non usare <code>dist-rawhide</code>. Ricordarsi che i valori di <code>%fedora</code>, %fc9, ... non saranno giusti per una scratch build, quindi non funzioneranno se il proprio .spec file fa qualcosa di diverso basato su quei valori.<br />
I build koji possono solo dipendere dai pacchetti che sono attualmente disponibili nei repository TARGET. Quindi non si può usare Koji per costruire per distribuzioni rilasciate se il proprio pacchetto dipende da altri nuovi pacchetti che Bodhi non ha ancora rilasciato.<br />
Se si vuole costruire un pacchetto che non è ancora una versione aggiornata stabile, presentare una richiesta "buildroot override" via Bodhi. Se il pacchetto non è a proprio carico, contattare il/i maintainer. [Prima dell'attuale metodo che prevede una richiesta "buildroot override", si poteva aprire un ticket con rel-eng a https://fedorahosted.org/rel-eng/newticket e chiedere che il pacchetto venisse aggiunto come buildroot override]<br />
<br />
== Strumenti utili ==<br />
<br />
Il pacchetto <code>rpmdevtools</code> fornisce diversi strumenti utili; "<code>rpm -qil rpmdevtools</code>" mostra ciò che verrà installato.<br />
<br />
* <code>rpmdev-bumpspec : dal tag release dello spec file, aggiunge un commento al changelog con la data e la versione del software:</code><br />
$ rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES<br />
<br />
DNF download plugin (dal core DNF plugins) contiene molti strumenti utili:<br />
<br />
* <code>dnf download</code>: scarica il pacchetto sorgente<br />
<br />
$ dnf download --source PACKAGENAME<br />
<br />
Il pacchetto <code>auto-buildrequires</code> ha un paio di buoni strumenti d'aiuto per configurare correttamente la voce BuildRequires. Dopo averlo installato, rimpiazzare "<code>rpmbuild</code>" con "<code>auto-br-rpmbuild</code>" e si vedrà automaticamente generata la lista buildrequires.<br />
<br />
Potrebbe essere utile [http://rust.sourceforge.net/ RUST] (GPL), anche se non crea rpm di adeguata qualità per i repository Fedora. [http://kitenet.net/~joey/code/alien/ Alien] converte pacchetti di diverso formato. Non produce rpm sorgente puliti ma potrebbe essere utile per la conversione di pacchetti esistenti dai quali trarre informazioni preziose.<br />
<br />
Se si ha intenzione di creare un pacchetto RPM per Fedora, assicurarsi di sottoporre il proprio file ad una [https://fedorahosted.org/FedoraReview/ Fedora Review], che aiuta a garantire che ci si attenga alle [https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines Linee-guida sul Packaging].<br />
<br />
Finalmente, [https://github.com/alanfranz/docker-rpm-builder docker-rpm-builder] (APL 2.0) usa [http://www.docker.com Docker] per costruire i pacchetti RPM; mentre l'uso di 'rpmbuild' richiede di lavorare nella stessa distro del target, e 'mock' funziona bene su distribuzioni Fedora/Centos/RHEL per qualsiasi target, '''quest'ultimo strumento lavora con Docker'''.<br />
<br />
Se si preferisce costruire RPM per altre distribuzioni o architetture avendo accesso pubblico ai repository, è possibile usare [https://copr.fedoraproject.org Copr].<br />
<br />
Per firmare il pacchetto, usare <code>rpmsign</code>.<br />
<br />
== Linee guida e regole ==<br />
<br />
Una volta creato il proprio pacchetto, bisogna seguire queste regole e linee guida:<br />
* [[Join the package collection maintainers| How to join the Fedora Package Collection Maintainers]] - Descrive il processo per diventare Fedora package maintainer<br />
* [[Packaging:Guidelines | Packaging Guidelines]]<br />
* [[Packaging:NamingGuidelines| Package Naming Guidelines]] <br />
* [[Packaging:DistTag| Dist Tag Guidelines]] <br />
* [[Packaging:ReviewGuidelines| Package Review Guidelines]]<br />
<br />
Ci sono molte linee guida ufficiali che possono essere d'aiuto in circostanze particolari<br />
(Java programs, OCaml programs, GNOME programs, etc.).<br />
Si può inoltre imparare molto dalle sezioni [[SIGs]] e <br />
[[:Category:Package Maintainers|Package Maintainers]].<br />
[https://fedoraproject.org/wiki/Special:Prefixindex/Packaging Lista delle pagine wiki sul Packaging].<br />
<br />
Inoltre, si potrebbero trovare utili quelle non ufficiali<br />
[https://fedoraproject.org/wiki/Special:Search?ns0=1&search=PackagingDrafts%2F&searchx=Search Packaging Drafts] e [https://fedoraproject.org/wiki/PackagingDrafts Packaging Drafts To Do].<br />
<br />
Si potrebbero trovare spunti da [http://en.opensuse.org/Packaging SuSE],<br />
[http://www.debian.org/doc/debian-policy/ Debian], ma<br />
[http://www.mail-archive.com/distributions@lists.freedesktop.org/msg00156.html ci sono differenze tra le distribuzioni], quindi si presume che non possono essere usate direttamente.<br />
<br />
'''I file .spec creati devono riguardare software opensource come previsto dal [[Legal:Fedora_Project_Contributor_Agreement|FPCA]].'''<br />
<br />
== Mantenimento del pacchetto ==<br />
<br />
Quando il pacchetto viene accettato, dev'essere mantenuto dal maintainer (o dal co-maintainer).<br />
Vedere [[Package update HOWTO]] e [[Package update guidelines]] per maggiori informazioni.<br />
Se si aggiorna a più di una release Fedora, farlo a ritroso nel tempo; ad esempio, release per Fedora N, una volta accettato, Fedora N -1<br />
( il sistema presuppone che versioni successive di Fedora hanno versioni uguali o più aggiornate dei programmi).<br />
<br />
Incoraggiare gli sviluppatori upstream ad usare convenzioni stardard nel rilascio del codice sorgente; questo renderà più facile il packaging del software. Per maggiori informazioni, vedere:<br />
* [http://www.dwheeler.com/essays/releasing-floss-software.html Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation] (sommario veloce)<br />
* [http://www.gnu.org/prep/standards/html_node/Managing-Releases.html GNU Coding Standards release process]<br />
* [http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO]<br />
* [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard (FHS)]<br />
* [http://offog.org/articles/packaging/ Packaging Unix software]<br />
<br />
== Per maggiori informazioni ==<br />
<br />
La pagina [[:Category:Package Maintainers|Package Maintainers]] è collegata a molte altre pagine utili e<br />
[[Package update HOWTO]] descrive come aggiornare un pacchetto esistente già mantenuto in Fedora.<br />
<br />
Per maggiori informazioni, fuori dal wiki Fedora, vedere:<br />
* [http://www.g-loaded.eu/2006/04/05/how-to-build-rpm-packages-on-fedora/ How to build RPM packages on Fedora] - ripasso veloce<br />
* Packaging software con RPM (developerWorks) [http://www.ibm.com/developerworks/library/l-rpm1/ Part 1], [http://www.ibm.com/developerworks/library/l-rpm2/ Part 2] e [http://www.ibm.com/developerworks/library/l-rpm3.html Part 3]<br />
* Fedora Classroom ha avuto una sessione IRC sul packaging e si può far riferimento al log su https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29<br />
* [http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html Manuale Fedora Packager]<br />
* [http://www.redhatmagazine.com/2008/02/28/when-sally-met-eddie-the-fedora-package-story/ When Sally met Eddie] - Un semplice testo con pochi dettagli<br />
* [http://rpm.org/max-rpm-snapshot/ Maximum RPM Book] - Molte informazioni complete, ma in alcuni casi obsolete<br />
* [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-creating-rpms.html RPM Guide, section on creating RPMs] - Ha parecchie buone informazioni leggermente più aggiornate, ma è una bozza<br />
* [http://docs.fedoraproject.org/developers-guide/ch-rpm-building.html Guida per sviluppatori, sezione building RPM]<br />
* [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Creating RPMS slides] da Guru Labs<br />
* [http://freshrpms.net/docs/fight/ La lotta, il mio primo tentativo di fare un'introduzione leggibile sull'rpm building.]<br />
* [http://genetikayos.com/code/repos/rpm-tutorial/trunk/rpm-tutorial.html RPM Tutorial (Fullhart)]<br />
* [http://www-uxsup.csx.cam.ac.uk/talks/rpmbuild/rpmbuild.pdf Cambridge RPM tutorial] è una presentazione sulla creazione basilare degli RPM<br />
* [http://en.tldp.org/HOWTO/RPM-HOWTO/index.html] RPM HOWTO: RPM al Minimo di Donnie Barnes<br />
* [http://home.fnal.gov/~dawson/rpms/howto/index.html] RPM HowTo di Dawson<br />
* [http://en.opensuse.org/SUSE_Build_Tutorial SuSE build tutorial] - ma su SuSE, non per Fedora. [http://en.opensuse.org/Build_Service/cross_distribution_package_how_to Cross-distribution package HOWTO] contiene suggerimenti se si fanno rpm per diverse distribuzioni.<br />
* [http://wiki.mandriva.com/en/Development/Howto/RPM Mandriva Rpm HowTo (en)] ([http://www.mandrivaclub.com/xwiki/bin/view/KB/MandrivaRpmHowTo alt]) è un tutorial RPM anche se per Mandriva. Da notare che in Fedora ''non'' si ricomprimono i tarball originali, come Mandriva suggerisce, perché questo avrebbe cambiato le loro hash crittografate.<br />
* [http://linuxshellaccount.blogspot.com/2008/03/creating-your-own-linux-rpms-initial.html Creazione del proprio Linux RPM - Software Building Iniziale] è un'altra introduzione ma fa il punto su "Il processo per costruire RPM è più facile della creazione dei pacchetti per Solaris... Meno passaggi, e l'abilità di aggiungere tutte le informazioni sul software in uno specifico file, fatti per una maggiore essenzialità (più facile da modificare e riprodurre) del sistema di packaging".<br />
* [http://fedoranews.org/alex/tutorial/rpm/ Tutto ciò che bisogna sapere su RPM] (più sull'installazione che sulla creazione)<br />
* The [http://wiki.rpm.org/ rpm.org Wiki] ha alcune informazioni utili, come la [http://wiki.rpm.org/Problems lista dei problemi conosciuti]<br />
<br />
Da notare: il sito [http://rpm5.org/ rpm5.org] ha alcuni documenti ma non dipende da loro; è la casa di un fork di RPM mantenuto da Jeff Johnson. L'RPM usato da Fedora (e da Novell/SuSE) ha invece la sede in [http://www.rpm.org rpm.org].<br><br />
[http://lwn.net/Articles/236029/ lwn.net] contiene un articolo a riguardo.<br />
<br />
[[Category:Package Maintainers]]<br />
[[Category:How to]]<br />
[[Category:Italiano]]<br />
[[Category:Da revisionare]]</div>Germanohttps://fedoraproject.org/w/index.php?title=User:Germano&diff=433924User:Germano2016-02-10T21:32:05Z<p>Germano: /* Activities within Fedora */</p>
<hr />
<div>= Germano Massullo =<br />
<br />
<!-- Use code like this to put your hackergotchi or whatnot on the right side of the page. --><br />
<!-- Upload the file and edit the code below to match. --><br />
<!-- [[Image:|right]] --><br />
<br />
I started to use Linux around 2003 and I am a Fedora user since 2009.<br />
<br />
I mostly use Fedora with the KDE Plasma Desktop Environment.<br />
<br />
== Contact ==<br />
<br />
* '''Email''': my name DOT my surname AT gmail DOT com<br />
* '''IRC Channels''': I'm usually logged in #fedora-it, #fedora-kde<br />
* '''Fedora Account''': germano<br />
* '''Languages:''' Italian, English, French, and studying German :-)<br />
<br />
== Activities within Fedora ==<br />
<br />
* BOINC, Darktable, Owncloud-client, and various Python libaries packages co-mantainer;<br />
* involved in translations for the Italian language;<br />
* general bugreporting (downstream and upstream);<br />
* Fedora pre-releases tester to catch and report bugs related to the hardware I own;<br />
* patches tester;<br />
* user support in chat and forums;<br />
* Fedora and FOSS promotion among universities, public administrations and companies.<br />
<br />
== Badges ==<br />
{{ #fedorabadges: germano }}<br />
<br />
== Various FOSS communities I partecipate in ==<br />
<br />
* OpenStreetMap<br />
* Ninux.org<br />
* BOINC Italy<br />
<br />
== Some of my interests ==<br />
<br />
* [https://www.flickr.com/photos/130387494@N02/ photography];<br />
* 20th century history;<br />
* technology (not only information technology);<br />
* surfing;<br />
* swimming</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430823Changes/Darktable 2 02015-12-24T11:08:03Z<p>Germano: </p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
You can check the .spec file at https://fedorapeople.org/~germano/darktable.spec<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
<br />
<br />
== Release Notes ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeAnnounced]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:SelfContainedChange]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430756Changes/Darktable 2 02015-12-22T15:47:03Z<p>Germano: </p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
<br />
<br />
== Release Notes ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:SelfContainedChange]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430755Changes/Darktable 2 02015-12-22T15:46:30Z<p>Germano: /* Release Notes */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:SelfContainedChange]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430754Changes/Darktable 2 02015-12-22T15:45:27Z<p>Germano: </p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:SelfContainedChange]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430753Changes/Darktable 2 02015-12-22T15:44:32Z<p>Germano: /* How To Test */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430752Changes/Darktable 2 02015-12-22T15:44:11Z<p>Germano: /* How To Test */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
Basic Darktable editing functionality should work, although of course upstream bugs may exist.<br />
<br />
<br />
Actually you can test the '''final''' release by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430746Changes/Darktable 2 02015-12-22T14:49:50Z<p>Germano: /* Detailed Description */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
Changelog: https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
Basic Darktable editing functionality should work, although of course upstream bugs may exist.<br />
<br />
<br />
Version 2 will land in Rawhide as soon as it is ready, but you can also help test on Fedora 22 or Fedora 23 by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430745Changes/Darktable 2 02015-12-22T14:48:59Z<p>Germano: /* Owner */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
Basic Darktable editing functionality should work, although of course upstream bugs may exist.<br />
<br />
<br />
Version 2 will land in Rawhide as soon as it is ready, but you can also help test on Fedora 22 or Fedora 23 by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=430744Changes/Darktable 2 02015-12-22T14:15:32Z<p>Germano: /* Documentation */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x.<br />
<br />
Basic Darktable editing functionality should work, although of course upstream bugs may exist.<br />
<br />
<br />
Version 2 will land in Rawhide as soon as it is ready, but you can also help test on Fedora 22 or Fedora 23 by enabling the COPR repo https://copr.fedoraproject.org/coprs/germano/Darktable_2.0_release_candidate/<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0.0<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&diff=428554Development/SteeringCommittee/Nominations2015-11-21T22:02:31Z<p>Germano: /* Candidate Nominations */</p>
<hr />
<div><!--{{admon/important|The nomination period has not yet begun. Please wait for the elections announcement.}}--><br />
<!--{{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on June 14, 2015.}}--><br />
{{admon/important|We're OPEN!|The nomination period is in progress! Please add your nomination before 23:59:59 UTC on November 23rd, 2015! }}<br />
<!--{{admon/tip | VOTE FOR YOUR FAVORITE CANDIDATES. | Fedora contributors can elect FESCo at https://admin.fedoraproject.org/voting/about/fesco-december2012.--><br />
<!--<br />DEADLINE: Dec. 9, 23:59:59 UTC}}--><br />
<br />
The following [[Elections|elections]] will take place in November/December 2015:<br />
<br />
* [[Development/SteeringCommittee/Nominations|FESCo (Engineering)]] (five seats)<br />
<br />
More information about FESCo on [[Fedora_Engineering_Steering_Committee|FESCo wiki page]].<br />
<br />
See [https://fedorapeople.org/groups/schedule/f-23/f-23-elections.html Election Schedule] page for more details regarding the Elections timeline.<br />
All dates and times noted are UTC time.<br />
<br />
= FESCo Elections November/December 2015 =<br />
As per the [[FESCo_election_policy|FESCo election policy]], the following finish their terms, and the seats are up for re-election:<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - elected for F22/F23 period<br />
* [[User:Thozza| Thomas Hozza]] (thozza) - elected for F22/F23 period<br />
* [[User:Ajax| Adam Jackson]] (ajax) - elected for F22/F23 period<br />
* [[User:Pnemade| Parag Nemade]] (paragn) - elected for F22/F23 period<br />
* [[User:Rishi| Debarshi Ray]] (rishi) - elected for F22/F23 period<br />
<br />
<!--{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}--><br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=415562 Nominations June 2015]<br />
<br />
{{admon/note|Eligible Voters|Voting eligibility is determined by a community member's Fedora Account System ([https://admin.fedoraproject.org/accounts/ FAS]) memberships.<br/> <br/>To vote for [[Fedora_Engineering_Steering_Committee|FESCo]] you must have cla_done + one other "non-cla" group in FAS.}}<br />
<br />
== Candidate Nominations ==<br />
Please nominate just by Name, IRC nick and FAS account ID. A set of questions for candidates is being prepared, and the resulting introductions will be published in Fedora Magazine and/or Community Blog , at the end of the "Campaign" period.<br />
<br />
* NAME (IRC nick/FAS account ID)<br />
<br />
You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time.<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik / kevin)<br />
* [[User:Pnemade| Parag Nemade]] (paragn)<br />
* [[User:Jforbes| Justin Forbes]] (jforbes)<br />
* [[User:germano| Germano Massullo]] (Caterpillar / germano)<br />
<br />
[[Category:FESCo]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427910Changes/Darktable 2 02015-11-12T16:57:28Z<p>Germano: /* Dependencies */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus colord-gtk, cups, osmgpsmap, pugixml, and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427909Changes/Darktable 2 02015-11-12T16:56:44Z<p>Germano: /* Dependencies */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, plus pugixml, osmgpsmap, colord-gtk and gtk3* that replaced gtk2*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427907Changes/Darktable 2 02015-11-12T16:52:03Z<p>Germano: /* Detailed Description */</p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing software in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427903Changes/Darktable 2 02015-11-12T16:08:35Z<p>Germano: </p>
<hr />
<div>= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427902Changes/Darktable 2 02015-11-12T16:07:16Z<p>Germano: /* Change Proposal Name */</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}<br />
<br />
<!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= Darktable 2.0 <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427901Changes/Darktable 2 02015-11-12T16:06:50Z<p>Germano: /* Summary */</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}<br />
<br />
<!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= Change Proposal Name <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Update Darktable to new 2.0 major release<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427900Changes/Darktable 2 02015-11-12T16:06:03Z<p>Germano: /* How To Test */</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}<br />
<br />
<!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= Change Proposal Name <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germanohttps://fedoraproject.org/w/index.php?title=Changes/Darktable_2_0&diff=427899Changes/Darktable 2 02015-11-12T16:05:49Z<p>Germano: /* How To Test */</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}<br />
<br />
<!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= Change Proposal Name <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:madko| Madko]]<br />
* Name: [[User:germano| Germano Massullo]]<br />
<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24/ChangeSet | Fedora 24 ]]<br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1281478 #1281478]<br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
Darktable is one of the most important photo editing in the whole FOSS world. The 2.0 final version is going to be released in a few weeks, and it will be shipped in Fedora 24<br />
<br />
== Benefit to Fedora ==<br />
Darktable 2.0's improved support for newer cameras stresses that the FOSS world is a concrete alternative for professional (and not) photographers <br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: actually update Darktable package to 2.0 sources.<br />
<br />
* Other developers: nothing<br />
<br />
* Release engineering: no action required<br />
<br />
* Policies and guidelines: no new policy/guideline changes required.<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
Upgrade tested. Downgrade from 2.0 to 1.6.x not supported.<br />
<br />
== How To Test ==<br />
x86 64bit CPU only.<br />
You are expected to successfully open and edit photos already edited in Darktable 1.6.x<br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
The same of Darktable 1.6.x, except for gtk2* that has been replaced with gtk3*<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
https://github.com/darktable-org/darktable/releases/tag/release-2.0rc1<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
<!--[[Category:SelfContainedChange]] --><br />
[[Category:ChangePageIncomplete]]</div>Germano