Orphaning scram
by Olzhas Rakhimov
Hi,
I orphaned scram.
My hard drive w/ Fedora died a while ago.
Lost all my packaging setup and never caught up w/ the new packaging changes :(
There's an open "upgrade-request" [bug 1544524] that I cannot fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1544524
I'm an upstream developer
and willing to help out anyone wishing to adopt this package.
Thanks,
Olzhas
6 years, 4 months
Self-introduction: Kaushal
by Kaushal M
Hi all,
I've just been accepted into the packagers group, so that I can submit
and maintain a few packages. For anyone wondering why though, here's a
small introduction about me.
I'm Kaushal. I'm a developer who works out of Mysuru, India. I'm one
of the maintainers of the GlusterFS project [1], where I maintain the
distributed management framework, Glusterd.
We in the Gluster project, are developing a new version of the
management framework, called GlusterD2 (GD2) [2], which is scheduled
for release with the upcoming Gluster-4.0 release.
GD2 is a Golang application and is developed in a seperate tree from
GlusterFS. This is where me becoming a packager comes in.
I will be maintaining the glusterd2 Fedora package, and its required
dependencies. The main GD2 package [3] is still under-review. At the
moment I'm working on getting its dependencies update or added to the
packages. I know this is not an easy task, but I hope I can depend on
your assistance when needed.
I hope I enjoy my stay here.
Thanks!
~kaushal
[1]: https://www.gluster.org
[2]: https://github.com/gluster/glusterd2
[3]: https://bugzilla.redhat.com/1540553
6 years, 4 months
Re: Schedule for Friday's FESCo Meeting (2018-02-16)
by Randy Barlow
On 02/14/2018 10:06 PM, Devrim Gündüz wrote:
> On Wed, 2018-02-14 at 17:36 -0500, Randy Barlow wrote:
>> #topic #1842 Nonresponsive maintainer: devrim
>> .fesco 1842
>> https://pagure.io/fesco/issue/1842
> I thought other folks was already taking care of this package -- and to be
> honest, I was not even aware that pkgdb was obsoleted, so I am not sure how to
> pass the ownership of the package.
>
> Anyway, I'm fine with giving the ownership to MarkusN, he is maintaining the
> upstream as well.
Hi Devrim,
You can give the package to MarkusN by visiting:
https://src.fedoraproject.org/rpms/grass
Click on Settings in the upper right and you will see a section called
"Users and Groups". You can use this to grant ACLs to other developers.
If you want to give the package away, you can scroll a little further to
the "Give Project" section.
6 years, 4 months
Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async
working
by Steve Dickson
On 01/29/2018 12:42 PM, Steven Whitehouse wrote:
>
>
>
> -------- Forwarded Message --------
> Subject: Re: Fedora27: NFS v4 terrible write performance, is async working
> Date: Sun, 28 Jan 2018 21:17:02 +0000
> From: Terry Barnaby <terry1(a)beam.ltd.uk>
> To: Steven Whitehouse <swhiteho(a)redhat.com>, Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, Terry Barnaby <terry1(a)beam.ltd.uk>
> CC: Steve Dickson <steved(a)redhat.com>, Benjamin Coddington <bcodding(a)redhat.com>
>
>
>
> On 28/01/18 14:38, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 28/01/18 07:48, Terry Barnaby wrote:
>>> When doing a tar -xzf ... of a big source tar on an NFSv4 file system
>>> the time taken is huge. I am seeing an overall data rate of about 1
>>> MByte per second across the network interface. If I copy a single
>>> large file I see a network data rate of about 110 MBytes/sec which is
>>> about the limit of the Gigabit Ethernet interface I am using.
>>>
>>> Now, in the past I have used the NFS "async" mount option to help
>>> with write speed (lots of small files in the case of an untar of a
>>> set of source files).
>>>
>>> However, this does not seem to speed this up in Fedora27 and also I
>>> don't see the "async" option listed when I run the "mount" command.
>>> When I use the "sync" option it does show up in the "mount" list.
>>>
>>> The question is, is the "async" option actually working with NFS v4
>>> in Fedora27 ?
No. Its something left over from v3 that allowed servers to be unsafe.
With v4, the protocol defines stableness of the writes.
>>> _______________________________________________
>>
>> What server is in use? Is that Linux too? Also, is this v4.0 or v4.1?
>> I've copied in some of the NFS team who should be able to assist,
>>
>> Steve.
>
> Thanks for the reply.
>
> Server is a Fedora27 as well. vers=4.2 the default. Same issue at other
> sites with Fedora27.
>
> Server export: "/data *.kingnet(rw,async,fsid=17)"
>
> Client fstab: "king.kingnet:/data /data nfs async,nocto 0 0"
>
> Client mount: "king.kingnet:/data on /data type nfs4
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,nocto,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.202.2,local_lock=none,addr=192.168.202.1)"
>
>
This looks normal except for setting fsid=17...
The best way to debug this is to open up a bugzilla report
and attached a (compressed) wireshark network trace to see
what is happening on the wire... The entire tar is not needed
just a good chunk...
steved.
6 years, 4 months
libevent-2.1.8 SONAME change.
by Steve Dickson
Hello,
Yesterday I updated libevent to the latest upstream release.
I mistakenly did not realized there was a SONAME change
in this update. So if your package is dependent on
libevent, you are going to have to rebuild.
My apologies for this oversight...
steved.
6 years, 4 months
Re: Usefulness of `copr mock-config <PROJECT> <CHROOT>` feature?
by Pavel Raiskup
Sorry, I wanted to CC fedora devel before, forwarding.
Pavel
On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> Because we are unable to find a consensus on implementation details, it's
> likely we'll drop this feature from copr API and it will be probably a bit
> more complicated to setup mock chroot for local tests in future (you'll
> need to have builder machine with copr-rpmbuild installed, which brings a
> lot more runtime dependencies at least).
>
> From user perspective, do you mind if we dropped `copr mock-config` command?
>
> Pavel
6 years, 4 months
Granularity in disable mangling shebangs
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Since redhat-rpm-config-97-1.fc28 you can use 2 new variables:
* `__brp_mangle_shebangs_exclude_from` to exclude specific paths from mangling.
* `__brp_mangle_shebangs_exclude` to exclude specific shebangs from mangling.
Those are using same syntax as Requires/Provides filtering (REGEX_EXTENDED), so
you can use AutoProvidesAndRequiresFiltering guidelines[0] as reference for
syntax. I have opened FPC ticket to mention this in guidelines[1].
Big thanks goes to Miro Hrončok for implementing this!
[0] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
[1] https://pagure.io/packaging-committee/issue/750
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFPXwACgkQaVcUvRu8
X0y8SA//dtvyU2BWbmvWix4fHm9KpHWp3ACpROdJpip+cJTW/7u6gP3q0GGED8cU
p7nlBArzg0DwLmi9pDmTum9Q7KanvgqFDnjUmxZw9H4Sz8D6xZMdokmVv0Q1mF5O
9sKmj+xpOqbn/CG/ywA7Y39JiNbGS+Fk+6eBSLLAbYGDKSGbzg5QAdFdgbiHVTD/
C832xUhlF3pP+L4LgYi11zjyWgTPdOSgL6/mK9dS/GDLU7nXx45Cp84hpnNfcJrr
tTtW2CP5Jnwtf7lH5hHIhyL51KEKPbfr/pm61EAO5LnS0Ufq9/a2bOvKJkcBpk7d
uhcpSvVi46a4DLybH2cNqVw8dmItzMOlWAS9GiR45x5x2eD2ptGtx854wHTZGBL9
4UQr6AF/NCZ0tizB003sWXmi6PDw1C8HZRR4PTxEua+RFofIYFSpk+887NHExwHX
EZEa32tQsOjH6/02J2pyyzvHRjZCnk7b0OWIq7doefUkYv4R50D0j9nrH6fSj4r9
CkW7rIijJTA/wW6hgYbbF2JsyDDdhI8BeUCcsogwvgF50a8Zc0qMwXiImXIwYrT2
TzlZ18TdMGutOGAtcJgMeKB7d4oh9ctAgH0t7q4DMsGVBW8A/+6dYVus7PJDkFfx
Coeb/eH3cqQcLbvOxvICRBI2gCEIBvY3HmdBnVm5ISzWR7tRIiE=
=Tn9w
-----END PGP SIGNATURE-----
6 years, 4 months
