Fedora-Atomic 27-20180309.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Use of int types in the code base,

[Simon Pichugin]

- Original Message -
> From: "William Brown" 
> To: "Simon Pichugin" 
> Cc: "389-devel" <389-devel@lists.fedoraproject.org>
> Sent: Friday, March 9, 2018 12:30:40 AM
> Subject: Re: Use of int types in the code base,
> 
> On Thu, 2018-03-08 at 17:33 -0500, Simon Pichugin wrote:
> > Hi William!
> > Thank you for the email. It has clarified the things for me. :)
> > I still have one question though.
> > 
> > Do I understand right that I need also to cast types with these types
> > from inttypes.h?
> > So use it not only in the defenitions.
> > - sprintf(buf, "%lu", (long unsigned int)maxsize);
> > + sprintf(buf, "%" PRIu64, (uint64_t)maxsize);
> 
> There is PRIu32 too :)
> 
> The pattern is:
> 
> PRI
> 
> IE
> 
> PRIu64 - uint64_t
> PRId64 - int64_t
> PRIu32 - uint32_t
> PRId32 - int32_t
> 
> Check what type maxsize is to be sure you use the correct PRI type.
> 
> Hope that helps,
Ok. My question was about a bit different thing :)
But now, after some investigation I have clarified something but not all:

So we have size_t that will have the size of the platform (it's 64 now but 
later we can have 128 bit platform, etc.).
For now, the code will work like this (without any warning)
size_t maxsize
sprintf(buf, "%" PRIu64, maxsize);
And, actually, we already have lines like these in the older code added by you:
https://pagure.io/389-ds-base/c/274823860ac98b153e7f0bc84d979861c4ca895f

Or we can change size_t as you've proposed in pull request:
https://pagure.io/389-ds-base/pull-request/49595
"Ahhh I see the issue here. You have maxsize as size_t, but you have PRIu64. 
Size_t is platform specific width, so you could change maxsize to be a uint64_t 
instead to avoid this."
uint64_t maxsize
sprintf(buf, "%" PRIu64, maxsize);

So could you please guide me here on what coding style do we have in cases like 
this?

As I understood from coding style guide you gave, we need to use 64bit types 
mostly (size_t for arrays indexing and 32bit types for compatibility with some 
apis only)

Thank you,
Simon

> 
> 
> > 
> > Thanks,
> > Simon
> > 
> > - Original Message -
> > > From: "William Brown" 
> > > To: "389-devel" <389-devel@lists.fedoraproject.org>
> > > Sent: Thursday, March 8, 2018 12:42:03 AM
> > > Subject: Use of int types in the code base,
> > > 
> > > Hi there,
> > > 
> > > http://www.port389.org/docs/389ds/development/coding-style.html#typ
> > > es
> > > 
> > > In a few reviews I still see this sometimes.
> > > 
> > > It's pretty important that we keep moving our quality standard
> > > higher,
> > > and having known type sizes is important to this. Types like int
> > > and
> > > long are unknown sizes until you compile it depending on platform.
> > > 
> > > As a result, it's really important we use the intX_t and uintX_t
> > > types
> > > so we have guarantees of our values. I would encourage the use of
> > > int64_t and uint64_t, because while they are "larger", it's
> > > significantly faster for a modern 64bit system to process these
> > > values
> > > than their 32bit counterparts.
> > > 
> > > Another note is that arrays index by size_t, not 'int', so we
> > > should
> > > always keep this in mind.
> > > 
> > > Finally, because we are using c99 now, this means we should avoid:
> > > 
> > > size_t i = 0;
> > > 
> > > for (i = 0; i < cond; i++) {
> > > ...
> > > }
> > > 
> > > When we really should scope our values. Scoping is good because it
> > > limits possibility of data corruption to flow and other mistakes
> > > such
> > > as re-use of values. This means:
> > > 
> > > for (size_t i = 0; i < cond; i++) {
> > > ...
> > > }
> > > 
> > > Thanks!
> > > 
> > > --
> > > Thanks,
> > > 
> > > William Brown
> > > 
> --
> Thanks,
> 
> William Brown
> 
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
> * CI/automated tests run on it, and if all is ok goes out in the next
> rawhide compose.
> * If not ok, you could wave the results or build more things/edit the
> update until it passes.

Hi,
so it looks like you are going to remove chain-build from fedpkg,
right? It's kind of pain it doesn't work for stable, but if you want to
get rid of it for rawhide too, or add some unnecessary obstacles for
its usage, then it's a downgrade like the kerberos usage (it's a pain
to write my password all the time when I want to do something in
packaging, with compare of once-per-year replace of the certificate,
but that's another story, which only adds to the feeling of making
process more and more painful instead of simpler (I heard some time ago
something like this "security by obscurity", with which I fully
agree)). I chain-build like this "A : B : C D", which means in stable
that I build A, then fill override, then I build B, then fill an
override, the I build C and D and then I fill the update. I hope the
difference in stable and chain-build usage is obvious.

Anyway, could you enlighten what you call "if all is ok"? That's pretty
important measure.

What do I do if it's not ok?

I do maintain a package which is in critpath. I'm not a proven
packager, thus I cannot touch anyone's package (I hesitate to do it
anyway, even there are cases where are not many other options). If my
critpath package changes API and soname versions, then other packages,
for which I do not have commit rights, will be broken by that update,
but the update as such will build and look just fine. What do I do now?
Will I hunt for respective maintainers and co-maintainers kindly asking
them to do something about it? The paper work around this (finding who
it is, their email addresses, writing them a mail) would be a pain on
its own, but more painful would be the delay in the delivery. It will
not be rawhide anymore, from my point of view.

I'd rather prefer to have detected issues in updates early (though it's
understandable that doing API/ABI checks after each package update is
not doable at least due to resource requirements - thus you'd not
detect it with the gating too, right?), or at least like once a day.

I did a soname version bump in one of my packages recently and
announced it, with a list of "possibly affected packages". I know my
work flow is wrong in this regard, but I kind of rely on the
notifications of broken dependencies to rebuild what is really needed
to be rebuilt, because the packages sometimes requires something bigger
in the build time, which is not actually used in the run time (just my
feeling, no prove available). I didn't receive any single notification
of broken dependencies this time. While it's possible someone was just
quicker than me, I believe it's highly unlikely. I also believe I
didn't filter out any such "broken dependencies" mail notifications
from my notification settings, they used to come in the past.

That's also another disadvantage of the gating. I recall seeing broken
dependencies messages for package I've no commit rights for for weeks.
Either the maintainer (or co-maintainer) didn't receive those messages
similar like me, or they just didn't care. How would I force them to
rebuild/correct (I am definitely willing to help to correct the
packages when an API change requires it) their packages, when they
already ignore/filter out broken dependencies notifications? Should I
hunt for a proven packager to move things forward, thus other packages
can rely on the provided change? Proven packagers have their own work
to do to, they cannot be disrupted from their work every other day by
hundreds of packages to help with the packages their update broke.

By the way, why was the compose of rawhide broken for several days?
Corresponding people/packagers not being available? It looks to me that
you just want to move the issue to a slightly upper level, but then
you'll have working rawhide compose, which will not use the
recent/bleeding code. It is, from my point of view, the main credit of
Rawhide, to be on the bleeding edge.

It would be very sad to turn Rawhide from 'package update' to 'people
hunt' task.

Just my opinion.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Jason L Tibbitts III]

> "PM" == Panu Matilainen  writes:

PM> It's not a solution because doing so usually drags half the distro
PM> along due to library dependencies etc.

That's true if you're updating to the rpm/dnf/whatever from the distro
you want to upgrade to.  That's not true if you're updating to a new
version of rpm/dnf/whatever which supports the new features you need but
which has been built for the version of the distro you're currently
running.

But yes, I know how unpleasant it would be to have to somehow maintain
that magical package set in a separate "you're about to update your
distro" repository, and that it could still have issues when the minimum
supported versions of dependencies change.  Is it worse than some of the
other solutions?  I'm not sure.

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

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> Randy Barlow wrote:
>> It may be possible to automate the process a bit to make it less heavy
>> for developers, though there is some complication for multi-package
>> updates
> 
> Some automation would help, sure. But if we are going to do things 
> automatically, why bother with Bodhi at all?

Well, we don't currently have another tool to show results and allow
waving of them. We could come up with another app and have yet a
different place and workflow from regular releases, but why not stick to
the same workflow and avoid making yet another app.
> 
> We are already building into a pending tag for the autosigning, from which 
> the packages are moved into the final tag when they are signed. The same 
> process should work for autotesting. Just add it before or after the 
> autosigning in the pipeline, possibly with another intermediate tag.
> 
> I think that Bodhi is really the wrong tool for the job here. What you are 
> trying to hit with your shiny hammer may look like a nail to you, but it is 
> really a screw. ;-)

I don't think thats the case here, it's more than we don't want to build
another different tool for something that could work with the hammer we
have.

To be fair, there was a suggestion that we show results in
pagure/src.fedoraproject.org, but to me, that definitely sounds like the
wrong place for such things. We want tests tied to a specific update,
not the entire package as a whole. (Even thought we could fudge this by
having git tags or something to tie results to).

kevin



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: Fedora Rawhide-20180308.n.2 compose check report

[Adam Williamson]

On Thu, 2018-03-08 at 22:25 -0500, Dusty Mabe wrote:
> 
> On 03/08/2018 08:17 PM, Fedora compose checker wrote:
> > Missing expected images:
> > 
> > Atomichost qcow2 x86_64
> > Atomichost raw-xz x86_64
> 
> This is kind of interesting.. I see these images in the compose: 
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180308.n.2/compose/CloudImages/x86_64/images/
> 
> I wonder if the name should be 
> Fedora-AtomicHost-Rawhide-20180308.n.2.x86_64.qcow2
> and that's why it's complaining? We should be able to fix that by updating
> this line: https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_376

Well, nearly. It's not in fact based on the filename, but the
subvariant property of the metadata. But you're nearly there, as you
can see just a few lines below:

'subvariant': 'Atomic',

I didn't realize / remember, when reviewing your changes, that only the
ostree installer images are actually produced from the AtomicHost
variant (note: these images wind up with AtomicHost as their subvariant
as well as their variant, IIRC we use the variant as the subvariant any
time there isn't an *explicit* subvariant), while the other Atomic
images are produced in the CloudImages variant.

I'd suggest that, yes, we should change the names *and* subvariants for
those image definitions.

(Note, it annoys me immensely that we just flat out specify all these
'name' fields. They should be generated from the metadata, not
just...written down. But that's another issue.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Kevin Kofler]

We really need to get things working with the latest (or at least the 
second-to-latest, but ideally only the latest) LLVM and not carry ancient 
compatibility versions that are a symbol conflict minefield:

Yaakov Selkowitz wrote:
> On 2018-03-08 16:54, Adam Williamson wrote:
>> llvm3.9
> 
> Still required by julia[1].
>
> [1] https://github.com/JuliaLang/julia#llvm

This says that "Julia can be built with newer LLVM versions". So just do it. 
They consider it experimental, but it would definitely not be the first 
experimental package Fedora ships.

>> llvm4.0
> 
> Still required by ldc due to an issue on ppc64le[2].
> 
> [2] https://src.fedoraproject.org/rpms/ldc/c/4130742

Building with an obsolete LLVM just because of some bug on an "alternative" 
(i.e., secondary) architecture does not make any sense whatsoever. If 
anything, it should be built with the old version only on ppc64le. But if 
that's the only reason the old LLVM version is needed, just drop it, build 
ldc against what's available, ExcludeArch: ppc64le if the bug fails the 
build (do nothing if it doesn't (but only affects compiling things WITH 
ldc)), and let the ppc64le arch team fix LLVM. It does not make sense to let 
"alternative" architectures block progress on our primary architectures.

(And it looks like there is already a fix upstream by now, as pointed out 
elsewhere in this thread.)

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

Re: Gating packages in Rawhide

[Kevin Kofler]

Randy Barlow wrote:
> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi on Rawhide, similar to how we use it for our stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or something
> simple).

IMHO, this is highly impractical. Having to file Bodhi updates for every 
Rawhide build will make development cringe to a halt.

> It may be possible to automate the process a bit to make it less heavy
> for developers, though there is some complication for multi-package
> updates

Some automation would help, sure. But if we are going to do things 
automatically, why bother with Bodhi at all?

We are already building into a pending tag for the autosigning, from which 
the packages are moved into the final tag when they are signed. The same 
process should work for autotesting. Just add it before or after the 
autosigning in the pipeline, possibly with another intermediate tag.

I think that Bodhi is really the wrong tool for the job here. What you are 
trying to hit with your shiny hammer may look like a nail to you, but it is 
really a screw. ;-)

(That said, I am not even convinced gating Rawhide is going to be workable 
to begin with. Temporary breakage is just sometimes necessary to make things 
move forward. I would much rather see the compose process made more robust 
so it does not fail on every small breakage.)

