DT_RELR enabled in rawhide for aarch64 as well

Rawhide binutils recently gained DT_RELR (packed relative relocation) support on aarch64 as well, so redhat-rpm-config-293-1.fc41 enables it there as well. The only architecture missing is now s390x. I built a few thousand packages with this change and the most recent binutils, and did not see

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

On Wed, May 4, 2022 at 1:00 PM Miro Hrončok wrote: > On 04. 05. 22 15:40, Troy Dawson wrote: > > I just want to make sure that you are querying RHEL 9.0 and not 9.1. > > Well, I was querying 9.1, so you have a point. However, with 9.0 it is > almost > the same: > >

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

On 04. 05. 22 22:03, Josh Boyer wrote: The only difference I can spot is anthy-unicode-devel and double-conversion-devel, which apparently might be allowed in EPEL 9 for now. Both of those were requested and added in the last month (anthy-unicode-devel just this week). That should be reflected

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

On Wed, May 4, 2022 at 4:00 PM Miro Hrončok wrote: > > On 04. 05. 22 15:40, Troy Dawson wrote: > > I just want to make sure that you are querying RHEL 9.0 and not 9.1. > > Well, I was querying 9.1, so you have a point. However, with 9.0 it is almost > the same: > >

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

On 04. 05. 22 15:40, Troy Dawson wrote: I just want to make sure that you are querying RHEL 9.0 and not 9.1. Well, I was querying 9.1, so you have a point. However, with 9.0 it is almost the same: $ comm -12 <(repoquery -q --repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability} -a | pkgn

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

t; > libwmf > pybind11 > tesseract > tesseract-tessdata > > Thank you for this list, of source packages that are duplicates. We'll have to look into how they got built. > > As well as "binary" RPMs: > > $ comm -12 <(repoquery -q > --repo=RHEL9-{BaseOS,AppStr

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

On Wed, 4 May 2022 at 08:55, Miro Hrončok wrote: > Hello EPEL. > > I have just found out that the pybind11 component from c9s / RHEL 9 CRB > has > been built in EPEL 9 in different version: > > > > Do I understand correctly that this is still *not* allowed? If so, what > can we > do to

[EPEL-devel] RHEL 9 packages available in EPEL 9 (in different versions as well)

