Re: Removal of BuildRoot

On Friday, February 16, 2018 7:48:17 PM CET Tom Hughes wrote: > On 16/02/18 18:26, David Sommerseth wrote: > > > But my "worst" example was probably the openvpn package I'm now in charge > > for > > (and I am a core upstream developer for that project as well). But it > > didn't > > take that

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 06:48:17PM +, Tom Hughes wrote: > On 16/02/18 18:26, David Sommerseth wrote: > > > But my "worst" example was probably the openvpn package I'm now in charge > > for > > (and I am a core upstream developer for that project as well). But it > > didn't > > take that

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

Le 16/02/2018 à 15:18, Mark Wielaard a écrit : > I had to tweak it a little though so the spec could still be build > older RHEL or Fedora (I reuse the spec to build on RHEL and with SCL). > Maybe something like the following is better for people who have a spec > file they might reuse on systems

Re: RFC: BugURL in packages

On 02/16/2018 02:48 PM, Jason L Tibbitts III wrote: > Or you can just add this: > > config_opts['macros']['%bugurl'] = 'http://bugz.fedoraproject.org/%name' > > to the mock site-defaults.cfg on the builders. For some reason I > thought that we couldn't depend on %name to be stable in the case

[Bug 1546413] New: perl-Moose-2.2010 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1546413 Bug ID: 1546413 Summary: perl-Moose-2.2010 is available Product: Fedora Version: rawhide Component: perl-Moose Keywords: FutureFeature, Triaged Assignee:

[Bug 1546405] New: perl-ExtUtils-MakeMaker-7.32 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1546405 Bug ID: 1546405 Summary: perl-ExtUtils-MakeMaker-7.32 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged

Re: RFC: BugURL in packages

Or you can just add this: config_opts['macros']['%bugurl'] = 'http://bugz.fedoraproject.org/%name' to the mock site-defaults.cfg on the builders. For some reason I thought that we couldn't depend on %name to be stable in the case of subpackages but it appears to not matter. - J<

Re: RFC: BugURL in packages

So basically, koji has a list of macros (hardcoded in koji/__init__.py) which unfortunately carries the comment: #XXX - this needs to be configurable Those get turned into config_opts['macros']['%_foo']['whatever'] directives in the generated mock config. Some of those macros (%vendor,

Removal of sln

sln (staticly linked ‘ln’) was removed from glibc recently: https://bugzilla.redhat.com/show_bug.cgi?id=1531546 The explanation for this was: "The sln program is no longer useful, so we will not ship it anymore." and it was removed from Rawhide 3 days later. There are some %post scripts

Re: Orphaned Packages looking for a new point of contact

On 02/16/2018 01:40 PM, David Cantrell wrote: > On 02/16/2018 11:32 AM, Kevin Fenzi wrote: >> Greetings. >> >> There's some packages that have been orphaned by FESCo and are seeking a >> new point of contact to stay in the collection. >> >> If you are interested in becoming the point of contact

Re: RFC: BugURL in packages

> "KF" == Kevin Fenzi writes: KF> Does anyone have cycles to look into the best place to make this KF> change and how to get the override working on a per package basis? It appears that koji already forces several RPM tags: ; The vendor to use in rpm headers vendor=Fedora

Re: Orphaned Packages looking for a new point of contact

On 02/16/2018 11:32 AM, Kevin Fenzi wrote: > Greetings. > > There's some packages that have been orphaned by FESCo and are seeking a > new point of contact to stay in the collection. > > If you are interested in becoming the point of contact for these, please > note it in the appropriate ticket

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

> "RR" == Roberto Ragusa writes: RR> When I proposed this kind of optimization in some mailing list RR> (maybe this one?!), I was answered that my method was not entirely RR> safe because there could have been problems for some rpm scripts RR> calling libraries that

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

