On Tue, Mar 29, 2022 at 5:05 PM Mattia Verga via devel
wrote:
> Maybe BR overrides usage should be restricted only to users with special
> needs (users in provenpackager or releng groups), while "normal" users
> should be forced to take the side-tag way?
As always, there are special cases. I
On Wed, Mar 23, 2022 at 7:54 PM Richard Shaw wrote:
> Clang doesn't understand some options that gcc does, and a lot of it depends
> on the version of clang IIRC. For a while Fedora maintainers would modify
> clang to at least silently ignore these options but now it's much easier to
>
On Wed, Mar 23, 2022 at 6:55 PM Ron Olson wrote:
>
> Hey all-
>
> I’m trying to build a new version of a package and got the aforementioned
> error, but only under EPEL 8, all other builds (Rawhide, F35, F34, EPEL 9)
> built fine. The failed build is at
>
On Tue, Mar 8, 2022 at 6:40 PM Alexander Sosedkin wrote:
> Good news is, RHEL-9 is gonna lead the way
> and thus will take a lot of the hits first.
> Fedora doesn't have to pioneer it.
> Bad news is, Fedora has to follow suit someday anyway,
> and this brings me to how does one land such a
On Mon, Mar 7, 2022 at 5:03 AM Gordon Messmer wrote:
> I remember in the early days of deltarpm, it would frequently reduce the
> download size on my systems by 70-90%. I know that some people disliked
> that it made updates slower, but I always thought that reducing the
> bandwidth costs at
On Mon, Feb 28, 2022 at 5:25 PM Kevin Fenzi wrote:
> No, there's things we can do and are trying to do. ;)
I seem to remember that one of the issues
identified was (for those of us using gmail
for the notifications) was that google could
end up throttling emails.
I have a vague recollection
On Thu, Feb 24, 2022 at 7:14 PM Zbigniew Jędrzejewski-Szmek
wrote:
> systemd-analyze security shows whether units use systemd hardening
> features. Those units may well use other features, and may well be
> very secure.
My vague recollection from running systemd-analyze security
from some time
On Thu, Mar 3, 2022 at 1:45 PM Richard Shaw wrote:
> In this instance, it's not clear to me whether sub-type changes are ABI
> breaking or not...
Looking only at the output of the compare, those are
ABI breaking changes, and you will need to rebuild
deps, but if those deps are actually using
On Wed, Mar 2, 2022 at 5:06 AM Demi Marie Obenour wrote:
> What would it take to get tall of the users of QtWebEngine onto 6.2? I
> don’t think Fedora should ship any version of QtWebEngine except the
> latest, since only the latest version appears to get regular patches.
Well, it is slightly
On Mon, Feb 28, 2022 at 3:00 AM Neal Gompa wrote:
> We do also have OpenH264 support enabled via dlopening the library, so
> if the openh264 package is present on the system, it'll "just work"
> and provide H.264 support. If it is not installed, it'll return the
> correct error for applications
On Mon, Feb 28, 2022 at 2:46 AM Ian McInerney via devel
wrote:
> 1) How are these removed codecs handled in the library? Can we link an
> upstream application against FFMPEG in Fedora now and have it gracefully fail
> when it tries to access a non-free codec that was removed, or does the
>
On Sat, Feb 26, 2022 at 8:44 AM Kevin Kofler via devel
wrote:
>
> Florian Weimer wrote:
> > Fedora doesn't require this yet.
>
> … and will hopefully not do so any time soon!
Just as with the elimination of 32-bit support
(both x86, and the upcoming arm retirement)
there will come a time for
On Fri, Feb 25, 2022 at 5:42 PM Ron Olson wrote:
> I guess there was some CPU requirement change that I didn’t catch;
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
discussed the issue(s), and the x86_64 v2
On Thu, Feb 24, 2022 at 12:56 AM Chris Murphy wrote:
> And my understanding is it's required for
> Windows 11 preinstallations.
Except if your country has required that TPM not
be used, and as Microsoft did not want to prevent
billions of people from using Windows 11 those
locations are exempt
On Wed, Feb 23, 2022 at 11:55 PM Chris Adams wrote:
>
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> > After=network-online.target, which means that it'll delay the boot.
>
> If that's the problem, there's some
On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel
wrote:
> OTP is absolutely free. FIDO2 requires the purchase of a special
> hardware token.
Not necessarily. Not only can some mobile devices
present the needed credentials (as if they were an
external hardware token), but as I recall
On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi wrote:
> I don't think there's any way in IPA to require otp as a requirement for
> group membership currently. (Please let me know if there is).
> Which would leave us checking after the fact and removing people without
> one set, which is a big pile
On Tue, Feb 22, 2022 at 5:42 PM Chris Murphy wrote:
> $ cat /usr/lib/systemd/system/packagekit.service
> [Unit]
> Description=PackageKit Daemon
> # PK doesn't know how to do anything on ostree-managed systems;
> # currently the design is to have dedicated daemons like
> # eos-updater and
On Tue, Feb 22, 2022 at 5:43 PM Zbigniew Jędrzejewski-Szmek
wrote:
> No, no. dnf-makecache.timer is "asynchronous" — it is not part of
> multi-user.target. It is reasonable to order it after network is up
> because this way it can just do its thing without spurious noise about
> failed
On Mon, Feb 21, 2022 at 8:35 AM Alexander Bokovoy wrote:
> This is not ready for general consumption but we plan to have something
> to submit to Rawhide in a month or so. Enrolling IPA users into this
> would be similar to already existing RADIUS proxy authentication path in
> FreeIPA.
On Sun, Feb 20, 2022, 16:09 Adam Williamson
wrote:
> It used to support these, but the support was lost with the recent
> rewrite. However, it supports Google Authenticator-style OTPs. Folks
> with infra privileges on their accounts (like me) are already required
> to use these. It works fine. I
On Sun, Feb 20, 2022 at 4:01 PM Demi Marie Obenour
wrote:
> I think we should also require security key-based 2fa for all
> packagers.
In a previous discussion on this topic that was
suggested (and at least partially rejected(*)).
Many (larger) orgs have decided that issuing
hardware security
On Sat, Feb 19, 2022 at 8:21 PM Miro Hrončok wrote:
> Once I remove the Obsoletes line from Fedora, should I worry about merging
> that
> commit to the epel9 branch or not? Logic dictates that the Obsolete should
> remain in EPEL 9 forever, but I wonder if there is a policy/rule of thumb.
>
On Fri, Feb 11, 2022 at 10:43 AM Ian McInerney via devel
wrote:
>
> On Fri, Feb 11, 2022 at 10:39 AM Björn Persson wrote:
>>
>> Yes, that's a bad search. Till Maas told me eight years ago that the
>> release monitoring tickets are supposed to remain open when the
>> packages are upgraded. Thus
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton wrote:
> I have concerns with this approach. I would guess there's a long tail
> of packagers that maintain relatively few packages. These packages
> might not have frequent upstream releases or require new manual
> builds.
There are a lot of packages
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
wrote:
> That is referring to provenpackagers only. I'd like this to be extended
> to users in packagers group also.
FWIW, the last time this came up, there was
a vague idea to require a yearly resigning
of the CLA (or something equivalent,
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
wrote:
> That is referring to provenpackagers only. I'd like this to be extended
> to users in packagers group also.
Given that provenpackagers are group
that can do the most potential damage,
that process arguably covers the users
in the
On Sat, Feb 5, 2022 at 9:04 PM Kevin Fenzi wrote:
> Well, it's not any specific timeframe we can promise here.
Of course not. But it is clearly not "soon".
> Take a look at:
> https://admin.fedoraproject.org/mirrormanager/propagation
>
> You can see the two days recently we got rawhide
On Fri, Feb 4, 2022 at 11:32 AM Ian McInerney via devel
wrote:
> From a user experience perspective, the mirror lag time on it is very
> annoying. When the update is pushed to testing, Bodhi posts a comment in the
> associated Bugzilla saying that you should "soon" be able to install the
>
On Fri, Feb 4, 2022 at 2:05 PM Richard Shaw wrote:
> So most of them work, but not EPEL.
That specific example is being tracked in RHBZ #2049024
The discussion started back in November 2021
On Tue, Feb 1, 2022 at 9:27 PM Richard Shaw wrote:
>
> I just did a local mock build of the latest version of OpenImageIO which was
> just released and saw this on every cpp line:
>
> annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp:
> Warning: -D_GLIBCXX_ASSERTIONS not
On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi wrote:
> The limited arch policy we had for epel7 had a number of problems.
> At first we just said 'rebuild the exact rhel version' and then we
> switched to 'add a 0 to release so the rhel package always gets
> installed in favor of it'.
It
On Fri, Jan 21, 2022 at 3:27 PM Vít Ondruch wrote:
> Isn't it just the standard GMail deduplication?
Likely. For better or worse, that is the way gmail works.
One can see both the advantages and disadvantages
of the gmail approach, but it does catch some of the
people off-guard at least some
On Sat, Jan 15, 2022 at 6:29 PM Orion Poplawski wrote:
> I don't buy any of these arguments, and it doesn't really address the
> situation of "missing -devel" packages.
The missing devel packages for shipped libraries
are a clear pain point for those that just want build
something for their EL
On Tue, Jan 11, 2022 at 6:39 PM Andrew Bauer
wrote:
> I’ve read the EPEL documentation regarding incompatible upgrades, and I am
> not entirely sure this falls under that category. Yes, it is a major version
> upgrade, but it is unclear to me if that makes it “incompatible”.
As I recall, v3
On Tue, Jan 4, 2022 at 10:09 AM Florian Weimer wrote:
>
> Or is it still banned in Fedora?
>
> We have some scripts that are dual Python 2/Python 3, and Fedora tooling
> forced us to carry a downstream-only patch to replace /usr/bin/python
> with /usr/bin/python3. I'd like to remove this patch.
On Sat, Dec 25, 2021 at 8:16 PM Fabio Valentini wrote:
> (the community blog might be the right place for some of those,
> but it is a higher barrier to actually write a blog post that gets
> edited etc. instead of writing an e-mail to a mailing list).
The Fedora Community Blog and the Fedora
On Wed, Dec 22, 2021 at 11:56 PM Jakub Kadlčík wrote:
> TL;DR What about a place where people could ask for something to be
> packaged in Fedora?
There is https://fedoraproject.org/wiki/Package_maintainers_wishlist
___
devel mailing list --
On Sun, Dec 5, 2021 at 4:09 AM Kevin Fenzi wrote:
> yes, yesterday.
>
> See the announcement:
> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/
*sigh*. Sorry, I missed it (I think I need to
add yet another mail list
On Sun, Dec 5, 2021 at 4:09 AM Kevin Fenzi wrote:
> yes, yesterday.
>
> See the announcement:
> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/
*sigh*. Sorry, I missed it (I think I need to
add yet another mail list
Now that CentOS Stream 9 is announced as
available, is there a schedule for when EPEL-9
branches can be made, and when one can
(start to) ask others to build for EPEL-9
(it would be nice if a number of the EPEL-9
packages were preliminarily ready at the time
of the EL-9 formal release (just,
On Mon, Nov 29, 2021 at 7:05 PM Matthew Miller wrote:
> I mean... that would have been a good way to make sure everyone at least
> provided some answer, but I don't think we have (or should have) any rule
> against asking FESCo or Council people questions at other times.
I think asking FESCo or
On Mon, Nov 29, 2021, 10:06 Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
>
One should have proposed such a question
during the
On Thu, Nov 25, 2021 at 8:05 AM Miroslav Suchý wrote:
> I wrote down the possible options and their pros and cons and I done my best
> to catch all the feedback here.
Thanks.
Another idea occurred to me, similar to "D"
(use alternatives) and incorporates "A" (delete
the current epel-8) for
On Mon, Nov 22, 2021 at 2:01 PM Pavel Raiskup wrote:
> First I don't feel comfortable announcing this, I'm not happy about the
> situation and so I don't want to be the lightning rod :-).
I do not believe anyone should blame you for bringing
this up (although, it should be noted, killing the
On Thu, Nov 18, 2021 at 11:10 PM Arthur Bols wrote:
>
> Hi,
>
> Does anyone know if Seth Jennings (sjenning) is stil active in Fedora? I
> sent him an email in June without response.
> The package pam-u2f has been outdated for a while and I've created the
> non-responsive maintainer bug [1].
On Thu, Nov 18, 2021 at 2:32 AM Josh Stone wrote:
>
> On 11/16/21 7:05 PM, Kevin Kofler via devel wrote:
> > Realistically, they will just stick to Fedora 36 forever and just stop
> > updating the devices (or try updating them anyway and get no updates from
> > the server, obviously).
> >
> >
On Mon, Nov 15, 2021 at 7:16 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/RetireARMv7
>
I cannot recall the last time I tried to run a full armv7 desktop
(which, I would guess, generate a significant percentage of
the large app build failures since the "desktop" apps are,
On Thu, Nov 11, 2021 at 2:55 PM Miro Hrončok wrote:
>
> Hello,
>
> Since this update:
>
> https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide
>
> Nothing in rawhide builds, because Python and hence dnf is not installable:
>
Is it possible to
On Tue, Nov 9, 2021 at 8:42 AM Aleksei Bavshin
wrote:
> A module can load a firmware binary with the `request_firmware` API at
> any moment of it's lifetime. Usually, this happens when the module is
> initialized or discovers a new supported device, but I don't believe
> that is a strictly
On Sun, Nov 7, 2021 at 2:22 AM Demi Marie Obenour wrote:
> I have almost always seen it *increase* download times,
In my experience, while the download times may
be (slightly) reduced, on a number of my (slower)
systems, the rebuild of the rpm itself took longer
then it would have taken to
On Tue, Nov 2, 2021 at 7:30 PM Adam Williamson
wrote:
> Further to this .
Thanks for the report on your research.
When there are enough fragile moving parts,
sooner or later something goes sideways
___
devel mailing list --
On Mon, Oct 4, 2021 at 11:08 PM Gary Buhrmaster
wrote:
>
> On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson wrote:
>
> > I was going to ask people if they
> > were interested in them but I decided to straight up orphan them so
> > they#ll can go through the usual garbag
On Tue, Oct 5, 2021 at 12:21 AM Sérgio Basto wrote:
> I wonder if kodi shouldn't use cec from kernel [1] instead libcec
Perhaps, perhaps not. The recent libcec
for Linux uses the kernel functionality, but
(mostly) maintains the existing API. So
for an application which is trying to be
cross
On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson wrote:
> I was going to ask people if they
> were interested in them but I decided to straight up orphan them so
> they#ll can go through the usual garbage collection process unless
> someone claims them.
> libcec
> platform
I'll volunteer to take
On Mon, Oct 4, 2021 at 8:58 AM Vít Ondruch wrote:
> Thoughts?
Anything that improves the onboarding
process can only be a good thing.
I would recommend that before going
too deep into weeds that you need a
small group of "non-packagers"(*) to
see if this is the right approach from
their
On Wed, Sep 15, 2021 at 9:40 PM Fabio Valentini wrote:
> Thanks, that did the trick.
> But of course somebody built stuff during the side-tag window and now
> it can't be pushed. *le big sigh*
This seems to happen every time there is a
large(ish) side-tag. I do wish that (probably
using a
On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel
wrote:
>
> On 28/07/2021 15:07, Ben Cotton wrote:
> > Updates of user services take effect immediately (if so configured in
> > the providing packages).
>
> Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will
> cause a
On Mon, Jul 12, 2021 at 12:54 AM Jakub Kadlcik wrote:
> I am happy to announce that I deployed this little site
> https://docs.pagure.org/fedora-sponsors/
Thank you for doing this. Anything that reduces
the impedance for new people is overwhelming
a good thing.
It is easy for forget
On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel
wrote:
>
> On 06/07/2021 23:27, Christian Stadelmann wrote:
> > In other words: I think it is too early to drop non-(U)EFI BIOS support.
>
> Btw, the upcoming Windows 11 will require full UEFI support, enabled
> UEFI Secure Boot and TPM 2.0.
On Wed, Jun 23, 2021 at 8:58 AM Nico Kadel-Garcia wrote:
> I can't find *anyone* who likes modularity.
I like the concept of modules. But primarily
only if someone else is doing the actual
hard work that ends up being necessary
to build them.
___
On Thu, Jul 1, 2021 at 8:57 AM Miroslav Suchý wrote:
> Hmm, this should be easy to implement. Just one wiki page. I created:
>
> https://fedoraproject.org/wiki/Packagers_for_hire
>
> Comments?
Rather than a wiki for which people may not
reliably curate (i.e. remove themselves) or
respond to
On Tue, Jun 15, 2021 at 9:55 PM Neal Gompa wrote:
> Yeah, I think that proposal was not workable because of AVX2. The
> x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> current x86_64 baseline. All of these instructions were present in the
> first Intel Macs launched in
On Fri, May 28, 2021 at 4:42 PM PGNet Dev wrote:
> I'd bet $0.05 and a half-eaten donut that most folks
*Most* folks are not the deciders. The deciders
(for their particular projects) have decided,
presumably based on what they believe is best
for their community. In this case, for
On Wed, May 12, 2021 at 9:49 AM Евгений Пивнев wrote:
>
> Is there any real package .spec that use cc-toolset-9 as example?
> SCL documentation is too extensive and mostly about creating new SCL,
> I cannot find short description how simply to make one new package using
> modern C++.
>
Not sure
On Fri, Apr 30, 2021 at 5:18 PM Vitaly Zaitsev via devel
wrote:
>
> On 30.04.2021 16:23, Richard W.M. Jones wrote:
> > Because distributing SSH keys to temporary VMs is hard?
>
> Kickstart + Ansible will fix all these issues.
Or, perhaps, cloud-init, for those using that approach.
On Fri, Apr 23, 2021 at 3:57 PM Daniel P. Berrangé wrote:
> This is quite a niche problem that's unlikely to cause issues
> for most people, but its a illustration that swapping compilers
> out can have unexpected consequences/complications.
Presuming I am remembering my s390x history
On Fri, Apr 23, 2021 at 3:38 PM Neal Gompa wrote:
> To me, this sounds like an excuse to avoid doing the right thing and
> leveraging the toolchain that offers the highest quality code
> generation (performance, security, etc.).
I am not in favor of switching the distro (or any
package) to the
On Fri, Apr 23, 2021 at 3:30 PM Ben Cotton wrote:
> Or is it just a way of saying "we trust you to exercise good judgment"?
If one does not trust the packagers good
judgement you likely have a bigger
issue to address.
I doubt many packagers are going to
change from the default compiler
unless
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the
On Fri, Apr 16, 2021 at 4:31 PM David Cantrell wrote:
> 2) I'm curious why GDBM was chosen instead of something like sqlite.
I believe sasldb only supports gdbm and
ndbm as alternatives to bdb.
___
devel mailing list -- devel@lists.fedoraproject.org
On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek
wrote:
> There is no good way to do this.
This is one of those cases where I occasionally
miss a mainframe fix update feature to prevent
certain bad automated results.
In SMP/E, there was the concept of HOLD's for
a fix. There were a
On Mon, Feb 15, 2021 at 6:39 PM Dan Horák wrote:
> The open question still is whether we should try to keep 64k as default
> as it would allow to find the remaining bugs and offer 4k kernel variant
> (COPR for ppc64le should be coming back soon), similar for the
> installer (a new remix/spin).
On Sat, Feb 13, 2021 at 1:10 AM Kevin Kofler via devel
wrote:
>
> Kevin Kofler via devel wrote:
> > And why would I want to do Red Hat's / IBM's work for free?
> >
> > Contributing to Fedora provides value to me because I use Fedora myself.
> > In contrast, what would I gain from contributing to
On Fri, Jan 22, 2021 at 5:37 PM Kevin Fenzi wrote:
> Soon. We have staging pretty close to all working, so I would expect
> sometime in the next weeks. We will announce deployment plans as we make
> them.
Excellent news! Do let us know if/how we can
help by testing (no change in AAA systems
On Fri, Jan 22, 2021 at 9:54 AM Miro Hrončok wrote:
> OTOH many Fedora systems use the FAS name as an identifier so even if the
> account system supports this, it will confuse badges, etc.
I do not recall the various related dependency status,
but I am pretty sure the case of badges was
On Fri, Jan 22, 2021 at 3:39 AM Andrew Toskin wrote:
>
> Is there a ballpark estimate on when we'll switch to the new account system?
>
When it is ready? (that is a joke, mostly).
Late last February there was a post from the
CPE AAA team with a status update on the
project, which had a
On Tue, Jan 5, 2021 at 3:46 PM Florian Weimer wrote:
> The metadata would also be much larger, and so would be the battery
> usage to recompress the payload. 8-(
And while the bandwidth reduction has value,
cpu and wallclock time to rebuild the rpm is
substantially increased for low end devices
On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson
wrote:
> I wrote in the update that in my opinion the solution for this bug
> can't involve expecting add-ons to suddenly get re-signed en masse, or
> users to change their local configuration. It needs to keep working as
> it did before. If the
On Sun, Dec 27, 2020 at 3:12 PM Matthew Miller wrote:
> It's been talked about before but no one has done it.
There was also smolt, which collected some
system information (and could be extended
to collect more) However, not only did the
upstream die, follow-on proposals never
took off, and
On Wed, Dec 23, 2020 at 8:43 PM Matthew Miller wrote:
> I'm not in favor of that -- I think it's generally not the best policy
Correct, that is what FIDO2 biometrics are designed to
replace entirely. Passwords, in general, must die.
> and doesn't address the issue directly.
Agreed, as was
On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel
wrote:
>
> Maybe Fedora should add 2FA support and require it for the most powerful
> groups?
>
It does support it, but AFAIK does not require it.
Arguably those with elevated access (provenpackagers(*))
should be required to use a
On Mon, Dec 21, 2020 at 7:25 PM Richard Shaw wrote:
> I would say so...
>
> $ dmesg | grep -c audit
> 767
>
> $ dmesg | grep -cv audit
> 30
>
You will likely have to share some of the audit
entries.
That last time I recall seeing so many audit entries
in dmesg I had set selinux to be
On Sat, Dec 5, 2020 at 6:24 PM Kevin Fenzi wrote:
> I'm a bit torn by this. The rawhide report has actually triggered
> conversation (less than 3 weeks ago) and I find it usefull to point out
> things.
I also find the rawhide reports (at least occasionally)
useful, as being the early canaries
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
wrote:
> # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
Also, you may need to (as yourself) perform a
$ systemctl --user enable pipewire pipewire-pulse
In limited testing it
On Mon, Dec 14, 2020 at 3:30 PM Christopher wrote:
>
> Even if people don't agree that "main" is better for other reasons, surely
> people can agree that "rawhide" is much better than "master"
I disagree, my opinion is that main is better than
master, and master is better than rawhide.
One
On Wed, Dec 9, 2020 at 4:52 PM Adam Williamson
wrote:
> For some folks / maintenance styles this might still be an issue, but
> it should work OK in quite a lot of cases. It's not like you're running
> Rawhide.
For those that want the equivalent of a point release,
I would think they should be
On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie wrote:
> But fedoras aren't made of sheets of main, they're made from sheets of
> rawhide...
Actually, fedoras can be made from many different
source materials (straw, cotton, hemp, etc.) in
addition to rawhide.
There are some workflows such that I
On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok wrote:
> For what's it worth I think that packages that only use make via cmake should
> not have an explcit dependency on make. Packages that use make directly should
> have an explicit dependency on make (even if they already BR cmake).
Does that
On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini wrote:
> I still think a lot of those are "false positives".
> CMake has a hard Requires on make, so if I BuildRequires cmake, adding
> "BuildRequires: make" is just redundant.
> https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
On Thu, Dec 3, 2020 at 3:08 PM Fabio Valentini wrote:
> Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
Aligning as much as possible with what appears
to be the industry consensus ("main") makes sense
to me, as I will be able to (re)train my finger muscle
memory in
On Tue, Nov 24, 2020 at 8:05 PM Neal Gompa wrote:
> But that said, I would like to backport all the packaging changes to
> Fedora 33 too. It's not actually *hard* to do, it's just a matter of
> getting everyone to agree to get it to happen.
I think that being able to easily install/revert and
On Tue, Nov 24, 2020 at 8:11 PM Ben Cotton wrote:
> Rename `libusb` to `libusb-compat`
It was my recollection that I thought lib-compat package
naming was deprecated in favor of lib1 package
naming (or lib_1 if the last X was a number)
for a .1 soname example.
On Wed, Nov 11, 2020 at 3:01 PM Chris Adams wrote:
> Are there replacements for the old services built in to xinetd?
Not that I know of as being integrated, although
writing such servers (often in perl) can often be
seen in training materials about network socket
programming in a few dozen
On Mon, Nov 9, 2020 at 9:04 PM Sérgio Basto wrote:
> Like tftp we may replace xinetd by systemd service files [1] ,
> if we replace cvs-inetd by a systemd service, the problem is solved.
I am pretty sure cvs already ships systemd service files.
The issue is that there is also a sub-package
On Mon, Nov 9, 2020 at 3:15 PM Tom Hughes via devel
wrote:
> Well that's a packaging issue so it's not something that
> would normally go upstream, or does upstream have a spec
> file that you are using?
For this package there are upstream (prototype) spec files
in the repo.
I don't know
On Thu, Nov 5, 2020 at 3:44 PM Robbie Harwood wrote:
>
> Ben Cotton writes:
> >
> > The spec file updates will be automated and changes will be pushed
> > directly to dist-git once they are ready.
>
> -1. I think you should use pull requests for this, and continue to
> believe that mass-pushing
On Wed, Nov 4, 2020 at 7:15 PM Neal Gompa wrote:
> When did this happen? CMake should not be requiring Make at runtime,
> especially now that the CMake macros let you trivially use either Make
> or Ninja.
rhbz#1862014
___
devel mailing list --
On Wed, Nov 4, 2020 at 6:50 PM Richard Shaw wrote:
>
> Is the expectation to explicitly BR: make?
>
> Or would pulling in autotools/automake/cmake suffice?
The cmake package currently requires make. I do
not believe the auto packages requires make,
so you would need to add make explicitly
On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach wrote:
> As none of packages which require either libsepol or libsemanage use dropped
> symbols and in order not to break build root during soname bumps I've added
> temporary
> subpackages with original library versions - libsepol-compat with
>
201 - 300 of 337 matches
Mail list logo
