> Laurent Rineau writes:
> The result is that the following
> packages no longer build (F42FTBFS, RAWHIDEFTBFS):
> - prusa-slicer
> https://koji.fedoraproject.org/koji/taskinfo?taskID=124921682
Just so I don't forget (as I have no time to dig into this today), I see
some related information
> Jiri Konecny writes:
> Also a question, is kickstart command for RDP requirement for you? Or
> is inst.rdp (replacement of inst.vnc) enough to work with? We are
> trying to find out if we can drop the kickstart command.
I don't particularly care about how the functionality gets activated;
> Jiri Konecny writes:
> Hi, the only change should be that you will change "vnc --connect"
> with the new API we will provide and also use RDP as your client
> instead of VNC.
Thanks. I don't particularly care about VNC itself; I just wanted to
make sure that it was known that someone does
> Aoife Moloney writes:
> === VNC switch to RDP for remote GUI installations ===
I'm curious how my usual install workflow will be affected by this
change. I use the kickstart "vnc --connect" option extensively in my
workflow; I may have a bunch of installs running in parallel, and they
jus
For many years I have maintained xu4 (https://xu4.sourceforge.net/,
https://src.fedoraproject.org/rpms/xu4/), an open source engine which
can run the freely available Ultima IV game files. When the original
code was subsumed into the ScummVM engine, I was conflicted about what
should be done with
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 t
> 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 time
> 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 section
> 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, bu
> 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 packag
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 th
> 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 2011)
> 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 think
> 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 goo
> 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
> - ju
> "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 thi
> "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>
> "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 wa
> "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 from
> "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 minu
> "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 bl
> "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 f
> "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 spe
> "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 ex
> "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 stateme
> "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 th
Code of Conduct:
MH> 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 Tibbit
> "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 c
> "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
r
> "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 -- d
> "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 d
> "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 detai
> "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 si
> "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 i
> "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:
https://tmz.fedorapeople.or
> "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&state=enabled&order=name
They don't all have the same "capacity" rating.
TS> Because I'm s
> "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 extr
> "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 l
> "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 involve
> "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 instructions.
> "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:
https://docs.fedoraproject
> "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 new
> "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 is
> "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 package
> "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 ques
> "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 su
> "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 reboot
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 hav
> "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 it
> "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. Certa
> "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 -- devel@lists.fedoraprojec
> "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:
https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro
> "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:
https://pagure.io/packa
> "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 li
> "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" flag
> "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 texlive-bas
> "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 manufa
> "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 aga
> "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
> "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 thi
> "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 w
> "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 en
> "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 t
> "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 dis
> "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 Fe
> "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:
https://lists.fedoraproject.
> "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 abou
> "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<
__
> "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 function
> "RH" == Robbie Harwood writes:
RH> If I backport this to fc29, will that assuage people's concerns?
I think it would certainly help and I wouldn't complain. In fact, I'd
love to start running that as soon as I can. However, it wouldn't help
anyone who does a (supposedly supported) F28->F
> "RG" == Raphael Groner writes:
RG> Fedora packaging is becoming to get heavy magic aspects.
Well, obviously we would prefer that the scriptlets just go away and not
be replaced with magic. The magic macros exist to accommodate those who
wish to have a single spec across Fedora and EPEL, T
Here are the recent changes to the packaging guidelines.
-
We have begun to remove content from the wiki. The old pages should all
now have links to the new docs site. As we continue to work on the new
documents, the corresponding wiki pages will be emptied and left only
with the link to th
> Björn 'besser82' Esser writes:
> From what I know, and what is pratically done, one would name the
> compatibility package "python-sqlalchemy05".
Please see the relevant guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_multiple_packages_with_the_same_base_nam
> "RH" == Robbie Harwood writes:
RH> Ah, I see, you're talking about the case when the enctype is already
RH> not permitted. That all makes sense then.
Right. Basically, if any one of these:
* Warnings in previous versions about principals without modern etypes
* Logging in the new versio
> "RH" == Robbie Harwood writes:
RH> I've spent a nontrivial amount of time working on improving that,
RH> but am always willing to process more bugs in the
RH> documentation/errors area.
I know, and I don't mean to denigrate any work that's been done in
making the MIT KRB stack better. It'
> "JF" == John Florian writes:
JF> I thought I'd start by consulting
JF> https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what
JF> changed but much to my surprise the newest build I see there is
JF> sqlite-3.22.0-5.fc28! Huh? Where are the f29 builds?
First, note that Bodhi do
> "RH" == Robbie Harwood writes:
RH> Per your follow-up email, I'm not clear on whether you want changes
RH> here. If you do, speak up, especially if you have suggestions.
Well, it was just odd that the summary had information not contained at
all within the detailed description. Since thi
> "JLT" == Jason L Tibbitts writes:
JLT> Is it just me or does this not actually say clearly what is
JLT> changing?
Seems it's just me; somehow that's in the summary but not in the
detailed description. Seems odd for the details to have less
information than the short version, but I guess t
> "BC" == Ben Cotton writes:
BC> == Detailed Description ==
[elided]
Is it just me or does this not actually say clearly what is changing?
The first paragraph talks about two RFCs. The second paragraph talks
about how easy it is to break single DES. The third paragraph talks
about how dis
> "FV" == Fabio Valentini writes:
FV> - unless those other, main icon theme packages have also added
FV> %transfiletrigger* scriptlets, like I've done for elementary and
FV> Paper.
Perhaps it should be mandatory for icon themes to add the necessary file
triggers so that no package will ever
> "MH" == Miro Hrončok writes:
MH> Is there anything we can do to prevent maintains to override the
MH> change with their next "magical sync" from jira/RDO/github/whatever?
MH> I mean we already say they should not do that, but can we somehow
MH> make sure they actually won't?
This question
> "KL" == Kalev Lember writes:
KL> I agree with Zbyszek, I think it would be best to push the changes
KL> directly to git.
But then we're back to the same problem: Do you remove the ldconfig
calls entirely or do you add the macros? Prepare for flames if you get
it wrong, even though it's no
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> I think it's pretty clear: all the standard invocations of
ZJ> scriptlets that have by replaced by transfiletriggers will be
ZJ> removed, along with the whole %post/%postun sections if its the only
ZJ> thing in them.
I do think it would be be
> "AB" == Andrew Bauer writes:
AB> In the interested of getting this review completed, am I in my right
AB> to close this request and create a new one, or is there better
AB> course of action?
If you have a package ready to go, then certainly just close the old
review ticket. If someone is
> "MM" == Mike Miller writes:
MM> I have installed the latest fedpkg, fedpkg-1.35-1.fc28.noarch. Do I
MM> need to upgrade to 29? I thought fedpkg would still work on 28.
I'm still on F28 (for another hour or so) and have no problems running
fedpkg.
fedpkg-1.35-1.fc28.noarch
python2-2.7.15
> "SS" == Salman Siddiqui writes:
SS> I accidentally submitted a Koji build for 4 packages [1] that
SS> are not supposed to be packaged for Rawhide.
Are they EPEL only packages are something?
In any case, if those packages aren't ever supposed to be in rawhide (or
be branched for f30 in the
I filed https://pagure.io/fedora-infrastructure/issue/7398 to see if the
infrastructure folks (or pingou or whoever) would be willing to turn
this on for all existing repositories.
- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscr
> "PO" == Peter Oliver writes:
PO> Also, it's hard to volunteer to co-maintain a package which has a
PO> non-responsive maintainer, because there is no one to grant you
PO> access.
Well, certainly there is but the issue is finding the proper way to ask
for it. And I don't think we have any
> "DM" == Dusty Mabe writes:
DM> I personally think this should be the default for all projects but I
DM> don't know if there is a way to easily make that happen when a
DM> project gets created.
I'm sure there could be. But I'd go further and say that we should set
that on all existing repo
> "NG" == Neal Gompa writes:
NG> Most of these fonts look like they are licensed appropriately, the
NG> only problem is the Ubuntu fonts, which have been noted to have a
NG> non-free license[3] (unless someone can get Canonical to fix it).
I had a look at the license at https://www.ubuntu.co
> "MM" == Matthew Miller writes:
MM> It's the fundamental contradiction that all operating systems face:
MM> users complain "too fast and too slow!" at the same time.
Well, then lengthening the Fedora lifecycle does not seem to me to be
the real solution. Instead, I think, it's to piggyback
> "IU" == Iñaki Ucar writes:
IU> AFAIK, that wasn't officially supported.
What does "official" actually mean, and what relevance does that have?
Adrian Bunk didn't maintain 2.6.16 in a way that's much different than
the current long term support kernels are supported. And even before
that,
> "IU" == Iñaki Ucar writes:
IU> In this respect (the kernel), it's true that something changed
IU> compared to a decade ago: there was no LTS support upstream
IU> then. Now, there is.
That is not really true. 2.6.16 (the first kernel that I recall anyone
calling some equivalent of "LTS") w
> "FW" == Florian Weimer writes:
FW> Modules do not support parallel installations of different module
FW> versions. Many SCLs are constructed in such a way that this is
FW> possible. So I'm not sure if modules are a clear improvement over
FW> SCLs.
And the really fun thing is that once th
Since I actually had an existing pagure repo for random RPM macro
experiments, I just dropped the R macro stuff there.
https://pagure.io/misc-rpm-macros
https://pagure.io/misc-rpm-macros/blob/master/f/macros.R-extra
I still have some ideas to implement but feel free to test what's there.
To use t
> "IU" == Iñaki Ucar writes:
IU> I see. Anyway, I suppose that it's healthy to preserve some manual
IU> intervention in these sections.
Well, it would be super great if we didn't have to do that and one day
RPM might give us some reasonable way to generate more of the specfile
based on the c
1 - 100 of 563 matches
Mail list logo
