https://en.opensuse.org/api.php?action=feedcontributions&user=Okurz&feedformat=atomopenSUSE Wiki - User contributions [en]2024-03-29T14:03:50ZUser contributionsMediaWiki 1.37.6https://en.opensuse.org/index.php?title=Portal:Aeon&diff=177791Portal:Aeon2023-07-20T06:47:01Z<p>Okurz: /* An Introduction to transactional-update */</p>
<hr />
<div>= openSUSE Aeon =<br />
<br />
{{Warning|On 27th May, openSUSE MicroOS Desktop was renamed to openSUSE Aeon, and the Plasma Desktop version is being renamed to [[Portal:Kalpa|openSUSE Kalpa]] . Please mind the dust while we migrate everything from MicroOS Desktop to the new names.}}<br />
<br />
{{Info|openSUSE Aeon provides only a minimal base system with a GNOME Desktop Environment and Basic Configuration Tools ONLY.<br />
All Applications, Browsers, Codecs, etc are provided by FlatPaks from FlatHub.}}<br />
<br />
{{Point here|[[Image:Icon-warning.png|48px|link=]]|<br />
openSUSE Aeon is still in a '''Release Candidate''' stage, please keep that in mind!<br />
}}<br />
----<br />
== Who is openSUSE Aeon for? ==<br />
It is NOT for everyone. Your highly customisable Tumbleweed & Leap Desktops are safe and will remain the best choice for those who want to tinker with their Desktop.<br />
<br />
It should be perfect for lazy developers, who no longer want to mess around with their desktop and just ”get stuff<br />
done”, especially if they develop around containers.<br />
<br />
It should also appeal to the same audience now more used to an iOS, Chromebook or Android-like experience where the OS is static, automated & reliable and the Apps are the main thing the user cares about.<br />
<br />
To deep dive on the origins and the case why some users should use openSUSE Aeon check out the following workshop: <br />
<br />
https://www.youtube.com/watch?v=lKYLF1tA4Ik&t=1794s<br />
<br />
----<br />
<br />
== Design Goals ==<br />
Aeon should be reliable, predictable & immutable, just like openSUSE MicroOS.<br />
<br />
Aeon should be less customisable than regular openSUSE Tumbleweed/Leap.<br />
<br />
Aeon should be small, but not at the expense of functionality. Printing, Gaming, Media Production and<br />
much more should all work.<br />
<br />
Aeon should just work “out of the box” without the need for additional configuration to get key functionality like software installation and web browsing working. All features offered by default should work - features that don't work shouldn't be offered/visible/available to users.<br />
----<br />
<br />
== How to Download and Install ==<br />
# Installation media is currently only available under the projects old name of 'MicroOS Desktop'<br />
# Download the openSUSE MicroOS base ISO image from https://en.opensuse.org/Portal:MicroOS/Downloads<br />
# Write the ISO on a USB drive and start the installation process.<br />
<br />
----<br />
<br />
== Ways to Install Applications in Order of Preference ==<br />
<br />
Now that you have installed Aeon, you probably want to install software. <br />
<br />
Because it provides only a minimal base system with a Desktop Environment, it is designed to come with only basic configuration tools by default. <br />
<br />
For this reason, All Applications, Browsers, Codecs needed for specific apps, etc are provided by FlatPaks from FlatHub. <br />
<br />
To make this process even easier for users, the Flathub repository of all available flatpaks have been integrated with Gnome Software. This way, you can simply search and find all your favorite apps in a seamless and integrated way.<br />
<br />
While there are other ways to install software, it is important to remember that it is STRONGLY recommended to install software in the following order of preference:<br />
<br />
# Flatpaks from your software center of choice or [https://flathub.org/home Flathub]<br />
# RPM's in a user distrobox ''distrobox-enter'' <br />
# RPM's in a root distrobox ''distrobox-enter -r''<br />
# RPM's via transactional-update -- for drivers, kernel modules, strictly what you need for your host operating system to work.<br />
<br />
'''To reiterate: EVERYTHING should be done via Flatpaks or be installed in a Distrobox if a package is not available as a flatpak. Using transactional-update is strictly what you need for your host operating system to work (exotic drivers, specialized vpn services).'''<br />
<br />
Note: Distrobox is shipped by default w/ Aeon. It allows users to install any linux distribution inside your terminal. For those who want to run GUI apps via a Distrobox can do so with a special export command so that apps feel more native and integrated with the system. Check out the [[https://en.opensuse.org/Portal:Aeon#DistroBox Distrobox section]] to learn more about this convenient way to launch distrobox based apps from your host menu launcher. <br />
<br />
==== An Introduction to transactional-update ====<br />
<br />
openSUSE Aeon does '''not''' use ''zypper'' like openSUSE Tumbleweed or openSUSE Leap to install RPM packages and use them directly. openSUSE Aeon uses '''transactional-update''' with zypper under the hood.<br />
<br />
Most of the time, you should not need to use any of these commands interactively, as Aeon has automatic system updates via the ''transactional-update.service'' systemd service.<br />
<br />
==== transactional-update - Example Commands ==== <br />
<br />
Commands for transactional-update are listed below. NOTE: Remember to reboot after the command is finished to see the changes!<br />
* ''sudo transactional-update pkg install package_name'' install a rpm package<br />
* ''sudo transactional-update pkg remove package_name'' remove an rpm package<br />
* ''sudo transactional-update dup'' perform a system upgrade to the next release<br />
* ''sudo transactional-update shell'' open a shell of the next snapshot (you can use zypper commands there). '''This should only be used for debugging purposes'''. Any bug report that can only be reproduced by using transactional-update shell is almost certain to be closed as WONTFIX.<br />
* ''sudo transactional-update rollback snapshot_number'' roll the system back to the numbered snapshot. Use 'last' instead of the snapshot number to roll back to the last working snapshot. '''Do not use snapper for rollbacks.'''<br />
<br />
==== transactional-update - Automatic Update ====<br />
<br />
By default ''transactional-update.timer'' handles automated system updates. This is set to ''daily'' which means that the task will be executed each day at 00:00:00.<br />
<br />
In the event this might be at a time when the computer is off, as the timer is set to persistance=true, then the update will then take place the first chance it can. <br />
<br />
Some of the reasons why it may not be able to trigger an update could be: <br />
<br />
* the computer was off<br />
* the internet connection was disturbed - at time it is scheduled to.<br />
<br />
This should not cause issues due to the way ''transactional-update'' works since the new packages are installed on a new snapshot for which to take effect you must reboot.<br />
<br />
To track if ''transactional-update'' is able to upgrade, and run correctly you can use ''journalctl'':<br />
<br />
$ sudo journalctl -u transactional-update.service <br />
<br />
You can also use ''journalctl'' with the ''-f'' flag to tail the logs in real time.<br />
<br />
==== transactional-update - --Final Words About Snapshots and Boot Behavior ====<br />
By default, each ''transactional-update'' command produces a seperate, self-contained, snapshot that includes the changes requested by the ''transactional-update'' command.<br />
<br />
This snapshot is '''BASED ON THE LAST KNOWN GOOD/BOOTED SNAPSHOT'''. The last of the snapshots produced by multiple ''transactional-update'' commands then takes effect when rebooting.<br />
<br />
In other words ''sudo transactional-update pkg install $pkg1'' followed by ''sudo transactional-update pkg install $pkg2'' and then rebooting results in a system that has $pkg2 installed, but NOT $pkg1.<br />
<br />
This is the expected, and sensible default behaviour - Aeon always wants to move from the last known good/booted snapshot to it's new state in the smallest, least disruptive way possible.<br />
<br />
This is especially sensible when you think the default/expected behaviour is that Aeon updates itself automatically and most users should not be using ''transactional-update'' interactively at all. With ''transactional-update dup'' happening regularly in the background automatically, Aeon wants to make sure it's updating only to the latest clean system update state, not some weird hybrid of previous unbooted, unchecked, intermediate ''transactional-update dup'' that never got booted.<br />
<br />
However, when ignoring this best practice and using ''transactional-update'' interactively, there may be times where you wish to run ''transactional-update'' against an existing unbooted, unknown-if-good snapshot.<br />
<br />
For this use ''transactional-update --continue''<br />
<br />
Example:<br />
<br />
''sudo transactional-update pkg install $pkg1'' followed by ''sudo transactional-update --continue pkg install $pkg2'' will install $pkg1, then $pkg2 in the same snapshot that included $pkg1, marking that combined snapshot as the next boot target.<br />
<br />
If problems occur however, there is no additional complexity figuring out whether it was $pkg1 or $pkg2 that broke anything, as users will need to rollback to the snapshot before $pkg1 was installed to return to the last known good state.<br />
----<br />
<br />
== GNOME Software + Flathub Integration ==<br />
Gnome is currently in a '''RC''' stage.<br />
<br />
* At first boot flatpaks are enabled and some flatpaks are installed by default (Mozilla Firefox, Text Editor, Gnome Calculator and Extension Manager).<br />
<br />
* After the first boot script finishes you can open Gnome Software to install more software from flathub. <br />
<br />
----<br />
<br />
== DistroBox ==<br />
<br />
''Distrobox'' can be used like toolbox (which is included on the server version of MicroOS by default), but has some other advantages for desktop usage.<br />
Please refer to https://github.com/89luca89/distrobox for all options.<br />
<br />
[[Distrobox|For more documentation, see the Distrobox Page]]<br />
----<br />
<br />
== Troubleshooting ==<br />
<br />
This section describes known issues on openSUSE Aeon and their solutions.<br />
<br />
==== Set hostname ====<br />
<br />
Set your hostname with the following command, as currently it doesn't work from Gnome Settings yet:<br />
<br />
# sudo hostnamectl set-hostname <new name><br />
<br />
Reboot and hostname change will take effect. <br />
<br />
==== Adjust transactional-update.timer ====<br />
<br />
Depending on your daily use case, the Timer may not trigger the automatic update process successfully even with persistent=true because it adds a randomized delay at each boot with ''RandomizedDelaySec'' <br />
<br />
If you want automatic ''daily'' updates to your system, you may find that you need to adjust that delay mentioned. <br />
<br />
Edit transactional-update.timer:<br />
<br />
# sudo systemctl edit transactional-update.timer<br />
<br />
Add the following lines to create a override.conf (located in /etc/systemd/system/transactional-update.timer.d/override.conf)<br />
<syntaxhighlight lang="ini"><br />
[Timer]<br />
RandomizedDelaySec=10m<br />
</syntaxhighlight><br />
The example above is for a randomized delay of max. 10 minutes. (Default value is 2h)<br />
<br />
Change the time to your use case.<br />
<br />
==== Steam Proton, Bottles, WINE, Lutris, Android Studio emulator not working from flatpaks ====<br />
<br />
If you run into issues using WINE, and WINE based programs in flatpaks, it is likely due to an SELinux issue, and can be checked by running:<br />
<br />
# sudo getsebool selinuxuser_execmod<br />
<br />
For Android Studio:<br />
<br />
# sudo getsebool selinuxuser_execstack<br />
<br />
If that returns 'selinuxuser_execmod --> disabled' and 'selinuxuser_execstack --> disabled' you will need to enable it. This can be done temporarily (resets on next boot)<br />
<br />
For WINE:<br />
# sudo setsebool selinuxuser_execmod 1<br />
<br />
For Android Studio:<br />
# sudo setsebool selinuxuser_execstack 1<br />
<br />
Or can be set Persistent:<br />
<br />
# sudo setsebool -P selinuxuser_execmod 1<br />
# sudo setsebool -P selinuxuser_execstack 1<br />
<br />
The openSUSE Security team is reviewing these default policies, and you are enabling this at your own risk. See https://bugzilla.opensuse.org/show_bug.cgi?id=1206292 & https://bugzilla.opensuse.org/show_bug.cgi?id=1206789 for further information.<br />
<br />
----<br />
<br />
== Reporting Bugs ==<br />
<br />
Please use the following link for reporting bugs: [https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE+Aeon&format=guided Report a bug for openSUSE Aeon]<br />
<br />
Please see [[openSUSE:Submitting_bug_reports|Submitting Bug Reports]] for more information on how best to file a bug<br />
<br />
== Place for questions ==<br />
As openSUSE Aeon has various places discuss the project<br />
<br />
* ''Telegram'': https://t.me/openSUSE_Aeon<br />
* ''Matrix'': https://matrix.to/#/#aeon:opensuse.org<br />
* ''Discord'': https://discord.gg/opensuse #aeon-kalpa channel<br />
<br />
All these channels are bridged together via Matrix, so sending your comments in one, will be seen in the other two.<br />
<br />
[[nl:Portal:Aeon]]<br />
<br />
[[Category:Aeon]]<br />
[[Category:Kalpa]]</div>Okurzhttps://en.opensuse.org/index.php?title=Portal:Aeon&diff=177788Portal:Aeon2023-07-20T06:44:53Z<p>Okurz: /* Who is openSUSE Aeon for? */ Fix casing</p>
<hr />
<div>= openSUSE Aeon =<br />
<br />
{{Warning|On 27th May, openSUSE MicroOS Desktop was renamed to openSUSE Aeon, and the Plasma Desktop version is being renamed to [[Portal:Kalpa|openSUSE Kalpa]] . Please mind the dust while we migrate everything from MicroOS Desktop to the new names.}}<br />
<br />
{{Info|openSUSE Aeon provides only a minimal base system with a GNOME Desktop Environment and Basic Configuration Tools ONLY.<br />
All Applications, Browsers, Codecs, etc are provided by FlatPaks from FlatHub.}}<br />
<br />
{{Point here|[[Image:Icon-warning.png|48px|link=]]|<br />
openSUSE Aeon is still in a '''Release Candidate''' stage, please keep that in mind!<br />
}}<br />
----<br />
== Who is openSUSE Aeon for? ==<br />
It is NOT for everyone. Your highly customisable Tumbleweed & Leap Desktops are safe and will remain the best choice for those who want to tinker with their Desktop.<br />
<br />
It should be perfect for lazy developers, who no longer want to mess around with their desktop and just ”get stuff<br />
done”, especially if they develop around containers.<br />
<br />
It should also appeal to the same audience now more used to an iOS, Chromebook or Android-like experience where the OS is static, automated & reliable and the Apps are the main thing the user cares about.<br />
<br />
To deep dive on the origins and the case why some users should use openSUSE Aeon check out the following workshop: <br />
<br />
https://www.youtube.com/watch?v=lKYLF1tA4Ik&t=1794s<br />
<br />
----<br />
<br />
== Design Goals ==<br />
Aeon should be reliable, predictable & immutable, just like openSUSE MicroOS.<br />
<br />
Aeon should be less customisable than regular openSUSE Tumbleweed/Leap.<br />
<br />
Aeon should be small, but not at the expense of functionality. Printing, Gaming, Media Production and<br />
much more should all work.<br />
<br />
Aeon should just work “out of the box” without the need for additional configuration to get key functionality like software installation and web browsing working. All features offered by default should work - features that don't work shouldn't be offered/visible/available to users.<br />
----<br />
<br />
== How to Download and Install ==<br />
# Installation media is currently only available under the projects old name of 'MicroOS Desktop'<br />
# Download the openSUSE MicroOS base ISO image from https://en.opensuse.org/Portal:MicroOS/Downloads<br />
# Write the ISO on a USB drive and start the installation process.<br />
<br />
----<br />
<br />
== Ways to Install Applications in Order of Preference ==<br />
<br />
Now that you have installed Aeon, you probably want to install software. <br />
<br />
Because it provides only a minimal base system with a Desktop Environment, it is designed to come with only basic configuration tools by default. <br />
<br />
For this reason, All Applications, Browsers, Codecs needed for specific apps, etc are provided by FlatPaks from FlatHub. <br />
<br />
To make this process even easier for users, the Flathub repository of all available flatpaks have been integrated with Gnome Software. This way, you can simply search and find all your favorite apps in a seamless and integrated way.<br />
<br />
While there are other ways to install software, it is important to remember that it is STRONGLY recommended to install software in the following order of preference:<br />
<br />
# Flatpaks from your software center of choice or [https://flathub.org/home Flathub]<br />
# RPM's in a user distrobox ''distrobox-enter'' <br />
# RPM's in a root distrobox ''distrobox-enter -r''<br />
# RPM's via transactional-update -- for drivers, kernel modules, strictly what you need for your host operating system to work.<br />
<br />
'''To reiterate: EVERYTHING should be done via Flatpaks or be installed in a Distrobox if a package is not available as a flatpak. Using transactional-update is strictly what you need for your host operating system to work (exotic drivers, specialized vpn services).'''<br />
<br />
Note: Distrobox is shipped by default w/ Aeon. It allows users to install any linux distribution inside your terminal. For those who want to run GUI apps via a Distrobox can do so with a special export command so that apps feel more native and integrated with the system. Check out the [[https://en.opensuse.org/Portal:Aeon#DistroBox Distrobox section]] to learn more about this convenient way to launch distrobox based apps from your host menu launcher. <br />
<br />
==== An Introduction to transactional-update ====<br />
<br />
openSUSE Aeon does '''not''' use ''zypper'' like openSUSE Tumbleweed or openSUSE Leap to install RPM packages and use them directly. openSUSE Aeon uses '''transactional-update''' with zypper under the hood.<br />
<br />
Most of the time, you should not need to use any of these commands interactively, as Aeon has automatic system updates via a the ''transactional-update.service'' systemd service.<br />
<br />
==== transactional-update - Example Commands ==== <br />
<br />
Commands for transactional-update are listed below. NOTE: Remember to reboot after the command is finished to see the changes!<br />
* ''sudo transactional-update pkg install package_name'' install a rpm package<br />
* ''sudo transactional-update pkg remove package_name'' remove an rpm package<br />
* ''sudo transactional-update dup'' perform a system upgrade to the next release<br />
* ''sudo transactional-update shell'' open a shell of the next snapshot (you can use zypper commands there). '''This should only be used for debugging purposes'''. Any bug report that can only be reproduced by using transactional-update shell is almost certain to be closed as WONTFIX.<br />
* ''sudo transactional-update rollback snapshot_number'' roll the system back to the numbered snapshot. Use 'last' instead of the snapshot number to roll back to the last working snapshot. '''Do not use snapper for rollbacks.'''<br />
<br />
==== transactional-update - Automatic Update ====<br />
<br />
By default ''transactional-update.timer'' handles automated system updates. This is set to ''daily'' which means that the task will be executed each day at 00:00:00.<br />
<br />
In the event this might be at a time when the computer is off, as the timer is set to persistance=true, then the update will then take place the first chance it can. <br />
<br />
Some of the reasons why it may not be able to trigger an update could be: <br />
<br />
* the computer was off<br />
* the internet connection was disturbed - at time it is scheduled to.<br />
<br />
This should not cause issues due to the way ''transactional-update'' works since the new packages are installed on a new snapshot for which to take effect you must reboot.<br />
<br />
To track if ''transactional-update'' is able to upgrade, and run correctly you can use ''journalctl'':<br />
<br />
$ sudo journalctl -u transactional-update.service <br />
<br />
You can also use ''journalctl'' with the ''-f'' flag to tail the logs in real time.<br />
<br />
==== transactional-update - --Final Words About Snapshots and Boot Behavior ====<br />
By default, each ''transactional-update'' command produces a seperate, self-contained, snapshot that includes the changes requested by the ''transactional-update'' command.<br />
<br />
This snapshot is '''BASED ON THE LAST KNOWN GOOD/BOOTED SNAPSHOT'''. The last of the snapshots produced by multiple ''transactional-update'' commands then takes effect when rebooting.<br />
<br />
In other words ''sudo transactional-update pkg install $pkg1'' followed by ''sudo transactional-update pkg install $pkg2'' and then rebooting results in a system that has $pkg2 installed, but NOT $pkg1.<br />
<br />
This is the expected, and sensible default behaviour - Aeon always wants to move from the last known good/booted snapshot to it's new state in the smallest, least disruptive way possible.<br />
<br />
This is especially sensible when you think the default/expected behaviour is that Aeon updates itself automatically and most users should not be using ''transactional-update'' interactively at all. With ''transactional-update dup'' happening regularly in the background automatically, Aeon wants to make sure it's updating only to the latest clean system update state, not some weird hybrid of previous unbooted, unchecked, intermediate ''transactional-update dup'' that never got booted.<br />
<br />
However, when ignoring this best practice and using ''transactional-update'' interactively, there may be times where you wish to run ''transactional-update'' against an existing unbooted, unknown-if-good snapshot.<br />
<br />
For this use ''transactional-update --continue''<br />
<br />
Example:<br />
<br />
''sudo transactional-update pkg install $pkg1'' followed by ''sudo transactional-update --continue pkg install $pkg2'' will install $pkg1, then $pkg2 in the same snapshot that included $pkg1, marking that combined snapshot as the next boot target.<br />
<br />
If problems occur however, there is no additional complexity figuring out whether it was $pkg1 or $pkg2 that broke anything, as users will need to rollback to the snapshot before $pkg1 was installed to return to the last known good state.<br />
----<br />
<br />
== GNOME Software + Flathub Integration ==<br />
Gnome is currently in a '''RC''' stage.<br />
<br />
* At first boot flatpaks are enabled and some flatpaks are installed by default (Mozilla Firefox, Text Editor, Gnome Calculator and Extension Manager).<br />
<br />
* After the first boot script finishes you can open Gnome Software to install more software from flathub. <br />
<br />
----<br />
<br />
== DistroBox ==<br />
<br />
''Distrobox'' can be used like toolbox (which is included on the server version of MicroOS by default), but has some other advantages for desktop usage.<br />
Please refer to https://github.com/89luca89/distrobox for all options.<br />
<br />
[[Distrobox|For more documentation, see the Distrobox Page]]<br />
----<br />
<br />
== Troubleshooting ==<br />
<br />
This section describes known issues on openSUSE Aeon and their solutions.<br />
<br />
==== Set hostname ====<br />
<br />
Set your hostname with the following command, as currently it doesn't work from Gnome Settings yet:<br />
<br />
# sudo hostnamectl set-hostname <new name><br />
<br />
Reboot and hostname change will take effect. <br />
<br />
==== Adjust transactional-update.timer ====<br />
<br />
Depending on your daily use case, the Timer may not trigger the automatic update process successfully even with persistent=true because it adds a randomized delay at each boot with ''RandomizedDelaySec'' <br />
<br />
If you want automatic ''daily'' updates to your system, you may find that you need to adjust that delay mentioned. <br />
<br />
Edit transactional-update.timer:<br />
<br />
# sudo systemctl edit transactional-update.timer<br />
<br />
Add the following lines to create a override.conf (located in /etc/systemd/system/transactional-update.timer.d/override.conf)<br />
<syntaxhighlight lang="ini"><br />
[Timer]<br />
RandomizedDelaySec=10m<br />
</syntaxhighlight><br />
The example above is for a randomized delay of max. 10 minutes. (Default value is 2h)<br />
<br />
Change the time to your use case.<br />
<br />
==== Steam Proton, Bottles, WINE, Lutris, Android Studio emulator not working from flatpaks ====<br />
<br />
If you run into issues using WINE, and WINE based programs in flatpaks, it is likely due to an SELinux issue, and can be checked by running:<br />
<br />
# sudo getsebool selinuxuser_execmod<br />
<br />
For Android Studio:<br />
<br />
# sudo getsebool selinuxuser_execstack<br />
<br />
If that returns 'selinuxuser_execmod --> disabled' and 'selinuxuser_execstack --> disabled' you will need to enable it. This can be done temporarily (resets on next boot)<br />
<br />
For WINE:<br />
# sudo setsebool selinuxuser_execmod 1<br />
<br />
For Android Studio:<br />
# sudo setsebool selinuxuser_execstack 1<br />
<br />
Or can be set Persistent:<br />
<br />
# sudo setsebool -P selinuxuser_execmod 1<br />
# sudo setsebool -P selinuxuser_execstack 1<br />
<br />
The openSUSE Security team is reviewing these default policies, and you are enabling this at your own risk. See https://bugzilla.opensuse.org/show_bug.cgi?id=1206292 & https://bugzilla.opensuse.org/show_bug.cgi?id=1206789 for further information.<br />
<br />
----<br />
<br />
== Reporting Bugs ==<br />
<br />
Please use the following link for reporting bugs: [https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE+Aeon&format=guided Report a bug for openSUSE Aeon]<br />
<br />
Please see [[openSUSE:Submitting_bug_reports|Submitting Bug Reports]] for more information on how best to file a bug<br />
<br />
== Place for questions ==<br />
As openSUSE Aeon has various places discuss the project<br />
<br />
* ''Telegram'': https://t.me/openSUSE_Aeon<br />
* ''Matrix'': https://matrix.to/#/#aeon:opensuse.org<br />
* ''Discord'': https://discord.gg/opensuse #aeon-kalpa channel<br />
<br />
All these channels are bridged together via Matrix, so sending your comments in one, will be seen in the other two.<br />
<br />
[[nl:Portal:Aeon]]<br />
<br />
[[Category:Aeon]]<br />
[[Category:Kalpa]]</div>Okurzhttps://en.opensuse.org/index.php?title=Software_TPM_Emulator_For_QEMU&diff=160272Software TPM Emulator For QEMU2021-10-21T10:00:52Z<p>Okurz: Update reference to installable package from openSUSE Tumbleweed</p>
<hr />
<div>== Introduction ==<br />
<br />
Trusted Platform Module (TPM) is a component to provide several security functions, e.g. encryption, random number generation, measurement, etc., and now widely deployed among the new machines due to the requirement of Windows 10 certification. For the developers who want to use TPM to develop the security features, a software TPM emulator is usually a good choice. Before 2.11, QEMU can only do TPM passthrough to access the TPM hardware on the host, and this limits the number of guests to access TPM. Besides, the developers are also limited by the hardware capabilities. It's impossible to develop the TPM 2.0 features with a TPM 1.2 chip. Fortunately, since 2.11, QEMU starts to support the TPM emulator. With TPM emulator, the guest can switch between TPM 1.2 and TPM 2.0 easily, and this makes the developer's life much easier.<br />
<br />
== Install the Software TPM Emulator ==<br />
<br />
The software TPM emulator [https://github.com/stefanberger/swtpm swtpm] is curently included in openSUSE Tumbleweed. For other products and versions the packages are available in the "security" repo:<br />
<br />
https://software.opensuse.org//download.html?project=security&package=swtpm<br />
<br />
Just download libtpms0 and swtpm and install them.<br />
<br />
== Setup a TPM Emulator ==<br />
<br />
swtpm provides 3 types of interface: socket, chardev, and cuse. Here we choose "socket" since it's the only type that doesn't need to create a node in /dev. First, create a directory to store the TPM states right inside the VM directory:<br />
<br />
$ mkdir ${path_to_vm}/mytpm0<br />
<br />
And then, start the emulator to create a socket file, swtpm-sock, for QEMU.<br />
<br />
$ swtpm socket --tpmstate dir=${path_to_vm}/mytpm0 \<br />
--ctrl type=unixio,path=${path_to_vm}/mytpm0/swtpm-sock \<br />
--log level=20<br />
<br />
By default, swtpm starts a TPM 1.2 emulator and stores the states in "tpm-00.permall" in the directory. It's also possible to create a TPM 2.0 instance:<br />
<br />
$ swtpm socket --tpm2 --tpmstate dir=${path_to_vm}/mytpm0 \<br />
--ctrl type=unixio,path=${path_to_vm}/mytpm0/swtpm-sock \<br />
--log level=20<br />
<br />
The TPM 2.0 states will be stored in "tpm2-00.permall". If you want swtpm to run in the background, just add "-d" to daemonize it.<br />
<br />
== Start QEMU along with swtpm ==<br />
<br />
Once you start swtpm, add the following QEMU parameters to create the TPM device:<br />
<br />
-chardev socket,id=chrtpm,path=${path_to_vm}/mytpm0/swtpm-sock \<br />
-tpmdev emulator,id=tpm0,chardev=chrtpm \<br />
-device tpm-tis,tpmdev=tpm0<br />
<br />
Then, a TPM device will be available in the guest, and "tpm_version" would show you:<br />
<br />
TPM 1.2 Version Info:<br />
Chip Version: 1.2.18.158<br />
Spec Level: 2<br />
Errata Revision: 3<br />
TPM Vendor ID: IBM<br />
TPM Version: 01010000<br />
Manufacturer Info: 49424d00<br />
<br />
== Start swtpm with libvirt ==<br />
<br />
If you use libvirt, add the following TPM emulator device to template:<br />
<br />
</devices><br />
<tpm model='tpm-tis'><br />
<backend type='emulator' version='2.0'/><br />
</tpm><br />
</devices><br />
<br />
libvirt will start swtpm as the TPM emulator for the guest VM.<br />
'''You don't need to launch swtpm daemon by yourself.'''<br />
<br />
The tpm-crb TPM model can also be used, but it's only for TPM 2.0.<br />
<br />
The corresponding permall file will be created automatically in /var/lib/libvirt/swtpm/[VM_UUID]<br />
<br />
e.g.<br />
# ls /var/lib/libvirt/swtpm/00c1ee41-3150-4d24-80b4-ab032732653c/tpm2/<br />
.lock tpm2-00.permall<br />
<br />
The above UUID follows the number in libvirt template.<br />
<br />
==TPM measurement in OVMF==<br />
<br />
If you use OVMF firmware for the guest, then the firmware will measure components with TPM.<br />
<br />
After booting, kernel exposes the event log by securityfs:<br />
/sys/kernel/security/tpm0/binary_bios_measurements<br />
<br />
== See also ==<br />
* [http://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt http://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt]<br />
* [https://libvirt.org/formatdomain.html#elementsTpm https://libvirt.org/formatdomain.html#elementsTpm]</div>Okurzhttps://en.opensuse.org/index.php?title=Portal:15.2/Retrospective&diff=146002Portal:15.2/Retrospective2020-08-08T07:38:30Z<p>Okurz: Add missing space to clear URL</p>
<hr />
<div>Original document used for retro: https://etherpad.opensuse.org/p/ReleaseEngineering-Leap-15.2-retro-20200804<br />
<br />
<br />
== openSUSE Leap 15.2 Retrospective ==<br />
<br />
First round attendees (20200706): bmwiedemann, ddemaio, fvogt, okurz, jsegitz, meissner, szarate, GuillaumeG, Michel Normand, Lubos Kocman, maxlin<br />
<br />
Second round attendees (20200806) morning: Max, Doug, Antonio, Yifan, Marina<br />
Third round attendees (20200806) afternoon: Doug, Lubos, Sarah, Antonio, Michal K.<br />
Fourth round attendees (20200807) morning: Lubos, Doug, Antonio, Michal K., Max, Marina<br />
<br />
<br />
<br />
I'd like to do it on two rounds, first with core team, and then with whoever participated on https://progress.opensuse.org/projects/leap_152/issues/<br />
<br />
Raw data: https://progress.opensuse.org/projects/leap152retro/documents<br />
Last line processed: Line 83 in the spreadsheet lubos: Thank you!<br />
<br />
<br />
== What went well ==<br />
<br />
got plenty media coverage<br />
https://www.heise.de/news/openSUSE-Leap-15-2-Support-fuer-AI-OCI-Container-YaST-wird-besser-4836133.html<br />
https://linuxnews.de/2020/07/opensuse-leap-15-2-ist-fertig/<br />
https://www.linux-magazin.de/news/opensuse-leap-15-2-ist-fertig/<br />
working .torrent files via MirrorBrain http://tracker.opensuse.org:6969/stat<br />
Linode and Netcup started offering leap 15.2 images 1-2 days after<br />
openQA setup is stable and not demanding much (or hardly any) work<br />
<br />
=== Installation experience ===<br />
* 15.2 turns out to be just as solid and impressive as previous versions. Way back in the day, the rule was "only use odd-numbered version of SuSE" but those days are long gone.<br />
* Clean install in less than two hours on a laptop and home media center, very predictable results<br />
* Ease of setting up using existing partitions from a 15.1 installation +2<br />
* All packages and downloads and installation went well<br />
* Smooth and/or easy installation experience +14<br />
* Uneventful<br />
* Install of Gnome and Plasma without problems +2<br />
* I have done a few clean installs. Most works very smoothly.<br />
* I have installed openSUSE Leap 15.2 on the Medion E2291, which is a dual cored 11 zoll notebook. It works well on the notebook. Every hardware, also including the webcam was recognized by the operating system. I had no problems during the installation process.<br />
* Lenovo L470 and Lenovo x250 had issueless installations<br />
* Offline upgrade from 15.1 worked well. Good selection of software, I like the "Generic Desktop" install option as a starting point.<br />
* Installation without bootloader for use with refind (http://www.rodsbooks.com/refind/) went smooth.<br />
* Everything worked out of the box! It's new for me, on previous releases I had to do a lot of manual configuration.<br />
* I was very happy that the installer mentioned that the nouveau driver was selected, but is known to be buggy. In my case, I immediately deselected it because I have a laptop with intel and nvidia and don't care about the nvidia chip.<br />
* Installation process is now much better. Installer is easier to navigate (especially network settings), it's also much more verbose and easier to understand. Updated packages are always greeted with joy :D<br />
* Better integration of online repositories than before<br />
* I updated 2 homebuilt desktop PCs to Leap 15.2 with no problems (i have had issues with earlier versions) very happy with the upgrade process Painless and relatively quick.<br />
* This (openSUSE Leap 15.2) was my first OpenSUSE install that I remember. The installer is very very intuitive and the whole installation process was fairly fast (and yes I love the Gecko and green color theme).<br />
* Previous releases did not go as smooth with my ASUS Zenbook..... I had to resort to some GRUB manual configuration to "save" the installation. Moreover, the USB was not properly configured using 'imagewriter'. With Leap 15.2 none of those problems happened :) Thank you for the hard work!!<br />
* It was easier to add the network during installation compared to opensuse 15.1<br />
* As always, the flexibility of the installer is appreciated.<br />
* Hi. The install of OpenSuse Leap 15.2 was easy and all hardware is supported on my Lenovo Yoga C740. Haven’t tested the stylus, but I’m sure it’ll work. Using Gnome Desktop Environment. <br />
* I'm really impressed by the overall speed using the network installation ISO<br />
* I liked the easiness of customizing the packages during install, mitigation options, very flexible partitioning <br />
* I liked to being able to fine tune installation and select packages that I wanted and deselect the packages I didn't want. <br />
* I haven't used OpenSUSE before 15.2, but the installer has the best partition manager I've seen and is incredibly flexible with software configuration, all of my hardware was functional immediately, performance is great even on old hardware, and YaST is a dream to work with.<br />
<br />
===== Action items =====<br />
Reach out to yast and let them know that partitioning has a success<br />
HCL (hardware compatibility list) wiki<br />
KUDOS for Yast team<br />
<br />
=== Upgrade experience ===<br />
* updated from 13.2 directly to 15.2, no steps in between, went very well<br />
* I've been with openSUSE since, I believe, 9.3. This release is one of more seamless. So far I found only one (minor) degradation with an easy workaround.<br />
* 50+ machines update from 15.1 to 15.2 with no issues<br />
* 2 machines upgraded from 15.1 to 15.2 with no issues +2<br />
* I did a number of upgrades from 15.1 and they all went flawlessly. They all performed better after the upgrade. Desktops and laptops got a really nice UI update as well.<br />
* Smooth upgrade +30<br />
* Smooth upgrade of 15.1 VMs<br />
* Seamless Online Upgrade Process with good documentation<br />
* Smooth offline upgrade +2<br />
* I was able to upgrade via both the offline and online routes with absolutely no issues. Most of my packages ticked up in version and saw nice upgrades without any disruption. <br />
* I used zypper dup --download-only prior to dup. No suprises there. After upgrade and reboot, machine refused to start X server. Quick Ctrl + Alt + F1 followed with login and system update fixed this issue. +2<br />
* Update of 3000 packages under 20 minutes<br />
* Update was very smooth, especially unexpectedly smooth regarding package dependencies, though I had quit a lot customisations in my systems regarding packages. In my own system I had especially big number of packages from OBS projects, but still updating these packages was relatively very smooth.<br />
* Options to deactivate certain repos<br />
* Offline upgrade from 15.1 to 15.2 was pretty boring, just as I like my OS upgrades :)<br />
* Using $releasever in repos helps a lot, user was able to convert also OBS repos easily and do migration all in once<br />
* I like that the repos are now defined with a $releasever variable, this will avoid having to change<br />
* /etc/zypp/repos.d with sed in the future.<br />
* I was surprised by the updated documentation for the update with zypper --dup that now supports the $releasever variable. I found this option great (I had already seen it in Fedora and CentOS) and I see that I am getting ready for the next update next year.<br />
* I was positively surprised that an Upgrade was a simple `zypper --releasever=15.2 ref` and no sed-hackery.<br />
* Seamless migration experience since Leap 42.1 (In Polish)<br />
* Direct migration from 42.3 with no issue, system feels more responsive then 42.3<br />
* USB Update was painless<br />
* Painless upgrade, everything works, reasonable improvements<br />
* Real smooth update, new option for zypper for user to select 15.2, was excellent<br />
* Used SUSE since version 6; when upgrade from leap 15.0 to 15.2, all of the program put on the place including all of the preferences, icon arrangement unchanged. "I almost felt asleep upgraded to 15.2". no issue trapped. <br />
* Most Stuff works<br />
* I was really surprised, that everything went without any problems on all my machines. I updated three server machines from 15.1 to 15.2. It costed me about 2 hours and - a said above - everything was in place after the update.<br />
* Just upgraded with zypper. No need of a side-by-side installation.<br />
* I've been using openSUSE for 20+ years. I was so confident about the upgrade process that I decided to upgrade my work laptop even before it was officially release. Perhaps the positives about the upgrade was that my confidence was not shaken. Everything went smoothly as expected.<br />
* I updated from openSUSE 15.1 a couple of days ago using CLI (zypper refresh, zypper update). As a developer, I have many repositories including third party. One could not ask for a smoother upgrade. The only minor issues I had recompiling software was a few "depreciated" warnings. I have had no crashes of any kind - either system or application as a result of the upgrade. Good job, openSUSE Team!!!<br />
* Update fast and safe. The update wizard was easy and it cleans repository in a right way. The new graphic is pretty. The system seems to be solid and fast<br />
<br />
===== Action item =====<br />
Improve documentation for the $releasever. <br />
Improve documentation for cases with non-standard repos (e.g. not everybody knows --allow-vendor-change)<br />
<br />
KUDOS to the installer team for smooth migration experience.<br />
KUDOS to the documentation team for quality of documentation.<br />
Highlight that we received positive feedback to the theme (twice mentioned).<br />
^ Doug mentioned that refresh of graphics would happen always with a new code-stream (e.g. Leap 16)<br />
Raise the fact that users are migrating from relatively old releases.<br />
<br />
=== Keeping family open ===<br />
* My mother even did not noticed changes after update (in good meaning): no drastical changes, no problems arrised. (KDE)<br />
* Am on SuSE since ~7.0. Managed to keep my family M$ free ever since (not always easy). The openSUSE 15.x releases have been the most easiest to migrate (1 server, 2 desksides, 4 laptops) and I guess 15.2 has been the best experience ever!<br />
<br />
=== Migration from other distributions ===<br />
* Moved server, desktop and laptop to openSUSE Leap 15.2 from Debian, all went smoothly and the process was very straightforward. Am very happy with the whole process.<br />
* First time user of openSUSE. Compared to the .deb based distro I was using, every thing is just better. From installer allowing you to make choices to xfce set up in a sensible way. Documentation is also better. The last distro boot sequence docs were based on a 2.6 kernel.<br />
<br />
* I actually came from the tumbleweed version. What I didn't like was that the snap store and the software downloaded from there were not working properly. I tried this OS version because people said that this was a more stable one, and for me that's true. As a newbie in Linux, the installation process worked fast and this was the only version of Linux that worked well with my laptop from the ones I tried before.<br />
* Everything went smooth. Made fresh install (coming from Tumbleweed). Previous stable release (15.1) did not work on my machine which uses quite new components, thus started using Tumbleweed. Since it is machine for work, wanted to switch to stable as soon as possible. So far (about 2 weeks), Leap 15.2 is working excellent.<br />
* I was so impressed by the XFCE Gecko release DVD that I installed it on my computer from Manjaro XFCE. I have never had a a Live DVD work so well. It allowed easily to set up sound, printers, AMD drivers and AMD GPU drivers, and even to download things. RARE indeed. <br />
* high speed of the system in comparison with distributions Ubuntu-based. I like the openSUSE site, the history of openSUSE, the freedom of openSUSE (there is no Novell). (translated from Russian)<br />
<br />
===== Action items =====<br />
Reach out to Gecko linux folks<br />
Check on the documentation referencing 2.6 kernel (is it us?)<br />
<br />
=== Printing ===<br />
* I recently bought a home Brother printer-scanner that is quite a challenge to install and function as intended. I have had almost no success through multiple distros, including Tumbleweed. But, by running the manufacturer's installer file and rebooting, it works absolutely perfectly with Leap 15.2.<br />
* I had bought a new printer, and feared that it might not work. It does perfectly.<br />
<br />
=== User Experience ===<br />
* You people have got it right. Linux is no longer for geeks. It is smooth, slick and fast.<br />
* I'm satisfied with the new release<br />
* Noob-friendly default configurations, Wider coverage in software with release-official support,at least for what I may need.<br />
* Stable as usual, grateful for the work, Good for stability. Läuft sehr stabil. Très bon produit.... Merci. <br />
* The final release was elegant and stable. (let's say a lot of)<br />
* 15.2 resolved a year-long issue with swap, super happy (issue not described).<br />
* Almost everything went well<br />
* Both GNOME and KDE installatations with no issues, both done by a Long time Linux user who prefers openSUSE<br />
* Nice overall experience with GNOME, very stable, good selection of pre-installed apps, YAST improvements, just some minor issues<br />
* Outside the release, really satisfied with openSUSE. This project has complete product, good infrastructure, good documentation, and solid community. <br />
* Defaults are very good. <br />
* New exciting number of software is nice. <br />
* Welcome app is very good and very welcome. <br />
* Nothing significant changed but I feel comfortable with the performance of openSUSE Leap 15.2<br />
* Very cool and was top. Congratulations (in Spanish)<br />
* It simply runs on anything all the time.<br />
* The interface and feel looks better like every update. (not specified which WM)<br />
* Solid base for your computer! Core features (installer, yast, zypper, snapper, well-curated KDE and Gnome software) work really well.<br />
* New Kernel could not change screen resolution but it's not a Opesuse problem but enything below kernel 5 won't work well on my desktop pc.<br />
* I've used OpenSUSE for ~20 years. The positive is that things have always worked well. I've had so few issues with ever release that I've stayed a SUSE user all these years. So pleased with everyone's hard work and contributions.<br />
* Reasonable improvements<br />
* the new version is really excellent and powerful. it works well on the hardware, i have a dell laptop and it's really beautiful. thanks for your efforts and i hope for every one to be in good health.<br />
* Nice release, so far, and I've been using SuSE since 5.2. Installed on two gamer laptops and one SuperMicro server. On laptop went perfectly, everything worked, including the special function keys to adjust audio volume and screen brightness. The second laptop, different brand, couldn't adjust screen brightness with the Fn keys, but everything else seemed to work. But it didn't have a WiFi radio, it was removed for security reasons.<br />
* The server install went well, it has 512-GB of RAM, NvME system memory, SATA SSD drives, and a AVAGO raid controller with two volumes sharing 36 14-TB Seagate SAS disks. All in all, good job! Thanks to all you folks for all you do.<br />
* Btrfs + snapper is nice, but!<br />
* It went well, but not more so than in previous releases<br />
* My experience was normal in most senses. I think I had to resolve some inconsistencies before the upgrade by changing packages from the pack-man repository to the opensuse repository, which is not obvious for a newbie..Most of the experience was very similar to my old experience installing OpenSUSE. Please continue this project, you are my number one linux distro, in a list where there is no number two, and I appreciate your work very much.<br />
* I am no expert user at admin level, and system works well and stable, and has everything expected, which installs easily.<br />
* I like the decision of making the base closer to suse linux enterprise.<br />
<br />
===== Action items =====<br />
Action items placed into different sections (Marketing/Upgrade)<br />
<br />
=== Marketing ===<br />
* Communication/marketing wise, I am pleasantly surprised to see more coverage of the release, particularly on Linux-related Youtube channel<br />
* People talk about the 15.2. Somehow it seems a more popular/interesting release.<br />
* Great media support and a really well-polished distro.<br />
* For me, it's the first release with great communication support.<br />
* Everything went well, I received the news on the openSUSE social media channels that I follow<br />
* I think the marketing was done well, and there was a big buildup to the release of 15.2. <br />
* Overall, I've been pleased with the release.<br />
* The new site (most likely software.opensuse.org)<br />
* The info about release date and availability of the new version's images was very good. For instance, the countdown on the openSUSE web page was a nice detail, created sort of thrill in the way of "I can't wait to get the new release" :-)<br />
<br />
===== Action items =====<br />
Identifying new packages and use cases is helpful with the marketing<br />
Community listing the new features on the features wiki page is helpful<br />
Having community help out with blogs, video about installation and experience <br />
Continue countdown on opensuse.org (best to update about 90 days out)<br />
Reach out to marketing team with idea to display What went well quotes from Leap retrospective on Leap download page or perhaps software-o-o ...<br />
<br />
=== Release notes ===<br />
* Beta and RC builds available before the final Leap 15.2 release helped ISVs prepare for the upcoming release, giving more detail than releases notes ever could.<br />
<br />
===== Action item =====<br />
Just an idea: Make sure that our "landing place for partners and ISVs" has a direct link to release notes section.<br />
<br />
=== Hardware requirements ===<br />
* Works well on 10 year old laptop with 4GB ram and new SSD. No driver issues. I'm always impressed by openSUSE<br />
* I am using one of the cheapest laptops available that I got last year June 2019, the Dell Inspiron 3000 (or something like that). Leap 15.1 had various issues, what seemed to be a thrashing issue or something, and a mouse driver that would cut out after a while. It seems with Leap 15.2 everything works out of the box perfectly. Thank you!!<br />
* The Base Memory usage at less than 500 MB with KDE & XFCE is a pleasant surprise.<br />
* I use it with the Gnome desktop on my old iMac 9.1 (dualcore) and I'm very impressed by the speed, CPU and memory consumption.<br />
* Worked on both my new ryzen hardware and even mini pc Intel atom one.<br />
<br />
===== Action item =====<br />
no action items at the moment<br />
<br />
=== Hardware Enablement ===<br />
* More updated kernel, much better on AMD threadtripper<br />
* AMD support! (translated from Russian)<br />
* kernel version appreciation +2<br />
* NVME installation worked, wasn't the case for 15.1<br />
* UPS Info without installing APCUPSD-GUI through Power-Manager - Magical <br />
* All hardware works perfekt. +5<br />
* Ability to install driver for Realtek RTL8812BU (translated from Russian)<br />
* Everything works fine. No problems on PC1 (AMD Athlon 200GE). No problems on PC2 (AMD Ryzen 3950X + Radeon 5600XT). No problems on the laptop (lenovo E595 with AMD 3500U).<br />
* Setup went well on a Dell XPS 15 9560 and did not require any kernel parameters to boot or get touchpad to work (unlike 15.1). SD reader also works, unlike in 15.1. Performance seems very smooth.<br />
* works well with nvidia card<br />
* There were no issues at all with installing openSUSE Leap 15.2 on my Lenovo ThinkPad E595 (AMD Ryzen 5 3500U, Vega 8).<br />
<br />
===== Action item =====<br />
Track mentioned hardware on our HCL (Hardware Compatibility List)<br />
<br />
=== AI/ML ===<br />
ML and AI package were great. <br />
Surprised by the new AI stuff.<br />
<br />
===== Action item =====<br />
KUDOS to AI/ML team<br />
<br />
=== Network manager ===<br />
* Appreciation of the current version of Network Manager on KDE with openvpn configuration <br />
* Configure Wi-Fi access. Is like Tumbleweed and more easy to do. <br />
* The network setup at boot is normal again, wireless connection is established fast as in older (pre 15.1) releases. <br />
* NetworkManager worked seamlessly with WiFi and hard-wired Ethernet. <br />
<br />
===== Action item =====<br />
KUDOS to NetworkManager team<br />
<br />
=== Beta phase updates ===<br />
* All went smooth from Alpha to GA, with exception of pgAdmin4<br />
* I found that things went fairly smoothly for the release. Most testing had been completed and most things functioned without any problems<br />
* Packages were quickly available, which means problems were quickly resolved. I have rund a prelease months before the actual release and it was very stable. User mentioned rolling model but I think he just meant the way how we do our Beta snapshots.<br />
* Experience of using and updating 15.2 RC to release one went smoothly.<br />
* Very stable Beta version<br />
* Everything worked as expected for me. Both upgrading from Beta to Stable and 15.1 to 15.2<br />
* <br />
===== Action items =====<br />
Continue to list Leap development in Alpha Build Phase, Beta Build Phase and RC Build Phase. "Leap has a rolling development model until it’s final build".<br />
<br />
=== Packages ===<br />
* Some packages were surprisingly rather recent.<br />
* Adding additional software met requirements<br />
* The structure of included apps in patterns have been matured. <br />
* some nice brave updates for apps which i didn't expect to see, like wine, gimp etc.<br />
* PHP 7.4 instead of 7.3<br />
* Glad to see the Firefox esr version updated to current.<br />
<br />
===== Action items =====<br />
KUDOS to packaging team community, and Release team (perhaps send email to factory?)<br />
KUDOS to packaging team and PM, The version appreciation might be also one of visible outcomes of CtLG<br />
<br />
<br />
=== NGINX === <br />
* Good amount of Nginx modules included which are missing in mainstream distro like Ubuntu/Debian or CentOS/RHEL/Fedora. For example, nginx-module-brotli and nginx-module-modsecurity along with lastest PHP 7.4.6 and MariaDB makes my job easier. I loved it.<br />
<br />
===== Action item =====<br />
KUDOS to maintainer.<br />
<br />
=== WAYLAND ===<br />
* What perhaps might stand out was the enabling of Wayland and me not realizing I was on Wayland. I only found out when I tried to install the NVidia driver.<br />
<br />
===== Action item =====<br />
KUDOS to wayland maintainers<br />
<br />
=== Xfce ===<br />
* installer allowing you to make choices to xfce set up in a sensible way<br />
<br />
===== Action item =====<br />
KUDOS to Xfce and Installer team<br />
<br />
=== GNOME ===<br />
* Nice overall experience with GNOME<br />
* The newer version of GNOME has significantly better performance on my lower power laptop.<br />
* Gnome is visibly faster<br />
<br />
===== Action item =====<br />
KUDOS to GNOME maintainers team<br />
<br />
<br />
=== KDE ===<br />
* Almost the latest version of Plasma and the system is stable!<br />
* The new KDE desktop is more polished +2<br />
* The new KDE presents well<br />
* The release (specifically using the KDE Plasma desktop environment) feels very polished and sleek. Everything seems to work out of the box including obscure configuration options.<br />
* Continuation from family upgrade: I found few little changes in system or KDE Plasma desktop that are fresh and positive step from ancient ages to today.<br />
<br />
===== Action item =====<br />
KUDOS to KDE maintainers team<br />
<br />
=== Yast ===<br />
* It looks like system works smoother and faster, especially Yast<br />
* YaST is a dream to work with<br />
<br />
===== Action item =====<br />
KUDOS to Yast team<br />
<br />
=== ISO / Torrent / Images ===<br />
<br />
* I'm positively surprised that there are available cloud images at the same time. And when I wanted to try WSL version, it was available the next day.<br />
* I could get it as soon as it was released.<br />
* A good Image availability of the release. <br />
* Quick download of rather big image. <br />
* I downloaded the ISO image as soon as it was announced that it was available. I downloaded it using MetaLink with aria2c tools and I have no problem with that.<br />
* Download of the installation image was fast and flawless.<br />
<br />
===== Action item =====<br />
KUDOS to the release team<br />
<br />
=== Development ===<br />
* I am delighted with the combination of using strip after compiling C programs with gcc. I generally look for a small sized executable, and the Leap 15.2 gcc 7 (-Os) with strip gives me that. The executables I create with Leap 15.2 are up to several hundred bytes smaller than the same sources compiled on alternative distros such as Tumbleweed, Fedora, Arch and Debian/Ubuntu. <br />
<br />
===== Action item =====<br />
KUDOS to toolchain team<br />
<br />
<br />
=== Mirrors ===<br />
* Good download speed from mirror.us.leaseweb.net<br />
* I'm in Australia but the nearest repository I could find at the time was in New Zealand. It was fast enough for me.<br />
<br />
===== Action item =====<br />
Can we have a mirror (or more) in Australia?<br />
<br />
=== Translations ===<br />
* Installation of the Dutch version for Belgium went flawless! I appreciate the work that has been done, it is a fine experience working with Leap 15.2. There is one important exception, alas ... <br />
* <br />
* By the way I translated the release announcement for my language, also my colleague translated the scheduled twitter announcement. We are proud that we can help event it is only just a translation works :-)<br />
<br />
===== Action item =====<br />
KUDOS to the translations team<br />
<br />
=== Virt ===<br />
Well maintained virtualbox compared to debian.<br />
Availability of virtualization facilities that I am interested in learning.<br />
<br />
<br />
=== Feature requests ===<br />
* Leap feature request looks better processed to SLE, than in past<br />
* Informational "meeting updates" in factory mailing list<br />
<br />
===== Action item =====<br />
The jira.suse.com access could have pilot in 5 weeks from now. https://github.com/openSUSE/CommunitySLEFeatureRequests/<br />
People will have option to check status of jira feature requests by themselves.<br />
<br />
Advertise the change once it's available.<br />
<br />
== What did not go too well ==<br />
<br />
=== Installation process ===<br />
* installation went well, except that I could not put the installation software on an usb-stick like I could do with the pre-release version, I could only put it on a dvd.<br />
* I had to turn off ACPI or else installation freezes ...<br />
* After the installation there was a problem that Yast gave a notice that the installation had failed. But after a restart everything was just fine<br />
* Depend.Recommend.Suggest. The installer usually tries to pull in recommended packages that I don't actually want.But disabling the pull-in greatly decreases the system function. For example,once I tried installing a server system(openSUSE of course) in virtualbox,which is supposed to have no GUI,but the installer tries to install X11 components,since the YaST2 recommends it. And for now I have to manually untick pkgs I don't want. Maybe either don't recommend too much,or make a stricter strategy for the installer?<br />
* Download during install (using the network install) took quite some time<br />
* Software selection. On a PC that will never have a use for Samba why is it that when I deselect Samba there a massive amounts of it still left on my PC? Software selection is not fine grained.<br />
* I could not configure proxy internet access during installation. Caused a few long timeouts, but easily fixed using Yast efter initial boot.<br />
* I would also like to see the capability of adding a proxy server during the install process. I frequently have to install on non-routed RFC 1918 networks, but that do contain a reachable squid proxy.<br />
* Dvd should be ejected after installation is complete. Otherwise if you leave the end of installation unattended, the dvd boot back to start a fresh installation.<br />
* It might be helpful to see a better install-time description of the "transactional server" install option.<br />
* This is likely an edge case, but the installer doesn't let me specify which drive to install GRUB to - At least, not one I could find. My system's weird and doesn't let me specify a boot order in the BIOS, I had to boot a LiveCD and chroot into my new system to manually install GRUB. Can you add an option to specify which disk to put the bootloader on?<br />
<br />
===== Action item =====<br />
RFE: Add an option to configure proxy during installation https://jira.suse.com/browse/PM-1895 or define proxy on Linuxrc commandline https://en.opensuse.org/SDB:Linuxrc#p_proxy<br />
RFE: Eject media after the install<br />
^ The first option on our media boot screen is to boot for a local hard drive, so reboot should not trigger a new install process<br />
RFE: Ability to set target device for the Boot loader, there is a bug https://bugzilla.suse.com/show_bug.cgi?id=1165042 with planned solution: At the Installation summary page: Show where exactly is the bootloader going to be installed<br />
^ For the UEFI system this is given, for Legacy BIOS this could be an option <br />
Decrease footprint of smaller installations (recommends/patterns)<br />
<br />
<br />
=== Update Process ===<br />
* Installing from an image downloaded to USB stick, I somehow missed the option to "Update" from 15.1 and found myself wiping my /home directory by doing a clean install of 15.2. I guess I was too nervous to notice the Update option (I'm just an ordinary user). <br />
* The update via Zypper is too complicated (+3)<br />
* Additional comment that the documentation feels out of date<br />
* Problem when using transacitonal-update dup when upgrading to 15.2. Can't wait for a MicroOS Desktop based on Leap<br />
* I first tried to upgrade the system via the iso, but the upgrade had an issue (upgrading libre-office). So I had to reinstall the system.<br />
* I might haven't seen it but there should be an easier way to upgrade from an older distribution. I use a sed command but that works only if no $release variable was used in the repos. Also on one machine I went through the betas and this resulted in not being able to run yosys (got core dumps). I waited until the release of 15.2 and tried my luck in a VM with it installed and there it worked perfectly. So I had to do a :upsiclean install afterwards. Of course a beta is a beta, so I can't blame anyone for this. But: it would have been helpful if there was a third option when installing: installation, update and replace the existing distribution, where there installer reads fstab to determine the partitions and some crucial configuration (printers, soundcards, etc.). <br />
* What is still unclear is how to change the repo pointers in /etc/zypp/repos.d/*.repo. I used the documented sed command and it replaced the pointers fine. Still, I have a file "openSUSE-Leap-15.1-1.repo" there which I renamed to "openSUSE-Leap-15.2-1.repo" just to be sure. But I don't see how release numbers in repo file names are handled. There is no information available.<br />
* There were some packages and library that broke after the update. (Translated from Portugese)<br />
* I usually do upgrades (e.g.: 15.1->15.2). My problem is that there's still no GUI for this. There should be a GUI (like in Ubuntu) to make it easy to do upgrades (not thru a CLI!!!). It's a VERY VERY awful experience to do upgrades on openSUSE if you compare it to Ubuntu/Windows/Mac. It feels like a travel to the 80's were everyone lived in the terminal. It's a very awful experience! <br />
* Very disappointed by the lack of online repository support during upgrade. Upgrade remove ~150 packages, including gcc, kmymoney, all *-devel packages, etc. All had to be restored by hand, a huge PITA.<br />
* I upgraded from USB image from 15.1 with KDE5 repositories. At the last check before the installation is executed it says in the S/W selection that there are unresolved conflicts and manual intervention is required. Clicking on manual intervention or on Software selection immediately brings up the dialog with detected conflicts. This window cannot be dismissed. The only choice one has is to click through all (100s in my case) conflicts and solve them manually or to abort the installation and do an installation instead of upgrade. Possible solutions: a) Provide a way to solve conflicts later or b) allow vendor change from the conflict window (*all* of my conflicts were solved in that way)<br />
* I was not able to upgrade from Leap 15.1 to 15.2 using cli or yast, was getting prompts for Vendor Change option every package, it should have included Yes to All option. I'd to do fresh install and need to format partition.<br />
* During the update something clogged my hdd. I deleted some games, cleared the zypper cache and removed snapper images. The situation with just a few bytes left on the root partition happened multiple times during zypper dup. I have a 500 GB SDD that was automatically partitioned using btrfs by Yast. It took me an afternoon to fix this up on the command line. I can't recommend this to any non-technical person at the moment.<br />
* I was hoping that it would preserve all my existing applications by upgrading them too. Unfortunately, it didn't. I had to re-install many of my apps. Also my mp3 drivers broke, probably because it is non-free system.<br />
* can't import photos from iphone (bug was reported)<br />
* I somehow got gtk and graphical friends installed on my servers that haven't been there before (I don't need them on my servers)<br />
* Performed upgrade via full image USB stick. First time I chose upgrade from image when booting, I ended up in console asking me to specify where the packages should be loaded from. None of the options worked, so I rebooted. On second try I correctly ended up in upgrade GUI as described. <br />
* First I chose to update from 15.1. This ended in a disaster. In 15.1 I used the proprietary NVIDIA drivers. Those also got updated. But when I booted the first time, X window system didn't start at all. So I tried to check the installed packages, realizing that I also got no access to the internet.<br />
* Finally I decided to install 15.2 from scratch keeping my old home dirs. This ended in KDE not starting. The reason was that the zsh-shell is not installed by default but my user account is set for using zsh. After installing zsh I could start KDE.<br />
<br />
===== Action items =====<br />
Add option to specify --allow-vendor-change once there are install conflicts during install (usually multimedia). This might result into system with broken multimedia set.<br />
^ This might be not a good idea for the upgrading system<br />
<br />
Perhaps advertise zypper dup as a prefered migration option for users with custom OBS repos etc.<br />
<br />
If the vendor change issues would be e.g. mainly OBS projects which do not have yet repository for the new Leap release, we could perhaps display this to user in a more structure way that would better integrate with OBS. Saying e.g. these 10 OBS projects do not have repository for your $releasever. This approach would not be then applicable for pacman.<br />
<br />
the update via zypper consumed all space on the root partition (size of partition was set by the auto-partitioning).<br />
<br />
server installations received some unwanted graphical packages (more on patterns/recommends)<br />
<br />
Already mentioned to document $releasever, make sure that it's clear how to update to the last Leap via zypper dup (check docs)<br />
<br />
=== User Experience ===<br />
* Minor issues with: welcome App not available, lag of community-based Repos <br />
* artwork should be improved (some icons e. G. Printer setup is pixeld, better icons for YAST) <br />
* Selection of the the Macintosh keyboard layout required further research. <br />
* After installing opensuse on the first update, I was unable to boot the system and the error appeared amd-vi unable to read/write to iommu perf counter Disabled iommu in the bios and everything worked again <br />
* When booting to install, I see the boot sequence but the screen goes dark and GUI never appears. "Out of range" error or some such thing. Haven't switched to 15.2 because of this (I installed on this hardware about 4 years back (can't remember which release) and currently on Tumbleweed). <br />
* Well, as a person who was using Leap 15.2 1 week and as a person who uses right sway Tumbleweed (KDE), that the system don't remember my password for Wi-Fi and it's annoyed <br />
* Distribution is not very user friendly and often requires usage of terminal to workaround issue (from Russian) <br />
* When choosing an encrypted disk, the decryption key is asked for three times on boot, which is very cumbersome if the install is intended for a non-export to use. <br />
* during the last days (16.-18.07.2020) the/some repositories were inconsistent - for some RPMs the checksums did not match, i.e. an error message during update using 'zypper dup'; thus, the update on some of the installations was not possible on the first try; this was fixed latest today <br />
* After the update, some updates are not yet available in Leap 15.2 such as libdouble-conversion, libgsl23, and limpoppler, which makes Inkscape unable to run. so the result must be installed from source 15.1 manually via rpm. <br />
* After rebooting, the system hung. The only way I could get the system updated was to reformat /dev/sda3 (the root partition) and /dev/sda7 (/boot/efi) and reinstall everything. Even then the system hung after installing the nvidia drivers. I had to login through windows, run yast2 using ncurses and update the kernel in order for the system to boot. Tried later to boot to runlevel 3 (networked multiuser target) just to see if it was possible but the system hung again. Had to once again go into windows and fix the runlevel to graphical.target and reboot. <br />
* Overall the whole system just felt buggy and slow. I have used numerous other distros and DE without issues, but this one just did not feel right. So sadly, I had to remove openSUSE. Will probably try again at a later date, but at this point it is a no-go for me. <br />
* I installed the XFCE version, and after install, YAST software kept crashing while installing additional software. <br />
<br />
===== Action items =====<br />
Document keyboard layout config for Mac Users<br />
lkocman: I have reported feature request for the disk encryption password prompt. I'll share updates on the https://etherpad.opensuse.org/p/ReleaseEngineering-meeting<br />
Consider sharing wifi-passwords in between individual installations (some cloud option?)<br />
Revisit welcome app <br />
Not all new translations are in the welcome app translation (Action item for Lubos). The package is 1 year old.<br />
advertise snapper usage to avoid system-reinstall<br />
lkocman: double check on the issue with repository checsum<br />
<br />
<br />
<br />
=== Laptops / Suspend ===<br />
* Just one bug on my lenovo laptop freezing after closing and opening the lid with nothing resolved yet. Bug was reported.<br />
* The sleep mode (suspend to RAM) doesn't work. My computer just reboot when I try to wake it. Just another regression. Downgraded to 15.1.<br />
<br />
===== Action item =====<br />
Perhaps go through the Beta testing sheet (covers also manual suspend/resume test) during RC.<br />
<br />
<br />
=== Images ===<br />
* DVD image has almost 4 Gigs. Its very big for me- in Indonesia, which internet connection rather slow. With narrow band i need four hours to download. but this is not a big issue. <br />
* installation went well, except that I could not put the installation software on an usb-stick like I could do with the pre-release version, I could only put it on a dvd.<br />
* 4GiB ISO very big in Indonesia with slow internet connection. Took 4 hours to download but not a big issue.<br />
<br />
===== Action item =====<br />
Advertise availability of Live images and network images that are generally smaller than DVD. Network image might be tricky if there is a bad latency.<br />
<br />
Raise the indonesia situation to mirror admins<br />
<br />
TBD: double check on the usb image, but I'm pretty sure it worked for GA as I have one Leap 15.2 USB drive myself and it works.<br />
<br />
=== Packages ===<br />
* Bash version too far behind<br />
* The point is that 15.2 core packages are still based on years old releases. If they would have been a year old, okay. Alas, some are 4 years old and lack therefore features we (I) are depending upon. Also, the kernel is not even based upon a LTS version, which means additional burden in maintaining the kernel. Instead of being the main OS, Tumbleweed has taken that position, even despite the frequent updates and hence the time it takes to run the updates. Version 15.2 is now only used when modern features/functions/optimizations are not a prerequisite and stability is. <br />
* Lack of packages compare to AUR or even Fedora<br />
* surprised that exFAT is not supported by default (package has to be installed),<br />
* I would appreciate more often update of Wine (still version 5.0 provided, quite "old" one)<br />
* Leap 15.2 still comes with old SLE stuff, including the kernel, apart from e.g. up-to-date KDE DE. Reporting bugs is frustrating, since they are very often not addressed at all. When Leap 15.2 was published, there were around 240 open bugs. I do not know any other distro that provides such incomplete/defective "product" to the public. As far as I am concerned, Leap does not have any future in its current setup.<br />
* The Darktable 3.0 package provided in the Graphic repository misses the libIex-2_4-24 library<br />
* I find it unfortunate that some packages, such as podman, were outdated.<br />
* TexLive (LaTeX) related packages update during upgrade was very very slow: hundreds small packages; it would be better to provide a collection of most common these packages as one single package as replacement (but small packages could still remain for those who want very fine tuned TexLive/LaTex installation).<br />
* The kernel is also version 5.3, instead of LTS 5.4. I see no reason not to join forces to support LTS versions. It's open-source, and it's for everyone, not you. (Translated from Russian)<br />
* I expected that almost all Tumbleweed packages will end in Leap. I was unsitisfied, when I discovered, that is not true and multiple Tumbleweed packages missing in Leap 15.2. It was unclear what does "refresh release" mean. I expected, that it will contain newer glibc and newer systemd, like it was with Leap 42.2 / SLE 12 SP2, so issues with gaming on Leap 15.1 will be resolved with Leap 15.2 . But it wasn't the case, so workarounds are still needed. I didn't know that, so I cannot fill bugs (or write somewhere) earlier, than it was too late for SLE.<br />
* installed Leap 15.2 and almost pulled my hairs off when realised there isn't a functioning repository for QGIS (geographics software)<br />
* Under 15.1 I did not use apparmor/audit and the packages were not installed. Installer automatically selected those packages.<br />
<br />
===== Action item =====<br />
Decrease footprint of smaller installations (recommends/patterns) same as in the Installation experience.<br />
Advertise reason why we don't have LTS kernel. Our kernel is heavily patched and in some cases newer then the LTS kernel itself - Greg Kroah-Hartman, the #2 Leading Linux Kernel Engineer and the maintainer of the upstream LTS Kernel says that any distribution kernel is better than that LTS Kernel<br />
Reach out to kernel team regarding kernel feedback<br />
Revisit large update issues with texlive. Sarah mentioned that there were used to be 3 different packages (default, full and half-full) providing different set of rpms.<br />
exfat should be already supported by the kernel, so this is most likely availability of the userspace tools. Todo revisit this<br />
Try to keep wine up2date<br />
Try to reduce amount of open bugs, this number is truly high<br />
try to revisit bash<br />
podman - try to have the recent version<br />
Raise complain about obsolete versions in SLES to PM (e.g. bash etc). Sometimes it's not so easy as shells might break some of customer scripts.<br />
Document meaning behind tic-toc releases. What can be expected from the refresh release.<br />
<br />
=== Multimedia ===<br />
* codecs are an Disaster by all opensuse Version. +2<br />
* The URL from Suse for Installation Codecs need and Refresh and Check<br />
* Videos working in VLC only by installation of extra codecs and vendor change (packman repo)<br />
* Many formats (mp3, mp4, movs, jpegs, jpgs, etc are not viewable with Leap15.2 and my efforts with vlc or other. SUSE needs to create a tainted library, from which youtuber's facebook users's, etc, can click on a video, and watch it without having to switch to other distributions. As it is now, Fedora 32 with the tained rpms and some other downloads allows me to watch or view any email attachment, or any video format. SUSE is number 2, because of not being one distribution for all users. I recognize that there are copyright/legal implications of including copyrighted and licensed software within Leap. But there should be no danger in saying, we cannot provide tainted software, but here is a list of third party repositories from which you can purchase/download such codecs.<br />
* Install H.264 - HTML5 drivers. Browser Firefox 68.0 ESR. Trouble with HTML5 drivers in YouTube. I understand the copyright thing about "privative drivers", but another distros make this easy with "ugly" or "bad" packs. Ubuntu ask "do you want multimedia?" and go on.<br />
<br />
===== Action item =====<br />
* Revisit docs which cover multimedia, make sure that it's obvious how to get codecs<br />
* Consider adding an option to the system or installer to add multimedia.<br />
https://opensuse-guide.org/codecs.php - one click install that could be integrated in the welcome application.<br />
* Discuss with Frederic what are reasonable options to make this more convenient for users.<br />
<br />
<br />
=== Boot issues ===<br />
* could not boot after installation did not seem to recognize efi<br />
* Installation DVD iso was unable to work with Secure Boot, but NET istallation iso worked without a problem.<br />
* After install OpenSUSE would not start if I do not have the openSUSE liveUSB connected to my computer. I found options under Yast→ System → Boot Loader to change some of the boot options which I did but it caused my Windows installation not accessible from boot manager entries. I tried following options so far but have not got dual boot working. I am hoping to find a definite guide that I can follow. <br />
* During the update something clogged my hdd. I deleted some games, cleared the zypper cache and removed snapper images. The situation with just a few bytes left on the root partition happened multiple times during zypper dup. I have a 500 GB SDD that was automatically partitioned using btrfs by Yast. It took me an afternoon to fix this up on the command line. I can't recommend this to any non-technical person at the moment.<br />
* I use extra repository, Change secure boot policy on 15.2. Cannot boot after update, I add repository key by Mokutil. It is difficult for find document, please write release note.<br />
* Was unable to do a PXE installation on a UEFI laptop. I am experienced with normal BIOS PXE deployments, UEFI something else. Some instructions would be nice. <br />
* lkocman: This is unfortunately the case with all new Dell laptops I was personally surprised as well.<br />
* Updating from 15.1 running system failed because of boot configuration not being allowed for (dual boot win10/legacy bios/MBR) which was as originally proposed by 15.1 New complete installation took ages for same reason - now works fine, but no help available on OpenSuse sites, or within YAST explaining what the many boot options mean or do, or why "search for other OS" option needs deinstalling and then reinstalling to work! Disc partitioning offerings still confusing, partly because of boot uncertainty.<br />
* Not able to boot due to problems in ucode-intel package.<br />
<br />
===== Action item =====<br />
Document the UEFI PXE detail on wiki (available only with Legacy BIOS)<br />
Revisit the no-space-on-disk during zypper dup<br />
Document dualboot best practices and perhaps even /boot structure for efi<br />
Revisit release notes section for SecureBoot/Signed modules <br />
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT kernel config option (bsc#1173158) etc.<br />
<br />
=== yast ===<br />
* I think the Yast software manager still needs a little work. If you don't know close enough to what you are looking for it will just come back with no result. Then I use a web browser to get some clues and type that back in and all is good. But that really is a minor quibble otherwise Excellent OS. I use it 99.9999% of the time.<br />
* <br />
===== Action item =====<br />
Reach out to yast if we could ease the navigation.<br />
Some usecases of what's not easy to find would help us a lot.<br />
<br />
=== X / Wayland / Mesa ===<br />
* On my HTPC, which uses intel i915 graphics, I had also a bad upgrade experience. The desktop was full of artefacts and unusable. I realized after a lot of head-scratching that this was because it has switched from regular X11 to X11-wayland. This is quite a big change, though it is described nowhere in the release notes either ! I read from distrowatch that when one installs from scratch, several session types are possible. In my case only 'Plasma' in proposed at the login screen, I do not know how to get the extra session types. I uninstalled x11-wayland and things have gone back to normal.<br />
* Something wrong happened with Mesa from SLE to Leap transition. In SLE 15 SP2 beta was Mesa 19.3 much earlier and in Leap 15.2 it ended only after release candidate (!) Release candidate was not package freeze (like article https://news.opensuse.org/2020/05/28/opensuse-leap-15-2-enters-release-candidate-phase/ trying to say), but big changes like big Mesa upgrade happens<br />
* Opensource graphic stack is older than usually. In previous version new release shipped with one major version behind, this release was with two major versions behind<br />
* <br />
===== Action item =====<br />
Note on the Wayland by default: Plasma is not using wayland by default, this is only the case with GNOME. This will be changed in future release as well.<br />
Todo: talk to maintainers and perhaps even SLE PM about the Graphics stack, we should not be two releases behind.<br />
Revisit release notes, perhaps we can spare some time and pain to users who did not do the update yet.<br />
<br />
=== KDE ===<br />
* Moved the connectivity issues to remote share to File Server section <br />
* I use KDE PIM with KMail. There is a terrible bug in it now: https://bugs.kde.org/show_bug.cgi?id=422336 because of Qt 5.12 and they say that will be the case until next Leap 15.3. I hope not. It is simply nearly impossible to work with e-mail because akonadi_maildir_resource is endlessly retrieving entire folders and blocks e-mails from appearing, and blocks KMail from being used. Some solution MUST be found, please - this is a real bummer.<br />
* Kaffeine is not able to play HEVC full HD DVB-T2 channels, some issue in VDPAU_DRIVER, must be switched to va_gl (I guess some issue with vdpau, mesa or something, not opensuse).<br />
* Maybe this problem on Plasma not openSUSE itself, when network status is limited (Wi-Fi with orange exclamation mark icon) Plasma shell become not responding for few seconds.<br />
* Some user configurations of KDE Plasma or some individual applications was lost after updates<br />
* Dolphin can't be split.<br />
* Additional repos: I would prefer to have the repos for the latest KDE software releases available to add during the install. There's no reason why they shouldn't be available.<br />
* the kile (beta) program is REALLY unstable...... it should not had made it to the release my opinion.... I uninstalled and went to emacs-auctex for my LaTeX.<br />
* KDE plasma bugs, those minor annoyances like inconsistent colour scheme in settings app, and other kde apps.<br />
* Missing data in the kinfocenter app.<br />
* I've also encountered konsole windows where changes to font sizes, color schemes, etc. don't persist on the first tab of the window. The attributes persist on any additional tabs. Odd<br />
<br />
===== Action item =====<br />
Double check on the remote fielsystems, this has been mentioned multiple times.<br />
QT issue with kmail, someone has to bisect the patch and fix it. This will take a while to do so.<br />
Perhaps we could use the possible 15.2.1 release and ask SLE if we could simply update QT<br />
Split button changed from left to right corner, but it can be done<br />
The problem with offering a repository with newer KDE is that it would be blocked on the current version of QT. It's essentially same problem as with offering two parallel versions of glibc<br />
Responsiveness: let's report a bug, perhaps plasma is trying to resolve a hostname and it can't be done on a poor wifi connectivity<br />
<br />
<br />
=== GNOME ===<br />
* I have the feeling the GNOME version that has been chosen was not a good pick. Several important extensions like kstatus/appindicator support do not work. On my test machine libinput also has an issue that the mouse coursor gets unresponsible after suspend / resume. Previous and also later GNOME/Libinput versions work fine.<br />
* some Apps from GNOME world are missing (feeds, podcasts, fractal, astrosophe, shortwave )<br />
* Gnome version could be at least 3.36 +4<br />
* Gnome 3.34 isn't as snappy as 3.36 on my laptop (core i5). I experienced minor issues with it (mouse lagging while opening app list). But all in all its usable. I hope that 3.36 will be available in the future (if possible).<br />
* not latest oldstable version of GNOME (3.34.7), <br />
* GNOME Memory usage without any apps open is upwards of 1 GB is a disappointment.<br />
* One cannot create a symbolic link for me on the desktop<br />
<br />
===== Action item =====<br />
Revisit GNOME memory usage, and perhaps even minimal recommended memory for Graphical install specifically with GNOME.<br />
Let's check on the missing GNOME apps, and why are they missing (check with Frederic or Yifan perhaps).<br />
Raise complains about GNOME to SLE PM<br />
<br />
=== MATE ===<br />
* Mate install did not work even after multiple tries & re-installs - tried GNOME, KDE , XFCE worked perfectly.<br />
<br />
===== Action item =====<br />
check openQA coverage<br />
<br />
=== Xfce ===<br />
* Feature request: please add Xfce as a desktop option in the installer, SUSE/openSUSE Xfce team has done an amazing job :)<br />
<br />
===== Action item =====<br />
Xfce will be an install option in next Leap release.<br />
<br />
=== Cinnamon ===<br />
* Cinnamon DE shipped with the release has performance issues, for some strange reason it starts lagging after ~1h of using the system. It's not related to oS, because folks on other distros with this DE are also having these issues (got this info from Reddit, but I'm unable to find exact link to the discussion, sorry). I upgraded to Tumbleweed and added this repo https://build.opensuse.org/package/show/X11%3ACinnamon%3ANext/cinnamon to get the latest Cinnamon DE available for Tumbleweed. It seems to fix that strange lagging problem.<br />
<br />
* Installing flatpaks went fine and they are working fine, but for some strange reason their icons disappeared randomly from the Cinnamon program menu. Changing the DE didn't fixed the issue. I haven't tried the latest version of Flatpak (1.8.1 from user repo) on Tumbleweed to check if this was solved or not.<br />
<br />
===== Action item =====<br />
Check whether we can update cinnamon to latest factory version as a maintenance update, otherwise it seems to be fully unusable in 15.2<br />
<br />
=== SWAY (Tiling manager) ===<br />
I saw that 15.2 comes with Sway, which I'm using on Fedora right now. So I installed the OS, which went well, then tried to install and start Sway which sadly crashed. (lkocman: Systemd issue)<br />
Action item identify and push on the bug to get it fixed, otherwise SWAY is not usable in 15.2<br />
<br />
===== Action items =====<br />
Priorize the systemd bug<br />
<br />
=== Web browsers ===<br />
==== Chromium ====<br />
* Chromium had problems with playing some videos. I had to disable "Hardware-accelerated video decode" and "Hardware-accelerated mjpeg decode for captured frame".<br />
==== Chrome ====<br />
* In the fast way I could download Chrome, but Yast says something about the "integrity" of this browser. I dont like Chromium. <br />
<br />
===== Action item =====<br />
Raise issues to the packaging team<br />
<br />
=== Thirdparty apps ===<br />
* Owncloud broken by providing php newer than 7.2, this broke the upgrade experience<br />
* Using dropbox, the icon did not appear in gnome but in plasma the indicator work. I was using the default dropbox installation from opensuse repo installer. <br />
* <br />
===== Action item =====<br />
Contact owncloud people about the issue, also consider offering php72 in parallel (Cristian Rodriguez might help)<br />
Dropbox: report bug we'll see what can be done.<br />
<br />
=== Development ===<br />
* Not good for hardware development, not possible to install synthesis and stimulate most FPGA and ASIC base tools. <br />
* RISC-V development tools issue.<br />
* GCC9 for Leap 15.2 was at version 9.2 for a while even though 9.3 was available for Leap 15.1. It was a surprise to see Leap 15.2 with an older version than Leap 15.1. Presumably this was due to a packaging freeze as the release date approached. This inconsistency has now been solved via an update, though a bit of reassurance in the release notes may have helped. https://software.opensuse.org/package/gcc9<br />
<br />
* gcc9 isn't be default package when install gcc, rpm-build is still requiring gcc7 instead of gcc9.<br />
* I have a dream about the day when Apple Swift, which runs on Ubuntu, will finally be running on openSUSE. But I guess, this remains a wish and I never get that. <br />
<br />
===== Action item =====<br />
Use release notes in cases where we know that Leap GA will have older verison than recent Leap 15.1 update. <br />
Consider adding hardweare development stack, if there would be a maintainer willing to maintain it<br />
Check with RISC-V team on the mentioned issue.<br />
message opensuse-factory@ and ask if somebody would be willing to maintain swift<br />
<br />
<br />
<br />
=== Python ===<br />
* Lack of updates for python. Python is still left at 3.6.x. That was not expected.<br />
* Pip / Python old version<br />
* python stack does not work any more. Any pip command returns some error...<br />
<br />
===== Action items =====<br />
There is already a feature to offer parallel versions of python including 3.8 to my knowledge. TODO: track status together with other openSUSE-originated features<br />
<br />
Regarding pip and error, please return a bug if you can see this text.<br />
<br />
=== Java ===<br />
* Bulleted list item<br />
my old IBM SPSS 22 stopped to open fileopen/filesave dialogs due to JAVA exception – it took few weeks to resolve issue by resetting all SPSS settings to default ones.<br />
<br />
===== Action item =====<br />
Pass feedback to Java Maintainer.<br />
<br />
=== Additional repositories ===<br />
* Community repositories blank when I'd add in YaST->Respositories -> Add -> Community<br />
* In adition, IMHO this list should include another repos as KDE-Applications, Geo, Education and others.<br />
* During the process of setup, I discovered that Packman was not available in the Yast community repos. Most of the one click and terminal entries I've used in the past no longer worked to install it either. So it was a search and learn process to learn how to install Packman. Once installed it worked perfectly. I love that I learned a lot during this process, but I question the wisdom of making the maze to set it up so challenging to wander through.<br />
* I'll admit that I was confused when I installed 15.2, went into Yast to add the pacman repository and didn't see anything.<br />
<br />
===== Action item ===== <br />
This was a human error the submission containing community repos was submitted ahead but not merged in time. Perhaps add a check to RC checklist.<br />
<br />
=== Deleted packages ===<br />
* Two weeks before release I installed the beta or RC, including lilo as bootloader. After release, when I ran a zypper dup, I was surprised to see lilo was going to be deleted. I had to do a lock on it. There is an open bugzilla.<br />
<br />
===== Action item =====<br />
<br />
The lilo was scheduled to be deleted for a long time, the SR got under the radar and it was brought back to our attention around the time when we were taking the last submissions including ucode-intel to enable newest hardware and so on. One of the reasons was also that maintainer didn't want to maintain it any more.<br />
<br />
If someone would be interested in maintaining the package, feel free to reach out to openSUSE release team, or report a bug against Leap 15.3 to add back lilo (and mention that you're willing to maintain it).<br />
<br />
=== File systems ===<br />
==== btrfs ====<br />
* Very embarrassing was missing "back-port" support for zstd compression for btrfs in grub, had to reinstall with zlib compression, and i think this should be considered as a bug and be fixed in coming months. Would be nice to have some default options activated for btrfs for ssd's... Default disk setup was providing only encryption with lvm which should be migrated to btrfs.<br />
* btrfs cleaning that hanged the computer for minutes, what's the point of hourly snapshots if the script hangs the computer with a cleaning script that makes the computer unusable, also btrfs compression or ssd optimization settings did not seem to be on default, or have any Gui tool to configure it<br />
<br />
===== Action item =====<br />
<br />
We should really look into the option to enable SSD optimizations for btrfs in case that SSDs are in use.<br />
The second issue should be reported as a bug.<br />
<br />
ZSTD - SLE 15 SP3 is adding libzstd because of dnf stack, we should look into btrfs as well. Check if the feature is not already reported, or report it.<br />
<br />
<br />
=== Performance ===<br />
* It does feel like it takes a little bit longer to boot up.<br />
<br />
===== Action item =====<br />
Please report a bug and provide boot logs. Could be some service (e.g. mount) that is delaying the boot for up to 2 minutes. Happened to me in the past.<br />
<br />
<br />
=== AI / ML ===<br />
* A bit underwhelming, tough expected: shipping ML libraries without CUDA support, presumably because of the legal reasons. <br />
* Kind of related: Nvidia driver compute is a bit temperamental/finicky to get working, but that's really not your fault, I've seen the similar problem before on my previous distribution. Hopefully, upstream will fix it at some point. <br />
* working with laptops and NVIDIA graphics hardware did not work well. <br />
* Needed access to cuda facilties only supplied from nvidia drivers did not install at all. <br />
* Doing any sort of AI or machine learning without having GPU accelerated facilities is a waste of time. <br />
* Nouveau drivers worked well, but no cuda libraries can be used. <br />
<br />
===== Action item =====<br />
Raise this to our AI/ML team, I believe that I've seen feature request for this (update community with the status). There are some related features opened for ComputeNode (provide repo for NVIDIA CUDA) perhaps something could be done for openSUSE as well. Lubos will reach out to Marco V.<br />
<br />
<br />
=== Hardware Support ===<br />
* Ryzen and Realtek support is still not good, and I think this is because of the kernel. On one machine I have had to resort to a different distro to get bluetooth operational. On another machine, using a kernel from the HEAD branch resolved networking driver issues with realtek and most importantly, reduced power consumption on the laptop by almost 25% in comparison with the 5.3 kernel. It "feels" as though, while openSUSE remains a rock-solid distribution, its hardware support is really lagging.<br />
* in my dell laptop during booting it appears that the temperature of the CPU is high, when i just turn on the laptop , it happens randomly for no reason<br />
* some other issues are the Broadcom-WL wireless driver and realtek Ethernet which must also be installed manually<br />
<br />
===== Action item =====<br />
Kernel in a default installation is tied to be the same in SUSE Linux Enterprise, however if we identify that some hardware is not working any more or is too new, we should raise it as a bug or a feature request.<br />
<br />
Realtek support: kernel team is not surprised, Realtek is not very co-operative with upstream. Please report bugs against openSUSE Distribution, kernel team has an experience that they're handled in a right way.<br />
<br />
Ryzen: we have backported a lot of patches for this topic, so far we've received a lot of positive feedback in this poll regarding the Ryzen support. Please open a bug if you have any specific issue, kernel team can't do much to help here as long as they do not have more information.<br />
<br />
<br />
=== intel ===<br />
* It is KDE with HiDPI support on Intel integrated GPU's. If you enlarge everything by 125%, you will see artifacts in Konsole, KPatience, etc. However, if you select NVIDIA as your primary GPU, those artifacts are disappearing. That's what was on the Leap 15.1 and Tumbleweed as well.<br />
* Wrong graphics driver was installed. I have an ASUS laptop with an intel integrated 620 graphics card. It took several days of troubleshooting to fix it. A kernel paramter was required to prevent screen flickering once the right driver was identifed. This problem didn't occur in Leap 15.1. Also the wrong trackpad driver was installed. This error also occured in Leap 15.1.<br />
<br />
===== Action item =====<br />
if there is a regression and hardware doesn't work please make sure to report it ideally during Beta phase. I'll copy paste your entry to a bug, but I'm afraid we'll need some logs as well.<br />
<br />
=== nvidia ===<br />
* Upgrading from 15.1 on a "standard" hardware (HP Z2 with nVIDIA Quadro P2000) went fine up to loading of the nVIDIA driver. This seems to be a persisting problem as I understood from bug reports. I went back to 15.1 on this production machine (running Tumbleweed on my Lenovo X1 carbon, happily). I am surprised that the nVIDIA driver problems were not caught and sorted out before launch. <br />
* When I restarted I enabled the additional repositories again, and updated the packages and programs with multimedia support with patents. Everything worked fine after the upgrade, except for the nVidia Optimus software that started working without moving settings after an upgrade of the nVidia version 390 packages <br />
* My Nvidia graphics card does not work anymore.. As far as I understand it, its because the kernel module is not properly signed. I am still searching for a solution.<br />
* I was on with beta stage, and nvidia drivers were complaining about missing library, but that was fixed before real launch.<br />
* Suse made the choise to not accept unsigned kernel drivers on Secureboot machines in 15.2. Sounds great, but Suse knew about NVidia's lack of keys in their driver to do so. Which left me with a non workable system for two weeks. For me that's not a big problem, I know where to go with problems and bugs. But for regular users (Linux is seeing more and more of those) this is a disaster from which they can't recover. I think Suse should have waited for NVidia to put keys in their driver and THEN enforce the signed driver feature. NVidia is in too many systems to just ignore. And no, the Nouveau driver is not an alternative. I also think Suse and other Linux companies should activily talk, work and ask companies like NVidia to comply with these changes. Publicly of everyone to see if needed. This will have more chance of being effective then when some users do this. It will also make users not complain at Suse, but direct their complaints to where it should, NVidia.<br />
* It was hard to deselect the nouveau driver. It would have been very nice if you can add a "remove nouveau" driver button on the dialog that warns people for its quality.<br />
* The release notes did not mention anything about NVIDIA deprecation, but it turns out my driver does not exist any more at https://download.nvidia.com/opensuse/leap/15.2/x86_64/ (nvidia-computeG03). That was an unpleasant surprise, I tried to install it myself from the source (https://en.opensuse.org/SDB:NVIDIA_the_hard_way) but that did not work. I ended up using nouveau in the end but I have a few glitches with 3D I did not have with proprietary driver.<br />
* I tried to upgrade or install Leap 15.2 on a machine with an Nvidia GT610 graphics card and no matter what I did the install failed - ended up removing the graphics card and everything worked perfectly.<br />
* A machine with an old Nvidia graphics card that used Nvidia drivers is no longer supported, but the Nouveau driver fallback is not letting me up the resolution to HD, still working on it but it's not a big deal. <br />
* nvidia don,t work especially 340...<br />
* A variety of laptops both Intel and AMD based CPU coupled with NVIDIA graphics hardware often completely leaves the NVIDIA drivers not fully installed. This needs to work just as readily as the Nouveau drivers.<br />
* I had to first uninstall the old and then install the new NVIDIA drivers from the openSUSE Leap 15.2 NVIDIA repository. A direct upgrade of the NVIDIA packages did not work for me.<br />
* One of my slightly older machines with nVidia Geforce GTX 330 lost proprietary nVidia driver support with the kernel upgrade from Leap 15.1 to 15.2. I had to change my desktop environment from KDE to LxQt due to graphical glitches with the Nouveau driver. I don't think this is openSUSE's fault though, I blame nVidia.<br />
* Suse Prime doesn't work. This is also clear from the wiki (Bumblebee). Packages supplied by NVidia for openSUSE Leap do not contain any files or symlinks in the /etc/X11R6/ directory.<br />
* Received a new Ryzen7 laptop with Nvidia GeForce GTX graphics. Opensuse simply will not install, it hangs at the line ">pci.2 get sysfs pci data". Will go to the forums for a solution.<br />
<br />
===== Action item =====<br />
Make sure to document how to handle secure boot with current nvidia drivers. This needs to be broadcasted on all possible places. Lubos will work with Doug to make sure we can hit as much audience as we can.<br />
<br />
About the deprecated drivers, (nvidia-computeG03).we should re-map the NVIDIA situation and retrospectively update release notes.<br />
<br />
SUSE prime - please open a bug<br />
<br />
Geforce GTX - We can copy-paste this information into a bug as at least we know what's the error message, but please supply more information.<br />
<br />
<br />
=== radeon ===<br />
* Still not considered by many software provider e.g. Radeon pro driver. <br />
* Issue with AMDGPU, Radeon wx4150.<br />
* MDGPU-Pro would be nice.<br />
<br />
===== Action item =====<br />
Raise a feature request to support Radeon Pro/AMDGPU-Pro driver<br />
Please open a bug for the issue with wx4150<br />
<br />
=== printers ===<br />
<br />
* What I find problematic ... peripherals: printers, tables, scanners etc. The package for this are generally coming from SLE and getting an upgrade to support newer hardware, something recently bought, is a long process to which maintainers are generally unresponsive. I assume this not an issue for an enterprise context, but for consumers (as I am) this could see some improvement. <br />
* With this release I was unable to add my networked printer. It had issues when the root profile was used. Returned back to 15.1 to get it back working. <br />
* For some reason hpcups did not install correctly but a report on bugzilla provided a quick fix (Thanks!) <br />
* Samsung printer driver got lost. Reinstallation fixes it. <br />
* Sane-backends 1.27 is still useless for my genesys scanner. I must install an older version of the community package. <br />
* Setting up HP Laserprinter and scanner was very difficult even when I used the IP address. In the end I disabled the firewall and let the HP utility find my printer, thus the correct driver was loaded. <br />
* .I am unable to install my network printer. I have never had these problems before with any of my equipment. This makes Leap 15.2 unusable for my situation. +2 <br />
* I have a panasonic printer I have used for several versions of open suse. The drivers install but the printer will not work. <br />
* Also, with this release I was unable to add my networked printer. It had issues when the root profile was used. Again I have never had an issue before. <br />
<br />
===== Action item =====<br />
<br />
Lubos - report a bug for network printing (with cups-browsed)<br />
Sane backends - we have a feature for this, I'll track it in the ReleaseEngineering-meeting minutes together with other community features.<br />
Samsung printer driver got lost - please report a bug for this.<br />
Panasonic printer - please report a bug we need more information<br />
<br />
<br />
=== Sound ===<br />
* module for soundcards was not loaded, so no sound. (Dutch)<br />
* Using a Lenovo Yoga C940 audio isn't working properly. It's working under Tumbleweed. I installed sof-firmware from the multimedia repo, but still doesn't work (https://wiki.archlinux.org/index.php/Lenovo_Yoga_c940). Can sof-firmware + kernel patch/setting/driver please be backported for Leap 15.2?<br />
* sound card doesn't work. she was working with opensuse 15.0<br />
* What I am still fighting with is sound. In 15.1 I could switch between using my headphones and using my monitor speakers connected via DisplayPort. In 15.2 I get no sound at all.<br />
* Creative SoundBlasterX AE-5 (introduced 3 years ago) is still not really supported--the annoying permanent static hiss makes impossible to listen to the music with headphones.<br />
<br />
===== Action item ===== <br />
open bugs for any issues with sound cards, especially regressions. We do have an upstream alsa maintainerand he'll be happy to help.<br />
Lubos - will open a bug or a feature to support SoundBlasterX AE-5 (as we have at least some details on the issue)<br />
<br />
=== displays ===<br />
* Two displays via DP, configured, but after restart background and bottom panel were gone (seems like new displays connected again), after second setup and next restart it holds conf so far.<br />
<br />
===== Action item =====<br />
Please report a bug<br />
<br />
=== wireless ===<br />
* My Qualcomm Atheros QCA6174 (using ath10k driver) is sometimes not being detected by the installer and I can't access online repos, when installing the oS. But this wireless chip also causes problems on any distro that I have tried it on, so I'm not gonna blame oS here. That wireless chip is fscking trash. <br />
* Driver for Realtek wifi/bluetooth interface rtl8723de on my laptop was not available, had to use google to locate a suitable driver for this interface. It now works though, so all is OK in the end. <br />
* rtl8812au never works out of the box <br />
* My USB WiFi adapter doesn't work anymore. Something with ath9k_htc module. That's why I immediately rolled back to 15.1 after update. <br />
* Initially in my laptop sometimes integrated Intel WiFi started to fail after suspend to RAM (workaround was force reload of related kernel modules by: rmmod iwldvm; rmmod iwlwifi; modprobe iwlwifi; modprobe iwldvm); but I can not reproduce recently – I am not sure, why i can no longer reproduce recently – maybe due to kernel updates... <br />
<br />
===== Action item =====<br />
Report issue against ath10k not being detected, but we'll need a feedback from the user<br />
Lubos: Report a feature for availablity of rtl8723de<br />
Lubos: report regression with rtl8723de (works in 15.1 not 15.2)<br />
I take it as the Intel Wifi issue does not happen any more so nothing to do.<br />
<br />
=== Network issues ===<br />
* Network Manager not started, LTE USB modem not acknowledged after installation<br />
* Just the password manager didn't login on wireless connection<br />
* I have to use yast to setup and use the wireless. If i use the networkmanager it can not be connected.<br />
<br />
===== Action item =====<br />
Please report a bug for the the LTE USB modem, this is not a hardware that we typically have our disposal.<br />
Please report a bug for the yast/network manager issue. As of now we don't have required details to look at the issue.<br />
<br />
=== Translations ===<br />
* Incomplete (Czech) translation of landing page. Out of date offer to try Beta version on the same page.<br />
* Translation to Swedish is still lacking a bit<br />
* If the Ukrainian language is installed in the system, then in the terminal all questions must be answered in Cyrillic! There is no way to type Y press Enter (((<br />
* Translations weren't pulling to and from weblate correctly. Needed to change all languages from 15.1 to 15.2.<br />
<br />
<br />
===== Action item ===== <br />
Owner: Marketa Calabkova / Stanislav, Lubos (for early check)<br />
* Lubos to pass the information about Czech and Swedish translations remarks to the translations team. <br />
* Lubos to raise a feature for usability issues with Y/N confirmation dialogs on Cyrilic based installations<br />
* Make sure that this doesn't happen again. Check any possible merge conflicts with Beta<br />
* Create a task in progres-o-o / Release process to double check if translations are not stuck in weblate<br />
<br />
=== Marketing ===<br />
* The were not enough announcements on public channels that openSUSE 15.2 was released, e.g. no report on golem.de.<br />
* Missed opportunity: brag about backported Wireguard kernel module in the release notes :)<br />
<br />
===== Action item =====<br />
German specific audience felt a lack of articles about the release. TODO raise this to Doug<br />
<br />
=== Documentation ===<br />
* Not really a problem but I had to read the docs to discover how to make choices on install. Which is what lead me to the docs that I like so much.<br />
<br />
===== Action item =====<br />
Pass feedback to the Translations team<br />
<br />
=== Schedule ===<br />
* The delay in release was disappointing, but worth it. <br />
<br />
===== Action item =====<br />
Acknowledged, thank you for your feedback.<br />
<br />
=== Samba ===<br />
* In this release I was unable to connect to my file server under both desktops. it is a smb server. Never have had an issue before. Gnome and KDE were both tried. Returned back to 15.1. <br />
* i am unable to connect to my file server and my external media attached to the router<br />
* I cannot get KDE to connect to my local shares at all. +2 <br />
* Accessing windows networks is terrible in 15.2 (Plasma), while in 15.1 it was super-fast (compared to 15.2 ATM, which usually takes 20+ sec to load a directory).<br />
* <br />
===== Action item =====<br />
Report a bug against samba shares.<br />
<br />
Note: Please do report a bug in case that e.g. NFS is not working. I can't really say for the text what type of the share are we talking about.<br />
<br />
=== Web server ===<br />
* Installer selected multithreaded apache2, although prefork version was installed. Installing mpm version of apache solved the problem.<br />
<br />
===== Action items =====<br />
Lubos - report a bug for this issue, seems like we have necessary information<br />
<br />
=== Virt ===<br />
==== XEN ====<br />
* User raised a concern that openSUSE (mentions also SUSE) is influenced a lot by Red Hat with a reference to our status of Xen project. The fact we do not have Xen on install media and so on. User is aware of popularity of Xen and KVM and raises a fact that Xen is mature and still used by a lot of companies.<br />
<br />
===== Action item =====<br />
On the Red Hat influence/control: Yes we do receive a lot of KVM submissions from Red Hat and therefore our KVM stack is in a very good shape. Perhaps this is what you're referring to<br />
<br />
On the Xen support: We welcome anybody who wants to help maintaining our Xen stack. You have to understand that we can't put Xen on install media until Xen passes at least some openQA tests, which implies to have a test suite.<br />
<br />
==== Virtualbox ====<br />
* VirtualBox refused to work due to unsigned kernel modules, which are not allowed for Secure Boot. I had to search for workaroud. +4 <br />
* The Guest additions no longer seem to be integrated into VirtualBox, although I noticed this in several distributions released in early 2020. <br />
* Opensuse leap freezes as a VirtualBox guest for me. I hoped v15. 2 would solve it but it didn't. I tried many reinstalls, configuring things differently. Nothing solved it. <br />
<br />
===== Action item =====<br />
Lubos - Document the unsigned/signed situation for Virtualbox. Raise this also to Virtualbox maintainer<br />
Lubos - Guest additions - check what happened with Guest additions, raise this to Virtualbox maintainer (Larry Finger). Max mentioned that we no longer build additions in the virtual box package.<br />
Please open a bug for openSUSE Leap 15.2 / Virtual box. TODO: Lubos to test virtual box, but we'll need some feedback from reporter in case that the issue can't be reproduced.<br />
<br />
=== Flatpak ===<br />
* Flatpak error on first boot. +2<br />
* Adding the Flathub repository is a bit of a mess. One needs to delete an empty directory in /var before it can be successfully enabled.<br />
* (on KDE) Flatpaks did not work initially. I had to delete a directory to perform a fix. Flatpaks also did not initially display to the X Server. I had to change my hostname in YaST and back again for them to display properly. +2<br />
<br />
===== Action items =====<br />
Lubos - Raise these issues to the maintainer. Please make sure that we have bugs reported. <br />
<br />
Antonio mentioned that the issue is fixed in updates<br />
> - Create a skeleton flatpak repo using "flatpak remotes" instead of a manually created directory https://bugzilla.opensuse.org/show_bug.cgi?id=1172316 <br />
https://bugzilla.opensuse.org/show_bug.cgi?id=1169619<br />
https://bugzilla.opensuse.org/show_bug.cgi?id=1170416<br />
<br />
=== Late updates ===<br />
* Broken systemd (and perhaps others)<br />
* lkocman: https://bugzilla.opensuse.org/show_bug.cgi?id=1173422 - Last minute acceptance from SLE, breaks rebuild of systemd on ppc64le and i586<br />
<br />
<br />
Too much paperwork for Late updates<br />
late updates to packages that are also in SLE cause lots of (IMHO too much) paperwork, see AppArmor for an example<br />
related: the requirement to have a bugreport for each and every detail in late updates is equally annoying<br />
<br />
===== Action items =====<br />
Owner: Lubos Kocman<br />
https://github.com/openSUSE/openSUSE-release-process/issues/40<br />
<br />
Late feature requests is being seen as a big over head. Raise this to the maintenance team and ECO folks. Check if lightweight ECO would be any help.<br />
<br />
=== Mirrors ===<br />
<br />
* Some mirrors were not live so there were a few errors on download attempts.<br />
* It takes time to update the website. Mirror for Brazil too slow.<br />
* The download of the iso was relatively slow off the nearby mirror, but still acceptable speed. This may be related to congestion due to the current worldwide health situation as well, but the servers still are good enough<br />
<br />
<br />
==== hotstuff-160gb and others ====<br />
<br />
https://progress.opensuse.org/issues/47621<br />
<br />
https://github.com/openSUSE/knapsack existed to automatically fill up the "hotstuff" repositories in the past, but the tool is outdated and needs development resources.<br />
<br />
I can see that modules have specific configuration which seem to be outdated +12.2 on the top for hotstuff-160GB<br />
<br />
Ludwig used rsync in the past from ftp/ftp-stage to /srv/rsync-modules, so I did it as well, but I'd like to revisit this in the future. As this doesn't sound very right to me.<br />
<br />
Action item find an owner for knapsack. Person should have access to pontifex<br />
Action item Clarify staging/prod space/server/host for mirroring modules<br />
Owner: Lubos Kocman + Doug<br />
<br />
===== Action item =====<br />
Email mirror admins regarding the feedback with brazil mirror being too slow<br />
<br />
<br />
==== (In-)Visibility of GM build ====<br />
* Leap 15.2 was officially released on thursday 2.7.2020. I saw files with correct looking dates on a mirror 1.7. or 30.6. Could not tell whether they were the final release version or some beta.<br />
<br />
==== Action item =====<br />
We've already had a discussion whether there is any point in hiding the GM build data (chmod o-x). Seems like people were inclined to not hide anything, which would then reduce confusion and also improve the mirror pre-seed.<br />
<br />
==== mirror repodata temp. issue ====<br />
<br />
https://www.reddit.com/r/openSUSE/comments/hgwijz/404_not_found_on_leap_15_2_repository_appdataxmlgzr<br />
<br />
Specifically http://download.opensuse.org/distribution/leap/15.2/repo/oss/ (repomd.xml was returning 404).<br />
Lars re-synced mirrors over mirrors. <br />
<br />
===== Action item =====<br />
Owner: Lubos or whoever does the GM/pontifex IO operations - especially late minute changes.<br />
send early/late notification to mirror@opensuse.org : keep our mirror administrators informed about changes, so they can trigger a re-sync of the "not so often" synced directories (usually /distribution/ or /ports/ ).<br />
<br />
==== 4 mirrors had issue with our NET image ====<br />
<br />
list from Robin:<br />
http://widehat.opensuse.org/distribution/leap/15.2/iso/openSUSE-Leap-15.2-NET-x86_64.iso<br />
http://ftp.man.poznan.pl/linux/opensuse/distribution/leap/15.2/iso/openSUSE-Leap-15.2-NET-x86_64.iso<br />
https://provo-mirror.opensuse.org/distribution/leap/15.2/iso/openSUSE-Leap-15.2-NET-x86_64.iso<br />
http://mirror.sjc02.svwh.net/opensuse/distribution/leap/15.2/iso/openSUSE-Leap-15.2-NET-x86_64.iso<br />
<br />
===== Action item =====<br />
look over all mirror tickets in progress-o-o (admin queue). https://progress.opensuse.org/projects/opensuse-admin/issues?query_id=461 (search the open <br />
issues in the "mirror" Category)<br />
Owner: Heroes (will need help as there is way too much)<br />
<br />
==== Fr mirror was not recognized as up2date ====<br />
<br />
Frederic noticed, that MirrorBrain did not recognize http://opensuse.mirrors.proxad.net/ as an up2date mirror, can you please have a look? (Admin issue was opened) <br />
<br />
===== Action item =====<br />
Owner: Lubos<br />
Run https://progress.opensuse.org/issues/61521 regularly (need to document when to run it. Generally after any IO change)<br />
<br />
<br />
<br />
=== OBS and pontifex ===<br />
Too many OBS repos not enabling 15.2 even on release day.<br />
/current symlinks were not bumped for updates<br />
<br />
===== Action item =====<br />
Talk to autobuild regarding mass project/repo enablement of Leap next after or shortly before the release. Perhaps schedule a meeting and invite Max as well. Keep in mind that this might be hindering some of the migrations where user has a lot of custom OBS repos.<br />
<br />
Document all locations (as part of the progres-o-o task to bump symlinks) where symlinks needs to be bumped (prod, stage), ports (probably not in 15.3 any more), updates ... Get a simple tool for this, perhaps get it automated in the future with the OBS is_released flag/attribute.<br />
<br />
<br />
=== Bugzilla ===<br />
<br />
* Not directly related to release but disappointing number of bugs related to packman, nvidia, etc. updates soon after 15.2 was released.<br />
<br />
* During Leap 15.2 development was openSUSE bugzilla multiple times down, so it was difficult to fill bugs<br />
<br />
===== Action item =====<br />
Nvidia/Pacman already have action items in sections above<br />
Bugzilla down, unfortunately we've had a carve-out (split from Microfocus) going on, so most of these outages were actually expected. Thank you for your understanding.<br />
<br />
<br />
=== Less collaboration on QA side ===<br />
<br />
From QA SLE (Userspace) perspective, there was less collaboration from our side, with many issues affecting openSUSE taking longer time without being fixed (This was added to our postmortem too)<br />
<br />
Additionally, it can be seen that several tests are only written for/tested on/enabled for SLE and not openSUSE, due to only being mentioned in SLE YAML schedules.<br />
<br />
===== Action item ===== <br />
Owner: foursixnine and Oliver, possibly outside openSUSE QA entity<br />
<br />
* Lubos to point external people who might be interested in helping with QA to progress.opensuse.org (openQA project). Perhaps also updating a landing page section "How to contribute?". We should not overwhelm new people with too much information.<br />
* foursixnine to support external people to get started with collaboration process (Prepare queries, update guides)<br />
* foursixnine to ping internal team to also improve on the collaboration side, and take up factory first approach (Tumbleweed -> SLE -> Leap)<br />
* lkocman to explain internally the contributions of SUSE for openSUSE, as mentioned below by foursixnine to find agreement how SUSE QA should contribute or is impacting openSUSE, e.g. ticket triaging onhttps://progress.opensuse.org/projects/openqatests/issues/ again (was done in past, less done for Leap 15.2), also see https://progress.opensuse.org/projects/suseqa/wiki#ticket-refinement-grooming . Adress runger, mawerner, hrommel<br />
<br />
<br />
=== Trouble with publishing ports and appliances ===<br />
<br />
Publishing Images (live isos, appliances) broke after the GM preparation:https://progress.opensuse.org/issues/61614<br />
<br />
A note from Marco: The publish hook for 15.2 ToTest/images is missing<br />
^ Seems like this was caused by disabling of rsync. Adrian mentioned that he just republished it.<br />
<br />
Adrian also mentioned that we can use setrelease functionality and avoid this struggle completely.https://github.com/openSUSE/openSUSE-release-process/issues/32<br />
<br />
This is caused by "black magic" (opaque hacks which only a few know about) both on pontifex and OBS. Those parts have to match and only very few have access to both sides. In this particular case, pontifex defined some rsync modules for appliance publishing, but OBS didn't use them and instead used the main 15.2 one which was disabled for GM preparation. If the one doing the rsync module changes on pontifex was aware of that or OBS was aware of the proper rsync modules, this issue wouldn't have happened.<br />
Adrian started some work on simplifying this, which would be very useful.<br />
<br />
===== Action item =====<br />
Owner: Lars (OBS) & Lubos (RelEng)<br />
<br />
<br />
* Create a meeting with OBS and Rel-eng to go through manual steps and possibly create issues for "standardization" perhaps in openSUSE-release-tools git repo (keep in mind the symlink bump as well)<br />
- mirrorbrain https://github.com/openSUSE/mirrorbrain<br />
- prepare GM structure<br />
- ask Adrian about the publishing simplification in OBS<br />
<br />
<br />
=== Torrents ===<br />
==== torrents were too complicated ====<br />
Owner: Bernhard and Lubos (to make updates)<br />
Action item Create a script or document how to create .torrent files that can be pre-seeded ahead of GA (let's say few hours). We'll go through automation option on the rel-eng/obs meeting.<br />
<br />
Additionally torrents were not available on launch time<br />
<br />
===== Action item =====<br />
Talk to Bernhard and Darix about how to do this ahead of GA. So far it was not possible in any openSUSE Leap 15.X release<br />
Get this automated<br />
<br />
=== Timer / Landing page ===<br />
<br />
We still have issue with the off-by one hour caused by a Berlin TZ set for the time calculation,there is currently no update on the issue https://github.com/openSUSE/landing-page/issues/113 <br />
<br />
===== Action item =====<br />
Owner: Doug<br />
Find an owner for the ticket.<br />
The countdown on the website reverted to "beta 15.2" at launch time.<br />
I was waiting the release watching the countdown, and am not sure but... I think it did not was accurate, maybe 1 day was added that was not originally there.<br />
<br />
=== OBS returns 503 around on GA date ===<br />
9:49 - 10:25<br />
build.opensuse.org is unavailable because of regular kernel deployment on Thursday<br />
we did notify infra, heroes but not buildops explicitly<br />
<br />
https://sd.suse.com/servicedesk/customer/portal/1/SD-13379<br />
https://github.com/openSUSE/openSUSE-release-process/pull/37<br />
<br />
===== Action item =====<br />
Notify buildops aside from heroes, infra about the GA and make sure that infra is not being updated or so.<br />
Owner: Lubos Kocman<br />
<br />
=== pontifex2 rsync took long time (~20s) to respond ===<br />
/etc/resolv.conf had a broken DNS server as first entry - maybe from NUE network changes ; bmwiedemann swapped order 2020-07-02 09:03<br />
<br />
===== Action item =====<br />
Make sure that we can cover resolv.conf with salt, in case that we'd have a carve-out2 any time soon :-) <br />
Owner: Heroes<br />
<br />
=== software-o-o expects current symlinks which should not be present ===<br />
===== Action item =====<br />
Owner: Lubos Kocman / or maintainer of https://github.com/openSUSE/software-o-o<br />
<br />
quick workaround create symlink, next edit page ... but why did this not happen automagically<br />
Idea; create a task to create submission to transition this ... or have links dynamic and don't use current with stable.<br />
<br />
Update to have Leap 15.2 - https://metrics.opensuse.org/<br />
* okurz: created https://github.com/openSUSE/openSUSE-release-tools/pull/2458 to cover, not sure if more changes than just on grafana side are necessary<br />
<br />
===== Action item =====<br />
<br />
Create a session with Heroes to decide on fate of Current symlinks. This seems to vary on various directories and also has to be propagated on mirrors. -Current vs -Latest vs -Stable etc. Ludwig might know why it is called current.<br />
<br />
There should be no need to change this manually in software-o-o <br />
A note: Debian also uses the stable symlink.<br />
<br />
Invitee list: Heroes, Lubos, Ludwig?, <br />
<br />
Owner: Lubos Kocman<br />
<br />
<br />
<br />
=== Outdated non-oss update repo ===<br />
<br />
non-oss repository was not up2date<br />
Lars raised that /srv/ftp/pub/opensuse/update/leap/15.2/non-oss/ is not up2date<br />
<br />
===== Action item =====<br />
https://github.com/openSUSE/openSUSE-release-process/issues/39<br />
Owner: Lubos<br />
<br />
<br />
=== non-opensuse signing key on .sha256 files ===<br />
We did not use the opensuse key to sign the data with opensuse key. this escalated back on opensuse forum.<br />
We need to document the task better https://progress.opensuse.org/issues/61560<br />
<br />
Newly added from retro: We should improve the way it's signed. Perhaps a separate .asc file. Red Hat was using and extra file for that. Lubos will check.<br />
<br />
===== Action item =====<br />
Owner: Lubos<br />
Specify signing key in request to autobuild team.<br />
<br />
=== Ports cleanup needed ===<br />
In http://download.opensuse.org/ports/aarch64/distribution/leap/15.2/iso/ we still have links with build numbers. We should hide them. Same for ppc. (It was not done for previous Leap versions)<br />
<br />
===== Action items =====<br />
post-GA-processing section should contain any cleanups (could be changes files, or broken links in ports). Possibly could be also scripted.<br />
<br />
Owner: Lubos or ports rel-eng who can raise the ticket to Heroes<br />
<br />
=== Preventing mirrors to sync GM build before it's renamed to GM ===<br />
<br />
An interesting thought is that mirrors usually sync GM build before we rename files (hide the directory). We should probably set permissions on iso dir to 754 prior we even attempt to build the GM build.<br />
<br />
What happened is that the prod (iso redirected to iso-devel) had an older build, stage had GM build. Some mirrors already had non-renamed GM build from stage.<br />
<br />
===== Action items =====<br />
Ideas: Why do we hide the GM image at all? The unveiling of image on GA is just overloading mirrors. Let's ask factory if there is any reason not to be "open open" about GM build.<br />
<br />
Perhaps use survey.opensuse.org to do a poll about this.<br />
<br />
Owner: Lubos<br />
<br />
<br />
=== switch to local builds happened relatively late. ===<br />
Switch to build local as long as there are no SLE submissions or in Beta stage, the goal is to safe building time for eg. compilers, however there are some late submissions.<br />
<br />
===== Action items =====<br />
Do not switch to local in case that we still have significant submissions or more specifically a package change. This should be also documented in progres-o-o task.<br />
<br />
Would be skipping the local build completely a solution? For TW we always keep the rebuild local mode, but in some cases we re-build the whole project manually. We've agreed with Max that keeping the default mode would be simply easier.<br />
<br />
=== Kubernetes is reported to be broken ===<br />
* Kubernetes that ships with 15.2 is reported broken. Steps required to address it before release. maintenance request<br />
<br />
===== Action items =====<br />
Owner: Lubos and QA<br />
Make last call for release notes update more visible<br />
Deploy k8s test suite to openqa<br />
Identify release teasers and make sure that they have release-notes section and known issues page.<br />
Check openqa tests against last release and tumbleweed for "lost checks". Perhaps around Beta timeframe.<br />
<br />
=== ARM === <br />
==== Bad Raspberry Pi 4 experience ====<br />
* While my regular PC upgraded easily, I also did a new install on a pi 4, support for which was just introduced. The first boot was erratic, and I ended up having to manually expand the partition. After that it booted fine, but at some point it stopped picking up dns servers from dhcp, so I had to manually set that in sysconfig and yast. Finally<br />
* <br />
chrony often used 100% cpu on a clean boot. I eventually switched it to ntp. So in a way my pi4 experience was somewhat miserable, but even so that system is now working.<br />
<br />
===== Action item =====<br />
Marina: seems like this could be caused by a late update of chrony. Udate was not picked up by Leap 15.2 GA/GM as it was released a day after.<br />
<br />
* Reach out to installer team, regarding auto-partitioning on RPi4<br />
* Advertise what image to use with RPi4 to have the smoothest experience. Raise this to Doug<br />
* Raise this issue to ARM rel-eng and also Andreas F.<br />
<br />
<br />
=== Databases ===<br />
==== postgresql ====<br />
* I have 1 problem though, the data is stored in iscsi storage, event the postgresql systemd script already consist of After=network.target, it always failed to start automatically, and the log shows it cannot find /data directory. If I login and start the postgresql service it run automagically.<br />
* Incompatibility of apps - installed PostreSQL 12 from repository and pgadmin 4.1 but this version of pgadmin does not support PostgreSQL 12.<br />
===== Action items =====<br />
<br />
pgadmin issue<br />
https://bugzilla.suse.com/show_bug.cgi?id=1174996 <br />
https://build.suse.de/request/show/223881 fix for the issue</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:Linuxrc&diff=138010SDB:Linuxrc2019-12-11T05:54:37Z<p>Okurz: Add new parameter "reboot_timeout", see https://bugzilla.suse.com/show_bug.cgi?id=1122493</p>
<hr />
<div>'''linuxrc''' is a small program that runs before the actual installation program<br />
[[Portal:YaST|YaST]] is started.<br />
<br />
It is responsible for the hardware setup and will search for an installation repository.<br />
To specify the repository location, use the [[#p_install|install]] option.<br />
<br />
The use of linuxrc is not limited to the installation. You can also use it as a boot tool<br />
for an installed system and even for an independent RAM disk–based rescue system.<br />
<br />
Linuxrc writes its settings to a special file [[SDB:Linuxrc install.inf|/etc/install.inf]] that makes them easy-to-read later. See the reference page [[SDB:Linuxrc install.inf|here]].<br />
<br />
==Passing parameters==<br />
<br />
linuxrc accepts parameters either by commandline or through configuration files.<br />
For this, pass the file location using the [[#p_info|info]] parameter.<br />
You can use this option several times - linuxrc will read all files.<br />
<br />
linuxrc parameters are case-insensitive and you can add as many hyphens, underscores,<br />
or dots as you want.<br />
<br />
The option argument can be put in doublequotes.<br />
<br />
For example, the following are all equivalent:<br />
<br />
SSHPassword=foo<br />
sshpassword="foo"<br />
ssh.password=foo<br />
ssh-password="foo"<br />
ssh_password=foo<br />
S.Shp-AsSw._.orD=foo<br />
<br />
Parameters that are unknown to linuxrc but are of the form ''foo.bar'' are<br />
interpreted as options to kernel modules. See [[#p_options|options]] for<br />
details.<br />
<br />
==Network Config==<br />
<br />
linuxrc configures the network automatically when it is needed. That is, it<br />
has to access files via a network url or an ssh/vnc setup is requested.<br />
The default is to send a dhcp request.<br />
<br />
This section summarises how to influence linuxrc's network setup.<br />
<br />
Note that linuxrc will store the network config in /etc/sysconfig/network/<br />
and then run wicked to actually configure the network.<br />
<br />
There are wo ways<br />
<br />
===Classical===<br />
<br />
Use the [[#p_hostip|hostip]], [[#p_gateway|gateway]], [[#p_nameserver|nameserver]], [[#p_domain|domain]], and [[#p_vlanid|vlanid]] options to setup a<br />
static config. Otherwise dhcp is used. Use [[#p_netdevice|netdevice]] to specify the<br />
interface (otherwise it tries all interfaces until things work).<br />
<br />
If linuxrc itself does not need a network but you want to setup it anyway,<br />
use the [[#p_netsetup|netsetup]] option.<br />
<br />
===<span id="using_ifcfg">Using ifcfg</span>===<br />
<br />
With SLE12/openSUSE 13.2 comes a new [[#p_ifcfg|ifcfg]] option that gives you more<br />
control over network settings. It also lets you configure several network<br />
interfaces.<br />
<br />
Use ifcfg=$IF_NAME=dhcp for dhcp or ifcfg=$IF_NAME=hostip,gateway,nameserver,domain as<br />
a shorthand to the options described above. Instead of dhcp, you can use dhcp4 or dhcp6<br />
to force either ipv4 or ipv6 dhcp leases.<br />
<br />
For example:<br />
<br />
ifcfg=*=dhcp<br />
<br />
This will run dhcp on all interfaces. If you do this with a static setup,<br />
only the first matching interface is configured:<br />
<br />
ifcfg=eth*=10.0.1.1/24,10.0.1.254<br />
<br />
This will setup only your first ethernet interface.<br />
<br />
The shell wildcard pattern is matched against interface names and MAC<br />
addresses. But it will never match 'lo'.<br />
<br />
You can setup vlans by adding a vlan id to the interface.<br />
<br />
ifcfg=eth0.66=10.0.1.1/24,10.0.1.254<br />
<br />
For more esoteric uses you can append (comma-separated) arbitrary keys<br />
from /etc/sysconfig/network/ifcfg.template and /etc/sysconfig/network/config.<br />
<br />
ifcfg=*=dhcp6,DHCLIENT6_MODE=managed,CHECK_DUPLICATE_IP=no<br />
<br />
Note that hostip, gateway, nameserver, and domain accept space separated<br />
multiple values. So please add quotes (") when doing this on the kernel <br />
command line.<br />
<br />
ifcfg="eth0=10.0.1.1/24,10.0.1.254,10.0.1.10 10.0.1.11,foo.bar zap.bar"<br />
<br />
When using bonding you have to also use an additional parameter so linuxrc takes the device into account.<br />
<br />
hwprobe=+200:*:*:bond0<br />
<br />
===Wireless Network Setup===<br />
<br />
linuxrc supports three authentication variants: open (no authentication) wlan, WPA-PSK (WPA with<br />
pre-shared key), and WPA-PEAP (WPA with user id and password authentication).<br />
<br />
More specialized variants or the obsolete WEP are not directly supported but you can still pass<br />
suitable ''WIRELESS_*'' parameters directly via the [[#p_ifcfg|ifcfg]] option.<br />
<br />
linuxrc will normally ask the necessary parameters automatically when it is about to set up<br />
a wifi interface. But you can also pass the values via boot options.<br />
<br />
For an open wlan use, e.g.:<br />
<br />
essid=foo wlanauth=open<br />
<br />
For a WPA-PSK setting use, e.g.:<br />
<br />
essid=foo wpapsk=foobarsecret<br />
<br />
For a WPA-PEAP setting use, e.g.:<br />
<br />
essid=foo wpaidentity=foouser wpapassword=barsecret<br />
<br />
==AutoYaST Profile Handling==<br />
<br />
# [[#p_autoyast|AutoYaST]]=<autoyast_url><br />
# [[#p_autoyast2|AutoYaST2]]=<linuxrc_url><br />
# /autoinst.xml on local storage with label 'OEMDRV'<br />
# /autoinst.xml on install media<br />
# /autoinst.xml in initrd<br />
<br />
The first AutoYaST profile found is used. In 1. just the profile location is<br />
passed to YaST. In all other cases linuxrc reads and parses the profile (so<br />
you can embed linuxrc options).<br />
<br />
==Parameter Reference==<br />
<br />
<span id="url_descr"></span><br />
<br />
Some parameters expect a URL as argument. Here is a short overview of the syntax.<br />
<br />
Supported schemes:<br />
<br />
cd (or cdrom) # CD-ROM<br />
hd (or harddisk) # local hard disk<br />
disk # any local disk device (CD-ROM, hard disk or floppy)<br />
file # local file<br />
floppy # floppy (better use ''disk'')<br />
ftp # ftp server<br />
http # http server<br />
https # https server<br />
nfs # nfs server<br />
slp # use SLP to get the real URL<br />
smb (or cifs) # Windows share<br />
tftp # tftp server<br />
<br />
General format:<br />
scheme://domain;user:password@server:port/path?query<br />
<br />
If ''scheme:'' is missing, a relative URL is assumed which is normally<br />
relative to the repository.<br />
<br />
Don't forget the brackets if you enter a literal IPv6 address; e.g.:<br />
<nowiki>http://[2001:db8:42:815::1]/some_dir</nowiki><br />
<br />
For ''smb''/''cifs'' ''path'' is preceded with the ''share'' name:<br />
path = share/path<br />
<br />
''domain'' is only for scheme ''smb''/''cifs'' and specifies the domain/workgroup<br />
of the user.<br />
<br />
For references to local devices, using ''cd'', ''disk'', ''floppy'', ''hd'',<br />
''path'' can optionally be preceded with the device name<br />
path = device/path<br />
For another way to specify the device, see below.<br />
<br />
''query'' may be one or more of<br />
device=device_pattern<br />
type=file|dir # url points to a file or directory<br />
instsys=URL # install parameter only<br />
service=slp_service # slp scheme only<br />
descr=slp_descr # slp scheme only<br />
url=slp_url # slp scheme only<br />
<br />
separated by '&amp;'.<br />
<br />
<span id="device_descr"></span><br />
<br />
''device'' specifies the device to use (linuxrc will normally try all devices<br />
in turn). You can use typical shell metacharacters here. Like:<br />
<br />
install=cd:/?device=sr0 # first CD-ROM<br />
install=cd:/sr0 # alternative form<br />
install=cd:/dev/sr0 # optionally add /dev<br />
install=hd:/?device=sdb* # any partition on 2nd hard disk<br />
install=hd:/?device=*label/foo # partition with fs label 'foo'<br />
install=nfs://foo/bar?device=eth0 # works with network devices, too<br />
install=nfs://foo/bar?device=00:0e:0c:* # matches MAC addresses, too<br />
<br />
''instsys'' is only relevant for the [[#p_install|install]] parameter. Also, see<br />
[[#p_instsys|instsys]] option.<br />
<br />
''service'', ''descr'' and ''url'' are only useful for scheme ''slp'' and<br />
limit the list of URLs. Like:<br />
<br />
# get URL list via SLP<br />
install=slp:/<br />
# ... but only those with 'openSUSE' in the description<br />
install=slp:/?descr=*openSUSE*<br />
# ... and only ftp URLs<br />
install=slp:/?descr=*openSUSE*&url=ftp:*<br />
<br />
You will probably never need any parameter except [[#p_install|install]].<br />
But in case you do, here is the complete list.<br />
<br />
<br />
{| class="wikitable"<br />
! Parameter <br />
! Description<br />
<br />
|-<br />
<br />
| addon ||<br />
<span id="p_addon"></span><br />
<br />
Add an additional add-on product, the parameter is a comma separated list of URLs.<br />
Addons can be added interactively during installation, this parameter is useful<br />
for PXE boot of custom boot media to define the default addons.<br />
If multiple products are found, YaST will give you a choice which of them to use.<br />
<br />
Examples:<br />
# a single addon<br />
addon=https://example.com/addon<br />
# multiple addons<br />
addon=https://example.com/addon1,ftp://user:password@example.com/addon2<br />
# one medium with multiple addons, choose later<br />
addon=dvd:///?devices=/dev/sr1<br />
# multiple addons<br />
addon=dvd:///?devices=/dev/sr1,dvd:///?devices=/dev/sr2<br />
# one addon with a fallback list, so YaST will use the first device containing a<br />
# repository (note that you need to use '%2C' instead of a comma)<br />
addon=dvd:///?devices=/dev/sr0%2C/dev/sr1<br />
|-<br />
<br />
| AddSwap ||<br />
<span id="p_addswap"></span><br />
<br />
Tries to activate a ''swap'' partition. If set to 0, the system does not<br />
try to activate a ''swap'' partition. If set to a positive number, the<br />
partition corresponding to the number is activated as a swap partition. With a negative number, linuxrc will<br />
present you a dialog for selecting the swap partition or creating a swap file.<br />
Alternatively, specify the full device name of a partition.<br />
<br />
Examples:<br />
addswap=/dev/sda2<br />
# '/dev/' is optional<br />
addswap=sda2<br />
# 3rd swap partition<br />
addswap=3<br />
# never ask for swap (even if it might be a good idea)<br />
addswap=0<br />
# interactive<br />
addswap=-1<br />
<br />
|-<br />
<br />
| Alias ||<br />
<span id="p_alias"></span><br />
<br />
|-<br />
<br />
| <span id="p_autoassembly">AutoAssembly</span> ||<br />
<br />
This parameter can be used to disable MD/RAID auto-assembly (the default is 1 - enabled).<br />
<br />
You might use this option if you have a combined RAID/multipath setup and the installer has problems to correctly analyze your setup.<br />
<br />
Example:<br />
# disable auto-assembly<br />
AutoAssembly=0<br />
<br />
|-<br />
<br />
| AutoYaST ||<br />
<span id="p_autoyast"></span><br />
<br />
This parameter can be used to initiate an automatic installation using<br />
[http://doc.opensuse.org/projects/autoyast/ AutoYaST].<br />
The value must be a URL pointing to an AutoYaST installation profile.<br />
Note that linuxrc does not use this option in any way. It just passes it on to YaST.<br />
Note also that AutoYaST uses its own URL schemata that differ from linuxrc's.<br />
See the [https://doc.opensuse.org/projects/autoyast/#invoking_autoinst.options AutoYaST documentation] for details.<br />
<br />
Example:<br />
<nowiki>AutoYaST=ftp://example.com/autoyast_profile.xml</nowiki><br />
<br />
|-<br />
<br />
| AutoYaST2 ||<br />
<span id="p_autoyast2"></span><br />
<br />
This parameter can be used to initiate an automatic installation using<br />
[http://doc.opensuse.org/projects/autoyast/ AutoYaST].<br />
The value must be a URL pointing to an AutoYaST installation profile.<br />
For supported schemes and a syntax description, look [[#url_descr|here]].<br />
<br />
In contrast to the [[#p_autoyast|AutoYaST]] option linuxrc loads the AutoYaST file and passes it to YaST.<br />
<br />
You can embed linuxrc options into the AutoYaST file as described in the<br />
[https://doc.opensuse.org/projects/autoyast/#invoking_autoinst AutoYAST documentation].<br />
<br />
This option has no effect if an [[#p_autoyast|AutoYaST]] option is used at the same time.<br />
<br />
Example:<br />
<nowiki>AutoYaST2=ftp://example.com/autoyast_profile.xml</nowiki><br />
<br />
|-<br />
<br />
| AUTOUPGRADE ||<br />
<span id="p_autoupgrade"></span><br />
<br />
This parameter can be used to initiate an automatic upgrade using<br />
[http://doc.opensuse.org/projects/autoyast/ AutoYaST].<br />
The value must be 1. The additional path of the AutoYaST configuration<br />
file must be given too.<br />
<br />
This option has no effect if an [[#p_autoyast|AutoYaST]] or [[#p_autoyast2|AutoYaST2]] option is not used at the same time.<br />
<br />
Example:<br />
<nowiki>autoupgrade=1 AutoYaST2=ftp://example.com/autoyast_profile.xml</nowiki><br />
<br />
|-<br />
<br />
| biosdevname ||<br />
<span id="p_biosdevname"></span><br />
<br />
Use BIOS network interface names (instead of eth*). The option<br />
itself is not used by linuxrc but passed on to YaST.<br />
<br />
Example:<br />
biosdevname=1<br />
<br />
|-<br />
<br />
| BOOTPTimeout ||<br />
<span id="p_bootptimeout"></span><br />
<br />
Timeout for BOOTP requests in seconds.<br />
<br />
|-<br />
<br />
| Bootpwait ||<br />
<span id="p_bootpwait"></span><br />
<br />
Sets a delay between interface setup and bootp request in seconds.<br />
<br />
Example:<br />
BootpWait=10<br />
<br />
|-<br />
<br />
| Broadcast ||<br />
<span id="p_broadcast"></span><br />
<br />
Broadcast IP address<br />
<br />
Example:<br />
Broadcast=10.10.255.255<br />
<br />
|-<br />
<br />
| BrokenModules ||<br />
<span id="p_brokenmodules"></span><br />
<br />
Comma-separated list of modules that will not be loaded during initialization.<br />
You can prepend a '+' or a '-' to the (whole) list indicating the modules<br />
should be added or removed (instead of replacing) the broken modules list.<br />
<br />
Example:<br />
BrokenModules=ahci,ata_piix<br />
BrokenModules=-tg3<br />
<br />
|-<br />
<br />
| ConsoleDevice ||<br />
<span id="p_consoledevice"></span><br />
<br />
Console device name.<br />
<br />
Example:<br />
ConsoleDevice=/dev/tty9<br />
<br />
|-<br />
<br />
| <span id="p_debugshell">debug.shell</span> ||<br />
<br />
Specify the command to run when linuxrc starts a shell for debugging.<br />
<br />
Example<br />
debug.shell=bash<br />
<br />
|-<br />
<br />
| <span id="p_debugwait">debug.wait</span> ||<br />
<br />
For debugging purposes linuxrc can stop at a number of places and offer to start a shell to inspect the system. You can pass a comma-separated list of such control points. Each entry is a shell wildcard pattern that must match either a function name or module:line_number.<br />
<br />
Examples:<br />
# stop in the network code around line 2500-2599 and in lxrc_end()<br />
debug.wait=net:25??,lxrc_end<br />
<br />
|-<br />
<br />
| <span id="p_defaultinstall">defaultinstall</span> ||<br />
<br />
Comma-separated list of installation sources to try when no [[#p_install|install]] option is given.<br />
<br />
Example:<br />
# first look at cdroms, then check local disks<br />
install.default=cd:/,hd:/<br />
<br />
|-<br />
<br />
| <span id="p_defaultrepo">defaultrepo</span> ||<br />
<br />
An alias for [[#p_defaultinstall|defaultinstall]].<br />
<br />
|-<br />
<br />
| <span id="p_device">device</span> ||<br />
<br />
Specify the storage device to use when looking for a repository.<br />
See [[#device_descr|device description]] for allowed values.<br />
<br />
Normally, this is not necessary. But if you really need this option, consider<br />
adding it to the URL of the [[#p_install|install]] parameter.<br />
<br />
Examples:<br />
device=sr1 # 2nd CD-ROM drive<br />
device=sdc* # partition on 3rd disk<br />
<br />
|-<br />
<br />
| <span id="p_display">display</span> ||<br />
<br />
Sets the linuxrc color scheme.<br />
<br />
* ''1'' - Monochromatic display [black/white]<br />
* ''2'' - VGA colors [blue/white] (default)<br />
* ''3'' - Alternative VGA colors [green/white]<br />
<br />
Example:<br />
# go greenish<br />
display=3<br />
<br />
|-<br />
<br />
| Display_IP ||<br />
<span id="p_displayip"></span><br />
<br />
IP address of X server for remote installation via X11<br />
<br />
Example:<br />
Display_IP=10.10.1.57<br />
<br />
Note: Screen <code>:0.0</code> is used by default. Since SLE11-SP4 and SLE12-SP1 it possible to specify the required screen number, e.g. <code>Display_IP=10.10.1.57:1</code>. IPv6 address needs to be enclosed in square brackets, e.g. <code>Display_IP=[2001:db8::ff00:42:8329]:1</code>.<br />
|-<br />
<br />
| DHCP ||<br />
<br />
No longer supported.<br />
<br />
|-<br />
<br />
| DHCPCD ||<br />
<span id="p_dhcpcd"></span><br />
<br />
Additional options for ''dhcpcd'' (the DHCP client used by linuxrc).<br />
<br />
Example:<br />
dhcpcd=-B<br />
<br />
|-<br />
<br />
| DHCPTimeout ||<br />
<span id="p_dhcptimeout"></span><br />
<br />
Timeout for DHCP requests in seconds.<br />
<br />
Example:<br />
dhcptimeout=120<br />
<br />
|-<br />
<br />
<span id="p_disablesnapshots"></span><br />
| DisableSnapshots ||<br />
<br />
Temporarily disables creating filesystem snapshots during installation or system upgrade.<br />
There are different types of snapshots: ''single'' are common snapshots when a defined<br />
milestone is reached, ''around'' stand for ''pre'' and ''post'' snapshots that are usually<br />
created right before and right after calling YaST.<br />
<br />
Example:<br />
disable_snapshots=all # disables creating all snapshots<br />
disable_snapshots=single,around # disables creating pre, post, and single snapshots<br />
<br />
Note: Since openSUSE 13.3 or SLE 12 SP1<br />
<br />
|-<br />
| Domain ||<br />
<span id="p_domain"></span><br />
<br />
Domain search path for DNS. Only useful for non-DHCP network config.<br />
<br />
Example:<br />
domain=opensuse.org<br />
<br />
|-<br />
<br />
| DriverUpdate ||<br />
<span id="p_driverupdate"></span><br />
<br />
Obsolete alias for [[#p_dud|dud]] parameter. Please use [[#p_dud|dud]] instead.<br />
<br />
|-<br />
<br />
| DUD ||<br />
<span id="p_dud"></span><br />
<br />
For documentation on driver updates see http://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO/index.html.<br />
<br />
An easy to use script for creating driver updates is available at<br />
http://software.opensuse.org/package/mkdud?search_term=mkdud<br />
<br />
There are two semantics: ''dud=1'' and ''dud=<url>''.<br />
With ''dud=1'' linuxrc lets you interactively select a driver update.<br />
''dud=<url>'' specifies the location of the driver update directly.<br />
''<url>'' should point either to a directory with the unpacked driver update<br />
or to a driver update archive.<br />
<br />
You can use this option several times; linuxrc will load all specified updates.<br />
<br />
For supported schemes and a syntax description, look [[#url_descr|here]].<br />
<br />
Note that driver updates are automatically searched for on your installation<br />
server/media. You don't have to use this option for that.<br />
<br />
Examples:<br />
# ask for driver update disk<br />
dud=1<br />
# load 'myupdate' from server 'foo'<br />
dud=<nowiki>ftp://foo/myupdate</nowiki><br />
# search & load 'update1' on local disks and load update2 from network<br />
dud=disk:/update1 dud=<nowiki>http://foo/update2</nowiki><br />
<br />
For easy testing the semantics has been extended a bit: if ''<url>'' does not<br />
point to a driver update but rather a normal filesystem image, cpio archive, or rpm,<br />
it is unpacked and the files are added to the install (or rescue) system.<br />
<br />
Examples:<br />
# add vsftpd ftp server to rescue system<br />
# rescue=1 dud=<nowiki>http://foo/bar/vsftpd.rpm</nowiki><br />
<br />
|-<br />
<br />
| <span id="p_escdelay">ESCDelay</span> ||<br />
<br />
|-<br />
<br />
| ESSID ||<br />
An alias for [[#p_wlanessid|WlanESSID]]<br />
|-<br />
<br />
| ethtool ||<br />
<span id="p_ethtool"></span><br />
<br />
Run ''[[ethtool]]'' for any or all network interfaces.<br />
Ethtool can change ethernet card settings. See ''man ethtool'' for details.<br />
<br />
Format:<br />
[if0=]option<br />
<br />
Examples:<br />
"ethtool=eth0=duplex full" # only applies to eth0<br />
"ethtool=speed 10" # applies to all network interfaces<br />
<br />
|-<br />
<br />
| Exec ||<br />
<span id="exec"></span><br />
<br />
Executes an additional binary.<br />
<br />
Example:<br />
exec=/usr/bin/top<br />
<br />
|-<br />
<br />
| Expert ||<br />
<span id="p_expert"></span><br />
<br />
''deprecated''<br />
<br />
Combines ''Textmode'' and ''DriverUpdate''<br />
<br />
Values:<br />
0 ignored<br />
1 enable text mode<br />
2 ask for driver update disk<br />
3 both<br />
<br />
|-<br />
<br />
| FloppyDevice ||<br />
<span id="p_floffydevice"></span><br />
<br />
No longer supported. Use [[#p_install|install]].<br />
<br />
|-<br />
<br />
| ForceRootimage ||<br />
<br />
No longer supported.<br />
<br />
|-<br />
<br />
| Gateway ||<br />
<span id="p_gatway"></span><br />
<br />
This specifies the gateway through which the installation server can be<br />
reached if it is not located in the subnetwork of the host.<br />
<br />
Example:<br />
gateway=192.168.1.1<br />
<br />
|-<br />
<br />
| HasPCMCIA ||<br />
<span id="p_haspcmcia"></span><br />
<br />
|-<br />
<br />
| HostIP ||<br />
<span id="p_hostip"></span><br />
<br />
Specifies the static IP address of the host. The number<br />
of network bits can be appended, saving you the extra ''netmask'' parameter.<br />
<br />
Examples:<br />
hostip=192.168.1.101<br />
# or, giving netmask 255.255.255.0 as well<br />
hostip=192.168.1.101/24<br />
<br />
|-<br />
<br />
| Hostname ||<br />
<span id="p_hostname"></span><br />
<br />
Full qualified hostname.<br />
<br />
|-<br />
<br />
| HWDetect ||<br />
<span id="p_hwdetect"></span><br />
<br />
Controls hardware detection.<br />
<br />
Values: 0 (off), 1 (on)<br />
<br />
|-<br />
<br />
| <span id="p_ifcfg">ifcfg</span> ||<br />
<br />
Use this option to configure network interfaces. This option directly controls the content of<br />
the ''/etc/sysconfig/network/ifcfg-*'' files.<br />
<br />
linuxrc normally will try to find and configure a suitable network interface '''when it needs one'''.<br />
<br />
But sometimes you want to have network configured even if it's not directly necessary for installation<br />
or you need to configure several interfaces or you need special config options for your interface.<br />
<br />
The general syntax is, for dhcp:<br />
<br />
ifcfg=<interface_spec>=dhcp*,OPTION1=value1,OPTION2=value2...<br />
<br />
and, for a static setup:<br />
<br />
ifcfg=<interface_spec>=IP_LIST,GATEWAY_LIST,NAMESERVER_LIST,DOMAINSEARCH_LIST,OPTION1=value1,...<br />
<br />
''<interface_spec>'' is either an interface name or hardware address or a shell glob that is matched<br />
against interface names and hardware addresses.<br />
<br />
Examples:<br />
ifcfg=eth1=dhcp # run dhcp on eth1<br />
ifcfg=eth*=dhcp # run dhcp on all ethernet interfaces<br />
ifcfg=12:34:56:78:9A:BC # run dhcp on an interface with the specified mac address <br />
ifcfg=*:BC # run dhcp on all interfaces whose mac address ends in ':BC'<br />
<br />
The interface spec will never match the loopback interface ''lo''. So it's ok to use<br />
''ifcfg=*=dhcp'' to configure all interfaces via dhcp.<br />
<br />
''dhcp*'' above stands for either ''dhcp'', ''dhcp4'', or ''dhcp6''.<br />
<br />
Note that ''*_LIST'' above are space-separated lists. So please don't forget to put quotes<br />
around the whole option when necessary (e.g. when used on the kernel command line). You can<br />
use either ipv4 or ipv6 addresses (and even mix them).<br />
<br />
''IP_LIST'' contains values in ''IP_ADDRESS/PREFIX'' form (there's no separate netmask value).<br />
<br />
Both dhcp and static config parameters can be optionally followed by an arbitrary list of<br />
''OPTION=value'' pairs. All these are put verbatim into ''/etc/sysconfig/network/ifcfg-*'' or<br />
''/etc/sysconfig/network/config'' resp. (depending on where they belong).<br />
<br />
|-<br />
<br />
| IgnoreFeatures ||<br />
<span id="p_ignore_features"></span><br />
<br />
Comma-separated list of features in installer that should not be used. Right now, only ''import_users'' (imports local users from previous installation on disk) and ''import_ssh_keys'' (imports SSH keys from previous installation on disk) are supported. If you don't want this parameter to be appended to Kernel commandline later, use also [[#p_ptoptions|PTOptions]].<br />
<br />
Added in SLE 12.<br />
<br />
Examples:<br />
ignore_features=import_users<br />
ignore_features=import_users,import_ssh_keys<br />
<br />
|-<br />
<br />
| Info ||<br />
<span id="p_info"></span><br />
<br />
Specifies the file to read more options from as URL. For supported schemes and<br />
a syntax description, look [[#url_descr|here]].<br />
<br />
linuxrc reads all specified files. A file may contain further ''info'' parameters.<br />
<br />
Examples:<br />
info=cd:/info1<br />
info=disk:/install/info2<br />
info=<nowiki>http://foo/bar/info3</nowiki><br />
<br />
|-<br />
<br />
| InitrdID ||<br />
<span id="p_initrdid"></span><br />
<br />
Forces initrd ID to a given value. linuxrc compares instsys and initrd IDs and only proceeds if both are identical.<br />
<br />
|-<br />
<br />
| Insecure ||<br />
<span id="p_insecure"></span><br />
<br />
linuxrc checks SHA1 sums of all files it downloads. They are taken from<br />
''(repository):/content'' after its signature has been verified.<br />
<br />
If you don't want this, do:<br />
<br />
insecure=1<br />
<br />
Note that it is not possible to bring linuxrc back into secure mode after this.<br />
In particular:<br />
<br />
insecure=0<br />
<br />
will not work.<br />
<br />
|-<br />
<br />
| Insmod ||<br />
<span id="p_insmod"></span><br />
<br />
This specifies a module the kernel should load, together with any parameters needed for it. Module parameters must be separated by blanks.<br />
<br />
The module is loaded before hardware detection starts. Module<br />
dependencies are automatically resolved (the name ''insmod'' is a bit<br />
misleading here).<br />
<br />
Note that modules blacklisted with [[#p_brokenmodules|brokenmodules]]<br />
cannot be loaded this way.<br />
<br />
Examples:<br />
# load ahci<br />
insmod=ahci<br />
# remember the quotes<br />
insmod="loop max_loop=100"<br />
# load several modules<br />
insmod=tg3 insmod=e1000<br />
<br />
|-<br />
<br />
| <span id="p_install">install</span> ||<br />
<br />
Specifies the installation repository as URL. For supported schemes and<br />
a syntax description, look [[#url_descr|here]].<br />
<br />
It must point to either a directory or an ISO image.<br />
<br />
Additionally, a special scheme ''exec'' is supported which does<br />
not need a repository but just runs the argument after linuxrc did<br />
the hardware setup.<br />
<br />
Examples:<br />
# from CD-ROM<br />
install=cd:/<br />
# ftp from server ''foo'', directory ''pub/bar''<br />
install=<nowiki>ftp://foo/pub/bar</nowiki><br />
# local disk, ISO image ''zap.iso'' in directory ''bar''<br />
install=hd:/bar/zap.iso<br />
# Windows share ''bar'', ISO image ''zap.iso'' on server ''foo''<br />
install=smb://foo/bar/zap.iso<br />
# get real URL via SLP<br />
install=slp:/<br />
# just start a shell<br />
install=exec:/bin/sh<br />
<br />
The installation program is normally loaded from the repository. If for some<br />
reason you don't want this, you can specify the installation system image to<br />
use explicitly by adding ''?instsys='' or using the [[#p_instsys|instsys]] parameter; for example:<br />
<br />
<nowiki>install=cd:/?instsys=ftp://testserver/foo</nowiki><br />
# is the same as<br />
<nowiki>instsys=ftp://testserver/foo install=cd:/</nowiki><br />
<br />
|-<br />
<br />
| <span id="p_instsys">instsys</span> ||<br />
<br />
Specifies the installation system to use. Default value is<br />
''boot/<arch>/root''. May point to a filesystem image or to a directory.<br />
For supported schemes and a syntax description, look [[#url_descr|here]].<br />
See [[#p_install|install]] for an alternative way to specify it.<br />
<br />
Example:<br />
instsys=my/zappel # use ''my/zappel'' from repository<br />
instsys=<nowiki>http://foo/zappel</nowiki> # use ''zappel'' from server ''foo''<br />
<br />
|-<br />
<br />
| <span id="p_instsyscomplain">instsys.complain</span> ||<br />
<br />
Controls what initrd should do if initrd ID and instsys ID do not match.<br />
<br />
Values:<br />
0 ignore<br />
1 print a warning<br />
2 abort with an error<br />
<br />
In non-Beta systems this parameter defaults to 0 (ignore).<br />
<br />
|-<br />
<br />
| InstsysID ||<br />
<span id="p_instsysid"></span><br />
<br />
Force instsys ID to a given value. linuxrc compares instsys and initrd IDs and only proceeds if both are identical.<br />
<br />
|-<br />
<br />
| <span id="p_ipv4">ipv4</span> ||<br />
<br />
Enable or disable IPv4 support. (Both IPv4 and IPv6 are enabled by default.)<br />
<br />
Example:<br />
# disable IPv4<br />
ipv4=0<br />
<br />
|-<br />
<br />
| <span id="p_ipv4only">ipv4only</span> ||<br />
<br />
Enable IPv4 support, disable IPv6.<br />
<br />
Example:<br />
ipv4only=1<br />
# is identical to<br />
ipv4=1 ipv6=0<br />
# or<br />
ipv6only=0<br />
<br />
|-<br />
<br />
| <span id="p_ipv6">ipv6</span> ||<br />
<br />
Enable or disable IPv6 support. (Both IPv4 and IPv6 are enabled by default.)<br />
<br />
Example:<br />
# disable IPv6<br />
ipv6=0<br />
<br />
|-<br />
<br />
| <span id="p_ipv6only">ipv6only</span> ||<br />
<br />
Enable IPv6 support, disable IPv4.<br />
<br />
Example:<br />
ipv6only=1<br />
# is identical to<br />
ipv4=0 ipv6=1<br />
# or<br />
ipv4only=0<br />
<br />
|-<br />
<br />
| KBDTimeout ||<br />
<span id="p_kbdtimeout"></span><br />
<br />
''windowed only''<br />
<br />
Keyboard timeout in seconds. The time after which linuxrc proceeds with default values if no input is made. Default to ''0'' (off).<br />
<br />
|-<br />
<br />
| <span id="p_kexec">Kexec</span> ||<br />
<br />
linuxrc has the capability to download and run a new kernel and initrd pair from the repository. The installation process will basically be restarted (with this option disabled).<br />
<br />
This can spare users installing via network the download of a new boot medium as they<br />
can keep using the existing one.<br />
<br />
There are four settings for the kexec option:<br />
<br />
0: feature disabled<br />
1: always restart with kernel/initrd from repository (without bothering to check<br />
if it's necessary)<br />
2: restart only if needed - that is, if linuxrc detects that the booted initrd is<br />
outdated (this is the default)<br />
3: like kexec=2 but without user interaction<br />
<br />
The difference between <code>kexec=2</code> and <code>kexec=3</code> is that in the first case the user is presented a dialog asking for confirmation before downloading kernel and initrd.<br />
<br />
Example:<br />
# do it without asking the user<br />
kexec=3<br />
<br />
|-<br />
<br />
| kexec_reboot ||<br />
<span id="p_kexec_reboot"></span><br />
<br />
If set to ''1'' (the default on most machines), then kexec will be used to reboot the machine after finishing the 1st stage of installation. If set to ''0'', a normal reboot will be used. There is some blacklist maintained in YaST (for example for VirtualBox) for machine that are known to be broken with kexec.<br />
<br />
|-<br />
<br />
| Keytable ||<br />
<span id="p_keytable"></span><br />
<br />
Virtual console keyboard map to load.<br />
<br />
Example:<br />
Keytable=fr-latin1<br />
<br />
|-<br />
<br />
| Lang ||<br />
<span id="p_lang"></span><br />
<br />
Alias for ''Language'' parameter.<br />
<br />
|-<br />
<br />
| Language ||<br />
<span id="p_language"></span><br />
<br />
Language preselected for the installation.<br />
<br />
Example:<br />
Language=de_DE<br />
Language=fr_FR<br />
Language=cs_CZ<br />
<br />
|-<br />
<br />
| Linemode ||<br />
<br />
<span id="p_linemode"></span><br />
<br />
Enables line-mode usable on dumb terminals.<br />
<br />
Example:<br />
linemode=1<br />
<br />
|-<br />
<br />
| linuxrc ||<br />
<br />
Obsolete. Please don't use.<br />
<br />
|-<br />
<br />
| <span id="p_linuxrccore">linuxrc.core</span> ||<br />
<br />
Enable linuxrc core dumps.<br />
<br />
The argument must be either a block device or a character device.<br />
<br />
If it is a block device, it is mounted (so there must be a file system on it)<br />
and core files are written onto this device.<br />
<br />
If it is a character device (e.g. a serial line), the core dump is written uuencoded to this<br />
device. Use the ''uudecode'' tool to decode it. Note that as linuxrc runs as init process the kernel<br />
will stop right after writing the core dump and the last bytes may never get flushed. You will have<br />
to fix up the uuencoded dump by appending the typical trailing bytes manually before running ''uudecode''<br />
on the serial line log.<br />
<br />
Examples:<br />
linuxrc.core=/dev/sdb1<br />
linuxrc.core=/dev/console<br />
<br />
|-<br />
<br />
| <span id="p_linuxrcdebug">linuxrc.debug</span> ||<br />
<br />
Comma-separated list of a numerical debug level (max. 4) and debug flags.<br />
Flags can be turned on or off (prepend '+' or '-'). Debug flags currently<br />
supported are:<br />
<br />
* ''tmpfs'': move everything into tmpfs at startup (default)<br />
* ''udev'': use udev to manage ''/dev'' tree (default)<br />
* ''udev.mods'': let udev load modules (default)<br />
* ''wait'': stop at critical points and wait for a keypress<br />
* ''trace'': enable backtrace<br />
<br />
See also [[#p_debugwait|debug.wait]].<br />
<br />
Examples:<br />
# a reasonable amount of debug info<br />
linuxrc.debug=1<br />
# ... and stop at some critical points<br />
linuxrc.debug=1,wait<br />
# linuxrc loads drivers itself<br />
linuxrc.debug=-udev.mods<br />
# don't copy files into tmpfs (but keep them in ramfs)<br />
linuxrc.debug=-tmpfs<br />
<br />
|-<br />
<br />
| <span id="p_linuxrclog">linuxrc.log</span> ||<br />
<br />
Device to print log messages to. Defaults to ''/dev/tty3''.<br />
To see more log messages, increase the [[#p_linuxrcdebug|debug level]].<br />
<br />
If you want you log to be automatically saved to the target system, place it in ''/var/log/YaST2/''.<br />
<br />
Example:<br />
# save all log messages to 'foo.log'<br />
linuxrc.log=/foo.log<br />
# show them on the default console (ideally together with ''[[#p_linemode|linemode]]'')<br />
linuxrc.log=/dev/console linemode=1<br />
<br />
|-<br />
<br />
| linuxrc.stderr ||<br />
<br />
Obsolete. Use [[#p_linuxrclog|linuxrc.log]].<br />
<br />
|-<br />
<br />
| listen ||<br />
<br />
''* experimental *''<br />
<br />
linuxrc sets up the network and listens on the specified port for<br />
input. (You may want to use ''[[#p_manual|manual]]''=1 along with this option and then connect via telnet to linuxrc.)<br />
<br />
Examples:<br />
# wait for input on port 1234<br />
listen=1234<br />
<br />
|-<br />
<br />
| Loghost ||<br />
<br />
<span id="p_loghost"></span><br />
Hostname to redirect syslog to. Also YaST will log both to y2log and to the remote syslog.<br />
<br />
To enable log reception on the destination host, see "source" section in ''/etc/syslog-ng/syslog-ng.conf''<br />
<br />
|-<br />
<br />
| LogLevel ||<br />
<br />
Set kernel log level.<br />
<br />
Values: 1 - 8<br />
<br />
Defaults to 1 for serial consoles, 7 for all other consoles.<br />
<br />
|-<br />
<br />
| LXRCDebug ||<br />
<br />
Obsolete. Use ''[[#p_linuxrcdebug|linuxrcdebug]]''.<br />
<br />
|-<br />
<br />
| Manual ||<br />
<br />
Start linuxrc in manual mode.<br />
<br />
Values:<br />
0 automatic mode (this is the default)<br />
1 manual mode<br />
2 really manual manual mode (E.g. no USB keyboard since no USB setup is done!)<br />
<br />
There's normally no reason to use manual mode. Please<br />
avoid it. You can pass everything directly via command line.<br />
<br />
''manual=1'' still uses hardware detection to some degree<br />
(e.g. to mark suitable modules in module loading dialogs)<br />
but you basically have to take care to load all necessary drivers<br />
yourself.<br />
<br />
''manual=2'' does no automatic hardware detection at all and is<br />
useful only if the hardware detection has some<br />
problem. A typical example would be linuxrc not letting<br />
you select a network interface even though the driver is loaded<br />
and the interface exists.<br />
<br />
|-<br />
<br />
| MediaUpgrade ||<br />
<br />
<span id="p_mediaupgrade"></span><br />
<br />
Use ''media_upgrade=1'' to force upgrading the system using the installation media<br />
instead of using the registration system.<br />
<br />
This option only makes sense with ''upgrade=1'' option and is relevant only for<br />
registered systems, otherwise it is ignored.<br />
<br />
''This option is available in SLE15 and newer.''<br />
<br />
|-<br />
<br />
| MemLimit ||<br />
<br />
Amount of free memory in kB below which linuxrc will ask the user to set up a swap partition.<br />
<br />
|-<br />
<br />
| MemLoadImage ||<br />
<br />
Amount of free memory in kB below which linuxrc will not copy the root image into RAM.<br />
<br />
|-<br />
<br />
| MemYaST ||<br />
<br />
Amount of free memory in kB below which linuxrc will ask the user to set up a swap partition before starting YaST.<br />
<br />
|-<br />
<br />
| MinMemory ||<br />
<br />
Amount of memory in kB below which linuxrc will refuse to start. Defaults to 0.<br />
<br />
|-<br />
<br />
| Modeset ||<br />
<br />
Some gfxchips are incompatible with kernel modesetting. Modeset=0 does not work. If<br />
X malfunction occurs, try nomodeset, or one of the following specific to your gfxchip:<br />
<br />
i915.modeset=0<br />
nouveau.modeset=0<br />
radeon.modeset=0<br />
<br />
|-<br />
<br />
| ModuleDelay ||<br />
<br />
Wait some seconds after loading each module. Useful if<br />
your hardware is a bit slow.<br />
<br />
Example:<br />
# wait 5 seconds<br />
ModuleDelay=5<br />
<br />
Defaults to 0.<br />
<br />
|-<br />
<br />
| ModuleDisks ||<br />
<br />
No longer supported.<br />
<br />
|-<br />
<br />
| NameScheme ||<br />
<br />
[''openSUSE 11.3+'']<br />
<br />
Selects the device name scheme linuxrc uses.<br />
Value can be ''by-id'', ''by-path'', ''by-label'' or ''""''.<br />
<br />
Default setting is ''by-id''<br />
<br />
Examples:<br />
# back to classical device names (like /dev/sda)<br />
namescheme=<br />
# use /dev/disk/by-path/...<br />
namescheme=by-path<br />
<br />
|-<br />
<br />
| Nameserver ||<br />
<br />
Space or comma separated list of DNS servers.<br />
<br />
Examples:<br />
# just one<br />
Nameserver=192.168.1.1<br />
# or more<br />
Nameserver="192.168.1.2 192.168.1.3"<br />
# or, avoiding the quotes<br />
Nameserver=192.168.1.2,192.168.1.3<br />
<br />
|-<br />
<br />
| Netdevice ||<br />
<br />
Specify the network interface. See [[#device_descr|device description]] for allowed values.<br />
<br />
Normally, this is not necessary. But if you really need this option, consider<br />
adding it to the URL of the [[#p_install|Install]] parameter.<br />
<br />
Examples:<br />
netdevice=eth1 # 2nd ethernet interface<br />
netdevice=wlan* # wlan interface<br />
<br />
|-<br />
<br />
| Netmask ||<br />
<br />
''also via DHCP''<br />
<br />
Static IP netmask of the installing host.<br />
<br />
|-<br />
<br />
| Netretry ||<br />
<br />
Netretry=N will retry all network connection attempts N times (e.g., when trying<br />
to reach the FTP server).<br />
This is mainly for debugging network problems.<br />
<br />
|-<br />
<br />
| NetSetup ||<br />
<br />
<span id="p_netsetup"></span><br />
<br />
Prompt for network parameters and setup network. Normally linuxrc<br />
will do this automatically when you [[#p_install|install]] via<br />
network. But if you want to configure the network even if you<br />
install from local media, use this option.<br />
<br />
''netsetup'' accepts a comma-separated list of ''default'', ''dhcp'', ''hostip'', ''gateway'', ''nameserver'', ''vlanid'', or ''all''.<br />
<br />
Flags can be turned on or off (prepend '+' or '-').<br />
<br />
Examples:<br />
# default = dhcp,hostip,gateway,nameserver<br />
netsetup=default<br />
# same as 'default'<br />
netsetup=1<br />
# do dhcp<br />
netsetup=dhcp<br />
# setup all interfaces<br />
netsetup=dhcp,all<br />
<br />
|-<br />
<br />
| _NetStop ||<br />
<br />
''internal''<br />
<br />
|-<br />
<br />
| NetUniqueID ||<br />
<br />
|-<br />
<br />
| NetWait ||<br />
<br />
<span id="p_netwait"></span><br />
<br />
Wait some seconds after activating the network interface. This might be<br />
needed in rare cases for some cards.<br />
<br />
If you have problems with DHCP, also look at [[#p_dhcpcd|dhcpcd]];<br />
for BOOTP, try [[#p_bootpwait|bootpwait]]<br />
<br />
Example:<br />
# wait 8 seconds<br />
NetWait=8<br />
<br />
|-<br />
<br />
| Network ||<br />
<br />
''also via DHCP''<br />
<br />
|-<br />
<br />
| NewID ||<br />
<br />
|-<br />
<br />
| NFSOpts ||<br />
<br />
<span id="p_nfsopts"></span><br />
<br />
NFS mount options. A comma-separated list. Supported options are<br />
''vers'', ''tcp'', ''udp'', ''rsize'' and ''wsize''.<br />
<br />
Examples:<br />
<br />
# use NFSv2 via UDP<br />
nfsopts=udp,vers=2<br />
# different block size<br />
nfsopts=rsize=4096,wsize=4096<br />
<br />
|-<br />
<br />
| NFS.RSize ||<br />
<br />
Obsolete. Use ''[[#p_nfsopts|NFSOpts]]''.<br />
<br />
|-<br />
<br />
| NFS.TCP ||<br />
<br />
No longer supported. Use ''[[#p_nfsopts|NFSOpts]]''.<br />
<br />
|-<br />
<br />
| NFS.WSize ||<br />
<br />
Obsolete. Use ''[[#p_nfsopts|NFSOpts]]''.<br />
<br />
|-<br />
<br />
| NoMDNS ||<br />
<br />
Turn off MDNS usage.<br />
<br />
Example:<br />
nomdns=1<br />
<br />
|-<br />
<br />
| NoPCMCIA ||<br />
<br />
''deprecated''<br />
<br />
Do not start the PCMCIA card manager. This option may not be useful any more.<br />
<br />
|-<br />
<br />
| NoRepo ||<br />
<br />
Disable the repo location check and do not write a ZyppRepoURL to /etc/install.inf; <br />
expect YaST to take care of the repo selection.<br />
<br />
This is useful for delegating the repo selection to the registration server so a user can simply enter a registration code first, then the matching product will be automatically selected based on that registration code, and the respective repos will be addded accordingly (Fate#325482).<br />
<br />
Example:<br />
norepo=1<br />
<br />
|-<br />
<br />
| NoShell ||<br />
<br />
Do not start any shell. By default, linuxrc starts ''/bin/bash'' at<br />
''/dev/tty2'', ''/dev/tty9'' and if memory requirements permit<br />
(well, about always) also at ''/dev/tty5'' and ''/dev/tty6''.<br />
<br />
See also parameters ''MemLimit'', ''MemYaST''.<br />
<br />
Example:<br />
noshell=1<br />
<br />
|-<br />
<br />
| Options ||<br />
<br />
<span id="p_options"></span><br />
<br />
Pass options to kernel modules. Syntax is "module.parameter" or "module=parameter".<br />
<br />
Examples:<br />
<br />
# "tzp=50" for module "thermal"<br />
options=thermal.tzp=50<br />
# looks a bit weird, but means the same:<br />
options=thermal=tzp=50<br />
# create 100 loop devices<br />
options=loop.max_loop=100<br />
<br />
Alternatively, all options that are unknown but have the form<br />
''foo.bar'' are interpreted as option ''bar'' to module ''foo''.<br />
<br />
Examples:<br />
<br />
thermal.tzp=50<br />
loop.max_loop=100<br />
<br />
To pass several options to a module, use, e.g.:<br />
<br />
libata.atapi_enabled=1 libata.ignore_hpa=1<br />
# same as above, but in one go:<br />
options="libata.atapi_enabled=1 ignore_hpa=1"<br />
<br />
|-<br />
<br />
| Partition ||<br />
<br />
No longer supported. Use [[#p_device|device]] or [[#p_install|install]].<br />
<br />
|-<br />
<br />
| <span id="p_password">password</span> ||<br />
<br />
An alias for [[#p_sshpassword|ssh.password]].<br />
<br />
|-<br />
<br />
| password.enc ||<br />
<br />
An alias for [[#p_sshpasswordenc|ssh.password.enc]].<br />
<br />
|-<br />
<br />
| plymouth ||<br />
<br />
Defines whether plymouth is active during installation.<br />
<br />
Example:<br />
plymouth=0<br />
<br />
|-<br />
<br />
| <span id="p_ptoptions">pt.options</span> ||<br />
<br />
Comma-separated list of options linuxrc recognizes and passes on to YaST<br />
but does nothing else with. Options are stored in /etc/install.inf using<br />
the spelling given in pt.options. You can prepend a '+' or '-' to the<br />
(whole) option list indicating that those options should be added or removed to<br />
the internal list.<br />
<br />
Example:<br />
pt.options=foo,bar Foo=123 BAR=Nice_Bar<br />
# this will cause<br />
# foo: 123<br />
# bar: Nice_Bar<br />
# to be written to /etc/install.inf<br />
<br />
|-<br />
<br />
| <span id="p_proxy">proxy</span> ||<br />
<br />
Defines a HTTP proxy server.<br />
For a URL syntax overview, look [[#url_descr|here]].<br />
<br />
Examples:<br />
# use proxy.foo.org at port 3128<br />
proxy=<nowiki>http://proxy.example.com:3128</nowiki><br />
# using <nowiki>'http://'</nowiki> is optional:<br />
proxy=proxy.example.com:3128<br />
# or, with authentication<br />
proxy=<nowiki>http://foo:bar@proxy.example.com:3128</nowiki><br />
<br />
|-<br />
<br />
| proxy.port ||<br />
<br />
No longer supported. Use [[#p_proxy|proxy]].<br />
<br />
|-<br />
<br />
| proxy.proto ||<br />
<br />
No longer supported. Use [[#p_proxy|proxy]].<br />
<br />
|-<br />
<br />
| <span id="p_repo">repo</span> ||<br />
<br />
An alias for [[#p_install|install]].<br />
<br />
|-<br />
<br />
| <span id="p_rescue">rescue</span> ||<br />
<br />
Load the rescue system. See [[#p_install|install]] for syntax.<br />
<br />
Alternatively, use ''rescue=1'' and [[#p_install|install]] or [[#p_instsys|instsys]].<br />
<br />
|-<br />
<br />
| rescue.image ||<br />
<br />
Location of the rescue system image within the installation source.<br />
<br />
|-<br />
<br />
| <span id="p_restart">restart</span> ||<br />
<br />
If set to 1 and [[#p_restarted|restarted]] is 0 linuxrc is immediately restarted.<br />
The new linuxrc sets [[#p_restarted|restarted]] automatically to 1 to indicate that it has already been restarted to prevent it from looping. If you want it restarted again, set [[#p_restarted|restarted]] to 0 first.<br />
<br />
Another way to restart linuxrc is to send it the USR2 signal.<br />
<br />
This options is basically there to allow linuxrc to be updated while running.<br />
<br />
|-<br />
<br />
| <span id="p_restarted">restarted</span> ||<br />
<br />
Indicates whether linuxrc has been restarted and prevents further restarts unless reset to 0. See [[#p_restart|restart]].<br />
<br />
|-<br />
<br />
| root.image ||<br />
<br />
Location of root image (installation system image) within the installation source.<br />
<br />
|-<br />
<br />
|<br />
<br />
<span id="p_rootpassword">RootPassword</span><br />
<br />
||<br />
<br />
The password to use for the 'root' account of the installed system. If set to 'ask' linuxrc will show a dialog to enter the 'root' password.<br />
<br />
This will override any settings you make for the 'root' password in the installer UI during the installation or the corresponding setting in your AutoYaST profile.<br />
<br />
Note: this is not the temporary password used <b>during</b> installation. Use [[#p_password|password]] for that.<br />
<br />
Examples:<br />
# set password<br />
RootPassword=t0psecr5t<br />
<br />
# get dialog asking for password<br />
RootPassword=ask<br />
<br />
|-<br />
<br />
| Screenmap ||<br />
<br />
Obsolete, do not use (it does not do what you probably think [if you think of anything it could do ;) ]).<br />
<br />
|-<br />
<br />
| <span id="p_screenmode">Screenmode (experimental)</span> ||<br />
<br />
Set an alternative style (colors and fonts) for the installer. Current supported values are 'highcontrast', 'white-black' and 'cyan-black'. This feature will land in Tumbleweed shortly (oct/nov 2016), but it's not supported yet in openSUSE or SLE.<br />
<br />
Example:<br />
<br />
screenmode=white-black<br />
<br />
|-<br />
<br />
| Server ||<br />
<br />
|-<br />
<br />
| Serverdir ||<br />
<br />
No longer supported. Use [[#p_install|install]].<br />
<br />
|-<br />
<br />
| SetHostname ||<br />
<br />
Set the hostname via DHCP.<br />
<br />
Example:<br />
SetHostname=1<br />
<br />
|-<br />
<br />
| SetupCmd ||<br />
<br />
|-<br />
<br />
| SetupNetIF ||<br />
<br />
|-<br />
<br />
| Share ||<br />
<br />
No longer supported. Use [[#p_install|install]].<br />
<br />
|-<br />
<br />
| Splash ||<br />
<br />
Defines whether a splash-screen is used during initialization.<br />
<br />
Example<br />
Splash=silent<br />
Splash=verbose<br />
<br />
|-<br />
<br />
| <span id="p_ssh">ssh</span> ||<br />
<br />
This parameter enables access to linuxrc via SSH when performing the installation with YaST in text mode or via X11 forwarding. Use ''ssh -X root@hostname'' or ''ssh -Y root@hostname'' for X11 forwarding.<br />
<br />
Values: 0 (off), 1 (on)<br />
<br />
Example:<br />
# use ssh and set ssh password<br />
ssh=1 sshpassword=foobar123<br />
<br />
|-<br />
<br />
| <span id="p_sshd">sshd</span> ||<br />
<br />
This parameter enables login to the installation system while the installation is running. Use ''ssh -X root@hostname'' to connect. You must also set a [[#p_sshpassword|password]] to be able to login. This option is for debugging and does not enable an installation via ssh like the [[#p_ssh|ssh]] option.<br />
<br />
Note that this has no influence on the ssh settings of the target (installed) system.<br />
<br />
Values: 0 (off), 1 (on)<br />
<br />
Example:<br />
# start sshd ssh and set root password<br />
sshd=1 password=foobar123<br />
<br />
|-<br />
<br />
| <span id="p_sshkey">ssh.key</span> ||<br />
<br />
The option takes a [[#url_descr|URL]] as argument. The file is downloaded and put into /root/.ssh/authorized_keys of the installation system. This key can be used to log into the SSH server during installation. The key is not copied into the final installed system.<br />
<br />
Example:<br />
# get ssh pubkey and put into authorized_keys<br />
ssh.key=<nowiki>https://foo.bar/my_key</nowiki><br />
<br />
|-<br />
<br />
| <span id="p_sshpassword">ssh.password</span> ||<br />
<br />
This sets the password for the user root for logging into the SSH server during installation if [[#p_ssh|ssh]] or [[#p_sshd|sshd]] is set. This is not the password of the system to be installed. See ''RootPassword''.<br />
<br />
Example:<br />
ssh.password=12345678<br />
<br />
|-<br />
<br />
| <span id="p_sshpasswordenc">ssh.password.enc</span> ||<br />
<br />
This sets the password for the user root for logging into the SSH server during installation if [[#p_ssh|ssh]] or [[#p_sshd|sshd]] is set. This is not the password of the system to be installed.<br />
<br />
The password is passed in encrypted form.<br />
<br />
Example:<br />
ssh.password.enc=$1$Bdh9Ixdo$0me9ZFlYZ7tfKq.T5xTVQ.<br />
<br />
|-<br />
<br />
| <span id="p_sslcerts">ssl.certs</span> ||<br />
<br />
If set to 0, turns off ssl certificate checking during an installation using https.<br />
<br />
Example:<br />
ssl.certs=0<br />
<br />
|-<br />
<br />
| startshell ||<br />
<br />
Boots into the installation system and starts a shell. Waits until user exits the shell. User can modify the installation system, mount or remount partitions or start YaST installation manually by running ''yast''.<br />
<br />
It also stops again after YaST has finished the installation.<br />
<br />
Example:<br />
startshell=1<br />
<br />
|-<br />
<br />
| <span id="p_systemboot">systemboot</span> ||<br />
<br />
If set to 1 this causes linuxrc to start with the 'Boot Installed System' menu. This menu lets you select a root partition and kernel/initrd pair and boot it via kexec.<br />
<br />
If [[#p_linuxrcdebug|linuxrc.debug]] is set you get an additional dialog letting you add kexec options.<br />
<br />
Example:<br />
systemboot=1<br />
<br />
|-<br />
<br />
| TERM ||<br />
<br />
Terminal type on which linuxrc is running<br />
<br />
Example:<br />
TERM=dumb<br />
<br />
|-<br />
<br />
| textmode ||<br />
<br />
Enables starting YaST in text mode otherwise it uses the Qt interface if possible.<br />
<br />
Example:<br />
textmode=1<br />
<br />
|-<br />
<br />
| reboot_timeout ||<br />
<br />
Configures the reboot timeout countdown at the end of installation. Value in seconds. A value of 0 disables the timeout so that the reboot must be confirmed manually. Defaults to 10s.<br />
<br />
Example:<br />
reboot_timeout=0<br />
<br />
|-<br />
<br />
| udev.rule ||<br />
<br />
Write udev rules. Currently only writing network rules to 70-persistent-net.rules<br />
is implemented. If the need arises, more can follow.<br />
<br />
Note that this option is only useful on command line or in linuxrc.config as the rules<br />
need to be written before udevd is started (which is rather early).<br />
<br />
The option can be given more than once to pass several rules.<br />
<br />
Example:<br />
# add entry to 70-persistent-net.rules<br />
udev.rule="mac=00:11:d8:39:4e:d0,name=eth0"<br />
<br />
|-<br />
<br />
| Upgrade ||<br />
<br />
If set to a nonzero value YaST will do an update instead of a new installation.<br />
<br />
Example:<br />
Upgrade=1<br />
<br />
|-<br />
<br />
| USBWait ||<br />
<br />
Number of seconds to wait after loading USB modules.<br />
<br />
|-<br />
<br />
| UseDHCP ||<br />
<br />
If an automatic network setup is required, defines whether DHCP or BOOTP should be used. Default is DHCP.<br />
<br />
Example:<br />
# use BOOTP<br />
UseDHCP=0<br />
<br />
|-<br />
<br />
| Username ||<br />
<br />
No longer supported. Use [[#p_install|install]].<br />
<br />
|-<br />
<br />
| UseSax2 ||<br />
<br />
Alias for [[#p_sax2|sax2]] parameter.<br />
<br />
|-<br />
<br />
| SSH ||<br />
<br />
<span id="p_ssh"></span><br />
<br />
This parameter enables access to linuxrc via SSH when performing the installation with YaST in text mode or via X11 forwarding. Use ''ssh -X root@hostname'' or ''ssh -Y root@hostname'' for X11 forwarding.<br />
<br />
Values: 0 (off), 1 (on)<br />
<br />
Example:<br />
# use ssh and set ssh password<br />
ssh=1 sshpassword=foobar123<br />
<br />
|-<br />
<br />
| UseSSH ||<br />
<br />
Alias for [[#p_ssh|ssh]] parameter.<br />
<br />
|-<br />
<br />
| UseVNC ||<br />
<br />
Alias for [[#p_vnc|vnc]] parameter.<br />
<br />
|-<br />
<br />
| vlanid ||<br />
<br />
If you want to setup a vlan specify the id here.<br />
<br />
Note: normally you can't enter a vlan id in manual mode. To enable the vlan dialog set any non-empty value with this option or use the netsetup option.<br />
<br />
Example:<br />
# set v lan id to 12<br />
vlanid=12<br />
# enable vlan, but don't set an id<br />
vlanid=0<br />
<br />
|-<br />
<br />
| VNC ||<br />
<br />
<span id="p_vnc"></span><br />
<br />
The VNC parameter enables the installation process via VNC, making the installation more convenient on hosts that have no or no really usable local console. If enabled, a VNC server is activated on the installation host. See also ''VNCPassword''.<br />
<br />
Example:<br />
vnc=1 # enable VNC<br />
<br />
|-<br />
<br />
| VNCPassword ||<br />
<br />
This sets the VNC password for an installation via VNC. Minimum password length 8 characters.<br />
<br />
Example:<br />
VNCPassword=12345678<br />
<br />
|-<br />
<br />
| WaitReboot ||<br />
<br />
|-<br />
<br />
| WithiSCSI ||<br />
<br />
The [[YaST:iscsi]] configuration module is automatically started before before YaST starts the harddisk partitioner module.<br />
<br />
|-<br />
<br />
| <span id="p_wlanauth">WlanAuth</span> ||<br />
Sets wireless authentication mode. Accepted values are: ''open'', ''wpa'', ''peap''.<br />
<br />
Example:<br />
WlanAuth=open # open (non-authenticated) wlan<br />
<br />
|-<br />
<br />
| <span id="p_wlandevice">WlanDevice</span> ||<br />
<br />
WiFi capabilities of a network interface are automatically detected but if they aren't or you have<br />
several wifi interfaces and want to apply the wifi parameters to a specific one, use this<br />
option to set the device used for wifi setup.<br />
<br />
This overrides any auto-detection. If you repeat this option, the settings are tried on '''all'''<br />
interfaces you specified.<br />
<br />
Note that this is basically an option for debugging and testing.<br />
<br />
Example:<br />
WlanDevice=wlan0<br />
<br />
|-<br />
<br />
| <span id="p_wlanessid">WlanESSID</span> ||<br />
Select the ESSID (network name) of the wireless network to connect to.<br />
<br />
Example:<br />
WlanESSID=Foo<br />
<br />
|-<br />
<br />
| <span id="p_wpaidentity">WPAIdentity</span> ||<br />
Identity (user name) used in WPA-PEAP authentication method.<br />
Note that this implicitly sets [[#p_wlanauth|WlanAuth]] to ''peap''.<br />
<br />
Example:<br />
WPAIdentity=MrFoo WPAPassword=Foo123<br />
<br />
|-<br />
<br />
| <span id="p_wpapassword">WPAPassword</span> ||<br />
Password used in WPA-PEAP authentication method.<br />
Note that this implicitly sets [[#p_wlanauth|WlanAuth]] to ''peap''.<br />
<br />
Example:<br />
WPAIdentity=MrFoo WPAPassword=Foo123<br />
<br />
|-<br />
<br />
| <span id="p_wpapsk">WPAPSK</span> ||<br />
Set the WPA pre-shared key. Note that this implicitly sets [[#p_wlanauth|WlanAuth]] to ''wpa''.<br />
The key must be at least 8 chars long.<br />
<br />
Example:<br />
WPAPSK=Foo.123456<br />
<br />
|-<br />
<br />
| WorkDomain ||<br />
<br />
No longer supported. Use [[#p_install|install]].<br />
<br />
|-<br />
<br />
| <span id="p_xvideo">XVideo</span> ||<br />
<br />
Set the screen size and resolution using during installation for the graphical installer.<br />
The option accepts a screen size optionally followed by a screen resolution in dpi.<br />
Note this does neither influence the text mode (console) resolution nor set the screen size for the installed system.<br />
<br />
Examples:<br />
# set screen size to 1024 x 768<br />
XVideo=1024x768<br />
# set screen size to 1024 x 768, and set resolution to 100 dpi<br />
XVideo=1024x768,100<br />
<br />
|-<br />
<br />
| YaST2update ||<br />
<br />
|-<br />
<br />
| YaST2color ||<br />
<br />
|-<br />
<br />
| Zen ||<br />
<br />
No longer supported.<br />
<br />
|-<br />
<br />
| ZenConfig ||<br />
<br />
No longer supported.<br />
<br />
|-<br />
<br />
| Zombies ||<br />
<br />
If you don't want linuxrc to take care of zombie processes during installation,<br />
set this to 0. (Don't do this.)<br />
<br />
Example:<br />
zombies=0<br />
<br />
|}<br />
<br />
==Special parameters for S/390 and zSeries==<br />
<br />
{| class="wikitable"<br />
! Parameter <br />
! Description<br />
<br />
|-<br />
<br />
| CTCProtocol ||<br />
<br />
CTC protocol to use.<br />
<br />
Values:<br />
0 compatible<br />
1 extended<br />
2 z/OS<br />
<br />
|-<br />
<br />
| DataChannel ||<br />
<br />
CCW data channel for CU3088 and QDIO devices<br />
<br />
Format: h.h.hhhh<br />
<br />
|-<br />
<br />
| InstNetDev ||<br />
<br />
Network device to install from.<br />
<br />
Values:<br />
osa OSA-2 or OSA Express<br />
hsi Hipersocket<br />
ctc CTC (deprecated)<br />
escon ESCON (deprecated)<br />
iucv IUCV (deprecated)<br />
<br />
|-<br />
<br />
| IUCVPeer ||<br />
<br />
Name of peer for IUCV networking.<br />
<br />
|-<br />
<br />
| Layer2 ||<br />
<br />
Turn on OSI layer 2 access for OSA Express Ethernet interfaces.<br />
<br />
Values: 0 (off), 1 (on)<br />
<br />
|-<br />
<br />
| OSAHWAddr ||<br />
<br />
''introduced in SLE10 SP1''<br><br />
Manual MAC address setting for Layer 2-enabled OSA devices. Note that this is distinct from HWAddr, which contains the default MAC address as detected by linuxrc.<br />
<br />
Example: OSAHWAddr=11:22:33:44:55:66<br />
<br />
|-<br />
<br />
| OSAInterface ||<br />
<br />
Software interface for OSA devices.<br />
<br />
Values:<br />
qdio QDIO<br />
lcs LCS<br />
<br />
|-<br />
<br />
| OSAMedium ||<br />
<br />
Physical medium for OSA devices.<br />
<br />
Values:<br />
eth Ethernet<br />
tr Token Ring<br />
<br />
|-<br />
<br />
| Portname ||<br />
<br />
Portname for OSA devices.<br />
<br />
|-<br />
<br />
| ReadChannel ||<br />
<br />
CCW read channel for CU3088 and QDIO devices.<br />
<br />
Format: h.h.hhhh<br />
<br />
|-<br />
<br />
| WriteChannel ||<br />
<br />
CCW write channel for CU3088 and QDIO devices.<br />
<br />
Format: h.h.hhhh<br />
<br />
|}<br />
<br />
<br />
==Special parameters not handled by Linuxrc itself==<br />
<br />
{| class="wikitable"<br />
! Parameter !! Description<br />
<br />
|-<br />
<br />
| LIBSTORAGE_MULTIPATH_AUTOSTART ||<br />
<br />
When installing on a system with a network storage that is accessed via multiple paths,<br />
the installer should detect the situation and ask the user whether to enable multipath.<br />
But the detection is not always 100% reliable. This parameter can be used to<br />
enforce the installer to enable multipath in all cases, without even asking the user.<br />
<br />
Example:<br />
LIBSTORAGE_MULTIPATH_AUTOSTART=ON<br />
<br />
This parameter is ignored by AutoYaST, use the "start_multipath" property in the<br />
AutoYaST profile to specify whether multipath should be activated in AutoYaST.<br />
<br />
|-<br />
<br />
| <span id="p_libstorage_mdpart">LIBSTORAGE_MDPART</span> ||<br />
<br />
When set, all devices detected as software RAID will be considered BIOS RAID devices.<br />
<br />
Example:<br />
LIBSTORAGE_MDPART=ON<br />
<br />
|-<br />
<br />
| Mem ||<br />
<br />
Defines a maximum RAM that will be used by the installation system.<br />
It's helpful for testing installation memory requirements.<br />
<br />
Example:<br />
mem=128M<br />
<br />
|-<br />
<br />
| Y2_BRAILLE ||<br />
<br />
This environment variable sets the style of installation textmode UI <br />
to 'braille' i.e. it is optimized for visually impaired people. Use<br />
together with 'textmode=1'<br />
<br />
Example:<br />
Y2_BRAILLE=1<br />
<br />
|-<br />
<br />
| Y2DEBUG ||<br />
<br />
Turns all YaST debugging messages on. These messages are logged into the ''/var/log/YaST2/y2log'' file marked with ''<0>'' flag. This parameter is handled by [[Portal:YaST]] itself and can be also prepended to the command-line when starting any YaST module.<br />
<br />
|-<br />
<br />
| Y2DEBUGGER ||<br />
<br />
Enables the Ruby debugger in the YaST installer. It can be also prepended to the command-line when starting any YaST module in installed system.<br />
See the [http://yastgithubio.readthedocs.io/en/latest/debugging/ YaST Debugger] documentation for more details.<br />
<br />
Example:<br />
Y2DEBUGGER=1<br />
|-<br />
<br />
| TERM ||<br />
<br />
Setting this environment variable influences the color style that will <br />
be used in installation text mode UI. E.g. ''TERM=xterm'' sets the theme to <br />
''xterm'', some TERM not supporting colors will use monochromatic theme. When not<br />
set, default theme ''linux'' is applied. However, be careful and before <br />
setting any TERM value, check that it has valid terminfo entry. Otherwise<br />
installation may abort.<br />
<br />
Available terms can be found in the ''/yast/instsource/inst-sys/usr/share/terminfo''<br />
directory - installation system has another set of available terms than a running system.<br />
To get a monochromatic term, use ''linux-m''.<br />
<br />
Use this parameter together with ''textmode=1''.<br />
<br />
Example:<br />
TERM=xterm<br />
TERM=linux-m<br />
<br />
|-<br />
<br />
| ZYPP_FULLLOG ||<br />
<br />
Sets [[Libzypp/Main_page|LibZYPP]] logging level to the highest value. Useful for debugging products,<br />
packages and patches dependency problems. This variable can be also set on a running system before<br />
running every [[Portal:YaST]] module.<br />
<br />
Example:<br />
ZYPP_FULLLOG=1 # Linuxrc<br />
ZYPP_FULLLOG=1 /sbin/yast2 online_update # Running system<br />
<br />
|}<br />
<br />
<br />
[[Category:SDB]]<br />
[[Category:Booting]]<br />
[[Category:Installation]]<br />
[[Category:YaST|Linuxrc]]<br />
<br />
[[de:Linuxrc]]<br />
[[nl:Linuxrc]]<br />
[[ja:Linuxrc]]<br />
[[ru:SDB:Linuxrc]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Creating_a_changes_file_(RPM)&diff=136872openSUSE:Creating a changes file (RPM)2019-10-07T13:59:52Z<p>Okurz: Fix example bugzilla link</p>
<hr />
<div>{{Packaging docnav}}<br />
{{Intro|This article will give you a hints from the [[openSUSE:OpenSUSE_review_team|openSUSE review team]] how to write a good and useful changes entry.}}<br />
<br />
==Changelog section (%changelog)==<br />
Every time you make changes to the package, you must add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packagers, and QA people to easily spot the changes that you make. (The osc log is underused, as it does not support linking history à la ''git merge'' when an SR is accepted.)<br />
<br />
The Open Build Service uses a separate file for package changes. This file is called like the specfile, but has <tt>.changes</tt> at the end instead of <tt>.spec</tt>. The `osc vc` command can be used to autocreate a new item with the basic structure and formatting. Changelog entries have to be in chronological order. Newer changelog entries are listed in the file above older entries, thus the first entry is the most recent one. You '''shall not''' modify any existing component (where component is a text enclosed between ----------) if a package is checked in to the official repository (openSUSE:Factory). Small typo fixes are accepted, as is the addition of bug references, and trimming useless trailing whitespace. You may add new components in between older ones. This enables developing a package in more than one branch at a time.<br />
<br />
Entries in this changes file shall have the following structure/formatting styles:<br />
<br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- level 1 bullet point; long descriptions<br />
should wrap<br />
* level 2 bullet point; long descriptions<br />
should wrap<br />
* another l2 bullet point<br />
- another l1 bullet point<br />
</pre><br />
<br />
Note: The recommended maximal length per line is 67 chars (equal to the dashed line/separator). Third-level or deeper bullet points are not defined. yast2-qt will show the log with a proportional font, so do not attempt any indentation beyond the two levels shown here.<br />
<br />
The second-level bullet point symbol ought to be an asterisk, not a plus sign as is sometimes seen. The helper script <tt>/usr/lib/build/changelog2spec</tt> specifically recognizes the asterisk and will reflow such bullet points for the RPM changelog (inspectable `<tt>rpm -q --changelog</tt>`) should they not already be at the second indentation level.<br />
<br />
== What goes into the changelog ==<br />
<br />
The intent of this changelog is to summarize the most newsworthy items, distilled for an openSUSE user. That means you shouldn't just provide a link to a changelog on the Internet. (Network connections may also be unavailable at the time a user wants to find out about changes.)<br />
<br />
=== Version updates ===<br />
<br />
If a version update was done, that should definitely be in the <tt>.changes</tt> file, for example like so:<br />
<br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- Update to new upstream release x.y.z:<br />
* bling and changes from upstream for that version<br />
* just the relevant parts, no info about other OS<br />
* and keep it as short as possible<br />
</pre><br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- Update to snapshot version 1.2.3.456789<br />
* Speed of computing primality of a number was improved two-fold<br />
</pre><br />
<br />
# First of all, find out what is new or has changed. Non-exhaustive list of potential sources for newsworthy items:<br />
## Files inside the source tree with a name of, or similar to, <tt>NEWS</tt>, <tt>CHANGES</tt>, <tt>ChangeLog</tt><br />
## the homepage of the project<br />
## a blog about the software / a blog by the author<br />
## an announce post on a mailing list or community site such as freshcode.club<br />
## your own experience with the new version.<br />
# If you cannot find anything in the aforementioned set of places, that is ok. Say so, and consider it done. (For example, “<tt>* No changelog was made available.</tt>”) It is not necessary to inspect commit logs or to analyze source code.<br />
<br />
Then, assort what you have found with due care:<br />
<br />
# Don't just copy what you find without reviewing yourself.<br />
# Avoid and trim anything related to the build procedure of the package if it has no visible effect on the user. The software is already built by the time it reaches the user.<br />
# Like with [[openSUSE:Package_description_guidelines#Summary|summaries]], remove anything about non-openSUSE platforms.<br />
# You can use SCM commit messages, if they prove to be useful. If in doubt, don't.<br />
# Now, can you, as a package maintainer, make sense of every news item? Does the item mean something to you? If not, then neither does it for the user, and the item in question should be dropped.<br />
# If, at this point, there is nothing to report, say so and consider it done. (E.g. “<tt>* No user-visible changes</tt>” when, for example, upstream only changed the way the software is built.)<br />
# Be concise. Pick only the topmost interesting points: If you have over 30 lines of changelog, it is time to stop and refer the user to the other materials (such as upstream-provided news files, web links, …)<br />
# Be concise (part 2). Summarize and generalize the points: Don't go too much into specifics of a modification — a suitably interested user can look for implementation details elsewhere.<br />
# If there is an incompatible change that requires the user to adapt their configuration and/or setup, this should be mentioned in the changelog of the package, too, to make the users aware of it.<br />
<br />
You can, optionally, add the original upstream change documents to the package as a file as a reference. This however is only in addition to something in .changes.<br />
<br />
== Distro-related changes ==<br />
<br />
Besides version updates, there may be changes related to the openSUSE packaging itself. Noteworthy items about that would simply be appended.<br />
<br />
<pre><br />
- update to new upstream release 2.0 (if not, omit)<br />
* this and that as per above<br />
- Added new BuildRequires glibc-devel: new dependency<br />
- Do magic trick in install section to overcome installation failure<br />
- add foobar-fix-ham.patch: <give a reason><br />
- add foobar-remove-spam.patch: <give a reason><br />
- modify foobar-autotools.patch: <give a reason><br />
- remove foobar-libpng15-compat.patch: <give a reason> <br />
- ... (other changes done to the package)<br />
</pre><br />
<br />
* Document the changes for future package changes. It can help in identifying if some hack is still needed (the hack in the .spec should have a comment anyway) and when it was added.<br />
* Make the life for any reviewer easier: a short explanation why something is the way it is helps with annoying declines due to misunderstandings. (This sometimes should go into .spec, whereever appropriate.)<br />
<br />
== Referring to upstream ChangeLog ==<br />
<br />
While it might sound like a good idea in the first run, a simple reference to the place of the upstream Changelog (especially if it is tracked on GitHub or other popular collaboration plattforms) is NOT such a good idea. <br />
<br />
* if you reference the Changelog in the "master" branch in your changes file, this file might have changed already. Making it really hard to identify which version your changes file entry belongs to <br />
* People with limited internet access (yes: such people still exist) need not only to download the package but also need to open the link (...and we are not starting the discussion on how to extract it from your changes file here) to really see what happened<br />
<br />
So - whenever possible - please try to follow the two simple suggestions:<br />
* put the most important upstream changes in your changes file, so your package users can get an idea about important changes. 10-15 lines should be enough for this.<br />
* refer to a Changelog file which is installed together with your package (normally under /usr/share/doc/packages/$name/Changelog.md or similar), so people can read the full details without the need to open an internet connection.<br />
<br />
== Bug fix, feature implementation ==<br />
<br />
Anytime you have fixed a bug (or implemented the feature), you '''have to''' mention the number of bug in changes. As fix should be reported in upstream bugzilla, it is better to add a prefix before the number, so people will know where to find an information. For example use ''bsc#1234'' to reference https://bugzilla.suse.com/1234 . The full list of issue trackers is available on [[openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations | Current set of abbreviations]].<br />
<br />
In case the issue has some external identifier, like CVE number, it should be added as well. There are more common ways how to format the message <br />
<br />
- update to Firefox 13.0 (bnc#765204)<br />
* MFSA 2012-34/CVE-2012-1938/CVE-2012-1937/CVE-2011-3101<br />
Miscellaneous memory safety hazards<br />
<br />
- Fix string quoting. [bnc#666416]<br />
<br />
- Add xz BuildRequires because we can't build a package for a<br />
xz-compressed tarball without explicitly specifying that... See<br />
bnc#697467 for more details.<br />
<br />
- fix bnc#595144 - Compiled binary in ant<br />
<br />
== Package updates ==<br />
<br />
In case of package update, the new version have to be mentioned in changes. It is often useful to provide some basic changes from upstream changelog. In case upstream does not provide it, you have to still provide that information in the .changes file, such as <br />
<br />
- update to foo 1.2.3: no changelog available<br />
<br />
- update to Firefox 13.0.1<br />
* bugfix release<br />
<br />
== Patches changes ==<br />
<br />
All changes in patches must follow the [[openSUSE:Packaging_Patches_guidelines#Patch_live_cycle|Patches guidelines]]. It is always a good idea to put the patch name behind the line describing the fix<br />
<br />
- fix segfault on load incorrect document (bnc#123456)<br />
* foo-1.2.4-buffer-owerflow.patch<br />
<br />
- update to Firefox 7 (bnc#720264)<br />
* removed obsolete mozilla-cairo-lcd.patch (upstream)<br />
<br />
[[Category:Packaging|{{PAGENAME}}]]<br />
[[Category:Packaging documentation]]<br />
[[it:openSUSE:Come scrivere buoni file delle modifiche]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Heroes&diff=134994openSUSE:Heroes2019-06-14T08:00:32Z<p>Okurz: Add okurz</p>
<hr />
<div><!-- Template:Navbar is used to connect similar articles in one easy to navigate group --><br />
{{Services_navbar}}<br />
<br />
<br />
[[Image:Heroes logo.png|500px|center|Infrastructure]]<br />
<br />
{| style="width:100%"<br />
|}<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#000000"><br />
=== Introduction ===<br />
</div><br />
Heroes Team members are people helping the project with all system administration related tasks. It consists of people with skills ranging from generic Administrators over to Storage and Network experts. <br />
<br />
In short: the team helps the openSUSE community make their ideas and dreams come true.<br />
<br />
Check out videos of past openSUSE Conferences where we give more details about the Team and the openSUSE infrastructure and services: [https://www.youtube.com/watch?v=91xKCInVSKM&index=32&list=PL_AMhvchzBafyMDGuvBmtb45mhmukdLOP oSC13] [https://www.youtube.com/watch?v=Cp5vAaTI3wQ&index=35&list=PL_AMhvchzBaeV36wYqnKb7xWAN0zfDfjz oSC15] [https://www.youtube.com/watch?v=-CYHkNym124&index=43&list=PL_AMhvchzBaeIQntCDiVNUUgmRaAzam1V oSC16] [https://www.youtube.com/watch?v=QSXniKW_q9Q oSC17]<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#000000"><br />
<br />
=== Communication ===<br />
</div><br />
As team we communicate over a lot of channels. Mostly mailing list and IRC.<br />
<br />
* join our monthly [[openSUSE:Heroes/Meetings|meeting]] - usually at the first Tuesday of a month at 20:00 CET / 18:00 UTC at irc://irc.opensuse.org/#opensuse-admin<br />
* [mailto:admin@opensuse.org admin@opensuse.org] Is where you can write and create issues for our ticket system. <br />
{{Mailinglist|heroes|Is our mailing list and communication channel}} <br />
* [irc://irc.freenode.net/opensuse-admin #opensuse-admin] on the [http://freenode.net freenode] network is the generic channel where you can reach us. We have a bot there that logs the discussions. You can have a look at former discussions [https://monitor.opensuse.org/heroes/ here].<br />
* [irc://irc.freenode.net/opensuse-buildservice #opensuse-buildservice] on the [http://freenode.net freenode] network is the 2nd channel where you can reach us<br />
* We post informations about maintenance of the infrastructure to [http://news.opensuse.org/category/infrastructure/ news.opensuse.org]<br />
* For ways to communicate with us individually check our list of [[openSUSE:Services_team#Members|members]]<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== System Administration ===<br />
</div><br />
One of the main areas of work for the Heroes Team is the system administration of the infrastructure for openSUSE. Here is a short list of so called projects, that need our help:<br />
* The [[openSUSE:Mirror_infrastructure|mirror infrastructure]] for deploying ISO images and packages over the world. This includes updates for released distributions and also providing the upcoming openSUSE release to our users (have a look at our [[openSUSE:Launch_Checklist#Infrastructure|Checklist]], if you want to know more about this).<br />
* The [[Portal:Build_Service|Build Service]] - including not only hardware related tasks but also the involvement inside the project (discussing the [[openSUSE:Build_Service_Roadmap|Roadmap]], working on the [http://gitorious.org/opensuse/build-service Source Code] and also helping [[openSUSE:Build_Service_installations|Build Service Users]] on [irc://irc.freenode.net/opensuse-buildservice #opensuse-buildservice].<br />
* Providing the infrastructure behind [[openSUSE:Openfate|openFate]] and other projects like the [[Portal:Conference|openSUSE Conference]], the [[Portal:Documentation|Documentation]], [http://users.opensuse.org Users] or the [[openSUSE:Maintenance_team|Maintenance infrastructure]].<br />
<br />
=== Duties ===<br />
Each individual team member has also some duties. Beside the regular team meetings (online on IRC or in person) where we discuss important topics occurred during the last meeting, everyone has some special tasks and areas of interest (others call it: hobbies).<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
=== Members ===<br />
</div><br />
<br />
{| class="wikitable sortable"<br />
! Image<br />
! Name <br />
! Freenode nick <br />
! Blog <br />
! Email <br />
<span style="font-weight:100;">(add opensuse.org behind the @)</span><br />
! Area of expertise<br />
|-<br />
| align="left" | <br />
| [[User:cboltz|Christian Boltz]] <br />
| cboltz<br />
| -<br />
| cboltz@<br />
| wiki server admin, admin for English wiki, salting servers and services<br />
|-<br />
| align="left" | <br />
| [[User:AdaLovelace|Sarah Kriesch]] <br />
| AdaLovelace<br />
| -<br />
| sarah.kriesch@<br />
| Admin for German Wiki<br />
|-<br />
| align="left" | <br />
| [[User:TBro|Thorsten B.]]<br />
| thomic<br />
| <br />
| TBro@<br />
| openSUSE Infrastructure, SaltStack, Hardware wishlist <br />
|-<br />
| align="left" | [[Image:DSC00964a.jpeg|50px|thumbnail|left]]<br />
| [[User:pjessen|Per Jessen]]<br />
| pjessen<br />
| http://rambling.jessen.ch/<br />
| per@<br />
| mailing list manager, mirror infrastructure<br />
|-<br />
| align="left" |<br />
| [[User:IonutVan|Ioan Vancea]]<br />
| IonutVan<br />
| https://www.vioan.eu/<br />
| IonutVan@<br />
| ~ to be assigned ~<br />
|-<br />
| align="left" |<br />
| [[User:okurz|Oliver Kurz]]<br />
| okurz<br />
|<br />
| okurz@<br />
| openQA (openqa.opensuse.org)<br />
|-<br />
|}<br />
<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== Contributions ===<br />
</div><br />
You want to contribute to our openSUSE infrastructure? Contact us via IRC or at the mailing list.<br />
<br />
Check the list of [[Portal:Teams|teams]] to learn more about which teams exist in the project.<br />
<br />
[[Category:Team pages]]<br />
[[Category:Infrastructure]]<br />
__NOTOC__</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Creating_a_changes_file_(RPM)&diff=132194openSUSE:Creating a changes file (RPM)2019-02-21T16:47:19Z<p>Okurz: Consolidate issue tracker list with already existing list (already out of sync) on https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines by moving missing entry jsc# there and just reference the list and delete it locally</p>
<hr />
<div>{{Packaging docnav}}<br />
{{Intro|This article will give you a hints from the [[openSUSE:OpenSUSE_review_team|openSUSE review team]] how to write a good and useful changes entry.}}<br />
<br />
==Changelog section (%changelog)==<br />
Every time you make changes to the package, you must add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packagers, and QA people to easily spot the changes that you make. (The osc log is underused, as it does not support linking history à la ''git merge'' when an SR is accepted.)<br />
<br />
The Open Build Service uses a separate file for package changes. This file is called like the specfile, but has <tt>.changes</tt> at the end instead of <tt>.spec</tt>. The `osc vc` command can be used to autocreate a new item with the basic structure and formatting. Changelog entries have to be in chronological order. Newer changelog entries are listed in the file above older entries, thus the first entry is the most recent one. You '''shall not''' modify any existing component (where component is a text enclosed between ----------) if a package is checked in to the official repository (openSUSE:Factory). Small typo fixes are accepted, as is the addition of bug references, and trimming useless trailing whitespace. You may add new components in between older ones. This enables developing a package in more than one branch at a time.<br />
<br />
Entries in this changes file shall have the following structure/formatting styles:<br />
<br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- level 1 bullet point; long descriptions<br />
should wrap<br />
* level 2 bullet point; long descriptions<br />
should wrap<br />
* another l2 bullet point<br />
- another l1 bullet point<br />
</pre><br />
<br />
Note: The recommended maximal length per line is 67 chars (equal to the dashed line/separator). Third-level or deeper bullet points are not defined. yast2-qt will show the log with a proportional font, so do not attempt any indentation beyond the two levels shown here.<br />
<br />
The second-level bullet point symbol ought to be an asterisk, not a plus sign as is sometimes seen. The helper script <tt>/usr/lib/build/changelog2spec</tt> specifically recognizes the asterisk and will reflow such bullet points for the RPM changelog (inspectable `<tt>rpm -q --changelog</tt>`) should they not already be at the second indentation level.<br />
<br />
== What goes into the changelog ==<br />
<br />
The intent of this changelog is to summarize the most newsworthy items, distilled for an openSUSE user. That means you shouldn't just provide a link to a changelog on the Internet. (Network connections may also be unavailable at the time a user wants to find out about changes.)<br />
<br />
=== Version updates ===<br />
<br />
If a version update was done, that should definitely be in the <tt>.changes</tt> file, for example like so:<br />
<br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- Update to new upstream release x.y.z:<br />
* bling and changes from upstream for that version<br />
* just the relevant parts, no info about other OS<br />
* and keep it as short as possible<br />
</pre><br />
<pre><br />
-------------------------------------------------------------------<br />
Tue Apr 22 20:54:26 UTC 2013 - your@email.com<br />
<br />
- Update to snapshot version 1.2.3.456789<br />
* Speed of computing primality of a number was improved two-fold<br />
</pre><br />
<br />
# First of all, find out what is new or has changed. Non-exhaustive list of potential sources for newsworthy items:<br />
## Files inside the source tree with a name of, or similar to, <tt>NEWS</tt>, <tt>CHANGES</tt>, <tt>ChangeLog</tt><br />
## the homepage of the project<br />
## a blog about the software / a blog by the author<br />
## an announce post on a mailing list or community site such as freshcode.club<br />
## your own experience with the new version.<br />
# If you cannot find anything in the aforementioned set of places, that is ok. Say so, and consider it done. (For example, “<tt>* No changelog was made available.</tt>”) It is not necessary to inspect commit logs or to analyze source code.<br />
<br />
Then, assort what you have found with due care:<br />
<br />
# Don't just copy what you find without reviewing yourself.<br />
# Avoid and trim anything related to the build procedure of the package if it has no visible effect on the user. The software is already built by the time it reaches the user.<br />
# Like with [[openSUSE:Package_description_guidelines#Summary|summaries]], remove anything about non-openSUSE platforms.<br />
# You can use SCM commit messages, if they prove to be useful. If in doubt, don't.<br />
# Now, can you, as a package maintainer, make sense of every news item? Does the item mean something to you? If not, then neither does it for the user, and the item in question should be dropped.<br />
# If, at this point, there is nothing to report, say so and consider it done. (E.g. “<tt>* No user-visible changes</tt>” when, for example, upstream only changed the way the software is built.)<br />
# Be concise. Pick only the topmost interesting points: If you have over 30 lines of changelog, it is time to stop and refer the user to the other materials (such as upstream-provided news files, web links, …)<br />
# Be concise (part 2). Summarize and generalize the points: Don't go too much into specifics of a modification — a suitably interested user can look for implementation details elsewhere.<br />
# If there is an incompatible change that requires the user to adapt their configuration and/or setup, this should be mentioned in the changelog of the package, too, to make the users aware of it.<br />
<br />
You can, optionally, add the original upstream change documents to the package as a file as a reference. This however is only in addition to something in .changes.<br />
<br />
== Distro-related changes ==<br />
<br />
Besides version updates, there may be changes related to the openSUSE packaging itself. Noteworthy items about that would simply be appended.<br />
<br />
<pre><br />
- update to new upstream release 2.0 (if not, omit)<br />
* this and that as per above<br />
- Added new BuildRequires glibc-devel: new dependency<br />
- Do magic trick in install section to overcome installation failure<br />
- add foobar-fix-ham.patch: <give a reason><br />
- add foobar-remove-spam.patch: <give a reason><br />
- modify foobar-autotools.patch: <give a reason><br />
- remove foobar-libpng15-compat.patch: <give a reason> <br />
- ... (other changes done to the package)<br />
</pre><br />
<br />
* Document the changes for future package changes. It can help in identifying if some hack is still needed (the hack in the .spec should have a comment anyway) and when it was added.<br />
* Make the life for any reviewer easier: a short explanation why something is the way it is helps with annoying declines due to misunderstandings. (This sometimes should go into .spec, whereever appropriate.)<br />
<br />
== Referring to upstream ChangeLog ==<br />
<br />
While it might sound like a good idea in the first run, a simple reference to the place of the upstream Changelog (especially if it is tracked on GitHub or other popular collaboration plattforms) is NOT such a good idea. <br />
<br />
* if you reference the Changelog in the "master" branch in your changes file, this file might have changed already. Making it really hard to identify which version your changes file entry belongs to <br />
* People with limited internet access (yes: such people still exist) need not only to download the package but also need to open the link (...and we are not starting the discussion on how to extract it from your changes file here) to really see what happened<br />
<br />
So - whenever possible - please try to follow the two simple suggestions:<br />
* put the most important upstream changes in your changes file, so your package users can get an idea about important changes. 10-15 lines should be enough for this.<br />
* refer to a Changelog file which is installed together with your package (normally under /usr/share/doc/packages/$name/Changelog.md or similar), so people can read the full details without the need to open an internet connection.<br />
<br />
== Bug fix, feature implementation ==<br />
<br />
Anytime you have fixed a bug (or implemented the feature), you '''have to''' mention the number of bug in changes. As fix should be reported in upstream bugzilla, it is better to add a prefix before the number, so people will know where to find an information. For example use ''bsc#1234'' to reference [bugzilla.suse.com/1234 . The full list of issue trackers is available on [[openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations | Current set of abbreviations]].<br />
<br />
In case the issue has some external identifier, like CVE number, it should be added as well. There are more common ways how to format the message <br />
<br />
- update to Firefox 13.0 (bnc#765204)<br />
* MFSA 2012-34/CVE-2012-1938/CVE-2012-1937/CVE-2011-3101<br />
Miscellaneous memory safety hazards<br />
<br />
- Fix string quoting. [bnc#666416]<br />
<br />
- Add xz BuildRequires because we can't build a package for a<br />
xz-compressed tarball without explicitly specifying that... See<br />
bnc#697467 for more details.<br />
<br />
- fix bnc#595144 - Compiled binary in ant<br />
<br />
== Package updates ==<br />
<br />
In case of package update, the new version have to be mentioned in changes. It is often useful to provide some basic changes from upstream changelog. In case upstream does not provide it, you have to still provide that information in the .changes file, such as <br />
<br />
- update to foo 1.2.3: no changelog available<br />
<br />
- update to Firefox 13.0.1<br />
* bugfix release<br />
<br />
== Patches changes ==<br />
<br />
All changes in patches must follow the [[openSUSE:Packaging_Patches_guidelines#Patch_live_cycle|Patches guidelines]]. It is always a good idea to put the patch name behind the line describing the fix<br />
<br />
- fix segfault on load incorrect document (bnc#123456)<br />
* foo-1.2.4-buffer-owerflow.patch<br />
<br />
- update to Firefox 7 (bnc#720264)<br />
* removed obsolete mozilla-cairo-lcd.patch (upstream)<br />
<br />
[[Category:Packaging|{{PAGENAME}}]]<br />
[[Category:Packaging documentation]]<br />
[[it:openSUSE:Come scrivere buoni file delle modifiche]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_Patches_guidelines&diff=132192openSUSE:Packaging Patches guidelines2019-02-21T16:46:10Z<p>Okurz: Move in missing issue tracker definitions from https://en.opensuse.org/index.php?title=openSUSE:Creating_a_changes_file_(RPM)</p>
<hr />
<div>{{Packaging_docnav}}<br />
{{Intro|Packagers deal with lots of packages, and lots of patches inside those packages. These need to be marked in the .spec files with a well-known format to be able to run automatic tools on them, in order to generate reports, patch counts and other interesting information. They also need to be named consistently.}}<br />
<br />
== Patch life cycle ==<br />
Patches need to be added to packages for various reasons and it is important that the life cycle of a patch is well-defined. This helps in preventing that patches get "lost" and nobody knows why and when it was removed. The life cycle is defined in these simple steps:<br />
* Patch added to the package<br />
* Patch is modified (functional/rebased)<br />
* Patch is disabled (but not deleted)<br />
* Patch removed from the package<br />
<br />
The middle stages of the patch life cycle are optional and not every patch will live through them.<br />
<br />
Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. This is only for the benefit of human readers, so does not need to be in a strict machine-parseable format; here are some examples of the suggested format:<br />
* Add package-awesomeness.patch: Makes package awesome<br />
* Drop package-awesomeness.patch: Upstream made it even more awesome.<br />
* Disable package-awesomeness.patch: Testing if users can live without awesomeness<br />
* Rebase package-awesomeness.patch to apply to the new version.<br />
<br />
== Upstream policy ==<br />
For the purpose of defining the upstream policy, we can divide patches into two categories:<br />
* '''upstream''' - upstream probably will be interested in it<br />
* '''openSUSE/SLE specific''' - upstream won't be interested in it<br />
<br />
=== Policy for upstream patches ===<br />
If you want to add a patch that can be interesting for upstream, please note that this '''patch must always be sent upstream'''. This is the only way to ensure that our fixes will be integrated upstream and we can get rid of these patches within the next upstream release. A significant advantage is also that upstream can provide you with sanity checking and a valuable feedback regarding your patch.<br />
<br />
==== When to send the patch to upstream ====<br />
Usually, it's useful to contact upstream before you submit the patch to OBS. You save yourself from resubmitting the patch if upstream finds an error in it.<br />
Also, some of the package maintainers may request this "upstream first" policy before such patch is to be considered for inclusion in the OBS package. Usually, there should be a mention about "upstream first" policy in the specfile of those packages (e. g. SuSEfirewall).<br />
However, sometimes upstream is not active enough and sending them the patch after you submit it to OBS is the only reasonable way.<br />
<br />
==== How to find upstream ====<br />
You have to dig. A good start is to check 'Url' or 'Source' tags in the specfile and visit the upstream website. Then you have to find a way upstream prefers for sending patches. It could be e. g. mail, mailing list, Bugzilla, git, ...<br />
<br />
=== Policy for openSUSE/SLE specific patches ===<br />
Usually, we try to add patches that can be merged upstream. However, it can happen that our package is different from the upstream and a specific patch is the only solution. Then please note that every openSUSE/SLE specific '''patch should be documented properly''' with a justification why this specific fix is needed.<br />
<br />
== Patch markup (also called "Tagging patches") ==<br />
<br />
To facilitate the use of automatic tools (some day), and to help inform future packagers about the patch nature, the following categories for our patches exist:<br />
<br />
* Fixes: these are normal fixes and are divided into three categories:<br />
** Fixes for openSUSE-specific things, that upstream maintainers will not be interested in.<br />
** Fixes for SLE-specific things, that upstream maintainers will not be interested in and that are not needed in openSUSE.<br />
** Fixes for the upstream sources that should be upstreamed.<br />
* Features: new features added to the packages, also divided into three categories:<br />
** Features for openSUSE-specific things (switching the displaymanager via /etc/sysconfig, for instance) with no interest for upstream maintainers.<br />
** Features for SLE-specific things with no interest for upstream maintainers or openSUSE.<br />
** Features that should be upstreamed. Whenever we write this kind of new feature, it is important to coordinate with upstream maintainers. That way, we can develop something that will be accepted upstream without changes. Once a feature is finished, it is a lot of work to rework it to be acceptable to upstream maintainers. As such, it is better to know from the beginning exactly what upstream maintainers would expect.<br />
<br />
There are two competing standards for this.<br />
<br />
=== Type 1: minimal single-line comment in spec file ===<br />
<br />
The old format consists of a comment line above a Patch: line, containing the patch category (see above), a (redundant) copy of the filename, and the rest of the line is a free-format string. Since a single line does not leave much room for words or other metadata, check out Type&nbsp;2 below.<br />
<br />
Type 1 format example:<br />
<br />
# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch1: fix-for-opensuse-specific-things.patch<br />
# PATCH-FIX-SLE fix-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch2: fix-for-sle-specific-things.patch<br />
# PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch bnc#<VAR >123456</VAR ><br />
Patch3: fix-for-upstream-sources.patch<br />
# PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch4: feature-for-opensuse-specific-things.patch<br />
# PATCH-FEATURE-SLE feature-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch5: feature-for-sle-specific-things.patch<br />
# PATCH-FEATURE-UPSTREAM feature-for-upstream.patch bnc#<VAR >123456</VAR ><br />
Patch6: feature-for-upstream.patch<br />
<br />
Special case: we often have patches that get commented out temporarily because they failed to apply to the latest sources, and the patches need to be rebased. Do not comment out the patch's declaration, but do comment out its application. When marking a patch as needing a rebase, it is a good idea to preserve its old tag.<br />
<br />
# PATCH-NEEDS-REBASE old-patch.patch bnc#<VAR >123456</VAR > -- Does something old. Was: PATCH-FEATURE-OPENSUSE<br />
Patch7: old-patch.patch<br />
[...]<br />
# %patch7<br />
<br />
Finally, we include e-mail addresses so that it will be easier to figure out who wrote a patch if we have questions later, and free-form comments after " -- ".<br />
<br />
That is:<br />
# PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} ''name-of-file.patch'' bnc#<VAR >[0-9]+</VAR > <VAR >you</VAR >@<VAR >example.com</VAR > -- ''this patch makes things totally awesome''<br />
If there are related bugs in [http://bugzilla.novell.com Novell] or other bugzillas, please add them, it will help us to get more accurate information. If there are two or more available then it's preferable to list both (or more).<br />
<br />
In general, the bugzilla field is not required on new patches. For patches to released packages that will go out as updates, a bugzilla entry (BNC#) for the overall update in the changes file is required. If appropriate, the patch description should also include it.<br />
<br />
The primary use case of the patch field should be references to<br />
'''upstream''' bug trackers in case of PATCH-*-UPSTREAM patches, such<br />
patches should be submitted upstream first and then referenced in the<br />
patch tag. That helps a lot to keep track of patches, it makes it easy to<br />
determine which patches are still needed on version updates if<br />
upstream references the bug numbers in their changelog or release<br />
notes. Of course if there is already a corresponding bnc# bug<br />
open it should be referenced as well.<br />
<br />
You can find the current set of abbreviations at the end of this document. We can also define more abbreviations later if and when they prove necessary.<br />
<br />
Some patches fix bugs that are not explicitly recorded anywhere. The right thing to do in this case requires some judgment on the part of the packager, but here are some ideas:<br />
<br />
* If a release is imminent, create a bug for it. This is usually a requirement, and even if it were not, it is still the right thing to do.<br />
* If a release is a long way off and the bug has already been fixed upstream, note in the comment that it is already fixed in the <ABBR >SVN</ABBR > (or wherever) and the patch will go away when we next upgrade.<br />
<br />
=== Type 2: Complete Information provided in patch ===<br />
<br />
The Type 1 standard lacks the most important part of a patch: a useful description why it is needed or desired in the first place, its single line format is seldomly enough to convey all the desirable information, and the state of the patch (upstream or opensuse-specific, fix or feature, etc.) is cut off from the actual patch.<br />
<br />
The patches in the openSUSE kernel packages have traditionally used a form of tagging where metadata is directly attached to where it is needed — in the patch file itself. This facilitates submission of patches to upstream, as the description cannot be accidentally omitted, and the Git SCM (where used) knows to retain the metadata on import. Conversely, extraction of patches from Git repos also yields single files.<br />
<br />
Patch files are to follow a scheme of "<tt>key: value</tt>" pairs and a description, optionally with a diffstat, prepended to the actual hunks. Example.<br />
<br />
From: Random J Developer <email@example.org><br />
Date: 2012-07-28 01:28:22 +0200<br />
Subject: input: add Acer Aspire 5710 to nomux blacklist<br />
References: bnc#404881<br />
Upstream: submitted<br />
<br />
Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad misbehaves.<br />
<br />
---<br />
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++<br />
1 file changed, 7 insertions(+)<br />
<br />
--- a/drivers/input/serio/i8042-x86ia64io.h<br />
+++ b/drivers/input/serio/i8042-x86ia64io.h<br />
@@ -371,6 +371,13 @@ static const struct dmi_system_id __init<br />
[...]<br />
<br />
It is advised to use e.g. Quilt which retains descriptions on refresh. `<tt>quilt ref --sort --diffstat -p1</tt>` creates/refreshes such patches, sorted, with a diffstat and in the wanted -p1 format.<br/><br />
Common fields encountered:<br />
<br />
* '''From:''' shall specify the e-mail address of the original author of the patch.<br />
* '''Date:''' when this patch was first created. Preferably an ISO-8601 timestamp with timezone. If a new patch was just created and has none, you can use `<tt>stat your.patch</tt>` to determine a timestamp.<br />
* '''References:''' links to mailing list posts, bugzillas, etc. No fixed format, though URLs are preferred for they are easy to copy&paste into the browser. See the below section “[[#Current set of abbreviations]]” for details.<br />
* '''Upstream:''' the disposition of the patch. No fixed format, though common options are “never”/“no” (openSUSE-specific), “to be done” (tbd), “sent”/“submitted” (sent to upstream developers; provide Reference if possible), “merged” (upstream has accepted it; provide Reference if possible) and “dead” (no activity in upstream project).<br />
* '''Subject:''' A short one-line summary of the patch.<br />
<br />
'''Patches are to provide a description.''' The description shall describe _why_ it is needed. Be as thorough as you like, because it will influence the decision what a different developer should do with the patch should it not apply anymore. The three questions “what command did you execute?”, “what did you observe?”, “what did you expect to see instead?” can give some guidance. If a related error message is available, e.g. when creating a patch to fix a syntactical error in a source file that causes the compilation to abort, it should be included, trimmed to the important parts. Furthermore, a summary on the how the solution is implemented can help readers grok larger patches.<br />
<br />
Reading material (from the mailing lists) that shows the need for this kind of tagging: [http://lists.opensuse.org/opensuse-factory/2012-08/msg00683.html (1)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00719.html (2)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00749.html (3)]<br />
<br />
== Patch naming ==<br />
<br />
All new patches should end with the extension '.patch'.<br />
<br />
Whether a patch's name should start with the name of the package it applies to is a matter of debate or style. When in doubt, follow the convention used in the package you are hacking on.<br />
<br />
Do '''NOT''' use <code>%{version}</code> macro in <code>Patch:</code> line, specify the version by hand. Using the macro:<br />
* causes lots of renames on version update<br />
* makes it easy to overlook patches that are no longer needed<br />
* makes it hard to determine when the patch was touch for the last time<br />
* makes it easy to find out when the patch broke (package archaelogy)<br />
<br />
An exception to this exists: patches that fix warnings that the compiler emits due to bogus code are frequently named <tt>abuild.patch</tt>.<br />
<br />
The preferred patchlevel is <tt>-p1</tt> as it makes importing using tools like ''quilt'' more straightforward.<br />
<br />
----<br />
== Current set of abbreviations ==<br />
To avoid confusion and double burden, referencing to other issue trackers is allowed. Here are some shortcuts for often used issue trackers, which should be added before the "#" of the issue id. Note there is no whitespace between the shortcut and the issue id.<br />
<br />
NOTE: this list is not authoritative, please check with the Open Build Service how they are defined there (osc api /issue_trackers). You can also request new trackers via the [https://github.com/openSUSE/open-build-service OBS github project].<br />
<br />
{| border="1" <br />
!Shortcut<br />
!Issue-Tracker-URL<br />
!Example<br />
|-<br />
| '''openSUSE Bug tracker'''<br />
| http://bugzilla.opensuse.org/show_bug.cgi?id=123456<br />
| (boo#123456)<br />
|-<br />
| AbiWord<br />
| https://bugzilla.abisource.com<br />
| (bac#123456)<br />
|-<br />
| Apache Software Foundation (obsolete)<br />
| https://issues.apache.org/bugzilla/<br />
| (pr#37770)<br />
|-<br />
| Apache Software Foundation Bugzilla<br />
| https://bz.apache.org/bugzilla/<br />
| (bao#12345)<br />
|-<br />
| Apache Software Foundation Jira<br />
| https://issues.apache.org/jira/issues/<br />
| (jira#12345)<br />
|-<br />
| Apache OpenOffice<br />
| https://bz.apache.org/ooo/<br />
| (aoo#1234)<br />
|-<br />
| Apache SpamAssassin<br />
| https://bz.apache.org/SpamAssassin/<br />
| (asa#12345)<br />
|-<br />
| Boost<br />
| https://svn.boost.org/trac/boost/report<br />
| (boost#123456)<br />
|-<br />
| Ceph bug tracker<br />
| http://tracker.ceph.com/<br />
| (ceph#123456)<br />
|-<br />
| Claws Mail<br />
| http://www.thewildbeast.co.uk/claws-mail/bugzilla/<br />
| (claws#123456)<br />
|-<br />
| CVE entries (please add the number, even if there is an additional bugzilla for it)<br />
| http://cve.mitre.org<br />
| (CVE-2009-0067)<br />
|-<br />
| CPAN Public Bug Tracker<br />
| http://rt.cpan.org/Public/<br />
| (RT#123456)<br />
|-<br />
| Debian<br />
| http://bugs.debian.org/<br />
| (deb#123456)<br />
|-<br />
| Enlightenment<br />
| https://phab.enlightenment.org<br />
| (e#1234)<br />
|-<br />
| Exim<br />
| http://bugs.exim.org/<br />
| (beo#1234)<br />
|-<br />
| Fate (Feature tracking tool)<br />
| https://features.opensuse.org/ | https://fate.suse.com<br />
| (fate#123456)<br />
|-<br />
| freedesktop.org<br />
| http://bugs.freedesktop.org/<br />
| (fdo#123456)<br />
|-<br />
| Freedesktop's GitLab<br />
| https://gitlab.freedesktop.org<br />
| ([https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/571 glfdo#pulseaudio/pulseaudio#571])<br />
|-<br />
| GCC<br />
| http://gcc.gnu.org/bugzilla/<br />
| (GCC#123456)<br />
|-<br />
| GitHub<br />
| https://github.com/<br />
| ([https://github.com/yast/yast-core/issues/42 gh#yast/yast-core#42])<br />
|-<br />
| GitLab<br />
| https://gitlab.com<br />
| ([https://gitlab.com/gitlab-org/gitlab-ce/issues/43675 gl#gitlab-org/gitlab-ce#43675])<br />
|-<br />
| GNOME<br />
| http://bugzilla.gnome.org/<br />
| (bgo#123456)<br />
|-<br />
| GNOME's GitLab<br />
| https://gitlab.gnome.org<br />
| ([https://gitlab.gnome.org/GNOME/nautilus/issues/79 glgo#GNOME/natilus#79])<br />
|-<br />
| GnuCash<br />
| https://bugs.gnucash.org/<br />
| (bgco#123456)<br />
|-<br />
| Graphviz<br />
| http://graphviz.org/mantisbt/view_all_bug_page.php<br />
| (gvz#123456)<br />
|-<br />
| ICCULUS<br />
| http://bugzilla.icculus.org/<br />
| (bio#123456)<br />
|-<br />
| Jenkins CI<br />
| https://issues.jenkins-ci.org<br />
| (jenk#123456)<br />
|-<br />
| KDE <br />
| http://bugs.kde.org/<br />
| (kde#123456)<br />
|-<br />
| Kernel or K<br />
| http://bugzilla.kernel.org/<br />
| (bko#123456)<br />
|-<br />
| Launchpad (Ubuntu)<br />
| https://bugs.launchpad.net/<br />
| (lp#123456)<br />
|-<br />
| LibreOffice<br />
| https://bugs.documentfoundation.org/describecomponents.cgi<br />
| (bdo#123456)<br />
|-<br />
| Linux Foundation<br />
| https://developerbugs.linux-foundation.org/<br />
| (lf#1234)<br />
|-<br />
| MeeGo<br />
| http://bugs.meego.com<br />
| (MeeGo#123456)<br />
|-<br />
| Mozilla<br />
| http://bugzilla.mozilla.org/<br />
| (bmo#123456)<br />
|-<br />
| Novell<br />
| https://bugzilla.novell.com/<br />
| (bnc#123456)<br />
|-<br />
| SUSE bugs<br />
| https://bugzilla.suse.com/<br />
| (bsc#123456)<br />
|-<br />
| SUSE SLE features<br />
| https://jira.suse.com/ | https://jira.suse.de<br />
| (jsc#SLE-1234)<br />
|-<br />
| OpenLDAP<br />
| http://www.openldap.org/its/<br />
| (ITS#123456)<br />
|-<br />
| OpenOffice.org Issuezilla (obsolete)<br />
| http://qa.openoffice.org/issues/<br />
| (i#123456)<br />
|-<br />
| OpenOffice.org Novell (obsolete)<br />
| https://bugzilla.novell.com/<br />
| (n#123456)<br />
|-<br />
| openSUSE-Education<br />
| http://devzilla.novell.com/education/<br />
| (os-edu#123456)<br />
|-<br />
| Pidgin<br />
| https://developer.pidgin.im/ticket/12345<br />
| (pidgin.im#12345)<br />
|-<br />
| RedHat<br />
| https://bugzilla.redhat.com/<br />
| (rh#123456)<br />
|-<br />
| Samba<br />
| https://bugzilla.samba.org/<br />
| (bso#123456)<br />
|-<br />
| Sourceforge<br />
| http://sf.net/support/tracker.php?aid=1234567<br />
| (sf#1234567); number is in the "aid=" part in an URL<br />
|-<br />
| SourceWare<br />
| http://sourceware.org/bugzilla/<br />
| (swo#1234567)<br />
|-<br />
| Typo3<br />
| http://forge.typo3.org/<br />
| (t3#1234567)<br />
|-<br />
| WebKit<br />
| https://bugs.webkit.org/<br />
| (webkit#123456)<br />
|-<br />
| Xfce<br />
| https://bugzilla.xfce.org/<br />
| (bxo#123456)<br />
|-<br />
| Xamarin<br />
| http://bugzilla.xamarin.com/<br />
| (bxc#4321)<br />
|-<br />
| trello<br />
| https://trello.com/c/OMdsDiAE<br />
| (tr#OMdsDiAE)<br />
|}<br />
<br />
For other issue ids, please use the full URL to the coresponding issue tracker at the beginning of the patch file. For example:<br />
* http://developer.berlios.de/bugs/?func=detailbug&bug_id=12707&group_id=769<br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Paketbau Richtlinien für Patches]]<br />
[[el:openSUSE:Packaging Patches guidelines]]<br />
[[ja:openSUSE:パッケージング修正ガイドライン]]<br />
[[ru:openSUSE:Руководство по оформлению патчей]]<br />
[[zh:openSUSE:Packaging_Patches_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Systemd_packaging_guidelines&diff=130384openSUSE:Systemd packaging guidelines2018-11-18T06:55:47Z<p>Okurz: /* Systemd timers */ revert last change, links seem to not work in info-box</p>
<hr />
<div>{{Template:Systemd_navbar}}<br />
<br />
{{Intro|This article describes packaging guidelines for systemd services. }}<br />
<br />
==RPM macros==<br />
<br />
Starting with openSUSE 12.1, several RPM macros must be used to package systemd services files.<br />
<br />
=== (Build) Requirements ===<br />
You should add :<br />
<pre><br />
%if 0%{?suse_version} >= 1210<br />
%bcond_without systemd<br />
%else<br />
%bcond_with systemd<br />
%endif<br />
[...]<br />
%if %{with systemd}<br />
BuildRequires: systemd-rpm-macros<br />
%{?systemd_requires}<br />
%endif<br />
</pre><br />
<br />
You need both the build requirement ''and'' the '''%{?systemd_requires}'''.<br />
<br />
===Systemd unit files===<br />
Systemd unit files like service, socket, and path files should always be installed in <code>%_unitdir</code> (i.e. <code>/usr/lib/systemd/system</code>) and never in <code>/etc/systemd/system</code> (so they can be overridden by users without conflicting with packaging). An exception are user unit files which must be installed in <code>%{_prefix}/lib/systemd/user</code> (i.e. <code>/usr/lib/systemd/user</code>).<br />
<br />
This command is an example of a legal install line where <code>%{S:3}</code> is a reference e.g. to your service file:<br><br />
<pre><br />
install -D -m 644 %{S:3} %{buildroot}%{_unitdir}/foo.service<br />
</pre><br />
<br />
Systemd unit files should be considered not to be edited by system administrators. For this the directory <code>/etc/systemd/system</code> exists. A service file named <code>foo.service</code> might be overriden by the system administrator creating a file <code>/etc/systemd/system/foo.service.d/my.conf</code>.<br />
<br />
===Instantiated Service files===<br />
If an instantiated service (compare with manual page [https://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)]) is needed then the service file packaged with the RPM should be installed to <code>foo@.service</code>. Thus this command is a legal install line:<br />
<pre><br />
install -D -m 644 %{S:3} %{buildroot}%{_unitdir}/foo@.service<br />
</pre><br />
<br />
The user should instantiate the service via a command like:<br />
<pre><br />
sytemctl enable autossh@${my-instance}.service<br />
</pre><br />
<br />
and override the service file by the system administrator creating a file <code>/etc/systemd/system/foo@${my-instance}.service.d/my.conf</code><br />
<br />
Thus each instance must be individually instantiated and overridden by the system administrator or the appropriate systemd generator (compare with manual page [https://www.freedesktop.org/software/systemd/man/systemd.generator.html systemd.generator(7)]) as specified in http://www.freedesktop.org/wiki/Software/systemd/Generators .<br />
<br />
===Register systemd unit files in install scripts===<br />
Add the following macros to your scripts:<br />
<br />
if <code>foo.service</code>, <code>bar.socket</code>, and <code>elsewhere.path</code> are three systemd units you are installing :<br />
<pre><br />
%pre<br />
%service_add_pre foo.service bar.socket elsewhere.path<br />
<br />
%post<br />
%service_add_post foo.service bar.socket elsewhere.path<br />
<br />
%preun<br />
%service_del_preun foo.service bar.socket elsewhere.path<br />
<br />
%postun<br />
%service_del_postun foo.service bar.socket elsewhere.path<br />
</pre><br />
<br />
Compare with the manual pages [https://www.freedesktop.org/software/systemd/man/systemd.service.html systemd.service(5)], [https://www.freedesktop.org/software/systemd/man/systemd.socket.html systemd.socket(5)], and [https://www.freedesktop.org/software/systemd/man/systemd.path.html systemd.path(5)] as well as the overview [https://www.freedesktop.org/software/systemd/man/systemd.exec.html systemd.exec(5)] and [https://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)].<br />
<br />
If your package is also providing sysv initscripts, those macros will handle sysv initscripts migration transparently (as long as initscripts and systemd services have similar names).<br />
<br />
If your package is supposed to build for openSUSE older than 12.1, you should use condition test for those macros.<br />
<br />
Since <code>%suse_version > 1320 or %sle_version > 120100</code> <code>%service_del_preun</code>, <code>%service_del_postun</code> and <code>%systemd_preun</code> know the arguments <code>-f</code> and <code>-n</code>: <br />
# '''-f''' forces a restart on update when called with <code>%service_del_postun</code> or stop on removal when called from <code>%service_del_preun</code>while<br />
# '''-n''' will prevent active services from being touched on update (<code>%service_del_postun</code>) or uninstall (<code>%service_del_preun</code>). <br />
On older versions or when nothing is specified, the default is that <br />
# if the service should NOT be restarted when being updated, you should append in the <code>%postun</code> section, just before <code>%service_del_postun</code> call:<br />
<pre><br />
export DISABLE_RESTART_ON_UPDATE=yes<br />
</pre><br />
# if the service should NOT be stopped when being uninstalled, you should append in the <code>%preun</code>, just before the <code>%service_del_preun</code> call:<br />
<pre><br />
export DISABLE_STOP_ON_REMOVAL=yes<br />
</pre><br />
<br />
==Enabling systemd unit files==<br />
By default, services are not enabled when package is installed. If you want your service to be enabled by default, you should do a submit request (with OBS) on <code>systemd-presets-branding-openSUSE</code> package, modifying <code>default-openSUSE.preset</code> file by adding e.g.:<br />
<pre><br />
enable your_service_name.service<br />
</pre><br />
<br />
Such an automatically enabled service shouldn't require any manual configuration before it can start properly.<br />
<br />
== Systemd timers==<br />
[https://www.freedesktop.org/software/systemd/man/systemd.timer.html Systemd timer] is a systemd feature that helps to define time activated services or events. It's an alternative to cron.<br />
<br />
{{info| Since 2018-11-09, a process of migration from cron to systemd timers (fate#323635) is in progress. See boo#1115430 (openSUSE) and bsc#1115399 (SLE, internal) trackerbugs that track all packages that should be migrated for openSUSE and SLE.}}<br />
<br />
===Timer and service units===<br />
Timer unit is a unit configuration file that ends with <code>.timer</code> suffix and it activates the matching service file (<code>foo.timer</code> activates <code>foo.service</code>). Systemd automatically pair timer and service with the same name but it can be also specified via <code>Unit=</code>.<br />
<br />
Timers need to include <code>[Timer]</code> section that defines when the timer is activated. For the whole description of the time format used for timer configuration please see [https://www.freedesktop.org/software/systemd/man/systemd.timer.html systemd.timer(5)]. For time and date specification see [https://www.freedesktop.org/software/systemd/man/systemd.time.html systemd.time(7)].<br />
<br />
Timer units can be either provided by upstream or a packager needs to write it himself/herself (e.g. during migration from cron to systemd timers). <br />
<br />
====Examples====<br />
Example <code>logrotate.timer</code><br />
<pre><br />
[Unit]<br />
Description=Daily rotation of log files<br />
Documentation=man:logrotate(8) man:logrotate.conf(5)<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
AccuracySec=12h<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
</pre><br />
<br />
Example <code>logrotate.service</code><br />
<pre><br />
[Unit]<br />
Description=Rotate log files<br />
Documentation=man:logrotate(8) man:logrotate.conf(5)<br />
ConditionACPower=true<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf<br />
</pre><br />
<br />
=== Packaging of the systemd timers===<br />
Packaging of the systemd timers is very similar to the packaging of any other systemd unit.<br />
<br />
<pre><br />
# Pack service and timer files<br />
Source5: %{name}.service<br />
Source6: %{name}.timer<br />
<br />
# Standard systemd requirements<br />
BuildRequires: pkgconfig(systemd)<br />
%{?systemd_requires}<br />
<br />
# Install service and timer file<br />
%install<br />
install -D -m 0644 %{SOURCE:5} %{buildroot}%{_unitdir}/%{name}.service<br />
install -D -m 0644 %{SOURCE:6} %{buildroot}%{_unitdir}/%{name}.timer<br />
<br />
# Use systemd macros in %pre, %post, %preun, %postun sections<br />
%pre<br />
%service_add_pre %{name}.timer<br />
<br />
%post<br />
%service_add_post %{name}.timer<br />
<br />
%preun<br />
%service_del_preun %{name}.timer<br />
<br />
%postun<br />
%service_del_postun %{name}.timer<br />
<br />
# List them in the %files section<br />
%files<br />
%{_unitdir}/%{name}.service<br />
%{_unitdir}/%{name}.timer<br />
</pre><br />
<br />
===Enabling and starting===<br />
Please note that by default, services are not enabled when the package is installed. You probably want your timer to be enabled by default so you should create a submit request on <code>systemd-presets-branding-openSUSE</code> package, modifying <code>default-openSUSE.preset</code> file by adding <code>enable your_timer_name.timer</code>.<br />
<br />
== Creating files and subdirectories in /var/run and /run ==<br />
<br />
Since openSUSE 12.2, <code>/var/run</code> (which is either bind mounted or symlinked to <code>/run</code>) are mounted as tmpfs, so packages should not contain any directories (or files) under <code>/var/run</code> (or <code>/run</code>), since they will disappear at the next reboot.<br />
<br />
If new files / directories need to be created there, you should package a tmpfiles.d file (see man [http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html tmpfiles.d] for the syntax), installed in <code>%_tmpfilesdir</code>(<code>/usr/lib/tmpfiles.d/</code>). One example of such a file:<br />
<pre><br />
# create a directory with permissions 0770 owned by user foo and group bar<br />
d /var/run/my_new_directory 0770 foo bar<br />
</pre><br />
<br />
You should install them in '''%install''' section like this:<br />
<pre><br />
install -d -m 0755 %{buildroot}/usr/lib/tmpfiles.d/<br />
install -m 0644 %{SOURCE4} %{buildroot}/usr/lib/tmpfiles.d/%{name}.conf<br />
</pre><br />
<br />
If you expect this file or directory to be available after package installation (and before reboot), remember to add in your package '''%post''' section:<br />
<pre><br />
%tmpfiles_create %_tmpfilesdir/<file_name><br />
</pre><br />
<br />
== Backward compatibility ==<br />
<br />
=== rc symlink ===<br />
It's still possible to keep the <code>/usr/sbin/rc<i>name</i></code> symlink. In order to make it work with systemd, link to <code>/usr/sbin/service</code> for each unit (service and target types are supported):<br />
<pre><br />
ln -s /usr/sbin/service %{buildroot}%{_sbindir}/rcname<br />
</pre><br />
<br />
=== Extra actions ===<br />
<br />
Init scripts sometimes implemented additional actions besides the usual<br />
start/stop/status etc. For systemd service files that extra feature<br />
doesn't exist. It's still convenient to have for some services though.<br />
Therefore /usr/sbin/service implements "legacy actions" like Fedora.<br />
<br />
Suppose your previous init script "foo" had an action "frob". Now the<br />
service file is called "foo.service" and you want to still support the "frob"<br />
action. In Factory since 2014-03-11 (post 13.1) you can create a script<br />
/usr/lib/initscripts/legacy-actions/foo/frob<br />
that implements the feature you need.<br />
Obviously the action is only available when calling the service via<br />
<code>/usr/sbin/service</code>, ie<br />
<br />
# service foo frob<br />
or<br />
# rcfoo frob<br />
<br />
[[Category:Systemd]]<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[ja:openSUSE:Systemd パッケージングガイドライン]]<br />
[[ru:openSUSE:Сборка_пакетов_с_поддержкой_systemd]]<br />
[[zh:openSUSE:Systemd_packaging_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Systemd_packaging_guidelines&diff=130382openSUSE:Systemd packaging guidelines2018-11-18T06:48:26Z<p>Okurz: /* Systemd timers */ use links for fate+bugzilla references</p>
<hr />
<div>{{Template:Systemd_navbar}}<br />
<br />
{{Intro|This article describes packaging guidelines for systemd services. }}<br />
<br />
==RPM macros==<br />
<br />
Starting with openSUSE 12.1, several RPM macros must be used to package systemd services files.<br />
<br />
=== (Build) Requirements ===<br />
You should add :<br />
<pre><br />
%if 0%{?suse_version} >= 1210<br />
%bcond_without systemd<br />
%else<br />
%bcond_with systemd<br />
%endif<br />
[...]<br />
%if %{with systemd}<br />
BuildRequires: systemd-rpm-macros<br />
%{?systemd_requires}<br />
%endif<br />
</pre><br />
<br />
You need both the build requirement ''and'' the '''%{?systemd_requires}'''.<br />
<br />
===Systemd unit files===<br />
Systemd unit files like service, socket, and path files should always be installed in <code>%_unitdir</code> (i.e. <code>/usr/lib/systemd/system</code>) and never in <code>/etc/systemd/system</code> (so they can be overridden by users without conflicting with packaging). An exception are user unit files which must be installed in <code>%{_prefix}/lib/systemd/user</code> (i.e. <code>/usr/lib/systemd/user</code>).<br />
<br />
This command is an example of a legal install line where <code>%{S:3}</code> is a reference e.g. to your service file:<br><br />
<pre><br />
install -D -m 644 %{S:3} %{buildroot}%{_unitdir}/foo.service<br />
</pre><br />
<br />
Systemd unit files should be considered not to be edited by system administrators. For this the directory <code>/etc/systemd/system</code> exists. A service file named <code>foo.service</code> might be overriden by the system administrator creating a file <code>/etc/systemd/system/foo.service.d/my.conf</code>.<br />
<br />
===Instantiated Service files===<br />
If an instantiated service (compare with manual page [https://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)]) is needed then the service file packaged with the RPM should be installed to <code>foo@.service</code>. Thus this command is a legal install line:<br />
<pre><br />
install -D -m 644 %{S:3} %{buildroot}%{_unitdir}/foo@.service<br />
</pre><br />
<br />
The user should instantiate the service via a command like:<br />
<pre><br />
sytemctl enable autossh@${my-instance}.service<br />
</pre><br />
<br />
and override the service file by the system administrator creating a file <code>/etc/systemd/system/foo@${my-instance}.service.d/my.conf</code><br />
<br />
Thus each instance must be individually instantiated and overridden by the system administrator or the appropriate systemd generator (compare with manual page [https://www.freedesktop.org/software/systemd/man/systemd.generator.html systemd.generator(7)]) as specified in http://www.freedesktop.org/wiki/Software/systemd/Generators .<br />
<br />
===Register systemd unit files in install scripts===<br />
Add the following macros to your scripts:<br />
<br />
if <code>foo.service</code>, <code>bar.socket</code>, and <code>elsewhere.path</code> are three systemd units you are installing :<br />
<pre><br />
%pre<br />
%service_add_pre foo.service bar.socket elsewhere.path<br />
<br />
%post<br />
%service_add_post foo.service bar.socket elsewhere.path<br />
<br />
%preun<br />
%service_del_preun foo.service bar.socket elsewhere.path<br />
<br />
%postun<br />
%service_del_postun foo.service bar.socket elsewhere.path<br />
</pre><br />
<br />
Compare with the manual pages [https://www.freedesktop.org/software/systemd/man/systemd.service.html systemd.service(5)], [https://www.freedesktop.org/software/systemd/man/systemd.socket.html systemd.socket(5)], and [https://www.freedesktop.org/software/systemd/man/systemd.path.html systemd.path(5)] as well as the overview [https://www.freedesktop.org/software/systemd/man/systemd.exec.html systemd.exec(5)] and [https://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)].<br />
<br />
If your package is also providing sysv initscripts, those macros will handle sysv initscripts migration transparently (as long as initscripts and systemd services have similar names).<br />
<br />
If your package is supposed to build for openSUSE older than 12.1, you should use condition test for those macros.<br />
<br />
Since <code>%suse_version > 1320 or %sle_version > 120100</code> <code>%service_del_preun</code>, <code>%service_del_postun</code> and <code>%systemd_preun</code> know the arguments <code>-f</code> and <code>-n</code>: <br />
# '''-f''' forces a restart on update when called with <code>%service_del_postun</code> or stop on removal when called from <code>%service_del_preun</code>while<br />
# '''-n''' will prevent active services from being touched on update (<code>%service_del_postun</code>) or uninstall (<code>%service_del_preun</code>). <br />
On older versions or when nothing is specified, the default is that <br />
# if the service should NOT be restarted when being updated, you should append in the <code>%postun</code> section, just before <code>%service_del_postun</code> call:<br />
<pre><br />
export DISABLE_RESTART_ON_UPDATE=yes<br />
</pre><br />
# if the service should NOT be stopped when being uninstalled, you should append in the <code>%preun</code>, just before the <code>%service_del_preun</code> call:<br />
<pre><br />
export DISABLE_STOP_ON_REMOVAL=yes<br />
</pre><br />
<br />
==Enabling systemd unit files==<br />
By default, services are not enabled when package is installed. If you want your service to be enabled by default, you should do a submit request (with OBS) on <code>systemd-presets-branding-openSUSE</code> package, modifying <code>default-openSUSE.preset</code> file by adding e.g.:<br />
<pre><br />
enable your_service_name.service<br />
</pre><br />
<br />
Such an automatically enabled service shouldn't require any manual configuration before it can start properly.<br />
<br />
== Systemd timers==<br />
[https://www.freedesktop.org/software/systemd/man/systemd.timer.html Systemd timer] is a systemd feature that helps to define time activated services or events. It's an alternative to cron.<br />
<br />
{{info| Since 2018-11-09, a process of migration from cron to systemd timers ([https://fate.suse.com/323635 fate#323635]) is in progress. See [https://bugzilla.opensuse.org/show_bug.cgi?id=1115430 boo#1115430] (openSUSE) and [https://bugzilla.suse.com/show_bug.cgi?id=1115399 bsc#1115399] (SLE, internal) trackerbugs that track all packages that should be migrated for openSUSE and SLE.}}<br />
<br />
===Timer and service units===<br />
Timer unit is a unit configuration file that ends with <code>.timer</code> suffix and it activates the matching service file (<code>foo.timer</code> activates <code>foo.service</code>). Systemd automatically pair timer and service with the same name but it can be also specified via <code>Unit=</code>.<br />
<br />
Timers need to include <code>[Timer]</code> section that defines when the timer is activated. For the whole description of the time format used for timer configuration please see [https://www.freedesktop.org/software/systemd/man/systemd.timer.html systemd.timer(5)]. For time and date specification see [https://www.freedesktop.org/software/systemd/man/systemd.time.html systemd.time(7)].<br />
<br />
Timer units can be either provided by upstream or a packager needs to write it himself/herself (e.g. during migration from cron to systemd timers). <br />
<br />
====Examples====<br />
Example <code>logrotate.timer</code><br />
<pre><br />
[Unit]<br />
Description=Daily rotation of log files<br />
Documentation=man:logrotate(8) man:logrotate.conf(5)<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
AccuracySec=12h<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
</pre><br />
<br />
Example <code>logrotate.service</code><br />
<pre><br />
[Unit]<br />
Description=Rotate log files<br />
Documentation=man:logrotate(8) man:logrotate.conf(5)<br />
ConditionACPower=true<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf<br />
</pre><br />
<br />
=== Packaging of the systemd timers===<br />
Packaging of the systemd timers is very similar to the packaging of any other systemd unit.<br />
<br />
<pre><br />
# Pack service and timer files<br />
Source5: %{name}.service<br />
Source6: %{name}.timer<br />
<br />
# Standard systemd requirements<br />
BuildRequires: pkgconfig(systemd)<br />
%{?systemd_requires}<br />
<br />
# Install service and timer file<br />
%install<br />
install -D -m 0644 %{SOURCE:5} %{buildroot}%{_unitdir}/%{name}.service<br />
install -D -m 0644 %{SOURCE:6} %{buildroot}%{_unitdir}/%{name}.timer<br />
<br />
# Use systemd macros in %pre, %post, %preun, %postun sections<br />
%pre<br />
%service_add_pre %{name}.timer<br />
<br />
%post<br />
%service_add_post %{name}.timer<br />
<br />
%preun<br />
%service_del_preun %{name}.timer<br />
<br />
%postun<br />
%service_del_postun %{name}.timer<br />
<br />
# List them in the %files section<br />
%files<br />
%{_unitdir}/%{name}.service<br />
%{_unitdir}/%{name}.timer<br />
</pre><br />
<br />
===Enabling and starting===<br />
Please note that by default, services are not enabled when the package is installed. You probably want your timer to be enabled by default so you should create a submit request on <code>systemd-presets-branding-openSUSE</code> package, modifying <code>default-openSUSE.preset</code> file by adding <code>enable your_timer_name.timer</code>.<br />
<br />
== Creating files and subdirectories in /var/run and /run ==<br />
<br />
Since openSUSE 12.2, <code>/var/run</code> (which is either bind mounted or symlinked to <code>/run</code>) are mounted as tmpfs, so packages should not contain any directories (or files) under <code>/var/run</code> (or <code>/run</code>), since they will disappear at the next reboot.<br />
<br />
If new files / directories need to be created there, you should package a tmpfiles.d file (see man [http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html tmpfiles.d] for the syntax), installed in <code>%_tmpfilesdir</code>(<code>/usr/lib/tmpfiles.d/</code>). One example of such a file:<br />
<pre><br />
# create a directory with permissions 0770 owned by user foo and group bar<br />
d /var/run/my_new_directory 0770 foo bar<br />
</pre><br />
<br />
You should install them in '''%install''' section like this:<br />
<pre><br />
install -d -m 0755 %{buildroot}/usr/lib/tmpfiles.d/<br />
install -m 0644 %{SOURCE4} %{buildroot}/usr/lib/tmpfiles.d/%{name}.conf<br />
</pre><br />
<br />
If you expect this file or directory to be available after package installation (and before reboot), remember to add in your package '''%post''' section:<br />
<pre><br />
%tmpfiles_create %_tmpfilesdir/<file_name><br />
</pre><br />
<br />
== Backward compatibility ==<br />
<br />
=== rc symlink ===<br />
It's still possible to keep the <code>/usr/sbin/rc<i>name</i></code> symlink. In order to make it work with systemd, link to <code>/usr/sbin/service</code> for each unit (service and target types are supported):<br />
<pre><br />
ln -s /usr/sbin/service %{buildroot}%{_sbindir}/rcname<br />
</pre><br />
<br />
=== Extra actions ===<br />
<br />
Init scripts sometimes implemented additional actions besides the usual<br />
start/stop/status etc. For systemd service files that extra feature<br />
doesn't exist. It's still convenient to have for some services though.<br />
Therefore /usr/sbin/service implements "legacy actions" like Fedora.<br />
<br />
Suppose your previous init script "foo" had an action "frob". Now the<br />
service file is called "foo.service" and you want to still support the "frob"<br />
action. In Factory since 2014-03-11 (post 13.1) you can create a script<br />
/usr/lib/initscripts/legacy-actions/foo/frob<br />
that implements the feature you need.<br />
Obviously the action is only available when calling the service via<br />
<code>/usr/sbin/service</code>, ie<br />
<br />
# service foo frob<br />
or<br />
# rcfoo frob<br />
<br />
[[Category:Systemd]]<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[ja:openSUSE:Systemd パッケージングガイドライン]]<br />
[[ru:openSUSE:Сборка_пакетов_с_поддержкой_systemd]]<br />
[[zh:openSUSE:Systemd_packaging_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_Patches_guidelines&diff=127746openSUSE:Packaging Patches guidelines2018-07-16T14:52:05Z<p>Okurz: /* Current set of abbreviations */ Replace "bugzillas" with more generic "issue trackers" as not all are actually bugzilla; Add "trello" as issue tracker as many SUSE teams use trello</p>
<hr />
<div>{{Packaging_docnav}}<br />
{{Intro|Packagers deal with lots of packages, and lots of patches inside those packages. These need to be marked in the .spec files with a well-known format to be able to run automatic tools on them, in order to generate reports, patch counts and other interesting information. They also need to be named consistently.}}<br />
<br />
== Patch life cycle ==<br />
Patches need to be added to packages for various reasons and it is important that the life cycle of a patch is well-defined. This helps in preventing that patches get "lost" and nobody knows why and when it was removed. The life cycle is defined in these simple steps:<br />
* Patch added to the package<br />
* Patch is modified (functional/rebased)<br />
* Patch is disabled (but not deleted)<br />
* Patch removed from the package<br />
<br />
The middle stages of the patch life cycle are optional and not every patch will live through them.<br />
<br />
Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. This is only for the benefit of human readers, so does not need to be in a strict machine-parseable format; here are some examples of the suggested format:<br />
* Add package-awesomeness.patch: Makes package awesome<br />
* Drop package-awesomeness.patch: Upstream made it even more awesome.<br />
* Disable package-awesomeness.patch: Testing if users can live without awesomeness<br />
* Rebase package-awesomeness.patch to apply to the new version.<br />
<br />
== Upstream policy ==<br />
For the purpose of defining the upstream policy, we can divide patches into two categories:<br />
* '''upstream''' - upstream probably will be interested in it<br />
* '''openSUSE/SLE specific''' - upstream won't be interested in it<br />
<br />
=== Policy for upstream patches ===<br />
If you want to add a patch that can be interesting for upstream, please note that this '''patch must always be sent upstream'''. This is the only way to ensure that our fixes will be integrated upstream and we can get rid of these patches within the next upstream release. A significant advantage is also that upstream can provide you with sanity checking and a valuable feedback regarding your patch.<br />
<br />
==== When to send the patch to upstream ====<br />
Usually, it's useful to contact upstream before you submit the patch to OBS. You save yourself from resubmitting the patch if upstream finds an error in it.<br />
Also, some of the package maintainers may request this "upstream first" policy before such patch is to be considered for inclusion in the OBS package. Usually, there should be a mention about "upstream first" policy in the specfile of those packages (e. g. SuSEfirewall).<br />
However, sometimes upstream is not active enough and sending them the patch after you submit it to OBS is the only reasonable way.<br />
<br />
==== How to find upstream ====<br />
You have to dig. A good start is to check 'Url' or 'Source' tags in the specfile and visit the upstream website. Then you have to find a way upstream prefers for sending patches. It could be e. g. mail, mailing list, Bugzilla, git, ...<br />
<br />
=== Policy for openSUSE/SLE specific patches ===<br />
Usually, we try to add patches that can be merged upstream. However, it can happen that our package is different from the upstream and a specific patch is the only solution. Then please note that every openSUSE/SLE specific '''patch should be documented properly''' with a justification why this specific fix is needed.<br />
<br />
== Patch markup (also called "Tagging patches") ==<br />
<br />
To facilitate the use of automatic tools (some day), and to help inform future packagers about the patch nature, the following categories for our patches exist:<br />
<br />
* Fixes: these are normal fixes and are divided into three categories:<br />
** Fixes for openSUSE-specific things, that upstream maintainers will not be interested in.<br />
** Fixes for SLE-specific things, that upstream maintainers will not be interested in and that are not needed in openSUSE.<br />
** Fixes for the upstream sources that should be upstreamed.<br />
* Features: new features added to the packages, also divided into three categories:<br />
** Features for openSUSE-specific things (switching the displaymanager via /etc/sysconfig, for instance) with no interest for upstream maintainers.<br />
** Features for SLE-specific things with no interest for upstream maintainers or openSUSE.<br />
** Features that should be upstreamed. Whenever we write this kind of new feature, it is important to coordinate with upstream maintainers. That way, we can develop something that will be accepted upstream without changes. Once a feature is finished, it is a lot of work to rework it to be acceptable to upstream maintainers. As such, it is better to know from the beginning exactly what upstream maintainers would expect.<br />
<br />
There are two competing standards for this.<br />
<br />
=== Type 1: minimal single-line comment in spec file ===<br />
<br />
The old format consists of a comment line above a Patch: line, containing the patch category (see above), a (redundant) copy of the filename, and the rest of the line is a free-format string. Since a single line does not leave much room for words or other metadata, check out Type&nbsp;2 below.<br />
<br />
Type 1 format example:<br />
<br />
# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch1: fix-for-opensuse-specific-things.patch<br />
# PATCH-FIX-SLE fix-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch2: fix-for-sle-specific-things.patch<br />
# PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch bnc#<VAR >123456</VAR ><br />
Patch3: fix-for-upstream-sources.patch<br />
# PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch4: feature-for-opensuse-specific-things.patch<br />
# PATCH-FEATURE-SLE feature-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch5: feature-for-sle-specific-things.patch<br />
# PATCH-FEATURE-UPSTREAM feature-for-upstream.patch bnc#<VAR >123456</VAR ><br />
Patch6: feature-for-upstream.patch<br />
<br />
Special case: we often have patches that get commented out temporarily because they failed to apply to the latest sources, and the patches need to be rebased. Do not comment out the patch's declaration, but do comment out its application. When marking a patch as needing a rebase, it is a good idea to preserve its old tag.<br />
<br />
# PATCH-NEEDS-REBASE old-patch.patch bnc#<VAR >123456</VAR > -- Does something old. Was: PATCH-FEATURE-OPENSUSE<br />
Patch7: old-patch.patch<br />
[...]<br />
# %patch7<br />
<br />
Finally, we include e-mail addresses so that it will be easier to figure out who wrote a patch if we have questions later, and free-form comments after " -- ".<br />
<br />
That is:<br />
# PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} ''name-of-file.patch'' bnc#<VAR >[0-9]+</VAR > <VAR >you</VAR >@<VAR >example.com</VAR > -- ''this patch makes things totally awesome''<br />
If there are related bugs in [http://bugzilla.novell.com Novell] or other bugzillas, please add them, it will help us to get more accurate information. If there are two or more available then it's preferable to list both (or more).<br />
<br />
In general, the bugzilla field is not required on new patches. For patches to released packages that will go out as updates, a bugzilla entry (BNC#) for the overall update in the changes file is required. If appropriate, the patch description should also include it.<br />
<br />
The primary use case of the patch field should be references to<br />
'''upstream''' bug trackers in case of PATCH-*-UPSTREAM patches, such<br />
patches should be submitted upstream first and then referenced in the<br />
patch tag. That helps a lot to keep track of patches, it makes it easy to<br />
determine which patches are still needed on version updates if<br />
upstream references the bug numbers in their changelog or release<br />
notes. Of course if there is already a corresponding bnc# bug<br />
open it should be referenced as well.<br />
<br />
You can find the current set of abbreviations at the end of this document. We can also define more abbreviations later if and when they prove necessary.<br />
<br />
Some patches fix bugs that are not explicitly recorded anywhere. The right thing to do in this case requires some judgment on the part of the packager, but here are some ideas:<br />
<br />
* If a release is imminent, create a bug for it. This is usually a requirement, and even if it were not, it is still the right thing to do.<br />
* If a release is a long way off and the bug has already been fixed upstream, note in the comment that it is already fixed in the <ABBR >SVN</ABBR > (or wherever) and the patch will go away when we next upgrade.<br />
<br />
=== Type 2: Complete Information provided in patch ===<br />
<br />
The Type 1 standard lacks the most important part of a patch: a useful description why it is needed or desired in the first place, its single line format is seldomly enough to convey all the desirable information, and the state of the patch (upstream or opensuse-specific, fix or feature, etc.) is cut off from the actual patch.<br />
<br />
The patches in the openSUSE kernel packages have traditionally used a form of tagging where metadata is directly attached to where it is needed — in the patch file itself. This facilitates submission of patches to upstream, as the description cannot be accidentally omitted, and the Git SCM (where used) knows to retain the metadata on import. Conversely, extraction of patches from Git repos also yields single files.<br />
<br />
Patch files are to follow a scheme of "<tt>key: value</tt>" pairs and a description, optionally with a diffstat, prepended to the actual hunks. Example.<br />
<br />
From: Random J Developer <email@example.org><br />
Date: 2012-07-28 01:28:22 +0200<br />
Subject: input: add Acer Aspire 5710 to nomux blacklist<br />
References: bnc#404881<br />
Upstream: submitted<br />
<br />
Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad misbehaves.<br />
<br />
---<br />
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++<br />
1 file changed, 7 insertions(+)<br />
<br />
--- a/drivers/input/serio/i8042-x86ia64io.h<br />
+++ b/drivers/input/serio/i8042-x86ia64io.h<br />
@@ -371,6 +371,13 @@ static const struct dmi_system_id __init<br />
[...]<br />
<br />
It is advised to use e.g. Quilt which retains descriptions on refresh. `<tt>quilt ref --sort --diffstat -p1</tt>` creates/refreshes such patches, sorted, with a diffstat and in the wanted -p1 format.<br/><br />
Common fields encountered:<br />
<br />
* '''From:''' shall specify the e-mail address of the original author of the patch.<br />
* '''Date:''' when this patch was first created. Preferably an ISO-8601 timestamp with timezone. If a new patch was just created and has none, you can use `<tt>stat your.patch</tt>` to determine a timestamp.<br />
* '''References:''' links to mailing list posts, bugzillas, etc. No fixed format, though URLs are preferred for they are easy to copy&paste into the browser. See the below section “[[#Current set of abbreviations]]” for details.<br />
* '''Upstream:''' the disposition of the patch. No fixed format, though common options are “never”/“no” (openSUSE-specific), “to be done” (tbd), “sent”/“submitted” (sent to upstream developers; provide Reference if possible), “merged” (upstream has accepted it; provide Reference if possible) and “dead” (no activity in upstream project).<br />
* '''Subject:''' A short one-line summary of the patch.<br />
<br />
'''Patches are to provide a description.''' The description shall describe _why_ it is needed. Be as thorough as you like, because it will influence the decision what a different developer should do with the patch should it not apply anymore. The three questions “what command did you execute?”, “what did you observe?”, “what did you expect to see instead?” can give some guidance. If a related error message is available, e.g. when creating a patch to fix a syntactical error in a source file that causes the compilation to abort, it should be included, trimmed to the important parts. Furthermore, a summary on the how the solution is implemented can help readers grok larger patches.<br />
<br />
Reading material (from the mailing lists) that shows the need for this kind of tagging: [http://lists.opensuse.org/opensuse-factory/2012-08/msg00683.html (1)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00719.html (2)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00749.html (3)]<br />
<br />
== Patch naming ==<br />
<br />
All new patches should end with the extension '.patch'.<br />
<br />
Whether a patch's name should start with the name of the package it applies to is a matter of debate or style. When in doubt, follow the convention used in the package you are hacking on.<br />
<br />
Do '''NOT''' use <code>%{version}</code> macro in <code>Patch:</code> line, specify the version by hand. Using the macro:<br />
* causes lots of renames on version update<br />
* makes it easy to overlook patches that are no longer needed<br />
* makes it hard to determine when the patch was touch for the last time<br />
* makes it easy to find out when the patch broke (package archaelogy)<br />
<br />
An exception to this exists: patches that fix warnings that the compiler emits due to bogus code are frequently named <tt>abuild.patch</tt>.<br />
<br />
The preferred patchlevel is <tt>-p1</tt> as it makes importing using tools like ''quilt'' more straightforward.<br />
<br />
----<br />
== Current set of abbreviations ==<br />
To avoid confusion and double burden, referencing to other issue trackers is allowed. Here are some shortcuts for often used issue trackers, which should be added before the "#" of the issue id. Note there is no whitespace between the shortcut and the issue id.<br />
<br />
NOTE: this list is not authoritative, please check with the Open Build Service how they are defined there (osc api /issue_trackers). You can also request new trackers via the [https://github.com/openSUSE/open-build-service OBS github project].<br />
<br />
{| border="1" <br />
!Shortcut<br />
!Issue-Tracker-URL<br />
!Example<br />
|-<br />
| '''openSUSE Bug tracker'''<br />
| http://bugzilla.opensuse.org/show_bug.cgi?id=123456<br />
| (boo#123456)<br />
|-<br />
| AbiWord<br />
| https://bugzilla.abisource.com<br />
| (bac#123456)<br />
|-<br />
| Apache Software Foundation (obsolete)<br />
| https://issues.apache.org/bugzilla/<br />
| (pr#37770)<br />
|-<br />
| Apache Software Foundation Bugzilla<br />
| https://bz.apache.org/bugzilla/<br />
| (bao#12345)<br />
|-<br />
| Apache Software Foundation Jira<br />
| https://issues.apache.org/jira/issues/<br />
| (jira#12345)<br />
|-<br />
| Apache OpenOffice<br />
| https://bz.apache.org/ooo/<br />
| (aoo#1234)<br />
|-<br />
| Apache SpamAssassin<br />
| https://bz.apache.org/SpamAssassin/<br />
| (asa#12345)<br />
|-<br />
| Boost<br />
| https://svn.boost.org/trac/boost/report<br />
| (boost#123456)<br />
|-<br />
| Ceph bug tracker<br />
| http://tracker.ceph.com/<br />
| (ceph#123456)<br />
|-<br />
| Claws Mail<br />
| http://www.thewildbeast.co.uk/claws-mail/bugzilla/<br />
| (claws#123456)<br />
|-<br />
| CVE entries (please add the number, even if there is an additional bugzilla for it)<br />
| http://cve.mitre.org<br />
| (CVE-2009-0067)<br />
|-<br />
| CPAN Public Bug Tracker<br />
| http://rt.cpan.org/Public/<br />
| (RT#123456)<br />
|-<br />
| Debian<br />
| http://bugs.debian.org/<br />
| (deb#123456)<br />
|-<br />
| Enlightenment<br />
| https://phab.enlightenment.org<br />
| (e#1234)<br />
|-<br />
| Exim<br />
| http://bugs.exim.org/<br />
| (beo#1234)<br />
|-<br />
| Fate (Feature tracking tool)<br />
| https://features.opensuse.org/<br />
| (fate#123456)<br />
|-<br />
| freedesktop.org<br />
| http://bugs.freedesktop.org/<br />
| (fdo#123456)<br />
|-<br />
| GCC<br />
| http://gcc.gnu.org/bugzilla/<br />
| (GCC#123456)<br />
|-<br />
| GitHub<br />
| https://github.com/<br />
| ([https://github.com/yast/yast-core/issues/42 gh#yast/yast-core#42])<br />
|-<br />
| GitLab<br />
| https://gitlab.com<br />
| ([https://gitlab.com/gitlab-org/gitlab-ce/issues/43675 gl#gitlab-org/gitlab-ce#43675])<br />
|-<br />
| GNOME<br />
| http://bugzilla.gnome.org/<br />
| (bgo#123456)<br />
|-<br />
|GNOME GitLab<br />
| https://gitlab.gnome.org<br />
| ([https://gitlab.gnome.org/GNOME/nautilus/issues/79 glgo#GNOME/natilus#79])<br />
|-<br />
| Graphviz<br />
| http://graphviz.org/mantisbt/view_all_bug_page.php<br />
| (gvz#123456)<br />
|-<br />
| ICCULUS<br />
| http://bugzilla.icculus.org/<br />
| (bio#123456)<br />
|-<br />
| Jenkins CI<br />
| https://issues.jenkins-ci.org<br />
| (jenk#123456)<br />
|-<br />
| KDE <br />
| http://bugs.kde.org/<br />
| (kde#123456)<br />
|-<br />
| Kernel or K<br />
| http://bugzilla.kernel.org/<br />
| (bko#123456)<br />
|-<br />
| Launchpad (Ubuntu)<br />
| https://bugs.launchpad.net/<br />
| (lp#123456)<br />
|-<br />
| LibreOffice<br />
| https://bugs.documentfoundation.org/describecomponents.cgi<br />
| (bdo#123456)<br />
|-<br />
| Linux Foundation<br />
| https://developerbugs.linux-foundation.org/<br />
| (lf#1234)<br />
|-<br />
| MeeGo<br />
| http://bugs.meego.com<br />
| (MeeGo#123456)<br />
|-<br />
| Mozilla<br />
| http://bugzilla.mozilla.org/<br />
| (bmo#123456)<br />
|-<br />
| Novell<br />
| https://bugzilla.novell.com/<br />
| (bnc#123456)<br />
|-<br />
| SUSE<br />
| https://bugzilla.suse.com/<br />
| (bsc#123456)<br />
|-<br />
| OpenLDAP<br />
| http://www.openldap.org/its/<br />
| (ITS#123456)<br />
|-<br />
| OpenOffice.org Issuezilla (obsolete)<br />
| http://qa.openoffice.org/issues/<br />
| (i#123456)<br />
|-<br />
| OpenOffice.org Novell (obsolete)<br />
| https://bugzilla.novell.com/<br />
| (n#123456)<br />
|-<br />
| openSUSE-Education<br />
| http://devzilla.novell.com/education/<br />
| (os-edu#123456)<br />
|-<br />
| Pidgin<br />
| https://developer.pidgin.im/ticket/12345<br />
| (pidgin.im#12345)<br />
|-<br />
| RedHat<br />
| https://bugzilla.redhat.com/<br />
| (rh#123456)<br />
|-<br />
| Samba<br />
| https://bugzilla.samba.org/<br />
| (bso#123456)<br />
|-<br />
| Sourceforge<br />
| http://sf.net/support/tracker.php?aid=1234567<br />
| (sf#1234567); number is in the "aid=" part in an URL<br />
|-<br />
| SourceWare<br />
| http://sourceware.org/bugzilla/<br />
| (swo#1234567)<br />
|-<br />
| Typo3<br />
| http://forge.typo3.org/<br />
| (t3#1234567)<br />
|-<br />
| WebKit<br />
| https://bugs.webkit.org/<br />
| (webkit#123456)<br />
|-<br />
| Xfce<br />
| https://bugzilla.xfce.org/<br />
| (bxo#123456)<br />
|-<br />
| Xamarin<br />
| http://bugzilla.xamarin.com/<br />
| (bxc#4321)<br />
|-<br />
| trello<br />
| https://trello.com/c/OMdsDiAE<br />
| (tr#OMdsDiAE)<br />
|}<br />
<br />
For other issue ids, please use the full URL to the coresponding issue tracker at the beginning of the patch file. For example:<br />
* http://developer.berlios.de/bugs/?func=detailbug&bug_id=12707&group_id=769<br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Paketbau Richtlinien für Patches]]<br />
[[el:openSUSE:Packaging Patches guidelines]]<br />
[[ja:openSUSE:パッケージング修正ガイドライン]]<br />
[[ru:openSUSE:Руководство по оформлению патчей]]<br />
[[zh:openSUSE:Packaging_Patches_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=Features_15.0&diff=125488Features 15.02018-05-14T16:28:13Z<p>Okurz: /* What else is new */ Added matrix.org synapse serve</p>
<hr />
<div>{{Current_distribution_navbar|15.0}}<br />
<div style="text-align:justify;float:left;"><br />
<br />
==openSUSE 15.0 – Leap==<br />
<gallery><br />
<br />
</gallery><br />
<br />
The following pages go into much detail on what is new in this openSUSE release. Too much information? Check out the [[Portal:15.0/Features|Feature highlights]] instead.<br />
<br />
__TOC__<br />
<br />
== Base operating system ==<br />
<br />
=== Linux kernel ===<br />
<br />
Leap 15 ships with Linux 4.12. A prominent feature list and intricate details can be found [https://kernelnewbies.org/Linux_4.12 on kernelnewbies.org].<br />
<br />
==== Networking ====<br />
<br />
==== Security ====<br />
<br />
===== OpenSSL =====<br />
OpenSSL was updated to [1.1.0](https://www.openssl.org/news/openssl-1.1.0-notes.html):<br />
<br />
* Support for ChaCha20 and Poly1305<br />
* Support for extended master secret<br />
* CCM ciphersuites<br />
* SSLv2 support removed<br />
* Kerberos ciphersuite support removed<br />
* RC4 removed from DEFAULT ciphersuites in libssl<br />
* 40 and 56 bit cipher support removed from libssl<br />
* Support for OCB mode added to libcrypto<br />
* Support for RFC6698/RFC7671 DANE TLSA peer authentication<br />
* New security levels<br />
* Support for scrypt algorithm<br />
* Support for X25519<br />
* KDF algorithm support. Implement TLS PRF as a KDF.<br />
* Support for Certificate Transparency<br />
* HKDF support.<br />
<br />
==== Hardware Support ====<br />
<br />
==== More ====<br />
<br />
=== systemd ===<br />
Leap 15 has systemd version 234.<br />
<br />
Support for dynamically creating users for the lifetime of a service has been added. If DynamicUser=yes is specified, user and group IDs will be allocated from the range 61184..65519 for the lifetime of the service. They can be resolved using the new nss-systemd.so NSS module. The module must be enabled in /etc/nsswitch.conf. Services started in this way have PrivateTmp= and RemoveIPC= enabled, so that any resources allocated by the service will be cleaned up when the service exits. They also have ProtectHome=read-only and ProtectSystem=strict enabled, so they are not able to make any permanent modifications to the system.<br />
<br />
MemoryLimit= and related unit settings now optionally take percentage specifications. The percentage is taken relative to the amount of physical memory in the system (or in case of containers, the assigned amount of memory). This allows scaling service resources neatly with the amount of RAM available on the system. Similarly, systemd-logind's RuntimeDirectorySize= option now also optionally takes percentage values.<br />
<br />
In similar fashion TasksMax= takes percentage values now, too. The value is taken relative to the configured maximum number of processes on the system. The per-service task maximum has been changed to 15% using this functionality. (Effectively this is an increase of 512 → 4915 for service units, given the kernel's default pid_max setting.)<br />
<br />
The SystemCallFilter= unit file setting gained support for pre-defined, named system call filter sets. For example SystemCallFilter=@clock is now an effective way to make all clock changing-related system calls unavailable to a service. A number of similar pre-defined groups are defined. Writing system call filters for system services is simplified substantially with this new concept. Accordingly, all of systemd's own, long-running services now enable system call filtering based on this, by default.<br />
<br />
A new service setting MemoryDenyWriteExecute= has been added, taking a boolean value. If turned on, a service may no longer create memory mappings that are writable and executable at the same time. This enhances security for services where this is enabled as it becomes harder to dynamically write and then execute memory in exploited service processes. This option has been enabled for all of systemd's own long-running services.<br />
<br />
The unified cgroup hierarchy added in Linux 4.5 is now supported. Use systemd.unified_cgroup_hierarchy=1 on the kernel command line to enable. Also, support for the "io" cgroup controller in the unified hierarchy has been added, so that the "memory", "pids" and "io" are now the controllers that are supported on the unified hierarchy.<br />
<br />
A new command "systemctl revert" has been added that may be used to revert to the vendor version of a unit file, in case local changes have been made by adding drop-ins or overriding the unit file.<br />
<br />
=== PHP 7 ===<br />
[https://software.opensuse.org/package/php7 PHP7] is a server-side HTML embedded scripting language designed primarily for web development but also used as a general-purpose programming language. This package contains the standard implementation of PHP, namely Zend PHP. Included are the PHP command-line binary and the configuration file (php.ini). This package must be installed in order to use PHP. Additionally, extension modules and server modules (e.g. for Apache) may be installed. Additional documentation is available in package php-doc.<br />
<br />
=== Printing System ===<br />
<br />
== Office and Groupware ==<br />
<br />
=== Libreoffice ===<br />
[https://software.opensuse.org/package/libreoffice LibreOffice] is a free and open source office suite, a project of The Document Foundation. LibreOffice is a comprehensive office package featuring a word processor, a spreadsheet, a presentation program, and much more. This package provides only the basic framework. You have to install the additional modules to get the required functionality, see packages: - libreoffice-base - libreoffice-calc - libreoffice-draw - libreoffice-impress - libreoffice-math - libreoffice-writer Some optional features are provided by extra packages, for example: - libreoffice-mailmerge - libreoffice-filters - libreoffice-kde4 - libreoffice-gnome Non-English localizations are provided by extra packages as well, for example: - libreoffice-l10n-de - libreoffice-l10n-fr - libreoffice-l10n-it<br />
<br />
==== Writer ==== <br />
Various<br />
* Direct cursor: Add option to insert only spaces tdf#108427 (Samuel Mehrbrodt, CIB)<br />
* Find toolbar: Add drop down list to change search type tdf#79167 (Jim Raykowski)<br />
* The main menu (top level) now has an entry “Form” tdf#91781 (Yousuf Philips)<br />
* Page dialog: page orientation automatically adjusts based on manual input tdf#106890 (Heiko Tietze)<br />
* Default column spacing (aka gutter) changed to 0.5cm tdf#67670 (Heiko Tietze)<br />
* Support for split sections inside tables blog entry (Miklós Vajna, Collabora)<br />
* New set of default numbering list styles tdf#106988 (Yousuf Philips)<br />
<br />
Input fields<br />
* Improved input field behavior tdf#79877 (Bernhard Widl, CIB)<br />
* double click on input field brings up old input fields dialog<br />
* that dialog now starts at current field and has previous/next navigation<br />
<br />
Images rotation<br />
<br />
* Implement rotation of images in Writer to any angle tdf#73797 (Armin Le Grand, CIB)<br />
* This long requested feature (there are 20 year old reports) could now be implemented. It supports rotating Writer FlyFrames (e.g. inserted Graphics) freely around their center. UI elements to support this were added in various places (Dialog, Sidebar). Direct setting of rotation is extended to allow simple reset ('Reset Rotation'). A 'rotate' interactive mode was added to allow the same interactions as when Draw-Objects are selected. The interactive Cropping was adapted to work with rotated graphics (WYSIWIG). When a frame is used, it gets 'expanded' to the bounding rectangle of the rotated graphic (a feature to allow rotating with the Object is planned for the future). The text can wrap around a rotated Image using the existing 'Contour' feature ('Edit Contour') adding a whole rectangle covering the Image using the Contour-Editor (a single action, e.g. a Button, to do this in one step may be implemented to make this more accessible to the user). The following picture shows examples of this feature in action.<br />
<br />
Mail Merge<br />
* Writer document as mail merge data source (Miklós Vajna, Collabora)<br />
* Mail Merge now can use XLSX files as data source tdf#98168 (Miklós Vajna, Collabora)<br />
* Temporary connections created during mail merge are no longer stored tdf#108572 (Szymon Kłos, Collabora)<br />
<br />
Tables<br />
* New default table style tdf#107554 (Yousuf Philips)<br />
* Default table style applied to inserted tables tdf#107555 (Jim Raykowski)<br />
* Default table border width changed to 0.5pt tdf#99027 (Yousuf Philips)<br />
* Old collection of autoformat table styles were replaced with a new collection of table styles: Default, Academic, Box List Blue, Box List Green, Box List Red, Box List Yellow, Elegant, Financial, Simple Grid Columns, Simple Grid Rows, Simple List Shaded tdf#101349 (Andreas Kainz, Eike Rathke, Heiko Tietze, Yousuf Philips)<br />
<br />
“Grammar By” spell checking<br />
<br />
User dictionaries allow automatic affixation or compounding, supporting effective editing and technical dictionary creation in several languages. tdf#113739 (László Németh)<br />
<br />
This is a general spell checking improvement of LibreOffice, but it can speed up especially the work of Writer users. Instead of manual handling of hundreds of correct word forms of a new word in a language with rich morphology or compounding, Hunspell spell checker will recognize the new user dictionary word with affixes or in compounds, too, based on a “Grammar By” model word. Screencasts about the usage: English, German.<br />
<br />
For (a simplified English) example, on the following screen shot of the “Edit custom dictionary” window, the word “crowdfund” is the new word (missing from the American English dictionary), and “fund” is the model word in the new “Grammar By” field (this more common word is part of the Hunspell spell checking dictionary). This way, the new word “crowdfund” will be recognized with suffixes of the word “fund” automatically, too: crowdfund’s, crowdfunds, crowdfunder, crowdfunders and crowdfunding.<br />
<br />
With “Grammar By” spell checking, it will be possible to create and handle technical dictionaries more easily, using existing user interface of custom dictionaries to switch on/off them, for example, medical, technological or other scientific dictionaries shipped with LibreOffice.<br />
<br />
Note: this feature works only in language-dependent user dictionaries, so it needs to create one or modify the language of an existing one.<br />
<br />
==== Calc ==== <br />
Various<br />
* Pivot table interop fixes (Mike Kaganski (Collabora), Tamás Zolnai (Collabora), Bartosz Kosiorek)<br />
* Default 2-entry color scale conditional formatting colors changed to Yellow and Green. tdf#86508 (Yousuf Philips)<br />
* Enhanced "Links" dialog tdf#113807 (Serge Krot, CIB)<br />
* Number format: accept English syntax keywords; some languages use localized keywords (AAAA for YYYY in French for instance). Now these languages can use English keywords to get valid format in any UI language tdf#33689 (Laurent Balland-Poirier)<br />
* The main menu (top level) now has an entry “Styles” tdf#91820 (Yousuf Philips)<br />
<br />
Exporting images<br />
* A cell range selection or a selected group of shapes (images) can be exported to PNG or JPG graphics format with File ▸ Export... if the Selection checkbox is marked in the file dialog. tdf#108317 (Eike Rathke (Red Hat, Inc.))<br />
<br />
Pasting: unformatted text<br />
* The text/plain Unformatted text format results in unquoted/unescaped content as expected for external pastes. For single cell copy&paste embedded line breaks and tabs are preserved, for multiple cells they are replaced with spaces, effectively being a tab-separated-values (TSV) format. For intra-Calc on-cell pastes using the paste special toolbar button the Unformatted text [TSV-Calc] format can be used, which preserves embedded line breaks and tabs across multiple cells. tdf#113571 tdf#32213 (Eike Rathke (Red Hat, Inc.))<br />
* Added "Paste unformatted text" command with its hot key Ctrl+⇧ Shift+Alt+V tdf#50746 (Serge Krot, CIB)<br />
<br />
Protection, cells, sheets<br />
* Added new command to select unprotected cells on protected or unprotected sheet. Located Edit ▸ Select ▸ Select Unprotected Cells. tdf#95883 (Gülşah Köse, Eike Rathke)<br />
* If a tab is protected, the lock symbol (🔒︎) appears at the beginning of the tab name. tdf#95880 (Gülşah Köse, Eike Rathke)<br />
New spreadsheet functions<br />
<br />
* New ODFF1.2 compliant functions SEARCHB, FINDB and REPLACEB added (commit1, commit2, commit3). (Winfried Donkers)<br />
* FINDB returns the starting position of a given text, using byte positions. FINDB is case sensitive.<br />
* SEARCHB returns the starting position of a given text, using byte positions.<br />
* REPLACEB returns text where an old text is replaced with a new text, using byte positions.<br />
<br />
==== Impress and Draw ====<br />
<br />
Various<br />
* Addition of 10 new Impress templates and improvement of two existing templates tdf#103317 (Ashisuto, Yousuf Philips, Heiko Tietze, Laurent BP)<br />
* Removal of confirmation dialog when setting image as slide or page background (preferably make use of Slide masters to set for more/all slides) tdf#112650 (Heiko Tietze, Samuel Mehrbrodt)<br />
* Set default slide format 16:9 tdf#93244 (Heiko Tietze)<br />
* Duplicate dialog ⇧ Shift+F3:<br />
* Offer more possibilities for placement and enlargement tdf#61561 (Laurent BP)<br />
* Enable negative angle commit (Laurent BP)<br />
<br />
Layers in Draw<br />
Better UI for handling layer attributes tdf#89130 (Ulrich Gemkow):<br />
* ⇧ Shift+click: toggle visible/hidden layer, with name in blue (like in previous versions)<br />
* Ctrl+click: lock/unlock layer with italic name<br />
* Ctrl+⇧ Shift+click: printable/not printable layer with underline name<br />
<br />
New UI behavior for tabs attributes in Draw<br />
<br />
=== ThunderBird ===<br />
[https://software.opensuse.org/package/MozillaThunderbird Mozilla Thunderbird] is a redesign of the Mozilla Mail component. It is written using the XUL user interface language and designed to be cross-platform. It is a stand-alone application instead of part of the Mozilla application suite.<br />
<br />
=== Kopano ===<br />
[https://software.opensuse.org/package/kopano Kopano] provides email storage on the server side and brings its own Ajax-based mail client called WebAccess. Kopano is designed to integrate with Kopano WebApp, Push clients and other mail services as an alternative to Microsoft Exchange and other comparable mail servers. Personal address book, calendar, notes and tasks, "Public Folders" and shared calendar functionalities (inviting internal and external users, resource management) can be handled by the software as well.<br />
<br />
== Browsers and Web Search ==<br />
<br />
=== Chromium ===<br />
[https://software.opensuse.org/package/chromium Chromium] is the open-source project behind Google Chrome. Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.<br />
<br />
=== Firefox ===<br />
Mozilla firefox - the OFFICIAL Mozilla Firefox build for Linux adapted to RPM package with weekly updates. Firefox is created by a global non-profit dedicated to putting individuals in control online. <br />
<br />
=== Surfraw ===<br />
[https://software.opensuse.org/package/surfraw?search_term=Surfraw Surfraw] allows the user to launch Web search directly in terminal emulators with several different Web engines (called elvis in surfraw). For instance: ''surfraw duckduckgo opensuse'' will open a duckduckgo search page for the "opensuse" key word in the default web browser (defined in $BROWSER env var).<br />
<br />
== Desktop Environments ==<br />
<br />
=== Enlightenment ===<br />
Enlightenment window manager and desktop environment is really fast, configurable and beautiful. This package will provide the latest released version of enlightenment, as opposed to e16 or e17.<br />
<br />
==== Changes ====<br />
Enlightenment 0.22.3 is a bugfix and stability release for the Enlightenment 22 Release series.<br />
<br />
Carsten Haitzler (5):<br />
* fix autofoo build to match e auth patch backport<br />
* desklock - make it fail to lock on non-bsd platforms if no pam support<br />
* e desklock pam error - go back to previous text<br />
* move from data_home/apps/defaults.list to config_home/mimeapps.list<br />
* build - make pam a requirement on non-bsd unless disabled<br />
<br />
Derek Foreman (1):<br />
* Revert no-longer required pulseaudio hack for wayland<br />
<br />
=== GNOME ===<br />
<br />
<br />
==== GNOME Applications ====<br />
<br />
<br />
<br />
=====Other Little Improvements=====<br />
<br />
<br />
==== GNOME Infrastructure / internals ====<br />
<br />
<br />
<br />
=== KDE Plasma ===<br />
<br />
<br />
==== Frameworks ====<br />
<br />
<br />
=== LXQt ===<br />
<br />
<br />
=== GNU Health ===<br />
<br />
<br />
==== New ====<br />
<br />
<br />
==== New Modules ====<br />
<br />
<br />
== openSUSE technologies==<br />
<br />
=== AutoYaST ===<br />
<br />
<br />
<br />
=== Snapper ===<br />
<br />
<br />
=== YaST ===<br />
<br />
<br />
<br />
== Scientific and Educational Apps ==<br />
<br />
<br />
== Security ==<br />
<br />
<br />
=== apparmor ===<br />
<br />
<br />
=== Lynis ===<br />
<br />
<br />
=== yast2-security ===<br />
<br />
=== dehydrated / letsencrypt ===<br />
<br />
Dehydrated is a client for letsencrypt. The SUSE integration provides templates for Apache, nginx and lighttpd. It also supports DNS-based issuance including support for wildcard certificates.<br />
<br />
== Tools ==<br />
<br />
=== CMake ===<br />
<br />
==== GUI ====<br />
<br />
==== Command-Line ====<br />
<br />
==== Commands ====<br />
<br />
==== Variables ====<br />
<br />
<br />
==== Modules ====<br />
<br />
<br />
==== Platforms ====<br />
<br />
<br />
=== nodejs ===<br />
<br />
<br />
=== Qt ===<br />
<br />
<br />
<br />
=== GNU Compiler Collection ===<br />
<br />
GCC has been bumped to version 7, bringing support for [https://en.wikipedia.org/wiki/C++17 C++17] to Leap. Intricate details may be found [https://gcc.gnu.org/gcc-7/changes.html at gcc.gnu.org].<br />
<br />
=== Ruby ===<br />
<br />
== What else is new ==<br />
<br />
=== OpenStack clients updated ===<br />
The OpenStack clients got updated to the versions from the [https://releases.openstack.org/queens/index.html#service-client-projects OpenStack Queens] release.<br />
<br />
=== matrix.org synapse server added ===<br />
Matrix.org’s reference server – [https://matrix.org/docs/projects/server/synapse.html Synapse] is included<br />
<br />
[[Category:15.0]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Specfile_guidelines&diff=124420openSUSE:Specfile guidelines2018-03-28T20:21:37Z<p>Okurz: Add backward compatible description for License files</p>
<hr />
<div>{{Packaging_docnav}}<br />
{{Intro|RPM itself places very few limitations on what you can do in spec files, so they can quickly become difficult to read and maintain. These guidelines try to minimize the variations in specific areas so spec files are maintainable.}}<br />
<br />
==General Rules==<br />
All spec files must be comprehensible. If other packagers are unable to read the spec file, it will be impossible to perform a review and to collaborate on the package.<br />
<br />
===Specfile Template===<br />
When writing a package from scratch, you should base your spec file on the spec file template (see [http://software.opensuse.org/search?q=rpmdevtools rpmdevtools]). A basic setup for a package MYPACK can be generated by<br />
<br />
{{Shell|1=[https://build.opensuse.org/package/show?package=osc-plugin-install&project=openSUSE%3ATools osc-plugin-install] devel:tools rpmdevtools}}<br />
<br />
or (change URL according to your version of openSUSE)<br />
<br />
{{Shell|sudo zypper -p obs://devel:tools/openSUSE_Leap_42.2 -v in osc rpmdevtools}}<br />
<br />
Once you have done so:<br />
<br />
# A folder already created for a project, like home:user.<br />
cd MYPROJECT<br />
# Create a new package.<br />
osc mkpac MYPACK<br />
cd MYPACK<br />
# Download source tarball from upstream (the group that develops the code).<br />
wget http://upstream.example.org/source/.../MYPACK-1.0.tar.gz<br/><br />
# Create a spec file template for MYPACK.<br />
rpmdev-newspec -t lib MYPACK<br />
# Record changes to the MYPACK package.<br />
osc vc<br />
# Edit spec file.<br />
vim MYPACK.spec<br />
<br />
and then later:<br />
<br />
# Test it builds correctly<br />
osc build<br />
# Checkin/commit to OBS server<br />
osc ci<br />
<br />
'''Please try to conform to this template as much as possible.'''<br />
<br />
It is not the only way to write a spec file, but doing so makes it easier for QA to spot mistakes and quickly understand what you are trying to do. <br />
<br />
Spec files for specific languages can often be created with specialized tools like <code>cpanspec</code> or <code>gem2rpm-opensuse</code>. See also<br />
<br />
* [[openSUSE:Packaging_Perl]]<br />
* [[openSUSE:Packaging_Python]]<br />
* [[openSUSE:Packaging_Ruby]]<br />
<br />
===Specfile Encoding===<br />
'''Use ASCII characters unless necessary (if so, save as UTF-8).'''<br />
<br />
Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you are in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png an ASCII chart].<br />
<br />
===Specfile Licensing===<br />
'''For legal reasons, spec files must have a license header.'''<br />
<br />
Use the following template:<br />
<br />
#<br />
# spec file for package $YOUR_PACKAGE<br />
#<br />
# Copyright (c) $CURRENT_YEAR $YOUR_NAME_WITH_MAIL_ADDRESS<br />
#<br />
# All modifications and additions to the file contributed by third parties<br />
# remain the property of their copyright owners, unless otherwise agreed<br />
# upon. The license for this file, and modifications and additions to the<br />
# file, is the same license as for the pristine package itself (unless the<br />
# license for the pristine package is not an Open Source License, in which<br />
# case the license is the MIT License). An "Open Source License" is a<br />
# license that conforms to the Open Source Definition (Version 1.9)<br />
# published by the Open Source Initiative.<br />
<br />
# Please submit bugfixes or comments via http://bugs.opensuse.org/<br />
#<br />
<br />
If there is no such header yet, you can run <tt>osc service format_spec_file</tt> to have one added automatically for you.<br />
<br />
===Macros===<br />
'''Use macros instead of hard-coded directory names.'''<br />
<br />
A list of macros and what they do is available at [[openSUSE:Packaging Conventions RPM Macros]]. Having macros in a <code>Source:</code> or <code>Patch:</code> line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual <code>Source:</code> value, you can run:<br />
<br />
{{Shell|rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"}}<br />
<br />
Caution: the above command works with <code>%{name}</code> and <code>%{version}</code>, but may fail with user defined macros.<br />
<br />
====Macros vs RPM variables====<br />
rpm re-exports a few of its macros as shell variables implicitly at the start of <tt>%prep</tt>, <tt>%build</tt> and <tt>%install</tt>. Excerpt from <tt>/usr/lib/rpm/macros</tt>:<br />
<br />
<pre><br />
%___build_pre \<br />
RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\<br />
RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\<br />
RPM_OPT_FLAGS=\"%{optflags}\"\<br />
RPM_ARCH=\"%{_arch}\"\<br />
RPM_OS=\"%{_os}\"\<br />
RPM_DOC_DIR=\"%{_docdir}\"\<br />
RPM_PACKAGE_NAME=\"%{name}\"\<br />
RPM_PACKAGE_VERSION=\"%{version}\"\<br />
RPM_PACKAGE_RELEASE=\"%{release}\"\<br />
LANG=C\<br />
unset CDPATH DISPLAY ||:\<br />
%{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\<br />
%{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\<br />
PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\<br />
</pre><br />
<br />
It is technically possible to use either; they will resolve to the same values in all (sensible) scenarios. However, not all macros, such as <tt>%_bindir</tt>, are mapped to a shell variable. Do not mix the two styles in openSUSE packages, as it is bad from a QA and usability point of view.<br />
<br />
RPM macros are expanded before a section is run, and it is slower for variables to be read by sh during runtime.<br />
<br />
====Macros vs shell commands====<br />
For many commonly used shell commands, there is a macro equivalent. For example (excerpt from <tt>/usr/lib/rpm/macros</tt>),<br />
<br />
<pre><br />
%__cat /usr/bin/cat<br />
%__chgrp /usr/bin/chgrp<br />
%__chmod /usr/bin/chmod<br />
%__chown /usr/bin/chown<br />
…<br />
</pre><br />
<br />
These macros provide a better portability for the purpose of non-GNU platforms such as Solaris or FreeBSD where the GNU utilities may have names like <tt>gchgrp</tt> instead of <tt>chgrp</tt>. Since environments other than GNU/Linux are not the target of the openSUSE project at present, the use of such macros is most discouraged in favor of plain shell commands. The spec file cleaner bot even converts macros to their shell command counter part [https://github.com/openSUSE/spec-cleaner/blob/master/spec_cleaner/rpmsection.py automatically].<br />
<br />
==== Conditionals ====<br />
<br />
See [[openSUSE:RPM conditional builds]].<br />
<br />
For a list of version macros for different openSUSE releases, see [[openSUSE:How_to_contribute_to_Leap#RPM_Distro_Version_Macros|openSUSE RPM distro version macros]].<br />
<br />
For example, to detect Leap 42.1:<br />
<br />
%if 0%{?sle_version} == 120100 && 0%{?is_opensuse}<br />
# perform Leap 42.1 specific actions here<br />
%else<br />
# something else<br />
%endif<br />
<br />
For other distributions, see [[openSUSE:Build_Service_cross_distribution_howto]].<br />
<br />
== Preamble ==<br />
===Naming / versioning ===<br />
See [[openSUSE:Package naming guidelines]].<br />
<br />
===Metadata Tags===<br />
* ''AutoReqProv'': should not be used '''unless''' you want to turn off automatic dependency processing.<br />
* ''Source'': an HTTP link should be specified where possible ([[openSUSE:Package source verification]]).<br />
* ''Group'': only package groups listed in the [[openSUSE:Package group guidelines|package group guidelines]] should be used.<br />
* ''BuildRoot'': should always be used, even if newer versions of RPM override it anyway. The preferred path is <code class="filename">%{_tmppath}/%{name}-%{version}-build</code>.<br />
* ''Summary'': should be a short description of what the package is ([[openSUSE:Package_description_guidelines#Summary|summary guidelines]]).<br />
<br />
'''Do not use the following tags:'''<br />
* ''Copyright'': deprecated, use ''License'' instead ([[openSUSE:Packaging_guidelines#Licensing|licensing guidelines]]).<br />
* ''Packager'': rebuilding the RPM package elsewhere forces this value onto the new packager, leading to subsequent confusion about who to contact. The identities of the packagers should be specified with changelog entries instead.<br />
* ''Vendor'': same reason as for ''Packager''. If you want to override the default set by the openSUSE Build Service, use a prjconf-level <code>%define</code>.<br />
<br />
===Description Section(%description)===<br />
See [[openSUSE:Package description guidelines]].<br />
<br />
===Dependencies===<br />
See [[openSUSE:Package dependencies]].<br />
<br />
=== Patches ===<br />
All patches in openSUSE spec files '''SHOULD''' have a comment within the patch file (or above its respective "PatchN:" tag) about its status. For details see [[openSUSE:Packaging Patches guidelines]].<br />
<br />
==Preparation Section (%prep)==<br />
===Quiet %setup===<br />
'''The <code>-q</code> option should be passed to the <code>%setup</code> macro.'''<br />
<br />
This will reduce the size of the build logfile significantly, especially with source archives that extract a lot of files.<br />
<br />
==Build Section (%build)==<br />
=== Compiler flags ===<br />
'''Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration.'''<br />
<br />
In practice, this means <code>%{optflags}</code> (variable: <code>$RPM_OPT_FLAGS</code>, see above) for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there is a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases.<br />
<br />
=== Parallel make ===<br />
'''Whenever possible, invocations of <code>make</code> should be done in parallel.'''<br />
<br />
This should be done using:<br />
<br />
make %{?_smp_mflags}<br />
<br />
This is also available as the <code>%make_build</code> macro, but it is not available for openSUSE 13.2, Leap 42.2 and SLE 12 SP2 (rpm < 4.12).<br />
<br />
This generally speeds up builds, especially on SMP machines. It is much preferable to <code>make %{?jobs:-j%jobs}</code>, as the former allows alternate make flags to be used, such as <code>make -l''N''</code>, and not hardcoding <code>-j''N''</code>. Do make sure, however, that the package builds cleanly this way; some make files do not support parallel building, or have broken dependencies.<br />
<br />
'''If a package does not support parallel building, please explicitly write <code>-j1</code>.'''<br />
<br />
This facilitate grepping for such packages among a group of specfiles. There may be other reasons to use <code>-j1</code>, for example due to otherwise excessive memory usage. (Such a case occurs for example when building Boost for MINGW.) The common workers on build.opensuse.org have only 2 GB RAM assigned as of September 2013. In any case, consider adding a comment saying what led to the use of <code>-j1</code>, whether it is due to broken dependencies, or memory requirements, etc.<br />
<br />
==Install Section (%install)==<br />
'''Running <code>make install</code> must not attempt to chown any files.'''<br />
<br />
Since rpmbuild is run as an unprivileged user, the %install section must not run chown directly or indirectly, for example, `<code>install -o root</code>...`). File ownership shall be set in the later <code>%files</code> section instead.<br />
<br />
'''Use <code>%make_install</code> instead of <code>%makeinstall</code> (without an underscore).'''<br />
<br />
<code>%make_install</code> is a macro equivalent to <code>make install DESTDIR="%{?buildroot}"</code>. Should you be creating a package for older RPM versions (rpm < 4.10, e.g. SLE 11), use the expanded version instead of the macro.<br />
<br />
There is also a second macro with a confusingly similar name, <code>%makeinstall</code> (note: no underscore). '''Avoid''' using this.<br />
<br />
{{Info|1=<br />
In attempt to work with broken software, this macro expands to a very long line which sets all variables to %buildroot plus their final paths, but does not set DESTDIR itself, which causes certain broken software to actually fail.<br />
<br />
An example of this is xapian-core-1.2.17, where:<br />
<br />
<pre><br />
# configure.ac contains:<br />
incdir=$includedir<br />
AC_SUBST(incdir)<br />
# include/Makefile.mk contains:<br />
inc_HEADERS = include/xapian.h<br />
</pre><br />
<br />
With this, %makeinstall's expansion, "make install ... includedir=/buildroot/usr/include" has ''no'' effect since the awkward Makefile requires <code>incdir</code> to be set instead of <code>includedir</code>. Because %makeinstall does not set DESTDIR, xapian-core will try to install xapian.h to the default location, /usr/include, rather than /buildroot/usr/include. A double failure, so to say.<br />
<br />
SUSE's rpm redefines %makeinstall to be the same as %make_install, but as it is conceivable that your specfile may be used on other distro targets, it is best to avoid %makeinstall, and only ever use %make_install or its expanded form.}}<br />
<br />
===Removing the buildroot===<br />
'''Do not attempt to clean or remove the buildroot folder manually.'''<br />
<br />
openSUSE marks it as '''bad coding style''' to have <code>rm -rf %{buildroot}</code> (or <code>rm -rf $RPM_BUILD_ROOT</code>) at the beginning of an <code>%install</code> section like this:<br />
<br />
%install<br />
rm -Rf "%buildroot"<br />
mkdir -p "%buildroot/%_prefix/..." <br />
<br />
or<br />
<br />
%install<br />
rm -Rf "%buildroot"<br />
make install<br />
<br />
{{Info|1=<br />
Why?<br />
<br />
%{buildroot} is normally within <code>/var/tmp</code> and you just opened a trivial race condition to a local attacker on your machine to take over your account (or even root if you build as root). It is better not to `<code>rm -rf %{buildroot}</code>` in <code>%install</code> at all (and rely on <code>%clean</code> to do it).<br />
<br />
Somewhat better would be the following, ('''do not do this''', it is done automatically for you):<br />
<pre><br />
%install<br />
rm -Rf "%buildroot";<br />
mkdir "%buildroot";<br />
mkdir -p "%buildroot/%_prefix/..."<br />
</pre><br />
or<br />
<pre><br />
%install<br />
rm -Rf "%buildroot";<br />
mkdir "%buildroot";<br />
make install<br />
</pre><br />
<br />
In this case the <code>mkdir %buildroot</code> would fail and the build would abort if an attacker tries to replace the buildroot by his own symlink.}}<br />
<br />
==Clean Section (%clean)==<br />
'''The %clean section should not be included -- it is no longer necessary.'''<br />
<br />
The <code>%clean</code> section, if specified, will be run after the binary and source RPMs have been generated. In the Open Build Service, this section is not necessary because chroots and VM environments that are used to build the package are generally torn down anyway. Building packages in environments not started from scratch is usually not supported for openSUSE packages (cf. [https://bugzilla.opensuse.org/show_bug.cgi?id=176528#c4 boo#176528#c4])<br />
<br />
Starting with rpm-4.7/openSUSE_11.3, rpm defaults to "<code>%clean: rm -Rf %{buildroot}</code>" if the <code>%clean</code> section is completely absent from the spec file.<br />
<br />
If a package contains a <code>%clean</code> section, it ''should'' be safe to remove. Check with another maintainer first if you are not sure.<br />
<br />
==Scriptlets==<br />
Great care should be taken when using scriptlets. Some common scriptlets are documented in [[openSUSE:Packaging scriptlet snippets]].<br />
<br />
=== Scriptlet requirements ===<br />
'''Your package has to require everything you use in scriptlets.'''<br />
<br />
The notation for %pre*/%post* scriptlets is as follows:<br />
<br />
Requires(pre): ...<br />
Requires(post): ...<br />
<br />
<font color="red"><br />
'''Scriplets are only allowed to write in certain directories.'''<br />
<br />
Build scripts of packages shall only alter (create, modify, delete) files under <code>%buildroot</code>, <code>%_builddir</code> and valid temporary locations like <code>/tmp</code>, <code>/var/tmp</code> (or <code>%_tmppath</code> as set by the rpmbuild process) according to the following table:<br />
<br />
{| border="1"<br />
|-<br />
! || /tmp, /var/tmp, %_tmppath || %_builddir || %buildroot<br />
|-<br />
|%prep || yes || yes || no<br />
|-<br />
|%build || yes || yes || no<br />
|-<br />
|%install || yes || yes || yes<br />
|-<br />
|%check || yes || yes || no<br />
|-<br />
|%clean || yes || yes || yes<br />
|}<br />
<br />
Further clarification: This must hold true irrespective of the builder's uid.<br />
</font><br />
<br />
== Files Section (%files) ==<br />
openSUSE follows the [https://wiki.linuxfoundation.org/lsb/fhs Filesystem Hierarchy Standard] (FHS) with regards to filesystem layout, which defines where files should be placed on the system. Any deviation from the FHS should be justified in a comment in the spec file.<br />
<br />
===Ownership===<br />
'''Your package should own all files that are installed as part of the <code>%install</code> process.'''<br />
<br />
Packages must not own files already owned by other packages (or, if they legitimately do, the package needs a <code>Conflict:</code> tag). The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.<br />
<br />
Directory ownership is a little more complex than file ownership. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it is desirable for multiple packages to own a directory. Examples of this include:<br />
<br />
<blockquote><br />
'''Forward compatibility with future versions of a package'''<br />
<br />
The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version.<br />
<br />
One common example of this is a Perl module. Assume ''perl-A-B'' depends on ''perl-A'' and installs files into <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B</code>. The base Perl package guarantees that it will own <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi</code> for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) <code>/usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A</code>. So the ''perl-A-B'' package needs to own <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A</code> as well as <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B</code> in order to maintain proper ownership.<br />
<br />
'''Common directory for unrelated packages'''<br />
<br />
Multiple packages may have files in a common directory, but are not necessarily dependent on one of the packages. Take the following example:<br />
<br />
* Package foo-animal-emu puts files into /usr/share/Foo/Animal/Emu<br />
* Package foo-animal-llama puts files into /usr/share/Foo/Animal/Llama<br />
<br />
Neither package depends on the other one. Neither package depends on any other package which owns the <code>/usr/share/Foo/Animal</code> directory. In this case, each package must own the <code>/usr/share/Foo/Animal</code> directory.<br />
</blockquote><br />
<br />
This is to prevent [[Packaging/Unowned_Directories|unowned directories]] from being installed on a system.<br />
<br />
'''An openSUSE package must not contain any duplicate files in the <code>%files</code> listing.'''<br />
<br />
Files packaged more than once (in two or more subpackages) and files containing the same content are both considered to be duplicate files.<br />
<br />
It is recommended to run <code>%fdupes %buildroot</code> (requires adding <code>BuildRequires: fdupes</code>) to smartly eliminate duplicate content by replacing those files with hardlinks to one another.<br />
<br />
===Permissions===<br />
Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every <code>%files</code> section must include a <code>%defattr(...)</code> line. Here is a good default:<br />
<br />
%files<br />
%defattr(-,root,root)<br />
<br />
Unless you have a very good reason to deviate from that, you should use <code>%defattr(-,root,root)</code> for all <code>%files</code> sections in your package. You can use <code>%defattr(-,root,root,0755)</code> to fix permission issues with directories. E.g. when an umask was too tight while unpacking.<br />
<br />
====SUID bits====<br />
'''SUID bits set by default require explicit approval by the SUSE Security Team.'''<br />
<br />
See the [[openSUSE:Package_security_guidelines#Setuid_Binaries|openSUSE package security guidelines]] for more information.<br />
<br />
===Documentation files===<br />
'''Any relevant documentation included in the source distribution should be included in the package.'''<br />
<br />
Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Also pay attention about which subpackage you include documentation in, for example API documentation belongs in the <code>-devel</code> subpackage, not the main one. Or if there is a lot of documentation, consider putting it into a subpackage of its own. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.<br />
<br />
'''Any file marked as <code>%doc</code> must not affect the runtime of the application.'''<br />
<br />
That is, if it is in <code>%doc</code>, the program must run properly if it is not present.<br />
<br />
===License files===<br />
<br />
License files should be marked with <code>%license</code> for newer products. See https://lists.opensuse.org/opensuse-factory/2016-02/msg00167.html for reasoning. <code>%doc</code> should be avoided. To be backward compatible use a definition like:<br />
<br />
%if 0%{?suse_version} < 1500<br />
%doc LICENSE<br />
%else<br />
%license LICENSE<br />
%endif<br />
<br />
===Configuration files===<br />
Configuration files must be marked as such in packages. As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when ''not'' to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision would not work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.<br />
<br />
Do not use <code>%config</code> or <code>%config(noreplace)</code> under <code>/usr</code>. <code>/usr</code> is deemed to not contain configuration files in openSUSE.<br />
<br />
=== Development files ===<br />
If the software being packaged contains files intended solely for development, those files should be put in a <code>-devel</code> subpackage. The following are examples of file types which should be in <code>-devel</code>:<br />
<br />
* Header files (e.g. .h files)<br />
* Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries, e.g. <code>libfoo.so.3</code>, <code>libfoo.so.3.0.0</code> should not be in <code>-devel</code>.<br />
* pkgconfig files. A reasonable exception is when the main package itself is a development tool, e.g. gcc or gdb.<br />
<br />
Packages containing pkgconfig (<code>.pc</code>) files must utilize <code>BuildRequires: pkg-config</code> so that the proper runtime dependency <code>Requires: pkg-config</code> is added.<br />
<br />
===Locale files===<br />
openSUSE includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the <code>%install</code> section of your spec file, after all of the files have been installed into the buildroot. Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.<br />
<br />
* Packages that use <code>%_datadir/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.<br />
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:<br />
<pre><br />
%_datadir/locale/ar/LC_MESSAGES/%name.mo<br />
%_datadir/locale/be/LC_MESSAGES/%name.mo<br />
%_datadir/locale/cs/LC_MESSAGES/%name.mo<br />
%_datadir/locale/de/LC_MESSAGES/%name.mo<br />
%_datadir/locale/es/LC_MESSAGES/%name.mo<br />
...<br />
</pre><br />
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.<br />
* To include the locale files found by <code>%find_lang</code> you have add the <code>-f %{name}.lang</code> option to the <code>%files</code> section. So the section header should look like <code>%files -f %{name}.lang</code>.<br />
<br />
===Non-ASCII filenames===<br />
'''Filenames that contain non-ASCII characters must be encoded as UTF-8.'''<br />
<br />
Since there is no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8, you can use a utility like <code>convmv</code> (from the convmv package) to convert the filename in your <code>%install</code> section.<br />
<br />
=== Libexecdir ===<br />
<br />
The GNU build system (autotools) offers a [https://www.gnu.org/prep/standards/html_node/Directory-Variables.html "libexecdir" variable/option], which specifies a location "for installing executable programs to be run by other programs rather than by users". Packages often create a subdirectory in libexecdir, for which they may also use the predefined convenient variable <code>${pkglibexecdir}</code> in Automake files; one might find "<code>pkglibexec_PROGRAMS = myhelper</code>" in <code>Makefile.am</code>.<br />
<br />
However, older versions of the [https://wiki.linuxfoundation.org/lsb/fhs Filesystem Hierarchy Standard] (before 3.0) do not include any provision for libexecdir, and the rpm package in (open)SUSE has been changed to expand <code>%_libexecdir</code> to <code>/usr/lib</code> instead of <code>/usr/libexec</code>.<br />
<br />
==Changelog section (%changelog)==<br />
<br />
openSUSE uses a separate changelog file instead of placing it in the spec file.<br />
<br />
See [[openSUSE:Howto_write_good_changes|HOWTO write good changes]] for more information.<br />
<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Richtlinien für Spezifikationsdateien]]<br />
[[it:openSUSE:Linee guida per i file Spec]]<br />
[[ja:openSUSE:Spec ファイルのガイドライン]]<br />
[[zh:openSUSE:Specfile_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_Conventions_RPM_Macros&diff=123422openSUSE:Packaging Conventions RPM Macros2018-02-08T09:38:56Z<p>Okurz: Adjust "pan" package spec file template according to current state of package including the to-be-included SR #574127 to use the proper %license macro.</p>
<hr />
<div>{{Packaging_docnav}}<br />
<br />
=== Syntax ===<br />
<br />
{{warning|The validity of the claims in this subsection are uncertain. It is actually possible to mix options with parameters, as is commonly done in, for example, '''%kernel_module_package -p preamble -x xen xenpae'''.}}<br />
<br />
This section describes predefined RPM macros used in the SUSE packages. Some of them are generic RPM macros. Some are SUSE-specific macros. For other existing generic macros, other documentation should be consulted, such as [http://www.rpm.org/max-rpm-snapshot/ Maximum RPM] or [http://rpm.org/user_doc/macros.html Macro syntax]. The Java-related macros are described in the [[openSUSE:Packaging Java]] page. KDE macros are documented at [[openSUSE:KDE RPM Macros]]. If you wish to perform advanced rpm macro programming, rpm has built in support for the [http://www.lua.org/manual/5.1/manual.html#5.1 Lua programming language]<br />
<br />
You can find all the predefined macros in the <tt>/usr/lib/rpm/macros</tt> and <tt>suse_macros</tt> files with some explanation. Additional package specific macros are added by files in <tt>/etc/rpm</tt>. If you place the macro <tt>%dump</tt> in your spec file and use `<tt>rpmbuild -bp specfile</tt>`, it will cause a dump of all the macros available on your system. It is however easier to just execute `<tt>rpm --showrc</tt>`.<br />
<br />
One important difference between RPM macros and normal Linux commands is how the options and parameters are defined. RPM provides only a simple support for processing options. One limitation is that all options must be defined before parameters and it is not possible to simply use pairs created from an option and a related value. For example, the Linux command <span>'''top'''</span> uses the following synopsis:<br />
<br />
<code>'''top'''</code> [<code>-bcisS</code>] [<code>-d</code> ''<code>delay</code>''] [<code>-n</code> ''<code>iterations</code>''] [<code>-p</code> ''<code>pid</code>''] [, ''<code>pid</code>'' ...]<br />
<br />
The used pairs <tt>-d</tt> ''<tt>delay</tt>'', <tt>-n</tt> ''<tt>iterations</tt>'', <tt>-p</tt> ''<tt>pid</tt>'' and all the parameters are optional. The option before a parameter defines which parameter is really used on the command line. This makes it possible to call:<br />
<br />
Example 1: <code>'''top -n 20 -p 10345'''</code><br />
<br />
Example 2: <code>'''top -d 1 -p 10345'''</code><br />
<br />
and the command knows that <tt>20</tt> is a number of iterations, <tt>1</tt> is a delay and <tt>10345</tt> is a PID.<br />
<br />
Due to the limitation in RPM, the synopsis of a related RPM macro would look like:<br />
<br />
<code>'''%top'''</code> [<code>-bcisSdnp</code>] [''<code>delay</code>''] [''<code>iterations</code>''] [''<code>pid</code>''] [,''<code>pid</code>'' ...]<br />
<br />
All the options must be defined before parameters and the option again defines which parameter is really used. This means that the related call of the potential RPM macro of the examples above would be:<br />
<br />
Example 1: <code>'''%top -n -p 5 10345'''</code><br />
<br />
Example 2: <code>'''%top -d -p 1 460'''</code><br />
<br />
=== %_docdir ===<br />
<br />
This macro is substituted with the default directory for documentation, <tt>/usr/share/doc/packages</tt>. It may be redefined by the <tt>Docdir</tt> tag. Usually, it is used to install a documentation in the <tt>%install</tt> section if it is not sufficient to do it in the <tt>%files</tt> with the <tt>%doc</tt> tag. Furthermore, the <tt>%doc</tt> tag need not be used together with <tt>%_docdir</tt> in the <tt>%files</tt> section. It is done automatically for this directory.<br />
<br />
This example is taken from the ''aeolus'' package:<br />
<br />
%install<br />
[...]<br />
mkdir -p "%buildroot/%_docdir/%name"<br />
cp -a .aeolusrc "%buildroot/%_docdir/%name/aeolusrc"<br />
cp -Ra stops-* "%buildroot/%_docdir/%name"<br />
[...]<br />
<br />
%files<br />
[...]<br />
%_docdir/%name<br />
<br />
=== %_infodir ===<br />
<br />
This macro is substituted with the default directory for info pages, <tt>/usr/share/info</tt>. It is often used with `<code>./configure --infodir="%_infodir"</code>`, with the the <tt>%install_info</tt> macro, and in the file list. As with <tt>%_docdir</tt>, the tag <tt>%doc</tt> need not be used together with <tt>%_infodir</tt> in the <tt>%files</tt> section. It is done automatically for this directory.<br />
<br />
=== %_lib ===<br />
<br />
This macro substitutes with either <tt>lib</tt> or <tt>lib64</tt>, as appropriate. The second variant appears on 64-bit architectures which support running both 64-bit and 32-bit programs in parallel (biarch systems). On such systems, two variants of the same libraries must coexist. Therefore, the 64-bit libraries are installed in <tt>lib64</tt> directories and 32-bit libraries in the traditional <tt>lib</tt> directories.<br />
<br />
<tt>%_lib</tt> itself is used when the macro <tt>%_libdir</tt> is not sufficient, for example, when libraries are supposed to go into <tt>/usr/X11R6/%_lib</tt>. It is often used with `<code>./configure -–libdir="/usr/X11R6/%_lib"</code>` and in the file list.<br />
<br />
=== %_libdir ===<br />
<br />
This macro is substituted with <tt>%_prefix/%_lib</tt>. It has the same function as <tt>%_lib</tt> and is used even more often than it, because the libraries usually are installed into <tt>/usr/lib(64)</tt>. Used with `<code>./configure --libdir="%_libdir"</code>` and in the file list.<br />
<br />
=== %_mandir ===<br />
<br />
This macro is substituted with the default directory for manual pages, <tt>/usr/share/man</tt>. It is often used with `<code>./configure --mandir="%_mandir"</code>` and in the <tt>%files</tT> section, such as in<br />
<br />
%files<br />
%_mandir/*/*<br />
<br />
As with <tt>%_docdir</tt>, the <tt>%doc</tt> tag need not be used together with <tt>%_mandir</tt> in the <tt>%files</tt> section. It is done automatically for this directory.<br />
<br />
=== %_rundir ===<br />
<br />
This macro is substituted with the default directory for volatile<br />
runtime data which is by default <tt>/run</tt>. The macro was<br />
introduced April 2014. For older distribution you may want to add<br />
the following snippet:<br />
<br />
%if ! %{defined _rundir}<br />
%define _rundir %{_localstatedir}/run<br />
%endif<br />
<br />
=== %_fillupdir ===<br />
<br />
This macro is substituted with the default directory for the templates used by %fillup_only and %fillup_and_insserv macros. The macro was introduced in November 2017 as part of the migration of this data from <tt>/var/adm/fillup-templates</tt> to <tt>/usr/share/fillup-templates</tt>.<br />
For older distributions you may want to add the following snippet to continue to use the old path:<br />
<br />
%if ! %{defined _fillupdir}<br />
%define _fillupdir /var/adm/fillup-templates<br />
%endif<br />
<br />
=== %desktop_database_post / %desktop_database_postun ===<br />
<br />
These macros need to be called for every application which installs a .desktop file. This will update the system media type cache by calling update-desktop-database.<br />
<br />
{{Warning|Most packagers forget to do this! This can lead to hard-to-debug bugs, for example after installing your application, GNOME Shell/GDM missing all its panel icons. So normally these macros need to run after you install .desktop files in the package.}}<br />
{{Info|These macros are relevant for openSUSE Leap 42.3 and older. These macros are not necessary for newer releases, including Tumbleweed, as they use [https://lists.opensuse.org/opensuse-factory/2017-06/msg00898.html RPM's file triggers] to handle such updates.}}<br />
<br />
It requires <tt>desktop-file-utils</tt> package. Example from <tt>meld</tt> package:<br />
...<br />
BuildRequires: update-desktop-files<br />
<br />
...<br />
<br />
%if 0%{?suse_version} < 1330<br />
%post<br />
%desktop_database_post<br />
%endif<br />
<br />
%if 0%{?suse_version} < 1330<br />
%postun<br />
%desktop_database_postun<br />
%endif<br />
{{Info|<code>BuildRequires: desktop-file-utils</code> is not needed if <code>BuildRequires: update-desktop-files</code> is already added to the specfile preamble, as the latter already requires <tt>desktop-file-utils</tt> package.}}<br />
<br />
=== %define ===<br />
This macro is used to define custom macros inside a specific spec file. Use this as a placeholder for recurring words like a custom name for the package<br />
<br />
%define custom_version 12.6_64<br />
..<br />
%setup -qn %name-%custom_version<br />
<br />
=== %fdupes ===<br />
<br />
The %fdupes macro replaces duplicate files by hard links or soft links. Duplicate files waste space in the installed system. %fdupes thus reduces the installed size of your package. There is a [[openSUSE:Packaging_checks|RPMLint]] check that will give an error for the package if it is wasting a considerable amount of space with duplicate files. In that case you have to use %fdupes. <br />
<br />
To use %fdupes, you must include <tt>BuildRequires: fdupes</tt> in the spec file.<br />
<br />
You will receive a "no job control" error if you do not BuildRequire fdupes.<br />
The "%fdupes" macro is then undefined and it is copied into the shell script, and the shell treats '%' for job control, resulting in the error.<br />
<br />
Please be careful that these duplicated files do not end up in different subpackages; we have not tried yet what rpm does in the hardlink case. If in doubt, you can use <tt>%fdupes -s</tt>, which will create symlinks that are easier to grasp for rpm and rpmlint will give a "dangling symlink" error if the file and link ended up in different packages.<br />
<br />
Here is an example, combining both symbolic and hard links:<br />
..<br />
# define %fdupes<br />
<strong>BuildRequires: fdupes</strong><br />
..<br />
%install<br />
..<br />
# create symlinks for man pages<br />
%fdupes -s %{buildroot}/%{_mandir}<br />
# create hardlinks for the rest<br />
%fdupes %{buildroot}/%{_prefix}<br />
<br />
fdupes must NOT be used on (%buildroot)/etc and /var when creating hardlinks. All files in /etc are meant to be readily editable, and the presence of hardlinks leads to unexpected behavior, as some editing programs may modify files in-place, and others may recreate the file.<br />
<br />
<tt>%fdupes</tt> is generally safe for use on <tt>/bin</tt>, <tt>/lib</tt>*, <tt>/usr</tt> (= <tt>%_prefix</tt>) and <tt>/sbin</tt>. Do note however that files with same content but different ownership, when hardlinked, will get the ownership of any of its content siblings.<br />
<br />
=== %fillup_and_insserv ===<br />
<br />
This macro can be used to fill up sysconfig files and insserv init scripts.<br />
<br />
Synopsis:<br />
<br />
'''<code>%fillup_and_insserv</code>''' [<code>-finyY</code>] [''<code>sysconfig_filename</code>''] [''<code>init_script_name</code>''] ...<br />
<br />
The <tt>%fillup_and_insserv</tt> macro combines two functions in one command. It is used to insert (fill up) config files in <tt>/etc/sysconfig</tt> and to enable (insserv) services in runlevels. The fillup part assumes a template stored in <tt>/usr/share/fillup-templates/''sysconfig_filename''.%name</tt> (before Nov 2017 this was <tt>/var/adm/fillup-templates</tt>)<br />
<br />
The macro is used in the <tt>%post</tt> section of packages that install an init script and want to enable it by default. See [[openSUSE:Packaging_init_scripts#Installation|“Installation”]] for more details. Do not forget to mention the used utilities used in the <tt>PreReq</tt>. The <tt>%insserv_prereq</tt> and <tt>%fillup_prereq</tt> serve this purpose.<br />
<br />
(Actually, since insserv/fillup is only called in <tt>%post</tt>, should <tt>Requires(post)</tt> not be more appropriate than <tt>PreReq</tt>?)<br />
<br />
Options:<br />
<br />
* <code>-f</code> skips the fillup part.<br />
* <code>-i</code> skips the insserv part.<br />
* <code>-n</code> defines that the parameter ''<code>sysconfig_filename</code>'' is used (see below).<br />
* <code>-y</code> causes enabling the init-script by default if the package is installed for the first time (not during an update). It is ignored if <code>X-UnitedLinux-Default-Enabled</code> is specified in the init script.<br />
* <code>-Y</code> forcefully enables the service. This means the service is always activated regardless of the setting before an update.<br />
<br />
Parameters:<br />
<br />
* ''<tt>sysconfig_filename</tt>'' creates a pair with the option <tt>-n</tt> and defines the filename where the configuration is filled up, <tt>/etc/sysconfig/''sysconfig_filename''</tt>. In addition, it defines a name of the file with templates. The macro searches for two possible template files. It prefers <tt>/usr/share/fillup-templates/sysconfig.''sysconfig_filename''.%name</tt> if it is available. Otherwise, it searches for <tt>/usr/share/fillup-templates/sysconfig.''sysconfig_filename''</tt>. The longer variant must be used if multiple packages write to the same config file. By default (that is, when the <tt>-n</tt> option is not used), the template is <tt>/usr/share/fillup-templates/sysconfig.%name</tt> and the target sysconfig file is <tt>/etc/sysconfig/%name</tt>.<br />
* ''<tt>init_script_name</tt>'' defines a name of the init script processed by `<code>insserv</code>`. It must be defined if the <tt>-i</tt> option is not used. More init scripts names can be defined (see examples below).<br />
<br />
Example from the ''mailman'' package:<br />
<br />
Requires(post): %insserv_prereq %fillup_prereq ...<br />
<br />
%post<br />
%{fillup_and_insserv mailman}<br />
<br />
It fills the configuration file <tt>/etc/sysconfig/mailman</tt> from the template <tt>/usr/share/fillup-templates/sysconfig.mailman</tt>.<br />
<br />
Example taken from the ''hwinfo'' package:<br />
<br />
Requires(post): %insserv_prereq<br />
<br />
%post<br />
%{fillup_and_insserv -f -y hwscan}<br />
<br />
It runs `<code>insserv</code>` on <tt>/etc/init.d/hwscan</tt> and enables the service by default. Note that only the <tt>insserv</tt> part is in <tt>PreReq</tt> because the <tt>fillup</tt> part is omitted, as the <tt>-f</tt> option was used.<br />
<br />
Example from the ''openssh'' package:<br />
<br />
%{fillup_and_insserv -n -y ssh sshd}<br />
<br />
It fills the configuration file <tt>/etc/sysconfig/ssh</tt>. The template is taken either from <tt>/usr/share/fillup-templates/sysconfig.ssh.openssh</tt> or from <tt>/usr/share/fillup-templates/sysconfig.ssh</tt>. The first one is preferred. It runs `<code>insserv</code>` on <tt>/etc/init.d/sshd</tt> and enables the service by default during a new installation.<br />
<br />
Example from the ''openldap2'' package:<br />
<br />
%{fillup_and_insserv -n openldap ldap slurpd}<br />
<br />
It fills the configuration file <tt>/etc/sysconfig/openldap</tt>. The template is taken either from <tt>/usr/share/fillup-templates/sysconfig.openldap.openldap2</tt> or from <tt>/usr/share/fillup-templates/sysconfig.openldap</tt>. The former is preferred.<br />
<br />
=== %fillup_only ===<br />
<br />
This macro can be used to fill up sysconfig files.<br />
<br />
Synopsis:<br />
<br />
<code>'''%fillup_only'''</code> [<code>-adns</code>] [''<code>sysconfig_filename</code>''] [''<code>suffix</code>''] [''<code>sysconfig_subdir</code>'']<br />
<br />
The '''%fillup_only''' macro is used to insert (fill up) the variables from a template <tt>/usr/share/fillup-templates/sysconfig.''sysconfig_filename''[-''suffix'']</tt> into a config file <tt>/etc/sysconfig/''sysconfig_filename''</tt>. (before Nov 2017 the template location was <tt>/var/adm/fillup-templates</tt>)<br />
<br />
The base function is similar to '''%fillup_and_insserv -i''', but it allows modifying config files in subdirectories of <tt>/etc/sysconfig</tt>.<br />
<br />
The macro is typically used in the <tt>%post</tt> section. Do not forget to mention the utilities used in the <tt>PreReq</tt> tag. The macro <tt>%fillup_prereq</tt> is intended for this purpose.<br />
<br />
Options:<br />
<br />
* <code>-a</code> uses the package name as a suffix of the syconfig template filename.<br />
* <code>-d</code> defines that the parameter ''<code>sysconf_subdir</code>'' is used (see below).<br />
* <code>-n</code> defines that the parameter ''<code>sysconfig_filename</code>'' is used (see below).<br />
* <code>-s</code> defines that the parameter ''<code>suffix</code>'' is used (see below).<br />
<br />
Parameters:<br />
<br />
* ''<tt>sysconfig_filename</tt>'' creates a pair with the <tt>-n</tt> option and defines the name of the sysconfig file and a name of the file with templates. By default (that is, when the <tt>-n</tt> option is not used), the package name is used instead. So the template <tt>/usr/share/fillup-templates/sysconfig.%name</tt> is filled up to <tt>/etc/sysconfig/%name</tt>.<br />
* ''<tt>sysconfig_template_filename_suffix</tt>'' creates a pair with the <tt>-s</tt> option and defines a suffix of the filename with templates.<br />
* ''<tt>sysconfig_subdir</tt>'' creates a pair with the <tt>-d</tt> option and defines a subdirectory of <tt>/etc/sysconfig</tt> where the synconfig file is located.<br />
<br />
Example from the ''tetex'' package:<br />
<br />
Requires(post): %fillup_prereq<br />
<br />
%post<br />
%fillup_only<br />
<br />
It fills up the config file <tt>/etc/sysconfig/tetex</tt> from the template <tt>/usr/share/fillup-templates/sysconfig.tetex</tt>.<br />
<br />
Example from the ''man'' package:<br />
<br />
%{fillup_only -an cron}<br />
<br />
It fills the config file <tt>/etc/sysconfig/cron</tt> from the template <tt>/usr/share/fillup-templates/sysconfig.cron-man</tt>.<br />
<br />
Example from the ''dhcp'' package:<br />
<br />
%{fillup_only -ans syslog dhcpd}<br />
<br />
It fills the config file <tt>/etc/sysconfig/syslog</tt> from the template <tt>/usr/share/fillup-templates/sysconfig.syslog-dhcpd</tt>.<br />
<br />
Example from the ''samba'' package:<br />
<br />
%fillup_only -nsd dhcp samba-client network<br />
<br />
It fills the config file <tt>/etc/sysconfig/network/dhcp</tt> from the template <tt>/usr/share/fillup-templates/sysconfig.dhcp-samba-client</tt>.<br />
<br />
=== %find_lang ===<br />
<br />
This macro helps to mark locale-dependent files with the respective <code>%lang</code> tag in the file list.<br />
<br />
==== Synopsis ====<br />
<br />
%find_lang ''options'' ''name'' [''filelist'']<br />
<br />
The <tt>%find_lang</tt> macro searches the directories <tt>/usr/share/locale</tt> and <tt>locale/*/LC_MESSAGES</tt> for <tt>''name''.mo</tt> files. It also searches <tt>gnome/help/''name''</tt> and <tt>kde*/share/doc/HTML/*/''name''</tt> directories for a localized documentation. Then it creates the file ''filelist'' where the files are marked with the respective <tt>%lang(locale)</tt> and <tt>%doc</tt> tags. Such a file list can be then passed to the <tt>%files</tt> tag via the <tt>-f</tt> option. See below for an example.<br />
<br />
It is recommended to use this macro only if the [[openSUSE:Specfile_guidelines#Metadata_Tags|BuildRoot]] tag is defined as otherwise the entire system will be searched.<br />
<br />
%find_lang should be used in %install section.<br />
<br />
==== Options ====<br />
<br />
;--without-gnome<br />
: do not find GNOME help files.<br />
<br />
;--without-kde<br />
: do not find KDE help files.<br />
<br />
;--with-qt<br />
: find Qt translation files.<br />
<br />
;--with-man<br />
: find localized man pages.<br />
<br />
;--all-name<br />
: match all package/domain names.<br />
<br />
;--without-mo<br />
: do not find locale files.<br />
<br />
==== Parameters ====<br />
<br />
;''name''<br />
: defines the name of <tt>.mo</tt> files and the name of sub-directories where GNOME and KDE localized documentation is stored. It is also used for the ''filelist'' where the generated file list is stored if the parameter ''filelist'' is not given.<br />
<br />
;''filelist''<br />
: defines the name of the file where the generated list of files is stored. <tt>''name''.lang</tt> is used if not otherwise defined.<br />
<br />
Example from the package <tt>pan</tt>: <br />
<br />
%install<br />
make -i DESTDIR="%{buildroot}" install<br />
%find_lang %{name} # generate a special file list (macro can be used for different file names again)<br />
<br />
%files -f %{name}.lang # use the special file list (add more "-f" for each special file list)<br />
%defattr(-,root,root) # list the other files<br />
%license COPYING COPYING-DOCS<br />
%doc AUTHORS NEWS README<br />
%attr(755,root,root) %prefix/bin/pan<br />
[&hellip;]<br />
<br />
=== %icon_theme_cache_post / %icon_theme_cache_postun ===<br />
<br />
This macro is used to update the icon theme cache for packages which install icons into hicolor or other icon themes.<br />
It is meant to be called in <tt>%post</tt> and <tt>%postun</tt> sections and takes an option argument which is the name of the updated icon theme where <tt>hicolor</tt> is the default.<br />
<br />
{{Info|These macros are not necessary anymore for Tumbleweed which uses [https://lists.opensuse.org/opensuse-factory/2017-06/msg00898.html RPM's file triggers] to handle such updates.}}<br />
<br />
It requires the <tt>hicolor-icon-theme</tt> package. Example: see [[#.25desktop_database_post_.2F_.25desktop_database_postun|%desktop_database_post / %desktop_database_postun]].<br />
<br />
FIXME: Which tag is needed as Requires(post/postun)?<br />
<br />
=== %lang_package ===<br />
<br />
This macro is used to create a template for a <tt>lang</tt> subpackage.<br />
<br />
It accepts two optional parameters:<br />
<br />
* name: Alternative name for <tt>lang</tt> subpackage.<br />
* requires: Additional <tt>lang</tt> subpackage dependencies.<br />
<br />
Example from the ''k3b'' package:<br />
<br />
Recommends: %{name}-lang = %{version}<br />
...<br />
%package devel<br />
...<br />
%description devel<br />
This package contain files needed for development with k3b.<br />
<br />
%lang_package<br />
<br />
%prep<br />
%setup -q<br />
...<br />
<br />
This will create a <tt>k3b-lang</tt> subpackage. Do not forget to add the<br />
<tt>Recommends</tt> tag to the main package.<br />
<br />
=== %insserv_cleanup ===<br />
<br />
This macro is used to run `<code>insserv</code>` after a package is removed. Each package providing an init script should call this macro in the <tt>%postun</tt> section.<br />
<br />
Example from the ''openldap2'' package:<br />
<br />
%postun<br />
%restart_on_update ldap slurpd<br />
%insserv_cleanup<br />
<br />
=== %insserv_force_if_yast ===<br />
<br />
This macro is a plain call of the `<code>insserv</code>` if the package is not installed by YaST. When YaST is used, it calls `<code>insserv -f</code>` instead. This helps to avoid errors on "out-of-sequence" package installations.<br />
<br />
The macro is used in the <tt>%post</tt> script of packages that install an init script and which want to enable it by default. It is also used if the init script existed prior to SL 8.0 when the START variables were used. See [[openSUSE:Packaging_init_scripts#Installation]], “Installation” for more details. Do not forget to mention the used utilities in the <tt>PreReq</tt> tag. There are the macros <code>%insserv_prereq</code> and <code>%fillup_prereq</code> for this purpose.<br />
<br />
Example from the ''glibc'' package, ''nscd'' subpackage:<br />
<br />
%package -n nscd<br />
PreReq: %insserv_prereq<br />
<br />
%post -n nscd<br />
%{insserv_force_if_yast nscd}<br />
<br />
=== %install_info ===<br />
<br />
This macro updates dir entries for info files.<br />
<br />
Synopsis:<br />
<br />
<code>'''%install_info'''</code> ''<code>install_info_options</code>''<br />
<br />
The '''%install_info''' macro runs `<code>bin/install-info</code>` with some additional tests. It accepts any option from the <tt>install-info</tt> utility. See `<code>man install-info</code>` for more details.<br />
<br />
Each package providing info pages should call this macro in the <tt>%post</tt> section. Do not forget to mention all the used utilities in the <tt>PreReq</tt> tag. The <code>%install_info_prereq</code> macro exists for this purpose.<br />
<br />
Examples:<br />
<br />
Example from the ''zsh'' package:<br />
<br />
Requires(post): %install_info_prereq<br />
Requires(preun): %install_info_prereq<br />
<br />
%post<br />
%install_info --info-dir=%_infodir %_infodir/%name.info.gz<br />
<br />
Example from the ''rplay'' package (a package with multiple info pages):<br />
<br />
Requires(post): %install_info_prereq<br />
Requires(preun): %install_info_prereq<br />
<br />
%post<br />
%install_info --info-dir=%_infodir %_infodir/%name.info.gz<br />
%install_info --info-dir=%_infodir %_infodir/RPLAY.info.gz<br />
%install_info --info-dir=%_infodir %_infodir/RPTP.info.gz<br />
%install_info --info-dir=%_infodir %_infodir/librplay.info.gz<br />
<br />
=== %install_info_delete ===<br />
<br />
This macro removes dir entries for info files.<br />
<br />
Synopsis:<br />
<br />
<code>'''%install_info_delete'''</code> ''<code>install_info_options</code>''<br />
<br />
The macro <span>'''%install_info_delete'''</span> is a complement to the macro <span>'''%install_info'''</span>. It runs <span>'''sbin/install-info --quiet –delete'''</span> with some additional tests. It accepts any option from the <span>'''install-info'''</span> utility. See <span>'''man install-info'''</span> for more details.<br />
<br />
Each package providing info pages should call this macro in <code class="systemitem">%postun</code> script. Do not forget to mention all the utilities used in the <code class="systemitem">PreReq</code> tag. The macro <code class="systemitem">%install_info_prereq</code> is intended for this purpose.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">zsh</code> (also shows the related <code class="systemitem">PreReq</code> tag):<br />
Requires(post): %install_info_prereq<br />
Requires(preun): %install_info_prereq<br />
[...]<br />
%preun<br />
%install_info_delete --info-dir=%_infodir %_infodir/%name.info.gz<br />
# This example is taken from the package <code class="systemitem">rplay</code> (a package with multiple info pages). The example also shows the related <code class="systemitem">PreReq</code> tag):<br />
Requires(post): %install_info_prereq<br />
Requires(preun): %install_info_prereq<br />
<br />
[...]<br />
%preun<br />
for infoname in %name RPLAY RPTP librplay; do<br />
%install_info_delete --info-dir=%_infodir %_infodir/$infoname.info.gz<br />
done<br />
<br />
=== %perl_archlib ===<br />
<br />
This macro is substituted by the path where architecture-specific parts of Perl are installed, for example, <code class="filename">/usr/lib/perl5/5.8.5/i586-linux-thread-multi</code>.<br />
<br />
It is normally only used by the <code class="systemitem">perl</code> package itself and by the macro <code class="systemitem">%perl_process_packlist</code>. See below.<br />
<br />
=== %perl_gen_filelist ===<br />
<br />
Generates an rpmlint happy filelist of your installed files.<br />
<br />
In most cases you only need to check the %doc part<br />
sometimes there is a "Changes" or "ChangeLog",....<br />
<br />
You have to define following parts inside your spec file<br />
<br />
Example:<br />
<br />
%install<br />
%perl_make_install<br />
%perl_process_packlist<br />
%perl_gen_filelist<br />
<br />
%files -f %{name}.files<br />
%defattr(-,root,root)<br />
%doc Changes README<br />
<br />
And here an Example of the generated filelist:<br />
<br />
%dir /usr/lib/perl5/vendor_perl/5.8.8/Algorithm<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/DiffOld.pm<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/diff.pl<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/Diff.pm<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/diffnew.pl<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/cdiff.pl<br />
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/htmldiff.pl<br />
%dir /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm<br />
%dir /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm/Diff<br />
/usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm/Diff/.packlist<br />
/usr/share/man/man?/*<br />
/var/adm/perl-modules/perl-Algorithm-Diff<br />
<br />
=== %perl_make_install ===<br />
<br />
This macro does the <span>'''make install'''</span> call correctly on various products. Before SL 9.0, the normal way to invoke it was:<br />
<br />
make PREFIX="%buildroot/%_prefix" \<br />
INSTALLMAN1DIR="%buildroot/%_mandir/man1" \<br />
INSTALLMAN3DIR="%buildroot/%_mandir/man3" \<br />
install<br />
<br />
For 9.0 and later versions:<br />
<br />
make DESTDIR="%buildroot" install_vendor<br />
<br />
With the macro <code class="systemitem">%perl_make_install</code>, this is done correctly according to the version.<br />
<br />
This example comes from the package <code class="systemitem">perl-URI</code><nowiki>:</nowiki><br />
<br />
%install<br />
%perl_make_install<br />
<br />
=== %perl_process_packlist ===<br />
<br />
This macro prepares some files, related to perl modules, for the final package. It does the following actions:<br />
<br />
Each package including a perl module should call this macro in the section <code class="systemitem">%install</code>.<br />
<br />
==== for 0%{?suse_version} >= 1140 ====<br />
<br />
* Searches for the installed <code class="filename">.packlist</code> files and removes them from <code class="filename">%buildroot/%perl_vendorarch/auto</code>.<br />
If <code class="filename">%_target_cpu == noarch</code> then empty directories are removed from <code class="filename">%buildroot/%perl_vendorarch/auto</code>.<br />
* Removes the <code class="filename">%buildroot/%perl_archlib/perllocal.pod</code> file.<br />
<br />
This example is taken from the package <code class="systemitem">perl-HTML-Parser</code><nowiki>:</nowiki><br />
<br />
%install<br />
%perl_make_install<br />
%perl_process_packlist<br />
%perl_gen_filelist<br />
<br />
%files -f %name.files<br />
%doc Changes mkhctype mkpfunc README TODO eg<br />
<br />
%changelog<br />
<br />
==== for 0%{?suse_version} <= 1130 ====<br />
<br />
* Removes <code class="filename">%buildroot</code> from <code class="filename">%perl_archlib/perllocal.pod</code> and renames the file to a package-specific file. See below for more details.<br />
* Searches for the installed <code class="filename">.packlist</code> files and removes <code class="filename">%buildroot</code> from them.<br />
<br />
The file <code class="filename">%perl_archlib/perllocal.pod</code> must be renamed because it contains information about additional installed perl modules and evidently cannot be installed at the same place from multiple packages. Therefore, it is renamed and a special SuSEconfig module, <code class="filename">/sbin/conf.d/SuSEconfig.perl</code>, adds this information to the system <code class="filename">%perl_archlib/perllocal.pod</code> after the package is installed.<br />
<br />
This example is taken from the package <code class="systemitem">perl-URI</code><nowiki>:</nowiki><br />
<br />
%install<br />
%perl_make_install<br />
%perl_process_packlist<br />
<br />
%files<br />
[...]<br />
/var/adm/perl-modules/%name<br />
<br />
=== %perl_sitearch ===<br />
<br />
This macro is substituted by the path where architecture-specific parts of Perl modules are installed by a local administrator (<code class="filename">/usr/lib/perl5/site_perl/5.8.5/i586-linux-thread-multi</code>). The packages distributed within SUSE Linux use the path defined by <code class="systemitem">%perl_vendorarch</code> instead. See below.<br />
<br />
=== %perl_sitelib ===<br />
<br />
This macro is substituted by the path where architecture-independent parts of Perl modules are installed by a local administrator (<code class="filename">/usr/lib/perl5/site_perl/5.8.5</code>). The packages distributed within SUSE Linux use the path defined by <code class="systemitem">%perl_vendorlib</code> instead (see below).<br />
<br />
=== %perl_vendorarch ===<br />
<br />
This macro is substituted by the path where architecture-specific parts of Perl modules are installed by a Linux vendor (<code class="filename">/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi</code>). The macro is typically used in the file list. This example comes from the package <code class="systemitem">perl-URI</code><nowiki>:</nowiki><br />
<br />
%files<br />
[...]<br />
%perl_vendorarch/auto/URI<br />
<br />
This path has been used since SL 9.0. Until then, the Perl modules were installed below <code class="filename">/usr/lib/perl5/site_perl</code> using the macro <code class="systemitem">%perl_sitearch</code>. The directory <code class="filename">site_perl</code> is now intended for modules installed by a local administrator (see above at <code class="systemitem">%perl_sitearch</code>).<br />
<br />
=== %perl_vendorlib ===<br />
<br />
This macro substitutes for the path where architecture-independent parts of Perl modules are installed by a Linux vendor (<code class="filename">/usr/lib/perl5/vendor_perl/5.8.5</code>). The macro is typically used in the file list. This example comes from the package <code class="systemitem">perl-URI</code><nowiki>:</nowiki><br />
<br />
%files<br />
[...]<br />
%perl_vendorlib/URI.pm<br />
%perl_vendorlib/URI<br />
<br />
This path has been used since SL 9.0. Until then, the Perl modules were installed below <code class="filename">/usr/lib/perl5/site_perl</code> using the macro <code class="systemitem">%perl_sitearch</code>. The directory <code class="filename">site_perl</code> is now intended for modules installed by a local administrator (see above at <code class="systemitem">%perl_sitelib</code>).<br />
<br />
=== %perl_version ===<br />
<br />
This macro is substituted by the version of Perl used for building the package, such as <code class="literal">5.8.5</code>. It is used in packages providing a perl module to define the dependency on Perl.<br />
<br />
It is typically used the following way. This example is taken from the package <code class="systemitem">perl-URI</code><nowiki>:</nowiki><br />
<br />
%perl_requires<br />
<br />
and is expanded this way <nowiki>:</nowiki><br />
<br />
%perl_requires() \<br />
%if 0%{?suse_version} > 0 && 0%{?suse_version} < 1700 \<br />
Requires: perl = %perl_version \<br />
%endif<br />
<br />
=== %py_incdir ===<br />
<br />
This macro substituted by the path where Python header files are installed, such as <code class="filename">/usr/include/python2.3</code>. See [[openSUSE:Packaging_Python]], “Python Modules” for an example.<br />
<br />
=== %py_libdir ===<br />
<br />
This macro is substituted by the path where Python modules are installed, such as <code class="filename">/usr/lib/python2.3</code>. See [[openSUSE:Packaging_Python]], “Python Modules” for an example.<br />
<br />
=== %py_requires ===<br />
<br />
This macro is substituted by <code class="systemitem">PreReq</code> and <code class="systemitem">BuildRequires</code> tags. This defines dependency on the same python major version as is used during build. See [[openSUSE:Packaging_Python]], “Python Modules” for an example.<br />
<br />
=== %py_sitedir ===<br />
<br />
This macro is substituted by the path where all extra Python modules all installed, such as <code class="filename">/usr/lib/python2.3/site-packages</code>. See [[openSUSE:Packaging_Python|“Python Modules”]] for an example.<br />
<br />
=== %py_ver ===<br />
<br />
This macro is substituted by the Python major version, such as <code class="literal">2.3</code>. See [[openSUSE:Packaging_Python]], “Python Modules” for an example.<br />
<br />
=== %remove_and_set ===<br />
<br />
This macro is used to remove obsolete sysconfig variables.<br />
<br />
Synopsis:<br />
<br />
<span>'''%remove_and_set'''</span> [<code class="option">-ny</code>] [''<code>sysconfig_filename</code>''] ''<code>variable</code>''...<br />
<br />
The macro <span>'''%remove_and_set'''</span> removes variables from <code class="filename">/etc/rc.config</code> and <code class="filename">/etc/sysconfig/sysconfig_filename</code> and sets them in the actual environment for further handling. If a variable is not found, it is set to <code class="literal">"no"</code> by default or it is set to <code class="literal">“yes”</code> if the option <code class="option">-y</code> is used.<br />
<br />
Options:<br />
<br />
* <code class="option">-n</code> defines that the parameter ''<code>sysconfig_filename</code>'' is used (see below).<br />
* <code class="option">-y</code> sets the default value to <code class="literal">“yes”.</code><br />
<br />
Parameters:<br />
<br />
* ''<code>sysconfig_filename</code>'' creates a pair with the option <code class="option">-n</code> and defines the syconfig filename. The package name (<span>'''%name'''</span>) is used as the sysconfig filename otherwise.<br />
* ''<code>variable</code>'' defines the name of a variable to remove. Multiple variables can be defined.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">postfix</code><nowiki>:</nowiki><br />
%{fillup_and_insserv -y postfix}<br />
if [ -f etc/sysconfig/mail ]; then<br />
. etc/sysconfig/mail<br />
if [ -n "$NULLCLIENT" ]; then<br />
RCTMP="etc/sysconfig/postfix.$$"<br />
sed "s/^POSTFIX_NULLCLIENT.*/POSTFIX_NULLCLIENT=\"$ \"/" \<br />
etc/sysconfig/postfix &gt;"$RCTMP"<br />
mv "$RCTMP" etc/sysconfig/postfix<br />
fi<br />
fi<br />
%{remove_and_set -n mail NULLCLIENT}<br />
This code sets the variable <code class="systemitem">POSTFIX_NULLCLIENT</code> from <code class="filename">etc/sysconfig/postfix</code> to the value of the obsolete variable <code class="systemitem">NULLCLIENT</code> from <code class="filename">etc/sysconfig/mail</code>. Then the obsolete variable is removed.<br />
# This example is taken from the package <code class="systemitem">autofs</code><nowiki>:</nowiki><br />
<nowiki>%post<br />
%{fillup_and_insserv autofs}<br />
# needed for update from 7.3 and before<br />
%{remove_and_set USE_NIS_FOR_AUTOFS USE_NISPLUS_FOR_AUTOFS}<br />
if [ $USE_NIS_FOR_AUTOFS == "yes" ] ; then<br />
if `grep "^automount:" etc/nsswitch.conf | \<br />
grep -vqw nis` ; then<br />
sed "s/^automount:.*/&amp; nis/" &lt; etc/nsswitch.conf \<br />
&gt;etc/nsswitch.conf.new<br />
mv etc/nsswitch.conf.new etc/nsswitch.conf<br />
fi<br />
fi<br />
if [ $USE_NISPLUS_FOR_AUTOFS == "yes" ] ; then<br />
if `grep "^automount:" etc/nsswitch.conf | \<br />
grep -vqw nisplus` ; then<br />
sed "s/^automount:.*/&amp; nisplus/" &lt; etc/nsswitch.conf \<br />
&gt; etc/nsswitch.conf<br />
mv etc/nsswitch.conf.new etc/nsswitch.conf<br />
fi<br />
fi</nowiki><br />
The obsolete variables <code class="systemitem">USE_NIS_FOR_AUTOFS</code>, <code class="systemitem">USE_NISPLUS_FOR_AUTOFS</code> are removed from <code class="filename">/etc/rc_config</code> and <code class="filename">/etc/sysconfig/autofs</code> and the removed values are used to modify an actual configuration.<br />
The detected values cannot be used in the previous example because the macro <span>'''%remove_and_set'''</span> is able to set only values <code class="literal">“yes”</code> or <code class="literal">“no”</code> in the environment.<br />
<br />
=== %restart_on_update ===<br />
<br />
This macro restarts a service after an update.<br />
<br />
Synopsis:<br />
<br />
<span>'''%restart_on_update'''</span> ''<code>service</code>''...<br />
<br />
The macro <span>'''%restart_on_update'''</span> runs <span>'''systemctl try-restart'''</span> if not running under YaST in the <code class="systemitem">instsys</code> mode. Multiple services can be defined.<br />
<br />
This macro is usually used in the <code class="systemitem">%postun</code> script of packages providing a service. However, it cannot be used if it cannot be guaranteed that the service will work after an update.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">rsync</code><nowiki>:</nowiki><br />
%postun<br />
%restart_on_update rsyncd<br />
%insserv_cleanup<br />
# This example is taken from the package <code class="systemitem">samba</code> (restarts two services):<br />
%postun<br />
%restart_on_update nmb smb<br />
%insserv_cleanup<br />
<br />
=== %run_ldconfig (<span style="font-weight:bold; color:red">deprecated</span>) ===<br />
<br />
This macro runs <span>'''ldconfig'''</span> if not running from YaST. YaST runs <span>'''ldconfig'''</span> itself after all selected packages are installed.<br />
<br />
It was used in both <code class="systemitem">%post</code> and <code class="systemitem">%postun</code> scripts of packages providing a library. <span style="font-weight:bold; color:red">The macro is deprecated and should not be used anymore</span>. Instead, <span>'''/sbin/ldconfig'''</span> should be called directly both scripts, even from YaST, to keep from breaking other <code class="systemitem">%post</code> scripts. It could be done the following way:<br />
<br />
%post -p /sbin/ldconfig<br />
%postun -p /sbin/ldconfig<br />
<br />
If <span>'''ldconfig'''</span> is not the only command, the <code class="option">-p</code> option is not usable. For example, the <code class="systemitem">%post</code> script could look like:<br />
<br />
%post<br />
/sbin/ldconfig<br />
[...]<br />
<br />
(Keep in mind that RPM will interpret "[...]" to include any comments, which might be a surprise if they were intended for the next section of the spec file!)<br />
<br />
=== %run_permissions (<span style="font-weight:bold; color:red">deprecated</span>) ===<br />
<br />
This macro runs ''SuSEconfig --module permissions'' to adjust file permissions<br />
according to the system's security setting.<br />
<br />
Note: Running SuSEconfig has the disadvantage that permissions of<br />
all installed files are adjusted, not just the ones that belong to<br />
the package. Therefore this macro is <span style="font-weight:bold; color:red">deprecated</span> since openSUSE 11.4, use [[#%set_permissions|%set_permissions]] instead.<br />
<br />
''%run_permissions'' needs to be called in the ''%post'' script of packages<br />
that install files handled by ''/etc/permissions.*''. The ''permissions''<br />
package needs to be in ''PreReq'' so ''SuSEconfig.permissions'' is guaranteed<br />
to be available at install time.<br />
<br />
In addition the macro<br />
[[#%verify_permissions|%verify_permissions]]<br />
needs to be called as ''%verifyscript''<br />
<br />
Example:<br />
<br />
PreReq: permissions<br />
[...]<br />
%post<br />
%run_permissions<br />
<br />
=== %service_add_pre ===<br />
<br />
Needs to be called in %pre section of packages that install systemd<br />
service. Pass the list of service files as parameters.<br />
<br />
%pre<br />
%service_add_pre demo.service demo1.service<br />
<br />
=== service_add_post ===<br />
<br />
Needs to be called in %post section of packages that install systemd<br />
service. Pass the list of service files as parameters.<br />
<br />
%post<br />
%service_add_post demo.service demo1.service<br />
<br />
=== service_del_preun ===<br />
<br />
Needs to be called in %preun section of packages that install systemd<br />
service. Pass the list of service files as parameters.<br />
<br />
%preun<br />
%service_del_preun demo.service<br />
<br />
=== %service_del_postun ===<br />
<br />
Needs to be called in %postun section of packages that install systemd<br />
service. Pass the list of service files as parameters.<br />
<br />
%postun<br />
%service_del_postun demo.service<br />
<br />
=== %set_permissions ===<br />
<br />
This macro adjusts permissions of the specified files according to the system's security setting.<br />
<br />
Available since openSUSE 11.4<br />
<br />
''%set_permissions'' needs to be called in the ''%post'' script of packages<br />
that install files handled by ''/etc/permissions.*''. The ''permissions''<br />
package needs to be in ''PreReq'' so ''chkstat'' is guaranteed to be available<br />
at install time. The parameter is the name of the permissions config file of<br />
the package (usually identical to the package name).<br />
<br />
In addition the macro<br />
[[#%verify_permissions|%verify_permissions]]<br />
needs to be called as ''%verifyscript''<br />
<br />
Example:<br />
<br />
PreReq: permissions<br />
[...]<br />
%post<br />
%set_permissions /bin/ping<br />
<br />
=== %sles_version ===<br />
<br />
This macro expands to the version of SLES where the package is built. It is <code class="literal">”7”</code> for SLES7, <code class="literal">”8”</code> for SLES8, etc. It is <code class="literal">”0”</code> when not building on SLES.<br />
<br />
See also <code class="systemitem">[[#%suse_version|%suse_version]]</code> and <code class="systemitem">[[#%ul_version|%ul_version]]</code>.<br><br />
And [[openSUSE:Build Service cross distribution howto#Detect_a_distribution_flavor_for_special_code]]<br />
<br />
This example is taken from the package <code class="systemitem">pam-modules</code><nowiki>:</nowiki><br />
<br />
<nowiki>%install<br />
[...]<br />
# On UL or SLES, we have other defaults<br />
%if %sles_version &gt;= 8<br />
cp %_sourcedir/pam_pwcheck.conf.sles \<br />
%buildroot/etc/security/pam_pwcheck.conf<br />
%endif</nowiki><br />
<br />
=== %stop_on_removal ===<br />
<br />
This macro stops a service after a package is removed.<br />
<br />
Synopsis:<br />
<br />
<span>'''%stop_on_removal'''</span> ''<code>service</code>''...<br />
<br />
The macro <span>'''%stop_on_removal'''</span> runs <span>'''/etc/init.d/service stop'''</span> if not running from YaST in the instsys mode. Multiple services can be defined.<br />
<br />
Each package providing a service that can be stopped should call this macro on all services in the <code class="systemitem">%preun</code> script.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">rsync</code><nowiki>:</nowiki><br />
%preun<br />
%stop_on_removal rsyncd<br />
# This example is taken from the package <code class="systemitem">samba</code> (stops two services):<br />
%preun<br />
%stop_on_removal smb nmb<br />
<br />
=== %suse_update_config ===<br />
<br />
This macro updates some auto-stuff related files.<br />
<br />
Usage:<br />
<br />
<span>'''%suse_update_config'''</span> [<code class="option">-fcl</code>] [''<code>dir</code>'' ...]<br />
<br />
This macro takes the following actions for the current directory and all directories given as parameters:<br />
<br />
* <code class="filename">config.guess</code> and <code class="filename">config.sub</code> are overwritten by their most current versions from <code class="filename">/usr/share/automake*/</code>.<br />
* <code class="filename">depcomp</code> and <code class="filename">missing</code> are added if not present in the processed directory but present in <code class="filename">/usr/share/automake*/</code>.<br />
* <code class="filename">ltconfig</code> and <code class="filename">ltmain.sh</code> are patched to accept both <code class="literal">linux-gnu</code> and <code class="literal">linux</code>.<br />
* <code class="filename">/lib</code> is replaced by <code class="filename">/%_lib</code> in some occurrences in both <code class="filename">ltconfig</code> and <code class="filename">ltmain.sh</code>.<br />
<br />
This macro should be called in all packages using the problematic files. However, it is not needed when <span>'''autoreconf'''</span> or <span>'''aclocal'''</span>, <span>'''libtoolize'''</span>, <span>'''automake'''</span>, and <span>'''autoconf'''</span> is used, because they are able to update the needed things.<br />
<br />
This macro should be tested for existence when used in the section <code class="systemitem">%prep</code>. This allows running this section on other distributions where the macro is not available. See the examples below.<br />
<br />
Options:<br />
<br />
* <code class="option">-c</code> — do not update <code class="filename">config.guess</code>, <code class="filename">config.sub</code>, <code class="filename">depcomp</code> and <code class="filename">missing</code><br />
* <code class="option">-f</code> — force, ignore time stamps<br />
* <code class="option">-l</code> — do not update <code class="filename">ltconfig</code> and <code class="filename">ltmain.sh</code><br />
<br />
Parameters:<br />
<br />
* ''<code>dir</code>'' defines an additional directory where the files should be updated. Multiple directories can be defined.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">libunicode</code><nowiki>:</nowiki><br />
%prep<br />
%setup<br />
%patch -P 1 -p1<br />
<br />
%build<br />
%{?suse_update_config:%{suse_update_config -f}}<br />
%configure<br />
make %{?_smp_mflags}<br />
# This example is taken from the package <code class="systemitem">xosview</code> (updates files in both <code class="filename">./</code> and <code class="filename">./config</code> directories):<br />
%prep<br />
%setup -q<br />
%patch -P 1 -p0 -b ".serial"<br />
[...]<br />
%{?suse_update_config:%{suse_update_config -f config}}<br />
<br />
%build<br />
%ifarch ppc<br />
export SYSTEM=powerpc-suse-linux<br />
%else<br />
export SYSTEM=%_target_cpu-suse-linux<br />
%endif<br />
(cd config/; autoconf; cp configure ../)<br />
./configure $SYSTEM \<br />
--with-x \<br />
--enable-auto-depend \<br />
--enable-linux-syscalls \<br />
--prefix=/usr/X11R6 \<br />
--disable-linux-memstat<br />
make clean<br />
<br />
=== %suse_update_desktop_file ===<br />
<br />
This macro updates .desktop files.<br />
<br />
Synopsis:<br />
<br />
<span>'''%suse_update_desktop_file'''</span> <code class="option">-c</code> ''<code>filename</code>'' ''<code>name</code>'' ''<code>generic-name</code>'' ''<code>exec</code>'' ''<code>icon</code>'' [''<code>category</code>'']...<br />
<br />
<span>'''%suse_update_desktop_file'''</span> [<code class="option">-inru</code>] [<code class="option">-D</code> ''<code>docpath</code>''] [<code class="option">-N</code> ''<code>name</code>''] [<code class="option">-G</code> ''<code>genericname</code>''] ''<code>filename</code>'' [''<code>category</code>'']...<br />
<br />
The macro <span>'''%suse_update_desktop_file'''</span> updates translations, adds categories (needed to sort menus), and does some sanity checks in the given .desktop file. It requires the package <code class="systemitem">update-desktop-files</code>.<br />
<br />
Each package providing a .desktop file should call this macro for all basenames of .desktop files (without .desktop suffix) in the section <code class="systemitem">%install</code> after the desktop-files have been installed under <code>/usr/share/applications</code> or <code>/etc/xdg/autostart</code>. Do not forget to mention the package <code class="systemitem">update-desktop-files</code> in the [[openSUSE:Specfile_guidelines#BuildRequires|BuildRequires]] tag. It is included in the meta packages:<br />
<br />
* <code class="systemitem">gnome2-devel-packages</code><br />
* <code class="systemitem">gtk2-devel-packages</code><br />
* <code class="systemitem">kde3-devel-packages</code><br />
* <code class="systemitem">qt3-devel-packages</code><br />
* <code class="systemitem">yast2-core-devel-packages</code><br />
* <code class="systemitem">yast2-devel-packages</code><br />
<br />
The package <code class="systemitem">update-desktop-files</code> need not be explicitly mentioned in the <code class="systemitem">BuildRequires</code> tag if any of these meta packages is already there.<br />
<br />
Options:<br />
<br />
* <code class="option">-c</code> ''<code>filename</code>'' ''<code>name</code>'' ''<code>comment</code>'' ''<code>exec</code>'' ''<code>icon</code>'' [''<code>category</code>''] — Create a new .desktop file initialized by the parameters ''<code>filename</code>'', ''<code>name</code>'', ''<code>comment</code>'', ''<code>exec</code>'', ''<code>icon</code>'', and ''<code>category</code>'' the following way:<br />
[Desktop Entry]<br />
Name=name<br />
GenericName=comment<br />
Type=Application<br />
Exec=exec<br />
Icon=icon<br />
Categories=category;....<br />
and install it as <code class="filename">%buildroot/usr/share/applications/filename.desktop</code>.<br />
* <code class="option">-i</code> — Search <code class="filename">%_sourcedir</code> and <code class="filename">/usr/share/update-desktop-files/templates</code> for the template <code class="filename">filename.desktop</code> and install it as <code class="filename">%buildroot/usr/share/applications/filename.desktop</code>.<br />
* <code class="option">-n</code> — Do not update translations. It is useful if the lines <code class="literal">Name=</code> and <code class="literal">GenericName=</code> contain a string that cannot be translated.<br />
* <code class="option">-r</code> — Replace categories defined in the .desktop file with the new one defined by the parameter category. By default, the new categories are only added after the already included categories.<br />
* <code class="option">-u</code> — Add the line <code class="literal">X-SuSE-Unimportant=true</code> to the .desktop file.<br />
* <code class="option">-D</code>''<code>docpath</code>'' Sets the .desktop file DocPath entry.<br />
* <code class="option">-N</code>''<code>name</code>'' Sets the .desktop file Name entry.<br />
* <code class="option">-G</code>''<code>genericname</code>'' Sets the .desktop file GenericName entry.<br />
<br />
Parameters:<br />
<br />
* ''<code>filename</code>'' defines a filename of the .desktop file. The value is the filename without the suffix <code class="filename">.desktop</code>.<br />
* ''<code>category</code>'' is used to add or modify the line <code class="literal">Categories=</code> in the .desktop file. This line is used to sort entries into submenus.<br />
<br />
Examples:<br />
<br />
# This example is taken from the package <code class="systemitem">kvim</code> (also shows the related parts of <code class="systemitem">BuildRequires</code> tag and <code class="systemitem">%files</code> section):<br />
<br />
BuildRequires: ... update-desktop-files ...<br />
<br />
%install<br />
[...]<br />
%suse_update_desktop_file KVim TextEditor<br />
<br />
%files<br />
[...]<br />
/opt/kde3/share/applnk/*/*.desktop<br />
This code updates translations in the already installed <code class="filename">/opt/kde3/share/applnk/Editors/KVim.desktop</code>. As the original .desktop file does not contain the line <code class="literal">Categories=</code>, it is initialized to <code class="literal">Categories=TextEditor;</code>.<br />
# This example is from the package <code class="systemitem">crack-atack</code><nowiki>: (also shows the related parts of </nowiki><code class="systemitem">BuildRequires</code> tag, <code class="systemitem">Source</code> tags and <code class="systemitem">%files</code> section):<br />
<br />
BuildRequires: ... update-desktop-files ...<br />
<br />
Source1: %name.desktop<br />
Source2: %name-xtreme.desktop<br />
[...]<br />
<br />
%install<br />
[...]<br />
%suse_update_desktop_file -i %name Game ArcadeGame<br />
%suse_update_desktop_file -i %name-xtreme Game ArcadeGame<br />
<br />
%files<br />
[...]<br />
/usr/share/applications/%name.desktop<br />
/usr/share/applications/%name-xtreme.desktop<br />
This code finds the two templates in <code class="filename">%_sourcedir</code> and installs them into <code class="filename">/usr/share/applications</code>. See the section <code class="systemitem">%files</code> for the final path. It also updates translations. As the templates do not contain the line <code class="literal">Categories=</code>, it is initialized to <code class="literal">Categories=Game;ArcadeGame;</code>.<br />
# This example is taken from the package <code class="systemitem">koffice</code><nowiki>:</nowiki><br />
%install<br />
[...] <br />
%suse_update_desktop_file kugar Office Viewer<br />
%suse_update_desktop_file -r karbon Graphics VectorGraphics<br />
%suse_update_desktop_file kivio Office FlowChart<br />
%suse_update_desktop_file kpresenter Office Presentation<br />
%suse_update_desktop_file kchart Office FlowChart<br />
%suse_update_desktop_file kspread Office Spreadsheet<br />
%suse_update_desktop_file -u KThesaurus Office<br />
%suse_update_desktop_file -u kformula Office<br />
%suse_update_desktop_file kword Office WordProcessor<br />
%suse_update_desktop_file -u koshell Office Core-Office<br />
This code updates translations in the already installed desktop files. In addition, for example, <code class="filename">Kthesaurus.desktop</code> is marked as unimportant and the obsolete line <code class="literal">Categories=</code> is replaced with <code class="literal">Categories=VectorGraphics;</code> in <code class="filename">karbon.dekstop</code>.<br />
# This example is taken from the package <code class="systemitem">qbrew</code><nowiki>:</nowiki><br />
%suse_update_desktop_file -c qbrew QBrew \<br />
"A homebrewer's recipe calculator" \<br />
qbrew "" Science<br />
# This code creates a .desktop file:<br />
[Desktop Entry]<br />
Name=QBrew<br />
GenericName=A homebrewer's recipe calculator<br />
Type=Application<br />
Exec=qbrew<br />
Icon=<br />
Categories=Science;<br />
Then it adds available translations and installs it as <code class="filename">/usr/share/applications/qbrew.desktop</code>.<br />
<br />
==== Known issues ====<br />
# The setting<br />
Categories=Application;Office;<br />
is typical for Fedora packages, but yields to build failures in SUSE. The error message says '''No sufficient Category definition'''.<br />
You need to use the '-r' flag to remove the offending category 'Application' and replace it by only [[openSUSE:Packaging_desktop_menu_categories|allowed categories]]. The -r option must come before the name to be effective.<br />
%suse_update_desktop_file -u -r -G 'OCR Suite' %{name} Office Graphics Scanning OCR<br />
<br />
<br />
<br />
If this command leads to an error message '''/var/tmp/rpm-tmp.mkeCpx: line 54: fg: no job control''' please try adding<br />
BuildRequires: update-desktop-files<br />
<br />
# The setting<br />
Version=0.5<br />
is typical for Fedora packages, but yields a warning with SUSE. Manual patching is required to resolve this warning.<br />
<br />
=== %suse_version ===<br />
<br />
This macro expands to the version of SUSE Linux / openSUSE where the package is built. It is "1000" for SUSE Linux 10.0, "1020" for openSUSE 10.2 and so on.<br />
<br />
See also <code class="systemitem">[[#%sles_version|%sles_version]]</code> and <code class="systemitem">[[#%ul_version|%ul_version]]</code>.<br><br />
And [[openSUSE:Build Service cross distribution howto#Detect_a_distribution_flavor_for_special_code]]<br />
<br />
It can be used to used for version check<br />
..<br />
%if 0%{?suse_version} >= 1110<br />
BuildRequires: new-package-introduced-in-11.0<br />
%endif<br />
..<br />
<br />
Or to check if the package is being built for openSUSE<br />
<br />
..<br />
%if 0%{?suse_version}<br />
BuildRequires: libqt4-devel<br />
%else<br />
BuildRequires: qt4-devel<br />
%endif<br />
...<br />
<br />
=== %tcl_version ===<br />
<br />
This macro expands to the version of Tcl used on the product where the package is built. It is <code class="literal">"8.3"</code> for tcl-8.3, <code class="literal">“8.4”</code> for tcl-8.4, etc.<br />
<br />
This example is taken from the package <code class="systemitem">vkeybd</code><nowiki>:</nowiki><br />
<br />
%build<br />
make PREFIX="%_prefix" \<br />
TCL_VERSION="%tcl_version" \<br />
XLIB="-L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11" \<br />
USE_LADCCA=1<br />
<br />
=== %ul_version ===<br />
<br />
This macro expands to a version of United Linux where the package is built. It is <code class="literal">“1”</code> for UL 1.0 and <code class="literal">“0”</code> when not building on UL.<br />
<br />
See also <code class="systemitem">[[#%sles_version|%sles_version]]</code> and <code class="systemitem">[[#%suse_version|%suse_version]]</code>.<br />
<br />
This example is taken from the package <code class="systemitem">installation-images</code><nowiki>:</nowiki><br />
<br />
%build<br />
[...]<br />
%ifarch %ix86<br />
themes="SuSE Home"<br />
%else<br />
themes=SuSE<br />
%endif<br />
%if %ul_version &gt; 0<br />
themes=UnitedLinux<br />
%else<br />
%if %sles_version &gt; 0<br />
themes="SuSE-SLES"<br />
%endif<br />
<br />
=== %verify_permissions ===<br />
<br />
This macro verifies permissions of files handled via<br />
''/etc/permissions.*'' according to the system's security settings.<br />
<br />
Permissions attributes in the package should reflect the setting of<br />
the ''secure'' level (/etc/permissions.secure).<br />
<br />
To prevent rpm from complaining about the packaged permission<br />
settings affected files need to be tagged accordingly with e.g.<br />
''%verify(not mode)''.<br />
<br />
Usage:<br />
<br />
'''%verify_permissions''' [<code class="option">-f</code> ''<code>filelist</code>''] [<code class="option">-e</code> ''<code>file</code>''] ...<br />
<br />
''%verify_permissions'' needs to be used together with<br />
[[#%run_permissions|%run_permissions]] or [[#%set_permissions|%set_permissions]]<br />
<br />
<br />
Options:<br />
<br />
* <code class="option">-e</code> file — specifies which file to check<br />
* <code class="option">-f</code> filelist — specifies a file with a list of files to check (useful if there are many).<br />
<br />
Both options can be repeated.<br />
<br />
Example 1, files with variable mode:<br />
<br />
%verifyscript<br />
%verify_permissions -e /usr/bin/foo -e /bin/bar<br />
[...]<br />
%files<br />
%defattr(-,root,root)<br />
%verify(not mode) %attr(0755,root,root) /usr/bin/foo<br />
%verify(not mode) %attr(0755,root,root) /bin/bar<br />
<br />
<br />
Example 2, file with variable mode and user:<br />
<br />
%verifyscript<br />
%verify_permissions -e /etc/foo<br />
[...]<br />
%files<br />
%defattr(-,root,root)<br />
%verify(not mode user) %attr(0600,joe,root) /etc/foo<br />
<br />
Example 3, file with support for fscaps or setuid<br />
<br />
%verifyscript<br />
%verify_permissions -e /bin/foo<br />
[...]<br />
%files<br />
%defattr(-,root,root)<br />
%verify(not mode caps) %attr(4755,root,root) /bin/foo<br />
<br />
=== %create_subdir_filelist / %create_exclude_filelist ===<br />
<code>%create_subdir_filelist</code> macro helps to create sub-packages by looking at what's installed from a specified sub-directory (and a matching doc/ directory) of the source. It requires a parameter <code class="option">-d <directory></code> and creates a file list called filelists/<directory> unless a parameter <code class="option">-f <filelistname></code> is given which then let it appends to filelists/<filelistname>. If a <code class="option">-v <develfilelistname></code> parameter is given, development files like headers, cmake definitions and .so symlinks will be written to filelists/<develfilelistname> instead. <br />
<br />
<code>%create_exclude_filelist</code> creates an exclude file list from all file lists that were created by <code>%create_subdir_filelist</code>. It is intended to be used for the main package, to ensure that files that were moved into a subpackage are not packaged twice.<br />
<br />
Usage in ''koffice2.spec'' (shortened):<br />
<br />
..<br />
%install<br />
cd build<br />
%make_install<br />
%create_subdir_filelist -d kplato -v devel<br />
%create_subdir_filelist -d kword -v devel<br />
%create_subdir_filelist -d filters/kword -f kword -v devel<br />
..<br />
cd ..<br />
sed -ri s,.*/usr/share/doc/kde/HTML/en/.*,, filelists/*<br />
%create_exclude_filelist<br />
rm -rf $RPM_BUILD_ROOT/usr/share/doc/kde/HTML/en<br />
..<br />
%files devel -f filelists/devel<br />
..<br />
%files kplato -f filelists/kplato<br />
..<br />
%files kword -f filelists/kword<br />
..<br />
%files -f filelists/exclude<br />
<br />
This example also shows how it's optionally possible to merge/change the automatically created file lists.<br />
<br />
=== %make_jobs ===<br />
This is just a macro that calls <code>%make</code> with the right jobs parameter, if icecream is in use. This is for local test builds on a multiprocessor machine and/or the Factory builds, which use distributed buildpower to speed up compilation.<br />
<br />
=== %glib2_gsettings_schema ===<br />
{{Info|Macros described in this paragraph are relevant only for openSUSE Leap 42.3 and older. Newer releases, including Tumbleweed, do not need these macros. They use [https://lists.opensuse.org/opensuse-factory/2017-06/msg00898.html RPM's file triggers] instead.}}<br />
Some applications might add configuration files to <code>%{_datadir}/glib-2.0/schemas/</code>. You need to not ship them in compiled form, but rather compile after installation and uninstallation. If the Makefile has no switch you need to manually remove them: <code>rm %{buildroot}%{_datadir}/glib-2.0/schemas/gschemas.compiled</code>.<br />
<br />
Put<br />
<pre><br />
%glib2_gsettings_schema_requires<br />
</pre><br />
near the <code>BuildRequires:</code> section and<br />
<br />
<pre><br />
%post<br />
%glib2_gsettings_schema_post<br />
<br />
%postun<br />
%glib2_gsettings_schema_postun<br />
</pre><br />
<br />
below <code>%install</code><br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Paketbauvereinbarungen zu RPM-Makros]]<br />
[[ru:Сборка пакетов/Соглашение по стилю RPM-пакетов/Макросы RPM]]<br />
[[zh:openSUSE:Packaging_Conventions_RPM_Macros]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Specfile_guidelines&diff=123420openSUSE:Specfile guidelines2018-02-08T09:24:28Z<p>Okurz: /* Documentation files */ Add hint how to handle license files</p>
<hr />
<div>{{Packaging_docnav}}<br />
{{Intro|RPM itself places very few limitations on what you can do in spec files, so they can quickly become difficult to read and maintain. These guidelines try to minimize the variations in specific areas so spec files are maintainable.}}<br />
<br />
==General Rules==<br />
All spec files must be comprehensible. If other packagers are unable to read the spec file, it will be impossible to perform a review and to collaborate on the package.<br />
<br />
===Specfile Template===<br />
When writing a package from scratch, you should base your spec file on the spec file template (see [http://software.opensuse.org/search?q=rpmdevtools rpmdevtools]). A basic setup for a package MYPACK can be generated by<br />
<br />
{{Shell|1=[https://build.opensuse.org/package/show?package=osc-plugin-install&project=openSUSE%3ATools osc-plugin-install] devel:tools rpmdevtools}}<br />
<br />
or (change URL according to your version of openSUSE)<br />
<br />
{{Shell|sudo zypper -p obs://devel:tools/openSUSE_Leap_42.2 -v in osc rpmdevtools}}<br />
<br />
Once you have done so:<br />
<br />
# A folder already created for a project, like home:user.<br />
cd MYPROJECT<br />
# Create a new package.<br />
osc mkpac MYPACK<br />
cd MYPACK<br />
# Download source tarball from upstream (the group that develops the code).<br />
wget http://upstream.example.org/source/.../MYPACK-1.0.tar.gz<br/><br />
# Create a spec file template for MYPACK.<br />
rpmdev-newspec -t lib MYPACK<br />
# Record changes to the MYPACK package.<br />
osc vc<br />
# Edit spec file.<br />
vim MYPACK.spec<br />
<br />
and then later:<br />
<br />
# Test it builds correctly<br />
osc build<br />
# Checkin/commit to OBS server<br />
osc ci<br />
<br />
'''Please try to conform to this template as much as possible.'''<br />
<br />
It is not the only way to write a spec file, but doing so makes it easier for QA to spot mistakes and quickly understand what you are trying to do. <br />
<br />
Spec files for specific languages can often be created with specialized tools like <code>cpanspec</code> or <code>gem2rpm-opensuse</code>. See also<br />
<br />
* [[openSUSE:Packaging_Perl]]<br />
* [[openSUSE:Packaging_Python]]<br />
* [[openSUSE:Packaging_Ruby]]<br />
<br />
===Specfile Encoding===<br />
'''Use ASCII characters unless necessary (if so, save as UTF-8).'''<br />
<br />
Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you are in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png an ASCII chart].<br />
<br />
===Specfile Licensing===<br />
'''For legal reasons, spec files must have a license header.'''<br />
<br />
Use the following template:<br />
<br />
#<br />
# spec file for package $YOUR_PACKAGE<br />
#<br />
# Copyright (c) $CURRENT_YEAR $YOUR_NAME_WITH_MAIL_ADDRESS<br />
#<br />
# All modifications and additions to the file contributed by third parties<br />
# remain the property of their copyright owners, unless otherwise agreed<br />
# upon. The license for this file, and modifications and additions to the<br />
# file, is the same license as for the pristine package itself (unless the<br />
# license for the pristine package is not an Open Source License, in which<br />
# case the license is the MIT License). An "Open Source License" is a<br />
# license that conforms to the Open Source Definition (Version 1.9)<br />
# published by the Open Source Initiative.<br />
<br />
# Please submit bugfixes or comments via http://bugs.opensuse.org/<br />
#<br />
<br />
If there is no such header yet, you can run <tt>osc service format_spec_file</tt> to have one added automatically for you.<br />
<br />
===Macros===<br />
'''Use macros instead of hard-coded directory names.'''<br />
<br />
A list of macros and what they do is available at [[openSUSE:Packaging Conventions RPM Macros]]. Having macros in a <code>Source:</code> or <code>Patch:</code> line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. If you need to determine the actual string when it contains macros, you can use rpm. For example, to determine the actual <code>Source:</code> value, you can run:<br />
<br />
{{Shell|rpm -q --specfile foo.spec --qf "$(grep -i ^Source foo.spec)\n"}}<br />
<br />
Caution: the above command works with <code>%{name}</code> and <code>%{version}</code>, but may fail with user defined macros.<br />
<br />
====Macros vs RPM variables====<br />
rpm re-exports a few of its macros as shell variables implicitly at the start of <tt>%prep</tt>, <tt>%build</tt> and <tt>%install</tt>. Excerpt from <tt>/usr/lib/rpm/macros</tt>:<br />
<br />
<pre><br />
%___build_pre \<br />
RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\<br />
RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\<br />
RPM_OPT_FLAGS=\"%{optflags}\"\<br />
RPM_ARCH=\"%{_arch}\"\<br />
RPM_OS=\"%{_os}\"\<br />
RPM_DOC_DIR=\"%{_docdir}\"\<br />
RPM_PACKAGE_NAME=\"%{name}\"\<br />
RPM_PACKAGE_VERSION=\"%{version}\"\<br />
RPM_PACKAGE_RELEASE=\"%{release}\"\<br />
LANG=C\<br />
unset CDPATH DISPLAY ||:\<br />
%{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\<br />
%{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\<br />
PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\<br />
</pre><br />
<br />
It is technically possible to use either; they will resolve to the same values in all (sensible) scenarios. However, not all macros, such as <tt>%_bindir</tt>, are mapped to a shell variable. Do not mix the two styles in openSUSE packages, as it is bad from a QA and usability point of view.<br />
<br />
RPM macros are expanded before a section is run, and it is slower for variables to be read by sh during runtime.<br />
<br />
====Macros vs shell commands====<br />
For many commonly used shell commands, there is a macro equivalent. For example (excerpt from <tt>/usr/lib/rpm/macros</tt>),<br />
<br />
<pre><br />
%__cat /usr/bin/cat<br />
%__chgrp /usr/bin/chgrp<br />
%__chmod /usr/bin/chmod<br />
%__chown /usr/bin/chown<br />
…<br />
</pre><br />
<br />
These macros provide a better portability for the purpose of non-GNU platforms such as Solaris where the GNU utilities may have names like <tt>gchgrp</tt> instead of <tt>chgrp</tt>). Since non-GNU, and moreover non-Linux environments, is not the target of the openSUSE project at present, the use of macros is deprecated in favor of the more readable shell commands. The spec file cleaner bot even converts macros to their shell command counter part [https://github.com/openSUSE/spec-cleaner/blob/master/spec_cleaner/rpmsection.py automatically].<br />
<br />
==== Conditionals ====<br />
<br />
See [[openSUSE:RPM conditional builds]].<br />
<br />
For a list of version macros for different openSUSE releases, see [[openSUSE:How_to_contribute_to_Leap#RPM_Distro_Version_Macros|openSUSE RPM distro version macros]].<br />
<br />
For example, to detect Leap 42.1:<br />
<br />
%if 0%{?sle_version} == 120100 && 0%{?is_opensuse}<br />
# perform Leap 42.1 specific actions here<br />
%else<br />
# something else<br />
%endif<br />
<br />
For other distributions, see [[openSUSE:Build_Service_cross_distribution_howto]].<br />
<br />
== Preamble ==<br />
===Naming / versioning ===<br />
See [[openSUSE:Package naming guidelines]].<br />
<br />
===Metadata Tags===<br />
* ''AutoReqProv'': should not be used '''unless''' you want to turn off automatic dependency processing.<br />
* ''Source'': an HTTP link should be specified where possible ([[openSUSE:Package source verification]]).<br />
* ''Group'': only package groups listed in the [[openSUSE:Package group guidelines|package group guidelines]] should be used.<br />
* ''BuildRoot'': should always be used, even if newer versions of RPM override it anyway. The preferred path is <code class="filename">%{_tmppath}/%{name}-%{version}-build</code>.<br />
* ''Summary'': should be a short description of what the package is ([[openSUSE:Package_description_guidelines#Summary|summary guidelines]]).<br />
<br />
'''Do not use the following tags:'''<br />
* ''Copyright'': deprecated, use ''License'' instead ([[openSUSE:Packaging_guidelines#Licensing|licensing guidelines]]).<br />
* ''Packager'': rebuilding the RPM package elsewhere forces this value onto the new packager, leading to subsequent confusion about who to contact. The identities of the packagers should be specified with changelog entries instead.<br />
* ''Vendor'': same reason as for ''Packager''. If you want to override the default set by the openSUSE Build Service, use a prjconf-level <code>%define</code>.<br />
<br />
===Description Section(%description)===<br />
See [[openSUSE:Package description guidelines]].<br />
<br />
===Dependencies===<br />
See [[openSUSE:Package dependencies]].<br />
<br />
=== Patches ===<br />
All patches in openSUSE spec files '''SHOULD''' have a comment within the patch file (or above its respective "PatchN:" tag) about its status. For details see [[openSUSE:Packaging Patches guidelines]].<br />
<br />
==Preparation Section (%prep)==<br />
===Quiet %setup===<br />
'''The <code>-q</code> option should be passed to the <code>%setup</code> macro.'''<br />
<br />
This will reduce the size of the build logfile significantly, especially with source archives that extract a lot of files.<br />
<br />
==Build Section (%build)==<br />
=== Compiler flags ===<br />
'''Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration.'''<br />
<br />
In practice, this means <code>%{optflags}</code> (variable: <code>$RPM_OPT_FLAGS</code>, see above) for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there is a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases.<br />
<br />
=== Parallel make ===<br />
'''Whenever possible, invocations of <code>make</code> should be done in parallel.'''<br />
<br />
This should be done using:<br />
<br />
make %{?_smp_mflags}<br />
<br />
This is also available as the <code>%make_build</code> macro, but it is not available for openSUSE 13.2, Leap 42.2 and SLE 12 SP2 (rpm < 4.12).<br />
<br />
This generally speeds up builds, especially on SMP machines. It is much preferable to <code>make %{?jobs:-j%jobs}</code>, as the former allows alternate make flags to be used, such as <code>make -l''N''</code>, and not hardcoding <code>-j''N''</code>. Do make sure, however, that the package builds cleanly this way; some make files do not support parallel building, or have broken dependencies.<br />
<br />
'''If a package does not support parallel building, please explicitly write <code>-j1</code>.'''<br />
<br />
This facilitate grepping for such packages among a group of specfiles. There may be other reasons to use <code>-j1</code>, for example due to otherwise excessive memory usage. (Such a case occurs for example when building Boost for MINGW.) The common workers on build.opensuse.org have only 2 GB RAM assigned as of September 2013. In any case, consider adding a comment saying what led to the use of <code>-j1</code>, whether it is due to broken dependencies, or memory requirements, etc.<br />
<br />
==Install Section (%install)==<br />
'''Running <code>make install</code> must not attempt to chown any files.'''<br />
<br />
Since rpmbuild is run as an unprivileged user, the %install section must not run chown directly or indirectly, for example, `<code>install -o root</code>...`). File ownership shall be set in the later <code>%files</code> section instead.<br />
<br />
'''Use <code>%make_install</code> instead of <code>%makeinstall</code> (without an underscore).'''<br />
<br />
<code>%make_install</code> is a macro equivalent to <code>make install DESTDIR="%{?buildroot}"</code>. Should you be creating a package for older RPM versions (rpm < 4.10, e.g. SLE 11), use the expanded version instead of the macro.<br />
<br />
There is also a second macro with a confusingly similar name, <code>%makeinstall</code> (note: no underscore). '''Avoid''' using this.<br />
<br />
{{Info|1=<br />
In attempt to work with broken software, this macro expands to a very long line which sets all variables to %buildroot plus their final paths, but does not set DESTDIR itself, which causes certain broken software to actually fail.<br />
<br />
An example of this is xapian-core-1.2.17, where:<br />
<br />
<pre><br />
# configure.ac contains:<br />
incdir=$includedir<br />
AC_SUBST(incdir)<br />
# include/Makefile.mk contains:<br />
inc_HEADERS = include/xapian.h<br />
</pre><br />
<br />
With this, %makeinstall's expansion, "make install ... includedir=/buildroot/usr/include" has ''no'' effect since the awkward Makefile requires <code>incdir</code> to be set instead of <code>includedir</code>. Because %makeinstall does not set DESTDIR, xapian-core will try to install xapian.h to the default location, /usr/include, rather than /buildroot/usr/include. A double failure, so to say.<br />
<br />
SUSE's rpm redefines %makeinstall to be the same as %make_install, but as it is conceivable that your specfile may be used on other distro targets, it is best to avoid %makeinstall, and only ever use %make_install or its expanded form.}}<br />
<br />
===Removing the buildroot===<br />
'''Do not attempt to clean or remove the buildroot folder manually.'''<br />
<br />
openSUSE marks it as '''bad coding style''' to have <code>rm -rf %{buildroot}</code> (or <code>rm -rf $RPM_BUILD_ROOT</code>) at the beginning of an <code>%install</code> section like this:<br />
<br />
%install<br />
rm -Rf "%buildroot"<br />
mkdir -p "%buildroot/%_prefix/..." <br />
<br />
or<br />
<br />
%install<br />
rm -Rf "%buildroot"<br />
make install<br />
<br />
{{Info|1=<br />
Why?<br />
<br />
%{buildroot} is normally within <code>/var/tmp</code> and you just opened a trivial race condition to a local attacker on your machine to take over your account (or even root if you build as root). It is better not to `<code>rm -rf %{buildroot}</code>` in <code>%install</code> at all (and rely on <code>%clean</code> to do it).<br />
<br />
Somewhat better would be the following, ('''do not do this''', it is done automatically for you):<br />
<pre><br />
%install<br />
rm -Rf "%buildroot";<br />
mkdir "%buildroot";<br />
mkdir -p "%buildroot/%_prefix/..."<br />
</pre><br />
or<br />
<pre><br />
%install<br />
rm -Rf "%buildroot";<br />
mkdir "%buildroot";<br />
make install<br />
</pre><br />
<br />
In this case the <code>mkdir %buildroot</code> would fail and the build would abort if an attacker tries to replace the buildroot by his own symlink.}}<br />
<br />
==Clean Section (%clean)==<br />
'''The %clean section should not be included -- it is no longer necessary.'''<br />
<br />
The <code>%clean</code> section, if specified, will be run after the binary and source RPMs have been generated. In the Open Build Service, this section is not necessary because chroots and VM environments that are used to build the package are generally torn down anyway. Building packages in environments not started from scratch is usually not supported for openSUSE packages (cf. [https://bugzilla.opensuse.org/show_bug.cgi?id=176528#c4 boo#176528#c4])<br />
<br />
Starting with rpm-4.7/openSUSE_11.3, rpm defaults to "<code>%clean: rm -Rf %{buildroot}</code>" if the <code>%clean</code> section is completely absent from the spec file.<br />
<br />
If a package contains a <code>%clean</code> section, it ''should'' be safe to remove. Check with another maintainer first if you are not sure.<br />
<br />
==Scriptlets==<br />
Great care should be taken when using scriptlets. Some common scriptlets are documented in [[openSUSE:Packaging scriptlet snippets]].<br />
<br />
=== Scriptlet requirements ===<br />
'''Your package has to require everything you use in scriptlets.'''<br />
<br />
The notation for %pre*/%post* scriptlets is as follows:<br />
<br />
Requires(pre): ...<br />
Requires(post): ...<br />
<br />
<font color="red"><br />
'''Scriplets are only allowed to write in certain directories.'''<br />
<br />
Build scripts of packages shall only alter (create, modify, delete) files under <code>%buildroot</code>, <code>%_builddir</code> and valid temporary locations like <code>/tmp</code>, <code>/var/tmp</code> (or <code>%_tmppath</code> as set by the rpmbuild process) according to the following table:<br />
<br />
{| border="1"<br />
|-<br />
! || /tmp, /var/tmp, %_tmppath || %_builddir || %buildroot<br />
|-<br />
|%prep || yes || yes || no<br />
|-<br />
|%build || yes || yes || no<br />
|-<br />
|%install || yes || yes || yes<br />
|-<br />
|%check || yes || yes || no<br />
|-<br />
|%clean || yes || yes || yes<br />
|}<br />
<br />
Further clarification: This must hold true irrespective of the builder's uid.<br />
</font><br />
<br />
== Files Section (%files) ==<br />
openSUSE follows the [https://wiki.linuxfoundation.org/lsb/fhs Filesystem Hierarchy Standard] (FHS) with regards to filesystem layout, which defines where files should be placed on the system. Any deviation from the FHS should be justified in a comment in the spec file.<br />
<br />
===Ownership===<br />
'''Your package should own all files that are installed as part of the <code>%install</code> process.'''<br />
<br />
Packages must not own files already owned by other packages (or, if they legitimately do, the package needs a <code>Conflict:</code> tag). The rule of thumb here is that the first package to be installed should own the files that other packages may rely upon. If you feel that you have a good reason to own a file or that another package owns, then please present that at package review time.<br />
<br />
Directory ownership is a little more complex than file ownership. Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it is desirable for multiple packages to own a directory. Examples of this include:<br />
<br />
<blockquote><br />
'''Forward compatibility with future versions of a package'''<br />
<br />
The package you depend on to provide a directory may choose to own a different directory in a later version and your package will run unmodified with that later version.<br />
<br />
One common example of this is a Perl module. Assume ''perl-A-B'' depends on ''perl-A'' and installs files into <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B</code>. The base Perl package guarantees that it will own <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi</code> for as long as it remains compatible with version 5.8.8, but a future upgrade of the ''perl-A'' package may install into (and thus own) <code>/usr/lib/perl5/vendor_perl/5.9.0/i386-linux-thread-multi/A</code>. So the ''perl-A-B'' package needs to own <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A</code> as well as <code>/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/A/B</code> in order to maintain proper ownership.<br />
<br />
'''Common directory for unrelated packages'''<br />
<br />
Multiple packages may have files in a common directory, but are not necessarily dependent on one of the packages. Take the following example:<br />
<br />
* Package foo-animal-emu puts files into /usr/share/Foo/Animal/Emu<br />
* Package foo-animal-llama puts files into /usr/share/Foo/Animal/Llama<br />
<br />
Neither package depends on the other one. Neither package depends on any other package which owns the <code>/usr/share/Foo/Animal</code> directory. In this case, each package must own the <code>/usr/share/Foo/Animal</code> directory.<br />
</blockquote><br />
<br />
This is to prevent [[Packaging/Unowned_Directories|unowned directories]] from being installed on a system.<br />
<br />
'''An openSUSE package must not contain any duplicate files in the <code>%files</code> listing.'''<br />
<br />
Files packaged more than once (in two or more subpackages) and files containing the same content are both considered to be duplicate files.<br />
<br />
It is recommended to run <code>%fdupes %buildroot</code> (requires adding <code>BuildRequires: fdupes</code>) to smartly eliminate duplicate content by replacing those files with hardlinks to one another.<br />
<br />
===Permissions===<br />
Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every <code>%files</code> section must include a <code>%defattr(...)</code> line. Here is a good default:<br />
<br />
%files<br />
%defattr(-,root,root)<br />
<br />
Unless you have a very good reason to deviate from that, you should use <code>%defattr(-,root,root)</code> for all <code>%files</code> sections in your package. You can use <code>%defattr(-,root,root,0755)</code> to fix permission issues with directories. E.g. when an umask was too tight while unpacking.<br />
<br />
====SUID bits====<br />
'''SUID bits set by default require explicit approval by the SUSE Security Team.'''<br />
<br />
See the [[openSUSE:Package_security_guidelines#Setuid_Binaries|openSUSE package security guidelines]] for more information.<br />
<br />
===Documentation files===<br />
'''Any relevant documentation included in the source distribution should be included in the package.'''<br />
<br />
Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Also pay attention about which subpackage you include documentation in, for example API documentation belongs in the <code>-devel</code> subpackage, not the main one. Or if there is a lot of documentation, consider putting it into a subpackage of its own. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.<br />
<br />
'''Any file marked as <code>%doc</code> must not affect the runtime of the application.'''<br />
<br />
That is, if it is in <code>%doc</code>, the program must run properly if it is not present.<br />
<br />
===License files===<br />
<br />
License files should be marked with <code>%license</code>. See https://lists.opensuse.org/opensuse-factory/2016-02/msg00167.html for reasoning. <code>%doc</code> should be avoided.<br />
<br />
===Configuration files===<br />
Configuration files must be marked as such in packages. As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when ''not'' to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision would not work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.<br />
<br />
Do not use <code>%config</code> or <code>%config(noreplace)</code> under <code>/usr</code>. <code>/usr</code> is deemed to not contain configuration files in openSUSE.<br />
<br />
=== Development files ===<br />
If the software being packaged contains files intended solely for development, those files should be put in a <code>-devel</code> subpackage. The following are examples of file types which should be in <code>-devel</code>:<br />
<br />
* Header files (e.g. .h files)<br />
* Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries, e.g. <code>libfoo.so.3</code>, <code>libfoo.so.3.0.0</code> should not be in <code>-devel</code>.<br />
* pkgconfig files. A reasonable exception is when the main package itself is a development tool, e.g. gcc or gdb.<br />
<br />
Packages containing pkgconfig (<code>.pc</code>) files must utilize <code>BuildRequires: pkg-config</code> so that the proper runtime dependency <code>Requires: pkg-config</code> is added.<br />
<br />
===Locale files===<br />
openSUSE includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the <code>%install</code> section of your spec file, after all of the files have been installed into the buildroot. Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.<br />
<br />
* Packages that use <code>%_datadir/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.<br />
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:<br />
<pre><br />
%_datadir/locale/ar/LC_MESSAGES/%name.mo<br />
%_datadir/locale/be/LC_MESSAGES/%name.mo<br />
%_datadir/locale/cs/LC_MESSAGES/%name.mo<br />
%_datadir/locale/de/LC_MESSAGES/%name.mo<br />
%_datadir/locale/es/LC_MESSAGES/%name.mo<br />
...<br />
</pre><br />
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.<br />
* To include the locale files found by <code>%find_lang</code> you have add the <code>-f %{name}.lang</code> option to the <code>%files</code> section. So the section header should look like <code>%files -f %{name}.lang</code>.<br />
<br />
===Non-ASCII filenames===<br />
'''Filenames that contain non-ASCII characters must be encoded as UTF-8.'''<br />
<br />
Since there is no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8, you can use a utility like <code>convmv</code> (from the convmv package) to convert the filename in your <code>%install</code> section.<br />
<br />
=== Libexecdir ===<br />
<br />
The GNU build system (autotools) offers a [https://www.gnu.org/prep/standards/html_node/Directory-Variables.html "libexecdir" variable/option], which specifies a location "for installing executable programs to be run by other programs rather than by users". Packages often create a subdirectory in libexecdir, for which they may also use the predefined convenient variable <code>${pkglibexecdir}</code> in Automake files; one might find "<code>pkglibexec_PROGRAMS = myhelper</code>" in <code>Makefile.am</code>.<br />
<br />
However, older versions of the [https://wiki.linuxfoundation.org/lsb/fhs Filesystem Hierarchy Standard] (before 3.0) do not include any provision for libexecdir, and the rpm package in (open)SUSE has been changed to expand <code>%_libexecdir</code> to <code>/usr/lib</code> instead of <code>/usr/libexec</code>.<br />
<br />
==Changelog section (%changelog)==<br />
<br />
openSUSE uses a separate changelog file instead of placing it in the spec file.<br />
<br />
See [[openSUSE:Howto_write_good_changes|HOWTO write good changes]] for more information.<br />
<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Richtlinien für Spezifikationsdateien]]<br />
[[it:openSUSE:Linee guida per i file Spec]]<br />
[[ja:openSUSE:Spec ファイルのガイドライン]]<br />
[[zh:openSUSE:Specfile_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_guidelines&diff=123414openSUSE:Packaging guidelines2018-02-08T09:15:06Z<p>Okurz: Correct suggestion regarding the use of %license vs. %doc for license files in packages.</p>
<hr />
<div>{{Packaging docnav}}<br />
{{Intro|The '''Packaging guidelines''' regulate all the nitty gritty details of packaging for the openSUSE distribution. There are general rules, rules about legal aspects of a package, about specific package features and about specific package types.}}<br />
<br />
*It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues — whether they block a package or can be worked on after the package is in the repository. <br />
*The packaging guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the guidelines, please bring the issue to the [http://lists.opensuse.org/opensuse-packaging/ openSUSE-packaging] mailing list.<br />
* Please also note that, in the Build Service, a lot of the rules will be enforced, or warned about, after a successful build, by a tool called ''rpmlint''. The packager should always check its output to be notified of common packaging errors and to get hints where the packaging could be improved. See [[openSUSE:Packaging checks|Packaging checks]] for explanations about most of the rpmlint warnings. That page also contains instructions how false positives can be suppressed.<br />
* If there is a need to change the guidelines please follow the [[openSUSE:Packaging_guidelines_change_process|change process]] as outlined.<br />
==General guidelines==<br />
There are some general rules that must be followed. <br />
<br />
===No inclusion of pre-built binaries or libraries===<br />
All binaries or libraries included with openSUSE packages must have been built from source code included in the source package. This is a requirement for the following reasons:<br />
* Security: Pre-packaged binaries and libraries not built from source could include anything, malicious or dangerous content, or just being plain broken. Also, these are functionally impossible to patch and bugfix.<br />
* Compiler flags: Pre-packaged binaries and libraries not built from source probably do not have the standard openSUSE compiler flags for security and optimization.<br />
<br />
If you are in doubt as to whether something is considered a binary or library, here is some helpful criteria:<br />
* Is it executable? If so, it is probably a binary.<br />
* Does it contain a <tt>.so</tt>, <tt>.so.#</tt>, <tt>.so.#.#</tt> or <tt>.so.#.#.#</tt> extension? If so, it is probably a library.<br />
* If in doubt, ask on the [http://lists.opensuse.org/opensuse-packaging/ openSUSE-packaging] mailing list.<br />
<br />
Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).<br />
<br />
====Exceptions====<br />
* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the openSUSE Packaging Committee for approval.<br />
* An exception is made for binary firmware, as long as it meets the documented requirements: [http://old-en.opensuse.org/Packaging/Licensing_Guidelines#BinaryFirmware BinaryFirmware]<br />
<br />
===Bundling of multiple projects===<br />
Packages in openSUSE should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.<br />
<br />
===Specfile guidelines===<br />
The rules that apply to content of specfiles are in a separate document called the [[openSUSE:Specfile guidelines|Specfile guidelines]].<br />
<br />
===Architecture support===<br />
All openSUSE packages must successfully compile and build into binary RPM files on at least one of the supported architectures, which are i586 and x86_64. The packagers should make every effort to make the package build for both supported architectures. Content — code which does not need to be compiled or built — and architecture independent code (noarch) are notable exceptions.<br />
<br />
===Relocatable packages===<br />
The use of RPM's facility for generating relocatable packages is strongly discouraged. It is difficult to make it work properly, impossible to use from the installer or from zypper and yast, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review.<br />
<br />
----<br />
==Legal==<br />
<br />
===Banned software===<br />
Applications (or other software) listed on the [[openSUSE:Build_Service_application_blacklist|Build Service application blacklist]] are banned from being packaged.<br />
<br />
===Donation requests===<br />
Packaging content (descriptions/summaries/comments/...) should never contain direct donation requests neither for upstream project nor for the packager.<br />
Even if we do not deny need for donations with such projects they should market the campain on their website and not use downstream packaging for such purposes.<br />
<br />
If you find package that is during its runtime asking for donations it is up to the packager discretion whether to keep this code or patch it out.<br />
<br />
===Licensing===<br />
Software licenses should comply with the [http://opensource.org/osd.html Open Source Definition] (which is currently at version 1.9). If you are in doubt as to whether a particular license conforms with the Open Source Definition, you should [http://bugzilla.opensuse.org file a bug] using the category SUSE Tools -> SUSE Linux Legal Issues. <br />
<br />
==== Spec Files ====<br />
Packagers usually come into contact with software licensing through the spec file. A spec file can declare the license(s) for the entire package or for individual subpackages. Licenses should be declared using [http://www.spdx.org/licenses SPDX] shortname format. SPDX and its associated list of licenses is relatively young, however, the list is limited and does not cover all licenses an openSUSE packager will typically have to address. To temporarily work around this limitation, we have [https://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc created a spreadsheet] which contains not only the existing SPDX licenses but also many other licenses which are acceptable for either openSUSE Factory or openSUSE NonFree. If you still can't find a suitable license short name there, you should [http://bugzilla.opensuse.org file a bug] using the category SUSE Tools -> SUSE Linux Legal Issues.<br />
<br />
As well as using a predefined syntax for declaring licenses, openSUSE also recognizes a kind of license grammar in spec files. You can use operators such as 'and' to declare an aggregation of licenses, or 'or' to show that either one or the other license should be chosen. You can also use brackets to gather licenses, for example<br />
License: (MIT or GPL-2.0) and LGPL-2.1+<br />
could be the declaration for a package with an executable binary and a corresponding LGPL-2.1+ licensed library.<br />
<br />
Another thing to be aware of when you are writing spec files is that subpackages will inherit the main license of the package if the packager omits to enter a license specifically for that subpackage. This is not always ideal. For example, if you decide to create a separate subpackage for documentation, you should check if the documentation is licensed under e.g. GFDL-1.1 rather than the (e.g.) GPL-2.0+ license of the main package. It is advisable to always add a license to a subpackage - even if the subpackage is coincidentally under the same license as the main package. This makes it immediately obvious to anybody reading the spec file later.<br />
<br />
Finally, license texts should '''always''' be copied into the package. This is usually done by adding the filename to the %files section using the %license macro in the spec file. Licenses are often found in files with names such as COPYING, COPYING.LIB, LICENSE.txt etc. See https://lists.opensuse.org/opensuse-factory/2016-02/msg00167.html for a discussion around that.<br />
<br />
===Code vs Content===<br />
It is important to make distinction between computer executable code and content.<br />
While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissible. The rule is:<br />
<br />
If the content enhances the user experience, then the content is OK to be packaged in openSUSE. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK.<br />
<br />
Content still has to be reviewed for inclusion. It must have an open source compatible license and must not be legally questionable.<br />
In addition, there are several additional restrictions for content:<br />
<br />
* Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn.<br />
* Content should not be offensive, discriminatory, or derogatory. If you are not sure if a piece of content is one of these things, it probably is.<br />
<br />
Some examples of content which is permissable:<br />
* Clipart for use in office suites<br />
* Wallpaper (non-offensive, non-discriminatory, with permission to freely redistribute)<br />
* Fonts (under an open source license, with no ownership/legal concerns)<br />
* Game levels are not considered content, since games without levels would be non-functional.<br />
* Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable.<br />
* Game music or audio content is permissible, as long as the content is freely distributable without restriction.<br />
* Example files included with the source tarball are not considered content.<br />
<br />
Some examples of content which are not permissible:<br />
* Comic book art files<br />
* Religious texts<br />
<br />
If you are unsure if something is considered approved content, ask on the [http://lists.opensuse.org/opensuse-packaging/ openSUSE-packaging] mailing list.<br />
<br />
----<br />
<br />
==Package features==<br />
===Init scripts===<br />
<br />
* SystemV-style initscripts are supported in openSUSE. There are detailed guidelines for SysV-style initscripts at [[openSUSE:Packaging_init_scripts]].<br />
* systemd unit files (openSUSE for 12.1 and later). Detailed guidelines are available at [[openSUSE:Systemd_packaging_guidelines]].<br />
<br />
Since openSUSE 12.3 has switched completely to systemd, no more new SysV-style init scripts should be written for openSUSE only - but you might need them so that your package works on older distributions, especially SLE 11.<br />
<br />
Recommendation for init scripts and service files is:<br />
* If there is both an init file and a service file, install for openSUSE 12.3 and newer only the service file.<br />
* If the package is needed for SLE 11, you need at least a SysV init file <br />
* If you only support a service file, link rcXXX to /sbin/service so that rcXXX continues to work<br />
* If you submit a new package, consider your audience: Create a new service file for openSUSE 12.3 and newer - or a SysV init file for SLE 11.<br />
<br />
You can (continue to) use the SysV init file for openSUSE, if you want - but consider adding a new service file, these are really easy to write.<br />
<br />
===Desktop files===<br />
If a package contains a GUI application, then it needs to also include a properly installed <tt>.desktop</tt> file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed <tt>.desktop</tt> files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec], paying particular attention to validating correct usage of the ''Name'', ''GenericName'', ''[http://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories Categories] and <br />
''[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]'' entries.<br />
<br />
====Icon tag in Desktop Files====<br />
The icon tag has to be the basename of the icon file(s), because it allows for icon theming:<br />
<br />
* <code> Icon=comical </code><br />
<br />
It assumes <tt>.png</tt> by default, then tries <tt>.svg</tt> and finally <tt>.xpm</tt>.<br />
<br />
====<tt>.desktop</tt> file creation====<br />
If the package does not already include and install its own <tt>.desktop</tt> file, you need to make your own, and include it as a source (e.g. <code>Source3: '''%name'''.desktop</code>). The contents of a sample <tt>.desktop</tt> file (<tt>comical.desktop</tt>) are:<br />
<br />
<pre><br />
[Desktop Entry]<br />
Name=Comical<br />
GenericName=Comic Archive Reader<br />
Comment=Open .cbr & .cbz files<br />
Exec=comical<br />
Icon=comical<br />
Terminal=false<br />
Type=Application<br />
Categories=Graphics;<br />
</pre><br />
<br />
====<tt>%suse_update_desktop_file</tt> usage====<br />
It is not simply enough to just include the <tt>.desktop</tt> file in the package. One MUST run <code>%suse_update_desktop_file</code> in the <code>%install</code> section, and have <code>BuildRequires: update-desktop-files</code> enlisted, to help ensure <tt>.desktop</tt> file safety and spec-compliance. <code>%suse_update_desktop_file</code> MUST be used if the package does not install the file or there are changes desired to the <tt>.desktop</tt> file (such as adding/removing categories, etc). Some examples of usage:<br />
<br />
* check desktop file<br />
<pre>%suse_update_desktop_file %{name}</pre><br />
<br />
* install desktop file and change categories<br />
<pre>%suse_update_desktop_file -r %{name} System Utility Core GTK FileManager</pre><br />
<br />
===Users and Groups===<br />
Note that for the moment, we primarily address the case where the mapping from user/group names to uids/gids is decided dynamically by target systems at package install time. Some options for system administrators for making this mapping static even though the package scriptlets use a dynamic scheme are also discussed below, and more are being investigated, including possibilities to make the mapping static at package build time.<br />
<br />
<br />
System users, which are used by a variety of applications, by standard<br />
filesystem directories or are standard users which should exist on<br />
every Unix compatible system, should be provided by special RPMs.<br />
<br />
This RPMs provides and the user and groups:<br />
<pre><br />
Provides: user(<name>)<br />
Provides: group(<name>)<br />
</pre><br />
<br />
This RPMs are also responsible to create and provide the home directory.<br />
Applications needing a special system user should require them:<br />
<pre><br />
Requires(pre): user(<name>)<br />
Requires(pre): group(<name>)<br />
</pre><br />
<br />
With this, the system users will only be created if they are needed.<br />
And an admin can easy find out, if a system user is still required or<br />
can be deleted.<br />
<br />
systemd-sysusers (sysusers.d(5)) is used to create this accounts. This<br />
allows to verify how the system account should look like.<br />
<br />
An example spec file for the uucp system user should contain the<br />
following lines:<br />
<pre><br />
Source1: system-user-uucp.conf<br />
BuildRequires: sysuser-tools<br />
<br />
%package -n system-user-uucp<br />
Summary: System user and group uucp<br />
%sysusers_requires<br />
<br />
%build<br />
%sysusers_generate_pre %{SOURCE1} uucp<br />
<br />
%pre -n system-user-uucp -f uucp.pre<br />
<br />
%files -n system-user-uucp<br />
%defattr(-,root,root)<br />
%dir %attr(0750,uucp,uucp) %{_sysconfdir}/uucp<br />
</pre><br />
<br />
<tt>%pre ... -f uucp.pre</tt> causes the content of uucp.pre to be taken as scriptlet. This file is generated at build time by the <tt>%sysusers_generate_pre</tt>-macro.<br />
<br />
To create users and groups in packages, which are only needed for this single package, use:<br />
<br />
<pre><br />
Requires(pre): shadow<br />
<br />
[...]<br />
<br />
%pre<br />
getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME<br />
getent passwd USERNAME >/dev/null || useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin -c "user for PACKAGENAME" USERNAME<br />
exit 0<br />
<br />
[...]<br />
</pre><br />
<br />
<code>HOMEDIR</code> should usually be a directory created and owned by the package, with appropriate restrictive permissions. A good choice for the location of the directory is the package's data directory or directory under <code>/var</code> like <code>/var/lib/''NAME''</code>, in case it has one.<br />
<br />
User accounts created by packages are rarely used for interactive logons, and should thus generally use <tt>/bin/false</tt> or <tt>/sbin/nologin</tt> as the user's shell.<br />
<br />
<!-- Does not apply to openSUSE pwdutils. Creating a group as a side effect of creating a user is a Fedoraism (and a whacky one, I might add - UNIX principle violated).<br />
We want to invoke <code>groupadd</code> explicitly instead of relying on <code>useradd</code> to create the group for us. This is because <code>useradd</code> alone would fail if the group it tries to create already existed.<br />
--><br />
<br />
The <code>exit 0</code> at the end will result in the <code>%pre</code> scriptlet returning success even if the user/group creation fails for some reason. This is suboptimal, but has less potential for system-wide breakage than allowing it to fail. If the user/group is not available at the time the package's payload is unpacked, rpm will fall back to getting those files owned by root.<br />
<br />
<code>getent</code> is run before <code>groupadd</code>/<code>useradd</code>, to check whether the user/group that is about to be created already exists, and if so, skip the creation. This is done so to provide a possibility for local system administrators to create the user/group beforehand, in case they wish to get a predefined static UID/GID mapping for those users. <!-- Fedoraism: Creating users, for example when using unattended kickstart installations is a case where creating users/groups beforehand is a bit tricky; one way to accomplish this is to create a customized version of the "setup" package with the desired users/groups, along with their static UID/GID mappings in place, and to make sure the install transaction uses that package instead of the vanilla distro one. --><br />
<br />
<code>groupadd</code>/<code>useradd</code> in <tt>%pre</tt> is always run — both on initial installs and upgrades. This is made possible by doing the <code>getent</code> checks above, and should fix things up if the user/group has disappeared after the package to be upgraded was initially installed (just like file permissions get reset on upgrades etc).<br />
<br />
Users or groups created by packages are never removed. There is no sane way to check if files owned by those users/groups are left behind — and even if there were, what would we do to them? Leaving those behind with ownerships pointing to then-nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups, deleting the user/group might not be possible or/nor desirable, for example, when using a shared remote user/group database. Cleanup of unused users/groups is left to the system administrators to take care of, if they so desire.<br />
<br />
In some cases it is desirable to create only a group without a user account. Usually, this is because there are some system resources to which we want to control access by using that group, and a separate user account would add no value. Examples of common such cases include (but are not limited to) games whose executables are setgid for the purpose of sharing high score files or the like, and/or software that needs exceptional permissions to some hardware devices and it would not be appropriate to grant those to all system users nor even only those logged in on the console. In these cases, apply only the <code>groupadd</code> parts of the above recipe.<br />
<br />
Note that the practice of not creating users/groups if they already exist has a drawback of possibly unrelated but coincidentally same named existing system users and/or groups unnecessarily and undesirably getting access to things in a package that uses the same user/group names. This version of the users/groups guideline does not address that issue in any way, but it is possible that future revisions will if a good enough way to do that is found.<br />
<br />
===Migration / Upgrades===<br />
With the introduction of containerized deployments it is not a good idea to do all the configuration and generating of random information during the package installation but rather it should be done on the selected spawned container to ensure data consistency and stability.<br />
<br />
Basically, it means to move all configuration tasks that are using the binaries and affecting resulting data (e.g. keychain generation, database migration) from scriptlet phases to be executed later on a live system. As our requirement is to be able to install packages using rpm directly we have several options how to achieve this:<br />
<br />
====systemd services (as a sample see <code>mariadb</code> package)====<br />
Use the systemd services to actually do the initial configuration and deployment, alternatively even the migration of the already existing content in place prior start.<br />
<br />
General systemd file is quite obvious:<br />
<pre>[Unit]<br />
Description=MySQL server<br />
Wants=basic.target<br />
Conflicts=mysql.target<br />
After=basic.target network.target <br />
<br />
[Service]<br />
Restart=on-abort<br />
Type=simple<br />
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install<br />
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade<br />
ExecStart=/usr/lib/mysql/mysql-systemd-helper start<br />
ExecStartPost=/usr/lib/mysql/mysql-systemd-helper wait<br />
<br />
[Install]<br />
WantedBy=multi-user.target</pre><br />
All the operations are done by the helper shell script that as it is described prior each start does installation and upgrade steps. To ilustrate these points will be different for each application but as a concept this is done in the mariadb:<br />
<pre># Create new empty database if needed<br />
mysql_install() {<br />
if [[ ! -d "$datadir/mysql" ]]; then<br />
echo "Creating MySQL privilege database... "<br />
mysql_install_db --user="$mysql_daemon_user" --datadir="$datadir" || \<br />
die "Creation of MySQL databse in $datadir failed"<br />
echo -n "$MYSQLVER" > "$datadir"/mysql_upgrade_info<br />
fi<br />
}</pre><br />
<pre># Upgrade database if needed<br />
mysql_upgrade() {<br />
# Run mysql_upgrade on every package install/upgrade. Not always<br />
# necessary, but doesn't do any harm.<br />
if [[ -f "$datadir/.run-mysql_upgrade" ]]; then<br />
echo "Checking MySQL configuration for obsolete options..."<br />
sed -i -e 's|^\([[:blank:]]*\)skip-locking|\1skip-external-locking|' \<br />
-e 's|^\([[:blank:]]*skip-federated\)|#\1|' /etc/my.cnf<br />
<br />
# instead of running mysqld --bootstrap, which wouldn't allow<br />
# us to run mysql_upgrade, we start a full-featured server with<br />
# --skip-grant-tables and restict access to it by unix<br />
# permissions of the named socket<br />
<br />
echo "Trying to run upgrade of MySQL databases..."<br />
<br />
# Check whether upgrade process is not already running<br />
protected="$(cat "/run/mysql/protecteddir.$INSTANCE" 2> /dev/null)"<br />
if [[ -n "$protected" && -d "$protected" ]]; then<br />
pid="$(cat "$protected/mysqld.pid" 2> /dev/null)"<br />
if [[ "$pid" && -d "/proc/$pid" ]] &&<br />
[[ $(readlink "/proc/$pid/exe" | grep -q "mysql") ]]; then<br />
die "Another upgrade in already in progress!"<br />
else<br />
echo "Stale files from previous upgrade detected, cleaned them up"<br />
rm -rf "$protected"<br />
rm -f "/run/mysql/protecteddir.$INSTANCE"<br />
fi<br />
fi<br />
protected="$(mktemp -d -p /var/tmp mysql-protected.XXXXXX | tee "/run/mysql/protecteddir.$INSTANCE")"<br />
[ -n "$protected" ] || die "Can't create a tmp dir '$protected'"<br />
<br />
# Create a secure tmp dir<br />
chown --no-dereference "$mysql_daemon_user:$mysql_daemon_group" "$protected" || die "Failed to set group/user to '$protected'"<br />
chmod 0700 "$protected" || die "Failed to set permissions to '$protected'"<br />
<br />
# Run protected MySQL accessible only though socket in our directory<br />
echo "Running protected MySQL... "<br />
/usr/sbin/mysqld \<br />
--defaults-file="$config" \<br />
--user="$mysql_daemon_user" \<br />
--skip-networking \<br />
--skip-grant-tables \<br />
$ignore_db_dir \<br />
--log-error="$protected/log_upgrade_run" \<br />
--socket="$protected/mysql.sock" \<br />
--pid-file="$protected/mysqld.pid" &<br />
<br />
mysql_wait "$protected/mysql.sock" || die "MySQL didn't start, can't continue"<br />
<br />
# Run upgrade itself<br />
echo "Running upgrade itself..."<br />
echo "It will do some chek first and report all errors and tries to correct them"<br />
echo<br />
if /usr/bin/mysql_upgrade --no-defaults --force --socket="$protected/mysql.sock"; then<br />
echo "Everything upgraded successfully"<br />
up_ok=""<br />
rm -f "$datadir/.run-mysql_upgrade"<br />
[[ $(grep -q "^$MYSQLVER" "$datadir/mysql_upgrade_info" 2> /dev/null) ]] || \<br />
echo -n "$MYSQLVER" > "$datadir/mysql_upgrade_info"<br />
else<br />
echo "Upgrade failed"<br />
up_ok="false"<br />
fi<br />
<br />
# Shut down MySQL<br />
echo "Shuting down protected MySQL"<br />
kill "$(cat "$protected/mysqld.pid")"<br />
for i in {1..30}; do<br />
/usr/bin/mysqladmin --socket="$protected/mysql.sock" ping > /dev/null 2>&1 || break<br />
done<br />
/usr/bin/mysqladmin --socket="$protected/mysql.sock" ping > /dev/null 2>&1 && kill -9 "$(cat "$protected/mysqld.pid")"<br />
<br />
# Cleanup<br />
echo "Final cleanup"<br />
if [[ -z "$up_ok" ]]; then<br />
rm -rf "$protected" "/run/mysql/protecteddir.$INSTANCE"<br />
else <br />
die "Something failed during upgrade, please check logs"<br />
fi<br />
fi<br />
}</pre><br />
<br />
====crontab====<br />
Similar to the previous option but using crontab instead of systemd.<br />
====binary tweaks====<br />
Adjust binaries to perform all these configuration tasks by themselves on the first run/migration.<br />
But it could get complicated in order to persuade upstream projects to accept these changes.<br />
<br />
===Logrotate scripts===<br />
Logrotate requires the log files (or the directory they are in) to be owned as root:root, so it won't be prone to symlink tricks and other attacks.<br />
<br />
If the log files have to be owned by a non-root user,<br />
the recently added "su" directive should be used.<br />
The logrotate process will switch user:group before rotating to match the permissions of the rotated log file.<br />
<br />
Example:<pre><br />
/var/log/radius/radius.log {<br />
su radiusd radiusd<br />
[...]<br />
}</pre><br />
<br />
===Patches===<br />
See [[openSUSE:Packaging Patches guidelines|Packaging Patches guidelines]].<br />
<br />
<br />
===Supporting multiple versions of a package===<br />
See [[openSUSE:Packaging Multiple Version guidelines|Supporting the installation of multiple package versions]]<br />
----<br />
<br />
===Changelog===<br />
<br />
See [[openSUSE:Creating_a_changes_file_(RPM)|Creating a (RPM) changes file]]. Please note that openSUSE uses a separate file for the RPM changelog.<br />
<br />
===Udev rules===<br />
<br />
Udev rules files must be placed into %{_udevrulesdir}.<br />
<br />
Reloading udev in %post and %postun is not needed, because udev automatically detects changes in rules files ([https://lists.opensuse.org/opensuse-packaging/2016-06/msg00050.html opensuse-packaging discussion]).<br />
<br />
==GConf scriptlets==<br />
<br />
==SuSEfirewall2 Service Definitions==<br />
<br />
<br />
----<br />
<br />
==Package types==<br />
Some applications have specific guidelines written for them, located on their own pages in the Packaging/ hierarchy.<br />
<br />
<br />
=== Architecture crossover (baselib) packages===<br />
<br />
A.k.a. <tt>-32bit</tt>, <tt>-64bit</tt>, <tt>-x86</tt>, and so on.<br /><br />
→ [[openSUSE:Build_Service_baselibs.conf]]<br />
<br />
===Branding===<br />
===Debuginfo===<br />
<br />
Packages should produce useful <tt>-debuginfo</tt> packages, or explicitly disable them when it is not possible to generate a useful one, but where rpmbuild would do it anyway. Generation of <tt>-debuginfo</tt> packages happens automatically where possible, and can be explicitly disabled in the Build Service on a per-(project, repository) or per-(package, repository) basis. For example, look at the Debuginfo flags within the OBS web UI's [https://build.opensuse.org/project/repositories/openSUSE:12.3:Update Repository tab for the openSUSE:12.3:Update project] or [https://build.opensuse.org/package/repositories/openSUSE:12.3:Update/ConsoleKit a package within that project]. Of course you can also change these flags by using <tt>osc</tt> to edit the metadata belonging to the project or package. Whenever a <tt>-debuginfo</tt> package is explicitly disabled, an explanation why this was done so is required in the specfile. <br />
<br />
If the debuginfo flag is enabled, <tt>bs-worker</tt> will trickle this down to <tt>build(1)</tt><br />
(some env var?) and <tt>/usr/bin/build</tt> calls <tt>rpm</tt> with <tt>--define<br />
'_build_create_debug 1'</tt>.<br />
<br />
<tt>/home/abuild/.rpmmacros</tt> is populated with the definition for <tt>_build_create_debug</tt>, and will cause an expansion of ungodly macro magic, including <tt>%debug_package</tt>. <tt>%debug_package</tt> is a standardized RPM component and marks the end of BS-specific logic.<br />
<br />
NOTE: Older versions of <tt>rpm</tt> (still used for SLE-11 builds) don't support <tt>noarch</tt> sub-packages. This leads to debuginfo files being created but no <tt>-debuginfo<tt> being generated. When building for those versions, <tt>noarch</tt> must not be used for sub-packages.<br />
<br />
Debuginfo packages are discussed in more detail in a separate document, [http://old-en.opensuse.org/Packaging/Debuginfo].<br />
<br />
===Eclipse Plugins===<br />
===Emacs===<br />
Add single elisp file (.el) in <code>%{_datadir}/emacs/site-lisp</code>. If you add multiple file, make a subdir <code>%{_datadir}/emacs/site-lisp/%{name}</code> and add a new initialization file to add the subdir to the <code>load-path</code> list:<br />
<br />
<pre><nowiki><br />
%define _sitedir %{_datadir}/emacs/site-lisp<br />
%define _startfile %{_sitedir}/suse-start-%{name}.el<br />
<br />
cat <<EOF > %{buildroot}%{_startfile}<br />
;; %{_startfile}<br />
<br />
(add-to-list 'load-path "%{_sitedir}/%{name}")<br />
<br />
;; %{_startfile} ends here<br />
EOF<br />
</nowiki></pre><br />
<br />
'''TODO''': byte-compilation & autoloads<br />
<br />
===Fonts===<br />
Fonts in general-purpose formats such as Type1, OpenType TT (TTF) or OpenType CFF (OTF) are subject to specific [[openSUSE:Packaging_Fonts]], and should never be packaged in a private application directory instead of the system-wide font repositories.<br />
<br />
===Games===<br />
How to package games is explained in [[openSUSE:Packaging_Games]].<br />
<br />
===GNOME===<br />
===Go===<br />
How to package Go software is explained in [[openSUSE:Packaging_Go]].<br />
===Haskell===<br />
How to package Haskell software is explained in [[openSUSE:Packaging_Haskell]].<br />
===Java===<br />
How to package Java software is explained in [[openSUSE:Packaging_Java]]<br />
===Lisp===<br />
How to package Common Lisp software is explained in [[openSUSE:Packaging_Lisp]]<br />
<br />
===Lua===<br />
How to package Lua software is explained in [[openSUSE:Packaging_Lua]]<br />
===Mono===<br />
===Mozilla===<br />
===OCaml===<br />
===OpenOffice.org extensions===<br />
===PAM (Pluggable Authentication Modules)===<br />
===Perl===<br />
How to package Perl software is explained in [[openSUSE:Packaging_Perl]]<br />
===PHP===<br />
How to package PHP software is explained in [[openSUSE:Packaging_PHP]]<br />
===Python===<br />
How to package Python software is explained in [[openSUSE:Packaging_Python]]<br />
===R===<br />
How to package R software is explained in [[openSUSE:Packaging_R]]<br />
===Ruby===<br />
How to package Ruby software is explained in [[openSUSE:Packaging_Ruby]]<br />
===wxWidgets===<br />
How to package wxWidgets software is explained in [[openSUSE:Packaging_wxWidgets]]<br />
===Libraries===<br />
====Shared Libraries====<br />
[[openSUSE:Shared library packaging policy]]<br />
<br />
====GObject Introspection Bindings (.typelibs)====<br />
A good amount of libraries, mostly from the GNOME Stack, ship a .typelib file. This .typelib interfaces between various programming languages (seed, python, vala) and the library. Just like shared libraries, they are versioned and can potentially require to be installed in multiple versions.<br />
<br />
The package name follows the convention typelib-<GIVersion>-<TypeLibName>-<TypeLibVersion>, where dots (.) are replaced with underscores (_)<br />
<br />
Explanation of the <FIELDS>:<br />
typelib: Literal, as an identifier of the package type.<br />
<GIVersion>: Current gobject introspection version is 1.0, so 1_0<br />
<TypeLibName>: The name of the actual binding, Case sensitive<br />
<TypeLibVersion>: The version of the binding<br />
<br />
All these elements can be taken out of the filename. For example /usr/lib/girepository-1.0/Memphis-0.2.typelib results in the package name typelib-1_0-Memphis-0_2<br />
When building such packages, make sure that the spec file contains BuildRequires: gobject-introspection, as this triggers the installation of an automatic dependency scanner in plus. As a result, the typelib-* package automatically requires its libraries and possibly other typelib-packages.<br />
<br />
====Static Libraries====<br />
Packages including libraries should exclude static libraries as far as possible (e.g. by configuring with the <tt>--disable-static</tt> switch). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should, as far as possible, link against shared libraries, not static versions.<br />
<br />
Libtool archives, <tt>foo.la</tt> files, should not be included. Packages using libtool will install these by default even if you configure with <tt>--disable-static</tt>, so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases, it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable openSUSE release and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change, in other words, removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.<br />
<br />
=====Exception=====<br />
We want to be able to track which packages are using static libraries so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance. If you really need to package static libraries, you have to follow this guideline.<br />
<br />
Static libraries must be placed in a ''*-devel-static'' subpackage, which <code>Requires</code> the ''*-devel'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-devel-static'' package. The intent is that, whenever possible, packages will move away from using these static libraries, to the shared libraries. When a package only provides static libraries, skip the <code>Requires</code> on the ''*-devel'' subpackage. Packages which explicitly need to link against the static version must then <code>BuildRequire: foo-devel-static</code>, so that the usage can be tracked.<br />
<br />
If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-devel-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-devel-static'' package.<br />
<br />
====Duplication of system libraries====<br />
For several reasons, a package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed.<br />
<br />
===Tcl===<br />
<br />
===Web Applications===<br />
<br />
Web applications packaged in openSUSE should place their files in<br />
/etc, /usr, /var, etc., depending on type, just like any other<br />
application would do.<br />
<br />
In general, a package must not install, remove or otherwise modify /srv content as its use is reserved to the admin according to FHS[http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM]. In openSUSE, it's OK to have a package create an empty directory in /srv if the default configuration of the software points there.<br />
<br />
===Vala===<br />
<br />
====How to detect Vala version in specfile====<br />
We assume you're not building Vala itself. If so, the version of Vala is defined by youself and can be called simply using <tt>%{version}</tt> tag, the problem does not even exist.<br />
Here we're facing such an embarrassing situation:<br />
<br />
The package is built with Vala, and is built well under all versions of Vala(So you don't have to gild the lily by <tt>BuildRequires: vala >= 0.14</tt> tag). But you still have to detect and use the version number of Vala. <br />
<br />
Here Build Service got a bottleneck. For now, Vala can not simply be included with <tt>BuildRequires: vala</tt> and exports its version simple and naive with automatic tag like <tt>%{py_ver}</tt> or <tt>%{perl_version}</tt> as Perl or Python does. Some package do need to know Vala's number to get its work done(eg.., Babl or Gegl will install <tt>.vapi</tt> file to <tt>/usr/share/vala</tt> by default, but that directory is meaningless in a standard openSUSE system. However, openSUSE use directory suffixed with a Vala version number like <tt>/usr/share/vala-0.14</tt>. Now it is you packager's responsibility to move them from package default directory to openSUSE's callable).<br />
<br />
Of course you could, by using <tt>%if 0?{%suse_version} >= 1140</tt> tag, move them to the directory suffixed with standard Vala version number, which is installed by default on that 1140 version of openSUSE. But it will make your specfile huge and unmaintainable(you have to add such section for almost every version of openSUSE).<br />
<br />
Now we use the self defined function <tt>%define</tt> in specfile,as follows:<br />
<br />
#import Vala dependency <br />
BuildRequires: vala<br />
#define a function to export Vala's version number<br />
%define vala_version %(rpm -q --queryformat='%{VERSION}' vala | sed 's/\.[0-9]*$//g')<br />
<br />
We use <code>rpm -q --queryformat='%{VERSION}' vala</code> to fetch Vala's full version number <tt>0.14.0</tt>, which is installed in a standard RPM way before the build process actually starts, that's why such code works. And then use <tt>sed</tt> shell command with the power of Regex to cut the suffix <tt>.0</tt> and export the result to a variable <tt>vala_version</tt>, which can be called easily by <tt>%{vala_version}</tt>. eg:<br />
<br />
#create a new directory. -pv means export directories it made into logfile for futher debug <br />
#and create it automatically if the parent directory does not exist.<br />
mkdir -pv %{buildroot}%{_datadir}/vala-%{vala_version}/<br />
#move the files<br />
mv %{buildroot}%{_datadir}/vala/* %{buildroot}%{_datadir}/vala-%{vala_version}/<br />
#delete the original folder<br />
rm -Rf %{buildroot}%{_datadir}/vala/<br />
<br />
Even in <tt>%files</tt> section, you could use:<br />
<br />
%dir %{_datadir}/vala-%{vala_version}/<br />
%{_datadir}/vala-%{vala_version}/*<br />
<br />
to simplify your specfile.<br />
<br />
Because every file under <tt>%{buildroot}</tt> will be packaged by hierarchy into the final output RPM, now your package's user friendliness pops up +1.<br />
<br />
[[de:openSUSE:Paketbau Richtlinien]]<br />
[[el:openSUSE:Packaging guidelines]]<br />
[[it:openSUSE:Packaging guidelines]]<br />
[[ja:openSUSE:パッケージングガイドライン]]<br />
[[zh:openSUSE:Packaging_guidelines]]<br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation|z]]</div>Okurzhttps://en.opensuse.org/index.php?title=Features_42.3&diff=120762Features 42.32017-08-02T19:01:28Z<p>Okurz: fix typos</p>
<hr />
<div>{{Current_distribution_navbar|42.3}}<br />
<div style="text-align:justify;float:left;"><br />
<br />
==openSUSE 42.3 – Leap==<br />
The next minor version of openSUSE Leap is version 42.3. The release is mostly a refresh and hardware enablement release that will include more than 10,000 packages coming from both community and enterprise developers. openSUSE Leap 42.3 is extremely stable and hardened because it shares source code from SUSE Linux Enterprise (SLE) 12 Service Pack (SP) 3. Leap also benefits from the bug fixes and maintenance of community developers and SUSE engineers. The rock-solid Leap distribution also offers great packages for streaming media, playing games, editing graphics and creating animation, 3D printing projects, worldwide health-care projects, data extraction, tools for high performance computing, network monitoring and much more. Try [https://software.opensuse.org/distributions/leap Leap 42.3] and see why so many people are switching to [https://software.opensuse.org/ openSUSE distributions].<br />
<gallery><br />
<br />
</gallery><br />
<br />
The following pages go into much detail on what is new in this openSUSE release. Too much information? Check out the [[Portal:42.3/Features|Feature highlights]] instead.<br />
<br />
__TOC__<br />
<br />
== Base operating system ==<br />
<br />
=== Linux kernel ===<br />
<br />
The default kernel for openSUSE Leap 42.3 is the longterm maintenance Kernel 4.4.<br />
<br />
==== Networking ====<br />
<br />
* Completely lockless TCP listener handling, which allows for faster and more scalable TCP servers.<br />
* A persistent reservation API for block devices.<br />
* VRF (Virtual Routing and Forwarding) support in the IPv6 stack.<br />
<br />
==== Security ====<br />
<br />
* EXT4 fixes for the filesystem's native encryption support.<br />
* Additional UEFI 2.5 functionality.<br />
* Optimized code for using Intel SHA extensions.<br />
* Improved Trusted Platform Module (TPM) 2.0 support.<br />
<br />
==== Hardware Support ====<br />
<br />
* Support for Open-Channel solid state drives (SSDs) through LightNVM.<br />
* Improved Skylake Windows 8 precision touchpad support.<br />
* Google Fiber TV remote control support.<br />
* Many new and updated drivers.<br />
<br />
==== More ====<br />
<br />
* A new mlock2() syscall that allows users to request memory to be locked on page fault.<br />
* Clustered RAID1 and Journaled RAID5 support.<br />
* A lot of x86 KVM work.<br />
* Numerous 64-bit ARM changes.<br />
<br />
=== systemd ===<br />
systemd 228<br />
https://github.com/systemd/systemd/blob/v228/NEWS<br />
<br />
Support for the "pids" cgroup controller has been added. It allows accounting<br />
the number of tasks in a cgroup and enforcing limits on it. For user processes<br />
the limit is set to 12K whereas the limit is 512 for system services.<br />
The general benefit of these changes should be a more robust and safer system,<br />
that provides a certain amount of per-service fork() bomb protection.<br />
<br />
The systemd package now also enables machined and imported, which enables systemd's native support for running lightweight containers.<br />
<br />
==== PHP 7 ====<br />
openSUSE Leap 42.3 provides both PHP 5 and PHP 7 packages. The<br />
<br />
PHP 7.0.7 fixes several bugs, such as:<br />
* Fixed bug #72162 (use-after-free - error_reporting).<br />
* Add compiler option to disable special case function calls.<br />
* Fixed bug #72101 (crash on complex code).<br />
* Fixed bug #72100 (implode() inserts garbage into resulting string when joins very big integer).<br />
* Fixed bug #72057 (PHP Hangs when using custom error handler and typehint).<br />
* Fixed bug #72038 (Function calls with values to a by-ref parameter don't always throw a notice).<br />
* Fixed bug #71737 (Memory leak in closure with parameter named $this).<br />
* Fixed bug #72059 (?? is not allowed on constant expressions).<br />
* Fixed bug #72159 (Imported Class Overrides Local Class Name).<br />
<br />
A detailed list of new of bug fixes is available at http://php.net/ChangeLog-7.php#7.0.7<br />
<br />
Users considering to migrate production systems from PHP 5.5.x to 7.0.x should<br />
also review the following documents which describe backward incompatible changes,<br />
deprecated features and changed functions:<br />
<br />
* http://php.net/manual/en/migration56.php<br />
* http://php.net/manual/en/migration70.php<br />
<br />
==== Printing System ====<br />
In openSUSE Leap 42.3, there are no major changes in the printing system compared to openSUSE Leap 42.2. The cups-filters-1.8.2 remains the same and the RPM package for hplip in openSUSE Leap 42.3 compared to openSUSE Leap 42.2 is hplip-3.16.11 rather than hplip-3.16.5.<br />
<br />
=== Mesa 17 ===<br />
Mesa is an open-source implementation of the OpenGL, Vulkan and other specifications, which is a system for rendering interactive 3D graphics.<br />
<br />
==== New ====<br />
* Building RADV requires --enable-gallium-llvm<br />
* The vulkan headers vk_platform.h and vulkan.h are no longer installed<br />
* The configure options --with-sha1 and --disable-shader-cache are removed alongside their respective library requirements<br />
* Intel Haswell now supports OpenGL 4.2<br />
* Vulkan Float64 capability support on Intel's ANV driver<br />
<br />
==== Fixes ====<br />
* Fixed the configuration of a desktop with 3x4k monitors in one row<br />
* Fixed Blender line rendering broken after removing XY clipping of lines<br />
* Fixed Firefox crashing when opening about:support with WebGL2 enabled<br />
* Fixed VLC video that has corrupted colors when using VDPAU output on Radeon SI<br />
<br />
More fixes can be found [https://www.mesa3d.org/relnotes/17.0.4.html here].<br />
<br />
== Office and Groupware ==<br />
=== TeX Live 2016 ===<br />
TeX Live is an easy way to get up and running with the TeX document production system. It provides a comprehensive TeX system with a lot of programs like LaTeX, pdfLaTeX, XeLaTeX, and LuaLaTex. It includes all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world. <br />
<br />
===== New =====<br />
There are a lot of changes in LuaTeX backend.<br />
The pdfTeX and XeTeX commands got new primitives.<br />
MetaFont got experimental Lua integration.<br />
MetaPost got bug fixes and was prepared for a new major version coming soon.<br />
<br />
A lot of updates of packages had been done like update of the fontspec package as well as the corresponding LaTeX engine.<br />
<br />
The environment variable SOURCE_DATE_EPOCH is supported in all engines except LuaTEX (which will come in the next release) and original tex (intentionally omitted): If the environment variable SOURCE_DATE_EPOCH is set, its value is used for timestamps in the PDF output. If SOURCE_DATE_EPOCH_TEX_PRIMITIVES is also set, the SOURCE_DATE_EPOCH value is used to initialize the TEX primitives \year, \month, \day, \time. The pdfTEX manual has examples and details.<br />
<br />
pdfTEX: new primitives \pdfinfoomitdate, \pdftrailerid, \pdfsuppressptexinfo, to control values appearing in the output which normally change with each run. These features are for PDF output only, not DVI.<br />
<br />
XeTEX: New primitives \XeTeXhyphenatablelength, \XeTeXgenerateactualtext,<br />
\XeTeXinterwordspaceshaping, \mdfivesum; character class limit increased to 4096; DVI id byte incremented.<br />
<br />
Other utilities:<br />
<br />
gregorio is a new program, part of the gregoriotex package for typesetting Gregorian chant scores; it is included in shell_escape_commands by default.<br />
upmendex is an index creation program, mostly compatible with makeindex, with support for Unicode sorting, among other changes.<br />
afm2tfm now makes only accent-based height adjustments upward; a new option -a omits all adjustments.<br />
ps2pk can handle extended PK/GF fonts.<br />
<br />
It doesn’t sound like a big change, but it comes with updates for a lot of packages compared to last year’s TeX Live 2015.<br />
<br />
=== Firefox 52 (ESR version) ===<br />
Firefox is a free and open-source web browser developed by the Mozilla Foundation and its subsidiary the Mozilla Corporation.<br />
===== New =====<br />
Added automatic captive portal detection, for easier access to Wi-Fi hotspots. When accessing the Internet via a captive portal, Firefox will alert users and open the portal login page in a new tab.<br />
<br />
Implemented the Strict Secure Cookies specification which forbids insecure HTTP sites from setting cookies with the "secure" attribute. In some cases, this will prevent an insecure site from setting a cookie with the same name as an existing "secure" cookie from the same base domain.<br />
<br />
Added user warnings for non-secure HTTP pages with logins. Firefox now displays a “This connection is not secure” message when users click into the username and password fields on pages that don’t use HTTPS.<br />
<br />
Enhanced Sync to allow users to send and open tabs from one device to another.<br />
<br />
===== Changed =====<br />
Improved experience for downloads:<br />
* Notification in the toolbar when a download fails<br />
* Quick access to five most recent downloads rather than three<br />
* Larger buttons for canceling and restarting downloads<br />
<br />
Removed Battery Status API to reduce fingerprinting of users by trackers<br />
<br />
Display (but allow users to override) an “Untrusted Connection” error when encountering SHA-1 certificates that chain up to a root certificate included in Mozilla’s CA Certificate Program. (Note: Firefox continues to permit SHA-1 certificates that chain to manually imported root certificates.) Read more about the Mozilla Security Team’s plans to deprecate SHA-1<br />
<br />
=== Libreoffice ===<br />
LibreOffice is a free and open source office suite, a project of The Document Foundation.<br />
<br />
==== Writer ==== <br />
* Spelling dialog no longer automatically closes once spellcheck is complete. <br />
* Widow/Orphan paragraph text-flow enabled by default for new documents. <br />
* Mail merge embedding of the datasource definition ([http://vmiklos.hu/blog/mail-merge-embedding.html see this blog entry]) <br />
* Hide Whitespace option added to View menu <br />
* Outline split button available in formatting toolbar, but hidden by default <br />
* While in print preview mode to jump to a specific page, the only thing you have to do is enter the page number on the numeric field in the toolbar. <br />
<br />
==== Calc ==== <br />
* New commands to add rows below and columns right.<br />
* Data Sources keyboard shortcut was changed to Ctrl+⇧ Shift+F4 and F4 was assigned to toggling cell references.<br />
* Formula Wizard shows the values of parameters and results on the Structure page.<br />
* Statistics regression: linear, logarithmic, power: Add a new statistics dialog for calculating regression. <br />
* Organize sheet level context menus. commit<br />
* PNG export in LibreOffice Calc was added, as in Writer and Impress. [http://vmiklos.hu/blog/calc-png-export.html blog entry] <br />
* Option to search formatted display strings using find bar and also "Find & Replace" dialog.<br />
<br />
==== Impress and Draw ====<br />
* Slide navigation and sorting commands were added with corresponding shortcut keys.<br />
* Master slide view appears in a different background color to normal view.<br />
* KDE, XFCE, and Mate ScreenSavers are now also inhibited when presenting<br />
<br />
'''Impress Mode selection'''<br />
Several modes were active in Impress:<br />
* Page to edit slides content<br />
* Page Master to edit slides container<br />
* Notes to add Notes<br />
* Notes Master to edit Notes container<br />
* Plan to sketch a presentation<br />
* Handout to define the handout format<br />
* Slide sorter to organise presentation<br />
<br />
It was hard to navigate between Master / non master modes. Tabs above the working area were jumping right and left, consuming screen space.<br />
<br />
Now, two toolbox icons have been added:<br />
<br />
* one to toggle Tab bar visibility. It is hidden by default. Clicking the toggle disables the new Mode Selection tool and restores the previous behaviour.<br />
* one to Select the Working mode among the 7 modes listed above. It is divided in two zones: top zone is regular mode (dealing with content of the presentation), bottom zone is the Master mode (dealing with container).<br />
<br />
'''Slide Design'''<br />
Slide Design dialog in Slide ▸ Slide Design now affects all selected (standard) slides.<br />
<br />
'''Equalize Width/Height'''<br />
When multiple objects are selected, the right click context menu Shapes submenu now supports Equalize Width and Equalize Height which adjusts the width/height of the selected objects to the width/height of the last selected object.<br />
<br />
'''Save Background Image'''<br />
Right clicking a slide now supports saving a background image to file, this matches the pre-existing set background image option.<br />
<br />
'''View/Edit Control Points'''<br />
The Shape Properties dialog for enhanced shapes now lists and enables editing the control points. This is in addition to the preexisting mechanism of selecting with the mouse the yellow control handle of the shape, but enables viewing and fine control over the control values. <br />
<br />
'''Presenter Console'''<br />
There is now a button on the presenter console to restart the timer of the slideshow without restarting the slideshow itself ([http://vmiklos.hu/blog/presenter-console.html see this blog entry])<br />
<br />
'''OpenGL Transitions'''<br />
All OpenGL transitions have been ported to OpenGL 2.1+, which removes support for very old GPUs but allows a better usage of modern ones. Four new transitions have been added which require OpenGL 3.2+ that exploit these new available features.<br />
<br />
==== Math ==== <br />
Import MathML from Clipboard<br />
<br />
* The tool “Math Input Panel” in Windows or the context menu of a formula in a browser allow to copy the MathML source to clipboard. The Math module in LibreOffice has got a new item “Import MathML from Clipboard” in menu Tools to import such source and convert it into LibreOffice’s own formula syntax StarMath.<br />
* MathML and StarMath have some differences and therefore sometimes corrections on the imported formula are needed, but most of the formula should be correct. If a conversion is not possible, nothing happens.<br />
* The import expects, that a <math> element exists, which has an attribute xmlns="http://www.w3.org/1998/Math/MathML".<br />
<br />
=== ThunderBird 52 ===<br />
Mozilla Thunderbird is a free,[10] open source, cross-platform email, news, RSS, and chat client developed by the Mozilla Foundation.<br />
<br />
===== New =====<br />
* Folder pane toolbar and folder view selector (replacement for folder view arrows)<br />
* Optionally remove corresponding data files when removing an account from Thunderbird<br />
* Import settings from Becky! Internet Mail<br />
* Possibility to copy message filter<br />
* Dictionary setting is restored when editing a draft. Content-Language header (RFC 3282) transmitted with message<br />
* Calendar: Event can now be created and edited in a tab<br />
* Calendar: Processing of received invitation counter proposals<br />
* Chat: Support Twitter Direct Messages<br />
* Chat: Liking and favoriting in Twitter<br />
* Chat: XMPP: Support SASL SCRAM authentication mechanism<br />
* Chat: Support Jabber/XMPP Message Carbons (XEP-280)<br />
<br />
===== Fixed =====<br />
* IMPORTANT: The way images are included in a compose window has changed. Images are now included as [https://en.wikipedia.org/wiki/Data_URI_scheme data URIs] and not as references to parts of other messages or operating system files. This allows better interoperability with office packages for LibreOffice. Images linked from locations on the internet will no longer be downloaded and attached to the message automatically. This can be changed for each image individually via the Image Properties dialog or globally by setting the preference mail.compose.attach_http_images.<br />
* Correspondents column now default for all new folders, can be switched off with preference mail.threadpane.use_correspondents<br />
* When replying to a mailing list, reply will be sent to address in From header ignoring Reply-to header<br />
* Formatting toolbar is now left in place when delivery format is switched to plain text only<br />
* Messages in IMAP folders read on external device are now filtered by default<br />
* Folders backed by mbox storage larger than 4GB are supported without warning (unless preference mailnews.allowMboxOver4GB is set to false)<br />
* IMAP caching now uses Mozilla's latest caching technology<br />
* The keyboard shortcut to insert hyperlinks into a compose window was changed from CTRL+L to CTRL+K to align with Office applications<br />
* Chat: Removed Yahoo! Messenger support ([https://web.archive.org/web/20160730080614/https://help.yahoo.com/kb/yahoo-messenger-for-web/SLN26860.html since Yahoo removed support])<br />
<br />
=== Kopano Core & WebApp ===<br />
<br />
Leap 42.3 brings Kopano Core and Kopano WebApp, part of a groupware for office collaboration:<br />
* Put bluntly, KC is a replacement for an Exchange Server installation. More technically, it is a set of remote system services for handling email, contacts, calendars, events and tasks. kopano-server is the main storage service where emails get placed into an indexed key-value store. Protocols like LMTP, IMAP, POP3, iCal/CalDav and HTTPRPC enable connectivity from and to e.g. postfix, Thunderbird, Outlook and mobile systems like Android, BlackBerry, iOS, etc.<br />
* WebApp is a PHP/JS-based webinterface similar in looks to Outlook Web Access for connecting to a kopano-server instance.<br />
* The optional Z-Push extension (to be obtained separately) is a PHP-based web service that translates ActiveSync requests for a kopano-server instance.<br />
* For more information, see the [https://en.wikipedia.org/wiki/Kopano_%28software%29 wikipedia article] and the [https://documentation.kopano.io/ Kopano online documentation].<br />
<br />
== Desktop Environments ==<br />
<br />
=== Enlightenment ===<br />
Enlightenment is classed as a “desktop shell” providing the things you need to operate your desktop (or laptop), but is not a whole application suite. This covers launching applications, managing their windows and doing other system tasks like suspending, reboots, managing files etc. openSUSE Leap 42.3 comes with Enlightenment 0.21.8, an upgrade from the 0.21.3 version found in Leap 42.2.<br />
<br />
==== Changes ====<br />
<br />
* Fixed macro namings in relation to endianness.<br />
* Fixed compiler type warnings (snprintf)<br />
* E keyboard settings - use the same icon as the keyboard settings dialog<br />
* e randr2 - fixed freeing of stringshare by making it a stringshare<br />
* Fixed fullscreen no blank logic in e's dpms code<br />
* Further fixes to screensaver/banking with window states like fullscreen<br />
* Better protect comp object internals from dereferencing freed clients<br />
* Add all wl client frame callbacks with priority AFTER<br />
* Defer menu activation mouse-up feed<br />
<br />
Further changes to Enlightenment 0.21.8 can be found [https://www.enlightenment.org/news/e0.21.8_release here].<br />
<br />
=== GNOME ===<br />
<br />
openSUSE Leap 42.3 ships with the same GNOME as it did in Leap 42.2 - GNOME 3.20. <br />
<br />
==== GNOME Applications ====<br />
<br />
=====Files (Nautilus)=====<br />
it is now possible to access Google Drive directly from the Files application, as well as from file chooser dialogs. To use the feature, simply add your Google account through the Online Accounts settings, and Google Drive will automatically appear in the files places sidebar.<br />
<br />
Once set up, Google Drive behaves very similarly to the rest of your files and folders: files can be opened using your normal applications, and folders can be created just like regular folders. It is also really easy to upload files to Google Drive — all you have to do is move or copy them across.<br />
<br />
Furthermore, long-running operations (such as copying or moving large numbers of files) have also been improved: a button shows progress information in the header bar, which shows more detailed information when pressed. This allows you to easily see progress at a glance, and avoids progress windows getting in the way.<br />
<br />
Search has been a particular focus: search filters have been revamped, and are vastly simpler and easier to use than the previous version. Search has also been made more robust: performance issues have been addressed, and the interface is faster and more responsive.<br />
<br />
=====GNOME Calendar=====<br />
Calendar is a new application for GNOME, which was initially introduced as a preview in 3.16. Designed to be consistent with other GNOME 3 applications, and to be fully integrated with GNOME 3, Calendar makes a great addition to the GNOME application suite. It is attractive, simple to use, and is fully integrated with GNOME Online Accounts.<br />
<br />
The initial feature list is simple and straightforward, including month and year views, search, the ability to add calendars from files and remote calendars from URLs, online accounts integration, and event viewing and editing.<br />
<br />
=====Automatic screen brightness=====<br />
If your computer has an integrated light sensor, GNOME 3 is now able to use it to automatically control screen brightness. Not only does this ensure that the screen is always easy to see, but it also helps to reduce battery consumption. An option is provided to disable automatic screen brightness in the Power settings, should you want to turn it off.<br />
<br />
=====Simple and Easy Photo Editing=====<br />
With GNOME 3.20, editing has arrived in 'Photos'. The new editing controls are simple and easy to use. All editing is non-destructive, so your original photo is preserved and changes can be undone. Editing functions include crop and rotate, color adjustment and picture enhancement. A selection of artistic filters are also available.<br />
<br />
=====Quickly Access Media Controls=====<br />
With GNOME 3.20, media controls are now built-in and displayed in the notification/clock area. This provides a way to quickly access music and video applications that are currently in use. Controls for multiple media applications can even be shown at the same time.<br />
<br />
The controls show the name and artist of the currently playing track, which can be paused and resumed. It is also possible to skip forward and back. This new feature works with a large range of music players, using the common MPRIS standard.<br />
<br />
=====Maps=====<br />
Maps now supports editing and adding place information using your OpenStreeMap login.<br />
In addition, it supports printing of routes, as well as saving and exporting maps as png images for inclusion into your documents and emails.<br />
<br />
=====Other Little Improvements=====<br />
<br />
* Applications launchers on the dash and application overview now come with convenient secondary-click shortcuts. Try secondary click (right click or long press after primary-click) on the evolution icon to directly open the mail composer, calendar, contacts, tasks and more.<br />
* Many applications in GNOME now feature a helpful Keyboard Shortcuts window (e.g., try hitting Ctrl+? when the Files application is open).<br />
* Polari, the IRC chat application, now automatically pastes images and large blocks of text to a pastebin service and prints the corresponding pastebin URL into your chat message, making the drag of pasting these manually and then copy-pasting the link back into your IRC chat a convenient one-step process.<br />
* Evince, the pdf and djvu document viewer, has seen a major improvement to its annotations interface: highlighting is now supported as one of the annotations, in addition to the existing text annotations supported earlier.<br />
* Location awareness settings can now be controlled at the application level, thus making the feature more privacy focused.<br />
* The Mouse and touchpad settings panel in system settings has been redesigned and is much more convenient to work with.<br />
* Web (or Epiphany), GNOME's other browser, has also undergone several exciting changes. At the user interface level, it has now gained a pretty popover to show ongoing and completed downloads. But, its major new feature is the session restore, whereby if you choose to restore your tabs from the previous browsing session, it now also restores your entire session history, including the scroll position from the previous session.<br />
* Boxes, GNOME's super user-friendly virtualization app, now has an improved list view where it shows the current status of all your virtual machines.<br />
* New applications available from the default repositories<br />
** Lollypop — A new feature-rich music player<br />
** GNOME To Do — A tasks application<br />
** Calendar — A user-friendly calendar and appointment manager<br />
** Guake — A dropdown terminal<br />
<br />
==== GNOME Infrastructure / internals ====<br />
<br />
=====dconf editor=====<br />
dconf Editor has had a facelift for 3.20. Settings lists have been overhauled, to give a better overview, with each row now including the description for the setting. Search uses the standard design found in other GNOME applications, making it easier to find. Search can also be activated by just starting to type.<br />
<br />
=====GTK+ Inspector=====<br />
The GTK+ Inspector keyboard shortcut must be explicitly enabled. This can be done using DConf Editor, by checking enable-inspector-keybinding in org ▸ gtk ▸ settings ▸ Debug. Alternatively, you can run the following command:<br />
<br />
gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true<br />
<br />
=====GLib=====<br />
* Threadpools are no longer limited to 10 threads.<br />
* Information about metered networks is now available in GNetworkMonitor.<br />
* Portability improvements: GNotification has now been implemented on OS X, and GAppInfo has been partially implemented on Windows (this is backed by the registry).<br />
<br />
=====Builder=====<br />
Builder is the new integrated development environment for GNOME, which aims to make it quick and easy to do all kinds of development work, particularly application development. Thanks to a successful crowdfunding campaign, a huge amount of progress has been made on Builder since last release. While it is still under heavy development, it is already becoming an extremely effective tool.<br />
<br />
=== KDE Plasma 5.8 ===<br />
openSUSE Leap 42.3 will once again have the Long Term Support version for KDE Plasma 5.8. At the release of Leap 42.3, version 5.8.7 offers many feature refinements and new modules to complete the desktop experience.<br />
<br />
The global menu functionality, known from KDE 4 times already, is supported by the Plasma Desktop in openSUSE Leap 42.3.<br />
<br />
Three months worth of new translations and fixes from KDE's contributors gives KDE user a great user experience. The bugfixes are typically small but important and include fixes for user management, system setting, audio volume controls and the Plasma workspace.<br />
<br />
KDE now integrates with Google Drive thanks to kio-gdrive which allows to access your data in the cloud from Dolphin as well as KDE file dialogs. To use your account, install the kio-gdrive package, open Dolphin, click on Network and then on Google Drive and "New account". The new place can be added to the side panel to access your Google Drive files easily from all KDE applications. <br />
<br />
==== Applications 17.04.2 ====<br />
The newest applications provides several fixes and new features. From Dolphin to konqueror, Applications 17.04.2 enhances the experience of users. Changes for Applications 17.04.2 can be found [https://www.kde.org/announcements/fulllog_applications.php?version=17.04.2 here].<br />
<br />
===== Dolphin =====<br />
* Correct searchbox, split view transitions between tabs.<br />
* Show pointing hand cursor when hovering spaceinfo bar.<br />
* Change "Date" to "Modified" and allow access to new "Accessed" time field.<br />
* Fixed async conditions.<br />
* DolphinSearchBox: Add a "More search tools..." menu button.<br />
* Apply the file preview shadow frame to most previews instead of only image file previews.<br />
<br />
===== kalgebra =====<br />
* Offer the same default window size as the legacy UI.<br />
* PrintSupport only needed for the Widgets-based UI.<br />
* Implementation for pasting text from log to input.<br />
* Use PlotsView3DES to render 3D plots.<br />
<br />
===== konqueror =====<br />
* Restore/port the "Default web browser engine" setting. <br />
* Fix 'Home Folder' button action.<br />
* Use PlotsView3DES to render 3D plots.<br />
<br />
===== print-manager =====<br />
* Fix moving print job to another printer.<br />
* Make kded happy by prepending "kded_" to the X-KDE-Library value "printmanager". <br />
* Remove the depreciated Plasma PopupApplet servicetype.<br />
<br />
==== Frameworks ====<br />
KDE Frameworks 5.32.0 provides numerous component updates for KDE users. Among these are updates to KWidgetsAddons, KTextEditor, KPackage Framework, KNotification and many more. There are plenty of bugfixes and improvements in this frameworks release and Breeze has icons changes. The collection of libraries and software frameworks provide functionality and solutions needed for file format support, graphical control elements, plotting functions, spell checking and more. The release adds support for Flatpak portals through KNotification and KTextEditor adds sentence style capitalization with label texts of edit fields. KDE Kiosk, which has been built since KDE 3, can also be used.<br />
<br />
=== LXQt ===<br />
openSUSE Leap 42.3 ships with the same LXQt 0.11 version from Leap 42.2.<br />
<br />
* Multimonitor support improved a lot in this release (especially lxqt-panel)<br />
* Search functionality in lxqt-panel menu<br />
* New component: pavucontrol-qt Qt interface to Pulseaudio<br />
* lxqt-config contains now a tool to adjust display brightness<br />
* The pattern changed from gwenview to the newly included Lximage-qt as the default image viewer<br />
* pattern requires lightdm now<br />
<br />
See [http://lxqt.org/release/2016/09/24/lxqt-011-et-al/ LXQt release notes] for complete LXQt release notes.<br />
<br />
== Health ==<br />
openSUSE Leap 42.3 has packages that support worldwide health care initiative and is proud to be assisting projects with improving health and science efforts. <br />
<br />
=== GNU Health ===<br />
GNU Health, developed by GNUSolidario, a non-profit, non-government organization (NGO), delivers free open-source software for health practitioners, health institutions and governments worldwide. GNU Health’s free software provides functionality to facilitate a Hospital Information System (HIS), Health Information System and Electronic Medical Record (EMR) management. It is translated into many languages, amongst which are: Arabic, Chinese (China), English (United Kingdom), French, German, Greek, Italian, Japanese, Kannada, Lao, Portuguese (Brazil), Spanish (Argentina), Spanish (Ecuador), Spanish (Mexico), Spanish (Peru) and Spanish (Spain). <br />
<br />
The new GNU Health release 3.2 is a major milestone, as it was completely ported to Python 3. It sets the ground for the upcoming GNU Health Federation.<br />
<br />
==== New ====<br />
* Tryton 4.2 integration<br />
* All GNU Health packages are now written in Python 3<br />
* Enhanced support for Calendar and WebDAV system<br />
* Updated Crypto packages<br />
* Link lab orders with health services<br />
* Better language and localization, that optimizes translation for regional languages<br />
* Add cod39 to lab tests<br />
* Include the Domicilary Unit address in the main person information<br />
* Improved gnuhealth-setup and gnuhealth-control programs (gnuhealth-control comes with a version adapted to openSUSE)<br />
* Patient, Medicament and Services can now be activated / deactivated<br />
<br />
==== New Modules ====<br />
* health_ems : Emergency and Ambulances Management<br />
* health_insurance : Insurance management and pricelists<br />
* health_genetics_uniprot : Uniprot DB for thousands of genetic natural variants and phenotypes<br />
* health_crypto_lab : Digital signatures for lab orders<br />
* health_services_lab : Integrate lab orders into services<br />
<br />
=== health-check ===<br />
Health-check monitors processes and optionally their child processes and threads for a given amount of time. At the end of the monitoring it will display the CPU time used, wakeup events generated and I/O operations of the given processes. It can be used to diagnose unhealthy bad processes.<br />
<br />
== openSUSE technologies==<br />
<br />
=== AutoYaST ===<br />
<br />
AutoYaST is now more robust, powerful and friendly than ever. Apart from faster installation in many situations and better reporting of the adjustments automatically performed to the partition sizes, the management of services have been moved to the first AutoYaST stage, opening many new possibilities for more flexible unattended scenarios.<br />
<br />
But the new jewel of the AutoYaST crown is its brand new integration with SaltStack and other configuration management systems introduced by the new addition to the Leap family: the [https://github.com/yast/yast-configuration-management yast2-configuration-manager] package. Now AutoYaST can take care of the system installation (partitioning, network setup, etc.) and then delegate the system configuration to one of those widely used external tools.<br />
<br />
=== Snapper ===<br />
openSUSE Released Snapper 0.5.0 in may and users of Leap benefit from the cleanup of an algorithm for rollback snapshots. [http://snapper.io/ Snapper] snapshots based on the btrfs filesystem is more mature and is less disk-hungry. Snapper was also improved to work with a read-only btrfs root filesystem, which is related to openSUSE Kubic that uses a read-only root filesystem and uses transactional updates.<br />
<br />
(Transactional updates work by creating a snapshot of the system and then updating the packages in that new snapshot. This way the update does not affect any of the running services. Instead the update is activated by a reboot. A read-only root filesystem on a system with transactional updates simply ensures that the update does not accidentally modify the running system. When installing openSUSE with YaST, the space aware cleanup will be enabled for the root filesystem.)<br />
<br />
=== YaST ===<br />
<br />
The YaST development sprints have brought tons of improvements to openSUSE Leap 42.3. The YaST community has been working hard to improve usability and continues to add new tools and modules in Tumbleweed and Leap. The list of improvements include extending the ability to configure and use Trusted Boot also to EFI systems, new possibilities for network installation, enhancements in the YaST partitioner and better integration with Systemd services.<br />
<br />
But the most visible change is the revamped desktop selection screen in the installer, that offers a more fair playground for all graphical environments beyond KDE and Gnome. The installer does not longer offers a predefined selection of "secondary" desktops environments, but relies on the existing patterns created and maintained by the enthusiasts of every graphical environment. So the "those who do, decide" principle now also drives the selection of available desktops.<br />
<br />
== Scientific and Educational Apps ==<br />
<br />
=== Avogadro ===<br />
Avogadro is an advanced molecular editor designed for cross-platform use in computational chemistry, molecular modeling, bioinformatics, materials science, and related areas. It offers flexible rendering and a powerful plugin architecture).<br />
<br />
=== Chemical MIME Data ===<br />
A collection of data files which tries to give support for various chemical MIME types (chemical/*) on Linux/UNIX desktops. Chemical MIME's have been proposed in 1995, though it seems they have never been registered with IANA.<br />
<br />
=== Octave === <br />
GNU Octave is a high-level language, primarily intended for numerical computations. It provides a convenient command line interface for solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with Matlab. It may also be used as a batch-oriented language.<br />
<br />
Octave has extensive tools for solving common numerical linear algebra problems, finding the roots of nonlinear equations, integrating ordinary functions, manipulating polynomials, and integrating ordinary differential and differential-algebraic equations. It is easily extensible and customizable via user-defined functions written in Octave’s own language, or using dynamically loaded modules written in C++, C, Fortran, or other languages.<br />
<br />
=== KStars ===<br />
KStars is free, open source, cross-platform Astronomy Software. It provides an accurate graphical simulation of the night sky, from any location on Earth, at any date and time. The display includes up to 100 million stars, 13,000 deep-sky objects,all 8 planets, the Sun and Moon, and thousands of comets, asteroids, supernovae, and satellites. For students and teachers, it supports adjustable simulation speeds in order to view phenomena that happen over long timescales, the KStars Astrocalculator to predict conjunctions, and many common astronomical calculations.<br />
<br />
=== Open Babel ===<br />
Open Babel is a chemical toolbox designed to speak the many languages of chemical data. It's an open, collaborative project allowing anyone to search, convert, analyze, or store data from molecular modeling, chemistry, solid-state materials, biochemistry, or related areas.<br />
<br />
=== Scilab ===<br />
Scilab is a scientific software package for numerical computations providing a powerful open computing environment for engineering and scientific applications which includes hundreds of mathematical functions with the possibility to add interactively programs from various languages (C, C++, Fortran...). It has sophisticated data structures (including lists, polynomials, rational functions, linear systems...), an interpreter and a high level programming language. Matlab and Maple files can be converted.<br />
<br />
=== Step ===<br />
Step is an open source two-dimensional physics simulation engine that is included in the KDE SC as a part of KDE Education Project.[1] It includes StepCore, a physical simulation library.<br />
<br />
== Security ==<br />
openSUSE Leap 42.3 offers several packages for security. Below are just of the few packages you can use to ensure you are protecting your system.<br />
<br />
=== apparmor ===<br />
AppArmor is an effective and easy-to-use Linux application security system. AppArmor proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good behavior and preventing even unknown application flaws from being exploited. <br />
<br />
AppArmor 2.10.2 is an incremental bug fix release over AppArmor 2.10.1 that is focused on fixing issues in the userspace code. <br />
<br />
=== Lynis ===<br />
Lynis is a security and system auditing tool. It scans a system on the <br />
most interesting parts useful for audits, like: <br />
* Security enhancements <br />
* Logging and auditing options <br />
* Banner identification <br />
* Software availability <br />
<br />
=== yast2-security ===<br />
The YaST2 component for security settings configuration.<br />
<br />
== Tools ==<br />
<br />
=== CMake 3.5.2 ===<br />
CMake is an extensible, open-source system that manages the build process in an operating system and in a compiler-independent manner. Unlike many cross-platform systems, CMake is designed to be used in conjunction with the native build environment. Simple configuration files placed in each source directory (called CMakeLists.txt files) are used to generate standard build files (e.g., makefiles on Unix and projects/workspaces in Windows MSVC) which are used in the usual way. CMake can generate a native build environment that will compile source code, create libraries, generate wrappers and build executables in arbitrary combinations.<br />
==== GUI ====<br />
* The cmake-gui(1) gained options to control warnings about deprecated functionality.<br />
* The cmake-gui(1) learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing -T option to cmake(1).<br />
* The cmake-gui(1) gained a Regular Expression Explorer which may be used to create and evaluate regular expressions in real-time. The explorer window is available via the Tools menu.<br />
<br />
==== Command-Line ====<br />
* The -Wdev and -Wno-dev cmake(1) options now also enable and suppress the deprecated warnings output by default.<br />
* The suppression of developer warnings as errors can now be controlled with the new -Werror=dev and -Wno-error=dev cmake(1) options.<br />
* The cmake(1) -E command-line tools copy, copy_if_different, copy_directory, and make_directory learned to support multiple input files or directories.<br />
<br />
==== Commands ====<br />
* The cmake_parse_arguments() command is now implemented natively. The CMakeParseArguments module remains as an empty placeholder for compatibility.<br />
* The install(DIRECTORY) command learned to support generator expressions in the list of directories.<br />
<br />
==== Variables ====<br />
* The CMAKE_ERROR_DEPRECATED variable can now be set using the -Werror=deprecated and -Wno-error=deprecated cmake(1) options.<br />
* The CMAKE_WARN_DEPRECATED variable can now be set using the -Wdeprecated and -Wno-deprecated cmake(1) options.<br />
<br />
==== Modules ====<br />
* The ExternalProject module learned a new GIT_REMOTE_NAME option to control the git clone --origin value.<br />
* The FindBoost module now provides imported targets such as Boost::boost and Boost::filesystem.<br />
* The FindFLEX module FLEX_TARGET macro learned a new DEFINES_FILE option to specify a custom output header to be generated.<br />
* The FindGTest module now provides imported targets.<br />
* The FindGTK2 module, when GTK2_USE_IMPORTED_TARGETS is enabled, now sets GTK2_LIBRARIES to contain the list of imported targets instead of the paths to the libraries. Moreover it now sets a new GTK2_TARGETS variable containing all the targets imported.<br />
* The FindOpenMP module learned to support Clang.<br />
* The FindOpenSSL module gained a new OPENSSL_MSVC_STATIC_RT option to search for libraries using the MSVC static runtime.<br />
* The FindPNG module now provides imported targets.<br />
* The FindTIFF module now provides imported targets.<br />
* A FindXalanC module was introduced to find the Apache Xalan-C++ XSL transform processing library.<br />
* The FindXercesC module now provides imported targets.<br />
<br />
==== Platforms ====<br />
* Support was added for the ARM Compiler (arm.com) with compiler id ARMCC.<br />
* A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details.<br />
* The Compile Features functionality is now aware of features supported by Clang compilers on Windows (MinGW).<br />
* When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the IOS_INSTALL_COMBINED target property.<br />
<br />
=== nodejs ===<br />
As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications. openSUSE Leap 42.3 comes with nodejs 4 and 6. The most notable change for nodejs version 6.9.5 is upgrade openssl sources to 1.0.2k; this was also made available in nodejs version 4.7.3.<br />
<br />
=== Qt ===<br />
<br />
The Qt libraries were updated to Qt 5.6.2, which is a bug-fix release. It maintains both forward and backward<br />
compatibility (source and binary) with Qt 5.6.0. This is the second patch release to the long-term supported Qt 5.6, and there will still be more patch releases to come. While a patch release does not bring new features, it contains security fixes, error corrections and general improvements. Read more about [http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released/ Qt 5.6.2]. Qt now detects remote print queues using avahi. This adds a delay the first time a print dialog is opened in an application. If you don't have any network print queues and you find the delay too annoying, it can be disabled by setting the QT_DISABLE_PRINTER_DISCOVERY environment variable to 1 in /etc/environment .<br />
<br />
As part of this update, Qt Creator has been updated to 4.3.0. Qt Creator 4.3 integrated a code editor into Qt Quick Designer, which allows you to use the Properties editor and the Navigator also while editing code. Split the view to show both the graphical and the code editor, and directly see how a change in the graphical editor affects the code, and vice versa.<br />
<br />
=== GNU Compiler Collection ===<br />
<br />
GCC7 is available as optional compiler. The same is true for GCC 5 and GCC 6. This gives developers tons of options. The default compiler is GCC 4.8.5.<br />
<br />
=== Ruby 2.4 ===<br />
<br />
Ruby 2.4 is available as an optional choice in addition to ruby 2.1, 2.2 and 2.3<br />
<br />
== What else is new ==<br />
<br />
* The zypper lifecycle plugin allows list installed packages that require updating or are no longer supported<br />
* postgresql 9.6 is the default, postgresql 9.4 is still available though<br />
<br />
[[Category:42.3]]<br />
[[pl:Features_42.3]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Build_Service_Collaboration&diff=119664openSUSE:Build Service Collaboration2017-06-17T06:04:50Z<p>Okurz: /* Special handling for openSUSE:Factory */ grammar and language</p>
<hr />
<div>{{Buildservice navbar}}<br />
[[Category:Build_Service]]<br />
=Introduction=<br />
<br />
The Open Build Service offers different ways of collaboration. The easiest way is to grant write access for more people in a package or project. This way allows a small team working closely together to collaborate very quickly.<br />
<br />
However, this approach does not work in a number of cases:<br />
<br />
* Unknown contributors have no write access and therefore can't submit changes.<br />
* The trust of a project decreases with the number of people who have write access.<br />
* Even people with write access might want to get a review of their changes, before becoming active in a project.<br />
* Continual changes in a large project lead to the situation where the project never finishes to build. Changes to base packages can block other packages indefinitely.<br />
<br />
Therefore, the Open Build Service offers another way of making contributions. You can prepare changes in a branched project and then request to have the changes merged back.<br />
<br />
Large projects, such as KDE, GNOME, Apache, and YaST, often need another layer of review, where submissions can be staged before being checked in to the main project. This is the case with openSUSE:Factory, for example. This project defines a development project for each package. The Open Build Service helps the user to develop against these projects and to submit contributions there. The project owners of the development project can then submit all the contributions to openSUSE:Factory. This process is visualized in [[Media:OBS_SubmitRequest.pdf|these slides]].<br />
<br />
=Example with CLI=<br />
<br />
Our CLI (Command Line Client) is called <tt>osc</tt> (<Install it with tt>sudo zypper install osc</tt>).<br />
<br />
{{Warning| This page describes the osc UI since version 0.119. Older versions had slightly different commands.}}<br />
<br />
[http://duncan.mac-vicar.com/2008/08/20/opensuse-build-service-layering-linking-patching-and-aggregating/ Here is another example ] mentioning the use of the web client, of layering, linking, patching and aggregating for one project (PackageKit) is here:<br />
<br />
<br />
==How do I contribute my changes to someone else packages?==<br />
<br />
Let's say you want to work on the package openSUSE:Factory/initviocons, and later submit your work back into the openSUSE:Factory project.<br />
<br />
The following shows you what to do, step by step.<br />
<br />
===Create a Branch Package===<br />
<br />
First, we create a branch of the package we want to work on in our home project.<br />
<br />
# osc branch <nowiki><source project> <source package></nowiki><br />
osc branch openSUSE:Factory initviocons<br />
<br />
This command first creates a new personal 'branch project' below home:$yourself:branches, if it does not exist yet. This branch project has the same build setup as the original source project. Then the command also creates the package inside of the branch as a source link.<br />
<br />
Many packages have a 'Devel Project' defined. In that common case, the server creates a link to that devel project instead of the source project. You see this in the 'osc branch' output, like this:<br />
<br />
# branch a package from factory but which is developed in a different project<br />
osc branch openSUSE:Factory glib2<br />
<br />
will create home:$yourself:branches:GNOME:UNSTABLE/glib2.<br />
<br />
This ensures that your changes follow the existing flow of changes into the package's real home.<br />
<br />
===Work on Changes===<br />
<br />
Now that you have branched a package, you can start working on it. The following commands:<br />
<br />
osc checkout home:$yourself:branches:openSUSE:Factory initviocons<br />
cd home:$yourself:branches:openSUSE:Factory/initviocons<br />
<br />
check out the package to your local file system. The source link is <EM >expanded</EM >. When you branch a package, a link to the original is created instead of copying everything. With this link, our branch stays up to date if the original changes. To do work on your branch, you want to have the real package sources, not a _link XML file. So by default, checking out a linked package <EM >expands</EM > the link into the contents of the original package. You therefore get the original sources/files plus any existing changes in the checkout.<br />
<br />
Now prepare your changes. If the source files are not inside a .tar.gz archive, simply edit the files:<br />
<br />
vim <path/to/file><br />
...<br />
osc diff<br />
...<br />
<br />
<br />
If the source files are in a .tar.gz archive, you will need to do things a little differently. Prepare your patch with <tt>quilt</tt> (install it with <tt>sudo zypper install quilt</tt>):<br />
<br />
# Unpack the .tar.gz archive<br />
quilt setup <name of package>.spec<br />
cd <name of package-version number><br />
<br />
# Create a patch file to hold your changes<br />
quilt new <desired name of your patch>.patch<br />
<br />
# Edit the files<br />
# Option 1:<br />
quilt edit <path/to/file><br />
# Option 2:<br />
quilt add <path/to/file><br />
<edit the file in the graphical editor of your choice><br />
<br />
# Give your patch a clear description<br />
quilt header -e<br />
<br />
# Complete the patch file once you're done editing everything<br />
quilt refresh<br />
<br />
# Integrate your patch into the package<br />
cp patches/<name of your patch>.patch ..<br />
cd ..<br />
/usr/lib/build/spec_add_patch <name of your patch>.patch<br />
<br />
# Add your patch to the repo<br />
osc add <name of your patch>.patch<br />
<br />
<br />
Now Give your change a clear description, mentioning the bug in this format: "(bsc#<number of bug>)"<br />
osc vc<br />
<br />
Do a local test-build to make sure everything works:<br />
osc build<br />
<br />
Local builds help to lower the turnaround times while you develop; there's no need to wait for the Open Build Service to finish building (or failing to build) your package each time you make a change.<br />
<br />
Once your changes package builds locally, it's time to inform the Open Build Service about your changes:<br />
<br />
# commit the changes<br />
osc commit -m "changed this and that"<br />
<br />
Your changes go to the server, and a build is scheduled. <br />
<br />
Even though you checked out expanded sources, there's no need to create patches against the base package yourself. The Open Build Service takes care of all that, by comparing your branch and the original and creating diffs in your (unexpanded) on the Open Build Service.<br />
<br />
<br />
After a while you can see if it all worked out with:<br />
<br />
# check whether it builds<br />
osc results<br />
<br />
Sometimes you'll want to see how your work is different from the original package. You may want to discuss your changes with somebody else, for example, or you may simply want to see what other developers have been doing at the same time. To do so, use:<br />
<br />
# show differences between your version and the one in openSUSE:Factory<br />
osc rdiff home:yourself:branches:openSUSE:Factory initviocons<br />
<br />
===Debugging the build===<br />
<tt >osc build </tt > leaves some files in the build directory that can help you diagnose the problem. The last statement output by <tt >osc build </tt > is:<br />
<br />
The buildroot was: /var/tmp/build-root<br />
<br />
If you go there, you can examine the following files of interest:<br />
<br />
{|<br />
!name!!meaning<br />
|-<br />
|<tt >.build.log</tt >||Examine the build and identify the error<br />
|-<br />
|<tt >.build.command</tt >||The command used to do the actual build<br />
|-<br />
|<tt >.build.packages</tt >||The directory where the object files are <br />
|}<br />
<br />
If the build fails, you might be tempted to try to fix something ''in the build directory''; this is usually not a good idea because the command <tt >osc build </tt > usually discards everything there ( <tt >rm -rf </tt > ) and restarts from scratch. This strategy is unfortunately not viable for incremental changes: if the build takes a long time, which is quite likely for large projects. To work around this problem, look at the file <tt >.build.command</tt >; it usually contains a line of the form<br />
<br />
rpmbuild -ba package.spec<br />
<br />
That command will discard everything you have built, so it is of no use either. However, this command is likely to resume the build:<br />
<br />
rpmbuild -bc --short-circuit package.spec #compile<br />
rpmbuild -bi --short-circuit package.spec #install<br />
<br />
These options are explained in detail in the [http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ Fedora RPM Guide].<br />
<br />
===Submit your changes to be merged===<br />
<br />
Once you are satisfied and believe that your changes have a good chance of being accepted by the maintainers of the upstream project -- that is, if you are using the examples elsewhere in this document, by the maintainers of the openSUSE:Factory project -- you can go ahead and request a submit.<br />
<br />
osc submitrequest -m 'version update to 3.3'<br />
<br />
This submits the changes of the package in your local working copy to the project defined in the source link.<br />
<br />
You can also do so without a checked out working copy by calling<br />
<br />
osc submitrequest home:$yourself:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'<br />
<br />
This creates a request that indicates that you're offering something brilliant for Factory. :-) The maintainers of the project will quickly check it out. If the change is acceptable, they can merge it into their project. If it needs more work, they can send you further feedback.<br />
<br />
==How is my contribution handled?==<br />
<br />
The maintainer of a project (like openSUSE:Factory) is supposed to check for contributions (i.e. for submit requests) like this:<br />
<br />
<br />
% osc request list openSUSE:Factory<br />
37 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'version update to 3.3'<br />
<br />
<br />
The maintainer will look at the change by comparing it with the current package source, and either accept it or decline it and give a reason.<br />
<br />
% osc request show -d 37<br />
Request to submit (id 37): <br />
<br />
home:poeml/initviocons -> openSUSE:Factory/initviocons<br />
<br />
Source revision MD5:<br />
f839321325a0b5582def283c3520bf13<br />
<br />
Message:<br />
'version update to 3.3'<br />
<br />
State: new 2008-03-20T19:57:02 poeml<br />
<br />
<br />
<br />
changes files:<br />
--------------<br />
--- initviocons.changes<br />
--- initviocons.changes<br />
@@ -20 +20 @@<br />
- which sends a characteristic primary da<br />
+ which sends a characteristic primary DA<br />
[...]<br />
<br />
<br />
After that, the maintainer can accept the submission:<br />
<br />
osc request accept 37<br />
<br />
Or reject it, with a reason:<br />
<br />
osc request decline -m "changelog missing, but required by policy" 37<br />
<br />
=Example with web interface=<br />
<br />
This describes how to change sources via the web interface, you can find it for openSUSE behind http://build.opensuse.org.<br />
<br />
The webui is nice to get an overview and to change simple things, like obvious errors or package descriptions. For doing more complex changes, like fixing merge conflicts the CLI is recommended.<br />
<br />
==How do I contribute my changes to someone else packages?==<br />
<br />
Let's say you want to work on the package openSUSE:Factory/initviocons, and later submit your work back into the openSUSE:Factory project.<br />
<br />
The following shows you what to do, step by step.<br />
<br />
===Create a Branch Package===<br />
<br />
You need to create a branch, which is basically a copy of the original package, because you usually don't have write access in the target. Or you want to experiment first, before shipping your code to all users.<br />
<br />
The branch is always merging by default with changes from the branched package.<br />
<br />
For openSUSE:Factory go to the [https://build.opensuse.org/project/packages?project=openSUSE%3AFactory package list] and find your package.<br />
<br />
====Create Branch Project====<br />
<br />
Firstly, we create a branch of the package (and its project) we want to work on in our home project. Click on the "Actions" menu and afterwards on "Branch package".<br />
<br />
This server creates a new project below home:$yourself:branches, the branch project. This branch project has the same build setup as the original source project. The command also creates the package inside of the branch as a source link.<br />
<br />
Many packages have a 'Devel Project' defined. In that common case, the server creates a link to that devel project instead of the source project. You see this in the 'osc branch' output, like this:<br />
<br />
===Work on Changes===<br />
<br />
Click on the "source files" tab and edit your sources as wanted. You should wait and see if they are really building.<br />
<br />
You may also want to download the packages and try if your changes really make a difference at runtime.<br />
<br />
===Submit your changes to be merged===<br />
<br />
{{Warning|This feature is currently not implemented for frozen projects like openSUSE:11.0, Fedora:9 or the :Update projects. This requires changes in our maintenance handling which will come later :)}}<br />
<br />
Once you are satisfied and believe that your changes have a good chance of being accepted by the maintainers of the upstream project -- that is, if you are using the examples elsewhere in this document, by the maintainers of the openSUSE:Factory project -- you can go ahead and request a submit.<br />
<br />
You can either create a submit request via the "Actions" menu or find the link "show diff and submit these changes back" on the "Source Files" page.<br />
<br />
This will create a request for the target author, who will review your change and usually accept it. Your branched package is usually remove after merging back (except you denied this).<br />
<br />
<br />
= Special handling for openSUSE:Factory =<br />
<br />
Each package in openSUSE:Factory has a "development repository". These development repositories are used for development of the package itself. (You can "see" the develproject of a package via ''osc meta pkg openSUSE:Factory <package> | grep devel'' or simpler with ''osc dp openSUSE:Factory <package>''.) If you do a <br />
osc branch openSUSE:Factory <package><br />
do not be surprised if you get the package from another location if you want to make changes for a package in openSUSE:Factory.<br />
<br />
To do a submitrequest to openSUSE Factory (Note: accepting a submitrequest in the development project does not trigger a submitrequest for Factory automatically!), a maintainer of the Devel-Project has to do something like:<br />
osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory<br />
<br />
So we have two scenarios here:<br />
<br />
== Branch, non-official Devel Project maintainer's workflow ==<br />
# ''osc branch openSUSE:Factory <package>''<br />
# ''osc submitrequest'' (sends the submitrequest to the devel project)<br />
# Devel-Project maintainer accepts via ''osc sr accept <id>''<br />
# Devel-Project maintainer creates a new submitrequest against Factory<br />
# Autobuild people accept the change<br />
<br />
== Devel Project maintainer's workflow ==<br />
# Devel-Project maintainer creates a new submitrequest against Factory<br />
# The autobuild (openSUSE:Factory team) people accept the change<br />
<br />
{{Info|So for Devel Project maintainers, it is always a good idea to configure their [http://hermes.opensuse.org Hermes] notifications to get informed about submitrequests against their project and/or check for submitrequests against their project via<br />
osc request list <devel:project><br />
}}<br />
<br />
[[de:openSUSE:Zusammenarbeit im Build Service]]<br />
[[el:openSUSE:Build Service Collaboration]]<br />
[[ja:openSUSE:Build Service での共同作業]]<br />
[[zh:openSUSE:Build_Service_Collaboration]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Bugreport_kernel&diff=119160openSUSE:Bugreport kernel2017-03-18T16:54:01Z<p>Okurz: /* Note: Configuration via YaST doesn't currently work due to bnc#773143 */ bnc#773143 is long fixed</p>
<hr />
<div>{{Bug navbar}}<br />
{{Kernel navbar}}<br />
{{Intro|This article is intended to help make it easier to diagnose and fix kernel bugs to all people involved in this process.}}<br />
<br />
==Linux Kernel Debugging Introduction==<br />
<br />
Diagnosing a Kernel bug is a difficult task but some simple categories of bugs that might be Kernel bugs include:<br />
<br />
* Hardware driver issues - missing drivers, missing features, etc<br />
* File system corruption - data corruption, missing files, etc<br />
* Hard locks - system lockups, or freezes see [[Wikipedia:Magic_SysRq_key|SysRq Key]]<br />
* Kernel oopses - printed in dmesg or /var/log/messages<br />
* Performance issues or latency <br />
<br />
This document is intended for: <br />
<br />
* supporters and consultants, so they know how to provide useful and valuable bug reports.<br />
* developers, who need to know about debugging facilities provided by the Linux kernel<br />
<br />
==A Classification of Kernel Bugs==<br />
<br />
Kernel bugs can be categorized in a number of different schemes (e.g. by their impact on security, data integrity, etc). As this document is about debugging, let's try to categorize them by complexity.<br />
<br />
* Not working as expected<br>Some kernel bugs are quite easy to localize and even reproduce, and do not affect the stability of the rest of the system. For instance, a network card may not work in certain configurations, or NFS produces weird errors.<br><br>These are often fairly easy to debug. All it takes is a precise description of what happens, and detailed description how to reproduce the problem. And of course a kernel hacker who has a good understanding of the subsystem :)<br />
* Kernel Oopses<br>If the kernel runs into an unexpected error condition (e.g. when dereferencing an invalid pointer), an exception handler will catch this error, abort the current process, and try to log a message describing the exception in some detail. Normally, the oops message is logged to the system log. It is also possible to display the message on the text console, but this is turned off by default and needs to be enabled manually.<br><br> As this log message starts with the words "Kernel Ooops", the entire event it commonly referred to as "oopsing".<br><br>When an oops occurs, the process that caused it was usually in the middle of some dreadfully important business inside the kernel, and was holding one or more locks. As the process is terminated immediately, none of these locks will be released, so that other processes trying to claim these locks later will hang forever.<br><br>If the user is in an X Windows session while the oops occurs, the machine may appear to be hung completely, because the X server got stuck on some stale kernel lock and does not react anymore.<br />
*Kernel panics<br>If an oops occurs inside an interrupt handler, the kernel will try to deliver the oops message, and then halt completely, because there is no sane way to recover after an interrupt handler crashed. This is called a kernel panic.<br><br>In the case of a kernel panic, the oops will not be written to syslog, simply because the syslog daemon will not be scheduled anymore.<br />
* Soft lockups<br>Some kernel bugs do not trigger oopses, but simply freeze the machine. They can be caused by deadlocks or livelocks, among other things. In most cases (unless some stupid bug causes an interrupt handler to spin on a lock), these soft lockups will not prevent delivery of interrupts.<br><br>If interrupt delivery is still possible, the machine will react to pings, and keyboard input will be echoed on the text console. However, processes will not make any progress anymore.<br><br>Still, the machine will be mostly unresponsive, because processes do not make any progress anymore.<br><br>A good way to test for this is to hit the numlock or capslock key; if the keyboard LEDs are turned on and off, you have a deadlock somewhere.<br><br>Also, the kernel will start flashing the numlock or caps-lock LED all by itself if it got hung.<br />
* Hard lockups<br>A hard lockup may occur as well; these are usually due to hardware problems (or excessive abuse of the hardware by some poorly written driver). If this happens, you're in trouble. You can stop reading now, and we wish you good luck in debugging this.<br />
<br />
==Getting the right Information==<br />
<br />
Users have a tendency to blame software problems on that part of the system that seems to be the most complex or mysterious from their point of view. Which in most cases is the kernel.<br />
<br />
That doesn't mean they have to be wrong. But it often means that their bug reports are inaccurate, or omit important details.<br />
<br />
So when you're tasked with debugging a Linux kernel bug (or what someone '''thinks''' is a Linux kernel bug) there is a number of questions on the symptoms you should ask first:<br />
<br />
* Hangs versus crashes<br>Is the machine hanging? Did it crash? Did it just ''appear'' to have crashed?<br><br>Even experienced users will not always remember to check the syslog for oops messages, especially if the kernel just behaves "slightly strange" without crashing and burning spectaculary. You can save yourself a lot of work if you ask them to check the syslog for oops messages nevertheless.<br><br>As described above, if the kernel oopsed while user was using X, it may appear to him as if the machine was hanging.<br><br>There is one indication that will tell you that the kernel paniced, even if you're in X: the numlock LED will start flashing.<br><br>In this case, it always helps to reproduce the problem after changing to the text console. If the machine isn't hung hard, the kernel will at least accept keyboard input. On the console, it will also be possible to capture additional information on the crash. As a minimum, you should tell the kernel to display the oops message on the console as well, using<br><br />
# klogconsole -r0 -l8<br />
:If the oops isn't written to the syslog (e.g. when the oops occurs inside an interrupt), capturing the output with a digital camera may still help (but please make sure that any images you attach to a bug report don't exceed 512k).<br><br>Alternatively, one can try to capture the oops via a serial console.<br><br>In addition, you may want to enable the sysrq key and capture some sysrq information, as described in section "Capturing sysrq information" below.<br><br><br />
* Eliminate well-known problems<br>There are certain classes of problems that are common as dirt. Be aware of these problem areas and try to get these out of the equation early on.<br />
:Item Number One on the list of annoying issues is probably ACPI:<br />
::Most of the time when a user reports a problem with a machine not booting properly, or hardware not getting set up correctly, this is caused by bad ACPI BIOS tables.<br />
::Try to boot with acpi=off to turn off ACPI entirely.<br />
::[list of all ACPI related kernel command line variables goes here]<br />
:Other Very Common Problems?<br />
* Eliminate non-essential variables<br>User bug reports often describe fairly specific scenarios, such as "I am using a USB disk with reiserfs on it exported via NFS while listening to my mp3s and all of a sudden the machine crashes".<br><br>This is a nice and accurate report involving almost every subsystem the kernel has (block device layer, VM, VFS, network, sound, ...)<br><br>To help you narrow down the problem, here is a bunch of things you can try:<br />
** does the problem exist with older/newer kernel versions as well?<br />
** if you take component X out of the equation, can the bug still be reproduced?<br />
** if you exchange component X for another, equivalent component (e.g. replacing reiserfs with ext3), does the problem persist?<br />
** if the problem implicates memory corruption or random hardware failure: can the problem be reproduced on a different machine?<br />
** Especially on large machines, random memory corruption could be caused by hardware problems with bad RAM. To diagnose bad RAM, use the installation CD, select memtest86 and run it for 24 hours.<br />
<br />
==Capturing Oops info==<br />
<br />
As described previously, a kernel crash will result in an Oops that gets written to the system log. The oops messages contain a great deal of information that can help you at least diagnosing the problem.<br />
<br />
In (relatively speaking) benign cases, the kernel will be able to continue despite the error condition, and the system will be stable enough to at least write the oops into the system log. If the kernel paniced, it is far from trivial to record an oops, however.<br />
<br />
Your worst enemy is the desktop. Any kernel messages printed to the console while the X server is running will not show up on the screen. The X server has a way of capturing messages printed on /dev/console and display them to you, but if the bug is bad enough to prevent syslogd and klogd from writing the oops to the syslog, the chances of X actually being able to display anything useful to you are very very small.<br />
<br />
So if you're able to reproduce the problem in some way, the first thing you should do is switch to a text console and bump the console logging info:<br />
<br />
klogconsole -r0 -l8<br />
<br />
This will switch the kernel's console log level to display ''anything'' it sends to syslogd on the virtual console as well. This includes any kernel oopses; if you trigger the kernel bug now, you will at least get a screenful of oops information.<br />
<br />
Note: if you're doing this frequently, please refer to the section on serial consoles below - this is really the preferred method, but as a first stab, just being able to ''read'' the oops is a major win. To learn how to read an oops, please refer to the file oops-reading.<br />
<br />
===Kdump===<br />
Starting with openSUSE 12.2 pre-releases, kdump has the ability to dump quickly and only capture the oops. YaST should eventually be updated to configure this automatically, but for now the following instructions should be used.<br />
<br />
* Install the yast2-kdump and kdump packages.<br />
* Use yast2-kdump to enable kdump<br />
* Edit /etc/sysconfig/kdump to change $KDUMP_DUMPFORMAT to "none" -- this will disable dumps in general and only save the Oops.<br />
* Reboot to enable the crashkernel zone in the kernel. Your system will operate normally until you reboot but will not capture Oopses. <br />
** Please note that enabling dump uses 128M of RAM except on large systems (more than 512GB RAM) where it must use more to accommodate larger page tables. Once you have reported your issue with the Oops generated, you may want to disable it again.<br />
<br />
Now attempt to reproduce your problem. Your system should reboot nearly immediately when it occurs after dropping to a text console. When you reboot, there should be a log file in /var/log/dump/<br />
<br />
==Using ksymoops==<br />
*This should not be needed for any openSUSE release, but may be useful for self-built kernels.<br />
<br />
A kernel oops usually includes a dump of the current processor state, including registers, the instruction pointers, and a function call back trace. For this to be of any use to the kernel developer, these addresses must be mapped to function and/or variable names, if possible.<br />
<br />
Current SUSE kernels support a feature called "kallsyms" where the running kernel includes a symbol table of itself, which allows it to resolve the addresses automatically when printing an oops.<br />
<br />
Older kernels do not have this feature, so the oops printed will contain just the raw addresses, which need to be converted by a user space application.<br />
<br />
This is what ksymoops is for: you can feed ksymoops a raw oops on standard input, and given the right symbol information, it will provide you with a cooked version of that oops that maps all the symbols ''and'' a disassembly listing of the hex instructions. It should '''not''' be used when kallsyms is turned on (which holds true for opensuse kernels).<br />
<br />
The crux of the matter is providing ksymoops with the right symbol information. This information is usually taken from the vmlinux image and the System.map file in <tt>/boot</tt>, which must '''exactly''' match the version of the kernel that generated the oops. Therefore, it is usually a good idea to run ksymoops on the machine where the crash happened.<br />
<br />
If it is to resolve module symbols properly, ksymoops also needs the list of kernel modules and their location in memory. A good way of providing this is to copy the file <tt>/proc/modules</tt> immediately before or after the oops occurred, and specify this copy on the ksymoops command line using the <tt>-l</tt> option:<br />
<br />
# ksymoops -l /tmp/proc-modules-copy < /tmp/my-oops<br />
<br />
Fortunately, much of this work is already done automatically when the oops is captured by syslogd, because syslogd will do all the symbols translations for you. This has the great advantage that it always uses the correct symbol list.<br />
<br />
Of course, oopses captured via the serial console will not have their addresses massaged by syslogd, so you will have to run ksymoops manually on this case.<br />
<br />
==Using sysrq==<br />
<br />
sysrq means "system request". This is the name for a bunch of magic key combinations that will tell the kernel to display various types of internal information, sync the file system or kill a task. Since this is somewhat security sensitive (esp. the task killing part), the sysrq keyboard commands are disabled by default for security reasons.<br />
<br />
One way to enable sysrq is to execute the following command at the shell prompt:<br />
<br />
echo 1 > /proc/sys/kernel/sysrq<br />
<br />
In addition, you may want to edit /etc/sysconfig/sysctl and change the variable ENABLE_SYSRQ to "yes". This will ensure that sysrq is enabled after reboot.<br />
<br />
To use sysrq, you need to press a "magic" key combination plus a command key. This magic key combination depends on the hardware platform, but on most platforms it's usually ALT-SysRQ (on some keyboards, the SysRQ key is labelled "PrtScr" or "Print", it's usually located to the right of the function keys).<br />
<br />
Most sysrq keys will cause the kernel to report status information to the serial console. In the default configuration, a SUSE system has all kernel generated output redirected to tty10, so you need to switch to console 10 or redirect the kernel console to a different tty using klogconsole.<br />
<br />
The most helpful command key is "h", which displays a short help text:<br />
<br />
SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem powerOff showPc<br />
unRaw Sync showTasks Unmount<br />
<br />
Here's a description of the most important commands:<br />
<br />
0-8 These keys change the console log level to the indicated <br />
level. 8 will display everything on the console, 1 will be <br />
critical messages only, and 0 turns console logging off entirely.<br />
M Display current memory statistics<br />
P Display current processor registers, instruction counter, call <br />
trace and list of loaded modules. This is essentially the process <br />
related information that would get printed as part of an oops.<br />
T Shows a listing of all tasks, including the back trace of their <br />
current kernel stack. Beware, this list can be very long.<br />
U Try to re-mount all currently mounted file systems read-only.<br />
E Send a TERM signal to all processes except init.<br />
I Send a KILL signal to all processes except init.<br />
<br />
There are a number of other sysrq keys; a complete list is available<br />
from Documentation/sysrq.txt in the kernel source.<br />
<br />
It is also possible to trigger sysrq commands from the command line,<br />
which is very useful if you do not have keyboard access (e.g. when<br />
debugging a problem remotely). In this case, simply echo the letter <br />
to /proc/sysrq-trigger and read back the information from dmesg or<br />
the syslog files:<br />
<br />
# echo t > /proc/sysrq-trigger<br />
<br />
==Using lkcd==<br />
[TBD]<br />
<br />
==Using nmi_watchdog==<br />
[TBD]<br />
<br />
==Using the serial console==<br />
Some kernel oops (especially during boot-up) might occur when the system console unusable.<br />
To get a reliable dump report a serial console helps in this case.<br />
You'll need a second machine and a null-modem cable (ie a serial cable with two identical<br />
connectors); additionally both machines have to have a serial port on them.<br />
This leaves some modern machines out of the equation, I'm afraid; you'll have to try to use<br />
netconsole on them.<br />
<br />
Once you've hooked the cable up you should add 'console=ttyS0,115200 console=tty0' to the<br />
command-line of the debuggee. This causes all console message to be sent to ttyS0 as well<br />
as well as the standard console. The last console= parameter determines where the console<br />
input should be handled from; so if you want to use the serial console to accept input also<br />
you'll have to exchange those parameters.<br />
<br />
On the receiving machine you just fire up (as root) screen with the command:<br />
<br />
# screen -T vt100 /dev/ttyS0 115200<br />
<br />
(Assuming that the serial connection is hooked onto the first serial port).<br />
The do a reboot and watch.<br />
<br />
To capture any oops it's easiest to enable logging from screen, see the screen manual on<br />
how to do that.<br />
<br />
==Authors==<br />
[[User:Okir|Olaf Kirch]] <okir@suse.de><br><br />
[[User:Hreinecke|Hannes Reinecke]] <hare@suse.de><br><br />
[[User:Jeff_Mahoney|Jeff Mahoney]] <jeffm@suse.com><br />
<br />
=What should I do with a Kernel OOPS?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/oops-reading.txt OOPS reading] document.<br />
<br />
<br />
=How can I debug a kernel problem?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/kernel-debugging-intro.txt Kernel Debugging Introduction] document.<br />
<br />
=Where to report results of your debugging?=<br />
If you are lucky enough and arrive at the patch, be so kind as to report the defect via [https://bugzilla.novell.com/ Bugzilla] to us. Remember to select component '''Kernel''' for optimal routing of your bug report within SUSE.<br />
<br />
Even if you weren't able to produce a fix for the bug, report at least information you have collected so far. That will help us take it further.<br />
<br />
[[Category:Reporting bugs|Kernel Report]]<br />
[[Category:Debugging|Kernel Bugreport]]<br />
[[Category:Kernel|Bugreport]]<br />
<br />
[[de:Fehler/Kernel]]<br />
[[it:openSUSE:Bugreport kernel]]<br />
[[ru:openSUSE:Сообщить об ошибке Ядра]]<br />
[[zh:openSUSE:报告内核错误]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Bugreport_kernel&diff=119159openSUSE:Bugreport kernel2017-03-18T16:51:54Z<p>Okurz: /* Getting the right Information */</p>
<hr />
<div>{{Bug navbar}}<br />
{{Kernel navbar}}<br />
{{Intro|This article is intended to help make it easier to diagnose and fix kernel bugs to all people involved in this process.}}<br />
<br />
==Linux Kernel Debugging Introduction==<br />
<br />
Diagnosing a Kernel bug is a difficult task but some simple categories of bugs that might be Kernel bugs include:<br />
<br />
* Hardware driver issues - missing drivers, missing features, etc<br />
* File system corruption - data corruption, missing files, etc<br />
* Hard locks - system lockups, or freezes see [[Wikipedia:Magic_SysRq_key|SysRq Key]]<br />
* Kernel oopses - printed in dmesg or /var/log/messages<br />
* Performance issues or latency <br />
<br />
This document is intended for: <br />
<br />
* supporters and consultants, so they know how to provide useful and valuable bug reports.<br />
* developers, who need to know about debugging facilities provided by the Linux kernel<br />
<br />
==A Classification of Kernel Bugs==<br />
<br />
Kernel bugs can be categorized in a number of different schemes (e.g. by their impact on security, data integrity, etc). As this document is about debugging, let's try to categorize them by complexity.<br />
<br />
* Not working as expected<br>Some kernel bugs are quite easy to localize and even reproduce, and do not affect the stability of the rest of the system. For instance, a network card may not work in certain configurations, or NFS produces weird errors.<br><br>These are often fairly easy to debug. All it takes is a precise description of what happens, and detailed description how to reproduce the problem. And of course a kernel hacker who has a good understanding of the subsystem :)<br />
* Kernel Oopses<br>If the kernel runs into an unexpected error condition (e.g. when dereferencing an invalid pointer), an exception handler will catch this error, abort the current process, and try to log a message describing the exception in some detail. Normally, the oops message is logged to the system log. It is also possible to display the message on the text console, but this is turned off by default and needs to be enabled manually.<br><br> As this log message starts with the words "Kernel Ooops", the entire event it commonly referred to as "oopsing".<br><br>When an oops occurs, the process that caused it was usually in the middle of some dreadfully important business inside the kernel, and was holding one or more locks. As the process is terminated immediately, none of these locks will be released, so that other processes trying to claim these locks later will hang forever.<br><br>If the user is in an X Windows session while the oops occurs, the machine may appear to be hung completely, because the X server got stuck on some stale kernel lock and does not react anymore.<br />
*Kernel panics<br>If an oops occurs inside an interrupt handler, the kernel will try to deliver the oops message, and then halt completely, because there is no sane way to recover after an interrupt handler crashed. This is called a kernel panic.<br><br>In the case of a kernel panic, the oops will not be written to syslog, simply because the syslog daemon will not be scheduled anymore.<br />
* Soft lockups<br>Some kernel bugs do not trigger oopses, but simply freeze the machine. They can be caused by deadlocks or livelocks, among other things. In most cases (unless some stupid bug causes an interrupt handler to spin on a lock), these soft lockups will not prevent delivery of interrupts.<br><br>If interrupt delivery is still possible, the machine will react to pings, and keyboard input will be echoed on the text console. However, processes will not make any progress anymore.<br><br>Still, the machine will be mostly unresponsive, because processes do not make any progress anymore.<br><br>A good way to test for this is to hit the numlock or capslock key; if the keyboard LEDs are turned on and off, you have a deadlock somewhere.<br><br>Also, the kernel will start flashing the numlock or caps-lock LED all by itself if it got hung.<br />
* Hard lockups<br>A hard lockup may occur as well; these are usually due to hardware problems (or excessive abuse of the hardware by some poorly written driver). If this happens, you're in trouble. You can stop reading now, and we wish you good luck in debugging this.<br />
<br />
==Getting the right Information==<br />
<br />
Users have a tendency to blame software problems on that part of the system that seems to be the most complex or mysterious from their point of view. Which in most cases is the kernel.<br />
<br />
That doesn't mean they have to be wrong. But it often means that their bug reports are inaccurate, or omit important details.<br />
<br />
So when you're tasked with debugging a Linux kernel bug (or what someone '''thinks''' is a Linux kernel bug) there is a number of questions on the symptoms you should ask first:<br />
<br />
* Hangs versus crashes<br>Is the machine hanging? Did it crash? Did it just ''appear'' to have crashed?<br><br>Even experienced users will not always remember to check the syslog for oops messages, especially if the kernel just behaves "slightly strange" without crashing and burning spectaculary. You can save yourself a lot of work if you ask them to check the syslog for oops messages nevertheless.<br><br>As described above, if the kernel oopsed while user was using X, it may appear to him as if the machine was hanging.<br><br>There is one indication that will tell you that the kernel paniced, even if you're in X: the numlock LED will start flashing.<br><br>In this case, it always helps to reproduce the problem after changing to the text console. If the machine isn't hung hard, the kernel will at least accept keyboard input. On the console, it will also be possible to capture additional information on the crash. As a minimum, you should tell the kernel to display the oops message on the console as well, using<br><br />
# klogconsole -r0 -l8<br />
:If the oops isn't written to the syslog (e.g. when the oops occurs inside an interrupt), capturing the output with a digital camera may still help (but please make sure that any images you attach to a bug report don't exceed 512k).<br><br>Alternatively, one can try to capture the oops via a serial console.<br><br>In addition, you may want to enable the sysrq key and capture some sysrq information, as described in section "Capturing sysrq information" below.<br><br><br />
* Eliminate well-known problems<br>There are certain classes of problems that are common as dirt. Be aware of these problem areas and try to get these out of the equation early on.<br />
:Item Number One on the list of annoying issues is probably ACPI:<br />
::Most of the time when a user reports a problem with a machine not booting properly, or hardware not getting set up correctly, this is caused by bad ACPI BIOS tables.<br />
::Try to boot with acpi=off to turn off ACPI entirely.<br />
::[list of all ACPI related kernel command line variables goes here]<br />
:Other Very Common Problems?<br />
* Eliminate non-essential variables<br>User bug reports often describe fairly specific scenarios, such as "I am using a USB disk with reiserfs on it exported via NFS while listening to my mp3s and all of a sudden the machine crashes".<br><br>This is a nice and accurate report involving almost every subsystem the kernel has (block device layer, VM, VFS, network, sound, ...)<br><br>To help you narrow down the problem, here is a bunch of things you can try:<br />
** does the problem exist with older/newer kernel versions as well?<br />
** if you take component X out of the equation, can the bug still be reproduced?<br />
** if you exchange component X for another, equivalent component (e.g. replacing reiserfs with ext3), does the problem persist?<br />
** if the problem implicates memory corruption or random hardware failure: can the problem be reproduced on a different machine?<br />
** Especially on large machines, random memory corruption could be caused by hardware problems with bad RAM. To diagnose bad RAM, use the installation CD, select memtest86 and run it for 24 hours.<br />
<br />
==Capturing Oops info==<br />
<br />
As described previously, a kernel crash will result in an Oops that gets written to the system log. The oops messages contain a great deal of information that can help you at least diagnosing the problem.<br />
<br />
In (relatively speaking) benign cases, the kernel will be able to continue despite the error condition, and the system will be stable enough to at least write the oops into the system log. If the kernel paniced, it is far from trivial to record an oops, however.<br />
<br />
Your worst enemy is the desktop. Any kernel messages printed to the console while the X server is running will not show up on the screen. The X server has a way of capturing messages printed on /dev/console and display them to you, but if the bug is bad enough to prevent syslogd and klogd from writing the oops to the syslog, the chances of X actually being able to display anything useful to you are very very small.<br />
<br />
So if you're able to reproduce the problem in some way, the first thing you should do is switch to a text console and bump the console logging info:<br />
<br />
klogconsole -r0 -l8<br />
<br />
This will switch the kernel's console log level to display ''anything'' it sends to syslogd on the virtual console as well. This includes any kernel oopses; if you trigger the kernel bug now, you will at least get a screenful of oops information.<br />
<br />
Note: if you're doing this frequently, please refer to the section on serial consoles below - this is really the preferred method, but as a first stab, just being able to ''read'' the oops is a major win. To learn how to read an oops, please refer to the file oops-reading.<br />
<br />
===Kdump===<br />
Starting with openSUSE 12.2 pre-releases, kdump has the ability to dump quickly and only capture the oops. YaST should eventually be updated to configure this automatically, but for now the following instructions should be used.<br />
<br />
* Install the yast2-kdump and kdump packages.<br />
* Use yast2-kdump to enable kdump<br />
* Edit /etc/sysconfig/kdump to change $KDUMP_DUMPFORMAT to "none" -- this will disable dumps in general and only save the Oops.<br />
* Reboot to enable the crashkernel zone in the kernel. Your system will operate normally until you reboot but will not capture Oopses. <br />
** Please note that enabling dump uses 128M of RAM except on large systems (more than 512GB RAM) where it must use more to accommodate larger page tables. Once you have reported your issue with the Oops generated, you may want to disable it again.<br />
<br />
====Note: Configuration via YaST doesn't currently work due to [https://bugzilla.novell.com/show_bug.cgi?id=773143 bnc#773143]====<br />
* You will need to manually add "crashkernel=256M-:128M" to your grub configuration and reboot instead of using YaST.<br />
<br />
Now attempt to reproduce your problem. Your system should reboot nearly immediately when it occurs after dropping to a text console. When you reboot, there should be a log file in /var/log/dump/<br />
<br />
==Using ksymoops==<br />
*This should not be needed for any openSUSE release, but may be useful for self-built kernels.<br />
<br />
A kernel oops usually includes a dump of the current processor state, including registers, the instruction pointers, and a function call back trace. For this to be of any use to the kernel developer, these addresses must be mapped to function and/or variable names, if possible.<br />
<br />
Current SUSE kernels support a feature called "kallsyms" where the running kernel includes a symbol table of itself, which allows it to resolve the addresses automatically when printing an oops.<br />
<br />
Older kernels do not have this feature, so the oops printed will contain just the raw addresses, which need to be converted by a user space application.<br />
<br />
This is what ksymoops is for: you can feed ksymoops a raw oops on standard input, and given the right symbol information, it will provide you with a cooked version of that oops that maps all the symbols ''and'' a disassembly listing of the hex instructions. It should '''not''' be used when kallsyms is turned on (which holds true for opensuse kernels).<br />
<br />
The crux of the matter is providing ksymoops with the right symbol information. This information is usually taken from the vmlinux image and the System.map file in <tt>/boot</tt>, which must '''exactly''' match the version of the kernel that generated the oops. Therefore, it is usually a good idea to run ksymoops on the machine where the crash happened.<br />
<br />
If it is to resolve module symbols properly, ksymoops also needs the list of kernel modules and their location in memory. A good way of providing this is to copy the file <tt>/proc/modules</tt> immediately before or after the oops occurred, and specify this copy on the ksymoops command line using the <tt>-l</tt> option:<br />
<br />
# ksymoops -l /tmp/proc-modules-copy < /tmp/my-oops<br />
<br />
Fortunately, much of this work is already done automatically when the oops is captured by syslogd, because syslogd will do all the symbols translations for you. This has the great advantage that it always uses the correct symbol list.<br />
<br />
Of course, oopses captured via the serial console will not have their addresses massaged by syslogd, so you will have to run ksymoops manually on this case.<br />
<br />
==Using sysrq==<br />
<br />
sysrq means "system request". This is the name for a bunch of magic key combinations that will tell the kernel to display various types of internal information, sync the file system or kill a task. Since this is somewhat security sensitive (esp. the task killing part), the sysrq keyboard commands are disabled by default for security reasons.<br />
<br />
One way to enable sysrq is to execute the following command at the shell prompt:<br />
<br />
echo 1 > /proc/sys/kernel/sysrq<br />
<br />
In addition, you may want to edit /etc/sysconfig/sysctl and change the variable ENABLE_SYSRQ to "yes". This will ensure that sysrq is enabled after reboot.<br />
<br />
To use sysrq, you need to press a "magic" key combination plus a command key. This magic key combination depends on the hardware platform, but on most platforms it's usually ALT-SysRQ (on some keyboards, the SysRQ key is labelled "PrtScr" or "Print", it's usually located to the right of the function keys).<br />
<br />
Most sysrq keys will cause the kernel to report status information to the serial console. In the default configuration, a SUSE system has all kernel generated output redirected to tty10, so you need to switch to console 10 or redirect the kernel console to a different tty using klogconsole.<br />
<br />
The most helpful command key is "h", which displays a short help text:<br />
<br />
SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem powerOff showPc<br />
unRaw Sync showTasks Unmount<br />
<br />
Here's a description of the most important commands:<br />
<br />
0-8 These keys change the console log level to the indicated <br />
level. 8 will display everything on the console, 1 will be <br />
critical messages only, and 0 turns console logging off entirely.<br />
M Display current memory statistics<br />
P Display current processor registers, instruction counter, call <br />
trace and list of loaded modules. This is essentially the process <br />
related information that would get printed as part of an oops.<br />
T Shows a listing of all tasks, including the back trace of their <br />
current kernel stack. Beware, this list can be very long.<br />
U Try to re-mount all currently mounted file systems read-only.<br />
E Send a TERM signal to all processes except init.<br />
I Send a KILL signal to all processes except init.<br />
<br />
There are a number of other sysrq keys; a complete list is available<br />
from Documentation/sysrq.txt in the kernel source.<br />
<br />
It is also possible to trigger sysrq commands from the command line,<br />
which is very useful if you do not have keyboard access (e.g. when<br />
debugging a problem remotely). In this case, simply echo the letter <br />
to /proc/sysrq-trigger and read back the information from dmesg or<br />
the syslog files:<br />
<br />
# echo t > /proc/sysrq-trigger<br />
<br />
==Using lkcd==<br />
[TBD]<br />
<br />
==Using nmi_watchdog==<br />
[TBD]<br />
<br />
==Using the serial console==<br />
Some kernel oops (especially during boot-up) might occur when the system console unusable.<br />
To get a reliable dump report a serial console helps in this case.<br />
You'll need a second machine and a null-modem cable (ie a serial cable with two identical<br />
connectors); additionally both machines have to have a serial port on them.<br />
This leaves some modern machines out of the equation, I'm afraid; you'll have to try to use<br />
netconsole on them.<br />
<br />
Once you've hooked the cable up you should add 'console=ttyS0,115200 console=tty0' to the<br />
command-line of the debuggee. This causes all console message to be sent to ttyS0 as well<br />
as well as the standard console. The last console= parameter determines where the console<br />
input should be handled from; so if you want to use the serial console to accept input also<br />
you'll have to exchange those parameters.<br />
<br />
On the receiving machine you just fire up (as root) screen with the command:<br />
<br />
# screen -T vt100 /dev/ttyS0 115200<br />
<br />
(Assuming that the serial connection is hooked onto the first serial port).<br />
The do a reboot and watch.<br />
<br />
To capture any oops it's easiest to enable logging from screen, see the screen manual on<br />
how to do that.<br />
<br />
==Authors==<br />
[[User:Okir|Olaf Kirch]] <okir@suse.de><br><br />
[[User:Hreinecke|Hannes Reinecke]] <hare@suse.de><br><br />
[[User:Jeff_Mahoney|Jeff Mahoney]] <jeffm@suse.com><br />
<br />
=What should I do with a Kernel OOPS?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/oops-reading.txt OOPS reading] document.<br />
<br />
<br />
=How can I debug a kernel problem?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/kernel-debugging-intro.txt Kernel Debugging Introduction] document.<br />
<br />
=Where to report results of your debugging?=<br />
If you are lucky enough and arrive at the patch, be so kind as to report the defect via [https://bugzilla.novell.com/ Bugzilla] to us. Remember to select component '''Kernel''' for optimal routing of your bug report within SUSE.<br />
<br />
Even if you weren't able to produce a fix for the bug, report at least information you have collected so far. That will help us take it further.<br />
<br />
[[Category:Reporting bugs|Kernel Report]]<br />
[[Category:Debugging|Kernel Bugreport]]<br />
[[Category:Kernel|Bugreport]]<br />
<br />
[[de:Fehler/Kernel]]<br />
[[it:openSUSE:Bugreport kernel]]<br />
[[ru:openSUSE:Сообщить об ошибке Ядра]]<br />
[[zh:openSUSE:报告内核错误]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Bugreport_kernel&diff=119158openSUSE:Bugreport kernel2017-03-18T16:50:33Z<p>Okurz: /* A Classification of Kernel Bugs */ flashing LED is available in all recent versions</p>
<hr />
<div>{{Bug navbar}}<br />
{{Kernel navbar}}<br />
{{Intro|This article is intended to help make it easier to diagnose and fix kernel bugs to all people involved in this process.}}<br />
<br />
==Linux Kernel Debugging Introduction==<br />
<br />
Diagnosing a Kernel bug is a difficult task but some simple categories of bugs that might be Kernel bugs include:<br />
<br />
* Hardware driver issues - missing drivers, missing features, etc<br />
* File system corruption - data corruption, missing files, etc<br />
* Hard locks - system lockups, or freezes see [[Wikipedia:Magic_SysRq_key|SysRq Key]]<br />
* Kernel oopses - printed in dmesg or /var/log/messages<br />
* Performance issues or latency <br />
<br />
This document is intended for: <br />
<br />
* supporters and consultants, so they know how to provide useful and valuable bug reports.<br />
* developers, who need to know about debugging facilities provided by the Linux kernel<br />
<br />
==A Classification of Kernel Bugs==<br />
<br />
Kernel bugs can be categorized in a number of different schemes (e.g. by their impact on security, data integrity, etc). As this document is about debugging, let's try to categorize them by complexity.<br />
<br />
* Not working as expected<br>Some kernel bugs are quite easy to localize and even reproduce, and do not affect the stability of the rest of the system. For instance, a network card may not work in certain configurations, or NFS produces weird errors.<br><br>These are often fairly easy to debug. All it takes is a precise description of what happens, and detailed description how to reproduce the problem. And of course a kernel hacker who has a good understanding of the subsystem :)<br />
* Kernel Oopses<br>If the kernel runs into an unexpected error condition (e.g. when dereferencing an invalid pointer), an exception handler will catch this error, abort the current process, and try to log a message describing the exception in some detail. Normally, the oops message is logged to the system log. It is also possible to display the message on the text console, but this is turned off by default and needs to be enabled manually.<br><br> As this log message starts with the words "Kernel Ooops", the entire event it commonly referred to as "oopsing".<br><br>When an oops occurs, the process that caused it was usually in the middle of some dreadfully important business inside the kernel, and was holding one or more locks. As the process is terminated immediately, none of these locks will be released, so that other processes trying to claim these locks later will hang forever.<br><br>If the user is in an X Windows session while the oops occurs, the machine may appear to be hung completely, because the X server got stuck on some stale kernel lock and does not react anymore.<br />
*Kernel panics<br>If an oops occurs inside an interrupt handler, the kernel will try to deliver the oops message, and then halt completely, because there is no sane way to recover after an interrupt handler crashed. This is called a kernel panic.<br><br>In the case of a kernel panic, the oops will not be written to syslog, simply because the syslog daemon will not be scheduled anymore.<br />
* Soft lockups<br>Some kernel bugs do not trigger oopses, but simply freeze the machine. They can be caused by deadlocks or livelocks, among other things. In most cases (unless some stupid bug causes an interrupt handler to spin on a lock), these soft lockups will not prevent delivery of interrupts.<br><br>If interrupt delivery is still possible, the machine will react to pings, and keyboard input will be echoed on the text console. However, processes will not make any progress anymore.<br><br>Still, the machine will be mostly unresponsive, because processes do not make any progress anymore.<br><br>A good way to test for this is to hit the numlock or capslock key; if the keyboard LEDs are turned on and off, you have a deadlock somewhere.<br><br>Also, the kernel will start flashing the numlock or caps-lock LED all by itself if it got hung.<br />
* Hard lockups<br>A hard lockup may occur as well; these are usually due to hardware problems (or excessive abuse of the hardware by some poorly written driver). If this happens, you're in trouble. You can stop reading now, and we wish you good luck in debugging this.<br />
<br />
==Getting the right Information==<br />
<br />
Users have a tendency to blame software problems on that part of the system that seems to be the most complex or mysterious from their point of view. Which in most cases is the kernel.<br />
<br />
That doesn't mean they have to be wrong. But it often means that their bug reports are inaccurate, or omit important details.<br />
<br />
So when you're tasked with debugging a Linux kernel bug (or what someone '''thinks''' is a Linux kernel bug) there is a number of questions on the symptoms you should ask first:<br />
<br />
* Hangs versus crashes<br>Is the machine hanging? Did it crash? Did it just ''appear'' to have crashed?<br><br>Even experienced users will not always remember to check the syslog for oops messages, especially if the kernel just behaves "slightly strange" without crashing and burning spectaculary. You can save yourself a lot of work if you ask them to check the syslog for oops messages nevertheless.<br><br>As described above, if the kernel oopsed while user was using X, it may appear to him as if the machine was hanging.<br><br>On a 2.4 kernel, there is one indication that will tell you that the kernel paniced, even if you're in X: the numlock LED will start flashing. 2.6 doesn't have this feature yet.<br><br>In this case, it always helps to reproduce the problem after changing to the text console. If the machine isn't hung hard, the kernel will at least accept keyboard input. On the console, it will also be possible to capture additional information on the crash. As a minimum, you should tell the kernel to display the oops message on the console as well, using<br><br />
# klogconsole -r0 -l8<br />
:If the oops isn't written to the syslog (e.g. when the oops occurs inside an interrupt), capturing the output with a digital camera may still help (but please make sure that any images you attach to a bug report don't exceed 512k).<br><br>Alternatively, one can try to capture the oops via a serial console.<br><br>In addition, you may want to enable the sysrq key and capture some sysrq information, as described in section "Capturing sysrq information" below.<br><br><br />
* Eliminate well-known problems<br>There are certain classes of problems that are common as dirt. Be aware of these problem areas and try to get these out of the equation early on.<br />
:Item Number One on the list of annoying issues is probably ACPI:<br />
::Most of the time when a user reports a problem with a machine not booting properly, or hardware not getting set up correctly, this is caused by bad ACPI BIOS tables.<br />
::Try to boot with acpi=off to turn off ACPI entirely.<br />
::[list of all ACPI related kernel command line variables goes here]<br />
:Other Very Common Problems?<br />
* Eliminate non-essential variables<br>User bug reports often describe fairly specific scenarios, such as "I am using a USB disk with reiserfs on it exported via NFS while listening to my mp3s and all of a sudden the machine crashes".<br><br>This is a nice and accurate report involving almost every subsystem the kernel has (block device layer, VM, VFS, network, sound, ...)<br><br>To help you narrow down the problem, here is a bunch of things you can try:<br />
** does the problem exist with older/newer kernel versions as well?<br />
** if you take component X out of the equation, can the bug still be reproduced?<br />
** if you exchange component X for another, equivalent component (e.g. replacing reiserfs with ext3), does the problem persist?<br />
** if the problem implicates memory corruption or random hardware failure: can the problem be reproduced on a different machine?<br />
** Especially on large machines, random memory corruption could be caused by hardware problems with bad RAM. To diagnose bad RAM, use the installation CD, select memtest86 and run it for 24 hours.<br />
<br />
==Capturing Oops info==<br />
<br />
As described previously, a kernel crash will result in an Oops that gets written to the system log. The oops messages contain a great deal of information that can help you at least diagnosing the problem.<br />
<br />
In (relatively speaking) benign cases, the kernel will be able to continue despite the error condition, and the system will be stable enough to at least write the oops into the system log. If the kernel paniced, it is far from trivial to record an oops, however.<br />
<br />
Your worst enemy is the desktop. Any kernel messages printed to the console while the X server is running will not show up on the screen. The X server has a way of capturing messages printed on /dev/console and display them to you, but if the bug is bad enough to prevent syslogd and klogd from writing the oops to the syslog, the chances of X actually being able to display anything useful to you are very very small.<br />
<br />
So if you're able to reproduce the problem in some way, the first thing you should do is switch to a text console and bump the console logging info:<br />
<br />
klogconsole -r0 -l8<br />
<br />
This will switch the kernel's console log level to display ''anything'' it sends to syslogd on the virtual console as well. This includes any kernel oopses; if you trigger the kernel bug now, you will at least get a screenful of oops information.<br />
<br />
Note: if you're doing this frequently, please refer to the section on serial consoles below - this is really the preferred method, but as a first stab, just being able to ''read'' the oops is a major win. To learn how to read an oops, please refer to the file oops-reading.<br />
<br />
===Kdump===<br />
Starting with openSUSE 12.2 pre-releases, kdump has the ability to dump quickly and only capture the oops. YaST should eventually be updated to configure this automatically, but for now the following instructions should be used.<br />
<br />
* Install the yast2-kdump and kdump packages.<br />
* Use yast2-kdump to enable kdump<br />
* Edit /etc/sysconfig/kdump to change $KDUMP_DUMPFORMAT to "none" -- this will disable dumps in general and only save the Oops.<br />
* Reboot to enable the crashkernel zone in the kernel. Your system will operate normally until you reboot but will not capture Oopses. <br />
** Please note that enabling dump uses 128M of RAM except on large systems (more than 512GB RAM) where it must use more to accommodate larger page tables. Once you have reported your issue with the Oops generated, you may want to disable it again.<br />
<br />
====Note: Configuration via YaST doesn't currently work due to [https://bugzilla.novell.com/show_bug.cgi?id=773143 bnc#773143]====<br />
* You will need to manually add "crashkernel=256M-:128M" to your grub configuration and reboot instead of using YaST.<br />
<br />
Now attempt to reproduce your problem. Your system should reboot nearly immediately when it occurs after dropping to a text console. When you reboot, there should be a log file in /var/log/dump/<br />
<br />
==Using ksymoops==<br />
*This should not be needed for any openSUSE release, but may be useful for self-built kernels.<br />
<br />
A kernel oops usually includes a dump of the current processor state, including registers, the instruction pointers, and a function call back trace. For this to be of any use to the kernel developer, these addresses must be mapped to function and/or variable names, if possible.<br />
<br />
Current SUSE kernels support a feature called "kallsyms" where the running kernel includes a symbol table of itself, which allows it to resolve the addresses automatically when printing an oops.<br />
<br />
Older kernels do not have this feature, so the oops printed will contain just the raw addresses, which need to be converted by a user space application.<br />
<br />
This is what ksymoops is for: you can feed ksymoops a raw oops on standard input, and given the right symbol information, it will provide you with a cooked version of that oops that maps all the symbols ''and'' a disassembly listing of the hex instructions. It should '''not''' be used when kallsyms is turned on (which holds true for opensuse kernels).<br />
<br />
The crux of the matter is providing ksymoops with the right symbol information. This information is usually taken from the vmlinux image and the System.map file in <tt>/boot</tt>, which must '''exactly''' match the version of the kernel that generated the oops. Therefore, it is usually a good idea to run ksymoops on the machine where the crash happened.<br />
<br />
If it is to resolve module symbols properly, ksymoops also needs the list of kernel modules and their location in memory. A good way of providing this is to copy the file <tt>/proc/modules</tt> immediately before or after the oops occurred, and specify this copy on the ksymoops command line using the <tt>-l</tt> option:<br />
<br />
# ksymoops -l /tmp/proc-modules-copy < /tmp/my-oops<br />
<br />
Fortunately, much of this work is already done automatically when the oops is captured by syslogd, because syslogd will do all the symbols translations for you. This has the great advantage that it always uses the correct symbol list.<br />
<br />
Of course, oopses captured via the serial console will not have their addresses massaged by syslogd, so you will have to run ksymoops manually on this case.<br />
<br />
==Using sysrq==<br />
<br />
sysrq means "system request". This is the name for a bunch of magic key combinations that will tell the kernel to display various types of internal information, sync the file system or kill a task. Since this is somewhat security sensitive (esp. the task killing part), the sysrq keyboard commands are disabled by default for security reasons.<br />
<br />
One way to enable sysrq is to execute the following command at the shell prompt:<br />
<br />
echo 1 > /proc/sys/kernel/sysrq<br />
<br />
In addition, you may want to edit /etc/sysconfig/sysctl and change the variable ENABLE_SYSRQ to "yes". This will ensure that sysrq is enabled after reboot.<br />
<br />
To use sysrq, you need to press a "magic" key combination plus a command key. This magic key combination depends on the hardware platform, but on most platforms it's usually ALT-SysRQ (on some keyboards, the SysRQ key is labelled "PrtScr" or "Print", it's usually located to the right of the function keys).<br />
<br />
Most sysrq keys will cause the kernel to report status information to the serial console. In the default configuration, a SUSE system has all kernel generated output redirected to tty10, so you need to switch to console 10 or redirect the kernel console to a different tty using klogconsole.<br />
<br />
The most helpful command key is "h", which displays a short help text:<br />
<br />
SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem powerOff showPc<br />
unRaw Sync showTasks Unmount<br />
<br />
Here's a description of the most important commands:<br />
<br />
0-8 These keys change the console log level to the indicated <br />
level. 8 will display everything on the console, 1 will be <br />
critical messages only, and 0 turns console logging off entirely.<br />
M Display current memory statistics<br />
P Display current processor registers, instruction counter, call <br />
trace and list of loaded modules. This is essentially the process <br />
related information that would get printed as part of an oops.<br />
T Shows a listing of all tasks, including the back trace of their <br />
current kernel stack. Beware, this list can be very long.<br />
U Try to re-mount all currently mounted file systems read-only.<br />
E Send a TERM signal to all processes except init.<br />
I Send a KILL signal to all processes except init.<br />
<br />
There are a number of other sysrq keys; a complete list is available<br />
from Documentation/sysrq.txt in the kernel source.<br />
<br />
It is also possible to trigger sysrq commands from the command line,<br />
which is very useful if you do not have keyboard access (e.g. when<br />
debugging a problem remotely). In this case, simply echo the letter <br />
to /proc/sysrq-trigger and read back the information from dmesg or<br />
the syslog files:<br />
<br />
# echo t > /proc/sysrq-trigger<br />
<br />
==Using lkcd==<br />
[TBD]<br />
<br />
==Using nmi_watchdog==<br />
[TBD]<br />
<br />
==Using the serial console==<br />
Some kernel oops (especially during boot-up) might occur when the system console unusable.<br />
To get a reliable dump report a serial console helps in this case.<br />
You'll need a second machine and a null-modem cable (ie a serial cable with two identical<br />
connectors); additionally both machines have to have a serial port on them.<br />
This leaves some modern machines out of the equation, I'm afraid; you'll have to try to use<br />
netconsole on them.<br />
<br />
Once you've hooked the cable up you should add 'console=ttyS0,115200 console=tty0' to the<br />
command-line of the debuggee. This causes all console message to be sent to ttyS0 as well<br />
as well as the standard console. The last console= parameter determines where the console<br />
input should be handled from; so if you want to use the serial console to accept input also<br />
you'll have to exchange those parameters.<br />
<br />
On the receiving machine you just fire up (as root) screen with the command:<br />
<br />
# screen -T vt100 /dev/ttyS0 115200<br />
<br />
(Assuming that the serial connection is hooked onto the first serial port).<br />
The do a reboot and watch.<br />
<br />
To capture any oops it's easiest to enable logging from screen, see the screen manual on<br />
how to do that.<br />
<br />
==Authors==<br />
[[User:Okir|Olaf Kirch]] <okir@suse.de><br><br />
[[User:Hreinecke|Hannes Reinecke]] <hare@suse.de><br><br />
[[User:Jeff_Mahoney|Jeff Mahoney]] <jeffm@suse.com><br />
<br />
=What should I do with a Kernel OOPS?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/oops-reading.txt OOPS reading] document.<br />
<br />
<br />
=How can I debug a kernel problem?=<br />
<br />
<br />
See the separate [https://bugzilla.novell.com/bugreporting-faq/kernel-debugging-intro.txt Kernel Debugging Introduction] document.<br />
<br />
=Where to report results of your debugging?=<br />
If you are lucky enough and arrive at the patch, be so kind as to report the defect via [https://bugzilla.novell.com/ Bugzilla] to us. Remember to select component '''Kernel''' for optimal routing of your bug report within SUSE.<br />
<br />
Even if you weren't able to produce a fix for the bug, report at least information you have collected so far. That will help us take it further.<br />
<br />
[[Category:Reporting bugs|Kernel Report]]<br />
[[Category:Debugging|Kernel Bugreport]]<br />
[[Category:Kernel|Bugreport]]<br />
<br />
[[de:Fehler/Kernel]]<br />
[[it:openSUSE:Bugreport kernel]]<br />
[[ru:openSUSE:Сообщить об ошибке Ядра]]<br />
[[zh:openSUSE:报告内核错误]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Build_Service_Concept_SourceService&diff=119133openSUSE:Build Service Concept SourceService2017-03-09T15:16:56Z<p>Okurz: /* Step by step */ delete broken link</p>
<hr />
<div>{{Buildservice navbar}}<br />
[[Category:Build Service implemented concepts]]<br />
<br />
{{Intro|This page describes how source service could be implemented and used in the OBS. Source services are applications which process source files before the actual scheduling or building happens.}}<br />
<br />
'''Examples for this are''':<br />
* Download service - downloads a file (e.g. tarball) from given URL and stores it.<br />
* Checkout service - checks out from SVC system (svn, git, ...) and creates a tarball.<br />
* Validate service - validates a file with a given checksum (md5sum, gpg key).<br />
* Code generator - analyses a tarball and creates proper rpm and debian build descriptions (based on cmake, automake/conf, qmake or alike files).<br />
* Run pre_checkin.sh scripts via a service<br />
<br />
<br />
==Tool aspects==<br />
<br />
* All of the given examples will need tools which are not 100% trustworthy, that means that they should run in a secure environment.<br />
* The tools should allow to run on server and client side.<br />
* The tools may be highly specific, e.g. a code generator which is based on cmake files. This code should not be part of the Build Service itself, but it should be inside a package which can be easily maintained. This allows contributors to fix, extend or add services via usual packaging methods.<br />
* The tools should be maintained in a project, building for all distributions to allow the executions on the developer workstations. However only one instance is needed on the server side.<br />
* As much as possible should be done within the packages to have a thin as possible layer for this within OBS code.<br />
* Tools can share functionality via common packages.<br />
<br />
<br />
==Workflow aspects==<br />
<br />
A meta file (_service file) as part of the package sources should trigger the services. It might run multiple of them in a given order. A change in this meta file should not direct trigger a build, but wait for the generator result.<br />
<br />
The result of the services should become part of the source package and the history. However it should not possible to change these files directly to avoid lost work, when the service is generating a new file.<br />
<br />
==Server side service instance==<br />
<br />
The server should have a permanently running service instance. This is basically a usual build instance, but running all the time, except when new service tools get deployed (or build). This instance needs internet connection for its services, but we need to protect against random connections to our internal interfaces.<br />
<br />
The same instance should keep running and not restarted/rebuild for each call, but it needs to get updated when new service packages appear.<br />
<br />
==Needed implementations==<br />
<br />
===Tools===<br />
* A set of tools which create files.<br />
* Store all of these tools in a project<br />
<br />
===Source server===<br />
* On source commit, containing a _service file the server needs to trigger an event for updating the sources in package.<br />
<br />
===Dispatcher===<br />
* Validate that a service instance is running, if not start one according to specification.<br />
* Send service event to service instance, if it is free (basically the _service file together with project and package information).<br />
<br />
===Scheduler===<br />
* Needs to block a package, if a service event is waiting<br />
* Do not remove calculated buildinfo for service instance to keep it running. However it needs to get updated if service tool packages are changing and running instance need to get stopped as usual.<br />
<br />
===Build script and bs_worker===<br />
The build script needs a service mode which needs to<br />
# build up a system according to a configured service repo and package list (TBD where to specify this, maybe just BSConfig.pm for now.)<br />
# endless loop to process _service files, for each file<br />
## run XEN/kvm with network enabled<br />
## rename all _service:*:$name files to $name<br />
## process all <service items by calling the specified tool in /opt/obs/lib/service/$name<br />
## XEN/kvm session ends<br />
## copy generate files with prefix to source server (_service:$tool:$filename)<br />
## check if service instance got a kill event and die, otherwise loop back<br />
<br />
==Possible extensions==<br />
<br />
This framework might get extended later, to allow to create/remove complete new packages. This would allow us to use it for the productconverter and also for stuff like cpan2OBS generators.<br />
<br />
This would also obsolete the oscupstream need.<br />
<br />
==Examples==<br />
<br />
===Example 1: Input file commit===<br />
<br />
This is a real life example, stored as _service in the package sources.<br />
<br />
<services><br />
<service name="download_url"><br />
<param name="protocol">http</param><br />
<param name="host">download.kde.org</param><br />
<param name="path">pub/kde/stuff/krabber-1.0.tar.gz</param><br />
</service><br />
<service name="verify_file"><br />
<param name="file">_service:download_url:krabber-1.0.tar.gz</param><br />
<param name="verifier">sha256</param><br />
<param name="checksum">7f535a96a834b31ba2201a90c4d365990785dead92be02d4cf846713be938b78</param><br />
</service><br />
&lt;!--<br />
<service name="generate_automake_kde" /><br />
--&gt;<br />
</services><br />
<br />
This would download krabber-1.0.tar.gz and stores it as _service:download_url:krabber-1.0.tar.gz, validates it via a given sha256 checksum, and (commented out) generates a spec file using the generate_automake_kde tool.<br />
<br />
This _service file is e.g. created by <br />
<br />
osc add http://download.kde.org/pub/kde/stuff/krabber-1.0.tar.gz<br />
<br />
The required packages (recent osc, obs-service-download_url, build) are available from [https://build.opensuse.org/project/show/openSUSE:Tools openSUSE:Tools].<br />
<br />
<br />
===Example 2: GIT integration===<br />
<br />
Using OBS source services, you can create a package of the latest source code from a Git repository. We suppose that you know how to create/checkout/commit a package to an OBS project.<br />
<br />
====Requirements====<br />
You will need 4 additional packages on your OBS server:<br />
* ''obs-service-tar_scm'': create an archive from a source code repository<br />
* ''obs-service-extract_file'': extract files from an archive<br />
* ''obs-service-recompress'': compress/recompress an archive<br />
* ''obs-service-set_version'': update package version in spec/dsc files<br />
<br />
You can check with service are available with the osc client:<br />
osc api /service<br />
<br />
====Step by step====<br />
* Create an empty package, either using the web interface or the commandline<br />
* In that package, create a file named '''_service''' with root tag '''<code><services> </services></code>'''<br />
* Insert a first service definition to create an archive from git:<br />
<service name="tar_scm"><br />
<param name="scm">git</param><br />
<param name="url">'''''the URL of your Git repository''''' ''(something like "git://gitorious.org/your-project.git")''</param><br />
<param name="subdir">'''''the subdirectory of your repository you want to create an archive from'''''</param><br />
<param name="filename">'''''the name of the file you want to create, without version'''''</param><br />
<param name="versionprefix">'''''the first part of the version string''''' ''(e.g. "0.4.git")''</param><br />
<span style="color:#5082FF"><param name="revision">'''''optional: the commit hash, tag or branch you want to get'''''</param></span><br />
</service><br />
This will create a file called ''<filename>-<versionprefix>.<commit_timestamp>.tar'', with ''<commit_timestamp>'' being the number of seconds between Jan 1st 1970 and the commit from which the archive is created.<br />
<br />
* Insert a second service definition to extract ''.spec/.dsc'' files from the archive. If you prefer manually adding these files in your OBS package, just skip this section.<br />
<service name="extract_file"><br />
<param name="archive">*.tar</param><br />
<param name="files">'''''the files you want to extract from the previously created archive, separated by space'''''<br />
''(notice that there is a top directory with a name that you don't know, so file names should start with "*/"''</param><br />
</service><br />
* Insert a third service definition to compress the archive (Debian builds expect ''.tar.gz'' and it saves space on server)<br />
<service name="recompress"><br />
<param name="file">'''''a pattern matching the archive name''''' ''(e.g. "*git*.tar")''</param><br />
<param name="compression">'''''the format in which you want to compress the archive: "gz", "bz2", "xz", "none"'''''</param><br />
</service><br />
* Insert a fourth service definition to update package version in spec and dsc files, with the one of the generated archive<br />
<service name="set_version"/><br />
* Now upload/commit the '''_service''' file on OBS<br />
* Each time a new commit is available in your Git repository, trigger a service run, either with the web UI or with <tt>osc service run</tt><br />
<br />
====Complete ''_service'' example====<br />
<code><br />
<services><br />
<!-- Make an archive from our git repository --><br />
<service name="tar_scm"><br />
<param name="scm">git</param><br />
<param name="subdir">src</param><br />
<param name="url">git://gitorious.org/meego-developer-tools/obs-light.git</param><br />
<param name="versionprefix">0.4.git</param><br />
<param name="filename">obslight</param><br />
</service><br />
<!-- Extract build control files from the archive --><br />
<service name="extract_file"><br />
<param name="archive">*.tar</param><br />
<param name="files">*/deb/* */rpm/obslight.changes */rpm/obslight.spec */rpm/obslight.yaml</param><br />
</service><br />
<!-- Compress the archive to save space --><br />
<service name="recompress"><br />
<param name="file">*git*.tar</param><br />
<param name="compression">gz</param><br />
</service><br />
<!-- Update spec and dsc files with generated version string --><br />
<service name="set_version"/><br />
</services><br />
</code><br />
<br />
<br />
== All OBS services available ==<br />
<br />
=== cpanspec ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-cpanspec<br />
* '''GitHub''':<br />
* '''Description''': A wrapper around [https://build.opensuse.org/package/show/devel:languages:perl/cpanspec cpanspec] script.<br />
<br />
<br />
=== download_files ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-download_files<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-download_files<br />
* '''Description''': This service is parsing all spec files and downloads all Source files which are specified via a http, https or ftp url.<br />
<br />
<br />
=== download_src_package ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-download_src_package<br />
* '''GitHub''':<br />
* '''Description''': It supports downloading src.rpms and extracting.<br />
<br />
<br />
=== download_url ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-download_url<br />
* '''GitHub''':<br />
* '''Description''': It supports downloading files from given URLs via curl.<br />
<br />
<br />
=== extract_file ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-extract_file<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-extract_file<br />
* '''Description''': It supports to extract a file from an archive, for example a spec file from a tar.<br />
<br />
<br />
=== format_spec_file ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-format_spec_file<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-format_spec_file<br />
* '''Description''': This source service is formating the spec file to SUSE standard. The rational behind is to make it easier to review spec files from unknown packagers. This should be used in "trylocal" mode, so that osc is adapting the existing spec file instead of creating a new one.<br />
<br />
<br />
=== generator_driver_update_disk ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-generator_driver_update_disk<br />
* '''GitHub''':<br />
* '''Description''': Creates kiwiw files to create driver update disks used to deliver updated hardware drivers to install older suse versions on newer hardware.<br />
<br />
<br />
<br />
=== generator_pom ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-generator_pom<br />
* '''GitHub''':<br />
* '''Description''': Is supports downloading a java source from Maven Central and creates the build description for it.<br />
<br />
<br />
=== git_tarballs ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-git_tarballs<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-git_tarballs<br />
* '''Description''': It downloads tarballs from upstream and updates the spec file version and changes file.<br />
<br />
<br />
=== github_tarballs ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-github_tarballs<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-github_tarballs<br />
* '''Description''': It downloads tarballs from upstream and updates the spec file version and changes file using information from a github repository.<br />
<br />
<br />
=== kiwi_import ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-kiwi_import<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-kiwi_import<br />
* '''Description''': It supports the import of a generic kiwi archive.<br />
<br />
<br />
=== part2pkg ===<br />
* '''Package''': <br />
* '''GitHub''': https://github.com/openSUSE/obs-service-part2pkg<br />
* '''Description''': snapcraft part repackage service for OBS<br />
<br />
<br />
=== python_requires ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-python_requires<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-python_requires<br />
* '''Description''': It refreshes Python Requires from the pypi source tarball<br />
<br />
<br />
=== product_converter ===<br />
* '''Package''': <br />
* '''GitHub''': https://github.com/openSUSE/obs-service-product_converter<br />
* '''Description''': New product converter as OBS source service instead of OBS built-in<br />
<br />
<br />
=== python_sdist ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-python_sdist<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-python_sdist<br />
* '''Description''': It generates Python source distribution (sdist) tarballs<br />
<br />
<br />
=== rearchive ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-rearchive<br />
* '''GitHub''':<br />
* '''Description''': It unpacks non-tar-archives to a temporary directory and generates a compressed tar archive (tar.gz). Supported formats: .zip<br />
<br />
<br />
=== recompress ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-recompress<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-recompress<br />
* '''Description''': It supports to compress, uncompress or recompress files from or to<br />
:* none : No Compression<br />
:* gz : Gzip Compression<br />
:* bz2 : Bzip2 Compression<br />
:* xz : XZ Compression<br />
<br />
<br />
=== refresh_patches ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-refresh_patches<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-refresh_patches<br />
* '''Description''': It refreshes locals patches by using quilt.<br />
<br />
<br />
=== regex_replace ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-regex_replace<br />
* '''GitHub''':<br />
* '''Description''': Very simply script to change the content of a file using regular expressions<br />
<br />
<br />
=== renderspec ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-renderspec<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-renderspec<br />
* '''Description''': It supports rendering .spec.j2 templates via renderspec.<br />
<br />
<br />
=== set_version ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-set_version<br />
* '''Description''': Very simply script to update the version in .spec or .dsc files according to a given version or to the existing files.<br />
<br />
<br />
=== set_version.sle_11 ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-set_version.sle_11<br />
* '''GitHub''':<br />
* '''Description''': Very simply script to update the version in .spec or .dsc files according to a given version or to the existing files.<br />
<br />
<br />
=== source_validator ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-source_validator<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-source_validator<br />
* '''Description''': This service runs all checks as required by openSUSE:Factory project. This can be used to guarantee that all checks succeed also on the service side. This plugin can be used via project wide defined services.<br />
<br />
<br />
=== tar_scm ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm<br />
* '''GitHub''': https://github.com/openSUSE/obs-service-tar_scm <br />
* '''Description''': It supports downloading from svn, git, hg and bzr repositories.<br />
<br />
<br />
=== verify_file ===<br />
* '''Package''': https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-verify_file<br />
* '''GitHub''':<br />
* '''Description''': This is a source service for openSUSE Build Service. It allows to verify a file with a given sha256sum<br />
<br />
[[Category:Build Service]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_Python&diff=119028openSUSE:Packaging Python2017-02-28T07:02:17Z<p>Okurz: Add a warning about recent changes to "single-spec" approach.</p>
<hr />
<div>{{Packaging_navbar}}<br />
{{Intro|The '''Packaging Python''' is a step by step introduction on how to build Python software packages for openSUSE and others using the [[Portal:Build Service|openSUSE Build Service]].}}<br />
<br />
== python single-spec ==<br />
{{Warning|Recently the maintainers of devel:languages:python, the main development project for python packages within openSUSE, changed to a 'single-spec' approach for providing python2 + python3 variants from a single source spec file. The wiki has not yet been fully updated, see mailing list posts [https://lists.opensuse.org/opensuse-packaging/2017-02/msg00105.html Python single-spec: it's starting] and [https://lists.opensuse.org/opensuse-packaging/2017-02/msg00107.html python singlespec: how to convert your package]}}<br />
<br />
== The fast and automated way ==<br />
<br />
Lets suppose you want to package zope.interface and you don't know how it is named exactly or where to download from. First of all, you can search for it with py2pack, which can be found in the python-py2pack package and download the source tarball automatically with it if you found the correct module:<br />
<br />
<div class="shell">$ py2pack search zope.interface<pre>searching for module zope.interface...<br />
found zope.interface-3.6.1</pre><!--<br />
-->$ py2pack fetch zope.interface<pre>downloading package zope.interface-3.6.1...<br />
from http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.6.1.tar.gz</pre></div><br />
<br />
As a next step you may want to generate a package recipe for your distribution. For RPM-based distributions, you want to generate a spec file named python-zopeinterface.spec:<br />
<br />
<div class="shell">$ py2pack generate zope.interface -f python-zopeinterface.spec</div><br />
<br />
The source tarball and package recipe is all you need to generate the RPM file. This final step may depend on which distribution you use. Again, for openSUSE (and by using the openSUSE Build Service), the complete recipe becomes:<br />
<br />
<div class="shell">$ osc mkpac python-zopeinterface<br /><!--<br />
-->$ cd python-zopeinterface<br /><!--<br />
-->$ py2pack fetch zope.interface<br /><!--<br />
-->$ py2pack generate zope.interface -f python-zopeinterface.spec<br /><!--<br />
-->$ vi *.spec<br /><!--<br />
--> BuildRequires: python-setuptools<br /><!--<br />
-->ZZ <br /><!--<br />
-->$ osc build<br /><!--<br />
-->$ osc vc <br /><!--<br />
-->$ osc add *<br /><!--<br />
-->$ osc commit</div><br />
<br />
The first line uses osc, the Build Service command line tool to generate a new package (preferrably in your Build Service home project). The py2pack steps are known already. <br />
It is always good to review the BuildRequires (with 'vi *.spec') and e.g. add python-setuptools if needed.<br />
Finally, the package is tested (built locally), a changes (package changelog) file is generated (with ‘osc vc’) and the result is sent back to the Build Service for public consumption. However, depending on the Python module, you may have to adapt the generated spec file slightly. Py2pack is quite clever and tries to auto-generate as much as it can, but it depends on the metadata that the module provides. Thus, bad metadata implies mediocre results. To get further help about py2pack usage, issue the following command:<br />
<br />
<div class="shell">$ py2pack help</div><br />
<br />
Often, the first run of 'osc build' will fail with build error messages, due to missing python modules. Look for the keyword 'import', this should give you a hint, what needs to be added to the 'BuildRequires:' of you spec-file.<br />
<br />
----<br />
<br />
== Hints on how to package Python modules manually ==<br />
<br />
Manual packaging is discouraged since we have tools to do that. If you insist on having fun, please consider any package spec file in [https://build.opensuse.org/project/show/devel:languages:python devel:languages:python3]. [https://build.opensuse.org/package/show/devel:languages:python/python-nose python-nose], [https://build.opensuse.org/package/show/devel:languages:python/python-pip python-pip] or [https://build.opensuse.org/package/show/devel:languages:python/python-Sphinx python-Sphinx] are good examples.<br />
<br />
=== Naming policy ===<br />
<br />
SUSE has a policy for names of Python module packages. A ''module'' is to Python what shared libraries are to C - a piece of code that doesn't work by itself, but provides functionality to other Python programs.<br />
<br />
All Python module packages, whether pure Python or C-based, should be called '''python-'''modulename. '''modulename''' should be the name of this module on the [http://pypi.python.org/pypi Python Package Index],<br />
the official third-party software repository for the Python programming language.<br />
<br />
Previously, Python packages have been named after directories in the <tt>site-packages</tt> hierarchy. Often, this was an arbitrary choice, several modules install more than one directory there. Also, the Python universe includes modules that share the same directory name (search for "daemon" on PyPI) and it was not always easy to find out the right package name. Furthermore, the new approach has several advantages:<br />
<br />
* Scripts (like py2pack) know where to fetch metadata and (new) release tarballs, PyPI has a stable API<br />
* Package names match [http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies install_required, etc. in setup.py files] and [http://www.pip-installer.org/en/latest/requirements.html pip requirements files] making it easy to find out (Build)Requires in your RPM specs<br />
* Users know where to look for API or usage documentation: http://pypi.python.org/pypi/$PYPYNAME<br />
<br />
This policy doesn't apply to end-user applications - so if you're packaging something that is going to have an icon in the application menu, you should just call the package by its normal name (as found on the Python Package Index).<br />
<br />
There are some corner cases as to what is an application and what is a module - for example, many modules come with simple command-line tools that allow you to use a subset of their functionality directly. The rule of thumb is this: if you think that the users will install your package to use the command line tool, call it by its normal name. If this package is going to be a dependency of some other Python application, apply the naming policy.<br />
<br />
=== BuildRequires ===<br />
<br />
In all cases, use '''BuildRequires: python-devel'''. Technically '''BuildRequires: python-base''' is sufficient for Python-only modules (i.e. no C code), but it increases consistency and doesn't add much overhead. <br />
<br />
Some modules require [http://pypi.python.org/pypi/setuptools setuptools] to build. In this case add the package '''BuilRequires: python-setuptools''' <del>or preferably it's succcessor as BuildRequires: python-distribute</del><span style="color:red;">2013-10-16: distribute is a setuptools fork that was done because development stalled. meanwhile, the project was taken over by distribute devs and they merged. Nowadays, setuptools is pretty active again and obsoleted distribute (again). -- quoted Saschpe</span>. <br />
<br />
Due to how the Python interpreter is spread across the packages "python" and "python-base", you sometimes need to say '''BuildRequires: python''' in your spec files. This is especially true if you need one of the following Python modules at build time: ssl, _ssl, md5, sha.<br />
<br />
=== Python version ===<br />
<br />
In openSUSE, even version-agnostic python packages need to depend on a specific python series. A python series is denoted by python's major and minor version. For example, the current (as of 3.4.2013) python series is 2.7 for the legacy line and 3.3 for Python 3.<br><br />
This is because you are installing into version-specific directory <tt>/usr/lib(64)/pythonX.Y/site-packages</tt>, where X.Y is the series.<br />
<br />
=== File locations ===<br />
<br />
All python source and bytecode files should go into <tt>/usr/lib(64)/pythonX.Y/site-packages</tt>, or maybe <tt>/usr/lib(64)/yourapp</tt>. FHS says that <tt>/usr/share</tt> hierarchy should only contain data, so don't install sources in there.<br><br />
This is not a strict requirement, though, only a recommendation. If your package's upstream is bent on installing to <tt>/usr/share</tt>, please try to convince them of the error of their ways, but don't feel obliged to patch the package to death just so it installs into <tt>/usr/lib</tt>.<br />
<br />
=== File lists ===<br />
<br />
There are two useful macros to list files:<br />
* '''<tt>%python_sitelib</tt>''' expands to <tt>/usr/lib/pythonX.Y/site-packages</tt>. This is the install location for platform-independent modules.<br />
* '''<tt>%python_sitearch</tt>''' expands to <tt>%{_libdir}/pythonX.Y/site-packages</tt>, that is, either /usr/lib or /usr/lib64, depending on your architecture. This is the install location for platform-dependent modules.<br />
<br />
So, for platform-independent Python packages, the simplest example would look like this:<br />
<pre><br />
%install<br />
python setup.py install --prefix=%{_prefix} --root=%{buildroot}<br />
<br />
%files<br />
%defattr(-,root,root)<br />
%{python_sitelib}/*<br />
</pre><br />
<br />
To avoid file conflicts with packages for other Python interpreters, binaries and/or man-pages should be suffixed with the Interpreter versions, e.g.:<br />
<pre><br />
%{_bindir}/foo<br />
</pre><br />
<br />
should become<br />
<pre><br />
%{_bindir}/foo-%{py_ver}<br />
</pre><br />
<br />
Please check the Python3 / parallel installation section below.<br />
<br />
=== System Architecture ===<br />
<br />
If your package only contains python sources (.py), bytecode files (.pyc and .pyo) and platform-independent data, you should mark it as noarch. Include '''<tt>BuildArchitectures: noarch</tt>''' at the start of your spec file. Such module should install entirely into %python_sitelib.<br />
<br />
Otherwise, the whole module installs into %python_sitearch. Note that it is not possible to have part of a module in %python_sitelib and another part in %python_sitearch. And in most cases, even if package contains more than one module, all of them should be in one prefix.<br />
<br />
This is important so i'm going to stress it: '''the entire module is either platform-independent, or it isn't.''' Even one binary library or platform-specific config file in otherwise pure python module will mark the entire module as platform-dependent and you won't be able to use it as noarch. This is usually handled by distutils, so you shouldn't need to worry most of the time.<br />
<br />
Certain packages might install parts of themselves into %python_sitelib and parts into %python_sitearch. Such setup is a common source of bugs and problems. Unless you know exactly what you're doing, you should modify such packages so that ''everything'' goes into %python_sitearch.<br />
<br />
=== setuptools/eggs ===<br />
{{Warning|The following text was imported from [http://fedoraproject.org/wiki/Packaging/Python Fedora Guidelines] and not reviewed for use in openSUSE yet. Use at your own risk.}}<font color="red"><br />
In the past, Fedora has done the minimal amount to support eggs for upstream distros. As eggs are being adopted more widely upstream we need to have more comprehensive documentation on how to handle this. The following are a summary of the guidelines for reviewers to go over. The [[Packaging/Python/Eggs| complete policy]] includes examples and rationale for the way we do things.<br />
* '''Must''': Python eggs must be built from source. They cannot simply drop an egg from upstream into the proper directory.<br />
* '''Must''': Python eggs must not download any dependencies during the build process.<br />
* '''Must''': If egg-info files are generated by the modules build scripts they must be included in the package.<br />
* '''Must''': When building a compat package, it must install using easy_install -m so it won't conflict with the main package.<br />
* '''Must''': When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.<br />
* '''Should''': A package which is used by another package via an egg interface should provide egg info.<br />
</font><br />
<br />
=== Byte Compiled Files ===<br />
<br />
Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run. These files are saved in files with the extension of .pyc (compiled python) or .pyo (optimized compiled python). These files are a byte code that is portable across OSes. If you do not include them in your packages, python will try to create them when the user runs the program. If the system administrator uses them, then the files will be successfully written. Later, when the package is removed, the .pyc and .pyo files will be left behind on the filesystem. To prevent that you need to byte compile the files when building your package and include the files in the %files section.<br />
<br />
Many packages install byte-compiled .pycs and .pyos by themselves. If your package doesn't do that, you should use the macro %{py_compile} in this way: '''<tt>%py_compile <directory></tt>''' to create .pyc and '''<tt>%py_compile -O <directory></tt>''' for .pyo files.<br />
<br />
Most of the time, .pyo files are exactly the same as .pyc. You can save space by running fdupes to hardlink them together.<br />
<pre><br />
BuildRequires: fdupes<br />
(...)<br />
<br />
%install<br />
(...)<br />
%fdupes $RPM_BUILD_ROOT%{py_sitedir}<br />
</pre><br />
<br />
=== Summary of useful rpm macros ===<br />
<br />
* '''%py_ver''' - python series denomination (major.minor version number)<br />
* '''%py_compile''' - byte-compiles python sources from the specified directory. Use <tt>%{py_compile -O}</tt> to produce optimized bytecode (.pyo)<br />
* '''%python_sitelib''' - <tt>site-packages</tt> directory for platform-independent modules. Expands to <tt>/usr/lib/python%{py_ver}/site-packages</tt><br />
* '''%python_sitearch''' - <tt>site-packages</tt> directory for platform-dependent modules. Expands to <tt>%{_libdir}/python%{py_ver}/site-packages</tt><br />
<br />
=== Compatibility with older distributions ===<br />
<br />
In 11.1, split python package was introduced. If you want to build a package for older distribution, you cannot require <tt>python-base</tt>. Note that <tt>python-base</tt> was introduced because it has almost no build-time or run-time dependencies. That means that it is unblocked sooner in the rebuild cycle, and conversely, if your package doesn't buildrequire <tt>python</tt>, it can be build sooner.<br />
<br />
The possibility to build noarch packages, along with <tt>%python_sitelib</tt> and <tt>%python_sitearch</tt>, was introduced in 11.2. If you need compatibility with older distributions, you must define the macros you are using. Place this at the start of your spec:<br />
<pre>%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}<br />
%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}</pre><br />
<br />
If your package is noarch, you must wrap the noarch declaration in a conditional sequence.<br />
<br />
This would build your package as noarch only on openSUSE 11.2 and higher:<pre><br />
%if 0%{?suse_version} >= 1120<br />
BuildArchitectures: noarch<br />
%endif</pre><br />
And this would build your package as noarch on openSUSE 11.2 and higher, plus on any non-SUSE distro. (Useful when building packages for Fedora)<pre>%if %{?suse_version: %{suse_version} > 1110} %{!?suse_version:1}<br />
BuildArchitectures: noarch<br />
%endif</pre><br />
<br />
=== Running tests ===<br />
The easiest way to run tests is using setuptools ''test'' subcommand:<br />
<pre><br />
python setup.py test<br />
</pre><br />
<br />
This of course only works, if ''test_suite'' or ''cmd_class'' is properly defined in your ''setup.py''. E.g. if you use external modules to find the tests:<br />
* <pre>cmdclass = {'test': pytest}</pre><br />
* <pre>test_suite='nose.collector'</pre><br />
Or the tests can be run by directly calling a module in `tests/` or `packagename/tests`:<br />
* <pre>test_suite='tests'</pre><br />
* <pre>test_suite='packagename.tests'</pre><br />
<br />
This also works for packages with compiled components.<br />
<br />
== Hints on how to Package Python3 modules ==<br />
<br />
Python-2.7 is the default Interpreter version no transition date to make Python-3.x the default interpreter has been defined.. Packages for Python-2.x are developed in the OBS project [https://build.opensuse.org/project/show?project=devel%3Alanguages%3Apython devel:languages:python], whereas Python-3.x packages are developed in [https://build.opensuse.org/project/show?project=devel%3Alanguages%3Apython3 devel:languages:python3]. <br />
<br />
It is recommended to create packages for both versions. Here is a small procedure how to do this:<br />
<br />
# Start packaging <tt>python-$FOO</tt> with [https://build.opensuse.org/package/show/devel:languages:python/python-py2pack py2pack].<br />
# Submit it to <tt>devel:languages:python</tt>. Wait if your package is accepted. If not, fix the remaining problems.<br />
# Create a separate package <tt>python3-$FOO</tt> by copying <tt>python-$FOO</tt> with <tt>osc copypac</tt>.<br />
# Rename all files from <tt>python-*</tt> to <tt>python3-*</tt> .<br />
# Open the <tt>python3-$FOO.spec</tt> file and:<br />
## Replace any dependency with their python3 counterpart.<br />
## Change <tt>%py_ver</tt> into <tt>%py3_ver</tt>.<br />
## Change <tt>%python_sitelib</tt> into <tt>%python3_sitelib</tt>.<br />
# Drop any compatibility macros for openSUSE versions older than 12.2.<br />
# Build your package locally.<br />
# Submit your package to [https://build.opensuse.org/project/show?project=devel%3Alanguages%3Apython3 devel:languages:python3].<br />
<br />
To stay in line with the above example, consider [https://build.opensuse.org/package/show/devel:languages:python3/python3-Sphinx python3-Sphinx].<br />
<br />
<br />
=== Parallel installation ===<br />
<br />
In order to be able to install the Python-2.x and Python-3.x version of a package in parallel, file conflicts need to be avoided. In general this includes all files not installed into <tt>%{python_sitelib}</tt> / <tt>%{python_sitearch}</tt> (and their Py3k equivalents) nor files marked as %doc. In other words, check your <tt>%files</tt> section(s) for the following:<br />
<pre><br />
%{_bindir}/foo<br />
%{_mandir}/man1/foo.1.gz<br />
</pre><br />
Icons, <tt>*.desktop</tt> files and application data in <tt>%{_datadir}</tt> may also conflict. The correct solution is to use <tt>update-alternatives</tt>. The already mentioned package examples all implement proper <tt>update-alternatives</tt>, so please consider those.<br />
<br />
<br />
<br />
See [[openSUSE:Python 3 Status]] for a list of Python packages and their Python3 status on openSUSE.<br />
<br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Paketbau von Python-Software]]<br />
[[el:openSUSE:Packaging Python]]<br />
[[zh:openSUSE:Packaging_Python]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Testing&diff=118361openSUSE:Testing2016-12-17T17:05:09Z<p>Okurz: Delete outdated content; refer to current openQA URLs; mention Tumbleweed</p>
<hr />
<div>{{Bug navbar}}<br />
{{Special info|__NOTOC__ Thank you for your interest in helping to test openSUSE. It is people like you that make open source software happen. Testing and finding issues is a critical component to the delivery of any software, and this page aims to bring together the required resources in one place. Especially to help new testers, but also be a resource for more experienced testers to help them maintain testing of a high quality and consistency between releases.}}<br />
<br />
<br />
{{Point here|[[Image:Icon-distribution.png|48px]]|<br />
'''The development cycle'''<br />
<br />
In addition to the current stable release of openSUSE, there is a development version of openSUSE called [[Portal:Factory|Factory]] on which openSUSE Tumbleweed is based. On the [[openSUSE:Roadmap]] you will see development releases such as Milestones and Release Candidates, these releases are snapshots in the ever changing [[Portal:Factory|Factory]]. <br />
<br />
Testing is generally done on a regular basis on openSUSE Tumbleweed and on the latest [http://software.opensuse.org/developer development release], with additional testing sometimes done using updates from Factory to verify bug fixes. More information on the development process can be found on the [[Portal:Development|development portal]].<br />
<br />
Besides the manual testing there is an automated system called [http://openqa.opensuse.org/ openQA] which runs predefined tests on the latest factory snapshots, release version builds, maintenance requests and more. An overview of the latest results can be found [http://openqa.opensuse.org/ here].<br />
<br />
}}<br />
<br />
{{Point here|[[Image:Icon-bug.png|48px]]|<br />
'''Reporting Bugs'''<br />
<br />
One very important aspect of being a good tester is to be able to report the issues that you find, that is, to '[[openSUSE:Submitting_bug_reports |Submit a bug report]]'. They need to be as clear as possible, so that the developers can understand exactly what component has an issue and under what circumstances. Don't worry, there are a lot of resources to help you learn how to write a good bug report.<br />
<br />
* [[openSUSE:Submitting_bug_reports]]<br />
* [[openSUSE:Bug_reporting_FAQ]]<br />
<br />
If you need help/support in testing, if you have topics to discuss or if you are just interested in this area, join the '''opensuse-testing@opensuse.org''' mailing list (see [[openSUSE:Mailing lists]] page how to subscribe) or join us on IRC [irc://chat.freenode.net/opensuse-factory #opensuse-factory].<br />
}}<br />
<br />
{{Point here|[[Image:Icon-community.png|48px]]|<br />
'''Testing Core Team (TCT)'''<br />
<br />
The [[openSUSE:Testing Core team|openSUSE Testing Core Team]] is in charge of testing the openSUSE distro.<br />
For the next scheduled team meeting refer to [[openSUSE:Testing meeting]] page.<br />
}}<br />
<br />
{{Point here|[[Image:Icon-event.png|48px]]|<br />
'''Events'''<br />
<br />
* Check here for the next [[openSUSE:Testing meeting | Testing Core Team meeting]]<br />
* Check here for the next [[openSUSE:Open-Bugs-Day | Open-Bugs-Day]]<br />
}}<br />
<br />
{{Point here|[[Image:Icon-info.png|48px]]|<br />
'''Additional Info'''<br />
<br />
* SyncML OBEX Client plug-in allows many modern mobile phones to do a local synchronization, help to test on your model. Check out the test plan for [[SyncML OBEX client]]<br />
* Help Update the HCL with information from your hardware. [[Portal:Hardware]]<br />
* Linux Desktop Testing Project ([http://ldtp.freedesktop.org LDTP] in short)<br />
}}<br />
<br />
[[Category:Factory|{{PAGENAME}}]]<br />
[[Category:Fixing bugs|{{PAGENAME}}]]<br />
[[Category:Projects|{{PAGENAME}}]]<br />
<br />
[[de:Testen]]<br />
[[es:Pruebas]]<br />
[[ru:openSUSE:Тестирование]]<br />
[[ja:Testing]]<br />
[[zh:openSUSE:Testing]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Open-Bugs-Day&diff=118358openSUSE:Open-Bugs-Day2016-12-17T15:22:21Z<p>Okurz: proposal to delete page</p>
<hr />
<div>{{Bug navbar}}<br />
{{Special info|__NOTOC__<br />
<center>The third openSUSE '''Open-Bugs-Day''' will be on '''2011-08-21''' from 00:00 to 23:59 UTC</center><br />
}}<br />
<br />
{{delete|Article outdated and refers to outdated openSUSE versions only}}<br />
<br />
{{Point here|[[Image:Icon-distribution.png|48px]]|<br />
'''Why'''<br><br />
As you all know, the next Release is in the pipeline [[Portal:factory|openSUSE 12.1]] so we need your help to go through old bugs!<br />
The testing team is looking for volunteers to help with [http://bugzilla.novell.com/ bugzilla]: Closing what's fixed; and confirming what still needs work.<br />
With us clearing out what is fixed, the developers can focus their energies on fixing bugs instead of clicking around bugzilla!<br />
This event is similar to [[openSUSE:Bug Day|Bug Day]] - just that this time, it is about more recent versions. In fact, we will concentrate on the open bugs for 11.4 to see if they still exist in the developmental version of 12.1.<br />
}}<br />
{{Point here|[[Image:Icon-event.png|48px]]|<br />
'''When'''<br><br />
2011-08-21 from 00:00 to 23:59 UTC<br />
}}<br />
{{Point here|[[Image:Icon-community.png|48px]]|<br />
'''Who'''<br><br />
Anyone using openSUSE is welcome to help.<br />
}}<br />
{{Point here|[[Image:Icon-irc.png|48px]]|<br />
'''Where'''<br><br />
Coordination for '''Open-Bugs-Day''' happens on this wiki page and on [irc://irc.opensuse.org/openSUSE-testing #openSUSE-testing] IRC channel on Freenode.<br />
}}<br />
{{Point here|[[Image:Icon-usage.png|48px]]|<br />
'''What you need'''<br><br />
You need an account on http://bugzilla.novell.com/<br />
<br />
As openSUSE 12.4 MS4 was not formally released, we run the risk of testing on different versions. Accordingly, we are providing a common Factory version for testing. There are three ways to do this<br />
* You can ask bmwiedemann on IRC for [[SDB:VNC_usage|VNC]] access to a hosted virtual machine (VM) - this is the easiest<br />
* For those people that wish to test on their own hardware, there will be KDE and Gnome virtual images available at [http://www5.zq1.de/img/ http://www5.zq1.de/img/]. These have been built with KVM, but have been tested with VirtualBox. They are compressed with xz and are just over 900 MB. Assuming you wish to keep only the decompressed file, use 'xz -d <image_name>', where <image_name> does not include the "xz" extension. Next start VB and use the GUI to create a new VM. On the disk image screen, choose the file you just decompressed. The images will use 800x600 resolution. If you want greater, install the VB extension pack and change the "vga" parameter on the GRUB bootup line. The default 0x314 is for 800x600, 0x317 gets 1024x768, and 0x31b gets 1280/1024.<br />
* You can install 12.1 natively on your computer (e.g. in a separate partition) - this is a better test for hardware-related issues. Factory snapshots are available at [http://mirror.zq1.de/opensuse/factory/iso/ http://mirror.zq1.de/opensuse/factory/iso/].<br />
}}<br />
{{Point here|[[Image:Icon-question.png|48px]]|<br />
'''How'''<br><br />
The workflow is usually as follows:<br />
# use the [http://openbugs.zq1.de Open-Bugs-Coordination-Tool] or search bugzilla for open bugs in the 11.4 release<br />
# try to reproduce an issue on the current openSUSE release (12.1 or Factory) and update [http://bugzilla.novell.com/ bugzilla], using prepared texts as follows<br />
## if it still occurs, clone the bug (link is in lower right-hand corner of screen) and set the current version<br />
## if you know the issue was fixed, add <br/>{{HL|"''This has been fixed in 12.1.''"}}<br />
## if you are unable to confirm the bug, it may have been fixed, or it may be difficult to reproduce. Please change the bug to NEEDINFO from the reporter and ask that the bug be tested on 12.1.<br />
# GOTO 1<br />
}}<br />
{{Point here|[[Image:Icon-feature.png|48px]]|<br />
'''Reward'''<br><br />
There will be free openSUSE t-shirts for the top 5 most active participants in Open-Bugs-Day.<br />
}}</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Testing_Core_team&diff=118357openSUSE:Testing Core team2016-12-17T15:01:58Z<p>Okurz: </p>
<hr />
<div>__NOTOC__<br />
<center>[[File:Testing-Group-Logo.png|128px]]</center><br />
<div style="background-color:#E5E5E6;text-align:center;color:#000000"><br />
=== Introduction ===<br />
</div><br />
:<br />
'''Where do we come from'''<br />
* The openSUSE Testing Core team is composed of members from around the globe that want to contribute in improving the openSUSE operating system.<br />
<br />
'''How do we perform our jobs'''<br />
* We coordinate our work during the regular meetings. For more details see the [[openSUSE:Testing_meeting | meeting]] page.<br />
<br />
'''What skills do we posess'''<br />
* We are able to create valid bug reports that will help developers to fix problems found in early development stages of openSUSE and in the stable version.<br />
<br />
'''Objectives'''<br />
* The openSUSE Testing Core team wants to identify bugs as early as possible in the development cycle to give developers time to find a solution and to give less technical testers a better user-experience.<br />
* The openSUSE Testing Core team tries to identify bugs in the stable version of openSUSE and passes the information down to the developers in order for them to create a proper fix.<br />
<br />
'''Team Statement '''<br />
* Make openSUSE a reliable platform for both users and developers.<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#000000"><br />
<br />
=== Communicate ===<br />
</div><br />
'''Mailing List''' {{Mailinglist|opensuse-testing|Discussion about testing the openSUSE distribution}}<br />
<br />
'''IRC Channel''' <br />
* [irc://irc.opensuse.org/openSUSE-testing #openSUSE-testing] Feedback and discussion about testing openSUSE<br />
<br />
'''openSUSE Connect Group''' <br />
* Join also [https://connect.opensuse.org/pg/groups/12174/opensuse-testers/ The openSUSE Testers group]<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== Main coordinating members ===<br />
</div><br />
<br />
<br />
{|style="border:2px solid #aaa;" border="2" cellpadding="2" cellspacing="3" <br />
|-<br />
! Name<br />
! IRC<br />
! Mail<br />
! Web<br />
! Country<br />
|-<br />
| [[user:bmwiedemann|Bernhard M. Wiedemann]]<br />
| bmwiedemann ; ICQ: 41890653<br />
| susetestingbmw at lsmod de<br />
|<br />
| Germany<br />
|-<br />
| Larry Finger <br />
| LWFinger<br />
| Larry.Finger - at - lwfinger - net<br />
|<br />
| US<br />
|-<br />
|}<br />
<br />
<!--*Brazil<br />
** Gabriel Franco (irc: IsoreHalav / e-mail: gffranco@opensuse.org)<br />
** Kayo Hamid (irc: kayo / e-mail: kayohf@gmail.com)<br />
** Gabriel Stein (irc: gabrielstein / email: gabrielstein at gmail dot com)<br />
<br />
*Canada<br />
** Refilwe Seete (e-mail: r.seete at removablerubbish gmail dot com)<br />
<br />
*Finland<br />
** Thomas Sundell (e-mail: firstname.lastname at removethis pp dot inet dot fi(nland), http://thsundel.blogspot.com/ | http://twitter.com/thsundel)<br />
<br />
*Germany<br />
** Thomas Schulte ([[user:TERROR-FX]] / irc: CupRacer / e-mail: thomas@cupracer.de) Availability:16:00 - 22:00 GMT weekdays, Whole day during weekends<br />
** Jürgen Radzuweit (irc: jradzuweit / e-mail: juergen@radzuweit.eu )<br />
'''Availability'''16:00 - 22:00 GMT weekdays, Whole day during weekends<br />
** Bernhard M. Wiedemann<br />
<br />
*Hungary<br />
** Peter Czanik (e-mail: pczanik at fang.fa.gau.hu / IRC: CzP)<br />
<br />
*India<br />
** Atri Bhattacharya (irc: badshah / email: badshah400@aim.com)<br />
<br />
*Italy<br />
** Marco Poletti (e-mail: poletti.marco@gmail.com)<br />
'''Availability'''<br />
7:00 - 19:00 GMT all days, until 21 September. After that, only 1 hour/day in the same timeframe.<br />
<br />
*Norway<br />
** Birger Kollstrand (e-mail birger kollstrand at googlemail com)<br />
<br />
<br />
*South Africa<br />
** Dave Plater (e-mail: dave.plater@yahoo.co.uk)<br />
** Johan Kotze (e-mail: jkotze@novell.com)<br />
<br />
*UK<br />
** Spencer Paul French (irc: ingvildr / e-mail: spencerpaulfrench at gmail dot com)<br />
'''Availability'''<br />
8.00 - 10.30 and 16.30 - 19.30 GMT weekdays / All day on weekends<br />
<br />
*US<br />
** Larry Finger (e-mail: Larry.Finger@lwfinger.net)<br />
'''Availability'''<br />
15.00 - 03.00 GMT weekdays<br />
** Steven Harms (e-mail: sharms at removethis ubuntu.com, irc: sharms)<br />
'''Availability'''<br />
14.00 - 03.00 GMT<br />
** Jonathon Robison (e-mail: jrobiso2 at gmail dot com)<br />
'''Availability'''<br />
09.00 - 15.00 EST (After mid-October. Until then, deeply involved in virtualization of (**shudder**) Windows<br />
<br />
*Country not yet specified<br />
** Boyd Lynn Gerber<br />
** Ciro Iriarte<br />
** Elmar Stellnberger<br />
** Günther J. Niederwimmer<br />
** Patrick M. Shanahan<br />
** Terje J. Hanssen<br />
--><br />
<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== How to join ===<br />
</div><br />
:<br />
<br />
'''Who is eligible to join the team (terms and conditions)?'''<br />
* Everybody that wants to contribute to the testing of openSUSE is welcomed to join the team. The future contributor must have a a basic understanding of how openSUSE works.<br />
<br />
'''Whom to contact for more informations?<br />
* Contact the Main coordinating members via IRC or e-mail. Remember to be polite and not to spam. <br />
<br />
'''Is openSUSE Membership required for tasks?'''<br />
* openSUSE Membership is required only for some tasks. More information about becoming an openSUSE member is available in this [[openSUSE:Members | wiki page]].<br />
<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== Team tasks ===<br />
</div><br />
:<br />
<br />
* Test and report bugs on [[openSUSE:Bugreport Factory|Factory]], Milestones and Release Candidates using [https://bugzilla.novell.com/index.cgi Bugzilla]<br />
* Test and report bugs found on the stable version of openSUSE again using [https://bugzilla.novell.com/index.cgi Bugzilla]<br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
==== Currently Working on ====<br />
</div><br />
:<i>Tasks currently being performed to noted here .</i><br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
==== Open Tasks ====<br />
</div><br />
:<i>There may be some tasks where the normal contributors can contribute apart from the team Members .</i><br />
<br />
<div style="background-color:#E5E5E6;text-align:center;color:#0b5147"><br />
<br />
=== Additional links for contributors ===<br />
</div><br />
:<br />
<br />
Refer to [[openSUSE:Testing | Testing ]] for information about distribution testing.<br />
<br />
Refer to [[openSUSE:Testing meeting | Testing meeting]] for the next scheduled meeting.<br />
<br />
Refer to [[Portal:Factory | Portal:Factory]] for information about the developing state of a future openSUSE version. <br />
<br />
Refer to [[openSUSE:Submitting_bug_reports | openSUSE Bugs]] for information about bugs and how to report them correctly. <br />
<br />
Refer to [https://bugzilla.novell.com/index.cgi Bugzilla] when searching or reporting bugs.<br />
<br />
----<br />
[[Category:Team pages]]<br />
[[Category:Factory]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Testing_meeting&diff=118356openSUSE:Testing meeting2016-12-17T15:01:22Z<p>Okurz: delete "next meeting" because it was referring to 2013 and is outdated for three years already</p>
<hr />
<div>{{Intro|The [[openSUSE:Testing Core team | Testing Core team]] meets after a new milestone is released to discuss the next steps for testing. Everybody is welcome who is interested in testing. The meeting will be held on the [irc://irc.freenode.net/opensuse-testing #openSUSE-testing] IRC channel.<br />
}}<br />
<br />
__TOC__<br />
<br />
==Next meeting==<br />
{{Point here|[[Image:Icon-event.png|48px]]|<br />
Currently there are no meetings planned or the meeting planning is not conducted on this wiki<br />
}}<br />
<br />
----<br />
<br />
==Archive==<br />
{{Point here|[[Image:Icon-history.png|48px]]|<br />
===2013===<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2013/opensuse-testing.2013-02-11-18.05.html Testing Meeting - Monday 2013-02-11 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2013/opensuse-testing.2013-01-21-18.01.html Testing Meeting - Monday 2013-01-21 18:00 (UTC)]<br />
===2012===<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-12-17-18.00.html Testing Meeting - Monday 2012-12-17 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-11-12-18.07.html Testing Meeting - Monday 2012-11-12 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-08-09-17.00.html Testing Meeting - Tuesday 2012-08-09 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-07-19-17.01.html Testing Meeting - Tuesday 2012-07-19 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-07-02-17.04.html Testing Meeting - Tuesday 2012-07-02 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-06-18-17.02.html Testing Meeting - Tuesday 2012-06-18 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-06-04-17.02.html Testing Meeting - Tuesday 2012-06-04 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-05-29-17.23.html Testing Meeting - Tuesday 2012-05-29 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-04-16-17.01.html Testing Meeting - Monday 2012-04-16 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-03-19-18.01.html Testing Meeting - Monday 2012-03-19 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-02-13-18.00.html Testing Meeting - Monday 2012-02-13 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2012/opensuse-testing.2012-01-16-18.01.html Testing Meeting - Monday 2012-01-16 18:00 (UTC)]<br />
===2011===<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-12-12-18.02.html Testing Meeting - Monday 2011-12-12 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-11-07-18.00.html Testing Meeting - Monday 2011-11-07 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-10-25-17.00.html Testing Core Team Meeting - Monday 2011-10-25 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-09-26-17.52.html Testing Core Team Meeting - Monday 2011-09-26 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-09-12-17.03.html Testing Core Team Meeting - Monday 2011-09-12 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-08-15-17.01.html Testing Core Team Meeting - Monday 2011-08-15 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-07-25-17.00.html Testing Core Team Meeting - Monday 2011-07-25 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-07-18-17.06.html Testing Core Team Meeting - Monday 2011-07-18 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-06-27-17.02.html Testing Core Team Meeting - Monday 2011-06-27 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-06-06-17.05.html Testing Core Team Meeting - Monday 2011-06-06 17:00 (UTC)]<br />
* [[openSUSE:Testing meeting 20110523|Testing Core Team Meeting - Monday 2011-05-23 17:00 (UTC)]]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-05-09-17.03.html Testing Core Team Meeting - Monday 2011-05-09 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-04-11-17.00.html Testing Core Team Meeting - Monday 2011-04-11 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-03-28-17.01.html Testing Core Team Meeting - Monday 2011-03-28 17:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-03-14-18.00.html Testing Core Team Meeting - Monday 2011-03-14 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-03-07-18.01.html Testing Core Team Meeting - Monday 2011-03-07 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-02-28-18.04.html Testing Core Team Meeting - Monday 2011-02-28 18:00 (UTC)]<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2011/opensuse-testing.2011-02-14-18.01.html Testing Core Team Meeting - Monday 2011-02-14 18:00 (UTC)] [[openSUSE:Testing meeting 20110214|Local Copy]]<br />
* [[openSUSE:Testing meeting 20110131|Testing Core Team Meeting - Monday 2011-01-31 18:00 (UTC)]]<br />
<br />
===2010===<br />
* [http://community.opensuse.org/meetings/opensuse-testing/2010/opensuse-testing.2010-12-06-18.00.html Testing Core Team Meeting - Monday 2010-12-06 18:00 (UTC)]<br />
* [[openSUSE:Testing meeting 20101115|Testing Core Team Meeting - Monday 2010-11-15 18:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20101004|Testing Core Team Meeting - Monday 2010-10-04 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100705|Testing Core Team Meeting - Monday 2010-07-05 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100628|Testing Core Team Meeting - Monday 2010-06-28 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100621|Testing Core Team Meeting - Monday 2010-06-21 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100531|Testing Core Team Meeting - Monday 2010-05-31 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100503|Testing Core Team Meeting - Monday 2010-05-03 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100419|Testing Core Team Meeting - Monday 2010-04-19 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100329|Testing Core Team Meeting - Monday 2010-03-29 17:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100315|Testing Core Team Meeting - Monday 2010-03-15 18:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100224|Testing Core Team Meeting - Wednesday 2010-02-24 18:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20100121|Testing Core Team Meeting - Thursday 2010-01-21 18:00 (UTC)]]<br />
<br />
<!-- -- see [ transcript] --><br />
<br />
===2009===<br />
* [[openSUSE:Testing meeting 20091216|Testing Core Team Meeting - Wednesday 2009-12-16 18:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20091117|Testing Core Team Meeting - Tuesday 2009-11-17 20:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20091031|Testing Core Team Meeting - Saturday 2009-10-31 - Incomplete Log]]<br />
* [[openSUSE:Testing meeting 20091022|Testing Core Team Meeting - Thursday 2009-10-22 18:00 (UTC)]]<br />
* [[openSUSE:Testing meeting 20091008|Testing Core Team Meeting - Thursday 2009-10-08 18:00 (UTC)]]<br />
}}</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Testing&diff=118355openSUSE:Testing2016-12-17T14:56:08Z<p>Okurz: Delete outdated content; refer to current openQA URLs; mention Tumbleweed</p>
<hr />
<div>{{Bug navbar}}<br />
{{Special info|__NOTOC__ Thank you for your interest in helping to test openSUSE. It is people like you that make open source software happen. Testing and finding issues is a critical component to the delivery of any software, and this page aims to bring together the required resources in one place. Especially to help new testers, but also be a resource for more experienced testers to help them maintain testing of a high quality and consistency between releases.}}<br />
<br />
<br />
{{Point here|[[Image:Icon-distribution.png|48px]]|<br />
'''The development cycle'''<br />
<br />
In addition to the current stable release of openSUSE, there is a development version of openSUSE called [[Portal:Factory|Factory]] on which openSUSE Tumbleweed is based. On the [[openSUSE:Roadmap]] you will see development releases such as Milestones and Release Candidates, these releases are snapshots in the ever changing [[Portal:Factory|Factory]]. <br />
<br />
Testing is generally done on the latest [http://software.opensuse.org/developer development release], with additional testing sometimes done using updates from Factory to verify bug fixes. More information on the development process can be found on the [[Portal:Development|development portal]].<br />
<br />
Besides the manual testing there is an automated system called [http://openqa.opensuse.org/ openQA] which runs predefined tests on the latest factory snapshots. An overview of the latest results can be found [http://openqa.opensuse.org/ here].<br />
<br />
}}<br />
<br />
{{Point here|[[Image:Icon-bug.png|48px]]|<br />
'''Reporting Bugs'''<br />
<br />
One very important aspect of being a good tester is to be able to report the issues that you find, that is, to '[[openSUSE:Submitting_bug_reports |Submit a bug report]]'. They need to be as clear as possible, so that the developers can understand exactly what component has an issue and under what circumstances. Don't worry, there are a lot of resources to help you learn how to write a good bug report.<br />
<br />
* [[openSUSE:Submitting_bug_reports]]<br />
* [[openSUSE:Bug_reporting_FAQ]]<br />
<br />
If you need help/support in testing, if you have topics to discuss or if you are just interested in this area, join the '''opensuse-testing@opensuse.org''' mailing list (see [[openSUSE:Mailing lists]] page how to subscribe).<br />
}}<br />
<br />
{{Point here|[[Image:Icon-community.png|48px]]|<br />
'''Testing Core Team (TCT)'''<br />
<br />
The [[openSUSE:Testing Core team|openSUSE Testing Core Team]] is in charge of testing the openSUSE distro.<br />
For the next scheduled team meeting refer to [[openSUSE:Testing meeting]] page.<br />
}}<br />
<br />
{{Point here|[[Image:Icon-event.png|48px]]|<br />
'''Events'''<br />
<br />
* Check here for the next [[openSUSE:Testing meeting | Testing Core Team meeting]]<br />
* Check here for the next [[openSUSE:Open-Bugs-Day | Open-Bugs-Day]]<br />
}}<br />
<br />
{{Point here|[[Image:Icon-info.png|48px]]|<br />
'''Additional Info'''<br />
<br />
* SyncML OBEX Client plug-in allows many modern mobile phones to do a local synchronization, help to test on your model. Check out the test plan for [[SyncML OBEX client]]<br />
* Help Update the HCL with information from your hardware. [[Portal:Hardware]]<br />
* Linux Desktop Testing Project ([http://ldtp.freedesktop.org LDTP] in short)<br />
}}<br />
<br />
[[Category:Factory|{{PAGENAME}}]]<br />
[[Category:Fixing bugs|{{PAGENAME}}]]<br />
[[Category:Projects|{{PAGENAME}}]]<br />
<br />
[[de:Testen]]<br />
[[es:Pruebas]]<br />
[[ru:openSUSE:Тестирование]]<br />
[[ja:Testing]]<br />
[[zh:openSUSE:Testing]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Launch_party_HOWTO&diff=117931openSUSE:Launch party HOWTO2016-11-21T20:40:30Z<p>Okurz: /* Pick a date */</p>
<hr />
<div>{{Marketing resources navbar}}<br />
<br />
Here you find the [[openSUSE:Launch_parties|launch party]] how-to. It contains a simple 5-step plan on creating a party - but keep in mind that you can do it any way you want! Organizing a launch party is not meant to be difficult and should be enjoyable, also for you! So don't stress out, just take these steps and '''have a lot of fun!'''<br />
<br />
The main thing to keep in mind is that '''organizing an openSUSE party is easy''': ''getting some fellow geeko's in a room is an instant recipe for fun, so that's all you have to accomplish.''<br />
<br />
==Five Steps to a successful launch party==<br />
There's a number of questions you might want to ask yourself. The biggest question is about size: how big do you want it? Next up, how formal. We suggest to keep it small and informal the first time around: a living room party with 10 people is a great way of having fun and a good start of an awesome new tradition!<br />
<br />
We won't try to cover all the bases here, but focus on the average launch party. There are 5 steps you should take to successfully run a party. Keep in mind that you have to keep a balance: extra effort into the party will be appreciated; but it has to remain fun for you as well so ask others to help out if you start doing a big event!<br />
<br />
===Find a nice location===<br />
No location = no party. You can be creative with this - from a coffee shop to a club, from a living room to an office or university room - it is all great.<br />
<br />
'''What does a location need to have?'''<br />
* Something to eat and drink<br />
** In an office or living room you can order pizza together ("everyone trows in $5") and ask people to bring drinks<br />
** In a cafe or coffee shop food & drinks can be ordered by everyone for themselves<br />
* Easy to reach with public transport and/or car<br />
* Optional (note that it's meant to be a party, not a sales meeting!):<br />
** the ability to give a presentation to show what's new in KDE (beamer!)<br />
** power and wifi so people can bring their laptop to install the latest openSUSE and/or get help with issues and/or demonstrate new things<br />
<br />
====Pick a date====<br />
Launch parties aren't limited to the release date. It's fine to organize a party 3 or 4 weeks after the release, when people have had a chance to test it out!<br />
<br />
Example: For a release in September as we had it for openSUSE Leap 42.1 it might even make sense to do the release party in December or even January.<br />
<br />
===Find a sponsor===<br />
This step is not mandatory but will help you a lot with the golden rule of putting in '''the extra effort'''. Your employer, the local IT company or computer shop might be willing to spend a little bit of money so you can sponsor some drinks and/or food as it's nice advertisement for them. Just go out and ask politely, you will be surprised what you can get. Some extra cash might come in handy later on. <br />
<br />
===Promote it===<br />
You have to make sure that everyone you want to attend has heard about the party as far in advance as possible! People plan their lives and there are tons of events going on you most likely compete against. Convince them yours is the one not to miss :-)<br />
<br />
What to do:<br />
* Make sure you register the event on the [[openSUSE:Launch_parties|openSUSE Launch Party page]] so the Marketing Team can write about it and people can find it easily!<br />
* Blog about it. It's nice to give a bit of an agenda of the evening - the better they know what will happen, the more likely it is they will come.<br />
* Create hand outs and posters and spread them around. You can find posters on [[openSUSE:Artwork_posters|this page]].<br />
* Inform your local newspapers and magazines about the event, they might even show up and report about the event and openSUSE. Keep in mind that they have a press date! That can mean that you have to inform them up to a month before the event. Most magazines and papers print the press date for their next issue inside the imprint.<br />
* Create a facebook event and send invites, tweet about it and use other social media sites to spread the word. Ask the marketing team to re-tweet you and post it on the openSUSE facebook page!<br />
* Send out email invites to the local Linux User Groups and other possible interested people like schools, universities, IT departments of companies, IT departments of local authorities and the like. <br />
* Tell the [[openSUSE:News team]] about your event so they write a post for openSUSE News.<br />
<br />
===Prepare It===<br />
What happens on your event is up to your imagination and the only real limited is the amount of preparation you want to put in. The more you want to do at the party the more you have to plan for in advance and it has shown that events work best if the program reflects the abilities the organizer. However this has a lot to do with individual experience so it's kind of hard to give advice about it. Try things, be creative, give your event a personal touch and remember to put in some'''extra effort'''.<br />
<br />
Some ideas:<br />
* make or order a nice openSUSE cake!<br />
* give a presentation on what's new in the release. The announcement and marketing materials should give you plenty to put together a quick talk of 20 minutes or so<br />
** Or ask someone else to give a talk.<br />
* You could ask people to bring laptops to share tips and ideas on openSUSE or help each other with the upgrade to the new version<br />
{{info|Don't plan too much. Really, if you have a 20 min presentation and then the eating of cake, you'll be fine - after that, people chat and drink beer and have fun.}}<br />
<br />
For larger events you might want to use some form of sign up so you can plan better. You can of course use your email address and some text file for this but there are also various free tools in the web, like [http://www.eventbrite.com/ EventBrite] or for just finding a good date, use [http://doodle.com doodle]. <br />
<br />
====Presentations====<br />
If you want to give a presentation, find some materials [[openSUSE:Presentations|on the Presentations page]]. There is a bunch of standard presentations you or someone else could give. Be sure to check the notes, as they explain what you need to say!<br />
<br />
====Getting cool stuff™====<br />
<br />
It's always nice to have some things to give away at a release party. The openSUSE marketing team has some goodies like stickers, flyers, DVD's and t-shirts we can send to you! You could do a little lottery or give away some things to long-time local openSUSE contributors and the DVD's and flyers you can give to people to hand out to their friends and family.<br />
<br />
If there is anything left, just save it for a local conference where you can hand it out!<br />
<br />
If you want to organize a release party and get stuff, put your details below and ''order the materials'' via [http://software.opensuse.org/promodvd this website]. Note clearly in the description that you want stuff for a release party so we prioritize your request!!!<br />
<br />
Count on ''at least 2 weeks'' shipping and handling time in Europe and the USA, ''3-4 weeks'' in the rest of the world.<br />
<br />
===Report about It===<br />
Once you successfully ran your launch party we would of course hear about it! For this we would like to ask you to please send an e-mail with a report on your party to the [mailto:opensuse-marketing@opensuse.org marketing mailinglist]. Please answer these questions:<br />
<br />
# What was the events name?<br />
# When was it? <br />
# Did anyone sponsor it?<br />
# Who organized it?<br />
# Tell us about the event!<br />
## What exactly did you do?<br />
## Any interesting story you would like to share with us?<br />
## Care to share any photos or videos you took?<br />
# How much promotional material (DVDs etc.) did you distribute?<br />
# How many people were there attending the event?<br />
# How did you promote the Event?<br />
# Would you do it again? <br />
# Did your report about the event elsewhere?<br />
<br />
If you follow these five steps and put in '''the extra effort''' you will make a bunch of people happy, maybe even introduce some new people to Linux and help to promote the openSUSE Project! But most important you'll<br />
<br />
'''Have a lot of Fun...'''</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.1&diff=116490openSUSE:Most annoying bugs 42.12016-08-21T19:04:44Z<p>Okurz: /* openSUSE 42.1 */ correct bugurl copy-paste error</p>
<hr />
<div>{{Bug navbar}}<br />
{{Intro|The most annoying bugs and their suggested workarounds:<br>For general information about reporting bugs, see [[openSUSE:Submitting_bug_reports|Submit a Bug]]. <br />
Also see the [[openSUSE:Localization guide|Localization Guide]].}}<br />
<br />
To directly report a bug against openSUSE Leap 42.1 - use "openSUSE Distribution". Here's a [https://bugzilla.opensuse.org/enter_bug.cgi?&product=openSUSE%20Distribution&cf_foundby=Customer&op_sys=openSUSE+42.1&version=Leap+42.1 shortcut].<br />
<br />
You can also view the [https://bugzilla.opensuse.org/buglist.cgi?product=openSUSE%20Distribution&version=Leap%2042.1 list of all bugs]<br />
<br />
When adding a bug to this page, please always include a link to the bugreport in bugzilla.<br />
<br />
== openSUSE 42.1 ==<br />
<br />
* [https://bugzilla.opensuse.org/show_bug.cgi?id=955167 Bug #955167]<br />
** '''Symptoms:''' X cannot be started with gdm using fglrx<br />
** '''Problem:''' Unknown<br />
** '''Workaround:''' Switch to a different displaymanager like xdm, lightdm, sddm<br />
<br />
* [https://bugzilla.opensuse.org/show_bug.cgi?id=953778 Bug #953778]<br />
** '''Symptoms:''' KDE displaymanager unusable with lots of users<br />
** '''Problem:''' No user name entry, trying to mount every user's home<br />
** '''Workaround:''' modify /etc/sddm.conf and define a different theme and maximum UID<br />
** '''See also:''' [https://bugzilla.opensuse.org/show_bug.cgi?id=953778#c3 Bug #953778]<br />
<br />
* [https://bugzilla.opensuse.org/show_bug.cgi?id=953737 Bug #953737]<br />
** '''Symptoms:''' KDE displaymanager fails in VirtualBox guest<br />
** '''Workaround:''' Turn off 3D acceleration in VirtualBox manager<br />
<br />
<br />
* [https://bugzilla.opensuse.org/show_bug.cgi?id=967666 Bug #967666]<br />
** '''Symptoms:''' Updates not available for ppc64le and ARM<br />
** '''Workaround:''' Add the following URL as UPDATE repo <code>http://download.opensuse.org/ports/update/42.1/</code><br />
<br />
[[Category:Most annoying bugs]]<br />
[[Category:42.1|Bugs dev]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_for_Leap&diff=84719openSUSE:Packaging for Leap2016-05-25T12:31:21Z<p>Okurz: grammar/typo</p>
<hr />
<div>{{Leap navbar}}<br />
<br />
{{Intro|This article will give you a view from the contributor perspective on [[Portal:Leap|openSUSE Leap]]. Many of the concepts, commands to execute, people to talk to and so on are very similar to [[Portal:Factory|openSUSE Factory]]. It is recommended to use the [[openSUSE:How_to_contribute_to_Factory|How to Contribute to openSUSE Factory]] guide as a starting point, with this guide focusing on the differences specific to [[Portal:Leap|openSUSE Leap]]. This article will show that contribution to Leap is both '''easy''' and '''very welcome'''.}}<br />
<br />
== When can packages be submitted into Leap ==<br />
<br />
In general, packages can only be added to an openSUSE Leap version during it's development, not after its release. Any exceptions have to be approved and processed by the [[Portal:Maintenance|Maintenance team]].<br />
<br />
Packages that are already in openSUSE Factory will '''not''' automatically show up in Leap. Acceptance in Factory usually is a precondition though.<br />
<br />
== How to add a new package to an openSUSE Leap release in development ==<br />
<br />
'' Note that openSUSE Leap 42.1 is released and now under maintenance. This section only applies to 42.2''<br />
<br />
Leap is a stable release built by combining packages from [https://www.suse.com/products/server/ SUSE Linux Enterprise] and [[Portal:Tumbleweed|openSUSE Tumbleweed]].<br />
<br />
For people familiar with the [[openSUSE:Factory_development_model|Factory Development Model]], Factory serves a purpose for Leap similar to the purpose a Devel Project serves for Factory.<br />
<br />
By default new packages for Leap must either come from SLE or be accepted in Factory first.<br />
<br />
Preferably new packages should be introduced on the opensuse-factory list with a link to the submit request. A good introduction contains information on the state of the upstream project and how maintainable it is and what the purpose of having it in the distribution will be.<br />
<br />
Example of submitting from the Factory devel project:<br />
{{Shell|osc submitrequest -m 'Submitting Factory version of Salt for openSUSE Leap, see https://lists.opensuse.org/opensuse-factory/2015-07/msg00443.html ' systemsmanagement:saltstack/salt openSUSE:Leap:42.2}}<br />
<br />
It's also possible to submit from Factory but that requires extra hacks:<br />
{{Shell|osc submitrequest -m 'Submitting Salt for openSUSE Leap, see https://lists.opensuse.org/opensuse-factory/2015-07/msg00443.html ' openSUSE:Factory/salt openSUSE:Leap:42.2}}<br />
<br />
Because of bugs in OBS, <tt>~/.oscrc</tt> must have <tt>submitrequest_on_accept_action</tt> unset, and there must be no <tt>--cleanup</tt> nor <tt>--no-cleanup</tt> specified on the osc command line. Otherwise, OBS would return a permission error.<br />
<br />
The following example shows how to submit a package from SLE:<br />
{{Shell|osc submitrequest -m 'Submitting jakarta-commons-dbcp from SLE 12 to Leap' SUSE:SLE-12-SP2:GA/jakarta-commons-dbcp openSUSE:Leap:42.2}}<br />
<br />
If a package for Leap for whatever reason cannot be taken from either SLE or Factory the reason for that should be explained in the submit request.<br />
<br />
== How to upgrade a package in an openSUSE Leap release in development ==<br />
<br />
In general version updates of packages in minor Leap version upgrades (42.1 -> 42.2) are possible. The packager should carefully consider the pros and cons of such upgrades for the users though. Within a major version Leap is considered stable, so overly disruptive and incompatible changes are to be avoided.<br />
<br />
After careful consideration of the pros and cons the same process as with new packages applies. Ie packages must be accepted in Factory first.<br />
<br />
== How to add a new package to a released openSUSE Leap version ==<br />
<br />
''Get prior approval from the Maintenance team for the 42.1 target used below.''<br />
<br />
Again, a package must be accepted in Factory first before it can be considered for submission to Leap.<br />
<br />
{{Shell|osc submitrequest -m 'Submitting Salt for openSUSE Leap 42.1' openSUSE:Factory/salt openSUSE:Leap:42.1:Update}}<br />
<br />
For more complex cases and multiple dependent packages, start with:<br />
<br />
{{Shell|osc branch -M -N openSUSE:Leap:42.1:Update NEWPACKAGE}}<br />
<br />
<br />
[[ja:openSUSE:Leap_への貢献方法]]<br />
<br />
== Development Information ==<br />
<br />
=== Project Layout ===<br />
<br />
;openSUSE&#58;Leap&#58;42.2: packages with free software license [https://build.opensuse.org/project/show/openSUSE:Leap:42.2]<br />
;openSUSE&#58;Leap&#58;42.2&#58;NonFree: packages with non free licenses [https://build.opensuse.org/project/show/openSUSE:Leap:42.2:NonFree]<br />
;openSUSE&#58;Leap&#58;42.2&#58;Update: updates for packages with free software license [https://build.opensuse.org/project/show/openSUSE:Leap:42.2:Update]<br />
;openSUSE&#58;Leap&#58;42.2&#58;NonFree&#58;Updates: updates for packages with non free licenses [https://build.opensuse.org/project/show/openSUSE:Leap:42.2:NonFree:Update]<br />
<br />
==== Upstream Projects ====<br />
<br />
Many packages in openSUSE Leap 42.2 come from other projects. During the development phase release engineers may pull package updates from those.<br />
<br />
;SUSE&#58;SLE-12-*: SUSE Linux Enterprise packages: pulled automatically<br />
;openSUSE&#58;Leap&#58;42.1: Maintenance updates from previous release: pulled automatically<br />
;openSUSE&#58;Factory: Factory package updates: need to be submitted explicitly<br />
<br />
A [https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/00Meta/lookup.yml?expand=1 mapping file] specifies the origin of each package.<br />
<br />
=== RPM Distro Version Macros ===<br />
* suse_version 1315 for the full time life of SLE12 and openSUSE:Leap:42.x<br />
* additionally is_opensuse 1 for openSUSE:Leap:* to mark differences<br />
<br />
{| class="wikitable"<br />
|+RPM macros for SLE12 and openSUSE:Leap<br />
| <br />
|SLE12:GA<br />
|SLE12:SP1<br />
|SLE12:SP2<br />
|Leap 42.1<br />
|Leap 42.2<br />
|-<br />
|suse_version<br />
|1315<br />
|1315<br />
|1315<br />
|1315<br />
|1315<br />
|-<br />
|sle_version<br />
|120000<br />
|120100<br />
|120200<br />
|120100<br />
|120200<br />
|-<br />
|is_opensuse<br />
|undefined<br />
|undefined<br />
|undefined<br />
|1<br />
|1<br />
|}<br />
<br />
[[Category:Leap]]<br />
[[Category:42.1]]<br />
[[Category:42.2]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Backports_Package_Submission_Process&diff=84510openSUSE:Backports Package Submission Process2016-05-09T18:16:53Z<p>Okurz: /* Project Setup */ 'I.e.' is more readable with separating dots</p>
<hr />
<div>== Overview ==<br />
<br />
This page outlines the technical process of building and maintaining packages for the SLE Backports repos.<br />
<br />
== Project Setup ==<br />
<br />
Backported packages are built in the [https://build.opensuse.org/ openSUSE build service]<br />
<br />
The following targets exist:<br />
<br />
* [https://build.opensuse.org/project/show/openSUSE:Backports:SLE-12 openSUSE:Backports:SLE-12]<br />
<br />
The target project doesn't actually build the packages but behaves like an update project for released openSUSE distributions. I.e. the actual sources are built in so called "incident projects". The openSUSE maintenance team takes care of those incident projects.<br />
<br />
== Packager workflow ==<br />
<br />
=== Introducing a new package ===<br />
<br />
The Backports project only allows packages that are already accepted in Factory. The easiest way to submit the sources is to add the Backports project as build target in the devel project. The following snippet may be added to devel projects:<br />
<br />
<repository name="SLE_12"><br />
<path project="openSUSE:Backports:SLE-12" repository="standard"/><br />
<arch>x86_64</arch><br />
</repository><br />
<br />
After the package successfully built against this repo the package can be submitted, e.g.:<br />
<br />
osc sr devel:openSUSE:Factory hello openSUSE:Backports:SLE-12<br />
<br />
=== Branching existing package ===<br />
<br />
Just like with openSUSE maintenance a package can be branched directly from the destination project<br />
<br />
osc branch openSUSE:Backports:SLE-12 hello<br />
<br />
Alternatively, to automatically branch all maintained versions<br />
<br />
osc mbranch hello<br />
<br />
This command would set up a project that also contains all openSUSE versions of the same package so the maintainer can fix all instances at once.<br />
<br />
Note that the current policy requires that package sources for the Backports project and openSUSE Factory are identical.<br />
<br />
=== Maintenance Workflow ===<br />
<br />
After the packager filed a submit request (which will be converted by osc to a maintenance incident request) the requests are reviewed by automated review bots:<br />
<br />
* maintbot: checks if the submission was created by the package maintainer as defined in the devel project. maintbot will add the devel project as reviewer for submissions by non-maintainers.<br />
* factory-source: checks if the sources for submissions to the Backports project are actually accepted in factory. Rejects requests where this is not the case.<br />
<br />
After successful automated review the maintenance engineer takes over. If the request is ok he accepts it and therefore creates a maintenance incident. After the packages built successfully the maintenance engineer creates a release request. The release request in turn is checked again by factory-source.<br />
<br />
After the usual grace period for testing as used on openSUSE the maintenance engineer then accepts release requests to actually release the package.<br />
<br />
=== User Workflow ===<br />
<br />
The user may run the following command to add the Backports repo to the system:<br />
<br />
# zypper addrepo -fc http://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-12/standard/openSUSE:Backports:SLE-12.repo</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Backports_How_To_Use&diff=84509openSUSE:Backports How To Use2016-05-09T18:15:31Z<p>Okurz: fix typo "intstalled"</p>
<hr />
<div>== Overview ==<br />
<br />
This page describes how to use Backports repos on SUSE Linux Enterprise<br />
<br />
== Adding the repository ==<br />
<br />
The [http://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-12/standard/ repo] can be added using either yast or simply zypper as root:<br />
<br />
# zypper addrepo -fc http://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-12/standard/openSUSE:Backports:SLE-12.repo<br />
<br />
Now packages from the backports repo can be installed as usual using yast, zypper or packagekit.<br />
<br />
YaST/zypper may ask for the following gpg key to be imported:<br />
<br />
Key Name : openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org><br />
Key Fingerprint: 637B32FF 3D83F07A 7AE1C40A 9C214D40 65176565<br />
<br />
== Enable extra modules ==<br />
<br />
On a plain SLE 12 some packages may not install due to unresolvable dependencies. In such cases it may be necessary to enable additional modules like the Workstation Extension or SDK.</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:Remote_installation&diff=84494SDB:Remote installation2016-05-08T19:57:26Z<p>Okurz: /* External links */</p>
<hr />
<div>{{DEFAULTSORT:{{PAGENAME}}}}<br />
{{Installation_navbar}}<br />
{{Intro|This article covers the procedures and methods to install openSUSE on a remote machine.}}<br />
<br />
==Performing a Network-only installation==<br />
<br />
Sometimes it is necessary to upgrade a machine that is only reachable over the network. In openSUSE you have several possibilities to remotely run the installation program. These are:<br />
<br />
* [[openSSH]]<br />
* [[Portal:Remote_access|VNC]]<br />
* serial console<br />
<br />
This tutorial outline here how to install with openSSH. VNC is similar, and for serial console things are even easier. This tip is intended as a hint on how to get things done, not as an in-depth reference.<br />
<br />
{{Info|'''Note:''' On a hosted server, it could be wise to don't use the default boot for the install, install on an other partition than the actual running system and use [[Reboot_from_CLI_to_selective_partitions|grubonce]] to boot the install. If ever the install fail, the next reboot will reboot the default running system.}}<br />
<br />
----<br />
<br />
== Manual preparation ==<br />
=== Get the needed installation files ===<br />
<br />
What you need for a network install is to boot the installation kernel as well as the installation initrd on the remote computer. At the same time, you need to know about the IP-address that the computer will have. Lets suppose that you have a fixed IP-address. If you use dhcp, omit the network definitions and use the IP-address you get from your dhcp server.<br />
<br />
First, copy the kernel image and installation initrd to your <tt>/boot</tt> directory:<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://<path to openSUSE>/boot/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://<path to openSUSE>/boot/loader/initrd</nowiki><br />
<br />
==== For stable openSUSE release ====<br />
*Replace <tt><version></tt> by your openSUSE release (ie,<tt>11.2</tt>, ...).<br />
*Replace <tt><arch></tt> by your architecture (<tt>i386</tt> or <tt>x86_64</tt>).<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://download.opensuse.org/distribution/<version>/repo/oss/boot/<arch>/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://download.opensuse.org/distribution/<version>/repo/oss/boot/<arch>/loader/initrd</nowiki><br />
<br />
==== For latest Factory development code ====<br />
*Replace <tt><arch></tt> by your architecture (<tt>i386</tt> or <tt>x86_64</tt>).<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://download.opensuse.org/factory/repo/oss/boot/<arch>/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://download.opensuse.org/factory/repo/oss/boot/<arch>/loader/initrd</nowiki><br />
<br />
=== Configure GRUB ===<br />
Next, prepare your grub configuration to boot these images. If the ip adress of your computer is 192.168.10.10, the gateway to the internet is 192.168.10.1 and your root (/) partition is /dev/hda1, add a section like the following to '''/boot/grub/menu.lst''' :<br />
<br />
title Boot -- openSUSE 11.2<br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install noapic usessh=1 sshpassword="12345678" install=<nowiki>ftp://<path to openSUSE></nowiki> hostip=192.168.10.10 netmask=255.255.255.0 gateway=192.168.10.1 nameserver=192.168.10.1<br />
initrd /boot/initrd.install<br />
<br />
{{Info|'''Note:''' The password must be at least 8 characters long.}}<br />
{{Info|'''Note:''' Make sure the IP address is really available before reboot. Even local addresses may cause trouble if the target machine is in a larger network segment.}}<br />
<br />
Note that you must enter the IP-address in the path to openSUSE instead of the name if you do not provide a nameserver. Then make this 1st entry the default by changing menu.lst at the line <br />
<br />
default 0<br />
<br />
to reflect the section number of your entry.<br />
<br />
{{Info|'''Note:''' If you want to boot to another section temporarily, do not change the default. Instead use the command <tt>grubonce 0</tt>, where 0 is the number of your new section.}}<br />
<br />
After doing this, do a reboot.<br />
<br />
==== For stable openSUSE release ====<br />
*Replace <tt><version></tt> by your openSUSE release (ie,<tt>11.2</tt>, ...).<br />
<br />
title Boot -- openSUSE <version><br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install noapic usessh=1 sshpassword="12345645"<nowiki> install=http://download.opensuse.org/distribution/<version>/repo/oss/</nowiki> hostip=192.168.42.123/24 gateway=192.168.42.1 nameserver=192.168.42.1<br />
initrd /boot/initrd.install<br />
<br />
==== For latest Factory development release ====<br />
<br />
title Boot -- openSUSE Factory INSTALL<br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install usessh=1 sshpassword="12345678" install=<nowiki>http://download.opensuse.org/factory/repo/oss/</nowiki> hostip=192.139.88.209 netmask=255.255.255.0 gateway=192.139.88.254 nameserver=192.139.88.1<br />
initrd /boot/initrd.install<br />
<br />
Eventually, you may have to give the mirror IP.<br />
<br />
----<br />
<br />
== Automated preparation ==<br />
<br />
Downloading kernel and initrd as well as modifying the grub config can mostly be automated with the [https://github.com/lnussel/setupgrubfornfsinstall Setup GRUB for NFS install] script.<br />
<br />
----<br />
<br />
==Start the installation==<br />
<br />
The computer will start again after rebooting, but this time booting your installation image instead of the installed system. To reach the installation image, do a ssh to this system:<br />
<br />
ssh -X root@192.168.10.10<br />
<br />
and enter the password that was given in sshpassword (in the example above, this is "12345645", as 1-8 would be to obvious to phishers;) ). All you have to do now is start yast (or yast2 for graphical installation), and proceed as in a normal installation. <br />
<br />
{{Info|'''Note:''' During installation if you're disconnected before you have a chance to entering the root password, then reconnect after a few minutes and enter the given installation password that was set in the grub '''menu.lst''' file. After that you have to run '''/usr/lib/YaST2/startup/YaST2.ssh''' to continue the installation.}}<br />
<br />
----<br />
<br />
== Post-install ==<br />
After that you may have to run '''/usr/lib/YaST2/startup/YaST2.ssh''' to continue the installation.<br />
<br />
This may be missed, because it's only usefull to install X, but if not the starting process is somewhat broken.<br />
<br />
----<br />
==More information==<br />
<br />
The options that may be used at the kernel command line are summarized in either<br />
<tt>/usr/share/doc/packages/autoyast2/html/appendix.linuxrc.html</tt><br />
or<br />
<tt>/usr/share/doc/packages/linuxrc/linuxrc.html</tt>. Instead of using a colon (:) to separate the name and values (as used in a /info file), use an equal sign (=) when adding those options in the GRUB menu to the kernel command line. <tt>[[SDB:Linuxrc|Linuxrc]]</tt> always tries to find out as much information as possible about the computer, so if you don't provide network connection information, it will try to use dhcp to setup its network.<br />
<br />
----<br />
<br />
==See also==<br />
* [[SDB:Network installation|Network installation]]<br />
* [[openSSH]]<br />
* [[Portal:Remote_access|Remote access]]<br />
<br />
----<br />
<br />
==External links==<br />
*[https://github.com/lnussel/setupgrubfornfsinstall Setup GRUB for NFS install]<br />
<br />
<br />
[[Category:SDB:HOWTOs]]<br />
[[Category:SDB:Alternative installation]]<br />
[[Category:SDB:Remote access]]<br />
<br />
[[de:Netzwerkinstallation]]<br />
[[es:SDB:Instalación remota de openSUSE]]<br />
[[fr:SDB:Remote_installation]]<br />
[[it:SDB:Remote_installation]]<br />
[[nl:SDB:Remote_installation]]<br />
[[pt:SDB:Instalação remota]]<br />
[[ru:SDB:Удаленная установка]]<br />
[[zh:SDB:远程安装方式]]</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:Remote_installation&diff=84493SDB:Remote installation2016-05-08T19:53:53Z<p>Okurz: /* Automated preparation */ Use direct link to target instead of relying on redirect</p>
<hr />
<div>{{DEFAULTSORT:{{PAGENAME}}}}<br />
{{Installation_navbar}}<br />
{{Intro|This article covers the procedures and methods to install openSUSE on a remote machine.}}<br />
<br />
==Performing a Network-only installation==<br />
<br />
Sometimes it is necessary to upgrade a machine that is only reachable over the network. In openSUSE you have several possibilities to remotely run the installation program. These are:<br />
<br />
* [[openSSH]]<br />
* [[Portal:Remote_access|VNC]]<br />
* serial console<br />
<br />
This tutorial outline here how to install with openSSH. VNC is similar, and for serial console things are even easier. This tip is intended as a hint on how to get things done, not as an in-depth reference.<br />
<br />
{{Info|'''Note:''' On a hosted server, it could be wise to don't use the default boot for the install, install on an other partition than the actual running system and use [[Reboot_from_CLI_to_selective_partitions|grubonce]] to boot the install. If ever the install fail, the next reboot will reboot the default running system.}}<br />
<br />
----<br />
<br />
== Manual preparation ==<br />
=== Get the needed installation files ===<br />
<br />
What you need for a network install is to boot the installation kernel as well as the installation initrd on the remote computer. At the same time, you need to know about the IP-address that the computer will have. Lets suppose that you have a fixed IP-address. If you use dhcp, omit the network definitions and use the IP-address you get from your dhcp server.<br />
<br />
First, copy the kernel image and installation initrd to your <tt>/boot</tt> directory:<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://<path to openSUSE>/boot/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://<path to openSUSE>/boot/loader/initrd</nowiki><br />
<br />
==== For stable openSUSE release ====<br />
*Replace <tt><version></tt> by your openSUSE release (ie,<tt>11.2</tt>, ...).<br />
*Replace <tt><arch></tt> by your architecture (<tt>i386</tt> or <tt>x86_64</tt>).<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://download.opensuse.org/distribution/<version>/repo/oss/boot/<arch>/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://download.opensuse.org/distribution/<version>/repo/oss/boot/<arch>/loader/initrd</nowiki><br />
<br />
==== For latest Factory development code ====<br />
*Replace <tt><arch></tt> by your architecture (<tt>i386</tt> or <tt>x86_64</tt>).<br />
<br />
cd /boot<br />
wget --output-document=vmlinuz.install <nowiki>http://download.opensuse.org/factory/repo/oss/boot/<arch>/loader/linux</nowiki><br />
wget --output-document=initrd.install <nowiki>http://download.opensuse.org/factory/repo/oss/boot/<arch>/loader/initrd</nowiki><br />
<br />
=== Configure GRUB ===<br />
Next, prepare your grub configuration to boot these images. If the ip adress of your computer is 192.168.10.10, the gateway to the internet is 192.168.10.1 and your root (/) partition is /dev/hda1, add a section like the following to '''/boot/grub/menu.lst''' :<br />
<br />
title Boot -- openSUSE 11.2<br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install noapic usessh=1 sshpassword="12345678" install=<nowiki>ftp://<path to openSUSE></nowiki> hostip=192.168.10.10 netmask=255.255.255.0 gateway=192.168.10.1 nameserver=192.168.10.1<br />
initrd /boot/initrd.install<br />
<br />
{{Info|'''Note:''' The password must be at least 8 characters long.}}<br />
{{Info|'''Note:''' Make sure the IP address is really available before reboot. Even local addresses may cause trouble if the target machine is in a larger network segment.}}<br />
<br />
Note that you must enter the IP-address in the path to openSUSE instead of the name if you do not provide a nameserver. Then make this 1st entry the default by changing menu.lst at the line <br />
<br />
default 0<br />
<br />
to reflect the section number of your entry.<br />
<br />
{{Info|'''Note:''' If you want to boot to another section temporarily, do not change the default. Instead use the command <tt>grubonce 0</tt>, where 0 is the number of your new section.}}<br />
<br />
After doing this, do a reboot.<br />
<br />
==== For stable openSUSE release ====<br />
*Replace <tt><version></tt> by your openSUSE release (ie,<tt>11.2</tt>, ...).<br />
<br />
title Boot -- openSUSE <version><br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install noapic usessh=1 sshpassword="12345645"<nowiki> install=http://download.opensuse.org/distribution/<version>/repo/oss/</nowiki> hostip=192.168.42.123/24 gateway=192.168.42.1 nameserver=192.168.42.1<br />
initrd /boot/initrd.install<br />
<br />
==== For latest Factory development release ====<br />
<br />
title Boot -- openSUSE Factory INSTALL<br />
root (hd0,0)<br />
kernel /boot/vmlinuz.install usessh=1 sshpassword="12345678" install=<nowiki>http://download.opensuse.org/factory/repo/oss/</nowiki> hostip=192.139.88.209 netmask=255.255.255.0 gateway=192.139.88.254 nameserver=192.139.88.1<br />
initrd /boot/initrd.install<br />
<br />
Eventually, you may have to give the mirror IP.<br />
<br />
----<br />
<br />
== Automated preparation ==<br />
<br />
Downloading kernel and initrd as well as modifying the grub config can mostly be automated with the [https://github.com/lnussel/setupgrubfornfsinstall Setup GRUB for NFS install] script.<br />
<br />
----<br />
<br />
==Start the installation==<br />
<br />
The computer will start again after rebooting, but this time booting your installation image instead of the installed system. To reach the installation image, do a ssh to this system:<br />
<br />
ssh -X root@192.168.10.10<br />
<br />
and enter the password that was given in sshpassword (in the example above, this is "12345645", as 1-8 would be to obvious to phishers;) ). All you have to do now is start yast (or yast2 for graphical installation), and proceed as in a normal installation. <br />
<br />
{{Info|'''Note:''' During installation if you're disconnected before you have a chance to entering the root password, then reconnect after a few minutes and enter the given installation password that was set in the grub '''menu.lst''' file. After that you have to run '''/usr/lib/YaST2/startup/YaST2.ssh''' to continue the installation.}}<br />
<br />
----<br />
<br />
== Post-install ==<br />
After that you may have to run '''/usr/lib/YaST2/startup/YaST2.ssh''' to continue the installation.<br />
<br />
This may be missed, because it's only usefull to install X, but if not the starting process is somewhat broken.<br />
<br />
----<br />
==More information==<br />
<br />
The options that may be used at the kernel command line are summarized in either<br />
<tt>/usr/share/doc/packages/autoyast2/html/appendix.linuxrc.html</tt><br />
or<br />
<tt>/usr/share/doc/packages/linuxrc/linuxrc.html</tt>. Instead of using a colon (:) to separate the name and values (as used in a /info file), use an equal sign (=) when adding those options in the GRUB menu to the kernel command line. <tt>[[SDB:Linuxrc|Linuxrc]]</tt> always tries to find out as much information as possible about the computer, so if you don't provide network connection information, it will try to use dhcp to setup its network.<br />
<br />
----<br />
<br />
==See also==<br />
* [[SDB:Network installation|Network installation]]<br />
* [[openSSH]]<br />
* [[Portal:Remote_access|Remote access]]<br />
<br />
----<br />
<br />
==External links==<br />
*[http://www.suse.de/~lnussel/setupgrubfornfsinstall.html Setup GRUB for NFS install]<br />
<br />
<br />
[[Category:SDB:HOWTOs]]<br />
[[Category:SDB:Alternative installation]]<br />
[[Category:SDB:Remote access]]<br />
<br />
[[de:Netzwerkinstallation]]<br />
[[es:SDB:Instalación remota de openSUSE]]<br />
[[fr:SDB:Remote_installation]]<br />
[[it:SDB:Remote_installation]]<br />
[[nl:SDB:Remote_installation]]<br />
[[pt:SDB:Instalação remota]]<br />
[[ru:SDB:Удаленная установка]]<br />
[[zh:SDB:远程安装方式]]</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:KDE_repositories&diff=74248SDB:KDE repositories2016-02-19T16:54:15Z<p>Okurz: Fix two tiny grammar issues, see https://owl.english.purdue.edu/owl/resource/591/01/ about "a" vs. "an"</p>
<hr />
<div>{{Repositories navbar}}<br />
{{Intro|This page lists and describes the available repositories containing KDE software and provides links. Most of them are maintained and supported by the openSUSE KDE Community team.}}<br />
<br />
{{Warning|Do not mix stable with unstable repositories. Doing so is not supported and is prone to put your system in an inconsistent state.}}<br />
{{Warning|Be aware that the KDE:Current repositories, currently providing KDE Applications 14.12.3, will no longer be updated.}}<br />
<br />
==Background==<br />
The setup of the repositories is based on the distinction between three groups of packages, namely:<br />
<br />
* KDE Framework/Plasma packages. This group contains the Framework libraries and the Plasma Workspace.<br />
* KDE Application packages. This group contains the KDE Application releases, like Dolphin, Kdenlive, KTP, Konqueror, etc<br />
* Packages for KDE/Qt based applications that are released independently from the major KDE software releases. This group contains applications that are based on the KDE or Qt libraries, like Amarok, Konversation, Quassel, etc<br />
<br />
==Maintenance Updates==<br />
Since openSUSE 12.3, the openSUSE KDE Community team has been following a maintenance procedure where KDE packages that were shipped with the distribution are updated through the maintenance track with minor updates. This to ensure that users have the latest available bug fixes for their KDE release. This was reflected in the following maintenance tracks:<br />
<br />
openSUSE 13.1: Shipped with KDE SC 4.11.2 and maintenance updates have been provided up to KDE SC 4.11.5.<br />
<br />
openSUSE 13.2: Shipped with KDE SC 4.14.2 and maintenance updates have been provided up to KDE SC 4.14.4. <br />
<br />
openSUSE Leap 42.1: Shipped with Plasma 5.4.2, Applications 15.08 (with a couple of exceptions) and KDE Frameworks 5.15. <br />
<br />
As long as the underlying stack is compatible, the plan is to provide updates through the maintenance channel.<br />
<br />
==What's available==<br />
Based on what has been indicated above, the following repositories have been made available to the openSUSE users. <br />
<br />
===For Users===<br />
*'''Updated KDE Frameworks 5 and Plasma releases'''<br/>These are newer versions of the Framework libraries and Plasma Desktop as released by the KDE community, plus a number of openSUSE-specific patches. These are delivered for at least the latest openSUSE release and Tumbleweed. Depending on available versions of dependencies, these updates could also be delivered for older, but supported, openSUSE versions.<br />
<br />
*'''Updated KDE Application releases'''<br/>These are newer versions of the KDE Applications as released by the KDE community, plus a number of openSUSE-specific patches. These are delivered for at least the latest openSUSE release and Tumbleweed. Depending on available versions of dependencies, these updates could also be delivered for older, but supported, openSUSE versions. <br />
<br />
*'''KDE Extra'''<br/>Newer versions of individual applications, KDE/Qt based (but not part of Frameworks, Plasma, or Application releases), which have been packaged for released distributions. These newer versions are building against diverse targets. This repository is maintained by the wider openSUSE community.<br />
<br />
*'''Live Media'''<br/>The openSUSE KDE Community team prepares a weekly update of the new developments, by providing a live Media (which also can be installed) based on the KDE Unstable repositories. openSUSE Argon is based on top of openSUSE Leap and openSUSE Krypton is based on top of Tumbleweed. These live Medias would allow you to see what the future release of Frameworks, Plasma and Applications will look like. Be aware that these live Medias could be rough around the edges and will only contain partial translations. Bug reports for these medias are only accepted in case a user believes software is missing or that the media does not work.<br />
<br />
===For Contributors===<br />
*'''KDE Unstable Repositories'''<br/>Packages based on git snapshots of the above mentioned packages/releases. These are only built for the latest openSUSE release and Tumbleweed due to possible dependencies on newer packages. <br />
<br />
----<br />
<br />
==I want to...==<br />
<br />
===[[#Updated KDE Applications only|Get the latest KDE Application releases]]===<br />
===[[#KDE Frameworks 5 & Plasma 5|Get the latest KDE Framework and Plasma 5 releases]]===<br />
===[[#Unstable Frameworks, Plasma and Applications|Help develop or test the next generation of KDE software]]===<br />
===[[#Unstable live media|Get the latest live media to explore the upcoming Plasma releases]]===<br />
===[[#Last KDE SC 4 release|Get the latest KDE SC 4 Release for openSUSE 13.1 or SLE 12]]===<br />
===[[#Qt|Try a newer Qt snapshot]]===<br />
===[[https://en.opensuse.org/KDE3 Get the latest KDE 3 Packages]]===<br />
<br />
----<br />
<br />
==Updated KDE Applications only==<br />
If you're using the official, supported and tested core KDE packages provided with the distribution, there are these additional repositories available for your consideration. Factory/Tumbleweed users do not need (but can, if they want) to use it, as new releases are submitted to Tumbleweed as soon as they're available, and are usually pushed to standard repositories in a matter of days. This repository also serves as a development project for openSUSE:Factory.<br />
<br />
{{Warning|Most of these packages are KDE Frameworks 5 based and will pull in additional libraries. Also, newer KF5 based applications will '''overwrite''' their 4.x counterparts.}}<br />
<br />
{{Version note|Leap 42.1|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.1/<br/><br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/<br />
}}<br />
{{Version note|13.2|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_13.2/<br/><br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_13.2/<br />
}}<br />
{{Version note|Tumbleweed|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/<br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Factory_standard/<br />
}}<br />
<br />
----<br />
<br />
==KDE Frameworks 5 & Plasma 5==<br />
{{Info|Do not use GDM.}}<br />
<br />
Releases of KDE Frameworks 5 and Plasma 5.<br />
Since openSUSE 13.2, KDE Frameworks 5(KF5) libraries, and Plasma 5 components are part of the standard distribution repositories.<br />
If you want test and/or use the latest release, you can use this repo.<br />
Factory/Tumbleweed users do not need (but can, if they want) to use it, as new releases are submitted to Tumbleweed as soon as they're available, and are usually published to standard repositories in a matter of days.<br />
<br />
'''Note for openSUSE 13.2 users''': KF5 packages are coinstallable with KDE SC 4 and Qt 4, while Plasma 5 packages '''are not''' for the most part and will remove certain KDE4 packages (in particular, Plasma Workspace 4.x and Plasma 5 cannot coexist). This repository serves also as a development project for openSUSE:Factory.<br />
<br />
To add a Plasma 5 session to your display manager, install the '''plasma5-session''' package.<br />
Before trying out Plasma 5, please read known issues:<br />
https://community.kde.org/Plasma/5.4_Errata<br />
<br />
{{Version note|Tumbleweed|<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Factory/<br />
}}<br />
{{Version note|Leap 42.1|<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_42.1/<br />
}}<br />
{{Version note|13.2|<br />
*'''Qt 5:''' http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.2/<br/><br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_13.2/<br />
}}<br />
{{Version note|13.1|<br />
*'''Qt 5:''' http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.1/<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_13.1/<br />
}}<br />
----<br />
<br />
==Unstable Frameworks, Plasma and Applications==<br />
<br />
These repositories contain daily builds of KDE Frameworks 5, Plasma 5 and KF5-based applications from trunk. Due to the requirements/dependencies, we can only provide packages for the latest openSUSE release and Tumbleweed/Factory.<br />
<br />
Given the rapid pace of development, use of these repositories is '''not recommended''' on production systems. They are mostly meant for developers or early testers.<br />
<br />
{{Warning|Due to the nature of these repository the usage is at your own risk: do not report bugs against packages. However, please file bugs upstream with KDE if you find bugs in the software.}}<br />
{{Warning|Not all the KF5 applications are ready to receive bug reports. Always enquire with upstream KDE first if you use any of these repositories and want to submit a bug report to KDE.}}<br />
<br />
{{Warning|In order to prevent issues due to dependencies, all four repositories should be added at the same time.}}<br />
<br />
{{Version note|Tumbleweed|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Factory/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Factory/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_Factory/<br />
}}<br />
<br />
{{Version note|Leap 42.1|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Leap_42.1/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Leap_42.1/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Leap_42.1/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Extra_openSUSE_Leap_42.1/<br />
}}<br />
<br />
{{Version note|13.2|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_13.2/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_13.2/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_13.2/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_13.2/<br />
}}<br />
<br />
----<br />
<br />
==Unstable live media==<br />
<br />
The live media comes in two shapes. Argon is based on openSUSE Leap and Krypton is based on openSUSE Tumbleweed. Both offers the same KDE Frameworks, Plasma and KDE Applications packages. These packages are based on the KDE:Unstable repositories which are build from snapshots of the upstream git repositories. <br />
<br />
The live Medias are refreshed every week during the weekend and offer a chance to see and explore the latest updates. The medias are also offering a Live installer, which will install the live image on a hard disk and will automatically install the KDE:Unstable repositories for YaST/zypper, so that the installation is being kept up-to-date. Be aware that packages in the unstable repositories are rebuild on almost a daily basis and that breakage could occur.<br />
<br />
The live medias can be found here: http://download.opensuse.org/repositories/KDE:/Medias/images/iso/<br />
<br />
----<br />
<br />
==Last KDE SC 4 release==<br />
<br />
The last release of Plasma 4 and KDE Applications 14.12.3. Use this repository, if you want to have the version of the KDE Software Compilation 4.<br />
<br />
'''The KDE 4 packages for openSUSE 13.2 has been updated as part of our maintenance updates. At this moment there will be no more updates for KDE 4 given that Plasma 5 is the main focus for upstream development.''' <br />
<br />
{{Warning|With the update to KDE Applications 14.12.3, the KDE:Current repository will not receive any further updates as that newer releases are moving to KDE Framework based applications.}}<br />
<br />
{{Warning|Remove all repos from the ''[[#Updated applications only|Updated Apps only]]'' section if you are going to use KDE:Current.}}<br />
<br />
{{Version note|13.1|<br />
*'''KDE SC packages:''' http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/<br/><br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/KDE_Current_openSUSE_13.1/<br />
}}<br />
<br />
{{Version note|SLE12|<br />
*'''KDE SC packages:''' http://download.opensuse.org/repositories/KDE:/Current/SLE_12/<br/><br />
}}<br />
<br />
----<br />
<br />
==Qt==<br />
{{Warning|You do not need to add these if you are using the KDE repositories listed above. The repositories already include the correct Qt packages.}}<br />
<br />
<br />
===Qt 4 release===<br />
Qt 4.x.x version that is currently being considered most stable while being reasonably recent. Usually not needed.<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_Factory/}}<br />
{{Version note|SLE12|http://download.opensuse.org/repositories/KDE:/Qt/SLE_12/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_13.1/}}<br />
<br />
<br />
===Qt 5 release===<br />
Latest stable Qt5 release (currently 5.5.1)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Factory/}}<br />
{{Version note|SLE12|http://download.opensuse.org/repositories/KDE:/Qt5/SLE_12/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.1/}}<br />
<br />
<br />
=== Qt 5.4 Development Snapshots ===<br />
For developers only<br />
These snapshots are from the Qt git repository, dev branch (not yet functional)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_Factory/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_13.1/}}<br />
<br />
<br />
=== Qt 5.5 Development Snapshots ===<br />
For developers only<br />
These snapshots are from the Qt git repository, dev branch (not yet functional)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Factory/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_13.2/}}<br />
<br />
----<br />
<br />
==See also==<br />
*[[SDB:Vendor change update|Vendor change update]]<br />
*[[Package repositories]]<br />
*[[Additional package repositories]]<br />
*[[SDB:Add package repositories|Add package repositories]]<br />
<br />
[[Category:KDE]]<br />
[[Category:Repositories]]<br />
<br />
[[de:KDE_Repositorys]]<br />
[[es:Repositorios de KDE]]<br />
[[fr:Dépôts_KDE]]<br />
[[it:SDB:KDE repositories]]<br />
[[nl:KDE repositories]]<br />
[[ru:SDB:Репозитории KDE]]<br />
[[ja:SDB:KDE リポジトリ]]<br />
[[zh:KDE 软件源]]</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:KDE_repositories&diff=74246SDB:KDE repositories2016-02-19T16:51:08Z<p>Okurz: fix typos</p>
<hr />
<div>{{Repositories navbar}}<br />
{{Intro|This page lists and describes the available repositories containing KDE software and provides links. Most of them are maintained and supported by the openSUSE KDE Community team.}}<br />
<br />
{{Warning|Do not mix stable with unstable repositories. Doing so is not supported and is prone to put your system in an inconsistent state.}}<br />
{{Warning|Be aware that the KDE:Current repositories, currently providing KDE Applications 14.12.3, will no longer be updated.}}<br />
<br />
==Background==<br />
The setup of the repositories is based on the distinction between three groups of packages, namely:<br />
<br />
* KDE Framework/Plasma packages. This group contains the Framework libraries and the Plasma Workspace.<br />
* KDE Application packages. This group contains the KDE Application releases, like Dolphin, Kdenlive, KTP, Konqueror, etc<br />
* Packages for KDE/Qt based applications that are released independently from the major KDE software releases. This group contains applications that are based on the KDE or Qt libraries, like Amarok, Konversation, Quassel, etc<br />
<br />
==Maintenance Updates==<br />
Since openSUSE 12.3, the openSUSE KDE Community team has been following a maintenance procedure where KDE packages that were shipped with the distribution are updated through the maintenance track with minor updates. This to ensure that users have the latest available bug fixes for their KDE release. This was reflected in the following maintenance tracks:<br />
<br />
openSUSE 13.1: Shipped with KDE SC 4.11.2 and maintenance updates have been provided up to KDE SC 4.11.5.<br />
<br />
openSUSE 13.2: Shipped with KDE SC 4.14.2 and maintenance updates have been provided up to KDE SC 4.14.4. <br />
<br />
openSUSE Leap 42.1: Shipped with Plasma 5.4.2, Applications 15.08 (with a couple of exceptions) and KDE Frameworks 5.15. <br />
<br />
As long as the underlying stack is compatible, the plan is to provide updates through the maintenance channel.<br />
<br />
==What's available==<br />
Based on what has been indicated above, the following repositories have been made available to the openSUSE users. <br />
<br />
===For Users===<br />
*'''Updated KDE Frameworks 5 and Plasma releases'''<br/>These are newer versions of the Framework libraries and Plasma Desktop as released by the KDE community, plus a number of openSUSE-specific patches. These are delivered for at least the latest openSUSE release and Tumbleweed. Depending on available versions of dependencies, these updates could also be delivered for older, but supported, openSUSE versions.<br />
<br />
*'''Updated KDE Application releases'''<br/>These are newer versions of the KDE Applications as released by the KDE community, plus a number of openSUSE-specific patches. These are delivered for at least the latest openSUSE release and Tumbleweed. Depending on available versions of dependencies, these updates could also be delivered for older, but supported, openSUSE versions. <br />
<br />
*'''KDE Extra'''<br/>Newer versions of individual applications, KDE/Qt based (but not part of Frameworks, Plasma, or Application releases), which have been packaged for released distributions. These newer versions are building against diverse targets. This repository is maintained by the wider openSUSE community !!<br />
<br />
*'''Live Media'''<br/>The openSUSE KDE Community team prepares a weekly update of the new developments, by providing a live Media (which also can be installed) based on the KDE Unstable repositories. openSUSE Argon is based on top of openSUSE Leap and openSUSE Krypton is based on top of Tumbleweed. These live Medias would allow you to see what the future release of Frameworks, Plasma and Applications will look like. Be aware that these live Medias could be rough around the edges and will only contain partial translations. Bug reports for these medias are only accepted in case an user believes software is missing or that the media does not work.<br />
<br />
===For Contributors===<br />
*'''KDE Unstable Repositories'''<br/>Packages based on git snapshots of the above mentioned packages/releases. These are only built for the latest openSUSE release and Tumbleweed due to possible dependencies on newer packages. <br />
<br />
----<br />
<br />
==I want to...==<br />
<br />
===[[#Updated KDE Applications only|Get the latest KDE Application releases]]===<br />
===[[#KDE Frameworks 5 & Plasma 5|Get the latest KDE Framework and Plasma 5 releases]]===<br />
===[[#Unstable Frameworks, Plasma and Applications|Help develop or test the next generation of KDE software]]===<br />
===[[#Unstable live media|Get the latest live media to explore the upcoming Plasma releases]]===<br />
===[[#Last KDE SC 4 release|Get the latest KDE SC 4 Release for openSUSE 13.1 or SLE 12]]===<br />
===[[#Qt|Try a newer Qt snapshot]]===<br />
===[[https://en.opensuse.org/KDE3 Get the latest KDE 3 Packages]]===<br />
<br />
----<br />
<br />
==Updated KDE Applications only==<br />
If you're using the official, supported and tested core KDE packages provided with the distribution, there are these additional repositories available for your consideration. Factory/Tumbleweed users do not need (but can, if they want) to use it, as new releases are submitted to Tumbleweed as soon as they're available, and are usually pushed to standard repositories in a matter of days. This repository also serves as a development project for openSUSE:Factory.<br />
<br />
{{Warning|Most of these packages are KDE Frameworks 5 based and will pull in additional libraries. Also, newer KF5 based applications will '''overwrite''' their 4.x counterparts.}}<br />
<br />
{{Version note|Leap 42.1|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.1/<br/><br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/<br />
}}<br />
{{Version note|13.2|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_13.2/<br/><br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_13.2/<br />
}}<br />
{{Version note|Tumbleweed|<br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/<br />
*'''Applications:''' http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Factory_standard/<br />
}}<br />
<br />
----<br />
<br />
==KDE Frameworks 5 & Plasma 5==<br />
{{Info|Do not use GDM.}}<br />
<br />
Releases of KDE Frameworks 5 and Plasma 5.<br />
Since openSUSE 13.2, KDE Frameworks 5(KF5) libraries, and Plasma 5 components are part of the standard distribution repositories.<br />
If you want test and/or use the latest release, you can use this repo.<br />
Factory/Tumbleweed users do not need (but can, if they want) to use it, as new releases are submitted to Tumbleweed as soon as they're available, and are usually published to standard repositories in a matter of days.<br />
<br />
'''Note for openSUSE 13.2 users''': KF5 packages are coinstallable with KDE SC 4 and Qt 4, while Plasma 5 packages '''are not''' for the most part and will remove certain KDE4 packages (in particular, Plasma Workspace 4.x and Plasma 5 cannot coexist). This repository serves also as a development project for openSUSE:Factory.<br />
<br />
To add a Plasma 5 session to your display manager, install the '''plasma5-session''' package.<br />
Before trying out Plasma 5, please read known issues:<br />
https://community.kde.org/Plasma/5.4_Errata<br />
<br />
{{Version note|Tumbleweed|<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Factory/<br />
}}<br />
{{Version note|Leap 42.1|<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_42.1/<br />
}}<br />
{{Version note|13.2|<br />
*'''Qt 5:''' http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.2/<br/><br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_13.2/<br />
}}<br />
{{Version note|13.1|<br />
*'''Qt 5:''' http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.1/<br />
*'''KDE Frameworks 5:''' http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_13.1/<br />
}}<br />
----<br />
<br />
==Unstable Frameworks, Plasma and Applications==<br />
<br />
These repositories contain daily builds of KDE Frameworks 5, Plasma 5 and KF5-based applications from trunk. Due to the requirements/dependencies, we can only provide packages for the latest openSUSE release and Tumbleweed/Factory.<br />
<br />
Given the rapid pace of development, use of these repositories is '''not recommended''' on production systems. They are mostly meant for developers or early testers.<br />
<br />
{{Warning|Due to the nature of these repository the usage is at your own risk: do not report bugs against packages. However, please file bugs upstream with KDE if you find bugs in the software.}}<br />
{{Warning|Not all the KF5 applications are ready to receive bug reports. Always enquire with upstream KDE first if you use any of these repositories and want to submit a bug report to KDE.}}<br />
<br />
{{Warning|In order to prevent issues due to dependencies, all four repositories should be added at the same time.}}<br />
<br />
{{Version note|Tumbleweed|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Factory/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Factory/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_Factory/<br />
}}<br />
<br />
{{Version note|Leap 42.1|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Leap_42.1/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Leap_42.1/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Leap_42.1/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Extra_openSUSE_Leap_42.1/<br />
}}<br />
<br />
{{Version note|13.2|<br />
*'''Qt 5.5:''' http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_13.2/<br/><br />
*'''KDE Unstable Frameworks:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_13.2/<br />
*'''KDE Unstable Applications:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_13.2/<br />
*'''KDE Unstable Extra:''' http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_13.2/<br />
}}<br />
<br />
----<br />
<br />
==Unstable live media==<br />
<br />
The live media comes in two shapes. Argon is based on openSUSE Leap and Krypton is based on openSUSE Tumbleweed. Both offers the same KDE Frameworks, Plasma and KDE Applications packages. These packages are based on the KDE:Unstable repositories which are build from snapshots of the upstream git repositories. <br />
<br />
The live Medias are refreshed every week during the weekend and offer a chance to see and explore the latest updates. The medias are also offering a Live installer, which will install the live image on a hard disk and will automatically install the KDE:Unstable repositories for YaST/zypper, so that the installation is being kept up-to-date. Be aware that packages in the unstable repositories are rebuild on almost a daily basis and that breakage could occur.<br />
<br />
The live medias can be found here: http://download.opensuse.org/repositories/KDE:/Medias/images/iso/<br />
<br />
----<br />
<br />
==Last KDE SC 4 release==<br />
<br />
The last release of Plasma 4 and KDE Applications 14.12.3. Use this repository, if you want to have the version of the KDE Software Compilation 4.<br />
<br />
'''The KDE 4 packages for openSUSE 13.2 has been updated as part of our maintenance updates. At this moment there will be no more updates for KDE 4 given that Plasma 5 is the main focus for upstream development.''' <br />
<br />
{{Warning|With the update to KDE Applications 14.12.3, the KDE:Current repository will not receive any further updates as that newer releases are moving to KDE Framework based applications.}}<br />
<br />
{{Warning|Remove all repos from the ''[[#Updated applications only|Updated Apps only]]'' section if you are going to use KDE:Current.}}<br />
<br />
{{Version note|13.1|<br />
*'''KDE SC packages:''' http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/<br/><br />
*'''Extra:''' http://download.opensuse.org/repositories/KDE:/Extra/KDE_Current_openSUSE_13.1/<br />
}}<br />
<br />
{{Version note|SLE12|<br />
*'''KDE SC packages:''' http://download.opensuse.org/repositories/KDE:/Current/SLE_12/<br/><br />
}}<br />
<br />
----<br />
<br />
==Qt==<br />
{{Warning|You do not need to add these if you are using the KDE repositories listed above. The repositories already include the correct Qt packages.}}<br />
<br />
<br />
===Qt 4 release===<br />
Qt 4.x.x version that is currently being considered most stable while being reasonably recent. Usually not needed.<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_Factory/}}<br />
{{Version note|SLE12|http://download.opensuse.org/repositories/KDE:/Qt/SLE_12/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_13.1/}}<br />
<br />
<br />
===Qt 5 release===<br />
Latest stable Qt5 release (currently 5.5.1)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Factory/}}<br />
{{Version note|SLE12|http://download.opensuse.org/repositories/KDE:/Qt5/SLE_12/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_13.1/}}<br />
<br />
<br />
=== Qt 5.4 Development Snapshots ===<br />
For developers only<br />
These snapshots are from the Qt git repository, dev branch (not yet functional)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_Factory/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_13.2/}}<br />
{{Version note|13.1|http://download.opensuse.org/repositories/KDE:/Qt54/openSUSE_13.1/}}<br />
<br />
<br />
=== Qt 5.5 Development Snapshots ===<br />
For developers only<br />
These snapshots are from the Qt git repository, dev branch (not yet functional)<br />
{{Version note|Factory|http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Factory/}}<br />
{{Version note|13.2|http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_13.2/}}<br />
<br />
----<br />
<br />
==See also==<br />
*[[SDB:Vendor change update|Vendor change update]]<br />
*[[Package repositories]]<br />
*[[Additional package repositories]]<br />
*[[SDB:Add package repositories|Add package repositories]]<br />
<br />
[[Category:KDE]]<br />
[[Category:Repositories]]<br />
<br />
[[de:KDE_Repositorys]]<br />
[[es:Repositorios de KDE]]<br />
[[fr:Dépôts_KDE]]<br />
[[it:SDB:KDE repositories]]<br />
[[nl:KDE repositories]]<br />
[[ru:SDB:Репозитории KDE]]<br />
[[ja:SDB:KDE リポジトリ]]<br />
[[zh:KDE 软件源]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Packaging_Patches_guidelines&diff=73630openSUSE:Packaging Patches guidelines2016-01-18T10:55:51Z<p>Okurz: Add "bsc#"</p>
<hr />
<div>{{Packaging_docnav}}<br />
{{Intro|Packagers deal with lots of packages, and lots of patches inside those packages. These need to be marked in the .spec files with a well-known format to be able to run automatic tools on them, in order to generate reports, patch counts and other interesting information. They also need to be named consistently.}}<br />
<br />
== Patch life cycle ==<br />
Patches need to be added to packages for various reasons and it is important that the life cycle of a patch is well-defined. This helps in preventing that patches get "lost" and nobody knows why and when it was removed. The life cycle is defined in these simple steps:<br />
* Patch added to the package<br />
* Patch is modified (functional/rebased)<br />
* Patch is disabled (but not deleted)<br />
* Patch removed from the package<br />
<br />
The middle stages of the patch life cycle are optional and not every patch will live through them.<br />
<br />
Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. This is only for the benefit of human readers, so does not need to be in a strict machine-parseable format; here are some examples of the suggested format:<br />
* Add package-awesomeness.patch: Makes package awesome<br />
* Drop package-awesomeness.patch: Upstream made it even more awesome.<br />
* Disable package-awesomeness.patch: Testing if users can live without awesomeness<br />
* Rebase package-awesomeness.patch to apply to the new version.<br />
<br />
== Upstream policy ==<br />
<br />
There are a handful of packages where the Build Service-level maintainer(s) is/are the same person or group that runs upstream, so that it makes more sense to just submit to upstream instead.<br />
<br />
A BS-level package maintainer may request that patches not specific to building for openSUSE should always be sent upstream first for sanity checking and validation, before such patch is to be considered for inclusion in the Build Service package. A simple mention of ''Upstream First'' in the specfile will suffice; the proposed location would be right above the first "<tt>Patch:</tt>" line. If there is no <tt>Patch</tt> line yet, right below the last "<tt>Source:</tt>" line would be a good place, since <tt>Patch</tt>es often follow <tt>Source</tt>s.<br />
<br />
The benefit is that the maintainers will not need to extract patches out of the BS, which can a problem because some BS-level patches are often notoriously underdocumented, including description and/or metadata. With an upstream submission, this problem will be resolved upon contact. Since the maintainer is the same at both levels, they also know better of the potential caveats of an older version included in the BS.<br />
<br />
Examples for packages where UF is desired are for example those that are "home" to (open)SUSE: yast, zypp, SuSEfirewall, and so on. But there are also packages that do not directly relate to SUSE and which still request UF.<br />
<br />
== Patch markup (also called "Tagging patches") ==<br />
<br />
To facilitate the use of automatic tools &mdash; and to help future packagers &mdash;, we have agreed on using the following categories for our patches:<br />
<br />
* Fixes: these are normal fixes and are divided into two categories:<br />
** Fixes for openSUSE-specific things, that upstream maintainers will not be interested in.<br />
** Fixes for SLE-specific things, that upstream maintainers will not be interested in and that are not needed in openSUSE.<br />
** Fixes for the upstream sources that should be upstreamed.<br />
* Features: new features added to the packages, also divided into two categories:<br />
** Features for openSUSE-specific things (AppArmor integration, for instance) with no interest for upstream maintainers.<br />
** Features for SLE-specific things with no interest for upstream maintainers or openSUSE.<br />
** Features that should be upstreamed. Whenever we write this kind of new feature, it is important to coordinate with upstream maintainers. That way, we can develop something that will be accepted upstream without changes. Once a feature is finished, it is a lot of work to rework it to be acceptable to upstream maintainers. As such, it is better to know from the beginning exactly what upstream maintainers would expect.<br />
<br />
=== Type 1: minimal single-line comment in spec file ===<br />
<br />
To mark our patches to follow this convention, we have came up with a ''standard'' to mark them in the .spec file, following the format below:<br />
# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch1: fix-for-opensuse-specific-things.patch<br />
# PATCH-FIX-SLE fix-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch2: fix-for-sle-specific-things.patch<br />
# PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch bnc#<VAR >123456</VAR ><br />
Patch3: fix-for-upstream-sources.patch<br />
# PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch4: feature-for-opensuse-specific-things.patch<br />
# PATCH-FEATURE-SLE feature-for-sle-specific-things.patch bnc#<VAR >123456</VAR ><br />
Patch5: feature-for-sle-specific-things.patch<br />
# PATCH-FEATURE-UPSTREAM feature-for-upstream.patch bnc#<VAR >123456</VAR ><br />
Patch6: feature-for-upstream.patch<br />
<br />
Special case: we often have patches that get commented out temporarily because they failed to apply to the latest sources, and the patches need to be rebased. Do not comment out the patch's declaration, but do comment out its application. When marking a patch as needing a rebase, it is a good idea to preserve its old tag.<br />
<br />
# PATCH-NEEDS-REBASE old-patch.patch bnc#<VAR >123456</VAR > -- Does something old. Was: PATCH-FEATURE-OPENSUSE<br />
Patch7: old-patch.patch<br />
[...]<br />
# %patch7<br />
<br />
<br />
Finally, we include e-mail addresses so that it will be easier to figure out who wrote a patch if we have questions later, and free-form comments after " -- ".<br />
<br />
That is:<br />
# PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} ''name-of-file.patch'' bnc#<VAR >[0-9]*</VAR > <VAR >you</VAR >@<VAR >example.com</VAR > -- ''this patch makes things totally awesome''<br />
If there are related bugs in [http://bugzilla.novell.com Novell] or other bugzillas, please add them, it will help us to get more accurate information. If there are two or more available then it's preferable to list both (or more).<br />
<br />
In general, the bugzilla field is not required on new patches. For patches to released packages that will go out as updates, a bugzilla entry (BNC#) for the overall update in the changes file is required. If appropriate, the patch description should also include it.<br />
<br />
The primary use case of the patch field should be references to<br />
'''upstream''' bug trackers in case of PATCH-*-UPSTREAM patches, such<br />
patches should be submitted upstream first and then referenced in the<br />
patch tag. That helps a lot to keep track of patches, it makes it easy to<br />
determine which patches are still needed on version updates if<br />
upstream references the bug numbers in their changelog or release<br />
notes. Of course if there is already a corresponding bnc# bug<br />
open it should be referenced as well.<br />
<br />
You can find the current set of abbreviations at the end of this document. We can also define more abbreviations later if and when they prove necessary.<br />
<br />
Some patches fix bugs that are not explicitly recorded anywhere. The right thing to do in this case requires some judgment on the part of the packager, but here are some ideas:<br />
<br />
* If a release is imminent, create a bug for it. This is usually a requirement, and even if it were not, it is still the right thing to do.<br />
* If a release is a long way off and the bug has already been fixed upstream, note in the comment that it is already fixed in the <ABBR >SVN</ABBR > (or wherever) and the patch will go away when we next upgrade.<br />
<br />
=== Type 2: Complete Information provided in patch ===<br />
<br />
The previous ''standard'' lacks the most important part of a patch: a description why it is needed or desired in the first place. Furthermore, the state of the patch (upstream or opensuse-specific, fix or feature, etc.) is disjoined from the actual patch.<br />
<br />
The patches in the openSUSE kernel packages have traditionally used a form of tagging where metadata is directly attached to where it is needed — in the patch file itself. This facilitates submission of patches to upstream, as the description cannot be accidentally omitted, and the Git SCM (where used) knows to retain the metadata on import. Conversely, extraction of patches from Git repos also yields single files.<br />
<br />
Patch files are to follow a scheme of "<tt>key: value</tt>" pairs and a description, optionally with a diffstat, prepended to the actual hunks. Example.<br />
<br />
From: Random J Developer <email@example.org><br />
Date: 2012-07-28 01:28:22 +0200<br />
Subject: input: add Acer Aspire 5710 to nomux blacklist<br />
References: bnc#404881<br />
Upstream: submitted<br />
<br />
Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad misbehaves.<br />
<br />
---<br />
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++<br />
1 file changed, 7 insertions(+)<br />
<br />
--- a/drivers/input/serio/i8042-x86ia64io.h<br />
+++ b/drivers/input/serio/i8042-x86ia64io.h<br />
@@ -371,6 +371,13 @@ static const struct dmi_system_id __init<br />
[...]<br />
<br />
It is advised to use e.g. Quilt which retains descriptions on refresh. `<tt>quilt ref --sort --diffstat -p1</tt>` creates/refreshes such patches, sorted, with a diffstat and in the wanted -p1 format.<br/><br />
Common fields encountered:<br />
<br />
* '''From:''' shall specify the e-mail address of the original author of the patch.<br />
* '''Date:''' when this patch was first created. Preferably an ISO-8601 timestamp with timezone. If a new patch was just created and has none, you can use `<tt>stat your.patch</tt>` to determine a timestamp.<br />
* '''References:''' links to mailing list posts, bugzillas, etc. No fixed format, though URLs are preferred for they are easy to copy&paste into the browser. See the below section “[[#Current set of abbreviations]]” for details.<br />
* '''Upstream:''' the disposition of the patch. No fixed format, though common options are “never”/“no” (openSUSE-specific), “to be done” (tbd), “sent”/“submitted” (sent to upstream developers; provide Reference if possible), “merged” (upstream has accepted it; provide Reference if possible) and “dead” (no activity in upstream project).<br />
* '''Subject:''' A short one-line summary of the patch.<br />
<br />
'''Patches are to provide a description.''' The description shall describe why it is needed. Be as thorough as you like, because it will influence the decision what a different developer should do with the patch should it not apply anymore. The three questions “what command did you execute?”, “what did you observe?”, “what did you expect to see instead?” can give some guidance. If a related error message is available, e.g. when creating a patch to fix a syntactical error in a source file that causes the compilation to abort, it should be included, trimmed to the important parts. Furthermore, a summary on the how the solution is implemented can help readers grok larger patches.<br />
<br />
Reading material (from the mailing lists) that shows the need for this kind of tagging: [http://lists.opensuse.org/opensuse-factory/2012-08/msg00683.html (1)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00719.html (2)] [http://lists.opensuse.org/opensuse-factory/2012-08/msg00749.html (3)]<br />
<br />
== Patch naming ==<br />
<br />
All new patches should end with the extension '.patch'.<br />
<br />
Whether a patch's name should start with the name of the package it applies to is a matter of debate or style. When in doubt, follow the convention used in the package you are hacking on.<br />
<br />
Do '''NOT''' use <code>%{version}</code> macro in <code>Patch:</code> line, specify the version by hand. Using the macro:<br />
* causes lots of renames on version update<br />
* makes it easy to overlook patches that are no longer needed<br />
* makes it hard to determine when the patch was touch for the last time<br />
* makes it easy to find out when the patch broke (package archaelogy)<br />
<br />
An exception to this exists: patches that fix warnings that the compiler emits due to bogus code are frequently named <tt>abuild.patch</tt>.<br />
<br />
The preferred patchlevel is <tt>-p1</tt> as it makes importing using tools like ''quilt'' more straightforward.<br />
<br />
----<br />
== Current set of abbreviations ==<br />
To avoid confusion and double burden, referencing to other bugzillas is allowed. Here are some shortcuts for often used bugzillas, which should be added before the "#" of the bugzilla number. Note there is no whitespace between the shortcut and the bugzilla number.<br />
<br />
{| border="1" <br />
!Shortcut<br />
!Bugzilla-URL<br />
!Example<br />
|-<br />
| '''openSUSE Bug tracker'''<br />
| http://bugzilla.opensuse.org/show_bug.cgi?id=123456<br />
| (boo#123456)<br />
|-<br />
| Apache Software Foundation<br />
| https://issues.apache.org/bugzilla/<br />
| (pr#37770)<br />
|-<br />
| Boost<br />
| https://svn.boost.org/trac/boost/report<br />
| (boost#123456)<br />
|-<br />
| Ceph bug tracker<br />
| http://tracker.ceph.com/<br />
| (ceph#123456)<br />
|-<br />
| Claws Mail<br />
| http://www.thewildbeast.co.uk/claws-mail/bugzilla/<br />
| (claws#123456)<br />
|-<br />
| CVE entries (please add the number, even if there is an additional bugzilla for it)<br />
| http://cve.mitre.org<br />
| (CVE-2009-0067)<br />
|-<br />
| CPAN Public Bug Tracker<br />
| http://rt.cpan.org/Public/<br />
| (RT#123456)<br />
|-<br />
| Debian<br />
| http://bugs.debian.org/<br />
| (deb#123456)<br />
|-<br />
| Exim<br />
| http://bugs.exim.org/<br />
| (beo#1234)<br />
|-<br />
| Fate (Feature tracking tool)<br />
| https://features.opensuse.org/<br />
| (fate#123456)<br />
|-<br />
| freedesktop.org<br />
| http://bugs.freedesktop.org/<br />
| (fdo#123456)<br />
|-<br />
| FSF<br />
| http://bugs.gnu.org<br />
| (gnu#123456)<br />
|-<br />
| GCC<br />
| http://gcc.gnu.org/bugzilla/<br />
| (GCC#123456)<br />
|-<br />
| GH<br />
| https://github.com/<br />
| ([https://github.com/yast/yast-core/issues/42 gh#yast/yast-core#42])<br />
|-<br />
| GNOME<br />
| http://bugzilla.gnome.org/<br />
| (bgo#123456)<br />
|-<br />
| Graphviz<br />
| http://graphviz.org/mantisbt/view_all_bug_page.php<br />
| (gvz#123456)<br />
|-<br />
| ICCULUS<br />
| http://bugzilla.icculus.org/<br />
| (bio#123456)<br />
|-<br />
| Jenkins CI<br />
| https://issues.jenkins-ci.org<br />
| (jenk#123456)<br />
|-<br />
| KDE <br />
| http://bugs.kde.org/<br />
| (kde#123456)<br />
|-<br />
| Kernel or K<br />
| http://bugzilla.kernel.org/<br />
| (bko#123456)<br />
|-<br />
| Launchpad (Ubuntu)<br />
| https://bugs.launchpad.net/<br />
| (lp#123456)<br />
|-<br />
| Linux Foundation<br />
| http://developerbugs.linux-foundation.org/<br />
| (lf#1234)<br />
|-<br />
| MeeGo<br />
| http://bugs.meego.com<br />
| (MeeGo#123456)<br />
|-<br />
| Mono<br />
| http://bugzilla.ximian.com/<br />
| (Mono#123456)<br />
|-<br />
| Mozilla<br />
| http://bugzilla.mozilla.org/<br />
| (bmo#123456)<br />
|-<br />
| Novell<br />
| https://bugzilla.novell.com/<br />
| (bnc#123456)<br />
|-<br />
| SUSE<br />
| https://bugzilla.suse.com/<br />
| (bsc#123456)<br />
|-<br />
| OpenLDAP<br />
| http://www.openldap.org/its/<br />
| (ITS#123456)<br />
|-<br />
| OpenOffice.org (Issuezilla)<br />
| http://qa.openoffice.org/issues/<br />
| (i#123456)<br />
|-<br />
| OpenOffice.org Novell (obsolete)<br />
| https://bugzilla.novell.com/<br />
| (n#123456)<br />
|-<br />
| openSUSE-Education<br />
| http://devzilla.novell.com/education/<br />
| (os-edu#123456)<br />
|-<br />
| Pidgin<br />
| https://developer.pidgin.im/ticket/12345<br />
| (pidgin.im#12345)<br />
|-<br />
| RedHat<br />
| https://bugzilla.redhat.com/<br />
| (rh#123456)<br />
|-<br />
| Samba<br />
| https://bugzilla.samba.org/<br />
| (bso#123456)<br />
|-<br />
| Sourceforge<br />
| http://sf.net/support/tracker.php?aid=1234567<br />
| (sf#1234567); number is in the "aid=" part in an URL<br />
|-<br />
| SourceWare<br />
| http://sourceware.org/bugzilla/<br />
| (swo#1234567)<br />
|-<br />
| Typo3<br />
| http://forge.typo3.org/<br />
| (t3#1234567)<br />
|-<br />
| WebKit<br />
| https://bugs.webkit.org/<br />
| (webkit#123456)<br />
|-<br />
| Ximian<br />
| http://bugzilla.ximian.com/<br />
| (Ximian#4321)<br />
|-<br />
| Xfce<br />
| https://bugzilla.xfce.org/<br />
| (bxo#123456)<br />
|-<br />
| Xamarin<br />
| http://bugzilla.xamarin.com/<br />
| (bxc#4321)<br />
|}<br />
<br />
For other bugzilla numbers, please use the full URL to the coresponding bugzilla at the beginning of the patch file. For example:<br />
* http://developer.berlios.de/bugs/?func=detailbug&bug_id=12707&group_id=769<br />
<br />
[[Category:Packaging]]<br />
[[Category:Packaging documentation]]<br />
<br />
[[de:openSUSE:Paketbau Richtlinien für Patches]]<br />
[[el:openSUSE:Packaging Patches guidelines]]<br />
[[ja:openSUSE:パッケージング修正ガイドライン]]<br />
[[ru:openSUSE:Руководство по оформлению патчей]]<br />
[[zh:openSUSE:Packaging_Patches_guidelines]]</div>Okurzhttps://en.opensuse.org/index.php?title=SDB:System_upgrade&diff=73624SDB:System upgrade2016-01-17T11:18:00Z<p>Okurz: mark explicit TOC order numbers consistently (no bold)</p>
<hr />
<div>{{Migration navbar}}<br />
{{Intro|This guide shows how to use [[Portal:Zypper|Zypper]] to do a live distribution upgrade of openSUSE.<br />
}}<br />
{{Knowledge|<br />
*[[Portal:13.2|13.2]]<br />
*[[Portal:13.1|13.1]]<br />
*[[Portal:12.3|12.3]]<br />
*[[Portal:12.2|12.2]]<br />
*[[Portal:12.1|12.1]]<br />
*[[Portal:11.4|11.4]]<br />
*[[Portal:11.3|11.3]]<br />
*[[Portal:11.2|11.2]]<br />
|<br />
*[[SDB:Zypper_usage|Zypper usage]]<br />
*[[YaST Online Update]]<br />
|<br />
*[[YaST Software Management]]<br />
*[[SDB:Offline_upgrade]]<br />
*[http://doc.opensuse.org/documentation/html/openSUSE/opensuse-startup/cha.update.html Official upgrade documentation (Startup, Ch 16).]<br />
}}<br />
{{Version note|11.2+|Starting with openSUSE 11.2, a live upgrade from the prior version is [https://features.opensuse.org/305634 officially supported]. This allows to perform a complete operating system upgrade in place, without reloading everything from scratch.}}<br />
<br />
----<br />
==Summary==<br />
This page explains how to run a tool or a series of command line steps to upgrade your system to the latest version of openSUSE.<br />
<br />
Doing a live upgrade has advantages as well as disadvantages.<br />
<br />
Among the advantages are:<br />
* You only download the packages that need to be upgraded, thus using a lot less bandwidth.<br />
* During the upgrade, you can still use your workstation (even if this is not recommended); the only downtime will be the reboot after the upgrade.<br />
* You do not have to use a DVD, nor do you need a DVD writer. (You also could boot from the net or a USB key, and install the rest from the net...)<br />
<br />
The disadvantages:<br />
* If, for any reason, the upgrade is interrupted (e.g. power outages, network disconnect) and the process cannot continue, you could be left with a broken system (that depends on where the process stopped of course).<br />
* If you have multiple systems to upgrade, you use bandwidth each time, so it might be better to download an ISO image.<br />
* It does not do all of the cleanup and maitanence that an offline DVD Upgrade does.<br />
<br />
'''Warning:''' Do not skip a release when upgrading! Example: do ''not'' upgrade from 13.1 to 42.1. Instead, from 13.1 upgrade to 13.2, then from 13.2 upgrade to 42.1.<br />
<br />
Other possibility:<br />
Offline upgrade, a.k.a. traditional or DVD upgrade. For more information, read [[SDB:offline_upgrade|offline upgrade]]. This upgrade method is safer and more versatile. Unless you have a good reason to do otherwise, use the [[SDB:offline_upgrade|offline upgrade]] method.<br />
<br />
----<br />
<br />
==Supported scenarios==<br />
Be aware that, in principle, this upgrade process is considered “best effort” only. This means that due to some third-party packages and the myriad of possible configurations, it is possible for some combinations to cause failure upon upgrade.<br />
<br />
Also, remember these important rules:<br />
<br />
* All important data must be backed up prior to beginning the upgrade process.<br />
* You must update your system with the latest updates for the release you are currently running before running zypper dup.<br />
* You must only zypper dup to the next release. Hopping over a release, e.g., going from 13.1 -> 42.1, is not supported.<br />
<br />
<!--- The following scenarios are the two options available:<br />
# Command line – using [[Portal:Zypper|Zypper]].<br />
# Graphical tool – using [[Portal:YaST|YaST]].---><br />
----<br />
<br />
==Making sure you are up to date==<br />
The '''supported''' starting point is the last openSUSE release with all current updates applied. This does not include arbitrary openSUSE Build Service repositories you may have added. We recommend that you disable all OBS repositories first, perform the upgrade, then reenable them. The following steps show you how to update your openSUSE distribution to the current packages before upgrading to the next version.<br />
<br />
===Command line===<br />
====1. Check if the update repository already exists and is enabled.====<br />
<div class=shell>zypper repos --uri</div><br />
Check if <tt>http://download.opensuse.org/update/13.2/</tt> (replace 13.2 with your version) exists in one of the ''URI'' column values, and '''Yes''' in column ''Enabled'', like the example below,<br />
# | Alias | Name | Enabled | Refresh | URI<br />
---+-----------------+-----------------+---------+---------+---------------------------------------<br />
1 | repo-update | repo-update | Yes | Yes | http://download.opensuse.org/update/13.2/<br />
<br />
If the ''Enabled'' column says ''No'', enable it by issuing the command<br />
<div class=shell>zypper modifyrepo --enable repo-update</div><br />
: where ‘repo-update’ is the name of the update repository.<br />
If it exists and has been enabled, continue to step [[#3. Update system to the latest packages|3]].<br />
<br />
====2. Add update-repository====<br />
<div class=shell>zypper addrepo --check --refresh --name 'openSUSE-13.2-Update' http://download.opensuse.org/update/13.2/ repo-update</div><br />
: Replace 13.2 above with your current openSUSE version.<br />
<br />
====3. Update system to the latest packages====<br />
<div class=shell>zypper refresh</div><br />
<div class=shell>zypper update</div><br />
For more information, read [[SDB:Zypper_usage|Zypper Usage]].<br />
<br />
===Graphical tool===<br />
See [[YaST_Online_Update|YaST Online Update]].<br />
<br />
----<br />
==Running the Upgrade==<br />
The following steps will show you how to upgrade your openSUSE distribution to the following release (eg. 13.2 -> 42.1). As already mentioned, any third party or OBS repositories can cause troubles, so it is recommended to disable or remove them before proceeding.<br />
<br />
===Before you begin===<br />
Make sure that you read the [[openSUSE:Most_annoying_bugs|list of annoying bugs]] for the new version you are going to install. Some of them could affect the update process. Usually, alongside the bug is listed some solution or workaround, so make sure that you are prepared for upcoming problems.<br />
<br />
Also, read the [https://doc.opensuse.org/release-notes/x86_64/openSUSE/ Release Notes] which list changes and glitches in the new release<br />
<br />
===Command line===<br />
As an example, we will be showing upgrade from 13.2 to 42.1 here:<br />
* Take a look at all repos you have <div class=shell>zypper lr</div> and remove all third party/OBS repos you no longer need <div class=shell># zypper rr <alias></div><br />
* Change all remaining repo URLs to the new version of the distribution (needs to be run as root) <div class=shell># cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old</div> (for a backup copy), then: <div class=shell># sed -i 's/13\.2/leap\/42\.1/g' /etc/zypp/repos.d/*</div><br />
* NOTE - Although the above sed based modification might work for other repos, it fails modifying the update repos upgrading from 13.2. To fix the problem, paste and run the following(all a single line) in your console which manually adds the update repos using the correct URI<br />
: <syntaxhighlight lang="cpp"><br />
# zypper rr repo-update repo-update-non-oss && zypper ar -f http://download.opensuse.org/update/leap/42.1/oss/ openSUSE-Leap-42.1-Update && zypper ar -f http://download.opensuse.org/update/leap/42.1/non-oss/ openSUSE-Leap-42.1-Update-Non-Oss<br />
</syntaxhighlight><br />
* If you are upgrading from 12.1 or older, add non-oss-update repo <br />
: <syntaxhighlight lang="cpp"><br />
# zypper ar -f http://download.opensuse.org/update/leap/42.1/non-oss/ repo-update-non-oss<br />
</syntaxhighlight><br />
* Refresh new repositories (you might be asked to accept new gpg key) <div class=shell># zypper --gpg-auto-import-keys ref</div> If you haven't removed third party/OBS repositories you may encounter some errors as these repositories may not exist yet or they may have different unguessable URL. It is always recommended to remove them and add their newer version after upgrade.<br />
* Now execute the full distribution upgrade. <br />
{{Info|It is strongly recommended that you run the upgrade not in runlevel 5 (graphical mode) but in runlevel 3 (text + network). <br />
<br />
People had their X session stopped/crashed during the upgrade, causing the upgrade to abort, which in turn left the system in an inconsistent state.<br />
<br />
To change to runlevel 3, see [[SDB:Switch_runlevel]].<br />
}}<br />
<br />
<div class=shell># zypper dup</div> With the above command, zypper will download all required packages and install them in heaps. To download all packages in advance, use: <div class=shell># zypper dup --download in-advance</div><br />
{{Info|If you did the above dist upgrade before the official release date (eg.2014-11-04 for 13.2), you may have installed a Release Candidate (RC) or a milestone version and will need to repeat the final <code>zypper dup</code> step now to receive the final release.}}<br />
<br />
<br />
deleted providers: libyui-ncurses-pkg5-2.44.4-2.1.5.x86_64 <br />
Solution 1: Following actions will be done: <br />
deinstallation of PackageKit-backend-zypp-0.8.11-2.3.1.x86_64<br />
deinstallation of PackageKit-0.8.11-2.3.1.x86_64<br />
deinstallation of PackageKit-branding-openSUSE-13.1-2.2.1.noarch<br />
deinstallation of apper-lang-0.8.1-11.7.1.noarch<br />
Solution 2: deinstallation of patterns-openSUSE-yast2_basis-13.1-13.6.1.x86_64<br />
Solution 3: deinstallation of sysvinit-2.88+-89.1.2.x86_64<br />
Solution 4: install PackageKit-0.8.17-3.1.3.i586 despite the inferior architecture<br />
Solution 5: keep libyui-ncurses-pkg5-2.44.4-2.1.5.x86_64<br />
Solution 6: keep libyui-ncurses-pkg5-2.44.4-2.1.5.x86_64<br />
Solution 7: break patterns-openSUSE-yast2_basis-13.1-13.6.1.x86_64 by ignoring some of its dependencies<br />
<br />
Choose from above solutions by number or skip, retry or cancel [1/2/3/4/5/6/7/s/r/c] (c): <br />
<br />
Make the choice to delete sysvinit.<br />
}}<br />
* Search for updated openSUSE leap 42.1 compatible third-party repositories that you used before&nbsp;— if you still need them&nbsp;— and add them. {{Warning|Use with caution. Using third-party repositories may break your system or cause instabilities.}} <div class=shell>zypper addrepo --name <name> <url> <alias></div> Or, if you have URL of a .repo file: <div class=shell># zypper ar <url.repo></div><br />
<br />
* After upgrade, reboot is recommended to start the new kernel and newer versions of everything.<br />
<br />
{{Info|In addition, <code>zypper up</code> can be run from time to time to ensure you have the latest available packages from the various repositories that you have enabled. YOU (Yast Online Update) only addresses security updates from the official repositories.}}<br />
<br />
<!-- hidden because this is not working properly<br />
===Graphical tool===<br />
There is a [[YaST]] module called [[YaST wagon|Wagon]] to run the distribution upgrade with a graphical user interface ([[GUI]]).<br />
{{Warning|Keep in mind that the Wagon update is less tested than the command line method described above.}}<br />
Here is a quick walkthrough the 11.3->11.4 upgrade with [[YaST wagon|Wagon]]:<br />
* ensure you have yast2-wagon installed<br />
* make sure you have only 11.3 repositories enabled<br />
* start "<code>YaST2 wagon</code>" or use the YaST control center<br />
* when asked for a URL, choose "Custom URL" => "Specify URL" and give http://download.opensuse.org/distribution/11.4/repo/oss<br />
* follow the dialogs<br />
* after upgrade, ignore the message about contacting Novell Customer Center => click Abort<br />
* update all repositories to 11.4 as described above (e.g. with yast2 inst_source)<br />
* reboot<br />
--><br />
----<br />
<br />
== Links to other openSUSE or SUSE projects ==<br />
<!--=== Novell's Bugzilla===--><br />
<br />
===The openSUSE Forums===<br />
* [https://forums.opensuse.org/search.php Search threads] tagged with <tt>zypper dup</tt> or <tt>upgrade</tt><br />
<br />
[[Category:Package management]]<br />
[[Category:SDB:Installation 11.4]]<br />
[[Category:SDB:Installation 12.1]]<br />
[[Category:SDB:Installation 12.2]]<br />
<br />
[[de:SDB:Distribution-Upgrade]]<br />
[[es:SDB:Actualización de la distribución]]<br />
[[fr:SDB:System upgrade]]<br />
[[it:SDB:System upgrade]]<br />
[[nl:SDB:Upgrade]]<br />
[[ru:SDB:Обновление системы]]<br />
[[ja:Upgrade/Supported]]<br />
[[zh:SDB:系统升级]]<br />
[[zh-tw:SDB:系統升級]]</div>Okurzhttps://en.opensuse.org/index.php?title=Restricted_formats&diff=73249Restricted formats2015-12-01T07:19:01Z<p>Okurz: mark mp3 tutorial link as broken</p>
<hr />
<div>{{Intro|Functionality which is considered to infringe on some software patents, or it is possible copyright violation, prevents various frequently requested packages to be included in openSUSE. Here is explanation of the issues and suggestions how to solve the problems.}}<br />
<br />
{{Warning|Please do ''not'' add links to software packages which contain intellectual property protected by patent laws.}}<br />
<br />
openSUSE supports the use of [[Free and Open Source Software]]. However, retail versions may include additional packages that have been licensed by Novell or other distributors for distribution.<br />
<br />
The reasons why a certain software package is not included in the main openSUSE are the following:<br />
* The software is proprietary software, it does not conform to the [http://www.opensource.org/docs/definition.php Open Source definition].<br />
* The software is providing functionality which is patented and the patent holder is preventing distribution of the software - e.g. multimedia-related patents affect a number of free software projects like ffmpeg, mplayer, xine, lame, mythtv, lastfm and x264.<br />
* The software violates laws concerning software distribution in jurisdictions where Novell conducts business.<br />
<br />
Some proprietary software and drivers may be available from their respective owners and licensed vendors. Patent-encumbered software may be obtained from vendors which have been able to strike licensing deals with the patent holders.<br />
<br />
==MPEG-2==<br />
MPEG-2 patent holders (assembled in the [http://www.chiariglione.org/mpeg/ Moving Picture Experts Group (MPEG).]) do not provide patent licenses which are compatible with the distribution of free software. This means that MPEG-2 decoders and encoders cannot be part of openSUSE. Even though [[Kaffeine]] and [[Xine]] are included in the distribution, the required decoder modules cannot be provided, at least not under a free license. This also effects [[GStreamer]] based projects like [[Totem]].<br />
<br />
===DVB TV viewers===<br />
All DVB video data is encoded using ''MPEG-2''. Some more expensive DVB cards contain an MPEG-2 decoder and at least some of them are supported under Linux.<br />
<br />
===DVD video===<br />
All video data on DVDs is usually encoded using ''MPEG-2''.<br />
<br />
In addition, region-coded DVDs are encrypted with the [[wikipedia:Content_Scramble_System|Content Scrambling System (CSS)]].<br />
There is an opensource project called '''libdvdcss''' that bypasses this encryption. Though the encryption is weak, using any method or device to bypass this is classed as a 'circumvention device' in jurisdictions such as the US, Australia and many EU jurisdictions, and distribution of such software is considered illegal in those jurisdictions and may be prosecuted if it is not certified. For certification, it may not allow copying and has to forbid fast-forward over some DVD tracks which often contain advertising.<br />
<br />
===Possible solutions===<br />
[http://www.fluendo.com Fluendo] offers a complete set of playback plugins for [[GStreamer]], which includes not only MPEG-2, but also MPEG-4, H.264, WMA/WMV and AAC codecs fully licensed and pre-packaged for major distributions like openSUSE. This way one can get all GStreamer-based programs to work with patented mainstream video and audio codecs. The Fluendo DVD player is a proprietary software that can be bought and installed as RPM for openSUSE. It offers fully licensed MPEG 2 codecs via GStreamer and has a legal CSS key.<br />
<br />
If you do not require compatibility with a DVD player, consider encoding videos as [[wikipedia:Ogg|Ogg]] [[wikipedia:Theora|Theora]].<br />
<br />
----<br />
<br />
==MP3==<br />
Even though MPEG Audio Layer 3 (''MP3'') is an ISO standard, the MP3 [http://www.mp3licensing.com/patents/index.html patent holders] do not license MP3 encoders or decoders under an open source license.<br />
<br />
===Possible solutions===<br />
You can use the [http://software.opensuse.org/codecs Fluendo MP3 decoder] which is a fully licensed [[GStreamer]] plugin for ''MP3'', available free of charge. It can be used via [[Amarok]] or [[Banshee]]. The tutorial [http://www.justuber.com/blog/2007/02/09/mp3-on-opensuse-5-minute-fix MP3 on openSUSE – 5 Minute Fix] (BROKEN LINK) demonstrates how to get up and running with MP3 on openSUSE in a few minutes.<br />
<br />
As an alternative, encode your audio files in [[wikipedia:Ogg|Ogg]] [[wikipedia:Vorbis|Vorbis]], [[wikipedia:FLAC|FLAC]], [[wikipedia:Speex|Speex]], or other such freely used and available ''audio codecs''.<br />
<br />
The ''mp3'' licensing [http://www.mp3licensing.com/help/ FAQ] and [http://www.mp3licensing.com/royalty/emd.html royalty] pages state that that "no license is needed for private, non-commercial activities (e.g., home-entertainment, receiving broadcasts and creating a personal music library), not generating revenue or other consideration of any kind or for entities with associated annual gross revenue less than US$ 100.000".<br />
<br />
----<br />
<br />
==NTFS==<br />
<br />
There are no ''NTFS'' patents known. Instead of patents (which are made public), Microsoft apparently chose to use Non-disclosure agreements to impede the ability of open source projects to implement support for NTFS. Everything which is known to the public about the internals of NTFS has been reverse engineered therefore. As that reverse engineering has been conducted in compliance with respective laws, the information about the NTFS data structures obtained by this reverse engineering can and is legally used in free software.<br />
<br />
Unfortunately, the data format of the NTFS journal log has not been successfully reverse engineered yet, so if the NTFS journal log is dirty (contains data of not committed transactions), the free software cannot read the current state of the NTFS partition, only the state which is committed in the filesystem itself. This is however not an issue if the NTFS partition is in clean state.<br />
<br />
===Possible solutions===<br />
[[SDB:NTFS|NTFS-3g]] provides read-write support to NTFS partitions, excluding transactions which are not committed to the filesystem itself, but only present in the NTFS journal log. If the partition is clean and properly disconnected by Windows, this is however not a problem.<br />
<br />
FAT32 (see in [http://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 wikipedia])is well-supported by both Windows and Linux, but has some limitations:<br />
* Does not support some characters in filenames which are allowed by POSIX, e.g. the colon: “:” (can be circumnavigated by using additional layers, e.g. posixovl)<br />
* For formatting partitions greater than 32GB, the Windows XP automatically switches to NTFS, but a command line tool can be used to create FAT32 partitions which are bigger than 32GB.<br />
<br />
There are drivers and software for Windows which allow limited access to ext2 (see for [http://en.wikipedia.org/wiki/Ext2 ext2 in Wikipedia]):<br />
* [http://www.fs-driver.org Ext2 IFS] is a “freeware” (not free software) installable ext2 file system for Windows. It integrates with the Windows kernel thereby providing access to files on ext2 (and ext3) partitions seamlessly to all applications. It may however lead to blue screens under Windows XP.<br />
* [http://www.chrysocome.net/explore2fs explore2fs] supports [[wikipedia:ext2|ext2]] and [[wikipedia:ext3|ext3]] from within Windows.<br />
* [http://ext2fsd.sourceforge.net/ ext2fsd] is an open-source ext2 (and ext3, with some limitations) driver for Windows. While still under development, its current feature set may already suffice.<br />
<br />
[[wikipedia:cifs|cifs]] allows Linux to access Windows shares and [[Samba]] enables a Linux host to provide Windows shares itself to a network.<br />
<br />
----<br />
<br />
==Proprietary Linux kernel modules which include Linux headers==<br />
<br />
===NVIDIA graphics drivers===<br />
Three classes of drivers support [[SDB:NVIDIA|NVIDIA]] cards:<br />
# The open source '''nv''' driver which has severe limitations (does not even support some new cards like the Quadro 570FX, does not have proper dual head support and has no 3D support) It is included in X.org and is used by default. As of openSUSE 11.3 it has been replaced by nouveau driver. Anyway, on NVIDIA without KMS (Kernel Mode Setting) the nv driver is still used.<br />
# The closed source, proprietary '''nvidia''' driver which requires the '''nvidia kernel module''' which many kernel developers regard as being in violation of the [[GNU General Public License]]. <br />
# There is the reverse engineered '''nouveau''' driver which is based on the '''nv''' driver. It aims to provide proper dual head support and 3D support.<br />
<br />
===ATI graphics drivers===<br />
Three classes of drivers support [[SDB:ATI|ATI]] cards:<br />
# X.org includes F/LOSS drivers for many (older) ATI graphics adapters. These are used by default.<br />
# The closed source, proprietary '''ATI''' graphics drivers which requires the '''ati kernel module''' which many kernel developers consider this driver to violate the [[GNU General Public License]] license of the kernel.<br />
# ATI has released some register specifications of their recent chipsets but has not released any documentation about the 3D functionality of their newer cards. The new '''ativivo''' and '''radeonhd''' drivers support (alpha quality) newer ATI R500/R600 graphics adapters. See the corresponding [http://news.opensuse.org/?p=265 openSUSE news item]<br />
<br />
----<br />
<br />
==See also==<br />
* [[openSUSE:Build Service application blacklist|Build Service application blacklist]]<br />
<br />
----<br />
<br />
==External links==<br />
* [http://opensuse-community.org openSUSE-Community.org]<br />
* [http://software.opensuse.org/codecs Proprietary multimedia support in openSUSE]<br />
<br />
[[Category:Policies and guidelines]]<br />
[[Category:SDB:Configuration]]<br />
[[Category:Multimedia|{{PAGENAME}}]]<br />
<br />
[[de:Eingeschränkte Formate]]<br />
[[el:Restricted Formats]]<br />
[[es:Formatos restringidos]]<br />
[[fr:Restricted Formats]]<br />
[[it:Restricted formats]]<br />
[[ru:Restricted Formats]]<br />
[[ja:制限されている規格]]<br />
[[zh:受限媒体格式]]</div>Okurzhttps://en.opensuse.org/index.php?title=Category:Develop_It&diff=73138Category:Develop It2015-11-19T12:46:49Z<p>Okurz: correct also second "novell" bugzilla reference</p>
<hr />
<div>==Develop it==<br />
Help us develop our distribution or our infrastructure.<br />
<br />
{{Point here|[[Image:Icon-usage.png|48px|Develop|link=]]|<br />
* '''Design openSUSE Artwork''' <br/> Interested in contributing to the look and feel of openSUSE? Visit the [[Portal:Artwork|Artwork]] [[openSUSE:Pixel pool|Pixel pool]] to show off your designs and help influence the next version of openSUSE's artwork.<br />
<br />
* '''Localize openSUSE Specific Applications''' <br/> Translations of YaST2 and other applications specific to openSUSE.<br />For KDE, GNOME and different applications that don't belong to either of two, it is possible to find contributors in other Linux communities, but YaST and Co are our responsibility. Read more about it on [http://i18n.opensuse.org/ http://i18n.opensuse.org].<br />
<br />
* '''Test openSUSE and Report Bugs''' <br/>You can help improve openSUSE by finding and reporting bugs. Our bug tracking system, [https://bugzilla.opensuse.org Bugzilla], is used for all openSUSE/SUSE Linux products. If you have never written a bug report, please refer to [[openSUSE:Bug_reporting_FAQ|Bug reporting FAQ]] to learn what kinds of information make the report most useful. You are welcome to participate in our [[openSUSE:Bug Day|Bug day]] events. In addition to the current release, you can also test our regularly updated development version at [[Portal:Factory|Factory]] which will result in the next openSUSE version.<br />
<br />
* '''Start with a Junior Job'''<br/> [[openSUSE:Junior jobs|Junior jobs]] are issues that are easy to do such as basic bug fixes, package updates or the creation of a test case. Every maintainer sometimes has these. It is nice to have them fixed but usually maintainers are too busy or want to reserve them for someone who wants to learn. These tasks are a great opportunity to start for community members who want to contribute, but don't know how. The maintainers are very willing to help you learn!<br />
<br />
* '''Screen openFATE Features'''<br/>You can assure best outcome for the openSUSE distribution by reviewing the proposed [https://features.opensuse.org Features] for the next product generation to keep [[openSUSE:openfate|openFATE]] as efficient as possible.<br />
<br />
* '''Package Applications''' <br/>[[Portal:Packaging|Packaging]] describes the process of getting your packaged application into the next release. For more information about getting source code and building your own packages, read the [[openSUSE:Build_Service_Tutorial|openSUSE Build Tutorial]].<br />
<br />
* '''Develop Patches''' <br/> The most obvious way for programmers to [[Portal:Factory contribution|participate in the development]] of openSUSE is to post a patch as a suggested solution to an existing bug in [https://bugzilla.opensuse.org Bugzilla]. Each package has a maintainer, who will contact you to discuss your proposed solution. You may want to join one of our [[openSUSE:Mailing_lists#Development_lists | development mailing lists]] before you start coding in order to discuss your plans and coordinate with other developers.<br />
<br />
* '''Work on a Google Summer of Code project'''<br/>There are several areas in and around openSUSE which offer the opportunity to do a Google [[openSUSE:GSOC|Summer of Code]] project. If you are a student, you can participate by developing one of the open source projects described here (or propose an idea of your own!) and earn money, while being mentored by an experienced member of the openSUSE community.<br />
<br />
* '''Build your own openSUSE based distribution'''<br/>You can quite easily build your own openSUSE based distro using [[Portal:SUSE_Studio|SUSE Studio]] or [[openSUSE:Build_Service_KIWI|OBS and KIWI]]. Developing a specialized openSUSE version, like [[Portal:Medical|openSUSE Medical]] which caters to a specific target group is something we'd love to see you do!<br />
}}<br />
<br />
'''Additional information:''' [[openSUSE:Pixel pool|Artwork pixel pool]] &ndash; [[openSUSE:Localization team|Localization team]] &ndash; [[openSUSE:Testing Core team|Testing Core team]] &ndash; [[openSUSE:Openfate_screening|Features screening team]] &ndash; [[openSUSE:Junior jobs|Junior jobs]] &ndash; [[GSoC|Summer of Code]]<br />
<br />
----<br />
[[Category:Participate]]</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE_talk:Testing&diff=73034openSUSE talk:Testing2015-11-13T17:00:43Z<p>Okurz: Created page with ""Currently we work on openSUSE 13.1 (Factory)" is outdated. Replace by version independant wording --okurz 2015-11-13"</p>
<hr />
<div>"Currently we work on openSUSE 13.1 (Factory)" is outdated. Replace by version independant wording --okurz 2015-11-13</div>Okurzhttps://en.opensuse.org/index.php?title=Portal_Talk:How_to_participate&diff=72838Portal Talk:How to participate2015-11-02T18:24:26Z<p>Okurz: "bugzilla" link outdated?</p>
<hr />
<div>== Activity info missing ==<br />
<br />
The hyperlinks Participate Document Develop Spread Lead are all void. What happened?<br />
--[[User:Yecril71pl|Yecril71pl]] ([[User talk:Yecril71pl|talk]]) 11:05, 5 January 2014 (UTC)<br />
<br />
I think the "bugzilla" link should point to bugzilla.opensuse.org, see https://bugzilla.opensuse.org/show_bug.cgi?id=953202 --okurz</div>Okurzhttps://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.1&diff=72779openSUSE:Most annoying bugs 42.12015-10-31T11:56:24Z<p>Okurz: repair shortcut link</p>
<hr />
<div>To directly report a bug against openSUSE Leap 42.1 - use "openSUSE Distribution" now, here's a [https://bugzilla.opensuse.org/enter_bug.cgi?&product=openSUSE%20Distribution&cf_foundby=Customer&op_sys=openSUSE+42.1 shortcut].</div>Okurz