Re: Orphaning python-Lektor

[Sasa Savic]

On Wed, 2019-03-27 at 11:38 -0400, Charalampos Stratakis wrote:
> Not interested anymore in this package, feel free to reach me out if
> you'd like to take it, I'll orphan it this week.

I'm actively using Lektor so I'll take it off your shoulders gladly.
Thank you for your work on it. 

Br,
Saša
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Sérgio Basto]

Sorry , please discard my message, the user name was wrong here ... 

On Thu, 2019-03-28 at 02:55 +, Sérgio Basto wrote:
> On Wed, 2019-03-27 at 13:14 +, Martin Gansser wrote:
> > debug1: Next authentication method: publickey
> > debug1: Offering public key: /home/martin/.ssh/id_rsa RSA
> > SHA256:bHNp1Vhqsa4aRUMuVsXdBIALgvNzDzAriQKRvNxpQos agent
> > debug3: send packet: type 50
> > debug2: we sent a publickey packet, wait for reply
> > debug3: receive packet: type 51
> > debug1: Authentications that can continue: publickey
> 
> hum , seems you private key is not the same of F29 
> 
> because in a similar test on my F30 I got:
> 
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/sergio/.ssh/id_rsa RSA
> SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
> debug3: send packet: type 50
> debug2: we sent a publickey packet, wait for reply
> debug3: receive packet: type 60
> debug1: Server accepts key: /home/sergio/.ssh/id_rsa RSA
> SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
> debug3: sign_and_send_pubkey: RSA
> SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
> debug3: sign_and_send_pubkey: signing using rsa-sha2-256
> Enter passphrase for key '/home/sergio/.ssh/id_rsa': 
> debug3: send packet: type 50
> debug3: receive packet: type 52
> debug1: Authentication succeeded (publickey).
> Authenticated to pkgs.fedoraproject.org ([209.132.181.4]:22).
> 
> 
> 
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Sérgio Basto]

On Wed, 2019-03-27 at 13:14 +, Martin Gansser wrote:
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/martin/.ssh/id_rsa RSA
> SHA256:bHNp1Vhqsa4aRUMuVsXdBIALgvNzDzAriQKRvNxpQos agent
> debug3: send packet: type 50
> debug2: we sent a publickey packet, wait for reply
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey

hum , seems you private key is not the same of F29 

because in a similar test on my F30 I got:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/sergio/.ssh/id_rsa RSA
SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /home/sergio/.ssh/id_rsa RSA
SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
debug3: sign_and_send_pubkey: RSA
SHA256:W9KGO1pmTdzilJ2Df/+iTLT/Wp/jYETbP9Sw+6rS9Ug
debug3: sign_and_send_pubkey: signing using rsa-sha2-256
Enter passphrase for key '/home/sergio/.ssh/id_rsa': 
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to pkgs.fedoraproject.org ([209.132.181.4]:22).



-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: pkgconfig usage

[Richard Shaw]

On Wed, Mar 27, 2019 at 6:08 PM Luya Tshimbalanga 
wrote:

> Sightly related to the topic, is there an effective way to use
> pkgconfig(foo) for packages rather foo-devel?  It seems very few
> packages use that method.
>

I admit I'm usually too lazy to do this when -devel works. Most of my
packages are CMake based but even then many packages are found through the
pkg-config module.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned some Java packages

[Miro Hrončok]

On 05. 02. 19 11:07, Mikolaj Izdebski wrote:

I've just orphaned 259 packages listed below. Almost all of them are
Java packages which I will continue to maintain as part of modules.
Intent to orphan them was already announced on java-devel [1] and
devel [2] lists, with detailed reasoning.


Hi Mikolaj,

do you have some kind out outline about what packages are in what modules?

I took over google-gson, but I see no stream branch.

junit has javapackages branch 
https://src.fedoraproject.org/rpms/junit/commits/javapackages


Is this the branch you use to build a module?

A friend sent me a list of package they were able to find in a module by some 
dark magic. BTW what is the supported way to query this kind of information?


You say almost all of the 259 Java packages will be maintained as part of 
modules, yet it's hard for me to find the rest.


Thanks.

ant-antlr: ant
ant-apache-bcel: ant
ant-apache-bsf: ant
ant-apache-log4j: ant
ant-apache-oro: ant
ant-apache-regexp: ant
ant-apache-resolver: ant
ant-apache-xalan2: ant
ant-commons-logging: ant
ant-commons-net: ant
ant-javamail: ant
ant-jdepend: ant
ant-jmf: ant
ant-jsch: ant
ant-junit5: ant
ant-junit: ant
ant-lib: ant
ant-swing: ant
ant-testutil: ant
ant-xz: ant
ant: ant
antlr-C++-doc: ant
antlr-tool: ant
aopalliance: maven
apache-commons-cli: maven
apache-commons-codec: maven
apache-commons-io: maven
apache-commons-lang3: maven
apache-commons-logging: ant
apache-commons-logging: maven
apache-commons-net: ant
atinject: maven
bcel: ant
bsf: ant
cdi-api: maven
geronimo-annotation: maven
glassfish-el-api: maven
google-guice: maven
guava20: maven
hamcrest-core: ant
hawtjni-runtime: maven
hawtjni-runtime: scala
httpcomponents-client: maven
httpcomponents-core: maven
jakarta-oro: ant
jansi-native: maven
jansi-native: scala
jansi: maven
jansi: scala
javamail: ant
jboss-interceptors-1.2-api: maven
jcl-over-slf4j: maven
jdepend: ant
jline: scala
jsch: ant
jsoup: maven
junit5: ant
junit: ant
jzlib: ant
log4j12: ant
maven-lib: maven
maven-resolver-api: maven
maven-resolver-connector-basic: maven
maven-resolver-impl: maven
maven-resolver-spi: maven
maven-resolver-transport-wagon: maven
maven-resolver-util: maven
maven-shared-utils: maven
maven-wagon-file: maven
maven-wagon-http-shared: maven
maven-wagon-http: maven
maven-wagon-provider-api: maven
maven: maven
opentest4j: ant
plexus-cipher: maven
plexus-classworlds: maven
plexus-containers-component-annotations: maven
plexus-interpolation: maven
plexus-sec-dispatcher: maven
plexus-utils: maven
python2-antlr: ant
regexp: ant
scala-apidoc: scala
scala-swing: scala
scala: scala
sisu-inject: maven
sisu-plexus: maven
slf4j: maven
univocity-parsers: ant
xalan-j2: ant
xerces-j2: ant
xml-commons-apis: ant
xml-commons-resolver: ant
xz-java: ant

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

pkgconfig usage

[Luya Tshimbalanga]

On 2019-03-26 10:07 a.m., Georg Sauthoff wrote:
> Hello,
>
> when packaging a C/C++ program, the rpm automatic dependency feature
> usually works well for shared libraries.
>
> That mean when program 'bar' needs libfoo-devel at build time it's
> sufficient to add
>
> BuildRequires: libfoo-devel
>
> and I can omit
>
> Requires: libfoo
>
> because rpm automatically adds something like:
>
> libfoo.so.1()(64bit)
>
> Of course, I could still add a superfluous
>
> Requires: libfoo
>
> and then the resulting binary package would contain a redundant
> dependency like this:
>
> libfoo
> libfoo.so.1()(64bit)
>
> Has Fedora a policy against such redundant dependencies?
>
> Best regards
> Georg
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Sightly related to the topic, is there an effective way to use
pkgconfig(foo) for packages rather foo-devel?  It seems very few
packages use that method.


Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2019-03-28 16:00 UTC)

[James Antill]

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

 Local time information (via. uitime):

= Day: Thursday ==
2019-03-28 09:00 PDT  US/Pacific
2019-03-28 12:00 EDT  --> US/Eastern <--
2019-03-28 16:00 GMT  Europe/London 
2019-03-28 16:00 UTC  UTC   
2019-03-28 17:00 CET  Europe/Berlin 
2019-03-28 17:00 CET  Europe/Paris  
2019-03-28 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2019-03-29 00:00 HKT  Asia/Hong_Kong
2019-03-29 00:00 +08  Asia/Singapore
2019-03-29 01:00 JST  Asia/Tokyo
2019-03-29 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

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

= Followups =

#topic #845 Wiki deprecation status

.fpc 845
https://pagure.io/packaging-committee/issue/845

#topic #859 Scriptlet to replace a directory: try delete first? 
.fpc 859
https://pagure.io/packaging-committee/issue/859

= 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&tags=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
  * 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Jonathan Wakely]

On 26/03/19 11:40 +, Tomasz Kłoczko wrote:

On Tue, 26 Mar 2019 at 08:57, Jonathan Wakely 
wrote:
[..]


>What does this 42 means in this case? It means that during whole gcc build
>are repeated 42 times some subset of *autoconf tests*. How it was possible
>to loose that?!? 🤔
>gcc is quite monolithic and it should have only one configure.ac. Yes,

Why?



Really?
Really do you want me to answer on the question "why there is no any sense
repeat 42 times some tests on the source code configuration stage?" ??


Yes, because you repeatedly make the mistake of assuming that one
dimension of a problem is the only one that matters, and that all
other considerations are irrelevant.

I haven't quoted the rest of your email because it's the usual
rambling diatribe and I gave up trying to follow it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sway SIG

[Dan Čermák]

Me too!

qrsBRWN  writes:

> I'm in too
>
> On March 27, 2019 7:49:03 PM GMT+01:00, Jeff Peeler  
> wrote:
>>On Mon, Mar 18, 2019 at 11:24 AM Till Hofmann
>>
>>wrote:
>>
>>> 
>>> There's been ongoing discussions on BZ [1] with some people showing
>>> interest in a SIG. The main purpose of this email is to see who else
>>> would be interested in contributing to sway. If we can find enough
>>> people, I'd continue with the SIG, as outlined in [2].
>>>
>>> I've never been involved in creating a SIG before, so please let me
>>know
>>> if I forgot anything.
>>>
>>
>> Please add me to the sway SIG as well.
>>
>>Jeff
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Martin Gansser]

