Re: Firefox 49.0.2

[Florian Weimer]

On 10/26/2016 02:45 AM, Bojan Smojver wrote:

What about this?

https://www.mozilla.org/en-US/security/advisories/mfsa2016-87/


And it seems that Fedora builds do not enable e10s, so the cache leak 
might actually affect users.


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

Re: Pondering security update time frames

[Florian Weimer]

On 10/26/2016 04:28 AM, Kevin Fenzi wrote:

On Wed, 26 Oct 2016 13:00:07 +1100
Bojan Smojver  wrote:


If there existed updates-urgent and updates-urgent-testing
repositories for packages like kernel (example: Dirty COW
patch-to-testing wait time was rather long; note that some people
cannot install unsigned kernel packages from koji due to grub2 bugs),
FF etc., maybe these large (and possibly failing) composes could be
avoided? Something like fast track in RHEL.

So, a small and fast couple of repos for really, really important
stuff. Unless I'm misunderstanding how repos work...


We worked on something like this last year:

https://fedorahosted.org/rel-eng/ticket/5886

https://fedoraproject.org/wiki/Urgent_updates_policy

We concluded that we needed to use bodhi for it, and were unsure how
much bodhi work it would be to get it to be able to do this, so we went
looking for other easier wins.


Would it make sense to get *all* updates delivered faster to users instead?

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

Re: Pondering security update time frames

[Florian Weimer]

On 10/26/2016 02:59 AM, Andrew Lutomirski wrote:


3. AFAIK Fedora has no means by which it can participate in embargoed
updates.


Is this really relevant?  For how many updates a year would it make a 
difference?  I get that participating in embargoes is important to some 
people, but in the grand scheme of things, they just complicate things 
tremendously.


Doing community QA on embargoed packages is rather difficult, and QA is 
usually what takes the most time, not getting the update package updated 
or built.


The other avoidable delay is getting the updated repository to users, 
and having pre-packaged and pre-built updates won't help there, either.


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

[Bug 1388088] perl-Module-Install-1.17 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #1 from Fedora Update System  ---
perl-Module-Install-1.17-1.fc25 has been pushed to the Fedora 25 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-2016-d317351bd0

-- 
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: Pondering security update time frames

[Bojan Smojver]

Dnf would need to be taught to do these things, of course

The "on the fly" repositories could be defined like any other, using
repo files. They could be signed by the same keys updates/updates-
testing repos use. Not sure why master mirrors would be required.
Wouldn't regular mirrors work, minus the repomd.xml checksum?

Multilib would be a problem, if this is something that only bodhi can
do.

I guess if that's not doable, then having a jump-the-queue bodhi
mashing of urgent repos would be the only option.

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

Re: Pondering security update time frames

[Kevin Fenzi]

On Wed, 26 Oct 2016 13:50:11 +1100
Bojan Smojver  wrote:

> I'm thinking, why not just have these as dump repositories (i.e. just
> signed packages) and then have dnf on each system stitch up a repo
> from them using createrepo locally. Then you don't need to teach bodhi
> anything. And the number of such urgent packages would always be very
> low. Essentially an intersection of critical path and high severity
> CVEs.

How would dnf know there are packages there without any repodata?

How would it know what key they should be signed by? 

Every fedora dnf on every run hits the master mirror for an index?

There would also be no multilib, so people with i686/x86_64 installed
machines could see errors/not update. Also no drpms, but perhaps thats
not a show stopper. 
 
> In the meantime, when the regular bodhi composer job sees them, it
> picks them up and puts them into updates/updates-testing, as required.

Sure.

kevin




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

Re: Pondering security update time frames

[Bojan Smojver]

I'm thinking, why not just have these as dump repositories (i.e. just
signed packages) and then have dnf on each system stitch up a repo from
them using createrepo locally. Then you don't need to teach bodhi
anything. And the number of such urgent packages would always be very
low. Essentially an intersection of critical path and high severity
CVEs.

In the meantime, when the regular bodhi composer job sees them, it
picks them up and puts them into updates/updates-testing, as required.

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 597  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 359  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  78  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  61  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c3527eff6c   
libass-0.13.4-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-14.el7 libyui-bindings-1.1.0-7.el7 
mono-4.2.4-7.el7 mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 
mono-zeroconf-0.9.0-16.el7 notify-sharp-0.4.0-0.26.20100411svn.el7 
notify-sharp3-3.0.3-2.el7 nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 
taglib-sharp-2.1.0.0-3.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-95eaec7747   
bubblewrap-0.1.3-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0f6483aa7   
tor-0.2.8.9-1.el7


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

breeze-icon-theme-5.27.0-1.el7
distribution-gpg-keys-1.8-1.el7
extra-cmake-modules-5.27.0-1.el7
kf5-5.27.0-1.el7
kf5-attica-5.27.0-1.el7
kf5-baloo-5.27.0-1.el7
kf5-bluez-qt-5.27.0-1.el7
kf5-frameworkintegration-5.27.0-1.el7
kf5-kactivities-5.27.0-1.el7
kf5-kactivities-stats-5.27.0-1.el7
kf5-kapidox-5.27.0-1.el7
kf5-karchive-5.27.0-1.el7
kf5-kauth-5.27.0-1.el7
kf5-kbookmarks-5.27.0-1.el7
kf5-kcmutils-5.27.0-1.el7
kf5-kcodecs-5.27.0-1.el7
kf5-kcompletion-5.27.0-1.el7
kf5-kconfig-5.27.0-1.el7
kf5-kconfigwidgets-5.27.0-1.el7
kf5-kcoreaddons-5.27.0-1.el7
kf5-kcrash-5.27.0-1.el7
kf5-kdbusaddons-5.27.0-1.el7
kf5-kdeclarative-5.27.0-1.el7
kf5-kded-5.27.0-1.el7
kf5-kdelibs4support-5.27.0-1.el7
kf5-kdesignerplugin-5.27.0-1.el7
kf5-kdesu-5.27.0-1.el7
kf5-kdewebkit-5.27.0-1.el7
kf5-kdnssd-5.27.0-1.el7
kf5-kdoctools-5.27.0-1.el7
kf5-kemoticons-5.27.0-1.el7
kf5-kfilemetadata-5.27.0-1.el7
kf5-kglobalaccel-5.27.0-1.el7
kf5-kguiaddons-5.27.0-1.el7
kf5-khtml-5.27.0-1.el7
kf5-ki18n-5.27.0-1.el7
kf5-kiconthemes-5.27.0-1.el7
kf5-kidletime-5.27.0-1.el7
kf5-kimageformats-5.27.0-1.el7
kf5-kinit-5.27.0-1.el7
kf5-kio-5.27.0-1.el7
kf5-kitemmodels-5.27.0-1.el7
kf5-kitemviews-5.27.0-1.el7
kf5-kjobwidgets-5.27.0-1.el7
kf5-kjs-5.27.0-1.el7
kf5-kjsembed-5.27.0-1.el7
kf5-kmediaplayer-5.27.0-1.el7
kf5-knewstuff-5.27.0-1.el7
kf5-knotifications-5.27.0-1.el7
kf5-knotifyconfig-5.27.0-1.el7
kf5-kpackage-5.27.0-1.el7
kf5-kparts-5.27.0-1.el7
kf5-kpeople-5.27.0-1.el7
kf5-kplotting-5.27.0-1.el7
kf5-kpty-5.27.0-4.el7
kf5-kross-5.27.0-1.el7
kf5-krunner-5.27.0-1.el7
kf5-kservice-5.27.0-1.el7
kf5-ktexteditor-5.27.0-1.el7
kf5-ktextwidgets-5.27.0-1.el7
kf5-kunitconversion-5.27.0-1.el7
kf5-kwallet-5.27.0-1.el7
kf5-kwidgetsaddons-5.27.0-1.el7
kf5-kwindowsystem-5.27.0-1.el7
kf5-kxmlgui-5.27.0-1.el7
kf5-kxmlrpcclient-5.27.0-1.el7
kf5-modemmanager-qt-5.27.0-1.el7
kf5-networkmanager-qt-5.27.0-1.el7
kf5-plasma-5.27.0-1.el7
kf5-solid-5.27.0-1.el7
kf5-sonnet-5.27.0-1.el7
kf5-threadweaver-5.27.0-1.el7
php-email-address-validation-0-0.11.20090910svn.el7
php-udan11-sql-parser-3.4.11-1.el7
purple-hangouts-0-39.20161023hgf66236a.el7
python-flask-0.10.1-3.el7
python-ruamel-ordereddict-0.4.9-2.el7
python-werkzeug-0.9.1-1.el7
rpkg-1.46-5.el7
sundials-2.7.0-6.el7
youtube-dl-2016.10.25-1.el7

Details about builds:



 breeze-icon-theme-5.27.0-1.el7 (FEDORA-EPEL-2016-f797a03667)
 Breeze icon theme

Update Information:

KDE Frameworks 5.27.0, https://www.kde.org/announcements/kde-
frameworks-5.27.0.php




 distribution-gpg-keys-1.8-1.el7 (FEDORA-EPEL-2016-d2eb5ab4b1)
 GPG keys of various Linux distributions

Update Information:

- update copr gpg keys - README.md: Indicate what keys 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 475  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 469  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 401  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 359  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 331  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 217  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  61  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  34  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-25e30f6dc3   
jansson-2.9-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2f6f1435ed   
tor-0.2.8.9-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a886ace670   
tomcat-7.0.72-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6


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

distribution-gpg-keys-1.8-1.el6
rpkg-1.46-5.el6
sundials-2.7.0-6.el6
youtube-dl-2016.10.25-1.el6

Details about builds:



 distribution-gpg-keys-1.8-1.el6 (FEDORA-EPEL-2016-66690120b3)
 GPG keys of various Linux distributions

Update Information:

- update copr gpg keys - README.md: Indicate what keys are actually included -
add rpmfusion F19 keys - add note how to verify gpg key using fingerprint -
RPMFusion add fedora-20 and fedora-21 keys - RPMFusion add rpmfusion el-7 keys -
RPMFusion add fedora-25 keys - use symbol links . - Add a crucial information to
README.md

References:

  [ 1 ] Bug #1379990 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1379990




 rpkg-1.46-5.el6 (FEDORA-EPEL-2016-33b79611f8)
 Utility for interacting with rpm+git packaging systems

Update Information:

Allow using gssapi for lookaside caches.




 sundials-2.7.0-6.el6 (FEDORA-EPEL-2016-860ab0145c)
 Suite of nonlinear solvers

Update Information:

- Fix builds of MPICH libraries    - Update to 2.7.0 - Enabled SuperLUMT and
HYPRE support - Removed pkgconfig files

References:

  [ 1 ] Bug #1272352 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1272352




 youtube-dl-2016.10.25-1.el6 (FEDORA-EPEL-2016-539455cccb)
 A small command-line program to download online videos

Update Information:

Update to latest release    Update to the latest upstream release.

References:

  [ 1 ] Bug #1385662 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1385662
  [ 2 ] Bug #1377102 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1377102

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

Re: Pondering security update time frames

[Kevin Fenzi]

On Wed, 26 Oct 2016 13:00:07 +1100
Bojan Smojver  wrote:

> If there existed updates-urgent and updates-urgent-testing
> repositories for packages like kernel (example: Dirty COW
> patch-to-testing wait time was rather long; note that some people
> cannot install unsigned kernel packages from koji due to grub2 bugs),
> FF etc., maybe these large (and possibly failing) composes could be
> avoided? Something like fast track in RHEL.
> 
> So, a small and fast couple of repos for really, really important
> stuff. Unless I'm misunderstanding how repos work...

We worked on something like this last year: 

https://fedorahosted.org/rel-eng/ticket/5886

https://fedoraproject.org/wiki/Urgent_updates_policy

We concluded that we needed to use bodhi for it, and were unsure how
much bodhi work it would be to get it to be able to do this, so we went
looking for other easier wins. 

kevin


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

Re: F26 proposed release tooling changes

[Ken Dreyer]

On Tue, Oct 25, 2016 at 3:00 PM, Dennis Gilmore  wrote:
> On martes, 25 de octubre de 2016 2:42:15 PM CDT Ken Dreyer wrote:
>> Hi Amanda,
>>
>> I'm curious about this change: "Kerberos support in koji, fedpkg, OSBS "
>>
>> Is koji.fedoraproject.org is going to eventually stop supporting TLS
>> authentication, and we'll have a Fedora-project-wide Kerberos
>> infrastructure instead?
>
> there will be kerberos auth for koji and lookaise cache, if it will be project
> wide or not I am not sure that is decided yet.

Thanks Dennis.

I'm curious about this because most organizations do not expose their
KDCs directly to the internet. As I understand it, it's possible for a
passive attacker to sniff the TGT exchange and brute-force a password,
whereas this attack scenario is not possible with Koji's current HTTPS
client cert authentication.

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

Re: Pondering security update time frames

[Bojan Smojver]

Wouldn't package maintainers get the CVE bug notification from Bugzilla
about FF that I pointed to? Given that, the assumption that maintainers
are away seems reasonable. Ergo, I sent an e-mail to the list.

PS. I also checked FF package git repo, which had no recent commits.

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

Re: Pondering security update time frames

[Bojan Smojver]

If there existed updates-urgent and updates-urgent-testing repositories
for packages like kernel (example: Dirty COW patch-to-testing wait time
was rather long; note that some people cannot install unsigned kernel
packages from koji due to grub2 bugs), FF etc., maybe these large (and
possibly failing) composes could be avoided? Something like fast track
in RHEL.

So, a small and fast couple of repos for really, really important
stuff. Unless I'm misunderstanding how repos work...

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

Re: Supported way to require that a service be stopped prior to installing an .rpm package?

[Japheth Cleaver]

On 10/25/2016 6:13 PM, jha...@gmail.com wrote:

On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:

https://fedoraproject.org/wiki/Packaging:Scriptlets

It seems like this is something that could be done in %pretrans, as well. 
Alternatively,
depending on the paradigm you're working with, you could give service restart
responsibility to the rpm process itself. This already happens during most 
daemon updates
anyway, so if it's for your team's internal use, I'd consider saving state in
%pretrans, stopping the service (if running), and starting back up in 
%posttrans.

On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:


I don't see why this needs to be the case.

Between %pre, %post, %verify, and the newer %*trans functions, along
with Requires(pre), etc, 'rpm' provides all the tools you need to
perform modifications of a service using easily-grokkable logic, already
running as root, and using easily-testable methods.

Edge cases like saving state have best-practice implementations already
available, and rpm scriptlets already perform this action for many
services. Meta-packages which perform service control aren't
particularly groundbreaking.

Regards,

-jc

Thanks for the response!  could you possibly point me to an example of what 
you're referencing?


Hmm. Well, it looks like things have moved around a bit on the wiki 
since I last looked them up, but the basic concepts were discussed at:
https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Scriptlet_Ordering 



I do seem to recall actual code examples there, but I don't see it in 
the merged page history.


Essentially, you'd just be doing something like (untested):

%pretrans
# Check if running, if so, be sure to start back up afterwards
rm -f "/tmp/%{name}.upgrade.restart"

/sbin/service %{name} status >/dev/null && touch 
"/tmp/%{name}.upgrade.restart"

/sbin/service %{name} stop >/dev/null 2>&1


%posttrans
if [ -e "/tmp/%{name}.upgrade.restart" ] ; then
   rm -f "/tmp/%{name}.upgrade.restart"
   /sbin/service %{name} start >/dev/null|| :
else
   /sbin/service %{name} condrestart >/dev/null  || :
fi

exit 0


== * ==

This is untested, but adapted from some logic I'd had in some other, 
hairier, %pre/%post scriptlet that had to do some shuffling around of 
directories and symlinks. I've never actually had to use %*trans myself, 
so if %pre is working for you then I'd simply continue using that.


Note that any use of anything other than lua in %pretrans means that 
your RPM can't be installed at initial/anaconda time, since pretrans 
runs way at the beginning of whatever's happening.



Hope that helps,

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

[389-devel] Re: Enable quiet build on ds, ns, svrcore

[William Brown]

On Tue, 2016-10-25 at 09:08 +0200, Lukas Slebodnik wrote:
> On (25/10/16 14:23), William Brown wrote:
> >Hi,
> >
> >I want to get feedback from the team about a small change I would like
> >to make to our configure.ac. I want to add the following to
> >configure.ac.
> >
> >m4_ifdef([AM_SILENT_RULES], [
> > AM_SILENT_RULES([yes])
> >])
> >
> We(sssd) do not use it by default for few reasons.
> It need to be expilicitely disabled if you want to see failures
> in CI/mock build. Otherwise, it's imposible to check whether
> compilation/linking had correct flags on different distributions
> fedora/rhel/debian/opensuse and troubleshooting is much harder.

Hmmm that's a good point. I didn't think of this. 

> 
> This is a reason why we prefer to explicitely enable it at configure
> time or at build time
>   ./configure --enable-silent-rules
> or at build time
>   make V=0 (make V=1)

I didn't realise you could do that.


