Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Matthew Miller]

On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
> mistake that caused files to go missing, and was never detected by the person
> making the change, because of the use of globs. So I agree it is good practice
> to explicitly list files without globs whereever it is practical todo so. I'd
> make an exception for files which don't have functional impact eg don't list
> 1000 HTML files individually, but it is always worth listing everything in
> /usr/bin, and /usr/lib(64) explicitly without globs.

I used to agree with this, but I've come around to thinking that spec
files should be smaller, less complicated, and more automatable. I
think we'd be better having a post-build test warning that this package
has files missing from the previous build. That could be advisory, or
it could even gate, with the packager clearing the gate by updating the
file list in the test, rather than in the spec file.

-- 
Matthew Miller

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Richard Shaw]

On Wed, Feb 28, 2018 at 12:38 PM, Daniel P. Berrangé 
wrote:

> On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
> > On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
> > > mistake that caused files to go missing, and was never detected by the
> person
> > > making the change, because of the use of globs. So I agree it is good
> practice
> > > to explicitly list files without globs whereever it is practical todo
> so. I'd
> > > make an exception for files which don't have functional impact eg
> don't list
> > > 1000 HTML files individually, but it is always worth listing
> everything in
> > > /usr/bin, and /usr/lib(64) explicitly without globs.
> >
> > I used to agree with this, but I've come around to thinking that spec
> > files should be smaller, less complicated, and more automatable. I
> > think we'd be better having a post-build test warning that this package
> > has files missing from the previous build. That could be advisory, or
> > it could even gate, with the packager clearing the gate by updating the
> > file list in the test, rather than in the spec file.
>
> The further down the workflow a problem is detected the more time expensive
> / disruptive it is to fix it. So while having post-build tests to validate
> lots of things is great (and I wish we had more of it in Fedora), I see it
> as complementary to anything that we can do to detect problems earlier. I
> rather see failures right away when I test the new RPM build locally, than
> waiting to push it through koji and wait again for post-build tests to find
> the problem, as by that time I've context switched my mind away to a
> different bit of work.


I don't have the infra experience to implement, but what about adding
adding a pkgdiff option to fedpkg where it would complete a scratch build
(--srpm if necessary) and then run pkgdiff against it and the current
packages in the repository and putting the report somewhere accessible?

Another idea might be to have a way through the copr-cli to create a
private copr project on the fly, build the new package and then attempt to
rebuild all dependencies with it. That way it can be done completely
"offline" and you'll know if you're likely to break anything before doing
official builds.

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

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

[Jason L Tibbitts III]

> "OO" == Orcan Ogetbil  writes:

OO> Shouldn't we consider having -devel packages Require gcc or gcc-c++?
OO> What good is a header package without a compiler anyway?

You could argue whether they're useful without a compiler, but they are
certainly useful without gcc.  Because that's not the only compiler.

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 28, 2018 at 09:53:19AM -0700, stan wrote:
> On Wed, 28 Feb 2018 08:04:41 -0500
> "Jared K. Smith"  wrote:
> 
> > ... Even if we didn't have
> > this rule, it would be common courtesy to announce any change that
> > causes others to have to do work, even if it's only for a few users.
> 
> What about an email list called fedora-soname-bump.  If you are going
> to do a soname bump, you send an email to that list with the library in
> the subject line.  Maybe, if it isn't a lot of work to find them, the
> dependent packages are in the body of the message.
> 
> Subscription is voluntary, so if someone likes surprises, they don't
> subscribe.  But everybody sends their soname changes to the list,
> subscribed or not.

I don't want to be notified about any random so-name bump. That'd be
mostly noise. But I *do* want to be notified about the ones that
matter for packages that I maintain. So, the right solution imho is
to write to fedora-devel and include the relevant maintainers in cc.

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Daniel P . Berrangé]

On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
> On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
> > mistake that caused files to go missing, and was never detected by the 
> > person
> > making the change, because of the use of globs. So I agree it is good 
> > practice
> > to explicitly list files without globs whereever it is practical todo so. 
> > I'd
> > make an exception for files which don't have functional impact eg don't list
> > 1000 HTML files individually, but it is always worth listing everything in
> > /usr/bin, and /usr/lib(64) explicitly without globs.
> 
> I used to agree with this, but I've come around to thinking that spec
> files should be smaller, less complicated, and more automatable. I
> think we'd be better having a post-build test warning that this package
> has files missing from the previous build. That could be advisory, or
> it could even gate, with the packager clearing the gate by updating the
> file list in the test, rather than in the spec file.

The further down the workflow a problem is detected the more time expensive
/ disruptive it is to fix it. So while having post-build tests to validate
lots of things is great (and I wish we had more of it in Fedora), I see it
as complementary to anything that we can do to detect problems earlier. I
rather see failures right away when I test the new RPM build locally, than
waiting to push it through koji and wait again for post-build tests to find
the problem, as by that time I've context switched my mind away to a
different bit of work.

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Daniel P . Berrangé]

On Wed, Feb 28, 2018 at 12:49:09PM -0600, Richard Shaw wrote:
> On Wed, Feb 28, 2018 at 12:38 PM, Daniel P. Berrangé 
> wrote:
> 
> > On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
> > > On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
> > > > mistake that caused files to go missing, and was never detected by the
> > person
> > > > making the change, because of the use of globs. So I agree it is good
> > practice
> > > > to explicitly list files without globs whereever it is practical todo
> > so. I'd
> > > > make an exception for files which don't have functional impact eg
> > don't list
> > > > 1000 HTML files individually, but it is always worth listing
> > everything in
> > > > /usr/bin, and /usr/lib(64) explicitly without globs.
> > >
> > > I used to agree with this, but I've come around to thinking that spec
> > > files should be smaller, less complicated, and more automatable. I
> > > think we'd be better having a post-build test warning that this package
> > > has files missing from the previous build. That could be advisory, or
> > > it could even gate, with the packager clearing the gate by updating the
> > > file list in the test, rather than in the spec file.
> >
> > The further down the workflow a problem is detected the more time expensive
> > / disruptive it is to fix it. So while having post-build tests to validate
> > lots of things is great (and I wish we had more of it in Fedora), I see it
> > as complementary to anything that we can do to detect problems earlier. I
> > rather see failures right away when I test the new RPM build locally, than
> > waiting to push it through koji and wait again for post-build tests to find
> > the problem, as by that time I've context switched my mind away to a
> > different bit of work.
> 
> 
> I don't have the infra experience to implement, but what about adding
> adding a pkgdiff option to fedpkg where it would complete a scratch build
> (--srpm if necessary) and then run pkgdiff against it and the current
> packages in the repository and putting the report somewhere accessible?

My typical scenario is to use a combination of "fedpkg local"
and "fedpkg scratch-build". So if there's a way to run tests on
the results of either or both of those, that could be a useful
thing.

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Simo Sorce]

On Wed, 2018-02-28 at 13:12 -0500, Matthew Miller wrote:
> On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
> > mistake that caused files to go missing, and was never detected by the 
> > person
> > making the change, because of the use of globs. So I agree it is good 
> > practice
> > to explicitly list files without globs whereever it is practical todo so. 
> > I'd
> > make an exception for files which don't have functional impact eg don't list
> > 1000 HTML files individually, but it is always worth listing everything in
> > /usr/bin, and /usr/lib(64) explicitly without globs.
> 
> I used to agree with this, but I've come around to thinking that spec
> files should be smaller, less complicated, and more automatable. I
> think we'd be better having a post-build test warning that this package
> has files missing from the previous build. That could be advisory, or
> it could even gate, with the packager clearing the gate by updating the
> file list in the test, rather than in the spec file.

If you still have to keep a list, why is it better to keep it in tests
?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Zbigniew Jędrzejewski-Szmek]

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

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

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


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

= Followups =

#topic #1846 F28 approved Changes not in MODIFIED status (considered as not 
testable) 
.fesco 1846
https://pagure.io/fesco/issue/1846

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

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

= New business =

self contained changes:

#topic #1856 F29 Self Contained Change: FedoraScientific VagrantBox
.fesco 1856
https://pagure.io/fesco/issue/1856

#topic #1854 F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark
.fesco 1854
https://pagure.io/fesco/issue/1854

#topic #1852 F29 Self Contained Change: No more automagic Python bytecompilation
.fesco 1852
https://pagure.io/fesco/issue/1852

#topic #1851 F29 System Wide Change: Remove GCC from BuildRoot
.fesco 1851
https://pagure.io/fesco/issue/1851

