Reliability test for hard drives and SSD

[Andrey Ponomarenko]

Hi there!

Good news for all interested in hardware compatibility and reliability.

I've started a new project to estimate reliability of hard drives and SSD in 
real-life conditions based on the SMART data reports collected by Linux users 
in the Linux-Hardware.org database since 2014. The initial data (SMART 
reports), analysis methods and results are publicly shared in a new github 
repository: https://github.com/linuxhw/SMART. Everyone can contribute to the 
report by uploading probes of their computers by the hw-probe tool!

The primary aim of the project is to find drives with longest "power on hours" 
and minimal number of errors. The following formula is used to measure 
reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first 
error/between errors.

Please be careful when reading the results table. Pay attention not only to the 
rating, but also to the number of checked model samples. If rating is low, then 
look at the number of power-on days and number of errors occurred. New drive 
models will appear at the end of the rating table and will move to the top in 
the case of long error-free operation.

Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and 
others who had made this work possible by contribution to the database!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel marking files in /boot as %ghost

[Samuel Rakitničan]

> What is the result you expect from this email?  You filed a bug, it
was closed because the packaging was done intentionally and there is
no other solution when considering the original reasons for the
change.  I'm not sure if you want the original change reverted
entirely or what you would like to see, but "I don't like this" isn't
really productive.  Also, using rpm -qV as an indication that kernel
installation is correct and bootable is simply never going to work
anyway.  The initramfs is generated at kernel installation time, and
therefore has to be marked as %ghost.  If that is missing, your
machine doesn't boot with that kernel.  If the grub config file
doesn't get updated, your machine doesn't boot with that kernel.

Not having initramfs or grub updated because of scriptlets not executing is 
expected, kernel image and configuration files etc. are however not. I am 
hoping for a discussion on how to potentially do this better without working 
around important rpm features.

> What suggestion do you have for a solution?

Stating the obvious, but why not install files to /boot in the first place as 
it was before. It seems the only logical thing to do until grub and other 
utilities learn how to read from other places.

Also it seems like I am not the right person to answer that question since I 
still don't understand what are the benefits of having these files installed to 
/usr/lib/modules and also having them installed by default? If I understand 
correctly the only purpose they serve is to copy them back to /boot from some 
kind of /usr system image when restoring the system. This doesn't seem to me as 
a reason to install them by default in /usr in the first place.

How about installing the files to /boot by default and making an optional 
subpackage named something like "kernel-stateless" with copies of these files. 
That way whatever needs its presence can depend on this subpackage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: News in opencv package

[Sérgio Basto]

On Sat, 2018-03-03 at 00:58 +0100, Till Hofmann wrote:
> 
> On 03/02/2018 08:31 PM, Sérgio Basto wrote:
> > On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote:
> > > On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote:
> > > > 
> > > > player will fail due a glibc problem 
> > > 
> > > Can you elaborate? You've tried a build and it blew up?
> > > 
> > > I am starting to get rather worried about this new glibc that
> > > landed
> > > yesterday. I think it might be breaking several things.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1
> > 
> > player is FTBFS since glibc 2.27, is not new . 
> > 
> > 
> 
> I was just going to take a look, but it seems like Rich already fixed
> player last week:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1036515
> https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b2
> 4f99397b0ac84e4?branch=master

Cool , so as owner of fawkes you can built it , at least for F28 


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1551174] New: perl-Test2-Suite-0.000102 is available

[bugzilla]

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

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



Latest upstream release: 0.000102
Current version/release in rawhide: 0.000100-1.fc28
URL: http://search.cpan.org/dist/Test2-Suite/

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

-- 
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: News in opencv package

[Till Hofmann]

On 03/02/2018 08:31 PM, Sérgio Basto wrote:
> On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote:
>> On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote:
>>>
>>> player will fail due a glibc problem 
>>
>> Can you elaborate? You've tried a build and it blew up?
>>
>> I am starting to get rather worried about this new glibc that landed
>> yesterday. I think it might be breaking several things.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1
> 
> player is FTBFS since glibc 2.27, is not new . 
> 
> 

I was just going to take a look, but it seems like Rich already fixed
player last week:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1036515
https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b24f99397b0ac84e4?branch=master

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

Fedora 28-20180302.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Atomic raw-xz x86_64

Failed openQA tests: 16/127 (x86_64), 7/24 (i386), 1/2 (arm)

ID: 196778  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/196778
ID: 196791  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196791
ID: 196793  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196793
ID: 196794  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196794
ID: 196807  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196807
ID: 196808  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196808
ID: 196809  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196809
ID: 196810  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/196810
ID: 196811  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/196811
ID: 196812  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/196812
ID: 196813  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/196813
ID: 196814  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/196814
ID: 196824  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/196824
ID: 196825  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/196825
ID: 196833  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/196833
ID: 196846  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/196846
ID: 196847  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196847
ID: 196852  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196852
ID: 196863  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/196863
ID: 196895  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/196895
ID: 196896  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/196896
ID: 196901  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/196901
ID: 196907  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/196907
ID: 196914  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/196914

Soft failed openQA tests: 7/127 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 196786  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/196786
ID: 196787  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/196787
ID: 196835  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196835
ID: 196849  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196849
ID: 196858  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/196858
ID: 196861  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/196861
ID: 196871  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/196871
ID: 196889  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/196889
ID: 196891  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/196891

Passed openQA tests: 82/127 (x86_64), 15/24 (i386)

Skipped openQA tests: 20 of 153
-- 
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

Re: why do I keep getting Broken dependencies: nfs-ganesha emails

[Kevin Fenzi]

On 03/02/2018 12:48 PM, Kaleb S. KEITHLEY wrote:
> 
> E.g.:
> ...
> On x86_64:
>   nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires
> libntirpc.so.1.6(NTIRPC_1.6.0)(64bit)
> ...
> 
> 
> I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and
> even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining
> about -0.4rc5.
> 
> Is something stuck somewhere that it is complaining about this obsolete
> build?

No, you only build -1 in rawhide/f29. branched/f28 was still using the
rc5 one until you built -2 today:


> ➜  ~ koji list-tag-history --package=nfs-ganesha --tag=f28
...snip...
> Fri Feb  9 05:06:18 2018: nfs-ganesha-2.6.0-0.4rc5.fc28 tagged into f28 by 
> autopen [still active]
> Fri Mar  2 04:43:10 2018: nfs-ganesha-2.6.0-2.fc28 tagged into f28 by autopen 
> [still active]
> ➜  ~ koji list-tag-history --package=nfs-ganesha --tag=f29
> Tue Feb 20 02:28:06 2018: nfs-ganesha-2.6.0-0.4rc5.fc28 tagged into f29 by 
> mohanboddu [still active]
> Tue Feb 20 05:31:30 2018: nfs-ganesha-2.6.0-1.fc28 tagged into f29 by autopen 
> [still active]
> Tue Feb 20 13:17:42 2018: nfs-ganesha-2.6.0-0.5rc5.fc29 tagged into f29 by 
> autopen [still active]
> Fri Feb 23 07:57:35 2018: nfs-ganesha-2.6.0-1.fc29 tagged into f29 by autopen 
> [still active]
> Fri Mar  2 04:40:52 2018: nfs-ganesha-2.6.0-2.fc29 tagged into f29 by autopen 
> [still active]

So, it should go away with tomorrow's f28 compose

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: Re: Frequently broken Rawhide/Branched composes

[Kevin Fenzi]

On 03/02/2018 08:42 AM, Nicolas Mailhot wrote:
> Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit :

...snip...

>> That'd actually give us the opportunity to clean up more our repos no?
>> :)
> 
> Explain that to someone who had several hours/days of builds rejected
> because of a broken obsolete package somewhere in the repo :(

Well, it wouldn't be rejected, it just would be held.

* Get your side tag
* Do all your bootstrapping builds and rebuilding things that depend on
it in the side tag.
* submit it, and it gets checked

Say there's one old package that doesn't build anymore against the new
stack. You could either wait for it to get fixed or decide the rest of
the builds are too important and wave the test to move them in.
There would still be some breakage there (the one old package), but at
least we would have record of who said that was ok so we could talk to
them, and it's a deliberate decision.

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: Why size of repositories metadata is too high in Fedora?

[Colin Walters]

On Fri, Mar 2, 2018, at 3:29 PM, Andrew Lutomirski wrote:

> I feel like that discussion is ignoring a third option: keep file deps
> built preprocess the repo metadata to turn each file dep that is
> uniquely satisfied by a single package into a direct dependency on
> that package.

This discussion is, but that was my first thought too; see
https://github.com/projectatomic/rpm-ostree/issues/1127

I actually started writing just a little bit of code for it; I don't really
have anything to show yet, but if I do I'll post it.  It will clearly 
complement zsync
or similar by being a lot less data to sync.

(I think it's a lot more practical than anything requiring changes to librepo 
today anyways)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

why do I keep getting Broken dependencies: nfs-ganesha emails

[Kaleb S. KEITHLEY]

E.g.:
...
On x86_64:
nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires
libntirpc.so.1.6(NTIRPC_1.6.0)(64bit)
...


I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and
even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining
about -0.4rc5.

Is something stuck somewhere that it is complaining about this obsolete
build?

--

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

Re: BuildError: package PKGNAME not in list for tag f29-pending

[Kevin Fenzi]

On 03/02/2018 01:22 AM, Jan Chaloupka wrote:
> Hi,
> 
> anyone knows cause of the build error message? Getting the message for
> 70 Go packages when building for rawhide.

FYI, this was due to the new go macros treating everything as lower
space, when these 70 packages had upper case in the name.

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: Why size of repositories metadata is too high in Fedora?

[Andrew Lutomirski]

> On Mar 2, 2018, at 6:42 AM, Matthew Miller  wrote:
>
>> On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote:
>> I don't know, I just ran "dnf upgrade" and it took metadata in
>> mentioned size, Fedora developers should answer to these questions.
>
> A very large chunk of it is this:
> https://pagure.io/packaging-committee/issue/714
>
>

I feel like that discussion is ignoring a third option: keep file deps
built preprocess the repo metadata to turn each file dep that is
uniquely satisfied by a single package into a direct dependency on
that package.  Obviously, once the package is actually installed, rpm
would record the actual deps, but that's only for the packages that
are installed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Kevin Fenzi]

