Re: Self Introduction

[Michal Novotny]

I cannot take your review right now but i just want to say: Welcome!

Michal

On Thu, Aug 23, 2018 at 10:11 AM Manas Mangaonkar 
wrote:

> Hello,
>
> My name is Manas,i am a Computer Engineering student at the University of
> Mumbai.
>
> i recently began packaging with my first package being this
> ,and
> would love to work on even more packages. I am wish to join the packager
> group,thus seeking sponsorship.
>
> You may find the bugzilla review request for my first package here
> .
>
> Learned about the fedora community effort during Google summer of
> code,joined the mailing list saw a issue open and began working on it. Have
> been using various tux distro's since a teen always wanted to
> contribute,have been self taught.  Learned the ropes of packaging using
> the irc fedora chat room.
>
> I am mostly interested in packaging and maintaining python packages as i
> use python a lot and would love to give back to the community.
>
> My Github 
>
> - Manas Mangaonkar
> ___
> 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/message/GSZFIHQTY6AEENZ3YEHXYEDSVMW7SAQI/
>
___
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: Fwd: fedora-tagger sunset - week post F29 beta freeze

[Petr Pisar]

On 2018-08-26, Mattia Verga  wrote:
>> On 24.8.2018 10:04, Clement Verna wrote:
>> 
>> Oh no, the press-random-arrows-to-get-badges app will be gone :D
>
> Actually, I would find tags useful for searching packages related to
> a specific field: for example, I would like to search for 'astronomy'
> and get a list of all packages related to that topic.
>
> It would be nice if tags could be added directly in the rpm specfile.
> Or at least in the appdata file.
>
 :(

-- Petr
___
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: dokuwiki packagers unresponsive

[Artur Iwicki]

Thanks for the PR! I've merged it and used it to build the updated dokuwiki 
package for Rawhide and F29.

I've also done builds for F28 and F27, though I'm wondering if they should be 
pushed to updates - on one hand, there's the risk of breaking changes. On the 
other, the package has multiple issues and leaving it out of date leaves users 
vulnerable to security bugs.
___
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: Summary/Minutes from yesterday's FESCo meeting (2018-08-20)

[pravin....@gmail.com]

On Thu, 23 Aug 2018 at 17:02, Kevin Kofler  wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
> > #1957 F29 Change: Liberation Fonts 2
> > https://pagure.io/fesco/issue/1957
> > DECISION (+6, 0, 0)
>
> Sigh!
>
> Really nothing has changed since the decision in Fedora 19 to stick with
> Liberation 1, only 4 years have passed without any changes whatsoever to
> the
> "Liberation 2" fonts.
>
> Liberation 1 is no longer developed upstream, but as far as I can tell,
> neither is Liberation 2.
>

Agree not much happened in upstream. Its because i was busy in other
project and also conflict between Liberation 1  and 2. Basic idea behind
Liberation 2 was to stop bug fixing on Liberation 1 and develop 2 for
future.  But still we were using Liberation 1.
Now, we have new maintainer for Liberation Fonts and with clear direction
for Liberation 2, he will do the required bug-fixes and enhancements into
it. He is already working on adding BitCoin glyph to it.


>
> "Liberation 2" fonts are essentially rebranded Google Croscore fonts.


No, Liberation 2 are not just re-branded.  We have done bug-fixing and also
added Serbian language support into it. [1]

And
> those Google Croscore fonts are, in fact, already packaged in Fedora
> (https://src.fedoraproject.org/rpms/google-croscore-fonts). Why can't we
> just let Liberation be Liberation and Croscore be Croscore?
>

Unlike Liberation, Google just released .ttf version for there fonts. I
have not see any way, to fix issues in Noto upstream [2] and rebuilt that
.ttf.
In Liberation 2, we have source file .sfd, one can fix, provide patch.

Thanks Kevin for raising this point, i assure will get more development on
Liberation 2 soon. Bug list for Liberation 2 [3]

Thanks,
Pravin Satpute

1. https://github.com/liberationfonts/liberation-fonts/commits/master
2. https://github.com/googlei18n/noto-fonts/tree/master/hinted
3.
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=liberation-fonts&list_id=931&product=Fedora&query_format=advanced
___
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: dokuwiki packagers unresponsive

[Solomon Peachy]

On Mon, Aug 27, 2018 at 08:44:40AM -, Artur Iwicki wrote:
> I've also done builds for F28 and F27, though I'm wondering if they 
> should be pushed to updates - on one hand, there's the risk of 
> breaking changes. On the other, the package has multiple issues and 
> leaving it out of date leaves users vulnerable to security bugs. 

The dokuwiki packages shipped by Fedora since F24 simply *do not work* [1], 
so it's hard to argue against providing an update that will only improve 
the situation.

[1] The package is so broken that it's impossible to actually take 
advantage of those security vulnerabilities.  It's perhaps the 
only upside of a package that can serve nothing more than 
'Error 500' codes.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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: Self Introduction

[Manas Mangaonkar]

Okay, I am happy to be finally joining the effort.

- Manas

On Mon, Aug 27, 2018 at 12:52 PM, Michal Novotny  wrote:

> I cannot take your review right now but i just want to say: Welcome!
>
> Michal
>
> On Thu, Aug 23, 2018 at 10:11 AM Manas Mangaonkar <
> manasmangaon...@gmail.com> wrote:
>
>> Hello,
>>
>> My name is Manas,i am a Computer Engineering student at the University of
>> Mumbai.
>>
>> i recently began packaging with my first package being this
>> ,and
>> would love to work on even more packages. I am wish to join the packager
>> group,thus seeking sponsorship.
>>
>> You may find the bugzilla review request for my first package here
>> .
>>
>> Learned about the fedora community effort during Google summer of
>> code,joined the mailing list saw a issue open and began working on it. Have
>> been using various tux distro's since a teen always wanted to
>> contribute,have been self taught.  Learned the ropes of packaging using
>> the irc fedora chat room.
>>
>> I am mostly interested in packaging and maintaining python packages as i
>> use python a lot and would love to give back to the community.
>>
>> My Github 
>>
>> - Manas Mangaonkar
>> ___
>> 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/message/GSZFIHQTY6AEENZ3YEHXYEDSVMW7SAQI/
>>
>
> ___
> 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

Corrected license of 'screen'

[Václav Doležal]

Hi,

I have corrected license of 'screen' from GPLv2+ to GPLv3+. It has been 
licensed under GPLv3+ since version 4.2.0.


Regards,
Václav Doležal
___
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: [modularity] Managing module lifecycles — let's talk!

[Adam Samalik]

On Wed, Aug 22, 2018 at 5:48 PM Owen Taylor  wrote:

> What are the possibilities for how a stream is maintained? The cases I can
> think of:
>
>  * Indefinite - rolling forward with upstream - "master" "stable" etc.
>  * Tied to an upstream version and it's EOL -  a "2.1" stream of django
>
 * [less common] tied to a particular version of Fedora - the "29" stream
> of flatpak-runtime
>
> How do your proposed mechanisms handle these cases?
>

The first proposal isn't really a proposal, it's basically the current
state. As it is now, it would only handle a specific date. However, we
could extend it with an "infinite" and "specific fedora release" options
easily, I believe.

The second one would work with all three cases with a little attention of
the maintainer:

* case 1, indefinite: The maintainer would keep it in rawhide and the
package would continue rolling.
* case 2, a specific date: The maintainer would keep it in rawhide until
the EOL date approaches, after which they would just remove it from rawhide
by setting its EOL to the latest release.
* case 3, a specific release: The maintainer would set the EOL to be this
specific release.


>
> It seems like by trying to automatically determine an EOL, the intent of
> module maintainer might not be respected - e.g. you might include a package
> with a short EOL intending to rebase to newer versions as necessary.
>

Good point!

>
> What if we just had a streams.yaml file checked into the master branch of
> git and gave the maintainer the flexibility to set an EOL (with defaults if
> no streams.yaml is present, perhaps.) We could still write tools to check
> the EOL against that of dependencies and components, but that would just be
> used to flag problems.
>

Something like this was one of my initial thoughts as well, glad you
brought it up. Having a "forced module EOL", maybe as an optional override
could be a good idea.


>
> Owen
>
>
> On Wed, Aug 22, 2018 at 6:39 AM, Adam Samalik  wrote:
>
>> During the Modularity WG meeting yesterday [1], we've touched the topic
>> of module lifecycles. Even though there are some ideas in the air as well
>> as some code written, we haven't reached a state in which we would know how
>> exactly to deal with it. So I'd like to discuss it here with a wider
>> audience, and review it again in the next Modularity WG meeting.
>>
>> == Introduction: (feel free to skip this if you know what I'm talking
>> about)
>>
>> In concept, modules live more or less independently from the Fedora
>> release. So while traditional packages in Fedora are branched for each
>> Fedora release (such as f27, f28, etc.), and each branch is maintained for
>> the lifetime of its release (~13 months), modular packages and modules
>> themselves are branched in any way it makes most sense for the software
>> (mostly major version, such as nodejs 6, nodejs 8, nodejs 10, etc.) — we
>> call these "stream branches" in dist-git and "streams" when we talk about
>> modules. This has two implications, one of which is the topic of this email:
>>
>> 1) One module stream can be built and maintained for multiple Fedora
>> releases — that means it's lifecycle can be longer than just a single
>> Fedora release — and that's what this email is about
>> 2) One Fedora release can have multiple streams of modules — also cool,
>> but not discussed in this email
>>
>> If you're a visual type, watch this short animation (38 seconds):
>> https://www.youtube.com/watch?v=5VQljp1p_ok
>>
>> == The problem + what we've decided already
>>
>> Simply put, we need to have a way of indicating how long each module
>> stream lives. This should be probably defined at the package level, because
>> packages the actual software that is being maintained.
>>
>> At Flock 2017 we've discussed this topic and reached a following
>> decision: Module stream's lifecycles should be somehow aligned with Fedora
>> releases — in particular, they should be retired only at the end of a
>> release. That way we prevent a situation where different module streams
>> could be retired at any point in time, which would be pretty messy. On the
>> other hand, introducing new streams at any time should be possible, the
>> same way as we add new packages today.
>>
>> == Approaches
>>
>> Option 1: The current, yet unfinished approach
>>
>> We specify an EOL (end of life) date for each stream branch of individual
>> packages. This is done when requesting a new stream branch for a package
>> [2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored,
>> but not yet consumed by anything.
>>
>> The next step would be having the build system to be smart enough to:
>>
>> 1) Figure out the module's EOL based on its packages' EOLs.
>> 2) Only build the module for the Fedora releases that have their EOL
>> before the module stream's EOL.
>>
>> There is a caveat, however:  Giving dates like this might be hard for the
>> maintainer. The upstream project might not have one, etc. In that case the
>> maintainer need