#topic #1850 F29 Self Contained Change: True Noarch Erlang Packages
.fesco 1850
https://pagure.io/fesco/issue/1850

#topic #1855 F29 Self Contained Change: BINUTILS 2.30
.fesco 1855
https://pagure.io/fesco/issue/1855

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

other topics:

#topic #1848 Request to Authorize Removal of Blender Source Tarballs from 
Incorrect Place in Repository
.fesco 1848
https://pagure.io/fesco/issue/1848

#topic #1843 FAS bot account sponsoring
.fesco 1843
https://pagure.io/fesco/issue/1843

#topic The time of the next meeting.
Fesco members, please respond to the whenisgood poll!

= Open Floor = 

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

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

Re: march VFAD for the atomic working group

[chicago]

Hi Dusty,

I'm very excited for atomic workstation. 

Sincerely, 

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 02/28/2018 01:38 PM, Daniel P. Berrangé wrote:
> On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
>> On Wed, Feb 28, 2018 at 05:57:53PM +, Daniel P. Berrangé wrote:
>>> mistake that caused files to go missing, and was never detected by the 
>>> person
>>> making the change, because of the use of globs. So I agree it is good 
>>> practice
>>> to explicitly list files without globs whereever it is practical todo so. 
>>> I'd
>>> make an exception for files which don't have functional impact eg don't list
>>> 1000 HTML files individually, but it is always worth listing everything in
>>> /usr/bin, and /usr/lib(64) explicitly without globs.
>>
>> I used to agree with this, but I've come around to thinking that spec
>> files should be smaller, less complicated, and more automatable. I
>> think we'd be better having a post-build test warning that this package
>> has files missing from the previous build. That could be advisory, or
>> it could even gate, with the packager clearing the gate by updating the
>> file list in the test, rather than in the spec file.
> 
> The further down the workflow a problem is detected the more time expensive
> / disruptive it is to fix it. So while having post-build tests to validate
> lots of things is great (and I wish we had more of it in Fedora), I see it
> as complementary to anything that we can do to detect problems earlier. I
> rather see failures right away when I test the new RPM build locally, than
> waiting to push it through koji and wait again for post-build tests to find
> the problem, as by that time I've context switched my mind away to a
> different bit of work.

Agree with this. We need to have something that is automated and also happens as
soon as possible. Gating rawhide should give us the ability to do something 
like this
and enforce it (i.e. making sure rebuilt dependent packages get pushed along 
with
the package that introduced the soname bump). I know this isn't clearly black 
and
white (i.e. oftentimes it's more than just a rebuild, and requires code 
changes) but
should give us a good start.

Dusty 
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqXTJsACgkQMwLb1zlS
5nFCUBAAuh+tHA9yIm6W8Ge4KMLahDzypb64/pXFZ4FkOcQf0TO6KpAhzXtvI+jj
/zLdZqOsfttjtSCYdOTSrjaTg9HX7g1v8r3KnpmqX1OKMDF83kZc+RiUHULnuCPR
OUv8yQ3fFc+yTlSeW3UScJ+xbnZnB/pZp9TFilDC7Ny33qs7pnzzp71QgguIUtp2
XlQm07aY7iZz0JqajQRnXWAhRJGYVPA9MR29SXU9a7LJ0HMrBpgRCQruiCaWozpz
LclhVV9sMGVeKs5yuxroI1t2DSBkjrl6umlvklMEtx22SpKFo8xWNoAScEWR8zXY
W1F2dY5Kxdv6Y4N1ACj3g/m+xziTqsy/acnDkqoK7Afpj51J0poZnIuwKk/SReft
a3nPJSSMrowxMn9+ZZVpuonvK0L3D+ACmJkPSI6arCmPWaXJqcBn2IcRUOV5Ok49
VL6Kl6AP7UdDQkW06T5Ub1wjjK4yjRiWVoNxrqp0y24wFzMi/NVUwelZlKbs6jjR
AbPE9ucNnYWrqqAQMHXjPC7Q+I64sfdkUmVadLqp3mAz0VToeRsJEdhq6ZMyk65h
eYz4prhfAL7mbxmAhQNdOnihALcftOE9MOxOGL3MF3Il5WQAGkqqXwbVUW9Ryg40
NqoVzQtQjGif2O3oRFFKlR5vLpvntzOkISB+gQV/lIs1bhYKW8I=
=1cnG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Test gating enabled in Bodhi

[mcatanzaro]

I have an update here:

https://bodhi.fedoraproject.org/updates/epiphany-3.26.6-1.fc27

that is blocked due to some harmless translation-related warnings from 
desktop-file-validate. I'm not the translation police and do not plan 
to make any changes to the desktop file.


* Who can help unblock this update? waiverdb looks too hard for me.
* Who can fix this so that it does not cause update failures in the 
future?


Thanks,

Michael

 {
"module" : "DesktopLint",
"order" : 93,
"results" : [
   {
  "arch" : "armv7hl,i686,x86_64",
  "code" : "DesktopFileValidation",
  "context" : {
 "path" : 
"/usr/share/applications/org.gnome.Epiphany.desktop"

  },
  "diag" : "warning: value \"???-???\" for key 
\"Comment[ru]\" in group \"Desktop Entry\" looks redundant with value 
\"???-???\" of key \"Name[ru]\"",

  "subpackage" : "epiphany"
   },
   {
  "arch" : "armv7hl,i686,x86_64",
  "code" : "DesktopFileValidation",
  "context" : {
 "path" : 
"/usr/share/applications/org.gnome.Epiphany.desktop"

  },
  "diag" : "warning: value \" ???\" for key 
\"Comment[tg]\" in group \"Desktop Entry\" looks redundant with value 
\" ???\" of key \"GenericName[tg]\"",

  "subpackage" : "epiphany"
   },
   {
  "arch" : "armv7hl,i686,x86_64",
  "code" : "DesktopFileValidation",
  "context" : {
 "path" : 
"/usr/share/applications/org.gnome.Epiphany.desktop"

  },
  "diag" : "warning: value \"Veb brauzer\" for key 
\"Comment[uz]\" in group \"Desktop Entry\" looks redundant with value 
\"Veb brauzer\" of key \"GenericName[uz]\"",

  "subpackage" : "epiphany"
   },
   {
  "arch" : "armv7hl,i686,x86_64",
  "code" : "DesktopFileValidation",
  "context" : {
 "path" : 
"/usr/share/applications/org.gnome.Epiphany.desktop"

  },
  "diag" : "warning: value \"??? ???\" for key 
\"Comment[uz@cyrillic]\" in group \"Desktop Entry\" looks redundant 
with value \"??? ???\" of key \"Name[uz@cyrillic]\"",

  "subpackage" : "epiphany"
   }
],
"run_time" : 0,
"status" : "completed"
 }
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Orcan Ogetbil]

On 28 February 2018 at 10:03, Nicolas Mailhot wrote:
> Le 2018-02-28 15:28, Orcan Ogetbil a écrit :
>>
>> On 28 February 2018 at 09:19, Nicolas Mailhot wrote:
>
>
>> These are all _very_ edge use-cases.
>
>
> Those are *not* edge-cases.

We have a few thousand build failures. If you cannot find as many (or
at least in the same magnitude) such use case examples these will stay
as edge cases.

Please start counting.

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

Open Seats on the Fedora Packaging Committee

[James Antill]

 The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.

 The FPC would like to thank Ralf Corsepius, Dominik 'Rathann'
Mierzejewski, and Thomas Spura for their service.

 This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.

 Currently the FPC meets on IRC weekly, on alternate
Wednesdays/Thursdays based around 12:00 EST, for approximately an
hour. 
 However that is likely to change back to a single day/time slot, and
the time would depend on when is good for all the members (East Coast
US and German TZs, at least).

 FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if quorum (5)
is not present. Candidates who are interested should provide the
following details to the FPC for consideration, by emailing it directly
to me (james(a)fedoraproject.org).

 The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. We will accept
applications for the next two weeks (deadline Wednesday, 2018-03-14).

 Name:
 FAS Account:
 Provenpackager? (Yes/No):
 Main area of packaging interest/expertise:
 Reason(s) for wanting to join the FPC:


 Thanks in advance,
  ~James
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Frequently broken Rawhide/Branched composes (was: Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21))

[Kevin Kofler]

Fabio Valentini wrote:
> AFAICT, those "broken deps in rawhide" mails are only sent if there is a
> compose, and during the past weeks, there have been few of those ... so
> breakage is sometimes allowed to sit unnoticed (and grow increasingly
> worse) for very long.

