Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 15:50, Stephen John Smoogen  wrote:
[..]

> Even before EPEL-5 was EOL, very little of Fedora would compile out of
>
the box and required massive amounts of %if and other hacks to even
> try to compile from a rawhide spec file.
>
> If someone wanted to keep compiling for EL-5 they should branch the
> code themselves and maintain it as such versus trying to keep the
> cruft in the main tree. I believe that is what arbitrary branching is
> for.
>

I think that you are not fully aware what you've just done.
You just delivered *golden argument* on why EL{6,7} changes/tweaks should
be not be kept as %ifed part of the spec on master branch.

Than you very much because you succeeded on what I've been failing so far
here!!! :D

I can only repeat yet another time that only way solving whole class of
issues like those with EL*/EPEL is NOT keeping EL{6,7} relevant changes on
rawhide master branch!
If at least one person will checkout exact older Fedora branch, do
necessary updates, test it (somehow) and will be using such updated package
it is absolute minimum guarantee that such updates may be working correct.

At the moment each package has per Fedora version branches and some of the
packages el{6,7} branches.
It is hard to understand why it is in this case such duality that on master
are integrated changes relevant to el{6,7} or older Fedora on master.
What looks like handy from point of view single package maintainer creates
whole chaos on master branch and moving forward all changes in this point
with descent speed is only by this harder and harder from point of view of
Fedora as distribution
In other words .. what looks like useful feature on single package scale is
really UNACCEPTABLE on whole distro level.

If someone still has some doubts about necessary changes just ask
yourselves what would happen if Linus would be accepting in his kernel git
repo #ifdefed parts which will be used on older kernels? such #ifdefed
parts does not make any sense as whole tree is in EXACT kernel version!!!
-> such parts never would be tested!!!
Isn't it?

Because kernel has similar number of objects (text files) as Fedora, and
needs to be maintained *as consistent set*, it delivers working example
where some future Fedora changes should go.
Some package maintainers must as well step down on Earth to spot that what
they are doing *has bigger context*.
Why? Because it is only LOGICAL way of keeping everything as *working and
consistent set*.

Q: What generally happens with Linux kernel tree when Linus releases new
non-rc main kernel version?
A: Whole tree is cloned and maintained separately by people who at least
are using exact kernel version.

EXACTLY the same methodology should be applied in case of the Fedora.
In both cases (kernel and fedora) general methodology is determined quite
frankly by VCS tooling which in both cases is git.
With proper separations will be possible to remove INSTANTLY tons of
%ifings from rawhide specs which will make all specs *way more readable*
and NOT affected by any changes in older Fedoras or EL*.
Simpler form/shorter specs -> lower possibility of mistakes and lower
effort on understand what is done in exact spec.
It lowers energy barrier on introduce large scale changes (if they will be
needed) as well on any branches.

Q.E.D.

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

Re: Koji build: cannot find spec file

[Kevin Fenzi]

On 02/17/2018 08:22 PM, Jerry James wrote:
> On Sat, Feb 17, 2018 at 9:19 PM, Jerry James  wrote:
>> And it looks like the issue has been fixed.  Thanks, Mamoru.
> 
> Except that it hasn't.  Sorry, I misread the linked ticket as being
> this one so, no, the issue is still ongoing.

