Change Checkpoint: Proposal submission deadline (Self contained Changes) on Fedora 28 is today

[Jan Kurik]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Petr Pisar]

On 2018-01-29, J. Bruce Fields  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.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Removal of systemd-units

[Akira TAGOH]

2018-01-26 3:17 GMT+09:00 Jason L Tibbitts III :
>> "IG" == Igor Gnatenko  writes:
> ebnetd   tagoh

fixed.

-- 
Akira TAGOH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] 389-ds please review: alpha CLI tools

[William Brown]

Hello!

(resent with fixed link for certain browsers)

Today is an exciting day where I get to ask everyone for their feedback
on our new command line tools. The design document related to "why" is
found here:

http://www.port389.org/docs/389ds/design/dsadm-dsconf.html

These are very new, and have been tested by the team and some others
for some time. This is a departure from our classic perl scripts into a
well integrated set of complete cli management tools for 389 Directory
Server.

All tools are written in python, and I would really appreciate feedback
on these and their ease of use. They are not 100% able to manage the
server yet (many plugins are still missing) however, the core framework
is in place, and many common tasks are possible.

These can be used on el7/f27 by enabling the copr repo:

https://copr.fedorainfracloud.org/coprs/firstyear/ds/

For f27 this is:

dnf copr enable firstyear/ds
dnf install 389-ds-base


Then you can follow the steps here:

http://www.port389.org/docs/389ds/design/dsadm-dsconf.html#example-usag
e

As well, exploration of the tools would be great (they have extensive
help guides with --help). If you find there are tasks you *want* to be
able to achieve, let me know of these also. 


Thank you and looking forward to your feedback.

---
WARNING: This package is a pre-release version of 389 Directory Server,
and should not be used for production, only for the purposes of testing
and evaluation. 
---

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] 389-ds please review: alpha CLI tools

[William Brown]

Hello!

Today is an exciting day where I get to ask everyone for their feedback
on our new command line tools. The design document related to "why" is
found here:

http://port389.org/docs/389ds/design/dsadm-dsconf.html

These are very new, and have been tested by the team and some others
for some time. This is a departure from our classic perl scripts into a
well integrated set of complete cli management tools for 389 Directory
Server.

All tools are written in python, and I would really appreciate feedback
on these and their ease of use. They are not 100% able to manage the
server yet (many plugins are still missing) however, the core framework
is in place, and many common tasks are possible.

These can be used on el7/f27 by enabling the copr repo:

https://copr.fedorainfracloud.org/coprs/firstyear/ds/

For f27 this is:

dnf copr enable firstyear/ds
dnf install 389-ds-base


Then you can follow the steps here:

http://port389.org/docs/389ds/design/dsadm-dsconf.html#example-usage

As well, exploration of the tools would be great (they have extensive
help guides with --help). If you find there are tasks you *want* to be
able to achieve, let me know of these also. 


Thank you and looking forward to your feedback.

---
WARNING: This package is a pre-release version of 389 Directory Server,
and should not be used for production, only for the purposes of testing
and evaluation. 
---

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Tomasz Kłoczko]

On 30 January 2018 at 02:11, Tim Landscheidt  wrote:
[..]

> Unfortunately, progress in Fedora and similar projects is
> not made by telling people what they are doing wrong, but by
> doing The Right Thing™ yourself or in collaboration with
> others.  And even if one is reporting a fault, there are
> ways to enable someone to fix that fault and there ways to
> overwhelm them with superfluous information that makes their
> work harder.


> For example, take the first line of your text I quoted
> above.  I can tell you that you used "with" there twice, or
> I can hide that nugget in a long diatribe about the English
> language, HTML mail and whatever.  If your time is limited,
> you will probably prefer one over the other.
>
> Or, to paraphrase perlstyle(1): Be explicit.  Be concise.  Be
> nice.
>

OK. So if I'll be nice, explicit and concise it will cause that Igor will
finish at least one mass change before start another one?
Igor could you pleas confirm above?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[mcatanzaro]

On Mon, Jan 29, 2018 at 7:39 PM, Per Bothner  wrote:
If any logs or monitoring tools would be helpful, I'll be happy to 
help.


Please see my earlier post in this thread regarding how to get a 
stacktrace out of coredumpctl. If you post an issue report with a 
stacktrace at https://gitlab.gnome.org/GNOME/gnome-shell/issues, then 
the developers will have a chance to investigate.


Thanks,

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Tim Landscheidt]

Tomasz Kłoczko  wrote:

> […]

> This is like with with problems on taking care of the production issues or 
> faults.
> Always needs to be someone who is controlling whole situation but this person 
> does not need to to person doing all OS, HW, app, db related things which 
> needs to be
> changed.
> At the end such person in bigger organisation sometimes is taking 
> responsibility to teach other technical personnel about how to prevent 
> similar faults.

Unfortunately, progress in Fedora and similar projects is
not made by telling people what they are doing wrong, but by
doing The Right Thing™ yourself or in collaboration with
others.  And even if one is reporting a fault, there are
ways to enable someone to fix that fault and there ways to
overwhelm them with superfluous information that makes their
work harder.

For example, take the first line of your text I quoted
above.  I can tell you that you used "with" there twice, or
I can hide that nugget in a long diatribe about the English
language, HTML mail and whatever.  If your time is limited,
you will probably prefer one over the other.

Or, to paraphrase perlstyle(1): Be explicit.  Be concise.  Be
nice.

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Per Bothner]

FWIW, I too have Wayland crashing every few days.
I can't pin-point a pattern: Just now it crashed while
trying to open a pdf attachment in Thunderbird (using
the default Document Viewer).  After rebooting, the same
attachment opened with no problems.

Given that the apps I use are pretty good about recovering
from a crash, it's not a show-stopper for me, but it is annoying.

If any logs or monitoring tools would be helpful, I'll be happy to help.

I'm running an updated Fedora 27 on an HP Spectre.  I have a 4k Sceptre monitor
(cheap and possibly buggy) connected via a Thunderbolt-3-to-HDMI dongle
- or maybe it's a USB-C-to-HDMI dongle :-).
--
--Per Bothner
p...@bothner.com   http://per.bothner.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: 49544 double check password inputs.

[William Brown]

https://pagure.io/389-ds-base/issue/49544

https://pagure.io/389-ds-base/issue/raw/files/cca61c45a5c0c85eecf0b7ee1
8a2f66d12eb27c155bd4b8cff7bb3b63aeb722b-0001-Ticket-49544-Double-check-
pw-prompts.patch


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1539966] New: perl-PPIx-Regexp-0.054 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539966

Bug ID: 1539966
   Summary: perl-PPIx-Regexp-0.054 is available
   Product: Fedora
   Version: rawhide
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.054
Current version/release in rawhide: 0.053-1.fc28
URL: http://search.cpan.org/dist/PPIx-Regexp/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3288/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539952] perl-B-Keywords-1.18 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539952



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-B-Keywords-1.18-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=24548339

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539954] New: perl-CSS-DOM-0.17 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539954

Bug ID: 1539954
   Summary: perl-CSS-DOM-0.17 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CSS-DOM
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.17
Current version/release in rawhide: 0.16-6.fc27
URL: http://search.cpan.org/dist/CSS-DOM

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/8181/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539952] perl-B-Keywords-1.18 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539952



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1388065
  --> https://bugzilla.redhat.com/attachment.cgi?id=1388065=edit