> On 3/27/19 7:06 AM, Martin Gansser wrote:
> 
> I don't see anything wrong on the server side logs here, it shows that
> it's accepting your key. Is this still happening?
> 
> Feel free to drop by #fedora-admin on freenode or file a infrastructure
> ticket and we will get it working (
> https://pagure.io/fedora-infrastructure/new_issue )
> 
> kevin
on vmware with f29 it still accepting my key, but not on vmware with f30
I think i will open a ticket on infrastructure tomorrow.

Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Jonathan, thanks for the tip! It works now!

How cool is that we have a lot of experts in almost every aspect of
software development around?


ср, 27 мар. 2019 г. в 17:43, Jonathan Wakely :
>
> On 27/03/19 16:37 +, Jonathan Wakely wrote:
> >On 27/03/19 16:13 +0100, Jakub Jelinek wrote:
> >>On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
> >>>Jakub, thanks for the tip! Now I moved a little further. I've added
> >>>-save-temps to CXXFLAGS and indeed there is something wrong. Here is
> >>>how this cstddef file was included:
> >>>
> >>>===
> >>># 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
> >>># 51 "/usr/include/c++/9/cstddef" 2 3
> >>>
> >>>
> >>># 52 "/usr/include/c++/9/cstddef" 3
> >>>  "C++"
> >
> >Wow, somebody did something very silly.
>
> And here it is:
> https://github.com/SIPp/sipp/blob/fc348b8539949b0533a259e81923ed64e22f4657/include/logger.hpp#L10
>
> A less ridiculous way to do that would be:
>
> #ifdef GLOBALS_FULL_DEFINITION
> #define MAYBE_EXTERN
> #define _DEFVAL(value) = value
> #else
> #define MAYBE_EXTERN extern
> #define _DEFVAL(value)
> #endif
>
> and then use MAYBE_EXTERN instead of extern.
>
> The _DEFVAL is also undefined behaviour, because that's a reserved
> name. It should be DEFVAL.
>
>


-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sway SIG

[qrsBRWN]

I'm in too

On March 27, 2019 7:49:03 PM GMT+01:00, Jeff Peeler  wrote:
>On Mon, Mar 18, 2019 at 11:24 AM Till Hofmann
>
>wrote:
>
>> 
>> There's been ongoing discussions on BZ [1] with some people showing
>> interest in a SIG. The main purpose of this email is to see who else
>> would be interested in contributing to sway. If we can find enough
>> people, I'd continue with the SIG, as outlined in [2].
>>
>> I've never been involved in creating a SIG before, so please let me
>know
>> if I forgot anything.
>>
>
> Please add me to the sway SIG as well.
>
>Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Fabio Valentini]

On Wed, Mar 27, 2019 at 8:13 PM Kevin Fenzi  wrote:
>
> On 2/15/19 5:16 AM, Fabio Valentini wrote:
> > On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa  wrote:
> >>
> >> This group would be for maintaining packages that are modularized in a
> >> non-module context so that it's actually usable by the broader
> >> ecosystem. Modules are not usable for non-module packages, and third
> >> parties building on top of Fedora can't use modules at all either.
>
> That is indeed sadly true right now, but that should change.
>
> >> Since module developers don't care about these users, this SIG will.
>
> I don't think that's true.
>
> > Exactly. This clarification is definitely more succinct than I
> > anything I could have said.
>
> Well, does that mean the stewardship sig will stop existing once we can
> build non modular content against modules? I was seeing it as more long
> term.

Probably both. The primary reason for starting this group now was the
issues around modularizing packages before the infrastructure had
caught up.

On the other side, I don't think that the problem of orphaned
"important" packages will go away, and this group can offer
maintenance until a "proper" new maintainer for those packages is
found.

> >> Fabio, I'm willing to help where I can with this, too.
> >
> > Thank you!
>
> I don't have much spare time these days, but feel free to add me to the
> group/list and I can help as time permits.
>
> kevin
>

Thank you Kevin, I've added you to the group and the list.

Fabio

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Golang Packaging Guidelines: Feedback needed and appreciated

[Nicolas Mailhot]

Le mercredi 27 mars 2019 à 19:13 +, David Dykstra a écrit :
Hi David,
> 
> I'd like to see clarity on the guidelines for golang applications as
> opposed to golang libraries.  It seems to assume from the start that
> it's talking about libraries, based on the package naming
> requirement.

From a technical POW and given how the Go world is structured a Golang
application is just another bundle of Go source code, that happens to
produce binaries.

So all the Go source code packaging guidelines apply as-is, except for
the srpm naming, and the fact that %build also produces binaries that
need to be deployed somewhere on the filesystem (but once compiled,
there is no specific difference between a Go or a C binary from a
packaging POW, so you won't find long Go-binary specific explanations
here).



-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Golang Packaging Guidelines: Feedback needed and appreciated

[David Dykstra]

Robert,

I'd like to see clarity on the guidelines for golang applications as
opposed to golang libraries.  It seems to assume from the start that
it's talking about libraries, based on the package naming requirement.
In the "Bundled or de-bundled" section I see mention of "golang projects"
and I suppose that's the name given to what I'm talking about.  It's
hard to tell how much of the guidelines apply to a golang project.

Dave
(singularity package owner)

On Fri, Mar 22, 2019 at 07:46:23PM +0100, Robert-André Mauchin wrote:
> Hello Fedora people,
> 
> As you may or may not know, currently applied Golang packaging guidelines 
> have always been simply a «???draft???». Part of the new Go SIG mission is to 
> update ours best practices and tooling. As such, Nicolas Mailhot designed  a 
> new set of macros based on lua script to improve our current situation. As a 
> result, we needed to draft new guidelines to reflect the future 
> implementation 
> of these macros.
> 
> I have written these new guidelines and I'd like to ask for your help in 
> order to review them: both from current Go SIG packagers point of view and 
> from novices in the matter, in order to make sure they are clear and 
> understandable enough for everyone.
> 
> I have uploaded a mirror of the Guidelines on my FedoraPeople space:
> https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
> 
> Please, if you have 10 mn to spare, read them and send me feedback. If 
> you 
> wish you can also directly send me a Merge Request on Pagure:
> https://pagure.io/fork/eclipseo/packaging-committee/  (branch 
> implement_golang_guidelines).
> 
> Best regards,
> 
> Robert-André
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Kevin Fenzi]

On 2/15/19 5:16 AM, Fabio Valentini wrote:
> On Fri, Feb 15, 2019 at 2:14 PM Neal Gompa  wrote:
>>
>> This group would be for maintaining packages that are modularized in a
>> non-module context so that it's actually usable by the broader
>> ecosystem. Modules are not usable for non-module packages, and third
>> parties building on top of Fedora can't use modules at all either.

That is indeed sadly true right now, but that should change.

>> Since module developers don't care about these users, this SIG will.

I don't think that's true.

> Exactly. This clarification is definitely more succinct than I
> anything I could have said.

Well, does that mean the stewardship sig will stop existing once we can
build non modular content against modules? I was seeing it as more long
term.

>> Fabio, I'm willing to help where I can with this, too.
> 
> Thank you!

I don't have much spare time these days, but feel free to add me to the
group/list and I can help as time permits.

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sway SIG

[Jeff Peeler]

On Mon, Mar 18, 2019 at 11:24 AM Till Hofmann 
wrote:

> 
> There's been ongoing discussions on BZ [1] with some people showing
> interest in a SIG. The main purpose of this email is to see who else
> would be interested in contributing to sway. If we can find enough
> people, I'd continue with the SIG, as outlined in [2].
>
> I've never been involved in creating a SIG before, so please let me know
> if I forgot anything.
>

 Please add me to the sway SIG as well.

Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is SELinux enforcing on the koji builders?

[Kevin Fenzi]

On 3/27/19 8:04 AM, Lubomír Sedlář wrote:
> Jerry James píše v St 27. 03. 2019 v 08:17 -0600:
>> On Wed, Mar 27, 2019 at 1:17 AM Miroslav Suchý 
>> wrote:
>>> Hmmm, it would be nice if we can send ABRT reports from crashes,
>>> which happens during a build.
>>
>> Or a button I can push somewhere that downloads the contents of
>> /builddir/build/BUILD as a tarball, for a given architecture, after a
>> failed build.  Or even some way of replicating *exactly* the koji
>> build environment on my local machine.
> 
> There's an app for that (well, a Koji plugin): 
> https://docs.pagure.org/koji/plugins/#save-failed-tree-plugin
> 
> Sadly, it does not seem to be enabled:
> 
> $ koji save-failed-tree 33751726
> * The save_failed_tree plugin appears to not be installed on the koji
> hub.  Please contact the administrator.

Huh, didn't know about that plugin. It does sound handy... we can look
into enabling it. Of course you would need to run it before koji cleans
up the buildroot, but still could be of help.

I filed
https://pagure.io/releng/issue/8243
to consider enabling this.

Do note that if you coordinate with #fedora-releng we can try and
manually get you the core or whatever you need from the build. Just let
us know what you need and when the build is happening. Of course that
doesn't scale, but for infrequent requests it's acceptable. :)

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Kevin Fenzi]

On 3/27/19 7:06 AM, Martin Gansser wrote:
> [martin@f30 fedora-scm]$ cat -v ~/.ssh/config
> Host pkgs.fedoraproject.org
> User martinkg
> IdentityFile ~/.ssh/id_rsa.pub
> 
> [martin@f30 fedora-scm]$ fedpkg clone lollypop
> Cloning into 'lollypop'...
> packet_write_wait: Connection to 209.132.181.4 port 22: Broken pipe
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> Could not execute clone: Failed to execute command.

I don't see anything wrong on the server side logs here, it shows that
it's accepting your key. Is this still happening?

Feel free to drop by #fedora-admin on freenode or file a infrastructure
ticket and we will get it working (
https://pagure.io/fedora-infrastructure/new_issue )

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ACTION NEEDED: Orphaned packages to be retired (Java packages in 1 week)

[Richard Shaw]

I considered taking xcdroast but it needs to be patched to work with wodim
because it's only designed to be used with real cdrecord... Probably best
just to retire it. There are several other lightweight graphical CD/DVD
writer tools.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ACTION NEEDED: Orphaned packages to be retired (Java packages in 1 week)

[Sérgio Basto]

On Wed, 2019-03-27 at 18:48 +0100, Miro Hrončok wrote:
> On 27. 03. 19 18:18, Sérgio Basto wrote:
> > On Tue, 2019-03-26 at 11:08 +0100, Miro Hrončok wrote:
> > > sergiomb: nodejs-array-union
> > 
> > why today ;) I'm associated to nodejs-array-union , seems to me
> > thescript have a bug ...
> 
> What bug? Read the full report and grep your FAS name, follow the
> crumbs:

ah ok , thanks for the info 



> Depending on: nodejs-array-union (54)
> 
>   nodejs-multimatch (maintained by: jamielinux, nodejs-sig,
> patches)
>   nodejs-multimatch-2.1.0-7.fc30.noarch requires
> npm(array-union) = 1.0.1
>   nodejs-multimatch-2.1.0-7.fc30.src requires npm(array-
> union) = 1.0.1
> 
>   nodejs-load-grunt-tasks (maintained by: jamielinux, nodejs-sig, 
> patches)
>   nodejs-load-grunt-tasks-3.5.0-7.fc30.noarch requires
> npm(multimatch) = 2.1.0
>   nodejs-load-grunt-tasks-3.5.0-7.fc30.src requires
> npm(multimatch) = 2.1.0
> 
>   js-jquery (maintained by: ctubbsii, jamielinux, nodejs-sig,
> patches)
>   js-jquery-3.3.1-2.fc30.src requires npm(load-grunt-
> tasks) = 3.5.0
> 
>   xpra (maintained by: jgu, sagitter, sergiomb)
>   xpra-2.4.3-3.fc30.i686 requires js-jquery = 3.3.1-
> 2.fc30
> 
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ACTION NEEDED: Orphaned packages to be retired (Java packages in 1 week)

