[golang packaging] how to get files from source tarball
by Zdenek Dohnal
Hi,
I'm trying to package ipp-usb project
(https://github.com/OpenPrinting/ipp-usb) which is written in Go. I
generated spec file via go2rpm, but several files from source tarball
which supposed to be packaged is not packaged e.g. systemd unit file
ipp-usb.service or udev rule file 71-ipp-usb.rules.
I managed to package those files with following install command e.g.:
install -m 0644 -vp
%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules
%{buildroot}%{_udevrulesdir}
but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly -
is there a predefined golang macro for such path? Or a best practice?
Thank you in advance,
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
3 years, 9 months
fedora-review fails with "warning: line 16: Possible unexpanded macro
in: Requires .."
by Martin Gansser
Hi,
when I want to do a review with: fedora-review -m fedora-rawhide-x86_64 -b 1873407
i get this error message:
warning: line 16: Possible unexpanded macro in: Requires: vdr(abi)(x86-64) = %{vdr_apiversion}
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1598313600
Wrote: /builddir/build/SRPMS/vdr-skinelchihd-0.5.0-1.fc34.src.rpm
Child return code was: 0
Mock Version: 2.4
.. that's all I get in the build.log
How can i solve this ?
Regards
Martin
3 years, 9 months
Can a bugzilla issue be locked because of spam?
by Christopher
This old issue (https://bugzilla.redhat.com/show_bug.cgi?id=1177202)
keeps receiving spam every couple of weeks from a different account.
I've been trying to flag the spam comments as spam, and remove the
flags they keep setting, and remove their CC as well, so they don't
get follow-ups and get encouraged to continue spamming. However, they
keep doing it. It's really quite annoying. Is there any way it can be
locked or restricted to committers?
3 years, 9 months
NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide
Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...
== Summary ==
Change the default settings plugin of NetworkManager so that new
profiles will be created in keyfile format instead of ifcfg-rh format.
== Owner ==
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com>
== Detailed Description ==
NetworkManager supports settings plugins to persist connection
profiles to disk. There is the native ''keyfile'' format and the
Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
The keyfile plugin is always enabled in NetworkManager and can handle
any supported type of profile. It stores profiles under
`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
documented in [https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
with the network-scripts package from initscripts, however both
network-scripts and NetworkManager define their own extensions
([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
[1]]). Since network-scripts and NetworkManager are fundamentally
different, the same ifcfg file is not treated exactly the same by both
systems. In the past, having the ifcfg-rh format made it easier for
users familiar with initscripts to migrate to/from NetworkManager.
The settings plugins are configurable in
[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
can be configured and on Fedora 32 and older, the compile time default
for the option is `"ifcfg-rh,keyfile"`. This means, that when
NetworkManager stores a new profile to disk, it will first try to
persist it in ifcfg-rh format before falling back to keyfile format,
if the ifcfg-rh plugin doesn't support the profile type. When reading
profiles from disk, NetworkManager will read and expose profiles from
both settings plugins and when modifying an existing profile, it will
update the existing file and preserve the settings plugin.
This Change is about to change the default for `"main.plugins"` from
`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
== Feedback ==
This was brought up on the NetworkManager mailing list
([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00002.html
[1]]]).
Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
too. For CoreOS this of course is simpler, because they don't deal
with existing user configurations and tools that would break during
upgrade.
== Benefit to Fedora ==
The long term goal of NetworkManager is to move away from ifcfg-rh
files. That will be difficult as it affects existing installations and
will require migration of existing configurations. This change is only
a first step and affects how NetworkManager by default persists new
profiles to disk.
The ifcfg-rh format arguably has an uglier syntax and, contrary to
keyfile, does not support all profile types. Also, keyfile plugin is
available on every NetworkManager installation because that is the
only plugin that supports all profiles. Having multiple plugins and
file formats is confusing. By now, initscripts' `network-script`
package is deprecated in Fedora and upstream wants to move away from
that format in the long term. Also maintaining multiple settings
plugins is a maintainance burden, and in the past there were subtle
bugs where ifcfg-rh did not implement all settings (e.g.
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
CVE-2020-10754]). On other Linux distributions NetworkManager uses the
keyfile format by default. It is a general goal that NetworkManager
works similar on all distributions.
== Scope ==
* Proposal owners: The default settings for `"main.plugins"` can
already be selected at compile time. This only requires building the
package with a different default
([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38ba...
[3]]).
* Other developers: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This affects most users, unless they explicitly set the option in
NetworkManager.conf configuration. The biggest effect of this change
is that new profiles will now preferably be persisted in keyfile
format. This changes behavior for users who expect NetworkManager to
write ifcfg-rh files, or who have scripts or tools that expect that.
What will still work is that existing ifcfg files are loaded after
upgrade. Users who only use the D-Bus API (via one of the client
applications like nmcli or the GUI), shouldn't notice the difference.
As before, users still can explicitly configure the settings plugins
in NetworkManager.conf. This only affects the default, but it affects
existing installations if the user didn't explicitly configure
NetworkManager's `"main.plugins"` option.
The Change will be implemented by changing the compile time default,
instead of dropping a configuration snippet. The reason is that it is
preferably that the installation of NetworkManager avoids extra
configuration. The default behavior should be achived without any
configuration. During package update there would be the possibility to
drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that
preserves the previous behavior. However, I don't think that is
necessary. After upgrading NetworkManager, it will still read ifcfg-rh
file so for the user it is less necessary to preserve the previous
behavior. Also, dropping configuration snippets during package upgrade
has its own downsides because new installations behave different than
upgraded systems.
== How To Test ==
You can already test the effect by explicitly configuring the setting
which will become the default. For example, add a file
`/etc/NetworkManager/conf.d/99-main-plugins.conf` with content
[main]
plugins=keyfile,ifcfg-rh
== User Experience ==
NetworkManager now preferably uses the keyfile format (INI files).
This format is probably easier to understand to users and also has a
closer resemblance to how the profile is presented in nmcli.
If the user is using NetworkManager tools that use the D-Bus API (like
nmcli or the GUI), then the used storage plugin and format is usually
of no concern for the user.
== Dependencies ==
None
== Contingency Plan ==
The `"main.plugins"` option exists for a long time in NetworkManager.
All that changes here is the default of this option.
* Contingency mechanism: revert the change
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
I am not aware of documentation that gets affected by this.
== Release Notes ==
NetworkManager now prefers the keyfile settings plugin over ifcfg-rh
plugin when writing new connection profiles to disk. Existing ifcfg-rh
files are still handled as before.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
Re: Release criteria proposal: networking requirements
by Steven Bonneville
Pardon me for thread-breaking, I read in digest mode.... :)
On Fri, Aug 28, 2020 at 16:56:26 -0700 <adamwill(a)fedoraproject.org> wrote:
> > What about mDNS?
>
> ehhhhhhh
>
> I am probably a bit biased on this front because I always found mDNS to
> be a pile of garbage and gave up trying to use it a while back. :P But
> if a significant amount of people are actually using it and relying on
> it, adding it might make sense. Anyone else have input on this? Who out
> there does use mDNS?
>
IPP Everywhere for printer discovery and driverless printer configuration
uses mDNS. Pretty much every modern network printer supports it (because of
Apple AirPrint and so on) and if it's working properly in the distribution
it can make printer discovery and printer configuration simpler for CUPS.
-- Steve
--
Steven Bonneville <sbonnevi(a)redhat.com>
Principal Technical Curriculum Architect
Red Hat | Red Hat Training
3 years, 9 months