On 03/01/2018 07:40 PM, Kevin Kofler wrote:

> And how do you propose doing that? The only reliable way to hold packages 
> that break the compose would be to actually try to run the whole compose 
> process after every package build. That just does not scale. The composes 
> are only daily for a reason. Running a compose for every package build would 
> use a lot of resources and would also take very long, delaying the tagging 
> of the package into Rawhide for an insane amount of time (at least hours).

The vast majority of issues are related to a package update causing
broken deps for something needed in something release blocking. So, I
would start there and setup gating to check for broken deps and require
waving that test or fixing the deps.

The next most common issue is core tools changing that we use to compose
(lorax, anaconda, kernel, glibc). For those we are intending to try and
make 'quick composes' that compose something quickly and test it to
catch common/simple issues.

Then we go from there.

> If you propose just doing some fast automated tests catching some issues, 
> that will never reliably catch all issues breaking the composes, and so my 
> proposals to increase the robustness of the compose process will still be 
> relevant. The only way to know for sure whether the compose will succeed is 
> to run it (and even that will not necessarily catch non-deterministic 
> failures).

The problems I see with just shipping whatever we compose:

* It means things will likely be broken longer as there is less urgency
to fix them quickly.
* There's cascading issues where issue A stops composing of items 1, 2,
3, 4 and each of those have further issues, so it means we don't even
know what all is broken.
* Shipping things out means we can't easily untag or revert packages
with using Epoch's much more commonly.
* It will mean we are not in fact always shipping alpha quality, we
could be shipping anything.
* reactive just is a lot harder in the end, IMHO.

> It is just defensive programming to not fail the whole process on any small 
> issue that you cannot avoid (with the resources that are available).

Not if you aren't sure of the thing you are producing.
> 
> By the way, in the distant past, if some (or even all) live image compose(s) 
> failed, the compose would just get published without that/those live 
> image(s) (in the worst case, with an empty Live directory). Not ideal (and 
> keeping the last successful build of each image as I suggest doing would be 
> an improvement on that, Koji should be enough to fulfill the copyleft 
> licenses' source distribution requirements), but at least the package repo 
> went out a lot more often than nowadays.

Well, I think the last few weeks have been particularly bad... it's not
always like this (or even ever).
> 
> 
> I am not asking you to ship bug-free composes. (I know that's impossible. 
> ;-) ) I am just asking you to take less than a week to get a compose with an 
> already built critical fix out. :-)

Well, I am not sure I would call that a critical fix, but to each their
own.

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: News in opencv package

[Sérgio Basto]

On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote:
> On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote:
> > 
> > player will fail due a glibc problem 
> 
> Can you elaborate? You've tried a build and it blew up?
> 
> I am starting to get rather worried about this new glibc that landed
> yesterday. I think it might be breaking several things.

https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1

player is FTBFS since glibc 2.27, is not new . 


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[Adam Williamson]

On Thu, 2018-03-01 at 18:44 -0700, stan wrote:
> On Thu, 01 Mar 2018 14:29:45 -
> "Farhad Mohammadi Majd"  wrote:
> 
> > Hello, in Debian (9, stable), size of all the official repositories
> > metadata is maximum 10MB, while in Fedora, today I ran "dnf update"
> > for first time after installing Fedora 27
> > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two
> > official repositories!
> > 
> > It is really too high, why there is such difference? why don't
> > optimize it and fix this problem?
> 
> I don't have any intimate knowledge of this.  But you are comparing
> apples and oranges.  Apt and dnf.  Either the format of the meta data
> must be very different for the two, or apt must send much less meta
> data. 
> 
> You aren't alone in complaining about this.  Whenever an update occurs,
> all the meta data has to be downloaded again.

Well, not 'all' of it. The first run of dnf downloads an especially
large amount of metadata as it gets the metadata for the frozen release
repository ('fedora'). That never changes, so it only ever needs to get
downloaded once. Subsequent runs will only need to update the metadata
for the 'updates' and 'updates-testing' repositories, which is smaller.
-- 
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: News in opencv package

[Adam Williamson]

On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote:
> 
> player will fail due a glibc problem 

Can you elaborate? You've tried a build and it blew up?

I am starting to get rather worried about this new glibc that landed
yesterday. I think it might be breaking several things.
-- 
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: Appstream metadata compose failures

[Milan Crha]

On Fri, 2018-03-02 at 11:28 +0100, Kalev Lember wrote:
> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> 
> Would be awesome if maintainers could have a look and see if they can
> make their packages pass!

Hi,
even not a maintainer, why is evolution-rss in the list, please? There
is no "Vetos" section on that page for it, neither I noticed anything
in a scratch build log I ran for rawhide, finished few minutes ago.
https://koji.fedoraproject.org/koji/taskinfo?taskID=25422190

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

Re: News in opencv package

[Sérgio Basto]