On 02/16/2018 12:02 PM, Adam Williamson wrote: > On Fri, 2018-02-16 at 09:54 +0100, nicolas.mail...@laposte.net wrote: ...snip... >> >> Right now rawhide has to be *very* broken for it to get any attention. > > No it does not. This is not true. Rawhide is tested every day and I > (and several

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

> "CW" == Colin Walters writes: CW> Meanwhile, there are probably hundreds of people on this -devel list CW> who are capable of debugging and fixing things - some very CW> experienced engineers, yet some of them are here busily debating CW> minor things about spec files.

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

On 02/16/2018 05:31 AM, Colin Walters wrote: > On Thu, Feb 15, 2018, at 5:39 PM, Adam Williamson wrote: > >> In practice it tends to boil down to "me, nirik, and puiterwijk". > > Meanwhile, there are probably hundreds of people on this -devel > list who are capable of debugging and fixing things

Re: Removal of BuildRoot

> "DS" == David Sommerseth writes: DS> False positives are also easily filtered out by adding .rpmlint to DS> the dist-git repository. Which is an absolutely terrible name for that. Really. Why would anyone at all ever think it is a good idea to _hide_ the file that

Re: Removal of BuildRoot

> "NG" == Neal Gompa writes: NG> As upstream for rpmlint, I do not believe anyone cares at all about NG> rpmlint in Fedora. We seemingly care so little for it that the rpmlint status appears on every bodhi update. I did spend some time trying to make rpmlint better ages

Re: Removal of BuildRoot

> "NK" == Nico Kadel-Garcia writes: NK> While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. epel-rpm-macros set up the default buildroot value for EPEL5 and thus rendered the BuildRoot: tag unnecessary well before that release went EOL. But even without that

Re: RFC: BugURL in packages

On 02/15/2018 03:29 AM, Miroslav Suchý wrote: > Can we have this defined by Mock/Koji/Copr and let package maintainers > override it (e.g., to point to upstream, the > Gnome is good example)? I think thats a pretty good compromise. Does anyone have cycles to look into the best place to make

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

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.

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

On Fri, 2018-02-16 at 08:31 -0500, Colin Walters wrote: > On Thu, Feb 15, 2018, at 5:39 PM, Adam Williamson wrote: > > > In practice it tends to boil down to "me, nirik, and puiterwijk". > > Meanwhile, there are probably hundreds of people on this -devel > list who are capable of debugging and

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

On Fri, 2018-02-16 at 07:21 -0500, Matthew Miller wrote: > On Thu, Feb 15, 2018 at 03:22:29PM -0800, Adam Williamson wrote: > > I mean...#fedora-releng ? This is kinda what release engineering *does* > > - they engineer releases. So if a release is not being engineered > > optimally, go ask

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

On Fri, 2018-02-16 at 09:54 +0100, nicolas.mail...@laposte.net wrote: > > - Mail original - > De: "Adam Williamson" > > Hi Adam > > > This is...pretty much what I do for every release, and have been doing > > since like Fedora 14 or something? > > You do it end of cycle, No I don't.

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

On Fri, 2018-02-16 at 09:49 +0100, nicolas.mail...@laposte.net wrote: > > It's all too easy right now for everyone to be busy with something > else just when things break, and sometimes the authority to tell > people "fix your builds you're blocking everyone" is needed (or even > the authority to

Re: Mass Rebuild for Fedora 28

On Fri, 2018-02-16 at 08:44 +, Tomasz Kłoczko wrote: > On 14 February 2018 at 14:09, Tomasz Kłoczko > wrote: > [..] > > > Looks like at the moment Fedora build infrastructure is using set of > > packages which is still not pushed to public repo. > > This particular

[Bug 1542721] Please provide a package for EPEL7

https://bugzilla.redhat.com/show_bug.cgi?id=1542721 --- Comment #14 from Robert-André Mauchin --- (In reply to Ralf Corsepius from comment #13) Hello, Thanks for adding me and eseyman to perl-Locale-Maketext-Lexicon but you forgot to do the same for perl-Text-Haml, which

[Bug 1546269] New: Please provide a package for EPEL7

https://bugzilla.redhat.com/show_bug.cgi?id=1546269 Bug ID: 1546269 Summary: Please provide a package for EPEL7 Product: Fedora Version: rawhide Component: perl-Data-Float Assignee: ppi...@redhat.com Reporter:

[Bug 1546268] New: Please provide a package for EPEL7

https://bugzilla.redhat.com/show_bug.cgi?id=1546268 Bug ID: 1546268 Summary: Please provide a package for EPEL7 Product: Fedora Version: rawhide Component: perl-HTTP-Lite Assignee: emman...@seyman.fr Reporter:

Re: Removal of BuildRoot

On 16/02/18 19:48, Tom Hughes wrote: > On 16/02/18 18:26, David Sommerseth wrote: > >> But my "worst" example was probably the openvpn package I'm now in charge for >> (and I am a core upstream developer for that project as well).  But it didn't >> take that much efforts to iron out most of those

Re: Removal of BuildRoot

On 16/02/18 18:26, David Sommerseth wrote: But my "worst" example was probably the openvpn package I'm now in charge for (and I am a core upstream developer for that project as well). But it didn't take that much efforts to iron out most of those issues. False positives are also easily

Re: F29 System Wide Change: Remove GCC from BuildRoot

On 16/02/18 15:53, Daniel P. Berrangé wrote: > On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: [...snip...] >> There is no simple way of doing this. Also as other thread mentioned, people >> hate automated changes... So for this one we need every single packager to >> fix >> their

Re: Removal of BuildRoot

On 16/02/18 17:21, Martin Kolman wrote: > On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote: [...snip...] >> As upstream for rpmlint, I do not believe anyone cares at all about >> rpmlint in Fedora. One more warning or error won't mean anything. From >> time to time, I have considered making a

Re: F29 System Wide Change: Remove GCC from BuildRoot

De: "Daniel P. Berrangé" >> ??? Other compilers such as golang can generate ELF binaries too. The world >> has moved on. > Yes, but that's likely a small % of overall and it is harmless if we > addd BR: gcc to a few packages which don't need it - they'll be no > worse off than they are today,

Re: F29 System Wide Change: Remove GCC from BuildRoot

On 2018-02-16, 17:38 GMT, Daniel P Berrangé wrote: > Yes, but that's likely a small % of overall and it is harmless > if we addd BR: gcc to a few packages which don't need it > - they'll be no worse off than they are today, and it can be > easily removed again. By “adding BR: gcc” you mean

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

The following Fedora EPEL 6 Security updates need testing: Age URL 948 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 838 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 809

Re: F29 System Wide Change: Remove GCC from BuildRoot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-02-16 at 14:47 +, Richard W.M. Jones wrote: > On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: > > There is no simple way of doing this. > > grepping build logs for \bgcc\b might catch many of them? True. Advise

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 06:33:02PM +0100, nicolas.mail...@laposte.net wrote: > De: "Daniel P. Berrangé" > > > I would think we can detect it easily enough by looking for packages which > > contain ELF binaries. Those are going to require GCC except in the rare > > case that it used clang, > >

Orphaned Packages looking for a new point of contact

Greetings. There's some packages that have been orphaned by FESCo and are seeking a new point of contact to stay in the collection. If you are interested in becoming the point of contact for these, please note it in the appropriate ticket below for quickest processing. (no need to reopen the

Orphaned Packages looking for a new point of contact

Greetings. There's some packages that have been orphaned by FESCo and are seeking a new point of contact to stay in the collection. If you are interested in becoming the point of contact for these, please note it in the appropriate ticket below for quickest processing. (no need to reopen the

Re: F29 System Wide Change: Remove GCC from BuildRoot

De: "Daniel P. Berrangé" > I would think we can detect it easily enough by looking for packages which > contain ELF binaries. Those are going to require GCC except in the rare > case that it used clang, ??? Other compilers such as golang can generate ELF binaries too. The world has moved on.

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

=== #fedora-meeting: FESCO (2018-02-16) === Meeting started by bowlofeggs at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2018-02-16/fesco.2018-02-16-15.00.log.html . Meeting

Re: Removal of BuildRoot

On 2018-02-16, 12:36 GMT, Tomasz Kłoczko wrote: > And this is why for example calling rpmlint should be one of > the pre steps done by koji on sending build request. It would > be good to perform at least one time a month rpmlint test > across all packages, and if it anything wrong

Re: Removal of BuildRoot

On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote: > On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely > wrote: > > On 15/02/18 11:10 -0500, David Cantrell wrote: > > > > > > On 02/15/2018 11:02 AM, Jonathan Wakely wrote: > > > > > > > > On 15/02/18 08:46 -0500,

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 05:01:33PM +0100, Vít Ondruch wrote: > > > Dne 16.2.2018 v 16:33 Daniel P. Berrangé napsal(a): > > On Fri, Feb 16, 2018 at 04:22:58PM +0100, Vít Ondruch wrote: > >> > >> Dne 16.2.2018 v 16:12 Vít Ondruch napsal(a): > >>> Dne 16.2.2018 v 15:27 Daniel P. Berrangé napsal(a):

libmodulemd: SOname bump coming to released Fedora

I'm going to be submitting an update for libmodulemd today for all released branches of Fedora. This is *technically* in conflict with the Stable Updates Policy, but it is both necessary and should be safe to accomplish. 1) The teams that were planning to switch to it from the previous

Re: F29 System Wide Change: Remove GCC from BuildRoot

Dne 16.2.2018 v 16:54 Richard W.M. Jones napsal(a): > On Fri, Feb 16, 2018 at 04:22:58PM +0100, Vít Ondruch wrote: >> $ dnf repoquery --disablerepo=* --enablerepo=rawhide --source >> --whatrequires 'libc.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq >> | wc -l >> 8559 > I think you're just

Re: F29 System Wide Change: Remove GCC from BuildRoot

Dne 16.2.2018 v 16:33 Daniel P. Berrangé napsal(a): > On Fri, Feb 16, 2018 at 04:22:58PM +0100, Vít Ondruch wrote: >> >> Dne 16.2.2018 v 16:12 Vít Ondruch napsal(a): >>> Dne 16.2.2018 v 15:27 Daniel P. Berrangé napsal(a): On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: >

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 04:22:58PM +0100, Vít Ondruch wrote: > $ dnf repoquery --disablerepo=* --enablerepo=rawhide --source > --whatrequires 'libc.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq > | wc -l > 8559 I think you're just measuring what packages contain binaries, rather than what

Re: Removal of BuildRoot

On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely wrote: > On 15/02/18 11:10 -0500, David Cantrell wrote: >> >> On 02/15/2018 11:02 AM, Jonathan Wakely wrote: >>> >>> On 15/02/18 08:46 -0500, David Cantrell wrote: First, I actually don't care if this change is

Re: Removal of BuildRoot

On 16 February 2018 at 03:14, Nico Kadel-Garcia wrote: > On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III > wrote: >>> "LT" == Luya Tshimbalanga writes: >> >> LT> When you get a chance, would you also update the spec

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

The following Fedora EPEL 7 Security updates need testing: Age URL 1075 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 837 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 420

Re: fedpkg request-repo always fails - Could not execute request_repo

SOLVED: has now worked after renewing the API token one more time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

On 02/16/2018 12:14 AM, Nico Kadel-Garcia wrote: > On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III > wrote: >>> "LT" == Luya Tshimbalanga writes: >> >> LT> When you get a chance, would you also update the spec guideline as >> LT> well? >> >>

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 04:22:58PM +0100, Vít Ondruch wrote: > > > Dne 16.2.2018 v 16:12 Vít Ondruch napsal(a): > > > > Dne 16.2.2018 v 15:27 Daniel P. Berrangé napsal(a): > >> On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > >>> Proposed System Wide Change: Remove GCC from BuildRoot

[Bug 1546139] perl-Time-HiRes-1.9754 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1546139 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In

Re: F29 System Wide Change: Remove GCC from BuildRoot

Dne 16.2.2018 v 16:12 Vít Ondruch napsal(a): > > Dne 16.2.2018 v 15:27 Daniel P. Berrangé napsal(a): >> On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: >>> Proposed System Wide Change: Remove GCC from BuildRoot >>> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot >>>

Re: F29 System Wide Change: Remove GCC from BuildRoot

Dne 16.2.2018 v 15:27 Daniel P. Berrangé napsal(a): > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: >> Proposed System Wide Change: Remove GCC from BuildRoot >> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot >> >> >> Owner(s): >> * Igor Gnatenko >> >> >>

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, 2018-02-16 at 15:41 +0100, Igor Gnatenko wrote: > On Fri, 2018-02-16 at 14:27 +, Daniel P. Berrangé wrote: > > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > > > Proposed System Wide Change: Remove GCC from BuildRoot > > >

Re: Changing config from a %post?

Dne 16.2.2018 v 15:35 Chris Adams napsal(a): > What's the proper way to fix this? I can update the package to create a > user and use it in the default config, but is it correct to have a %post > that changes the existing config (something like a "sed -i")? > > I'd also like to switch it from

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, 2018-02-16 at 14:27 +, Daniel P. Berrangé wrote: > > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > > > Proposed System Wide Change: Remove GCC from

Re: Schedule for Friday's FESCo Meeting (2018-02-16)

On 02/14/2018 05:36 PM, Randy Barlow wrote: > #topic #1842 Nonresponsive maintainer: devrim > .fesco 1842 > https://pagure.io/fesco/issue/1842 This one was resolved, so we will not discuss it in today's meeting. signature.asc Description: OpenPGP digital signature

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: > There is no simple way of doing this. grepping build logs for \bgcc\b might catch many of them? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog:

Re: F29 System Wide Change: Remove GCC from BuildRoot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-02-16 at 14:27 +, Daniel P. Berrangé wrote: > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > > Proposed System Wide Change: Remove GCC from BuildRoot > > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot

Re: F29 System Wide Change: Remove GCC from BuildRoot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-02-16 at 14:15 +, Richard W.M. Jones wrote: > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > > written in C/C++, they are written in Python, Ruby, Node.js, Go, Rust, > > OCaml, Perl and so on so they don't need to have

Changing config from a %post?

The imapproxy package config defaults to user "nobody", which should be changed (probably should have been done a while back, but whatever). The user is set in the config though, and the config has to be edited for the package to work (to at least set the upstream IMAP server), so changing the

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > Proposed System Wide Change: Remove GCC from BuildRoot > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot > > > Owner(s): > * Igor Gnatenko > > > Removing gcc and gcc-c++ from default buildroot in Koji and mock. >

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

Hi Igor, On Wed, 2018-02-14 at 21:59 +0100, Igor Gnatenko wrote: > Your options: > > * Speak up and tell package names I should not touch because … (you should > complete this sentence). > * Fix up packages and tell package names I should not touch because you did > that already. > * Tell

Re: F28 Self Contained Change: VA-API 1.0.0

2018-02-16 14:35 GMT+01:00 Zbigniew Jędrzejewski-Szmek : > On Fri, Feb 09, 2018 at 08:07:20AM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Mon, Jan 29, 2018 at 11:06:05PM +0100, Jan Kurik wrote: >> > = Proposed Self Contained Change: VA-API 1.0.0 = >> >

Re: F29 System Wide Change: Remove GCC from BuildRoot

On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > written in C/C++, they are written in Python, Ruby, Node.js, Go, Rust, > OCaml, Perl and so on so they don't need to have C/C++ compiler. OCaml is probably a bad example as it uses gcc as wrapper around gas and ld to perform the

Re: F29 Self Contained Change: No more automagic Python bytecompilation

On 16.2.2018 14:09, Tomasz Kłoczko wrote: On 16 February 2018 at 11:25, Jan Kurik > wrote: Proposed Self Contained Change: No more automagic Python bytecompilation

Re: RPM Lint Errors

Greg Hellings wrote: > I have a package that includes a group of Ansible playbooks embedded into a > Python module. The playbooks include a number of templates that are designed > to be > uploaded into remote systems, templated out with appropriate variables, and >

Re: Call for users of darkserver

On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote: > So what do you advice as course of action here, should we fix darkserver or > move > its functionality to ABRT? "move its functionality to ABRT" > The later is tempting to me if it's just a few lines of code added on an app > we

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

- Mail original - De: "Bruno Wolff III" > Automation of rebuilds of dependencies might be a better approach. This > won't be able to address all cases, but could save people's time which we > seem to be short of. I'm all for it! Some languages that are not careful about API breaks

libmodulemd: SOname bump coming to released Fedora

I'm going to be submitting an update for libmodulemd today for all released branches of Fedora. This is *technically* in conflict with the Stable Updates Policy, but it is both necessary and should be safe to accomplish. 1) The teams that were planning to switch to it from the previous

Re: Removal of BuildRoot

> I don't follow. How else (other than manual download) do you get your > sources other than by spectool? Surely if you download them manually > you would notice any URL change? You can have an old source copy in Sources (downloaded manually of by spectool) but by the time you finish QA and

Re: F28 Self Contained Change: VA-API 1.0.0

On Fri, Feb 09, 2018 at 08:07:20AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 29, 2018 at 11:06:05PM +0100, Jan Kurik wrote: > > = Proposed Self Contained Change: VA-API 1.0.0 = > > https://fedoraproject.org/wiki/Changes/VA-API_1.0.0 > > > > Change owner(s): > > * Nicolas Chauvet >

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

On Fri, Feb 16, 2018 at 09:49:11 +0100, nicolas.mail...@laposte.net wrote: It's all too easy right now for everyone to be busy with something else just when things break, and sometimes the authority to tell people "fix your builds you're blocking everyone" is needed (or even the authority to

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

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. And the compose report email does pretty bad job explaining where the information comes from etc. V. Dne 15.2.2018 v 23:34 Matthew Miller

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 12:11:12PM +, Tomasz Kłoczko wrote: >On 15 February 2018 at 09:17, Paul Howarth wrote: >[..] > > Same here. Whilst I don't mind this change, as it stands I'm getting no > notifications when the packages I maintain are changed by

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

On Thu, Feb 15, 2018, at 5:39 PM, Adam Williamson wrote: > In practice it tends to boil down to "me, nirik, and puiterwijk". Meanwhile, there are probably hundreds of people on this -devel list who are capable of debugging and fixing things - some very experienced engineers, yet some of them are

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 7:22 AM, Tom Hughes wrote: > On 16/02/18 13:13, Richard Shaw wrote: > > I think it would be better to have fedpkg run rpmlint on "fedpkg build". >> It can be informative only. At least then it would not require the >> maintainer to run rpmlint themselves.

Re: Removal of BuildRoot

On 16/02/18 13:13, Richard Shaw wrote: I think it would be better to have fedpkg run rpmlint on "fedpkg build". It can be informative only. At least then it would not require the maintainer to run rpmlint themselves. Please no. See above about ridiculous noise. One thing I started doing was

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 6:43 AM, Tom Hughes wrote: > On 16/02/18 12:36, Tomasz Kłoczko wrote: > >> On 16 February 2018 at 11:21, Panu Matilainen > > wrote: >> [..] >> >> Not everybody runs rpmlint for everything they produce,

Re: F29 Self Contained Change: No more automagic Python bytecompilation

On 16 February 2018 at 11:25, Jan Kurik wrote: > Proposed Self Contained Change: No more automagic Python bytecompilation > https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_ > bytecompilation > > > Owner(s): > * Miro Hrončok > * Petr Viktorin > > > The

Re: F29 System Wide Change: Remove GCC from BuildRoot

Love that. Thank you for pushing this forward! V. Dne 16.2.2018 v 12:56 Jan Kurik napsal(a): > Proposed System Wide Change: Remove GCC from BuildRoot > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot > > > Owner(s): > * Igor Gnatenko > > > Removing gcc and gcc-c++ from

Re: Removal of BuildRoot

On 16/02/18 12:36, Tomasz Kłoczko wrote: On 16 February 2018 at 11:21, Panu Matilainen > wrote: [..] Not everybody runs rpmlint for everything they produce, on the contrary I suspect it's fairly small percentage of packagers out

Re: Removal of BuildRoot

On 16 February 2018 at 11:21, Panu Matilainen wrote: [..] > Not everybody runs rpmlint for everything they produce, on the contrary I > suspect it's fairly small percentage of packagers out there that do. If rpm > itself doesn't directly complain about such things they'll

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 03:14:43AM -0500, Nico Kadel-Garcia wrote: > While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are > there any EPEL tools that are identical to the upstream Fedora > releases, that might still use any of htese for legacy environments? FWIW EPEL 5 systems

[Bug 1546139] New: perl-Time-HiRes-1.9754 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1546139 Bug ID: 1546139 Summary: perl-Time-HiRes-1.9754 is available Product: Fedora Version: rawhide Component: perl-Time-HiRes Keywords: FutureFeature, Triaged Assignee:

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

On Thu, Feb 15, 2018 at 03:22:29PM -0800, Adam Williamson wrote: > I mean...#fedora-releng ? This is kinda what release engineering *does* > - they engineer releases. So if a release is not being engineered > optimally, go ask release engineering. I guess I'm just not seeing what > all would

[Bug 1401482] biber-2.11 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1401482 Upstream Release Monitoring changed: What|Removed |Added

Re: Removal of BuildRoot

On 15 February 2018 at 09:17, Paul Howarth wrote: [..] > Same here. Whilst I don't mind this change, as it stands I'm getting no > notifications when the packages I maintain are changed by other people, > and that's supposed to be one of the safeguards against potential >

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

On 15/02/18 22:10 -0800, Kevin Fenzi wrote: On 02/15/2018 03:21 PM, Adam Williamson wrote: On Thu, 2018-02-15 at 18:05 -0500, Stephen John Smoogen wrote: You have been doing it but have you been wanting to do it or just doing it because no one else seems to do it when it is needed. Was it an

F29 System Wide Change: Remove GCC from BuildRoot

Proposed System Wide Change: Remove GCC from BuildRoot https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot Owner(s): * Igor Gnatenko Removing gcc and gcc-c++ from default buildroot in Koji and mock. == Detailed description == Since beginning of Fedora, gcc (and gcc-c++) are

Re: Removal of BuildRoot

On 16/02/18 09:14, Nico Kadel-Garcia wrote: > On Thu, Feb 15, 2018 at 7:44 PM, Jason L Tibbitts III > wrote: [...snip...] > While RHEL 5 is obsolete, that does not mean EPEL 5 is obsolete. Are > there any EPEL tools that are identical to the upstream Fedora > releases, that

F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark

Proposed Self Contained Change: Drop Legacy GTK+ GUI in wireshark https://fedoraproject.org/wiki/Changes/Drop_Legacy_GTK+_GUI_in_wireshark Owner(s): * Michal Ruprich == Detailed description == Since wireshark-2.0 there are two GUIs availble for use. One is based on GTK+ and the other on Qt.

F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark

Proposed Self Contained Change: Drop Legacy GTK+ GUI in wireshark https://fedoraproject.org/wiki/Changes/Drop_Legacy_GTK+_GUI_in_wireshark Owner(s): * Michal Ruprich == Detailed description == Since wireshark-2.0 there are two GUIs availble for use. One is based on GTK+ and the other on Qt.

F29 Self Contained Change: True Noarch Erlang Packages

Proposed Self Contained Change: True Noarch Erlang Packages https://fedoraproject.org/wiki/Changes/TrueNoarchErlangPackages Owner(s): * Randy Barlow Erlang packages are currently all installed into %{_libdir}/erlang/lib, despite most of them being noarch packages. This proposal is to modify

F29 Self Contained Change: No more automagic Python bytecompilation

Proposed Self Contained Change: No more automagic Python bytecompilation https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation Owner(s): * Miro Hrončok * Petr Viktorin The current way of automatic Python byte-compiling of files outside Python-specific

  1   2   >