> Another idea that was tossed around in some chats I had with people
> about this involved a system for packagers to use to create Koji side
> tags.

This idea is interesting, and it could be also used without gating or with a 
gating process not relying on Bodhi. The side tag creation, and possibly the 
side tag merge request, would then be the only thing(s) done through Bodhi.

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

Re: libqalculate soname change

[Kevin Kofler]

Adam Williamson wrote:
> This cycle was actually kind of an interesting case, because on the one
> hand, there's a pretty good argument that we were in a very bad state
> at freeze time this cycle. On the *other* hand, one of the main reasons
> we were in a bad state is because people kept frickin' landing de-
> stabilizing changes while we were still dealing with the fallout from
> the previous de-stabilizing change: we've had GCC 8, various
> unannounced soname bumps, basically all of nu-Modularity showing up in
> the middle there somewhere, anaconda modularization, new versions of
> pungi and pykickstart and systemd, and that's just the things I
> *remember*. It's been something of a wild ride.

The reason why there are so many major changes in F28 is pretty clear: the 
F27 cycle was too short! Hardly any major change made it in there. So we now 
get double the changes.

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

Re: Fedora Rawhide-20180308.n.2 compose check report

[Dusty Mabe]

On 03/08/2018 08:17 PM, Fedora compose checker wrote:
> Missing expected images:
> 
> Atomichost qcow2 x86_64
> Atomichost raw-xz x86_64

This is kind of interesting.. I see these images in the compose: 

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180308.n.2/compose/CloudImages/x86_64/images/

I wonder if the name should be 
Fedora-AtomicHost-Rawhide-20180308.n.2.x86_64.qcow2
and that's why it's complaining? We should be able to fix that by updating
this line: https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_376

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

Fedora Rawhide-20180308.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Failed openQA tests: 25/129 (x86_64), 6/24 (i386), 1/2 (arm)

ID: 199278  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/199278
ID: 199280  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/199280
ID: 199297  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/199297
ID: 199298  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/199298
ID: 199301  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/199301
ID: 199310  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/199310
ID: 199311  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/199311
ID: 199314  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/199314
ID: 199315  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/199315
ID: 199316  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/199316
ID: 199318  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/199318
ID: 199326  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/199326
ID: 199328  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/199328
ID: 199329  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/199329
ID: 199331  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/199331
ID: 199336  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/199336
ID: 199343  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/199343
ID: 199346  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/199346
ID: 199359  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/199359
ID: 199376  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/199376
ID: 199377  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/199377
ID: 199378  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/199378
ID: 199385  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/199385
ID: 199386  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/199386
ID: 199387  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/199387
ID: 199395  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/199395
ID: 199399  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/199399
ID: 199405  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/199405
ID: 199406  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/199406
ID: 199409  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/199409
ID: 199410  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/199410
ID: 199422  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/199422

Soft failed openQA tests: 55/129 (x86_64), 16/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 199271  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/199271
ID: 199272  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/199272
ID: 199285  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/199285
ID: 199286  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/199286
ID: 199289  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/199289
ID: 199292  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/199292
ID: 199293  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/199293
ID: 199317  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/199317
ID: 199330  Test: i386 KDE-live-iso 

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Chuck Anderson]

On Thu, Mar 08, 2018 at 04:06:33PM -0800, Adam Williamson wrote:
> On Thu, 2018-03-08 at 17:23 -0600, Yaakov Selkowitz wrote:
> > 
> > > llvm3.9
> > 
> > Still required by julia[1].
> 
> "The Julia Language: A fresh approach to technical computing."
> 
> But not *too* fresh, apparently. ;)

Technical Computing, as in Fortran 90?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1553503] New: perl-Time-Moment-0.43 is available

[bugzilla]

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

Bug ID: 1553503
   Summary: perl-Time-Moment-0.43 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Time-Moment
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.43
Current version/release in rawhide: 0.42-5.fc28
URL: http://search.cpan.org/dist/Time-Moment/

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

-- 
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: On Ye Olde Foreste of Anciente LLVM Versiones

[Adam Williamson]

On Thu, 2018-03-08 at 17:23 -0600, Yaakov Selkowitz wrote:
> > llvm4.0
> 
> Still required by ldc due to an issue on ppc64le[2].

The 'issue' referred to there is closed upstream:

https://bugs.llvm.org/show_bug.cgi?id=36292

as of a couple of weeks ago. Perhaps the fix can be applied to our
packages and ldc changed to use current llvm now? That'd get rid of
another version.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Adam Williamson]

On Thu, 2018-03-08 at 17:23 -0600, Yaakov Selkowitz wrote:
> 
> > llvm3.9
> 
> Still required by julia[1].

"The Julia Language: A fresh approach to technical computing."

But not *too* fresh, apparently. ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Adam Williamson]

On Thu, 2018-03-08 at 15:47 -0800, Josh Stone wrote:
> On 03/08/2018 03:25 PM, Yaakov Selkowitz wrote:
> > On 2018-03-08 17:05, Adam Williamson wrote:
> > > On Thu, 2018-03-08 at 14:54 -0800, Adam Williamson wrote:
> > > > While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
> > > > have a rather magnificent collection of ancient llvm versions:
> > > > 
> > > > llvm34
> > > > llvm35
> > > > llvm3.9
> > > > llvm4.0
> > > > llvm5.0
> > > > 
> > > > None of these is retired (llvm33 and llvm3.7 also exist, but *are*
> > > > retired). llvm34 and llvm35 don't build successfully and haven't for
> > > > some time. The more recent ones mostly look like they should build,
> > > > except they have issues with exhausting RAM on the i686 and armhfp
> > > > builders.
> > > > 
> > > > Do we actually need all of these for anything? Can we kill some of
> > > > them?
> > > 
> > > AFAICS, nothing at all uses these:
> > 
> > You have to look at the -libs subpackage too.
> 
> Or -devel if you're querying BuildRequires.
> 
> Rust currently builds with llvm5.0-devel, but I should be able to move
> it to the base llvm (6.0) for its next release.

Thanks, all of you.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Josh Stone]

On 03/08/2018 03:25 PM, Yaakov Selkowitz wrote:
> On 2018-03-08 17:05, Adam Williamson wrote:
>> On Thu, 2018-03-08 at 14:54 -0800, Adam Williamson wrote:
>>> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
>>> have a rather magnificent collection of ancient llvm versions:
>>>
>>> llvm34
>>> llvm35
>>> llvm3.9
>>> llvm4.0
>>> llvm5.0
>>>
>>> None of these is retired (llvm33 and llvm3.7 also exist, but *are*
>>> retired). llvm34 and llvm35 don't build successfully and haven't for
>>> some time. The more recent ones mostly look like they should build,
>>> except they have issues with exhausting RAM on the i686 and armhfp
>>> builders.
>>>
>>> Do we actually need all of these for anything? Can we kill some of
>>> them?
>>
>> AFAICS, nothing at all uses these:
> 
> You have to look at the -libs subpackage too.

Or -devel if you're querying BuildRequires.

Rust currently builds with llvm5.0-devel, but I should be able to move
it to the base llvm (6.0) for its next release.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Tom Stellard]

On 03/08/2018 03:23 PM, Yaakov Selkowitz wrote:
> On 2018-03-08 16:54, Adam Williamson wrote:
>> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
>> have a rather magnificent collection of ancient llvm versions:
> 
> Please double-check, but based on results of dnf repoquery of the
> respective -libs subpackage:
> 
>> llvm34
> 
> Don't see any reverse dependencies since at least F26.
> 
>> llvm35
> 
> Ditto.
> 

I can retire these two packages.

-Tom

>> llvm3.9
> 
> Still required by julia[1].
> 
>> llvm4.0
> 
> Still required by ldc due to an issue on ppc64le[2].
> 
>> llvm5.0
> 
> 6 was *just* released, so at least atm still required (directly, or
> indirectly via clang5.0) by bcc, beignet, ispc, iwyu, pocl, and rust.
> It will take a little while for all these to support 6 upstream.
> 
>> None of these is retired (llvm33 and llvm3.7 also exist, but *are*
>> retired). llvm34 and llvm35 don't build successfully and haven't for
>> some time. The more recent ones mostly look like they should build,
>> except they have issues with exhausting RAM on the i686 and armhfp
>> builders.
> 
> [1] https://github.com/JuliaLang/julia#llvm
> [2] https://src.fedoraproject.org/rpms/ldc/c/4130742
> 
> 
> 
> ___
> 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

[Bug 1553479] SElinux denials on stock install

[bugzilla]

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



--- Comment #1 from R P Herrold  ---
another symptom of the problem is the inability to save a cookie, and so having
to repeatedly log in over and over again

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

rust-structopt and rust-structopt-derive license change

[Josh Stone]

rust-structopt-0.2.5-1.fc29 and rust-structopt-derive-0.2.5-1.fc29 come
with a license change from "WTFPL" to "ASL 2.0 or MIT".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Use of int types in the code base,

[William Brown]

On Thu, 2018-03-08 at 17:33 -0500, Simon Pichugin wrote:
> Hi William!
> Thank you for the email. It has clarified the things for me. :)
> I still have one question though.
> 
> Do I understand right that I need also to cast types with these types
> from inttypes.h?
> So use it not only in the defenitions.
> - sprintf(buf, "%lu", (long unsigned int)maxsize);
> + sprintf(buf, "%" PRIu64, (uint64_t)maxsize);

There is PRIu32 too :) 

The pattern is:

PRI

IE

PRIu64 - uint64_t
PRId64 - int64_t
PRIu32 - uint32_t
PRId32 - int32_t

Check what type maxsize is to be sure you use the correct PRI type.

Hope that helps,


> 
> Thanks,
> Simon
> 
> - Original Message -
> > From: "William Brown" 
> > To: "389-devel" <389-devel@lists.fedoraproject.org>
> > Sent: Thursday, March 8, 2018 12:42:03 AM
> > Subject: Use of int types in the code base,
> > 
> > Hi there,
> > 
> > http://www.port389.org/docs/389ds/development/coding-style.html#typ
> > es
> > 
> > In a few reviews I still see this sometimes.
> > 
> > It's pretty important that we keep moving our quality standard
> > higher,
> > and having known type sizes is important to this. Types like int
> > and
> > long are unknown sizes until you compile it depending on platform.
> > 
> > As a result, it's really important we use the intX_t and uintX_t
> > types
> > so we have guarantees of our values. I would encourage the use of
> > int64_t and uint64_t, because while they are "larger", it's
> > significantly faster for a modern 64bit system to process these
> > values
> > than their 32bit counterparts.
> > 
> > Another note is that arrays index by size_t, not 'int', so we
> > should
> > always keep this in mind.
> > 
> > Finally, because we are using c99 now, this means we should avoid:
> > 
> > size_t i = 0;
> > 
> > for (i = 0; i < cond; i++) {
> > ...
> > }
> > 
> > When we really should scope our values. Scoping is good because it
> > limits possibility of data corruption to flow and other mistakes
> > such
> > as re-use of values. This means:
> > 
> > for (size_t i = 0; i < cond; i++) {
> > ...
> > }
> > 
> > Thanks!
> > 
> > --
> > Thanks,
> > 
> > William Brown
> > 
-- 
Thanks,

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

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 15:47 -0500, Stephen John Smoogen a écrit :
> On 8 March 2018 at 15:32, Stephen John Smoogen 
> wrote:
> > On 8 March 2018 at 13:38, Nicolas Mailhot  > et> wrote:
> > I have spent this afternoon going through many of your emails and
> > our
> > logs so I could find try to figure out what to help you. Coming back
> > and finding you blaming everyone else is insulting to my time and
> > tiresome. You are better than this.
> > 
> 
> You also deserved better from me in that I should have sent that email
> only to you versus the entire list. I apologize for my conduct as it
> was rude.

Everyone is tired and touchy and I'd rather have spend my time on
finishing up my packages. Nevertheless, since I spent my time on this, I
believe the listserver is invalidating dkim signatures by appending
footers to signed messages without removing those signatures, which
causes some MTAs like my ISP's to add  prefixes to subjects, and
others to flag messages from the listserver as spam.

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

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Yaakov Selkowitz]

On 2018-03-08 17:05, Adam Williamson wrote:
> On Thu, 2018-03-08 at 14:54 -0800, Adam Williamson wrote:
>> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
>> have a rather magnificent collection of ancient llvm versions:
>>
>> llvm34
>> llvm35
>> llvm3.9
>> llvm4.0
>> llvm5.0
>>
>> None of these is retired (llvm33 and llvm3.7 also exist, but *are*
>> retired). llvm34 and llvm35 don't build successfully and haven't for
>> some time. The more recent ones mostly look like they should build,
>> except they have issues with exhausting RAM on the i686 and armhfp
>> builders.
>>
>> Do we actually need all of these for anything? Can we kill some of
>> them?
> 
> AFAICS, nothing at all uses these:

You have to look at the -libs subpackage too.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, 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

