date:20180824

Re: Dropping python2 Biopython on fedora 30+

2018-08-24 Thread Miro Hrončok


On 24.8.2018 02:53, Dominik 'Rathann' Mierzejewski wrote:

Hello, Antonio.

On Thursday, 23 August 2018 at 11:05, Antonio Trande wrote:

Hello everyone.

Python2 Biopython is required by 'python-MDAnalysis' on fedora 30+
(other than 'openms', already modified).

Ask to the maintainer of 'python-MDAnalysis' (Dominik Mierzejewski -
rathann) if we are ready for switching to Python3 definitively.


MDAnalysis claims to support python 3.4+ since 0.17.0, but I haven't
tried to build and run it with python3 yet. Please open a bugzilla
ticket to track this. PRs are of course welcome. Thank you for being
proactive on this.


A trivial change 2-> passes %check. Expect a PR.

--
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/message/F4XSPI7QD6WBZHUR7B6FO5VUIEKNKV45/

Re: Dropping python2 Biopython on fedora 30+

2018-08-24 Thread Miro Hrončok


On 24.8.2018 09:59, Miro Hrončok wrote:

On 24.8.2018 02:53, Dominik 'Rathann' Mierzejewski wrote:

Hello, Antonio.

On Thursday, 23 August 2018 at 11:05, Antonio Trande wrote:

Hello everyone.

Python2 Biopython is required by 'python-MDAnalysis' on fedora 30+
(other than 'openms', already modified).

Ask to the maintainer of 'python-MDAnalysis' (Dominik Mierzejewski -
rathann) if we are ready for switching to Python3 definitively.


MDAnalysis claims to support python 3.4+ since 0.17.0, but I haven't
tried to build and run it with python3 yet. Please open a bugzilla
ticket to track this. PRs are of course welcome. Thank you for being
proactive on this.


A trivial change 2-> passes %check. Expect a PR.


Should have said 2 -> 3.

PR: https://src.fedoraproject.org/rpms/python-MDAnalysis/pull-request/1

--
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/message/ODH3VGXJ5RYAQEWPPKUTNSFZGROOYMKG/

Re: Idea: let's use Pagure to track Changes

2018-08-24 Thread David Sommerseth

On 23/08/18 22:43, Ben Cotton wrote:
> Hi community,
> 
> We've traditionally used the wiki for Change proposals because it's
> the tool we had. But, it's not necessarily well-suited to the purpose.
> But now we have Pagure, which can help address some of the
> shortcomings of using the wiki: poor scriptability, no reporting, and
> a lot of copy/paste.
> 
> So I've come up with a plan that would use Pagure instead:
> https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> 
> You can read the full details on the wiki page above, but the general
> idea is that we won't change the policy for Changes, just how we store
> and manipulate them. My intent is to make it nearly seamless for the
> community while giving us a platform for building on the process in
> the future. Note that this would run parallel to Bugzilla for a
> release or two and then replace Bugzilla for Changes tracking.

Even though I'm not as active here as I would like to be, I generally like
this idea.

A few things which would be good to sort out are:

* Still requires changes be represented in three different Pagure repos
* We lose edit history if a change proposal is updated based on feedback

From my point of view, those are the most critical ones.  The history is good
when you want to see if/how things changed - to learn from specific changes
which went well or really bad.  Not having a history to base it on makes this
learning somewhat more difficult - as you don't know exactly how a change
proposal did develop, just the final result.

Also having changes represented in three different repos sounds a bit too
bureaucratic to me.  Processes are good to have, but in the moment they get
too complicated people will generally try to avoid them.  If it is really
needed to involve three repos, then a decent tooling on top of it is needed at
launch time; to hide this bureaucratic process a bit.

Other than that, I think this idea makes perfect sense.  The first time I did
a change proposal (not even system-wide), it felt like an odd process ("Is
this the right template? In a wiki? Have I filled out all the proper fields
correctly? How is this proposal picked up and distributed properly?" are some
of the thousands questions which popped up).

-- 
kind regards,

David Sommerseth

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/message/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/

Re: Idea: let's use Pagure to track Changes

2018-08-24 Thread Fabio Valentini

On Fri, Aug 24, 2018, 11:38 David Sommerseth  wrote:

> On 23/08/18 22:43, Ben Cotton wrote:
> > Hi community,
> >
> > We've traditionally used the wiki for Change proposals because it's
> > the tool we had. But, it's not necessarily well-suited to the purpose.
> > But now we have Pagure, which can help address some of the
> > shortcomings of using the wiki: poor scriptability, no reporting, and
> > a lot of copy/paste.
> >
> > So I've come up with a plan that would use Pagure instead:
> > https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> >
> > You can read the full details on the wiki page above, but the general
> > idea is that we won't change the policy for Changes, just how we store
> > and manipulate them. My intent is to make it nearly seamless for the
> > community while giving us a platform for building on the process in
> > the future. Note that this would run parallel to Bugzilla for a
> > release or two and then replace Bugzilla for Changes tracking.
>
> Even though I'm not as active here as I would like to be, I generally like
> this idea.
>
> A few things which would be good to sort out are:
>
> * Still requires changes be represented in three different Pagure repos
> * We lose edit history if a change proposal is updated based on feedback
>