[patch] Update to 1.18 (#1539952)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539952] New: perl-B-Keywords-1.18 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539952

Bug ID: 1539952
   Summary: perl-B-Keywords-1.18 is available
   Product: Fedora
   Version: rawhide
 Component: perl-B-Keywords
  Keywords: FutureFeature, Triaged
  Assignee: robinlee.s...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, rob.my...@gtri.gatech.edu



Latest upstream release: 1.18
Current version/release in rawhide: 1.16-1.fc28
URL: http://search.cpan.org/dist/B-Keywords/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2662/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Orphaning ofono

[Rex Dieter]

Samuel Sieb wrote:

> On 01/29/2018 07:05 AM, Rex Dieter wrote:
>> I will be orphaning the ofono package today.  I'd primarily packaged it
>> with the the intention that it may become a new dependency of pulseaudio
>> (which never happened), and I've not been able to give it the time it
>> needs.
> 
> Isn't it an optional dependency of pulseaudio, as in pulseaudio will use
> it if it's running?  That's what the pulseaudio documentation says.  It
> will use it for bluetooth HFP mode if it's there, otherwise you can't
> have HFP mode.  That's what I was unsuccessfully trying to get working
> when I found the build issue and new version.
> 
> 
https://freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/

OK, maybe it's worthwhile keeping then.  I'd asked some PA devs about that 
awhile back, and I'd gotten the impression ofono wouldn't be used at all... 
at least not in the configuration fedora uses it.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Mon, Jan 29, 2018 at 08:37:50PM +, Terry Barnaby wrote:
> Ok, that's a shame unless NFSv4's write performance with small files/dirs
> is relatively ok which it isn't on my systems.
> Although async was "unsafe" this was not an issue in main standard
> scenarios such as an NFS mounted home directory only being used by one
> client.
> The async option also does not appear to work when using NFSv3. I guess it
> was removed from that protocol at some point as well ?

This isn't related to the NFS protocol version.

I think everybody's confusing the server-side "async" export option with
the client-side mount "async" option.  They're not really related.

The unsafe thing that speeds up file creates is the server-side "async"
option.  Sounds like you tried to use the client-side mount option
instead, which wouldn't do anything.

> What is the expected sort of write performance when un-taring, for example,
> the linux kernel sources ? Is 2 MBytes/sec on average on a Gigabit link
> typical (3 mins to untar 4.14.15) or should it be better ?

It's not bandwidth that matters, it's latency.

The file create isn't allowed to return until the server has created the
file and the change has actually reached disk.

So an RPC has to reach the server, which has to wait for disk, and then
the client has to get the RPC reply.  Usually it's the disk latency that
dominates.

And also the final close after the new file is written can't return
until all the new file data has reached disk.

v4.14.15 has 61305 files:

$ git ls-tree -r  v4.14.15|wc -l
61305

So time to create each file was about 3 minutes/61305 =~ 3ms.

So assuming two roundtrips per file, your disk latency is probably about
1.5ms?

You can improve the storage latency somehow (e.g. with a battery-backed
write cache) or use more parallelism (has anyone ever tried to write a
parallel untar?).  Or you can cheat and set the async export option, and
then the server will no longer wait for disk before replying.  The
problem is that on server reboot/crash, the client's assumptions about
which operations succeeded may turn out to be wrong.

--b.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: VA-API 1.0.0

[Jan Kurik]

= Proposed Self Contained Change: VA-API 1.0.0 =
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0

Change owner(s):
* Nicolas Chauvet 

This change is about upgrading libva and others to version 2.0. This
change affects several multimedia players as there are both API and
ABI changes. This will allow some VA-API backends to be updated,
improving support for recent hardware.

== Detailed Description ==

Updating to VA-API 1.0.0 will allow to fix and clean-up issues with
the API as sum-up in this upstream topic VA-API 1.0.0:
https://github.com/intel/libva/issues/72

* fix errors in API/data structure definition, e.g. 01org#32
* add new features, e.g. 01org#69,
* deprecate some useless API/data structures, e.g. libva-tpi, libva-egl.
* provide other improvement, e.g. use portable type to define data structure.

All packages using libva will be rebuilt to take into account the new
API/ABI. Futhermore, the intel backend will be updated along (not
provided by Fedora). Others VA-API backend such the AMD and NVIDIA
backend provided by Fedora within mesa-dri-drivers will work as
appropriate. Bridges between VA-API and VDPAU will continue to be
supported , this is:

* libva-vdpau-driver which allows to use the VA-API enabled players
with VDPAU backend (such as NVIDIA binary driver).
* libvdpau-va-gl which allows to use the VDPAU API enabled players
with VA-API backends (such as intel driver).


== Scope ==
* Proposal owners:
- Update and rebuild packages that depend on libva. DONE
- Verify that everything is working as appropriate or report issue
upstream. TESTING IN PROGRESS.

* Other developers:
N/A

* Release engineering:
#7285 : https://pagure.io/releng/issue/7285

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

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/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

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-modular...@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/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

wish to resurrect shorewall on EPEL 6 (and re-self-introduction)

[J. Randall Owens]

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 
From: J. Randall Owens 
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/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: Removing ldconfig scriptlets

[Jan Kurik]

= Proposed Self Contained Change: Removing ldconfig scriptlets =
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets

Change owner(s):
* Igor Gnatenko 
* Neal Gompa 

For many years, package maintainers were required to write scriptlets
which call ldconfig in %post/%postun if they package shared libraries.

== Detailed Description ==
Since time immemorial, Red Hat/Fedora packagers have been required to
add a stanza to spec files for packages containing libraries to update
the ldconfig cache.

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

To say this is annoying is to put it mildly. However, there was no
standard mechanism to make this boilerplate go away. Now with RPM
4.13+, we should change this to file triggers and make all of that go
away.

With this change, these scriptlets can be removed and ldconfig would
be run just once per transaction.

If your package places shared libraries in special locations
referenced by ld.so.conf, you still need to run ldconfig manually.

For those who concerned about whether this is self-contained or
system-wide change: there is no overhead if packagers don't remove
ldconfig scriptlets in time, so completion doesn't depend whether
packagers remove them or not. We are just making it possible.


== Scope ==
* Proposal owners:
Make sure that DSO symlinks are being packagedcommit, add transaction
filetriggers to glibccommit + commit.

* Other developers:
Package maintainers are advised to remove ldconfig scriptlets in order
to achieve benefits specified above.

* Release engineering:
#7284: https://pagure.io/releng/issue/7284

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
Packaging guidelines need to be updated to reflect reality.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 29/01/18 19:50, Steve Dickson wrote:


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 +
From:   Terry Barnaby 
To: Steven Whitehouse , Development discussions related to Fedora 
, Terry Barnaby 
CC: Steve Dickson , Benjamin Coddington 




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.

Thanks for the reply.

Ok, that's a shame unless NFSv4's write performance with small 
files/dirs is relatively ok which it isn't on my systems.
Although async was "unsafe" this was not an issue in main standard 
scenarios such as an NFS mounted home directory only being used by one 
client.
The async option also does not appear to work when using NFSv3. I guess 
it was removed from that protocol at some point as well ?



___

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.


Ok, will try doing the wireshark trace. What should I open a Bugzilla 
report against, the kernel ?


What is the expected sort of write performance when un-taring, for 
example, the linux kernel sources ? Is 2 MBytes/sec on average on a 
Gigabit link typical (3 mins to untar 4.14.15) or should it be better ?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning ofono

[Samuel Sieb]

On 01/29/2018 07:05 AM, Rex Dieter wrote:

I will be orphaning the ofono package today.  I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.


Isn't it an optional dependency of pulseaudio, as in pulseaudio will use 
it if it's running?  That's what the pulseaudio documentation says.  It 
will use it for bluetooth HFP mode if it's there, otherwise you can't 
have HFP mode.  That's what I was unsuccessfully trying to get working 
when I found the build issue and new version.


https://freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[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 +
> From: Terry Barnaby 
> To:   Steven Whitehouse , Development discussions 
> related to Fedora , Terry Barnaby 
> 
> CC:   Steve Dickson , Benjamin Coddington 
> 
> 
> 
> 
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Tomasz Kłoczko]

On 29 January 2018 at 19:06, Igor Gnatenko  wrote:
[..]

> > As now with file trigger changes are committed and new glibc packages
> will
> > be in rawhide repo it should be mass change removing all ldconfig
> execution
> > from **ALL** Fedora specs.
>
> While I agree that this is needed, why do you point on this here? I mean
> it's
> obvious to everyone that this should be done. No need to point on obvious
> things.
>

Because similar changes even this one which you only recently started never
have been finished.
Don't get me wrong. You are doing great job. Method used so far in Fedora
are only wrong ..

I'm only asking to finish first what already have been started before you
will put on uour desk next mass change.

Also, are you interested to just write on ML what other people should do or
> you
> want to help? If former, then please stop (because it is just disturbing
> and
> not friendly). If latter, I'm happily will use script you have or you are
> going
> to write.
>

I've already wrote you in the ticket about remove icons caches updates that
remove desktop file cashes does not make any sense to start before remove
icons theme caches will be finished because quite often those updates are
in line above or below.
I'm simple waiting with raise next MCRs until prev changes will be finished.

I cannot help you on those changes because I have no proven packager privs.
If on next MCR you want me to deliver you list of patches and list of files
which needs to be applied on exact packages please do not force me or
people like me to do update those parches because someone else just after
generate thse patches made next batch of some past MCR changes still not
finishing those changes across all no touched specs.

As I wrote already I have at least few tenths other MCRs to discuss and
introduce but I refuse to cooperate in conditions when none of those
changes will be not really done from top to bottom. Is it now clear?
This is not about me or you. This is about GENERAL METHODOLOGY!!
We can do more together but you cannot just drop one change in the middle
and go to start another one ..
So again: please finish at lease PR 736 before you will start with ldconfig
to allow me start preparing next MCR when you will be working on ldconfig.