Yeah, it's still broken. I looked at it a bit but couldn't see what the
exact cause of the breakage is. ;(

If we cannot get it fixed by tomorrow morning, I'll revert us back to
the older koji version. ;(

Sorry for the hassles.

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: Koji build: cannot find spec file

[Jerry James]

On Sat, Feb 17, 2018 at 9:19 PM, Jerry James  wrote:
> And it looks like the issue has been fixed.  Thanks, Mamoru.

Except that it hasn't.  Sorry, I misread the linked ticket as being
this one so, no, the issue is still ongoing.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji build: cannot find spec file

[Jerry James]

On Sat, Feb 17, 2018 at 7:27 PM, Mamoru TASAKA
 wrote:
> Reported to infra pagure:
> https://pagure.io/fedora-infrastructure/issue/6710

And it looks like the issue has been fixed.  Thanks, Mamoru.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20180217.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Kde live i386

Failed openQA tests: 22/129 (x86_64), 8/22 (i386), 1/2 (arm)

ID: 193435  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193435
ID: 193436  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193436
ID: 193450  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/193450
ID: 193458  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193458
ID: 193460  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193460
ID: 193461  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193461
ID: 193462  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193462
ID: 193463  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193463
ID: 193465  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193465
ID: 193466  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/193466
ID: 193476  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193476
ID: 193478  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/193478
ID: 193479  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193479
ID: 193480  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193480
ID: 193481  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/193481
ID: 193482  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/193482
ID: 193483  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193483
ID: 193484  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193484
ID: 193485  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/193485
ID: 193495  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/193495
ID: 193518  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/193518
ID: 193519  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/193519
ID: 193524  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/193524
ID: 193535  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/193535
ID: 193542  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/193542
ID: 193543  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/193543
ID: 193568  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/193568
ID: 193572  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/193572
ID: 193573  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/193573
ID: 193577  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/193577
ID: 193579  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/193579

Soft failed openQA tests: 61/129 (x86_64), 14/22 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 193438  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/193438
ID: 193439  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/193439
ID: 193440  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/193440
ID: 193441  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193441
ID: 193442  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193442
ID: 193459  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/193459
ID: 193497  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193497
ID: 193498  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/193498
ID: 193500  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/193500
ID: 193501  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedora

Re: Removal of BuildRoot

[Neal Gompa]

On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  wrote:
>> "DS" == David Sommerseth  writes:
>
> DS> False positives are also easily filtered out by adding .rpmlint to
> DS> the dist-git repository.
>
> Which is an absolutely terrible name for that.  Really.  Why would
> anyone at all ever think it is a good idea to _hide_ the file that
> controls that?
>

I agree. What do we need to do to change this to .rpmlintrc?



-- 
真実はいつも一つ！/ 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: Koji build: cannot find spec file

[Mamoru TASAKA]

Jerry James wrote on 02/18/2018 09:48 AM:

This is the second of two attempts to build sympy this evening, both
of which failed the same way:

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

According to mock_output.log, the spec file can't be found.  What is going on?


Reported to infra pagure:
https://pagure.io/fedora-infrastructure/issue/6710

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

Koji build: cannot find spec file

[Jerry James]

This is the second of two attempts to build sympy this evening, both
of which failed the same way:

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

According to mock_output.log, the spec file can't be found.  What is going on?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: to batch or not to batch?

[Jerry James]

On Sat, Feb 17, 2018 at 3:15 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> Did I miss something on the plus or minus side? Or some good statistics?

I thought that was a pretty good summary of the ups and downs.  Thank
you for that.  I have no statistics.  But you also asked for anecdotal
evidence, and I've got that in spades. :-)

> Does patching make Fedora seem more approachable to end-users?

Not this end-user.  A little over 2 decades ago (good grief, am I
really that old?) I installed Linux for the first time.  It was
Slackware.  But then, in grad school, I was doing some cutting edge
work that required cutting edge tools, and Slackware didn't have new
enough versions of the tools I needed.  I went looking for a new
distribution, and everybody said that if I wanted the latest stuff, I
should install RedHat, so I did.  That was RedHat 4.2, and I updated
to every release of RedHat thereafter, and followed up by migrating to
Fedora when that transition took place.  Every version of Fedora since
then has run on at least one machine under my care, and often multiple
machines.

I came to RedHat/Fedora in the first place because it had the latest
shiny stuff.  That's the draw of Fedora for me.

> Do the benefits of batching outweigh the downsides?

Not for me, they don't.  I'm willing to believe that they do for some
users, but I frankly don't know which users that would be.  Perhaps
those with limited bandwidth?

> Should we keep batching as an interim measure until delta downloads are 
> implemented?

I'm indifferent on this one.  I find batching to be more annoying than
otherwise, but if it helps with server load and mirroring then I guess
I can't complain too loudly.

> Should dnf offer smart batched updates like gnome-software?

That seems reasonable, as long as there is a way to override it.

> Should we encourage maintainers to allow their updates to be batched?

The answer to this question must depend on the answers to the previous
questions.  I'll give you my personal experience again.  I've been
letting my updates go out with the batched updates.  I don't like it,
though.  The packages I tend get karma very, very rarely.  Almost
always, the only testing those packages get prior to going out to the
wide world is the testing I do before running fedpkg build.  So they
already have to pointlessly sit in testing for 7 days, getting no
actual testing, and then they have to wait up to another week to go
out.  If I'm fixing actual bugs, then all that accomplished was to
increase the probability that yet another user will run afoul of the
bug that I already fixed.

Bottom line: I don't like batching as either an end-user or as a
package maintainer, but I'm willing to put up with it if that is what
the project as a whole needs.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Adam Williamson]

On Sat, 2018-02-17 at 23:13 +0100, Lars Seipel wrote:
> On Fri, Feb 16, 2018 at 12:14:39PM -0800, Adam Williamson wrote:
> > On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote:
> > > I wish the compose process was more transparent. May be it is
> > > just me,
> > > but I don't know where to start looking when I don't get the
> > > daily
> > > compose report.
> > 
> > https://kojipkgs.fedoraproject.org/compose/
> > 
> > All composes initially happen there. Rawhide composes happen in the
> > rawhide/ subdirectory. Branched happen in the branched/
> > subdirectory.
> > Each compose directory contains logs. The usual process for
> > debugging
> > failed composes is to look at the pungi.global.log file, which
> > usually
> > indicates what the failed fatal task was, get the task ID or full
> > task
> > URL from that log, then go to Koji and look at the actual failed
> > task
> > and figure out what went wrong with it.
> 
> Thank you, Adam. That was super-helpful.
> 
> If I'm reading those correctly, all issues are due to live images,
> container images or OSTree-related stuff. The composes seem to result
> in perfectly fine netinstall images and they even appear to work.
> 
> Why do we block the whole Rawhide repo for weeks on that?

We didn't used to. It was changed a couple of years ago. The idea is
basically that a change which causes release-blocking images to fail to
compose is probably not a change we want to publish to the repos.

The most recent issue we fixed that I know of was actually in the KDE
live image, which is release-blocking. qt5-qtwebengine depends on
libevent, which was inadvertently soname-bumped (see devel@), so it
needed a rebuild. However, it failed to build with GCC 8. We had to
work with both Chromium (the issue was ultimately in Chromium -
qtwebengine includes a copy of Chromium) and GCC upstreams to get that
one addressed. So, ultimately what this policy "means" there is: we
don't want to ship the libevent soname bump out until it's at least not
stopping release blocking images from composing any more. That seems
like a fairly reasonable position to me, really - is it really 'better'
if we sync out a Rawhide repo which contains a broken KDE (and,
incidentally, a broken Chromium)?

That one should have been addressed in the 20180217.n.1 compose,
though, and someone's fired a 20180217.n.2 today, so they obviously
found and fixed something else. I've been out all day today so I don't
know specifically what that issue was.

The major improvement we could really do with is blocking problematic
changes *earlier* - before they are tagged into Rawhide at all. That's
something people are actively working on ATM. If we could, for
instance, have blocked the inadvertent libevent soname bump, that would
have saved a lot of trouble.
-- 
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: F29 Self Contained Change: FedoraScientific VagrantBox

[Samuel Sieb]

On 02/17/2018 01:38 AM, Jan Kurik wrote:

Fedora Scientific is currently delivered as ISOs. Shipping vagrant
boxes will give potential users a friendlier option to try out Fedora
Scientific while keeping their current operating system.


Where is this ISO?  There have been questions at ask.fpo for two 
releases looking for this and I couldn't find them anywhere.

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

Re: Removal of BuildRoot

[Luya Tshimbalanga]

On 2018-02-15 04:44 PM, Jason L Tibbitts III wrote:
>> "LT" == Luya Tshimbalanga  writes:
> LT> When you get a chance, would you also update the spec guideline as
> LT> well?
>
> Which spec guideline did you mean?  If you were referring to the
> packaging guidelines, they have said that BuildRoot: should not be used
> since 2016:
>
> The BuildRoot: tag, Group: tag, and %clean section SHOULD NOT be used.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>
>  - J<

Thank you for the update, I missed that part. In that case, the
fedora-package needs to update as well as rpmdev-newspec command still
uses "rm -fr %{buildroot}" line.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net



0xD8A2609A.asc
Description: application/pgp-keys


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

to batch or not to batch?

[Zbigniew Jędrzejewski-Szmek]

Bodhi currently provides "batched updates" [1] which lump updates of
packages that are not marked urgent into a single batch, released once
per week. This means that after an update has graduated from testing,
it may be delayed up to a week before it becomes available to users.

Batching is now the default, but maintainers can push theirs updates
to stable, overriding this default, and make the update available the
next day.

Batching is liked by some maintainers, but hated by others
Unfortunately, the positive effects of batching are strongly
decreased when many packages are not batched. Thus, we should settle
on a single policy — either batch as much as possible, or turn
batching off. Having the middle ground of some batching is not very
effective and still annoys people who don't like batching.

To summarize the ups (+) and downs (-):

+ batching reduces the number of times repository metadata is updated.
  Each metadata update results in dnf downloading about 20-40 mb,
  which is expensive and/or slow for users with low bandwidth.

+ a constant stream of metadata updates also puts strain on our mirrors.

+ a constant stream of updates feels overwhelming to users, and a
  predictable once-per-week batch is perceived as easier. In
  particular corporate users might adapt to this and use it to
  schedule an update of all machines at fixed times.

+ a batch of updates may be tested as one, and, at least in principle,
  if users then install this batch as one, QA that was done on the
  batch matches the user systems more closely, compared to QA testing
  package updates one by one as they come in, and users updating them
  at a slightly different schedule.

- batching delays updates of packages between 0 and 7 days after
  they have reached karma and makes it hard for people to immediately
  install updates when they graduate from testing.

- some users (or maybe it's just maintainers?) actually prefer a
  constant stream of small updates, and find it easier to read
  changelogs and pinpoint regressions, etc. a few packages at a time.

- batching (when done on the "server" side) interferes with clients
  applying their own batching policy. This has two aspects:
  clients might want to pick a different day of the week or an
  altogether different schedule,
  clients might want to pick a different policy of updates, e.g. to
  allow any updates for specific packages to go through, etc.

  In particular gnome-software implements its own style of batching, where
  it will suggest an update only once per week, unless there are security
  updates.

Unfortunately there isn't much data on the effects of batching.
Kevin posted some [2], as did the other Kevin [3] ;), but we certainly
could use more detailed stats.

One of the positive aspects of batching — reduction in metadata downloads,
might be obsoleted by improving download efficiency through delta downloads.
A proof-of-concept has been implemented [4].

Second positive aspect of batching — doing updates in batches at a
fixed schedule, may just as well be implemented on the client side,
although that does not recreate the testing on the whole batch, since
now every client it doing it at a different time. It's not clear though
if this additional testing is actually useful.

There's an open FESCo ticket to "adjust/drop/document" batching [5].
That discussion has not been effective, because this issue has many
aspects, and depending on priorities, the view on batching is likely to
be different. FESCo is trying to gather more data and get a better
understanding of what maintainers consider more important.

Did I miss something on the plus or minus side? Or some good statistics?
Does patching make Fedora seem more approachable to end-users?
(this is a question in particular for Matthew Miller who pushed for batching.)
Do the benefits of batching outweigh the downsides?
Should we keep batching as an interim measure until delta downloads are 
implemented?
Should dnf offer smart batched updates like gnome-software?
Should we encourage maintainers to allow their updates to be batched?

[1] https://github.com/fedora-infra/bodhi/issues/1157,

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UDXVXLT7JXCY6N7NRACN4GBS3KA6D4M6/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B6MMH3L36A2YXQ45Y4DUGMR4XIG7QKE5/
[3] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F36YMWKDXBHAQWQOLDSYLYTMDF4WYHE6/
[4] http://lists.rpm.org/pipermail/rpm-ecosystem/2018-February/000534.html
[5] https://pagure.io/fesco/issue/1820

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

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Lars Seipel]