[Miro Hrončok]

On 27. 03. 19 18:18, Sérgio Basto wrote:

On Tue, 2019-03-26 at 11:08 +0100, Miro Hrončok wrote:

sergiomb: nodejs-array-union


why today ;) I'm associated to nodejs-array-union , seems to me thescript have 
a bug ...


What bug? Read the full report and grep your FAS name, follow the crumbs:

Depending on: nodejs-array-union (54)

nodejs-multimatch (maintained by: jamielinux, nodejs-sig, patches)
nodejs-multimatch-2.1.0-7.fc30.noarch requires npm(array-union) 
= 1.0.1
nodejs-multimatch-2.1.0-7.fc30.src requires npm(array-union) = 
1.0.1

nodejs-load-grunt-tasks (maintained by: jamielinux, nodejs-sig, patches)
nodejs-load-grunt-tasks-3.5.0-7.fc30.noarch requires 
npm(multimatch) = 2.1.0
nodejs-load-grunt-tasks-3.5.0-7.fc30.src requires 
npm(multimatch) = 2.1.0

js-jquery (maintained by: ctubbsii, jamielinux, nodejs-sig, patches)
js-jquery-3.3.1-2.fc30.src requires npm(load-grunt-tasks) = 
3.5.0

xpra (maintained by: jgu, sagitter, sergiomb)
xpra-2.4.3-3.fc30.i686 requires js-jquery = 3.3.1-2.fc30


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ACTION NEEDED: Orphaned packages to be retired (Java packages in 1 week)

[Sérgio Basto]

On Tue, 2019-03-26 at 11:08 +0100, Miro Hrončok wrote:
> sergiomb: nodejs-array-union

why today ;) I'm associated to nodejs-array-union , seems to me thescript have 
a bug ... 

Thanks, 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Dridi Boukelmoune]

On Wed, Mar 27, 2019 at 3:06 PM Martin Gansser  wrote:
>
> [martin@f30 fedora-scm]$ cat -v ~/.ssh/config
> Host pkgs.fedoraproject.org

You can probably wildcard it to *.fedoraproject.org in case you have
to ssh somewhere else in the future.

> User martinkg
> IdentityFile ~/.ssh/id_rsa.pub
>
> [martin@f30 fedora-scm]$ fedpkg clone lollypop
> Cloning into 'lollypop'...
> packet_write_wait: Connection to 209.132.181.4 port 22: Broken pipe
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> Could not execute clone: Failed to execute command.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Jonathan Wakely]

On 27/03/19 16:37 +, Jonathan Wakely wrote:

On 27/03/19 16:13 +0100, Jakub Jelinek wrote:

On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:

Jakub, thanks for the tip! Now I moved a little further. I've added
-save-temps to CXXFLAGS and indeed there is something wrong. Here is
how this cstddef file was included:

===
# 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
# 51 "/usr/include/c++/9/cstddef" 2 3


# 52 "/usr/include/c++/9/cstddef" 3
 "C++"


Wow, somebody did something very silly.


And here it is:
https://github.com/SIPp/sipp/blob/fc348b8539949b0533a259e81923ed64e22f4657/include/logger.hpp#L10

A less ridiculous way to do that would be:

#ifdef GLOBALS_FULL_DEFINITION
#define MAYBE_EXTERN
#define _DEFVAL(value) = value
#else
#define MAYBE_EXTERN extern
#define _DEFVAL(value)
#endif

and then use MAYBE_EXTERN instead of extern.

The _DEFVAL is also undefined behaviour, because that's a reserved
name. It should be DEFVAL.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Jonathan Wakely]

On 27/03/19 16:13 +0100, Jakub Jelinek wrote:

On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:

Jakub, thanks for the tip! Now I moved a little further. I've added
-save-temps to CXXFLAGS and indeed there is something wrong. Here is
how this cstddef file was included:

===
# 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
# 51 "/usr/include/c++/9/cstddef" 2 3


# 52 "/usr/include/c++/9/cstddef" 3
  "C++"


Wow, somebody did something very silly.


{

namespace std
{

  using ::max_align_t;
}
# 197 "/usr/include/c++/9/cstddef" 3
}
# 25 "./include/strings.hpp" 2


You can use -E -dD to see what macros are defined and where.
If the app does
#define extern
before including system headers, then it obviously needs to be fixed.
It can do that before its own include headers if it makes sure it will work,


It's undefined behaviour to do so, but I guess if they want to deal
with that, that's their problem.

"A translation unit shall not #define or #undef names lexically
identical to keywords, "


but system headers of course should be able to use extern whenever it makes
sense in there.

Jakub

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Jonathan Wakely]

On 27/03/19 16:54 +0100, J. Scheurich wrote:



g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
'./'`src/sipp.cpp
In file included from ./include/strings.hpp:24,
 from ./include/sipp.hpp:484,
 from src/sipp.cpp:41:
/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
string constant
   52 | extern "C++"
  |^
make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1


https://en.cppreference.com/w/cpp/language/language_linkage
...
| Only two language linkages are guaranteed to be supported:
| 1) "C++", the default language linkage.
| 2) "C", which makes it possible to link with functions written in the
| C programming language, and to define, in a C++ program, functions
| that can be called from the modules written in C.

Cause  'extern "C++"' is the default for C++ and the compiler is g++,
you should be able to simply delete 'extern "C++"', is should have no
effect.


That's not true at all:

extern "C" {
extern "C++" void f();
}

extern "C++" {
void g();
}

If you remove the first occurrence of extern "C++" then you change the
language linkage of f() and if you remove the second occurrence then
you have just { at namespace scope, which is ill-formed.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Policy regarding redundant dependencies

[Georg Sauthoff]

On Wed, Mar 27, 2019 at 03:04:53PM +, Richard W.M. Jones wrote:
> On Tue, Mar 26, 2019 at 06:07:05PM +0100, Georg Sauthoff wrote:
> > because rpm automatically adds something like:
> > 
> > libfoo.so.1()(64bit)
> > 
> > Of course, I could still add a superfluous
> > 
> > Requires: libfoo
 
> This could pull in the 32 bit version of the package so it's wrong as
> well as redundant.  (You'd want to use %{_isa} I think)
 
> Is there a reason why you want to add extra Requires lines?

I don't want to add extra Requires lines.

On the contrary, I want to remove an extra Requires line but was
challenged by the maintainer to keep it (without providing a convincing
reason, I would say):

https://src.fedoraproject.org/rpms/maildrop/pull-request/1

Thus, to finally resolve this issue I googled for the Fedora policy,
without finding the relevant section - thus I asked on this list.

Best regards
Georg

-- 
Hofstadter's Law: "It always takes longer than you think it will
take, even when you take into account Hofstadter's Law"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[J. Scheurich]

g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
'./'`src/sipp.cpp
In file included from ./include/strings.hpp:24,
  from ./include/sipp.hpp:484,
  from src/sipp.cpp:41:
/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
string constant
52 | extern "C++"
   |^
make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1


https://en.cppreference.com/w/cpp/language/language_linkage
...
| Only two language linkages are guaranteed to be supported:
| 1) "C++", the default language linkage.
| 2) "C", which makes it possible to link with functions written in the
| C programming language, and to define, in a C++ program, functions
| that can be called from the modules written in C.

Cause  'extern "C++"' is the default for C++ and the compiler is g++,
you should be able to simply delete 'extern "C++"', is should have no
effect.

so long
MUFTI
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20190327.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Compose FAILS proposed Rawhide gating check!
8 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 24/142 (x86_64), 3/24 (i386), 1/2 (arm)

ID: 373065  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/373065
ID: 373074  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/373074
ID: 373082  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/373082
ID: 373084  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/373084
ID: 373086  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/373086
ID: 373089  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/373089
ID: 373093  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/373093
ID: 373094  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/373094
ID: 373095  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/373095
ID: 373107  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/373107
ID: 373108  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/373108
ID: 373110  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/373110
ID: 373111  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/373111
ID: 373112  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/373112
ID: 373121  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/373121
ID: 373123  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/373123
ID: 373143  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/373143
ID: 373156  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/373156
ID: 373165  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/373165
ID: 373173  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/373173
ID: 373174  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/373174
ID: 373175  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/373175
ID: 373176  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/373176
ID: 373177  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/373177
ID: 373182  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/373182
ID: 373189  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/373189
ID: 373193  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/373193
ID: 373208  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/373208

Soft failed openQA tests: 14/142 (x86_64), 4/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 373041  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/373041
ID: 373042  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/373042
ID: 373043  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/373043
ID: 373044  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/373044
ID: 373054  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/373054
ID: 373068  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/373068
ID: 373069  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/373069
ID: 373080  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/373080
ID: 373087  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/373087
ID: 373088  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/373088
ID: 373092  Test: i386 Workstation-boot-iso memory_check
URL: htt

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Nicolas Mailhot]

Le 2019-03-27 16:23, Nico Kadel-Garcia a écrit :


That wasn't me. I was just asking about whether using pushd and popd
in a .spec file made sense. I think it does not, it's safer to specify
the target directory explicitly rather than rely on these tools.


The way rpm packaging works, you compose many different shell snippets 
(either via packaging guidelines or via rpm macros). Very rigid systems 
that assume things are exactly one way, without variation, tend to 
compose badly.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20190327.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190324.n.0
NEW: Fedora-Rawhide-20190327.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  50
Dropped packages:15
Upgraded packages:   202
Downgraded packages: 0

Size of added packages:  98.57 MiB
Size of dropped packages:220.71 MiB
Size of upgraded packages:   8.04 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -2.71 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Workstation live i386
Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190327.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190327.n.0-sda.raw.xz
Image: Python_Classroom live i386
Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-Rawhide-20190327.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: R-forcats-0.4.0-1.fc31
Summary: Tools for Working with Categorical Variables (Factors)
RPMs:R-forcats
Size:345.98 KiB

Package: R-gapminder-0.3.0-1.fc31
Summary: Data from Gapminder
RPMs:R-gapminder
Size:1.91 MiB

Package: R-tidyr-0.8.3-1.fc31
Summary: Easily Tidy Data with 'spread()' and 'gather()' Functions
RPMs:R-tidyr
Size:2.48 MiB

Package: crossguid2-0.2.2-1.20190126gitb151b7d.fc31
Summary: Lightweight cross platform C++ GUID/UUID library
RPMs:crossguid2 crossguid2-devel
Size:172.07 KiB

Package: cutter-re-1.8.0-1.fc31
Summary: GUI for radare2 reverse engineering framework
RPMs:cutter-re
Size:5.10 MiB

Package: daggy-1.0.1-1.fc31
Summary: Data Aggregation Utility
RPMs:daggy
Size:1.18 MiB

