Please, IMHO, resolve in some way the Samba MIT kerberos problem.
by Dario Lesca
Too many people (like also me) try to use samba-dc on fedora for deploy
a production AD DC controller, without know that MIT kerberos is
experimental and some useful things cannot work (es. win to win
access).
An recent last example:
https://lists.samba.org/archive/samba/2019-November/226845.html
> On 01/11/2019 22:23, Vex Mage wrote:
> > The script is expecting dpkg however this is a Red Hat
> > derived distro (Fedora Server.)
>
> Where did you get the Samba packages from ?
>
> If they are the default OS packages, then you should stop using
> them, they use MIT kerberos and are experimental.
There is many approach for resolve this issue:
a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos.
b) Produce a samba alternative package version (like, for example,
firefox-x11) build it with Heimdal Kerberos (es samba-hk-*)
c) Stop enable DC on Fedora, like RH/Centos do.
d) Notify users at the end of the installation that Fedora Samba DC is
experimental.
e) Solve the problems that make MIT kerberos experimental and put us in
a position to ask for help on the samba team.
f) ... some other proposal ?
What is the best approach chosen by Fedora ?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
4 years, 2 months
Copr Build System - review of 2019 and vote for features in 2020
by Miroslav Suchý
I want to sum up what happened in Copr during 2019. At the end of this email, you can see our TODO list and cast your
vote on what we should focus on.
During the year 2019:
* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including features as Jinja templates in configs, Dynamic BuildRequires,
subscription-manager support, which enables us to build on top of RHEL, Fedora Toolbox support, and container image
support which allows building using incompatible RPM.
https://github.com/rpm-software-management/mock/wiki#release-notes
To give credit - some of these Mock's features were contributed by community members.
* We removed outdated chroots, which allowed us to reclaim terabytes of disk space. At the same time, we give you the
option to keep those old repos if you want them.
http://frostyx.cz/posts/copr-removing-outdated-chroots
* we provided RSS feed
https://fedora-copr.github.io/posts/Copr-new-rss-feed
* we added project discussions by integration with https://discussion.fedoraproject.org
* your project can be marked as temporary, and we delete it automatically after a specified amount of days. This is
great for CI projects.
* we migrated from fedmsg to fedora-messaging
https://pavel.raiskup.cz/blog/copr-messsaging.html
* we provide anonymized DB dump so that you can play with our data
https://copr.fedorainfracloud.org/db_dumps/
* you can pin your favorite projects now
http://frostyx.cz/posts/create-your-portfolio-with-pinned-projects
* thanks to Amazon, we can use AWS for builders for free, which allowed us to use more builders.
* user Iucan rebuilds all R packages from CRAN for Fedora
https://copr.fedorainfracloud.org/coprs/iucar/cran/
* we are contributing to speed up createrepo_c, because that one is our biggest bottleneck. For projects like Cran or
python rebuilds, the createrepo task runs longer than the build of package and cannot be parallelized.
* Many interesting projects appeared in Copr and we wrote about them
https://fedoramagazine.org/?s=cool+new+projects+to+try+in+COPR
* Added per-package config option to blacklist the package from building against particular chroots
* Added support for multilib projects https://pagure.io/copr/copr/issue/1181
* Refined modularity support, module dependency, module_hotfixes flags, ...
* Copr permissions can now be set via API and CLI.
* Removing old builds automatically, per option that only keeps a maximum number of builds per given package.
What are our plans for 2020? We have some mandatory tasks:
* migrate to new datacenter together with the whole fedora-infrastructure
* install and use new and bigger storage
Yet we have quite a long list of RFEs and tasks to do. As **you** are our customers, I would like to hear your opinion
on what is crucial for you.
Please cast your vote here:
https://forms.gle/GXWaZ1yzmkPJmeQw9
Options:
* allow more parallel builds - everyone wants faster builds. I am afraid we cannot speed up the build itself, but we
can focus on allowing us to run more builds in parallel to handle peaks.
* Mock development - we spend a lot of time on Mock development. We utilize those new features in Copr, but they are
useful even for your local workflow with Mock. Should we spend more time on longstanding RFEs?
* build Flatpak application from your project - we have a viable idea how to build Flatpak app from your project with
just a few clicks, and we can upload the result to some registry. E.g., to https://quay.io/
* new commands for our API and copr-cli
* run lints like rpmlint or rpm-inspect after each build and give you hints on how to improve your spec files
* automatically rebuild PyPI and Rubygems - we already did this in the past, but we did not rebuild it for new Fedoras
* allow you to vote for quality of the project with thumbs up/down and high quality repos automatically promote and
will enable them as one big repo of "editors pick".
* focus on rpm spec generators - See https://docs.pagure.org/copr.copr/user_documentation.html#scm what we support
right now.
* add emulated architecture s390x - while we would like to add native architecture, it will likely not happen next
year, but we can do builds using QEMU.
* add RHEL as a target - right now you can build on top of CentOS, but we can allow you to build on top of RHEL
* better automatic builds triggered by GitHub, Gitlab, aka mimic the Copr CI we have for Pagure - git server sends
request - copr replies back with build status
* runtime dependency config between copr projects, so `dnf copr enable <user/foo>` enables other projects transitively
* something else - is something blocking you from using Copr? Please share it with us.
Please cast your vote here:
https://forms.gle/GXWaZ1yzmkPJmeQw9
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
4 years, 2 months
Self Introduction: Erich Eickmeyer
by Erich Eickmeyer
Hello all!
I'm Erich, the current project leader of Ubuntu Studio, the creativity-oriented flavor of Ubuntu. I've been leading that project for the past two years.
In that time, my team and I have taken Ubuntu Studio strides from where it was. However, due to some circumstances I will not mention here, we are looking for an alternative, and Fedora, with the Fedora Jam lab and with CCRMA's attention, seemed to be the perfect place to land. That said, it seems as though the Jam lab is dead, so I am here to revive it with mattdm's blessing.
We revamped a tool called Ubuntu Studio Controls (https://help.ubuntu.com/community/UbuntuStudio/UbuntuStudioControls), which makes audio configuration for Jack super simple. We wish to port that tool to Fedora, so I, with the help of another, will be working on packaging that, possibly naming it Studio Controls or Jam Controls.
I bring with me a team of people, including the primary developer of Ubuntu Studio Controls. We intend to make Jam a great project for musicians and audio engineers alike. I've been doing audio engineering for nearly 26 years, so this is an area that's completely within my wheelhouse.
In order to do the Self-Contained Change Request required, I need to be CLA+1, so that's the motivation behind joining the packaging group or whatever other group anyone feels is relevant to this project.
Thanks for reading!
Erich Eickmeyer
4 years, 2 months
Re: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer
by Sandro Bonazzola
Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha
scritto:
> Hi Sandro,All,
>
> Can I upgrade the tools on existing VM , or it requires a fresh one? Best
> Regards
>
If you have oVirt windows guest tools already installed suggestion is to
uninstall it before installing this new installer.
> Best Regards,
> Strahil Nikolov
> On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>
> Hi,
> as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
> Drivers installer using the open source framework WiX.
> Thanks to the virtio-win maintainer, the new installer is not shipped
> anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
> Windows ISO[1]
>
> Please give it a run on your testing environment / testing VMs and let us
> know about your experience at devel(a)ovirt.org.
> Thanks,
>
>
> [1]
> https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-...
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbonazzo(a)redhat.com
> <https://www.redhat.com/>*Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.*
>
>
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
4 years, 2 months
List of long term FTBFS packages to be retired in a week
by Miro Hrončok
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (2020-02-03).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
There is an open exception request for shim-unsigned-aarch64 and
shim-unsigned-x64, but it has not yet been approved -- if it gains no negative
votes within 1 day, it will be:
https://pagure.io/fesco/issue/2331
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
zbyszek
expresso jamielinux, nodejs-sig, Fedora 28
patches
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
server
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones (exception request) Fedora 28
shim-unsigned-x64 pjones (exception request) Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
nuvola-app-plex
nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 2 months
Strange "directory removed" dependencies in some RPMs
by Fabio Valentini
Hi everybody,
I've noticed these a few times now, and I have *no idea* where this is
coming from, for example:
dnf --releasever=rawhide --repo rawhide --repo rawhide-source
repoquery --source --requires python-pytest-harvest
lists:
directory
pyproject-rpm-macros
python3-devel
python3dist(decopatch)
python3dist(makefun) >= 1.5
python3dist(packaging)
python3dist(pandas)
python3dist(pypandoc)
python3dist(pytest-runner)
python3dist(pytoml)
python3dist(setuptools-scm)
python3dist(six)
python3dist(tabulate)
python3dist(wheel)
removed
Aaaaaand the "directory" and "removed" entries are obviously bogus.
Does anybody have an idea what's going on? Maybe a dependency
generator is still running while RPM is already cleaning up the build
directory?
Fabio
4 years, 2 months
unison can't be compiled in Rawhide
by Richard W.M. Jones
Previously:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.htm...
Unison is a file synchronization tool written in OCaml. The binary
protocol isn't compatible from one major release to the next, so to
provide compatibility with the broader ecosystem of Unison on other
Linux distros we have 3 branches of it in Fedora:
unison213 (upstream release 2.13)
unison227 (upstream release 2.27)
unison240 (upstream release 2.40)
We don't package upstream releases 2.48 or 2.5x in Fedora at all.
Anyway the news is that none of these branches can be compiled with
our OCaml 4.10.0-beta-1 compiler. For the past 5 years OCaml has been
introducing safe, immutable strings. This has required code changes
so was introduced gradually, but the last step happens next month when
OCaml 4.10.0 final is released. In OCaml 4.10 the -unsafe-string
option is disabled, so code must be updated to use immutable strings.
Even the upstream version of Unison has not been ported to use safe
strings (ie requiring the -unsafe-string option), never mind the older
branches that we're packaging.
I did attempt a safe string port and ... it's complicated. The code
does a lot of byte string manipulation all over the place using its
own custom functions with four letter function names, single letter
variable names, and no comments.
(Don't believe me? Here's the first function that would need to be
fixed:
https://github.com/bcpierce00/unison/blob/26a29f79487484b7982c85e0dc879cf... )
If we were to package Unison properly in Fedora (apart from fixing
the big mess above), I would prefer that we had a single unison
package which built multiple versioned unison subpackages. I had
a proof of concept of this a few years ago.
It looks as if Unison will be orphaned and retired unless someone who
cares persuades upstream to move to immutable strings and backport the
same work to the older branches.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4 years, 2 months
Fedora 31 Network Strangeness
by Steve Dickson
Hello,
I've recently updated my laptop to F31. Then I was no longer
able to ssh into it. After a little debugging... it turns
out my laptop was not getting the expected ip address
from DHCP. The reason for that was the MAC address it was
sending to dhcpd had change!!! Looking at the interfaces
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.31.1.175 netmask 255.255.0.0 broadcast 172.31.255.255
inet6 fe80::98f9:f0d0:4b79:cdaa prefixlen 64 scopeid 0x20<link>
ether 3a:00:66:8a:dd:b9 txqueuelen 1000 (Ethernet)
RX packets 259601 bytes 112149182 (106.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 256704 bytes 39319273 (37.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 8c:16:45:fe:c1:f1 txqueuelen 1000 (Ethernet)
RX packets 355186 bytes 134328851 (128.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 256743 bytes 40395059 (38.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xec200000-ec220000
The bridge0 interface has as different MAC that the enp0s31f6 interface.
How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
is set in the ifcfg-bridge0_slave_1.
What has changed and where is the bridge MAC address coming from???
tia,
steved.
4 years, 2 months