Re: On Ye Olde Foreste of Anciente LLVM Versiones

[Yaakov Selkowitz]

On 2018-03-08 16:54, Adam Williamson wrote:
> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
> have a rather magnificent collection of ancient llvm versions:

Please double-check, but based on results of dnf repoquery of the
respective -libs subpackage:

> llvm34

Don't see any reverse dependencies since at least F26.

> llvm35

Ditto.

> llvm3.9

Still required by julia[1].

> llvm4.0

Still required by ldc due to an issue on ppc64le[2].

> llvm5.0

6 was *just* released, so at least atm still required (directly, or
indirectly via clang5.0) by bcc, beignet, ispc, iwyu, pocl, and rust.
It will take a little while for all these to support 6 upstream.

> None of these is retired (llvm33 and llvm3.7 also exist, but *are*
> retired). llvm34 and llvm35 don't build successfully and haven't for
> some time. The more recent ones mostly look like they should build,
> except they have issues with exhausting RAM on the i686 and armhfp
> builders.

[1] https://github.com/JuliaLang/julia#llvm
[2] https://src.fedoraproject.org/rpms/ldc/c/4130742

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, 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

Re: question about Obsoletes/Provides

[Fernando Nasser]

On 2018-03-08 5:58 AM, Daniel P. Berrangé wrote:

On Thu, Mar 08, 2018 at 11:23:45AM +0100, Jos de Kloe wrote:

I have a question about an open review request on the eccodes package,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1508950

Eccodes will replace grib_api for which downstream will stop support at
the end of this year.
Therefore the first draft spec file had Obsoletes/Provides entries to
make clear that eccodes will replace it.

Then I received a comment that this was maybe not correct, since the
replacement package may not be compatible enough so I disabled these
keywords.

Main differences are:
* grib_api provides a fortran77 library, which is absent in eccodes
* library and pkg-config files changed name

on the other hand, they both provide a fully compatible api version of
the c and fortran90 library.

On top of that, they both provide a collection of tools in /usr/bin with
identical names which gives a conflict in ownership if both packages
would be present at the same time.

looking at
https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
is this a case where only an Obsoletes should be used?

Yes, IMHO this is a case where just using 'Obsoletes' on its own to get
the upgrade installed is reasonable. Any downstream RPM that depends on
the original package may well need adapting due to changed library name,
so claiming 'Provides' is not appropriate.


Regards,
Daniel



Just adding a reminder:  make sure your Obsoletes is versioned.


Regards,

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

[Bug 1553479] New: SElinux denials on stock install

[bugzilla]

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

Bug ID: 1553479
   Summary: SElinux denials on stock install
   Product: Fedora EPEL
   Version: el6
 Component: bugzilla
  Assignee: ita...@ispbrasil.com.br
  Reporter: herr...@owlriver.com
QA Contact: extras...@fedoraproject.org
CC: bazanlui...@gmail.com, emman...@seyman.fr,
ita...@ispbrasil.com.br,
perl-devel@lists.fedoraproject.org



Description of problem:

SElinux denials on stock install

Version-Release number of selected component (if applicable):

bugzilla-3.4.14-2.el6.noarch

How reproducible:

install utterly stock with no local edits beyond setting up /etc/my.cnf  and
letting the bugzilla set up tool handle the database matters

when then going in as admin, and using the web interface to adjust parameters,
I get:


type=AVC msg=audit(1520549558.851:1134): avc:  denied  { search } for
pid=1957 comm="editparams.cgi" name="pki" dev=vda1 ino=131147
scontext=system_u:system_r:httpd_bugzilla_script_t:s0
tcontext=system_u:object_r:cert_t:s0 tclass=dir
type=AVC msg=audit(1520549565.365:1141): avc:  denied  { search } for
pid=1962 comm="admin.cgi" name="pki" dev=vda1 ino=131147
scontext=system_u:system_r:httpd_bugzilla_script_t:s0   
tcontext=system_u:object_r:cert_t:s0 tclass=dir



From past experience, I know this will be an iterative process (I will need to
'click around' to provoke more AVC's

I will supplement this bug as I proceed but it is the end of a local business
day, and I wanted to capture this detail

-- 
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: On Ye Olde Foreste of Anciente LLVM Versiones

[Adam Williamson]

On Thu, 2018-03-08 at 14:54 -0800, Adam Williamson wrote:
> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
> have a rather magnificent collection of ancient llvm versions:
> 
> llvm34
> llvm35
> llvm3.9
> llvm4.0
> llvm5.0
> 
> None of these is retired (llvm33 and llvm3.7 also exist, but *are*
> retired). llvm34 and llvm35 don't build successfully and haven't for
> some time. The more recent ones mostly look like they should build,
> except they have issues with exhausting RAM on the i686 and armhfp
> builders.
> 
> Do we actually need all of these for anything? Can we kill some of
> them?

AFAICS, nothing at all uses these:

[adamw@adam llvm-3.4.2.src (master %)]$ sudo dnf repoquery 
--enablerepo=fedora-source --whatrequires llvm35
Last metadata expiration check: 0:00:00 ago on Thu 08 Mar 2018 03:04:53 PM PST.
llvm35-devel-0:3.5.2-4.fc26.i686
llvm35-devel-0:3.5.2-4.fc26.x86_64
llvm35-doc-0:3.5.2-4.fc26.noarch
[adamw@adam llvm-3.4.2.src (master %)]$ sudo dnf repoquery 
--enablerepo=fedora-source --whatrequires llvm3.9
Last metadata expiration check: 0:00:05 ago on Thu 08 Mar 2018 03:04:53 PM PST.
llvm3.9-devel-0:3.9.1-11.fc27.i686
llvm3.9-devel-0:3.9.1-11.fc27.x86_64
[adamw@adam llvm-3.4.2.src (master %)]$ sudo dnf repoquery 
--enablerepo=fedora-source --whatrequires llvm4.0
Last metadata expiration check: 0:00:12 ago on Thu 08 Mar 2018 03:04:53 PM PST.
llvm4.0-devel-0:4.0.1-3.fc28.i686
llvm4.0-devel-0:4.0.1-3.fc28.x86_64
llvm4.0-doc-0:4.0.1-3.fc28.noarch
[adamw@adam llvm-3.4.2.src (master %)]$ sudo dnf repoquery 
--enablerepo=fedora-source --whatrequires llvm5.0
Last metadata expiration check: 0:00:17 ago on Thu 08 Mar 2018 03:04:53 PM PST.
llvm5.0-devel-0:5.0.1-4.fc28.i686
llvm5.0-devel-0:5.0.1-4.fc28.x86_64
llvm5.0-doc-0:5.0.1-4.fc28.noarch
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

On Ye Olde Foreste of Anciente LLVM Versiones

[Adam Williamson]

While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we
have a rather magnificent collection of ancient llvm versions:

llvm34
llvm35
llvm3.9
llvm4.0
llvm5.0

None of these is retired (llvm33 and llvm3.7 also exist, but *are*
retired). llvm34 and llvm35 don't build successfully and haven't for
some time. The more recent ones mostly look like they should build,
except they have issues with exhausting RAM on the i686 and armhfp
builders.

Do we actually need all of these for anything? Can we kill some of
them?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Please review: Issue 49593 - NDN cache stats should be under the global stats

[Simon Pichugin]

Fixed issues with inttypes.

On Wed, Mar 07, 2018 at 08:01:33PM +0100, Simon Pichugin wrote:
> Fixed compile warnings.
> 
> On Wed, Mar 07, 2018 at 06:53:53PM +0100, Simon Pichugin wrote:
> > Hi team,
> > please, review:
> > 
> > https://pagure.io/389-ds-base/pull-request/49595
> > https://pagure.io/389-ds-base/issue/49593
> > 
> > Thanks,
> > Simon
> > ___
> > 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Use of int types in the code base,

[Simon Pichugin]

Hi William!
Thank you for the email. It has clarified the things for me. :)
I still have one question though.

Do I understand right that I need also to cast types with these types from 
inttypes.h?
So use it not only in the defenitions.
- sprintf(buf, "%lu", (long unsigned int)maxsize);
+ sprintf(buf, "%" PRIu64, (uint64_t)maxsize);

Thanks,
Simon

- Original Message -
> From: "William Brown" 
> To: "389-devel" <389-devel@lists.fedoraproject.org>
> Sent: Thursday, March 8, 2018 12:42:03 AM
> Subject: Use of int types in the code base,
> 
> Hi there,
> 
> http://www.port389.org/docs/389ds/development/coding-style.html#types
> 
> In a few reviews I still see this sometimes.
> 
> It's pretty important that we keep moving our quality standard higher,
> and having known type sizes is important to this. Types like int and
> long are unknown sizes until you compile it depending on platform.
> 
> As a result, it's really important we use the intX_t and uintX_t types
> so we have guarantees of our values. I would encourage the use of
> int64_t and uint64_t, because while they are "larger", it's
> significantly faster for a modern 64bit system to process these values
> than their 32bit counterparts.
> 
> Another note is that arrays index by size_t, not 'int', so we should
> always keep this in mind.
> 
> Finally, because we are using c99 now, this means we should avoid:
> 
> size_t i = 0;
> 
> for (i = 0; i < cond; i++) {
> ...
> }
> 
> When we really should scope our values. Scoping is good because it
> limits possibility of data corruption to flow and other mistakes such
> as re-use of values. This means:
> 
> for (size_t i = 0; i < cond; i++) {
> ...
> }
> 
> Thanks!
> 
> --
> Thanks,
> 
> William Brown
> 
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Atomic Working Group VFAD 03/09

[chicago]

We would like to have a VFAD (virtual Fedora Activity Day) on March 9th at 
approximately Fri Mar 9 15:00:00 UTC 2018 . 


This is 10 AM eastern. 

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

Re: Gating packages in Rawhide

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-03-08 at 13:00 -0500, Randy Barlow wrote:
> Greetings fellow Fedorans!
> 
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in
> place
> for the Fedora 29 timeframe.
> 
> As one of the Bodhi contributors, I am inclined to suggest that we
> could
> use Bodhi on Rawhide, similar to how we use it for our
> stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or
> something
> simple).
> 
> It may be possible to automate the process a bit to make it less
> heavy
> for developers, though there is some complication for multi-package
> updates (more on that in a bit). For simple package updates, we may
> be
> able to detect new commits on dist-git, and react to those by
> automatically starting a Koji build, and automatically filing a Bodhi
> update when that build is complete. I think that would be pretty
> nice,
> and pingou created a PoC[0] to do this about a year ago.
> 
> Multi-package updates won't be so easy though. It's not uncommon for
> us
> to need to update packages together, and the above workflow would be
> problematic since it would result in updates with single packages in
> them rather than updates with multiple packages. Of course, buildroot
> overrides would be a problem too, since multi-package updates often
> depend on each other at build time too.
> 
> We could create some way for packagers to indicate that a commit (or
> possibly even a whole repo) is not intended to be
> "autobuilt/updated".
> If the packager indicates this then their builds would go into a
> rawhide-pending (similar to what we do for f27 today). Once they have
> all their builds (and buildroot overrides) the way they want them,
> they
> can create the update.
> 
> Another idea that was tossed around in some chats I had with people
> about this involved a system for packagers to use to create Koji side
> tags. Bodhi manages BuildRoot Overrides today (with expirations), so
> perhaps Bodhi could be expanded to also manage Koji side tags (also
> with
> expirations). I can't remember all the details about this approach or
> why it was suggested over the former approach, but I wanted to list
> it
> to invite others to chew on it and see if it could work.
> 
> If you have other suggestions on how we might gate packages in
> Rawhide
> that are wildly different than the above, please feel free to share!

I would not mind this, but making buildroot overrides is something what
makes me to not update N-1 release.. Especially when I need to build
15-20 packages which have some dependency loops.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIyBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqhuGoACgkQaVcUvRu8
X0yNig/4nryfRqiDy6hTU2UgDxznTt/kg4/MXcqo02aNzcMOPf5Iel7XN3rs+Hqq
r8oIzzWE/1rldMdF6s/G/9vY0vpcRox9jZylMumevH59T8w6nTMioPqEcAKM3s2w
0SF6D+Mcj/US0pKaQhp6vcmOfHbXBfuBIl6XROW2rBKhCtjQhkU8bhBV9ku4qLxF
1rkk0yN06t4ULWeJmnAyBKYiU+fGGlixJCP6xeghrH3Vb5jsDC3weLSOm177V3zL
WCO4x7jtca/DbtW/CbHnJeIM7DzaAIL6FbfYQDBK9Z2xmEyH6JdnMrMdI4ItWvWM
KZQVEyWlx2cM0+dKJLvwgjDpMwHS6xsujxQCw7gaTTgDgsMgOz8dBxjgG/rQP1mK
D7sE2sKVVqwWOTCqOx9U2revpqLv2lD4Hq0Ecrklpph9SPs67YhdnJnWrhr1L8bz
xAd+j+JADbEtgwolWFDhrYS4rmmSm4mNTSAD0+HOCmkjHW0IYsXR/QRSsCzK/OJ0
gJHB3d4eCzk0AWILW12r8fyoJ6U344lNABk3irPQHparAaPxVsREIg35yAROWQP+
dmGefvsYUiR1w6+wUyTbKhttQId0gq8IH7N85yypVFQlHEqTxoUgu8RCOxga4AVA
FIv8ZsdPgfz3MYRvrynqZr+/F2RQ9avcZ8hYe1Ae5nlPaANWFw==
=1LVE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package name of flask_oauthlib

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-03-08 at 19:33 +, Richard Hughes wrote:
> Hi,
> 
> I've packaged up flask_oauthlib to use for a project I'm developing,
> and am close to submitting it for a Fedora package review. I'm
> wondering if the underscore should be used, and the package
> guidelines
> tell me to ask here. The source package could either be:
> 
>  * python-flask_oauthlib
>  * python-flask-oauthlib

