I'm interested in looking up the source used for different builds on Koji -- particularly the exact commit to the spec file's repo, when building from SCM -- in a scriptable way.
`koji list-history` has the most filtering options, so it seems like it *ought* to work... but I can't figure out how to make it include the source. Possibly with the `--xkey` or `--show` switches? But neither `--xkey=source` nor `--show=source` seems to do anything. I can't tell what the property name would be to get the source commits for a given build here.
Or, `koji list-tasks` does show the commits -- but it can't filter by package name, and the full NVR and source commit are on separate lines, so I'm in regular-expression hell trying to figure out how to grep or sed the output such that it will show matching pairs of NVRs and source commits...
The license of giada has changed from “GPLv3+ and MIT and CC0 and GPLv3 and ISC and ASL 2.0 and BSD and zlib and IJG” to “GPLv3+ and MIT and CC0 and BSD” after the bundled VST 3 SDK and JUCE sources were excluded from the source tarball due to legal considerations. See https://email@example.com... for details if you are interested.
Tools such as ls or stat report the size of a directory. Of course it is
not the content size.
stat -c %s /home/sergio/.config
What does 6550 mean in btrfs context?
Thanks in advance!
LPIC-2 Certified - http://www.lpi.org
I would like to question the decision that was made by systemd
maintainers to remove the fallback DNS server list:
And then backported to F33:
On F33, this actually breaks a working vanilla cloud instance by
removing the fallback DNS server list in a systemd upgrade, effectively
leaving the system with no DNS servers configured.
I described this in more detail here:
Zbigniew Jędrzejewski-Szmek wrote the following in the commit message
accompanying the fallback DNS server list removal:
> So hopefully users will not see any effect from the change done in
> this patch. Right now I think it is better to avoid the legal and
> privacy risk. If it turns out this change causes noticable problems,
> we might want to reconsider. In particular we could use the fallback
> servers only in containers and such which are not "personal" machines
> and there is no particular person attached to them.
I would argue that the change causes noticeable problems and we want to
reconsider this change.
In particular, I think cloud image users would prefer to have their
cloud instances usable out of the box, i.e. have DNS working out-of-the
Don't get me wrong, I understand the privacy concerns and I think
Fedora should strive to protect the privacy of its users as much as
possible, but at the same time, the circumstances of a cloud instance
are probably very different from a e.g. workstation instance.
Possible solutions that come to mind:
1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.
2) Pick a reputable DNS resolver that preserves users' privacy and
doesn't log anything and configure it as a fallback DNS server.
Here is a good summary of DNS resolvers and their privacy:
P.S. I'm subscribed, but please keep me in Cc so I'll notice replies