So I've been in this situation, both on the receiving end of nasty flames
because I dared touch someone else's package and having duplicated work
because I didn't check before trying to update something.
> Michael J Gruber writes:
> So, due to me following my package (notmuch)
The idea is
> Robert Marcano via devel writes:
> I seriously don't know how gnome-browser-connector [1] has ownership
> of:
> /usr/lib64/mozilla/native-messaging-hosts
> and not have conflict problems with mozilla-filesystem at install
> time, maybe because they usually get installed at the same
> Sandro writes:
> That aside, having the document linked in the packaging guidelines is
> a big step towards letting packagers know of its existence.
I just wanted to point out that the packaging guidelines have pointed
users to the document for quite some time (early 2019) in this
> Gary Buhrmaster writes:
> I have found that using something like libfoo.so.X{,.*} in the %files
> directive can be a useful reminder (enforcer) to reduce such surprises
> (that particular glob presumes semantic versioning, and that minor and
> patch level updates do not require rebuilds,
> stan via devel writes:
> As they say in the BUILDING.md file,
> though, fedora lacks wxWidgets 3.1.5 or greater. That stops the
> configuration, cmake -G Ninja -S . -B build when it errors out.
That's odd; as far as I can see, F36 has 3.1.5 and F37 has 3.2.1.
- J<
> Ewoud Kohl van Wijngaarden writes:
> Right now you can't test them since they haven't been migrated to
> testing yet.
You can download the packages directly from koji. From the relevant
update page, you can clock the "Builds" tab which will give you a link.
You can down exactly the
Quite recently a few macros were added to fedora-release: %dist_vendor,
%dist_name, %dist_home_url and %dist_bug_report_url. These will
eventually be documented in the Fedora packaging guidelines and you can
see the initial PR at
https://pagure.io/packaging-committee/pull-request/1198
I was
> Jilayne Lovejoy writes:
> https://pagure.io/packaging-committee/pull-request/1142
> Can someone merge that PR on Tuesday evening or Wednesday morning (US
> time)?
I will be watching the PR and can merge it when it's done, but feel free
to ping me.
- J<
So I went to do a dnf system-upgrade from F35 to F36 on a test machine,
as part of my usual testing. In the middle of the process, it appears
that /var filled up and that left the system in an unfortunate state.
Surprisingly (to me) it did boot with a random mix of F35 and F36
packages and even
> Ben Cotton writes:
> == Make UEFI a hardware requirement for new Fedora installations on
> platforms that support it (x86_64).
My problem here is that I have real, useful hardware which has always
run Fedora that I would like to continue using. But it's just old
enough (purchased in
> Brandon Nielsen writes:
> I would like to see the forge macros removed from the guidelines if
> development truly has ceased.
I would like to get into them and at least see what needs to change
but... the internal implementation is somewhat baroque and my time is
severely limited. I
> Gary Buhrmaster writes:
> I have occasionally conjectured that there should be a "last gasp"
> version of some core package released into updates for a version going
> unsupported that drops a file into /etc/motd.d that is, essentially:
I've thought about it as well, but I still wonder
> Robbie Harwood writes:
> Fabio Valentini writes:
>> Since it's not practical to modify almost all Fedora packages to add
>> "ExcludeArch: %{ix86}" to them, we'd probably need a different
>> machanism for this.
> Is it really not? This seems the easiest way to go about it, honestly
> -
> Richard Fontana writes:
> I am not sure if this should be acceptable for Fedora. My concern is
> that the "UW" naming prohibition is unreasonably restrictive. Does
> anyone have thoughts on this?
Naming can be difficult, but I believe we've long accepted clauses
forcing renaming. A
> Troy Dawson writes:
> If I remember right, the spec file name needs to be in the format
> .spec Thus, the spec file needs to be
> openssl3.spec, and thus you aren't really renaming it. :)
Yes, assuming that EPEL doesn't deviate:
That looks like a lot of change for what should be a one-line change.
Did some unrelated commit sneak in?
- J<
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to
>> Therefore, the goal of this license is to prohibit the use of MVT
>> (and any other software licensed the same) for the purpose of
>> adversarial forensics.
That sounds like a field-of-use restriction. I can't imagine how such a
license can be free under the usual definitions.
For the
> "BC" == Ben Cotton writes:
BC> Use the annocheck program from the annobin package to
BC> produce an analysis of the security hardening of a compiled package
BC> when reviewing a Bodhi update.
While I don't disagree with running annocheck at some point in the build
process, _only_ doing
> "AI" == Artur Iwicki writes:
AI> I imagine the reason is that this allows us to add new
AI> architectures to FPC and do some trial-and-error builds of FPC
AI> without affecting dependent packages - if FPC itself used
AI> %{fpc_arches}, then adding new architectures to FPC would require
AI>
> "DM" == David Moreau-Simard writes:
DM> I don't have the bandwidth to take care of pytest-django right now.
DM> Would it be acceptable to propose a new package without %check until
DM> it gets packaged ?
It's OK to disable tests you can't run because they have additional
dependencies
> "MM" == Matthew Miller writes:
MM> Whether or not it's documented policy (and I can't remember or find
MM> anything either), many packages have the practice of trimming very
MM> old entries.
You can't always do this. I tried to purge changelog entries from a
package older than 2010 and
> "C" == Christopher writes:
C> With version-controlled package sources, changelogs in SPEC seem so
C> obsolete to me. They are already problematic today when they conflict
C> due to changes in multiple branches.
It's important to note that the RPM changelog is rather a different
thing
> "JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a full
JBF> packet capture of the readdir reply to make sure it's legit.
I have been working with bcodding on IRC for the
> "CM" == Chris Murphy writes:
CM> But anyway, I did laugh a bit out loud at 23:45 UTC because *of
CM> course* there are many other totally unambiguous times to choose
CM> from instead. Some of the best comedy is pointing out the obvious.
If we're going to bikeshed it, I'll vote for two
I asked the XFS folks who mentioned that the issues with 64 bit inodes
are old, constrained to larger filesystems than what I'm using, not an
issue with nfsv4, and not present on anything but 32bit clients with old
userspace.
In any case, I have been experimenting a bit and somehow the issue
> "WW" == Wolfgang Walter writes:
WW> What filesystem do you use on the server? xfs?
Yeah, it's XFS.
WW> If yes, does it use 64bit inodes (or started to use them)?
These filesystems aren't super old, and were all created with the
default RHEL7 options. I'm not sure how to check that 64
> "JLT" == Jason L Tibbitts writes:
JLT> Certainly a server reboot, or maybe even just
JLT> unmounting and remounting the filesystem or copying the data to
JLT> another filesystem would tell me that. In any case, as soon as I
JLT> am able to mess with that server, I'll know more.
Rebooting
> "SJS" == Stephen John Smoogen writes:
SJS> Can koschei be limited to a single architecture or does it need to
SJS> build against all targets? I am worried about the number of s390
SJS> builds we may be adding.
Currently it only does builds for aarch64, ppc64le and x86_64, so it
does at
> "BF" == J Bruce Fields writes:
BF> Looks like that's db531db951f950b8 upstream. (Do you know if it's
BF> reproduceable upstream as well?)
Yes, it's reproducible up in the 5.3.0 RCs as well.
However, while trying to do some further bisecting I ran into an odd
problem. Now kernels which
I now have another user reporting the same failure of readdir on a long
directory which showed up in 5.1.20 and was traced to
3536b79ba75ba44b9ac1a9f1634f2e833bbb735c. I'm not sure what to do to
get more traction besides reposting and adding some addresses to the CC
list. If there is any
> "C" == Christopher writes:
C> BuildError: package thrift is
C> blocked for tag f32-updates-candidate
C> (https://koji.fedoraproject.org/koji/taskinfo?taskID=37187038)
It means that thrift has been blocked in koji. The usual reason for
this is that the package has been retired, and the
> "PW" == Phil Wyett writes:
PW> The '.1' should go before the %{?dist} tag in this case so to not
PW> confuse as the outputted 'el8.1' does.
This is not true:
> "GH" == Gerald Henriksen writes:
GH> On the other hand, unbuildable packages could be viewed as a
GH> security risk.
I mentioned security explicitly in my message. Just not in the portion
you quoted.
GH> If you can't just fix the security issue and rebuild, but instead
GH> have to also
> "DS" == David Sommerseth writes:
DS> As I can see it, there is little benefit of removing lz4-static.
Isn't that entirely the decision of those maintaining the package? It's
still completely reasonable if they want to remove it for no other
reason than it eliminates ten lines from the
> "FW" == Florian Weimer writes:
FW> Debian treats FTBFS bugs as release-critical. They either have to
FW> be fixed, or the package gets removed from the release. However,
FW> this is not an automated process.
Of course, Debian works on a slightly different release schedule, so
it's not
> "MH" == Miro Hrončok writes:
MH> If we stop here, the current "setting to ASSIGNED to stop this"
MH> remains a problem.
Let's think about why this is perceived as a problem. The maintainer
has performed an affirmative act that shows they noticed. Can't we just
accept that as some
> "NG" == Neal Gompa writes:
NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf
NG> That said, you probably don't want to do that, since most downloaded
NG> packages aren't signed...
I think that the ideal behavior would be to always check, but
warn/prompt for unsigned packages or
t; https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
MH> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
MH> List Archives:
MH> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Jason L Tibbitts III - j...@tib.bs - 71
> "TC" == Tom Callaway writes:
TC> One of my packages (alienarena) fails to build in rawhide on s390x
TC> (and only that arch), but the build log shows it never even
TC> starts.
Does it fail repeatably? This error is known but as far as I know it's
always been transient. It only seems to
> "FW" == Florian Weimer writes:
FW> At one point, there was a verified hash chain from the https://
FW> metalink service, to the repository metadata, down to individual
FW> packages. Any tampering was detected then.
I understand that the metalink contains enough information to verify the
> "KF" == Kevin Fenzi writes:
KF> * If you use metalinks, rpm signatures are just gravy on top, in the
KF> end you are still just trusing SSL CA's.
Only if you trust every mirror to always serve authentic content.
- J<
___
devel mailing list --
> "SG" == Stephen Gallagher writes:
SG> Do any tools exist to simplify the conversion to MDB? Can this be
SG> automated?
I'd like to know this as well. It's always better to provide tools or
extremely clear and detailed instructions, because it's not safe to
assume that people know how to
> "PM" == Panu Matilainen writes:
PM> So a big +1 for sysusers in sub-packages + file trigger to handle
PM> running systemd-sysusers. It solves more problems than the current
PM> sysusers-proposal and in a far more elegant way at that.
It's great that you agree. That leaves all of the
> "JN" == Jamie Nguyen writes:
JN> I couldn't find clear packaging policy on this. The guidelines [0]
JN> talk about %config(noreplace) vs %config, but /etc/named.conf is
JN> installed as a "noreplace" file.
I don't think there's a guideline about this. %config and
%config(noreplace) are
> "RF" == Richard Fearn writes:
RF> According to
RF>
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures:
>> If a Fedora package does not successfully compile, build or work on
>> an architecture, then those architectures should be listed in the
>> spec
> "JO" == Joe Orton writes:
JO> In the historic CVS-based build system which predated what we now
JO> use, we could do GPG key verification at the time of downloading and
JO> importing a new tarball.
You're right; tmz dug up a copy of the old Makefile.common file:
> "TS" == Tom Stellard writes:
TS> Are these updated builders only used for f30?
It appears that there are 29 PPC64le builders configured currently:
https://koji.fedoraproject.org/koji/hosts?start=80=enabled=name
They don't all have the same "capacity" rating.
TS> Because I'm still
> "FW" == Florian Weimer writes:
FW> ELF multilib DSOs inside RPMs result in code deduplication,
FW> affecting container image size.
I think it's important to quantify this kind of thing. I think we can
all agree that there is very little benefit to duplicating every single
library, so
> "KK" == Kaleb Keithley writes:
KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days
KK> ago. Two different builds on f30 built or are building fine on
KK> x86_64, i686, and aarch64, but failed with different errors on
KK> ppc64le at different places in the build. One
> "JLT" == Jason L Tibbitts writes:
JLT> And, let's see, I'd have to toss out five desktops (which isn't too
JLT> bad, I guess)
I was wrong. It would be 36 desktops. Being charitable requires me to
assume this was proposed without adequate consideration of just how much
hardware is
> "BC" == Ben Cotton writes:
BC> * Other developers: Other developers may have to adjust test suites
BC> which expect exact floating point results, and correct linking with
BC> libatomic. They will also have to upgrade their x86-64
BC> machines to something that can execute AVX2
> "ZD" == Zdenek Dohnal writes:
ZD> Converted to spaces now.
Well I appreciate that, but my point is that it's really personal
preference.
ZD> It is designed for user to run rpmdev-bumpspec
ZD> .spec, so the tool will supply correct format of changelog
ZD> entry and increment the release.
Welcome back to Fedora. I've clicked the necessary sponsorship buttons.
- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> "ZD" == Zdenek Dohnal writes:
ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
ZD> for Vim to do:
ZD> - when you open new file with .spec suffix, Vim will get you basic
ZD> spec file structure?
Personally I have always found that behavior annoying. If I open a
> "FW" == Florian Weimer writes:
FW> I strongly doubt this will be true indefinitely. I expect things
FW> will change pretty quickly once partners can access and file bugs in
FW> the other bug tracker.
This is interesting in light of the fact that one reason given for not
enabling Pagure
> "MH" == Miro Hrončok writes:
MH> Are my assumptions correct?
Yes, unless some major changes happened of which I was not aware, you
cannot have any package name in EPEL7 (including a source package) which
duplicates a package name in RHEL7 _on a particular architecture_.
(There are
> "VO" == Vít Ondruch writes:
VO> I just wonder what is the point of:
VO>
https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.in#L122
I guess it just saves packagers from having to call systemd-sysusers
properly. You include the configuration file in the source
The issues you show don't appear to have anything to do with EPEL. The
certbot package simply requires /usr/sbin/restorecon and
/usr/sbin/semanage; yum isn't able to install those because it appears
that there is some problem with the base (Centos) repositories. Please
make sure that you are
> "MC" == Michael Cronenworth writes:
MC> Yes, something would have to be invented, and I guess that's why no
MC> one replied.
Well I replied, bit I'm behind on email so...
MC> However, the data exists it is just not available in a standard,
MC> parsable format.
And that was really my
> "MC" == Michael Cronenworth writes:
MC> Any long term plans to support C/C++ apps?
Depends on what you mean by "support", really. Really there's just a
new spec section that gets run and it just needs to echo a list of build
dependencies. That's really all this does; the existing Rust
> "JP" == Jens-Ulrik Petersen writes:
JP> Jason, can you explain in more details (bug report is also fine) how
JP> exactly you are installing?
I install a generic minimal system via kickstart (booted using the
Server PXE images and using the Everything repositories) and then after
the
I noticed that my F30 installs are coming out far larger than my F29
installs (by 3GB or so) and did some digging into why.
With F30 we switched away from having groups named like "korean-support"
that you could install to get input methods and fonts needed to display
a language and instead we
> "AC" == Amir Caspi writes:
AC> Escalating bantime is a feature in v0.11. Unfortunately not
AC> available in v0.10 or earlier.
I have some locally updated Fedora packages for Fedora which I use here;
the feature works well. I use the following settings:
bantime = 6m
bantime.increment =
> "M" == Mike writes:
M> It would be nice to have some kind of shared attack list we could
M> use, like DNSRBL.
blocklist.de publishes several. fail2ban already has support for
reporting your bans to them; see the documentation in the default
jail.conf. You just need to get an API key
> "PM" == Panu Matilainen writes:
PM> Note that rpm doesn't support parallel zstd compression, and while
PM> it does for xz, that's not even utilized in Fedora.
Doing parallel xz compression has a surprising cost in compression ratio
which gets worse as the thread count increases (because
> "BC" == Ben Cotton writes:
BC> * The change requires setting a new compression algorithm in rpm
BC> macros. Then a mass rebuild of all packages is required.
Technically there is no harm if a mass rebuild is not done; there will
simply be no benefit for packages which aren't rebuilt.
> "PP" == Petr Pisar writes:
PP> I'm going to rebase miniz in Rawhide from 1.15_r4 to
PP> 2.1.0.
Thanks for doing this; it allows me to unbundle miniz from prusa-slicer,
at least in rawhide.
- J<
___
devel mailing list --
Just wanted to double check the proper License: tag for the following
license file. I believe it should be "Copyright only or BSD", but our
page for Copyright only doesn't use exactly the same text and the
plethora of BSD licenses is always fun. This software (and a bunch of
other things) has
> "CH" == Chris Hassell writes:
CH> Most build systems these days recommend building entirely as a
CH> normal user (even Debian?) and the chown-and-other-ops are done with
CH> careful setuid privileges given to the build system.
CH> RPM and rpmbuild have been doing it that way for years.
> "AT" == Andrew Toskin writes:
AT> I'm looking specifically into VeraCrypt, the open-source fork from
AT> TrueCrypt.
Has the situation which has kept VeraCrypt out of Fedora previously been
changed?
See this, for example:
> "BC" == Cuttler, Brian R (HEALTH) writes:
BC> Can anyone provide the files I need, give hints on what I'm doing
BC> wrong or help in some other way?
I don't believe Amanda upstream ships systemd unit files, so you would
need to provide them yourself. Perhaps look at the files Fedora
> "DH" == David Howells writes:
DH> I'm not entirely clear how I should go about requesting FPC
DH> approval. It says it is preferable that a ticket be filed in the
DH> packaging committee pagure - do they mean to raise an issue, do you
DH> know?
Just file a ticket:
I wish this message wasn't crossposted everywhere, but I don't want to
lose any discussion by trimming the CC list. Sorry if replies generate
bounces for some.
> "nm" == nicolas mailhot writes:
nm> And the forge macros are now available since
nm> redhat-rpm-config-73-1.fc28 (I had missed
> "nm" == nicolas mailhot writes:
nm> I don't know about EPEL6, but we use it as-is in EL7 and it works
nm> just as well (except maybe for the %autosetup bits but IIRC that's
nm> autosetup which is broken in EL7).
I had ported autosetup to EPEL6 and then at the next release the macros
> "LP" == Lennart Poettering writes:
LP> Yes it is. But so is rngd afaik?
The software isn't exclusive to any particular architecture, though it
may of course have different sources of entropy on different
architectures.
- J<
___
devel mailing
> "AT" == Antonio Trande writes:
AT> Is it correct tagging an absolute path with %doc?
Yes, it's fine; that just sets the flag that tells RPM "this
file/directory contains documentation". That's not really any different
than, say, using %config to set the "this is a configuration file"
> "JJ" == Jerry James writes:
JJ> Somebody out there has been involved with past attempts to build
JJ> xindy. Please, I would like to make progress on this so I can get
JJ> back to building the coq stack's new versions. Which package used
JJ> to contain xindy?
It is/was part of
> "LP" == Lennart Poettering writes:
LP> That's not true anymore. There's a kernel compile time option now
LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel
LP> sets that since a while.
Isn't this arch-dependent?
config RANDOM_TRUST_CPU
bool "Trust the CPU
> "DD" == David Dykstra writes:
DD> Does this also imply a new fuse3 package in pagure & bodhi? Or
DD> could it still be part of the fuse package but have a separate
DD> fuse3.spec?
It would have to be a separate package repository and receive separate
updates. It is not possible for a
> "RS" == Robert Scheck writes:
RS> wouldn't it have been a clever alternative to use lua52-* rather a
RS> quite unspecific "compat-lua-" to be really similar with your
RS> python2/3 example?
I made a similar suggestion in the packaging committee ticket.
"compat-" is nonspecific and goes
> "RM" == Robert-André Mauchin writes:
RM> Since our float of Golang packages is severely out of date, I was
RM> expecting a load of new messages from Bugzilla.
I don't believe it notifies when the project is first added. It should
notify when the project is next updated.
- J<
> "MH" == Miro Hrončok writes:
MH> You realize that once it is maintained by the group, nobody else is
MH> going to take it?
When the stewardship SIG maintains a package, it should be for the sole
purpose of keeping it around just long enough to avoid serious
disruption that would be caused
I've been doing a little experimentation with the support for
successively increasing ban times in the current 0.11 codebase and had a
few observations and a question.
In an actionban, seems to always expand to the base bantime
setting. But if I expand , I see something like:
BanTicket:
> "JC" == Jeremy Cline writes:
JC> The effort would be a 1-2 line change in the-new-hotness, and
JC> distributing the config to each package repository (some proven
JC> packager could do this easily).
Well that seems easy enough. We still need the repo for the bugzilla
assignee override
> "KF" == Kevin Fenzi writes:
KF> Well, I find it unfortunate, does that count? :)
It is unfortunate, but note that it's unfortunate simply because of our
procedures. Certainly it would be nice if the functionality for making
new branches and changing monitoring and some bugzilla settings
> "AP" == Andreas Piesk writes:
AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too)
AP> running on latest arch linux. Here's the configure summary:
AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes
AP> #6 0x7fc4aa385050 re_acquire_state_context
> "MH" == Miro Hrončok writes:
MH> There should be a configuration option that disbales xindly. Does
MH> the documentation build with it?
Since xindy isn't really something that can be relied upon, is it
possible (or reasonable) to do this globally in our sphinx packages?
Even when it was
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> This doesn't sound convincing at all.
I was not attempting to be convincing.
ZJ> We *know* that people miss announcements all the time. Dropping
ZJ> epochs would introduce yet another case where a "magical" step is
ZJ> needed at a specific
> "VO" == Vít Ondruch writes:
VO> In this case, if DNF said something like "you have installed
VO> foo-1:1.0, but there is available foo-0:2.0" it would give me
VO> hint. From the start it would be annoying, but once we would reach
VO> the point 4, I would, at least, know that I should do
> "MH" == Miro Hrončok writes:
MH> One thing to consider here is other packages that have Requires
MH> etc. on something like "foo > 1:1.2", so if it is automated, this
MH> part needs to be automated as well.
Indeed. And of course this breaks any such dependency outside of Fedora
as well.
> "MH" == Miro Hrončok writes:
MH> On 08. 03. 19 21:16, Neal Gompa wrote:
>> I really wish we'd allow Epochs to be reset on distribution upgrades.
>> With dnf distro-sync (which is used by system-upgrade) Epochs don't
>> really matter and upgrades work as intended anyway...
MH> Let's do a
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> kernel-install already calls depmod (from
ZJ> /usr/lib/kernel/install.d/50-depmod.install).
I'm not sure that's sufficient. Packages can install modules at any
time and I believe depmod needs to be called when this happens. Thus
the kernel
> "JLT" == Jason L Tibbitts writes:
JLT> One fun thing is that I have no idea how file triggers interact
JLT> with packages which are installed multiple times.
I now know: it works the way I hope it does, so the scriptlets I
suggested for auto-running depmod should work properly. As a
> "LA" == Laura Abbott writes:
LA> The kernel uses a few scriptlets at the moment which will need to be
LA> cleaned up, most likely replaced with file triggers.
I have some experience converting things to file triggers had a quick
look. It seems we have the following:
The main kernel
> "PV" == Paul van der Vlis writes:
PV> Somebody has packaged Cyrus version 3.08, but there are problems
PV> with some of the Cassandane tests.
It may be useful to see how Fedora handles Cassandane as part of its
build process. I did a lot of work to get things functioning and get
patches
> "JH" == John Harris writes:
JH> For what reason is SSPL considered non-free? As I see, it's
JH> essentially a GPL incompatible AGPL license.
It's been pretty well covered throughout this whole debacle, but here's
the most recent announcement from Fedora Legal:
> "SV" == Siteshwar Vashisht writes:
SV> I would do that.
Thanks.
SV> I will also provide a compatibility package for readline 7.
That does help, but then you have to know that it's the magic package
you need to install in order to restore the command line editing
capability. Nothing
> "RG" == Raphael Groner writes:
RG> Hi Miro, winetricks should get assigned to ekulik as he's the new
RG> main admin.
I've made ekulik the main admin of the winetricks repository. It's not
blocked in koji so everything should be OK now.
- J<
> "R" == Riseops <" > writes:
R> We've been trying to sync using the quick-fedora-mirror script but
R> we're getting the error below: - When syncing from
R> dl.fedoraproject.org
It would be useful to see the non-comment lines from your
quick-fedora-mirror configuration file. I suppose it
> "SV" == Siteshwar Vashisht writes:
SV> Readline-8.0 was released earlier this month[1]. I am going to
SV> rebase it in rawhide in couple of weeks.
Note that a couple of things break in weird ways every time readline gets a new
major version. For me that's the command line editing
1 - 100 of 1435 matches
Mail list logo