Package: golang-contrib-opencensus-exporter-ocagent-0.4.9-1.fc31
Summary: OpenCensus Go exporters for OpenCensus Agent
RPMs:golang-contrib-opencensus-exporter-ocagent-devel
Size:35.10 KiB

Package: golang-github-alexcesaro-quotedprintable-v3-3.0.0-1.fc31
Summary: A Go package concerning quoted-printable encoding
RPMs:golang-github-alexcesaro-quotedprintable-v3-devel 
golang-gopkg-3-alexcesaro-quotedprintable-devel 
golang-gopkg-alexcesaro-quotedprintable-3-devel
Size:56.96 KiB

Package: golang-github-anacrolix-missinggo-2.0.1-1.fc31
Summary: Supplementary material for Go's stdlib
RPMs:golang-github-anacrolix-missinggo 
golang-github-anacrolix-missinggo-devel
Size:37.97 MiB

Package: golang-github-anacrolix-tagflag-1.0.0-1.fc31
Summary: Declarative flag parsing for Go using struct tags
RPMs:golang-github-anacrolix-tagflag-devel
Size:19.84 KiB

Package: golang-github-benbjohnson-clock-0-0.1.20190325git7dc7640.fc31
Summary: Go library for mocking time
RPMs:golang-github-benbjohnson-clock-devel
Size:14.78 KiB

Package: golang-github-docopt-0.6.2-1.20190325gitee0de3b.fc31
Summary: A command-line arguments parser
RPMs:golang-github-docopt-devel
Size:28.98 KiB

Package: golang-github-euank-kmsg-parser-2.0.1-1.fc31
Summary: A simpler parser for the /dev/kmsg format
RPMs:godmesg golang-github-euank-kmsg-parser-devel
Size:3.41 MiB

Package: golang-github-facebookarchive-inject-0-0.1.20190326gitf23751c.fc31
Summary: Package inject provides a reflect based injector
RPMs:golang-github-facebookarchive-inject-devel
Size:18.71 KiB

Package: golang-github-facebookarchive-structtag-0-0.1.20190327git217e25f.fc31
Summary: Package structtag provides parsing of the defacto struct tag style
RPMs:golang-github-facebookarchive-structtag-devel
Size:11.15 KiB

Package: golang-github-hpcloud-tail-1.0.0-1.20190325gita1dbeea.fc31
Summary: Go package for reading from continously updated files
RPMs:golang-github-hpcloud-tail-devel
Size:25.46 KiB

Package: golang-github-inconshreveable-log15-2.14-1.fc31
Summary: Simple toolkit for best-practice logging in Go
RPMs:golang-github-inconshreveable-log15-devel
Size:30.67 KiB

Package: golang-github-koofr-httpclient-0-0.1.20190325git0378617.fc31
Summary: Go HTTP client
RPMs:golang-github-koofr-httpclient-devel
Size:17.31 KiB

Package: golang-github-koofr-koofrclient-0-0.1.20190325git7f32759.fc31
Summary: Go Koofr client
RPMs:golang-github-koofr-koofrclient-devel
Size:16.19 KiB

Package: golang-github-krolaw-dhcp4-0-0.1.20190325git7cead47.fc31
Summary: DHCP4 library written in Go
RPMs:golang-github-krolaw-dhcp4-devel
Size:23.64 KiB

Package: golang-github-macaron-binding-0-0.1.20190325gitac54ee2.fc31
Summary: Provides request data binding and validation for Macaron
RPMs:golang-github-macaron-binding-devel
Size:30.04 KiB

Package: golang-github-macaron-gzip-0-0.1.20190325gitcad1c65.fc31
Summary: Provides Gzip compress to responses for Macaron
RPMs:golang-github-macaron-gzip-devel
Size:14.93 KiB

Package: golang-github-mail-v2-2.3.1-1.fc31
Summary: Gomail is a simple and efficient package to send emails
RPMs:golang-github-mail-v2-devel golang-gopkg-mail-2-devel
Size:55.88 KiB

Package: golang-github-opentracing-1.1.0-1.fc31
Summary: Op

Orphaning python-Lektor

[Charalampos Stratakis]

Not interested anymore in this package, feel free to reach me out if you'd like 
to take it, I'll orphan it this week.

It will probably need a re-review to rename it to 'lektor' as it's mainly an 
application.

It's sort of active on github [0]. More info [1].

[0] https://github.com/lektor/lektor
[1] https://www.getlektor.com/

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Nico Kadel-Garcia]

On Wed, Mar 27, 2019 at 3:32 AM Nicolas Mailhot
 wrote:
>
> Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :
> > On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
> >  wrote:
>
> >> POSIX is dead as a shell compatibility target. You want to replace
> >> bash
> >> with something faster, by all means do it. With something that
> >> includes
> >> the GNU extensions like pushd/popd that most packagers expect today.
> >
> > Is there any reason to *ever* use pushd or popd in %build  or %install
> > today?
>
> That is totally the wrong attitude when you want to replace an
> implementation used for years by thousands of volunteer people in tens
> of thousands of interdependent files.

*I* wasn't suggesting altering the files. I'm merely startled by the
use of "pushd" and "popd" in build tools, especially within %build or
%install.

> It is used now, ergo packagers (the people who did the work) find it
> useful and convenient. You want them to do something else, you need to
> make it worth their effort to something else. Winning 10 minutes of CPU
> time in a single pathological spec like gcc isn't it.

Looking at https://src.fedoraproject.org/cgit/rpms/gcc.git/tree/gcc.spec
. *ouch*. Yeah, that is a good example. I disagree with that part
of the .spec file's logic, but wouldn't want to take on testing and
debugging something that takes this long to compile.

> Yet another is to propose a syntax with is clearly simpler, more
> expressive, more productive and better documented for humans (Not CPUs.
> CPUs do not get to vote). But, that solves "new spec and macro code"
> problem, not the "existing code" problem.
>
> Hazing people with negative terms like bashism never convinced anyone.
> Especially when others are doing the work, not you. In my language, that
> is called “arriving after the battle”: complaining loudly at the people
> who sweated and blooded doing some work, that they didn't do it well
> enough, when you were safely somewhere else, at the time help was
> needed.

That wasn't me. I was just asking about whether using pushd and popd
in a .spec file made sense. I think it does not, it's safer to specify
the target directory explicitly rather than rely on these tools. But
that's a matter of policy and best practices.

> Sincerely,
>
> --
> Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

rubygem-curb license change from Ruby to MIT

[Pavel Valena]

in Fedora Rawhide, rubygem-curb-0.9.9.

Regards,

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Jakub Jelinek]

On Wed, Mar 27, 2019 at 04:08:59PM +0100, Peter Lemenkov wrote:
> Jakub, thanks for the tip! Now I moved a little further. I've added
> -save-temps to CXXFLAGS and indeed there is something wrong. Here is
> how this cstddef file was included:
> 
> ===
> # 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
> # 51 "/usr/include/c++/9/cstddef" 2 3
> 
> 
> # 52 "/usr/include/c++/9/cstddef" 3
>   "C++"
> {
> 
> namespace std
> {
> 
>   using ::max_align_t;
> }
> # 197 "/usr/include/c++/9/cstddef" 3
> }
> # 25 "./include/strings.hpp" 2

You can use -E -dD to see what macros are defined and where.
If the app does
#define extern
before including system headers, then it obviously needs to be fixed.
It can do that before its own include headers if it makes sure it will work,
but system headers of course should be able to use extern whenever it makes
sense in there.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Jakub, thanks for the tip! Now I moved a little further. I've added
-save-temps to CXXFLAGS and indeed there is something wrong. Here is
how this cstddef file was included:

===
# 1 "/usr/lib/gcc/x86_64-redhat-linux/9/include/stddef.h" 1 3 4
# 51 "/usr/include/c++/9/cstddef" 2 3


# 52 "/usr/include/c++/9/cstddef" 3
  "C++"
{

namespace std
{

  using ::max_align_t;
}
# 197 "/usr/include/c++/9/cstddef" 3
}
# 25 "./include/strings.hpp" 2

===

Note the missing extern pragma before "C++" token.

ср, 27 мар. 2019 г. в 15:58, Jakub Jelinek :
>
> On Wed, Mar 27, 2019 at 03:48:41PM +0100, Peter Lemenkov wrote:
> > I cannot build SIPp anymore. It fails with a very cryptic (for me) message:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853
> >
> > ```
> > g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
> > -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
> > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> > -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
> > './'`src/sipp.cpp
> > In file included from ./include/strings.hpp:24,
> >  from ./include/sipp.hpp:484,
> >  from src/sipp.cpp:41:
> > /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
> > string constant
> >52 | extern "C++"
> >   |^
> > make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
> > make[1]: *** Waiting for unfinished jobs
> > make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
> > make: *** [Makefile:830: all] Error 2
> > error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
> > ```
> > ^^^ That's exactly where I'm stuck now. This is how my
> > `/usr/include/c++/9/cstddef` looks like:
> >
> > * 
> > https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/c_global/cstddef
> >
> > And I tend to think that this issue is related to this commit:
> >
> > * 
> > https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83ad4996ae
>
> You should look at what comes before that token and from where,
> that might be a reason why the extern "C++" is rejected at that spot.
> So, preprocess it (-save-temps or -E -o src/sipp-sipp.ii) and look in the
> preprocessed dump.  Perhaps cstddef is included in some context where it
> shouldn't be or there are macros redefining extern or similar bogosities.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Chris Adams]

Once upon a time, Vít Ondruch  said:
> Is there a way to do something similar to:

A case of:

  pushd someplace
  [do some things]
  popd

can be replaced with:

  cd someplace
  [do some things]
  cd -

If there's some more complicated stuff that has more directory changes
in between the pushd/popd, you can do:

  returnto=$(pwd)
  cd someplace
  [do some things]
  cd $returnto

I went through a lot of this many years ago when I used RPM for managing
third-party software on DEC Unix (where /bin/sh was actual Bourne
shell), but... I don't see the value for Fedora in such churn.  I don't
see a compelling reason to switch /bin/sh to something other than bash,
and it would just be confusing to run shell scriptlets with something
other than /bin/sh.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multiple Review Requests for one source package?

[Richard Shaw]

Ok, so just to close the loop on this thread, I gave up on trying to fix
the setuptools bug when using --root and have moved on to s straight cmake
build.

Because the packages have a dependency chain I have to do fake installs in
%build passing CMAKE_INSTALL_PREFIX to be somewhere in the build tree.

The means I have to run %cmake again with the correct install prefix in
%install but it looks like only the libraries are re-linked with the
correct RPATH and not everything building twice, which would be bad.

Cleaning up %files now because the install directories are slightly
different for some files between setuptools and cmake.

Thanks,
Richard

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Policy regarding redundant dependencies

[Richard W.M. Jones]

On Tue, Mar 26, 2019 at 06:07:05PM +0100, Georg Sauthoff wrote:
> because rpm automatically adds something like:
> 
> libfoo.so.1()(64bit)
> 
> Of course, I could still add a superfluous
> 
> Requires: libfoo

This could pull in the 32 bit version of the package so it's wrong as
well as redundant.  (You'd want to use %{_isa} I think)

Is there a reason why you want to add extra Requires lines?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is SELinux enforcing on the koji builders?

[Lubomír Sedlář]

Jerry James píše v St 27. 03. 2019 v 08:17 -0600:
> On Wed, Mar 27, 2019 at 1:17 AM Miroslav Suchý 
> wrote:
> > Hmmm, it would be nice if we can send ABRT reports from crashes,
> > which happens during a build.
> 
> Or a button I can push somewhere that downloads the contents of
> /builddir/build/BUILD as a tarball, for a given architecture, after a
> failed build.  Or even some way of replicating *exactly* the koji
> build environment on my local machine.

There's an app for that (well, a Koji plugin): 
https://docs.pagure.org/koji/plugins/#save-failed-tree-plugin

Sadly, it does not seem to be enabled:

$ koji save-failed-tree 33751726
* The save_failed_tree plugin appears to not be installed on the koji
hub.  Please contact the administrator.


> -- 
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange C++ error with GCC 9.0.1

[Jakub Jelinek]

On Wed, Mar 27, 2019 at 03:48:41PM +0100, Peter Lemenkov wrote:
> I cannot build SIPp anymore. It fails with a very cryptic (for me) message:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853
> 
> ```
> g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
> -DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
> -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
> './'`src/sipp.cpp
> In file included from ./include/strings.hpp:24,
>  from ./include/sipp.hpp:484,
>  from src/sipp.cpp:41:
> /usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
> string constant
>52 | extern "C++"
>   |^
> make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
> make: *** [Makefile:830: all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
> ```
> ^^^ That's exactly where I'm stuck now. This is how my
> `/usr/include/c++/9/cstddef` looks like:
> 
> * 
> https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/c_global/cstddef
> 
> And I tend to think that this issue is related to this commit:
> 
> * 
> https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83ad4996ae