Re: Golang SIG primary goals?

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: gol...@lists.fedoraproject.org, devel@lists.fedoraproject.org
> Sent: Friday, August 24, 2018 4:42:03 PM
> Subject: Golang SIG primary goals?
> 
> Hey guys and gals,
> 
> Can we start to discuss this SIG goals? What each of you are expecting

IMO meeting would be best so we can introduce ourselves. See my other email :)

I have taken liberty and have created pagure group 
https://pagure.io/group/GoSIG for the SIG and tracking project 
https://pagure.io/GoSIG/go-sig for all the ideas and work. I have added all 
folks listed in the wiki page to the group. Also there is issue for adding new 
members(or those that I have forgotten to add) 
https://pagure.io/GoSIG/go-sig/issue/1.

> A few ideas:
> 
>  - Making https://fedoraproject.org/wiki/More_Go_packaging official and
> working on bringing them to EPEL7

Don't forget about EPEL6, too. ;)

I have created issue for the guidelines at the tracker. Along with some other 
that popped on my mind.

> 
>  - Assigning current Go packages to the SIG so each member of the SIG can
>  work
> on them, similar to https://src.fedoraproject.org/group/rust-sig
> Many Google packages are inter-dependent, this would ease synchronising them.
> 
>  - Working toward packaging more: I'm thinking about unbundling kubernetes
>  and
> docker.
> 
>  - Developing tools to maintain up-to-date our current set of Go packages,
> some of which are left outdated since their creation.
> 
> Any other ideas? I'd like to move forward as soon as possible.