On Fri, 2018-03-02 at 10:29 -0800, Adam Williamson wrote:
> On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote:
> > On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote:
> > > 
> > > On 03/02/2018 12:24 PM, Josef Ridky wrote:
> > > > Hi folks,
> > > > 
> > > > I would like to inform you, that new version of opencv package
> > > > (3.4.1) will be available in rawhide and Fedora 28.
> > > > All packages, that requires opencv should be rebuild.
> > > > 
> > > 
> > > It would be nice if the announcement would have been made a week
> > > in
> > > advance, as stated in the guidelines, and as currently discussed
> > > in the
> > > other thread.
> > > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.
> > > 2F_master
> > 
> > Also note that Beta freeze is on 2018-03-06, so you are leaving
> > maintainers of dependent packages only about 3 days to do their
> > rebuilds for F28. :(
> 
> In fact, 3.4.1 has not yet been built for F28, now I check. Would you
> consider not doing it at present, given the F28 schedule? Thanks.
> 
> I am rebuilding dependencies for F29 (was doing for F28 also, but
> obviously will stop that).

dnf repoquery --disablerepo='*' --enablerepo=rawhide --alldeps --
whatrequires 'libopencv*' --srpm --quiet | sed
 's|\(-[^-]\+\)\{2\}.src||'


OpenImageIO
YafaRay
digikam
fawkes
frei0r-plugins
gmic
libfreenect
mlt
mrpt
nomacs
opencv
os-autoinst
php-facedetect
player
simarrange
simon
siril


player will fail due a glibc problem 

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 962  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 852  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 823  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 434  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 163  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  82  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  54  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5   
mbedtls-2.7.0-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9   
seamonkey-2.49.2-2.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6ac908eac8   
openjpeg2-2.3.0-6.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6


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

dpm-xrootd-3.6.4-5.el6
openvpn-2.4.5-1.el6

Details about builds:



 dpm-xrootd-3.6.4-5.el6 (FEDORA-EPEL-2018-b22a063e36)
 XROOT interface to the Disk Pool Manager (DPM)

Update Information:

Bugfix release, no major changes.




 openvpn-2.4.5-1.el6 (FEDORA-EPEL-2018-a95abc37cf)
 A full-featured SSL VPN solution

Update Information:

Releasing upstream openvpn-2.4.5, which contains several bug-fixes and feature
improvements. Details can can be found here in the [upstream change
log](https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst).  **Please
note** the separate list of [deprecated
options](https://community.openvpn.net/openvpn/wiki/DeprecatedOptions). Several
options are going to be removed in the coming releases.  And also start planning
your migration away from the Blowfish/BF-CBC cipher.  OpenVPN 2.4 provides by a
quite easy way to do the cipher migration gradually.

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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
 1089  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 852  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 434  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 331  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 163  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 100  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  50  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832   
seamonkey-2.49.2-2.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4   
mbedtls-2.7.0-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3   
knot-resolver-2.1.0-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1   
openjpeg2-2.3.0-6.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7


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

argbash-2.6.0-1.el7
dpm-xrootd-3.6.4-5.el7
openvpn-2.4.5-1.el7
pagekite-0.5.9.2-1.el7
php-bartlett-php-compatinfo-db-1.30.0-1.el7
python-libcloud-2.2.1-5.el7
synergy-1.8.8-3.el7
waiverdb-0.9.0-1.el7
yubikey-piv-manager-1.4.2-3.el7

Details about builds:



 argbash-2.6.0-1.el7 (FEDORA-EPEL-2018-193b444e50)
 Bash argument parsing code generator

Update Information:

Update to 2.6.0  Adds preliminary bash-completion support




 dpm-xrootd-3.6.4-5.el7 (FEDORA-EPEL-2018-76ef623773)
 XROOT interface to the Disk Pool Manager (DPM)

Update Information:

Bugfix release, no major changes.




 openvpn-2.4.5-1.el7 (FEDORA-EPEL-2018-57e2736a0c)
 A full-featured SSL VPN solution

Update Information:

Releasing upstream openvpn-2.4.5, which contains several bug-fixes and feature
improvements. Details can can be found here in the [upstream change
log](https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst).  **Please
note** the separate list of [deprecated
options](https://community.openvpn.net/openvpn/wiki/DeprecatedOptions). Several
options are going to be removed in the coming releases.  And also start planning
your migration away from the Blowfish/BF-CBC cipher.  OpenVPN 2.4 provides by a
quite easy way to do the cipher migration gradually.

References:

  [ 1 ] Bug #1526743 - Permissions on /etc/openvpn/server break default 
client-config-dir
https://bugzilla.redhat.com/show_bug.cgi?id=1526743




 pagekite-0.5.9.2-1.el7 (FEDORA-EPEL-2018-a7578c5325)
 Makes localhost servers visible to the world

Update Information:

New package - pagekite: makes localhost servers visible to the world

References:

  [ 1 ] Bug #910699 - Review Request: pagekite - makes localhost servers 
visible to the world
https://bugzilla.redhat.com/show_bug.cgi?id=910699




 php-bartlett-php-compatinfo-db-1.30.0-1.el7 (FEDORA-EPEL-2018-d1dc597e20)
 Reference Database to be used with php-compatinfo library

Re: News in opencv package

[Adam Williamson]

On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote:
> On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote:
> > 
> > On 03/02/2018 12:24 PM, Josef Ridky wrote:
> > > Hi folks,
> > > 
> > > I would like to inform you, that new version of opencv package (3.4.1) 
> > > will be available in rawhide and Fedora 28.
> > > All packages, that requires opencv should be rebuild.
> > > 
> > 
> > It would be nice if the announcement would have been made a week in
> > advance, as stated in the guidelines, and as currently discussed in the
> > other thread.
> > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master
> 
> Also note that Beta freeze is on 2018-03-06, so you are leaving
> maintainers of dependent packages only about 3 days to do their
> rebuilds for F28. :(

In fact, 3.4.1 has not yet been built for F28, now I check. Would you
consider not doing it at present, given the F28 schedule? Thanks.

I am rebuilding dependencies for F29 (was doing for F28 also, but
obviously will stop that).
-- 
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: News in opencv package

[Adam Williamson]

On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote:
> 
> On 03/02/2018 12:24 PM, Josef Ridky wrote:
> > Hi folks,
> > 
> > I would like to inform you, that new version of opencv package (3.4.1) will 
> > be available in rawhide and Fedora 28.
> > All packages, that requires opencv should be rebuild.
> > 
> 
> It would be nice if the announcement would have been made a week in
> advance, as stated in the guidelines, and as currently discussed in the
> other thread.
> https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

Also note that Beta freeze is on 2018-03-06, so you are leaving
maintainers of dependent packages only about 3 days to do their
rebuilds for F28. :(
-- 
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: Why size of repositories metadata is too high in Fedora?

[Nico Kadel-Garcia]

On Fri, Mar 2, 2018 at 12:40 PM, Neal Gompa  wrote:
> On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia  wrote:
>> On Thu, Mar 1, 2018 at 9:46 AM, chicago  wrote:
>>> Good question. What is in this 20+58MB? Is it all text? Does most of it it 
>>> change infrequently?/Maybe we can diff it?
>>
>> Most of it is pretty stable. But it's database-stored, and it's
>> compressed. Both cause the overall files to change and be awkward to
>> incrementally update, even if only one RPM actually changed.
>>
>> This is an old issue. One can reduce the download size needed and
>> expand the local disk and computational requirements by adding
>> delta-update and repodata merge tools, much as "deltarpms" did for the
>> RPM's themselves. It helps, but it's also adding local CPU burden, and
>> filesystem churn on the upstream repos to try and maintain that binary
>> data as well as the original repodata. In My Honest Opinion, this is
>> not going away until the whole "let's keep this all in one database"
>> approach is discarded and individual small metadata files for each
>> RPM, which can be surveyed and updated individually, replace the
>> repodata. That is much more like apt, and it's unlikely in the
>> foreseeable feature.
>
> APT hasn't done it this way in years. They've been actively reducing
> the number of files because it makes it punishing for mirrors and is
> rife for synchronization errors.

I'm old. ;-) And... interesting. The trade-off between "I can
incrementally update this by updating small files" versus I have an
efficient but monolithic database and have to update that atomically"
can be fun to select.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[Neal Gompa]

On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia  wrote:
> On Thu, Mar 1, 2018 at 9:46 AM, chicago  wrote:
>> Good question. What is in this 20+58MB? Is it all text? Does most of it it 
>> change infrequently?/Maybe we can diff it?
>
> Most of it is pretty stable. But it's database-stored, and it's
> compressed. Both cause the overall files to change and be awkward to
> incrementally update, even if only one RPM actually changed.
>
> This is an old issue. One can reduce the download size needed and
> expand the local disk and computational requirements by adding
> delta-update and repodata merge tools, much as "deltarpms" did for the
> RPM's themselves. It helps, but it's also adding local CPU burden, and
> filesystem churn on the upstream repos to try and maintain that binary
> data as well as the original repodata. In My Honest Opinion, this is
> not going away until the whole "let's keep this all in one database"
> approach is discarded and individual small metadata files for each
> RPM, which can be surveyed and updated individually, replace the
> repodata. That is much more like apt, and it's unlikely in the
> foreseeable feature.

APT hasn't done it this way in years. They've been actively reducing
the number of files because it makes it punishing for mirrors and is
rife for synchronization errors.


-- 
真実はいつも一つ！/ 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: Why size of repositories metadata is too high in Fedora?

[Nico Kadel-Garcia]

On Thu, Mar 1, 2018 at 9:46 AM, chicago  wrote:
> Good question. What is in this 20+58MB? Is it all text? Does most of it it 
> change infrequently?/Maybe we can diff it?

Most of it is pretty stable. But it's database-stored, and it's
compressed. Both cause the overall files to change and be awkward to
incrementally update, even if only one RPM actually changed.

This is an old issue. One can reduce the download size needed and
expand the local disk and computational requirements by adding
delta-update and repodata merge tools, much as "deltarpms" did for the
RPM's themselves. It helps, but it's also adding local CPU burden, and
filesystem churn on the upstream repos to try and maintain that binary
data as well as the original repodata. In My Honest Opinion, this is
not going away until the whole "let's keep this all in one database"
approach is discarded and individual small metadata files for each
RPM, which can be surveyed and updated individually, replace the
repodata. That is much more like apt, and it's unlikely in the
foreseeable feature.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1550752] perl-Locale-Codes-3.56 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Locale-Codes-3.56-1.fc27 has been pushed to the Fedora 27 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-437212397f

-- 
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: Draft: Macros to tell what Python versions to package for

[Jason L Tibbitts III]

> "MH" == Miro Hrončok  writes:

MH> I expect it to be called for both 2 and 3 unconditionally. Hiding
MH> the condition in the maro makes things too magical for me.

I don't think that stance holds up well as we increasingly hide things
in macros and will continue to hide even more.  (I'd like to see even
more hidden with macros, up to having whole classes of specfiles
completely generated by macros.)

And I can certainly understand the git branch thing, but if we
universally adopt and integrate %{with python3} as the conditional and
you're manually passing --without python3 then why would you really want
%py3_build to be executed unconditionally?  The principle of least
surprise would suggest that it isn't executed.

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

Summary/Minutes from today's FESCo Meeting (2018-03-02)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.log.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Draft: Macros to tell what Python versions to package for

[Jason L Tibbitts III]

> "PV" == Petr Viktorin  writes:

PV> %install

PV> %install

PV> %if %{with python2}
PV> %py2_install
PV> %endif
PV> %if %{with python3}
PV> %py3_install
PV> %endif

So... why not just make %py2_install and %py3_install just do the
%{with python*} internally, so the result is just

%install
%py2_install
%py3_install

And things just work.  That way you only need the conditionals when
you're doing something not covered by the macros.

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

Re: Re: Frequently broken Rawhide/Branched composes

[Nicolas Mailhot]

Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit :
> On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote:
> > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
> > > 
> > > I disagree entirely with the above. I think the solution is to
> > > gate
> > > packages coming into rawhide and hold or reject those that break
> > > the
> > > compose until they are fixed. 
> > 
> > While I don't disagree with the sentiment there needs to be a
> > mechanism
> > to handle bootstraps, where there are known-broken repository
> > statuses
> > between the beginning of the operation, when first bootstapped
> > pavkages
> > are injected, and the end, when several rebuild passes managed to
> > get
> > them all in fully build status.
> 
> Wouldn't side-tags in koji handle this? Imagining there was a tool to
> let packagers create/merge them as they need.

Maybe.
Let's just say, than after working for a few months with go, I've
severely revised my understanding of bootstrapping complexity, both on
the number of packages it may involve and the number of build phases it
may need before succeeding.

> > Also, how would you handle obsolete forgotten stray packages that
> > linger
> > in the repo (because they've not been killed properly, or a tool bug
> > resulted in their non removal)? Gating gives any such package the
> > power
> > to block all updates in more critical packages
> 
> That'd actually give us the opportunity to clean up more our repos no?
> :)

Explain that to someone who had several hours/days of builds rejected
because of a broken obsolete package somewhere in the repo :(

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

Re: News in opencv package

[Till Hofmann]

On 03/02/2018 12:24 PM, Josef Ridky wrote:
> Hi folks,
> 
> I would like to inform you, that new version of opencv package (3.4.1) will 
> be available in rawhide and Fedora 28.
> All packages, that requires opencv should be rebuild.
> 

It would be nice if the announcement would have been made a week in
advance, as stated in the guidelines, and as currently discussed in the
other thread.
https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

For completeness' sake, here's the list of packages:

$ dnf repoquery --disablerepo='*' --enablerepo='fedora'
--releasever=rawhide --alldeps --whatrequires 'libopencv*'
OpenImageIO-0:1.8.8-2.fc28.i686
OpenImageIO-0:1.8.8-2.fc28.x86_64
OpenImageIO-iv-0:1.8.8-2.fc28.x86_64
OpenImageIO-utils-0:1.8.8-2.fc28.x86_64
YafaRay-0:3.3.0-7.fc28.x86_64
YafaRay-lib-0:3.3.0-7.fc28.x86_64
digikam-0:5.8.0-4.fc28.x86_64
digikam-libs-0:5.8.0-4.fc28.i686
digikam-libs-0:5.8.0-4.fc28.x86_64
fawkes-firevision-0:1.0.1-13.fc28.i686
fawkes-firevision-0:1.0.1-13.fc28.x86_64
fawkes-guis-0:1.0.1-13.fc28.i686
fawkes-guis-0:1.0.1-13.fc28.x86_64
frei0r-plugins-opencv-0:1.6.1-4.fc28.x86_64
gmic-0:2.1.8-2.fc28.i686
gmic-0:2.1.8-2.fc28.x86_64
libfreenect-opencv-0:0.5.5-4.fc28.i686
libfreenect-opencv-0:0.5.5-4.fc28.x86_64
mlt-0:6.6.0-3.fc28.i686
mlt-0:6.6.0-3.fc28.x86_64
mrpt-2d-slam-0:1.4.0-6.fc28.x86_64
mrpt-apps-0:1.4.0-6.fc28.x86_64
mrpt-base-0:1.4.0-6.fc28.i686
mrpt-base-0:1.4.0-6.fc28.x86_64
mrpt-camera-calibration-0:1.4.0-6.fc28.x86_64
mrpt-gridmap-navigation-0:1.4.0-6.fc28.x86_64
mrpt-libs-0:1.4.0-6.fc28.i686
mrpt-libs-0:1.4.0-6.fc28.x86_64
mrpt-navlog-viewer-0:1.4.0-6.fc28.x86_64
mrpt-rawlog-viewer-0:1.4.0-6.fc28.x86_64
mrpt-reactive-navigation-0:1.4.0-6.fc28.x86_64
mrpt-robotic-arm-kinematics-0:1.4.0-6.fc28.x86_64
mrpt-scene-viewer-0:1.4.0-6.fc28.x86_64
mrpt-stereo-camera-calibration-0:1.4.0-6.fc28.x86_64
nomacs-0:3.8.0-1.fc28.i686
nomacs-0:3.8.0-1.fc28.x86_64
opencv-0:3.3.1-4.fc28.i686
opencv-0:3.3.1-4.fc28.x86_64
opencv-contrib-0:3.3.1-4.fc28.i686
opencv-contrib-0:3.3.1-4.fc28.x86_64
opencv-core-0:3.3.1-4.fc28.i686
opencv-core-0:3.3.1-4.fc28.x86_64
opencv-devel-0:3.3.1-4.fc28.i686
opencv-devel-0:3.3.1-4.fc28.x86_64
os-autoinst-0:4.5-4.20180208gitab8eeda.fc28.x86_64
php-facedetect-0:1.1.0-10.fc28.x86_64
player-0:3.1.0-4.fc27.i686
player-0:3.1.0-4.fc27.x86_64
python2-opencv-0:3.3.1-4.fc28.x86_64
python2-openimageio-0:1.8.8-2.fc28.x86_64
python3-opencv-0:3.3.1-4.fc28.x86_64
simarrange-0:0.0-16.20170316git8238ce5.fc28.x86_64
simon-0:0.4.1-15.fc28.x86_64
simon-libs-0:0.4.1-15.fc28.i686
simon-libs-0:0.4.1-15.fc28.x86_64
siril-0:0.9.8-1.fc28.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[Farhad Mohammadi Majd]

On Thu, 2018-03-01 at 14:46 +, chicago wrote:
> Good question. What is in this 20+58MB? Is it all text? Does most of
> it it change infrequently?/Maybe we can diff it?

I don't know, I just ran "dnf upgrade" and it took metadata in
mentioned size, Fedora developers should answer to these questions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Draft: Macros to tell what Python versions to package for

[Miro Hrončok]

On 2.3.2018 16:23, Richard W.M. Jones wrote:

On Fri, Mar 02, 2018 at 10:36:36AM +0100, Miro Hrončok wrote:

Hello Pythonistas,

I've prepared a draft for Python packaging that introduces some new
macros that should ease packaging for Fedoras, EPELs and even
potential new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches
for this, so I don't know what bothers you most. The proposal with
example spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros

All you have to do to test it, is add the following block to your
spec (that won't be needed once this is actually implemented):

 %if 0%{?fedora}
 %global py3_must 1
 %global py3_may 1
 %global py2_may 1
 %endif

 %if 0%{?rhel} &&  0%{?rhel} <= 7
 %global py3_may 1
 %global py2_may 1
 %endif

 %if 0%{?rhel} > 7
 ... (use your best judgment here)
 %endif

Could you please provide feedback? Ask questions?

There is a note at the bottom of the draft about how you could
possibly start dropping Python 2 subpackages from Fedora.


Thanks for doing this, it is much needed.

I'm not really convinced by the *_may macros.  If I've gone to the
trouble of getting the subpackage snippets correct for both of python2
& python3, why wouldn't I just enable them in all possible situations?
I can't see a situation where we've got possible subpackages but we
don't want to build them (except for where python2/3 is not available
in the distro and so they can't be built).


You might want to remove python2 subpackage from Fedora because it's not 
needed by anything. Ultimately, removing leaf python2 subpackages is 
also our goal. If we only provide a macro that says "it is possible", 
people will keep using it until judgment day.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Richard Shaw]

On Fri, Mar 2, 2018 at 8:10 AM, Kalev Lember  wrote:

> On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
> > qdirstat.desktop
> > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/
> 32x32/
> > apps/qdirstat.png, Has no Icon
> >
> > Well, what if upstream doesn't provide bigger icons?
>
> I believe the answer is to work with upstream to provide updated icons.
>
> I would personally be a bit more lax with what icon sizes we allow, but
> right now we require at least a 64x64px icon.


Since the freedesktop minimum[1] is a 48x48 icon, perhaps it would be best
to be aligned with it.

Thanks,
Richard

[1]
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Kalev Lember]

On 03/02/2018 03:59 PM, Dennis Gilmore wrote:
> El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
>> Hi,
>>
>> hughsie just did a new appstream-data compose for F29 and I noticed
>> there's quite a large number of packages failing in the logs:
>>
>> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
>>
>> Would be awesome if maintainers could have a look and see if they can
>> make their packages pass!
>>
> We were supposed to make builds fail if the appstream metadata failed,
> why has that not been done?

Sorry, I dropped the ball on this. I believe we need a brp script for
rpmbuild that runs:

  DESTDIR=%{buildroot} appstream-util check-root

and errors out if it fails.


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

Re: Appstream metadata compose failures

[Kevin Kofler]

Richard Hughes wrote:
> 64x64 is a very low bar indeed, compared to all of the other
> platforms, e.g. Windows Store or the Apple AppStore.

All that's going to happen with such a requirement is that specfiles are 
going to run the icon through scale2x or hq2x if you're lucky, through a 
dumb ImageMagick convert resize if you're not.

You cannot expect the packager to draw a new icon for upstream software.

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

Re: Appstream metadata compose failures

[Dennis Gilmore]

El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
> Hi,
> 
> hughsie just did a new appstream-data compose for F29 and I noticed
> there's quite a large number of packages failing in the logs:
> 
> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> 
> Would be awesome if maintainers could have a look and see if they can
> make their packages pass!
> 
We were supposed to make builds fail if the appstream metadata failed,
why has that not been done?

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

[HEAD UP] soname bump Re: News in opencv package

[Sérgio Basto]

Hi, 
Josef thanks for your work. 
As request we inform that is a soname bump , hopefully shouldn't change
much since version 3.3.1 and bring a lot of security fixes 

Thanks,

On Fri, 2018-03-02 at 06:24 -0500, Josef Ridky wrote:
> Hi folks,
> 
> I would like to inform you, that new version of opencv package
> (3.4.1) will be available in rawhide and Fedora 28.
> All packages, that requires opencv should be rebuild.
> 
> Regards
> 
> Josef Ridky
> Associate Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
> 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Richard Hughes]

On 2 March 2018 at 14:10, Kalev Lember  wrote:
> I believe the answer is to work with upstream to provide updated icons.

Right, or patch them in the srpm. Working upstream is obviously better
than all the distros having to do the same thing...

> I would personally be a bit more lax with what icon sizes we allow, but
> right now we require at least a 64x64px icon.

64x64 is a very low bar indeed, compared to all of the other
platforms, e.g. Windows Store or the Apple AppStore.

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

Re: Appstream metadata compose failures

[Richard Hughes]

On 2 March 2018 at 14:44, Robert-André Mauchin  wrote:
> Also, with what command can I check if my package is now ok?

From memory, I think you can do "appstream-builder
name-of-the-file.rpm" and if it makes it into the example.xml.gz file
then it passed all the checks.

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

Re: Appstream metadata compose failures

[Robert-André Mauchin]

On vendredi 2 mars 2018 15:10:59 CET Kalev Lember wrote:
> On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
> 
> > qdirstat.desktop
> > Failed to load icon: icon was too small 32x32:
> > /usr/share/icons/hicolor/32x32/
 apps/qdirstat.png, Has no Icon
> > 
> > Well, what if upstream doesn't provide bigger icons?
> 
> 
> I believe the answer is to work with upstream to provide updated icons.
> 
> I would personally be a bit more lax with what icon sizes we allow, but
> right now we require at least a 64x64px icon.
> 
> -- 
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Also, with what command can I check if my package is now ok?

Best regards,

Robert-André

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

Re: Why size of repositories metadata is too high in Fedora?

[Matthew Miller]

On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote:
> I don't know, I just ran "dnf upgrade" and it took metadata in
> mentioned size, Fedora developers should answer to these questions.

A very large chunk of it is this:
https://pagure.io/packaging-committee/issue/714

-- 
Matthew Miller

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

Re: Call for users of darkserver

[Jan Kratochvil]

On Thu, 01 Mar 2018 19:30:28 +0100, Pierre-Yves Chibon wrote:
> On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote:
> > On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote:
> > It seems to me interactive crash core file analysis is just not a goal of 
> > ABRT
> > (which is what was the goal of darkserver).
> 
> Did it ever meet this goal?

I do not know.


> I never quite understood how it works, being far from this field, so I'm happy
> to be enlighten on the topic.

Darkserver itself will just give you a rpm build for given build-id.  So with
a core file (containing the build-ids) and a small shell script you can
reconstruct system (chroot) where you can load the core file for more thorough
crash analysis.


> > And currently after my reassignment in Red Hat I currently do not have any
> > ABRT bugreports to investigate so I am currently not involved in this
> > darkserver/ABRT build-id crash reproducibility (I may be again later).
> 
> Would you know if anyone in your old team would be interested by this?

It is not specific to GDB team.  I am curious how all the Fedora package
developers deal with ABRT-filed Bugs where the backtrace contained therein is
not sufficient to understand the problem but one may be able to understand it
accessing more data with GDB using the core file.

The backtrace contained in the ABRT bugreport can rarely really debug the
problem.  Sure even the core file is not always sufficient but it gives more
chance to debug the crash (which requires an darkserver-like functionality).

But then I usually cannot get even just the core file from ABRT users so this
is why I ask how other package (*) maintainers deal with the ABRT bugreports.

(*) It may be confusing I am GDB package maintainer when GDB is used for the
crash analysis.  But here I talk about GDB as any other program (like bash,
firefox etc.) as even GDB crashes like any other program (bash, firefox, etc.).


> I'm trying to assess if there is actually an interest for it.
> You said you were interested by it but aren't working on this topic anymore, I
> don't think anybody else than you noticed it not working over the course of 
> last
> year.

Yes, because I think nobody knows one could troubleshoot ABRT-bugreported
problems better than with the information filed by ABRT into Bugzilla.


> So I wonder if we shouldn't just call it a day,

It won't change the current state of bugs troubleshooting.
But Fedora should not forget the Bugs troubleshooting could be improved.


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

Re: Kernel marking files in /boot as %ghost

[Josh Boyer]

On Fri, Mar 2, 2018 at 1:11 AM, Samuel Rakitničan
 wrote:
> Dear list,
>
> I've stumbled upon a serious issue that has not been discussed before. 
> Somewhere around May 2015 kernel files was moved to 
> /usr/lib/modules/, which are then copied to /boot in post 
> scriptlets [1]. The issue is that such files are marked with %ghost because 
> they don't exist initially and are being copied when installed. Now because 
> of that rpm (rpm -qV) can't verify the files attributes correctly and heck 
> even doesn't point out if they don't exist at all as it is the case if dnf 
> fails in the middle of transaction. Because of that I've opened a bug report 
> [2], but it was closed because that was supposedly intended, but looking at 
> mailing list archive, I don't see this particular issue being raised and 
> frankly in my opinion marking files that are responsible to boot the system 
> as %ghost should not happen. %ghost should be used only when there is not any 
> other option left in case when files truly doesn't exist and its integrity 
> could not be verified in advance.

What is the result you expect from this email?  You filed a bug, it
was closed because the packaging was done intentionally and there is
no other solution when considering the original reasons for the
change.  I'm not sure if you want the original change reverted
entirely or what you would like to see, but "I don't like this" isn't
really productive.  Also, using rpm -qV as an indication that kernel
installation is correct and bootable is simply never going to work
anyway.  The initramfs is generated at kernel installation time, and
therefore has to be marked as %ghost.  If that is missing, your
machine doesn't boot with that kernel.  If the grub config file
doesn't get updated, your machine doesn't boot with that kernel.

What suggestion do you have for a solution?

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

Re: Appstream metadata compose failures

[Kalev Lember]

On 03/02/2018 02:56 PM, Robert-André Mauchin wrote:
> qdirstat.desktop
> Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/
> apps/qdirstat.png, Has no Icon
> 
> Well, what if upstream doesn't provide bigger icons?

I believe the answer is to work with upstream to provide updated icons.

I would personally be a bit more lax with what icon sizes we allow, but
right now we require at least a 64x64px icon.

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

Re: Appstream metadata compose failures

[Robert-André Mauchin]

On vendredi 2 mars 2018 11:28:40 CET Kalev Lember wrote:
> Hi,
> 
> hughsie just did a new appstream-data compose for F29 and I noticed
> there's quite a large number of packages failing in the logs:
> 
> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> 
> Would be awesome if maintainers could have a look and see if they can
> make their packages pass!
> 
> -- 
> Thanks,
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


qdirstat.desktop
Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/
apps/qdirstat.png, Has no Icon

Well, what if upstream doesn't provide bigger icons?

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

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #10 from Petr Pisar  ---
I finished adding ExtUtils::CBuilder dependency to spec files. I omitted some
of them where it came as a transitive dependency of some other already used
XS-builder used module because I do not feel competent nor motivate to hunt the
specific piece of line responsible for executing gcc in foreign packages. I
fell little bit uneasy with this change.

-- 
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: 389-ds-base and freeipa on 32 bit arches

[Jared K. Smith]

On Fri, Feb 23, 2018 at 6:39 PM, Jared K. Smith 
wrote:

> Can you give any more details on 32-bit ARM in particular -- is it just
> i686 that is experiencing issues, or have you seen similar memory
> corruption issues on 32-bit ARM as well?
>

Just another gentle ping -- do we have any more information here that can
help FESCo as it makes a decision about this issue?

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

[389-devel] Please review: Issue 49572 - ns_job_wait race on condvar

[Simon Pichugin]

Hi team,
please, review a small fix for nunc-stance tests:

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

https://pagure.io/389-ds-base/pull-request/49592

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

Re: Why size of repositories metadata is too high in Fedora?

[Farhad Mohammadi Majd]

On Thu, 2018-03-01 at 14:46 +, chicago wrote:
> Good question. What is in this 20+58MB? Is it all text? Does most of
> it it change infrequently?/Maybe we can diff it?

I don't know, I just ran "dnf upgrade" and it took metadata in
mentioned size, Fedora developers should answer to these questions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Need assistance to build openvdb for both Blender and LuxRender

[Florian Weimer]

On 03/02/2018 01:04 PM, Mamoru TASAKA wrote:
/builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In 
function 'void exportFloatGrid()':
/builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: 
error: 'py::numeric' has not been declared

  py::numeric::array::set_module_and_type("numpy", "ndarray");
  ^~~
make[2]: *** [openvdb/python/CMakeFiles/pyopenvdb.dir/build.make:66: 
openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o] Error 1

make[2]: *** Waiting for unfinished jobs

I don't know why make does not stop immediately here (-k option 
implicitly specified??)


Fedora builders use -j40 or something similar, so you tend to get lots 
of output from other jobs running parallel after the first error.


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

[Bug 1550959] New: perl-CGI-Application-4.61 is available

[bugzilla]

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

Bug ID: 1550959
   Summary: perl-CGI-Application-4.61 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CGI-Application
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 4.61
Current version/release in rawhide: 4.60-1.fc29
URL: http://search.cpan.org/dist/CGI-Application/

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

-- 
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: Need assistance to build openvdb for both Blender and LuxRender

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 03/02/2018 03:00 PM:

Hello team,

openvdb currently failed for some odd reasons
(https://koji.fedoraproject.org/koji/taskinfo?taskID=25408808) on both
Rawhide and F28 in order to rebuild for boost 1.66.

Looking for tail result from build.log, it seems the mockbuild hit a bug:

https://koji.fedoraproject.org/koji/getfile?taskID=25408809=DEFAULT=build.log=-4000

Can someone investigate the cause? Thanks



Actually the above build.log says:


make[2]: Entering directory '/builddir/build/BUILD/openvdb-5.0.0'
[ 36%] Building CXX object 
openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o
cd /builddir/build/BUILD/openvdb-5.0.0/openvdb/python && /usr/bin/c++  
-DOPENVDB_3_ABI_COMPATIBLE -Dpyopenvdb_EXPORTS -I/builddir/build/BUILD/openvdb-5.0.0 
-isystem /usr/include/OpenEXR -i
system /usr/include/python2.7  -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches -spe
cs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wl
,--as-needed -fPIC   -DOPENVDB_PRIVATE -DOPENVDB_USE_BLOSC  -o 
CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o -c 
/builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc
make[2]: Leaving directory '/builddir/build/BUILD/openvdb-5.0.0'
/builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In function 
'void exportFloatGrid()':
/builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: error: 
'py::numeric' has not been declared
 py::numeric::array::set_module_and_type("numpy", "ndarray");
 ^~~
make[2]: *** [openvdb/python/CMakeFiles/pyopenvdb.dir/build.make:66: 
openvdb/python/CMakeFiles/pyopenvdb.dir/pyFloatGrid.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs

I don't know why make does not stop immediately here (-k option implicitly 
specified??)
The above error message seems the same as:
https://github.com/dreamworksanimation/openvdb/issues/170

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

[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version|perl-Net-CardDAVTalk-0.09-1 |perl-Net-CardDAVTalk-0.09-1
   |.fc29   |.fc28
 Resolution|--- |NEXTRELEASE
Last Closed||2018-03-02 06:35:31



-- 
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: Why size of repositories metadata is too high in Fedora?

[Neal Gompa]

On Fri, Mar 2, 2018 at 5:05 AM, Pavel Raiskup  wrote:
> On Friday, March 2, 2018 2:44:19 AM CET stan wrote:
>> On Thu, 01 Mar 2018 14:29:45 -
>> "Farhad Mohammadi Majd"  wrote:
>>
>> > Hello, in Debian (9, stable), size of all the official repositories
>> > metadata is maximum 10MB, while in Fedora, today I ran "dnf update"
>> > for first time after installing Fedora 27
>> > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two
>> > official repositories!
>> >
>> > It is really too high, why there is such difference? why don't
>> > optimize it and fix this problem?
>>
>> I don't have any intimate knowledge of this.  But you are comparing
>> apples and oranges.  Apt and dnf.  Either the format of the meta data
>> must be very different for the two, or apt must send much less meta
>> data.
>
> Yes, IMO the amount of information in metadata creates the difference.
>
>> You aren't alone in complaining about this.  Whenever an update occurs,
>> all the meta data has to be downloaded again.  People on limited
>> quantity connections find this onerous.  There has been discussion of
>> making the meta data update an incremental update, but the format of
>> meta data doesn't lend itself well to doing this.  And the delta files
>> would put a lot of extra files on repo hosts.
>
> I doubt delta files for metadata would cause significant storage problems
> (compare that with the size of RPMs).  You don't have to keep the deltas
> forever, it would be matter of quality of implementation..
>
> Do we have some RFE bug for this, or some feature page?  This is #1 issue in
> yum/dnf world for quite some time.
>

There's an ongoing discussion in rpm-ecosystem@[1] and
infrastructure@[2] about an optimized delta repodata format. So...
It's coming. :)

[1]: http://lists.rpm.org/pipermail/rpm-ecosystem/2018-February/000541.html
[2]: 
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/4TJOGXT35Q2UHWYQA66FCCHCF5DOEXO5/

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

News in opencv package

[Josef Ridky]

Hi folks,

I would like to inform you, that new version of opencv package (3.4.1) will be 
available in rawhide and Fedora 28.
All packages, that requires opencv should be rebuild.

Regards

Josef Ridky
Associate Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Net-CardDAVTalk-0.09-1
   ||.fc29



--- Comment #1 from Petr Pisar  ---
An enhancement release. It changes existing functions and adds new
dependencies. Safer for Fedora ≥ 28 only.

-- 
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: Draft: Macros to tell what Python versions to package for

[Miro Hrončok]

On 2.3.2018 11:54, Petr Viktorin wrote:
I like to use bconds, i.e. "%if %{with python2}". They're easy to 
override for local builds, allowing easy experimentation with, for 
example, dropping Python 2.
I'd be happy if our official recommendation used bconds. If we want 
people to copy-paste something, let's make it good.


Also, "with_python2" is the current de-facto best practice. It's a good, 
descriptive name, and people are used to it.
The "%if 0%{?py3_may}" is not as descriptive. If that is used throughout 
the specfile, people will need to know/read the docs – or just consider 
it magic.


So, I'd prefer adding macros that set "with_python2" bconds, and using 
that throughout the specfile.



For a more concrete idea, would something like this work? Naming to be 
bikeshedded of course.


# Build for python2 if it MUST be done
%py2_bcond_if required
# Build for python3 if it MAY be done
%py3_bcond_if available

%build

%{?with_python2:py2_build}
%{?with_python3:py3_build}

%install

%if %{with python2}
%py2_install
%endif
%if %{with python3}
%py3_install
%endif


That looks good!



(And some kind of %py_build_all and %py_install_all as the next baby 
step? Or am I reinventing a wheel with that line of thought?)


That would be awesome, but let's keep that for another discussion maybe?


Also, I'd like to do some wordsmithing on the proposal when the 
technicalities are sorted out, so the following is obvious to people who 
just skim it:
- This new complexity is *only* meant for packagers who share specs 
across distros; others can stop reading now.

- FYI, we would love it if you dropped your py2 subpackage from Fedora.


Yes, yes!


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Draft: Macros to tell what Python versions to package for

[Miro Hrončok]

On 2.3.2018 11:50, Pavel Raiskup wrote:

On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote:

On 2.3.2018 11:25, Pavel Raiskup wrote:

On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote:

I've prepared a draft for Python packaging that introduces some new
macros that should ease packaging for Fedoras, EPELs and even potential
new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches for
this, so I don't know what bothers you most. The proposal with example
spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros
[..snip..]
Could you please provide feedback? Ask questions?


What's the real usecase for *_must?


This tells you that according to the guidelines for given distro, if
upstream supports this python version, you MUST package for it.
Some packages might want to only package their Python library for the
stacks where it's required.


FWIW, I don't think macros should be used to _enforce_ guidelines (should be
rather convenient things which everyone loves to use).  But no problem, as
long as I don't have to use that.  Just saying that it might be a bit
confusing when reading the (draft) wiki...


They don't enforce anything. They just make it possible to get the value 
defined by the guideline in a technical manner and do with the value 
whatever you please. It's still up to the packager to decide what to do 
when py3_must is 1 or when it's not.


If the wiki is confusing, I can try to reword the description. However 
I'm afraid everybody will just jump to the table anyway.





Why the py2_must is not defined for
epel7 and epel6?


Because there is no such guideline. It is completely OK to package for
python3 only on EPELs.


I always only needed to see whether (a) python2 runtime is available, (b)
python3 is available.  So more readable and understandable approach (to
me) would be to have only the %pyX_may (or %py3_available).  But I'm
probably not experienced enough, so I'm only curious :-).


For that, yes. here may == available. We can discuss the naming if it
sounds weird.



E.g. last time (argparse-manpage) I went with:

%if 0%{?fedora}
  %bcond_without python2
  %bcond_without python3
%else
  %if 0%{?rhel} > 7
%bcond_withpython2
%bcond_without python3
  %else
%bcond_without python2
%bcond_withpython3
  %endif
%endif

Which allows me to do things like:

%if %{with python2}
  
%endif

Or:

BuildRequires: %{?with_python3:foo} %{?with_python2:bar}

.. and which brings the convenient --with{,out}-python{2,3} options for
custom re-builds.  Could we have something similar in the draft, too?


We can definitively make those with statemetns, however we cannot make
it with_python2 and with_python3, because we might destroy current
specfiles with that. So we would need to have:

 %if %{with python2_must}
   
 %endif

Or:

 BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar}

And specifying those on the command line would be rather unreadable.
What does --with-python2-may even mean?


--with-py3 or --with-py3-available doesn't soudd that bad, but ..

I wouldn't worry about existing spec files..  and I would stick with
--with-python2 (and friends).  Existing spec files should not depend
on the distro-default value, since no distro so far defined that; which
means that whatever value is defined in spec file will _just_ override
the new system default.  For the few remaining packages (are there any?),
well, there go proven packagers...?


I hear you. I like the idea Petr just sent to python-devel, so lets 
continue from there.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Draft: Macros to tell what Python versions to package for

[Petr Viktorin]

I like to use bconds, i.e. "%if %{with python2}". They're easy to 
override for local builds, allowing easy experimentation with, for 
example, dropping Python 2.
I'd be happy if our official recommendation used bconds. If we want 
people to copy-paste something, let's make it good.


Also, "with_python2" is the current de-facto best practice. It's a good, 
descriptive name, and people are used to it.
The "%if 0%{?py3_may}" is not as descriptive. If that is used throughout 
the specfile, people will need to know/read the docs – or just consider 
it magic.


So, I'd prefer adding macros that set "with_python2" bconds, and using 
that throughout the specfile.



For a more concrete idea, would something like this work? Naming to be 
bikeshedded of course.


# Build for python2 if it MUST be done
%py2_bcond_if required
# Build for python3 if it MAY be done
%py3_bcond_if available

%build

%{?with_python2:py2_build}
%{?with_python3:py3_build}

%install

%if %{with python2}
%py2_install
%endif
%if %{with python3}
%py3_install
%endif


(And some kind of %py_build_all and %py_install_all as the next baby 
step? Or am I reinventing a wheel with that line of thought?)



Also, I'd like to do some wordsmithing on the proposal when the 
technicalities are sorted out, so the following is obvious to people who 
just skim it:
- This new complexity is *only* meant for packagers who share specs 
across distros; others can stop reading now.

- FYI, we would love it if you dropped your py2 subpackage from Fedora.


On 03/02/18 10:36, Miro Hrončok wrote:

Hello Pythonistas,

I've prepared a draft for Python packaging that introduces some new 
macros that should ease packaging for Fedoras, EPELs and even potential 
new RHELs, when it comes to python stacks.


I don't do much ifs in specfiles and prefer to leverage git branches for 
this, so I don't know what bothers you most. The proposal with example 
spec file is at:


https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros 



All you have to do to test it, is add the following block to your spec 
(that won't be needed once this is actually implemented):


     %if 0%{?fedora}
     %global py3_must 1
     %global py3_may 1
     %global py2_may 1
     %endif

     %if 0%{?rhel} &&  0%{?rhel} <= 7
     %global py3_may 1
     %global py2_may 1
     %endif

     %if 0%{?rhel} > 7
     ... (use your best judgment here)
     %endif

Could you please provide feedback? Ask questions?

There is a note at the bottom of the draft about how you could possibly 
start dropping Python 2 subpackages from Fedora.



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

[Bug 1550943] New: perl-Net-CardDAVTalk-0.09 is available

[bugzilla]

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

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



Latest upstream release: 0.09
Current version/release in rawhide: 0.08-2.fc28
URL: http://search.cpan.org/dist/Net-CardDAVTalk/

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

-- 
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 1550942] New: Upgrade perl-Lucy to 0.6.2

[bugzilla]

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

Bug ID: 1550942
   Summary: Upgrade perl-Lucy to 0.6.2
   Product: Fedora
   Version: rawhide
 Component: perl-Lucy
  Assignee: lkund...@v3.sk
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 0.6.1 version. Upstream released 0.6.2. When you have
free time, please upgrade it

-- 
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 1550940] New: Upgrade perl-CGI-Simple to 1.13