Isn't that the real issue to fix? Failed Rawhide composes used to be a rare 
event. Now we have both Rawhide and Branched composes broken for days at a 
time, e.g., currently since February 20. This is just not acceptable.

Something needs to be done to make the compose process more robust, e.g.:
* running createrepo on a stable release, so that we do not have to be able
  to init a chroot of the target system to compose a repository. A broken
  dependency, even in systemd or rpm, should NEVER be a reason for the
  repository to fail to compose.
* publishing individual deliverables one at a time, i.e.:
  1. compose the repositories,
  2. sync the repositories out to the mirrors,
  3. build the images (atomic ostrees, live images etc.) one at a time,
  4. sync those images that succeeded out to the mirrors, keep the old
 versions of the other ones (the matching SRPMs are in Koji anyway, so
 it does not matter if the SRPMs in the tree don't match)
etc.

Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide and 
Branched trees (which miscompiles the Chromium/QtWebEngine build tool GN on 
x86_64), the fix (8.0.1-0.16) has already been in the right Koji tags for 
days, but any third-party repository (RPM Fusion, Copr, etc.) will still get 
the broken GCC. This is not acceptable.

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

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

[Orcan Ogetbil]

On 28 February 2018 at 11:37, Björn Persson wrote:
> Orcan Ogetbil  wrote:
>> Shouldn't we consider having -devel packages Require gcc or gcc-c++?
>> What good is a header package without a compiler anyway?
>> This would also (indirectly) pull in the compiler and fix most of
>> these failed builds.
>
> Do you mean that maintainers should add those dependencies manually?
> How much less manual work would that be compared to adding build-time
> dependencies?
>
> Or do you mean that RPMbuild should automatically add "gcc" as a
> dependency to every subpackage whose name ends with "-devel"? That would
> be no help at all for Ada, C++, Fortran, Go or Objective C, which need
> gcc-gnat, gcc-c++, gcc-gfortran, gcc-go and gcc-objc, respectively. It
> would be plainly wrong for Pascal for example, according to the
> dependencies of the package fpc which requires binutils but not gcc.
>
> Or do you mean that RPMbuild should automatically detect which
> programming languages are present in each -devel subpackage, and add
> dependencies accordingly?
>
> Björn Persson
>


Hi Bjorn, thank you for the brainstorm.

Of course the last option would be ideal. However I don't think we
have the tools to collect the necessary information (it would indeed
be useful information), maybe we could concentrate on adding
capability to collect such statistics to the builder.

What I meant was the first option (from experience). How much less
manual work would that be? Well, add the requires to some top level
devel files, e.g. glibc-devel, zlib-devel, libxcb-devel,
alsa-lib-devel etc; and a decent amount of the build failures above
will clear. Then one can deal with the remaining
libraries/applications, again starting from the top level ones. I am
guessing all related build failures will clear after no more than a
few hundred added requires, compared to thousands of BuildRequires.

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

Re: Test gating enabled in Bodhi

[Randy Barlow]

On 02/28/2018 07:05 PM, mcatanz...@gnome.org wrote:
> I have an update here:
> 
> https://bodhi.fedoraproject.org/updates/epiphany-3.26.6-1.fc27
> 
> that is blocked due to some harmless translation-related warnings from
> desktop-file-validate.

It does not appear to be blocked currently.



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

Schedule for Thursday's FPC Meeting (2018-03-01 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-03-01 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2018-03-01 09:00
PST  US/Pacific
2018-03-01 12:00 EST  -->
US/Eastern <--
2018-03-01 17:00 GMT  Europe/London 
2018-
03-01 17:00 UTC  UTC   
2018-03-01 18:00
CET  Europe/Berlin 
2018-03-01 18:00 CET  Europe/Paris  
2018-03-01 22:30 IST  Asia/Calcutta 
 New Day:
Friday -
2018-03-02 01:00 HKT  Asia/Hong_Kong
201
8-03-02 01:00 +08  Asia/Singapore
2018-03-02 02:00
JST  Asia/Tokyo
2018-03-02 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #694 Packaging guidelines for application independence 
.fpc 694
https://pagure.io/packaging-committee/issue/694

#topic #702 C/C++ guidelines should say using clang needs an exception
.fpc 702
https://pagure.io/packaging-committee/issue/702

#topic #708 Allocating a static uid and gid for openvswitch
.fpc 708
https://pagure.io/packaging-committee/issue/708

#topic #710 Ruby packaging guidelines update
.fpc 710
https://pagure.io/packaging-committee/issue/710

#topic #713 Forward-looking conditionals by default
.fpc 713
https://pagure.io/packaging-committee/issue/713

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #715 Separately building package documentation
.fpc 715
https://pagure.io/packaging-committee/issue/715

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #723 Guidelines for handling deprecated dependencies during
review 
.fpc 723
https://pagure.io/packaging-committee/issue/723

#topic #726 Review for SELinux Independent Policy packaging Draft   
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #743 Add link to C/C++ build flag documentation in redhat-rpm-
config
.fpc 743
https://pagure.io/packaging-committee/issue/743

#topic #751 Packaging:Guidelines#Noarch_with_Unported... is outdated
.fp
c 751
https://pagure.io/packaging-committee/issue/751

= New business =

#topic #752 metainfodir change breaks builds with appdata on F27 
.fpc 752
https://pagure.io/packaging-committee/issue/752

#topic #753 python2-... should not be packaged when it's not needed 
.fpc 753
https://pagure.io/packaging-committee/issue/753


= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

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

Open Seats on the Fedora Packaging Committee

[James Antill]

 The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.

 The FPC would like to thank Ralf Corsepius, Dominik 'Rathann'
Mierzejewski, and Thomas Spura for their service.

 This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.

 Currently the FPC meets on IRC weekly, on alternate
Wednesdays/Thursdays based around 12:00 EST, for approximately an
hour. 
 However that is likely to change back to a single day/time slot, and
the time would depend on when is good for all the members (East Coast
US and German TZs, at least).

 FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if quorum (5)
is not present. Candidates who are interested should provide the
following details to the FPC for consideration, by emailing it directly
to me (james(a)fedoraproject.org).

 The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. We will accept
applications for the next two weeks (deadline Wednesday, 2018-03-14).

 Name:
 FAS Account:
 Provenpackager? (Yes/No):
 Main area of packaging interest/expertise:
 Reason(s) for wanting to join the FPC:


 Thanks in advance,
  ~James
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Pierre-Yves Chibon]

On Wed, Feb 28, 2018 at 12:32:19PM +0100, Ralf Corsepius wrote:
> On 02/28/2018 12:21 PM, Vít Ondruch wrote:
> > 
> > 
> > Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):
> > > On 02/27/2018 07:27 PM, Richard Shaw wrote:
> > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> > > > > wrote:
> > > > 
> > > > 
> > > >      Once again, folks, *please* announce your soname bumps, and
> > > > co-ordinate
> > > >      rebuilds. (In fact it looks like Zdenek is the maintainer of both
> > > >      packages and could have rebuilt cups-filters, but just forgot to).
> > > > 
> > > > 
> > > > Is it time to update the packaging guidelines to enforce setting a
> > > > "%global sover " and using it in %files?
> > > > 
> > > > If nothing else it should at least be documented as a best practice.
> > > 
> > > I would be very opposed to this.
> > > 
> > > Even though some folks want rawhide to appear a release, rawhide is
> > > not a release. So SONAME breakages are expected to happen in rawhide
> > > and maintainers supposed to be reacted upon.
> > 
> > Yes, if they notice!
> They - rsp. the maintainers of dependent packages - (usually) will notice
> very soon, because they'll receive an email notifying them about the
> breakage.

We're supposed to work together on this, not by putting work on each's other
plate without worrying about the consequences.
So if you put work on my plate I would at least like that:
a) you know about it
b) you let me know, possibly in advance so I can plan for this work

This suggestions to the guideline definitely will make a) true, b) is of course
up to you but since there is a), not doing b) will be entirely on you instead of
slipping in un-noticed, giving you the excuse that "you did not know".


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

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

[Orcan Ogetbil]

On 28 February 2018 at 09:19, Nicolas Mailhot wrote:
> My point was *non-C-compilers* can read *C/C++* header files because they
> need to read the ABI definitions to use it from their non C/C++ code.
>
> That makes a C/C++ header file consumable by pretty much any kind of
> compiler, so it's *completely useless* to try to make C/C++ devel packages
> pull in a compiler, via virtual provides or not.

Hello,