> 
> Both versions are independent.
> 
> But I agree that thos posibility is very usefull for development.
> IMHO, it might be better not to use "yes" as a default
> m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES])
> 
> BTW. I can already see silent-rules in configure help.
> [root@7380c2d8ecf1 ds]# ./configure --help | grep silent
>   -q, --quiet, --silent   do not print `checking ...' messages
>   --enable-silent-rules   less verbose build output (undo: "make V=1")
>   --disable-silent-rules  verbose build output (undo: "make V=0")

Thanks, I might just leave this one alone then.

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


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

[389-devel] Please review 49017 minor test failures

[William Brown]

https://fedorahosted.org/389/ticket/49017

https://fedorahosted.org/389/attachment/ticket/49017/0001-Ticket-49017-Various-minor-test-failures.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


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

Re: Pondering security update time frames

[Kevin Fenzi]

On Tue, 25 Oct 2016 17:59:24 -0700
Andrew Lutomirski  wrote:

> It seems to me that Fedora has three severe distribution wide issues
> relating to security updates:
> 
> 1. Updates, even critical security updates, are very slow.  Getting an
> update out involves creating a build and an update (which is
> reasonably fast for most packages), pushing the update to
> updates-testing, getting karma, and pushing to updates.  The latter
> three can happen in parallel in the best case.  The big problem as I
> see it is that pushing updates is painfully slow.  For reasons that
> I'm sure make a lot of internal sense, updates seem to get stuck
> behind broken composes and such all the time.  Can this be made
> better?

It has been. In the last month or so, a bunch of bodhi masher bugs have
been tracked down and we have autosigning in place.
I think people don't realize all the stuff we have to do to push
updates. 

> IMO it should be possible for a security update to be checked,
> incrementally, for sanity with respect to the rest of the package
> repository, and then pushed out, without needing to do whatever
> expensive work a compose does.  If some other update breaks the
> compose, I don't think this should cause security updates to get
> stuck.

Nope. We have talked about having some kind of fast track, but IMHO, we
should just get the normal process faster. 
> 
> 2. There doesn't appear to be a working process to get updates out
> quickly.  As a current and pressing example, there is no build for
> Firefox 49.0.2.

Ask the maintainer(s)? there could be any number of reasons for this... 

> 3. AFAIK Fedora has no means by which it can participate in embargoed
> updates.  For this to work, I think there ought to be private git
> branches, a way to get Koji to make a private build from a private git
> branch, and a way to get private karma on a private update.  Then,
> when an embargo is lifted, the packager could merge the private branch
> in, the various infrastructure bits could notice that the very same
> git commit is now public and permit all of the private builds,
> updates, and karma to become public and allow an immediate push to
> updates.

Yep. Thats a gigantic pile of work there for sure. 

kevin


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

Re: Firefox 49.0.2

[Bojan Smojver]

Which is also already in Bugzilla:

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

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

Re: Supported way to require that a service be stopped prior to installing an .rpm package?

[jhally]

> On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:
> 
> https://fedoraproject.org/wiki/Packaging:Scriptlets
> 
> It seems like this is something that could be done in %pretrans, as well. 
> Alternatively,
> depending on the paradigm you're working with, you could give service restart
> responsibility to the rpm process itself. This already happens during most 
> daemon updates
> anyway, so if it's for your team's internal use, I'd consider saving state in
> %pretrans, stopping the service (if running), and starting back up in 
> %posttrans.
> 
> On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:
> 
> 
> I don't see why this needs to be the case.
> 
> Between %pre, %post, %verify, and the newer %*trans functions, along 
> with Requires(pre), etc, 'rpm' provides all the tools you need to 
> perform modifications of a service using easily-grokkable logic, already 
> running as root, and using easily-testable methods.
> 
> Edge cases like saving state have best-practice implementations already 
> available, and rpm scriptlets already perform this action for many 
> services. Meta-packages which perform service control aren't 
> particularly groundbreaking.
> 
> Regards,
> 
> -jc

Thanks for the response!  could you possibly point me to an example of what 
you're referencing?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Andrew Lutomirski]

On Tue, Oct 25, 2016 at 6:03 PM, Adam Williamson
 wrote:
> On Tue, 2016-10-25 at 17:59 -0700, Andrew Lutomirski wrote:
>> 2. There doesn't appear to be a working process to get updates out
>> quickly.  As a current and pressing example, there is no build for
>> Firefox 49.0.2.
>
> There isn't really a single 'security update process', no. Releasing
> security updates is a package maintainer responsibility. I've seen
> various people pontificating in various different places about why
> there's no Firefox 49.0.2 build yet, but no-one seems to have taken the
> rather obvious step of *asking the package maintainer*, or at least no-
> one's done so and then posted the result rather than guessing about it.

Fair enough.

FWIW, I think that #1 and #3 are more severe than #2 in the sense that
#2 is sporadic and there are various mechanisms that mostly work to
notify maintainers about updates, whereas #1 and #3 are problematic
even when the maintainer responds instantaneously.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Adam Williamson]

On Tue, 2016-10-25 at 17:59 -0700, Andrew Lutomirski wrote:
> 2. There doesn't appear to be a working process to get updates out
> quickly.  As a current and pressing example, there is no build for
> Firefox 49.0.2.

There isn't really a single 'security update process', no. Releasing
security updates is a package maintainer responsibility. I've seen
various people pontificating in various different places about why
there's no Firefox 49.0.2 build yet, but no-one seems to have taken the
rather obvious step of *asking the package maintainer*, or at least no-
one's done so and then posted the result rather than guessing about it.
-- 
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

Pondering security update time frames

[Andrew Lutomirski]

It seems to me that Fedora has three severe distribution wide issues
relating to security updates:

1. Updates, even critical security updates, are very slow.  Getting an
update out involves creating a build and an update (which is
reasonably fast for most packages), pushing the update to
updates-testing, getting karma, and pushing to updates.  The latter
three can happen in parallel in the best case.  The big problem as I
see it is that pushing updates is painfully slow.  For reasons that
I'm sure make a lot of internal sense, updates seem to get stuck
behind broken composes and such all the time.  Can this be made
better?

IMO it should be possible for a security update to be checked,
incrementally, for sanity with respect to the rest of the package
repository, and then pushed out, without needing to do whatever
expensive work a compose does.  If some other update breaks the
compose, I don't think this should cause security updates to get
stuck.

2. There doesn't appear to be a working process to get updates out
quickly.  As a current and pressing example, there is no build for
Firefox 49.0.2.

3. AFAIK Fedora has no means by which it can participate in embargoed
updates.  For this to work, I think there ought to be private git
branches, a way to get Koji to make a private build from a private git
branch, and a way to get private karma on a private update.  Then,
when an embargo is lifted, the packager could merge the private branch
in, the various infrastructure bits could notice that the very same
git commit is now public and permit all of the private builds,
updates, and karma to become public and allow an immediate push to
updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1385612] perl-Archive-Tar-2.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Archive-Tar-2.12-1.fc2 |perl-Archive-Tar-2.12-1.fc2
   |6   |6
   ||perl-Archive-Tar-2.14-1.fc2
   ||5
 Resolution|--- |ERRATA
Last Closed||2016-10-25 20:56:55



--- Comment #3 from Fedora Update System  ---
perl-Archive-Tar-2.14-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1387462] perl-Module-CoreList-5.20161020 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |1020-1.fc26 |1020-1.fc26
   ||perl-Module-CoreList-5.2016
   ||1020-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-25 20:56:59



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20161020-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1387451] perl-Archive-Tar-2.14 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Archive-Tar-2.14-1.fc2 |perl-Archive-Tar-2.14-1.fc2
   |6   |6
   ||perl-Archive-Tar-2.14-1.fc2
   ||5
 Resolution|--- |ERRATA
Last Closed||2016-10-25 20:56:52



--- Comment #2 from Fedora Update System  ---
perl-Archive-Tar-2.14-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1387453] perl-CPAN-Perl-Releases-2.98 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-2.9 |perl-CPAN-Perl-Releases-2.9
   |8-1.fc26|8-1.fc26
   ||perl-CPAN-Perl-Releases-2.9
   ||8-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-25 20:56:48



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-2.98-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1387452] perl-DateTime-TimeZone-2.06 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DateTime-TimeZone-2.06 |perl-DateTime-TimeZone-2.06
   |-1.fc26 |-1.fc26
   ||perl-DateTime-TimeZone-2.06
   ||-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-25 20:56:41



--- Comment #4 from Fedora Update System  ---
perl-DateTime-TimeZone-2.06-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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: Supported way to require that a service be stopped prior to installing an .rpm package?

[Japheth Cleaver]

On 10/25/2016 4:47 PM, jha...@gmail.com wrote:

Hello,

My team is building and maintaining a fairly complex software stack that is 
being packaged via rpm.  As part of the requirements, the service provided by 
the .rpm file must be stopped prior to installation / update of the package.

Is there any supported / recommended way to do this?  Currently the team uses 
the %pre section to check if the service is running and fail if so, but this 
seems a bit ugly.


https://fedoraproject.org/wiki/Packaging:Scriptlets

It seems like this is something that could be done in %pretrans, as well. 
Alternatively, depending on the paradigm you're working with, you could give 
service restart responsibility to the rpm process itself. This already happens 
during most daemon updates anyway, so if it's for your team's internal use, I'd 
consider saving state in %pretrans, stopping the service (if running), and 
starting back up in %posttrans.

On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:

Packaging methods should not be used for this requirement. You should 
be using some system automation tools like Ansible or Puppet or Chef 
to make that transaction complete smoothly.


Openshift uses Ansible for their cluster upgrades.



I don't see why this needs to be the case.

Between %pre, %post, %verify, and the newer %*trans functions, along 
with Requires(pre), etc, 'rpm' provides all the tools you need to 
perform modifications of a service using easily-grokkable logic, already 
running as root, and using easily-testable methods.


Edge cases like saving state have best-practice implementations already 
available, and rpm scriptlets already perform this action for many 
services. Meta-packages which perform service control aren't 
particularly groundbreaking.


Regards,

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

Re: Firefox 49.0.2

[Bojan Smojver]

What about this?

https://www.mozilla.org/en-US/security/advisories/mfsa2016-87/

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

[389-devel] please review: Ticket 49015 - register-ds-admin.pl - silent install does not work with local instances

[Mark Reynolds]

https://fedorahosted.org/389/ticket/49015

https://fedorahosted.org/389/attachment/ticket/49015/0001-Ticket-49015-register-ds-admin.pl-silent-install-doe.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Supported way to require that a service be stopped prior to installing an .rpm package?

[Subhendu Ghosh]

Packaging methods should not be used for this requirement. You should be
using some system automation tools like Ansible or Puppet or Chef to make
that transaction complete smoothly.

Openshift uses Ansible for their cluster upgrades.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1379558] perl-Image-Info: XXE in SVG files [fedora-all]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Image-Info-1.38-6.fc25 |perl-Image-Info-1.38-6.fc25
   |perl-Image-Info-1.38-6.fc24 |perl-Image-Info-1.38-6.fc24
   ||perl-Image-Info-1.38-6.fc23



--- Comment #7 from Fedora Update System  ---
perl-Image-Info-1.38-6.fc23 has been pushed to the Fedora 23 stable repository.
If problems still persist, please make note of it in this bug report.

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

Supported way to require that a service be stopped prior to installing an .rpm package?

[jhally]

Hello,

My team is building and maintaining a fairly complex software stack that is 
being packaged via rpm.  As part of the requirements, the service provided by 
the .rpm file must be stopped prior to installation / update of the package.

Is there any supported / recommended way to do this?  Currently the team uses 
the %pre section to check if the service is running and fail if so, but this 
seems a bit ugly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox 49.0.2

[Greg Evenden]

> Could someone with access please build this version of FF. Apparently,
> it's a security release.
> 
> Thanks,
usually Martin Stransky builds them, i think there is a JavaScript Bug fixed 
https://www.mozilla.org/en-US/firefox/49.0.2/releasenotes/, but IMO there is no 
point in compiling 49.0.2 when 50 will be out in about 2 weeks 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Jonny Heggheim]

On 25 October 2016 at 23:47, Jonny Heggheim  wrote:
> On 25 October 2016 at 17:06, Adam Williamson  
> wrote:
>> That wouldn't really bother me, so I'm only curious, but why do you
>> find having a big changelog at the end of the file so annoying? It's at
>> the end and you pretty much never have to look at it. Is it just
>> because it tends to match searches, or what?
> +
Sorry for premature send, I agree, the old content is hidden at the
end of the file with the most important/newest change logs at the top.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Private Bugzilla bugs

[Jeff Fearn]

On 25/10/16 22:49, den...@ausil.us wrote:
> There has never been any policy against private bugs, and it's been 
> encouraged for security sensitive bugs from day 1. There is a lot of Red Hat 
> employees who default to private bugs

FYI The warn on public create customization has been dropped from
Bugzilla 5.

> or private comments due to working mostly on internal bugs. A nice rfe might 
> be to enable the ability to default private comments in or off for different 
> products.

Currently only 150 accounts have private_comment_default enabled and
only 128 of those are current, so there isn't much of a business case to
work on this feature.

Cheers, Jeff.

> Dennis
> 
> On 25 October 2016 7:29:25 am GMT-05:00, Kevin Kofler 
>  wrote:
>> Jakub Filak wrote:
>>> I will repeat my argument again - users are allowed to do it when
>> filling
>>> a private bug manually.
>>
>> My point is, they shouldn't be.
>>
>>Kevin Kofler
>> ___
>> 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
> 




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: RPM %changelog?

[Jonny Heggheim]

On 25 October 2016 at 17:06, Adam Williamson  wrote:
> That wouldn't really bother me, so I'm only curious, but why do you
> find having a big changelog at the end of the file so annoying? It's at
> the end and you pretty much never have to look at it. Is it just
> because it tends to match searches, or what?
+
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[James Hogarth]

On 25 October 2016 at 21:38, Matthew Miller  wrote:
> On Tue, Oct 25, 2016 at 09:51:09PM +0200, Kevin Kofler wrote:
>> Well, the user-centric stuff belongs in the Bodhi update notes first of all.
>
> This is an excellent point. Argh — we have three changelogs, and
> possibly *four*:
>
> 1. Whatever upstream has
> 2. The specfile/rpm changelog
> 3. The dist-git commit
> 4. Bodhi notes — for updates that go through bodhi.
>
> For a user, #4 and #1 are probably the most useful, while #2 is the
> most easily-accessed (and #3 is a deep, dark secret).
>
> Of course, many updates go into Rawhide without going through the bodhi
> dance, and... I certainly appreciate the lack of hoop-jumping there. It
> means there's only an explanation for updates that happened during a
> release, though.


For certain updates (rawhide related here) you can add the version
release notes as a (5) as that's the main place some changes will
appear to users
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

scikit-learn in Fedora 25 ?

[Tom Devel]

I have used scikit-learn in several previous Fedora releases, however if I
look at
https://bodhi.fedoraproject.org/updates/?packages=python-scikit-learn there
is no scikit-learn for Fedora 25 anymore.

The latest stable version is 0.18.1 (
http://scikit-learn.org/dev/whats_new.html), this is a popular machine
learning library. Will scikit-learn be included Fedora 25? Or am I
searching incorrectly for it?

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

ausil set the critpath flag on the perl-Data-Dumper package (master)

[notifications]

ausil set the critpath flag on the perl-Data-Dumper package (master)

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

Re: F26 proposed release tooling changes

[Dennis Gilmore]

On martes, 25 de octubre de 2016 2:42:15 PM CDT Ken Dreyer wrote:
> Hi Amanda,
> 
> I'm curious about this change: "Kerberos support in koji, fedpkg, OSBS "
> 
> Is koji.fedoraproject.org is going to eventually stop supporting TLS
> authentication, and we'll have a Fedora-project-wide Kerberos
> infrastructure instead?

there will be kerberos auth for koji and lookaise cache, if it will be project 
wide or not I am not sure that is decided yet.

Dennis
> - Ken
> 
> On Mon, Oct 24, 2016 at 12:04 PM, Amanda Carter  wrote:
> > Heads up about the release tooling changes we're proposing for F26. Note
> > that this list may exclude work to be completed for modularity but that
> > will be added to the same page at a later date. If there's anything that
> > seems to be missing or mis-prioritized please let me know. I'd like
> > feedback on this list by the end of the week. Next week we'll start
> > getting ready to deliver these changes.
> > 
> > https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline#F26_Pro
> > posed_Tools_Changes
> > 
> > Thanks!
> > 
> > --
> > Amanda Carter
> > ___
> > 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



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

Re: F26 proposed release tooling changes

[Ken Dreyer]

Hi Amanda,

I'm curious about this change: "Kerberos support in koji, fedpkg, OSBS "

Is koji.fedoraproject.org is going to eventually stop supporting TLS
authentication, and we'll have a Fedora-project-wide Kerberos
infrastructure instead?

- Ken


On Mon, Oct 24, 2016 at 12:04 PM, Amanda Carter  wrote:
> Heads up about the release tooling changes we're proposing for F26. Note that 
> this list may exclude work to be completed for modularity but that will be 
> added to the same page at a later date. If there's anything that seems to be 
> missing or mis-prioritized please let me know. I'd like feedback on this list 
> by the end of the week. Next week we'll start getting ready to deliver these 
> changes.
>
> https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline#F26_Proposed_Tools_Changes
>
> Thanks!
>
> --
> Amanda Carter
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Matthew Miller]

On Tue, Oct 25, 2016 at 09:51:09PM +0200, Kevin Kofler wrote:
> Well, the user-centric stuff belongs in the Bodhi update notes first of all.

This is an excellent point. Argh — we have three changelogs, and
possibly *four*:

1. Whatever upstream has
2. The specfile/rpm changelog
3. The dist-git commit
4. Bodhi notes — for updates that go through bodhi.

For a user, #4 and #1 are probably the most useful, while #2 is the
most easily-accessed (and #3 is a deep, dark secret).

Of course, many updates go into Rawhide without going through the bodhi
dance, and... I certainly appreciate the lack of hoop-jumping there. It
means there's only an explanation for updates that happened during a
release, though.



-- 
Matthew Miller

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

[EPEL-devel] Bug in awscli-1.11.0-1.el7

[Ben Smith]

After an upgrade to the current EPEL awcli, a system I'm working on broke. 
There's a bug with downloading empty files that's been fixed in 1.11.1. We 
verified that upgrading to awscli-1.11.2-1.el7 fixes the problem. 

https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst#

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

Re: noarch debuginfo packages missing from repo?

[Sandro Mani]

On 25.10.2016 20:02, Till Maas wrote:

On Tue, Oct 25, 2016 at 05:44:49PM +0200, Sandro Mani wrote:


rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is
found). I suspect that perhaps noarch debuginfo packages are missing from

AFAIK debuginfo packages are not generated for noarch packages. I am not
sure if there is a way to enable them.
debuginfo packages have always been generated for mingw packages (see 
/usr/lib/rpm/macros.d/macros.mingw{32,64}) and that has always worked 
fine, see [1] as an example. What I'm talking about here is the recent 
problem that these packages are not available in the rawhide-debuginfo 
repos anymore (rawhide is what I'm using, perhaps the same problem 
affects stable releases).


Thanks
Sandro

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=812441
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1379558] perl-Image-Info: XXE in SVG files [fedora-all]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Image-Info-1.38-6.fc25 |perl-Image-Info-1.38-6.fc25
   ||perl-Image-Info-1.38-6.fc24



--- Comment #6 from Fedora Update System  ---
perl-Image-Info-1.38-6.fc24 has been pushed to the Fedora 24 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Adam Williamson]

On Tue, 2016-10-25 at 12:43 -0700, Adam Williamson wrote:
> 
> Aside from the 'getting stuck and timing out' problem there's a
> dep issue affecting a lot of these tests - looks like firebird-
> libfbembed requires a rebuild for an ICU soname bump. I haven't looked
> into the details yet (to see if anyone's tried to fix it).

So it seems like a new firebird release dropped some subpackages, but
missed obsoleting the libfbembed subpackage:

https://bugzilla.redhat.com/show_bug.cgi?id=1388648
-- 
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: RPM %changelog?

[Kevin Kofler]

Adam Williamson wrote:
> That's pretty much the exact *opposite* of what I put in the changelog,
> FWIW. For me, that stuff goes in the git commit message (and even then
> I don't really break it down in that much detail, because the tools
> make it easy to see *what* changed, the thing the commit message has to
> fill in is *why*). What goes in the package changelog is changes that
> actually make a concrete difference to a *user* of the package. They
> don't give a damn about the BuildRequires changing.

Well, the user-centric stuff belongs in the Bodhi update notes first of all.

To me, the specfile %changelog is somewhere inbetween, it contains things 
like added BuildRequires (which I would not put into the Bodhi notes unless 
it enables some user-visible new feature), it does not contain upstream 
changes (or at most a one-line summary when it matters, e.g. "adds support 
for Python 3"; anything beyond that is only for the Bodhi notes), but it 
does not contain things like "fix a typo in the date of the previous 
changelog entry", those are things I address with a git commit without 
touching %changelog.

So, to me:
* git commit notes: full detail of packaging-level changes including fixes
for screwups in the preceding commits, higher error rate
because I cannot fix them in followup commits (I would
have to force-push, which is not allowed in Fedora
dist-git, to do that),
* specfile %changelog: cleaned-up version of packaging-level changes that I
   am comfortable with letting the users read,
* Bodhi update notes: user-centric write-up of the changes, including
  (relevant) upstream changes, that actually matter to
  the user – I added "relevant" because if I copy
  a list of upstream changes, I actually remove the
  things that are clearly not relevant on Fedora (e.g.,
  because they are specific to some other operating
  system).

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

Re: Fedora Rawhide-20161025.n.0 compose check report

[Adam Williamson]

On Tue, 2016-10-25 at 17:07 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Workstation live i386
> Workstation live x86_64
> 
> Failed openQA tests: 8/90 (x86_64), 2/16 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in Rawhide-20161024.n.0):
> 
> ID: 44083 Test: x86_64 Workstation-boot-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/44083

This hit a failure in the g-s-d color plugin:

Oct 25 06:17:35 localhost.localdomain gnome-shell[1592]: GNOME Shell started at 
Tue Oct 25 2016 09:17:31 GMT-0400 (EDT)
Oct 25 06:17:54 localhost.localdomain pulseaudio[1619]: [pulseaudio] 
bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
Oct 25 06:19:01 localhost.localdomain gnome-session[1543]: 
gnome-session-binary[1543]: WARNING: Application 
'org.gnome.SettingsDaemon.Color.desktop' failed to register before timeout
Oct 25 06:19:01 localhost.localdomain gnome-session-binary[1543]: WARNING: 
Application 'org.gnome.SettingsDaemon.Color.desktop' failed to register before 
timeout
Oct 25 06:19:01 localhost.localdomain gnome-session-binary[1543]: Unrecoverable 
failure in required component org.gnome.SettingsDaemon.Color.desktop

The same test passed on staging, though, so it doesn't look to be a
completely reproducible bug. We can keep an eye out and see if it
happens again...

> ID: 44163 Test: x86_64 universal upgrade_2_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/44163

This timed out again, but I actually think there may be something wacky
going on in the upgrade process to Rawhide: tests that time out don't
seem to be running smoothly but just running out of time, they seem to
actually get stuck at the same point for a long time until they time
out. I haven't had time to look into this in detail yet, though.

> Old failures (same test failed in Rawhide-20161024.n.0):
> 
> ID: 44097 Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/44097

Boot is failing here, somehow, and winding up in dracut emergency
shell. Don't know what's wrong with it yet. Anyone have time to look
into it?

> ID: 44113 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/44113

ipa-server-install crashed.
https://bugzilla.redhat.com/show_bug.cgi?id=1388640

> ID: 44156 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/44156
> ID: 44159 Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/44159
> ID: 44161 Test: x86_64 universal upgrade_2_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/44161
> ID: 44164 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/44164
> ID: 44184 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/44184
> ID: 44185 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/44185

Aside from the 'getting stuck and timing out' problem there's a
dep issue affecting a lot of these tests - looks like firebird-
libfbembed requires a rebuild for an ICU soname bump. I haven't looked
into the details yet (to see if anyone's tried to fix it).
-- 
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

Firefox 49.0.2

[Bojan Smojver]

Could someone with access please build this version of FF. Apparently,
it's a security release.

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

Re: RPM %changelog?

[Japheth Cleaver]

On 10/25/2016 11:35 AM, David Shea wrote:

Please, no, don't do that. RPM is a standard

lol.

  * The representation of file names in package headers changed in rpm-4.0.
  * Originally, file names were stored as an array of absolute paths.
  * In rpm-4.0, file names are stored as separate arrays of dirname's and
  * basename's, * with a dirname index to associate the correct dirname
  * with each basname.

That's just my personal favorite. The RPM standard is whatever RPM is doing 
right now.


While that may be true operationally (the switch in hash algorithms away 
from md5 that forced extra steps backporting to EL5 was annoying), the 
bigger issue is probably spec file design.


It's possible to create spec files (and thus SRPMs) mostly-compatible 
with a wide variety of different downstream uses. This is a good ideal 
to keep striving towards.


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

Re: RPM %changelog?

[Adam Williamson]

On Tue, 2016-10-25 at 18:35 +, David Shea wrote:
> > Please, no, don't do that. RPM is a standard
> 
> lol.
> 
>  * The representation of file names in package headers changed in rpm-4.0.
>  * Originally, file names were stored as an array of absolute paths.
>  * In rpm-4.0, file names are stored as separate arrays of dirname's and
>  * basename's, * with a dirname index to associate the correct dirname
>  * with each basname.
> 
> That's just my personal favorite. The RPM standard is whatever RPM is doing 
> right now.

Still, that doesn't mean we should make it *worse*. :P
-- 
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: RPM %changelog?

[David Shea]

> Please, no, don't do that. RPM is a standard

lol.

 * The representation of file names in package headers changed in rpm-4.0.
 * Originally, file names were stored as an array of absolute paths.
 * In rpm-4.0, file names are stored as separate arrays of dirname's and
 * basename's, * with a dirname index to associate the correct dirname
 * with each basname.

That's just my personal favorite. The RPM standard is whatever RPM is doing 
right now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25-20161025.n.0 compose check report

[Adam Williamson]

On Tue, 2016-10-25 at 15:54 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 5/101 (x86_64), 2/17 (i386)
> 
> New failures (same test did not fail in 25-20161024.n.0):
> 
> ID: 44206 Test: x86_64 KDE-live-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/44206
> ID: 44216 Test: i386 KDE-live-iso install_default
> URL: https://openqa.fedoraproject.org/tests/44216

KDE seems to be crashing quite often on transition from SDDM to KDE
itself, at least in openQA testing. We might want to look into this a
bit more manually. I did take a look at one of the crash reports last
week with Kevin, it sounded like a bit of a mess (KDE's crash handler
was crashing trying to handle whatever the initial crash was...), but
I'm not sure yet if it's always the same thing.

> ID: 44264 Test: x86_64 universal install_simple_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/44264

This one's slightly odd, I've seen it I think once or twice before -
test just failed to transition out of the bootloader properly, it looks
like. Don't really know what's going on.

> ID: 44278 Test: x86_64 universal upgrade_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/44278

Same crash during KDE startup as the other two.
-- 
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: noarch debuginfo packages missing from repo?

[Till Maas]

On Tue, Oct 25, 2016 at 05:44:49PM +0200, Sandro Mani wrote:

> rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is
> found). I suspect that perhaps noarch debuginfo packages are missing from

AFAIK debuginfo packages are not generated for noarch packages. I am not
sure if there is a way to enable them.

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

[EPEL-devel] [Fedocal] Reminder meeting : EPSCO meeting

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPSCO meeting on 2016-10-26 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
Extra Packages for Enterprise Linux Steering COmmittee (EPSCO) has a weekly 
meeting to go over concerns and problems in the EPEL distribution. 

You are kindly invited to come and meet with us


Source: https://apps.fedoraproject.org/calendar/meeting/4639/

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

[EPEL-devel] Re: Desktop application major update (darktable)

[Matthew Miller]

On Tue, Oct 25, 2016 at 11:07:28AM -0600, Kevin Fenzi wrote:
> Well, we need more information (or at least I do): 
> * Is 1.x still supported by upstream?

I don't think so -- the last commit to the "darktable-1.6.x" branch is
just over a year ago, Oct 21, 2015.

> * Are there any known 1.x security issues?

I don't think there are any known outstanding ones — CVE-2015-3885 was
fixed in 1.6.7.

> * Is the upgrade from 1.x to 2.x transparent for the user? ie, would
>   they have to do any manual steps to move config? or is that all done
>   by the application?

It should be transparent, but it _is_ one way — if you make any edits
in the new program, you can't go back.

> * Is the "user experence" different between 1.x and 2.x?

Eh. Judgement call. I'd say it's fundamentally the same, but there are
many differences in both functionality and look & feel. 


Honestly, I think this is an example of an application which is not a
great fit for EPEL. It'd be better if we would make a Flatpak which
RHEL/CentOS users could transparently use.


-- 
Matthew Miller

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

Fedora Rawhide-20161025.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Workstation live x86_64

Failed openQA tests: 8/90 (x86_64), 2/16 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20161024.n.0):

ID: 44083   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44083
ID: 44163   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/44163

Old failures (same test failed in Rawhide-20161024.n.0):

ID: 44097   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/44097
ID: 44113   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/44113
ID: 44142   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/44142
ID: 44156   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/44156
ID: 44159   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/44159
ID: 44161   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/44161
ID: 44164   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/44164
ID: 44184   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44184
ID: 44185   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44185

Passed openQA tests: 79/90 (x86_64), 14/16 (i386)

New passes (same test did not pass in Rawhide-20161024.n.0):

ID: 44084   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/44084
ID: 44085   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/44085

Skipped openQA tests: 1 of 108
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f23). "2.055 bump"

[notifications]

From f5fd7d2520eff3f2d02d915925eb2346710d2e5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Tue, 25 Oct 2016 17:49:58 +0200
Subject: 2.055 bump

---
 .gitignore   |  1 +
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 14 +-
 sources  |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9a8d17a..de21707 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Dist-Zilla-Plugin-Test-Compile-2.052.tar.gz
 /Dist-Zilla-Plugin-Test-Compile-2.053.tar.gz
 /Dist-Zilla-Plugin-Test-Compile-2.054.tar.gz
+/Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz
diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index 4613016..847729e 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -1,6 +1,6 @@
 Name:   perl-Dist-Zilla-Plugin-Test-Compile
-Version:2.054
-Release:3%{?dist}
+Version:2.055
+Release:1%{?dist}
 Summary:Common tests to check syntax of your modules, only using core 
modules
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/
@@ -9,6 +9,7 @@ BuildArch:  noarch
 # Build
 BuildRequires:  perl
 BuildRequires:  perl-generators
+# XXX: BuildRequires:  perl(Data::Dumper)
 # XXX: BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Module::Build::Tiny) >= 0.039
 BuildRequires:  perl(strict)
@@ -29,15 +30,15 @@ BuildRequires:  perl(Path::Tiny)
 BuildRequires:  perl(Sub::Exporter::ForMethods)
 # Tests only
 BuildRequires:  perl(blib)
-BuildRequires:  perl(CPAN::Meta::Check) >= 0.007
+BuildRequires:  perl(CPAN::Meta::Check) >= 0.011
 BuildRequires:  perl(CPAN::Meta::Requirements)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(File::pushd)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(if)
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(IPC::Open3)
 BuildRequires:  perl(Module::CoreList) >= 2.77
+BuildRequires:  perl(Module::Metadata)
 BuildRequires:  perl(Perl::PrereqScanner) >= 1.016
 BuildRequires:  perl(Test::Deep)
 BuildRequires:  perl(Test::DZil)
@@ -73,12 +74,15 @@ perl Build.PL --installdirs=vendor
 ./Build test
 
 %files
-%license LICENSE
+%license LICENCE
 %doc Changes AUTHOR_PLEDGE CONTRIBUTING README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 25 2016 Petr Šabata  - 2.055-1
+- 2.055 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 2.054-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 12b9201..d07c4c4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3aba61846a8e294efd3bf72a328236ca  Dist-Zilla-Plugin-Test-Compile-2.054.tar.gz
+08f5ca67114b05bbaea1cc560f99d721  Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f23=f5fd7d2520eff3f2d02d915925eb2346710d2e5e
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f23). "Perl 5.24 rebuild"

[notifications]

From d88a80a2022a0e71c35493bca50d103ecec77b08 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 17 May 2016 01:15:00 +0200
Subject: Perl 5.24 rebuild

---
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index ed7d77e..2cdedef 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -1,6 +1,6 @@
 Name:   perl-Dist-Zilla-Plugin-Test-Compile
 Version:2.054
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Common tests to check syntax of your modules, only using core 
modules
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/
@@ -78,6 +78,9 @@ perl Build.PL --installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon May 16 2016 Jitka Plesnikova  - 2.054-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.054-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f23=d88a80a2022a0e71c35493bca50d103ecec77b08
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f23). "Mandatory Perl build-requires added "

[notifications]

From d60d066492ab524f60e1fbf35086ec9427484208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:20:33 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index 2cdedef..4613016 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -8,6 +8,7 @@ Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Dist-Zilla-Plugin-Test
 BuildArch:  noarch
 # Build
 BuildRequires:  perl
+BuildRequires:  perl-generators
 # XXX: BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Module::Build::Tiny) >= 0.039
 BuildRequires:  perl(strict)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f23=d60d066492ab524f60e1fbf35086ec9427484208
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f24). "Mandatory Perl build-requires added "

[notifications]

From d60d066492ab524f60e1fbf35086ec9427484208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:20:33 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index 2cdedef..4613016 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -8,6 +8,7 @@ Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/Dist-Zilla-Plugin-Test
 BuildArch:  noarch
 # Build
 BuildRequires:  perl
+BuildRequires:  perl-generators
 # XXX: BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Module::Build::Tiny) >= 0.039
 BuildRequires:  perl(strict)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f24=d60d066492ab524f60e1fbf35086ec9427484208
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f23). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"

[notifications]

From 17d6ee0b8e070d9bb04108a200549d584dcd4a66 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Thu, 4 Feb 2016 13:25:16 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

---
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index f163baf..ed7d77e 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -1,6 +1,6 @@
 Name:   perl-Dist-Zilla-Plugin-Test-Compile
 Version:2.054
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Common tests to check syntax of your modules, only using core 
modules
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/
@@ -78,6 +78,9 @@ perl Build.PL --installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 04 2016 Fedora Release Engineering  - 
2.054-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
 * Mon Aug 17 2015 Petr Šabata  - 2.054-1
 - 2.054 bump
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f23=17d6ee0b8e070d9bb04108a200549d584dcd4a66
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f24). "Perl 5.24 rebuild"

[notifications]

From d88a80a2022a0e71c35493bca50d103ecec77b08 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 17 May 2016 01:15:00 +0200
Subject: Perl 5.24 rebuild

---
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index ed7d77e..2cdedef 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -1,6 +1,6 @@
 Name:   perl-Dist-Zilla-Plugin-Test-Compile
 Version:2.054
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Common tests to check syntax of your modules, only using core 
modules
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/
@@ -78,6 +78,9 @@ perl Build.PL --installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon May 16 2016 Jitka Plesnikova  - 2.054-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.054-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f24=d88a80a2022a0e71c35493bca50d103ecec77b08
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

psabata pushed to perl-Dist-Zilla-Plugin-Test-Compile (f24). "2.055 bump"

[notifications]

From f5fd7d2520eff3f2d02d915925eb2346710d2e5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Tue, 25 Oct 2016 17:49:58 +0200
Subject: 2.055 bump

---
 .gitignore   |  1 +
 perl-Dist-Zilla-Plugin-Test-Compile.spec | 14 +-
 sources  |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9a8d17a..de21707 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Dist-Zilla-Plugin-Test-Compile-2.052.tar.gz
 /Dist-Zilla-Plugin-Test-Compile-2.053.tar.gz
 /Dist-Zilla-Plugin-Test-Compile-2.054.tar.gz
+/Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz
diff --git a/perl-Dist-Zilla-Plugin-Test-Compile.spec 
b/perl-Dist-Zilla-Plugin-Test-Compile.spec
index 4613016..847729e 100644
--- a/perl-Dist-Zilla-Plugin-Test-Compile.spec
+++ b/perl-Dist-Zilla-Plugin-Test-Compile.spec
@@ -1,6 +1,6 @@
 Name:   perl-Dist-Zilla-Plugin-Test-Compile
-Version:2.054
-Release:3%{?dist}
+Version:2.055
+Release:1%{?dist}
 Summary:Common tests to check syntax of your modules, only using core 
modules
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Dist-Zilla-Plugin-Test-Compile/
@@ -9,6 +9,7 @@ BuildArch:  noarch
 # Build
 BuildRequires:  perl
 BuildRequires:  perl-generators
+# XXX: BuildRequires:  perl(Data::Dumper)
 # XXX: BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Module::Build::Tiny) >= 0.039
 BuildRequires:  perl(strict)
@@ -29,15 +30,15 @@ BuildRequires:  perl(Path::Tiny)
 BuildRequires:  perl(Sub::Exporter::ForMethods)
 # Tests only
 BuildRequires:  perl(blib)
-BuildRequires:  perl(CPAN::Meta::Check) >= 0.007
+BuildRequires:  perl(CPAN::Meta::Check) >= 0.011
 BuildRequires:  perl(CPAN::Meta::Requirements)
-BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(File::pushd)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(if)
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(IPC::Open3)
 BuildRequires:  perl(Module::CoreList) >= 2.77
+BuildRequires:  perl(Module::Metadata)
 BuildRequires:  perl(Perl::PrereqScanner) >= 1.016
 BuildRequires:  perl(Test::Deep)
 BuildRequires:  perl(Test::DZil)
@@ -73,12 +74,15 @@ perl Build.PL --installdirs=vendor
 ./Build test
 
 %files
-%license LICENSE
+%license LICENCE
 %doc Changes AUTHOR_PLEDGE CONTRIBUTING README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 25 2016 Petr Šabata  - 2.055-1
+- 2.055 bump
+
 * Mon May 16 2016 Jitka Plesnikova  - 2.054-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 12b9201..d07c4c4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3aba61846a8e294efd3bf72a328236ca  Dist-Zilla-Plugin-Test-Compile-2.054.tar.gz
+08f5ca67114b05bbaea1cc560f99d721  Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Dist-Zilla-Plugin-Test-Compile.git/commit/?h=f24=f5fd7d2520eff3f2d02d915925eb2346710d2e5e
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Andrew Lutomirski]

On Tue, Oct 25, 2016 at 9:33 AM, Adam Williamson
 wrote:
> On Tue, 2016-10-25 at 09:30 -0700, Adam Williamson wrote:
>> On Tue, 2016-10-25 at 05:16 -0400, Bastien Nocera wrote:
>> >
>> > - Original Message -
>> > > Adam Williamson wrote:
>> > > > If you use Fedora (Workstation, at least, and I think maybe KDE too) on
>> > > > a 3200x1800 13" screen then hidpi mode will kick in, and everything
>> > > > will be sized as if you were using a 1600x900 13" screen, which is a
>> > > > pretty common setup.
>> > >
>> > > Yes, Plasma 5 definitely handles that as a hidpi display.
>> > >
>> > > But KDE is actually much smarter and can handle any DPI, though you will
>> > > likely have to configure it manually, because as you explained, the
>> > > developers of the commonly used X drivers decided to be jerks and
>> > > deliberately report a bogus geometry.
>> >
>> > [Citation really needed]
>>
>> Well, Kevin's framing of this is clearly...opionated...:) but my blog
>> post gave the citation.
>>
>> https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/
>> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86RandR12.c#n787
>>
>> as my post explained:
>
> Oh, since I'm referring to an old post I should note one thing: after I
> wrote that post (and partly because of it), GTK+'s behaviour was
> changed to just use a hardcoded default of 96dpi, like GNOME.
> Everywhere the post refers to GTK+ doing the same DPI calculation as
> KDE/Qt, that's no longer true. It doesn't do that any more.

All of this makes me wonder: should the system perhaps attempt to
estimate the number of pixels per visual inch or perhaps per degree at
expected viewing position?  This shouldn't be *that* hard -- there
would be a little table of estimated viewing distances for laptops,
desktops, and tablets, and the system could extrapolate from there.
(Projectors are probably a lost cause and perhaps it should be purely
a function of resolution.)

At the very least, it would be rather nice to have a real (not
gnome-tweak-tool or dconf) interface for scaling the UI.

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

Re: F25 workstation, and (almost) hidpi displays

[Adam Williamson]

On Tue, 2016-10-25 at 09:30 -0700, Adam Williamson wrote:
> On Tue, 2016-10-25 at 05:16 -0400, Bastien Nocera wrote:
> > 
> > - Original Message -
> > > Adam Williamson wrote:
> > > > If you use Fedora (Workstation, at least, and I think maybe KDE too) on
> > > > a 3200x1800 13" screen then hidpi mode will kick in, and everything
> > > > will be sized as if you were using a 1600x900 13" screen, which is a
> > > > pretty common setup.
> > > 
> > > Yes, Plasma 5 definitely handles that as a hidpi display.
> > > 
> > > But KDE is actually much smarter and can handle any DPI, though you will
> > > likely have to configure it manually, because as you explained, the
> > > developers of the commonly used X drivers decided to be jerks and
> > > deliberately report a bogus geometry.
> > 
> > [Citation really needed]
> 
> Well, Kevin's framing of this is clearly...opionated...:) but my blog
> post gave the citation.
> 
> https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/
> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86RandR12.c#n787
> 
> as my post explained:

Oh, since I'm referring to an old post I should note one thing: after I
wrote that post (and partly because of it), GTK+'s behaviour was
changed to just use a hardcoded default of 96dpi, like GNOME.
Everywhere the post refers to GTK+ doing the same DPI calculation as
KDE/Qt, that's no longer true. It doesn't do that any more.
-- 
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: F25 workstation, and (almost) hidpi displays

[Adam Williamson]

On Tue, 2016-10-25 at 05:16 -0400, Bastien Nocera wrote:
> 
> - Original Message -
> > Adam Williamson wrote:
> > > If you use Fedora (Workstation, at least, and I think maybe KDE too) on
> > > a 3200x1800 13" screen then hidpi mode will kick in, and everything
> > > will be sized as if you were using a 1600x900 13" screen, which is a
> > > pretty common setup.
> > 
> > Yes, Plasma 5 definitely handles that as a hidpi display.
> > 
> > But KDE is actually much smarter and can handle any DPI, though you will
> > likely have to configure it manually, because as you explained, the
> > developers of the commonly used X drivers decided to be jerks and
> > deliberately report a bogus geometry.
> 
> [Citation really needed]

Well, Kevin's framing of this is clearly...opionated...:) but my blog
post gave the citation.

https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86RandR12.c#n787

as my post explained:

"As you can see there are basically three paths: one if
monitorResolution is set, one if output->conf_monitor->mon_width and
output->conf_monitor->mon_height are set, and a fallback if neither of
those are true. monitorResolution is set if the Xorg binary was called
with the -dpi parameter. mon_width and mon_height are set if some X
config file or another contains the DisplaySize parameter.

If you specified a dpi on the command line, X will figure out whatever
‘physical size’ would result in that DPI for the resolution that’s in
use, and claim that the screen is that size. If you specify a size with
the DisplaySize parameter, X just uses that. And if neither of those is
true, X will pick a physical size based on a built-in default DPI,
which is...96."
-- 
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

[Bug 1379557] perl-Image-Info: XXE in SVG files [epel-5]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Image-Info-1.38-6.el5
 Resolution|--- |ERRATA
Last Closed||2016-10-25 12:16:33



--- Comment #3 from Fedora Update System  ---
perl-Image-Info-1.38-6.el5 has been pushed to the Fedora EPEL 5 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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: noarch debuginfo packages missing from repo?

[Sandro Mani]

On 25.10.2016 18:14, Kevin Fenzi wrote:

On Tue, 25 Oct 2016 17:44:49 +0200
Sandro Mani  wrote:


Hi

Just noticed that dnf (or yum-deprecated for the matter) won't find
any mingw{32,64}-XXX-debuginfo packages to install (even though
rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is
found). I suspect that perhaps noarch debuginfo packages are missing
from the repo? Indeed
mingw-qt5-qtbase-debuginfo-5.6.0-4.fc24.x86_64.rpm is also found.
Perhaps a recent regression in the repo generation?

Which repo? ;) If it's 25/rawhide, then pungi bug. If it's
updates/updates-testing then bodhi bug.

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

Re: noarch debuginfo packages missing from repo?

[Kevin Fenzi]

On Tue, 25 Oct 2016 17:44:49 +0200
Sandro Mani  wrote:

> Hi
> 
> Just noticed that dnf (or yum-deprecated for the matter) won't find
> any mingw{32,64}-XXX-debuginfo packages to install (even though 
> rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is 
> found). I suspect that perhaps noarch debuginfo packages are missing 
> from the repo? Indeed
> mingw-qt5-qtbase-debuginfo-5.6.0-4.fc24.x86_64.rpm is also found.
> Perhaps a recent regression in the repo generation?

Which repo? ;) If it's 25/rawhide, then pungi bug. If it's
updates/updates-testing then bodhi bug. 

kevin


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

Re: RPM %changelog?

[Adam Williamson]

On Tue, 2016-10-25 at 10:43 -0500, Michael Catanzaro wrote:
> On Tue, 2016-10-25 at 11:08 -0400, Matthew Miller wrote:
> > This seems perfect! (Wow, look what happens when we have people from
> > other distros participating -- thanks!)
> 
> It doesn't do anything to fix the problem that the changelog takes up
> way too much space in the spec file. We should have .changes files too,
> like SUSE has, and teach our build tools to deal with them properly.

That wouldn't really bother me, so I'm only curious, but why do you
find having a big changelog at the end of the file so annoying? It's at
the end and you pretty much never have to look at it. Is it just
because it tends to match searches, or what?
-- 
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

Fedora 25-20161025.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/101 (x86_64), 2/17 (i386)

New failures (same test did not fail in 25-20161024.n.0):

ID: 44206   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44206
ID: 44216   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/44216
ID: 44264   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/44264
ID: 44278   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/44278

Old failures (same test failed in 25-20161024.n.0):

ID: 44200   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/44200
ID: 44305   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44305
ID: 44307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/44307

Passed openQA tests: 96/101 (x86_64), 15/17 (i386), 2/2 (arm)

New passes (same test did not pass in 25-20161024.n.0):

ID: 44214   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/44214
ID: 44220   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44220
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

psabata uploaded Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz for perl-Dist-Zilla-Plugin-Test-Compile

[notifications]

08f5ca67114b05bbaea1cc560f99d721  Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Dist-Zilla-Plugin-Test-Compile/Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz/md5/08f5ca67114b05bbaea1cc560f99d721/Dist-Zilla-Plugin-Test-Compile-2.055.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

noarch debuginfo packages missing from repo?

[Sandro Mani]

Hi

Just noticed that dnf (or yum-deprecated for the matter) won't find any 
mingw{32,64}-XXX-debuginfo packages to install (even though 
rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is 
found). I suspect that perhaps noarch debuginfo packages are missing 
from the repo? Indeed mingw-qt5-qtbase-debuginfo-5.6.0-4.fc24.x86_64.rpm 
is also found. Perhaps a recent regression in the repo generation?


Thanks
Sandro


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

Re: RPM %changelog?

[Michael Catanzaro]

On Tue, 2016-10-25 at 11:08 -0400, Matthew Miller wrote:
> This seems perfect! (Wow, look what happens when we have people from
> other distros participating -- thanks!)

It doesn't do anything to fix the problem that the changelog takes up
way too much space in the spec file. We should have .changes files too,
like SUSE has, and teach our build tools to deal with them properly.

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

Re: RPM %changelog?

[Vít Ondruch]

Dne 25.10.2016 v 16:23 Kevin Fenzi napsal(a):
> On Tue, 25 Oct 2016 08:56:10 -0400
> Matthew Miller  wrote:
>
>> On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:
 Please, no, don't do that. RPM is a standard, the changelog is
 part of that. It would be pretty crappy to just declare we're
 going to stop using RPM changelogs and bake some random new idea
 into our distro's packaging tools instead.  
>>> I agree with Adam here.  
>> Well, except -- it doesn't come for free. I was just talking to David
>> Shea about something different and he mentioned that changelogs
>> comprise about 40% of RPM metadata, both on disk and in-memory for
>> every transaction.
> How about we globally set: 
>
> %global _changelog_trimtime %(date +%s -d "1 year ago")
>
> (or 6 months or whatever). 

It should be combination of time and number changelog entries. But the
latter is not supported by RPM I am afraid :/

V.

>
> Then git still has the full changelog for anyone that cares, but all
> the rpms have a trimmed changelog. 
>
> kevin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: RPM %changelog?

[Adam Williamson]

On Sun, 2016-10-23 at 19:46 +0200, Michael Schwendt wrote:
> On Sun, 23 Oct 2016 16:21:25 +, Christopher wrote:
> 
> > > Our rules is "leave it to the packager's personal preference" and to
> > > "keep what's important".
> > 
> > I'm curious, what *IS* important?
> 
> 1.) Don't copy upstream changelogs into the spec %changelog.
> 
> 2.) Mention everything that may affect whether the packaged software
> no longer works, such as added/removed patches, added/remove BuildRequires,
> added/removed explicit Requires, replaced source tarballs, changes to the
> build process, rebuilds (note that rebuilt dependencies may cause
> breakage, too, so both users and maintainers may read %changelogs and
> figure out what components had been touched before something has caused
> breakage), changes to custom installation in %install as well as to the
> scriptlets/triggers.

That's pretty much the exact *opposite* of what I put in the changelog,
FWIW. For me, that stuff goes in the git commit message (and even then
I don't really break it down in that much detail, because the tools
make it easy to see *what* changed, the thing the commit message has to
fill in is *why*). What goes in the package changelog is changes that
actually make a concrete difference to a *user* of the package. They
don't give a damn about the BuildRequires changing.

Of course, the reason we have a different opinion on this is simple:
because the distinction postdates the design of RPM and we've never
come up with a widely-followed formal policy on this stuff. We weren't
storing package specs in git (or in a VCS at all, I don't think) when
RPM was invented, so the package changelog got all the information (or
at least, it *should* have done; skeletal changelog entries are very
common in old packages, sadly).
-- 
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: RPM %changelog?

[Matthew Miller]

On Tue, Oct 25, 2016 at 04:59:17PM +0200, Michael Schroeder wrote:
> FWIW, SUSE has a patch in rpm that trims only the changelog of binary rpms
> and leaves the full changelog in the source rpms.

This seems perfect! (Wow, look what happens when we have people from
other distros participating -- thanks!)

-- 
Matthew Miller

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

Re: RPM %changelog?

[Michael Schroeder]

On Tue, Oct 25, 2016 at 03:33:25PM +0100, Peter Robinson wrote:
> >> On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:
> >> > > Please, no, don't do that. RPM is a standard, the changelog is
> >> > > part of that. It would be pretty crappy to just declare we're
> >> > > going to stop using RPM changelogs and bake some random new idea
> >> > > into our distro's packaging tools instead.
> >> > I agree with Adam here.
> >>
> >> Well, except -- it doesn't come for free. I was just talking to David
> >> Shea about something different and he mentioned that changelogs
> >> comprise about 40% of RPM metadata, both on disk and in-memory for
> >> every transaction.
> >
> > How about we globally set:
> >
> > %global _changelog_trimtime %(date +%s -d "1 year ago")
> >
> > (or 6 months or whatever).
> >
> > Then git still has the full changelog for anyone that cares, but all
> > the rpms have a trimmed changelog.
> 
> Yes! This was the parameter I couldn't remember above. I think this
> makes sense. The full spec changelog is then kept in dist-git and just
> trimmed as part of the build process. No loss and it's uniform.

FWIW, SUSE has a patch in rpm that trims only the changelog of binary rpms
and leaves the full changelog in the source rpms.

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: orphaning ec2-metadata, system-autodeath, s3cmd

[Manuel F Martinez]

I'm taking ec2-metadata.

Thank you.

On Fri, Sep 16, 2016 at 6:51 AM, Fabio Alessandro Locati 
wrote:

> On Fri, Sep 16, 2016 at 06:07:49AM -0400, Nico Kadel-Garcia wrote:
> > On Thu, Sep 15, 2016 at 3:24 PM, Athmane Madjoudj
> >  wrote:
> > > Hi,
> > >
> > > On Thu, Sep 15, 2016 at 8:00 PM, Matthew Miller
> > >  wrote:
> > >> s3cmd
> > >
> > > I took s3cmd.
> >
> > Good. s3cmd sems to have been superseded, at Amazon, by awscli.
> > Unfortunately, awscli is a !@#$!#@ to RPM bundle. I tried. The
> > difficulty is the chain of python module dependencies, each of which
> > have python module dependencies, and some of which have *conflicting*
> > python module dependencies. The conflicts apply especially to the
> > Sphinx versions used to build the documentation of different modules.
>
> awscli is actually packaged and maintained (by me) in Fedora.
> --
> Fabio Alessandro Locati
> Red Hat - Senior Consultant
>
> PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>


-- 
Manuel F Martinez
Linux Systems Engineer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Peter Robinson]

>> On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:
>> > > Please, no, don't do that. RPM is a standard, the changelog is
>> > > part of that. It would be pretty crappy to just declare we're
>> > > going to stop using RPM changelogs and bake some random new idea
>> > > into our distro's packaging tools instead.
>> > I agree with Adam here.
>>
>> Well, except -- it doesn't come for free. I was just talking to David
>> Shea about something different and he mentioned that changelogs
>> comprise about 40% of RPM metadata, both on disk and in-memory for
>> every transaction.
>
> How about we globally set:
>
> %global _changelog_trimtime %(date +%s -d "1 year ago")
>
> (or 6 months or whatever).
>
> Then git still has the full changelog for anyone that cares, but all
> the rpms have a trimmed changelog.

Yes! This was the parameter I couldn't remember above. I think this
makes sense. The full spec changelog is then kept in dist-git and just
trimmed as part of the build process. No loss and it's uniform.

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

Fedora 25 compose report: 20161025.n.0 changes

[Fedora Branched Report]

OLD: Fedora-25-20161024.n.0
NEW: Fedora-25-20161025.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  4
Dropped packages:0
Upgraded packages:   65
Downgraded packages: 0

Size of added packages:  199.07 KiB
Size of dropped packages:0.00 B
Size of upgraded packages:   730.97 MiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -3.38 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Docker_Base docker armhfp
Path: Docker/armhfp/images/Fedora-Docker-Base-25-20161024.n.0.armhfp.tar.xz
Image: Docker_Base docker x86_64
Path: Docker/x86_64/images/Fedora-Docker-Base-25-20161024.n.0.x86_64.tar.xz

= ADDED PACKAGES =
Package: perl-Specio-Library-Path-Tiny-0.04-1.fc25
Summary: Path::Tiny types and coercions for Specio
RPMs:perl-Specio-Library-Path-Tiny
Size:19090 bytes

Package: python-ntlm3-1.0.2-1.fc25
Summary: Python 3 compatible NTLM library
RPMs:python2-ntlm3 python3-ntlm3
Size:76392 bytes

Package: python-requests_ntlm-0.3.0-1.fc25
Summary: NTLM module for python requests
RPMs:python2-requests_ntlm python3-requests_ntlm
Size:28812 bytes

Package: switcheroo-control-1.0-1.fc25
Summary: D-Bus service to check the availability of dual-GPU
RPMs:switcheroo-control
Size:79550 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  389-ds-console-1.2.16-1.fc25
Old package:  389-ds-console-1.2.15-1.fc25
Summary:  389 Directory Server Management Console
RPMs: 389-ds-console 389-ds-console-doc
Size: 1503748 bytes
Size change:  276 bytes
Changelog:
  * Wed Oct 19 2016 Mark Reynolds <mreyno...@redhat.com> - 1.2.16-1
  - Bump version to 1.2.16
  - Ticket 48743 - ds-console enables obsolete SSL ciphers by default


Package:  ark-16.08.2-1.fc25
Old package:  ark-16.08.1-1.fc25
Summary:  Archive manager
RPMs: ark ark-libs
Size: 1820524 bytes
Size change:  -1476 bytes
Changelog:
  * Thu Sep 15 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.1-2
  - -libs: move Provides: ark-part here
  - soft deps: Recommends: unar, Suggests: lha

  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.2-1
  - 16.08.2


Package:  control-center-1:3.22.1-2.fc25
Old package:  control-center-1:3.22.1-1.fc25
Summary:  Utilities to configure the GNOME desktop
RPMs: control-center control-center-filesystem
Size: 14053744 bytes
Size change:  1608 bytes
Changelog:
  * Fri Oct 21 2016 Bastien Nocera <bnoc...@redhat.com> - 1:3.22.1-2
  + control-center-3.22.1-2
  - Show the correct GPUs available when under Wayland or with dual GPUs


Package:  erlang-19.1.4-1.fc25
Old package:  erlang-19.0.7-1.fc25
Summary:  General-purpose programming language and runtime environment
RPMs: erlang erlang-asn1 erlang-common_test erlang-compiler 
erlang-cosEvent erlang-cosEventDomain erlang-cosFileTransfer 
erlang-cosNotification erlang-cosProperty erlang-cosTime erlang-cosTransactions 
erlang-crypto erlang-debugger erlang-dialyzer erlang-diameter erlang-doc 
erlang-edoc erlang-eldap erlang-erl_docgen erlang-erl_interface erlang-erts 
erlang-et erlang-eunit erlang-examples erlang-gs erlang-hipe erlang-ic 
erlang-inets erlang-jinterface erlang-kernel erlang-megaco erlang-mnesia 
erlang-observer erlang-odbc erlang-orber erlang-os_mon erlang-otp_mibs 
erlang-parsetools erlang-percept erlang-public_key erlang-reltool 
erlang-runtime_tools erlang-sasl erlang-snmp erlang-ssh erlang-ssl 
erlang-stdlib erlang-syntax_tools erlang-tools erlang-typer erlang-wx 
erlang-xmerl
Size: 133672632 bytes
Size change:  129480 bytes
Changelog:
  * Tue Oct 04 2016 Peter Lemenkov <lemen...@gmail.com> - 19.1.1-1
  - Ver. 19.1.1

  * Thu Oct 06 2016 Peter Lemenkov <lemen...@gmail.com> - 19.1.2-1
  - Ver. 19.1.2

  * Tue Oct 11 2016 Peter Lemenkov <lemen...@gmail.com> - 19.1.3-1
  - Ver. 19.1.3

  * Fri Oct 14 2016 Peter Lemenkov <lemen...@gmail.com> - 19.1.4-1
  - Ver. 19.1.4


Package:  execdb-0.0.7-5.fc25
Old package:  execdb-0.0.7-4.fc25
Summary:  Execution status database for Taskotron
RPMs: execdb
Size: 48094 bytes
Size change:  100 bytes
Changelog:
  * Thu Sep 29 2016 Martin Krizek <mkri...@redhat.com> - 0.0.7-5
  - using python2-flask-sqlalchemy breaks depcheck on f23


Package:  filelight-1:16.08.2-1.fc25
Old package:  filelight-1:16.08.1-1.fc25
Summary:  Graphical disk usage statistics
RPMs: filelight
Size: 812806 bytes
Size change:  -3524 bytes
Changelog:
  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 1:16.08.2-1
  - 16.08.2


Package:  gasnet-1.26.4-6.fc25
Old package:  gasnet-1.26.4-5.fc25
Summary:  A Portable High-Performance Communication Layer for GAS Languages
RPMs: gasnet gasnet-common gasnet-devel gasnet-doc gasnet-mpich 
gasnet-openmpi
Si

Re: RPM %changelog?

[Kevin Fenzi]

On Tue, 25 Oct 2016 08:56:10 -0400
Matthew Miller  wrote:

> On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:
> > > Please, no, don't do that. RPM is a standard, the changelog is
> > > part of that. It would be pretty crappy to just declare we're
> > > going to stop using RPM changelogs and bake some random new idea
> > > into our distro's packaging tools instead.  
> > I agree with Adam here.  
> 
> Well, except -- it doesn't come for free. I was just talking to David
> Shea about something different and he mentioned that changelogs
> comprise about 40% of RPM metadata, both on disk and in-memory for
> every transaction.

How about we globally set: 

%global _changelog_trimtime %(date +%s -d "1 year ago")

(or 6 months or whatever). 

Then git still has the full changelog for anyone that cares, but all
the rpms have a trimmed changelog. 

kevin


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

Re: RPM %changelog?

[Michael Schroeder]

On Tue, Oct 25, 2016 at 11:35:46AM +0100, Richard W.M. Jones wrote:
> SUSE deleted all their RPM changelogs a very long time ago, we should
> do the same.

AFAIK the SUSE .changes files predate the switch to rpm. So we
somewhat never used rpm style changelogs. ;)

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-1.fc26.noarch requires root-core
Please resolve this as soon as possible.

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

Re: RPM %changelog?

[Alec Leamas]

On 25/10/16 14:56, Matthew Miller wrote:

On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:

Please, no, don't do that. RPM is a standard, the changelog is part of
that. It would be pretty crappy to just declare we're going to stop
using RPM changelogs and bake some random new idea into our distro's
packaging tools instead.

I agree with Adam here.


So do I


Well, except -- it doesn't come for free. I was just talking to David
Shea about something different and he mentioned that changelogs
comprise about 40% of RPM metadata, both on disk and in-memory for
every transaction.


Which raises another issue: How long history should be kept in the spec 
file? Can't we have some policy stating that we can purge entries older 
then X years, and tooling support for that? Trusting whatever VCS we 
have for the longer history?


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

Re: RPM %changelog?

[Matthew Miller]

On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:
> > Please, no, don't do that. RPM is a standard, the changelog is part of
> > that. It would be pretty crappy to just declare we're going to stop
> > using RPM changelogs and bake some random new idea into our distro's
> > packaging tools instead.
> I agree with Adam here.

Well, except -- it doesn't come for free. I was just talking to David
Shea about something different and he mentioned that changelogs
comprise about 40% of RPM metadata, both on disk and in-memory for
every transaction.


-- 
Matthew Miller

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

Re: Private Bugzilla bugs

[dennis]

There has never been any policy against private bugs, and it's been encouraged 
for security sensitive bugs from day 1. There is a lot of Red Hat employees who 
default to private bugs or private comments due to working mostly on internal 
bugs. A nice rfe might be to enable the ability to default private comments in 
or off for different products.

Dennis

On 25 October 2016 7:29:25 am GMT-05:00, Kevin Kofler  
wrote:
>Jakub Filak wrote:
>> I will repeat my argument again - users are allowed to do it when
>filling
>> a private bug manually.
>
>My point is, they shouldn't be.
>
>Kevin Kofler
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Call for help contacting contributor: aledvink

[Pierre-Yves Chibon]

On Wed, Oct 05, 2016 at 12:42:53PM +0200, Pierre-Yves Chibon wrote:
> Dear all,
> 
> Packagers, members of the fedorabugs group and people having a 'watchbugzilla'
> ACL in pkgdb must have a bugzilla account attached to the email they set in 
> the
> Fedora Account System (FAS).
> This is mandatory to allow ACLs to be propagated from pkgdb to bugzilla, 
> allowing
> the right person to be made assignee or to be cc'ed on bug reports of 
> packages.
> 
> There are currently an users who is not following this rule and have been for
> quite a while, despite our attempts to contact them:
> 
> * aledvink,  FAS email: aledvink -- centrum.cz
> PoC of 2 packages - co-maintains 7 packages
> https://admin.fedoraproject.org/pkgdb/packager/aledvink/
> 
> 
> If anyone knows how to reach to them and could either send them to us, the
> Fedora infrastructure team, or directly ask them to create a bugzilla account
> associated to the email they set in FAS, it would be highly appreciated.
> 
> 
> If nothing changes in the coming days, we will ask FESCo to drop their ACLs.

Since the situation has not changed over the last 20 days, I have opened a
ticket for FESCo to consider: https://pagure.io/fesco/issue/1639


Thanks,
Pierre


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

Re: F25 workstation, and (almost) hidpi displays

[Kevin Kofler]

Bastien Nocera wrote:
> - Original Message -
>> But KDE is actually much smarter and can handle any DPI, though you will
>> likely have to configure it manually, because as you explained, the
>> developers of the commonly used X drivers decided to be jerks and
>> deliberately report a bogus geometry.
> 
> [Citation really needed]

Sorry, this is actually done in the XRandR code in the X server (though some 
drivers may be doing their own thing in addition):
https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86RandR12.c#n793
https://lists.x.org/archives/xorg-devel/2011-October/026227.html
https://cgit.freedesktop.org/xorg/xserver/commit/?id=fff00df94d7ebd18a8e24537ec96073717375a3f

> So Qt 5.6 supports non-integer scale factors with the exact same problems
> that made GTK+ developers not support it.

Trying to support it is the way to get it fixed. And users may prefer having 
the application using the correct sizes with some minor glitches to having 
huge or unreadably small fonts, icons, etc.

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

Re: Storage size unknown on rawhide

[Tomas Mraz]

On 10/25/2016 10:41 AM, Tomasz Torcz wrote:
> On Tue, Oct 25, 2016 at 10:01:55AM +0200, Julien Enselme wrote:
>> Hi,
>>
>> I have an error while building ccnet on rawhide:
>>
>> utils.c: In function 'ccnet_decrypt_with_key':
>> utils.c:1141:20: error: storage size of 'ctx' isn't known
>>  EVP_CIPHER_CTX ctx;
>   Looks like ccnet need porting to OpenSSL 1.1.x API.
> There was a thread about version bump few days ago on this list.

Yes, please look here for similar patches, how this API change needs to
be reflected in the sources:
https://github.com/patch-exchange/openssl-1.1-transition

Basically you have to use EVP_CIPHER_CTX_new() and ..._free() to
allocate and deallocate the structure and use only pointer. For all the
structure members that should be used publicly there are accessor
functions ..._get..() and ..._set...().

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

Re: Private Bugzilla bugs

[Kevin Kofler]

Jakub Filak wrote:
> I will repeat my argument again - users are allowed to do it when filling
> a private bug manually.

My point is, they shouldn't be.

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

[Bug 1382943] perl-Dist-Zilla-6.008 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Dist-Zilla-6.008-1.fc2
   ||5
 Resolution|--- |CURRENTRELEASE
Last Closed||2016-10-25 08:15:32



-- 
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: Dumb newbie packager questions

[Stephen Gallagher]

On 10/25/2016 01:48 AM, Adam Williamson wrote:
> On Sat, 2016-10-22 at 22:08 -0600, William Moreno wrote:
>> By default koji will not let build a package of there is a previus buid
>> with the same NVR in the same branch, you can build many times the same NVR
>> in diferent  branches, (fedpkg switch-branch)
> 
> Well, no, because it won't be the same release...that's the 'R' part of
> NEVR. The .fc26 / .fc25 / .fc24 you get in almost any Fedora package -
> it's the value of %{dist} - is part of the release.
> 
> I don't know what happens if you take the %{dist} out of your spec file
> and try to build it for two different build targets, but...don't do
> that. :)
> 

Having done that accidentally last week, I can tell you that the first one will
succeed and the second one will fail when it tries to tag the build at the end,
because the tag is based on NEVR. So the compilation phase will succeed, but the
Koji build as a whole will fail.



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: First steps for New Comers

[Stephen Gallagher]

On 10/25/2016 06:19 AM, amitk...@redhat.com wrote:
> Hi,
> I want to contribute to sssd project. I have builded and installed source 
> code on my VM
> These are my queries:
> 1. I tried to pick up a easyfix bug at 
> https://fedorahosted.org/sssd/query?status=new=reopened=~easyfix=~=status=id=summary=status=type=priority=milestone=component=34=priority
>  But all bugs are owned by someone or else.

That doesn't mean that the person is actively working on it, actually. If the
status is "New", then it hasn't been started on yet. The SSSD developers move
the status to "Assigned" once they start on it.

I'd suggest picking one you're interested in and adding a comment asking if it
would be okay if you took it over.


> Though in filters I have selected .. Statusnew  or  reopened
> 2. Is there any documentation(Steps) for new comers to start with.
> 


https://fedorahosted.org/sssd/wiki/Contribute#Tasksfornewcomers



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: RPM %changelog?

[Vít Ondruch]

Dne 25.10.2016 v 13:03 Neal Gompa napsal(a):
> On Tue, Oct 25, 2016 at 6:35 AM, Richard W.M. Jones  wrote:
>> On Tue, Oct 25, 2016 at 09:14:14AM +0200, Vít Ondruch wrote:
>>> So why don't we optionally split changelog out of the .spec file?
>>> Something like this might be first step:
>>>
>>>
>>> $ sed -n '/^*/,$ p' ruby.spec > ruby.changes
>> The problem with this is the first time there is a mass rebuild, or a
>> packager uses rpmdev-bumpspec, or we just have a naive packager who
>> doesn't understand what's happening, you'll end up with:
>>
>>   %changelog
>>   * Fri Oct 21 2016 Some One  - 2.3.1-59
>>   - Mass rebuild.
>>   %include %{SOURCE100}
>>
>> which will cause all sorts of problems (changelog will likely be out
>> of order for a start).

I agree, that was idea for start. Of course rpmdev-bumspec and fedpkd
clog and similar would need some adjustments.

On the other hand, your example actually does not break anything, it is
just a bit inconsistent. Nothing which I could not fix next time I'll be
updating the package. This is something similar to -bumpspec addint .1
after NEVR.

>>
>> SUSE deleted all their RPM changelogs a very long time ago, we should
>> do the same.

It seems to be baked into their build system, since their tool which
modifies the .spec file in-place. But we are probably looking into
something which fits better into RPM ecosystem.

> It would probably be better if %changelog grew a "-f" flag so that you
> can point it to a file instead of using %include. It's also idiomatic
> (we do this for %files lists, too).

I like the idea, although something like %include_chagelog macro would
do the job as well. What I dislike about my initial proposal is the need
of %{SOURCE} macro. Not sure if the '-f' flag would do better job here.


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

Re: F25 workstation, and (almost) hidpi displays

[nicolas . mailhot]

De: "Bastien Nocera" 
> So Qt 5.6 supports non-integer scale factors with the exact same problems
> that made GTK+ developers not support it.

So QT 5.6 handles configurations GTK+ developers refused to envision.

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

Re: RPM %changelog?

[Neal Gompa]

On Tue, Oct 25, 2016 at 6:35 AM, Richard W.M. Jones  wrote:
> On Tue, Oct 25, 2016 at 09:14:14AM +0200, Vít Ondruch wrote:
>> So why don't we optionally split changelog out of the .spec file?
>> Something like this might be first step:
>>
>>
>> $ sed -n '/^*/,$ p' ruby.spec > ruby.changes
>
> The problem with this is the first time there is a mass rebuild, or a
> packager uses rpmdev-bumpspec, or we just have a naive packager who
> doesn't understand what's happening, you'll end up with:
>
>   %changelog
>   * Fri Oct 21 2016 Some One  - 2.3.1-59
>   - Mass rebuild.
>   %include %{SOURCE100}
>
> which will cause all sorts of problems (changelog will likely be out
> of order for a start).
>
> I agree with the sentiment but I don't think this will work.  It has
> to be coordinated across the whole distro and tooling.
>
> SUSE deleted all their RPM changelogs a very long time ago, we should
> do the same.
>
> Rich.

It would probably be better if %changelog grew a "-f" flag so that you
can point it to a file instead of using %include. It's also idiomatic
(we do this for %files lists, too).

That behavior could also allow for truncating to the most recent
entries in the spec itself, while keeping the rest in a changes file
that gets appended to the end of the in-spec changelog. Of course, if
there's no entries, then only the changes file would be merged into
the spec.



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