devel January 2018

devel@lists.fedoraproject.org

239 participants
308 discussions

net-snmp, cmake, mc unresponsive packagers
by Tomasz Kłoczko 30 Jan '18

30 Jan '18

https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers net-snmp https://bugzilla.redhat.com/show_bug.cgi?id=1529716 https://src.fedoraproject.org/rpms/net-snmp/pull-request/2 cmake: https://src.fedoraproject.org/rpms/cmake/pull-request/2 https://bugzilla.redhat.com/show_bug.cgi?id=1530574 mc https://bugzilla.redhat.com/show_bug.cgi?id=1536909 https://src.fedoraproject.org/rpms/mc/pull-request/1 In case of mc there is no contact with maintainer since my last mc updates (May 2017) kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*

2 2

FYI: Fedora/RISC-V third and final bootstrap
by Richard W.M. Jones 30 Jan '18

30 Jan '18

About a month ago I posted about the state of the RISC-V architecture for Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Quoting from that email: | First the basics: RISC-V is a free and open Instruction Set | Architecture (ISA). You can read more about it on the RISC-V | Foundation's website here: | | https://riscv.org/ | | Fedora/RISC-V is a project to port Fedora to RISC-V. Actual, real | 64-bit RISC-V hardware you can buy is going to be released in Q1 2018 | (it's already sampling to a few lucky developers), and I want Fedora | to be the first choice to run on that hardware. | | The Fedora/RISC-V project web pages are here: | | https://fedoraproject.org/wiki/Architectures/RISC-V As noted in the earlier email the project was on a hiatus since the end of 2016, waiting for the RISC-V Foundation to commit to a stable Linux libc ABI for the architecture. Well, finally that has happened. glibc 2.27, due to be released on Thursday, will contain a stable RISC-V ABI allowing us to sanely develop a Linux distro. And thus the Fedora/RISC-V project is back in business. Next week we'll be starting the third (and final) bootstrap. You can follow the work at these links: https://github.com/rwmjones/fedora-riscv-bootstrap https://fedoraproject.org/wiki/Architectures/RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V/Bootstrapping The approximate timelines (don't hold me to any of this) are: * mid-February: Stage 3 disk image. * end-March: Pristine, pure RPM-built stage 4 disk image, autobuilder picking up Fedora packages and building them. * Summer: Shadow-Koji instance, Fedora 28/Rawhide RPM hosting. You can already try out the interim (and very minimal and hacky) bbl-bootloader/kernel/stage 3 disk image: http://oirase.annexia.org/riscv/ Install the riscv-qemu package from: https://copr.fedorainfracloud.org/coprs/rjones/riscv/ and then run: qemu-system-riscv64 \ -nographic \ -machine virt \ -m 2G \ -kernel bbl \ -append "console=ttyS0 ro root=/dev/vda init=/init" \ -device virtio-blk-device,drive=hd0 \ -drive file=stage3-disk.img,format=raw,id=hd0 \ -device virtio-net-device,netdev=usernet \ -netdev user,id=usernet I'll be at FOSDEM on Saturday if anyone is interested in Fedora and RISC-V. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

1 0

Re: net-snmp, cmake, mc unresponsive packagers
by Tomasz Kłoczko 30 Jan '18

30 Jan '18

On 30 January 2018 at 21:37, Jindrich Novy <novyjindrich(a)gmail.com> wrote: > Hi Tomasz, > > I haven't done much on mc front recently but I'm pretty responsive. Have > you tried to get in touch with me at all? > You are not reacting on bugzuilla tickets and now on pull requests. Why? Prev tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1436394 https://bugzilla.redhat.com/show_bug.cgi?id=1442842 This is always should be base channel of communication. By this probably you didn't even notice that mc.spec looks now completely different than it was year ago. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*

1 0

GCC broken in rawhide?
by Ralf Corsepius 30 Jan '18

30 Jan '18