These are all _very_ edge use-cases. The primary use is to build the
software. Hence pulling in a compiler will not be quite harmful; it is
certainly not *completely useless*.
On the other hand it will clear up vast majority of the build
failures. I was trying to come up with the least intrusive solution.

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

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

[Ralf Corsepius]

On 02/28/2018 11:28 AM, Rafal Luzynski wrote:

28.02.2018 09:33 Nicolas Mailhot  wrote:


Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :


Shouldn't we consider having -devel packages Require gcc or gcc-c++?
What good is a header package without a compiler anyway?
This would also (indirectly) pull in the compiler and fix most of
these failed builds.



gcc is not the only compiler that reads header files


Also, do the header files actually *require* gcc to be present?


No. C headers never require *GCC*. Packages wanting to use them need an 
arbitrary C compiler.


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

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

[Panu Matilainen]

On 02/28/2018 04:28 PM, Orcan Ogetbil wrote:

On 28 February 2018 at 09:19, Nicolas Mailhot wrote:

My point was *non-C-compilers* can read *C/C++* header files because they
need to read the ABI definitions to use it from their non C/C++ code.

That makes a C/C++ header file consumable by pretty much any kind of
compiler, so it's *completely useless* to try to make C/C++ devel packages
pull in a compiler, via virtual provides or not.


Hello,

These are all _very_ edge use-cases. The primary use is to build the
software. Hence pulling in a compiler will not be quite harmful; it is
certainly not *completely useless*.
On the other hand it will clear up vast majority of the build
failures. I was trying to come up with the least intrusive solution.


The headers don't *require* any damn thing, except perhaps other headers 
(from other -devel packages). They are generally *used by* C/C++ 
compilers, but there are all sorts of other users (including humans just 
looking at it) too as has been pointed out.


Point being, "used by" and "requires" are two very different kind of 
dependencies.


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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Jared K. Smith]

On Wed, Feb 28, 2018 at 7:46 AM, Kevin Kofler 
wrote:

> The requirement to announce soname bumps to begin with is unreasonable
> bureaucracy in the first place. If your package shows up in the broken
> dependency report, you rebuild it and move on, where is the problem?
>

I'm going to respectfully disagree here.  Strong and resilient communities
learn to communicate well, and this communication helps to avoid problems,
conflicts, and resentment.  Even if we didn't have this rule, it would be
common courtesy to announce any change that causes others to have to do
work, even if it's only for a few users.

I'll paraphrase a mantra that I learned from Greg DeKoenigsberg, which says
that "In communities, it's okay to be disappointed, but it's not okay to be
surprised."  I personally feel that we'd be a stronger community if we all
focused a bit more on the principle of "least surprise".

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

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

[Orcan Ogetbil]

On 28 February 2018 at 05:28, Rafal Luzynski  wrote:
> 28.02.2018 09:33 Nicolas Mailhot wrote:
>>
>> Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :
>> >
>> > Shouldn't we consider having -devel packages Require gcc or gcc-c++?
>> > What good is a header package without a compiler anyway?
>> > This would also (indirectly) pull in the compiler and fix most of
>> > these failed builds.
>> >
>>
>> gcc is not the only compiler that reads header files
>
> Also, do the header files actually *require* gcc to be present?
> I know it makes sense to have both installed but there are potential
> use cases where a user may need only the devel packages but not gcc:
>
> - abrt may need devel packages to generate readable stack traces,
> - a user may use a different compiler than gcc (e.g., compat-gcc-34).

Hi,
All of these use cases can be handled by some virtual provides. My
suggestion didn't intend to be specific to gcc. I guess I should have
said something like Requires: .

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Vít Ondruch]

Dne 28.2.2018 v 13:46 Kevin Kofler napsal(a):
> Richard Shaw wrote:
>> Unannounced soname bumps are a pain :)
> The requirement to announce soname bumps to begin with is unreasonable 
> bureaucracy in the first place. If your package shows up in the broken 
> dependency report, you rebuild it and move on, where is the problem?

You ignore the fact, that the rebuild might not be possible, since the
ABI break is typically associated with API break. The SONAME bump should
be announced in advance to avoid these kind surprises.

Vít

>
> I can see the point of the requirement for something like OpenSSL that half 
> of the distro depends on, but not for any random library with a handful 
> users.
>
> 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

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

[Nicolas Mailhot]

My point was *non-C-compilers* can read *C/C++* header files because 
they need to read the ABI definitions to use it from their non C/C++ 
code.


That makes a C/C++ header file consumable by pretty much any kind of 
compiler, so it's *completely useless* to try to make C/C++ devel 
packages pull in a compiler, via virtual provides or not.


Only the packager knows the compiler he intends to use to consume the 
devel packages of other projects.


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

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

[Susi Lehtola]

On 02/18/2018 07:09 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt


jussilehtola IQmol OpenMesh PyQuante QMsgBox QsLog agedu cppcheck 
dd_rescue ddrescue epson-inkjet-printer-escpr epstool ergo gle gsl 
libint multitail octave packmol pcc potrace


I've taken care of all of these.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Nicolas Mailhot]

Le 2018-02-28 15:28, Orcan Ogetbil a écrit :

On 28 February 2018 at 09:19, Nicolas Mailhot wrote:



These are all _very_ edge use-cases.


Those are *not* edge-cases.

Most system libraries are written in C/C++ so pretty much all the 
language toolchains we ship (except for toy languages not intended to 
produce complex apps) will read C/C++ header files from their compilers 
to use those system libraries, and will BuildRequires the corresponding 
C/C++  package to do so.


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

Re: News in net-snmp package

[Josef Ridky]

Hi thanks a lot for your review.

| On Tue, 2018-02-27 at 09:02 -0500, Josef Ridky wrote:
| > Hi folks,
| > 
| > I would like to inform you, that net-snmp package will use Python3 package
| > instead of Python2.
| > With this change, python2-net-snmp package will be renamed to
| > python3-net-snmp package.
| > This change will be applied in Fedora Rawhide and Fedora 28.
| > 
| > I would be glad for any feedback.
| 
| This sounds a bit odd. What do you mean by 'renamed', exactly? It's not
| as if you can just have python3-net-snmp provide and obsolete python2-
| net-snmp ; any dependency which actually needs the python2 one is not
| going to keep working with this change.
| 
| Do you just mean the python2-net-snmp package will go away and anything
| using it has to migrate to python3-net-snmp? If so, have you actually
| looked at the things that use it and considered how difficult it will
| be to migrate them?

Yes, python2-net-snmp will no longer be delivered and anyone, that want to use 
it as dependency, have to use Python3.
Right now, I didn't find any package (based on dnf repoquery), that require 
python2-net-snmp package, so this change should be harmless.

| 
| I see, for instance, '389-ds-base-owner' CCed on this mail; if 389-ds-
| base depends on python2-net-snmp it is not at all going to be
| acceptable to just throw it away without regards to whether 389-ds-base
| can reasonably migrate to python3 right now. That is a core component
| of one of our release-blocking deliverables, Fedora Server.

This package depends on net-snmp-devel, not python2-net-snmp. Anyway 
389-ds-base package already use Python3, so even this change shouldn't cause 
any inconveniences.
Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Vít Ondruch]

Dne 18.2.2018 v 18:09 Igor Gnatenko napsal(a):
>
> List of packages and respective maintainers:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
>

xchat-ruby was retired.

ruby and rubygem-bcrypt are fixed (at least in git).

Vít



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

packmol license change

[Susi Lehtola]

Hi,


I've updated packmol to version 18.013. This carries a license change 
from GPLv2+ to MIT. No other packages are affected, since packmol is 
executable only.

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Nicolas Mailhot]

Le 2018-02-28 16:03, Nicolas Mailhot a écrit :


Most system libraries are written in C/C++ so pretty much all the
language toolchains we ship (except for toy languages not intended to
produce complex apps) will read C/C++ header files from their
compilers to use those system libraries, and will BuildRequires the
corresponding C/C++  package to do so.


the corresponding C/C++ -devel package that is

Even forgetting about clang a C/C++ -devel package is *not* used solely 
to build C/C++ code with a C/C++ compiler.


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

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

[Nicolas Mailhot]

Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :
> 
> Shouldn't we consider having -devel packages Require gcc or gcc-c++?
> What good is a header package without a compiler anyway?
> This would also (indirectly) pull in the compiler and fix most of
> these failed builds.
> 

gcc is not the only compiler that reads header files

Regards,

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

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

[Vít Ondruch]

Can the logs actually contain timestamps with timezone?

And was the compose successful today or not. Looking at

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log