[bugzilla]

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

Bug ID: 1550940
   Summary: Upgrade perl-CGI-Simple to 1.13
   Product: Fedora
   Version: rawhide
 Component: perl-CGI-Simple
  Assignee: tcall...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest Fedora delivers 1.115 version. Upstream released 1.13. When you have
free time, please upgrade it

-- 
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: Draft: Macros to tell what Python versions to package for

[Miro Hrončok]

On 2.3.2018 11:25, Pavel Raiskup wrote:

On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote:

I've prepared a draft for Python packaging that introduces some new
macros that should ease packaging for Fedoras, EPELs and even potential
new RHELs, when it comes to python stacks.

I don't do much ifs in specfiles and prefer to leverage git branches for
this, so I don't know what bothers you most. The proposal with example
spec file is at:

https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros
[..snip..]
Could you please provide feedback? Ask questions?


What's the real usecase for *_must? 


This tells you that according to the guidelines for given distro, if 
upstream supports this python version, you MUST package for it.
Some packages might want to only package their Python library for the 
stacks where it's required.



Why the py2_must is not defined for
epel7 and epel6?


Because there is no such guideline. It is completely OK to package for 
python3 only on EPELs.




I always only needed to see whether (a) python2 runtime is available, (b)
python3 is available.  So more readable and understandable approach (to
me) would be to have only the %pyX_may (or %py3_available).  But I'm
probably not experienced enough, so I'm only curious :-).