You should look at what comes before that token and from where,
that might be a reason why the extern "C++" is rejected at that spot.
So, preprocess it (-save-temps or -E -o src/sipp-sipp.ii) and look in the
preprocessed dump.  Perhaps cstddef is included in some context where it
shouldn't be or there are macros redefining extern or similar bogosities.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Re: Fedora 30 Beta Go/No-Go meeting

[Ben Cotton]

Reminder: the Go/No-Go meeting for the Fedora 30 Beta release will be
held TOMORROW, 2019-03-28 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting

View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Vít Ondruch]

Dne 27. 03. 19 v 10:30 Dridi Boukelmoune napsal(a):
> On Wed, Mar 27, 2019 at 8:33 AM Nicolas Mailhot
>  wrote:
>> Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :
>>> On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
>>>  wrote:
 POSIX is dead as a shell compatibility target. You want to replace
 bash
 with something faster, by all means do it. With something that
 includes
 the GNU extensions like pushd/popd that most packagers expect today.
>>> Is there any reason to *ever* use pushd or popd in %build  or %install
>>> today?



Is there a way to do something similar to:


~~~


%check   
pushd .%{gem_instdir}

# Load nio4r_ext.so.   
rspec -I$(dirs +1)%{gem_extdir_mri} spec
   
popd

~~~


But honestly I don't care if /bin/sh is Bash or something different as
long as my script runs in our build environment.



Vít



>> That is totally the wrong attitude when you want to replace an
>> implementation used for years by thousands of volunteer people in tens
>> of thousands of interdependent files.
> Again, not interested in the side of the discussion about replacing
> bash as the default interpreter. This is a reminder that I would
> personally prefer that bash weren't behind /bin/sh.
>
>> It is used now, ergo packagers (the people who did the work) find it
>> useful and convenient. You want them to do something else, you need to
> I strongly disagree with the shortcut you make here.
>
> The only use of pushd/popd I made in scriptlets was because it was
> part of the Python packaging guidelines and I happen to maintain a
> bunch of Python packages. So what I was doing then wasn't to choose
> something I would deem useful and convenient but rather follow
> guidelines to the best of my abilities.
>
> So sure some people may find it useful and convenient, but others may
> not even be aware or care that this construct is bash-specific so
> please refrain from authoritatively introduce causality where there
> isn't.
>
> And on the convenience factor:
>
> pushd somewhere
> ...
> popd
>
> is not harder than:
>
> cd somewhere
> ...
> cd -
>
> The bash construct becomes interesting only when you need to stack
> directories and not keep explicit track of where you are returning to.
>
> This convenience I do not wish to remove from package maintainers,
> even in scriptlets.
>
>> make it worth their effort to something else. Winning 10 minutes of CPU
>> time in a single pathological spec like gcc isn't it.
>>
>> The easiest way to make it worth their effort is to reduce the effort to
>> zero, ie implement the capabilities commonly people use in your target
>> replacement shell. That will be way way easier than trying to invent
>> something compelling enough for them to change their habits. 10% of
>> specs doing something is definitely common use.
>>
>> Another way is to take the conversion work unto yourself. But that does
>> not solve the ongoing effort of helping packagers that try to use bash
>> syntax in their spec because they need to do something, and find out it
>> does not work, and give up because the additional work of looking for
>> alternatives makes the cost/benefit analysis of packaging something
>> negative. We have many packages where the cost/benefit hovers next to
>> the limit, because we have nice volunteers that will go to their limits
>> for Fedora.
> Conversely whenever as a Fedora end user I run into a failing script
> on a non Fedora system because it uses GNUisms it makes my life harder
> to work on the multiple systems I have to deal with. By having bash as
> /bin/sh Fedora defers the moment when I realize this is happening and
> pain ensues. That is because Fedora is my main system and others are
> second-class citizens in my workflow. I'd hate to elect a different
> one as main my system for obvious reasons.
>
>> Yet another is to propose a syntax with is clearly simpler, more
>> expressive, more productive and better documented for humans (Not CPUs.
>> CPUs do not get to vote). But, that solves "new spec and macro code"
>> problem, not the "existing code" problem.
>>
>> Hazing people with negative terms like bashism never convinced anyone.
> I'm sure some comments of this nature actually got a "fair enough"
> response from a couple people.
>
>> Especially when others are doing the work, not you. In my language, that
>> is called “arriving after the battle”: complaining loudly at the people
>> who sweated and blooded doing some work, that they didn't do it well
>> enough, when you were safely somewhere else, at the time help was
>> needed.
> I am personally taking an opportunity to raise my concern about the
> default shell seeing this after-the-battle thread.
>
> Maybe I should start a different one on /bin/sh?
>
> I was not aware of this until the link was shared in this thread but
> this is an interesting read on the topic:
>
> https://wiki.ubuntu.com/DashAsBinSh
>
> If RPM goes somewhere on this topic [1] maybe that could be a change for f31?
>

Strange C++ error with GCC 9.0.1

[Peter Lemenkov]

Hello All!
I cannot build SIPp anymore. It fails with a very cryptic (for me) message:

https://koji.fedoraproject.org/koji/taskinfo?taskID=33763853

```
g++ -DHAVE_CONFIG_H -DUSE_OPENSSL -DPCAPPLAY -DRTP_STREAM -DUSE_SCTP
-DHAVE_EPOLL -I. -I./include   -D__LINUX -I./include -Wall -pedantic
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-c -o src/sipp-sipp.o `test -f 'src/sipp.cpp' || echo
'./'`src/sipp.cpp
In file included from ./include/strings.hpp:24,
 from ./include/sipp.hpp:484,
 from src/sipp.cpp:41:
/usr/include/c++/9/cstddef:52:8: error: expected unqualified-id before
string constant
   52 | extern "C++"
  |^
make[1]: *** [Makefile:1768: src/sipp-sipp.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/home/petro/rpmbuild/BUILD/sipp-3.5.2'
make: *** [Makefile:830: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Y5CFt4 (%build)
```
^^^ That's exactly where I'm stuck now. This is how my
`/usr/include/c++/9/cstddef` looks like:

* 
https://github.com/gcc-mirror/gcc/blob/25694c85/libstdc%2B%2B-v3/include/c_global/cstddef

And I tend to think that this issue is related to this commit:

* 
https://github.com/gcc-mirror/gcc/commit/038feca5beacbe36e28680c8e1a8af83ad4996ae

-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Student Introduction

[Hemant Kumar Singh]

Greetings,
I am Hemant Kumar Singh, a computer science undergrad studying in NIT Warangal, 
India. I am interested to work on the project "CentOS CI User Front End" with 
Fedora Project under the guidance of Brian Stinson and Vipul Siddharth; this 
project requires HTML5 and CSS; I have done HTML in my high school and this is 
my 2nd semester pursuing a computer science major in NITW where I've been 
learning CSS on my own. Although I am new to the open source community, I feel 
I am a potential candidate for the same and will post my draft proposal asap 
for your feedback.

Regards,
Hemant Kumar Singh

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is SELinux enforcing on the koji builders?

[Jerry James]

On Wed, Mar 27, 2019 at 1:17 AM Miroslav Suchý  wrote:
> Hmmm, it would be nice if we can send ABRT reports from crashes, which 
> happens during a build.

Or a button I can push somewhere that downloads the contents of
/builddir/build/BUILD as a tarball, for a given architecture, after a
failed build.  Or even some way of replicating *exactly* the koji
build environment on my local machine.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Martin Gansser]

[martin@f30 fedora-scm]$ cat -v ~/.ssh/config
Host pkgs.fedoraproject.org
User martinkg
IdentityFile ~/.ssh/id_rsa.pub

[martin@f30 fedora-scm]$ fedpkg clone lollypop
Cloning into 'lollypop'...
packet_write_wait: Connection to 209.132.181.4 port 22: Broken pipe
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

strange failures with gcc-9.0.1-0.11.fc31.x86_64

[Zbigniew Jędrzejewski-Szmek]

Hi,

I'm trying to compile systemd in koji and mock, and I'm getting suspicious
crashes...

$ valgrind x86_64-redhat-linux-gnu/test-terminal-util
/* test_default_term_for_tty */
...
/* test_read_one_char */
==21== Invalid read of size 4
==21==at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so)
==21==by 0x109301: UnknownInlinedFun (test-terminal-util.c:43)
==21==by 0x109301: main (test-terminal-util.c:80)
==21==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==21== 
==21== 
==21== Process terminating with default action of signal 11 (SIGSEGV)

The problem is at this line, there is just a call to (a function which
transitively calls) mkostemp(). It seems like the inlining is somehow
going wrong.


Strangely, gdb also crashes:
$ gdb x86_64-redhat-linux-gnu/test-terminal-util
GNU gdb (GDB) Fedora 8.3.50.20190321-3.fc31
...
Reading symbols from x86_64-redhat-linux-gnu/test-terminal-util...
(gdb) r
Starting program: 
/builddir/build/BUILD/systemd-49bd196d693efe0acfc8d56c4e3d8f7ba9f91b5d/x86_64-redhat-linux-gnu/test-terminal-util
 