it probably was, but it is not obvious from the log.



Vít



Dne 16.2.2018 v 21:14 Adam Williamson napsal(a):
> On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote:
>> I wish the compose process was more transparent. May be it is just me,
>> but I don't know where to start looking when I don't get the daily
>> compose report.
> https://kojipkgs.fedoraproject.org/compose/
>
> All composes initially happen there. Rawhide composes happen in the
> rawhide/ subdirectory. Branched happen in the branched/ subdirectory.
> Each compose directory contains logs. The usual process for debugging
> failed composes is to look at the pungi.global.log file, which usually
> indicates what the failed fatal task was, get the task ID or full task
> URL from that log, then go to Koji and look at the actual failed task
> and figure out what went wrong with it.
>
>> And the compose report email does pretty bad job explaining where the
>> information comes from etc.
> The compose reports are generated by https://pagure.io/compose-utils ,
> which is called by the scripts that actually run the composes, which
> live in https://pagure.io/pungi-fedora , along with (most of) the
> Fedora-specific compose configuration bits.
> https://pagure.io/pungi-fedora/blob/master/f/nightly.sh is the script
> that runs the Rawhide composes. Branched composes are run by the copy
> of the same script on the appropriately-numbered branch. (Personally I
> hate these scripts and the branching system, FWIW, and would much
> prefer to rewrite them entirely, but Mohan has said he's going to work
> on that and it's more his job than it is mine, so I'm deferring to him
> on that one).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Lubomír Sedlář]

Vít Ondruch píše v St 28. 02. 2018 v 10:35 +0100:
> Can the logs actually contain timestamps with timezone?

There's a timezone offset at the beginning of the log:

2018-02-28 00:33:30 [INFO] Current timezone offset: +00:00

> And was the compose successful today or not. Looking at
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201
> 80228.n.0/logs/global/pungi.global.log
> 
> it probably was, but it is not obvious from the log.

It did not actually finish, the status is still STARTED:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180
228.n.0/STATUS

If the compose is successful, the log will say so explicitly:

2018-02-27 20:46:57 [INFO] Compose finished:
/mnt/koji/compose/updates/Fedora-Epel-7-updates-testing-20180227.1

Even on failure there should be indication:

2018-02-27 14:34:22 [CRITICAL] Compose failed:
/mnt/koji/compose/rawhide/Fedora-Rawhide-20180227.n.0

Lubomír
> 
> Vít
> 
> 
> 
> Dne 16.2.2018 v 21:14 Adam Williamson napsal(a):
> > On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote:
> > > I wish the compose process was more transparent. May be it is
> > > just me,
> > > but I don't know where to start looking when I don't get the
> > > daily
> > > compose report.
> > 
> > https://kojipkgs.fedoraproject.org/compose/
> > 
> > All composes initially happen there. Rawhide composes happen in the
> > rawhide/ subdirectory. Branched happen in the branched/
> > subdirectory.
> > Each compose directory contains logs. The usual process for
> > debugging
> > failed composes is to look at the pungi.global.log file, which
> > usually
> > indicates what the failed fatal task was, get the task ID or full
> > task
> > URL from that log, then go to Koji and look at the actual failed
> > task
> > and figure out what went wrong with it.
> > 
> > > And the compose report email does pretty bad job explaining where
> > > the
> > > information comes from etc.
> > 
> > The compose reports are generated by https://pagure.io/compose-util
> > s ,
> > which is called by the scripts that actually run the composes,
> > which
> > live in https://pagure.io/pungi-fedora , along with (most of) the
> > Fedora-specific compose configuration bits.
> > https://pagure.io/pungi-fedora/blob/master/f/nightly.sh is the
> > script
> > that runs the Rawhide composes. Branched composes are run by the
> > copy
> > of the same script on the appropriately-numbered branch.
> > (Personally I
> > hate these scripts and the branching system, FWIW, and would much
> > prefer to rewrite them entirely, but Mohan has said he's going to
> > work
> > on that and it's more his job than it is mine, so I'm deferring to
> > him
> > on that one).
> 
> ___
> 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: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 12:21 PM, Vít Ondruch wrote:



Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):

On 02/27/2018 07:27 PM, Richard Shaw wrote:

On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> wrote:


     Once again, folks, *please* announce your soname bumps, and
co-ordinate
     rebuilds. (In fact it looks like Zdenek is the maintainer of both
     packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a
"%global sover " and using it in %files?

If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is
not a release. So SONAME breakages are expected to happen in rawhide
and maintainers supposed to be reacted upon.


Yes, if they notice!
They - rsp. the maintainers of dependent packages - (usually) will 
notice very soon, because they'll receive an email notifying them about 
the breakage.


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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Fabio Valentini]

On Feb 28, 2018 12:35, "Ralf Corsepius"  wrote:

On 02/28/2018 12:21 PM, Vít Ondruch wrote:

>
>
> Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):
>
>> On 02/27/2018 07:27 PM, Richard Shaw wrote:
>>
>>> On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
>>> > wrote:
>>>
>>>
>>>  Once again, folks, *please* announce your soname bumps, and
>>> co-ordinate
>>>  rebuilds. (In fact it looks like Zdenek is the maintainer of both
>>>  packages and could have rebuilt cups-filters, but just forgot to).
>>>
>>>
>>> Is it time to update the packaging guidelines to enforce setting a
>>> "%global sover " and using it in %files?
>>>
>>> If nothing else it should at least be documented as a best practice.
>>>
>>
>> I would be very opposed to this.
>>
>> Even though some folks want rawhide to appear a release, rawhide is
>> not a release. So SONAME breakages are expected to happen in rawhide
>> and maintainers supposed to be reacted upon.
>>
>
> Yes, if they notice!
>
They - rsp. the maintainers of dependent packages - (usually) will notice
very soon, because they'll receive an email notifying them about the
breakage.



AFAICT, those "broken deps in rawhide" mails are only sent if there is a
compose, and during the past weeks, there have been few of those ... so
breakage is sometimes allowed to sit unnoticed (and grow increasingly
worse) for very long.

This is why I would be strongly in favor of adding something like
"Packagers MUST NOT use globs in %files lists that cover up sonames of
shared libraries in %{_libdir}" to the Packaging Guidelines.

Fabio



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

[Sérgio Basto]

On Wed, 2018-02-28 at 16:51 +0100, Vít Ondruch wrote:
> 
> Dne 18.2.2018 v 18:09 Igor Gnatenko napsal(a):
> > 
> > List of packages and respective maintainers:
> > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
> > 

Igor, you will fix my packages isn't it ? 

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

march VFAD for the atomic working group

[Dusty Mabe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

https://pagure.io/atomic-wg/issue/429

In the Atomic working group in Fedora we have occasionally used virtual
Fedora Activity Days (VFADs) to get the community together to discuss 
in a high bandwidth setting (video conference) some techical issues we're
having or some direction of where we're going. 

We have scheduled a VFAD for next Friday (march 9th). We'd like to get
some input on some topics to discuss during this VFAD. Please discuss
and add topics to the ticket.

It would be preferable if we keep discussion in one place so please add
responses to the ticket.

Thanks!
Atomic Working Group
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqW4BkACgkQMwLb1zlS
5nFk+g/+MInPWyUZcBt1ZmBHgPxkyaaE3vDkNIB2upt4nzABVmiOQIFvijnPie37
pN6jRhTChCSFxgDD2NIklNvoJN9CEwSWogD/IFHsr3Ty2p2+5RDHDHaGQVNsEn0a
nD9Ye6E05C0A/iQ3QFbTS+Fin4go+P5Z/ZekCrnaC+6VE12MNf6L1v3y3hXplepo
HuYVf9nfrQr+pw4m/4E1zcWDbxWkDVWv3l76HsVMMzCevgWoj/I6/GGzl0oIgnfy
oMmw9wgpWst72EKMP5bTEpLl1VfG6UU0MVquv4sWpoP3eM7zSjXbwZ1DFuf3gWHS
R4yjWN9vk+haRbyDnfLDZ6/a1hvqXd91rGA9XSNaMVSpSx2ePjBPAj9zO/i4b9ZI
0/04NM3A4ru0jxzDljZmHSolkPh3qmNK9TYFF1Vl3c0ukOAjE1g3JoGHeHCbpyp9
uks1ImatgkhWduV3OyrtpblmxUfZLbn2GxkGKZIavK7z9sN8mStI6Ids4WYMO2PC
Z8k5TYge9lQpUOUQYOSQEEiCxtzuwEJGAzWI7JMW6hECO7xd6XFCqPcrYDChgkAr
PIHJH9/puurhLUmP/3MUpx3nK1V6g26mgs5oeYwYdu7SmSz9RvrlhH5lihWO6njM
6J9A0Pwh8pSgmymXnrBtYZAIgFGmH8ZCuRdgkLDTeJ+GD4aiWy4=
=1Vdx
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Dennis Gilmore]