Would you please create tracking 
issues(https://pagure.io/GoSIG/go-sig/new_issue) for the above ideas(or any 
other you might have) in the pagure project so we can discuss it there with 
better tracking/threading?

JC

> 
> Best regards,
> 
> Robert-André
> 
> ___
> 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/message/JII4CSPFA4PNTE6TCR477U7RDSU4Y3Z3/
> 
___
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: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

[Miroslav Suchý]

Dne 22.8.2018 v 22:41 Zbigniew Jędrzejewski-Szmek napsal(a):
> Can we patch rpm not to show this useless line?

https://github.com/rpm-software-management/rpm/issues/534

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: python-sshtunnel?

[Dusty Mabe]

On 08/26/2018 07:11 PM, Miro Hrončok wrote:
> On 27.8.2018 01:03, Joseph D. Wagner wrote:
>> I'd be happy to help, but I feel overwhelmed.  I've never used the whole 
>> stack of koji, src.fedoraproject.org, fedpkg, etc.
>>
>> I need someone to help walk me through the first one.
> 
> Feel free to ping me on #fedora-python when I'm online and we can work 
> on that together. I can also get you sponsored if you are not yet.
> 

Thanks Miro!! Welcome Joseph! 
___
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: Idea: let's use Pagure to track Changes

[Adam Samalik]

I would definitely love that!

Having the ability to list all changes at a single place, comment, and even
organise them by tags seems like a way forward.

BTW I know that Pagure stores issues in git, so that could solve the
history problem, although I don't know how exactly is that implemented.

On Fri, Aug 24, 2018 at 3:50 PM Ben Cotton  wrote:

> Thanks for the feedback so far. Some of the responses are fairly
> similar, so I'll try to clump them together:
>
> > Vote in the Change ticket or a FESCo ticket?
>
> The intent, for now, is to still have FESCo vote in a separate ticket,
> mostly for their visibility. Alternatively, I could tag all FESCo
> members in the change ticket. This part of the process is no different
> from what we do now, so I'd leave it to FESCo to decide where they
> would want to vote.
>
> > Three repos is too many repos
>
> Yes! As with the above, one option would be to have the Docs team use
> the Changes repo for release notes tracking as well. Again, the issue
> is visibility, but if they're open to using the Changes repo as the
> single source of truth, I think that works out better for everyone.
>
> > Changes as Markdown files
>
> This does address the history, but it loses the metadata aspect that
> makes the current process clunky. Being able to script against the
> metadata fields eliminates trying to parse the wiki text and hope
> nothing too unusual is in there. One option would be to change it so
> that the markdown file is submitted as a PR, but then the change is
> submitted as an issue that points to the PR. It's a little bit
> clunkier, but it would give us both edit history and some enforced
> structure. The downside means that if I were to automate, e.g.,
> sending the announcement email, the script would have to find the PR
> from the issue and then find the appropriate file from the PR.
>
> The proposal isn't what I'd come up with if time and resources were no
> concern, but it's what I can come up with that stands a chance of
> being implemented. I'm really intrigued by the idea of using markdown
> files both from an easier-for-submission standpoint and also from a
> "here's the entire history of our changes" standpoint. I'm just
> concerned that it will make all of the backend processing more
> cumbersome. If there's something I'm missing on this, I'd love to
> explore the idea some more.
>
> > But what about Bugzilla?
>
> I agree that the ability to link other BZ issues to the Changes is
> helpful, but in my limited experience so far, it's not a common use
> case.
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> ___
> 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/message/GUYCGNJUZCBOFL2R7BFTG6RWCJKSGDHA/
>


-- 

Adam Šamalík
---
Software Engineer
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

Summary/Minutes from today's FESCo Meeting (2018-08-27)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2018-08-27)
=


Meeting started by contyk at 15:00:08 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-08-27/fesco.2018-08-27-15.00.log.html
.



Meeting summary
---
* init process  (contyk, 15:00:28)

* #1970 Action needed: Orphan packages will be retired if they remain
  orphaned for six weeks  (contyk, 15:02:16)
  * LINK: https://pagure.io/fesco/issue/1970   (contyk, 15:02:23)
  * LINK: https://pagure.io/releng/pull-request/6895 is a PR to update
th e script, the problem there was that previously orphan status was
per branch, now it is per package  (tyll, 15:17:10)
  * https://pagure.io/releng/pull-request/6895  (zbyszek, 15:21:00)
  * AGREED: The plan is: 1. contact factory 2 to see if they want to
finish the script, 2. once the script is ready, send info to all
co-maintainers and fedora-devel, 3. after a week reassign to one
co-maintainer, if no co-maintainers, retire (+6, 0, 0)  (contyk,
15:46:58)

* #1935 [Security] Remove packages which has a consistent bad security
  record from the distribution  (contyk, 15:48:36)
  * LINK: https://pagure.io/fesco/issue/1935   (contyk, 15:48:42)
  * AGREED: If a CRITICAL or IMPORTANT security issue is currently open