Missing separate debuginfos, use: dnf debuginfo-install 
glibc-2.29.9000-8.fc31.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
/* test_default_term_for_tty */
...
/* test_read_one_char */

Program received signal SIGSEGV, Segmentation fault.
0x77e759ec in fputs () from /lib64/libc.so.6
Segmentation fault (core dumped)


There also are compilation failures related to inlining, when I disable LTO:

In file included from ../src/basic/macro.h:549,
 from ../src/basic/alloc-util.h:9,
 from ../src/network/networkd-link.c:9:
In function ‘link_enable_ipv6’,
inlined from ‘link_set_mtu’ at ../src/network/networkd-link.c:1483:16:
../src/basic/log.h:104:9: error: ‘%s’ directive argument is null 
[-Werror=format-overflow=]
  104 | log_internal_realm(LOG_REALM_PLUS_LEVEL(LOG_REALM, (level)), 
__VA_ARGS__)
  | 
^
../src/shared/log-link.h:21:25: note: in expansion of macro ‘log_internal’
   21 | log_internal(level, error, __FILE__, __LINE__, 
__func__, ##__VA_ARGS__); \
  | ^~~~
../src/shared/log-link.h:33:50: note: in expansion of macro ‘log_link_full’
   33 | #define log_link_warning_errno(link, error, ...) log_link_full(link, 
LOG_WARNING, error, ##__VA_ARGS__)
  |  ^
../src/network/networkd-link.c:324:17: note: in expansion of macro 
‘log_link_warning_errno’
  324 | log_link_warning_errno(link, r, "Cannot %s IPv6 for 
interface %s: %m",
  | ^~
../src/network/networkd-link.c: In function ‘link_set_mtu’:
../src/network/networkd-link.c:324:79: note: format string is defined here
  324 | log_link_warning_errno(link, r, "Cannot %s IPv6 for 
interface %s: %m",
  | 
  ^~

The argument is field in a structure, and when the structure is
created, it is always set. It's hard to say for sure that it's never
null, but I think gcc must be confused when it says it's *always* null.

The same rpm compiles fine with gcc-9.0.1-0.8.fc30, gcc-9.0.1-0.8.fc31.
I'm writing to the mailing list instead of opening a bug because I'm not
really sure if gcc is at fault, or if systemd code is somehow buggy in
a non-obvious way... Has anyone else seen similar failures with the
latest gcc build?

Zbyszek

example failed koji scratch build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=33792874
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Stephen John Smoogen]

On Wed, 27 Mar 2019 at 09:39, Martin Gansser  wrote:
>
> same error !
>

No it is a different error. Your cert was used, but you can't ssh into
that server as it has no shells for users.
debug1: Authentication succeeded (publickey).
Authenticated to pkgs.fedoraproject.org ([209.132.181.4]:22).

The problem is that your .ssh/config is trying all your keys against
the server with the wrong username so fedpkg clone is not working. Set
up your .ssh/config to have some section like:


Host pkgs.fedoraproject.org
   User martinkg
   IdentityFile ~/.ssh/id_rsa.pub

And fedpkg should work

> packet_write_wait: Connection to 209.132.181.4 port 22: Broken pipe
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Non-responsive maintainer - Micah Roth

[Vitaly Zaitsev]

Hello!

According to Non-responsive Maintainer Policy I'm asking the maintainer
to respond and resolve issues with package zimlib.

RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1690432

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Martin Gansser]

same error !

ls -ls  ~/.fedora.upn
-rw-rw-r-- 1 martin martin 9 27. Mär 14:33 .fedora.upn

[martin@f30 ~]$ cat -v ~/.fedora.upn
martinkg

[martin@f30 ~]$ ssh -vvv marti...@pkgs.fedoraproject.org
OpenSSH_7.9p1, OpenSSL 1.1.1b FIPS  26 Feb 2019
debug1: Reading configuration data /home/martin/.ssh/config
debug1: /home/martin/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file 
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally 
pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file 
/etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok: 
[curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/martin/.ssh/config
debug1: /home/martin/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file 
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally 
pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file 
/etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok: 
[curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug2: resolving "pkgs.fedoraproject.org" port 22
debug2: ssh_connect_direct
debug1: Connecting to pkgs.fedoraproject.org [209.132.181.4] port 22.
debug1: Connection established.
debug1: identity file /home/martin/.ssh/id_rsa type 0
debug1: identity file /home/martin/.ssh/id_rsa-cert type -1
debug1: identity file /home/martin/.ssh/id_dsa type -1
debug1: identity file /home/martin/.ssh/id_dsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ecdsa type -1
debug1: identity file /home/martin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ed25519 type -1
debug1: identity file /home/martin/.ssh/id_ed25519-cert type -1
debug1: identity file /home/martin/.ssh/id_xmss type -1
debug1: identity file /home/martin/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat 
OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7*
 compat 0x0402
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to pkgs.fedoraproject.org:22 as 'martinkg'
debug3: hostkeys_foreach: reading file "/home/martin/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file 
/home/martin/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from pkgs.fedoraproject.org
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: 
rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openss

Re: Older Fedora AMIs to be deleted

[Sayan Chowdhury]

On Wed, Mar 27, 2019 at 11:43 AM Sayan Chowdhury  wrote:
>
> Hi,
>
> There has been a huge backlog of the nightly Fedora AMIs. So, today I
> will be deleting kicking off the process to purge the older AMIs.

By AMIs here I mean Amazon Machine Images.

-- 
Sayan Chowdhury 
GPG Fingerprint : 0F16 E841 E517 225C 7D13  AB3C B023 9931 9CD0 5C8B
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Tom Hughes]

On 27/03/2019 11:35, Martin Gansser wrote:


i get the error after copying my home folder /home/martin from a vmware with 
f29 to a new vmware with f30.

Cloning into 'lollypop'...
mar...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

What have i to do, that the fedpkg clone lollypop works again ?


Use the right username - your FAS username is martinkg not martin.

Easy way is to create ~/.fedora.upn containing your FAS username.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Martin Gansser]

the permissions are:

[martin@f30 ~]$ ll ~/.ssh/
insgesamt 20
-rw---. 1 martin martin  130  1. Okt 17:59 config
-rw---. 1 martin martin   65  1. Okt 13:25 config.orig
-rw---. 1 martin martin 3434  1. Okt 10:17 id_rsa
-rw---. 1 martin martin  737  1. Okt 10:17 id_rsa.pub
-rw---. 1 martin martin 1246  9. Sep 2016  known_hosts

and
[martin@f30 fedora-scm]$ ssh -vvv mar...@pkgs.fedoraproject.org
OpenSSH_7.9p1, OpenSSL 1.1.1b FIPS  26 Feb 2019
debug1: Reading configuration data /home/martin/.ssh/config
debug1: /home/martin/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file 
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally 
pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file 
/etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok: 
[curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/martin/.ssh/config
debug1: /home/martin/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file 
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org originally 
pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file 
/etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok: 
[curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug2: resolving "pkgs.fedoraproject.org" port 22
debug2: ssh_connect_direct
debug1: Connecting to pkgs.fedoraproject.org [209.132.181.4] port 22.
debug1: Connection established.
debug1: identity file /home/martin/.ssh/id_rsa type 0
debug1: identity file /home/martin/.ssh/id_rsa-cert type -1
debug1: identity file /home/martin/.ssh/id_dsa type -1
debug1: identity file /home/martin/.ssh/id_dsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ecdsa type -1
debug1: identity file /home/martin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ed25519 type -1
debug1: identity file /home/martin/.ssh/id_ed25519-cert type -1
debug1: identity file /home/martin/.ssh/id_xmss type -1
debug1: identity file /home/martin/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat 
OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7*
 compat 0x0402
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to pkgs.fedoraproject.org:22 as 'martin'
debug3: hostkeys_foreach: reading file "/home/martin/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file 
/home/martin/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from pkgs.fedoraproject.org
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: 
rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.

Re: fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Jakub Jelen]

Run ssh in debug mode:

ssh -vvv mar...@pkgs.fedoraproject.org

It will show you that you probably have bad permissions or owner on one
of your private keys in ~/.ssh/. They need to be owned by you and not
readable by anyone else (mode 0600).

Jakub

On Wed, 2019-03-27 at 11:35 +, Martin Gansser wrote:
> Hi,
> 
> i get the error after copying my home folder /home/martin from a
> vmware with f29 to a new vmware with f30.
> 
> Cloning into 'lollypop'...
> mar...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> Could not execute clone: Failed to execute command.
> 
> What have i to do, that the fedpkg clone lollypop works again ?
> 
> Thanks
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

fedpkg clone lollypop ... Permission denied (publickey), after copying my fedora cert to new vmware with f30

[Martin Gansser]

Hi,

i get the error after copying my home folder /home/martin from a vmware with 
f29 to a new vmware with f30.

Cloning into 'lollypop'...
mar...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

What have i to do, that the fedpkg clone lollypop works again ?

Thanks
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans

[Miro Hrončok]

On 27. 03. 19 11:07, Fabio Valentini wrote:
On a related topic, wasn't the orphan retirement process supposed to be amended, 
so that packages that still have co-maintainers will be assigned to one of those 
instead of being retired directly?


No. There was a quick kick of for this but it was turned down.
I personally am very against such proposals, as it makes maintained packages 
with plenty of "dead" maintainers almost immortal.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: "Basic graphics mode" feature and criterion discussion

[Kamil Paral]

On Tue, Mar 26, 2019 at 9:31 PM Chris Murphy 
wrote:

> My two cents:
>
> If there's a fallback option, and if the user selects it, they
> shouldn't end up in an unambiguous state. Right now we're seeing
> systems hanging. I'd rather see a crash than a hang where the user
> can't get to a shell, and sees no useful information on the screen
> that tells them why they're hung up; or even generically that "by now
> you should see a login screen and if you don't we've faceplanted
> somewhere, sorry".
>
> Maybe split the criterion:
>
> Basic criterion: installation media must have a basic video boot entry
> that uses the accepted fallback boot parameter(s), e.g. nomodeset. The
> criterion just means the media must have the menu entry, and that it
> passes something intentional for this purpose as a boot parameter.
>

Sounds good.


>
> Final criterion: installation media's basic video boot entry should
> either work (we get a successful graphical boot), or it should
> faceplant in some unambiguous way.
>

I'd rather require it to just work. Based on Ajax's response that the code
path is here to stay and they still need to support it because of VMs and
fresh new graphics cards.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans

[Fabio Valentini]

On Wed, Mar 27, 2019, 10:23 Miro Hrončok  wrote:

> On 20. 03. 19 9:57, Fabio Valentini wrote:
> > I've gone ahead with my proposal and created the Stewardship SIG.
> >
> > This includes the SIGs/Stewardship wiki page [0], the @stewardship-sig
> > FAS group [1], to which high-priority orphaned packages can be
> > assigned, and the stewardship-sig mailing list [2].
>  >
> > [0]: https://fedoraproject.org/wiki/SIGs/Stewardship
> > [1]: https://src.fedoraproject.org/group/stewardship-sig
> > [2]:
> https://lists.fedoraproject.org/admin/lists/stewardship-sig.lists.fedoraproject.org
>
> We need to claim more packages.
>
> I want to add the following to wiki:
>
> Adding a package to the SIG by a memeber
> 
>
> Since packages are always "owned" by users and never groups, in order to
> save a
> package from being retired, the member must claim it via a relneg ticket
> for
> themselves. Once they are main admin, they add the @stewardship-sig group
> as
> admin as well.
>
> Optionally, a bugzilla primary contact can be changed to @stewardship-sig
> in
> fedora-scm-requests.
>
> Adding a package to the SIG by a non-member
> ---
>
> TBD.
>

Right. I didn't realize that groups couldn't be primary admins, which makes
this all more complicated than it needs to be.

On a related topic, wasn't the orphan retirement process supposed to be
amended, so that packages that still have co-maintainers will be assigned
to one of those instead of being retired directly?
This would mean that @stewardship-sig could be admin for orphan packages,
without them being retired after some time.

Fabio



> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Dridi Boukelmoune]

On Wed, Mar 27, 2019 at 8:33 AM Nicolas Mailhot
 wrote:
>
> Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :
> > On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
> >  wrote:
>
> >> POSIX is dead as a shell compatibility target. You want to replace
> >> bash
> >> with something faster, by all means do it. With something that
> >> includes
> >> the GNU extensions like pushd/popd that most packagers expect today.
> >
> > Is there any reason to *ever* use pushd or popd in %build  or %install
> > today?
>
> That is totally the wrong attitude when you want to replace an
> implementation used for years by thousands of volunteer people in tens
> of thousands of interdependent files.

Again, not interested in the side of the discussion about replacing
bash as the default interpreter. This is a reminder that I would
personally prefer that bash weren't behind /bin/sh.

> It is used now, ergo packagers (the people who did the work) find it
> useful and convenient. You want them to do something else, you need to

I strongly disagree with the shortcut you make here.

The only use of pushd/popd I made in scriptlets was because it was
part of the Python packaging guidelines and I happen to maintain a
bunch of Python packages. So what I was doing then wasn't to choose
something I would deem useful and convenient but rather follow
guidelines to the best of my abilities.

So sure some people may find it useful and convenient, but others may
not even be aware or care that this construct is bash-specific so
please refrain from authoritatively introduce causality where there
isn't.

And on the convenience factor:

pushd somewhere
...
popd

is not harder than:

cd somewhere
...
cd -

The bash construct becomes interesting only when you need to stack
directories and not keep explicit track of where you are returning to.

This convenience I do not wish to remove from package maintainers,
even in scriptlets.

> make it worth their effort to something else. Winning 10 minutes of CPU
> time in a single pathological spec like gcc isn't it.
>
> The easiest way to make it worth their effort is to reduce the effort to
> zero, ie implement the capabilities commonly people use in your target
> replacement shell. That will be way way easier than trying to invent
> something compelling enough for them to change their habits. 10% of
> specs doing something is definitely common use.
>
> Another way is to take the conversion work unto yourself. But that does
> not solve the ongoing effort of helping packagers that try to use bash
> syntax in their spec because they need to do something, and find out it
> does not work, and give up because the additional work of looking for
> alternatives makes the cost/benefit analysis of packaging something
> negative. We have many packages where the cost/benefit hovers next to
> the limit, because we have nice volunteers that will go to their limits
> for Fedora.

Conversely whenever as a Fedora end user I run into a failing script
on a non Fedora system because it uses GNUisms it makes my life harder
to work on the multiple systems I have to deal with. By having bash as
/bin/sh Fedora defers the moment when I realize this is happening and
pain ensues. That is because Fedora is my main system and others are
second-class citizens in my workflow. I'd hate to elect a different
one as main my system for obvious reasons.

> Yet another is to propose a syntax with is clearly simpler, more
> expressive, more productive and better documented for humans (Not CPUs.
> CPUs do not get to vote). But, that solves "new spec and macro code"
> problem, not the "existing code" problem.
>
> Hazing people with negative terms like bashism never convinced anyone.

I'm sure some comments of this nature actually got a "fair enough"
response from a couple people.

> Especially when others are doing the work, not you. In my language, that
> is called “arriving after the battle”: complaining loudly at the people
> who sweated and blooded doing some work, that they didn't do it well
> enough, when you were safely somewhere else, at the time help was
> needed.

I am personally taking an opportunity to raise my concern about the
default shell seeing this after-the-battle thread.

Maybe I should start a different one on /bin/sh?

I was not aware of this until the link was shared in this thread but
this is an interesting read on the topic:

https://wiki.ubuntu.com/DashAsBinSh

If RPM goes somewhere on this topic [1] maybe that could be a change for f31?

Dridi

[1] https://github.com/rpm-software-management/rpm/issues/646
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Golang Packaging Guidelines: Feedback needed and appreciated

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Cc: "nicolas mailhot" , 
> gol...@lists.fedoraproject.org, jca...@redhat.com, "Discussion
> of RPM packaging standards and practices for Fedora" 
> 
> Sent: Friday, March 22, 2019 7:46:23 PM
> Subject: New Golang Packaging Guidelines: Feedback needed and appreciated
> 
> Hello Fedora people,
> 
> As you may or may not know, currently applied Golang packaging guidelines
> have always been simply a « draft ». Part of the new Go SIG mission is to
> update ours best practices and tooling. As such, Nicolas Mailhot designed  a
> new set of macros based on lua script to improve our current situation. As a
> result, we needed to draft new guidelines to reflect the future
> implementation
> of these macros.
> 
> I have written these new guidelines and I'd like to ask for your help in
> order to review them: both from current Go SIG packagers point of view and
> from novices in the matter, in order to make sure they are clear and
> understandable enough for everyone.
> 
> I have uploaded a mirror of the Guidelines on my FedoraPeople space:
> https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
> 
> Please, if you have 10 mn to spare, read them and send me feedback. If
> you
> wish you can also directly send me a Merge Request on Pagure:
> https://pagure.io/fork/eclipseo/packaging-committee/  (branch
> implement_golang_guidelines).
> 
> Best regards,
> 
> Robert-André
> 

