-Werror (or any alternatives in different languages)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

- From time to time I see upstreams using -Werror (or, #[deny(warnings)] in 
Rust)
which is definitely causing problems when gcc or any other compiler adds new
warnings. Unfortunately, some upstreams reject removing -Werror and use it just
 for specific warnings.

I'm thinking about passing --cap-lints warnings to rustc to prevent erroring on
this (and just show warning). Should we do same for C/C++? Or should I
reconsider decision in Rust land?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp+pdsACgkQaVcUvRu8
X0yycg/9HqrMtz/e4mP7gDeyiWx5JNWDtnWj778RsLw5dB1LmO7FIgtZ724cIR6t
GeLHbo+3Ap1nZpVJL+mlLJf9nAdVLQWRUn/pIUQFVDAlIuaSxnTT0LIE0qLCiLMb
Zch9M55rNSSJQR1IvmWEuOB/X3/fYt3jTaovdzr1aaUKlY68yXPUWvdRXEOp3OPt
73SFZ1kzTwnSJ2XfFccEmoFV47A/YWqojzV5EwdvWWYtaHpfKjTjQOgWvoqCTbqW
7QTOZ700kaje0Kbh3lcksQvFo3E9siSng8UvO/RDlUoWs/vmC/f2u2+mN7FKU4Es
Bgzt67UpnV7PeBqtaUKwRyvoC0AUNqxzVDtq3BFoNT8QOeCaxAjDi7/MWfxBxdmm
4UrEdwG7xXL/862UoEBUIXSWpAa40TKosjPkeJV3Bjnq44U/kp79xGpRzJgDgLIQ
LITGCecfWvveQaP9TJPLBlkgkA/Bmmd0pmSioATfwOfKwJEND99x7QsE2urpA7Lp
EsZf4p47LvJH5AvnDiMxojqfrKgND5bvHGtRCGVyBp0SlzkAfVmHM/MgLUrN03qx
0phKWyjuQqPsX1Nu2hL+zKHwkPD6ggfvIAuTZcwNeuZjkkglJMsP5Vx7oQl+Dtts
PsCNAHdS87+piOpTPEd84isv9nMI5oti4sfHuSuf1NlG4Tvezqk=
=smzF
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2018-02-12 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. It's a
public holiday here in Canada, and I don't think there are any urgent
topics at this time. We'll definitely catch up with a meeting next
week.

If anyone would like to have a meeting, and is willing to run it in my
place, please just go ahead and send an announcement mail (and, of
course, show up to run the meeting on Monday). Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
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

[Test-Announce] Proposal to CANCEL: 2018-02-12 blocker review meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the blocker review meeting for
Monday. Once again there are no proposed blockers for Beta or Final
at this time, so nothing to talk about. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
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

Re: Escaping macros in %changelog

[David Sommerseth]

On 09/02/18 23:46, Kevin Kofler wrote:
> David Sommerseth wrote:
>> Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge,
>> this is fairly close to what koji does under the hood.  Then you'll have
>> everything tested locally, git tree can be cleaned up and be in a
>> reasonable shape before being pushed out.
> 
> I'm surely not going to build those packages on my computer, that's what we 
> have Koji for!

I doubt Koji was primarily built for "does this work?"-builds.  It exists to
build proper packages targeting Fedora repositories.

>> If you want to make koji run the build, you can also use 'fedpkg build
>> --scratch' and provide an SRPM (generated by 'fedpkg srpm').  This
>> shouldn't need to be git pushed either to work.
> 
> Then I have to waste a build (which wastes my time and Koji's resources) 
> because I'll have to build the last attempt (the one that ends up 
> succeeding) again as an official build later. It also takes extra time to 
> build and upload the SRPM compared to letting Koji compose it from dist-git, 
> which for a large package like qt5-qtwebengine is not negligible either. (I 
> have only so much upload speed on this asymmetric cable broadband 
> connection.)

To me this is backwards and is lacking some logic.  If you push things which
does not build properly, you also waste a build.

And if your build works but there are other non-critical typos, you still
waste a build when you correct that.

Testing builds is critical to ensure your .spec file is properly setup.  If it
happens locally or in a pre-built SRPM sent to koji, is not really that
important.  Here people use what is most convenient to them.

To avoid bandwidth issues I know people (including myself) uses external hosts
with a decent Internet link (you might even get access to some free resources,
especially if targeting special platforms - like the Open Power Hub if doing
POWER8 related stuff [1]).  Use sshfs or similar approaches to a remote server
which is used to update a .spec file from your local host and then use ssh on
that host and do the heavy-lifting there directly.  The bandwidth for a ssh
connection is negligible compared to uploading large srpm packages.  Plus the
koji upload goes fairly fast.

Or you could get a more reasonable and decent Internet connection at home/work
with a better bandwidth.

To me these complaints sounds more like insisting on not adopting to the
reality.  Getting all your expectations covered and expect the Fedora tooling
around to adopt to your expectations just sounds backwards to me.


[1] 

-- 
kind regards,

David Sommerseth



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

Re: Atomic Host/Workstation Interview for Linux Unplugged Podcast

[Chicago]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks, Dusty!
-BEGIN PGP SIGNATURE-

iQI6BAEBCgAkHRxDaGljYWdvIDxjaGljYWdvQGFpcm1haWwuY2M+BQJafjgSAAoJ
ENL3SmB5LsIajfkQALNdt8hFDY0eMoMuneS0mZjpAEnwZGcHRp2dnGrGZUDg0Nu7
QRL8UikK+uGteQy27ybQsXwBfsNGpLNpELgu4ObevjBoqx+D0bSrbp/H3ZkJY861
KXemaX7RSs/iqrcAnr+Um7YWiWqta3VaJ6q2dtQjGNUFoJq2j0icxnkusxZ10szA
HMGCb/TIV4F3FGRVFEzRBtMFWuhH/mZtWWoYaR3OlfwJ3NKizUz/rClYkgJoLEi8
0T3hia6GFNg7WLtHzVmRdMyBImqxGxBnicoenxiQzBMjen6g+hw3FgLyt0hCgR1n
7x1VfOpHZ9+0DqX9lcnC3LuWQoJE+dvoiygNPOhE127fEDUjQTqr/hGs4bYhro4C
EOJ+QVuj2TbAcOYENoz6lGP4+VaWjngc+neD4lVjoAEGSmuCyywTzFM8uMWkryFJ
2TlVYtiHMkV48UjTaM8cpXPpdNCFzu4+I4tiHaf2GeW1Wz+OPtDQNAMC3oKqTK92
F0rDafNO+7BHU+zV1ZcnC5k2mJ2MPs/2rYdVMNhXIR0qNgU0dWqe7JlrBorUwcpM
2UB9fcs5HEASV/z5zTWT1zR0nTj/CoDZwORIMBphBTkS8z12niQymddGoTX63kJ6
rBMAiV3G2NqIGpMa0nocgq7oBAmDiXk/sEmMHqtDdbCHw98eghb4ZxwKleYF
=wvkt
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Kevin Kofler]

David Sommerseth wrote:
> Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge,
> this is fairly close to what koji does under the hood.  Then you'll have
> everything tested locally, git tree can be cleaned up and be in a
> reasonable shape before being pushed out.

I'm surely not going to build those packages on my computer, that's what we 
have Koji for!

> If you want to make koji run the build, you can also use 'fedpkg build
> --scratch' and provide an SRPM (generated by 'fedpkg srpm').  This
> shouldn't need to be git pushed either to work.

Then I have to waste a build (which wastes my time and Koji's resources) 
because I'll have to build the last attempt (the one that ends up 
succeeding) again as an official build later. It also takes extra time to 
build and upload the SRPM compared to letting Koji compose it from dist-git, 
which for a large package like qt5-qtwebengine is not negligible either. (I 
have only so much upload speed on this asymmetric cable broadband 
connection.)

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