-12 <(repoquery -q --repo=RHEL9-{BaseOS,AppStream,CRB,HighAvailability}-source -a | pkgname | sort | uniq ) <(repoquery -q --repo=epel9-source -a | pkgname | sort | uniq) libwmf pybind11 tesseract tesseract-tessdata As well as "binary" RPMs: $ comm -12 <(repoquery -q -

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

On Mon, 2020-04-13 at 17:52 -0500, Richard Shaw wrote: > > 2. JSON may be fine for machine readability but it SUCKS for human > readability. Both brackets and braces! Do I need a "," after that one? All > I know is I screw around with it until vim doesn't show me any more red > highlights.

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

On Mon, Apr 13, 2020 at 8:05 PM Scott Talbert wrote: > > Have you tried the py3 branch of chirp? > https://chirp.danplanet.com/projects/chirp/repository/show?rev=py3 Not in some time. From a packager POV I have no way to tell if it's ready for "prime time" and I don't want to be responsible

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

On Mon, 13 Apr 2020, Michael Catanzaro wrote: So how do I get a functional python2 interpreter and access to pip? As a short-term solution, you can switch the runtime-version in your manifest to 18.08, but this runtime will only be supported for four more months, until August (when the

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

On Mon, Apr 13, 2020 at 5:52 pm, Richard Shaw wrote: So how do I get a functional python2 interpreter and access to pip? As a short-term solution, you can switch the runtime-version in your manifest to 18.08, but this runtime will only be supported for four more months, until August (when

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

There's definitely some cool > technology there, but clearly it's not made for humans to work with. > It feels like you need too much built-in knowledge and understanding > of the pieces below you that do automagic to be able to use it well. > In essence, it feels a lot like how Debian

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

the nail on the head for why I've personally not been interested in Flatpaks. There's definitely some cool technology there, but clearly it's not made for humans to work with. It feels like you need too much built-in knowledge and understanding of the pieces below you that do automagic to be able to use

RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

So with Python 2 being fully removed (more or less) with Fedora 32, Fedora 31 is the last version that will contain Chirp, which is an important and the ONLY tool for Amateur Radio operators to program radios in linux. Don't get me started on upstreams lack of interest on correcting the issue...

Re: Fedora 31 Does Not Use Swap Well?

d, both of these become CPU bound due to compression/decompression, as well as IO bound. It definitely helps moderate the badness of swap use, but it's not a cure. - The in-kernel out of memory manager (oom-killer) does not at all care about user space. It doesn't care about responsiveness or in

Re: Fedora 31 Does Not Use Swap Well?

Lukasz I am not sure if this is related to virtualization as I installed Windows 10 on VirtualBox and the performance was quite fine, but as soon as Android VM starts up, the performance suffers painfully, almost every event (e.g. mouse) has 2-5 seconds delay in response. I tried a virtual device

Re: Fedora 31 Does Not Use Swap Well?

Data Sun, 10 Nov 2019 15:41:26 -0500 Code Zombie napisał(a): > I recently installed a fresh Fedora 31 in order to improve > performance. I have started to have a new problem. When my memory > fills up when launching an Android emulator, the system starts acting > very slowly and becomes quite

Re: Fedora 31 Does Not Use Swap Well?

On Sun, 10 Nov 2019 at 20:44, Code Zombie wrote: > Some more info following my last Email, Swap is 8GB (equal to memory) and > the hard disk is a 2-year old 250 GB SSD. > > On Sun, Nov 10, 2019 at 3:41 PM Code Zombie > wrote: > >> >> Hi, >> I recently installed a fresh Fedora 31 in order to

Re: Fedora 31 Does Not Use Swap Well?

Some more info following my last Email, Swap is 8GB (equal to memory) and the hard disk is a 2-year old 250 GB SSD. On Sun, Nov 10, 2019 at 3:41 PM Code Zombie wrote: > > Hi, > I recently installed a fresh Fedora 31 in order to improve performance. I > have started to have a new problem. When

Fedora 31 Does Not Use Swap Well?

Hi, I recently installed a fresh Fedora 31 in order to improve performance. I have started to have a new problem. When my memory fills up when launching an Android emulator, the system starts acting very slowly and becomes quite unresponsive. I used to fill both memory and swap close to 100%

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Wed, Oct 24, 2018 at 08:45:32AM +0200, Igor Gnatenko wrote: > How can I enable cgroups2 on my laptop? Put systemd.unified-cgroup-hierarchy on the kernel command line. Zbyszek > On Fri, Oct 19, 2018, 17:27 Lennart Poettering wrote: > > > On Fr, 19.10.18 09:12, Florian Weimer

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

How can I enable cgroups2 on my laptop? On Fri, Oct 19, 2018, 17:27 Lennart Poettering wrote: > On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote: > > > >> (cross-posting to devel and desktop lists, ideally reply to both) > > > > > > Coincidentally, at All Systems Go! in Berlin

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mo, 22.10.18 11:58, Florian Weimer (fwei...@redhat.com) wrote: > Anyway, the problem suggests to me that the default soft limit should > not be raised until the kernel gets better recovery, so that > applications won't trigger the issue by accident. During the whole discussions we always made

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

* Lennart Poettering: > On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote: > >> >> (cross-posting to devel and desktop lists, ideally reply to both) >> > >> > Coincidentally, at All Systems Go! in Berlin last week I had some >> > discussions with kernel people about RLIMIT_NOFILE

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote: > >> (cross-posting to devel and desktop lists, ideally reply to both) > > > > Coincidentally, at All Systems Go! in Berlin last week I had some > > discussions with kernel people about RLIMIT_NOFILE defaults. They > > basically

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

* Lennart Poettering: > On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote: > >> (cross-posting to devel and desktop lists, ideally reply to both) > > Coincidentally, at All Systems Go! in Berlin last week I had some > discussions with kernel people about RLIMIT_NOFILE defaults. They >

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

* Kamil Paral: > From a technical point of view I'm not able to judge whether raising > the fileno limits by default is a trivial change or something with > important security implications. It has implications for reliability (and perhaps security). File descriptors can refer to sockets, and

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

er > > > distros as soon as we do the next release. > > > > > > https://github.com/systemd/systemd/pull/10244 > > > > Lennart, Zbyszek, would it be possible to backport the change also to F29's > > systemd (F28 as well would be ideal), so that Wine esync

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

com/systemd/systemd/pull/10244 > > Lennart, Zbyszek, would it be possible to backport the change also to F29's > systemd (F28 as well would be ideal), so that Wine esync/Steam Proton works > for people out of the box earlier than on F30? Quite frankly I'd wait a bit so that peo

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

rged the PR that bumps RLIMIT_NOFILE to 256K into systemd > upstream yesterday. It should trickle into Fedora and the other > distros as soon as we do the next release. > > https://github.com/systemd/systemd/pull/10244 Lennart, Zbyszek, would it be possible to backport the change also to

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mi, 17.10.18 20:35, Zebediah Figura (z.figur...@gmail.com) wrote: > I do not, no. That number came up pretty early in testing, and I think we > ended up leaving the limit at ~1M while testing other applications. On the > other hand, I know many users in the wild have used ~200k values, and I >

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 10/16/18 6:25 AM, Kamil Paral wrote: On Mon, Oct 15, 2018 at 7:34 PM Lennart Poettering > wrote: On Mo, 15.10.18 18:00, Kamil Paral (kpa...@redhat.com ) wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mon, Oct 15, 2018 at 7:34 PM Lennart Poettering wrote: > On Mo, 15.10.18 18:00, Kamil Paral (kpa...@redhat.com) wrote: > > > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering > > wrote: > > > > > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > > > > > It would be

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mo, 15.10.18 18:00, Kamil Paral (kpa...@redhat.com) wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering > wrote: > > > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > > > It would be nice if somebody managed to find where this is patched in > > > > Debian.

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mon, Oct 15, 2018 at 06:00:05PM +0200, Kamil Paral wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering > wrote: > > > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > > > It would be nice if somebody managed to find where this is patched in > > > > Debian.

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering wrote: > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > It would be nice if somebody managed to find where this is patched in > > > Debian. Because I somewhat doubt that they made this change without a > > > proper

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > It would be nice if somebody managed to find where this is patched in > > Debian. Because I somewhat doubt that they made this change without a > > proper discussion. And Debian is very much server oriented. > > Can we not have

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 10/9/18 0810 UTC, Daniel P. Berrangé wrote: AFAICT, the TCP receive buffer size is about 200 KB per socket. With the current nfile=4096, it looks like a single process can already consume 200 KB * 4096 = ~800 MB of RAM just by using TCP sockets. IOW, does the nfiles limit make a real world

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Tue, Oct 09, 2018 at 04:08:06PM +0200, Kamil Paral wrote: > On Tue, Oct 9, 2018 at 3:29 PM Michal Konečný wrote: > > > Because this is mainly for Steam Proton I support the decision to raise > > the limit only for Workstation. No need to do this on server edition. > > I recommend to also

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Tue, Oct 9, 2018 at 3:29 PM Michal Konečný wrote: > Because this is mainly for Steam Proton I support the decision to raise > the limit only for Workstation. No need to do this on server edition. > I recommend to also raise this limit for Silverblue edition, because this > is targeted on

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 9.10.2018 15:14, Jan Pokorný wrote: On 08/10/18 18:28 -0500, Zebediah Figura wrote: On 08/10/18 16:43, John Reiser wrote: On 10/8/18 2026 UTC, Zebediah Figura wrote: On 08/10/18 2000 UTC, John Reiser wrote: Allowing 1M open files per unprivileged process is too many. Megabytes of RAM

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 08/10/18 18:28 -0500, Zebediah Figura wrote: > On 08/10/18 16:43, John Reiser wrote: >> On 10/8/18 2026 UTC, Zebediah Figura wrote: >>> On 08/10/18 2000 UTC, John Reiser wrote: Allowing 1M open files per unprivileged process is too many. Megabytes of RAM are precious.  A hard

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mon, Oct 08, 2018 at 01:00:01PM -0700, John Reiser wrote: > Allowing 1M open files per unprivileged process is too many. > > Megabytes of RAM are precious. A hard limit of 1M open files per process > allows each process to eat at least 256MB (1M * sizeof(struct file) > [linux/fs.h]) of RAM.

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 08/10/18 16:43, John Reiser wrote: > On 10/8/18 2026 UTC, Zebediah Figura wrote: >> On 08/10/18 2000 UTC, John Reiser wrote: >>> Allowing 1M open files per unprivileged process is too many. >>> >>> Megabytes of RAM are precious.  A hard limit of 1M open files per >>> process >>> allows each

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 10/8/18 2026 UTC, Zebediah Figura wrote: On 08/10/18 2000 UTC, John Reiser wrote: Allowing 1M open files per unprivileged process is too many. Megabytes of RAM are precious.  A hard limit of 1M open files per process allows each process to eat at least 256MB (1M * sizeof(struct file)

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 08/10/18 15:00, John Reiser wrote: > Allowing 1M open files per unprivileged process is too many. > > Megabytes of RAM are precious.  A hard limit of 1M open files per process > allows each process to eat at least 256MB (1M * sizeof(struct file) > [linux/fs.h]) of RAM.  If a single user is

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

Allowing 1M open files per unprivileged process is too many. Megabytes of RAM are precious. A hard limit of 1M open files per process allows each process to eat at least 256MB (1M * sizeof(struct file) [linux/fs.h]) of RAM. If a single user is allowed 1000 processes, then that's 256GB of RAM,

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

Hi all, My thanks as well to Kamil for raising the question; it's been on my list of things to do for a while. The design of my patch set necessitates the allocation of one eventfd descriptor for each kernel handle (which is, sort of, the Windows equivalent of an fd) associated with a sync

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Mon, Oct 8, 2018 at 11:09 AM Michal Konečný wrote: > Maybe it will be also good to look at the SteamOS distribution and what > limits they are using. > According to the proton document [1], SteamOS also has an increased fileno hard limit. I haven't verified the actual value, but they

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

Maybe it will be also good to look at the SteamOS distribution and what limits they are using. On 8.10.2018 10:53, Kamil Paral wrote: On Fri, Oct 5, 2018 at 10:20 PM Lennart Poettering mailto:mzerq...@0pointer.de>> wrote: I have thus prepared this a few days ago:

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Fri, Oct 5, 2018 at 10:20 PM Lennart Poettering wrote: > I have thus prepared this a few days ago: > > https://github.com/systemd/systemd/pull/10244 This is great, thank you. So, any idea why they picked 1M? Are there typical apps that require > really that many? > I've emailed Zebediah

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 10/05/2018 11:03 AM, Lennart Poettering wrote: On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote: (cross-posting to devel and desktop lists, ideally reply to both) Coincidentally, at All Systems Go! in Berlin last week I had some discussions with kernel people about

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Fr, 05.10.18 12:28, Nicholas Miell (nmi...@gmail.com) wrote: > >> This is not quite the 1M you appear to ask for though… I picked 256K > >> mostly because I wanted to stay lower than the kernel built-in max > >> (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick > >> something. Do

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On 10/5/18 11:55 AM, Michael Cronenworth wrote: > First off, thanks, Kamil, for starting this discussion. I've been > meaning to bring it up. > > On 10/5/18 1:03 PM, Lennart Poettering wrote: > [snip] >> This is not quite the 1M you appear to ask for though… I picked 256K >> mostly because I

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

First off, thanks, Kamil, for starting this discussion. I've been meaning to bring it up. On 10/5/18 1:03 PM, Lennart Poettering wrote: [snip] This is not quite the 1M you appear to ask for though… I picked 256K mostly because I wanted to stay lower than the kernel built-in max (which is 1M,

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote: > (cross-posting to devel and desktop lists, ideally reply to both) Coincidentally, at All Systems Go! in Berlin last week I had some discussions with kernel people about RLIMIT_NOFILE defaults. They basically suggested that the

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

On Fri, Oct 5, 2018 at 11:31 AM, Kamil Paral wrote: > (cross-posting to devel and desktop lists, ideally reply to both) > Debian and Ubuntu: > I've installed both Debian (Sid) and Ubuntu (18.10) to verify this, and can > confirm it. The default soft limit stays the same (1024), but the hard

raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

systemd's system instance (systemd --system, PID 1), and not to systemd user instances (systemd --user). Most of the apps you start in your session are children of gnome-shell, which doesn't run under the systemd user instance, so the higher limits apply for them as well (including Steam). However

Re: RANT: Packaging is changing too fast and is not well documented

On Sat, 2018-02-10 at 18:07 +0100, Robert-André Mauchin wrote: > Before requesting a new dist-git repository for a new package, you need to > generate a pagure.io API token at https://pagure.io/settings/token/new, and  > save it > into your local user configuration located at

Re: RANT: Packaging is changing too fast and is not well documented

On Mon, Feb 12, 2018, at 7:37 PM, Kevin Fenzi wrote: > On 02/12/2018 10:14 AM, Ken Dreyer wrote: > > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw wrote: > >> Not coming from a programming background I found the learning curve pretty > >> steep when I first tried to become

Re: RANT: Packaging is changing too fast and is not well documented

On Mon, Feb 12, 2018 at 10:37:38AM -0800, Kevin Fenzi wrote: > On 02/12/2018 10:14 AM, Ken Dreyer wrote: > > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw wrote: > >> Not coming from a programming background I found the learning curve pretty > >> steep when I first tried to

Re: RANT: Packaging is changing too fast and is not well documented

On 02/12/2018 10:14 AM, Ken Dreyer wrote: > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw wrote: >> Not coming from a programming background I found the learning curve pretty >> steep when I first tried to become a packager, I'm not sure I wouldn't have >> given up if I had

Re: RANT: Packaging is changing too fast and is not well documented

On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw wrote: > Not coming from a programming background I found the learning curve pretty > steep when I first tried to become a packager, I'm not sure I wouldn't have > given up if I had to do it now. Thanks for speaking up about

Re: RANT: Packaging is changing too fast and is not well documented

On 02/11/2018 08:40 AM, Kevin Kofler wrote: Richard Shaw wrote: $ fedpkg request-branch Could not execute request_branch: The "token" value must be set under the "fedpkg.pagure" section in your "fedpkg" user configuration WTF?! So, instead of going to a web interface and making the change

Re: RANT: Packaging is changing too fast and is not well documented

Richard Shaw wrote: > $ fedpkg request-branch > Could not execute request_branch: The "token" value must be set under the > "fedpkg.pagure" section in your "fedpkg" user configuration WTF?! So, instead of going to a web interface and making the change (old, now discontinued, pkgdb), we now have

Re: RANT: Packaging is changing too fast and is not well documented

On Sat, Feb 10, 2018 at 11:07 AM, Robert-André Mauchin wrote: > > I wasn't even aware of this new use of fedpkg, but you could just have > looked > the help instead of searcghinq the source code: Always in the place you don't look... :) Thanks, Richard

Re: RANT: Packaging is changing too fast and is not well documented

On samedi 10 février 2018 14:48:04 CET Richard Shaw wrote: > > So I went to request a new branch of an existing package only to find out > fedrepo-req-branch, which hasn't been around that long is already > depreceated and the facility brought into fedpkg... so: > > $ fedpkg request-branch >

Re: RANT: Packaging is changing too fast and is not well documented

please see if helps [1] the meassage just have 5 days :) [1]https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproj ect.org/message/KS6QZQHNFCFEVJPJMFWITYWV3AHRSX5E/ On Sat, 2018-02-10 at 07:48 -0600, Richard Shaw wrote: > > So I went to request a new branch of an existing package

RANT: Packaging is changing too fast and is not well documented

So I went to request a new branch of an existing package only to find out fedrepo-req-branch, which hasn't been around that long is already depreceated and the facility brought into fedpkg... so: $ fedpkg request-branch Could not execute request_branch: The "token" value must be set under the

Re: Well, here's my first package

On 6 May 2017 at 23:10, wrote: > Link to package review > https://bugzilla.redhat.com/show_bug.cgi?id=1448661 > Any comments? Any suggestions on how to tell upstream as I'm not really > good at talking to people. > Since this is your first package you'll need to find a sponsor.

Re: Well, here's my first package

* po...@pouar.net [06/05/2017 17:10] : > > Any comments? Any suggestions on how to tell upstream as I'm not really > good at talking to people. This is the generic mail I send after a package has been approved. You'll need to replace the different FIXME placeholders with something that works for

Re: Well, here's my first package

On Sat, 6 May 2017 17:10:51 -0500 wrote: > Link to package review > https://bugzilla.redhat.com/show_bug.cgi?id=1448661 > Any comments? Any suggestions on how to tell upstream as I'm not really > good at talking to people. > On Sat, 06 May 2017 23:50:50 +0200 Kevin Kofler

Well, here's my first package

Link to package review https://bugzilla.redhat.com/show_bug.cgi?id=1448661 Any comments? Any suggestions on how to tell upstream as I'm not really good at talking to people. -- GPG Keys: https://keybase.io/pouar Tox ID: 2EA7A6D5494C10B2E0F32004A1E9CBD971777E551A902059E5EA7E73E5A299272F29D9FF5F6A

[Bug 1119521] decode fails with well formatted packet

https://bugzilla.redhat.com/show_bug.cgi?id=1119521 Paul Wouters changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 Ralf Corsepius changed: What|Removed |Added Status|ASSIGNED|CLOSED

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 --- Comment #6 from Jon Ciesla --- Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/perl-Data-Page-Pageset -- You are receiving this mail because: You are on the CC list for the bug. --

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 Denis Fateyev changed: What|Removed |Added Flags|fedora-review? |fedora-review+

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 --- Comment #4 from Upstream Release Monitoring --- dfateyev's scratch build of perl-Data-Page-Pageset-1.02-2.fc24.src.rpm for rawhide completed

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 --- Comment #3 from Ralf Corsepius --- Thanks, Denis Update: spec: https://corsepiu.fedorapeople.org/packages/perl-Data-Page-Pageset.spec srpm:

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 --- Comment #1 from Upstream Release Monitoring --- dfateyev's scratch build of perl-Data-Page-Pageset-1.02-1.fc24.src.rpm for rawhide completed

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 --- Comment #2 from Denis Fateyev --- Package Review == Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed = MUST items = Generic: [x]: Package is

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

https://bugzilla.redhat.com/show_bug.cgi?id=1305134 Denis Fateyev changed: What|Removed |Added CC|

[389-devel] Please review: [389 Project] #48339: Share nsslapd-threadnumber in the case nunc-stans is enabled, as well.

https://fedorahosted.org/389/ticket/48339 https://fedorahosted.org/389/attachment/ticket/48339/0001-Ticket-48339-Share-nsslapd-threadnumber-in-the-case-.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel

[Bug 1119521] decode fails with well formatted packet

https://bugzilla.redhat.com/show_bug.cgi?id=1119521 Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com changed: What|Removed |Added Assignee|psab...@redhat.com

psabata pushed to perl-Net-DNS-SEC (master). D'oh, drop the explicit runtime dependencies as well

From 21f5d4ab72ebd899382ed607672711bf3d707fd2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com Date: Fri, 7 Aug 2015 18:34:39 +0200 Subject: D'oh, drop the explicit runtime dependencies as well diff --git a/perl-Net-DNS-SEC.spec b/perl-Net-DNS-SEC.spec index

[perl-Nagios-Plugin-WWW-Mechanize/epel7: 5/5] Unconditionally BR Time::HiRes since EL7 needs this as well as EL6

commit 4dd6e2b8046658020a86c0debf6965eed873e7b6 Author: Ken Dreyer ktdre...@ktdreyer.com Date: Sat Nov 8 19:45:58 2014 -0700 Unconditionally BR Time::HiRes since EL7 needs this as well as EL6 perl-Nagios-Plugin-WWW-Mechanize.spec |7 +-- 1 files changed, 5 insertions(+), 2

[perl-Nagios-Plugin-WWW-Mechanize] Unconditionally BR Time::HiRes since EL7 needs this as well as EL6

Summary of changes: 4dd6e2b... Unconditionally BR Time::HiRes since EL7 needs this as well (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel

[perl-Nagios-Plugin-WWW-Mechanize/epel7] (5 commits) ...Unconditionally BR Time::HiRes since EL7 needs this as well as EL6

needs this as well (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1119521] decode fails with well formatted packet

https://bugzilla.redhat.com/show_bug.cgi?id=1119521 Bug 1119521 depends on bug 1118651, which changed state. Bug 1118651 Summary: perl-Net-DNS-0.78 is available https://bugzilla.redhat.com/show_bug.cgi?id=1118651 What|Removed |Added

[Bug 1119521] New: decode fails with well formatted packet

https://bugzilla.redhat.com/show_bug.cgi?id=1119521 Bug ID: 1119521 Summary: decode fails with well formatted packet Product: Fedora Version: rawhide Component: perl-Net-DNS Severity: medium Assignee: psab...@redhat.com

[Bug 1119521] decode fails with well formatted packet

https://bugzilla.redhat.com/show_bug.cgi?id=1119521 jared mauch ja...@puck.nether.net changed: What|Removed |Added Depends On||1118651

[perl-Net-Twitter] Update to 4.00004. Upstream changed to Module::Build instead of MakeMaker as well.

commit 9855a4cd118b6613adcda18a01f4490b3659c9eb Author: Julian C. Dunn jd...@aquezada.com Date: Thu Mar 14 11:24:23 2013 -0400 Update to 4.4. Upstream changed to Module::Build instead of MakeMaker as well. .gitignore|1 + perl-Net-Twitter.spec | 22

[perl-Net-Twitter/f19] Update to 4.00004. Upstream changed to Module::Build instead of MakeMaker as well.

Summary of changes: 9855a4c... Update to 4.4. Upstream changed to Module::Build instea (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list

Re: well!

On 03/12/2013 08:17 PM, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity.

Re: well!

, installed F18 to a VM, and then used rsync + restorecon + grub2-mkconfig (!) to get it into the partition I wanted. That was my experience as well. LVMs though instead of partitions. I solved it by deleting the LVM I wanted to replace and letting Anaconda create a new LVM using the space from the old

Re: well!

On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the

Re: well!

On Tue, 2013-03-12 at 20:17 +0100, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a

Re: well!

Btw.: Ideas how to install F18 anyhow are welcome. I have had some success using gparted LiveCD or LiveUSB (http://gparted.org/) to construct the partition layout including file system labels, then using anaconda (DVD) to take over and re-format the then-existing partitions. I use the labels to

Re: well!

On 03/12/2013 02:17 PM, Till Maas wrote: Btw.: Ideas how to install F18 anyhow are welcome. Use F17 and then fedup to F18 if F18's anaconda will not work for you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

  1   2   >