against a package, or a security issue of lower severity has been
open for at least 6 months, four weeks before the branch point a
procedure similar to long-standing FTBFS will be triggered
immediately, with 8 weeks of weekly notifications to maintainers and
subsequent orphaning and then subsequent removal from distribution.
This  (contyk, 15:59:52)
  * AGREED: applies to all packages, not just leaf. (+6, 0, -0)
(contyk, 16:00:25)

* #1967 Fedora 29 incomplete changes  (contyk, 16:00:40)
  * LINK: https://pagure.io/fesco/issue/1967   (contyk, 16:00:48)
  * LINK: https://pagure.io/pungi-fedora/pull-request/631   (bowlofeggs,
16:02:52)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1598405
(bowlofeggs, 16:03:10)
  * ACTION: bowlofeggs will contact mclassen to get an update
(bowlofeggs, 16:04:10)
  * LINK:

https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/V4AMRMWOWIAPZFQTLUBWNDD3FU5OQOZX/
(bcotton, 16:12:01)
  * AGREED: "Rename Atomic Workstation to Silverblue": let folks work on
it today, if not done in time for freeze, they can ask for an
exception or move to f30. (+7, 0, -0)  (contyk, 16:32:34)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&classification=Fedora&component=Changes%20Tracking&list_id=9313935&product=Fedora&query_format=advanced&version=29
(nirik, 16:33:52)
  * AGREED: "update festival to 2.5": Defer to F30 unless implemented by
F29 devel freeze (+6, 0, -0)  (contyk, 16:49:18)
  * ACTION: bowlofeggs will ask for an update from the change owner
(bowlofeggs, 16:50:34)
  * AGREED: cloud image updates: defer and check next week, it's unclear
to me what would need to be done before beta as this change deals
with post GA content (+7, 0, -0)  (contyk, 16:51:37)

* Next week's chair  (contyk, 16:52:03)
  * Due to holidays, the next meeting will be on September 10  (contyk,
16:59:39)
  * ACTION: bowlofeggs will chair the next meeting  (contyk, 16:59:56)

* Open Floor  (contyk, 17:00:03)

Meeting ended at 17:02:34 UTC.

Action Items

* bowlofeggs will contact mclassen to get an update
* bowlofeggs will ask for an update from the change owner
* bowlofeggs will chair the next meeting

Action Items, by person
---
* bowlofeggs
  * bowlofeggs will contact mclassen to get an update
  * bowlofeggs will ask for an update from the change owner
  * bowlofeggs will chair the next meeting

People Present (lines said)
---
* bowlofeggs (158)
* contyk (94)
* sgallagh (56)
* tyll (53)
* zbyszek (51)
* nirik (40)
* maxamillion (28)
* zodbot (20)
* stickster (11)
* pingou (11)
* bcotton (9)
* mclasen (9)
* jsmith (9)
* puiterwijk (1)
* tyll_ (1)
* jwb (1)
* walters (1)


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: [atomic-devel] [CoreOS] Re: Re: Starting a Container SIG

[Clement Verna]

On Sat, 25 Aug 2018 at 15:29, Dusty Mabe  wrote:

>
>
> On 08/24/2018 10:24 AM, Brian Clark wrote:
> > Are there any minutes from this meeting?
>
> Here ya go:
>
>
> https://meetbot.fedoraproject.org/fedora-containers/2018-08-23/fedora_container_sig_kickoff.2018-08-23-15.00.html


 We also have a poll going on to try to find the best time for our meetings.

See
https://discussion.fedoraproject.org/t/container-sig-initial-irc-meeting-august-23-2018-15-00-utc-on-fedora-containers/258/9


>
> Mostly look at the logs since we didn't have any big ticket items.
> ___
> 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

Fedora 29 compose report: 20180827.n.0 changes

[Fedora Branched Report]

OLD: Fedora-29-20180826.n.0
NEW: Fedora-29-20180827.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   32
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   487.61 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-29-20180827.n.0.iso
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-29-20180827.n.0-sda.raw.xz
Image: LXQt live i386
Path: Spins/i386/iso/Fedora-LXQt-Live-i386-29-20180827.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  bison-3.0.5-1.fc29
Old package:  bison-3.0.4-9.fc28
Summary:  A GNU general-purpose parser generator
RPMs: bison bison-devel bison-runtime
Size: 4.31 MiB
Size change:  -85.81 KiB
Changelog:
  * Thu Jul 12 2018 Fedora Release Engineering  - 