On Fri, Feb 16, 2018 at 12:14:39PM -0800, Adam Williamson wrote:
> On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote:
> > I wish the compose process was more transparent. May be it is just me,
> > but I don't know where to start looking when I don't get the daily
> > compose report.
> 
> https://kojipkgs.fedoraproject.org/compose/
> 
> All composes initially happen there. Rawhide composes happen in the
> rawhide/ subdirectory. Branched happen in the branched/ subdirectory.
> Each compose directory contains logs. The usual process for debugging
> failed composes is to look at the pungi.global.log file, which usually
> indicates what the failed fatal task was, get the task ID or full task
> URL from that log, then go to Koji and look at the actual failed task
> and figure out what went wrong with it.

Thank you, Adam. That was super-helpful.

If I'm reading those correctly, all issues are due to live images,
container images or OSTree-related stuff. The composes seem to result
in perfectly fine netinstall images and they even appear to work.

Why do we block the whole Rawhide repo for weeks on that? If building
container images and OSTrees doesn't work in a reliable way, they
probably shouldn't be blocking repo composes. The failing spins
(Astronomy, PyClassroom, Mate, etc.) are already non-blocking, I
presume?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Randy Barlow]

On 02/17/2018 11:37 AM, Neal Gompa wrote:
> When tests have failures or
> warnings, they are _not_ featured on the update page itself.

The test tab shows the counts of passing, warning, and failing tests,
once they finish loading.



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: Removal of BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 12:43, Tom Hughes  wrote:

> On 16/02/18 12:36, Tomasz Kłoczko wrote:
>
>> On 16 February 2018 at 11:21, Panu Matilainen > > wrote:
>> [..]
>>
>> Not everybody runs rpmlint for everything they produce, on the
>> contrary I suspect it's fairly small percentage of packagers out
>> there that do. If rpm itself doesn't directly complain about such
>> things they'll simply never get cleaned up.
>>
>>
>> And this is why for example calling rpmlint should be one of the pre
>> steps done by koji on sending build request.
>> It would be good to perform at least one time a month rpmlint test across
>> all packages, and if it anything wrong automatically should be created git
>> issue or bugzilla ticket.
>>
>
> Well rpmlint would need to be made a lot better first. The rate of
> false positives at the moment is enormous.
>