Thanks, great work.

I unfortunately I have managed to just go trough roughly half of them, but they 
look great so far. There some parts that needs minor fix up, some a bit of 
expanding and IMO there are some that can be omitted with just pointer to the 
general guidelines.

I hope that I will be able to send some PRs and open some issue/enhancement 
requests by the next week. Also I will try to ask someone from the Fedora docs 
team to take a look at the non-technical side of the things.

Thanks again for writing the new guidelines draft,

JC

> 
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans

[Miro Hrončok]

On 20. 03. 19 9:57, Fabio Valentini wrote:

I've gone ahead with my proposal and created the Stewardship SIG.

This includes the SIGs/Stewardship wiki page [0], the @stewardship-sig
FAS group [1], to which high-priority orphaned packages can be
assigned, and the stewardship-sig mailing list [2].

>

[0]: https://fedoraproject.org/wiki/SIGs/Stewardship
[1]: https://src.fedoraproject.org/group/stewardship-sig
[2]: 
https://lists.fedoraproject.org/admin/lists/stewardship-sig.lists.fedoraproject.org


We need to claim more packages.

I want to add the following to wiki:

Adding a package to the SIG by a memeber


Since packages are always "owned" by users and never groups, in order to save a 
package from being retired, the member must claim it via a relneg ticket for 
themselves. Once they are main admin, they add the @stewardship-sig group as 
admin as well.


Optionally, a bugzilla primary contact can be changed to @stewardship-sig in 
fedora-scm-requests.


Adding a package to the SIG by a non-member
---

TBD.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Michal Konecny]

On 27/03/19 09:59, Pierre-Yves Chibon wrote:

On Tue, Mar 26, 2019 at 07:16:24PM +, Jeremy Cline wrote:

On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote:

On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote:


On 25/03/19 21:23, Jeremy Cline wrote:

On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:

"KF" == Kevin Fenzi  writes:

KF> Well, I find it unfortunate, does that count? :)

It is unfortunate, but note that it's unfortunate simply because of our
procedures.  Certainly it would be nice if the functionality for making
new branches and changing monitoring and some bugzilla settings were
integrated directly into src.fp.o; I won't argue against that. However,
that doesn't mean that changing those settings couldn't be accomplished
via some means other than a PR.

Possibilities I can think of include:

* Doing this via tickets in a manner similar to how branches are
     requested.  This would require teaching the ticket processing tools
     how to perform the operation, and writing some tool to submit the
     request.  Kind of a lot of overhead for a rare operation.

* Just storing this information in the package repository.  I've never
     understood why the system can't just extract this information from
     git.  I suspect there must be some reason related to security or
     resources consumption which prevents services from having a shallow
     git clone around from which to grab information like this, but
I'm not
     sure.


This is how it _should_ work. I just looked at the actual implementation
and hotness is doing an HTTP GET to the scm-requests repository. It
makes no sense, each repo should have a "monitoring" file or something.
  From the perspective of hotness, nothing changes. I have no idea why it
was put in a central repository.

I started to maintain the-new-hotness few months ago, so I don't know why
there is
some central repository. I agree with Jeremy that the best option is to have
monitoring
information directly in package repository.

The original idea, I believe, was to allow for the file to different per branch
without breaking the one branch for all releases that many packager like.

That doesn't make sense to me. Are you saying people might want
different files per branch, but also only have one branch in their dist-
git? Or is this only about the modularity/stream branching thing?

The thought was that people may want different behavior per branch without
having different files/content per branch.
So the-new-hotness notifies about 0.1 in EPEL and 1.0 in F29 and 2.0 in master.
This type of scenario becoming increasingly possible with stream branching.
I don't think the-new-hotness does anything like this. It just files the 
issue in Bugzilla that new version is out.


Michal


I'm trying to remember the thought process from back then, I'm not saying it was
perfect, that it is still valid nor that we cannot change it, just trying to
give some context :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Pierre-Yves Chibon]

