Re: Removal of BuildRoot

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? > > Which spec guideline did you mean? If you were referring to the > packaging guidelines, they have said

Re: Removal of BuildRoot

On Wednesday, February 14, 2018 5:44:57 PM CET Remi Collet wrote: > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit : > > Just a small heads up, ... > > As I said on IRC > > - waste of time > - waste of energy > - absolutely no value > > And > > - abuse proven packager privileges Agreed, and it i

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

On 02/14/2018 10:14 PM, Matthew Miller wrote: > I'd be super-interested in benchmarks comparing before and after > install times. I guess since the plan is to do this _after_ the mass > rebuild, we'll need to wait until after the *next* rebuild to see how > much impact this has. Many years ago, I

Re: Mass Rebuild for Fedora 28

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 build fail looks like is caused by new version of > the xerces-c. > Will check this when new xerce

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

Hi, A manager per release (including rawhide) would be awesome (as long as some provision is made for holiday replacements). 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 blocki

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

- 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, and it is awe-inspiring to see you trying to fix all the problems that accumulated since the next-to-l

Re: Removal of BuildRoot

On 14 February 2018 at 16:44, Remi Collet wrote: > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit : > > Just a small heads up, ... > > > As I said on IRC > > - waste of time > - waste of energy > - absolutely no value > > And > > - abuse proven packager privileges > Cutting the tail of some legacy

Re: Removal of BuildRoot

On Fri, 16 Feb 2018 09:19:54 +0100 Pavel Raiskup wrote: > On Wednesday, February 14, 2018 5:44:57 PM CET Remi Collet wrote: > > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit : > > > Just a small heads up, ... > > > > As I said on IRC > > > > - waste of time > > - waste of energy > > - absolutely

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

On Thu, Feb 15, 2018 at 11:19:10PM +, Sérgio Basto wrote: > On Thu, 2018-02-15 at 16:39 -0600, Rex Dieter wrote: > > Matthew Miller wrote: > > > > > As shown at https://www.happyassassin.net/nightlies.html, we > > > haven't > > > had a successful compose for almost two weeks. AIUI this is most

Re: Call for users of darkserver

On Wed, Feb 14, 2018 at 06:13:53PM +0100, Jan Kratochvil wrote: > On Wed, 14 Feb 2018 11:02:52 +0100, Pierre-Yves Chibon wrote: > > If there is little interest for this project, we will likely decommission > > it in > > the coming weeks (say end of March). > > The darkserver project ws initiated

Re: Call for users of darkserver

On Wed, Feb 14, 2018 at 03:17:57PM -0500, Jason Callaway wrote: >I was unaware of it, but I think it looks pretty great! >OOC, is there an alternative service that one could use if this is >decommissioned? Or would we have to dig through Koji and Bodhi logs? >I'll bet the CHAOSS fol

fedpkg request-repo always fails - Could not execute request_repo

Hi, tried to create a new repo, but this fails always with: [martin@f27 ~]$ fedpkg --module-name gnome-shell-extension-netspeed request-repo 1377631 Could not execute request_repo: The following error occurred while creating a new issue in Pagure: Invalid or expired token. Please visit https://

Re: Removal of BuildRoot

On 02/15/2018 06:19 PM, 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 made or not.  My personal opinion is that it's a nice-to-ha

Re: Removal of BuildRoot

On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote: > Actually, inspired by this thread, rpm will start at least warning about > BuildRoot tag in the next release or so. > > The reason for silently ignoring all this time was to allow spec sharing > between old and new rpm versions, bu

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, and it is awe-

F29 Self Contained Change: BINUTILS 2.30

Proposed Self Contained Change: BINUTILS 2.30 https://fedoraproject.org/wiki/Changes/BINUTILS230 Owner(s): * Nick Clifton Rebase the binutils package from version 2.29 .1 to version 2.30. This will bring in bug-fixes and some new features. == Detailed description == Switch the binutils pa

F29 System Wide Change: Enable dbus-broker

Proposed System Wide Change: Enable dbus-broker https://fedoraproject.org/wiki/Changes/EnableDbusBroker Owner(s): * David Herrmann * Tom Gundersen Enable dbus-broker.service to use dbus-broker as system and session message bus backend. == Detailed description == The dbus-broker project

Re: Removal of BuildRoot

On 02/16/2018 12:54 PM, Michael Schroeder wrote: On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote: Actually, inspired by this thread, rpm will start at least warning about BuildRoot tag in the next release or so. The reason for silently ignoring all this time was to allow spec sh

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 directories

Re: Removal of BuildRoot

On Fri, 2018-02-16 at 13:21 +0200, Panu Matilainen wrote: > On 02/16/2018 12:54 PM, Michael Schroeder wrote: > > On Fri, Feb 16, 2018 at 12:41:18PM +0200, Panu Matilainen wrote: > > > Actually, inspired by this thread, rpm will start at least warning about > > > BuildRoot tag in the next release or

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

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 might still use any of

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 i

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 '

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 > errors by provenpackager

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 actual

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 chec

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 simply never get > clean

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 there that do. If rpm itsel

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 defau

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 current way of automati

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, on the >> contrary I suspect it's f

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 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. >> > > Please no.

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 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 other people, > a

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 na

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

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

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 de

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: 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 > then executed on the remote

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 https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation

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 assembly

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 = >> > https://fedoraproject.org/wiki/Changes/VA-

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 package

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

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 pack

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

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

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

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

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 run

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 > > > https://fedoraproject.org/wiki/Changes/Remove_GCC_

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

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

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

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? >> >> Which spec guideline did you mean? If you w

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 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 guideline as >> LT> well? >> >> Which spec guideline did you mean? I

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 made or not. My personal >

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 pa

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

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

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

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, David Cantrell wrote: > > > > >

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 automatically

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 summar

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

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 tick

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

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 taken

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 com

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

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 pr

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 p

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 filtere

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: 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 build fail looks like is ca

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: 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. I

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 release

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 fi

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

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 thi

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 it still doesn't ma

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 ago and kind of got

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 controls that? - J< _

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: 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. That's a false dicho

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 othe

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 had been just upgraded (e.

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 b

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 Project ; The pac

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 for

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 wh

  1   2   >