3.0.4-10
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

  * Tue Aug 14 2018 Patsy Griffin Franklin  - 3.0.5-1
  - _IO_ftrylockfile is obsolete as part of the removal of libio.h
  - Build requires gcc-c++ to fix build failure. (#1603491)
  - Update to bison 3.0.5 (#1583179)


Package:  crawl-0.22.0-1.fc29
Old package:  crawl-0.21.1-5.fc29
Summary:  Roguelike dungeon exploration game
RPMs: crawl crawl-common-data crawl-tiles crawl-tiles-data
Size: 52.07 MiB
Size change:  622.98 KiB
Changelog:
  * Sat Aug 11 2018 Antonio Trande  - 0.22.0-1
  - Update to 0.22.0 (bz#1614779)


Package:  flameshot-0.6.0-1.fc29
Old package:  flameshot-0.5.1-2.fc29
Summary:  Powerful and simple to use screenshot software
RPMs: flameshot
Size: 1.63 MiB
Size change:  106.40 KiB
Changelog:
  * Sun Aug 26 2018 Vitaly Zaitsev  - 0.6.0-1
  - Updated to version 0.6.0.


Package:  globus-gsi-proxy-core-8.6-8.fc29
Old package:  globus-gsi-proxy-core-8.6-7.fc29
Summary:  Globus Toolkit - Globus GSI Proxy Core Library
RPMs: globus-gsi-proxy-core globus-gsi-proxy-core-devel 
globus-gsi-proxy-core-doc
Size: 446.46 KiB
Size change:  -4.88 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 8.6-8
  - Increase default proxy key size to 2048 bits


Package:  globus-gssapi-gsi-13.8-3.fc29
Old package:  globus-gssapi-gsi-13.8-2.fc29
Summary:  Globus Toolkit - GSSAPI library
RPMs: globus-gssapi-gsi globus-gssapi-gsi-devel globus-gssapi-gsi-doc
Size: 677.93 KiB
Size change:  -7.70 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 13.8-3
  - Avoid TLS 1.3 - needs porting


Package:  globus-proxy-utils-6.19-8.fc29
Old package:  globus-proxy-utils-6.19-7.fc29
Summary:  Globus Toolkit - Globus GSI Proxy Utility Programs
RPMs: globus-proxy-utils
Size: 312.23 KiB
Size change:  -22.21 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 6.19-8
  - Increase default proxy key size to 2048 bits


Package:  go-compilers-1-32.fc29
Old package:  go-compilers-1-30.fc29
Summary:  Go language compilers for various architectures
RPMs: go-compilers-golang-compiler
Size: 17.83 MiB
Size change:  9.97 MiB
Changelog:
  * Fri Jul 13 2018 Fedora Release Engineering  - 1-31
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

  * Sun Aug 26 2018 Jan Chaloupka  - 1-32
  - Rebuild the golist with go1.11


Package:  golang-googlecode-go-crypto-0-0.24.20180716gita49355c.fc29
Old package:  golang-googlecode-go-crypto-0-0.23.20180716gita49355c.fc29
Summary:  Supplementary Go cryptography libraries
RPMs: golang-golangorg-crypto-devel
Size: 5.46 MiB
Size change:  7.05 KiB
Changelog:
  * Sun Aug 26 2018 Jan Chaloupka  - 0-0.24.gita49355c
  - Rebuild to accomodate golist rebuild
resolves: #1615497


Package:  graphite2-1.3.10-6.fc29
Old package:  graphite2-1.3.10-5.fc28
Summary:  Font rendering capabilities for complex non-Roman writing systems
RPMs: graphite2 graphite2-devel
Size: 872.06 KiB
Size change:  -72.50 KiB
Changelog:
  * Fri Jul 13 2018 Fedora Release Engineering  - 
1.3.10-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild


Package:  jd-2.8.9.180424-3.fc29
Old package:  jd-2.8.9.180424-2.fc29
Summary:  A 2ch browser
RPMs: jd
Size: 8.51 MiB
Size change:  -502.61 KiB
Changelog:
  * Mon Aug 27 2018 Mamoru TASAKA  - 2.8.9.180424-3
  - Apply upstream patch to suppress GLib deprecation warning


Package:  kiwi-9.16.12-1.fc29
Old package:  kiwi-9.16.0-3.fc29
Summary:  Flexible operating system image builder
RPMs: dracut-kiwi-lib dracut-kiwi-live dracut-kiwi-oem-dump 
dracut-kiwi-oem-repart dracut-kiwi-overlay kiwi-cli kiwi-pxeboot 
kiwi-systemdeps kiwi-tools python3

Fedora rawhide compose report: 20180827.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180826.n.0
NEW: Fedora-Rawhide-20180827.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:1
Upgraded packages:   29
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:6.44 MiB
Size of upgraded packages:   524.68 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20180827.n.0.x86_64.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: mingw-libdb-5.3.28-4.fc29
Summary: MinGW build of The Berkeley DB database library
RPMs:mingw32-libdb mingw32-libdb-static mingw32-libdb-utils mingw64-libdb 
mingw64-libdb-static mingw64-libdb-utils
Size:6.44 MiB


= UPGRADED PACKAGES =
Package:  crawl-0.22.0-1.fc30
Old package:  crawl-0.21.1-5.fc29
Summary:  Roguelike dungeon exploration game
RPMs: crawl crawl-common-data crawl-tiles crawl-tiles-data
Size: 52.07 MiB
Size change:  622.54 KiB
Changelog:
  * Sat Aug 11 2018 Antonio Trande  - 0.22.0-1
  - Update to 0.22.0 (bz#1614779)


Package:  deepin-terminal-3.0.3-1.fc30
Old package:  deepin-terminal-3.0.1-1.fc29
Summary:  Default terminal emulation application for Deepin
RPMs: deepin-terminal deepin-terminal-data
Size: 1.57 MiB
Size change:  -2.78 KiB
Changelog:
  * Sat Aug 25 2018 mosquito  - 3.0.3-1
  - Update to 3.0.3


Package:  flameshot-0.6.0-1.fc30
Old package:  flameshot-0.5.1-2.fc29
Summary:  Powerful and simple to use screenshot software
RPMs: flameshot
Size: 1.63 MiB
Size change:  105.54 KiB
Changelog:
  * Sun Aug 26 2018 Vitaly Zaitsev  - 0.6.0-1
  - Updated to version 0.6.0.


Package:  globus-gsi-proxy-core-8.6-8.fc30
Old package:  globus-gsi-proxy-core-8.6-7.fc29
Summary:  Globus Toolkit - Globus GSI Proxy Core Library
RPMs: globus-gsi-proxy-core globus-gsi-proxy-core-devel 
globus-gsi-proxy-core-doc
Size: 446.42 KiB
Size change:  -4.92 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 8.6-8
  - Increase default proxy key size to 2048 bits


Package:  globus-gssapi-gsi-13.8-3.fc30
Old package:  globus-gssapi-gsi-13.8-2.fc29
Summary:  Globus Toolkit - GSSAPI library
RPMs: globus-gssapi-gsi globus-gssapi-gsi-devel globus-gssapi-gsi-doc
Size: 677.88 KiB
Size change:  -7.75 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 13.8-3
  - Avoid TLS 1.3 - needs porting


Package:  globus-proxy-utils-6.19-8.fc30
Old package:  globus-proxy-utils-6.19-7.fc29
Summary:  Globus Toolkit - Globus GSI Proxy Utility Programs
RPMs: globus-proxy-utils
Size: 312.24 KiB
Size change:  -22.20 KiB
Changelog:
  * Sun Aug 26 2018 Mattias Ellert  - 6.19-8
  - Increase default proxy key size to 2048 bits


Package:  go-compilers-1-32.fc30
Old package:  go-compilers-1-30.fc29
Summary:  Go language compilers for various architectures
RPMs: go-compilers-golang-compiler
Size: 17.83 MiB
Size change:  9.97 MiB
Changelog:
  * Fri Jul 13 2018 Fedora Release Engineering  - 1-31
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

  * Sun Aug 26 2018 Jan Chaloupka  - 1-32
  - Rebuild the golist with go1.11


Package:  golang-googlecode-go-crypto-0-0.24.20180716gita49355c.fc30
Old package:  golang-googlecode-go-crypto-0-0.23.20180716gita49355c.fc29
Summary:  Supplementary Go cryptography libraries
RPMs: golang-golangorg-crypto-devel
Size: 5.46 MiB
Size change:  7.04 KiB
Changelog:
  * Sun Aug 26 2018 Jan Chaloupka  - 0-0.24.gita49355c
  - Rebuild to accomodate golist rebuild
resolves: #1615497


Package:  graphite2-1.3.10-6.fc30
Old package:  graphite2-1.3.10-5.fc28
Summary:  Font rendering capabilities for complex non-Roman writing systems
RPMs: graphite2 graphite2-devel
Size: 871.84 KiB
Size change:  -72.73 KiB
Changelog:
  * Fri Jul 13 2018 Fedora Release Engineering  - 
1.3.10-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild


Package:  kiwi-9.16.12-1.fc30
Old package:  kiwi-9.16.0-3.fc29
Summary:  Flexible operating system image builder
RPMs: dracut-kiwi-lib dracut-kiwi-live dracut-kiwi-oem-dump 
dracut-kiwi-oem-repart dracut-kiwi-overlay kiwi-cli kiwi-pxeboot 
kiwi-systemdeps kiwi-tools python3-kiwi
Size: 994.07 KiB
Size change:  -10.98 KiB
Changelog:
  * Sun Aug 26 2018 Neal Gompa  - 9.16.12-1
  - Upgrade to 9.16.12 (RH#1591056)


Package:  libproxy-0.4.15-9.fc30
Old package:  libproxy-0.4.15-8.fc29
Summary:  A library handling all the details of proxy configuration
RPMs: libproxy libproxy-bin libproxy-devel libproxy-gnome libproxy-kde 
libproxy-mozjs libproxy-networkmanager libproxy-pacrunner libproxy-webkitgtk4

Re: pgadmin4 prerequisites and status report for fedora 29

[Joseph D. Wagner]

all packages required already in fedora, all you need todo is update 
pgadmin4 spec and get it approved.



First, I've never used any of the online tools (e.g. koji, etc) for 
building a RPM before.  I would need someone to walk me through the 
first one.


Second, I tried your branch RPM, but I couldn't get it to run.  I could, 
however, get the one from the POSTGRESQL repository to run.


I will try yours again.

Joseph D. Wagner
___
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: Intel's Clear Linux optimizations

[Victor Rodriguez]

On Sun, Aug 26, 2018 at 12:40 PM, Manas Mangaonkar
 wrote:
> Thank you for the blog link victor , interesting read it is.
>

Fedora is already in glibc 2.28 it is possible to do the same approach

> - Manas
>
> On Sun, 26 Aug 2018, 23:03 Victor Rodriguez,  wrote:
>>
>> On Tue, May 15, 2018 at 10:38 PM, Hayden Barnes 
>> wrote:
>> > Would it be possible to mirror the Clear Linux kernel in copr or a
>> > third-party dnf repo?
>> >
>> > That would allow Fedora to keep it's general purpose kernel but then
>> > allow performance hounds to install the Clear Linux kernel.
>> >
>> > There is something similar already for people who want to use upstream
>> > vanilla kernel.
>> >
>> > The Clear Linux performance metrics posted by Phoronix are compelling.
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>> Maybe a great blog to read about Clear Linux could be this:
>>
>>
>> https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
>>
>> Regards
>>
>> Victor
>> ___
>> 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
>
___
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

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-08-28 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


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

___
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 Packages in rawhide (2018-08-27)

[Jason L Tibbitts III]

So audiofile has eight current maintainers (plus all of gnome-sig) but
somehow none of those maintainers has admin privileges on the
repository.  Would any of the maintainers like be made an admin so that
SDL and everything that depends on it can drop out of this report?

Just let me know and I'll make the change for you.

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

Buildroot-only modules

[Mikolaj Izdebski]

Some modules are built in MBS/Koji but are never released to users.
Currently such modules can only be used as build dependencies of other
modules.  In future, if solution like "ursa-major" [1] is implemented,
such modules could also be used as build dependencies for non-modular
packages.

An example of buildroot-only module is javapackages-tools.  This
module is used as build dependency for 4 modules, but it is not
included in any compose and it's not shipped to users.

Should such modules be considered as allowed in Fedora?  I am not
aware of any policy that would disallow them, but I would rather ask
in advance and not be surprised if one day I find out that I have to
ship such modules to users and support them.

[1]
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LPCRSNGLPC2M3ZX6DPXSADWDAGWUAQPD/#LPCRSNGLPC2M3ZX6DPXSADWDAGWUAQPD
[2]
https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/javapackages-tools.yaml

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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

Maintenance of arbitrary branches of orphaned package

[Mikolaj Izdebski]

Suppose I am main admin of a package which I would like to orphan in
release branches, but keep maintaining the package in arbitrary [1]
branches, which are used for building modules.  Would this considered
as a valid approach?

How should I handle orphaning the package in this case?  I can think
of at least two possibilities:
1. Keep myself as admin and set bugzilla_contact for product Fedora to
   orphan.
2. Set orphan as main admin and demote myself to just admin.

In case no one adopts orphaned package and it is retired by Release
Engineering, should commiters be still able to commit to non-retired
arbitrary branches?  I assume yes, but I'd rather ask in advance.

[1] https://fedoraproject.org/wiki/Changes/ArbitraryBranching

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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-20180827.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 20/132 (x86_64), 4/24 (i386), 1/2 (arm)

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

ID: 270334  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/270334
ID: 270401  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/270401
ID: 270449  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/270449
ID: 270471  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/270471

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

ID: 270320  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/270320
ID: 270330  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/270330
ID: 270332  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/270332
ID: 270336  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/270336
ID: 270346  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270346
ID: 270347  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270347
ID: 270361  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/270361
ID: 270364  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270364
ID: 270365  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270365
ID: 270369  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/270369
ID: 270377  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/270377
ID: 270378  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/270378
ID: 270393  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/270393
ID: 270394  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/270394
ID: 270397  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/270397
ID: 270407  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/270407
ID: 270439  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/270439
ID: 270440  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/270440
ID: 270451  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/270451
ID: 270452  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/270452
ID: 270460  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/270460

Soft failed openQA tests: 65/132 (x86_64), 17/24 (i386)
(Tests completed, but using a workaround for a known bug)

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

ID: 270405  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/270405
ID: 270432  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/270432
ID: 270436  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/270436
ID: 270438  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/270438

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

ID: 270314  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270314
ID: 270315  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270315
ID: 270317  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270317
ID: 270318  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270318
ID: 270321  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/270321
ID: 270327  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/270327
ID: 270329  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/270329
ID: 270333  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/270333
ID: 270340  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270340
ID: 270341  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/270341
ID: 270

Fedora 29-20180827.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 270139  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/270139
ID: 270140  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/270140
ID: 270150  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/270150
ID: 270152  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/270152
ID: 270156  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/270156
ID: 270166  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270166
ID: 270167  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270167
ID: 270177  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270177
ID: 270178  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/270178
ID: 270179  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/270179
ID: 270180  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270180
ID: 270181  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/270181
ID: 270184  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270184
ID: 270185  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270185
ID: 270189  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/270189
ID: 270197  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/270197
ID: 270198  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/270198
ID: 270216  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/270216
ID: 270217  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/270217
ID: 270218  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/270218
ID: 270219  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/270219
ID: 270232  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/270232
ID: 270263  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/270263
ID: 270265  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/270265
ID: 270272  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/270272
ID: 270286  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/270286

Soft failed openQA tests: 67/132 (x86_64), 16/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 270134  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270134
ID: 270135  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270135
ID: 270137  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/270137
ID: 270138  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270138
ID: 270141  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/270141
ID: 270147  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/270147
ID: 270149  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/270149
ID: 270153  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/270153
ID: 270154  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/270154
ID: 270160  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270160
ID: 270161  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/270161
ID: 270162  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270162
ID: 270163  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/270163
ID: 270164  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/270164
ID: 270202  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/270202
ID: 270203

Build failure with -Wl,--as-needed

[Scott Talbert]

Hi,

I'm not the maintainer of this package (iaxclient), but I ran into this 
build failure while working on a pull request.  It seems to be fallout 
from the -Wl,--as-needed change.  Any idea why this is happening?


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

Thanks,
Scott
___
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: Build failure with -Wl,--as-needed

[Jerry James]

On Mon, Aug 27, 2018 at 8:33 PM Scott Talbert  wrote:
> I'm not the maintainer of this package (iaxclient), but I ran into this
> build failure while working on a pull request.  It seems to be fallout
> from the -Wl,--as-needed change.  Any idea why this is happening?
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=29342306

Who started this trend of ignoring the libtool script generated by
configure and using /usr/bin/libtool instead?  I've run across several
spec files in the last few days that do that.  It isn't right.  The
configure script tailors the generated libtool in various ways.  Try
the attached spec file, which works much better.

Also, this gcc warning is warning about a real bug:

BUILDSTDERR: md5.c: In function 'MD5Final':
BUILDSTDERR: md5.c:180:26: warning: argument to 'sizeof' in 'memset'
call is the same expression as the destination; did you mean to
dereference it? [-Wsizeof-pointer-memaccess]
BUILDSTDERR:  memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */

Yep, that should be memset(ctx, 0, sizeof(*ctx));

The attached spec file also fixes mixed use of tabs and spaces, and
uses %ldconfig_scriptlets in place of explicit ldconfig invocations.

Regards,
-- 
Jerry James
http://www.jamezone.org/
%global betaver beta3
%global tclver 0.2
%global mainver 2.1
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
%global tkphonearch %{_arch}

Name:		iaxclient
Version:	%{mainver}
Release:	0.31.%{betaver}%{?dist}
Summary:	Library for creating telephony solutions that interoperate with Asterisk
Group:		System Environment/Libraries
License:	LGPLv2+
URL:		http://iaxclient.wiki.sourceforge.net/
Source0:	http://downloads.sourceforge.net/iaxclient/%{name}-%{version}%{betaver}.tar.gz
Source1:	tkiaxphone.desktop
Source2:	wxiax.desktop
Source3:	phone.png
Source4:	run-tkiaxphone.sh
Patch0:		iaxclient-2.1beta3-wxGTK28.patch
Patch1:		iaxclient-2.1beta3-tkphone-cleanups.patch
Patch2:		iaxclient-2.1beta3-tcl-includedir.patch
Patch3:		iaxclient-2.1beta3-tcl-libdir.patch
Patch4:		iaxclient-2.1beta3-tcl-nodoc.patch
Patch5:		iaxclient-2.1beta3-theora-detection.patch
Patch6:		iaxclient-2.1beta3-implicit-DSO-libm.patch
Patch7:		iaxclient-2.1beta3-arm-barriers.patch
Patch8:		iaxclient-portable.patch
# Link against the locally build iax
Patch9:		iaxclient-link-local-iax.patch
# Use system ilbc
Patch10:	iaxclient-system-ilbc.patch
# Add missing -fPIC to configure.ac test
Patch11:	iaxclient-2.1beta3-fpic.patch
# Fix some makefile issues
Patch20:	iax-0.2.3_makefile.patch
# Fix format-security issue
Patch21:	iax-0.2.3_format-security.patch
# Add missing #include 
Patch22:	iax-0.2.3_socket.patch

BuildRequires:	gcc-c++
BuildRequires:	make
BuildRequires:	speex-devel, libtheora-devel, gsm-devel, portaudio-devel
BuildRequires:	tk-devel, gtk2-devel, SDL-devel, libogg-devel, liboggz-devel 
BuildRequires:	wxGTK-devel, libvidcap-devel, desktop-file-utils, libtool
BuildRequires:	spandsp-devel, ilbc-devel, speexdsp-devel

%description
Iaxclient is an open source, multiplatform library for creating telephony 
solutions that interoperate with Asterisk, the Open Source PBX.

Although asterisk supports other VOIP protocols (including SIP, and with 
patches, H.323), IAX's simple, lightweight nature gives it several advantages, 
particularly in that it can operate easily through NAT and packet firewalls, 
and it is easily extensible and simple to understand.
Iaxclient pulls together the wide array of open source technologies required 
for telephony applications.

%package libiax
Summary:	IAX library
Group:		System Environment/Libraries
Obsoletes:	iax < 0.2.3

%description libiax
The %{name}-libs package contains the IAX library version 0.2.3, an improved
version of the abandoned upstream IAX library.

%package libiax-devel
Summary:	IAX library development files
Group:		Development/Libraries
Requires:	%{name}-libiax%{?_isa} = %{version}-%{release}
Obsoletes:	iax-devel < 0.2.3

%description libiax-devel
The %{name}-libiax-devel package contains libraries and header files for
developing applications that use %{name}-libiax.


%package devel
Summary:	Development files for %{name}
Group:		Development/Libraries
Requires:	pkgconfig
Requires:	%{name} = %{mainver}-%{release}

%description devel
The %{name}-devel package contains libraries and header files for
developing applications that use %{name}.

%package -n tcl-iaxclient
Summary:	Tcl interface to iax2 client lib
Version:	%{tclver}
Group:		System Environment/Libraries
License:	BSD
Requires:	tcl(abi) = 8.6
Requires:	%{name} = %{mainver}-%{release}

%description -n tcl-iaxclient
Tcl extensions to iaxclient libraries.

%package -n tkiaxphone
Summary:	Tk IAX Phone Client
Version:	%{mainver}
Group:		Applications/Internet
License:	LGPLv2+
Requires:	tcl(abi) = 8.6
Requires:	%{name} = %{mainver}-%{release}

%description -n tkiaxphone
Tk IAX Phone Client.

%package -n wxiax
Summary:	wx IAX Phon

Re: Build failure with -Wl,--as-needed

[Scott Talbert]

On Mon, 27 Aug 2018, Jerry James wrote:


I'm not the maintainer of this package (iaxclient), but I ran into this
build failure while working on a pull request.  It seems to be fallout
from the -Wl,--as-needed change.  Any idea why this is happening?

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


Who started this trend of ignoring the libtool script generated by
configure and using /usr/bin/libtool instead?  I've run across several
spec files in the last few days that do that.  It isn't right.  The
configure script tailors the generated libtool in various ways.  Try
the attached spec file, which works much better.


Thanks Jerry!  I had just noticed that LIBTOOL=... in the make invocation 
and was wondering if that was part of the problem.


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

f29-backgrounds ready for review

[Luya Tshimbalanga]

On 2018-08-24 01:27 PM, Ben Cotton wrote:
> Hi design team,
>
> Today we have reached the Beta Wallpapers deadline for Fedora 29. The
> schedule[1] has until 27 August to finish packaging. The packaging
> needs to be finished before Beta Freeze of the F28 release, which is
> planned on Tue 2018-08-28.
>
> [1] https://fedorapeople.org/groups/schedule/f-29/f-29-design-tasks.html
>
Packaged f29-backgrounds ready for review:

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


Should I be unable to push the package into the repository after the
review, someone makes sure to update desktops-backgrounds as well.
Thanks in advance.


-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net




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: Orphaned Packages in rawhide (2018-08-27)

[Dan Callaghan]

Excerpts from Till Maas's message of 2018-08-28 00:03 +02:00:
> python-configobj   fale, lmacken, orphan, 45 weeks ago  
>terjeros 
[...]

I will take python-configobj if nobody else will... BUT I don't quite 
understand what this means.

Pagure shows the owners as:

orphan (orphan) - main admin
Fabio Alessandro Locati (fale) - admin
lmacken (lmacken) - admin
Terje Røsten (terjeros) - commit

The package has no open bugs and is not failing in Koschei so I do not 
see any reason why it needs to be retired.

What does it mean for a package to be owned by orphan while it still has 
other admins who are real people?

Is this some kind of edge case where the package was owned by 
a maintainer who was inactive, and thus their packages got "orphaned", 
even though there are still other maintainers? Is there any record where 
we can see when or why these changes were made?

And is the solution here that one of the existing co-maintainers should 
just go into the Pagure settings and click... some button to become the 
"main admin" so that it's no longer orphaned?

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies DevOps
Red Hat


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