On Tue, Mar 26, 2019 at 07:16:24PM +, Jeremy Cline wrote:
> On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote:
> > On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote:
> > > 
> > > 
> > > On 25/03/19 21:23, Jeremy Cline wrote:
> > > > On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:
> > > > > > > > > > "KF" == Kevin Fenzi  writes:
> > > > > 
> > > > > KF> Well, I find it unfortunate, does that count? :)
> > > > > 
> > > > > It is unfortunate, but note that it's unfortunate simply because of 
> > > > > our
> > > > > procedures.  Certainly it would be nice if the functionality for 
> > > > > making
> > > > > new branches and changing monitoring and some bugzilla settings were
> > > > > integrated directly into src.fp.o; I won't argue against that. 
> > > > > However,
> > > > > that doesn't mean that changing those settings couldn't be 
> > > > > accomplished
> > > > > via some means other than a PR.
> > > > > 
> > > > > Possibilities I can think of include:
> > > > > 
> > > > > * Doing this via tickets in a manner similar to how branches are
> > > > >     requested.  This would require teaching the ticket processing 
> > > > > tools
> > > > >     how to perform the operation, and writing some tool to submit the
> > > > >     request.  Kind of a lot of overhead for a rare operation.
> > > > > 
> > > > > * Just storing this information in the package repository.  I've never
> > > > >     understood why the system can't just extract this information from
> > > > >     git.  I suspect there must be some reason related to security or
> > > > >     resources consumption which prevents services from having a 
> > > > > shallow
> > > > >     git clone around from which to grab information like this, but
> > > > > I'm not
> > > > >     sure.
> > > > > 
> > > > 
> > > > This is how it _should_ work. I just looked at the actual implementation
> > > > and hotness is doing an HTTP GET to the scm-requests repository. It
> > > > makes no sense, each repo should have a "monitoring" file or something.
> > > >  From the perspective of hotness, nothing changes. I have no idea why it
> > > > was put in a central repository.
> > > I started to maintain the-new-hotness few months ago, so I don't know why
> > > there is
> > > some central repository. I agree with Jeremy that the best option is to 
> > > have
> > > monitoring
> > > information directly in package repository.
> > 
> > The original idea, I believe, was to allow for the file to different per 
> > branch
> > without breaking the one branch for all releases that many packager like.
> 
> That doesn't make sense to me. Are you saying people might want
> different files per branch, but also only have one branch in their dist-
> git? Or is this only about the modularity/stream branching thing?

The thought was that people may want different behavior per branch without
having different files/content per branch.
So the-new-hotness notifies about 0.1 in EPEL and 1.0 in F29 and 2.0 in master.
This type of scenario becoming increasingly possible with stream branching.

I'm trying to remember the thought process from back then, I'm not saying it was
perfect, that it is still valid nor that we cannot change it, just trying to
give some context :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fork a 119MB pagure project to updating monitoring?

[Michal Konecny]

On 26/03/19 20:16, Jeremy Cline wrote:

On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote:

On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote:



On 25/03/19 21:23, Jeremy Cline wrote:

On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:

"KF" == Kevin Fenzi  writes:


KF> Well, I find it unfortunate, does that count? :)

It is unfortunate, but note that it's unfortunate simply because 
of our
procedures.  Certainly it would be nice if the functionality for 
making

new branches and changing monitoring and some bugzilla settings were
integrated directly into src.fp.o; I won't argue against that. 
However,
that doesn't mean that changing those settings couldn't be 
accomplished

via some means other than a PR.

Possibilities I can think of include:

* Doing this via tickets in a manner similar to how branches are
    requested.  This would require teaching the ticket processing 
tools

    how to perform the operation, and writing some tool to submit the
    request.  Kind of a lot of overhead for a rare operation.

* Just storing this information in the package repository.  I've 
never
    understood why the system can't just extract this information 
from

    git.  I suspect there must be some reason related to security or
    resources consumption which prevents services from having a 
shallow

    git clone around from which to grab information like this, but
I'm not
    sure.



This is how it _should_ work. I just looked at the actual 
implementation

and hotness is doing an HTTP GET to the scm-requests repository. It
makes no sense, each repo should have a "monitoring" file or 
something.
 From the perspective of hotness, nothing changes. I have no idea 
why it

was put in a central repository.
I started to maintain the-new-hotness few months ago, so I don't 
know why

there is
some central repository. I agree with Jeremy that the best option is 
to have

monitoring
information directly in package repository.


The original idea, I believe, was to allow for the file to different 
per branch
without breaking the one branch for all releases that many packager 
like.


That doesn't make sense to me. Are you saying people might want
different files per branch, but also only have one branch in their dist-
git? Or is this only about the modularity/stream branching thing?

With modularity and stream branching, the ability to say: "I want PR 
filled for
this version to this branch and for that version to that branch" 
would be neat,
but this means having per-branch information that the-new-hotness 
will then

access and act upon.

That shouldn't require any configuration at all. hotness knows the new
version, and can inspect the branches in dist-git. If the project is
marked as following semantic versioning in release-monitoring.org, for
example, it can automatically make PRs against any branch with the same
X release. The fallback is to always make a PR against master and let
the packager cherry-pick as they like.

Having this outside of the dist-git repo was meant to make it easier 
to tweak
this file and have it diverge without having the different dist-git 
branches

diverge.


I think having it outside the repo makes it harder to use in every way.
I used to maintained hotness and release-monitoring.org and if you sat
me down and told me to turn on monitoring now that pkgdb is gone, I
probably wouldn't be able to do it in any reasonable amount of time. The
packager experience in this regard went from moderately difficult (you
have to know to poke in pkgdb) to downright horrendous.
Speaking about this, I should take these packages from you to ease your 
burden. :-)


- Jeremy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Nicolas Mailhot]

Le 2019-03-26 16:51, Japheth Cleaver a écrit :


The tooling around the original ecosystem seemed to have no rhyme or
reason with it, JPackage efforts never *fully* went anywhere,


JPackage certainly went somewhere, and this somewhere is Fedora/Red Hat.

To recap, JPackage existed because the JDK was not open source, 
preventing the packaging of Java software in Linux definitions. JPackage 
was successful first in making some of the key Java software of the time 
available on Linux systems on a controlled QAed way, and second in 
helping to convince SUN it needed to open the JDK code or it would lose 
control of the Java ecosystem (I can tell you that SUN and other big 
Java companies were definitely aware and looking at JPackage at the time 
SUN made its openjdk decision).


With the opening of the JDK the core reason for JPackage to exist 
outside distributions vanished and Red Hat promptly hired most of the 
core JPackage team and told it to work for RHEL/Fedora.


Therefore, since a decade at least the stewardship of defining of how to 
integrate Java software in Linux packages, and convincing upstream Java 
projects to do package-friendly things, has rested on Fedora and Red 
Hat. That is a much heavier burden than working with language 
communities that already agreed to be  Linux distribution friendly.


We see now it has not turned out well. I wasn't involved in this phase, 
so I have no idea why. Certainly, Red Hat, which is now the official 
maintainer of several OpenJDK versions upstream, which bought JBoss, 
which had several initiatives (like 389 server) that relied on Java 
parts, which is now part of IBM (another huge Java stakeholder), had all 
the required weight to make things happen. Certainly more than the small 
JPackage team (which managed a definite impact at the time).


I can only explain it with lots of complacency Red Hat and Fedora side, 
Java was not going anywhere, no one was ever going to write Enterprisey 
free software in another language, no need to expend a lot of effort to 
get past what JPackage had already achieved, the Java & JPackage 
investment was safe. Well Kubernetes was rewritten from Java to Go and 
is massively used in Enterprises today, and the whole generation of 
cloud-oriented enterprise software is looking like it will abandon Java 
altogether. You rip what you sow.


If it was just me I'd tell all the various free software Java teams 
within Red Hat/Fedora to agree on a single Java component tech (probably 
Java modules), define a standard FHS-compatible materialization of those 
components, define basic sanity versioning rules ("if component N 
version X needs itself to build, it MUST work with version X-1") and 
then set a deadline, after which Red Hat/Fedora releases that do not 
conform to this model are not accepted anymore. That would get the ball 
rolling Java dev side.


But it's not me and I have decided quite a long time ago to work on 
other things than Java software, so whatever actually happens is up to 
Fedora and Red Hat/IBM leadership. I certainly hope that someone within 
Fedora instances alerted the main sponsor that things were starting to 
burn.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Nicolas Mailhot]

Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :

On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
 wrote:


POSIX is dead as a shell compatibility target. You want to replace 
bash
with something faster, by all means do it. With something that 
includes

the GNU extensions like pushd/popd that most packagers expect today.


Is there any reason to *ever* use pushd or popd in %build  or %install 
today?


That is totally the wrong attitude when you want to replace an 
implementation used for years by thousands of volunteer people in tens 
of thousands of interdependent files.


It is used now, ergo packagers (the people who did the work) find it 
useful and convenient. You want them to do something else, you need to 
make it worth their effort to something else. Winning 10 minutes of CPU 
time in a single pathological spec like gcc isn't it.


The easiest way to make it worth their effort is to reduce the effort to 
zero, ie implement the capabilities commonly people use in your target 
replacement shell. That will be way way easier than trying to invent 
something compelling enough for them to change their habits. 10% of 
specs doing something is definitely common use.


Another way is to take the conversion work unto yourself. But that does 
not solve the ongoing effort of helping packagers that try to use bash 
syntax in their spec because they need to do something, and find out it 
does not work, and give up because the additional work of looking for 
alternatives makes the cost/benefit analysis of packaging something 
negative. We have many packages where the cost/benefit hovers next to 
the limit, because we have nice volunteers that will go to their limits 
for Fedora.


Yet another is to propose a syntax with is clearly simpler, more 
expressive, more productive and better documented for humans (Not CPUs. 
CPUs do not get to vote). But, that solves "new spec and macro code" 
problem, not the "existing code" problem.


Hazing people with negative terms like bashism never convinced anyone. 
Especially when others are doing the work, not you. In my language, that 
is called “arriving after the battle”: complaining loudly at the people 
who sweated and blooded doing some work, that they didn't do it well 
enough, when you were safely somewhere else, at the time help was 
needed.


Sincerely,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Miroslav Suchý]

Dne 26. 03. 19 v 18:38 Tomasz Kłoczko napsal(a):
> If yes I can propose simpler solution like create .post_build_preserve.lst 
> file in source build root and whatever will
> be added to that file should be archived in some 
> --.tar.xz file to be accessible over koji
> web interface.
> If such file will be created during manually executed "rpmbuild -ba" it will 
> not leave any garbage behind or will be no
> flooding stdout during build.

In fact, this can be quite easy, because we already have:

https://github.com/rpm-software-management/mock/wiki/Plugin-ChrootScan

I will be happy to review and merge enhancement to this plugin, which read or 
add to the regexes from a file.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is SELinux enforcing on the koji builders?

[Miroslav Suchý]

Dne 27. 03. 19 v 4:33 Jerry James napsal(a):
> Thanks for confirming.  I am really puzzled.  I can consistently get
> good builds in mock, across all arches I am able to test, and
> consistently get segfaults on every single arch when building in koji.
> I'm going to have to do the trick of dumping a core file into the
> build logs to figure out what is happening, I guess.


Hmmm, it would be nice if we can send ABRT reports from crashes, which happens 
during a build.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org