If you are taking care if exact MCR please clean everything around with
documentation and for example update rpmlint as well.
Such MCR coordinator does not need to do everything. Other people may help
him/her but this person should be at least coordinating everything and at
the and whole MCR checklist is in finished state.

This is like with with problems on taking care of the production issues or
faults.
Always needs to be someone who is controlling whole situation but this
person does not need to to person doing all OS, HW, app, db related things
which needs to be changed.
At the end such person in bigger organisation sometimes is taking
responsibility to teach other technical personnel about how to prevent
similar faults.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Removal of systemd-units

[Jared K. Smith]

2018-01-25 13:17 GMT-05:00 Jason L Tibbitts III :

> For your list of packages, this gives the following two lists, making it
> easy for maintainers to see if they have something to fix without
> looking for individual package names.  (Hence it's now trivial for me to
> see that I have a couple of things that need fixing.)
>

[snip]


> asterisk itamarjp jsmith russellb
>

This has been fixed in the master branch [1].

--
Jared Smith

[1]
https://src.fedoraproject.org/rpms/asterisk/c/d6e4078c66238fd66ba93e27f155d4f41fd2fee4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-29 at 18:49 +, Tomasz Kłoczko wrote:
> On 29 January 2018 at 17:18, Florian Weimer  wrote:
> 
> > Igor committed a change to glibc so that from Fedora 28 going forward,
> > glibc will run ldconfig after the transaction if any of the library
> > directory trees was modified.
> > 
> > This means that libraries which package the lib*.so.* symbolic links will
> > no longer have to run ldconfig in %postin/%postun, and we can automate the
> > creation of those symbolic links with a buildroot policy hook, see:
> > 
> >   
> > 
> > Packages which edit ld.so search paths will still have to run ldconfig in
> > %postin/%postun, as before.
> 
> 
> As now with file trigger changes are committed and new glibc packages will
> be in rawhide repo it should be mass change removing all ldconfig execution
> from **ALL** Fedora specs.

While I agree that this is needed, why do you point on this here? I mean it's
obvious to everyone that this should be done. No need to point on obvious
things.

Also, are you interested to just write on ML what other people should do or you
want to help? If former, then please stop (because it is just disturbing and
not friendly). If latter, I'm happily will use script you have or you are going
to write.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvcMkACgkQaVcUvRu8
X0zJYg//SRQTzH5njmIlCtAzTNE0I9TB/TDAzf0pQOZ2uTJgrz1jp7TMod0CJm5q
c20cBAEvJSVESS9kLvZxHVsv8k8gB5kIn85lc3miXvu1NUZbZy/K+ENw/twINkZG
v/mXkVeofSUWvo5qH40LV1KT0GgRPFiczZ9GLMos+GMtRFmky6LtfG/CE8NS0GS2
MH3ogWMIa4trVN+a+qqslaV8CuWhibOKlBMmhGlJFJL+Wg65qlkya8uOwtHWyri7
/a5BLoIt4Tx7zR6DgHLfz0Xv6QvcxzpD8E8OTs8mC+dNaQ+OEaGe7GstwUUgdDFH
TGJEX74Up7xFc6ebrlacj0U27kftAVL+XAdPVAcEox5ASDojOzmaTtMJy2hfev2b
nR1BXV/a2bEgdezM7rFeKCvf6olU+5OeZoNJJpVhkWGbmcOiBx4QWF9Ynow14Z3r
wJ0yCteh7uAqypZzQsPZ5fFuLb6SiWQ+mXcfxeO1+jLk1EjNyD9MYK5kZ4rGTFFt
ORUb0LGCZOAQ7KtXbP/ulEaNrw34rCyCF8xaHwGYFtrDUbx63YfDZ7nE1SLwNJzn
/UKUeG/j34L0T52Sy1Ntk3XuEhns/Yw1jTA95iLwaufQ7z1TCBS/cX/JqKX7DO1D
DuDXUMQoZwTUtDs4gF2kxZFSfBlrt9LrqII0/g6rEPQaSfGY83Y=
=pj/r
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-01-29 at 18:49 +, Tomasz Kłoczko wrote:
> On 29 January 2018 at 17:18, Florian Weimer  wrote:
> 
> > Igor committed a change to glibc so that from Fedora 28 going forward,
> > glibc will run ldconfig after the transaction if any of the library
> > directory trees was modified.
> > 
> > This means that libraries which package the lib*.so.* symbolic links will
> > no longer have to run ldconfig in %postin/%postun, and we can automate the
> > creation of those symbolic links with a buildroot policy hook, see:
> > 
> >   
> > 
> > Packages which edit ld.so search paths will still have to run ldconfig in
> > %postin/%postun, as before.
> 
> 
> As now with file trigger changes are committed and new glibc packages will
> be in rawhide repo it should be mass change removing all ldconfig execution
> from **ALL** Fedora specs.
> 
> [tkloczko@domek SPECS.fedora]$ grep -e '^%post.*/sbin/ldconfig' * | awk
> -F\. '{print $1}' | uniq | wc -l
> 3257
> [tkloczko@domek SPECS.fedora]$ grep -e ' */sbin/ldconfig' * | awk -F\.
> '{print $1}' | uniq | wc -l
> 3432
> 
> And as well:
> 
> [tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
> > wc -l
> 
> 125
> [tkloczko@domek SPECS.fedora]$ grep -e '^Requires(postun):.*/sbin/ldconfig'
> * |wc -l
> 114
> 
> This needs to be removed as well. If not it will be like with for example
> in hicolor-icon-theme.spec after remove %post/%postun/%postrans
> with gtk-update-icon-cache execution still is possible to find in this spec:

Redmining you 1000th time, don't mix issues. This thread is **ONLY about
ldconfig**.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvb0YACgkQaVcUvRu8
X0wknxAAq3lIUPqHp86ANwS3fw3jlJBdCXjTNRVuxENg+1RsmC9ABNyxeig87o89
6t45hJSPA6Jq7w5DbTrNOm4Qpxw1ldRHeWxp6yxJw6qmmB8egPwrK20FzjQ1gELN
i+IoaQ2lu3aLS1VQBsEAiCYPco/Vw5JxRHge3AqzS4lS9VChH+wadfchjZAnWDv1
Q5etY2LP9P1qe0G0HnCKAPOQPQH4b0BAuRA6OTjaSRpahD/JKHsZDJHFOkVx9vEL
yshsAnwM2oiapUieytc1svEwQVd87DD/Wn3S0TbRynUALacz25X0xpfnRLwZLMBm
kiES8tCMBwesmoLwsuZhBSWM8VQYVqOfJ6EI1GRByj8p/tFMu44QduzgOqNJ8qKF
vyk0xJ0aTCXrux6Z42aPWBZJeQAz7TUHUeTUbyJxdeqPwZJkRx9vxgommcBIjN1u
P7sopGuFRLZfldut3DABtlwuiFDbQo4QZqPQaApLM6z4o7u5WURkLYvP9g1Qvuha
LLftGqm/JpOtNcLz2FbP+MP4aa8t5vky2TdwpBkKNv2DWcKu2XjeQm67GzA4Rp9N
kNzk39wEfECCL3hQN9/ah4MZzjb8DXbbXoPo/sIPOA8dQZFf84DxJXggLnzoiIW+
IpbJS+tjYKUt6bfsNKeVp3CA198YDhkjXTZlntKEXeTxCEumDRs=
=aJ8N
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Tomasz Kłoczko]

On 29 January 2018 at 17:18, Florian Weimer  wrote:

> Igor committed a change to glibc so that from Fedora 28 going forward,
> glibc will run ldconfig after the transaction if any of the library
> directory trees was modified.
>
> This means that libraries which package the lib*.so.* symbolic links will
> no longer have to run ldconfig in %postin/%postun, and we can automate the
> creation of those symbolic links with a buildroot policy hook, see:
>
>   
>
> Packages which edit ld.so search paths will still have to run ldconfig in
> %postin/%postun, as before.


As now with file trigger changes are committed and new glibc packages will
be in rawhide repo it should be mass change removing all ldconfig execution
from **ALL** Fedora specs.

[tkloczko@domek SPECS.fedora]$ grep -e '^%post.*/sbin/ldconfig' * | awk
-F\. '{print $1}' | uniq | wc -l
3257
[tkloczko@domek SPECS.fedora]$ grep -e ' */sbin/ldconfig' * | awk -F\.
'{print $1}' | uniq | wc -l
3432

