> Zbigniew Jędrzejewski-Szmek writes:
> Let's take a step back. Does it make sense to implement complicated
> and fragile scriptlets in packages?
No, of course not.
> Can we *please* get rid of this footgun that has been a continous
> source of problems?
The mantra on the packaging committ
> maxwell--- via devel-announce
> writes:
> fedscm-admin cqi, ignatenkobrain, limb, 3 weeks
> ago
> mohanboddu, orphan, tibbs
>
I can't think of any reason this shouldn't simply be retired. All of
the
> Adam Williamson writes:
> Honestly, we could really use more automation here, but it's a fairly
> hard thing to do *reliably* and there just isn't anybody specifically
> tasked with it so it doesn't happen.
So sure, we could use something but it doesn't have to start out as some
complex fu
> Kevin Kofler via devel writes:
> My pet peeve is provenpackagers or comaintainers who add unwanted
> automagic (autorelease, autosetup, autochangelog) to my packages.
That really shouldn't be happening for anything which wasn't officially
made mandatory or forbidden or whatnot. Sure, I we
> Christopher writes:
>> $ wget mypackage.rpm
>> $rpm --checksig mypackage.rpm
> the whole point of
> using DNF to install a local file is for consistency of using the same
> command as for repo packages, not manually altering the RPM database
> outside of YUM/DNF (that results in a warning
> Maxwell G writes:
> IIRC, we used to have nim in Fedora and then it was retired.
Yes, it was in Fedora 33 but orphaned for some time and then retired.
The last version packaged was 1.0.4. The final spec doesn't look very
complicated but of course it's tough to say how that would apply to
> Sandro Mani writes:
> To keep these functional, I've prepared a podofo-compat package with
> the previous 0.9.x library. The review request is here [2]. Happy to
> review in exchange.
Note that it's not necessary to go through the review process for
multiple versions of packages like this,
> Nicholas Frizzell writes:
> Has anyone investigated making use of multithreading for check-files
> previously?
I'm not sure multithreading is all that meaningful for that script; it's
really quite simple, after all. It runs find to get a list of files,
sorts it, and diffs that against the
> Miroslav Suchý writes:
> No, I'm not saying that. Somebody has enough courage to open the
> package review, discuss it, get to the point that the package review
> was approved. But did not have the courage to reach sponsors. It was
> road block for them.
That's an odd case, I suppose. I h
> Miroslav Suchý writes:
> Again. This is not what we are telling them.
Again? There's no need for that.
In any case, what I wrote was the procedure I documented it when I set
it up. If all of that documentation was lost, then I don't know what to
say but that's not what was intended.
I
> Jakub Kadlčík writes:
> Currently, we have 31 people waiting to be sponsored
> https://fedoraproject.org/PackageReviewStatus/needsponsor.html many of
> them waiting for months. To get to the point of waiting to be
> sponsored, all of these people invested their time to learn the basics
> of
> Kenneth Goldman writes:
> but … if the tutorial has a sample .spec file, I think it would
> help the new user if it was 100% complete.
I believe that the section "A Complete hello.spec File" at
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/#_a_comple
> Maxwell G writes:
> If you don't want to clone every distgit repository and use the git
> log, [...]
Even if you did, there is full copy of the git data tarred up nightly at
https://src.fedoraproject.org/repo/git-seed-latest.tar.xz which would
probably save a big load of time.
- J<
_
> Felix Schwarz writes:
> imho removing the devel packages is basically the same as removing
> openssl1.1 entirely. To me the idea of "deprecation" is to warn users
> that something is going away WITHOUT removing functionality
> immediately.
I just wanted to note, since I haven't noticed it
> Rex Dieter writes:
> I'm sure there's a way to opt-out of this behavior (right?)
There is a standard way to opt out of any of the brp scripts:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
- J<
___
de
Unfortunately I again have a scheduling conflict today, and won't be
near a computer for an hour either side of the meeting. Sorry about
this; for some reason things keep lining up badly.
- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To
I'll apologize in advance for rambling, but I've been kicking around
ideas in this space for very many years now.
> "SJS" == Stephen John Smoogen writes:
SJS> Well it is quite clear we are doing something wrong and have been
SJS> for as long as the project has been going on.
It's true that
> "IG" == Igor Gnatenko writes:
IG> We can actually get rid out of this using `libcurl-minimal`, but it
IG> is not easy to teach DNF to replace libcurl-minimal with libcurl
IG> without explicit --allowerasing on the command line.
That does prompt the question as to whether dnf itself is requ
I'm on vacation and a few days behind on email, sorry.
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> Also, there are still some obvious packages to trim:
I wonder if the rpm dependency on curl (the executable, not the library)
is strictly necessary. I believe it's only because of the
%
> "TH" == Tom Hughes writes:
TH> Presumably in this case the performance penalty was considered small
TH> enough that it was worth building even production code with this
TH> mode enabled.
I'd like to know if any performance analysis was done about this,
because the upstream of a package I h
> "KK" == Kaleb Keithley writes:
KK> The firewalld packager doesn't seem to know how to add an
KK> ExcludeArch: to the .spec or how to remove the 'Requires: kernel
KK> ...' line.
KK> https://bugzilla.redhat.com/show_bug.cgi?id=1733602
KK> Maybe someone with some authority on the subject can
> "PK" == Philip Kovacs via devel writes:
PK> Years ago when I was writing my specs to add the packages I now
PK> maintain, I recall someone recommended to me the use of these macros as
PK> Fedora "tribal knowledge." I am happy to remove mine if their use is
PK> unnecessary and could lead to
> "MM" == Matthew Miller writes:
MM> Let's talk about something new and exciting.
I assume that you mean "very much not new and about as exciting as the
fifteenth viewing of an episode of the Joy of Painting".
I know it's been a while. Maybe it's been long enough that a
significant number
"Richard W.M. Jones" writes:
> - Compiling the Verilog source code to a bitstream requires highly
>proprietary tools and will never be possible in Fedora.
Depending on what you actually consider these data to be, this should be
somewhat covered by:
https://fedoraproject.org/wiki/Packaging:
24 matches
Mail list logo