With such approach always will be chicken and egg problem because rpmlint
will be not improving because it will be not used, and it will be not
improving because it will not widely used.
It is necessary to cut this loop somewhere, and if it will be added in
whole pipeline of the Fedora processes single change in rpmlint will
automatically expose some number of packages with some issues.
I'm 100% sure that even current rpmlint will expose some number of specs
which needs to be cleaned up.

"Not everybody runs rpmlint"

If everybody will be using rpmlint it will start improving .. as same as
"build it and they will come".

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

Re: Removal of BuildRoot

[Jason L Tibbitts III]

> "NG" == Neal Gompa  writes:

NG> What do you want it to be?

What the other distros use seems far better to me.  Alternately, just
"rpmlintrc".

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

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Antonio Trande]

On 14/02/2018 21:59, Igor Gnatenko wrote:
> As guidelines changed[0] and now require maintainers who package libraries in
> default library path (/usr/lib, /usr/lib64) to use %ldconfig_scriptlets in 
> case
> they want spec file to be compatible with all Fedora/EPEL versions or drop 
> them
> entirely if they maintain one-spec-per-branch.
> 
> After branching (should be on 2018-02-20) completes + week (2018-02-26,
> probably later), I'm going to replace your scriptlets to follow guidelines in
> master branch (aka F29) with safest option available -- %ldconfig_scriptlets.
> The whole purpose of this is to make installation of packages FASTER and
> obviously to comply with guidelines. Most of packages would be possible to
> automate, however some would not and you would need to deal with it youself.
> 
> All packages which implement mentioned macro are already in stable updates
> (redhat-rpm-config for Fedora and epel-rpm-macros for EPEL).
> 
> Your options:
> 
> * Speak up and tell package names I should not touch because … (you should
> complete this sentence).
> * Fix up packages and tell package names I should not touch because you did
> that already.
> * Tell package names you want to remove ldconfig scriptlets entirely instead
> of replacing them with %ldconfig_scriptlets and get fix **for free**.
> * Ignore this message and get fix **for free**.
> 
> Preliminary list of packages is following (I omited packages which have
> ld.so.conf entry and probably added some unnecessary ones):
> 
> Maintainers by package:
> ...
> sagitter   MUMPS SuperLU SuperLUMT avogadro coin-or-Bonmin coin-or-CoinUtils
> coin-or-Couenne coin-or-Ipopt coin-or-OS giac gnustep-base gtengine libavc1394
> libdv libmodplug libnuml libsbml libsbw libsedml lightning metis mld2p4
> molequeue mp psblas3 qrmumps qwtplot3d qwtplot3d-qt5 spglib wildmagic5
> ...

Fixed.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



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: Removal of BuildRoot

[Neal Gompa]

On Sat, Feb 17, 2018 at 11:14 AM, Jason L Tibbitts III
 wrote:
>> "NG" == Neal Gompa  writes:
>
> NG> The problem with Bodhi is that it's too late.
>
> I don't disagree, but you've switched up your argument.  You made the
> statement that Fedora doesn't care about rpmlint so there's no point in
> improving it.  People do care, and rpmlint is featured in an important
> place in an important application.  It could even be used for gating,
> except that it gives far too many false positives.
>

You mentioned Bodhi, so I mentioned that where it happens is not
helpful. I could have also brought up the general attitude I encounter
from people in the mailing list and on IRC that rpmlint is useless and
its warnings and errors can be ignored, but that's not solvable
without making it a centerpiece in the package build process.

I would argue that the way Bodhi shows the update checks is actually
indicating that they're _not_ important. They're hidden away, and many
times, clicking on that tab will give you nothing but an endless
loading screen, which indicates that there's been no priority to
ensuring the test data is always accessible, anyway. It is _not_ front
and center in mock or koji builds. When tests have failures or
warnings, they are _not_ featured on the update page itself. They are
still hidden away.

Again, making the rpmlint policy that approximates Fedora packaging
guidelines is possible, but I don't think it'd be used.

> NG> And in both Mageia and openSUSE's case, you can define
> NG> .rpmlintrc files that are picked up by the build system
> NG> to ignore issues that are obvious false positives.
>
> And of course we have that, too, but it's not used in as many places.
> I would definitely want to get the name changed from the terrible
> ".rpmlint" before that happens, though.
>

What do you want it to be?



-- 
真実はいつも一つ！/ 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: Removal of BuildRoot

[Jason L Tibbitts III]

> "NG" == Neal Gompa  writes:

NG> The problem with Bodhi is that it's too late.

I don't disagree, but you've switched up your argument.  You made the
statement that Fedora doesn't care about rpmlint so there's no point in
improving it.  People do care, and rpmlint is featured in an important
place in an important application.  It could even be used for gating,
except that it gives far too many false positives.

NG> And in both Mageia and openSUSE's case, you can define
NG> .rpmlintrc files that are picked up by the build system
NG> to ignore issues that are obvious false positives.

And of course we have that, too, but it's not used in as many places.
I would definitely want to get the name changed from the terrible
".rpmlint" before that happens, though.

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

Re: F29 Self Contained Change: FedoraScientific VagrantBox

[Randy Barlow]

On 02/17/2018 04:38 AM, Jan Kurik wrote:
> ** List of deliverables:
> N/A (not a System Wide Change)

Since a VagrantBox is a deliverable, should this be a system wide change?



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: F29 System Wide Change: Remove GCC from BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I started rebuilding all active Fedora packages (on internal koji instance⁰).
Here are some stats:

* 20301 builds total
* 4073 builds passed
* 809 builds failed on autotools check
* 561 builds failed with command not found
* 238 builds failed on CMake check
* Rest is in progress

There might be overlaps in those errors and might be some false positives…
Given this, it should be possible to fix all those packages automatically. Only
one concern is there might be cases where package doesn't need C compiler, but
some of dependencies are missing runtime Requires: gcc. This is not really
harmful and hopefully there won't be many cases.


I will send another update closer to end (monday possibly).