And as well:

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
|wc -l
125
[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(postun):.*/sbin/ldconfig'
* |wc -l
114

This needs to be removed as well. If not it will be like with for example
in hicolor-icon-theme.spec after remove %post/%postun/%postrans
with gtk-update-icon-cache execution still is possible to find in this spec:

Requires(post): coreutils
Requires(postun): coreutils


If all those changes will be not it will be like with other such changes
which never have been finished:

[tkloczko@domek SPECS.fedora]$ grep '^%clean' * | wc -l
3007
[tkloczko@domek SPECS.fedora]$ grep '^BuildRoot:' * | wc -l
2746
[tkloczko@domek SPECS.fedora]$ grep '^Group:' * | wc -l
18065

To be hones I would be personally [1] way happier if Igor will finish first
finish remove hicolor icons theme cache update before jumping on ldconfig.

Just please Igor (or anyone else who will be helping him) do this properly
finishing whole set of necessary changes within as short as it is only
possible time.

Next point which someone needs to take care is update rpmlint to generate
warning that use ldconfig in %post/%postun is no longer needed.


 And yet another thing connected with above.

I've been many times proposing to use in specs single package/file name
name in each Reqiure or BuildRequires.
I know that many packages do not like this because they are already using
other style.
However it is not about what me or someone else may or may not prefer.
Using single package per Reqiure or BuildRequires is not a matter of
personal preferences because if all those Reqiure/BuildRequires will be
with single package or file path all mass changes will be *way easier to do* by
simple "sed -ie 'd,^Requires(post):.*/sbin/ldconfig,' *spec"

[tkloczko@domek SPECS.fedora]$ grep -e '^Requires(post):.*/sbin/ldconfig' *
acl.spec:Requires(post): /sbin/ldconfig
alsa-lib.spec:Requires(post): /sbin/ldconfig, coreutils
blitz.spec:Requires(post): /sbin/install-info /sbin/ldconfig
cfitsio.spec:Requires(post):/sbin/ldconfig
cinnamon-session.spec:Requires(post): /sbin/ldconfig
Coin2.spec:Requires(post): /sbin/ldconfig
Coin3.spec:Requires(post): /sbin/ldconfig
concordance.spec:Requires(post): /sbin/ldconfig
cyrus-imapd.spec:Requires(post): /sbin/ldconfig
dapl.spec:Requires(post): /sbin/ldconfig
ddccontrol.spec:Requires(post):   /sbin/ldconfig
drumstick0.spec:Requires(post): /sbin/ldconfig
drumstick.spec:Requires(post): /sbin/ldconfig
eb.spec:Requires(post): /sbin/ldconfig
eventlog.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
festival.spec:Requires(post): /sbin/ldconfig
firebird.spec:Requires(post):   /sbin/ldconfig
firebird.spec:Requires(post):   /sbin/ldconfig
freehdl.spec:Requires(post): /sbin/install-info /sbin/ldconfig
fwknop.spec:Requires(post): /sbin/ldconfig
gauche.spec:Requires(post): /sbin/install-info, /sbin/ldconfig
gconfmm26.spec:Requires(post):   /sbin/ldconfig
geda-gaf.spec:Requires(post):   /sbin/ldconfig
gerbv.spec:Requires(post):   /sbin/ldconfig
getdata.spec:Requires(post):/sbin/ldconfig
gnucash.spec:Requires(post): /sbin/ldconfig
gnumeric.spec:Requires(post):   /sbin/ldconfig
gr-air-modes.spec:Requires(post):   /sbin/ldconfig
graphviz.spec:Requires(post): /sbin/ldconfig
graphviz.spec:Requires(post): %{_bindir}/dot /sbin/ldconfig
gr-fcdproplus.spec:Requires(post):   /sbin/ldconfig
gr-iqbal.spec:Requires(post):   /sbin/ldconfig
groonga.spec:Requires(post): /sbin/ldconfig
gr-osmosdr.spec:Requires(post):   /sbin/ldconfig
gtkglextmm.spec:Requires(post): /sbin/ldconfig
gtkglext.spec:Requires(post): /sbin/ldconfig
gwenhywfar.spec:Requires(post): /sbin/ldconfig
hylafax+.spec:Requires(post): /sbin/ldconfig
infiniband-diags.spec:Requires(post): /sbin/ldconfig
infinipath-psm.spec:Requires(post):   /sbin/ldconfig
infinipath-psm.spec:Requires(post):   /sbin/ldconfig
k3d.spec:Requires(post):   

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1057  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 820  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 402  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 299  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 131  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  68  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73feedd767   
wordpress-4.9.2-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ce6223e559   
GraphicsMagick-1.3.28-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9eb18da891   
moodle-3.1.10-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0d5d190b0   
transmission-2.92-12.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd0bc449d7   
konversation-1.5.1-4.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

fuse-encfs-1.9.4-1.el7
mongodb-2.6.12-6.el7
pdns-3.4.11-3.el7
python-socksipychain-2.0.15-1.el7
timeshift-18.1.1-4.el7
w3m-0.5.3-36.git20180125.el7
yaml-cpp-0.5.1-1.el7.1

Details about builds:



 fuse-encfs-1.9.4-1.el7 (FEDORA-EPEL-2018-64ebf1c9ea)
 Encrypted pass-thru filesystem in userspace

Update Information:

Update to 1.9.4.




 mongodb-2.6.12-6.el7 (FEDORA-EPEL-2018-adb6af896b)
 High-performance, schema-free document-oriented database

Update Information:

Downgraded (0.5.3->0.5.1) yaml-cpp due to breaking of binaries built with it.

References:

  [ 1 ] Bug #1539386 - yaml-cpp 0.5.3 breaks existing binaries compiled against 
older versions
https://bugzilla.redhat.com/show_bug.cgi?id=1539386




 pdns-3.4.11-3.el7 (FEDORA-EPEL-2018-adb6af896b)
 A modern, advanced and high performance authoritative-only nameserver

Update Information:

Downgraded (0.5.3->0.5.1) yaml-cpp due to breaking of binaries built with it.

References:

  [ 1 ] Bug #1539386 - yaml-cpp 0.5.3 breaks existing binaries compiled against 
older versions
https://bugzilla.redhat.com/show_bug.cgi?id=1539386




 python-socksipychain-2.0.15-1.el7 (FEDORA-EPEL-2018-2cf21e719f)
 A Python SOCKS/HTTP Proxy module

Update Information:

New dependency from Fedora and EPEL6 for pagekite.

References:

  [ 1 ] Bug #910146 - Review Request: python-socksipychain - Python SOCKS/HTTP 
Proxy module
https://bugzilla.redhat.com/show_bug.cgi?id=910146




 timeshift-18.1.1-4.el7 (FEDORA-EPEL-2018-2034535a48)
 System restore tool for Linux

Update Information:

- Properly apply system LDFLAGS and thus enable full hardening - Generate useful
-debugsource package

References:

  [ 1 ] Bug #1534446 - Review Request: timeshift - System restore tool for Linux
https://bugzilla.redhat.com/show_bug.cgi?id=1534446

[EPEL-devel] Re: Keeping old packages

[Stephen John Smoogen]

On 29 January 2018 at 05:53, Avi Kivity  wrote:

> Recently, I ran into breakage due to yaml-cpp-0.5.3 breaking
> yaml-cpp-0.5.1's ABI. The breakage was due to upstream not maintaining ABI
> compatibility (something that's very hard with some C++ libraries), but
> recovering from it was pretty hard, due to EPEL not keeping old packages
> around.
>
>
> If old packages were kept around, we could just tell people to run "yum
> downgrade yaml-cpp-0.5.1" and then pin that package, until the ABI issue
> was resolved. As it was, we had to refer them to the package from koji,
> which means that new installs become harder.
>
>
> Can we change the policy to keep old packages in the repository, to
> prevent this in the future?
>

This requires a bit of work due to the way that EPEL is made into a
repository. It would require changing the layout quite a bit for what seems
a 'simple' change. It is hopefully going to be on the books for this year
though.



> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: RPM packaging and ldconfig handling

[Florian Weimer]

Igor committed a change to glibc so that from Fedora 28 going forward, 
glibc will run ldconfig after the transaction if any of the library 
directory trees was modified.


This means that libraries which package the lib*.so.* symbolic links 
will no longer have to run ldconfig in %postin/%postun, and we can 
automate the creation of those symbolic links with a buildroot policy 
hook, see:


  

Packages which edit ld.so search paths will still have to run ldconfig 
in %postin/%postun, as before.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-29 16:51, Richard Shaw wrote:
On Mon, Jan 29, 2018 at 8:37 AM, Florian Weimer > wrote:


I have reverted the -z defs change in rawhide.  A substantial number
of underlinked binaries are still shipped in rawhide after this
change, either due to explicit overrides or incomplete build flags
injection. This means that it is necessary to review built RPM
packages for incorrectly linked binaries even after the change. 
Considering that -z defs also causes a lot of spurious build

failures, it's probably not the way to go.

(The work to enable -z defs is not lost—even after the revert,
packages which have been fixed so far will remain fixed.)


Would it make sense (or be a lot of work) to include this in the Koschei 
integration?


Wouldn't that make it so packages with issues could be reported without 
creating a lot of FTBFS issues?




Making koschei builds use -z defs, while regular Fedora builds wouldn't 
use it, is not possible by design (koschei only requests the builds from 
koji, it cannot make changes to the spec and cannot alter the buildroot).
But if the build only produced a warning (as suggested in other part of 
this thread), then it would be possible for koschei to parse the build 
log and indicate this somehow.

But I think taskotron is a better place for such checks.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] please review: Ticket 49370 - Fix double free when using global password policy

[Mark Reynolds]

Fixes regression from previous patch for this ticket

https://pagure.io/389-ds-base/issue/49370

https://pagure.io/389-ds-base/issue/raw/files/f5d011cc871fd8b3ff31ba20f3e52ca972fa47a308150779cbd7f847e8fdfc32-0001-Ticket-49370-Crash-when-using-a-global-and-local-pw-.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Removal of systemd-units

[Paul Howarth]

On Thu, 25 Jan 2018 12:17:26 -0600
Jason L Tibbitts III  wrote:

> > "IG" == Igor Gnatenko 
> > writes:  
> 
> IG> It's just 198 packages and we are just going to fix them for you
> IG> in following days.  
> 
> When posting big lists of packages, please consider running that list
> through
> https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers
> 
> For your list of packages, this gives the following two lists, making
> it easy for maintainers to see if they have something to fix without
> looking for individual package names.  (Hence it's now trivial for me
> to see that I have a couple of things that need fixing.)
> 
> Maintainers by package:
...
> pghmcfcmilter-regex mod_fcgid proftpd rbldnsd spamass-milter

All done.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Richard Shaw]