For that, yes. here may == available. We can discuss the naming if it 
sounds weird.




E.g. last time (argparse-manpage) I went with:

   %if 0%{?fedora}
 %bcond_without python2
 %bcond_without python3
   %else
 %if 0%{?rhel} > 7
   %bcond_withpython2
   %bcond_without python3
 %else
   %bcond_without python2
   %bcond_withpython3
 %endif
   %endif

Which allows me to do things like:

   %if %{with python2}
 
   %endif

Or:

   BuildRequires: %{?with_python3:foo} %{?with_python2:bar}

.. and which brings the convenient --with{,out}-python{2,3} options for
custom re-builds.  Could we have something similar in the draft, too?


We can definitively make those with statemetns, however we cannot make 
it with_python2 and with_python3, because we might destroy current 
specfiles with that. So we would need to have:


   %if %{with python2_must}
 
   %endif

Or:

   BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar}

And specifying those on the command line would be rather unreadable. 
What does --with-python2-may even mean?


You can always define your with_python2 based on values of py2_may, 
py2_must and fedora version.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Appstream metadata compose failures

[Kalev Lember]

Hi,

hughsie just did a new appstream-data compose for F29 and I noticed
there's quite a large number of packages failing in the logs:

https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html

Would be awesome if maintainers could have a look and see if they can
make their packages pass!

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

