On Fri, Jun 2, 2023, 9:09 AM Matthew Miller mailto:mat...@fedoraproject.org>> wrote:
I think this sentiment is getting ahead of things. This thread _is_ that
effort.
Yes, but. In general, a better approach is to say "we plan on orphaning the packages
in $timeframe".
...
RH, for
If the need to package a snapshot goes away
'need' is certainly one right operative question.
whose?
Redhat's?
official Fedora packaging's?
"just us COPR users"?
i'm in the last camp.
i build/package to scratch my own projects' requirements' itch(es).
here's one,
Original Message
From: Richard W.M. Jones [mailto:rjo...@redhat.com]
Sent: Tuesday, May 23, 2023 at 1:27 PM EDT
To: devel@lists.fedoraproject.org
Subject: Status of the forge macros?
I've been using the so-called forge macros in lots of packages:
As I said earlier in the thread: of the 25 reverse dependencies of the
ImageMagick libraries, only five don't build[1].
Further analysis indicates that dvdauthor has a patch in openSUSE[2],
but the fix breaks support for GraphicsMagick as an alternative. I
want to rework that patch so it
Let's Encrypt also supports the dns-01 challenge[1] that doesn't require
any publicly available IPs. Using dns verification is required to obtain a
Let's Encrypt wildcard certificate.
While I tend to prefer using the dns-01 challenge approach
when possible, not all DNS providers have made it
Don't get me wrong, the folks who work on Koji and Copr are great, but
even they'll admit that they're woefully underfunded. The compose
tooling, PDC, etc. are also examples of this problem.
Can't agree enough. Hats off to the COPR folks.
Without it, even it current state, RH/Fed ecosystem is,
Does anyone know how to contact Othman Madjoudj a.k.a. athmane?
https://bugzilla.redhat.com/show_bug.cgi?id=2129515
Bug List, pkg libmodsecurity
ID Status ResolSummary
Changed
2129515 NEW Non-responsive
As I did those updates..
well explained, thx.
But this then seems to be a more general problem of how we want to
support a switch an application from one ESR/LTS release if it is EOL to
the next.
not terribly differently than others -- with an abundance of end-user education
and caution?
I'm shutting up now, because this comment from ngompa is, IMO, very
well/thoroughly said.
thx Neal!
On 4/6/22 8:16 AM, Neal Gompa wrote:
If you really have a need to reinstall such machine, you'll take the F36
image and upgrade to F37+ and you should still be good.
This is not a deprecation
On 4/6/22 8:03 AM, Vít Ondruch wrote:
If you really have a need to reinstall such machine, you'll take the F36 image
and upgrade to F37+ and you should still be good.
With 100s - 1000s of of affected machines -- real & virtual -- still in
operation, with usable lifetimes of years-to-come,
Akamai owns Linode, which is a prominent VPS that focuses on Linux
(Linode is a contraction meaning "Linux Node").
+1
DigitalOcean similarly is Linux centric and so Windows doesn't matter.
+1
Most web hosting providers and VPSes are Linux-centric and so Windows
doesn't matter.
+1
(Akamai is, to my knowledge, not a provider of VPSs.)
https://www.linode.com/press-release/akamai-to-acquire-linode/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
So you've heard that we're overloaded, and you know that UEFI is the
direction the world is heading.
Well, so is (was?) 'IPv6' ...
Your solution to this is... what, stick
our heads in the sand and ignore that? Just do legacy? We already have
UEFI-only platforms (see also: the mention of ARM
On 2/24/22 10:12 AM, Fabio Valentini wrote:
On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote:
especially since they don't really provide value for
standard GitHub tarball downloads etc. compared to the "old" SourceURL
some of us strongly disagree. admittedly, with
especially since they don't really provide value for
standard GitHub tarball downloads etc. compared to the "old" SourceURL
some of us strongly disagree. admittedly, with no weight ...
___
devel mailing list -- devel@lists.fedoraproject.org
To
Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:
not all are concerned with building according to Fedora Packaging standards,
for proposal in inclusion
some of us use forgemeta because it provides capability that
On 1/18/22 14:29, Chris Adams wrote:
to make it easier for me to install my own script and dependencies. :)
COPR (https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/) exists,
in part, to scratch that specific itch.
Moving eventually to official builds once a COPR build is humming
VDPAU is not VA-API
that's correct
Setting VDPAU_DRIVER means nothing to Firefox because it is not using VDPAU.
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0#Detailed_Description
https://ffmpeg.org/doxygen/0.8/group__VDPAU__Decoding.html
"libva-vdpau-driver which allows to
On 11/16/21 22:48, Michael Cronenworth wrote:
On 11/15/21 12:03 PM, PGNet Dev wrote:
launch @ shell
VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox
I think you mean:
LIBVA_DRIVER_NAME=nvidia firefox
nope.
https://en.wikipedi
Video decoding on NVIDIA
Please buy some real Linux hardware.
This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?
After trying to configure HW acceleration on 9xx series GPU, I'll just take
that as a serious response.
Consider following points:
*
randomly poking at headers, just
dnf reinstall kernel-devel
made no difference to the problem
but, complete removal/install
dnf remove kernel-devel
dnf reinstall kernel-core
dnf install kernel-devel dkms bison flex
did.
now, after nvidia install & subsequent
On 10/24/21 00:10, Reon Beon via devel wrote:
This is what I found.
"11 hour ago"
https://forums.developer.nvidia.com/t/nvidia-470-74-build-error-unable-to-load-the-nvidia-drm-kernel-module-modprobe-error-could-not-insert-nvidia-drm-exec-format-error/19287
Right. I posted it.
i'm building nvidia kernel mod, for use with a pci nvidia card
inxi -G | grep Dev
Graphics: Device-1: NVIDIA GK208B [GeForce GT 710] driver: N/A
Device-2: Advanced Micro Devices [AMD/ATI] Cezanne driver: N/A
on a new install/build,
cat
So if you only rely in things like OpenJDK (like for running
Minecraft, as I do, too), then you'll be fine.
If you need ant or maven, you should be fine too, since those two (and
their dependencies) will continue to be maintained.
But everything else ... *tumbleweeds*
Just one user's snapshot;
Many valid/interesting points being made. Most of them sound, reasonably, like
developer-/maintainer-centric issues.
Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its
(java app) users?
If so, what's the current understanding of a user-driven ProductRequirements
On 9/9/21 14:22, Neal Gompa wrote:
On Thu, Sep 9, 2021 at 2:06 PM PGNet Dev wrote:
On 9/9/21 13:53, Florian Weimer wrote:
Can the Firefox build be distributed among multiple machines?
I frequently deploy FF from upstream builds, with updates managed from within
the app.
Q: Is there any
On 9/9/21 13:53, Florian Weimer wrote:
Can the Firefox build be distributed among multiple machines?
I frequently deploy FF from upstream builds, with updates managed from within
the app.
Q: Is there any historical _measure_ of security issues fixed in @Fedora FF
pkgs, before upstream gets
On 9/8/21 06:28, Sérgio Basto wrote:
I think the gui of pdftk that I used is pdfchain, I also built pdfchain
in my copr repo [3] , if both packages works well I can unretire them .
Thank you
fyi, here on f34
dnf install bouncycastle
rpm -Uvh \
On 6/24/21 6:40 AM, Miro Hrončok wrote:
On 24. 06. 21 11:16, Tomas Tomecek wrote:
## Choosing git forge to host source-git repositories
We need to find a home for all the source-git repositories. This is
actually a really hard task because we have many options (github.com,
gitlab.com,
On 6/18/21 1:42 AM, Mark Otaris wrote:
For Fedora, linux-hardware.org says 78% use EFI and 16% have Secure Boot
enabled. Not a very good data set, though Fedora telemetry wouldn’t be either.
Of ~ 1K linux boxes in my env -- bare metal & VM, servers & desktops --
~ 550 are now running fully
one of the more important trusts
we place in the parties in question is to protect the privacy of tens
of thousands of *other* people's private conversations.
Sure. As do we all. Mostly. Kind of. Ok, hopefully.
Again, to _my_ read, _I_ see absolutely nothing in either side's recent
due specifically to Andrew Lee's actions.
I'd bet $0.05 and a half-eaten donut that most folks shrieking about this would
be hard-pressed to regurgitate much of anything beyond 'headlines', with little
actual insight into objective details.
But then, I'm often wrong.
Now, back to real work
Andrew Lee has a flexible relationship with the truth. This is not a both sides
issue, as every other free software project has also agreed.
Well, it seems you're good then. So, great.
Just for me, not my 1st rodeo dealing with the spectrum from
megalomaniacal-sociopathic-CEOs to
On 5/28/21 12:14 PM, Adam Williamson wrote:
On Fri, 2021-05-28 at 12:01 -0400, PGNet Dev wrote:
On 5/27/21 2:04 PM, Nick Bebout wrote:
Since its beginnings, the Fedora Project has used the freenode IRC network for
our project communications. Due to a variety of recent changes to that network
On 5/27/21 2:04 PM, Nick Bebout wrote:
Since its beginnings, the Fedora Project has used the freenode IRC network for
our project communications. Due to a variety of recent changes to that network,
the Fedora Project is moving our IRC communications to Libera.Chat.
If a still-fuzzy "variety
On 5/27/21 10:45 AM, Nikolay Nikolov wrote:
That is quite a painful process. And how do you do that on a MBR system that
dual boots Fedora and Windows 10? I really don't want to go through the pain of
reinstalling Windows and all the programs that I have there.
There's no migration path that
the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
There's been no assumption that "all" want any-one-thing.
As for common, print-from-any-device-you-use is
On 5/26/21 4:47 PM, Solomon Peachy wrote:
But disabling mDNS altogether might cause undesired regerssions elsewhere.
Sure. Particularly if you don't set up your /etc/nsswitch.conf correctly.
Hence the 'YMMV'.
In general, we assume zero-trust and avoid enabling auto-anything. We add
trust
On 5/26/21 4:28 PM, Björn Persson wrote:
You have always had (and always will) have that choice; the ability to
disable automatic printer discovery has been present since discovery was
added with CUPS 1.2 (released back in 2006!)
I'll have to see if I can find that option. Thanks for the hint.
Endless theoretical discussions ... Interesting, but _is_ there real-world, end-user doc
available for installing and using papp-et-al on Fedora, today? A "do this
now" for end users? TBH, I'm unclear (and no, I haven't gone digging ...)
Here, I've got hundreds of networked printers. _Many_
On 5/14/21 2:05 AM, Juha Tuomala wrote:
here,
Sure. But this is devel list. Are developers themselves the target audience?
:) Hopefully not. Is it defined somewhere?
by 'here', I meant my company environment, not just this list.
and, yes, 'developers themselves' -- again, "here" -- *are* a
hi,
On 5/13/21 6:06 PM, Sérgio Basto wrote:
mock -r fedora-34-x86_64 --rebuild
lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
also fails in my machine, %forgesetup -z 0 is where it fails
hm. whereas a non-isolated, local rpmbuild works, as per my OP,
a *mock* build here
I've a package .spec, that uses forgemeta macros, that builds locally just fine
on F34.
Same spec @ COPR, F34 chroot, fails.
Something's either missing on my end, or broken @COPR. Likely obvious pebkac,
but I'm not seeing it.
Any insights as to why the same spec, @COPR, is failing would be
On 5/13/21 10:48 AM, Juha Tuomala wrote:
Virtual machine installation is hopefully a special use case and majority of
installations are bare metal end users.
hardly.
here, for any given single bare-metal install, between cloud & local VMs, there
are typically *many*/*frequent* VM installs --
On 5/13/21 10:09 AM, Richard W.M. Jones wrote:
Not everyone is installing a public facing server. On my isolated,
non-networked test instances I want to put up a short-lived VM with a
root password of "123456" quickly and no user account, and this option
lets me do that.
this^^ is a _very_
On 5/1/21 8:02 PM, Chris Adams wrote:
Once upon a time, PGNet Dev said:
my $0.02
leave the root via password option, but simply DISABLE it by default, rather
than REMOVING it.
That's what is going to happen - the openssh-server package will follow
upstream default (PermitRootLogin without
On 5/1/21 7:23 PM, patra...@gmail.com wrote:
On 4/30/21 10:23 AM, Richard W.M. Jones wrote:
+1
in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS.
Ubuntu Server installer handles this in a very nice way by allowing to import
SSH keys from a GitHub account given a
On 4/30/21 10:23 AM, Richard W.M. Jones wrote:
Because distributing SSH keys to temporary VMs is hard? Not
everything is a long-lived machine connected to the internet.
+1
in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS.
Hi,
OFFLIST as it's not directly pertinent to your specific distro pkgs.
but, since you're packaging, fwiw, I take a very different approach than
distro-pkgd atm,
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-33-x86_64/02142389-nginx/nginx.spec
that puts
On 4/12/21 3:51 AM, Javier Martinez Canillas wrote:
I dropped it by mistake when rebasing to 2.06, sorry about that. I've
fixed it now in F33, F34 and Rawhide.
i see rawhide has 'stable' already; and that F33/F34 are 'pending->testing'.
thx!
___
Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to
solve major critical vulnerabilities and it's very difficult to pull
the patch set that fixes it (>115 patches!) backwards, GRUB got moved
forward instead.
GRUB 2.06~rc1 was pretty much released to release the patch set...
tangentially related ...
distro update on f33 from grub 2.04-release -> 2.06-rc (re)breaks Xen boot on
EFI.
already reopened the original bug, but a question:
is it normal/expected to push an *rc* (grub 2.06-rc, in this case), to
'supported' fedora (33) *release*?
unreleased f34/rawhide I
If the /boot/loader/entries directory is exists, kernel-install will use it.
systemd-boot cannot read configs from this directory.
fyi,
https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries
https://www.freedesktop.org/software/systemd/man/systemd-boot.html
Actually, the buggy file (/etc/grub.d/20_linux_xen) belongs to the grub2
package, so the bug is assigned to a wrong package.
Not that it matters, but I'd originally assigned it to grub. It was ignored
there as well.
I switched it to Xen after I was told in #irc to do so.
Too much pushing
On 2/5/21 8:13 AM, Neal Gompa wrote:
On Fri, Feb 5, 2021 at 6:31 AM PGNet Dev wrote:
Hm. Can't manage to get a fix, a reply, or interest.
Is Xen packaging/support abandoned for Fedora?
No. But the maintainer of Xen in Fedora doesn't pay attention to the
devel@ mailing list.
You can see
Hm. Can't manage to get a fix, a reply, or interest.
Is Xen packaging/support abandoned for Fedora?
On 2/3/21 12:09 PM, PGNet Dev wrote:
F33 on EFI + Xen delays 30+ seconds, sometimes hangs, on boot @ grub2 error,
...
Loading Xen 4.14.1 ...
error: ../../grub-core/fs/fshelp.c
F33 on EFI + Xen delays 30+ seconds, sometimes hangs, on boot @ grub2 error,
...
Loading Xen 4.14.1 ...
error: ../../grub-core/fs/fshelp.c:257:file
`/EFI/fedora/x86_64-efi/module2.mod' not found.
Loading Linux 5.10.9-201.fc33.x86_64 ...
Loading initial
And you're spamming MY 'private mailbox' now?
Who made you the consumer police?
Now, get lost, troll.
On 1/27/21 11:01 AM, Marius Schwarz wrote:
Am 27.01.21 um 16:53 schrieb PGNet Dev:
And that somehow justifies 'notifying the legal department' as a 1st response?
Yeap, because he spammed
On 1/27/21 10:44 AM, Matthew Miller wrote:
On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote:
I thought it was a public mailing list, I noted the subject was Commercial
in the Header as stated on the Fedora Guidelines:
On 1/16/21 12:35 PM, PGNet Dev wrote:
+ /usr/lib/rpm/brp-strip /usr/bin/strip
/usr/bin/strip: unable to copy file
'/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
reason: Permission denied
error: Bad exit status from /var
I'm building a pkg @ COPR, 'dhcpcd',
https://copr.fedorainfracloud.org/coprs/pgfed/dhcpcd/build/1885349/
for both F32 & F33 chroot targets.
The F32 build succeeds, pkg installs & execs OK,
dhcpcd client pkgs @Fedora
https://src.fedoraproject.org/rpms/dhcpcd
are years out of date, currently versioned at
Fedora 33 dhcpcd-6.11.3-11.fc33
Fedora 32 dhcpcd-6.11.3-10.fc32
as per comment,
On 12/4/20 3:08 AM, Matthias Runge wrote:
otherwise, it's YA-trivial DIY build ...
Thank you for looking into this. Since you already did the work,
would you mind to propose a patch here, especially, if it's trivial?
I'm asking abt non-response -- if the 'official' pkgs are maintained, or
unbound upstream release version is now a 1.13
Fedora packages
https://src.fedoraproject.org/rpms/unbound
are several versions behind.
no response from maintainer in months, re updates, @
https://bugzilla.redhat.com/show_bug.cgi?id=1860887
anyone know what's up with unbound pkgs
On 12/2/20 8:13 AM, Artem Tim wrote:
Vbox also available in RPM Fusion repo
https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/
Works OK in f33.
Didn't know about those -- thx.
Visit to the rpmfusion site returns:
"Firefox does not trust koji.rpmfusion.org because its
Is there an available/alternative option for VirtualBox repo installs on F33?
Currently,
http://download.virtualbox.org/virtualbox/rpm/fedora/
has only up to F32.
This thread
https://forums.virtualbox.org/viewtopic.php?f=7=100418
is the latest info I've found; atm, no pkgs,
On 11/2/20 9:22 AM, Neal Gompa wrote:
Work migrated to Chrony a year or so ago. The only thing I use from
ntp is the "ntpdate" tool. Everything else is chrony now. :)
out of curiosity, what's lacking for your use case?
ntpdate, here, was primarily for "set it now" interventions.
that, at
On 10/19/20 11:33 AM, Hans de Goede wrote:
I guess those machines are more or less the cut-off point and slower machines
are not worth keeping around. But that means that there still are a ton
of BIOS machines worth keeping around.
Note that even most sandy bridge machines do not support UEFI
On 9/30/20 2:34 PM, Paul Wouters wrote:
> And as I indicated earlier, most server installs have no use for
> systemd-resolved. Yes it can be disabled, but we didn't go all the
> way to virtual servers and containers to have to install things
> we will never use.
+1, & simply 'minimal' installs
anyone else more confused?
On 9/30/20 1:26 PM, Neal Gompa wrote:
> And like it or not, all our legacy network configuration mechanisms
> are deprecated and*will be removed eventually*.
is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct
dependency on systemd-resolved --
On 9/30/20 11:21 AM, Paul Wouters wrote:
> It also allows those Destop users that want to use their own validating
> resolvers on the end node to uninstall systemd-resolved.
Would separating the package preserve existing setups across upgrades?
It's not simply Enterprise/Server 'or' Desktops
On 9/30/20 9:50 AM, Michael Catanzaro wrote:
> You'll need to manually disable systemd-resolved after upgrade, restore
> /etc/resolv.conf from the backup file that will be created during upgrade
So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED +
'my' /etc/resolv.conf --
On 9/30/20 9:16 AM, Neal Gompa wrote:
> If you're not using NetworkManager, this change has _zero_ impact.
perfect.
clearly, i've missed or lost the obviousness of that incredibly useful tidbit
in this novella :-/
thx!
___
devel mailing list --
Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^
is.
What _is_ clear is that there's significant disagreement -- which,
unfortunately, has at times here become nasty & personal -- about needed vs
planned functionality, and, of late, regulatory compliance.
And,
On 9/28/20 11:21 AM, Andrew Lutomirski wrote:
> I would have expected NetworkManager to handle this kind of setup just fine.
> What went wrong?
getting offtopic, but ... a laundry list.
including broken routes, missed existing unit-file interface dependencies
particularly once bridges get
On 9/28/20 11:03 AM, Lennart Poettering wrote:
> I have the strong suspicion that the same people who are
> able to deploy working DNSSEC client side and are educated enough in
> DNSSEC to know what that even means are also capable of replacing that
> one symlink in /etc.
i'll start with: i'm
on
grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 32 (Server Edition)"
uname -rm
5.8.7-200.fc32.x86_64 x86_64
with
rpm -qa | grep xen
xen-4.13.1-4.fc32.x86_64
xen-hypervisor-4.13.1-4.fc32.x86_64
On 8/7/20 5:57 AM, Petr Pisar wrote:
> I think the build script does not use Perl configuration consistently. It uses
> ldflags value for the linker flags, but it does not use ld value for the
> linker
> exectable:
...
> $ perl -MConfig -E 'say $Config{ldflags}'
> -Wl,-z,relro -Wl,--as-needed
i'm attempting to build a MaxMind GeopIP2 DB reader perl module
MaxMind::DB::Reader::XS
( https://metacpan.org/pod/MaxMind::DB::Reader::XS
)
on Fedora 32.
the build fails on F32 with Errors:
"/usr/bin/ld: unrecognized option '-Wl,-z,relro'"
&
"Unsupported
On 7/13/20 3:20 PM, Jerry James wrote:
> On Mon, Jul 13, 2020 at 4:15 PM PGNet Dev wrote:
>> i can easily manually create the group, but ... this suggests something's
>> missing/broken in my install; I'd like to find/fix it.
>>
>> if not 'mock' what pkg (re)ins
i've installed a minimal F32 instance
building up the rpmbuild env, 'mock' pkg is installed
rpm -qa | grep mock
mock-core-configs-32.6-1.fc32.noarch
mock-2.3-1.fc32.noarch
there's _no_ expected 'mock' group installed
getent group mock
On 7/10/20 1:26 AM, Nicolas Mailhot wrote:
Le jeudi 09 juillet 2020 à 09:40 -0700, PGNet Dev a écrit :
I'm working on a spec, pulling source with forgemeta/scm
With known/supported scm sources (e.g., github), it works as
expected, with no issues.
involves writing the lua equivalent
I'm working on a spec, pulling source with forgemeta/scm
With known/supported scm sources (e.g., github), it works as expected, with no
issues.
Atm, I'm trying to pull from a different source,
git.kernel.org
with this 'ofono-test.spec'
On 7/6/20 8:27 AM, Björn Persson wrote:
> Florian Weimer wrote:
>> * Björn Persson:
>>
>>> The macro could be defined like this for example:
>>>
>>>%buildtag .%(date +%%s)
>>
>> Using time for synchronization is always a bit iffy.
>
> Well, if somebody manages to build a package twice within
On 7/3/20 2:07 PM, PGNet Dev wrote:
> from cmd line,
>
> copr-cli edit-chroot --packages git
>
> looks like it should work as well
and it does, nicely:
==> 14:26:43 Build 1517366: succeeded
___
devel mai
On 7/3/20 8:24 AM, PGNet Dev wrote:
> git _was_ trivially added to the local mock chroot, for its use, with obvious
> success, in the local mock build of the spec.
>
> COPR uses mock.
>
> So far, I have not seen how that's to be similarly done for the COPR env.
>
> Is i
On 7/3/20 11:22 AM, Paul Howarth wrote:
> Remember
ugh. well, i certainly will NOW! ;-)
> that '%' introduces a macro expansion, so if that's not what
> you want, you should escape the '%' as '%%':
>
> %define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S )
works perfectly. thx!
on F32,
date +FORMAT,
date +%Y%m%d_%H%M%S
returns
20200703_105351
as expected.
in an rpm .spec, if I define
%define _build_timestamp %( date +%Y%m%d_%H%M%S )
and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of any of
hi,
> ...
All the above^ is an interesting/informative read.
On 7/3/20 2:31 AM, Nicolas Mailhot via devel wrote:
> The requester is clearly attempting the second approach.
Well, not explicitly. I'm not requesting any _specific_ approach.
The goal is simply to 'build it here (locally, via
(i'd been discussing this issue with praiskup @ copr-devel/buildsys; he
suggested that I bring it here ...)
This spec
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec
which uses forgemeta to pull multiple SCM sources,
On 6/30/20 11:38 AM, Tom Seewald wrote:
> The primary areas of concern I have about Fedora dropping grub2 and BIOS boot
> support are:
nicely summarized.
> 4. Support documentation for sd-boot
>
> Would this result in changes to how users access the boot menu, select a boot
> entry, or edit
On 6/30/20 8:24 AM, nick...@gmail.com wrote:
> I've never tried UEFI in a VM, and I have no idea how stable it is.
IME, works well in a variety of hypervisors; atm, my 'exploration' of Fedora32
is running solely in VirtualBox VMs ... booted UEFI.
That said, their a lots of providers that have
On 6/30/20 8:07 AM, Jóhann B. Guðmundsson wrote:
>>> I think there are many people still install OS in the legacy mode, but
>>> I don't really have numbers.
I've just started working with Fedora 32 ~ a week ago. Looking at it as a
migration option, for imo a lot of _good_ reasons, from current
On 6/26/20 9:35 AM, PGNet Dev wrote:
> that said, _can_ such bash-ism be used in "getting" a forge commit value?
nm, pebkac!
%( git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}' )
seems to work.
sry 4 the noise.
___
devel
while 'exploring' some of the limits of forge syntax/usage, trying to see
if/how bash expansion might work, i find that:
neither
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global commit1 git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}'
nor
hi,
On 6/25/20 11:58 PM, Nicolas Mailhot wrote:
> forgemeta works in release mode, with release archives published over
> http(s). It does not talk at all to source projects using the git
> protocol (and that is intentional, since a lot ot things tooling-side
> do not talk the git protocol and
96 matches
Mail list logo
