Plan of Record for Fedora 22 Network Install Media
by Stephen Gallagher
(Cross-posted to the WG mailing lists; please reply only to devel@)
== Overview ==
Today in #anaconda, we had a discussion of the plans for network install
media for Fedora 22. We acknowledged that the network install (and more
generally, unattended installation) story in Fedora 21 was somewhat
lacking. In particular, there was user confusion around how to deploy
Fedora Workstation in an unattended manner.
Some of the problems we faced in Fedora 21 were a result of not having
necessary plumbing in Anaconda (largely because we didn't even realize
this until well into Beta phase, at which point we just started breaking
out the duct tape and chewing gum). In particular, we needed a way for
individual Fedora editions to provide a mechanism for specifying
different defaults (such as automatic partitioning rules or the default
environment group that would be displayed in an attended install).
Without these things, while we could produce media with separate
graphical branding, we couldn't truly produce separate network installs
for Cloud, Server and Workstation. So we settled on producing only the
Server network install media.
== Output ==
In Fedora 22, we will be producing four network install ISOs:
* Fedora Server
- Server branding
- Default environment group: Fedora Server
- Auto-partitioning defaults: LVM on XFS (except /boot)
- Responsible WG: Server WG
* Fedora Workstation
- Workstation branding
- Default environment group: Fedora Workstation
- Auto-partitioning defaults: LVM on EXT4
- Responsible WG: Workstation WG
* Fedora Cloud
- Cloud branding
- Default environment group: Fedora Cloud
- Auto-partitioning defaults: TBD
- Responsible WG: Cloud WG
* Fedora "Generic" (name TBD)
- Generic Fedora branding
- Default environment group: minimal
- Auto-partitioning defaults: TBD
- Responsible WG: Base WG
In addition, there is ongoing discussion around media for bare-metal
Fedora Atomic installations. This has not been finalized, but will
likely result in an additional output.
While each of these network installs will be *capable* of also
installing any of the other products (though possibly not with the
expected auto-paritioning), we have agreed that QA testing will only be
performed on the intended environment group target for the branded
media. We will not advertise or make any special effort to support other
targets.
== Remaining work that needs to be done ==
Release engineering will need to modify their compose tools to produce
each of these install trees, as well as handling the necessary mirroring
functions.
The working groups responsible for each of these install media will be
responsible for performing the following tasks before the Alpha Freeze
(ideally well before, so we can run test composes and fix issues without
slipping):
* Modify the appropriate fedora-productimg-$PRODUCT package to include
an anaconda extension model that will extend the InstallClass and set
the default environment group and optionally modify the
auto-partitioning functionality.
* Review the contents of comps-f22.xml.in and the related kickstart
files in spin-kickstarts to ensure that the install media contains the
appropriate content.
For simplicity in understanding who to contact, it would be beneficial
if each of the responsible working groups would nominate an individual
to be the point of contact on these changes. I volunteer myself to
represent the Server WG in this capacity.
Given that we branch on February 10th enter Alpha Freeze on February
24th, I'd like to propose a soft deadline (a check-in) on February 9th
with a hard deadline on February 16th in order to have time to run at
least one test compose prior to Alpha Freeze.
== Acknowledgements ==
The cast of characters involved in this discussion were:
* Stephen Gallagher (Server WG)
* Dennis Gilmore (Release Engineering)
* Brian C. Lane (Anaconda)
* Ian McLeod (Project Atomic)
* David Shea (Anaconda)
* Adam Williamson (QA)
6 years, 1 month
GUI applications writing garbage to stdout/stderr
by Marcel Oliver
Hallo,
there is one more thing which I found really annoying after upgrading
to F21. I like to launch GUI applications from the command line (I
know there is some debate on whether this habit makes me a target user
of Fedora, but I am writing under the assumption that it might).
Many GUI applications write garbage to either stdout or stderr, making
the terminal windows difficult to view and navigate. I have seen this
on earlier releases, too, but the volume being written and the number
of applications affected has increased to the extent that it is
becoming a real problem.
Some, like nemo, even keep writing messages during operation, which is
very distracting as there is sudden movement in the corner of one's
eye.
Yes, I know that I could write, for example
okular file.pdf &> /dev/null
but that somehow defeats the efficiency of the command line operation.
Some of the main culprints for me are nemo, evince, and okular; if I
am go looking, I can probably find many more. The only well-behaved
application I know is libreoffice.
Are these considered bugs that I should file against the package? Is
there a policy that applies?
Regards,
Marcel
6 years, 1 month
Is it a SELinux policy problem ?
by Casper
Or is it a luajit problem ?
Dear devs hello.
I would like to determine if these AVC are caused by prosody, lua, or
a wrong SELinux policy.
lancaster ~ # systemctl status prosody
● prosody.service - Prosody XMPP (Jabber) server
Loaded: loaded (/usr/lib/systemd/system/prosody.service; disabled)
Active: inactive (dead)
lancaster ~ # sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 29
lancaster ~ # rpm -q prosody luajit
prosody-0.9.4-4.fc21.x86_64
luajit-2.0.3-3.fc21.x86_64
systemd start:
janv. 27 19:28:03 lancaster prosodyctl[21208]: PANIC: unprotected
error in call to Lua API (runtime code generation failed, restricted
kernel?)
janv. 27 19:28:04 lancaster prosodyctl[21208]: PANIC: unprotected
error in call to Lua API (runtime code generation failed, restricted
kernel?)
janv. 27 19:28:04 lancaster systemd[1]: prosody.service: control
process exited, code=killed status=11
janv. 27 19:28:04 lancaster systemd[1]: Failed to start Prosody XMPP
(Jabber) server.
janv. 27 19:28:04 lancaster systemd[1]: Unit prosody.service entered
failed state.
janv. 27 19:28:04 lancaster systemd[1]: prosody.service failed.
kernel log:
janv. 27 19:28:03 lancaster prosodyctl[21208]: PANIC: unprotected
error in call to Lua API (runtime code generation failed, restricted
kernel?)
janv. 27 19:28:03 lancaster kernel: luajit[21209]: segfault at bcefddd
ip 000000000bcefddd sp 00007fff98c8cf00 error 15
janv. 27 19:28:04 lancaster prosodyctl[21208]: PANIC: unprotected
error in call to Lua API (runtime code generation failed, restricted
kernel?)
janv. 27 19:28:04 lancaster kernel: luajit[21208]: segfault at bcefe33
ip 000000000bcefe33 sp 00007fffe6d4a6b0 error 15
janv. 27 19:28:04 lancaster systemd[1]: prosody.service: control
process exited, code=killed status=11
janv. 27 19:28:04 lancaster systemd[1]: Failed to start Prosody XMPP
(Jabber) server.
janv. 27 19:28:04 lancaster systemd[1]: Unit prosody.service entered
failed state.
janv. 27 19:28:04 lancaster systemd[1]: prosody.service failed.
janv. 27 19:28:05 lancaster dbus[904]: [system] Successfully activated
service 'org.fedoraproject.Setroubleshootd'
janv. 27 19:28:14 lancaster setroubleshoot[21211]: Plugin Exception
restorecon_source
janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
preventing /usr/bin/luajit-2.0.3 from read access on the file
/var/log/prosody/debug.log. For complete SELinux messages. run sealert
-l 4598d861-a393-472b-9dda-2c1c3b069fd4
janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
preventing /usr/bin/luajit-2.0.3 from read access on the file
/var/log/prosody/info.log. For complete SELinux messages. run sealert
-l 4598d861-a393-472b-9dda-2c1c3b069fd4
janv. 27 19:28:14 lancaster setroubleshoot[21211]: SELinux is
preventing /usr/bin/luajit-2.0.3 from read access on the file
/var/log/prosody/error.log. For complete SELinux messages. run sealert
-l 4598d861-a393-472b-9dda-2c1c3b069fd4
janv. 27 19:28:15 lancaster setroubleshoot[21211]: SELinux is
preventing /usr/bin/luajit-2.0.3 from using the execmem access on a
process. For complete SELinux messages. run sealert -l
e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb
janv. 27 19:28:15 lancaster setroubleshoot[21211]: SELinux is
preventing /usr/bin/luajit-2.0.3 from using the execmem access on a
process. For complete SELinux messages. run sealert -l
e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb
lancaster ~ # sealert -l 4598d861-a393-472b-9dda-2c1c3b069fd4
SELinux is preventing /usr/bin/luajit-2.0.3 from read access on the
file /var/log/prosody/error.log.
***** Plugin catchall (100. confidence) suggests
**************************
If vous pensez que luajit-2.0.3 devrait être autorisé à accéder read
sur error.log file par défaut.
Then vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet
accès.
Do
autoriser cet accès pour le moment en exécutant :
# grep luajit /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:prosody_t:s0
Target Context system_u:object_r:var_log_t:s0
Target Objects /var/log/prosody/error.log [ file ]
Source luajit
Source Path /usr/bin/luajit-2.0.3
Port <Unknown>
Host lancaster
Source RPM Packages luajit-2.0.3-3.fc21.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.13.1-103.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name lancaster
Platform Linux lancaster 3.17.8-300.fc21.x86_64
#1 SMP Thu
Jan 8 23:32:49 UTC 2015 x86_64 x86_64
Alert Count 7
First Seen 2015-01-18
08:59:03 CET
Last Seen 2015-01-27
19:28:02 CET
Local ID 4598d861-a393-472b-9dda-2c1c3b069fd4
Raw Audit Messages
type=AVC msg=audit(1422383282.541:154043): avc: denied { read } for
pid=21209 comm="luajit" name="error.log" dev="dm-1" ino=2228909
scontext=system_u:system_r:prosody_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1422383282.541:154043): arch=x86_64
syscall=open success=no exit=EACCES a0=4154f8c0 a1=442 a2=1b6 a3=241
items=0 ppid=21208 pid=21209 auid=4294967295 uid=991 gid=990 euid=991
suid=991 fsuid=991 egid=990 sgid=990 fsgid=990 tty=(none)
ses=4294967295 comm=luajit exe=/usr/bin/luajit-2.0.3
subj=system_u:system_r:prosody_t:s0 key=(null)
Hash: luajit,prosody_t,var_log_t,file,read
lancaster ~ # sealert -l e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb
SELinux is preventing /usr/bin/luajit-2.0.3 from using the execmem
access on a process.
***** Plugin catchall (100. confidence) suggests
**************************
If vous pensez que luajit-2.0.3 devrait être autorisé à accéder
execmem sur les processus étiquetés prosody_t par défaut.
Then vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet
accès.
Do
autoriser cet accès pour le moment en exécutant :
# grep luajit /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:prosody_t:s0
Target Context system_u:system_r:prosody_t:s0
Target Objects Unknown [ process ]
Source luajit
Source Path /usr/bin/luajit-2.0.3
Port <Unknown>
Host lancaster
Source RPM Packages luajit-2.0.3-3.fc21.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.13.1-103.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name lancaster
Platform Linux lancaster 3.17.8-300.fc21.x86_64
#1 SMP Thu
Jan 8 23:32:49 UTC 2015 x86_64 x86_64
Alert Count 12
First Seen 2015-01-17
18:00:51 CET
Last Seen 2015-01-27 19:28:04 CET
Local ID e0b419ae-9eb4-45ec-9d8e-0ef19df4f5cb
Raw Audit Messages
type=AVC msg=audit(1422383284.804:154046): avc: denied { execmem }
for pid=21208 comm="luajit" scontext=system_u:system_r:prosody_t:s0
tcontext=system_u:system_r:prosody_t:s0 tclass=process permissive=0
type=SYSCALL msg=audit(1422383284.804:154046): arch=x86_64
syscall=mprotect success=no exit=EACCES a0=bce0000 a1=10000 a2=5
a3=47e items=0 ppid=1 pid=21208 auid=429496795 uid=991 gid=990
euid=991 suid=991 fsuid=991 egid=990 sgid=990 fsgid=990 tty=(none)
ses=4294967295 comm=luajit exe=/usr/bin/luajit-2.0.3
subj=system_u:system_r:prosody_t:s0 key=(null)
Hash: luajit,prosody_t,prosody_t,process,execmem
lancaster ~ # ll -Za /var/log/prosody
drwxrwx---. root prosody system_u:object_r:var_log_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_log_t:s0 ..
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0 debug.log
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0
debug.log-20130727
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0 error.log
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0
error.log-20130727
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0 info.log
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0
info.log-20130727
-rw-rw-r--. root prosody system_u:object_r:var_log_t:s0 prosody.log
An opinion on this ?
Best regards,
Matthieu Saulnier
--
Autorité de Certification: http://casperlefantom.net/root.pem
Empreinte: 0975 864A 2036 0F94 A139 114A D32E 8EBE 30F2 2429
Clef GPG ID: 83288189 @ hkp://keys.fedoraproject.org
Empreinte: CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189
6 years, 1 month
Re: Cannot start 2 VMs on F21
by Jerry James
I asked the question below on the virt mailing list about 2 weeks ago.
There have been a grand total of zero responses so far. I'll ask the
same question here, in hopes that somebody knows something that could
help.
On Wed, Jan 14, 2015 at 11:19 AM, Jerry James <loganjerry(a)gmail.com> wrote:
> Greetings,
>
> I recently upgraded my work machine from F20 to F21, via fedup. Now I
> cannot run two VMs at the same time, as I used to be able to do, at
> least with virt-manager. If I try to start a second VM via
> virt-manager, I get an error message:
>
> ------------------------------------------------------------------------------
> Error starting domain: Unable to read from monitor: Connection reset by peer
>
> Details:
> Error starting domain: Unable to read from monitor: Connection reset by peer
>
> Traceback (most recent call last):
> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
> callback(asyncjob, *args, **kwargs)
> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
> callback(*args, **kwargs)
> File "/usr/share/virt-manager/virtManager/domain.py", line 1388, in startup
> self._backend.create()
> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 999, in create
> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirtError: Unable to read from monitor: Connection reset by peer
>
> Close
> ------------------------------------------------------------------------------
>
> I can start any of my VMs, if there is no other VM running. After
> starting any VM, attempting to start any other VM as a second instance
> triggers this failure.
>
> I will paste the contents of /var/log/messages from the latest
> attempt. In this case, qemu-Rawhide32 is the VM that was already
> running, and had been running for some time, so I don't understand the
> "New machine" message. I'm trying to start the qemu-CentOS7 machine.
>
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): carrier is OFF
> Jan 14 11:02:36 diannao kernel: [94268.464579] device vnet1 entered
> promiscuous mode
> Jan 14 11:02:36 diannao kernel: [94268.467198] virbr0: port 3(vnet1)
> entered listening state
> Jan 14 11:02:36 diannao kernel: [94268.467211] virbr0: port 3(vnet1)
> entered listening state
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): new Tun
> device (driver: 'unknown' ifindex: 7)
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): exported
> as /org/freedesktop/NetworkManager/Devices/6
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (virbr0): bridge
> port vnet1 was attached
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): enslaved to virbr0
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: unmanaged -> unavailable (reason 'connection-assumed')
> [10 20 41]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): link connected
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: unavailable -> disconnected (reason
> 'connection-assumed') [20 30 41]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) starting connection vnet1'
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 1 of 5 (Device Prepare) scheduled...
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 1 of 5 (Device Prepare) started...
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: disconnected -> prepare (reason 'none') [30 40 0]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 2 of 5 (Device Configure) scheduled...
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 1 of 5 (Device Prepare) complete.
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 2 of 5 (Device Configure) starting...
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: prepare -> config (reason 'none') [40 50 0]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 2 of 5 (Device Configure) successful.
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 2 of 5 (Device Configure) complete.
> Jan 14 11:02:36 diannao dbus[838]: [system] Activating via systemd:
> service name='org.freedesktop.machine1'
> unit='dbus-org.freedesktop.machine1.service'
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 3 of 5 (IP Configure Start) scheduled.
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 3 of 5 (IP Configure Start) started...
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: config -> ip-config (reason 'none') [50 70 0]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> Activation
> (vnet1) Stage 3 of 5 (IP Configure Start) complete.
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: ip-config -> secondaries (reason 'none') [70 90 0]
> Jan 14 11:02:36 diannao NetworkManager[946]: <info> (vnet1): device
> state change: secondaries -> activated (reason 'none') [90 100 0]
> Jan 14 11:02:36 diannao dbus[838]: [system] Successfully activated
> service 'org.freedesktop.machine1'
> Jan 14 11:02:36 diannao kernel: device vnet1 entered promiscuous mode
> Jan 14 11:02:36 diannao kernel: virbr0: port 3(vnet1) entered listening state
> Jan 14 11:02:36 diannao kernel: virbr0: port 3(vnet1) entered listening state
> Jan 14 11:02:37 diannao systemd-machined: New machine qemu-Rawhide32.
> Jan 14 11:02:37 diannao systemd-machined: New machine qemu-CentOS7.
> Jan 14 11:02:37 diannao NetworkManager[946]: <info> Activation
> (vnet1) successful, device activated.
> Jan 14 11:02:37 diannao dbus[838]: [system] Activating via systemd:
> service name='org.freedesktop.nm_dispatcher'
> unit='dbus-org.freedesktop.nm-dispatcher.service'
> Jan 14 11:02:37 diannao dbus[838]: [system] Successfully activated
> service 'org.freedesktop.nm_dispatcher'
> Jan 14 11:02:37 diannao nm-dispatcher: Dispatching action 'up' for vnet1
> Jan 14 11:02:37 diannao systemd: Unit iscsi.service cannot be reloaded
> because it is inactive.
> Jan 14 11:02:37 diannao systemd: Unit named.service cannot be reloaded
> because it is inactive.
> Jan 14 11:02:37 diannao kernel: [94269.394707] qemu-system-x86:
> sending ioctl 5326 to a partition!
> Jan 14 11:02:37 diannao kernel: qemu-system-x86: sending ioctl 5326 to
> a partition!
> Jan 14 11:02:37 diannao kernel: qemu-system-x86: sending ioctl
> 80200204 to a partition!
> Jan 14 11:02:37 diannao kernel: [94269.394737] qemu-system-x86:
> sending ioctl 80200204 to a partition!
> Jan 14 11:02:37 diannao kernel: [94269.448193] virbr0: port 3(vnet1)
> entered disabled state
> Jan 14 11:02:37 diannao kernel: virbr0: port 3(vnet1) entered disabled state
> Jan 14 11:02:37 diannao kernel: device vnet1 left promiscuous mode
> Jan 14 11:02:37 diannao kernel: [94269.448871] device vnet1 left
> promiscuous mode
> Jan 14 11:02:37 diannao kernel: [94269.448894] virbr0: port 3(vnet1)
> entered disabled state
> Jan 14 11:02:37 diannao kernel: virbr0: port 3(vnet1) entered disabled state
> Jan 14 11:02:37 diannao NetworkManager[946]: <info> (vnet1): device
> state change: activated -> unmanaged (reason 'removed') [100 10 36]
> Jan 14 11:02:37 diannao NetworkManager[946]: <info> (vnet1):
> deactivating device (reason 'removed') [36]
> Jan 14 11:02:37 diannao journal: Unable to read from monitor:
> Connection reset by peer
> Jan 14 11:02:37 diannao NetworkManager[946]: <warn> (virbr0): failed
> to detach bridge port vnet1
> Jan 14 11:02:37 diannao NetworkManager[946]: nm_device_get_iface:
> assertion 'self != NULL' failed
> Jan 14 11:02:37 diannao NetworkManager[946]: <info> (vnet1): released
> from master (null)
> Jan 14 11:02:37 diannao systemd-machined: Machine qemu-CentOS7 terminated.
> Jan 14 11:02:37 diannao journal: error from service: TerminateMachine:
> No machine 'qemu-CentOS7' known
> Jan 14 11:02:38 diannao nm-dispatcher: Dispatching action 'down' for vnet1
> Jan 14 11:02:38 diannao gnome-session: Gjs-Message: JS LOG: Removing a
> network device that was not added
> Jan 14 11:02:38 diannao systemd: Unit named.service cannot be reloaded
> because it is inactive.
>
>
> It looks like there is some kind of trouble setting up the network for
> the second VM. Does anybody have any suggestions for things I could
> try to resolve this? Are there known issues with upgrading from F20
> to F21? Thank you,
--
Jerry James
http://www.jamezone.org/
6 years, 1 month
refactoring alternatives
by Frantisek Kluknavsky
Hi,
I have a packaging question. Package gnuplot contained binary
/usr/bin/gnuplot-wx. Subpackage gnuplot-qt contained binary
/usr/bin/gnuplot-qt with roughly the same functionality using different
GUI. Now it is time to declare qt default and wxGTK obsolete.
/usr/bin/gnuplot-qt should be in default package gnuplot,
/usr/bin/gnuplot-wx in subpackage gnuplot-wx.
My question is about alternatives. Both packages do something like
http://fedoraproject.org/wiki/Packaging:Alternatives suggests:
%preun
if [ $1 = 0 ]; then
%{_sbindir}/alternatives --remove gnuplot %{_bindir}/gnuplot-wx || :
fi
Now the name of the binary in package 'gnuplot' changes during an
update. But the package is not removed and the %preun scriptlet thinks
that old alternative should be left untouched.
What is the correct way to do this? My best idea so far is to increase
priority of new alternative. Old alternative will remain rotting but a
regular unknowing user will not notice broken symlinks after update.
Thank you very much and have a nice day.
Fero
6 years, 1 month
F22 Self Contained Change: Tunir
by Jaroslav Reznik
= Proposed Self Contained Change: Tunir =
https://fedoraproject.org/wiki/Changes/tunir
Change owner(s): Kushal Das <kushaldas(a)gmail.com>
Tunir is a self contained CI Continuous Integration [1] which will be used to
test Fedora Cloud images nightly. This tool can be used separately by any
developer in their Fedora 21 system to run/test their local tests/jobs.
== Detailed Description ==
Tunir is a very simple CI system written keeping Fedora Cloud images at mind.
At the same time it is generic enough to be used by anyone to configure and run
jobs/tests in their local system. We will be able to track the status of
nightly cloud builds, we can also keep track other changes like, the
dependencies pulled in, or the overall size of the images. The same tool can
used as a self contained CI system by any Fedora user to run their own tests
locally. The tool has a minimal dependency and very simple to configure and
maintain.
This tool right now can create vm(s) based on cloud images (without needing an
actual cloud), or can run the tests in a bare metal box, or it can even create
jobs inside Docker containers.
Example:
$ sudo tunir --job dockerjob --stateless
The above command will run a stateless job named "dockerjob", it will not save
the result into any database as it is a stateless run.
== Scope ==
* Proposal owners: kushaldas(a)gmail.com to work on tunir
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://en.wikipedia.org/wiki/Continuous_integration
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6 years, 1 month
F22 System Wide Change: Atomic Host
by Jaroslav Reznik
= Proposed System Wide Change: Atomic Host =
https://fedoraproject.org/wiki/Changes/AtomicHost
Change owner(s): Cloud SIG / Joe Brockmeier <jzb(a)fedoraproject.org> and Colin
Walters <walters(a)verbum.org>
New Fedora product: Fedora Atomic Host, an implementation of the Project
Atomic [1] pattern.
This is a continuation and expansion of Changes/Atomic_Cloud_Image [2].
== Detailed Description ==
The original Changes/Atomic_Cloud_Image was a host system delivered just as a
cloud image. This Change for Fedora 22 expands it to a multitude of delivery
vehicles:
* Bare metal support via Anaconda
* Cloud providers
** OpenStack/KVM qcow2
** EC2 AMI
** Google Compute Engine
* Vagrant boxes (OS X and vagrant-libvirt)
* Ultra-minimal LiveOS image designed for PXE booting diskless servers
== Scope ==
* Proposal owners: Maintain kickstart and tree configuration, integration with
Anaconda and other tools, maintain packages in Fedora
* Other developers: Unknown.
* Release engineering: Will need to generate trees during the general Fedora
compose process, and generate install media and cloud image based on trees.
* Policies and guidelines: May need updates for RpmOstree.
== Contingency Plan ==
* Blocks product? Yes, Atomic Host
If something fails and this product can't ship, some upgrade mechanism for
Fedora 21 Atomic Cloud Image users would need to be evaluated. The simplest
fallback is to tell those users to reinstall with a traditional Fedora 22
Cloud image.
[1] http://www.projectatomic.io/
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6 years, 1 month