⁰ Mikolaj Izdebski set up koji for me on one of our internal servers.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqIVDwACgkQaVcUvRu8
X0xqyQ/9E/dVftTDD+eg/5Zoxo3HafNQwebzllfwpwIYnhIgMbjTCUNBLgjzZEt4
7be6gXUESodZ/IGDxeCt/eRrKgjliV/qyY63hnDs+hKn5Q4MC6sjbwfho7aqQh3+
alqp+m0AxCNsqy94AvuPfHckMXYNE8ECuS0LCT1rHUsFo9xhOsMGRJskglDT1rK4
oGkegbRnoTgElq6pF8lk6NoHUpSFxQNMysaKLknr6R/KRuAd29q+gw8VBCqn4Z+A
ySKf46ZRJ8CvIaF9e5ZjYTm0IoKURG4oquGn7fiaZJ1woPiSlLZrkIEc8ytkalm8
ps0HCcZ+lHCautVoOrAqU+1WtGb++c03C+uL6m1GP9p6MilLx2nldYbqcJZ9eOTB
uq3erDK9Xumgv0tykxTErIFzGOUOUomOPZWDcoBpuJkVhX4IIdL0JZGdpyyq4NWk
f3cPjxiQU8CwSqh/8C1Mawji68Kpz3+IKWWrBQFbFQirj28fqm2D8QuQXu2SQ+G8
yaZcdZPMkCDlfs3THL2Obir5RVAdqfUVG/hJUiPAIkhR4g7OqHnX+A4h8S3cUd0n
jMpD+a0rJyouIAnwmxV/m7bK/I4S7TEnWL+TqxiKk/kAvM967st3ZVN25zOTXtvV
TOF9XcQZFj6RbZDlcb1U58BrfjntSRSM42dHMdhRh2dHJjfMy5o=
=4L2w
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of sln

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 16, 2018 at 09:53:35PM +, Richard W.M. Jones wrote:
> sln (staticly linked ‘ln’) was removed from glibc recently:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1531546
> 
> The explanation for this was:
> 
>   "The sln program is no longer useful, so we will not ship it anymore."
> 
> and it was removed from Rawhide 3 days later.
> 
> There are some %post scripts which still use this, notably
> ca-certificates, so that's now broken.  But more to the point what do
> you do if you are in a situation where you need to make a symlink to
> save some core shared library on the currently running system?
> 
> I also don't think rather fundamental, useful and old tools like this
> should be removed without discussion.

Why is normal ln not enough? It should be installed and runnable on
pretty much any system, even during upgrades of glibc and other basic
libraries.

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

Elasticsearch dependency tree trim?

[John Dulaney]

The dependency tree for Elasticsearch is way huge, even bringing in parts
of the X stack.  Do you reckon folks could work together to trim this a
bit?

Thanks!

--
John.


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

Re: Removal of BuildRoot

[Jonny Heggheim]

On 02/13/2018 11:05 PM, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which
> is oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
>
> I wanted to send this heads up before I actually did that, but I hit
> "enter"
> button too early.
>
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 😉

Thanks! I fully support changes like this.

Jonny




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: RFC: BugURL in packages

[Fabio Valentini]

On Sat, Feb 17, 2018 at 2:43 PM, Neal Gompa  wrote:
> On Thu, Feb 15, 2018 at 6:03 AM, Fabio Valentini  wrote:
>> On Feb 15, 2018 11:52, "Pierre-Yves Chibon"  wrote:
>>
>> On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Hello,
>>>
>>> it's been just 9 years since BugURL has been added to RPM, but it has not
>>> been
>>> used.
>>>
>>> I think it would be helpful for users to have it defined in RPMs, so when
>>> they
>>> do `dnf info`, `rpm -qi` they would just click on it and it would select
>>> right
>>> component, right version and such for it.
>>>
>>> Do you think same way? If so, which URL should we put there?
>>
>> I think bugz.fedoraproject.org/ is potentially a good url to
>> use
>> for this.
>>
>>
>> Linking to fedora bugzilla was my first "instinct". However, it is
>> completely redundant and doesn't add any new information to the package,
>> since it's the same URL for every package in fedora. Additionally, such URLs
>> don't even work right now (certificate errors and 404s, at least for me).
>>
>> In contrast, adding a link to upstream bug tracking (which is actually
>> different everywhere) would provide useful additional  information.
>>
>
> I'd argue otherwise. Generally speaking, bugs related to packages
> should absolutely be filed with Fedora. It is the maintainer who must
> judge whether it's something Fedora caused or upstream caused, and
> file the appropriate bug there. We are the stewards of the experience
> in Fedora, so we get first dibs on bug reports, too. ;)

I didn't argue that bugs should be reported upstream, I just wanted to
express that including redundant information isn't useful IMO.

Reporting bugs for fedora packages is the same process for every
fedora package, so that doesn't have to be documented seperately.
Upstream bug trackers aren't tracked/documented in fedora (.specs)
yet, however. That's the reason why I think providing links to
upstream trackers adds value, whereas linking to a fedora component in
rhbz / fedora bug list for a package doesn't.

Fabio

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

Re: RFC: BugURL in packages

[Neal Gompa]

On Thu, Feb 15, 2018 at 6:03 AM, Fabio Valentini  wrote:
> On Feb 15, 2018 11:52, "Pierre-Yves Chibon"  wrote:
>
> On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hello,
>>
>> it's been just 9 years since BugURL has been added to RPM, but it has not
>> been
>> used.
>>
>> I think it would be helpful for users to have it defined in RPMs, so when
>> they
>> do `dnf info`, `rpm -qi` they would just click on it and it would select
>> right
>> component, right version and such for it.
>>
>> Do you think same way? If so, which URL should we put there?
>
> I think bugz.fedoraproject.org/ is potentially a good url to
> use
> for this.
>
>
> Linking to fedora bugzilla was my first "instinct". However, it is
> completely redundant and doesn't add any new information to the package,
> since it's the same URL for every package in fedora. Additionally, such URLs
> don't even work right now (certificate errors and 404s, at least for me).
>
> In contrast, adding a link to upstream bug tracking (which is actually
> different everywhere) would provide useful additional  information.
>

I'd argue otherwise. Generally speaking, bugs related to packages
should absolutely be filed with Fedora. It is the maintainer who must
judge whether it's something Fedora caused or upstream caused, and
file the appropriate bug there. We are the stewards of the experience
in Fedora, so we get first dibs on bug reports, too. ;)



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