El mié, 28-02-2018 a las 10:35 +0100, Vít Ondruch escribió:
> Can the logs actually contain timestamps with timezone?
> 
> And was the compose successful today or not. Looking at
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201
> 80228.n.0/logs/global/pungi.global.log
> 
> it probably was, but it is not obvious from the log.
> 
the status of the compose can always be found in the STATUS file of the
root of the compose https://kojipkgs.fedoraproject.org/compose/rawhide/
Fedora-Rawhide-20180228.n.0/STATUS is todays for instance

Dennis

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[stan]

On Wed, 28 Feb 2018 08:04:41 -0500
"Jared K. Smith"  wrote:

> ... Even if we didn't have
> this rule, it would be common courtesy to announce any change that
> causes others to have to do work, even if it's only for a few users.

What about an email list called fedora-soname-bump.  If you are going
to do a soname bump, you send an email to that list with the library in
the subject line.  Maybe, if it isn't a lot of work to find them, the
dependent packages are in the body of the message.

Subscription is voluntary, so if someone likes surprises, they don't
subscribe.  But everybody sends their soname changes to the list,
subscribed or not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Dennis Gilmore]

El mié, 28-02-2018 a las 12:32 +0100, Ralf Corsepius escribió:
> On 02/28/2018 12:21 PM, Vít Ondruch wrote:
> > 
> > 
> > Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):
> > > On 02/27/2018 07:27 PM, Richard Shaw wrote:
> > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> > > > 
> > > > > wrote:
> > > > 
> > > > 
> > > >  Once again, folks, *please* announce your soname bumps,
> > > > and
> > > > co-ordinate
> > > >  rebuilds. (In fact it looks like Zdenek is the maintainer
> > > > of both
> > > >  packages and could have rebuilt cups-filters, but just
> > > > forgot to).
> > > > 
> > > > 
> > > > Is it time to update the packaging guidelines to enforce
> > > > setting a
> > > > "%global sover " and using it in %files?
> > > > 
> > > > If nothing else it should at least be documented as a best
> > > > practice.
> > > 
> > > I would be very opposed to this.
> > > 
> > > Even though some folks want rawhide to appear a release, rawhide
> > > is
> > > not a release. So SONAME breakages are expected to happen in
> > > rawhide
> > > and maintainers supposed to be reacted upon.
> > 
> > Yes, if they notice!
> 
> They - rsp. the maintainers of dependent packages - (usually) will 
> notice very soon, because they'll receive an email notifying them
> about 
> the breakage.

Actually they will not receive any such email currently, the tool that
sends the emails has had sending email turned off because it does not
understand rich and boolean dependencies and was creating a lot of
noise. Announcing is the polite thing to do. It can also help a
maintainer get help, or allow someone to raise concerns. some soname
bumps are handled in side tags because we know that the ABI will break
or a very large amount of packages will be affected. I would like us to
figure out how to deal with soname breakages in a more automated way.
It however needs people to write new tooling to be able to cope with
it, I currently do not have enough cycles to take on doing the work. 
So if someone wants a project to do please come and talk to me about
it.

Dennis



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

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

[Björn Persson]

Orcan Ogetbil  wrote:
> Shouldn't we consider having -devel packages Require gcc or gcc-c++?
> What good is a header package without a compiler anyway?
> This would also (indirectly) pull in the compiler and fix most of
> these failed builds.

Do you mean that maintainers should add those dependencies manually?
How much less manual work would that be compared to adding build-time
dependencies?

Or do you mean that RPMbuild should automatically add "gcc" as a
dependency to every subpackage whose name ends with "-devel"? That would
be no help at all for Ada, C++, Fortran, Go or Objective C, which need
gcc-gnat, gcc-c++, gcc-gfortran, gcc-go and gcc-objc, respectively. It
would be plainly wrong for Pascal for example, according to the
dependencies of the package fpc which requires binutils but not gcc.

Or do you mean that RPMbuild should automatically detect which
programming languages are present in each -devel subpackage, and add
dependencies accordingly?

Björn Persson


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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Adam Williamson]

On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote:
> On 02/27/2018 07:27 PM, Richard Shaw wrote:
> > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson 
> > > wrote:
> > 
> > 
> > Once again, folks, *please* announce your soname bumps, and co-ordinate
> > rebuilds. (In fact it looks like Zdenek is the maintainer of both
> > packages and could have rebuilt cups-filters, but just forgot to).
> > 
> > 
> > Is it time to update the packaging guidelines to enforce setting a 
> > "%global sover " and using it in %files?
> > 
> > If nothing else it should at least be documented as a best practice.
> 
> I would be very opposed to this.
> 
> Even though some folks want rawhide to appear a release, rawhide is not 
> a release. So SONAME breakages are expected to happen in rawhide and 
> maintainers supposed to be reacted upon.

This is not true and I have *specifically* pointed you at the policy
page which says it is not true, more than once.

https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

For updates to rawhide packages, Maintainers SHOULD:

Try not to push a clearly broken build (breaks the default
buildroot package set, etc)
When a proposed update contains an ABI or API change: notify a week
in advance both fedora-devel and maintainers directly (using the
packagename-owner@ alias) whose packages depend on yours to rebuild or
offer to do these rebuilds for them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: News in net-snmp package

[Tomasz Kłoczko]

On 27 February 2018 at 14:02, Josef Ridky  wrote:
> Hi folks,
>
> I would like to inform you, that net-snmp package will use Python3 package 
> instead of Python2.
> With this change, python2-net-snmp package will be renamed to 
> python3-net-snmp package.
> This change will be applied in Fedora Rawhide and Fedora 28.
>
> I would be glad for any feedback.

The last %changelog entry:

* Tue Feb 27 2018 Josef Ridky  - 1:5.7.3-35
- compile against Python3
- add gcc requirement
- remove rm buildroot

And below is preamble of the devel subpackage:

%package devel
Summary:  The development environment for the NET-SNMP project
Requires: %{name}-libs%{?_isa} = %{epoch}:%{version}-%{release}
Requires: %{name}-agent-libs%{?_isa} = %{epoch}:%{version}-%{release}
Requires: elfutils-devel, rpm-devel, elfutils-libelf-devel, openssl-devel
%ifnarch s390 s390x ppc64le
Requires: lm_sensors-devel
%endif
# pull perl development libraries, net-snmp agent libraries may link to them
Requires: perl-devel%{?_isa}, gcc

Comments:
1) on top of not used elfutils-devel, rpm-devel,
elfutils-libelf-devel, lm_sensors-devel and perl-devel Requires now is
added gcc (??? why?)

All those Requires should be removed (only openssl-devel should be left).
net-snmp libraries are linked with elfutils, rpm, elfutils-libelf and
lm_sensors libraries but id does not mean that any package which is
using net-snmp client libraries will need any of those packages during
compile or linking (look my PR below).

2) perl subpackage has redundant BuildRequires:

BuildRequires: perl-interpreter

# dnf -qC repoquery --whatrequires perl-interpreter | grep perl-devel
mod_perl-devel-0:2.0.10-6.fc27.x86_64
perl-devel-4:5.26.1-408.fc28.i686
perl-devel-4:5.26.1-408.fc28.x86_64

It was easy to lose this redundant BR as now all BRs are not in one place.

3) pie patch is no longer needed as -pie is now part of the default
linker options injected by /usr/lib/rpm/redhat/redhat-hardened-ld

$ cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}} < *here*

*link:
+ -z now

As you see here is as well "-z now" so adding to LDFLAGS in spec
"-Wl,-z,now" is redundant as well (look on my PR)
As pie patch will be removed it is possible to simplify %prep using
%autosetup (look below PR)

4) there are many smaller cleanups rejected as part of the
https://src.fedoraproject.org/rpms/net-snmp/pull-request/2 (list is
really long) like using in .gz suffix in man pages %files entries
which are still not included (for unknown reasons).
For example, adding -D_RPM_4_4_COMPAT to CFLAGS is only generating
from more than 2-3 years a lot of warnings about redefinition this
define.

From the last net-snmp build log:

$ curl --silent
https://kojipkgs.fedoraproject.org//packages/net-snmp/5.7.3/35.fc28/data/logs/x86_64/build.log
| grep -c 'warning: "_RPM_4_4_COMPAT" redefined'
357

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Kevin Fenzi]

On 02/27/2018 06:06 PM, Adam Williamson wrote:
> On Tue, 2018-02-27 at 19:41 -0600, Richard Shaw wrote:
>> On Tue, Feb 27, 2018 at 6:47 PM, Kevin Kofler 
>> wrote:
>>
>>> Richard Shaw wrote:
 Is it time to update the packaging guidelines to enforce setting a
 "%global sover " and using it in %files?

 If nothing else it should at least be documented as a best practice.
>>>
>>> Not yet another bureaucratic guideline making it harder to maintain
>>> packages!
>>>
>>> Hardcoded soversions in specfiles are a pain!
>>
>>
>> Unannounced soname bumps are a pain :)
> 
> Right. It's not "bureaucratic" if it's a specific response to a real
> problem that keeps happening. That's more or less the *opposite* of
> bureaucratic.

I don't think we need to "force" (how do we do that?) not using globs in
file lists on libraries. If you maintain some package and have other
ways of noticing the soname change, great. (inspection, local testing,
abicheck runs, etc). Personally, I think it's a good idea and best
practice to not use globs there so you can't help but notice, but that
seems to me a workflow detail.

On the other hand we do need to get people to be proactive here.
Being reactive is just not good enough. By that I mean you can't just
break something and expect other people to clean it all up for you when
you do, as a good community member it's up to you to inform people about
the impending breakage and how you plan to fix dependent packages,
ideally so they all rebuild the same day and cause no breakage to the
repo/composes/users.

In addtion to the updates policy Adam quoted downthread there is also:

https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages

It's just good community to communicate changes like these and try and
minimize their impact.

kevin



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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Daniel P . Berrangé]

On Wed, Feb 28, 2018 at 09:51:49AM -0800, Kevin Fenzi wrote:
> On 02/27/2018 06:06 PM, Adam Williamson wrote:
> > On Tue, 2018-02-27 at 19:41 -0600, Richard Shaw wrote:
> >> On Tue, Feb 27, 2018 at 6:47 PM, Kevin Kofler 
> >> wrote:
> >>
> >>> Richard Shaw wrote:
>  Is it time to update the packaging guidelines to enforce setting a
>  "%global sover " and using it in %files?
> 
>  If nothing else it should at least be documented as a best practice.
> >>>
> >>> Not yet another bureaucratic guideline making it harder to maintain
> >>> packages!
> >>>
> >>> Hardcoded soversions in specfiles are a pain!
> >>
> >>
> >> Unannounced soname bumps are a pain :)
> > 
> > Right. It's not "bureaucratic" if it's a specific response to a real
> > problem that keeps happening. That's more or less the *opposite* of
> > bureaucratic.
> 
> I don't think we need to "force" (how do we do that?) not using globs in
> file lists on libraries. If you maintain some package and have other
> ways of noticing the soname change, great. (inspection, local testing,
> abicheck runs, etc). Personally, I think it's a good idea and best
> practice to not use globs there so you can't help but notice, but that
> seems to me a workflow detail.

I've seen plenty of cases in the past where RPMs have silently had a build
mistake that caused files to go missing, and was never detected by the person
making the change, because of the use of globs. So I agree it is good practice
to explicitly list files without globs whereever it is practical todo so. I'd
make an exception for files which don't have functional impact eg don't list
1000 HTML files individually, but it is always worth listing everything in
/usr/bin, and /usr/lib(64) explicitly without globs.

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

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

[Bruno Wolff III]

On Wed, Feb 28, 2018 at 10:35:11 +0100,
 Vít Ondruch <vondr...@redhat.com> wrote:


And was the compose successful today or not. Looking at

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log

it probably was, but it is not obvious from the log.


Depending on why you care, it may be useful to know that in most cases when 
it fails a lot still gets done. Typically you can use the repos from 
failed composes to do updates if you want. This might be easier than pulling 
updates from koji, especially if you can about multiple packages.

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

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

[Vít Ondruch]

Dne 28.2.2018 v 10:52 Lubomír Sedlář napsal(a):
> Vít Ondruch píše v St 28. 02. 2018 v 10:35 +0100:
>> Can the logs actually contain timestamps with timezone?
> There's a timezone offset at the beginning of the log:
>
> 2018-02-28 00:33:30 [INFO] Current timezone offset: +00:00

A bit hard to find if you don't know. Thx

>
>> And was the compose successful today or not. Looking at
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201
>> 80228.n.0/logs/global/pungi.global.log
>>
>> it probably was, but it is not obvious from the log.
> It did not actually finish, the status is still STARTED:
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180
> 228.n.0/STATUS

Ah, ok. Thx for explanation.


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

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

[Rafal Luzynski]

28.02.2018 09:33 Nicolas Mailhot  wrote:
>
> Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :
> >
> > Shouldn't we consider having -devel packages Require gcc or gcc-c++?
> > What good is a header package without a compiler anyway?
> > This would also (indirectly) pull in the compiler and fix most of
> > these failed builds.
> >
>
> gcc is not the only compiler that reads header files

Also, do the header files actually *require* gcc to be present?
I know it makes sense to have both installed but there are potential
use cases where a user may need only the devel packages but not gcc:

- abrt may need devel packages to generate readable stack traces,
- a user may use a different compiler than gcc (e.g., compat-gcc-34).

Regards,

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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Zdenek Dohnal]

Hi,

I'm deeply sorry, I thought cups-filters will be rebuilt with new qpdf
during next mass rebuild - I forgot about 'rawhide is alpha' policy so
dependent packages need to be rebuild immediately with rebased package.

Again, I'm deeply sorry and thank you Adam and Rex for fixing it!


On 02/27/2018 07:16 PM, Adam Williamson wrote:
> qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26.
> This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 .
> This soname bump was not announced, as it is supposed to be, and
> dependent packages were not rebuilt.
>
> cups-filters depends on qpdf, so anything that includes cups-filters is
> now broken. This includes at least the Astronomy_KDE live image, per
> https://pagure.io/dusty/failed-composes/issue/24#comment-496381 .
>
> Once again, folks, *please* announce your soname bumps, and co-ordinate 
> rebuilds. (In fact it looks like Zdenek is the maintainer of both
> packages and could have rebuilt cups-filters, but just forgot to).
>
> I will attempt a rebuild of cups-filters using provenpackager
> privileges.

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




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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/27/2018 07:27 PM, Richard Shaw wrote:
On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson 
> wrote:



Once again, folks, *please* announce your soname bumps, and co-ordinate
rebuilds. (In fact it looks like Zdenek is the maintainer of both
packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a 
"%global sover " and using it in %files?


If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is not 
a release. So SONAME breakages are expected to happen in rawhide and 
maintainers supposed to be reacted upon.


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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 02:41 AM, Richard Shaw wrote:
On Tue, Feb 27, 2018 at 6:47 PM, Kevin Kofler > wrote:


Richard Shaw wrote:
> Is it time to update the packaging guidelines to enforce setting a
> "%global sover " and using it in %files?
>
> If nothing else it should at least be documented as a best practice.

Not yet another bureaucratic guideline making it harder to maintain
packages!

Hardcoded soversions in specfiles are a pain!


Unannounced soname bumps are a pain :)


SONAME bumps are "daily business" in rawhide and should be reacted upon 
in timely manners.


Whether they are announced or not actually, actually doesn't make much 
difference.


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

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Vít Ondruch]

Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):
> On 02/27/2018 07:27 PM, Richard Shaw wrote:
>> On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
>> > wrote:
>>
>>
>>     Once again, folks, *please* announce your soname bumps, and
>> co-ordinate
>>     rebuilds. (In fact it looks like Zdenek is the maintainer of both
>>     packages and could have rebuilt cups-filters, but just forgot to).
>>
>>
>> Is it time to update the packaging guidelines to enforce setting a
>> "%global sover " and using it in %files?
>>
>> If nothing else it should at least be documented as a best practice.
>
> I would be very opposed to this.
>
> Even though some folks want rawhide to appear a release, rawhide is
> not a release. So SONAME breakages are expected to happen in rawhide
> and maintainers supposed to be reacted upon.

Yes, if they notice! That is the point to let the maintainers notice
that they are actually about to bump SONAME.

Vít


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

[Kevin Kofler]

Richard Shaw wrote:
> Unannounced soname bumps are a pain :)

The requirement to announce soname bumps to begin with is unreasonable 
bureaucracy in the first place. If your package shows up in the broken 
dependency report, you rebuild it and move on, where is the problem?