Re: Rawhide armv7hl buildroot busted?

[Michael Cronenworth]

On 02/09/2018 03:54 PM, Orion Poplawski wrote:


Well, it doesn't appear to be completely broken as lots of builds are succeeding.  
I think you'll need the contents of config.log to see what is happening here. 


Thanks, Orion.

It was a Wine configure bug. Introduced by:
https://source.winehq.org/git/wine.git/blobdiff/c81de726f2d2555492afd4442a5a8635e64af584..364e04ce0ca011c4bf8087d4982283093766ee56:/configure.ac

I've worked around it for now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[David Sommerseth]

On 09/02/18 23:09, Kevin Kofler wrote:
> Kamil Dudka wrote:
>> Would not it be then better to work on this in a staging branch and rework
>> those commits before they are pushed to a production branch?  I am myself
>> not interested in going through commits like "fix a typo", "forgot to bump
>> release", "add missing BR", "revert the previous revert", etc.
> 
> I have to push them to the right branch so I can build them. Then if it 
> builds, it's fine, but if it's broken, I fix it and try again.

Hi Kevin,

Doesn't 'fedpkg mockbuild' resolve those test builds?  To my knowledge, this
is fairly close to what koji does under the hood.  Then you'll have everything
tested locally, git tree can be cleaned up and be in a reasonable shape before
being pushed out.

If you want to make koji run the build, you can also use 'fedpkg build
--scratch' and provide an SRPM (generated by 'fedpkg srpm').  This shouldn't
need to be git pushed either to work.


Just my 2 cents.


-- 
kind regards,

David Sommerseth



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

Re: inject rpm dependency depending on library symbol?

[Kevin Kofler]

Rex Dieter wrote:
> (I know this would be handled automatically if the Qt_5_PRIVATE_API symbol
> was versioned, but that's an option we'd rather avoid if reasonably
> possible)

IMHO, the right approach is to do just that. There is already a patch that
does this:
https://build.opensuse.org/package/view_file/KDE:Qt:5.9/libqt5-qtbase/tell-the-truth-about-private-api.patch?expand=1
It just needs to be applied in Fedora.

Binary compatibility with upstream is irrelevant here because we are talking
about private APIs only. Any third-party package that notices this at all is
using private APIs and so can already break at any time. Any binaries not
using private APIs will see any difference at all.

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

Re: Escaping macros in %changelog

[Kevin Kofler]

Neal Gompa wrote:
> Mageia, OpenMandriva, and PLD all generate their changelogs from the
> source control system.
[snip]
> SUSE uses the Open Build Service VCS export to changes files which are
> converted into changelog entries at package build time.

All these distros have in common that their changelogs are A LOT less 
readable than ours.

> But yeah, Fedora is once again a laggard. This seems to be a recurring
> trend, and one I'm not particularly pleased about.

Autogenerating RPM changelogs from the SCM has been proposed over and over 
again multiple times. It was always shot down because it just doesn't work. 
Not adopting some particular bad idea does not make us laggards. Can we 
please stop beating this dead horse again and again?

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

Re: Escaping macros in %changelog

[Kevin Kofler]

Kamil Dudka wrote:
> Would not it be then better to work on this in a staging branch and rework
> those commits before they are pushed to a production branch?  I am myself
> not interested in going through commits like "fix a typo", "forgot to bump
> release", "add missing BR", "revert the previous revert", etc.

I have to push them to the right branch so I can build them. Then if it 
builds, it's fine, but if it's broken, I fix it and try again.

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

Atomic Host/Workstation Interview for Linux Unplugged Podcast

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


A couple of us went on the LUP podcast this week to talk about Atomic 
Host/Workstation.

Check it out: https://twitter.com/jupitersignal/status/961283877883977728. We 
start around minute 16:20.

Dusty 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlp+HAcACgkQMwLb1zlS
5nFxmg/+MR/FjNQBwcx9HfhHY25wGlOYLeIaADUJGZNVIKvCoVzDvnfZGEqivsQ2
kKnk2yxYkPwWaJuzUEQDh3WYHlE19Sbb4ABxwexbd4nU1i0vGlLAJrAGVwUoZdcG
zaiAOz6kgBoablDXhBLiZhtjCRi4uXUvqy1iUcWd5KsAGmp4mzHvqPV5LZsr5TdS
nY5LBPi8zd3MQW/3UDg/FVjHIGVYpyhNZiJ2c78vHm5VjAZYlaQMlTqHhzrQOsQe
OZ149lbwvov9plT0K4byp6bdjrW3Ld66Ft799Zw0rhteZEvOyY9qXjvvXATxQwL8
lFA6G+Z7LKcPhBPxK0XhZqy2R/IHYWYuQSilhYOvcDLwCDJpXsuIkqAOE7zmeI5N
2ioLm5UDPHZmtpIg+NKXQzr6LByA/Mi7h1y+j71B2TnwnrG77s7UeIwKxFBelbJb
I30DwOeZB8ON10NjYaF9Y2DC+GxcmtcuU0GjXvnlt0j9SEPmRWnXEcvwxMRwahDP
2x0w/iS1Jl5VLxkj2f0a/F5VuZhRcw8LZyMMQ9dvfIl5qwfOTj550GVQE+B+45c7
gXB61Xwrr0D/A9fQFiAZyBMC7Oi6ElYizmxCY7n4X296T4FP9Ccr779oSP/f+osW
mmTV1o2B1oY4cqvmXPH3G/nHnE9DK0nIJR1NS4V2jBROBuj4umQ=
=3nfn
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen  wrote:

> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>
>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller 
>> wrote:
>>
>>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>>
 It seems that a lot of people have %file, %check, %build, %whatsoever
 in their changelog section.
 Is there any reason I should not go and automatically escape them?

>>>
>>> This seems like a lot of churn. If we're going to do this, let's go big
>>> and get rid of RPM changelogs.
>>>
>>> When we have a package update, there are basically two different kinds
>>> of changelog information. Well, three.
>>>
>>> First, there's the upstream changelog. We don't generally do much with
>>> these except maybe package as %doc.
>>>
>>> Second, there's package maintainer changelogs. These are really
>>> redundant with the dist-git log. We don't really need this anymore.
>>> It's just a chore.
>>>
>>> Third, though, there's end-user information. Why should a user care
>>> *This* is redundant with bodhi update info, at least if packagers fill
>>> that out, and it often also duplicates upstream changelogs, *and* it
>>> often also covers things like "fixes CVE-' also carried the
>>> specfile changelog.
>>>
>>> This is neither most helpful for user *nor* ideal for packages. Why
>>> don't we drop changelogs entirely in favor of 1) using the dist-git
>>> logs for specfile maintainers and 2) providing the end-user information
>>> in a different way. This could be through specially formatted log lines
>>> going with the commit, or it could be simply in a standard separate
>>> file (`fedora.user-visible-changes`). Optionally, it could include both
>>> a high level end-user summary, and a detailed description for sysadmins
>>> and the curious.
>>>
>>> Wherever it lives, this would be read by Bodhi, so there's
>>> would be need to enter it more than once. And, perhaps a DNF plugin
>>> could be made to read and display this information for systems
>>> administrators.
>>>
>>
>> I fully support the removal of RPM changelogs.  However, you've missed
>> two cases:
>>
>> 1) Rawhide, which doesn't go through bodhi
>> 2) Fedora release upgrades, which don't go through bodhi
>>
>> Now, I would actually LOVE for Rawhide to go through bodhi but
>> whatever.  The release -> release upgrade isn't really solvable that
>> way though.
>>
>> Someone else suggested changelogs could be inserted during koji build
>> time.  That would be interesting to look into.
>>
>
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.
>

I actually looked yesterday if I could make a PR for rpm implementing it
but I couldn't really find a good way to do it. So I decided to implement it
in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor -
basically a hack upon python-rpkg library) by spec preprocessing. So,
with that development version of rpkg, you can have specs (or rather spec
templates) like this in your Git project:

Name:   {{{ git_name }}}
Version:{{{ git_version }}}
Release:1%{?dist}
Summary:This is a test package.

License:GPLv2+
URL:https://someurl.org

Source: {{{ make_source }}}

%description
This is a test package.

%prep
{{{ setup }}}

{{{ git_change_log }}}

rpkg will take that spec template and replace the {{{ ... }}} tags with
standard output of the commands inside the braces (git_name, git_version,
make_source, setup, git_change_log are all shell functions). Afterwards,
the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
command).

I haven't actually implemented the `git_change_log` function yet (nor the
other functions except for `make_source`) like Igor did - currently it just
always returns '%changelog' and that's it but I wanted to show this to
possibly get some feedback.

Thank you
clime


>
> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>
> - Panu -
>
> ___
> 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: Rawhide armv7hl buildroot busted?

[Orion Poplawski]

On 02/09/2018 12:33 PM, Michael Cronenworth wrote:
I've tried two builds over the past couple hours that result in 
failures. Other architectures are building.


Is there something wrong in glibc/gcc/makefile for armv7hl?

build.log
https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/build.log

root.log
https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/root.log


Well, it doesn't appear to be completely broken as lots of builds are 
succeeding.  I think you'll need the contents of config.log to see what 
is happening here.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide armv7hl buildroot busted?

[Michael Cronenworth]

On 02/09/2018 02:19 PM, Peter Robinson wrote:

You need to reference the root task, it's hard to get back to that
from the .log files, and it allows people to see other things that
isn't just pure logs which are useful for debug.


The task ID is in the URL.

https://kojipkgs.fedoraproject.org//work/tasks/408/*24900408*/build.log

https://koji.fedoraproject.org/koji/taskinfo?taskID=24900408

From there you can get the root task.

https://koji.fedoraproject.org/koji/taskinfo?taskID=24900395
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: inject rpm dependency depending on library symbol?

[Tomasz Kłoczko]

On 9 February 2018 at 15:33, Rex Dieter  wrote:

> I'm exploring possibilities on how to track usage of a particular library
> symbol via rpm dependencies.
>
> In particular, whenever a package is built that includes a dependency on
> library symbol:
> libQt5Core.so.5(Qt_5_PRIVATE_API)
>
> I'd like to inject additional dependencies, something like:
> Requires: qt5-qtbase = %{_qt5_version}
>
> I've been told debian does a variant of this, but I've not been able to
> come
> up with any good way to do that here.  Any ideas or suggestions?
>

You know it is some old joke about colonist and locals in North America.
It was late autumn and one of the colonist spotted some local guy
collecting sticks. He was born in the city so he never saw someone
collecting sticks.
When he back to the colony he was so excited that he told what he saw to
his friends. They started scratching own heads and after discussion
colonist come to the conclusions that probably locals knows that winter
will be harsh so they need to spend more time to collect more heavy logs to
survive coming winter.
When locals spotted this they organized local tribe elders meeting to
discuss what colonist are doing. Because they knew colonists only few
months and they've already saw many amazing things they come to the
conclusion that colonist probably somehow knows that this winter will be
harsh so they decided to spend more time to collect more wood before coming
winter as well.

Doing something only because someone is doing something without
understanding why it is done is really bad way.
Try to add to this picture that current SONAME dependency generator
currently used for more then decade with only small cleanups.
So far no one found any issue with current generator so please do not waste
your time implement something to mimic something.

Engineering is not about assuming something and you just assumed that this
type of additional dependencies is fixing some unknown problem,
Do not try to fix *possible* problems but only those *already known* as
well (and list of those problems is reaaaly long).
If you want still dig around this hole just try to talk with Debian guys
and ask then why they are doing this.

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: Rawhide armv7hl buildroot busted?

[Peter Robinson]

On Fri, Feb 9, 2018 at 7:33 PM, Michael Cronenworth  wrote:
> I've tried two builds over the past couple hours that result in failures.
> Other architectures are building.

You need to reference the root task, it's hard to get back to that
from the .log files, and it allows people to see other things that
isn't just pure logs which are useful for debug.

> Is there something wrong in glibc/gcc/makefile for armv7hl?
>
> build.log
> https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/build.log
>
> root.log
> https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/root.log
> ___
> 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

Rawhide armv7hl buildroot busted?

[Michael Cronenworth]

I've tried two builds over the past couple hours that result in failures. Other 
architectures are building.


Is there something wrong in glibc/gcc/makefile for armv7hl?

build.log
https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/build.log

root.log
https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/root.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Package review - test builds for OpenVPN 3 Client

[David Sommerseth]

Hi,

This week I've started poking at packaging pre-release builds of the new
OpenVPN 3 based client for Linux (sorry, no server support yet).  I've started
a Copr build/repo for it and I'd appreciate some help reviewing the packaging
and otherwise hints (or pathces) how to improve things.

You'll find everything here:


Now, beware that this client is still under heavy development and is not ready
for a full release yet.  Once lacking features and the most critical or
annoying bugs are sorted out, we'll tag the first beta release.

Since it is under heavy development ... it is not ready for production yet.
But I have enabled it on a server, to test the long-term stability of it.

And a final warning ... This client is _very_ _different_ from the far more
common openvpn-2.x series.  It is different in almost every aspect.  The only
thing they have in common is that the OpenVPN wire protocol is essentially the
same and compatible (it can connect to OpenVPN 2.x servers) and the
configuration files will in most cases work just fine (as long as unsupported
options in OpenVPN 3 is not used).

If you have any questions or comments, feel free to reach out!


-- 
kind regards,

David Sommerseth
OpenVPN Inc




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

Outage: Switch Outage - 2018-02-11 15:00 UTC

[Stephen John Smoogen]

There will be an outage starting at 2018-02-11 15:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2018-02-11 15:00 UTC'

Reason for outage:  The network switches in our PHX2 colocation
require a firmware upgrade to deal with false overheating problems.
The updates should be short 5 to 10 minute disruptions per switch.

Affected Services:

Bodhi - https://admin.fedoraproject.org/updates/
Buildsystem - http://koji.fedoraproject.org/
GIT / Source Control
Docs - https://docs.fedoraproject.org/
Email system
Fedora Account System - https://admin.fedoraproject.org/accounts/
Fedora Community - https://admin.fedoraproject.org/community/
Fedora People - https://fedorapeople.org/
Main Website - https://fedoraproject.org/
Mirror Manager - https://admin.fedoraproject.org/mirrormanager/
Package Database - https://admin.fedoraproject.org/pkgdb/
QA Services
Secondary Architectures
Spins - https://spins.fedoraproject.org/
Translation Services - https://translate.fedoraproject.org/
Wiki - https://fedoraproject.org/wiki/

Unaffected Services:
Torrent - https://torrent.fedoraproject.org/
Mirror List - https://mirrors.fedoraproject.org/
Start - https://start.fedoraproject.org/

Ticket Link:

Contact Information:

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.


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

Re: Escaping macros in %changelog

[Jonathan Wakely]

On 09/02/18 16:53 +, Jonathan Wakely wrote:

On 09/02/18 08:34 -0500, Josh Boyer wrote:

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


If a koji build page just showed the Git commit logs since the last
build that could be far more useful than showing hundreds of lines of
the %changelog from the spec file. I could hit 'End' on my keyboard to
jump to the bottom of a koji page to see the changes.

Try finding the changelog entry for the new build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1029927

The bottom of the page shows a change from "Tue May 06 2003" (not very
relevant to a recent koji build) and the top of the page shows
hundreds of RPMs that I need to scroll past before the changelog
starts.


But a #changelog anchor would also solve that specific problem :-)

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

Re: Escaping macros in %changelog

[Jonathan Wakely]