Well, I suppose Changes could be represented as markdown/reStructuredText
files in a repository instead of issues on pagure? Then edit history is no
problem (that's what git is for), and proposed changes can be done via pull
requests.

Off the top of my head I'd suggest using a "fedora-changes" (?) project on
pagure with folders for different fedora releases.

- Edit history is accessible through git
- Changes can be submitted and updated with pull requests
- Postponing a change is as simple as moving a text file from one folder to
another
- Rejected or discarded changes can be archived in another folder

(Just thinking out loud here.)

Fabio


> From my point of view, those are the most critical ones.  The history is
> good
> when you want to see if/how things changed - to learn from specific changes
> which went well or really bad.  Not having a history to base it on makes
> this
> learning somewhat more difficult - as you don't know exactly how a change
> proposal did develop, just the final result.
>
> Also having changes represented in three different repos sounds a bit too
> bureaucratic to me.  Processes are good to have, but in the moment they get
> too complicated people will generally try to avoid them.  If it is really
> needed to involve three repos, then a decent tooling on top of it is
> needed at
> launch time; to hide this bureaucratic process a bit.
>
> Other than that, I think this idea makes perfect sense.  The first time I
> did
> a change proposal (not even system-wide), it felt like an odd process ("Is
> this the right template? In a wiki? Have I filled out all the proper fields
> correctly? How is this proposal picked up and distributed properly?" are
> some
> of the thousands questions which popped up).
>
>
> --
> kind regards,
>
> David Sommerseth
>
> ___
> 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/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
>
___
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/R5H22KIXOWYIKUYIRSXZVOZNHINOBVLC/

Golang SIG primary goals?

2018-08-24 Thread Robert-André Mauchin

Hey guys and gals,

Can we start to discuss this SIG goals? What each of you are expecting?
A few ideas:

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

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

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/message/JII4CSPFA4PNTE6TCR477U7RDSU4Y3Z3/

Re: Idea: let's use Pagure to track Changes

2018-08-24 Thread Ben Cotton

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/

Re: [atomic-devel] [CoreOS] Re: Re: Starting a Container SIG

2018-08-24 Thread Brian Clark

Are there any minutes from this meeting?

On Mon, Aug 20, 2018 at 6:27 AM Clement Verna 
wrote:

> Dear all,
>
> I have scheduled our first IRC meeting for this week Thursday (August
> 23, 2018 - 15:00 UTC)  on #fedora-containers (freenode) [0]. The
> agenda for this meeting is :
>   - everyone interested in the SIG to introduce themselves
>   - Go through some of the discussion we had during flock.
>   - Finally try to find a fortnightly meeting time that suits everyone.
>
> Hope to see you there Thursday,
>
> Clément
>
>
> [0] - https://apps.fedoraproject.org/calendar/meeting/9320/
> ___
> 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/UNW6ZSL6JBHGX547SYPXBWY3USO7WPFF/
>
___
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/UNOTYFFFLZMDMWP2I5AZFOM4FFMVKFHJ/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Petr Pisar

On 2018-08-22, Ben Cotton  wrote:
> https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
>
> glibc-minimal-langpack is added to @Buildsystem group and installed
> into the minimal buildroot instead of glibc-all-langpacks. Packages
> which need more locales than plain C/C.UTF-8/POSIX need to pull them
> in through BuildRequires.
>
I already wrote it in previous thread about this change but it seems
nobody takes me seriosly. Once again:

These three locales are not enough because Brew builders have
en_US.UTF-8 locale that is propagated to mock and then into rpmbuild.
That means all the build have set en_US.UTF-8 locale. If you stop
installing the locale things will blow up.

Either install glibc-langpack-en or change Brew locale first or edit
every spec file to set LC_ALL explicitly.

-- 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/message/CPZYQWAAJQAVMX3Q4BSK4QMSYHKSGWHX/

Re: Consistent CI Messages

2018-08-24 Thread Jeremy Cline

On 08/23/2018 04:21 PM, Neal Gompa wrote:
> On Thu, Aug 23, 2018 at 4:18 PM Randy Barlow
>  wrote:
>>
>> On 08/23/2018 01:34 PM, Adam Williamson wrote:
>>> 
>>> OUTPUT: "late December"
>>
>> What about
>>
>> 
>> OUTPUT: "late January"
>> 
>> OUTPUT: "late February"
> 
> Also don't forget
> 
> 
> OUTPUT: "late March"
> 

I'm glad we're all on the same page here, expect it by May of next year!


-- 
Jeremy Cline
XMPP: jer...@jcline.org
IRC:  jcline
___
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/EEPFPHII3KYRK2N3AQLSSDEYYW2R7SXB/

zram-generator

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

Hi!

https://fedoraproject.org/wiki/Changes/ZRAMforARMimages is a change to
automatically create a zram device on memory-constrained systems. It is
implemented using 'zram' package, which uses a service unit and two
bash scripts to implement the starting and stopping of the zram device.

I wanted to explore an alternative approach, using a systemd generator [1],
to create (or not) the unit to create the zram device. The advantages are:
- lower footprint (a custom binary instead of a shell script using
grep, awk, and whatnot)
- completely invisible if the memory limits are not met, no "skipped" units
- minimalistic: the unit just creates the device, but tells
systemd-modules-load.service to actually load the module,
and creates a .swap unit for the device, so it will be managed by systemd
in the usual fashion.

Systemd generators are often written in C, to keep them mean and lean, but
C is not an attractive option for many people. We have wanted to explore
the approach of writing generators in Rust. zram-generator doubles as a
proof-of-concept and example of a simple-yet-not-trivial systemd generator
in Rust.

Without further ado: upstream project [2], fedora package review [3].
Many thanks to Igor Gnatenko and Martin Sehnoutka for reviews of the code.

It works like this:
1. /usr/lib/systemd/zram-generator runs, checks if we have less memory than the
limit
2. /run/modules-load.d/zram.conf is created to have "zram" module loaded
3. /run/systemd/generator/swap-create@zram0.service is created, it'll
initialize /dev/zram0
4. /run/systemd/generator/dev-zram0.swap is created, and added to swap.target
5. swap.target is pulled in by systemd, the config from items 2, 3, 4 is
executed.

[1] https://www.freedesktop.org/software/systemd/man/systemd.generator.html
[2] https://github.com/systemd/zram-generator
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1622127

Comments, ideas, reviews of the package, etc, are very much welcome.

I think this might be used to replace the 'zram' package, but it's too early
to say.

Zbyszek
___
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/PCP7YAF7LBF5MLI36XWYNISQCYIDRNHS/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 01:55:54PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> > On 2018-08-22, Ben Cotton  wrote:
> > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> > >
> > > glibc-minimal-langpack is added to @Buildsystem group and installed
> > > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > > in through BuildRequires.
> > >
> > I already wrote it in previous thread about this change but it seems
> > nobody takes me seriosly. Once again:

When you wrote about mock configuration previously, I answered:
> Thanks, that's a good point. Do you know where this is configured?

This was me taking the issue seriously. I haven't started working on
this yet because it got bumped to F30, but I keep a list of all the
points raised, including this one.

> > These three locales are not enough because Brew builders have
> > en_US.UTF-8 locale that is propagated to mock and then into rpmbuild.
> > That means all the build have set en_US.UTF-8 locale. If you stop
> > installing the locale things will blow up.
> > 
> > Either install glibc-langpack-en or change Brew locale first or edit
> > every spec file to set LC_ALL explicitly.
> 
> NB, some apps will explicitly force locale to en_US.UTF-8 in order to
> ensure their output artifacts are stable & repeatable, and/or to work
> around bugs in tools they run.

If they do it even though a different locale is configured, they are buggy.
Worst case, if some packages are built using tools which simply
require en_US.UTF-8, a BR: glibc-langpack-en can be added to them.
I don't expected that this would be necessary in more than a handful of cases.

Zbyszek
___
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/PTP4KWQUFUXORVS5UEC6HFQBKYRKKAG6/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 02:39:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Aug 24, 2018 at 01:55:54PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> > > On 2018-08-22, Ben Cotton  wrote:
> > > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> > > >
> > > > glibc-minimal-langpack is added to @Buildsystem group and installed
> > > > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > > > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > > > in through BuildRequires.
> > > >
> > > I already wrote it in previous thread about this change but it seems
> > > nobody takes me seriosly. Once again:
> 
> When you wrote about mock configuration previously, I answered:
> > Thanks, that's a good point. Do you know where this is configured?
> 
> This was me taking the issue seriously. I haven't started working on
> this yet because it got bumped to F30, but I keep a list of all the
> points raised, including this one.

I turns out Tomasz Torcz already fixed this:
https://github.com/rpm-software-management/mock/commit/33db2351074753271700ee78c316bf1e36a00594
> env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')

Thanks Tomasz!

Zbyszek
___
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/OO6HBAHZQNIZJFGFYTIACTS56GAGBQR4/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Daniel P . Berrangé

On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> On 2018-08-22, Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> >
> > glibc-minimal-langpack is added to @Buildsystem group and installed
> > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > in through BuildRequires.
> >
> I already wrote it in previous thread about this change but it seems
> nobody takes me seriosly. Once again:
> 
> These three locales are not enough because Brew builders have
> en_US.UTF-8 locale that is propagated to mock and then into rpmbuild.
> That means all the build have set en_US.UTF-8 locale. If you stop
> installing the locale things will blow up.
> 
> Either install glibc-langpack-en or change Brew locale first or edit
> every spec file to set LC_ALL explicitly.

NB, some apps will explicitly force locale to en_US.UTF-8 in order to
ensure their output artifacts are stable & repeatable, and/or to work
around bugs in tools they run.

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

Fwd: fedora-tagger sunset - week post F29 beta freeze

2018-08-24 Thread Clement Verna

Dear all,

The Fedora Infrastructure is running the fedora-tagger [0] service,
however it gets little usage and also has no one really maintaining it
or fixing issues with it. Earlier this year [1] we have tried to
support community members who expressed their interests in maintaining
this application, unfortunately this effort did not results in a new
version being released.

During our last meeting [2], we agreed to retire this service a week
after the end of the F29 beta freeze (see F29 schedule [3]).

Once the F29 beta freeze is over, we will communicate a sunset date.

Regards,
Clément

[0] - https://apps.fedoraproject.org/tagger/
[1] - https://communityblog.fedoraproject.org/maintainers-package-tagger/
[2] - 
https://meetbot.fedoraproject.org/teams/infrastructure/infrastructure.2018-08-23-14.00.log.html
[3] - https://fedoraproject.org/wiki/Releases/29/Schedule?rd=Schedule
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org/message/UPM46GFVAD4NHUMOMEWS3XGM52T2YV3T/
___
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/UPM46GFVAD4NHUMOMEWS3XGM52T2YV3T/

Re: zram-generator

2018-08-24 Thread Jeff Johnson

Why not Haskell?

Seriously: you provide no reason for rust other than that "C is not attractive".

C is surely a reliable implementation language for long running system services.
___
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/UDRQBY42WWBWPRTOE7YJJHIDT2MSZ2NS/

Fedora Rawhide-20180823.n.0 compose check report

2018-08-24 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 29/132 (x86_64), 6/24 (i386), 1/2 (arm)

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

ID: 268930  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/268930
ID: 268938  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/268938
ID: 268997  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/268997

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

ID: 268862  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/268862
ID: 268863  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/268863
ID: 268874  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/268874
ID: 268878  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/268878
ID: 268887  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/268887
ID: 26  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/26
ID: 268889  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268889
ID: 268902  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268902
ID: 268903  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268903
ID: 268905  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268905
ID: 268906  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268906
ID: 268907  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268907
ID: 268911  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/268911
ID: 268919  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268919
ID: 268920  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/268920
ID: 268922  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/268922
ID: 268923  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268923
ID: 268935  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/268935
ID: 268936  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/268936
ID: 268939  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/268939
ID: 268941  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/268941
ID: 268945  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/268945
ID: 268959  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/268959
ID: 268960  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/268960
ID: 268961  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/268961
ID: 268981  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/268981
ID: 268982  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268982
ID: 268985  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/268985
ID: 268992  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268992
ID: 268993  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/268993
ID: 268994  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/268994
ID: 269002  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/269002
ID: 269003  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/269003

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

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

ID: 268969  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/268969
ID: 268987  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/268987
ID: 269009  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/269009

Old soft failures (same test soft failed in

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

2018-08-24 Thread Przemek Klosowski


On 08/22/2018 04:28 PM, Ben Cotton wrote:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FChanges%2FRemove_Group_Tagdata=02%7C01%7Cprzemek.klosowski%40nist.gov%7C651a81e7675e4b31057b08d6086f1e90%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636705670673083010sdata=xvi9PSYy9IGEIcvyLdwiX9QmyPqLmInm23Np%2Fl%2BJMSc%3Dreserved=0

== Summary ==
Remove the Group: tag from over 9000 source packages.
I noticed that gpg-pubkey packages consistently have the group of Public 
Keys, so at worst it's being used for something, and at best there's a 
template somewhere that includes it when those packages are created.


Also, as a random data point, here are the Group stats from a system 
with most (7700+) Fedora 27 packages installed:


  1 Applications/Security
  1 Development/Build Tools
  2 Amusements/Graphics
  2 Development/Java
  3 System/Boot
  6 Amusements/Games
 10 System Environment/Kernel
 11 Applications/Editors
 11 User Interface/X Hardware Support
 12 Applications/Communications
 13 Development/Debuggers
 16 Development/System
 17 Applications/File
 19 Applications/Archiving
 20 Applications/Databases
 20 Documentation
 21 Applications/Productivity
 22 Applications/Emulators
 26 User Interface/Desktops
 31 Public Keys
 33 Applications/Text
 46 System Environment/Daemons
 59 Applications/Internet
 65 User Interface/X
 93 Applications/Multimedia
    128 Applications/Engineering
    157 Applications/System
    163 Development/Tools
    201 System Environment/Base
    230 Development/Languages
    288 Development/Debug
    329 Applications/Publishing
    807 Development/Libraries
    843 System Environment/Libraries
   3516 Unspecified
___
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/NNOX5JGNLQC7OFKBMU54LI4ZNFZQNTQV/

Re: zram-generator

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 05:11:28PM -, Jeff Johnson wrote:
> Why not Haskell?
> 
> Seriously: you provide no reason for rust other than that "C is not 
> attractive".
> 
> C is surely a reliable implementation language for long running system 
> services.

I love C myself and spend my days writing C. But we already have
plenty of generators written in C in the systemd codebase. This is
about looking for new options, with easier memory management, easier
IO, easier error handling.

Rust is a nice modern language with a lot of promise. It seems well
suited for the purpose of low-level systems programming where one
needs fairly close control over IO error handling.

Zbyszek
___
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/CEMNYT7IIKEEHQ3RMLCRVLI6JNWTSHIS/

Re: zram-generator

2018-08-24 Thread Chris Murphy

On Fri, Aug 24, 2018 at 11:11 AM, Jeff Johnson  wrote:
> Why not Haskell?
>
> Seriously: you provide no reason for rust other than that "C is not 
> attractive".

Why Haskell? You've provided no reason for Haskell.

Seems to me it's more likely people will be, or can become Rust
competent before they become Haskell competent.

-- 
Chris Murphy
___
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/5Y45I37ITFSUKP7FL5KV7TJB6G4KFPK7/

Re: Golang SIG primary goals?

2018-08-24 Thread Ricardo Martinelli Oliveira

Hi Robert,

Maybe a document with Go packaging guidelines would be very helpful.
Also, it would be good document and maintain gofed as part of the go
packager toolkit.

I don't know if they are all already part of golang-SIG, but I'm in to
help improving the wiki pages.

On Fri, Aug 24, 2018 at 12:59 PM Robert-André Mauchin  wrote:
>
> Hey guys and gals,
>
> Can we start to discuss this SIG goals? What each of you are expecting?
> A few ideas:
>
>  - Making https://fedoraproject.org/wiki/More_Go_packaging official and
> working on bringing them to EPEL7
>
>  - 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.
>
> 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/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/message/BMWPSXVEYCTX75YQ7CV6FSJCEVQMQXA6/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Peter Robinson

On Fri, Aug 24, 2018 at 5:18 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Aug 24, 2018 at 02:39:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Aug 24, 2018 at 01:55:54PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> > > > On 2018-08-22, Ben Cotton  wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> > > > >
> > > > > glibc-minimal-langpack is added to @Buildsystem group and installed
> > > > > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > > > > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > > > > in through BuildRequires.
> > > > >
> > > > I already wrote it in previous thread about this change but it seems
> > > > nobody takes me seriosly. Once again:
> >
> > When you wrote about mock configuration previously, I answered:
> > > Thanks, that's a good point. Do you know where this is configured?
> >
> > This was me taking the issue seriously. I haven't started working on
> > this yet because it got bumped to F30, but I keep a list of all the
> > points raised, including this one.
>
> I turns out Tomasz Torcz already fixed this:
> https://github.com/rpm-software-management/mock/commit/33db2351074753271700ee78c316bf1e36a00594
> > env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')

That fixes the mock use case but koji configures and passes it's own
mock config and doesn't necessarily use the mock defaults so while it
may fix mock it's likely koji will need an associated patch as well.
___
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/EV6ZLPN4BDBLVKWCRXSTLRRE2U5A2ZF7/

Fedora rawhide compose report: 20180823.n.0 changes

2018-08-24 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180822.n.0
NEW: Fedora-Rawhide-20180823.n.0

= SUMMARY =
Added images:0
Dropped images:  5
Added packages:  3
Dropped packages:12
Upgraded packages:   122
Downgraded packages: 0

Size of added packages:  48.24 MiB
Size of dropped packages:11.73 MiB
Size of upgraded packages:   6.53 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20180822.n.0.x86_64.vagrant-virtualbox.box
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20180822.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20180822.n.0.x86_64.vagrant-libvirt.box
Image: Games live i386
Path: Labs/i386/iso/Fedora-Games-Live-i386-Rawhide-20180822.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20180822.n.0.iso

= ADDED PACKAGES =
Package: python-pikepdf-0.3.2-1.fc30
Summary: Read and write PDFs with Python, powered by qpdf
RPMs:python-pikepdf-doc python3-pikepdf
Size:30.83 MiB

Package: python-ruffus-2.7.0-1.fc30
Summary: Light-weight Python computational pipeline management
RPMs:python-ruffus-doc python3-ruffus
Size:17.19 MiB

Package: python-xmp-toolkit-2.0.1-1.fc30
Summary: Python XMP Toolkit for working with metadata
RPMs:python-xmp-toolkit-doc python3-xmp-toolkit
Size:218.73 KiB


= DROPPED PACKAGES =
Package: python-djvulibre-0.8-2.fc28
Summary: Python bindings for the DjVuLibre library
RPMs:python-djvulibre-doc python2-djvulibre python3-djvulibre
Size:2.97 MiB

Package: python-flask-restless-0.17.0-7.fc26
Summary: Flask-restless provides simple generation of ReSTful APIs
RPMs:python2-flask-restless python3-flask-restless
Size:173.78 KiB

Package: python-lmiwbem-0.7.2-18.fc28
Summary: Python WBEM Client
RPMs:python-lmiwbem-doc python2-lmiwbem python3-lmiwbem
Size:5.29 MiB

Package: python-ludolph-1.0.1-3.fc28
Summary: Monitoring Jabber Bot
RPMs:python2-ludolph python3-ludolph
Size:437.72 KiB

Package: python-ludolph-zabbix-1.7-4.fc29
Summary: Ludolph: Zabbix API plugin
RPMs:python2-ludolph-zabbix python3-ludolph-zabbix
Size:56.94 KiB

Package: python-sleekxmpp-1.3.2-4.fc29
Summary: Flexible XMPP client/component/server library for Python
RPMs:python2-sleekxmpp python3-sleekxmpp
Size:1.26 MiB

Package: python-sync2jira-1.7-7.fc29
Summary: Sync pagure and github issues to jira, via fedmsg
RPMs:python2-sync2jira python3-sync2jira
Size:69.24 KiB

Package: python-testfixtures-4.14.3-4.fc29
Summary: Collection of helpers and mock objects for unit tests and doc tests
RPMs:python-testfixtures-doc python2-testfixtures 
python2-testfixtures-tests python3-testfixtures python3-testfixtures-tests
Size:556.05 KiB

Package: python-tlslite-0.4.9-7.fc29
Summary: Python module for SSL/TLS support
RPMs:python2-tlslite python3-tlslite
Size:369.41 KiB

Package: python-ufo2ft-1.1.0-3.fc29
Summary: A bridge from UFOs to FontTool objects
RPMs:python2-ufo2ft python3-ufo2ft
Size:170.34 KiB

Package: rtv-1.22.1-1.fc29
Summary: A simple terminal viewer for Reddit (Reddit Terminal Viewer)
RPMs:rtv
Size:253.24 KiB

Package: tweepy-3.5.0-7.fc29
Summary: An easy-to-use Python library for accessing the Twitter API
RPMs:python2-tweepy python3-tweepy
Size:167.84 KiB


= UPGRADED PACKAGES =
Package:  Agda-stdlib-0.15-3.fc30
Old package:  Agda-stdlib-0.15-2.fc29
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 101.35 MiB
Size change:  -2.81 MiB
Changelog:
  * Wed Aug 22 2018 Jens Petersen  - 0.15-3
  - install library files correctly under src/


Package:  EekBoek-2.03-7.fc30
Old package:  EekBoek-2.03-6.fc29
Summary:  Bookkeeping software for small and medium-size businesses
RPMs: EekBoek EekBoek-db-postgresql EekBoek-gui
Size: 1.32 MiB
Size change:  188 B
Changelog:
  * Wed Aug 22 2018 Scott Talbert  - 2.03-7
  - Remove dependency on wxWidgets.  wxWidgets is pulled in by perl(Wx).


Package:  FlightGear-Atlas-0.5.0-0.47.cvs20141002.fc30
Old package:  FlightGear-Atlas-0.5.0-0.46.cvs20141002.fc29
Summary:  Flightgear map tools
RPMs: FlightGear-Atlas
Size: 4.11 MiB
Size change:  -181.41 KiB
Changelog:
  * Thu Aug 23 2018 Nicolas Chauvet  - 0.5.0-0.47.cvs20141002
  - Rebuilt for glew 2.1.0


Package:  OpenColorIO-1.1.0-8.fc30
Old package:  OpenColorIO-1.1.0-7.fc29
Summary:  Enables color transforms and image display across graphics apps
RPMs: OpenColorIO OpenColorIO-devel OpenColorIO-doc OpenColorIO-tools
Size: 4.78 MiB
Size change:  -167.22 KiB
Changelog:
  * Thu Aug 23 2018 Nicolas Chauvet  - 1.1.0-8

Scons python2 on fedora 30+

2018-08-24 Thread Antonio Trande

Hello!

Regarding Python2 package removal, 'python2-SCons' needs special
attention, i guess.
It's required for building by many packages on current 'rawhide':

$ dnf repoquery --release rawhide --enablerepo=*-source
--disablerepo=rpmfusion* --whatrequires scons

boswars-0:2.7-15.svn160110.fc28.src
btanks-0:0.9.8083-16.fc27.src
camotics-0:1.1.1-13.fc29.src
compat-tolua++-0:1.0.93-9.fc29.src
csstidy-0:1.4-20.fc29.src
elfelli-0:0.3.1-19.fc27.src
endless-sky-0:0.9.8-6.fc29.src
godot-0:3.0.4-2.fc29.src
gpick-0:0.2.6-0.rc1.fc28.1.src
gpsd-0:3.17-5.fc29.src
lcdtest-0:1.18-20.fc29.src
libnxt-0:0.3-19.fc29.src
mapnik-0:3.0.20-5.fc29.src
mingw-nsis-0:3.03-3.fc29.src
minicomputer-0:1.41-23.fc29.src
mongo-cxx-driver-0:1.1.2-13.fc28.src
netpanzer-0:0.8.7-9.fc29.src
pingus-0:0.7.6-31.fc29.src
pyexiv2-0:0.3.2-34.fc29.src
sagemath-0:8.2-4.fc29.src
sar2-0:2.3.3-6.fc29.src
swift-0:3.0-0.12.rc2.fc27.src
tolua++-0:1.0.93-24.fc29.src
v8-314-0:3.14.5.10-13.fc29.src
vdrift-0:20141020-13.fc28.src
vdrift-0:20141020-14.fc30.src
wesnoth-0:1.14.4-1.fc29.src
wlassistant-0:0.5.7-30.fc29.src
xsettingsd-0:0-0.16.20091208git7804894.fc29.src
zfs-fuse-0:0.7.2.2-6.fc27.src

What's the situation of these packages in a middle-term scenario in
respect of Python2 removal proposal?

Best regards.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



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/message/XMZGWJ7MBKHB7U7ZSOVCXZUHEBL62M7W/

Re: mingw-openssl rebased

2018-08-24 Thread Richard W.M. Jones

On Fri, Aug 24, 2018 at 01:33:36PM +0100, Richard W.M. Jones wrote:
> 
> I've rebased mingw-openssl to match the latest version in Fedora
> Rawhide.  This fixes a number of CVEs, but also it's the version with
> the new API.
> 
> I have kicked off rebuilds for (hopefully) all dependent packages.

So that should be done now.  Two bugs were found -- or to put it more
accurately: two mingw-* packages were found which use the old openssl
API and will need to be resynchronized with the corresponding Fedora
Rawhide package:

mingw-qt: https://bugzilla.redhat.com/show_bug.cgi?id=1622139
mingw-opusfile: https://bugzilla.redhat.com/show_bug.cgi?id=1622100

Also one package was found which seems to have a general FTBFS problem
which I could not diagnose:

mingw-podofo: https://bugzilla.redhat.com/show_bug.cgi?id=1622096

If you find any other bugs or fall-out from this change, let me know.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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/UNPADJR7K5D6YBZMHQKNH2JGT4PBUMFY/

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 05:24:25PM +0100, Peter Robinson wrote:
> On Fri, Aug 24, 2018 at 5:18 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Aug 24, 2018 at 02:39:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Aug 24, 2018 at 01:55:54PM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> > > > > On 2018-08-22, Ben Cotton  wrote:
> > > > > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> > > > > >
> > > > > > glibc-minimal-langpack is added to @Buildsystem group and installed
> > > > > > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > > > > > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > > > > > in through BuildRequires.
> > > > > >
> > > > > I already wrote it in previous thread about this change but it seems
> > > > > nobody takes me seriosly. Once again:
> > >
> > > When you wrote about mock configuration previously, I answered:
> > > > Thanks, that's a good point. Do you know where this is configured?
> > >
> > > This was me taking the issue seriously. I haven't started working on
> > > this yet because it got bumped to F30, but I keep a list of all the
> > > points raised, including this one.
> >
> > I turns out Tomasz Torcz already fixed this:
> > https://github.com/rpm-software-management/mock/commit/33db2351074753271700ee78c316bf1e36a00594
> > > env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')
> 
> That fixes the mock use case but koji configures and passes it's own
> mock config and doesn't necessarily use the mock defaults so while it
> may fix mock it's likely koji will need an associated patch as well.

Can you point me to this config? Upstream koji [https://pagure.io/koji/]
seems to have no locale configuration at all (searching for any LC_, LANG,
en_US occurrences yields nothing).

Zbyszek
___
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/AFDNHN5IPMKOEDM6VQVKMEDXJ3ADNFFK/

Re: zram-generator

2018-08-24 Thread David Malcolm

On Fri, 2018-08-24 at 20:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Aug 24, 2018 at 04:15:53PM -0400, David Malcolm wrote:
> > On Fri, 2018-08-24 at 17:11 +, Jeff Johnson wrote:
> > > Why not Haskell?
> > > 
> > > Seriously: you provide no reason for rust other than that "C is
> > > not
> > > attractive".
> > > 
> > > C is surely a reliable implementation language for long running
> > > system services.
> > 
> > https://cwe.mitre.org/data/definitions/658.html
> 
> That's a nice list. I was wondering if there were any I haven't done
> myself,
> but from a cursory glance, I score full bingo ;)

(nods)

I wonder how many Rust makes impossible (or, at least, requires
"unsafe" blocks to trigger).

Dave
___
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/FC4FETMGL7FSSW6ZGHRTTAABQYFKTOFX/

Self Introduction: Jason Gauci

2018-08-24 Thread Jason Gauci

Hey all!  I'm the author of Eternal Terminal, a replacement for ssh that
survives IP roaming & network outages.  Michael Salim is an avid Fedora
user and has already created a Fedora package for ET, but I want to make
sure that Fedora is updated ASAP as soon as a new version is out (and
hopefully script the entire process of releasing a package update on 5
OS's).  If anyone has tools to make that easier, please let me know.

I have a variety of open source projects, most of which you can see here
https://github.com/MisterTea
___
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/3XRNUNLEXEKBTNYSA3JCU6M44ZPQO74H/

Re: Self Introduction: Jason Gauci

2018-08-24 Thread Michel Alexandre Salim

Warm welcome, Jason, and thanks for all the work on Eternal Terminal!

I just sponsored Jason to be a Fedora package maintainer (for ET), looking
forward to getting feedback from the community at large (we already have
some dedicated users at work).

Best regards,

Michel

On Fri, Aug 24, 2018 at 4:51 PM Jason Gauci  wrote:

> Hey all!  I'm the author of Eternal Terminal, a replacement for ssh that
> survives IP roaming & network outages.  Michael Salim is an avid Fedora
> user and has already created a Fedora package for ET, but I want to make
> sure that Fedora is updated ASAP as soon as a new version is out (and
> hopefully script the entire process of releasing a package update on 5
> OS's).  If anyone has tools to make that easier, please let me know.
>
> I have a variety of open source projects, most of which you can see here
> https://github.com/MisterTea
> ___
> 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/3XRNUNLEXEKBTNYSA3JCU6M44ZPQO74H/
>


-- 
Michel Alexandre Salim
profile:https://keybase.io/michel_slm
GPG key ID: 4AF5 54AB A36A 937A
___
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/UQYAXOTOVKR5SU4YXMZWFXIH2NCUMAT5/

Fedora 29 compose report: 20180823.n.0 changes

2018-08-24 Thread Fedora Branched Report

OLD: Fedora-29-20180822.n.0
NEW: Fedora-29-20180823.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  5
Dropped packages:0
Upgraded packages:   62
Downgraded packages: 0

Size of added packages:  48.39 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.29 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.94 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cinnamon live i386
Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-29-20180823.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-29-20180823.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-pikepdf-0.3.2-1.fc29
Summary: Read and write PDFs with Python, powered by qpdf
RPMs:python-pikepdf-doc python3-pikepdf
Size:30.83 MiB

Package: python-pytest-helpers-namespace-2017.11.11-1.fc29
Summary: PyTest Helpers Namespace
RPMs:python3-pytest-helpers-namespace
Size:14.89 KiB

Package: python-ruffus-2.7.0-1.fc29
Summary: Light-weight Python computational pipeline management
RPMs:python-ruffus-doc python3-ruffus
Size:17.19 MiB

Package: python-xmp-toolkit-2.0.1-1.fc29
Summary: Python XMP Toolkit for working with metadata
RPMs:python-xmp-toolkit-doc python3-xmp-toolkit
Size:218.78 KiB

Package: textern-0-0.4.20180821git5339fb6.fc29
Summary: Firefox add-on for editing text in your favorite external editor
RPMs:textern
Size:147.09 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Agda-stdlib-0.15-3.fc29
Old package:  Agda-stdlib-0.15-2.fc29
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 101.35 MiB
Size change:  -2.81 MiB
Changelog:
  * Wed Aug 22 2018 Jens Petersen  - 0.15-3
  - install library files correctly under src/


Package:  CGAL-4.13-0.2.beta1.fc29
Old package:  CGAL-4.12-2.fc29
Summary:  Computational Geometry Algorithms Library
RPMs: CGAL CGAL-demos-source CGAL-devel
Size: 129.57 MiB
Size change:  3.56 MiB
Changelog:
  * Wed Aug 22 2018 Laurent Rineau  - 4.13-0.1.beta1.fc29
  - New upstream release

  * Wed Aug 22 2018 Laurent Rineau  - 4.13-0.2.beta1.fc29
  - add weak dependency to eigen3-devel


Package:  analitza-18.04.3-2.fc29
Old package:  analitza-18.04.3-1.fc29
Summary:  Library of mathematical features
RPMs: analitza analitza-devel
Size: 3.32 MiB
Size change:  -170.12 KiB
Changelog:
  * Wed Aug 22 2018 Rex Dieter  - 18.04.3-2
  - rebuild


Package:  bcc-0.6.1-2.fc29
Old package:  bcc-0.6.1-1.fc29
Summary:  BPF Compiler Collection (BCC)
RPMs: bcc bcc-devel bcc-doc bcc-lua bcc-tools python3-bcc
Size: 22.18 MiB
Size change:  720 B
Changelog:
  * Wed Aug 22 2018 Rafael Fonseca  - 0.6.1-2
  - Fix typo when mangling shebangs.


Package:  bodhi-3.9.0-1.fc29
Old package:  bodhi-3.8.1-2.fc29
Summary:  A modular framework that facilitates publishing software updates
RPMs: bodhi-client bodhi-composer bodhi-docs bodhi-server python2-bodhi 
python2-bodhi-client python3-bodhi python3-bodhi-client
Size: 6.07 MiB
Size change:  19.93 KiB
Changelog:
  * Thu Jul 12 2018 Fedora Release Engineering  - 
3.8.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

  * Wed Aug 22 2018 Randy Barlow  - 3.9.0-1
  - Update to 3.9.0.
  - Fix FTBFS (#1603504).
  - https://bodhi.fedoraproject.org/docs/user/release_notes.html#v3-9-0


Package:  docker-client-java-8.11.7-1.fc29
Old package:  docker-client-java-8.9.2-2.fc29
Summary:  Docker Client
RPMs: docker-client-java
Size: 617.47 KiB
Size change:  23.23 KiB
Changelog:
  * Wed Aug 22 2018 Mat Booth  - 8.11.7-1
  - Update to latest upstream release


Package:  duplicity-0.7.18-1.fc29
Old package:  duplicity-0.7.17-3.fc29
Summary:  Encrypted bandwidth-efficient backup using rsync algorithm
RPMs: duplicity
Size: 3.25 MiB
Size change:  10.36 KiB
Changelog:
  * Wed Aug 22 2018 Gwyn Ciesla  - 0.7.18-1
  - 0.7.18.


Package:  eclipse-abrt-0.0.3-6.fc29
Old package:  eclipse-abrt-0.0.3-5.fc29
Summary:  Eclipse ABRT plugin
RPMs: eclipse-abrt
Size: 32.50 KiB
Size change:  -4 B
Changelog:
  * Wed Aug 22 2018 Mat Booth  - 0.0.3-6
  - Update license tag


Package:  eclipse-cdt-1:9.6.0-0.1.fc29
Old package:  eclipse-cdt-1:9.5.2-1.fc29
Summary:  Eclipse C/C++ Development Tools (CDT) plugin
RPMs: eclipse-cdt eclipse-cdt-arduino eclipse-cdt-docker 
eclipse-cdt-llvm eclipse-cdt-native eclipse-cdt-parsers eclipse-cdt-qt 
eclipse-cdt-sdk eclipse-cdt-tests
Size: 418.54 MiB
Size change:  624.34 KiB
Changelog:
  * Wed Aug 22 2018 Mat Booth  - 1:9.6.0-0.1
  - Update to latest snapshot


Package:  eclipse-egit-5.1.0-0.1.fc29
Old package:  eclipse-egit-5.0.1-2.fc29
Summary:  Eclipse Git Integration
RPMs: eclipse-egit

Re: zram-generator

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 04:15:53PM -0400, David Malcolm wrote:
> On Fri, 2018-08-24 at 17:11 +, Jeff Johnson wrote:
> > Why not Haskell?
> > 
> > Seriously: you provide no reason for rust other than that "C is not
> > attractive".
> > 
> > C is surely a reliable implementation language for long running
> > system services.
> 
> https://cwe.mitre.org/data/definitions/658.html

That's a nice list. I was wondering if there were any I haven't done myself,
but from a cursory glance, I score full bingo ;)

Zbyszek
___
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/6M4LPNLN7NQUBYEPKMOJ3NEAITZEQ4MO/

Re: zram-generator

2018-08-24 Thread stan

On Fri, 24 Aug 2018 16:15:53 -0400
David Malcolm  wrote:

> On Fri, 2018-08-24 at 17:11 +, Jeff Johnson wrote:

> https://cwe.mitre.org/data/definitions/658.html

Is there a list like that for rust?
___
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/6FJSNEUILHKXZBK3B367U672GA35RLWJ/

Fedora 29-20180823.n.0 compose check report

2018-08-24 Thread Fedora compose checker

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

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

ID: 269161  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/269161
ID: 269171  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/269171
ID: 269173  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/269173
ID: 269177  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/269177
ID: 269186  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/269186
ID: 269187  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/269187
ID: 269188  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269188
ID: 269198  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/269198
ID: 269201  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269201
ID: 269202  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/269202
ID: 269205  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/269205
ID: 269206  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269206
ID: 269210  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/269210
ID: 269218  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/269218
ID: 269219  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/269219
ID: 269235  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/269235
ID: 269236  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/269236
ID: 269237  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/269237
ID: 269239  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/269239
ID: 269279  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/269279
ID: 269291  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/269291
ID: 269300  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/269300

Soft failed openQA tests: 74/130 (x86_64), 18/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 269155  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/269155
ID: 269156  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269156
ID: 269158  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/269158
ID: 269159  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269159
ID: 269162  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/269162
ID: 269168  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/269168
ID: 269170  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/269170
ID: 269174  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/269174
ID: 269175  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/269175
ID: 269181  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/269181
ID: 269182  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/269182
ID: 269183  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/269183
ID: 269184  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/269184
ID: 269185  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/269185
ID: 269221  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/269221
ID: 269222  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/269222
ID: 269223  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/269223
ID: 269224  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/269224
ID: 269225  Test: x86_64 universal install_blivet_btrfs
URL:

Re: zram-generator

2018-08-24 Thread David Malcolm

On Fri, 2018-08-24 at 17:11 +, Jeff Johnson wrote:
> Why not Haskell?
> 
> Seriously: you provide no reason for rust other than that "C is not
> attractive".
> 
> C is surely a reliable implementation language for long running
> system services.

https://cwe.mitre.org/data/definitions/658.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/message/EG57YYGH3JHRUA6H6EAVEMADR4RZR5BN/

Re: Scons python2 on fedora 30+

2018-08-24 Thread Jerry James

On Fri, Aug 24, 2018 at 2:22 PM Antonio Trande wrote:
> Hello!
>
> Regarding Python2 package removal, 'python2-SCons' needs special
> attention, i guess.
> It's required for building by many packages on current 'rawhide':

[snip]

> sagemath-0:8.2-4.fc29.src

[snip]

> What's the situation of these packages in a middle-term scenario in
> respect of Python2 removal proposal?

Not good. Sagemath upstream has been working on converting to python
3 for about 5 years now (see https://trac.sagemath.org/ticket/15530),
and they are not done. For now, sagemath must remain a python 2
package. Honestly, given how much work upstream still has to do, I do
not expect the python 3 version of sagemath to be ready any sooner
than a year from now, and quite possibly not until 2 years from now.

I've been meaning to post about this. What do we, as a distribution,
want to do? As I see it, we really only have 2 options.

Option 1. Tell Fedora users that sagemath will not be available for a
few Fedora releases, until upstream completes the conversion to python
3.

Option 2. Keep all of the python 2 packages that sagemath needs in
the distribution until the python 3 version is ready, which possibly
means that they have to be kept through Fedora 32. These are the
immediate dependencies of sagemath. I haven't gotten around to
computing the transitive closure yet. Maybe somebody has a script
that can do that.

pynac
python2-brial
python2-configparser
python2-crypto
python2-cryptominisat
python2-cvxopt
python2-cypari2
python2-cysignals
python2-Cython
python2-docutils
python2-flask-autoindex
python2-flask-babel
python2-flask-openid
python2-flask-silk
python2-fpylll
python2-future
python2-gmpy2
python2-html5lib
python2-imagesize
python2-ipykernel
python2-ipython
python2-matplotlib
python2-networkx
python2-notebook
python2-pathlib2
python2-pexpect
python2-pickleshare
python2-pillow
python2-prompt_toolkit
python2-pkgconfig
python2-psutil
python2-ptyprocess
python2-scipy
python2-send2trash
python2-setuptools
python2-six
python2-speaklater
python2-sphinx
python2-sympy
python2-twisted
python2-ZODB3
rpy
scons

From time to time it is necessary to use the bundled version of
ipython, because Fedora gets too far ahead and the sagemath code can't
cope with the Fedora version. In that case, the dependencies of
ipython not listed above are needed:

python2-backports-shutil_get_terminal_size
python2-path
python2-simplegeneric
python2-zmq

I prefer option 1, of course, but I recognize that that puts a burden
on other packagers. What do you members of the Fedora community
suggest?
--
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/message/GKEDVHZRG7HXDPTM26M3HBR7IBFWMSMK/

mingw-openssl rebased

2018-08-24 Thread Richard W.M. Jones


I've rebased mingw-openssl to match the latest version in Fedora
Rawhide.  This fixes a number of CVEs, but also it's the version with
the new API.

I have kicked off rebuilds for (hopefully) all dependent packages.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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/5TMKVGPYAMBJGQ75657SZEN5FKPFWB4E/

Re: Idea: let's use Pagure to track Changes

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Aug 24, 2018 at 12:16:09PM +0200, Fabio Valentini wrote:
> On Fri, Aug 24, 2018, 11:38 David Sommerseth  wrote:
> 
> > On 23/08/18 22:43, Ben Cotton wrote:
> > > Hi community,
> > >
> > > We've traditionally used the wiki for Change proposals because it's
> > > the tool we had. But, it's not necessarily well-suited to the purpose.
> > > But now we have Pagure, which can help address some of the
> > > shortcomings of using the wiki: poor scriptability, no reporting, and
> > > a lot of copy/paste.
> > >
> > > So I've come up with a plan that would use Pagure instead:
> > > https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> > >
> > > You can read the full details on the wiki page above, but the general
> > > idea is that we won't change the policy for Changes, just how we store
> > > and manipulate them. My intent is to make it nearly seamless for the
> > > community while giving us a platform for building on the process in
> > > the future. Note that this would run parallel to Bugzilla for a
> > > release or two and then replace Bugzilla for Changes tracking.
> >
> > Even though I'm not as active here as I would like to be, I generally like
> > this idea.
> >
> > A few things which would be good to sort out are:
> >
> > * Still requires changes be represented in three different Pagure repos
> > * We lose edit history if a change proposal is updated based on feedback
> >
> 
> Well, I suppose Changes could be represented as markdown/reStructuredText
> files in a repository instead of issues on pagure? Then edit history is no
> problem (that's what git is for), and proposed changes can be done via pull
> requests.

Hmmm, that'd also solve the issue of having a way to display the changes
in a nice way, that I started discussing in the other part of the thread.

Zbyszek

> 
> Off the top of my head I'd suggest using a "fedora-changes" (?) project on
> pagure with folders for different fedora releases.
> 
> - Edit history is accessible through git
> - Changes can be submitted and updated with pull requests
> - Postponing a change is as simple as moving a text file from one folder to
> another
> - Rejected or discarded changes can be archived in another folder
> 
> (Just thinking out loud here.)
> 
> Fabio
> 
> 
> > From my point of view, those are the most critical ones.  The history is
> > good
> > when you want to see if/how things changed - to learn from specific changes
> > which went well or really bad.  Not having a history to base it on makes
> > this
> > learning somewhat more difficult - as you don't know exactly how a change
> > proposal did develop, just the final result.
> >
> > Also having changes represented in three different repos sounds a bit too
> > bureaucratic to me.  Processes are good to have, but in the moment they get
> > too complicated people will generally try to avoid them.  If it is really
> > needed to involve three repos, then a decent tooling on top of it is
> > needed at
> > launch time; to hide this bureaucratic process a bit.
> >
> > Other than that, I think this idea makes perfect sense.  The first time I
> > did
> > a change proposal (not even system-wide), it felt like an odd process ("Is
> > this the right template? In a wiki? Have I filled out all the proper fields
> > correctly? How is this proposal picked up and distributed properly?" are
> > some
> > of the thousands questions which popped up).
> >
> >
> > --
> > kind regards,
> >
> > David Sommerseth
> >
> > ___
> > 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/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
> >

> ___
> 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/R5H22KIXOWYIKUYIRSXZVOZNHINOBVLC/
___
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/6YG7X4THI32J4DSXTJMDSRU2XPSJSNGQ/

Re: Idea: let's use Pagure to track Changes

2018-08-24 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Aug 23, 2018 at 11:52:57PM +0200, Miro Hrončok wrote:
> On 23.8.2018 22:43, Ben Cotton wrote:
> >Hi community,
> >
> >We've traditionally used the wiki for Change proposals because it's
> >the tool we had. But, it's not necessarily well-suited to the purpose.
> >But now we have Pagure, which can help address some of the
> >shortcomings of using the wiki: poor scriptability, no reporting, and
> >a lot of copy/paste.
> 
> Good idea!
> 
> >So I've come up with a plan that would use Pagure instead:
> >https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> 
> > 6. FESCo votes on change.
> 
> On the Pagure ticket with the change or in a separate FESCo Pagure ticket?

I think we should vote in the Change bug. I don't see advantages to
opening a new ticket.

> >You can read the full details on the wiki page above, but the general
> >idea is that we won't change the policy for Changes, just how we store
> >and manipulate them. My intent is to make it nearly seamless for the
> >community while giving us a platform for building on the process in
> >the future. Note that this would run parallel to Bugzilla for a
> >release or two and then replace Bugzilla for Changes tracking.
> 
> The good thing about Bugzilla trackers is that they can be used
> as... Bugzilla trackers. I mean you can block/depend other bugs on
> it.
> 
> See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37
> and the dependent bugs. Of course, this might be relevant to some
> kind of Changes only, so the Bugzilla tracker can be optional, but
> I'd rather keep it as part of the process.

I think we might want to make it an optional element. If the Change
needs a tracking bug, create it, otherwise not. I think most Changes
don't do any real tracking in bugzilla, except to change the bug as
"done" at some point.


One more thing that I didn't see explicitly mentioned in the proposal
is the fact that Change pages are also documentation, fairly widely
accessed, also long after the Change has been implemented. For this,
the fact that the Change page show no context by default is an advantage.
I wonder if we could request an enhancement to pagure to have a view
where just the main text is shown, without the side bar, comments,
headers, etc.

Also, it should be clarified if Change owners should edit the original
text.

Zbyszek
___
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/VSTCNQXOVJWSOJQBE6CXAIJ3XUMKFVDM/

[Bug 1611585] perl-Log-Any-1.707 is available

2018-08-24 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Log-Any-1.707-1.fc27   |perl-Log-Any-1.707-1.fc27
   ||perl-Log-Any-1.707-1.fc28



--- Comment #7 from Fedora Update System  ---
perl-Log-Any-1.707-1.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org/message/SAW2SYUINPLEKGYWVZPYUBEJLBXOXGCV/

[Bug 1611585] perl-Log-Any-1.707 is available

2018-08-24 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Log-Any-1.707-1.fc27
 Resolution|--- |ERRATA
Last Closed||2018-08-24 03:14:54



--- Comment #6 from Fedora Update System  ---
perl-Log-Any-1.707-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org/message/NQF4O6LJUDVEPFJTDS7FQPGR3DNHAKZ3/

[Bug 1616115] perl-Coro-Multicore-1.01 is available

2018-08-24 Thread bugzilla

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



--- Comment #4 from Fedora Update System  ---
perl-Coro-Multicore-1.01-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org/message/TKXLDYF5VY2TNSG7PBOSIJKWKT67OFNE/

[Bug 1615176] perl-Coro-Multicore-1.0 is available

2018-08-24 Thread bugzilla

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



--- Comment #6 from Fedora Update System  ---
perl-Coro-Multicore-1.01-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/perl-devel@lists.fedoraproject.org/message/C5EZAD724GAHFWQPA347LLKESW42CUVX/

Fwd: fedora-tagger sunset - week post F29 beta freeze

2018-08-24 Thread Clement Verna

Dear all,

The Fedora Infrastructure is running the fedora-tagger [0] service,
however it gets little usage and also has no one really maintaining it
or fixing issues with it. Earlier this year [1] we have tried to
support community members who expressed their interests in maintaining
this application, unfortunately this effort did not results in a new
version being released.

During our last meeting [2], we agreed to retire this service a week
after the end of the F29 beta freeze (see F29 schedule [3]).

Once the F29 beta freeze is over, we will communicate a sunset date.

Regards,
Clément

[0] - https://apps.fedoraproject.org/tagger/
[1] - https://communityblog.fedoraproject.org/maintainers-package-tagger/
[2] - 
https://meetbot.fedoraproject.org/teams/infrastructure/infrastructure.2018-08-23-14.00.log.html
[3] - https://fedoraproject.org/wiki/Releases/29/Schedule?rd=Schedule
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org/message/UPM46GFVAD4NHUMOMEWS3XGM52T2YV3T/

[EPEL-devel] Re: EPEL: Python 3.4 will be EOL in March 2019

2018-08-24 Thread Kevin Fenzi

On 08/21/2018 11:06 AM, Miro Hrončok wrote:
>>
>> I'd start untangling the deps and getting the following in:
>>
>>   * six (looking at that one now)
> 
> https://src.fedoraproject.org/rpms/python3-six/pull-request/1
> 
>>   * pytest
>>   * Cython
>>   * PyYAML
>>   * pip
>>   * attrs
>>   * requests
>>   * mock

Yeah, I'd love to see us move this forward and get everything on 3.6...

Unfortunately I don't have a lot of time, but I can review/merge PR's
and do builds and such.

Perhaps we could setup a wiki page or someplace to coordinate?

kevin




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org/message/5SQ7QYAI4QPGREKY7ZM2MJP5BEMYUIKN/

[EPEL-devel] Re: EPEL: Python 3.4 will be EOL in March 2019

2018-08-24 Thread Tim Orling

On Fri, Aug 24, 2018 at 3:04 PM Kevin Fenzi  wrote:

> On 08/21/2018 11:06 AM, Miro Hrončok wrote:
> >>
> >> I'd start untangling the deps and getting the following in:
> >>
> >>   * six (looking at that one now)
> >
> > https://src.fedoraproject.org/rpms/python3-six/pull-request/1


Merged.

> 
> >
> >>   * pytest
> >>   * Cython
> >>   * PyYAML
> >>   * pip
> >>   * attrs
> >>   * requests
> >>   * mock
>
> Yeah, I'd love to see us move this forward and get everything on 3.6...
>
> Unfortunately I don't have a lot of time, but I can review/merge PR's
> and do builds and such.
>
> Perhaps we could setup a wiki page or someplace to coordinate?
>
> kevin
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org/message/5SQ7QYAI4QPGREKY7ZM2MJP5BEMYUIKN/
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org/message/IGFFM7T7IT773RBZWUPOS2YQJVGKQHEA/

44 matches

Mail list logo