[Bug 1550755] perl-Mozilla-CA-20180117 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Mozilla-CA-20180117-1.
   ||fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-02 05:25:07



--- Comment #1 from Petr Pisar  ---
No significant changes in binary package. Because we use system certificate
storage instead, Rawhide is enough.

-- 
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: Why size of repositories metadata is too high in Fedora?

[chicago]

Good question. What is in this 20+58MB? Is it all text? Does most of it it 
change infrequently?/Maybe we can diff it?

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

Re: Why size of repositories metadata is too high in Fedora?

[Pavel Raiskup]

On Friday, March 2, 2018 2:44:19 AM CET stan wrote:
> On Thu, 01 Mar 2018 14:29:45 -
> "Farhad Mohammadi Majd"  wrote:
> 
> > Hello, in Debian (9, stable), size of all the official repositories
> > metadata is maximum 10MB, while in Fedora, today I ran "dnf update"
> > for first time after installing Fedora 27
> > (Fedora-Workstation-Live-x86_64-27-1.6) and it took 20+58MB for two
> > official repositories!
> > 
> > It is really too high, why there is such difference? why don't
> > optimize it and fix this problem?
> 
> I don't have any intimate knowledge of this.  But you are comparing
> apples and oranges.  Apt and dnf.  Either the format of the meta data
> must be very different for the two, or apt must send much less meta
> data.