On 09/02/18 08:34 -0500, Josh Boyer wrote:

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


If a koji build page just showed the Git commit logs since the last
build that could be far more useful than showing hundreds of lines of
the %changelog from the spec file. I could hit 'End' on my keyboard to
jump to the bottom of a koji page to see the changes.

Try finding the changelog entry for the new build here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1029927

The bottom of the page shows a change from "Tue May 06 2003" (not very
relevant to a recent koji build) and the top of the page shows
hundreds of RPMs that I need to scroll past before the changelog
starts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-02-08 at 13:32 -0500, Matthew Miller wrote:
> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> > It seems that a lot of people have %file, %check, %build, %whatsoever
> > in their changelog section.
> > Is there any reason I should not go and automatically escape them?
> 
> This seems like a lot of churn. If we're going to do this, let's go big
> and get rid of RPM changelogs. 
> 
> When we have a package update, there are basically two different kinds
> of changelog information. Well, three.
> 
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
> 
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.

So I've spent a bit of time and created git-rpm-changelog[0]. RFEs, Issues and
PRs are very welcome 😉

Once I will get it working very fast and reliable, I will try to make it part
of packaging process.. Somehow...


[0] https://github.com/ignatenkobrain/git-rpm-changelog
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9y3sACgkQaVcUvRu8
X0xDTxAAuJYSQFA8sIsFoLytUWyEca13z4dWFutsLA14T93/nRkH7/6sf92hqzDt
2ZEWDU3uS8GKe4Xi9t4Obcv9EAbC5ynx4Iu/fHUE83AEiySX8ihndeRyzKhW3zqB
ic/FUjJ5R9sdPMbc4m8LeAasOKgux3KxE57bcfJ5f6KpofVGn1aDZ35sKegox+5G
ZKlfTvutDRgiPjdrlFJEI83DVAqortpO7w4+Wip8JZqvd2EKuMwM34ZxW7S5KsSl
7v+QagenAGqc+hNVKfA9TPl1I8HCgppIphvJ+arS+rNiMJ1ACo4z2hvUx9jr8h7q
e8r26QtcL3U3Ccz/hlzzsWMDYjd195EPjWT4TOU3+t19rsIyuHlqLZUE+H9HVlFk
6cQhsXgsSEDjqrlxyZxh8czzhB5M7emN6I5KhrovHlnq7fzzq/WXF4irNBePmbSk
Tr7AlpGOhBbgrYexjK7xlMzguUvhE5kHHV8zU8pfNRT4F37jnwAezcKzbF7r4jkk
jrL/TxrUEh4N/l/R2JowWeuj17XXsgurNY+JWmu0jPqZtu+78I1AsPnTFjK3Dhwb
v+79osXQr2et9BKBr+APCnaGXaI/lNTfdPFLJVWAHBIvILjtPXbtSkxaDWnbmKxf
yqyGJqUNX8pJEzu+ghDKHDW19WO8PLkM77lQaPV9bZkqQoigxFE=
=5YnU
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: vdr-epg-daemon-1.1.128 compiles fine on f26 but not on higher fedora version

[Jonathan Wakely]

On 09/02/18 15:01 -, Martin Gansser wrote:

Hi,

vdr-epg-daemon-1.1.128 compiles fine on f26 but not on higher fedora version,
something changed on F27 and rawhide, program


make[1]: Entering directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.128/epglv'
gcc -c -I/usr/include/mysql -fPIC -L/usr/lib64/mysql -L/usr/lib64/ -lmariadb 
-lz -lm -lpthread -lssl -lcrypto -DMYSQL_DYNAMIC_PLUGIN -DDEBUG_MYSQL=0 -ggdb 
-fno-
stack-protector -O -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-
gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c++11 
-D__STDC_FORMAT_MACROS
-shared src/epglvbase.c -o src/epglvbase.o
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++ but not 
for C
In file included from src/epglv.h:16:0,
from src/epglvbase.c:10:
/usr/include/mysql/my_global.h:3:2: warning: #warning This file should not be 
included by clients, include only  [-Wcpp]
#warning This file should not be included by clients, include only 
 ^~~


This suggests the package is not using the mariadb API correctly, and
should be including a different header.


In file included from src/epglv.h:17:0,
from src/epglvbase.c:10:
/usr/include/mysql/my_sys.h:3:2: warning: #warning This file should not be included 
by clients, include only  [-Wcpp]
#warning This file should not be included by clients, include only 
 ^~~
In file included from src/epglvbase.c:10:0:
src/epglv.h:21:10: fatal error: m_ctype.h: No such file or directory
#include 
 ^~~


And this is probably for the same reason:  is not part of
the public API for mariadb clients.

Did you try replacing  and  and 
with  ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: inject rpm dependency depending on library symbol?

[Rex Dieter]

Neal Gompa wrote:

> On Fri, Feb 9, 2018 at 10:33 AM, Rex Dieter  wrote:
>> I'm exploring possibilities on how to track usage of a particular library
>> symbol via rpm dependencies.
>>
>> In particular, whenever a package is built that includes a dependency on
>> library symbol:
>> libQt5Core.so.5(Qt_5_PRIVATE_API)
>>
>> I'd like to inject additional dependencies, something like:
>> Requires: qt5-qtbase = %{_qt5_version}
>>
>> I've been told debian does a variant of this, but I've not been able to
>> come
>> up with any good way to do that here.  Any ideas or suggestions?
>>
>>
>> (I know this would be handled automatically if the Qt_5_PRIVATE_API
>> symbol was versioned, but that's an option we'd rather avoid if
>> reasonably possible)
> 
> You can write a dependency generator that would call a script that
> executes rpmdeps the same way as the real generator does. If it's
> detected, you can have it emit that dependency back as a Requires.

Can you be a little more specific?

In particular, I'm not interested in re-inventing any wheels here.  I 
included the phrase "reasonably possible" intentionally.

-- Rex

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

Re: inject rpm dependency depending on library symbol?

[Neal Gompa]

On Fri, Feb 9, 2018 at 10:33 AM, Rex Dieter  wrote:
> I'm exploring possibilities on how to track usage of a particular library
> symbol via rpm dependencies.
>
> In particular, whenever a package is built that includes a dependency on
> library symbol:
> libQt5Core.so.5(Qt_5_PRIVATE_API)
>
> I'd like to inject additional dependencies, something like:
> Requires: qt5-qtbase = %{_qt5_version}
>
> I've been told debian does a variant of this, but I've not been able to come
> up with any good way to do that here.  Any ideas or suggestions?
>
>
> (I know this would be handled automatically if the Qt_5_PRIVATE_API symbol
> was versioned, but that's an option we'd rather avoid if reasonably
> possible)

You can write a dependency generator that would call a script that
executes rpmdeps the same way as the real generator does. If it's
detected, you can have it emit that dependency back as a Requires.


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

inject rpm dependency depending on library symbol?

[Rex Dieter]

I'm exploring possibilities on how to track usage of a particular library 
symbol via rpm dependencies.

In particular, whenever a package is built that includes a dependency on 
library symbol:
libQt5Core.so.5(Qt_5_PRIVATE_API)

I'd like to inject additional dependencies, something like:
Requires: qt5-qtbase = %{_qt5_version}

I've been told debian does a variant of this, but I've not been able to come 
up with any good way to do that here.  Any ideas or suggestions?


(I know this would be handled automatically if the Qt_5_PRIVATE_API symbol 
was versioned, but that's an option we'd rather avoid if reasonably 
possible)

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

Was APLM accidently enabled in Fedora 27?

[Clemens Eisserer]

Hi,

Since a week or so my laptop has severe SATA issues when running on
battery-only.

Was APLM enabled by accident in Fedora-27 (I know there are currently
experiments going on for Rawhide / F28):
https://bugzilla.redhat.com/show_bug.cgi?id=1543493

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

vdr-epg-daemon-1.1.128 compiles fine on f26 but not on higher fedora version