I would go with this one.

> The upstream itself is somewhat conflicted, as the module name is
> flask_oauthlib and the source tarball is Flask-OAuthlib. Ideas
> welcome, thanks.
> 
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqht+oACgkQaVcUvRu8
X0yUFhAAu6UwLkoBMOHcI0cFDLtR8QWjpoq201GcROnRx7/+WamqK8jyU2898RFv
17Lb9TDMvwNBhoS6eCkMzw3Kbcy4yg5DdaBxkt1Ufi/NfRFLAGL04sb93agEyVnp
t5HXbF9bVbGvlVKYPhz7KgbxiOmmztV65GUVyIptyRkbPDNfUnh8+QEC5Xz3pmrG
DiVlCI+tjLyQGI3dYrJBns5ARxCwLsek7kNT9+as8uZ8FiQbRqXJ309ermURQ5G1
bUHp3MIvKz0NxTdM2No1e3H9HZ5wrMEI0GUCnRqmlvsVi3QRWfQ7koT4Jz1gZESM
LzqLkABlg3htb3+Jwi0fMlKVFZNmcCggIOCOCbFr+sSiH0+zuYj2cx515kvwRSJc
3PGk4782OotOYOFWcwQVnOuEziQ/c7I2oEX1MnhOldlFksPp3nn10dUd49+cHWy/
5tUTfnb7I24lWpt1sIFt6fXxPbr7nUiXAH+2gQruYfhWbtHWxHYyDLQxTPTKuQVP
HS/hZQV/Nnx5PSzO+eRR4F823lETbAVPbQbZnnQH2PuIAvRXsoTkMa6YmZI9u3Cj
9ezIFwQfvsjQcMKb3CClyBaDo9kHbricZ1UsxXlNyyPXc0gJEjnFkdRIRb4ZL8Ub
N6peHfoF+BZPa6ovpTYSR3GWM+BQ+agcizUHGH0j+dQ8Ex1Cb7Q=
=r1Lj
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libqalculate soname change

[Mukundan Ragavan]

> On Wed, 2018-03-07 at 20:46 -0500, Mukundan Ragavan wrote:
> 
> Thanks for the notification.
> 
> Note F28 is currently in freeze for Beta; this is a long freeze, and
> honestly, might get longer, given the current state of things. So I'm
> not sure whether it'd be optimal to have this committed and built for
> F28, but not able to go stable due to the freeze. Might be better to
> wait till after Beta, *or* get a freeze exception. Is there any
> significant benefit for us in the new libqalculate, which would justify
> a freeze exception?

I was worried about pushing this during freeze as well. While I do want to get 
this pushed out to F28 (this and previous two releases that never made to 
Fedora have bug fixes and new features), I can certainly do so after beta is 
out and freeze is lifted. 

I will build only for rawhide on Friday and leave F28 updates for after the 
freeze is lifted.

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

Re: Broken system upgrade due to rich dependencies

[Dennis Gilmore]

El jue, 08-03-2018 a las 12:55 +0200, Panu Matilainen escribió:
> On 03/08/2018 12:42 PM, Panu Matilainen wrote:
> > On 03/08/2018 12:21 PM, Reindl Harald wrote:
> > > 
> > > 
> > > Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
> > > > P.P.S. So why didn't yum have anything like that? Because back
> > > > then, 
> > > > there were other upgrade methods that did run on the "target
> > > > stack": 
> > > > anaconda, preupgrade, fedup to name a few
> > > 
> > > and i never used one of them - i did hundrets of dist-upgrades
> > > for 
> > > more than a decade on dozens of machines (workstations and
> > > production 
> > > servers) with yum/dnf - full stop
> > 
> > Sure. You just either didn't upgrade between versions that
> > introduced a 
> > new rpmlib() dependency or updated rpm first, one way or the
> > other. 
> 
> ...or the couple of features were introduced in that period were
> done 
> using the one generic solution at hand I did mention in my earlier 
> email: wait until the previous Fedora supports the new feature too 
> before enabling in the new. Come to think of it, I think this was
> mostly 
> the case. It'd be in the ml archives if somebody wants to dig (we're 
> talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload 
> compression being the big ones I can remember offhand)
> 
> Oh, and of course back then it was nearly impossible to introduce
> such 
> features in the first place because the builders were running RHEL. 
> Those couple of features that were introduced required a custom rpm
> to 
> be used on builders. Those were the days... no I dont miss.
> 
I do not miss those days either, but we knew and communicated the
changes. and managed them so upgrades would work. We were careful to
make sure that the change was managed. Maybe too careful. Managing
hybrid systems for building was a pain and I never want to go do that
again.  We do need to make sure that as new rpm/dnf features are
supported that we have everything in place to fully support them,  that
means waiting for a short period of time from being in RPM to being
something we can tell packagers to go and use.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 15:32, Stephen John Smoogen  wrote:
> On 8 March 2018 at 13:38, Nicolas Mailhot  wrote:

> I have spent this afternoon going through many of your emails and our
> logs so I could find try to figure out what to help you. Coming back
> and finding you blaming everyone else is insulting to my time and
> tiresome. You are better than this.
>

You also deserved better from me in that I should have sent that email
only to you versus the entire list. I apologize for my conduct as it
was rude.


>> So it should either not do that or strip the signature when modifying
>> the message.
>>
>> Modern mail systems are so much fun
>>
>> --
>> Nicolas Mailhot
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.



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

Atomic Working Group VFAD 03/09

[Dusty Mabe]

Hi everyone,

This is a reminder that tomorrow we have a VFAD (Virtual Fedora Activity Day) 
for everyone who 
can and wants to join in on the discussions: 
https://pagure.io/atomic-wg/issue/429

--
Location:

https://bluejeans.com/dmabe

--
Topics:

[upstream technology]

  * rpm-ostree rojig - short presentation/demo [5 minutes]
  * rpm-ostree rojig - Q [ max 10 minutes ]
  * podman - pros/cons to including it in the host vs using as a container [ 10 
minutes ]

[community]

  * discussion on whether Project Atomic needs to step away from the "umbrella" 
and make it clear what it's about, spin off projects [ 40 minutes ]

[Atomic Workstation]

  * suggestion for rebranding atomic workstation [ 20 minutes ]
  * dev/pet container tools - gather links to examples/docs [ 10 minutes ]
  * Minimizing content set in FAW [ 10 minutes ]
  o https://pagure.io/workstation-ostree-config/pull-request/74

[Q for users]

  * Q session for atomic host/workstation users [ 20 minutes ]

--

See you there,
Atomic WG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Stephen John Smoogen]

On 8 March 2018 at 13:38, Nicolas Mailhot  wrote:
> Le jeudi 08 mars 2018 à 17:57 +, Tom Hughes a écrit :
>>
>> No, it almost certainly means that laposte.net have announced via
>> their DNS records that emails with laposte.net addresses should not
>> be trusted unless they come direct from a laposte.net server.
>
> Actually, it probably means the fedora listserver broke the DKIM
> signature by appending a list footer  to the message.
>

Laposte is saying your emails are wrong before it gets to the
listserver. As far as I can tell your email goes as follows:



 {sometimes}
 {sometimes}
 {sometimes}





Sometimes your emails get 1 laposte SMTP outbound, and sometimes all
3. Sometimes none of them are being used and the ddns.net one is
talking to fedora directly. Depending on which of the smtp servers you
are going through, one (or more) of them is altering that your DKIM
signature from the previous ones is not valid and changing the subject
line.

I have spent this afternoon going through many of your emails and our
logs so I could find try to figure out what to help you. Coming back
and finding you blaming everyone else is insulting to my time and
tiresome. You are better than this.

> So it should either not do that or strip the signature when modifying
> the message.
>
> Modern mail systems are so much fun
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: unresponsive maintainer: nss-mdns

[Lennart Poettering]

On Do, 08.03.18 16:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Thu, Mar 08, 2018 at 05:45:24PM +0100, Lennart Poettering wrote:
> > On Mo, 05.03.18 20:35, Adam Goode (a...@spicenitz.org) wrote:
> > 
> > > > On Mon, Mar 05, 2018 at 06:45:35PM -, Adam Goode wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > Lennart has the flu, so he'll probably wont' reply immediately.
> > > > I'll ping him, but you can expect that he will want to give the
> > > > package away.
> > > > 
> > > 
> > > Thanks, and I hope he feels better soon.
> > 
> > Yes, I do, thanks!
> > 
> > Yes, please take the package! What do I have to do these days to
> > officially hand it over? Any web form I have to click on?
> 
> Go to https://src.fedoraproject.org/rpms/nss-mdns/settings, and at
> the bottom there 'give the nss-mdns project' field.

Urks. That form doesn't support searching by real name. Adam, what's
you fedora user name?

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Tony Nelson]

On 18-03-07 14:14:38, Nicolas Mailhot wrote:

Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>  wrote:
> > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a  
écrit

> > :
> > >
> > > I don't know if this is useful but in the RHL and early Fedora
> > > days,
> > > the way to do inplace upgrades was to first update just the  
'core'

> > > tools needed by rpm.
>
> This is a totally unrelated comment, but I will personally send you  
$5

> if you can configure your email client to stop adding  in the
> Subject line for every thread you reply to.

I'm pretty sure that's added by one of the MTAs in the chain between
Fedora SMTP and my ISP MTA, to attest they did DKIM verification,  
since

I see it already positioned on some received messages before I ever
replied to them.


Presumably by bastion01.phx2.fedoraproject.org (Postfix), which adds the
lines:

DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.phx2.fedoraproject.org
 2E4116051DFD
Authentication-Results: bastion01.phx2.fedoraproject.org;	 
dkim=fail
 reason="signature verification failed" (2048-bit key)  
header.d=laposte.net

 header.i=@laposte.net header.b="bKrmUuvt"

--

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

Package name of flask_oauthlib

[Richard Hughes]

Hi,

I've packaged up flask_oauthlib to use for a project I'm developing,
and am close to submitting it for a Fedora package review. I'm
wondering if the underscore should be used, and the package guidelines
tell me to ask here. The source package could either be:

 * python-flask_oauthlib
 * python-flask-oauthlib

The upstream itself is somewhat conflicted, as the module name is
flask_oauthlib and the source tarball is Flask-OAuthlib. Ideas
welcome, thanks.

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

Re: Gating packages in Rawhide

[Tom Hughes]

On 08/03/18 19:25, Mattia Verga wrote:

Il 08/03/2018 20:11, Richard Shaw ha scritto:
What about making side tags easily available to packagers directly? I 
could build my package that includes an ABI breaking update and 
rebuild the dependencies within that side tag and then submit when 
everything is complete.




+1

Maybe something like 'fedpkg build --side-tag=pkgname-abichange', that 
would mean to build that package using all packages already with the 
same side tag and tag the build with side-tag.


Well if a side tag exists then you can already choose to build
in it using the --target switch

What would be needed is a way to create a side tag and then
to merge it back.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/08/2018 11:11 AM, Richard Shaw wrote:
> What about making side tags easily available to packagers directly? I could
> build my package that includes an ABI breaking update and rebuild the
> dependencies within that side tag and then submit when everything is
> complete.

Yes, teaching bodhi about side tag management was one idea talked about.

Then you would do:

* get a side tag from bodhi
* build all your stuff, test it, etc.
* submit update with all those builds
* CI/automated tests run on it, and if all is ok goes out in the next
rawhide compose.
* If not ok, you could wave the results or build more things/edit the
update until it passes.

The only downsides to this is that it means more code for bodhi, and
more newrepos for koji.

kevin




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: Gating packages in Rawhide

[Mattia Verga]

Il 08/03/2018 20:11, Richard Shaw ha scritto:
What about making side tags easily available to packagers directly? I 
could build my package that includes an ABI breaking update and 
rebuild the dependencies within that side tag and then submit when 
everything is complete.




+1