Yes, IMO the amount of information in metadata creates the difference.

> You aren't alone in complaining about this.  Whenever an update occurs,
> all the meta data has to be downloaded again.  People on limited
> quantity connections find this onerous.  There has been discussion of
> making the meta data update an incremental update, but the format of
> meta data doesn't lend itself well to doing this.  And the delta files
> would put a lot of extra files on repo hosts.

I doubt delta files for metadata would cause significant storage problems
(compare that with the size of RPMs).  You don't have to keep the deltas
forever, it would be matter of quality of implementation..

Do we have some RFE bug for this, or some feature page?  This is #1 issue in
yum/dnf world for quite some time.

Pavel

> I think you can be assured that if there was a simple optimization that
> could take care of this, it would have already been applied.
> ___
> 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 1550752] perl-Locale-Codes-3.56 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Locale-Codes-3.56-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-437212397f

-- 
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 1550752] perl-Locale-Codes-3.56 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Locale-Codes-3.56-1.fc
   ||29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 27.

-- 
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: Re: Frequently broken Rawhide/Branched composes

[Pierre-Yves Chibon]

On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote:
> Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
> > 
> > I disagree entirely with the above. I think the solution is to gate
> > packages coming into rawhide and hold or reject those that break the
> > compose until they are fixed. 
> 
> While I don't disagree with the sentiment there needs to be a mechanism
> to handle bootstraps, where there are known-broken repository statuses
> between the beginning of the operation, when first bootstapped pavkages
> are injected, and the end, when several rebuild passes managed to get
> them all in fully build status.