[Martin Gansser]

Hi,

vdr-epg-daemon-1.1.128 compiles fine on f26 but not on higher fedora version,
something changed on F27 and rawhide, program


make[1]: Entering directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.128/epglv'
gcc -c -I/usr/include/mysql -fPIC -L/usr/lib64/mysql -L/usr/lib64/ -lmariadb 
-lz -lm -lpthread -lssl -lcrypto -DMYSQL_DYNAMIC_PLUGIN -DDEBUG_MYSQL=0 -ggdb 
-fno-
stack-protector -O -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-
gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c++11 
-D__STDC_FORMAT_MACROS 
-shared src/epglvbase.c -o src/epglvbase.o
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++ but not 
for C
In file included from src/epglv.h:16:0,
 from src/epglvbase.c:10:
/usr/include/mysql/my_global.h:3:2: warning: #warning This file should not be 
included by clients, include only  [-Wcpp]
 #warning This file should not be included by clients, include only 
  ^~~
In file included from src/epglv.h:17:0,
 from src/epglvbase.c:10:
/usr/include/mysql/my_sys.h:3:2: warning: #warning This file should not be 
included by clients, include only  [-Wcpp]
 #warning This file should not be included by clients, include only 
  ^~~
In file included from src/epglvbase.c:10:0:
src/epglv.h:21:10: fatal error: m_ctype.h: No such file or directory
 #include 
  ^~~
compilation terminated.
make[1]: *** [Makefile:51: src/epglvbase.o] Error 1
make[1]: Leaving directory 
'/home/martin/rpmbuild/BUILD/vdr-epg-daemon-1.1.128/epglv'
make: *** [Makefile:77: lv] Error 2
make: *** Waiting for unfinished jobs
g++ -shared epgdata.o  -o libepgd-epgdata.so


results compiling the program on different versions:

koji build --scratch f26 ../SRPMS/vdr-epg-daemon-1.1.128-1.fc26.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=24890318

koji build --scratch f27 ../SRPMS/vdr-epg-daemon-1.1.128-1.fc26.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=24890368

koji build --scratch rawhide ../SRPMS/vdr-epg-daemon-1.1.128-1.fc26.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=24890169
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Jakub Jelinek]

On Fri, Feb 09, 2018 at 03:55:26PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 09 February 2018 at 09:50, Jakub Jelinek wrote:
> > On Fri, Feb 09, 2018 at 09:48:30AM +0100, Rafal Luzynski wrote:
> > > 9.02.2018 08:41 Kevin Kofler  wrote:
> > > >
> > > >
> > > > Rafal Luzynski wrote:
> > > > > Requires: libstdc++.so.6
> > > >
> > > > That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit 
> > > > multilib
> > > > architectures though.
> > > 
> > > I know and this was going to be my next question: what magic
> > > operator to use to generate the correct form for all architectures?
> > > Or maybe there is no such operator and I should use some %if ... %else
> > > to detect 32bit/64bit/multiarch?
> > 
> > I believe there is none and in the compat-gcc-34 I've built yesterday I'm
> > using %ifarch.
> 
> I think it's better to use something like:
> 
> %if %__isa_bits == 64
> %global dep_suffix ()(64bit)
> %endif
> Requires: libstdc++.so.6%{?dep_suffix}

It is not, because not all 64-bit rpm arches use the (64bit) suffix,
e.g. alpha does not.

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

Re: Pull requests for compat-gcc-34

[Dominik 'Rathann' Mierzejewski]

On Friday, 09 February 2018 at 09:50, Jakub Jelinek wrote:
> On Fri, Feb 09, 2018 at 09:48:30AM +0100, Rafal Luzynski wrote:
> > 9.02.2018 08:41 Kevin Kofler  wrote:
> > >
> > >
> > > Rafal Luzynski wrote:
> > > > Requires: libstdc++.so.6
> > >
> > > That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit 
> > > multilib
> > > architectures though.
> > 
> > I know and this was going to be my next question: what magic
> > operator to use to generate the correct form for all architectures?
> > Or maybe there is no such operator and I should use some %if ... %else
> > to detect 32bit/64bit/multiarch?
> 
> I believe there is none and in the compat-gcc-34 I've built yesterday I'm
> using %ifarch.

I think it's better to use something like:

%if %__isa_bits == 64
%global dep_suffix ()(64bit)
%endif
Requires: libstdc++.so.6%{?dep_suffix}

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Neal Gompa]

On Fri, Feb 9, 2018 at 9:22 AM, Panu Matilainen  wrote:
>
>
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.
>
> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>

Mageia, OpenMandriva, and PLD all generate their changelogs from the
source control system.

Mageia does it with SVN, while OpenMandriva and PLD do it from Git.

Mageia's build system calls "mgarepo rpmlog " and appends it
to the spec file just before starting the package build. mgarepo has a
number of rules for excluding messages from generated changelog
entries, which is how they don't look extremely awful.

OpenMandriva's build system (ABF) does something similar, though it's
been switched off for a while due to it being somewhat slow (they
don't have a lot of build system resources anymore). I'm not aware of
the exact process used by PLD, but they do something similar.

SUSE uses the Open Build Service VCS export to changes files which are
converted into changelog entries at package build time. The changes
files are managed independently, so the function more or less like how
ours does, but some packages also dynamically generate changes entries
based on source VCS information (some openSUSE developed packages have
changes generated from upstream project Git information, for example).

When using a VCS for generating changelogs, you need to enforce some
rules for how to omit or include entries.

In our case, we'd probably want a rule that would make such a thing
actually include the commit message and omit them otherwise, since
unlike the other distributions, we can't rewrite our commit messages
(because Koji builds are tightly associated with commit messages). SVN
disassociates revision from revision message, and OMV and PLD let you
rewrite commits freely. We'd also need a way to "correct" generated
entries when they have errors in them.

But yeah, Fedora is once again a laggard. This seems to be a recurring
trend, and one I'm not particularly pleased about.

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

Re: Escaping macros in %changelog

[Panu Matilainen]

On 02/09/2018 03:34 PM, Josh Boyer wrote:

On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  wrote:

On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:

It seems that a lot of people have %file, %check, %build, %whatsoever
in their changelog section.
Is there any reason I should not go and automatically escape them?


This seems like a lot of churn. If we're going to do this, let's go big
and get rid of RPM changelogs.

When we have a package update, there are basically two different kinds
of changelog information. Well, three.

First, there's the upstream changelog. We don't generally do much with
these except maybe package as %doc.

Second, there's package maintainer changelogs. These are really
redundant with the dist-git log. We don't really need this anymore.
It's just a chore.

Third, though, there's end-user information. Why should a user care
*This* is redundant with bodhi update info, at least if packagers fill
that out, and it often also duplicates upstream changelogs, *and* it
often also covers things like "fixes CVE-' also carried the
specfile changelog.

This is neither most helpful for user *nor* ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.

Wherever it lives, this would be read by Bodhi, so there's
would be need to enter it more than once. And, perhaps a DNF plugin
could be made to read and display this information for systems
administrators.


I fully support the removal of RPM changelogs.  However, you've missed
two cases:

1) Rawhide, which doesn't go through bodhi
2) Fedora release upgrades, which don't go through bodhi

Now, I would actually LOVE for Rawhide to go through bodhi but
whatever.  The release -> release upgrade isn't really solvable that
way though.

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.


Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly 
rocket science we're talking about here if people are ready to give it a go.


Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM 
already? Do you know what kind of hook they're using? Actually I think 
Suse does this too so Fedora is probably again the last one to adopt this...


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

Re: Escaping macros in %changelog

[Josh Boyer]