On Mon, Jan 29, 2018 at 8:37 AM, Florian Weimer  wrote:

> I have reverted the -z defs change in rawhide.  A substantial number of
> underlinked binaries are still shipped in rawhide after this change, either
> due to explicit overrides or incomplete build flags injection. This means
> that it is necessary to review built RPM packages for incorrectly linked
> binaries even after the change.  Considering that -z defs also causes a lot
> of spurious build failures, it's probably not the way to go.
>
> (The work to enable -z defs is not lost—even after the revert, packages
> which have been fixed so far will remain fixed.)


Would it make sense (or be a lot of work) to include this in the Koschei
integration?

Wouldn't that make it so packages with issues could be reported without
creating a lot of FTBFS issues?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Richard W.M. Jones]

On Mon, Jan 29, 2018 at 03:55:53PM +0100, Florian Weimer wrote:
> On 01/29/2018 03:43 PM, Kevin Kofler wrote:
> >Is https://fedoraproject.org/wiki/Changes/Annobin (no user-visible
> >improvements, only yet another global distrowide size increase) really worth
> >the circular dependency nightmare (rebuilding annobin requires GCC, but GCC
> >is configured to not work without annobin) or is it time to drop the feature
> >and enact the contingency plan?
> 
> Yes, it is required for meeting our security hardening objectives.
> 
> Ideally, annobin would be built from the GCC source package, but
> since GCC needs more than twelve hours to build on armhfp, that is
> not really an option while we are still adjusting the information
> that annobin collects.

annobin.spec now uses:

  %undefine _annotated_build

so at least the circular dependency is no longer there.  You still
have to remember to rebuild it when a new version of GCC comes out
however.

RIch.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packaging DSO symlinks

[Tomasz Kłoczko]

On 29 January 2018 at 15:11, Igor Gnatenko  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> You might have seen that we are trying to eliminate /sbin/ldconfig from
> scriptlets which would speedup installation / upgrade of packages
> **significantly**.
>
> One of cases Florian brought that in case of libcrypt/libcrypt-nss,
> libraries
> didn't have symlinks, so if it would not call ldconfig in its scriptlet,
> then
> any packages which depend on libcrypt.so would fail to execute.
>
> In 99% (this number came just out of my head, not a real investigation) of
> packages, we always package those symlinks.
>
> So I'm going to push change to glibc which during build process executes
> ldconfig in buildroot which is forcing to create those symlinks and your
> package would fail to build with something like:
> error: Installed (but unpackaged) file(s) found:
>/usr/lib64/libhello.so.1
>
> To disable this you would need to use `%undefine __brp_ldconfig` and you
> really
> need to make sure that you have %post/%postun scriptlets with
> /sbin/ldconfig.
>
> The plan is to get this in, then get transfiletrigger in glibc which would
> execute ldconfig just **once per transaction** and then start removing
> scriptlets from packages.
>

Just FTR: it is one very good reason why those DSO SONAME symlinks *must be
packaged*.
If those files will be not packaged simple "rpm -Va" cannot verify those
symlinks that they've for example been repointed to some other DSO files
with some malware.

In other words: any Fedora package which does not package DSO SONAME
symlinks it is broken package, and it is completely independent fact from
whole ldconfig discussion.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Richard W.M. Jones]

On Mon, Jan 29, 2018 at 03:38:00PM +0100, Michael Schwendt wrote:
> On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
> 
> > = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> > 
> > Change owner(s):
> > * Björn Esser 
> > * Florian Weimer 
> > 
> > There are plans to remove libcrypt from glibc, so we should have a 
> > replacement.
> > 
> 
> Please clarify what exactly the plan is.
> 
> To replace libcrypt with a compatible library and with a grace period for
> apps to stop using deprecated functions that may be removed in the future?
> 
> Or to replace libcrypt with an incompatible library immediately with no
> grace period?
> 
> 
> The reason why I ask is that Claws Mail still uses encrypt() with the sole
> purpose of being able to decrypt old passwords. It doesn't convert them to
> different encryption algorithms automatically, unless the user changes the
> password, and it doesn't force the user to set a Master Password either.
> Only the latter would add security since Claws Mail 3.14.0 (2016), which
> added that as a new feature.

virt-customize is in a similar situation, except that we are also
writing passwords on very old operating system images that require
crypt(3).

One thing we had a bug report about was the old virt-builder and
virt-customize binaries segfaulting with the new glibc.  This turns
out because crypt(3) in the new glibc is still there but always(?)
returns NULL which unfortunately our code wasn't expecting ...
Something to be aware of anyway.

I have since modified virt-customize to use libxcrypt.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Packaging DSO symlinks

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

You might have seen that we are trying to eliminate /sbin/ldconfig from
scriptlets which would speedup installation / upgrade of packages
**significantly**.

One of cases Florian brought that in case of libcrypt/libcrypt-nss, libraries
didn't have symlinks, so if it would not call ldconfig in its scriptlet, then
any packages which depend on libcrypt.so would fail to execute.

In 99% (this number came just out of my head, not a real investigation) of
packages, we always package those symlinks.

So I'm going to push change to glibc which during build process executes
ldconfig in buildroot which is forcing to create those symlinks and your
package would fail to build with something like:
error: Installed (but unpackaged) file(s) found:
   /usr/lib64/libhello.so.1

To disable this you would need to use `%undefine __brp_ldconfig` and you really
need to make sure that you have %post/%postun scriptlets with /sbin/ldconfig.

The plan is to get this in, then get transfiletrigger in glibc which would
execute ldconfig just **once per transaction** and then start removing
scriptlets from packages.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpvOYgACgkQaVcUvRu8
X0y2dg//XN5KrnjG05+imdYHemsbGj0lX4CbEIjJiZMQ4Y35M/qtgSE4GhhQjqrv
+atrlzE8iV7oszMxbn3m59BHCmC0XGDn1Z68nc0WECTd3wfURt5/WLJiYCtxaDtL
Jai27G1I2orFO6s+jPr6Vi4FFFvaMKlSNlcXEFRCp2UOC+OLnIqPr5UueOAy6hk0
GUeiMto7VE0Nq/ScKfXQG70tJcdUB9MFkrBI3duhwCCNWqKdeSKDV37ZrDpCO98O
8OzoZhx22FcSvIodYNIz4FPYzRVUDegP4AwbRaeEq6JVhGMY6GrhQ/lFPvMQNynp
C2+t4U7hKXRut0GlOwPbyD0NxWy0rOMdz2lAyzOQIZZUcKmo0gvMxnYWDrPY8X1W
5uCdgMqvez3cXTj7crUBu2/jkJIeTG5INdgePZeDf6mX8Y1yp0IwP3WqeiQSLggN
HV/6bjNX4yLSPAtWoxZyQtwADl6LEW9oVqJB1nLdk2URx0hnN7Sl3e7xl6RLbHR6
PNXXku3Y2HtuFhe7HWb3TyBK1gpOz/GK7+Hqycd2BCozNnXc3Ho4wTe+YXip/xGL
KW1vJty0BXvgYXuDUFB/sO4ETWvDMVQMMLYxnjcHIo74VxCYlKAbLP40efQkh3wq
Zcol+j6TbqdA6aKBfO03nt5Q17P0+8BewfXNvcP3meeSMcxl470=
=k+H3
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Neal Gompa]