Maybe something like 'fedpkg build --side-tag=pkgname-abichange', that 
would mean to build that package using all packages already with the 
same side tag and tag the build with side-tag.
After all the packages are rebuilt, a simple command like 'fedpkg enable 
side-tag' will push all the packages with side-tag to testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Richard Shaw]

What about making side tags easily available to packagers directly? I could
build my package that includes an ABI breaking update and rebuild the
dependencies within that side tag and then submit when everything is
complete.

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

Re: Gating packages in Rawhide

[Mattia Verga]

Il 08/03/2018 19:00, Randy Barlow ha scritto:

As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, similar to how we use it for our stable/branched
releases, with more relaxed rules (perhaps 1 day in testing or something
simple).


Rawhide is a place where ABI changes are (quite) common. Having the 
builds pushed to a testing repo and managing them by body means that we 
would have more work to create buildroot overrides.


I think this change would imply changing the default tag assigned to a 
Rawhide build from (for example) 'f29' to 'f29-testing', doesn't it? So, 
what about giving maintainers the capability to force back the tag to 
'f29', overriding the default directly from the 'fedpkg build' command 
(only for Rawhide)?
This way, if a maintainer needs that build to be pushed directly to 
Rawhide for rebuilding dependent packages he can do that without going 
all over the buildroot override steps.

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

Re: Trying out More Go Packaging: Bugs and Questions

[Robert-André Mauchin]

On jeudi 8 mars 2018 16:37:57 CET Jan Chaloupka wrote:
> On 03/07/2018 04:07 PM, Jan Chaloupka wrote:
> >
> > Saying that, I will prepare new builds of gofed so the new spec files 
> > are generated with the new macros.
> 
> 
> F27 gofed build: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-52f059bf00
> F28 gofed build: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-13edd2e62f
> 


Can I suggest a few thing?

 - Add a switch to disable the tests like before. I use bcond_without:

# Run tests in check section
%bcond_without check

%if %{with check}
BuildRequires: golang(github.com/stretchr/testify/assert)
BuildRequires: golang(github.com/bmizerany/assert)
%endif

%if %{with check}
%check
%gochecks
%endif

 - Try to grab the packager name from Git like they do in rust2rpm:

def detect_packager():
rpmdev_packager = shutil.which("rpmdev-packager")
if rpmdev_packager is not None:
return subprocess.check_output(rpmdev_packager, 
universal_newlines=True).strip()

git = shutil.which("git")
if git is not None:
name = subprocess.check_output([git, "config", "user.name"], 
universal_newlines=True).strip()
email = subprocess.check_output([git, "config", "user.email"], 
universal_newlines=True).strip()
return "{} <{}>".format(name, email)

return None

 - why does it needs sudo to run sometimes?

 - This is not needed anymore, even on EPEL7:

#define license tag if not already defined
%{!?_licensedir:%global license %doc}

 - would it be possible to check the dependencies on https://
src.fedoraproject.org/ instead of pkgdb which is outdated.

 - would it be possible to detect if a repo has a tagged release and use it 
instead of a commit if it's detected

Best regards,

Robert-André

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

Re: Gating packages in Rawhide

[Kevin Fenzi]

On 03/08/2018 10:00 AM, Randy Barlow wrote:
> Greetings fellow Fedorans!
> 
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.

I was hoping we could come up with a more detailed proposal for the
community at the upcoming Infrastructure hackfest, but sure we could
start the discussion now.

> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi on Rawhide, similar to how we use it for our stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or something
> simple).

I don't think a testing will be of help here. Who would run with it
enabled? I'm much prefer we just use the gating to run automated tests
and get the update out as quickly as we can after that.
> 
> It may be possible to automate the process a bit to make it less heavy
> for developers, though there is some complication for multi-package
> updates (more on that in a bit). For simple package updates, we may be
> able to detect new commits on dist-git, and react to those by
> automatically starting a Koji build, and automatically filing a Bodhi
> update when that build is complete. I think that would be pretty nice,
> and pingou created a PoC[0] to do this about a year ago.

This has nice appeal for simple standalone updates...

> Multi-package updates won't be so easy though. It's not uncommon for us
> to need to update packages together, and the above workflow would be
> problematic since it would result in updates with single packages in
> them rather than updates with multiple packages. Of course, buildroot
> overrides would be a problem too, since multi-package updates often
> depend on each other at build time too.
> 
> We could create some way for packagers to indicate that a commit (or
> possibly even a whole repo) is not intended to be "autobuilt/updated".
> If the packager indicates this then their builds would go into a
> rawhide-pending (similar to what we do for f27 today). Once they have
> all their builds (and buildroot overrides) the way they want them, they
> can create the update.

having to file overrides would be a pretty big drag for people like the
KDE/Gnome teams... but I suppose they do it somehow in stable updates now.

> Another idea that was tossed around in some chats I had with people
> about this involved a system for packagers to use to create Koji side
> tags. Bodhi manages BuildRoot Overrides today (with expirations), so
> perhaps Bodhi could be expanded to also manage Koji side tags (also with
> expirations). I can't remember all the details about this approach or
> why it was suggested over the former approach, but I wanted to list it
> to invite others to chew on it and see if it could work.

This approach has the advantage of not needing buildroot overrides, you
just build all the things into the side tag in whatever order needed.
The downside is that these would take koji cycles to keep doing newrepos
for.

I was org not in favor of using bodhi, but it was noted that this is the
one place we have now for test results and gating, so I kind of think we
do need to use it now. That allows us to reuse it and waverdb, etc.

I really don't want to slow rawhide down or put barriers in place for
maintainers, so I think we need to make things as painless as we can.

kevin



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: Gating packages in Rawhide

[Randy Barlow]

On 03/08/2018 01:32 PM, Michael Cronenworth wrote:
> Why must the process change? It seems every bit of Fedora in the past
> year has been changing... for the sake of change.

We've had extreme issues with stability in Rawhide lately that could
have been prevented with automated testing. These issues cost a lot of
time from infrastructure, QA, and release engineering members. They also
caused us to be unable to compose Rawhide and Fedora 28 for quite some
time. Not all of these issues would have been caught by package gating,
but some would.

> I'm going to speak up now and be a little more involved.

+1!

> Do you want Rawhide used the same as Fedora N releases? If you want that
> I propose we remove Fedora N-1 releases. When branched occurs I have to
> switch branches four times. I'd much rather invest time in removing the
> need to support Fedora N-1 and if that means gating for Rawhide I can
> get on board.

I don't think making Rawhide used the same as Fedora N releases is the
goal here, though I think it would also improve things for people who do
choose to use Rawhide. I personally think we should continue to support N-1.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 17:57 +, Tom Hughes a écrit :
> 
> No, it almost certainly means that laposte.net have announced via
> their DNS records that emails with laposte.net addresses should not
> be trusted unless they come direct from a laposte.net server.

Actually, it probably means the fedora listserver broke the DKIM
signature by appending a list footer  to the message.

So it should either not do that or strip the signature when modifying
the message.

Modern mail systems are so much fun

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

Re: Gating packages in Rawhide

[Michael Cronenworth]

On 03/08/2018 12:00 PM, Randy Barlow wrote:

If you have other suggestions on how we might gate packages in Rawhide
that are wildly different than the above, please feel free to share!


Why must the process change? It seems every bit of Fedora in the past year has been 
changing... for the sake of change. I'm going to speak up now and be a little more 
involved.


Do you want Rawhide used the same as Fedora N releases? If you want that I propose 
we remove Fedora N-1 releases. When branched occurs I have to switch branches four 
times. I'd much rather invest time in removing the need to support Fedora N-1 and if 
that means gating for Rawhide I can get on board.

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

Gating packages in Rawhide

[Randy Barlow]

Greetings fellow Fedorans!

I would like to kick off a general discussion about how we might gate
packages in Rawhide. I think it would be nice to get something in place
for the Fedora 29 timeframe.

As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, similar to how we use it for our stable/branched
releases, with more relaxed rules (perhaps 1 day in testing or something
simple).

It may be possible to automate the process a bit to make it less heavy
for developers, though there is some complication for multi-package
updates (more on that in a bit). For simple package updates, we may be
able to detect new commits on dist-git, and react to those by
automatically starting a Koji build, and automatically filing a Bodhi
update when that build is complete. I think that would be pretty nice,
and pingou created a PoC[0] to do this about a year ago.

Multi-package updates won't be so easy though. It's not uncommon for us
to need to update packages together, and the above workflow would be
problematic since it would result in updates with single packages in
them rather than updates with multiple packages. Of course, buildroot
overrides would be a problem too, since multi-package updates often
depend on each other at build time too.

We could create some way for packagers to indicate that a commit (or
possibly even a whole repo) is not intended to be "autobuilt/updated".
If the packager indicates this then their builds would go into a
rawhide-pending (similar to what we do for f27 today). Once they have
all their builds (and buildroot overrides) the way they want them, they
can create the update.

Another idea that was tossed around in some chats I had with people
about this involved a system for packagers to use to create Koji side
tags. Bodhi manages BuildRoot Overrides today (with expirations), so
perhaps Bodhi could be expanded to also manage Koji side tags (also with
expirations). I can't remember all the details about this approach or
why it was suggested over the former approach, but I wanted to list it
to invite others to chew on it and see if it could work.

If you have other suggestions on how we might gate packages in Rawhide
that are wildly different than the above, please feel free to share!


[0] https://pagure.io/fedobuild



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: Broken system upgrade due to rich dependencies

[Tom Hughes]

On 08/03/18 17:46, Nicolas Mailhot wrote:

Le jeudi 08 mars 2018 à 18:11 +0100, Fabio Valentini a écrit :


Additionally, I frequently get Spam warnings for your e-mails because
they don't pass the validation tests for being sent from a laposte.net
address.


That tells a lot more about USA operators being not willing to work with
non USA operators than anything else.


No, it almost certainly means that laposte.net have announced via
their DNS records that emails with laposte.net addresses should not
be trusted unless they come direct from a laposte.net server.

Of course when you send email to a mailing list the list has to
resend it, meaning it no longer appears to come from a laposte.net
server and an recipient that acts on the announced policy will
wind up rejecting it.

The act of making that announcement is the problem because it is
based on a fundamental misunderstanding of how email is used.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8 ABI change on x86_64

[Jakub Jelinek]

On Thu, Mar 08, 2018 at 05:52:05PM +, Sérgio Basto wrote:
> On Thu, 2018-03-08 at 10:25 +0100, Marek Polacek wrote:
> > On Wed, Mar 07, 2018 at 07:20:18PM +, Sérgio Basto wrote:
> > > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > > > I did another mass rebuild with a specially-tweaked gcc in order
> > > > to
> > > > find out
> > > > which packages need to be rebuild with patched gcc-8.0.1-0.16. 
> > > 
> > > How we find out the same problem in packages from external repos ? 
> > 
> > I don't know; I've only rebuilt all rawhide packages.  
> 
> You rebuilt all packages and found what packages was different ? that'sit ? 

The bug affected solely x86_64 and the test mass rebuilt was thus performed
solely on x86_64, on non-koji boxes (even when the compiler for checking
this was twice as slow as normally).  Rebuilding all packages again on all
architectures would be certainly much more CPU time.

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

unproductive finger pointing; was: Re: Broken system upgrade due to rich dependencies

[R P Herrold]

On Thu, 8 Mar 2018, Nicolas Mailhot wrote:

> That tells a lot more about USA operators being not willing to work with
> non USA operators than anything else.

ehh?

from the headers in that post, as received by me:

X-Authentication-Results: bastion01.phx2.fedoraproject.org;
dkim=fail reason="signature verification failed" (2048-bit key)
header.d=laposte.net header.i=@laposte.net header.b="EPfsBz5c"

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

Re: GCC 8 ABI change on x86_64

[Sérgio Basto]

On Thu, 2018-03-08 at 10:25 +0100, Marek Polacek wrote:
> On Wed, Mar 07, 2018 at 07:20:18PM +, Sérgio Basto wrote:
> > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > > I did another mass rebuild with a specially-tweaked gcc in order
> > > to
> > > find out
> > > which packages need to be rebuild with patched gcc-8.0.1-0.16. 
> > 
> > How we find out the same problem in packages from external repos ? 
> 
> I don't know; I've only rebuilt all rawhide packages.  

You rebuilt all packages and found what packages was different ? that'sit ? 

> Were the external
> packages built with gcc 8? 

RPMFusion

> If not, we're fine.
> 
>   Marek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 18:11 +0100, Fabio Valentini a écrit :
> 
> Additionally, I frequently get Spam warnings for your e-mails because
> they don't pass the validation tests for being sent from a laposte.net
> address.

That tells a lot more about USA operators being not willing to work with
non USA operators than anything else.

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

Re: libqalculate soname change

[Adam Williamson]

On Thu, 2018-03-08 at 10:15 -0500, Przemek Klosowski wrote:
> 
> Having said that, I could see there might be a case for delaying the 
> freeze before it starts, if the overall schedule is delayed for 
> well-understood reasons.