On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  wrote:
> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>> It seems that a lot of people have %file, %check, %build, %whatsoever
>> in their changelog section.
>> Is there any reason I should not go and automatically escape them?
>
> This seems like a lot of churn. If we're going to do this, let's go big
> and get rid of RPM changelogs.
>
> When we have a package update, there are basically two different kinds
> of changelog information. Well, three.
>
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
>
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.
>
> Third, though, there's end-user information. Why should a user care
> *This* is redundant with bodhi update info, at least if packagers fill
> that out, and it often also duplicates upstream changelogs, *and* it
> often also covers things like "fixes CVE-' also carried the
> specfile changelog.
>
> This is neither most helpful for user *nor* ideal for packages. Why
> don't we drop changelogs entirely in favor of 1) using the dist-git
> logs for specfile maintainers and 2) providing the end-user information
> in a different way. This could be through specially formatted log lines
> going with the commit, or it could be simply in a standard separate
> file (`fedora.user-visible-changes`). Optionally, it could include both
> a high level end-user summary, and a detailed description for sysadmins
> and the curious.
>
> Wherever it lives, this would be read by Bodhi, so there's
> would be need to enter it more than once. And, perhaps a DNF plugin
> could be made to read and display this information for systems
> administrators.

I fully support the removal of RPM changelogs.  However, you've missed
two cases:

1) Rawhide, which doesn't go through bodhi
2) Fedora release upgrades, which don't go through bodhi

Now, I would actually LOVE for Rawhide to go through bodhi but
whatever.  The release -> release upgrade isn't really solvable that
way though.

Someone else suggested changelogs could be inserted during koji build
time.  That would be interesting to look into.

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

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 09:50 Jakub Jelinek  wrote:
> On Fri, Feb 09, 2018 at 09:48:30AM +0100, Rafal Luzynski wrote:
> > 9.02.2018 08:41 Kevin Kofler  wrote:
> > >
> > >
> > > Rafal Luzynski wrote:
> > > > Requires: libstdc++.so.6
> > >
> > > That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit
> > > multilib
> > > architectures though.
> >
> > I know and this was going to be my next question: what magic
> > operator to use to generate the correct form for all architectures?
> > Or maybe there is no such operator and I should use some %if ... %else
> > to detect 32bit/64bit/multiarch?
>
> I believe there is none and in the compat-gcc-34 I've built yesterday I'm
> using %ifarch.

Sorry, I did not notice you built yesterday. That's nice!

Please:
- backport the solution to F26 and F27 as well, this should be much
  easier than in F28 (my pull requests may be helpful),
- mark my pull requests as merged/obsolete/whatever is appropriate,
- mark the bugzilla tickets as fixed (hopefully this is automatic).

Regards,

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

Re: Escaping macros in %changelog

[Vít Ondruch]

Dne 9.2.2018 v 09:21 Kevin Kofler napsal(a):
> Matthew Miller wrote:
>> Second, there's package maintainer changelogs. These are really
>> redundant with the dist-git log. We don't really need this anymore.
>> It's just a chore.
> My %changelog entries are not identical to the dist-git commit messages:
>
> 1. It often takes me several git commits to make a new EVR that builds.
>Also, typos in commit messages cannot be fixed. (Both of those issues
>could be solved if we were to allow force pushes to dist-git, but that
>would open a much bigger can of worms, as you certainly know.)
>
> 2. Most of my git commit messages are of the form:
>
>one-line summary
>
>full copy&paste of the RPM changelog entry, including the line with date,
>author and EVR.
>
>(The only ones that deviate from that format are followup fixup commits
>as per point 1.) If you are going to generate RPM changelogs from those
>commit messages, they will look really messy, with the date-author-EVR
>line duplicated.
>
> 3. Some of my commit messages contain additional notes that are not intended
>for the package changelog. (Typically a full paragraph of explanatory
>text.)
>
> Thus, I think autogenerating the %changelog from dist-git commit messages 
> would degrade its quality a lot, at least for my packages.

This doesn't mean it could not work. There are, for example, well
established [skip ci] marks [1] used to skip CI for minor changes. We
could have something similar such as [skip changelog], or something of
opposite meaning to include just some specific part of commit message.

In the end it would save you at least the "full copy&paste of the RPM
changelog entry, including the line with date,   author and EVR." work.

BTW I assume you know "fedpkg clog" and "git commit -F clog" to save you
copy&pasting ;)

Vít


[1] https://www.google.cz/search?q=skip+ci

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

Re: Escaping macros in %changelog

[Kamil Dudka]

On Friday, February 9, 2018 9:21:27 AM CET Kevin Kofler wrote:
> Matthew Miller wrote:
> 
> > Second, there's package maintainer changelogs. These are really
> > redundant with the dist-git log. We don't really need this anymore.
> > It's just a chore.
> 
> 
> My %changelog entries are not identical to the dist-git commit messages:
> 
> 1. It often takes me several git commits to make a new EVR that builds.

Would not it be then better to work on this in a staging branch and rework 
those commits before they are pushed to a production branch?  I am myself
not interested in going through commits like "fix a typo", "forgot to bump 
release", "add missing BR", "revert the previous revert", etc.

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

unresponsive maintainer 'jamatos'

[Zbigniew Jędrzejewski-Szmek]

Hi José,

are you still around? You activity suddenly stops around May 28th
2017, I hope nothing serious happened.

grace package needs attention:
https://bugzilla.redhat.com/show_bug.cgi?id=1471223,
https://bugzilla.redhat.com/show_bug.cgi?id=1517243.

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

Re: [HEADS UP] Mass-macro-escape in %changelog

[Zdenek Dohnal]

> zdohnal    cups-filters net-tools system-config-printer
I checked system-config-printer and there are only '% ' and '%,' in
changelog, which aren't rpm macros. Others are escaped in changelog, no
need to fixing it.

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C




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

Re: Clean up your spec files

[Panu Matilainen]

On 02/08/2018 04:53 PM, Neal Gompa wrote:

On Thu, Feb 8, 2018 at 9:49 AM, Brett Lentz  wrote:

On 08/02/18 14:09 +0100, Miroslav Suchý wrote:



* rm -rf $RPM_BUILD_ROOT



rpmdev-newspec still inserts this. It may be worthwhile to file a bug to get
it to stop.



The only reason I haven't dropped it yet is because SLE 11 still is
supported, and it requires it.


Does it, really? IIRC Suse started doing this long long before we did - 
we basically copied it from them:


%__spec_install_pre %{___build_pre}\
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
mkdir -p `dirname "$RPM_BUILD_ROOT"`\
mkdir "$RPM_BUILD_ROOT"\
%{nil}




I could see into adding some magic into removing it when newer rpm is
detected, but I'm not sure it's worth it for a single line.


That single line is not just entirely harmless junk, it inserts an 
insecurity into the picture which the above _install_pre snippet fixes, 
and adding sections that might not even be needed can have other 
unwanted side-effects, witness 
https://bugzilla.redhat.com/show_bug.cgi?id=1542743 where a package 
actually fails to build because there's a bogus/redundant %install 
section containing that one line.


So please, remove it. If SLE 11 really requires it then handle it that 
old dog specially. It is worth it.


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

Re: [HEADS UP] Mass-macro-escape in %changelog

[Ralf Corsepius]

On 02/09/2018 09:18 AM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've went and fixed 493 packages (listed below). If it broke something, please
let me know. I checked diff briefly and don't think that I broke anything…


Did you ask FESCO? If not you, have abused your Fedora privileges, 
IMNSHO to play down a long unfixed *bug* in rpm.


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

Re: Attempting to contact unresponsive maintainers - xing, noriko, aortega, jcholast, mzatko

[Silvia Sánchez]

Hi,

I know Noriko, I can contact her if you want. I think she retired from the
project for personal, but I can ask her.

Regards,
Silvia
FAS:  Lailah



On 7 February 2018 at 19:27, Kevin Fenzi  wrote:

> Greetings, we've been told that the email addresses for these package
> maintainers are no longer valid. I'm starting the unresponsive
> maintainer policy to find out if they are still interested in
> maintaining their packages (and if so, have them update their email
> addresses in FAS).
>
> If they're not interested in maintaining or we can't locate them in 1
> week, I'll have FESCo orphan the packages so that others can take them
> over.
>
> If you have a way to contact these maintainers, please let them know
> that we'd appreciate knowing what to do with their packages. Thanks!
>
> xing:
>
>   https://src.fedoraproject.org/user/xning
>
>   Projects:
>
>   https://src.fedoraproject.org/rpms/perl-Pod-Plainer [product: Fedora]
>
> noriko:
>
>   Projects:
>
>   translation-quick-start-guide [product: Fedora Documentation]
>   Japanese [ja] [product: Fedora Localization]
>
> aortega:
>
>   Projects:
>
>   qpidpy [product: Fedora]
>
>   qpidrb [product: Fedora]
>
> jcholast:
>
>   https://src.fedoraproject.org/user/jcholast
>
>   Projects:
>
>   peervpn [product: Fedora]
>
> mzatko:
>
>   https://src.fedoraproject.org/user/mzatko
>
>   Projects:
>
>   arandr [product: Fedora]
>   rubygem-slim [product: Fedora]
>   rubygem-awesome_print [product: Fedora]
>   rubygem-colored [product: Fedora]
>   arm-none-eabi-gdb [product: Fedora]
>
> kevin
>
>
> ___
> 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: Pull requests for compat-gcc-34

[Jakub Jelinek]

On Fri, Feb 09, 2018 at 09:48:30AM +0100, Rafal Luzynski wrote:
> 9.02.2018 08:41 Kevin Kofler  wrote:
> >
> >
> > Rafal Luzynski wrote:
> > > Requires: libstdc++.so.6
> >
> > That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit multilib
> > architectures though.
> 
> I know and this was going to be my next question: what magic
> operator to use to generate the correct form for all architectures?
> Or maybe there is no such operator and I should use some %if ... %else
> to detect 32bit/64bit/multiarch?

I believe there is none and in the compat-gcc-34 I've built yesterday I'm
using %ifarch.

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

Re: Pull requests for compat-gcc-34

[Rafal Luzynski]

9.02.2018 08:41 Kevin Kofler  wrote:
>
>
> Rafal Luzynski wrote:
> > Requires: libstdc++.so.6
>
> That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit multilib
> architectures though.

I know and this was going to be my next question: what magic
operator to use to generate the correct form for all architectures?
Or maybe there is no such operator and I should use some %if ... %else
to detect 32bit/64bit/multiarch?

Regards,

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

Re: Escaping macros in %changelog

[Pavel Raiskup]

On Friday, February 9, 2018 9:25:33 AM CET Igor Gnatenko wrote:
> On Fri, 2018-02-09 at 08:57 +0100, Pavel Raiskup wrote:
> > On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
> > > Hello everyone,
> > >
> > > It seems that a lot of people have %file, %check, %build, %whatsoever in
> > > their
> > > changelog section.
> > >
> > > Is there any reason I should not go and automatically escape them?
> >
> > There's IMO no good reason why you should.
> >
> > I wouldn't use proven packager rights if the package builds fine.  Fill a
> > pull request if anything.
> 
> Then I have doubts that %changelog means anything

It means something but it is not that important to not ship such package.

> because whoever uses rpm -- changelog would see unexpanded macro so if
> you had %autosetup -p1 in there, users would see real commands
> instead... And also it might break in some cases which requires
> maintainer intervention.

I only said why I wouldn't use _my_ provenpackager powers for innocent
issues.

> Also I don't see reason why I should send PR for ~500 packages where most of 
> it
> won't be merged ever. And this will create much more problems for me to track
> this issue rather than just going and fixing all of them.

Though it only delayed (lowered priority of) the real solution ...

> > E.g. server-side git hook refusing commits "adding typos" into changelog
> > would solve it once and forever.  If you were able to implement some
> > systematic change like this then I would excuse the walk across all the
> > spec files to fix old issues..
> 
> https://pagure.io/releng/issue/7300

.. like this.  Thanks!

Pavel


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

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

[nicolas . mailhot]

- Mail original -
De: "Terry Barnaby" 

>If 
>it was important to get the data to disk it would have been using 
>fsync(), FS sync, or some other transaction based app

??? Many people use NFS NAS because doing RAID+Backup on every client is too 
expensive. So yes, they *are* using NFS because it is important to get the data 
to disk.

Regards,

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

Re: Escaping macros in %changelog

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-02-09 at 08:57 +0100, Pavel Raiskup wrote:
> On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote:
> > Hello everyone,
> > 
> > It seems that a lot of people have %file, %check, %build, %whatsoever in
> > their
> > changelog section.
> > 
> > Is there any reason I should not go and automatically escape them?
> 
> There's IMO no good reason why you should.
> 
> I wouldn't use proven packager rights if the package builds fine.  Fill a
> pull request if anything.

Then I have doubts that %changelog means anything because whoever uses rpm --
changelog would see unexpanded macro so if you had %autosetup -p1 in there,
users would see real commands instead... And also it might break in some cases
which requires maintainer intervention.

Also I don't see reason why I should send PR for ~500 packages where most of it
won't be merged ever. And this will create much more problems for me to track
this issue rather than just going and fixing all of them.

> One could admit that fixing similar typos (white space issues, spelling
> issues, changelog date issues, ...) is OK if you are touching the spec
> file anyway because of some real problems, but even then you make the
> patch less readable - and thus you raise chances that something get's
> overlooked.  So I wouldn't do that.
> 
> > %check → %%check
> > %build → %%build
> > %whatsoever → %%whatsoever
> > 
> > There might be valid use-cases, but I'm not sure if they really are:
> > %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> > 
> > Thoughts?
> 
> E.g. server-side git hook refusing commits "adding typos" into changelog
> would solve it once and forever.  If you were able to implement some
> systematic change like this then I would excuse the walk across all the
> spec files to fix old issues..

https://pagure.io/releng/issue/7300
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9Wv0ACgkQaVcUvRu8
X0wgEg/+K6D6X+LtU6WG9wO2uLl8vhx0KjxhHGMKJmp6Fwd6OZ1ZsIXd0su0veuA
CuGRxu6nphmGPg5ElwR+J1jdz4hBK/Hwqju1XZNNCgg56vLrA8OPVFzLlKoBPfqF
YDYfkh91AouECRdowwCeLfUS6pgOFZSlhdptrEusxSBcToL9HtwIf3AtOpUmIi+c
mBZ4TBWmt+4ik12tLR4Up7+n5a/dichEOx3Loq7RFPEOfjvBhudU/MZpn1b0Kf/P
vN8ocKoKbMvuHotHvBvp/j4BhsTIphvXr7Yg7DFItOTu18wfE+xr0DjWr3RZjxjF
bUIUJX4V9SRZHBBHJ6e4lwmifHtOLTlW/wW0d7pQvDKduw5ek0D0Bm/y5I/FEHwa
moY73GB7iQzIUMXOa12X1UyCnPvn3yw1WcBB/90QxovrAfAfYaPgKZmenVqwMapL
B4PKPHnbH2VqkFheZgBifixCL0ENSj35K+xgowQTkWJ1/0ZCXT+U1ihQh951zYF3
Jb7lSKJSVMvp96HgR8vYBQQL34sYM7/cL1/N0BMis3NFjPc0DYbMuVRp0pbuRs0/
XT04F/lTvYBRUbW5wBgY5ss/+kiVVTZLmRaoJXBEbf1fh79d3il5O7oHugYhbCBn
+U927O5rR38EdERBV7BofY1kmoQE9nrki4ZWX3PAyc1muUCvxZM=
=greE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[nicolas . mailhot]

De: "Przemek Klosowski"

Hi,