On Mon, Jan 29, 2018 at 10:02 AM, Fabio Valentini  wrote:
> On Mon, Jan 29, 2018 at 3:37 PM, Florian Weimer  wrote:
>> I have reverted the -z defs change in rawhide.  A substantial number of
>> underlinked binaries are still shipped in rawhide after this change, either
>> due to explicit overrides or incomplete build flags injection. This means
>> that it is necessary to review built RPM packages for incorrectly linked
>> binaries even after the change.  Considering that -z defs also causes a lot
>> of spurious build failures, it's probably not the way to go.
>>
>> (The work to enable -z defs is not lost—even after the revert, packages
>> which have been fixed so far will remain fixed.)
>
> Maybe this change can be revisited for a later fedora release? I think
> there is a benefit in assuring that working libraries / biniares are
> produced.
>
> Also, would it be possible to print a warning instead of failing on
> detected underlinking?
> If so, I think build logs could be checked for the warning as part of
> the usual taskotron/bodhi(?) build checks, and errors could get fixed
> one by one (or ignored, in the case of false positives). That would
> provide the same benefit of checking all packages, but with much less
> overall impact on package builds (ideally, none).
>

It also sounds like it'd make sense to make this an opt-in change for
this release, so that we can incrementally fix things to make it
opt-out next release.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning ofono

[Rex Dieter]

I will be orphaning the ofono package today.  I'd primarily packaged it with 
the the intention that it may become a new dependency of pulseaudio (which 
never happened), and I've not been able to give it the time it needs.

Recently updated  to latest 1.22 release which fixed a long-standing FTBFS 
issue, so at least it is in good shape for anyone interested in picking it 
up.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Fabio Valentini]

On Mon, Jan 29, 2018 at 3:37 PM, Florian Weimer  wrote:
> I have reverted the -z defs change in rawhide.  A substantial number of
> underlinked binaries are still shipped in rawhide after this change, either
> due to explicit overrides or incomplete build flags injection. This means
> that it is necessary to review built RPM packages for incorrectly linked
> binaries even after the change.  Considering that -z defs also causes a lot
> of spurious build failures, it's probably not the way to go.
>
> (The work to enable -z defs is not lost—even after the revert, packages
> which have been fixed so far will remain fixed.)

Maybe this change can be revisited for a later fedora release? I think
there is a benefit in assuring that working libraries / biniares are
produced.

Also, would it be possible to print a warning instead of failing on
detected underlinking?
If so, I think build logs could be checked for the warning as part of
the usual taskotron/bodhi(?) build checks, and errors could get fixed
one by one (or ignored, in the case of false positives). That would
provide the same benefit of checking all packages, but with much less
overall impact on package builds (ideally, none).

Fabio

>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Florian Weimer]

On 01/29/2018 03:43 PM, Kevin Kofler wrote:

Is https://fedoraproject.org/wiki/Changes/Annobin (no user-visible
improvements, only yet another global distrowide size increase) really worth
the circular dependency nightmare (rebuilding annobin requires GCC, but GCC
is configured to not work without annobin) or is it time to drop the feature
and enact the contingency plan?


Yes, it is required for meeting our security hardening objectives.

Ideally, annobin would be built from the GCC source package, but since 
GCC needs more than twelve hours to build on armhfp, that is not really 
an option while we are still adjusting the information that annobin 
collects.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Test gating enabled in Bodhi

[Kamil Paral]

On Tue, Jan 23, 2018 at 10:28 AM, Pierre-Yves Chibon 
wrote:

> Good Morning Fedorans!
>
> On Thursday, a new version of Bodhi was deployed that enabled Bodhi to
> gate updates based on test results. You may notice a "Test Gating
> Status" message in the right have side of the page.
>
> One thing to know about this is that there is currently a confusing
> issue where Bodhi will say that the tests have failed when the tests
> haven't finished running[0]. We are working on solving that issue, but
> for now you can just wait a while and it should report the result once
> all the tests have finished.
>
> There are three tests that must pass in order for updates to go to stable:
>
> 0. dist.depcheck - to make sure the update's dependencies are available.
>

Since I haven't seen anyone clarifying this, I'll clarify - the task is
named dist.rpmdeplint, not dist.depcheck. I fixed the wiki as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Kevin Kofler]

Is https://fedoraproject.org/wiki/Changes/Annobin (no user-visible 
improvements, only yet another global distrowide size increase) really worth 
the circular dependency nightmare (rebuilding annobin requires GCC, but GCC 
is configured to not work without annobin) or is it time to drop the feature 
and enact the contingency plan?

I would say the latter.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:

> = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> 
> Change owner(s):
> * Björn Esser 
> * Florian Weimer 
> 
> There are plans to remove libcrypt from glibc, so we should have a 
> replacement.
> 

Please clarify what exactly the plan is.

To replace libcrypt with a compatible library and with a grace period for
apps to stop using deprecated functions that may be removed in the future?

Or to replace libcrypt with an incompatible library immediately with no
grace period?


The reason why I ask is that Claws Mail still uses encrypt() with the sole
purpose of being able to decrypt old passwords. It doesn't convert them to
different encryption algorithms automatically, unless the user changes the
password, and it doesn't force the user to set a Master Password either.
Only the latter would add security since Claws Mail 3.14.0 (2016), which
added that as a new feature.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Florian Weimer]

I have reverted the -z defs change in rawhide.  A substantial number of 
underlinked binaries are still shipped in rawhide after this change, 
either due to explicit overrides or incomplete build flags injection. 
This means that it is necessary to review built RPM packages for 
incorrectly linked binaries even after the change.  Considering that -z 
defs also causes a lot of spurious build failures, it's probably not the 
way to go.


(The work to enable -z defs is not lost—even after the revert, packages 
which have been fixed so far will remain fixed.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: yaml-cpp: Better to only build static libraries?

[Richard Shaw]

On Mon, Jan 29, 2018 at 8:27 AM, Kevin Kofler 
wrote:

> Richard Shaw wrote:
> > Per https://bugzilla.redhat.com/show_bug.cgi?id=1539386 I've now been
> > bitten twice after being asked to update a package in EPEL.
> >
> > Per this version this was a patch level update but it still breaks
> > applications so I'm wondering if it would just be best to only supply a
> > static library, at least in EPEL...
>
> I can't speak for EPEL, but in Fedora I'd rather you just bump the soname
> and rebuild the applications using the library when it is needed.


That's what I did but on EPEL a lot of people develop their own business
applications, which of course I can't and shouldn't rebuild, and in many
cases they're "validated" so changing is very painful.

For now I reverted back to 0.5.1 in EPEL (with -static subpackage) and
created a COPR for those who want to work with the newer version.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: kernel component on bugzilla and call for "old bugs hunting season" to pen

[Josh Boyer]

On Sun, Jan 28, 2018 at 1:09 PM, Tomasz Kłoczko
 wrote:
> On 27 January 2018 at 21:50, Justin Forbes  wrote:
> [..]
>>
>> > 1) Probably it would be good start posting one time a week summary stats
>> > about Bugzilla tickets. Any volunteer to create such weekly report?
>>
>> 26   27rawhide
>> open:   243 191  288(722)
>>
>> Since 2017-12-27
>> opened:   7 6915  (91)
>> closed: 7 3613  (56)
>>
>>
>> This is the stats for the past 30 days, which are fairly bad because
>> 1)  a *lot* of time has been taken to deal with Spectre/Meltdown and
>> 2) Most kernel folks weren't working for the holidays, and half the
>> team was travelling last week. I will be happy to start sending out
>> such reports to the kernel list monthly.
>
>
> That is OK.
> Problem is with very long tail of other still opened tickets.
> Again: some of the tickets are in NEW state from 2009.
>
> In last two days I've closed about 10-15 tickets which I found that
> definitely are 100% outdated.
> Every package maintainer can at least spent 1-15 min a month to try have
> look is anything on the maintained packages list can be closed or not.
>
> Among those tickets I found at least one class which should be not opened
> against Fedora but exacts project which is producing at the end tar ball
> used in Fedora package.
> This class it is various RFE (Request For Enhance) tickets which none or
> almost none of the Fedora packagers can implement.
>
> Next: I think that it would be good to have obligatory rule that even if
> ticket was opened longer 3 to 5 years such ticket should be automatically
> closed,
>
> Next: as I wrote I found tickets which are opened against packages which are
> no lo longer part of the Fedora.
> Someone who can make query against Bugzilla SQL backend should try to find
> all those tickets and close them all.
> Those packets should be removed from list of Fefora components as well.
>
> One example I've mention already and it is ghdcpd ticket:
> https://bugzilla.redhat.com/show_bug.cgi?id=502717
> Second one is fr example xorg-x11-fonts:
> https://bugzilla.redhat.com/show_bug.cgi?id=477486
>
> I'm sure that list of such packets/components and tickets is way longer.
> It is possible to close those tickets by compare with list of still
> maintained Fedora packages.
> This could be done by Biugzilla admin and cannot be done that way by anyone
> else.
>
>> > 2) Q: do we need new kernel package maintainer or secondary co
>> > maintainers?
>>
>> We currently have 2.5 maintainers, and I believe the .5 is ramping up
>> to a full time 3.   We have asked several times over the years for
>> people to help with triage, and even have a lovely step by step guide:
>> https://fedoraproject.org/wiki/KernelBugTriage Very few people seem
>> interested.
>
>
> So I was simple unlucky (?) that in +1 years none of my +10 tickets with
> details about versions and call traces NEVER had even single short msg
> "We know about the issue. Closing ad duplicated ticket to "?
> Kernel is fast moving package end even within few days tickets with some
> reported OOPSes is possible to close. Why it does not happen?
> Is someone has time to update kernel package why the same person has no time
> to close few recent tickers wit c comment:
>
> "New kernel release is in rawhide repo.
> Closing ticket.
> Please reopen if issue still is present"
>
> ?
> Is it really so hard?