Pagure - Can't remove yourself from a project if not an admin?

[Richard Shaw]

I spent about 10 minutes trying to figure out how to remove myself from a
project (for which I'm not an admin) and I have come to the conclusion that
I'm not able to do so.

Is this a known issue?

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

Re: Removal of BuildRoot

[Neal Gompa]

On Fri, Feb 16, 2018 at 4:24 PM, Jason L Tibbitts III  wrote:
>> "NG" == Neal Gompa  writes:
>
> NG> As upstream for rpmlint, I do not believe anyone cares at all about
> NG> rpmlint in Fedora.
>
> We seemingly care so little for it that the rpmlint status appears on
> every bodhi update.
>
> I did spend some time trying to make rpmlint better ages ago and kind of
> got blocked by the restriction that it (at the time) had to conform to
> whatever RHEL4 wanted.  But that was obviously a long time ago.
>
> NG> Until we can fail builds on rpmlint errors (as both Mageia and
> NG> openSUSE do), it's pointless to consider rpmlint as something that
> NG> ensures things stay clean and sane.
>
> If you can tolerate no false positives from rpmlint then there must be a
> pile of things it doesn't look at.  I always saw it as a useful advisory
> tool but have difficulty imagining that you could gate off of it.
>
> What I did was hack my local setup (which does auto-rpmlint directly
> within vim) to accept magic comments to tell it to stop complaining
> about certain things.  I recall suggesting that upstream a long time ago
> but not having much luck.  But again, we're talking over a decade here.
>

The problem with Bodhi is that it's too late. By that point the build
has been submitted, it's gone through all the steps involved in
submitting updates, and to make matters worse, *all* test results are
now hidden from people by default. It took me a while to figure out
where the test results had gone after the change occurred. I honestly
thought we had given up on those things initially. I've always felt
that some of those tests should be happening post-build, not
post-update submission. Failing builds on "obviously bad" packages
makes for a bigger incentive to improve packaging.

As for toleration of false positives, that's more of a sign that we
don't quite have a well-tuned configuration and maybe there are some
checks in rpmlint itself that need to be tweaked. In both Mageia and
openSUSE, we have rpmlint policy packages that define the checks, the
"scores", and the threshold in which it is bad enough to make
something be rejected. The reason for this is because we want to block
packages that are "obviously wrong" from being accepted by the build
system. It's really the only way to make people consider improving
their packaging. Everyone has tried nicer ways, and it doesn't work.

And in both Mageia and openSUSE's case, you can define
.rpmlintrc files that are picked up by the build system to
ignore issues that are obvious false positives. Yes, this could be
abused, and perhaps we shouldn't do that. But if you want packaging to
improve, you need a way for people to reliably determine what they're
doing is "good" or "bad". Right now, we don't have that, and my
personal feeling is that if I spend the effort in doing so, it would
be wasted because it wouldn't result in any improvement.

-- 
真実はいつも一つ！/ 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: Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[nicolas . mailhot]

De: "Fabio Valentini" 

> Additionally, there are lots of packages that look like their
> maintainer hasn't touched them in years (for example, the only git
> commits are from mass rebuilds),

Actually it's hard to find the motivation to touch a package just for a little 
syntactic cleanup. Mass cleanups are much better on the ego of the person that 
does them, he can feel he accomplished something, since that's the mass effect 
that makes them worthwhile.

Thank you Igor!

Regards,

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

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Fabio Valentini]

On Sat, Feb 17, 2018 at 11:02 AM, Remi Collet  wrote:
> Le 17/02/2018 à 10:05, Igor Gnatenko a écrit :
>> On Sat, 2018-02-17 at 07:08 +0100, Remi Collet wrote:
>>> Le 16/02/2018 à 15:18, Mark Wielaard a écrit :
>>
 I had to tweak it a little though so the spec could still be build
 older RHEL or Fedora (I reuse the spec to build on RHEL and with SCL).
 Maybe something like the following is better for people who have a spec
 file they might reuse on systems that might not have this macro:

 # Only the latest Fedora and EPEL have these scriptlets,
 # older, or not up to date, Fedora and plain RHEL don't.
 %if 0%{?ldconfig_scriptlets:1}
 %ldconfig_scriptlets libs
 %ldconfig_scriptlets libelf
 %else
 %post libs -p /sbin/ldconfig
 %postun libs -p /sbin/ldconfig
 %post libelf -p /sbin/ldconfig
 %postun libelf -p /sbin/ldconfig
 %endif
>>
>>> Even simpler
>>
>>> %if 0%{?fedora} < 28
>>> %post   libs   -p /sbin/ldconfig
>>> %postun libs -  p /sbin/ldconfig
>>> %post   libelf -p /sbin/ldconfig
>>> %postun libelf -p /sbin/ldconfig
>>> %endif
>>
>> This is wrong because. This macro is defined on all EPEL and Fedora, so 
>> Mark's
>> way is correct (almost).
>>
>>> Because the ldconfig_scriptlets stuff only work in koji, not in other
>>> build system (brew, cbs, ...)
>>
>> This is not a problem for Fedora.
>
> This is exactly what Mark message was about (older RHEL or Fedora)
>
> Definitively we have a very different vision of packaging.
>
> You are trying to impose "your vision" as the only acceptable one
> without any respect for other packagers which may have different vision
> and different goal.

I don't understand that argument. What goal other than "providing good
packages for fedora" could there be for fedora packagers?

> And this is probably the reason of some much discussions about recent
> changes.
>
> And this create so much frustration on my side (and perhaps some
> others), BTW, we will never agree.
>
> And another point, message for all packagers, you don't have to take
> care of maintaining your package, Igor the robot will do the work for you.

That's neither a fair towords Igor, nor productive criticism.
While I agree that the changes could have been communicated better, I
am glad that _finally_ someone is cleaning up all the unnecessary
cruft that has accumulated in fedora .spec files.

Additionally, there are lots of packages that look like their
maintainer hasn't touched them in years (for example, the only git
commits are from mass rebuilds), so some maintainers _already_ don't
take care of maintaining their packages and adapting them to comply
with the current Packaging Guidelines. Doing incremental mass cleanups
and fixups seems to be the only workable solution to bring them
(barely) up to current Guidelines.

