have orphaned the plugins. Good luck to anyone that wants
to take them over.
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https
- Original Message -
> I tried qemu using this link but it's wildly out of date...
>
> https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU
>
Updated for Fedora 33.
> I updated the url for Fedora 33 but it still fails...
>
> sudo virt-install --name
tal SSL cert.
Pidgin is specificaly bad with this, firefox has builtin logic to prevent
all its tabs from reloading in captive portal page clones.
Instead, we have gnome, NM, systemd-resolved, firefox et all fighting
over who and how to handle captive portal a
seems a waste of resources?
Paul
___
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.org/en-US/project/code-of-conduct/
List Guidelines
focus!
I will try it out over the next few days. My personal usecases would be
that it still keeps working with rsync's method of invoking scp and that
we would have sftp enable by default for sshd by default.
Thanks!
Paul
___
devel mailing lis
rnel-devel: https://bugzilla.redhat.com/show_bug.cgi?id=1873876
--
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedorapr
On Thu, 8 Oct 2020, Michael Catanzaro wrote:
On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters wrote:
I agree for two reasons. One, the FESCO decision to postpone making
systemd-resolvd the default resolver. I would like to ensure this
change happens properly and securely for f34.
Well it's
becomes eveb more important. And DNS-over-TLS only
provides transport security, not data origin authenticity.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
On Thu, 8 Oct 2020 15:30:43 +0200
Pierre-Yves Chibon wrote:
> On Thu, Oct 08, 2020 at 03:27:22PM +0200, Pierre-Yves Chibon wrote:
> > On Thu, Oct 08, 2020 at 03:22:46PM +0200, Emmanuel Seyman wrote:
> > >
> > > Hello, all.
> > >
> > > Ralf C
e suggests it does not support this yet, but I'm pretty
sure upsteam would accept a patch.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Condu
g "but it leaks over there too" is not a
very strong argument to leak data yourself.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://d
stream as an active firewall.
Paul
___
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.org/en-US/project/code-of-conduct/
List
and ensure to then disable and keep disabled, the
systemd-resolved daemon.
The argument against this so far has been "it makes things more
complicated". I have asked for specific details on this so we can
talk about potentially addressing those complications and make
ev
ve it is _very_ common use case.
Paul
___
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.org/en-US/project/code-of-conduct/
List Gu
ng reasons not to split systemd-resolved in its own
package, I would like to better understand these reasons.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
ces. I did this specifically to prevent being seen as derogatory.
As we share the same employer, I encourage you to escalate my
"derogatory behaviour" to our magenement.
I did not read the rest of your email. I will not read or respond to
further emails from you on
it, we
rewrite resolv.conf and send all queries over the VPN. As I said, I'll
work on adding systemd-resolved support here for the next version of
libreswan.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to de
ld seriously FALL IN LOVE with systemd-resolved for doing 2) and 3)
even if I had to sometimes manually do 4) and 5)
I will work on extending 3) with VPN support in libreswan for IKEv1 and
IKEv2 based IPsec VPNs.
But 1) is crucial to widespread voluntary adoption. Without 1) we have
what applications expect and depend on.
So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented"
That is not what I see:
paul@thinkpad:~)$ dig +dnssec nohats.ca @127.0.0.53
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>
.
The software that decided that DNS answers are too security sensitive to
not be validated is now blamed for not trusting the system resolver
after it found said system resolver was untrustworthy.
As John Gilmore used to say, if you can't not trust your friends, who
can you not trust? :)
Paul
deal. It's annoying to have to edit an
extra config file, yes, and we should do better, but I don't think that
should derail this change.
If systemd-resolved was only installed on Linux desktops, you would have
a much stronger argument. But right now it is part of the same package
:
https://github.com/systemd/systemd/issues/8967
Not migrating everything to systemd-resolved per default would not be the
worst solution.
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Listen or read to Paul Vixie, father of many Bind software releases:
https://www.youtube.com/watch?v=ZxTdEEuyxHU
https://www.theregister.com/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_feature_becomes_a_standard/
There are use cases for and against routing all DNS over your VPN. If
systemd wants
nce there is a clean internet link, use
DoH or DoT to a known truted (non-coffeeshop) DNS server.
What we do not need is systemd-resolved making up its own incompatible
and unsuspected protocols.
Paul
___
devel mailing list -- devel@lists.fedoraprojec
about this.
The bar should never be "breaking the system is fine for advanced users"
The signal you are sending me (and others) right now is the wrong
signal. systemd should works for me, the user.
Paul
___
devel mailing lis
you should act. And yes, some of that
might depend on the VPN provisioning configuration.
libreswan already implements support for the unbound DNS server to
reconfigure DNS limited to the domains covered by the VPN. This can be
extended to support systemd-resolved if you point me to a documentation
solve.conf that now point to systemd-resolvd that does not
return DNSSEC records and is completely broken:
paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @127.0.0.53
;; global options: +cmd
;; Got ans
yground as in EPEL-8 proper are automatic builds rather
than manual ones?
That would certainly reflect my own usage, where almost all of my
packages would be the same, but my manual build of proftpd is different.
Paul.
___
epel-devel mailing list -- epel-dev
Thanks for the link !
But about the confidential part it's an automatic signature that I can't remove.
--
Paul TREHIOU
EURO INFORMATION PRODUCTION
Systèmes & Réseaux – SYSTEMES UNIX (3O30)
-Message d'origine-
De : Petr Pisar
Envoyé : jeudi 3 septembre 2020 12:07
À : epel-d
Hello
I am using the python2-jsonschema package but noticed it is out of date on EPEL
(2.5.1). On Fedora the latest version is available (3.2.0). Is it possible to
backport the latest Fedora version into EPEL ?
Thanks,
--
Paul TREHIOU
}}} EURO INFORMATION
lar issue, please let me know.
>
> Thanks for any help.
> Lukas
Looks like you might be hitting
https://bugzilla.redhat.com/show_bug.cgi?id=1850198 (changed api for
fail_if and fail_unless in check), the workaround for which now
introduces warnings, and they
solation-simple and it stopped complaining.
Maybe that would help you too?
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproje
ut and back in again.
>
> +1 on that.
If you remove the "with multiple user accounts" then being able to log
in and out on a single-user system would satisfy the requirement even
if the multi-user bug was present, which wouldn't be very helpful.
Paul.
), so it shouldn't be
*too* hard to fix but upstream has been inactive for a few years now.
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https
pghmcfc commented on the pull-request: `Use make macros` that you are following:
``
I did a bigger change that used %{make_install} too.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Compress-Raw-Lzma/pull-request/1
___
pghmcfc closed without merging a pull-request against the project:
`perl-Compress-Raw-Lzma` that you
are following.
Closed pull-request:
``
Use make macros
``
https://src.fedoraproject.org/rpms/perl-Compress-Raw-Lzma/pull-request/1
___
perl-devel
On Tue, 19 May 2020 19:00:25 +0100
Paul Howarth wrote:
> On Tue, 19 May 2020 09:21:46 -0700
> Kevin Fenzi wrote:
>
> > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen
> > wrote:
> > > On Tue, 19 May 2020 at 11:05, Paul Howarth
> > > wrot
, so if that's not what
you want, you should escape the '%' as '%%':
%define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S )
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Or just a new option to rpmbuild that skips %check ?
Sent from my iPhone
> On Jun 5, 2020, at 10:11, Tomas Orsava wrote:
>
> Hi,
> I think it would be useful to have a standard way of disabling the running of
> tests during RPM build (in the %check section of a spec file).
>
> I see a lot
had forgotten to reply also to the list... doing it now:
[cut the part where it was suggested to make package that contains LLVM
Intermediate Representation bitcode rather than CPU specific assembler]
On 2020-05-29 1:01 a.m., John M. Harris Jr wrote:
Paul,
What benefit do you see
On 2020-05-28 7:36 a.m., Dridi Boukelmoune wrote:
On Tue, May 26, 2020 at 12:07 PM Jan Kratochvil
wrote:
On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote:
The idea was to push code generation as near as possible of code execution.
Because at execution time, you know what
First I'd like to thanks people that made me realize I was confusing the
GPT's partition type GUID and GPT's Unique partition GUID. And to also
mention the filesystem UID.
Because Fedora choose not to apply the BLS partition type GUID or BLS
MBR type id, I believe we generate the following
Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit :
The change record for this states that we are not following the BLS at
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but
the proposed update at
https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ .
Thanks for
Well... I will try to repeat more clearly my claim:
If Fedora want to pretend to implement the Boot Loader Specification, it
must, on a new disk formatted in GPT, end up with an entry in fstab for
an ESP partition mounted on /boot:
"These directories are defined below the placeholder file
Le 20-05-24 à 05 h 47, Barry Scott a écrit :
...
But I cannot boot a live CD image as it gets stuck
in "Monitoring of LVM2 mirrors, ...". This is not a
new problem I have seen this for a couple of Fedora
releases, but not reported it before.
Is it possible you don't wait enough, that is about
It finally installed...
One of the first problem I have, is /boot have not the correct GUID for BLS:
[paul@localhost /]$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Sun May 24 11:48:45 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5)
Well... it take time to me to get used to the Boot Loader Specification.
I am being lazy here... asking people on the mailing list rather than
trying to determine it myself.
After making an installation of Fedora, I begin to think:
Hey, I don't remember having seen the installer like
On 5/23/20 11:26 PM, Neal Gompa wrote:
> On Sat, May 23, 2020 at 11:22 PM Paul Dufresne via devel
> wrote:
...
> It's completely toast on Linux for the same reason FatELF was: nobody liked
> it.
...
I think this is different than FatELF. The idea of FatELF, is that it
contains t
I sometime ask myself what have happened to the "LLVM dream"?
The idea of LLVM was not to be *just* an intermediate language for the
compiler. The idea was to push code generation as near as possible of
code execution. Because at execution time, you know what are the
specific features of the
On 5/22/20 4:22 PM, Parker Gibson wrote:
I don’t think this is specifically about FHS as it is about shared library
management. The underlying hierarchy defined in FHS doesn’t make the dictations
about version management that you seem to indicate, nor are the major problems
with maintaining
The File Hierarchy Standard (FHS), is a standard that define where the
files of a package should be placed in the root directory of the
systems. It probably did not change much since the beginning of Unix,
and it make files be placed where users, developers and administrators
expect them to
On Wed, 20 May 2020 08:10:42 +0200
Petr Pisar wrote:
> On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> > On Tue, 19 May 2020 09:07:30 -0400
> > Stephen John Smoogen wrote:
> >
> > > On Tue, 19 May 2020 at 06:05, Paul Howarth
> > > wrote
ause
perl-common-sense, perl-JSON-XS and perl-Types-Serialiser are available
in the EL-8 Code Ready Builder / PowerTools repo, which is a dependency
of EPEL-8:
https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
Is that repo not enabled in your EPEL-8 configuration?
Paul.
On Tue, 19 May 2020 09:21:46 -0700
Kevin Fenzi wrote:
> On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen wrote:
> > On Tue, 19 May 2020 at 11:05, Paul Howarth
> > wrote:
> > > On Tue, 19 May 2020 09:07:30 -0400
> > > Stephen John Smoogen wrot
On Tue, 19 May 2020 09:07:30 -0400
Stephen John Smoogen wrote:
> On Tue, 19 May 2020 at 06:05, Paul Howarth wrote:
>
> > On Mon, 18 May 2020 22:29:54 -0600
> > Orion Poplawski wrote:
> >
> > > On 5/17/20 6:34 AM, Paul Howarth wrote:
> > > &
On Mon, 18 May 2020 22:29:54 -0600
Orion Poplawski wrote:
> On 5/17/20 6:34 AM, Paul Howarth wrote:
> > I'm trying to do a local build of gtkwave for EPEL-8.
> >
> > A koji scratch build somehow works:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is
excluded
- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
excluded
Adding a repo with a local build of Judy doesn't help; that gets
excluded too.
Any clues?
Paul.
___
epel-devel
can safely depend on things in the PowerTools repo as it's expected
that EPEL-8 users will also use that repository:
https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
Looking at the BZ ticket, it seems you discovered that yourself.
Paul.
___
rolling release" does it make sense to just
> track 8-stream if you're using it, or are people resorting to hosting
> these key packages in internal repos?
That's what I'm doing. I got the sources from CentOS git
(https://git.centos.org/rpms/zstd/tree/c8)
pghmcfc merged a pull-request against the project: `perl-B-Hooks-OP-Check` that
you are following.
Merged pull-request:
``
Spec file cleanups: Use_make_build and make_install macros, use NO_PACKLIST=1
``
https://src.fedoraproject.org/rpms/perl-B-Hooks-OP-Check/pull-request/1
pghmcfc commented on the pull-request: `Spec file cleanups: Use_make_build and
make_install macros, use NO_PACKLIST=1` that you are following:
``
Hi Tom, the Perl Tips URL is missing an "r" at the end:
```
<<< https://fedoraproject.org/wiki/Perl/Tips#ExtUtils::MakeMake
>>>
thon 2 version? I would hope that the Python 2
version wouldn't need to be maintained for too much longer anyway.
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
eeks).
>
> Does anybody want to be an admin of the group (I'ld rather not be
> alone to do this)? Who wants to be a member of the group?
I'll be a member.
Paul.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscri
Le 20-04-17 à 09 h 09, Benson Muite a écrit :
On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote:
Elections for alternative wallpapers are currently open:
https://apps.fedoraproject.org/nuancier/elections/
Please vote for ones that you like.
Is the default wallpaper the result of a vote, or
but upstream developers (which is the
> case here) should correct that error. Our wiki links to a version of
> GPL 2 with the correct address:
> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
I view the rpmlint warning as a hint to try t
n pagure and dist-git
>
> * The privileges are given
> * They then request a branch, and build the package in EPEL-X
> following normal steps.
I think there's also a good case for the requester to be made the
bugzilla contact for EPEL for that package, though it would be
complicated if
I saw that Nvidia published version 440.82 of their drivers today.
Last one was 440.62 released on February 28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
I can just disable these tests downstream, but
> upstream might take a change if I can wrap them in a "if !mock"
> condition.
Why not test for the presence of /dev/log before running such tests?
Paul.
___
devel mailing list -- d
|Le 20-04-06 à 21 h 01, Paul Dufresne a écrit :> BTW, thanks I was
searching for an example of package using a git||version rather than a
released archive!||
|
|Just for the record, *I think* the current package is a bad example of
a package using a forge like git.|||
||
|Current
ht
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and
make_install macros, use NO_PACKLIST=1` that you are following:
``
I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference.
It's now pushed and built in Fedora.
``
To reply, visit the link
pghmcfc closed without merging a pull-request against the project:
`perl-Socket6` that you
are following.
Closed pull-request:
``
Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
``
https://src.fedoraproject.org/rpms/perl-Socket6/pull-request/1
Le 20-04-06 à 15 h 34, Adam Jackson a écrit :
On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
I think we have a fix for that. Let me poke at things a bit.
Have read:
https://www.phoronix.com/scan.php?page=news_item=Mesa-i915-OpenGL-2-Drop
In the link Alexei posted to Arch,
Le 20-04-06 à 15 h 34, Adam Jackson a écrit :
On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
2.1 used to be enabled on this hardware, but got dropped
I think we have a fix for that. Let me poke at things a
pghmcfc closed without merging a pull-request against the project:
`perl-String-CRC32` that you
are following.
Closed pull-request:
``
Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
``
https://src.fedoraproject.org/rpms/perl-String-CRC32/pull-request/1
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and
make_install macros, use NO_PACKLIST=1` that you are following:
``
I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference.
It's now pushed and built in Fedora.
``
To reply, visit the link
pghmcfc closed without merging a pull-request against the project:
`perl-Unix-Syslog` that you
are following.
Closed pull-request:
``
Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1
``
https://src.fedoraproject.org/rpms/perl-Unix-Syslog/pull-request/1
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build,
make_install macros, and use NO_PACKLIST=1` that you are following:
``
I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference.
It's now pushed and built in Fedora.
``
To reply, visit the link
itself ( Mesa Intel® UHD Graphics 630 (CFL GT2) ) I
have:
[paul@localhost ~]$ lsmod | grep i915
i915 2617344 18
i2c_algo_bit 16384 1 i915
cec 61440 1 i915
drm_kms_helper 245760 1 i915
drm 655360 7 drm_kms_helper,i915
Le 20-04-02 à 13 h 30, Samuel Sieb a écrit :
The problem is that in the past there have been some packages that
have had to be updated first to successfully do the upgrade. As Kamil
said, the list can change at any time. The easiest way to ensure the
upgrade works is to make sure that your
On Thu, Apr 2, 2020 at 1:12 PM Robbie Harwood wrote:
> Paul Frields writes:
> > Neal Gompa wrote:
[...snip...]
> >> It's also important to note that at the core of GitLab's incentive
> >> model is that they want to remove incentives to use FOSS solutions in
Le 20-04-02 à 07 h 01, Kamil Paral a écrit :
We failed to convince gnome-software maintainer to do the same:
https://bugzilla.redhat.com/show_bug.cgi?id=1336435
Well, actually I am more on the opposite side of you on this.
I am more like not wanting to updates so many packages for current
I tried to upgrade from F30 to F32 without doing updates first, and I got:
gnome-software[2045]: not handling error download-failed for action
refine: failed to refine distro upgrade: Failed to download gpg key for
repo 'fedora': Curl error (37): Couldn't read a file:// file for
https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html
For a solution to be viable it needs to meet requirements.
--
Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-
take away our tools, you take away the reason to be
> passionate about Fedora. And thus, you remove why people use and
> contribute to Fedora in the first place.
My reason for being passionate about Fedora is mainly about helping
people use the software and c
On Tue, Mar 31, 2020 at 5:23 PM Adam Williamson
wrote:
>
> On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> >
> > > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > > consume as a downstream. Project hosting has always been a kinda
&
> > our infrastructure the NFS shared storage also run an proprietary software
> > (NetApp).
>
> That's been covered already, and was why I put the "(more or less)"
> caveat into my quote. Of course, when you're getting to storage
> appliances, you're getting
Thanks to the person who suggested to change password in the web interface (at
least once, rather than changing by forgotten password).
I did the trick and now kinit works!___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
I am trying to follow instructions at:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
But when I do:
[paul@localhost ~]$ kinit pa...@fedoraproject.org
I get:
Password for pa...@fedoraproject.org:
kinit: Password incorrect while getting initial credentials
[paul@localhost
Le Wed, 25 Mar 2020 16:58:33 -0600,
Jerry James a écrit :
> Either I got lucky when I launched the Rawhide build, or something is
> fundamentally different between F32 and Rawhide. Clearly something
> nondeterministic is at work. I have been unable to reproduce this
> failure in mock so far,
f just deleting all the ones with subject "fedmsg update" and I
only look at the ones from bodhi.
Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
> Closing a bug doesn't clear the needinfo. Change the ? to blank under
> flags (or I'm happy to clear it for you if you'd like).
Ok, I have done it.
But I believe the outstanding bugs reminder should not include closed bugs!
___
devel mailing list
About outstanding bugs...
In my opinion, the frequency at which it is sent: every day, is way too often.
For me, once a month would make more sense.
Maybe... maybe once a week.
For me, the message contains this is a one bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1700171
For most of the
target's version of rpm anyway these days.
Paul.
___
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.org/en-US/project/code-of-cond
me but would mainly need buy-in from the packagers that
don't want to support EPEL as they'd have to have perl-packagers-sig
group added to their packages and they might have concerns about other
people committing updates in the Fedora branches.
Paul.
___
p
nk we can drop more without losing functionality.
> If you take a closer look, libdnf links to libcurl which pulls most
> of the dependencies.
In an environment where size matters a lot, you could use
curl-minimal and libcurl-minimal instead of curl and libcurl, which
On Wed, 26 Feb 2020 09:04:07 +
Paul Howarth wrote:
> I've been looking after the ancient Gnome 1 library stack for the last
> decade as I had a local use for the libraries. That is no longer the
> case so I'm planning to orphan the following packages, none of which
> appea
and I'll transfer them.
I'll still take care of the bottom two packages in the stack as they
still have several users in Rawhide:
* gtk+
* glib
Regards, Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
pghmcfc merged a pull-request against the project: `perl-Net-SSLeay` that you
are following.
Merged pull-request:
``
Spec file cleanups: Use make_build and make_install macros
``
https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1
___
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and
make_install macros` that you are following:
``
If you fix the comment I'll merge the PR.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1
JSON-Safe RPM package obsolete+provide perl-Cpanel-JSON-XS.
Cheers, Paul.
___
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
101 - 200 of 8800 matches
Mail list logo