Yes.  Mostly because there's no guarantee the newer kernel fixes the
issue and it's really not known.  So then you get into a cycle of
CLOSED->REOPENED->CLOSED->REOPENED *every day* and that's a waste of
time and a horrible user experience.

> After passing +100 still opened tickets per package I can understand that no
> one wants to even look on new tickets.

That's not the case for the kernel.

> This as result does not make any sense opening new tickets. Isn't it?

We need the new tickets.  The large number of tickets helps spot
patterns that would otherwise not be obvious given the kernel's
problem space.  If one user reports an issue, it might just be their
machine.  This happens frequently.  If 30 users report the same (or
very similar) issue, it's much more likely there is a bug we can hone
in on and fix.  We need the aggregate data.

> If current kernel (secondary) maintainers don't want to work on Bugzilla
> tickets (again) maybe it would be better to find new co-maintainers or add
> more co-maintainers?

There's nothing preventing anyone from doing this today.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: yaml-cpp: Better to only build static libraries?

[Kevin Kofler]

Richard Shaw wrote:
> Per https://bugzilla.redhat.com/show_bug.cgi?id=1539386 I've now been
> bitten twice after being asked to update a package in EPEL.
> 
> Per this version this was a patch level update but it still breaks
> applications so I'm wondering if it would just be best to only supply a
> static library, at least in EPEL...

I can't speak for EPEL, but in Fedora I'd rather you just bump the soname 
and rebuild the applications using the library when it is needed.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1537506] Upgrade perl-Crypt-SMIME to 0.23

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1537506

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Crypt-SMIME-0.23-1.fc2
   ||8
 Resolution|--- |RAWHIDE
   Assignee|steve.tray...@cern.ch   |jples...@redhat.com
Summary|Upgrade perl-Crypt-SMIME to |Upgrade perl-Crypt-SMIME to
   |0.22|0.23
Last Closed||2018-01-29 09:19:19



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539667] perl-DBIx-Class-0.082841 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539667

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBIx-Class-0.082841-1.
   ||fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-29 08:41:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Test-Announce] **CANCELLED** Re: 2018-01-29 @ 17:00 UTC - Fedora 28 Blocker Review Meeting

[Adam Williamson]

On Mon, 2018-01-29 at 01:43 +0100, Adam Williamson wrote:
> # F28 Blocker Review meeting
> # Date: 2018-01-29
> # Time: 17:00 UTC
> # Location: #fedora-blocker-review on irc.freenode.net
> 
> Hi folks! We have two proposed blockers for Fedora 28 Beta and one
> for Fedora 28 Final, so let's have a review meeting today.

So, this is now cancelled: folks did some voting in-bug and the
proposed blockers are dealt with. No need for IRC bureaucracy! Yay!
Thanks everyone who voted.

The QA meeting is still on, though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1539667] New: perl-DBIx-Class-0.082841 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539667

Bug ID: 1539667
   Summary: perl-DBIx-Class-0.082841 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBIx-Class
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest upstream release: 0.082841
Current version/release in rawhide: 0.082840-9.fc27
URL: http://search.cpan.org/dist/DBIx-Class/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6651/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539274] perl-Mail-Message-3.006 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539274

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Mail-Message-3.006-1.f
   ||c28
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |jples...@redhat.com
Last Closed||2018-01-29 07:09:11



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Mail-Message (master). "3.006 bump"

[notifications]

From 7a0763a7e16fe76864c064604fce56cff04b2da7 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jan 29 2018 12:06:27 +
Subject: 3.006 bump


---

diff --git a/.gitignore b/.gitignore
index 3053447..2285281 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Mail-Message-3.001.tar.gz
 /Mail-Message-3.002.tar.gz
 /Mail-Message-3.005.tar.gz
+/Mail-Message-3.006.tar.gz
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index 3cab334..2874754 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,13 +1,13 @@
 Name:  perl-Mail-Message
-Version:   3.005
+Version:   3.006
 Release:   1%{?dist}
 Summary:   MIME message handling
 Group: Development/Libraries
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Mail-Message/
 Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARKOV/Mail-Message-%{version}.tar.gz
-BuildRequires: perl-interpreter
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(base)
 BuildRequires: perl(Carp)
 BuildRequires: perl(Cwd)
@@ -66,7 +66,7 @@ BuildRequires:perl(vars)
 BuildRequires: perl(warnings)
 # Remember when we could assume build environments had common packages?
 # Pepperidge Farm remembers.
-BuildRequires: coreutils, make, findutils, glibc-common
+BuildRequires: coreutils, make, glibc-common
 BuildArch: noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 # Explicit run requires