This cycle was actually kind of an interesting case, because on the one
hand, there's a pretty good argument that we were in a very bad state
at freeze time this cycle. On the *other* hand, one of the main reasons
we were in a bad state is because people kept frickin' landing de-
stabilizing changes while we were still dealing with the fallout from
the previous de-stabilizing change: we've had GCC 8, various
unannounced soname bumps, basically all of nu-Modularity showing up in
the middle there somewhere, anaconda modularization, new versions of
pungi and pykickstart and systemd, and that's just the things I
*remember*. It's been something of a wild ride.

Freezing at least stops any *more* wacky new crap landing while we're
still trying to sort out the remains of this last batch.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libqalculate soname change

[Adam Williamson]

On Thu, 2018-03-08 at 15:51 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Note F28 is currently in freeze for Beta; this is a long freeze, and
> > honestly, might get longer, given the current state of things.
> 
> IMHO, if we know that we are not in a good enough state to release, we 
> should delay the start of the freeze (in the current case where it has 
> already started: cancel the freeze and try again later) until we are in a 
> releasable state. It just does not make sense to extend the freezes forever. 
> We should only freeze if we are actually ready to prepare a release (e.g. 
> F28 Beta).

This is actually being kicked around informally ATM, but I don't know
where we're going to end up yet.

> And there really needs to be a maximum freeze period. If we are still not 
> ready to go gold by then, we need to take all the pending packages and 
> restart the process from there.

In most cases this is a *really bad* idea as it will almost inevitably
mean the freeze (once restored) gets longer again, as it's almost
certainly going to be the case that some of the changes blocked by the
freeze cause new issues. That's *why we have the freeze*, after all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Yanko Kaneti]

On Thu, 2018-03-08 at 17:47 +0100, Nicolas Mailhot wrote:
> Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
> > 
> > Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
> > because nobody but you would see it.
> 
> And what, exactly, do you think answers to those mails look like once
> they had this added on the incoming route? You're not thinking it
> through.

Well, what the answers look like is entirely controlled by your email
client and your outgoing MTA.

I was indeed overthinking it. The simplest explanation of course is that
you personally don't care what crap ends in the subjects of your
replies, so you are just hitting reply and just spreading whatever your
incoming MTA tags on the Subject.

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

Re: Re: Broken system upgrade due to rich dependencies

[Fabio Valentini]

On Thu, Mar 8, 2018 at 5:47 PM, Nicolas Mailhot
 wrote:
> Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
>>
>> Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
>> because nobody but you would see it.
>
> And what, exactly, do you think answers to those mails look like once
> they had this added on the incoming route? You're not thinking it
> through.

For what it's worth, the only mails that start new threads (because of
the added "RE: " to the Subject line) are sent by you, Nicolas.
Additionally, I frequently get Spam warnings for your e-mails because
they don't pass the validation tests for being sent from a laposte.net
address.
So it really looks like there's something wrong with your setup.

Fabio

> --
> Nicolas Mailhot
> ___
> 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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1095  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 858  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 440  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 337  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 169  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 106  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  56  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aacf1b47d6   
clamav-0.99.4-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-815e0064e9   
tor-0.2.9.15-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f7a629b46f   
python-django16-1.6.11.7-1.el7


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

fedfind-4.1.1-1.el7
gpaste-3.22.6-1.el7
lcgdm-dav-0.20.0-1.el7
nmh-1.7.1-1.el7
php-cs-fixer-2.2.18-1.el7
php-pecl-psr-0.4.0-2.el7
python-ddt-1.1.2-1.el7
xalan-c-1.11.0-4.el7
xml-security-c-1.7.3-4.el7

Details about builds:



 fedfind-4.1.1-1.el7 (FEDORA-EPEL-2018-8d4e936882)
 Fedora compose and image finder

Update Information:

This update provides a new release of fedfind, which adapts the
`expected_images` for a few `Release` classes, and `const.SUBVARIANTS`, for the
renaming of the `Atomic` and `Workstation Ostree` (sub)variants in Fedora 28+
(see [this pull request](https://pagure.io/pungi-fedora/pull-request/498)).




 gpaste-3.22.6-1.el7 (FEDORA-EPEL-2018-2a0f117f18)
 Clipboard management system

Update Information:

* fix regression in gnome-shell extension * fix memory leaks in images support *
silence a warnings in the gnome-shell extension

References:

  [ 1 ] Bug #1552961 - gpaste-3.26.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1552961




 lcgdm-dav-0.20.0-1.el7 (FEDORA-EPEL-2018-f4f265f1ad)
 HTTP/DAV front end to the DPM/LFC services

Update Information:

Bugfixes and improvements. Includes an important fix for the Dynafed usecase
related to Auth headers.




 nmh-1.7.1-1.el7 (FEDORA-EPEL-2018-0e4ac8d2df)
 A capable MIME-email-handling system with a command-line interface

Update Information:

Updated nmh to 1.7.1.




 php-cs-fixer-2.2.18-1.el7 (FEDORA-EPEL-2018-6d14780d7e)
 A tool to automatically fix PHP code style

Update Information:

Changelog for v2.2.18 -  * bug #3446 Add PregWrapper
(kubawerlos) * bug #3464 IncludeFixer - fix incorrect order of fixing
(kubawerlos, SpacePossum) * bug #3496 Bug in Tokens::removeLeadingWhitespace
(kubawerlos, SpacePossum, keradus) * bug #3557 AbstractDoctrineAnnotationFixer:
edge case bugfix (Slamdunk) * bug #3574 GeneralPhpdocAnnotationRemoveFixer -
remove PHPDoc if no content is left (SpacePossum) * minor #3563 DX add missing
covers annotations (keradus) * minor #3565 Use EventDispatcherInterface instead
of EventDispatcher when possible (keradus) * minor #3572 DX: allow for more

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 968  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 858  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 829  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 440  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 169  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  88  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  60  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  23  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7e91105260   
clamav-0.99.4-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a27d71c715   
pax-utils-1.2.3-1.el6


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

fedfind-4.1.1-1.el6
lcgdm-dav-0.20.0-1.el6
nmh-1.7.1-1.el6

Details about builds:



 fedfind-4.1.1-1.el6 (FEDORA-EPEL-2018-8f1ce5d95e)
 Fedora compose and image finder

Update Information:

This update provides a new release of fedfind, which adapts the
`expected_images` for a few `Release` classes, and `const.SUBVARIANTS`, for the
renaming of the `Atomic` and `Workstation Ostree` (sub)variants in Fedora 28+
(see [this pull request](https://pagure.io/pungi-fedora/pull-request/498)).




 lcgdm-dav-0.20.0-1.el6 (FEDORA-EPEL-2018-04f9fa55e5)
 HTTP/DAV front end to the DPM/LFC services

Update Information:

Bugfixes and improvements. Includes an important fix for the Dynafed usecase
related to Auth headers.




 nmh-1.7.1-1.el6 (FEDORA-EPEL-2018-a097db48ad)
 A capable MIME-email-handling system with a command-line interface

Update Information:

Updated nmh to 1.7.1.

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

Re: unresponsive maintainer: nss-mdns

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 08, 2018 at 05:45:24PM +0100, Lennart Poettering wrote:
> On Mo, 05.03.18 20:35, Adam Goode (a...@spicenitz.org) wrote:
> 
> > > On Mon, Mar 05, 2018 at 06:45:35PM -, Adam Goode wrote:
> > > 
> > > Hi,
> > > 
> > > Lennart has the flu, so he'll probably wont' reply immediately.
> > > I'll ping him, but you can expect that he will want to give the
> > > package away.
> > > 
> > 
> > Thanks, and I hope he feels better soon.
> 
> Yes, I do, thanks!
> 
> Yes, please take the package! What do I have to do these days to
> officially hand it over? Any web form I have to click on?

Go to https://src.fedoraproject.org/rpms/nss-mdns/settings, and at
the bottom there 'give the nss-mdns project' field.

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

Re: Re: Broken system upgrade due to rich dependencies

[Nicolas Mailhot]

Le jeudi 08 mars 2018 à 18:15 +0200, Yanko Kaneti a écrit :
> 
> Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds
> because nobody but you would see it.

And what, exactly, do you think answers to those mails look like once
they had this added on the incoming route? You're not thinking it
through.

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

Re: unresponsive maintainer: nss-mdns

[Lennart Poettering]

On Mo, 05.03.18 20:35, Adam Goode (a...@spicenitz.org) wrote:

> > On Mon, Mar 05, 2018 at 06:45:35PM -, Adam Goode wrote:
> > 
> > Hi,
> > 
> > Lennart has the flu, so he'll probably wont' reply immediately.
> > I'll ping him, but you can expect that he will want to give the
> > package away.
> > 
> 
> Thanks, and I hope he feels better soon.

Yes, I do, thanks!

Yes, please take the package! What do I have to do these days to
officially hand it over? Any web form I have to click on?

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

[Yanko Kaneti]

On Wed, 2018-03-07 at 20:14 +0100, Nicolas Mailhot wrote:
> Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> > On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
> >  wrote:
> > > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a
> > > écrit
> > > :
> > > > 
> > > > I don't know if this is useful but in the RHL and early Fedora
> > > > days,
> > > > the way to do inplace upgrades was to first update just the
> > > > 'core'
> > > > tools needed by rpm.
> > 
> > This is a totally unrelated comment, but I will personally send you
> > $5
> > if you can configure your email client to stop adding  in the
> > Subject line for every thread you reply to.
> 
> I'm pretty sure that's added by one of the MTAs in the chain between
> Fedora SMTP and my ISP MTA, to attest they did DKIM verification,
> since
> I see it already positioned on some received messages before I ever
> replied to them.

Nobody would care if a MTA on the way Fedora-ml->your-mailbox adds it ,
because nobody but you would see it.

The problem is that (perhaps the same) MTA on the way 
your-email-client->fedora-ml does it. 


> And not all of them, only for senders that use a mail host that
> provides
> DKIM info.

Perhaps that middle box MTA that you are relaying through thinks the
same about your initial sending host and adds it to all your outgoing
mail.


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

[Bug 1551819] perl-Test2-Suite-0.000104 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Test-Simple-1.302130-1.fc28 perl-Test2-Suite-0.000106-1.fc28 has been
submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4420e51431

-- 
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 1552358] perl-Test2-Suite-0.000106 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Test-Simple-1.302130-1.fc28 perl-Test2-Suite-0.000106-1.fc28 has been
submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4420e51431

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

Schedule for Friday's FESCo Meeting (2018-03-09)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

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

or run:
  date -d '2018-03-09 15:00 UTC'


Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1853 F29 System Wide Change: Enable dbus-broker
.fesco 1853
https://pagure.io/fesco/issue/1853

#topic #1845 389-ds-base and freeipa on 32 bit arches
.fesco 1845
https://pagure.io/fesco/issue/1845

#topic #1820 Adjust/Drop/Document batched updates policy
.fesco 1820
https://pagure.io/fesco/issue/1820

#topic #1745 F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
.fesco 1745
https://pagure.io/fesco/issue/1745

#topic FESCo meeting time

= New business =

#topic #1861 F28 Changes not in ON_QA status (<100% completed)
.fesco 1861
https://pagure.io/fesco/issue/1861

#topic #1859 Review of release blocking deliverables for F28
.fesco 1859
https://pagure.io/fesco/issue/1859

#topic #1858 Proposed Fedora 29 schedule
.fesco 1858
https://pagure.io/fesco/issue/1858

#topic #1860 allow major version bump of rpkg utility 
.fesco 1860
https://pagure.io/fesco/issue/1860

= Open Floor = 

For more complete details, please visit each individual issue. The
report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can reply to
this e-mail, file a new issue at https://pagure.io/fesco, e-mail me
directly, or bring it up at the end of the meeting, during the open
floor topic. Note that added topics may be deferred until the
following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libqalculate soname change

[Randy Barlow]

On 03/08/2018 09:51 AM, Kevin Kofler wrote:
> IMHO, if we know that we are not in a good enough state to release, we 
> should delay the start of the freeze (in the current case where it has 
> already started: cancel the freeze and try again later) until we are in a 
> releasable state. It just does not make sense to extend the freezes forever. 
> We should only freeze if we are actually ready to prepare a release (e.g. 
> F28 Beta).

This would be counter to the goal of the freeze - we freeze so we can
stabilize things and get the release out the door. If we unfreeze, we
only decrease the stability.



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: Trying out More Go Packaging: Bugs and Questions

[Jan Chaloupka]

On 03/07/2018 04:07 PM, Jan Chaloupka wrote:



On 03/07/2018 04:02 PM, Jan Chaloupka wrote:



On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:

On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:

Hi Robert-André,

thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. 
Making

the packaging experience as easy as possible at the same time.



Can we already use the new guidelines in "production"? Should I 
recommed their
use in the Golang Package Review? Or should we still wait for you to 
adjust

the finer details?


Go for it :) We still can not guarantee the macros will not change 
their API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes 
are in macro implementation only.

In case there is macro incompatible change we will let you know.



Saying that, I will prepare new builds of gofed so the new spec files 
are generated with the new macros.


F27 gofed build: 
https://bodhi.fedoraproject.org/updates/FEDORA-2018-52f059bf00
F28 gofed build: 
https://bodhi.fedoraproject.org/updates/FEDORA-2018-13edd2e62f




Nicolas, can you more elaborate on that? I don't see any more reason 
why we should block folks from relying on the new macros.



Also will this be available for EPEL7 too?


I hope they will be. Thought, it will be not so trivial cause RHEL 
has different policies. It will take some time.




Best regards,

Robert-André


___
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

___
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

[Bug 1552960] perl-Log-Dispatch-FileRotate-1.35 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Log-Dispatch-FileRotate-1.35-1.fc28 has been pushed to the Fedora 28
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9cb96b97de

-- 
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 719874] perl-threads-lite keeps hanging during self checks

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|CLOSED  |ON_QA
 Resolution|NEXTRELEASE |---



--- Comment #17 from Fedora Update System  ---
perl-threads-lite-0.034-13.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-95f1522681

-- 
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 1549504] perl-Event-Lib-1.03-35.fc29 FTBFS: Lib.xs:131:14: error: ' struct event' has no member named 'ev_arg'

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Event-Lib-1.03-37.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-66d5557fbd