I can see the point of the requirement for something like OpenSSL that half 
of the distro depends on, but not for any random library with a handful 
users.

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

[389-devel] Please review: Issue 49584 - Fix issues with paged_results test suite

[Simon Pichugin]

Hi team,
please, review a small fix:

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

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

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

[Bug 1549556] perl-libwww-perl-6.33 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 960  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 850  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 821  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 432  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 161  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  52  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be69c94866   
clamav-0.99.3-8.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c8346d8e5   
mbedtls-2.7.0-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-76121890f9   
seamonkey-2.49.2-2.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6ac908eac8   
openjpeg2-2.3.0-6.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6


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

agedu-0-15.20171202.8a8299e.el6

Details about builds:



 agedu-0-15.20171202.8a8299e.el6 (FEDORA-EPEL-2018-fe89266f82)
 An utility for tracking down wasted disk space

Update Information:

Update to the newest snapshot.

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

[Bug 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-RT-Client-REST-0.51-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ff63a0451

-- 
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 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Test-Harness-3.41-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-675bf97721

-- 
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 1549884] perl-RDF-NS-20180227 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-RDF-NS-20180227-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9d85899558

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1087  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 850  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 432  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 329  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 161  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  98  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e50c94a832   
seamonkey-2.49.2-2.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-525417d3d4   
mbedtls-2.7.0-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3   
knot-resolver-2.1.0-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7a74678b1   
openjpeg2-2.3.0-6.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7


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

golang-github-golang-glog-0-0.17.gitfca8c88.el7
golang-github-golang-time-0-0.6.gitc06e80d.el7
golang-github-google-go-genproto-0-0.3.git411e09b.el7
golang-github-jtolds-gls-0-0.11.git9a4a02d.el7
golang-github-nsf-termbox-go-0-0.2.20171104gitaa4a75b.el7
golang-github-smartystreets-assertions-1.6.0-0.7.git287b434.el7
golang-github-stretchr-testify-1.1.4-0.2.git69483b4.el7
golang-googlecode-go-crypto-0-0.13.git81372b2.el7
golang-googlecode-goprotobuf-0-0.31.git24f28ae.el7
libp11-0.4.7-3.el7
py4j-0.10.6-4.el7
python-anyconfig-0.9.4-1.el7
python-molecule-2.7-1.el7
transtats-cli-0.1.2-1.el7

Details about builds:



 golang-github-golang-glog-0-0.17.gitfca8c88.el7 (FEDORA-EPEL-2018-627f85967c)
 Leveled execution logs for Go

Update Information:

Branch for epel7    Polish the spec file    Enable devel and unit-test
packages for epel7

References:

  [ 1 ] Bug #1249052 - Tracker for golang-github-golang-glog
https://bugzilla.redhat.com/show_bug.cgi?id=1249052




 golang-github-golang-time-0-0.6.gitc06e80d.el7 (FEDORA-EPEL-2018-fcb27b4367)
 Go supplementary time packages

Update Information:

Branch for epel7




 golang-github-google-go-genproto-0-0.3.git411e09b.el7 
(FEDORA-EPEL-2018-b053a27147)
 Go generated proto packages

Update Information:

Build for epel7




 golang-github-jtolds-gls-0-0.11.git9a4a02d.el7 (FEDORA-EPEL-2018-66aa36497e)
 Goroutine local storage

Update Information:

Update




 golang-github-nsf-termbox-go-0-0.2.20171104gitaa4a75b.el7 
(FEDORA-EPEL-2018-38d4e5706f)
 A minimalistic API which allows programmers to write text-based user interfaces

Update Information:

Branch for epel7




 golang-github-smartystreets-assertions-1.6.0-0.7.git287b434.el7 
(FEDORA-EPEL-2018-11a508a3a5)
 Fluent 

[Bug 1550305] New: perl-Net-FTPSSL-0.40 is available

[bugzilla]

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

Bug ID: 1550305
   Summary: perl-Net-FTPSSL-0.40 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-FTPSSL
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.40
Current version/release in rawhide: 0.39-2.fc28
URL: http://search.cpan.org/dist/Net-FTPSSL/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/10542/

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

Open Seats on the Fedora Packaging Committee

[James Antill]

 The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.

 The FPC would like to thank Ralf Corsepius, Dominik 'Rathann'
Mierzejewski, and Thomas Spura for their service.

 This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.

 Currently the FPC meets on IRC weekly, on alternate
Wednesdays/Thursdays based around 12:00 EST, for approximately an
hour. 
 However that is likely to change back to a single day/time slot, and
the time would depend on when is good for all the members (East Coast
US and German TZs, at least).

 FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if quorum (5)
is not present. Candidates who are interested should provide the
following details to the FPC for consideration, by emailing it directly
to me (james(a)fedoraproject.org).

 The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. We will accept
applications for the next two weeks (deadline Wednesday, 2018-03-14).

 Name:
 FAS Account:
 Provenpackager? (Yes/No):
 Main area of packaging interest/expertise:
 Reason(s) for wanting to join the FPC:


 Thanks in advance,
  ~James
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

[Bug 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Test-Harness-3.41-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-675bf97721

-- 
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 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RT-Client-REST-0.51-1.
   ||fc29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Test-Harness-3.41-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cb24f9fcf

-- 
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 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-RT-Client-REST-0.51-1. |perl-RT-Client-REST-0.51-1.
   |fc29|fc28



-- 
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 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-RT-Client-REST-0.51-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ff63a0451

-- 
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 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-RT-Client-REST-0.51-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-43ecd9b72e

-- 
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 1549884] perl-RDF-NS-20180227 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RDF-NS-20180227-1.fc29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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 1550049] New: perl-DBD-SQLite-1.56 is available

[bugzilla]

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

Bug ID: 1550049
   Summary: perl-DBD-SQLite-1.56 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBD-SQLite
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org,
st...@silug.org, tcall...@redhat.com



Latest upstream release: 1.56
Current version/release in rawhide: 1.54-7.fc28
URL: http://search.cpan.org/dist/DBD-SQLite/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2810/

-- 
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 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-ExtUtils-CBuilder-0.28
   ||0230-3.fc29



--- Comment #9 from Petr Pisar  ---
There were no objections. The change is implemented in:

perl-ExtUtils-CBuilder-0.280230-3.fc29
perl-ExtUtils-MakeMaker-7.32-2.fc29
perl-Module-Build-0.42.24-6.fc29

I also removed a hard dependency on perl-devel from perl-ExtUtils-MakeMaker.

I also noticed that perl-Module-Install pulls in perl-devel and gcc
transitively. I will find out why.

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

[EPEL-devel] No meeting today. Next meeting 2018-03-??

[Stephen John Smoogen]

Due to conflicts and lack of planning on my part.. I am cancelling
today's meeting. Please send agenda items for next weeks meeting to
the list

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

[Bug 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Test-Harness-3.41-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cb24f9fcf

-- 
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 1550056] perl-RT-Client-REST-0.51 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-RT-Client-REST-0.51-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-43ecd9b72e

-- 
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 1549884] perl-RDF-NS-20180227 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-RDF-NS-20180227-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-11d26d0837

-- 
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 1549884] perl-RDF-NS-20180227 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-RDF-NS-20180227-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-11d26d0837

-- 
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 1549884] perl-RDF-NS-20180227 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-RDF-NS-20180227-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9d85899558

-- 
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 1550055] New: perl-Test-Harness-3.41 is available

[bugzilla]

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

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



Latest upstream release: 3.41
Current version/release in rawhide: 3.39-5.fc28
URL: http://search.cpan.org/dist/Test-Harness/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3394/

-- 
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 1550056] New: perl-RT-Client-REST-0.51 is available

[bugzilla]

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

Bug ID: 1550056
   Summary: perl-RT-Client-REST-0.51 is available
   Product: Fedora
   Version: rawhide
 Component: perl-RT-Client-REST
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.51
Current version/release in rawhide: 0.50-7.fc28
URL: http://search.cpan.org/dist/RT-Client-REST/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3307/

-- 
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 1544589] perl-SNMP-Info-3.47 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-SNMP-Info-3.46 is  |perl-SNMP-Info-3.47 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.47
Current version/release in rawhide: 3.43-1.fc28
URL: http://search.cpan.org/dist/SNMP-Info/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3318/

-- 
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 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-Harness-3.41-1.fc
   ||29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-Test-Harness-3.41-1.fc |perl-Test-Harness-3.41-1.fc
   |29  |28



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