@@ -109,8 +109,7 @@ make
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT/*
 # Fix file encoding
 recode()
 {
@@ -128,6 +127,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jan 29 2018 Jitka Plesnikova  - 3.006-1
+- 3.006 bump
+
 * Wed Jan 10 2018 Jitka Plesnikova  - 3.005-1
 - 3.005 bump
 
diff --git a/sources b/sources
index b9004ab..8bad3b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Message-3.005.tar.gz) = 
6990fe1710cc7e8a09430c8686a695e436c454c9e5b2063161ad87d493bbd5ef3825c214c82341b75e2d388354460b0502db7d1c1c5821cef58c0107be75
+SHA512 (Mail-Message-3.006.tar.gz) = 
760bd67484264ba69736726274630bbbf5616deafc6873906480c39070fb1025b6aa5d8064c7a5f583469b07070c47bc5bb0c74d81147c1e7d90ba514ca7548e



https://src.fedoraproject.org/rpms/perl-Mail-Message/c/7a0763a7e16fe76864c064604fce56cff04b2da7?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511244] perl-Mail-Transport-3.002 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1511244

Jitka Plesnikova  changed:

   What|Removed |Added

   Assignee|tcall...@redhat.com |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511244] perl-Mail-Transport-3.002 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1511244

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Mail-Transport-3.002-1
   ||.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-29 06:43:21



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Mail-Transport (master). "3.002 bump"

[notifications]

From f992cf2408be7e01668810c4ee2ca7eff5e2bf8a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jan 29 2018 11:40:45 +
Subject: 3.002 bump


---

diff --git a/.gitignore b/.gitignore
index fc65ab5..8846b49 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mail-Transport-3.000.tar.gz
+/Mail-Transport-3.002.tar.gz
diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec
index 947ca73..89e626d 100644
--- a/perl-Mail-Transport.spec
+++ b/perl-Mail-Transport.spec
@@ -1,31 +1,29 @@
 Name:  perl-Mail-Transport
-Version:   3.000
-Release:   4%{?dist}
+Version:   3.002
+Release:   1%{?dist}
 Summary:   Email message exchange
 Group: Development/Libraries
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Mail-Transport/
 Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARKOV/Mail-Transport-%{version}.tar.gz
-BuildRequires: perl-interpreter
+BuildRequires: make
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(base)
 BuildRequires: perl(Carp)
 BuildRequires: perl(Errno)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires: perl(File::Spec) >= 0.7
 BuildRequires: perl(IO::Handle)
 BuildRequires: perl(IO::Lines)
 BuildRequires: perl(IO::Socket)
 BuildRequires: perl(List::Util)
-BuildRequires: perl(Net::SMTP)
 BuildRequires: perl(Mail::Reporter) >= 3
+BuildRequires: perl(Net::SMTP)
 BuildRequires: perl(strict)
 BuildRequires: perl(Test::More)
 BuildRequires: perl(vars)
 BuildRequires: perl(warnings)
-BuildRequires: coreutils
-BuildRequires: findutils
-BuildRequires: make
 BuildArch: noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 Requires:  perl(IO::Lines)
@@ -39,14 +37,12 @@ Email message exchange code, formerly part of the Mail::Box 
package.
 %setup -q -n Mail-Transport-%{version}
 
 %build
-yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor
+yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 make test
@@ -57,6 +53,10 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jan 29 2018 Jitka Plesnikova  - 3.002-1
+- 3.002 bump
+- Modernize spec file
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
3.000-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index fec720b..eeca5eb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Transport-3.000.tar.gz) = 
6a209aac34fd79141ce8559038a3e523e50338301391ff08e6450afc8494058afbe5c8930ac919a9e0c20227d1a3a5a08d7c6dd1a02641e94951923736772d4a
+SHA512 (Mail-Transport-3.002.tar.gz) = 
8bee89a71df9c6b834ce25ed131690c688e7f36b9778cb4862f4cb1a313154529a2ff924c053c525e12afeb0508dbb2895d769a8777be2709377ad48438de42a



https://src.fedoraproject.org/rpms/perl-Mail-Transport/c/f992cf2408be7e01668810c4ee2ca7eff5e2bf8a?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539371] perl-Authen-SCRAM-0.007 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539371

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Authen-SCRAM-0.007-1.f
   ||c28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-29 06:12:31



--- Comment #3 from Petr Pisar  ---
This defined a minimal iteration count. Server requiring less will cause an
error on the client. Due this change in behavior, we will push it only into
Rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539445] perl-DBI-1.640 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539445

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBI-1.640-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-29 06:03:06



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Correct FSF address

[Vascom]

Do you mean use addressless license notices
https://www.gnu.org/licenses/gpl-howto.en.html

пн, 29 янв. 2018 г. в 13:13, Florian Weimer :

> On 01/29/2018 10:23 AM, Vascom wrote:
> > Which address is really correct and should be used by upstream?
>
> The FSF recommends using  nowadays.
>
> Thanks,
> Florian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Keeping old packages

[Avi Kivity]

Recently, I ran into breakage due to yaml-cpp-0.5.3 breaking 
yaml-cpp-0.5.1's ABI. The breakage was due to upstream not maintaining 
ABI compatibility (something that's very hard with some C++ libraries), 
but recovering from it was pretty hard, due to EPEL not keeping old 
packages around.



If old packages were kept around, we could just tell people to run "yum 
downgrade yaml-cpp-0.5.1" and then pin that package, until the ABI issue 
was resolved. As it was, we had to refer them to the package from koji, 
which means that new installs become harder.



Can we change the policy to keep old packages in the repository, to 
prevent this in the future?

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Correct FSF address

[Florian Weimer]

On 01/29/2018 10:23 AM, Vascom wrote:

Which address is really correct and should be used by upstream?


The FSF recommends using  nowadays.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Correct FSF address

[Vascom]

rpmlint show error then in source code present incorrect FSF address and we
have recomendation to correct it
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
According this recomendation correct address can be taken from
http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
... Boston, MA 02110-1301 USA

But it has different ZIP-code from address present on this page
https://www.fsf.org/about/contact/
... Boston, MA 02110-1335 USA

Which address is really correct and should be used by upstream?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Wishlist (Was: Working on a Dracut bug?)

[inderaue23]

> Matthew Miller  hat am 27. Januar 2018 um 09:52 
> geschrieben:
> 
> 
> On Fri, Jan 26, 2018 at 08:06:59PM +0100, inderau...@arcor.de wrote:
> > > You are welcome to add things to
> > > https://fedoraproject.org/wiki/Package_maintainers_wishlist
> > hmm but there seems to be no mailing list address for requesting it?!
> > can i use the developerslist instead?
> 
> You could certainly make a case on this list. The thing is, we
> generally aren't short of ideas for things to do. The best way to
> make something happen in Fedora is to do it -- and the best person to
> do something is generally someone who cares about that thing. What's
> the software you are interested in?

Hi Matthew, that would be great. But i have no technical background to realise 
that :(
I'm interest in GNU Ring's communication solution.
https://ring.cx/en
https://ring.cx/en/about/practical

> 
> 
> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Petr Pisar]

On Thu, Jan 25, 2018 at 04:14:52PM +, Tom Hughes wrote:
> There seems to be a similar issue with perl extensions that use C++ failing
> to link due to missing libstdc++ symbols, eg:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24412387
> 
> I think in that case the issue is that libgdal is linked to libstdc++ but
> the perl GDAL.so module was wound up with direct references to symbols in
> libstdc++ but isn't linking to it directly.
> 
> So I think that needs a fix in gdal rather than changing the default
> libraries linked by perl.
> 
> In fact I guess the link should really use g++ not gcc? Not sure how easy
> that is to do in a perl extension build...
> 
Perl supports building using both C and C++ compilers. I did not checked gdal
build script, but if you use ExtUtils::MakeMaker, you can redefine CC value to
g++ in WriteMakefile() arguments in your Makefile.PL.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1539331] perl-App-a2p-1.010 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539331

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-App-a2p-1.010-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-01-29 03:51:46



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [heads-up] soname version bump for evolution-data-server in rawhide

[David Tardon]

Hello,

On Mon, 2018-01-29 at 08:58 +0100, Milan Crha wrote:
> The list of dependencies according to:
># dnf repoquery --whatrequires evolution-data-server-devel --
> alldeps
> follows:
>evolution
>folks
>maya-calendar
> but it seems surprisingly low number of packages, because I know of
> several others (like syncevolution, evolution-ews, evolution-mapi,
> ...)
> which also depend of evolution-data-server.

Build deps can be indirect. You have to look for packages that actually
link with any library from evolution-data-server. (And you should also
look at the rawhide repo, unless you are really sure that no new
packages that use evolution-data-server have been added.)

# dnf repoquery -q --disablerepo=* --enablerepo=rawhide --whatrequires 
evolution-data-server --alldeps \
  | xargs dnf repoquery -q --disablerepo=* --enablerepo=rawhide --qf 
'%{SOURCERPM}' \
  | sed -e 's/-[^-]*-[^-]*$//' \
  | sort -u
gives:
 almanah
 bijiben
 california
 ekiga
 evolution
 evolution-data-server
 evolution-ews
 evolution-mapi
 evolution-rspam
 evolution-rss
 ffgtk
 folks
 glabels
 gnome-calendar
 gnome-contacts
 gnome-phone-manager
 gnome-shell
 gnome-todo
 libopensync-plugin-evolution2
 maya-calendar
 sflphone
 syncevolution
 wingpanel-indicator-datetime

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 815713] perl-Padre-1.00 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=815713

Jitka Plesnikova  changed:

   What|Removed |Added

 CC||kloczko.tom...@gmail.com



--- Comment #6 from Jitka Plesnikova  ---
*** Bug 1539208 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1539208] Please upgrade to 1.00

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1539208

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2018-01-29 03:06:32



--- Comment #1 from Jitka Plesnikova  ---


*** This bug has been marked as a duplicate of bug 815713 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

Hello,
the next week release (2018-02-05) of evolution-data-server,
version 3.27.90, will contain a soname version bump of libcamel,
libedataserver and libedataserverui. It contains some backward
incompatible changes, though I expect minimal impact on other packages,
because that API was more or less related to evolution itself only.
That means that a simple rebuild of affected packages should be enough,
but in case of any issue feel free to ask me for help.

The list of dependencies according to:
   # dnf repoquery --whatrequires evolution-data-server-devel --alldeps
follows:
   evolution
   folks
   maya-calendar
but it seems surprisingly low number of packages, because I know of
several others (like syncevolution, evolution-ews, evolution-mapi, ...)
which also depend of evolution-data-server.

I'll rebuild packages I've commit rights for myself, unless the main
maintainer(s) will be quicker.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org