-- 
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 1551819] perl-Test2-Suite-0.000104 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Test-Simple-1.302128-1.fc28, perl-Test2-Suite-0.000106-1.fc28 has been
pushed to the Fedora 28 testing repository. If problems still persist, please
make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4420e51431

-- 
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 1552358] perl-Test2-Suite-0.000106 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Test-Simple-1.302128-1.fc28, perl-Test2-Suite-0.000106-1.fc28 has been
pushed to the Fedora 28 testing repository. If problems still persist, please
make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4420e51431

-- 
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: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

[Christopher]

On Thu, Mar 8, 2018 at 10:02 AM William Cohen  wrote:

> On 03/07/2018 02:43 AM, Igor Gnatenko wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > This is the second iteration of my mass-scratch-rebuild without
> > gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> > original mail still applies.
> >
> > Since people might have fixed their packages after I started rebuild, I
> > decided to include information about commits I have used to build
> > packages. Hope this helps.
> >
> >
> > New list of packages, their commits and build logs are available:
> > * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
> > * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx
> > t
> > * https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt
>

I've fixed hadoop, thrift, monkeysphere, and zookeeper, but there are
continued unrelated build failures in some, which I still need to fix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libqalculate soname change

[Przemek Klosowski]

On 03/08/2018 09:51 AM, Kevin Kofler wrote:

Adam Williamson wrote:

Note F28 is currently in freeze for Beta; this is a long freeze, and
honestly, might get longer, given the current state of things.

IMHO, if we know that we are not in a good enough state to release, we
should delay the start of the freeze (in the current case where it has
already started: cancel the freeze and try again later) until we are in a
releasable state. It just does not make sense to extend the freezes forever.
We should only freeze if we are actually ready to prepare a release (e.g.
F28 Beta).


You are speaking from the point of view of scheduling, but the reason 
for the freeze is to stabilize things during the release process.


Clearly it is not acceptable to extend the freezes forever if the 
release process is not going well, but the solution is to fix the 
problems which delay the release, not compound them by unfreezing in the 
middle of the process.


Having said that, I could see there might be a case for delaying the 
freeze before it starts, if the overall schedule is delayed for 
well-understood reasons.


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

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Kevin Kofler]

I wrote:
> Fedora:
>> Beta and Final freezes are in effect from 00:00 UTC of the freeze day.
> 
> KDE:
>> All deadlines are due 23:59 UTC, but if you need a few more hours, notify
>> someone from the release team.

PS: The deadlines I encountered for academic CfPs were also KDE style (23:59 
in a specified time zone), or in very rare occasions at a specified time 
during the say, e.g., noon (12:00), but never Fedora style (00:00).

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

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 02:23 PM, Neal Gompa wrote:

On Thu, Mar 8, 2018 at 6:48 AM, Panu Matilainen  wrote:

On 03/08/2018 01:39 PM, Neal Gompa wrote:


On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen 
wrote:


On 03/07/2018 03:10 PM, Neal Gompa wrote:



On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:



And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.



Bottom line: either dnf (or something else) grows an dist-upgrade method
that runs the transaction on the "target stack" OR Fedora is *forced* to
hold back on new rpm package features until all the active versions have
a
rpm/dnf stack that can handle them. Period. No ifs or buts.

P.S. No, updating rpm + dnf first in a separate transaction is not a
solution at all.



You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more.



It's not a solution because doing so usually drags half the distro along due
to library dependencies etc.



I suppose part of this is because the way we package libraries makes
it so that new library packages _must_ replace older ones as sonames
change. In Mageia and openSUSE, it doesn't work like that at all.
You'll get your new library dependencies for the RPM stack and then it
would re-execute with that target, and then upgrade the remainder of
the system.


Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.



No, preupgrade & friends basically created a special boot target that runs
the whole thing with the new version, in an isolated environment. Which
equals "using the target rpm stack" in fact.



In my mind, that's functionally equivalent. Yes, it's not actually on
the target yet, but it operates under the newer rpm environment.


This sounds like there's supposedly a disagreement somewhere in there 
but I don't know what it is. Details about how exactly preupgrade and 
friends went about their business maybe, but ultimately they did exactly 
what is being discussed: run the upgrade transaction on the target 
stack, because they created/downloaded/whatever a minimal environemnt 
from which to chroot-upgrade the actual root. That is *the* generic 
solution to this whole thing. Clearly there was something wrong with 
preupgrade & all or they wouldn't have been abandoned, but they did that 
one thing right.




And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



That's quite a different thing, and creates it's own quirks and issues. And
it doesn't help things at all when the simple "dnf update rpm dnf" drags
along for example a new glibc or python version which snowballs into 70% of
the distro getting pulled into the "just update rpm" transaction.



New glibc versions by itself should not snowball into 70% of
distribution, otherwise something is broken with how the dependencies
are versioned.

As for pulling in a new Python, you're right that it's an issue, but
it's an issue no matter what. Even when it's in the same transaction,
it's all broken until everything is upgraded anyway. And if we're
talking about this being done with system-upgrade or dist-upgrade
commands, then we can reasonably expect that we can upgrade a subset
first, then restart DNF with the new stack, and pass in the remainder
of the transaction to complete.

That said, stuff like this with the Python stuff makes me think we
should have pythonX.Y-foo packages that have Obsoletes/Provides
pythonX-foo instead, so that stuff wouldn't actually break like this.
But that's another discussion...

And also, PackageKit offline upgrades wouldn't be affected by the
Python bit and could happily do this "properly", if the Python bit is
what you're worried about.


Python is just one example, PackageKit (like almost everything) has 
their non-trivial dependencies that also snowball.


>

Another way to solve that problem would be to have a minimal C/C++
implementation that DNF would hand off to for system upgrades to avoid
the Python issue. Personally, I don't think that's necessary, all
things considered, but it's an option.

But I think we *really* should have the splitting 

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

[William Cohen]

On 03/07/2018 02:43 AM, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.
> 
> Since people might have fixed their packages after I started rebuild, I
> decided to include information about commits I have used to build
> packages. Hope this helps.
> 
> 
> New list of packages, their commits and build logs are available:
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx
> t
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt

oprofile has the build requires added
sediment doesn't actually use gcc/gcc-c++ the configure has been updated to 
avoid this false positive

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

Re: libqalculate soname change

[Kevin Kofler]

Adam Williamson wrote:
> Note F28 is currently in freeze for Beta; this is a long freeze, and
> honestly, might get longer, given the current state of things.

IMHO, if we know that we are not in a good enough state to release, we 
should delay the start of the freeze (in the current case where it has 
already started: cancel the freeze and try again later) until we are in a 
releasable state. It just does not make sense to extend the freezes forever. 
We should only freeze if we are actually ready to prepare a release (e.g. 
F28 Beta).

And there really needs to be a maximum freeze period. If we are still not 
ready to go gold by then, we need to take all the pending packages and 
restart the process from there.

It is just not workable to have everything shut down (including updates to 
stable releases if we care about upgrade paths!) for 3+ weeks at a time.

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

gnome-shell-extension - gschemas.compiled is no created

[Martin Gansser]

Hi,

When creating the package gnome-shell-extension-media-player-indicator, no 
gschemas.compiled is created.
rpm spec file:
https://src.fedoraproject.org/cgit/rpms/gnome-shell-extension-media-player-indicator.git/tree/gnome-shell-extension-media-player-indicator.spec

What is going wrong ?
regards Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Neal Gompa]

On Thu, Mar 8, 2018 at 6:48 AM, Panu Matilainen  wrote:
> On 03/08/2018 01:39 PM, Neal Gompa wrote:
>>
>> On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen 
>> wrote:
>>>
>>> On 03/07/2018 03:10 PM, Neal Gompa wrote:


 On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
  wrote:
>
>
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).
>

 This has been requested for a long time:
 https://bugzilla.redhat.com/show_bug.cgi?id=1032541

 It'd be *really* good if DNF implemented it.
>>>
>>>
>>> Bottom line: either dnf (or something else) grows an dist-upgrade method
>>> that runs the transaction on the "target stack" OR Fedora is *forced* to
>>> hold back on new rpm package features until all the active versions have
>>> a
>>> rpm/dnf stack that can handle them. Period. No ifs or buts.
>>>
>>> P.S. No, updating rpm + dnf first in a separate transaction is not a
>>> solution at all.
>>>
>>
>> You're right in that upgrading rpm + dnf + libsolv first won't fix it
>> 100% of the time (mainly with features that can't be guarded by
>> rpmlib() dependencies, such as the new header size), but I think it'll
>> deal with more than 80% of the cases where we have a problem, such
>> that distribution upgrades through this mechanism will work as we
>> introduce new features in the distribution.
>>
>> But I would disagree that updating rpm + dnf first is not a solution
>> at all. It's not a *perfect* solution, but it would help a hell of a
>> lot more.
>
>
> It's not a solution because doing so usually drags half the distro along due
> to library dependencies etc.
>

I suppose part of this is because the way we package libraries makes
it so that new library packages _must_ replace older ones as sonames
change. In Mageia and openSUSE, it doesn't work like that at all.
You'll get your new library dependencies for the RPM stack and then it
would re-execute with that target, and then upgrade the remainder of
the system.

>> Hell, even preupgrade and older mechanisms more or less
>> worked by getting the target rpm and package manager code installed
>> first and then doing the real thing using that code.
>
>
> No, preupgrade & friends basically created a special boot target that runs
> the whole thing with the new version, in an isolated environment. Which
> equals "using the target rpm stack" in fact.
>

In my mind, that's functionally equivalent. Yes, it's not actually on
the target yet, but it operates under the newer rpm environment.

>>
>> And supporting transaction ordering such that transactions can be
>> broken up into smaller ones as needed based on various conditions
>> would make upgrades more reliable in general, in my opinion.
>>
>
> That's quite a different thing, and creates it's own quirks and issues. And
> it doesn't help things at all when the simple "dnf update rpm dnf" drags
> along for example a new glibc or python version which snowballs into 70% of
> the distro getting pulled into the "just update rpm" transaction.
>

New glibc versions by itself should not snowball into 70% of
distribution, otherwise something is broken with how the dependencies
are versioned.

As for pulling in a new Python, you're right that it's an issue, but
it's an issue no matter what. Even when it's in the same transaction,
it's all broken until everything is upgraded anyway. And if we're
talking about this being done with system-upgrade or dist-upgrade
commands, then we can reasonably expect that we can upgrade a subset
first, then restart DNF with the new stack, and pass in the remainder
of the transaction to complete.

That said, stuff like this with the Python stuff makes me think we
should have pythonX.Y-foo packages that have Obsoletes/Provides
pythonX-foo instead, so that stuff wouldn't actually break like this.
But that's another discussion...

And also, PackageKit offline upgrades wouldn't be affected by the
Python bit and could happily do this "properly", if the Python bit is
what you're worried about.

Another way to solve that problem would be to have a minimal C/C++
implementation that DNF would hand off to for system upgrades to avoid
the Python issue. Personally, I don't think that's necessary, all
things considered, but it's an option.

But I think we *really* should have the splitting transactions
feature, not just for system upgrades, but for dealing with a litany
of conditions that may make it difficult to do "big" transactions.


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

[Bug 1553141] New: perl-Filesys-Notify-Simple-0.13 is available

[bugzilla]

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

Bug ID: 1553141
   Summary: perl-Filesys-Notify-Simple-0.13 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Filesys-Notify-Simple
  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,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com



Latest upstream release: 0.13
Current version/release in rawhide: 0.12-12.fc28
URL: http://search.cpan.org/dist/Filesys-Notify-Simple/

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