Hi, ATM all rawhide builds are failing for me, because autoconf's tests for CC are failing. Digging into details led me to this error: ... cc1: error: fail to initialize plugin /usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so annobin: conftest.c: Error: plugin built for compiler version (7.3.1) but run with compiler version (7.2.1) ... AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin wasn't rebuilt, resulting into rawhide now carrying an inconsistent GCC-toolchain. Ralf

15 28

Re: Fedora27: NFS v4 terrible write performance, is async working
by Petr Pisar 30 Jan '18

30 Jan '18

On Tue, Jan 30, 2018 at 08:31:05AM +0100, Reindl Harald wrote: > Am 30.01.2018 um 08:25 schrieb Petr Pisar: > > On 2018-01-29, J. Bruce Fields <bfields(a)redhat.com> wrote: > > > The file create isn't allowed to return until the server has created the > > > file and the change has actually reached disk. > > > > > Why is there such a requirement? This is not true for local file > > systems. This is why fsync() exists > > pretty simply because on the NFS server side the whole VFS layer sits again > and without "async" in the export you need a way to rely on "the stuff i > wrote to the network ended on the filesystem on the other end" If I need reliability, I issue fsync from the client process, client VFS passes it to the NFS client, NFS client translates it into NFS COMMIT message, sends it to the NFS server, NFS server translates it back to fsync, pass it to the server VFS and from there to the local file system driver. I don't understand why NFS should be reliable by default. -- Petr

2 1

Re: Fedora27: NFS v4 terrible write performance, is async working
by J. Bruce Fields 30 Jan '18

30 Jan '18

On Tue, Jan 30, 2018 at 10:00:44AM +0100, Reindl Harald wrote: > Am 30.01.2018 um 09:49 schrieb Terry Barnaby: > > Untar on server to its local disk: 13 seconds, effective data rate: 68 > > MBytes/s > > > > Untar on server over NFSv4.2 with async on server: 3 minutes, effective > > data rate: 4.9 MBytes/sec > > > > Untar on server over NFSv4.2 without async on server: 2 hours 12 > > minutes, effective data rate: 115 kBytes/s !! > > > > Is it really expected for NFS to be this bad these days with a > > reasonably typical operation and are there no other tuning parameters > > that can help ? > > no, we are running a virtual backup appliance (VMware Data Protection aka > EMC Avamar) on vSphere 5.5 on a HP microserver running CentOS7 with a RAID10 > built of 4x4 TB consumer desktop disks and the limiting factor currently is > the Gigabit Ethernet > > 35 TB network IO per month, around 1 TB per day which happens between 1:00 > AM and 2:00 AM as well as garbage collection between 07:AM and 08:00 AM Again, this is highly dependent on the workload. Your backup appliance is probably mainly doing large sequential writes to a small number of big files, and we aim for that sort of workload to be limited only by available bandwidth, which is what you're seeing. If you have a single-threaded process creating lots of small files, you'll be limited by disk write latency long before you hit any bandwidth limits. --b.

1 0

Change Checkpoint: Proposal submission deadline (Self contained Changes) on Fedora 28 is today
by Jan Kurik 30 Jan '18

30 Jan '18

Hi everyone! Today is the submission deadline for Self contained Changes of Fedora 28 [1]. Please schedule your upcoming Changes (Self contained as well as System wide) for the next (Fedora 29) release. Branch of Fedora 28 from Rawhide is then planned on 2018-Fed-20. [1] https://fedoraproject.org/wiki/Releases/28/Schedule Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

[Fedocal] Reminder meeting : Modularity Office Hours
by nils＠redhat.com 29 Jan '18

29 Jan '18

Dear all, You are kindly invited to the meeting: Modularity Office Hours on 2018-01-30 from 10:00:00 to 11:00:00 US/Eastern At https://meet.jit.si/fedora-modularity The meeting will be about: This is where you ask the Fedora Modularity Team questions (and we try to answer them)! Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): #fedora-modularity on [FreeNode](https://freenode.net) Source: https://apps.fedoraproject.org/calendar/meeting/8711/

1 0

[Fedocal] Reminder meeting : Modularity Office Hours
by nils＠redhat.com 29 Jan '18

29 Jan '18