> IMHO, we should explain things, explain why they are needed, and
> encourage people to understand and do their work.
>
>
>
>
> Remi, terribly disappointed by the way the project goes.
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Roberto Ragusa]

On 02/16/2018 10:35 PM, Jason L Tibbitts III wrote:
>> "RR" == Roberto Ragusa  writes:

> RR> Was that a valid consideration? Has something changed on that front?
> 
> It was, and packages will now fail to build (via brp-ldconfig) if they
> don't package those symlinks.  Though in practice packages which did not
> do this would have been exceedingly rare anyway and when I checked the
> package set looking for examples a year ago I think I only turned up two
> examples.

Thank you for clarifying this.
So in theory without ldconfig symlinks could have remained misconfigured,
but nowadays packages are forced to take care of links themselves.
Indeed, even in the old world, my upgrade went fine, I can't exclude that
some scripting may have failed, but I never noticed any unexpected issue.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Scilab, rkward install in Rawhide: nothing provides libgfortran.so.4()

[Jakub Jelinek]

On Sat, Feb 17, 2018 at 11:05:39AM -, Amit Saha wrote:
> Hi all,
> 
> `scilab` and `rkward` installation in Rawhide (in the Fedora Scientific 
> build) is currently failing with: nothing provides libgfortran.so.4(). I can 
> see that nothing provides libgfortran.so.4 on rawhide. The reason seems to be 
> a new release of libgfortran. The last libgfortran release with which these 
> packages both successfully installed was: libgfortran-7.2.1-7.fc28. The 
> current version is 8.0.1-0.9.fc28. 
> 
> What's the path forward here?

Rebuild whatever fortran packages have failed during mass rebuild which
should have fixed this.

> rkward koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=4881
> scilab koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=12847

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

Scilab, rkward install in Rawhide: nothing provides libgfortran.so.4()

[Amit Saha]

Hi all,

`scilab` and `rkward` installation in Rawhide (in the Fedora Scientific build) 
is currently failing with: nothing provides libgfortran.so.4(). I can see that 
nothing provides libgfortran.so.4 on rawhide. The reason seems to be a new 
release of libgfortran. The last libgfortran release with which these packages 
both successfully installed was: libgfortran-7.2.1-7.fc28. The current version 
is 8.0.1-0.9.fc28. 

What's the path forward here?

rkward koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=4881
scilab koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=12847

Thanks for your help.

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

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Remi Collet]

Le 17/02/2018 à 10:05, Igor Gnatenko a écrit :
> On Sat, 2018-02-17 at 07:08 +0100, Remi Collet wrote:
>> Le 16/02/2018 à 15:18, Mark Wielaard a écrit :
> 
>>> I had to tweak it a little though so the spec could still be build
>>> older RHEL or Fedora (I reuse the spec to build on RHEL and with SCL).
>>> Maybe something like the following is better for people who have a spec
>>> file they might reuse on systems that might not have this macro:
>>>
>>> # Only the latest Fedora and EPEL have these scriptlets,
>>> # older, or not up to date, Fedora and plain RHEL don't.
>>> %if 0%{?ldconfig_scriptlets:1}
>>> %ldconfig_scriptlets libs
>>> %ldconfig_scriptlets libelf
>>> %else
>>> %post libs -p /sbin/ldconfig
>>> %postun libs -p /sbin/ldconfig
>>> %post libelf -p /sbin/ldconfig
>>> %postun libelf -p /sbin/ldconfig
>>> %endif
> 
>> Even simpler
> 
>> %if 0%{?fedora} < 28
>> %post   libs   -p /sbin/ldconfig
>> %postun libs -  p /sbin/ldconfig
>> %post   libelf -p /sbin/ldconfig
>> %postun libelf -p /sbin/ldconfig
>> %endif
> 
> This is wrong because. This macro is defined on all EPEL and Fedora, so Mark's
> way is correct (almost).
> 
>> Because the ldconfig_scriptlets stuff only work in koji, not in other
>> build system (brew, cbs, ...)
> 
> This is not a problem for Fedora.

This is exactly what Mark message was about (older RHEL or Fedora)

Definitively we have a very different vision of packaging.

You are trying to impose "your vision" as the only acceptable one
without any respect for other packagers which may have different vision
and different goal.

And this is probably the reason of some much discussions about recent
changes.

And this create so much frustration on my side (and perhaps some
others), BTW, we will never agree.

And another point, message for all packagers, you don't have to take
care of maintaining your package, Igor the robot will do the work for you.

IMHO, we should explain things, explain why they are needed, and
encourage people to understand and do their work.




Remi, terribly disappointed by the way the project goes.



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

F29 Self Contained Change: FedoraScientific VagrantBox

[Jan Kurik]

= Proposed Self Contained Change: FedoraScientific VagrantBox =
https://fedoraproject.org/wiki/Changes/FedoraScientific_VagrantBox


Owner(s):
  * Amit Saha 


Fedora Scientific is currently delivered as ISOs. Shipping vagrant
boxes will give potential users a friendlier option to try out Fedora
Scientific while keeping their current operating system.



== Detailed description ==
Vagrant boxes for Fedora Scientific will allow users to easily run
Fedora Scientific in a virtual machine. This can be useful for users
who are using another operating system as their host operating system
and not have to manually download the ISO, and go through the
installation process which can be unfamiliar or unnecessary hassle for
users who may be new to Fedora or Linux.


== Scope ==
* Proposal owners:
This will require creating pungi configuration as well as new
kickstarts to be able to build the vagrant boxes for Fedora
Scientific.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7324

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

* Policies and guidelines:
N/A (not a System Wide Change)

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

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-02-16 at 15:18 +0100, Mark Wielaard wrote:
> Hi Igor,
> 
> On Wed, 2018-02-14 at 21:59 +0100, Igor Gnatenko wrote:
> > Your options:
> > 
> > * Speak up and tell package names I should not touch because … (you should
> > complete this sentence).
> > * Fix up packages and tell package names I should not touch because you did
> > that already.
> > * Tell package names you want to remove ldconfig scriptlets entirely
> > instead
> > of replacing them with %ldconfig_scriptlets and get fix **for free**.
> > * Ignore this message and get fix **for free**.
> > [...]
> > elfutils aoliva fche jakub jankratochvil mjw pmachata roland
> 
> I saw you already fixed this one up, thanks.
> 
> Although for some reason I didn't get any notification about this
> change.
> 
> I had to tweak it a little though so the spec could still be build
> older RHEL or Fedora (I reuse the spec to build on RHEL and with SCL).
> Maybe something like the following is better for people who have a spec
> file they might reuse on systems that might not have this macro:

Generally this is bad advise because people who maintain packages in Fedora are
supposed to maintain them only for Fedora and EPEL. Note that all macros are
available in all supported Fedora, so you don't need such conditions.

> # Only the latest Fedora and EPEL have these scriptlets,

This is noy completely true, **all** Fedora and **all** EPEL have these
scriptlets.

> # older, or not up to date, Fedora and plain RHEL don't.
> %if 0%{?ldconfig_scriptlets:1}

%if %{defined ldconfig_scriptlets}

I think this is more readable.

> %ldconfig_scriptlets libs
> %ldconfig_scriptlets libelf
> %else
> %post libs -p /sbin/ldconfig
> %postun libs -p /sbin/ldconfig
> %post libelf -p /sbin/ldconfig
> %postun libelf -p /sbin/ldconfig
> %endif
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqH8PcACgkQaVcUvRu8
X0wOZRAAkH7hAduIn74+3GYRUdbghOpElmACbJmixRSccF2ceRAw5lLSLAyqYhI1
nA/rtGsxt2cfp0Tmd5+AOKh7Yyce9a+uIDQ6TVUyo1kuWLnDV+8rJvEOYypjVkAL
0RYecywukCfO/v4D/cfzeitesL2i9xyThcoJkfuRPULB3aEhiBsGWqaj0pBfrph/
6pHXwBnQ2/rgzx4GTHScB/3GnagRRTtNeK1IFZwD9qFfbEcb3pI6r+ajeoztG1oU
StZwfo4TLyxNnQ34Ko7yp1o8pUZ2q7M2ySuP7E8gDyH6qQo+dv6NWB+z6pGyZcek
xS2U2pRNbLMj8/CgKmCR9qPh97Ghs0iln5aFxvlt0zHgTvq6FlUobxwdM8sD+jTu
gzzc2FpMAv/fQNsIsMBKGNuJqOhHBiRROuYdJTqrP1DcIVRbRfzwfxtcbcnGJEIQ
pIKmri8xx0FxHd76+41nQL21fMaJiXpZb77OrLTs8Kk7IyY3fYVVO0fOPHkPHm3t
wT7bNCq288k3Os+2TEyZfWdRSzZLuANvmfhIYr9LF6wqlFeykiGW2x+Ow1ET252C
tYE5fU2RVRK5S5uMgP2DJM9A/BgbWL+9WQmw9wf5EjZZMN8KATRACZ+nqCUs7po/
qXPlATdD2E9/7XTSbVBRaT5lgyiv/jTPlpQ6NukOI3dfle7/9b8=
=PNVr
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2018-02-17 at 07:08 +0100, Remi Collet wrote:
> Le 16/02/2018 à 15:18, Mark Wielaard a écrit :
> 
> > I had to tweak it a little though so the spec could still be build
> > older RHEL or Fedora (I reuse the spec to build on RHEL and with SCL).
> > Maybe something like the following is better for people who have a spec
> > file they might reuse on systems that might not have this macro:
> > 
> > # Only the latest Fedora and EPEL have these scriptlets,
> > # older, or not up to date, Fedora and plain RHEL don't.
> > %if 0%{?ldconfig_scriptlets:1}
> > %ldconfig_scriptlets libs
> > %ldconfig_scriptlets libelf
> > %else
> > %post libs -p /sbin/ldconfig
> > %postun libs -p /sbin/ldconfig
> > %post libelf -p /sbin/ldconfig
> > %postun libelf -p /sbin/ldconfig
> > %endif
> 
> Even simpler
> 
> %if 0%{?fedora} < 28
> %post   libs   -p /sbin/ldconfig
> %postun libs -  p /sbin/ldconfig
> %post   libelf -p /sbin/ldconfig
> %postun libelf -p /sbin/ldconfig
> %endif

This is wrong because. This macro is defined on all EPEL and Fedora, so Mark's
way is correct (almost).

> Because the ldconfig_scriptlets stuff only work in koji, not in other
> build system (brew, cbs, ...)

This is not a problem for Fedora.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqH8G0ACgkQaVcUvRu8
X0zjtg//XBoj8FwvFwOsdMAOgyncuEiSTgUBfKXnbLGsfqxTFSYPnZP3mFv5W/sZ
4V9yg27CodQc7lvD86N5uICRNhmWNYkJ1N/uTeqvySayQhvSDG2N5w+39fJdNOlI
vxcsCewbyf8af70oYPL4AF5F7y0er7Og/YfxRlJnWeUg2o6z/691SmTErNQ1xUJu
EaKc+2d0lsSPE7XGCtiC7gSoqhTM3jPW8RhXVgY4lJNSvjFHAgoy8MIikxGbi9/J
3D91rdirr5bB4yS/KlV2cVe6bHJusGwAZoqmwbDyaIoCm7/7xCC+XDXo/U30iR+k
LqZ3LBRd511xeQ8jIYRPtclbruxzmC30/WgkIYUWstN/yuFvykxK3wS9yGzudzpQ
hsuWejdOLRxE/lsR6DoP3IwOsLtY+QmItuT3C9xDGrhpnOgTxe2FpwyuAS4RNCG/
jjQ1gl6q6Fw9mESTXTxeNjC9dGg9Sb5HiW1Hnps5bi9jaEJ/FCfRzmUwEIlQETqz
JRdAWa1ysJwTb9zCC5wfzaiv2kklJFcAYffz8rbH0TnB++KzA6aDL6GByxArB+Jl
/EZzGpQfc7LN74p7jQp/SdCIn+pWkrh7gyEO2F//0rMsg+z5irUj+pYY6/nAqu0s
28X0AmZqdCMEBjGS5fkttO084uuNVhnikxLtoTivI+lp8zMUh+A=
=AfcB
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org