-- 
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: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 01:39 PM, Neal Gompa wrote:

On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen  wrote:

On 03/07/2018 03:10 PM, Neal Gompa wrote:


On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:


And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).



This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.


Bottom line: either dnf (or something else) grows an dist-upgrade method
that runs the transaction on the "target stack" OR Fedora is *forced* to
hold back on new rpm package features until all the active versions have a
rpm/dnf stack that can handle them. Period. No ifs or buts.

P.S. No, updating rpm + dnf first in a separate transaction is not a
solution at all.



You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more. 


It's not a solution because doing so usually drags half the distro along 
due to library dependencies etc.



Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.


No, preupgrade & friends basically created a special boot target that 
runs the whole thing with the new version, in an isolated environment. 
Which equals "using the target rpm stack" in fact.




And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



That's quite a different thing, and creates it's own quirks and issues. 
And it doesn't help things at all when the simple "dnf update rpm dnf" 
drags along for example a new glibc or python version which snowballs 
into 70% of the distro getting pulled into the "just update rpm" 
transaction.


- Panu -





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

Re: Broken system upgrade due to rich dependencies

[Neal Gompa]

On Thu, Mar 8, 2018 at 2:53 AM, Panu Matilainen  wrote:
> On 03/07/2018 03:10 PM, Neal Gompa wrote:
>>
>> On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
>>  wrote:
>>>
>>> And you forgot:
>>> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
>>> proper way).
>>>
>>
>> This has been requested for a long time:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1032541
>>
>> It'd be *really* good if DNF implemented it.
>
> Bottom line: either dnf (or something else) grows an dist-upgrade method
> that runs the transaction on the "target stack" OR Fedora is *forced* to
> hold back on new rpm package features until all the active versions have a
> rpm/dnf stack that can handle them. Period. No ifs or buts.
>
> P.S. No, updating rpm + dnf first in a separate transaction is not a
> solution at all.
>

You're right in that upgrading rpm + dnf + libsolv first won't fix it
100% of the time (mainly with features that can't be guarded by
rpmlib() dependencies, such as the new header size), but I think it'll
deal with more than 80% of the cases where we have a problem, such
that distribution upgrades through this mechanism will work as we
introduce new features in the distribution.

But I would disagree that updating rpm + dnf first is not a solution
at all. It's not a *perfect* solution, but it would help a hell of a
lot more. Hell, even preupgrade and older mechanisms more or less
worked by getting the target rpm and package manager code installed
first and then doing the real thing using that code.

And supporting transaction ordering such that transactions can be
broken up into smaller ones as needed based on various conditions
would make upgrades more reliable in general, in my opinion.



-- 
真実はいつも一つ！/ 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: question about Obsoletes/Provides

[Daniel P . Berrangé]

On Thu, Mar 08, 2018 at 11:23:45AM +0100, Jos de Kloe wrote:
> I have a question about an open review request on the eccodes package,
> see: https://bugzilla.redhat.com/show_bug.cgi?id=1508950
> 
> Eccodes will replace grib_api for which downstream will stop support at
> the end of this year.
> Therefore the first draft spec file had Obsoletes/Provides entries to
> make clear that eccodes will replace it.
> 
> Then I received a comment that this was maybe not correct, since the
> replacement package may not be compatible enough so I disabled these
> keywords.
> 
> Main differences are:
> * grib_api provides a fortran77 library, which is absent in eccodes
> * library and pkg-config files changed name
> 
> on the other hand, they both provide a fully compatible api version of
> the c and fortran90 library.
> 
> On top of that, they both provide a collection of tools in /usr/bin with
> identical names which gives a conflict in ownership if both packages
> would be present at the same time.
> 
> looking at
> https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
> is this a case where only an Obsoletes should be used?

Yes, IMHO this is a case where just using 'Obsoletes' on its own to get
the upgrade installed is reasonable. Any downstream RPM that depends on
the original package may well need adapting due to changed library name,
so claiming 'Provides' is not appropriate.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 12:42 PM, Panu Matilainen wrote:

On 03/08/2018 12:21 PM, Reindl Harald wrote:



Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few


and i never used one of them - i did hundrets of dist-upgrades for 
more than a decade on dozens of machines (workstations and production 
servers) with yum/dnf - full stop


Sure. You just either didn't upgrade between versions that introduced a 
new rpmlib() dependency or updated rpm first, one way or the other. 


...or the couple of features were introduced in that period were done 
using the one generic solution at hand I did mention in my earlier 
email: wait until the previous Fedora supports the new feature too 
before enabling in the new. Come to think of it, I think this was mostly 
the case. It'd be in the ml archives if somebody wants to dig (we're 
talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload 
compression being the big ones I can remember offhand)


Oh, and of course back then it was nearly impossible to introduce such 
features in the first place because the builders were running RHEL. 
Those couple of features that were introduced required a custom rpm to 
be used on builders. Those were the days... no I dont miss.


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

Re: [SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide

[Björn 'besser82' Esser]

Am Dienstag, den 06.03.2018, 15:10 +0100 schrieb Björn 'besser82' Esser:
> Hello folks,
> 
> I'll update json-c to v0.13.1 for fc28 and Rawhide.  This will bump
> libjson-c so-name from 3 to 4 without any changes to the API.  The
> bump
> was done, because some distributions already bumped the so-name to 3
> with json-c v0.12 on their own.
> 
> I'll bump and rebuild all affected packages in one run.  There are no
> adjustments nor patches needed.
> 
> There might be some general fallout for builds of many packages in
> Rawhide for a few minutes;  see `Circular dependencies` for the
> reason.
> 
> I don't see any big complications during the rebuild as v0.13.1 just
> brings the set of patches I already carried downstream in the present
> v0.13 builds.
> 
> As soon as the builds are done, I'll give a short update of the
> status.
> 
> Cheers,
>   Björn
> 
> 
> === Circular dependencies ===
> 
> Since we have a circular dependency in rebuilding cryptsetup (and many
> other packages having direct or indirect (systemd !!!) BuildRequires
> on
> that package, I'll do the rebuild chains in two passes:
> 
> json-c (with a copy of libjson-c.so.3* included) : cryptsetup
> 
> and after the rebuilt cryptsetup has landed the build-repos:
> 
> json-c (final build, no copy of libjson-c.so.3*) : $other_packages
> 
> 
> === Affected packages (my own packages excluded) ===
> 
> abrt
> bluez
> bti
> cryptsetup
> device-mapper-multipath
> fastd
> filezilla
> freeradius
> fwts
> gdal
> gdcm
> gfal2
> girara
> gluster-block
> lcgdm-dav
> libmypaint
> libreport
> libstorj
> libu2f-host
> libu2f-server
> libverto-jsonrpc
> libvmi
> mypaint
> ndctl
> newsbeuter
> openhpi
> opensips
> postgis
> riemann-c-client
> strongswan
> sway
> syslog-ng
> systemtap
> tlog
> zmap


=== Rebuild status ===

All packages have been rebuilt successfully, but gluster-block, which is
failing due the SunRPC change in fc28.

As soon as the beta-freeze for fc28 is lifted, I'll start the rebuild
process for fc28 and push an update with all rebuilt packages.

Cheers,
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Panu Matilainen]

On 03/08/2018 12:21 PM, Reindl Harald wrote:



Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
P.P.S. So why didn't yum have anything like that? Because back then, 
there were other upgrade methods that did run on the "target stack": 
anaconda, preupgrade, fedup to name a few


and i never used one of them - i did hundrets of dist-upgrades for more 
than a decade on dozens of machines (workstations and production 
servers) with yum/dnf - full stop


Sure. You just either didn't upgrade between versions that introduced a 
new rpmlib() dependency or updated rpm first, one way or the other. 
Neither of which are generic solutions to the problem.


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

question about Obsoletes/Provides

[Jos de Kloe]

I have a question about an open review request on the eccodes package,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1508950

Eccodes will replace grib_api for which downstream will stop support at
the end of this year.
Therefore the first draft spec file had Obsoletes/Provides entries to
make clear that eccodes will replace it.

Then I received a comment that this was maybe not correct, since the
replacement package may not be compatible enough so I disabled these
keywords.

Main differences are:
* grib_api provides a fortran77 library, which is absent in eccodes
* library and pkg-config files changed name

on the other hand, they both provide a fully compatible api version of
the c and fortran90 library.

On top of that, they both provide a collection of tools in /usr/bin with
identical names which gives a conflict in ownership if both packages
would be present at the same time.

looking at
https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
is this a case where only an Obsoletes should be used?

Or should I also request that grib_api is to be added to
fedora-obsolete-packages?

Best regards,

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

Re: GCC 8 ABI change on x86_64

[Marek Polacek]

On Wed, Mar 07, 2018 at 09:19:15PM -0800, Adam Williamson wrote:
> On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > Recently we discovered a serious bug in the compiler whereby we miscompiled
> > several packages.  The problem started with my ABI-changing patch which 
> > changed
> > how empty classes are passed, as per the x86_64 psABI (so this bug only 
> > affects
> > x86_64).  The problem could arise when the code contained empty class 
> > templates.  
> > For more info see .
> > 
> > I did another mass rebuild with a specially-tweaked gcc in order to find out
> > which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry about
> > this.
> > 
> > This is the list:
> 
> I've fired rebuilds of every package on the list, for F28 and Rawhide.
> I'll investigate any failures and put together an F28 update tomorrow.

Excellent.  I saw many failures due to "missing package".  Otherwise you
can take a look at
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FL4RYJ2NDEFT5CFB5JXI4OCL7VY5QCWJ/
to see if some failures persist.

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

Re: GCC 8 ABI change on x86_64

[Marek Polacek]

On Wed, Mar 07, 2018 at 09:36:29PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 07, 2018 at 12:27:34PM -0800, Adam Williamson wrote:
> > On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > > Recently we discovered a serious bug in the compiler whereby we 
> > > miscompiled
> > > several packages.  The problem started with my ABI-changing patch which 
> > > changed
> > > how empty classes are passed, as per the x86_64 psABI (so this bug only 
> > > affects
> > > x86_64).  The problem could arise when the code contained empty class 
> > > templates.  
> > > For more info see .
> > > 
> > > I did another mass rebuild with a specially-tweaked gcc in order to find 
> > > out
> > > which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry 
> > > about
> > > this.
> > > 
> > > This is the list:
> > 
> > 
> > 
> > >   xautolock-2.2-18.fc24.src.rpm
> > 
> > This seems like an odd entry. How can a package last built for F24
> > possibly be affected?
> 
> Just guessing; Marek has rebuilt all the non-noarch src.rpm for rawhide

Exactly.

> and the package build diagnosed the ABI incompatibility.  Perhaps the build
> normally only fails later than where the ABI issue was spotted.
> 
> The instrumented GCC had a new option to compile using the previous
> (8.0.1-0.15 and earlier) wrong behavior and compiled everything twice,
> comparing dumps on what would be produced between the two.

Of course packages that were never built with gcc 8 are not affected, and need
not be rebuilt, but the list doesn't reflect that.  

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

Re: GCC 8 ABI change on x86_64

[Marek Polacek]

On Wed, Mar 07, 2018 at 07:20:18PM +, Sérgio Basto wrote:
> On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > I did another mass rebuild with a specially-tweaked gcc in order to
> > find out
> > which packages need to be rebuild with patched gcc-8.0.1-0.16. 
> 
> How we find out the same problem in packages from external repos ? 

I don't know; I've only rebuilt all rawhide packages.  Were the external
packages built with gcc 8?  If not, we're fine.

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

[Bug 1552960] perl-Log-Dispatch-FileRotate-1.35 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Log-Dispatch-FileRotate-1.35-1.fc28 has been submitted as an update to
Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9cb96b97de

-- 
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 719874] perl-threads-lite keeps hanging during self checks

[bugzilla]

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



--- Comment #16 from Fedora Update System  ---
perl-threads-lite-0.034-13.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-95f1522681

-- 
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: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

[Vít Ondruch]

Dne 8.3.2018 v 09:19 Igor Gnatenko napsal(a):
> On Wed, 2018-03-07 at 16:39 +0100, Vít Ondruch wrote:
>
> > Dne 7.3.2018 v 15:08 Jerry James napsal(a):
> >> On Wed, Mar 7, 2018 at 12:43 AM, Igor Gnatenko
> >>  wrote:
> >>> This is the second iteration of my mass-scratch-rebuild without
> >>> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> >>> original mail still applies.
> >>
> >> The abe and flocq packages should be considered false
> >> positives.  The
> >> configure script in abe checks for a C++ compiler, but the makefile
> >> only uses a C compiler.
>
> > I think the same happens to Ruby. It checks for C++ while C++ is not
> > needed. I might try to query upstream about it.
>
> Yes, please.
>

https://bugs.ruby-lang.org/issues/14590

V.


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: compilation of lollypop fails on mock build server

[Martin Gansser]

then I will omit meson_test in the %check section.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org