Wouldn't side-tags in koji handle this? Imagining there was a tool to let
packagers create/merge them as they need.

> Also, how would you handle obsolete forgotten stray packages that linger
> in the repo (because they've not been killed properly, or a tool bug
> resulted in their non removal)? Gating gives any such package the power
> to block all updates in more critical packages

That'd actually give us the opportunity to clean up more our repos no? :)


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

Draft: Macros to tell what Python versions to package for

[Miro Hrončok]

Hello Pythonistas,

I've prepared a draft for Python packaging that introduces some new 
macros that should ease packaging for Fedoras, EPELs and even potential 
new RHELs, when it comes to python stacks.


I don't do much ifs in specfiles and prefer to leverage git branches for 
this, so I don't know what bothers you most. The proposal with example 
spec file is at:


https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros

All you have to do to test it, is add the following block to your spec 
(that won't be needed once this is actually implemented):


%if 0%{?fedora}
%global py3_must 1
%global py3_may 1
%global py2_may 1
%endif

%if 0%{?rhel} &&  0%{?rhel} <= 7
%global py3_may 1
%global py2_may 1
%endif

%if 0%{?rhel} > 7
... (use your best judgment here)
%endif

Could you please provide feedback? Ask questions?

There is a note at the bottom of the draft about how you could possibly 
start dropping Python 2 subpackages from Fedora.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

BuildError: package PKGNAME not in list for tag f29-pending

[Jan Chaloupka]

Hi,

anyone knows cause of the build error message? Getting the message for 
70 Go packages when building for rawhide.


Regards

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

[Bug 1544589] perl-SNMP-Info-3.47 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-SNMP-Info-3.47-1.fc29
   ||perl-SNMP-Info-3.47-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|w...@gouldfamily.org|jples...@redhat.com
Last Closed||2018-03-02 04:12:46



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

Re: Re: Frequently broken Rawhide/Branched composes

[Nicolas Mailhot]

Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
> 
> I disagree entirely with the above. I think the solution is to gate
> packages coming into rawhide and hold or reject those that break the
> compose until they are fixed. 

While I don't disagree with the sentiment there needs to be a mechanism
to handle bootstraps, where there are known-broken repository statuses
between the beginning of the operation, when first bootstapped pavkages
are injected, and the end, when several rebuild passes managed to get
them all in fully build status.

Also, how would you handle obsolete forgotten stray packages that linger
in the repo (because they've not been killed properly, or a tool bug
resulted in their non removal)? Gating gives any such package the power
to block all updates in more critical packages

Regards,

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

[Bug 1549346] perl-Plack-Middleware-RemoveRedundantBody-0.07 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Plack-Middleware-Remov
   ||eRedundantBody-0.07-1.fc29
   ||perl-Plack-Middleware-Remov
   ||eRedundantBody-0.07-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|dd...@cpan.org  |jples...@redhat.com
Last Closed||2018-03-02 03:54:44



-- 
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: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Pierre-Yves Chibon]

On Fri, Mar 02, 2018 at 06:10:16AM +0100, Ralf Corsepius wrote:
> On 02/28/2018 05:43 PM, Adam Williamson wrote:
> > On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote:
> > > On 02/27/2018 07:27 PM, Richard Shaw wrote:
> > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> > > > > wrote:
> > > > 
> > > > 
> > > >  Once again, folks, *please* announce your soname bumps, and 
> > > > co-ordinate
> > > >  rebuilds. (In fact it looks like Zdenek is the maintainer of both
> > > >  packages and could have rebuilt cups-filters, but just forgot to).
> > > > 
> > > > 
> > > > Is it time to update the packaging guidelines to enforce setting a
> > > > "%global sover " and using it in %files?
> > > > 
> > > > If nothing else it should at least be documented as a best practice.
> > > 
> > > I would be very opposed to this.
> > > 
> > > Even though some folks want rawhide to appear a release, rawhide is not
> > > a release. So SONAME breakages are expected to happen in rawhide and
> > > maintainers supposed to be reacted upon.
> > 
> > This is not true and I have *specifically* pointed you at the policy
> > page which says it is not true, more than once.
> 
> And I have to reiterate my mantra: This plan is a non-realistic illusion. It
> simply does not work and will not work.
> 
> > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master
> > 
> > For updates to rawhide packages, Maintainers SHOULD:
> > 
> >  Try not to push a clearly broken build (breaks the default
> > buildroot package set, etc)
> 
> Note the "SHOULD" - This is the reflection of what I said above.

The SHOULD is necessary as otherwise we'll never be able to do soname bumps, but
that doesn't say: be reckless and ignore the people you're giving work to.

I think we all agree soname bumps happen and are necessary, what we try to
advocate is that they don't happen by accident, that the packager pushing it
knows what they are doing and announce it to the people it impacts.


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

Re: Frequently broken Rawhide/Branched composes

[Pierre-Yves Chibon]

On Fri, Mar 02, 2018 at 04:40:03AM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> >> Something needs to be done to make the compose process more robust, e.g.:
> >> * running createrepo on a stable release, so that we do not have to be
> >> able
> >>   to init a chroot of the target system to compose a repository. A broken
> >>   dependency, even in systemd or rpm, should NEVER be a reason for the
> >>   repository to fail to compose.
> >> * publishing individual deliverables one at a time, i.e.:
> >>   1. compose the repositories,
> >>   2. sync the repositories out to the mirrors,
> >>   3. build the images (atomic ostrees, live images etc.) one at a time,
> >>   4. sync those images that succeeded out to the mirrors, keep the old
> >>  versions of the other ones (the matching SRPMs are in Koji anyway,
> >>  so it does not matter if the SRPMs in the tree don't match)
> >> etc.
> > 
> > I disagree entirely with the above. I think the solution is to gate
> > packages coming into rawhide and hold or reject those that break the
> > compose until they are fixed. I think being proactive is VASTLY better
> > than being reactive. Not breaking something in the first place is much
> > easier to deal with than trying to fix it later.
> 
> And how do you propose doing that? The only reliable way to hold packages 
> that break the compose would be to actually try to run the whole compose 
> process after every package build. That just does not scale. The composes 
> are only daily for a reason. Running a compose for every package build would 
> use a lot of resources and would also take very long, delaying the tagging 
> of the package into Rawhide for an insane amount of time (at least hours).

Well, do you remember Will Woods' talk at DevConf? They managed to do a compose
in a matter of minutes, so down the line this may be doable.

In the mean while, baby steps. Yes running fast automated tests won't catch all
the issues for every issues it will catch is one that will no need to be dealt
with later.
Once we have the mechanisms in place to gate packages entering rawhide, it will
be easier to improve the gating tools. We could even do as everybody else is
doing, start with some tests, fix a bug that got through, add the corresponding
tests to prevent it from happening again, repeat... :)


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

Re: [RFC] Packages which are not installable (obsoleted by other pacakges)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-03-01 at 12:56 -0800, Kevin Fenzi wrote:
> On 03/01/2018 08:46 AM, Igor Gnatenko wrote:
> > I ran some check on latest compose and found that quite a few
> > packages
> > in repo can't be installed due to being obsoleted. What do we do
> > about
> > those packages? Should I submit bugs for each of them?
> 
> I would say so yes. Then after some time just retire the rest.

Ack, submitted 30 bugs.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqZBY8ACgkQaVcUvRu8
X0yyqRAArZwz+RFcUCfXZidxSUKs7wkFCxDCJmSv073/UX8LbOEBwE45gtuFIFZh
rHcTJRX7/Ajy4mo1cbhuK1Z3iTALpoBlIiYrZPRf6SRS4lyfknKXhzHS43Z+xptB
+3AjmOtEwwtJKf0Uw89Q8iuIAQLEFZgX8z1awPp3Czil2DQklojtVcKY4uo+q7Oo
If7jh4nFVIXsYSVoYBbJB6uHhxGZiI86rdA9bO9LyHCX06MmA2ph8z0PhgsiS3pL
5qV0uE77JWi/9wNTwdAd5aZgdckcFbXMhq2i834j7sRgc+u8tA6w9cTC9TLcpE2F
foZliV2d4UMhgixd++/F//IR3KqgNeBcCNWQUT8XToxhu9nfI4wp/g0GlRiAhzdN
j1PUdAP6441aOPF0SlFSLVeK9ONLqUDgG8vfjOtMOVLxA+UiZCQs4Ui+b7KPhf/V
/I9TW88Uaa4PjN2HpG4JVByr9p7FgkQtayF5mXwhmxNxABEt3J+ESmJB7oBWJFdw
9blCub/zGvwfAlhkmWR00DNxwPU1y9BGVRZUb2b0hmbzF+d0+B32euhMZKroCmUB
BQLfAOv4irqC20Jz431etyCW9bvRkBchQjk1vd4Fj1XJCmPSR7hKzKz50iFg3z9f
56jGQZIMTdhKSBaoI9VC/yW2p07I3+rAajMVDsxldpg3FNA3oAg=
=nnoA
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org