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

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. Please

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 for

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 20.08

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 th

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

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

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

> You've more or less hit 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 pi

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?

catch here is that under heavy load, 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

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 unr

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 impr

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 my

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% withou

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 (fwei...@redhat.

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 la

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 de

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 sug

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 > b

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 eac

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

> > > 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

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 s

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

> > We merged 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

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 mailto:m

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 nice

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. Beca

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. Becaus

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 discus

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 raise

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 commo

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 ar

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 lim

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. I

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 proc

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) [linux/

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 allo

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, w

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

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 probably

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: https://github.com/s

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 Fi

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 RLIMIT_NOFIL

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 you

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 wante

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, i.

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 memory

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 limit

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

ies to the 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 (inclu

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 ~/.config/rpkg/fedpkg.

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 a packager, I'm not su

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 become a packager, I'm

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 to do it now. > > Than

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 this. I'm having trouble f

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 (ol

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 > Cou

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 o

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 "f

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. https://fedorapr

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 y

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 wrote: > po...@pouar

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 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||perl-devel@lists.fedoraproj

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

commit 9855a4cd118b6613adcda18a01f4490b3659c9eb Author: Julian C. Dunn 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 ++ sources

Re: well!

em. Eventually I gave up, 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 usi

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

Re: well!

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. Why would partitioning be an issue when you upgrade? Just do a real upgrade (using either FedUp or yum directly), not a

Re: well!

Am 12.03.2013 20:17, schrieb Till Maas: > 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 retur

Re: well!

On Tue, Mar 12, 2013 at 12: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 f

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

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 t

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 si

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

Re: well!

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 drama, you can manually partition F18. -- Digimer Papers and Pr

well!

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 -- Do what thou wilt shall be the whole of the Law. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapro

Re: Making PGP distribution key well-known

On 2012-03-05, Kevin Fenzi wrote: > > Would you be willing to file a websites ticket on this?=20 Done: -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making PGP distribution key well-known

ch nobody reads. To far. Would you be willing to file a websites ticket on this? I could as well, but if you file it, you'll have more input in how it's implemented. ;) https://fedorahosted.org/fedora-websites/newticket kevin signature.asc Description: PGP signature

Re: Making PGP distribution key well-known

On 05/03/12 10:37, Petr Pisar wrote: Even bellow export regulations which nobody reads. I do. -- Regards, Frank "Jack of all, fubars" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making PGP distribution key well-known

On 2012-03-02, Kevin Fenzi wrote: > On Fri, 2 Mar 2012 12:53:35 + (UTC) > Petr Pisar wrote: > >> On 2012-03-01, Michal Schmidt wrote: >> > Dne 1.3.2012 17:52, Petr Pisar napsal(a): >> >> where to get public key for verifying RPM signatures. >> > >> > The keys are at: https://fedoraproject.or

Re: Making PGP distribution key well-known

On Fri, 2 Mar 2012 12:53:35 + (UTC) Petr Pisar wrote: > On 2012-03-01, Michal Schmidt wrote: > > Dne 1.3.2012 17:52, Petr Pisar napsal(a): > >> where to get public key for verifying RPM signatures. > > > > The keys are at: https://fedoraproject.org/keys > > > And F16 primary key (A82BA4B7) i

Re: Making PGP distribution key well-known

On 2012-03-01, Michal Schmidt wrote: > Dne 1.3.2012 17:52, Petr Pisar napsal(a): >> where to get public key for verifying RPM signatures. > > The keys are at: https://fedoraproject.org/keys > And F16 primary key (A82BA4B7) is signed by... 1 guy. Awesome. And ISO images propagated on Fedora web pa

Re: Making PGP distribution key well-known

On 03/01/2012 06:52 PM, Petr Pisar wrote: As new Fedora release looms ahead, I'd like open discussion about verifying distribution integrity. In short---where to get public key for verifying RPM signatures. If I remember correctly, you are asked to accept new signing key by rpm while installing

Re: Making PGP distribution key well-known

Dne 1.3.2012 17:52, Petr Pisar napsal(a): where to get public key for verifying RPM signatures. The keys are at: https://fedoraproject.org/keys Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Making PGP distribution key well-known

er to newer Fedora release making upgrade more secured. Of course other good approach is to sign F17 public key by well-known Fedora developers and publish the key with its singatures, e.g. on PGP key servers. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraprojec

Re: irqbalance doesn't balance well x86_64 Fedora 16

On Sat, Oct 29, 2011 at 10:24:34PM +0200, Reindl Harald wrote: > > > Am 29.10.2011 22:04, schrieb Lucas: > > I do not understand why it places i915, eth0 and snd_hda_intel on the same > > CPU > > uname -a = 3.1.0-1.fc16.x86_64 #1 SMP Mon Oct 24 12:18:13 UTC 2011 x86_64 > > x86_64 x86_64 GNU/Lin

Re: irqbalance doesn't balance well x86_64 Fedora 16

Am 29.10.2011 22:04, schrieb Lucas: > I do not understand why it places i915, eth0 and snd_hda_intel on the same CPU > uname -a = 3.1.0-1.fc16.x86_64 #1 SMP Mon Oct 24 12:18:13 UTC 2011 x86_64 > x86_64 x86_64 GNU/Linux > > Any thoughts? because it is useless to speard on all present cores with

irqbalance doesn't balance well x86_64 Fedora 16

Dear All I would like to tell that irqbalance doesn't balance irqs properly: 0:126 0 0 0 IO-APIC-edge timer 1: 2 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 IO-APIC-edge

Re: TFTP not working on F15 as well as updated F14

On 10/12/2011 06:37 PM, Aaron Gray wrote: > sudo /usr/sbin/in.tftpd -L -v -v -v -s /var/lib/tftpboot > > > Wow, TFTP works like this ! > > Thanks for that, now why does it not work under xinetd ? I have no idea. xinetd should be spawning off the equivalent of: /usr/sbin/in.tftpd -s /var/li

Re: TFTP not working on F15 as well as updated F14

On 12 October 2011 19:30, Tom Callaway wrote: > Okay. Your configurations are the default configs (with the notable > exception of enabling the xinetd.d/tftp service). > > On my x86_64 laptop running Fedora 16, with iptables reasonably normal, > I installed "tftp" and "tftp-server", and changed "

Re: TFTP not working on F15 as well as updated F14

Okay. Your configurations are the default configs (with the notable exception of enabling the xinetd.d/tftp service). On my x86_64 laptop running Fedora 16, with iptables reasonably normal, I installed "tftp" and "tftp-server", and changed "disable = yes" to "disable = no" in /etc/xinetd.d/tftp. T

Re: TFTP not working on F15 as well as updated F14

On 12 October 2011 14:57, Aaron Gray wrote: > On 11 October 2011 18:49, Tom Callaway wrote: > >> On 10/11/2011 01:46 PM, Aaron Gray wrote: >> > I have two F15 machines one a desktop which is running the new Gnome 3 >> > desktop and a laptop not running the new desktop. >> > >> > TFTP is not work

Re: TFTP not working on F15 as well as updated F14

On 11 October 2011 18:49, Tom Callaway wrote: > On 10/11/2011 01:46 PM, Aaron Gray wrote: > > I have two F15 machines one a desktop which is running the new Gnome 3 > > desktop and a laptop not running the new desktop. > > > > TFTP is not working on the desktop machine on F15 as it was not workin

Re: TFTP not working on F15 as well as updated F14

On 12 October 2011 04:22, Nick Jones wrote: > On Tue, 2011-10-11 at 21:22 +0100, Aaron Gray wrote: > > On 11 October 2011 18:49, Tom Callaway wrote: > > On 10/11/2011 01:46 PM, Aaron Gray wrote: > > > I have two F15 machines one a desktop which is running the > > new Gnom

Re: TFTP not working on F15 as well as updated F14

On Tue, 2011-10-11 at 21:22 +0100, Aaron Gray wrote: > On 11 October 2011 18:49, Tom Callaway wrote: > On 10/11/2011 01:46 PM, Aaron Gray wrote: > > I have two F15 machines one a desktop which is running the > new Gnome 3 > > desktop and a laptop not running the ne

Re: TFTP not working on F15 as well as updated F14

On 11 October 2011 18:49, Tom Callaway wrote: > On 10/11/2011 01:46 PM, Aaron Gray wrote: > > I have two F15 machines one a desktop which is running the new Gnome 3 > > desktop and a laptop not running the new desktop. > > > > TFTP is not working on the desktop machine on F15 as it was not workin

  1   2   >