Dear all, You are kindly invited to the meeting: Modularity Office Hours on 2018-01-30 from 10:00:00 to 11:00:00 US/Eastern At fedora-modularity(a)chat.freenode.net The meeting will be about: This is where you ask the Fedora Modularity Team questions (and we try to answer them)! Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): #fedora-modularity on [FreeNode](https://freenode.net) Source: https://apps.fedoraproject.org/calendar/meeting/5910/

1 0

wish to resurrect shorewall on EPEL 6 (and re-self-introduction)
by J. Randall Owens 29 Jan '18

29 Jan '18

As I previously wrote (v.i.), I'd like to un-retire shorewall for EPEL 6. It seems as though the only reason for its retirement is that the previous maintainer hadn't updated it in four years, presumably having lost interest in it. I've had shorewall-4.5.4 & -4.4.17 building in my personal repo for a while now, and in use on my servers, so it doesn't seem there's any build problem that precludes it from (EP)EL6. If there's no objection, I'll file the releng ticket. If there's a simple shortcut in git for reverting the dead.package file to the shorewall.spec etc., I'd appreciate knowing it; otherwise, I'll muddle through the git checkout/push somehow, I suppose. And since it's been a long time since I introduced myself, without my contributing much since then, it can serve as a bit of a re-introduction, as well. -------- Forwarded Message -------- To: Michele Baldessari <michele [AT] acksyn [DOT] org> From: J. Randall Owens <jrowens.fedora(a)ghiapet.net> Subject: wish to resurrect shorewall on EPEL 6 Date: Sat, 15 Jul 2017 01:26:46 +0100 Hello. I've been a mostly-quiet Fedora user and occasional minor contributor for a fair while now, certainly over a decade (and RHL before that), and I love my shorewall, and I have a few CentOS 6 servers to tend to. Some of these being new to me, I found that they already had shorewall & shorewall-core on them, so I went to add shorewall6 to the mix, and after some puzzled moments, realised that it was all gone from the EPEL repository. So, I'd like to bring it back for EPEL 6, and figured I should run it past you first, see if there was a particular reason for retiring it, or if it was just that you didn't have the interest in 6 in particular. I've already been in the Fedora CLA, Git Commit, etc. groups for a while now [1], after I had some plans for packages that never materialised. Most recently, I took on gogoc (also networking- & IPv6-related) in a hurry before it would be automatically retired, only to discover that the tunnel service it was intended to connect to was going defunct, so not much point to keeping it afloat. A couple of other packages, though, I had good intentions for, but just never got the hang of how to go through the right combination of bodhi, koji, pkgdb, pungi, plague, copr, or whatever else for Fedora/EPEL. So if you're willing to let me take on EPEL 6, and walk me through a build or two so I can see how it's done (and take notes), that would be wonderful. I've had my own repository of a handful of packages since Fedora 9 [2], basically just for my own use, so I know the packaging side of things pretty well, and using mock. And I know a bit of git, somewhat narrowly, but reasonably well. Using branches is a weak area for me; I haven't done that much yet, and as I understand it, I think that might be important for this, although I guess there's just a branch per Fedora/EPEL release, and there isn't further branching after that, right? I seem to see that there were tags per version up through 4.4.10, and then they stopped, and I don't know if that was due to a policy change, or just personal preference of a (possibly new) maintainer. Anyway, if you're willing, we can sort that out later. If we can do this, I expect we should keep it at 4.x, and not make the jump to 5.x, this being EPEL. Any opinion on whether 4.6.y would be reasonable? Looks like the last one was 4.5.4, so could go either 4.5.21 or 4.6.13, if playing it safe. If you don't have an opinion yet, I can look into the 4.6 changes and see whether it's likely to negatively affect existing installations. Thank you for your time, and for keeping the Fedora and EPEL 7 branches of shorewall alive (which I also use, on the home machines). [1] https://admin.fedoraproject.org/accounts/user/view/jrowens [2] http://download.ghiapet.net/pub/ghiapet/linux/ -- J. Randall Owens | http://www.GhiaPet.net/

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2018