> Many environments (corporate, government) actually require keeping track 
> of this stuff, so addressing it would help the acceptance of Fedora and 
> Redhat in such environments

Then have Koji or Bohdi insert accurate changelogs at build time. Can't be less 
reliable than the current crap (though it was useful to drag rpm in UTF-8 land).

Regards,

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

Re: Escaping macros in %changelog

[Kevin Kofler]

Matthew Miller wrote:
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.

My %changelog entries are not identical to the dist-git commit messages:

1. It often takes me several git commits to make a new EVR that builds.
   Also, typos in commit messages cannot be fixed. (Both of those issues
   could be solved if we were to allow force pushes to dist-git, but that
   would open a much bigger can of worms, as you certainly know.)

2. Most of my git commit messages are of the form:

   one-line summary

   full copy&paste of the RPM changelog entry, including the line with date,
   author and EVR.

   (The only ones that deviate from that format are followup fixup commits
   as per point 1.) If you are going to generate RPM changelogs from those
   commit messages, they will look really messy, with the date-author-EVR
   line duplicated.

3. Some of my commit messages contain additional notes that are not intended
   for the package changelog. (Typically a full paragraph of explanatory
   text.)

Thus, I think autogenerating the %changelog from dist-git commit messages 
would degrade its quality a lot, at least for my packages.

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

[HEADS UP] Mass-macro-escape in %changelog (was: Escaping macros in %changelog)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've went and fixed 493 packages (listed below). If it broke something, please
let me know. I checked diff briefly and don't think that I broke anything…

Maintainers by package:
389-console  mreynolds nhosoi nkinder rmeggins
389-ds-base  mreynolds nhosoi nkinder rmeggins
FlightGear   bellet
GtkAda   rombobeorn
L-function   pcpa
MAKEDEV  airlied clumens
Macaulay2rdieter tremble
OpenTK   churchyard
PyPE moceap
R-BSgenome.Celegans.UCSC.ce2 pingou
R2spec   pingou
RdRand   jhladky jtulak
SDL_imagejwrdegoede limb moezroy sdz
SimGear  bellet jwrdegoede spot
abrt abrt-team jfilak jmilan mhabrnal mkutlak mmarusak msuchy
acpica-tools ahs3
anjuta   gnome-sig kalev limb moezroy rakesh
apache-log4j-extras  coolsvap gil moceap
apmuddwmw2
apperkde-sig rdieter rhughes
argusfab janfrode limb
asm6809  linville
asterisk itamarjp jsmith russellb
atomic-devmode   jlebon
atop grover hobbes1069 limb
attica   jreznik kde-sig rdieter
audiofileajax alexl caillon caolanm gnome-sig johnp mschwendt
rhughes rstrode ssp
autofs   iankent jmoyer
automake kasal praiskup ttomecek
aws  landgraf rombobeorn
b43-fwcutter linville
beakerlibafri sopos
beetsmaha mbaldessari
bip  adamwill bcl mmahut
bitmap-fonts pnemade pravins
blivet-gui   m4rtink vtrefny
bsp  limb
buildnumber-maven-plugin weli
cabal-rpmpetersen
capstone drago01 rebus
chemical-mime-data   belegdol
cjdnssdgathman
clamav   gnat janfrode mstevens nb pwouters robert sergiomb steve
cloudy   mmahut sergiopr
cmst martinkg
cobbler  jimi kwizart orion shenson
cockpit  cockpit dperpeet martinpitt pvolpe stefw
colord   gnome-sig rhughes
common-lisp-controller green
compat-gtkhtml314limb
compiz-plugins-extra raveit65
compiz-plugins-main  raveit65
cone moceap steve
conman   dsommers sharkcz tuxbrewr vda
container-selinuxdwalsh fkluknav jchaloup lsm5 runcom
copr-backend clime frostyx msuchy
copr-dist-gitclime msuchy
cqrlog   hobbes1069
crda linville
createrepo   james lmacken packaging-team vmukhame
cross-binutils   dhowells lkundrak sharkcz
crypto-policies  lef nmav
cups-filters jpopelka twaugh zdohnal
custodia cheimes simo
cyphesis bruno mpreisle
darktablegermano madko ohaessler
dhcp-forwarder   pwouters
dietlibc limb
djview4  terjeros
djvulibremkasik
dmraid   agk bmr cfeist iankent jwrdegoede kzak lvm-team mauelsha
mbroz mcsontos mornfall pjones prajnoha twaugh zkabelac
dnf-plugins-core dmach ignatenkobrain jmracek rpm-software-management-sig
dolphin  dvratil kde-sig
dot2tex  radford
dovecot  mhlavink
dpkg kanarip sergiomb topdog
dpm-dsi  aalvarez andreamanzi ellert rocha simonm
dput-ng  suraia
drgeo-docbrouhaha
dt   agk mbroz okozina
ecryptfs-utils   mhlavink raphgro sandeen
elementary-xfce-icon-theme hannes
elfutils aoliva fche jakub jankratochvil mjw pmachata roland
ell  sonkun
elog tc01
emacsjgu jsynacek msekleta phracek
emacs-luatimn
eqp  jcp
etoysdsd gavin tuxbrewr
evolutionalexl caillon caolanm mbarnes mcrha rhughes rstrode ssp
tpopela
evolution-data-server alexl caillon caolanm johnp mbarnes mcrha rhughes rstrode
ssp
exaile   cicku deji williamjmorenor
fedora-logos alexl caillon caolanm johnp mbarnes rhughes rstrode spot
ssp
fedpkg   ausil cqi lsedlar
firewallderig0 jpopelka twoerner
flashrom dhendrix mrnuke peter robert
flex kasal pfrankli
flow-tools   orion stingray
forge-parent huwang mizdebsk weli
fortune-firefly  bruno
foxtrotgps   bubeck
freefem++cicku corsepiu itamarjp
freeipa  abbra ipa-maint jhrozek mkosek pvoborni rcritten simo
tkrizek
freeradius   nkondras
fts-monitoring   aalvarez andreamanzi simonm
gawk dkaspar
gdb  jankratochvil sergiodj
genders  dmlb2000
gentoo   amigadave cicku thias
geomview rdieter
ghc  petersen
ghex dodji drago01 kalev
gistsfiremanxbr
glite-jobid-api-cpp  valtri
gnome-bluetooth  hadess
gnome-media  orph

Re: F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2018 at 12:20:09PM +0530, Sinny Kumari wrote:
> On Fri, Feb 2, 2018 at 8:25 PM, Daniel Walsh  wrote:
> > Not yet.  We are working on packaging podman which would give users the same
> > experience as Docker CLI without requiring a Daemon.  That would be the
> > thing to replace
> Thanks Dan! Nice to know about podman.

What's the status here? I don't see podman in
http://fedoraproject.org/PackageReviewStatus/NEW.html, is it possible
to track the packaging effort somewhere?

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

Re: F28 Self Contained Change: VA-API 1.0.0

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 29, 2018 at 11:06:05PM +0100, Jan Kurik wrote:
> = 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,
I guess those are tickets in a bugtracker... Can you add hyperlinks?

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

> Upgrade/compatibility impact
> Users should update to the more recent version provided in repositories.

Hmm, isn't the biggest compatibility impact that the library .so
version will be bumped and all users will have to be rebuilt?
Do we know how much software outside of the distro itself is linked
to those libraries?
I think it'd be good to make this explicit in the change page.

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

Re: [HEADS UP] poppler-qt4 going away

[Kevin Kofler]

David Tardon wrote:
> * diffpdf
> - apparently not OSS anymore, so an update is unlikely

The Debian package:
https://packages.debian.org/sid/utils/diffpdf
has a patch to build diffpdf against poppler-qt5.

> * krop
> - uses python-poppler-qt4
> - unknown status

There's a fork with Qt 5 and Python 3 support:
https://github.com/gocarlos/krop
(Note that it drops Qt 4 and Python 2 support.)

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