[HEADS UP] Meson 0.48.0

[Igor Gnatenko]

Hello folks,

new meson release is out (release notes
) which removes tools
which are deprecated for quite long time:
* mesonconf
* mesonintrospect
* mesontest
* wraptool

I will push it now for Rawhide and F29. F28 and EPEL7 won't get update
because of this incompatibility, but if you need it for building updates --
let me know and I will consider pushing it even there.

Thanks for attention!
-- 

-Igor Gnatenko
___
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

PyWavelets 1.x is coming to Rawhide

[Igor Gnatenko]

Release notes:https://pywavelets.readthedocs.io/en/latest/release.1.0.0.html

There are some incompatible changes so I'm building it only for Rawhide.

Just wanted to let you know yet another software reaching 1.0 milestone.
Enjoy ;)

-- 

-Igor Gnatenko
___
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: Semi-serious proposal: drop all optional entries from comps

[Vít Ondruch]

Dne 24.9.2018 v 19:32 Adam Williamson napsal(a):
> On Mon, 2018-09-24 at 12:21 +0200, Vít Ondruch wrote:
>> Just FTR, some while ago, I proposed to drop comps entirely:
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ISCIB67JKW7WBC74KA4DSCAP6AZOUY5G/
> That...doesn't seem like a very serious proposal at all, given that you
> didn't suggest *in any way* how we would replace the critical functions
> it's currently performing. Are you suggesting metapackages?

Well I proposed "drop comps entirely (or at least trim them down
significantly)". At least the second part is in line with your request I
believe.

And I am not speaking necessarily about "metapackages". But we should
really start using Recommends more and especially Suggest is unused at
all. E.g. in comps, there is "Ruby on Rails" group installing bunch of
packages. There is no reason to not have these dependencies specified in
rubygem-rails (which already exists and has its purpose no matter if
there are comps or not) via Suggests for example. The only issue AFAIK
is there is no real support for Suggests in DNF :/

Or conditional dependencies, e.g. fedora-release could have something
like "Recommends: gnome-shell" and "Recommends: (gnome-* if
gnome-shell)". Again, we have already fedora-release package (is it
metapackage or not?), there is nothing new here. Frankly, I would expect
such dependencies to be there already, but there was no push to do that,
"because we have comps which do the job just fine".

Or we could use Enhances for specifying that some application should be
part of default Gnome experience.

But there could be also metapackages such as "default-gnome-desktop"
which would suggest all the components for default Gnome experience.

There is plenty of options we could use instead of comps.


Vít
___
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-09-25 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: Orphaning some Java packages

[Ben Rosser]

On Mon, Sep 24, 2018 at 3:39 PM, Mikolaj Izdebski  wrote:
> On 09/24/2018 08:52 PM, Miro Hrončok wrote:
>> On 24.9.2018 19:09, Mikolaj Izdebski wrote:
>>> I'm in the process of transitioning maintenance of all software to
>>> modules only. The reason is that module maintenance is much easier
>>> compared to maintenance of non-modular, "ursine" packages.
>>>
>>> Ideally these packages should be retired instead of orphaning them, but
>>> these packages are build-required by a lot of other things.
>> This is an interesting situation. If more maintainers will decide to do
>> this, we can easily break everything and only have modules, except we
>> will no longer have any system to have those modules run on.
>>
>> (I'm not saying you shouldn't do this; I'm just really concerned if
>> modularity is actually helping Fedora as a whole or if it will
>> eventually break it entirely.)
>
> I was hoping for a solution like "ursa-major" described in [1], that
> would allow modules to be used as build-dependencies for non-modular
> packages. This would allow properly retiring non-modular packages and
> maintaining only modules, which would be also used as build dependencies
> for non-modular packages. But it seems that currently no one is
> interested in implementing such solution.
>
> Java SIG is dying slowly, this package set recently lost another
> co-maintainer and I don't have time to maintain all these packages by
> myself. Switching to module-only content is probably the best move to
> keep high-quality software delivered to our users and reduce maintenance
> work at the same time.
>
> [1]
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/message/JZMPGE2VMBHDO4D6SC4YTRSYNQYZOT63/

This is something that worried me also when I read this message.

Are modules only intended for leaf packages at the moment? I admit
that I have not really been keeping up to date with modularity. Or is
the intended workflow that (eventually) everything's a module, and so
if something needs to depend on a module, it too must be inside a
module for this to work?

This seems like it could become a problem, because I imagine that
there are lots of leaf packages out there that aren't in modules, or
don't necessarily need to be in modules-- unless parts of the
distribution start becoming module-only.

(Maybe this discussion belongs in a new thread, but I think it's important).

Ben Rosser
___
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: Semi-serious proposal: drop all optional entries from comps

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> On Sun, Sep 23, 2018 at 06:05:16AM +0100, Peter Robinson wrote:
> > Some of the group stuff is also used during the compose and if things
> > aren't in groups specified but needed by say a kickstart the packages
> > won't be in certain places and will break things. I did this by
> > accident when adding zram in F-29 and not adding it to comps.
> 
> How much if this is an artifact of the compose being designed around trying
> to pack subsets of installable media onto a DVD? Do we currently do that for
> anything but Server, and is it really important that we continue? 

Given the lack of individual package selection in Anaconda, this would mean
that optional package inclusions there are solely for:
- kickstarting off the DVD
- using the DVD as a post-install locally mounted package source

There may be people doing the first. I'd have to think there are better ways
to handle the second.

Bill
___
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: Semi-serious proposal: drop all optional entries from comps

[Matthew Miller]

On Sun, Sep 23, 2018 at 06:05:16AM +0100, Peter Robinson wrote:
> Some of the group stuff is also used during the compose and if things
> aren't in groups specified but needed by say a kickstart the packages
> won't be in certain places and will break things. I did this by
> accident when adding zram in F-29 and not adding it to comps.

How much if this is an artifact of the compose being designed around trying
to pack subsets of installable media onto a DVD? Do we currently do that for
anything but Server, and is it really important that we continue? 

-- 
Matthew Miller

Fedora Project Leader
___
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 30 Self-Contained Change proposal: PHP 7.3

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/php73

= PHP 7.3 =

== Summary ==
Update the PHP stack in Fedora to latest version 7.3.x

== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org

== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.3.x.

* [http://php.net/archive/2018.php#id2018-09-13-2 First RC] was
released on Sept 13th
* PHP 7.3.0 is [https://wiki.php.net/todo/php73 planed] for end of
year, which seems compatible with Fedora roadmap.

Compatibility for PHP code is very good.


== Benefit to Fedora ==
Provides the latest PHP version to developers and system administrators.

== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

== How To Test ==
* The PHP stack (extensions and libraries) are monitored by Koschei,
see the 
https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
* install and play with your web applications

== User Experience ==
Developers and system administrators will have the great benefit or
running the latest PHP version.


== Dependencies ==
All php-* packages (and some *-php)

== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.

== Documentation ==
* [https://raw.githubusercontent.com/php/php-src/PHP-7.3/UPGRADING
* [https://raw.githubusercontent.com/php/php-src/PHP-7.3/UPGRADING.INTERNALS
-- 
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

Re: Orphaning some Java packages

[Mikolaj Izdebski]

On 09/24/2018 08:52 PM, Miro Hrončok wrote:
> On 24.9.2018 19:09, Mikolaj Izdebski wrote:
>> I'm in the process of transitioning maintenance of all software to
>> modules only. The reason is that module maintenance is much easier
>> compared to maintenance of non-modular, "ursine" packages.
>>
>> Ideally these packages should be retired instead of orphaning them, but
>> these packages are build-required by a lot of other things.
> This is an interesting situation. If more maintainers will decide to do
> this, we can easily break everything and only have modules, except we
> will no longer have any system to have those modules run on.
> 
> (I'm not saying you shouldn't do this; I'm just really concerned if
> modularity is actually helping Fedora as a whole or if it will
> eventually break it entirely.)

I was hoping for a solution like "ursa-major" described in [1], that
would allow modules to be used as build-dependencies for non-modular
packages. This would allow properly retiring non-modular packages and
maintaining only modules, which would be also used as build dependencies
for non-modular packages. But it seems that currently no one is
interested in implementing such solution.

Java SIG is dying slowly, this package set recently lost another
co-maintainer and I don't have time to maintain all these packages by
myself. Switching to module-only content is probably the best move to
keep high-quality software delivered to our users and reduce maintenance
work at the same time.

[1]
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/message/JZMPGE2VMBHDO4D6SC4YTRSYNQYZOT63/

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

Re: Semi-serious proposal: drop all optional entries from comps

[Adam Williamson]

On Mon, 2018-09-24 at 08:47 -0700, Adam Williamson wrote:
> If we want to fix that we'd need to somehow run the comps script on all
> changes in dist-git and block those changes on introducing comps
> problems, which seems like a rather more difficult problem.

Well...thinking about it a bit more, it's just a *different* problem, I
guess. We'd need a somewhat different script: it would keep the bit for
reading the packagereq entries from comps, but instead of poking dnf
repos for current packages, it would have to be able to understand what
binary packages the source package in question would produce *before*
the change, and what binary packages it would produce *after* the
change.

That seems easy, but isn't entirely, because you can have stuff like a
%ifarch that produces a given subpackage on some arches but others.
It's another Will Woods Problem, of rpm specs being able to do an awful
lot of stuff that isn't terribly easy to interpret without actually
going through the process of building the package.

I suppose if we wind up having CI which actually runs a package build
for every prospective change to a package, this wouldn't be too
difficult, as we could just read out the subpackages...but yeah, I'd
say it's kind of a *different* thing, anyway.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Semi-serious proposal: drop all optional entries from comps

[Adam Williamson]

On Mon, 2018-09-24 at 12:21 +0200, Vít Ondruch wrote:
> Just FTR, some while ago, I proposed to drop comps entirely:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ISCIB67JKW7WBC74KA4DSCAP6AZOUY5G/

That...doesn't seem like a very serious proposal at all, given that you
didn't suggest *in any way* how we would replace the critical functions
it's currently performing. Are you suggesting metapackages?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Orphaning some Java packages

[Mikolaj Izdebski]

TL;DR  I am planning to orphan Java packages listed below soon after
Fedora 29 GA. Let me know if you want to adopt any of them.

I'm in the process of transitioning maintenance of all software to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages. Starting from
Fedora 29 modules are first-class citizens, so I am finally able to
orphan ursine packages that are already available in modules.

Ideally these packages should be retired instead of orphaning them, but
these packages are build-required by a lot of other things.
Unfortunately as of today modules can't be used as build-requires of
ursine packages and I'm not aware of any plans to change that. Therefore
I will let interested parties take maintenance of orphaned packages, or
else let release engineering figure out how to retire them without
breaking the whole distro.

I decided to start with the following subset of ursine packages for
which I am listed as PoC. Until Fedora 29 GA I will be providing all
updates and fixes to these packages in all active +*release branches.
After Fedora 29 GA I will orphan these packages, but I will keep
providing important bugfixes for Fedora 27 and Fedora 28. After Fedora
28 EOL I will not maintain these packages in release (non-arbitrary)
branches at all - I will maintain only corresponding modules.

If you want to adopt any of these packages, please let me know and I
will happily transfer them to you.


Packages orphan:
ant
ant-contrib
aopalliance
apache-commons-beanutils
apache-commons-collections
apache-commons-compress
apache-commons-io
apache-commons-jxpath
apache-commons-lang
apache-commons-lang3
apache-commons-logging
apache-commons-net
apache-ivy
apache-parent
apache-resource-bundles
aqute-bnd
atinject
bcel
beust-jcommander
bsf
bsh
byaccj
cal10n
easymock
exec-maven-plugin
felix-osgi-core
felix-utils
geronimo-jms
geronimo-jpa
geronimo-parent-poms
glassfish-jsp-api
google-guice
guava20
hawtjni
httpcomponents-client
httpcomponents-core
httpcomponents-project
jakarta-commons-httpclient
jansi
jansi-native
javacc
javacc-maven-plugin
javamail
javapackages-tools
javassist
jaxen
jdepend
jdependency
jflex
jsoup
junit
jvnet-parent
maven
maven-antrun-plugin
maven-archiver
maven-artifact-resolver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-invoker
maven-jar-plugin
maven-parent
maven-plugin-build-helper
maven-plugin-bundle
maven-plugins-pom
maven-plugin-testing
maven-plugin-tools
maven-reporting-api
maven-reporting-impl
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-utils
maven-source-plugin
maven-surefire
maven-verifier
maven-wagon
modello
mojo-parent
munge-maven-plugin
objectweb-pom
osgi-compendium
osgi-core
os-maven-plugin
plexus-ant-factory
plexus-archiver
plexus-bsh-factory
plexus-classworlds
plexus-cli
plexus-compiler
plexus-component-factories-pom
plexus-components-pom
plexus-containers
plexus-i18n
plexus-interactivity
plexus-interpolation
plexus-io
plexus-languages
plexus-resources
plexus-utils
plexus-velocity
qdox
regexp
sisu
sisu-mojos
slf4j
sonatype-oss-parent
sonatype-plugins-parent
velocity
xalan-j2
xbean
xmvn
xz-java

Maintainers by package:
ant  akurtakov jcapik kdaniel mizdebsk msrb
ant-contrib  davidcl mizdebsk
aopalliance  mizdebsk
apache-commons-beanutils fnasser mizdebsk spike
apache-commons-collections jcapik mizdebsk
apache-commons-compress mizdebsk spike
apache-commons-iomizdebsk spike
apache-commons-jxpath fnasser mizdebsk spike
apache-commons-lang  mizdebsk spike
apache-commons-lang3 mizdebsk
apache-commons-logging kdaniel mizdebsk spike
apache-commons-net   mizdebsk spike
apache-ivy   mizdebsk
apache-parentmizdebsk
apache-resource-bundles mizdebsk
aqute-bndjcapik mizdebsk
atinject kdaniel mizdebsk
bcel mizdebsk
beust-jcommander jcapik mizdebsk
bsf  choeger mizdebsk
bsh  mizdebsk
byaccj   akurtakov dbhole mizdebsk
cal10n   mizdebsk
easymock akurtakov ctubbsii dbhole fnasser mizdebsk
exec-maven-pluginmizdebsk
felix-osgi-core  jcapik mizdebsk
felix-utils  jcapik mizdebsk
geronimo-jms mizdebsk
geronimo-jpa lef mizdebsk
geronimo-parent-poms mizdebsk
glassfish-jsp-apikdaniel mizdebsk
google-guice mizdebsk
guava20  mizdebsk
hawtjni  gil goldmann mizdebsk
httpcomponents-client jerboaa kdaniel mizdebsk
httpcomponents-core  jerboaa kdaniel mizdebsk
httpcomponents-project mizdebsk
jakarta-commons-httpclient dbhole ke4qqq mizdebsk
jansigoldmann mizdebsk
jansi-native goldmann mizdebsk
javacc   jcapik mizdeb

Re: Qt 5 update in rawhide

[Kevin Fenzi]

On 09/24/2018 01:59 AM, Jan Grulich wrote:
> Hi,
> 
> this is because Plasma 5.14 beta update, not related to my Qt 5 update. I'm 
> cc-ing Martin Kyral as he is responsible for this update.

No problem. I don't want to blame anyone... but if we can figure out how
to prevent it from happening again that would be great. :)

kevin
--
> Regards,
> Jan
> 
> On pondělí 24. září 2018 0:32:23 CEST Kevin Fenzi wrote:
>> On 09/23/2018 02:59 PM, Kevin Fenzi wrote:
>>> On 09/22/2018 04:05 AM, Jan Grulich wrote:
 Hi,

 all packages should be now updated. If you experience broken
 dependencies, let me please know.
>>>
>>> Alas, some packages seem to have failed to build because their
>>> buildrequires hadn't landed in the buildroot yet. ;(
>>>
>>> This broke todays rawhide (since the release bocking kde live failed).
>>>
>>> I have done rebuilds (with waits for buildroot) for:
>>>
>>> plasma-breeze-5.13.90-1.fc30
>>> plasma-integration-5.13.90-2.fc30
>>> kwin-5.13.90-2.fc30
>>> plasma-workspace-5.13.90-1.fc30
>>> ksysguard-5.13.90-1.fc30
>>> plasma-oxygen-5.13.90-1.fc30
>>> plasma-desktop-5.13.90-1.fc30
>>> powerdevil-5.13.90-1.fc30
>>>
>>> and then I am now to kmenuedit and khotkeys and plasma-systemsettings.
>>>
>>> I'll try and get the rest, but if you have a handy koji chain-build for
>>> these deps let me know and you may be able to do it faster.
>>
>> Looks like it was only kmenuedit and plasma-systemsettings.
>>
>> kevin
> 
> 




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

Re: Semi-serious proposal: drop all optional entries from comps

[Adam Williamson]

On Mon, 2018-09-24 at 08:26 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Sep 23, 2018 at 10:41:31AM +0200, Nicolas Mailhot wrote:
> > Le samedi 22 septembre 2018 à 11:38 -0700, Adam Williamson a écrit :
> > > But at the same time I think Matt's right that comps -at least as it's
> > > currently set up - is kind of a really *bad* way of doing this, and
> > > that seems fairly well demonstrated by the problem I'm trying to solve
> > > - that comps has tons of broken entries in it. Just from looking
> > > through the file as I do this, I really suspect that no-one is
> > > maintaining quite a lot of the groups and the packages in them may
> > > well just not make much sense any more.
> > 
> > That's a QA problem
> > 
> > But really, the problem is not the comps format, it's that any kind of
> > classification activity is both tedious and optional (if you know how to
> > classify a package you do not need the classification in the first
> > place), rots fast in presence of high package churn, and can only work
> > long term with lots of janitorial involvement (both human and
> > automated).
> 
> That was my first thought too.
> 
> On Fri, Sep 21, 2018 at 06:14:51PM -0700, Adam Williamson wrote:
> > I am currently working on finding and removing all comps entries that
> > point to packages which don't exist any more.
> > 
> > While doing this extremely tedious task [...]
> 
> I would love to see some more info before any decisions are made.
> I *thought* I more-or-less understand the comps process, I remember
> doing some minor changes in the past, but things seem to have changed.
> 
> How are you doing those checks? Is it 
> https://pagure.io/fedora-comps/pull-request/328?

Yes.

> It should be possible to turn those checks into CI hooks.

Eh...it'd need a less janky script. That one is pretty dumb. Besides,
there's an obvious problem with that idea: missing packages don't
usually show up in the list via comps PRs. It's not that people make
changes to comps that list packages which don't exist *right then* -
not usually, anyway. What happens is packages get retired or renamed,
and no-one remembers to update comps.

If we want to fix that we'd need to somehow run the comps script on all
changes in dist-git and block those changes on introducing comps
problems, which seems like a rather more difficult problem.

> There was some jenkins jobs being run on PRs in
> pagure.io/fedora-comps, but it seems to have atrophied and
> doesn't appear on new PRs. Do we have any automated checks for comps now?

I don't think so.

> Instead of designing a whole new system that needs to be
> a) designed, b) agreed, c) documented, d) implemented, e) integrated
> with all the other tools, and f) referenced in all the docs where
> the old system is now referenced,
> why not first fix the CI to do the checks? Pruning nonexistent packages
> really sounds like something that can automatized.

Well, it's not quite as simple as it sounds to do it correctly, in fact
- it took me about five hours to handle the first 40 or so bad entries,
because I didn't just unthinkingly chop out all the entries. I actually
looked at each package's dist-git history and sometimes upstream
history to figure out why it had been retired, whether it had been
directly replaced by something else, or if there was in some other way
a clear replacement for it.

Besides, the reason we're now kicking around the possibility of
replacing/improving the system itself is that this isn't the *only*
problem with it.

> Another question: people keep mentioning unexpected breakage from
> changes by random contributors. But https://pagure.io/fedora-comps/
> seems *very* tightly controlled with write access by only @releng and
> adamw. So is this still actually a problem?

Not much (though it can sometimes be hard to completely predict the
impact of all proposals). But it *used* to be, which is why we have the
tight access control. Adding the tight access control, though - as KK
correctly pointed out - has the negative effect of making it perhaps
too *hard* to make changes that will always be trivial in impact, like
adding/removing 'optional' entries to/from a group mainly intended for
display in package managers.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: DNF and Modularity

[Miroslav Suchý]

Dne 24.9.2018 v 17:17 Kevin Fenzi napsal(a):
> On 09/24/2018 03:24 AM, M A Young wrote:
>> On Mon, 24 Sep 2018, Petr Šabata wrote:
>>
>>>
>>> Definitely an error.
>>>
>>> Could be another case of
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it
>>> should have been fixed last week.  Is your repo current?
>>> Could you check for the presence of modular repodata (the
>>> *modules.yaml.gz) file.
>>
>> the dnf upgrade problem looks to me like
>> https://bugzilla.redhat.com/show_bug.cgi?id=1616118
> 
> 
> It's actually fallout from https://pagure.io/releng/issue/7827
> 
> Basically we are building flatpaks from modules, but then the modules
> are getting into the normal module stream. They shouldn't and we need to
> setup some different tagging for them to avoid it.

I do not believe this is the case. I do not have installed bubblewrap from 
module. I have bubblewrap from F29. The
problem is that

bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 > bubblewrap-0.3.0-2.fc29.x86_64

And DNF put the module version into sack, despite the fact that I have all 
modules disabled.

I thin that BZ 1616118 correctly describe it.

Miroslav



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: DNF and Modularity

[Adam Williamson]

On Mon, 2018-09-24 at 08:17 -0700, Kevin Fenzi wrote:
> On 09/24/2018 03:24 AM, M A Young wrote:
> > On Mon, 24 Sep 2018, Petr Šabata wrote:
> > 
> > > Definitely an error.
> > > 
> > > Could be another case of
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it
> > > should have been fixed last week.  Is your repo current?
> > > Could you check for the presence of modular repodata (the
> > > *modules.yaml.gz) file.
> > 
> > the dnf upgrade problem looks to me like
> > https://bugzilla.redhat.com/show_bug.cgi?id=1616118
> 
> It's actually fallout from https://pagure.io/releng/issue/7827
> 
> Basically we are building flatpaks from modules, but then the modules
> are getting into the normal module stream. They shouldn't and we need to
> setup some different tagging for them to avoid it.

Well, that's part of it, but dnf actually printing these messages is
kind of a bug regardless. Even without that problem, there are always
likely to be some "real" modules that have packages in them which are
ahead of the non-modular package, and thus this bug will be prone to
happen so long as dnf doesn't just treat this as a normal situation and
print no warning message.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: DNF and Modularity

[Kevin Fenzi]

On 09/24/2018 03:24 AM, M A Young wrote:
> On Mon, 24 Sep 2018, Petr Šabata wrote:
> 
>>
>> Definitely an error.
>>
>> Could be another case of
>> https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it
>> should have been fixed last week.  Is your repo current?
>> Could you check for the presence of modular repodata (the
>> *modules.yaml.gz) file.
> 
> the dnf upgrade problem looks to me like
> https://bugzilla.redhat.com/show_bug.cgi?id=1616118


It's actually fallout from https://pagure.io/releng/issue/7827

Basically we are building flatpaks from modules, but then the modules
are getting into the normal module stream. They shouldn't and we need to
setup some different tagging for them to avoid it.

kevin



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

Re: Semi-serious proposal: drop all optional entries from comps

[Stephen Gallagher]

On Mon, Sep 24, 2018 at 11:15 AM Kevin Fenzi  wrote:
> Metapackages have other issues too. They make it difficult to consume
> part of a group. You either have to have everything or nothing. With
> comps groups you can install a group, remove some packages you don't
> want and still get updates to the group, with metapackages it's all or
> nothing.
>

That used to be true, but with Recommends these days, it's considerably less so.
___
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: Semi-serious proposal: drop all optional entries from comps

[Kevin Fenzi]

On 09/23/2018 10:14 PM, Nicolas Mailhot wrote:
> Le lundi 24 septembre 2018 à 00:57 +0200, Kevin Kofler a écrit :
>>
>> Another issue if you want to use metapackages for categorization is
>> that UIs 
>> such as Dnfdragora, or whatever tool converts the metapackages to a 
>> representation those UIs will consume, would have to be told what
>> packages 
>> are such categorization metapackages. 
> 
> That's trivially solvable by requiring they are named
> metapackage-something
> and contain a metapackage(something) provides
> 
> That would not change the fact such categorization helps tend to rot
> over time if not cared about. They would regularly miss composes due to
> broken deps.

Metapackages have other issues too. They make it difficult to consume
part of a group. You either have to have everything or nothing. With
comps groups you can install a group, remove some packages you don't
want and still get updates to the group, with metapackages it's all or
nothing.

kevin





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

summary of today's FESCo Meeting (2018-09-24)

[Zbigniew Jędrzejewski-Szmek]

Hi,

there were no tickets to discuss, and Open Floor yielded nothing too.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-24/fesco.2018-09-24-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-24/fesco.2018-09-24-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-24/fesco.2018-09-24-15.00.log.html

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

Re: python2-matplotlib needs a maintainer

[Miro Hrončok]

On 24.9.2018 16:17, Igor Gnatenko wrote:
On Mon, Sep 24, 2018 at 4:15 PM Miro Hrončok > wrote:


On 21.9.2018 12:19, Miro Hrončok wrote:
 > We updated python-matplotlib to 3.0.0. It only supports Python 3.
This
 > was done in Rawhide only.
 >
 > The python2-matplotlib* subpackages were moved to a new SRPM,
 > python2-matplotlib (remains at 2.2.x), as plenty of cruft still
needs
 > them :(
 >
 > If you experience some relevant trouble (conflicts between packages,
 > blocked updates, unresolved deps, matplotlib not working, your plots
 > exploding...) please file bugs or let me know.
 >
 > python2-matplotlib needs a maintainer. Volunteer at your local
animal
 > shelter (e-mail me). I'll orphan in ~1 week.

Nobody?

It's needed by:

    ...
    python-mne


Drop py2 subpkg.


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


    python-moss


Same.


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


    python-pyriemann


And here.



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


Sure thing. It will be dropped eventually.


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

Re: python2-matplotlib needs a maintainer (was: matplotlib 3 (no Python 2 support) in rawhide)

[Igor Gnatenko]

On Mon, Sep 24, 2018 at 4:15 PM Miro Hrončok  wrote:

> On 21.9.2018 12:19, Miro Hrončok wrote:
> > We updated python-matplotlib to 3.0.0. It only supports Python 3. This
> > was done in Rawhide only.
> >
> > The python2-matplotlib* subpackages were moved to a new SRPM,
> > python2-matplotlib (remains at 2.2.x), as plenty of cruft still needs
> > them :(
> >
> > If you experience some relevant trouble (conflicts between packages,
> > blocked updates, unresolved deps, matplotlib not working, your plots
> > exploding...) please file bugs or let me know.
> >
> > python2-matplotlib needs a maintainer. Volunteer at your local animal
> > shelter (e-mail me). I'll orphan in ~1 week.
>
> Nobody?
>
> It's needed by:
>
>ahkab
>python-igor
>anki
>flatcam
>freecad
>grass
>icaro
>mirrormanager2
>nfsometer
>pondus
>python-phyghtmap
>python-pysb
>qgis
>reinteract
>rootplot
>rtlsdr-scanner
>sagemath
>scitools
>seekwatcher
>sidc-gui
>tuna
>python-ase
>python-astroML
>python-basemap
>python-descartes
>python-healpy
>python-networkx
>python-nltk
>python-pandas
>python-seaborn
>python-subunit2sql
>sympy
>APLpy
>ginga
>moose
>nest
>python-assimulo
>python-cma
>python-deltasigma
>python-librosa
>
   python-mne
>

Drop py2 subpkg.

   python-moss
>

Same.

   python-music21
>python-nb2plots
>python-pyriemann
>

And here.

   python-sphinx-gallery
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800 <+420%20777%20974%20800>
> IRC: mhroncok
>

-- 

-Igor Gnatenko
___
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

python2-matplotlib needs a maintainer (was: matplotlib 3 (no Python 2 support) in rawhide)

[Miro Hrončok]

On 21.9.2018 12:19, Miro Hrončok wrote:
We updated python-matplotlib to 3.0.0. It only supports Python 3. This 
was done in Rawhide only.


The python2-matplotlib* subpackages were moved to a new SRPM, 
python2-matplotlib (remains at 2.2.x), as plenty of cruft still needs 
them :(


If you experience some relevant trouble (conflicts between packages, 
blocked updates, unresolved deps, matplotlib not working, your plots 
exploding...) please file bugs or let me know.


python2-matplotlib needs a maintainer. Volunteer at your local animal 
shelter (e-mail me). I'll orphan in ~1 week.


Nobody?

It's needed by:

  ahkab
  python-igor
  anki
  flatcam
  freecad
  grass
  icaro
  mirrormanager2
  nfsometer
  pondus
  python-phyghtmap
  python-pysb
  qgis
  reinteract
  rootplot
  rtlsdr-scanner
  sagemath
  scitools
  seekwatcher
  sidc-gui
  tuna
  python-ase
  python-astroML
  python-basemap
  python-descartes
  python-healpy
  python-networkx
  python-nltk
  python-pandas
  python-seaborn
  python-subunit2sql
  sympy
  APLpy
  ginga
  moose
  nest
  python-assimulo
  python-cma
  python-deltasigma
  python-librosa
  python-mne
  python-moss
  python-music21
  python-nb2plots
  python-pyriemann
  python-sphinx-gallery


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

Re: Managing stream (arbitrary) branch and module lifecycles

[Owen Taylor]

On Mon, Sep 24, 2018 at 7:04 AM Adam Samalik  wrote:

> I thought about this for a while, and I can see some conceptual
> similarities between upgrading a major Fedora release and changing a module
> stream. I tried to think about major Fedora releases (I mean f28, f29, etc)
> as "streams" of Fedora, the same way as streams of modules, with stable API.
>
> Until now, there was a single type of upgrade in Fedora — the major
> release upgrade. But with Modularity, there is more than that. It's no
> longer single monolithic upgrade of the whole OS. People can now upgrade
> (== change streams) different parts of the OS potentially independently. We
> need to think how to present this to users. Will it require a change of
> mindset?
>

I think we have to be very careful about making the default experience have
too much complexity to it. For graphical applications we are using Flatpaks
to get this separation of OS upgrade and application upgrade, *but* we're
planning to have applications be single stream - so applications just roll
forward with upstream stable releases. So the total complexity stays low.

Also, with the effort of separating apps and the OS we've discussed at
> Flock, will the goal be to get the "OS part" upgradable at any time, and,
> independently on that, users will choose to upgrade (again, change streams)
> individual parts of the system (modules) for new features? That probably
> will require a change of mindset. It sounds similar how a phone works. Do
> we need to develop a whole new UX around this?
>

We have no current plans to create a *graphical* user experience around
installation of modules as loose packages. Even creating a decent command
line experience around it seems very difficult, since if you allow
independent module maintenance, two modules can start conflicting at any
time (even without a branch switch!).

 "Updated versions of reviewboard and sagemath have different versions of
python2-, do you want to"
  A) Remove reviewboard
  B) Remove sagemath
  C) Use the version of python2- from reviewboard and hope for
the best
  D) Use the version of python2- from sagemath and hope for the
best
  E) Find a nearby brick wall to bang your head against

On the other hand, if you don't allow independent module maintenance and
enforce compatible versions across the entire set of modules included in
the modular compose, you've lost some of the point of modularity... still,
that's better, in my opinion than presenting the user with lose-lose
options.

Owen


> On Thu, Sep 20, 2018 at 11:01 PM Randy Barlow <
> bowlofe...@fedoraproject.org> wrote:
>
>> On 9/20/18 1:56 PM, Matthew Miller wrote:
>> > If it's "they'll find out when dnf system-upgrade errors out!", then see
>> > above. I'm ... not enthused. Something in dnf system-upgrade needs to
>> do it;
>> > possibly a "dnf system-upgrade prep" step before "download".
>>
>> I agree. Would it be feasible for the system-upgrade plugin to prompt
>> the user with "hey, you are using 1.7 but you need to switch to 1.8 to
>> upgrade. Proceed? (y/N)".
>>
>> ___
>> 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
>>
>
>
> --
>
> 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
>
___
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: What to do about sagemath

[Miro Hrončok]

On 24.9.2018 15:28, Owen Taylor wrote:
Using modules for this purpose will take some care for parallel 
installability - unless you are happy with sagemath only being runnable 
from within a container.


Unless I'm missing something, to restore a python2 subpackage that has 
been removed in the main Fedora, you'd need to:


  - Create a stream branch
  - Modify the spec file in that branch to *only* build the python2 
subpackage


IMHO You can build the python3 package as well, but blacklist it from 
the module.



  - Include that stream branch in your module



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

qpdf soname bump in rawhide to 21.2.1

[Zdenek Dohnal]

Hi,

qpdf got new version and I would like to rebase our rawhide version, but
two packages will need to be rebuilt, because they depends on libqpdf
library. They are:

- python-pikepdf

- cups-filters

I can manage cups-filters rebuild, but I would like to ask
python-pikepdf's maintainer to rebuild his package.

I have copr project
https://copr.fedorainfracloud.org/coprs/zdohnal/qpdf/builds/ , where I
tried to rebuild cups-filters and python-pikepdf with new qpdf.
python-pikepdf's new version fails to build even with old qpdf (I
reported it to python-pikepdf's maintainer at bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1631890).

Because python-pikepdf is broken anyway, I'll rebuild cups-filters and
put new qpdf with rawhide.

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C




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: What to do about sagemath

[Owen Taylor]

Using modules for this purpose will take some care for parallel
installability - unless you are happy with sagemath only being runnable
from within a container.

Unless I'm missing something, to restore a python2 subpackage that has been
removed in the main Fedora, you'd need to:

 - Create a stream branch
 - Modify the spec file in that branch to *only* build the python2
subpackage
 - Include that stream branch in your module

Regards,
Owen


On Sun, Sep 23, 2018 at 12:07 AM Jerry James  wrote:

> On Sat, Sep 22, 2018 at 4:55 PM Miro Hrončok  wrote:
> > I never thought I would ever ask this, but would it make sense to get
> > sagemath into a module? We could pin all the necessary python2 packages
> > in the module to the current (or even older?) versions (and don't update
> > them to newer versions that possibly drop py2 support). The rest of
> > Fedora could move forward and sagemath would keep going on.
>
> H, that might make sense, at that.  I have to admit now that I
> haven't really been following the development of modules, and don't
> really know how they work.  I'll try to read up on them next week.
>
> Thanks for the suggestion.
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning several nodejs-* packages

[Stephen Gallagher]

On Thu, Sep 20, 2018 at 11:00 AM Stephen Gallagher  wrote:
>
> I'm planning to orphan the following packages tomorrow, as I don't use
> them any more and don't have time to maintain them properly:
>
> * nodejs-spdx-expression-parse-v2.0.2
> * nodejs-aproba-v2.0.0
> * nodejs-read-package-tree

These three have been orphaned.

> * nodejs-less-3.8.1
>

nodejs-less was taken by Tom Hughes.

> If anyone would like to pick them up, let me know and I'll reassign
> them. Otherwise they'll be orphaned sometime tomorrow.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Monday's FESCo Meeting (2018-09-24)

[Zbigniew Jędrzejewski-Szmek]

Hello everyone,

we have no tickets on the agenda for the FESCo meeting today,
so hopefully it will be short one.

The meeting will be held at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-09-24 15:00 UTC'

Links to all issues can be found at: 
https://pagure.io/fesco/issues

If you would like to add something to this agenda, you can reply to
this e-mail, file a new issue at https://pagure.io/fesco, e-mail me
directly, or bring it up at the end of the meeting, during the open
floor topic. Note that added topics may be deferred until the
following meeting.

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

Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Michael Schwendt]

On Mon, 24 Sep 2018 11:27:49 +0200, Florian Weimer wrote:

> Actually, I assume Google simply made a mistake here.  But this is
> getting off-topic.

As I've mentioned in the Fedora bugzilla ticket, pointing at the gnutls
API is not a solution. libetpan upstream would appreciate a pull request.

  https://github.com/dinhviethoa/libetpan/issues/258#issuecomment-423823453

Patching Claws Mail won't be enough.
___
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: Managing stream (arbitrary) branch and module lifecycles

[Adam Samalik]

I thought about this for a while, and I can see some conceptual
similarities between upgrading a major Fedora release and changing a module
stream. I tried to think about major Fedora releases (I mean f28, f29, etc)
as "streams" of Fedora, the same way as streams of modules, with stable API.

Until now, there was a single type of upgrade in Fedora — the major release
upgrade. But with Modularity, there is more than that. It's no longer
single monolithic upgrade of the whole OS. People can now upgrade (==
change streams) different parts of the OS potentially independently. We
need to think how to present this to users. Will it require a change of
mindset?

Also, with the effort of separating apps and the OS we've discussed at
Flock, will the goal be to get the "OS part" upgradable at any time, and,
independently on that, users will choose to upgrade (again, change streams)
individual parts of the system (modules) for new features? That probably
will require a change of mindset. It sounds similar how a phone works. Do
we need to develop a whole new UX around this?

On Thu, Sep 20, 2018 at 11:01 PM Randy Barlow 
wrote:

> On 9/20/18 1:56 PM, Matthew Miller wrote:
> > If it's "they'll find out when dnf system-upgrade errors out!", then see
> > above. I'm ... not enthused. Something in dnf system-upgrade needs to do
> it;
> > possibly a "dnf system-upgrade prep" step before "download".
>
> I agree. Would it be feasible for the system-upgrade plugin to prompt
> the user with "hey, you are using 1.7 but you need to switch to 1.8 to
> upgrade. Proceed? (y/N)".
>
> ___
> 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
>


-- 

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

Re: DNF and Modularity

[M A Young]

On Mon, 24 Sep 2018, Petr Šabata wrote:

> On Mon, Sep 24, 2018 at 10:02:39AM +0200, Miroslav Suchý wrote:
> > Hi,
> > I have to admit that I am a bit puzzled about DNF behavior with modularity.
> > 
> > I have installed repo files with modularity repos, but all of them are 
> > disabled. I have no module enabled on my system
> > (F29 BTW). To be precise:
> >   output of `dnf module list`
> >   https://paste.fedoraproject.org/paste/3QvX2xv4OgVVmgckTnEQcQ
> > 
> > And every time I run `dnf upgrade` I get this output:
> > 
> > Problem 1: cannot install the best update candidate for package 
> > bubblewrap-0.3.0-2.fc29.x86_64
> >   - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
> >  Problem 2: cannot install the best update candidate for package 
> > docker-distribution-2.6.2-7.git48294d9.fc28.x86_64
> >   - package 
> > docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 is 
> > disabled
> >  Problem 3: cannot install the best update candidate for package 
> > eog-3.28.3-1.fc29.x86_64
> >   - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
> >  Problem 4: cannot install the best update candidate for package 
> > exempi-2.4.5-3.fc29.x86_64
> >   - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
> >  Problem 5: cannot install the best update candidate for package 
> > flatpak-runtime-config-27-7.fc29.x86_64
> >   - package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is 
> > disabled
> >  Problem 6: cannot install the best update candidate for package 
> > gimp-2:2.10.6-2.fc29.x86_64
> >   - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
> >  Problem 7: cannot install the best update candidate for package 
> > gimp-libs-2:2.10.6-2.fc29.x86_64
> >   - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
> >  Problem 8: cannot install the best update candidate for package 
> > kubernetes-client-1.10.3-1.fc29.x86_64
> >   - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is 
> > disabled
> >  Problem 9: cannot install the best update candidate for package 
> > libnghttp2-1.33.0-1.fc29.x86_64
> >   - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
> >  Problem 10: cannot install the best update candidate for package 
> > libpeas-1.22.0-9.fc29.x86_64
> >   - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
> >  Problem 11: cannot install the best update candidate for package 
> > libpeas-gtk-1.22.0-9.fc29.x86_64
> >   - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
> >  Problem 12: cannot install the best update candidate for package 
> > libpeas-loader-python3-1.22.0-9.fc29.x86_64
> >   - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is 
> > disabled
> >  Problem 13: cannot install the best update candidate for package 
> > libuv-1:1.22.0-2.fc29.x86_64
> >   - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled
> >  Problem 14: cannot install the best update candidate for package 
> > nghttp2-1.33.0-1.fc29.x86_64
> >   - package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
> >  Problem 15: cannot install the best update candidate for package 
> > nodejs-1:10.11.0-1.fc29.x86_64
> >   - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled
> >  Problem 16: cannot install the best update candidate for package 
> > npm-1:6.4.1-1.10.11.0.1.fc29.x86_64
> >   - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is disabled
> >  Problem 17: cannot install the best update candidate for package 
> > perl-DB_File-1.842-1.fc29.x86_64
> >   - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
> >  Problem 18: cannot install the best update candidate for package 
> > perl-HTTP-Tiny-0.076-1.fc29.noarch
> >   - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
> >  Problem 19: cannot install the best update candidate for package 
> > perl-Thread-Queue-3.13-1.fc29.noarch
> >   - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
> > 
> > It does not matter if I pass `--best` option or not.
> > Why I - as a user - see this warnings/errors?
> > 
> > Is this an error or a feature?
> 
> Definitely an error.
> 
> Could be another case of
> https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it
> should have been fixed last week.  Is your repo current?
> Could you check for the presence of modular repodata (the
> *modules.yaml.gz) file.

the dnf upgrade problem looks to me like
https://bugzilla.redhat.com/show_bug.cgi?id=1616118

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

Re: Semi-serious proposal: drop all optional entries from comps

[Vít Ondruch]

Just FTR, some while ago, I proposed to drop comps entirely:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ISCIB67JKW7WBC74KA4DSCAP6AZOUY5G/


Vít


Dne 22.9.2018 v 03:14 Adam Williamson napsal(a):
> Hi folks!
>
> I am currently working on finding and removing all comps entries that
> point to packages which don't exist any more.
>
> There are quite a lot of them.
>
> A lot of them are 'optional' entries.
>
> While doing this extremely tedious task, it occurred to me to think:
> what the hell is the *point* of these 'optional' entries any more,
> anyway?
>
> In Ye Olde Days, there was an obvious point to them: they showed up in
> the installer. Prior to Fedora 18, with the old anaconda UI, the
> 'package selection' screen gave you per-package selection within the
> comps groups. You could get it to show you a list of all packages in
> the group. Ones which were 'mandatory' would be locked in the GUI; you
> couldn't install the group and *not* install that package. Ones which
> were 'default' would be selected by default when you selected the
> group, but you could unselect them if you wanted. And ones which were
> 'optional' would be unselected by default, but they were *displayed*,
> and you could select them if you wanted.
>
> It looked like this:
>
> https://www.tecmint.com/wp-content/uploads/2012/07/rhel-15.png
>
> (you got to see the 'optional' packages if you clicked
> on...well...'Optional packages').
>
> The old gnome-packagekit, IIRC, also parsed groups and showed you all
> this stuff.
>
> But...we don't do that any more. anaconda does not expose 'optional'
> packages in any way any more (you can only pick environment groups and
> their supplementary package groups in anaconda, now). GNOME Software
> doesn't either.
>
> So do we really need these acres of 'optional' packages in comps? I
> mean, there are 2519 of them in comps-f30.xml.in. That's a lot. I
> suspect no-one's looked whether most of them make any sense for years.
> There are entire groups that are *nothing but optional packages*,
> making them almost entirely useless.
>
> So, OK, I think there are probably apps out there that still expose
> this info. I suspect dnfdragora does, for instance. But is the minor
> benefit of having these lists of 'hey maybe you'd like this thing' in
> minor package managers really worth the way they turn comps into even
> more of a gigantic crufty ball-of-wax than it would otherwise be?
>
> Is anyone really super-attached to this kinda stuff?
>
>   4ti2
>   alt-ergo
>   alt-ergo-gui
>   atlas
>   automaton
>   automaton-javadoc
>   azove
>   blas
>   bliss
>   bowtie
>   brial
>   bwa
>   cantor
>   cddlib
>   chemtool
>   coq
>   coq-coqide
>   coq-doc
>   coq-emacs
>   cryptominisat
>   csdp
>   csdp-tools
>   cudd
>   cudd-devel
>   cvc4
>   cvc4-devel
>   cvc4-doc
>   dx
>   E
>   eclib
>   EMBOSS
>   fastx_toolkit
>   fflas-ffpack-devel
>   fityk
>   flint
>   flocq
>   frama-c
>   freefem++
>   gabedit
>   galculator
>   gap
>   gappa
>   gappalib-coq
>   gdl
>   genius
>   geomview
>   gfan
>   ginac
>   glimmer
>   GMT
>   gshhg-gmt-nc4-full
>   gshhg-gmt-nc4-high
>   GMT-doc
>   gnome-chemistry-utils
>   gpredict
>   grace
>   grads
>   gromacs
>   gromacs-openmpi
>   gts
>   hdf
>   hdf5
>   hmmer
>   jmol
>   kpolynome
>   kst
>   lagan
>   lapack
>   latte-integrale
>   libmatheval
>   libtcd
>   linbox
>   ltl2ba
>   Macaulay2
>   malaga
>   maxima-gui
>   meataxe
>   minisat2
>   molsketch
>   mona
>   mona-devel
>   mona-emacs
>   mona-examples
>   mona-xemacs
>   mpfi
>   ncl
>   nco
>   ncview
>   netcdf
>   normaliz
>   openbabel
>   opencv
>   paraview
>   picosat
>   picosat-devel
>   plotutils
>   brial
>   polymake
>   pvs-sbcl
>   pypop
>   python3-biopython
>   python3-cvxopt
>   python3-networkx
>   python3-theano
>   qalculate-gtk
>   qalculate-kde
>   qepcad-B
>   qtoctave
>   root
>   routino
>   rrdtool
>   scidavis
>   seaview
>   sextractor
>   SIBsim4
>   stix-math-fonts
>   stp
>   symmetrica
>   sympy
>   tcd-utils
>   TeXmacs
>   tgif
>   tideEditor
>   TOPCOM
>   vaspview
>   veusz
>   vinci
>   wgrib
>   wgrib2
>   why
>   why3
>   wise2
>   wvs-data
>   xdrawchem
>   xgap
>   xtide
>   zenon
>
> can anyone even guess what package group that is?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.f

Fedora 29-20180923.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 284724  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/284724
ID: 284738  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/284738
ID: 284750  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/284750
ID: 284756  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/284756
ID: 284792  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/284792

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

ID: 284692  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/284692
ID: 284693  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/284693
ID: 284718  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/284718
ID: 284719  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/284719
ID: 284747  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/284747
ID: 284797  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/284797

Passed openQA tests: 115/132 (x86_64), 22/24 (i386)

Skipped openQA tests: 10 of 158
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Florian Weimer]

* Nicolas Mailhot:

> The RFC clearly states there is ongoing work to remove any issue that
> would prevent use of SNI everywhere. And you assume Google cares more
> about scalability, than about mixing traffic as much as possible, to
> avoid third parties interfering with the way it wants its network flow
> to reach end users.

Actually, I assume Google simply made a mistake here.  But this is
getting off-topic.

Florian
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Nicolas Mailhot]

Le 2018-09-24 08:49, Florian Weimer a écrit :

* Nicolas Mailhot:


Le dimanche 23 septembre 2018 à 22:39 +0200, Florian Weimer a écrit :



In Google's case, there is only one server, imap.gmail.com:

  


That's the public name, nothing stops them from sharing part of the 
entry point with google@work stuff.



Among other things, this avoids the scalability problems mentioned in
RFC 7817.


The RFC clearly states there is ongoing work to remove any issue that 
would prevent use of SNI everywhere. And you assume Google cares more 
about scalability, than about mixing traffic as much as possible, to 
avoid third parties interfering with the way it wants its network flow 
to reach end users.


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

Re: Qt 5 update in rawhide

[Jan Grulich]

Hi,

this is because Plasma 5.14 beta update, not related to my Qt 5 update. I'm 
cc-ing Martin Kyral as he is responsible for this update.

Regards,
Jan

On pondělí 24. září 2018 0:32:23 CEST Kevin Fenzi wrote:
> On 09/23/2018 02:59 PM, Kevin Fenzi wrote:
> > On 09/22/2018 04:05 AM, Jan Grulich wrote:
> >> Hi,
> >> 
> >> all packages should be now updated. If you experience broken
> >> dependencies, let me please know.
> > 
> > Alas, some packages seem to have failed to build because their
> > buildrequires hadn't landed in the buildroot yet. ;(
> > 
> > This broke todays rawhide (since the release bocking kde live failed).
> > 
> > I have done rebuilds (with waits for buildroot) for:
> > 
> > plasma-breeze-5.13.90-1.fc30
> > plasma-integration-5.13.90-2.fc30
> > kwin-5.13.90-2.fc30
> > plasma-workspace-5.13.90-1.fc30
> > ksysguard-5.13.90-1.fc30
> > plasma-oxygen-5.13.90-1.fc30
> > plasma-desktop-5.13.90-1.fc30
> > powerdevil-5.13.90-1.fc30
> > 
> > and then I am now to kmenuedit and khotkeys and plasma-systemsettings.
> > 
> > I'll try and get the rest, but if you have a handy koji chain-build for
> > these deps let me know and you may be able to do it faster.
> 
> Looks like it was only kmenuedit and plasma-systemsettings.
> 
> kevin


___
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: DNF and Modularity

[Petr Šabata]

On Mon, Sep 24, 2018 at 10:02:39AM +0200, Miroslav Suchý wrote:
> Hi,
> I have to admit that I am a bit puzzled about DNF behavior with modularity.
> 
> I have installed repo files with modularity repos, but all of them are 
> disabled. I have no module enabled on my system
> (F29 BTW). To be precise:
>   output of `dnf module list`
>   https://paste.fedoraproject.org/paste/3QvX2xv4OgVVmgckTnEQcQ
> 
> And every time I run `dnf upgrade` I get this output:
> 
> Problem 1: cannot install the best update candidate for package 
> bubblewrap-0.3.0-2.fc29.x86_64
>   - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
>  Problem 2: cannot install the best update candidate for package 
> docker-distribution-2.6.2-7.git48294d9.fc28.x86_64
>   - package 
> docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 is disabled
>  Problem 3: cannot install the best update candidate for package 
> eog-3.28.3-1.fc29.x86_64
>   - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
>  Problem 4: cannot install the best update candidate for package 
> exempi-2.4.5-3.fc29.x86_64
>   - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
>  Problem 5: cannot install the best update candidate for package 
> flatpak-runtime-config-27-7.fc29.x86_64
>   - package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is 
> disabled
>  Problem 6: cannot install the best update candidate for package 
> gimp-2:2.10.6-2.fc29.x86_64
>   - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
>  Problem 7: cannot install the best update candidate for package 
> gimp-libs-2:2.10.6-2.fc29.x86_64
>   - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
>  Problem 8: cannot install the best update candidate for package 
> kubernetes-client-1.10.3-1.fc29.x86_64
>   - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is disabled
>  Problem 9: cannot install the best update candidate for package 
> libnghttp2-1.33.0-1.fc29.x86_64
>   - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
>  Problem 10: cannot install the best update candidate for package 
> libpeas-1.22.0-9.fc29.x86_64
>   - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
>  Problem 11: cannot install the best update candidate for package 
> libpeas-gtk-1.22.0-9.fc29.x86_64
>   - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
>  Problem 12: cannot install the best update candidate for package 
> libpeas-loader-python3-1.22.0-9.fc29.x86_64
>   - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is 
> disabled
>  Problem 13: cannot install the best update candidate for package 
> libuv-1:1.22.0-2.fc29.x86_64
>   - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled
>  Problem 14: cannot install the best update candidate for package 
> nghttp2-1.33.0-1.fc29.x86_64
>   - package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
>  Problem 15: cannot install the best update candidate for package 
> nodejs-1:10.11.0-1.fc29.x86_64
>   - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled
>  Problem 16: cannot install the best update candidate for package 
> npm-1:6.4.1-1.10.11.0.1.fc29.x86_64
>   - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is disabled
>  Problem 17: cannot install the best update candidate for package 
> perl-DB_File-1.842-1.fc29.x86_64
>   - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
>  Problem 18: cannot install the best update candidate for package 
> perl-HTTP-Tiny-0.076-1.fc29.noarch
>   - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
>  Problem 19: cannot install the best update candidate for package 
> perl-Thread-Queue-3.13-1.fc29.noarch
>   - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
> 
> It does not matter if I pass `--best` option or not.
> Why I - as a user - see this warnings/errors?
> 
> Is this an error or a feature?

Definitely an error.

Could be another case of
https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it
should have been fixed last week.  Is your repo current?
Could you check for the presence of modular repodata (the
*modules.yaml.gz) file.

P

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


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 Guid

Re: Semi-serious proposal: drop all optional entries from comps

[Zbigniew Jędrzejewski-Szmek]

On Sun, Sep 23, 2018 at 10:41:31AM +0200, Nicolas Mailhot wrote:
> Le samedi 22 septembre 2018 à 11:38 -0700, Adam Williamson a écrit :
> > 
> > But at the same time I think Matt's right that comps -at least as it's
> > currently set up - is kind of a really *bad* way of doing this, and
> > that seems fairly well demonstrated by the problem I'm trying to solve
> > - that comps has tons of broken entries in it. Just from looking
> > through the file as I do this, I really suspect that no-one is
> > maintaining quite a lot of the groups and the packages in them may
> > well just not make much sense any more.
> 
> That's a QA problem
>
> But really, the problem is not the comps format, it's that any kind of
> classification activity is both tedious and optional (if you know how to
> classify a package you do not need the classification in the first
> place), rots fast in presence of high package churn, and can only work
> long term with lots of janitorial involvement (both human and
> automated).

That was my first thought too.

On Fri, Sep 21, 2018 at 06:14:51PM -0700, Adam Williamson wrote:
> I am currently working on finding and removing all comps entries that
> point to packages which don't exist any more.
>
> While doing this extremely tedious task [...]

I would love to see some more info before any decisions are made.
I *thought* I more-or-less understand the comps process, I remember
doing some minor changes in the past, but things seem to have changed.

How are you doing those checks? Is it 
https://pagure.io/fedora-comps/pull-request/328?

It should be possible to turn those checks into CI hooks.
There was some jenkins jobs being run on PRs in
pagure.io/fedora-comps, but it seems to have atrophied and
doesn't appear on new PRs. Do we have any automated checks for comps now?

Instead of designing a whole new system that needs to be
a) designed, b) agreed, c) documented, d) implemented, e) integrated
with all the other tools, and f) referenced in all the docs where
the old system is now referenced,
why not first fix the CI to do the checks? Pruning nonexistent packages
really sounds like something that can automatized.

Another question: people keep mentioning unexpected breakage from
changes by random contributors. But https://pagure.io/fedora-comps/
seems *very* tightly controlled with write access by only @releng and
adamw. So is this still actually a problem?

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

DNF and Modularity

[Miroslav Suchý]

Hi,
I have to admit that I am a bit puzzled about DNF behavior with modularity.

I have installed repo files with modularity repos, but all of them are 
disabled. I have no module enabled on my system
(F29 BTW). To be precise:
  output of `dnf module list`
  https://paste.fedoraproject.org/paste/3QvX2xv4OgVVmgckTnEQcQ

And every time I run `dnf upgrade` I get this output:

Problem 1: cannot install the best update candidate for package 
bubblewrap-0.3.0-2.fc29.x86_64
  - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
 Problem 2: cannot install the best update candidate for package 
docker-distribution-2.6.2-7.git48294d9.fc28.x86_64
  - package docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 
is disabled
 Problem 3: cannot install the best update candidate for package 
eog-3.28.3-1.fc29.x86_64
  - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
 Problem 4: cannot install the best update candidate for package 
exempi-2.4.5-3.fc29.x86_64
  - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
 Problem 5: cannot install the best update candidate for package 
flatpak-runtime-config-27-7.fc29.x86_64
  - package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is disabled
 Problem 6: cannot install the best update candidate for package 
gimp-2:2.10.6-2.fc29.x86_64
  - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
 Problem 7: cannot install the best update candidate for package 
gimp-libs-2:2.10.6-2.fc29.x86_64
  - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
 Problem 8: cannot install the best update candidate for package 
kubernetes-client-1.10.3-1.fc29.x86_64
  - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is disabled
 Problem 9: cannot install the best update candidate for package 
libnghttp2-1.33.0-1.fc29.x86_64
  - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 10: cannot install the best update candidate for package 
libpeas-1.22.0-9.fc29.x86_64
  - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 11: cannot install the best update candidate for package 
libpeas-gtk-1.22.0-9.fc29.x86_64
  - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
 Problem 12: cannot install the best update candidate for package 
libpeas-loader-python3-1.22.0-9.fc29.x86_64
  - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is 
disabled
 Problem 13: cannot install the best update candidate for package 
libuv-1:1.22.0-2.fc29.x86_64
  - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 14: cannot install the best update candidate for package 
nghttp2-1.33.0-1.fc29.x86_64
  - package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
 Problem 15: cannot install the best update candidate for package 
nodejs-1:10.11.0-1.fc29.x86_64
  - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled
 Problem 16: cannot install the best update candidate for package 
npm-1:6.4.1-1.10.11.0.1.fc29.x86_64
  - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is disabled
 Problem 17: cannot install the best update candidate for package 
perl-DB_File-1.842-1.fc29.x86_64
  - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
 Problem 18: cannot install the best update candidate for package 
perl-HTTP-Tiny-0.076-1.fc29.noarch
  - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
 Problem 19: cannot install the best update candidate for package 
perl-Thread-Queue-3.13-1.fc29.noarch
  - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled

It does not matter if I pass `--best` option or not.
Why I - as a user - see this warnings/errors?

Is this an error or a feature?

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

Fedora 29 compose report: 20180923.n.0 changes

[Fedora Branched Report]

OLD: Fedora-29-20180922.n.0
NEW: Fedora-29-20180923.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  0
Dropped packages:0
Upgraded packages:   34
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   2.75 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   1.03 GiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-29-20180922.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-29-20180922.n.0.s390x.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  aom-1.0.0-4.fc29
Old package:  aom-1.0.0-2.fc29
Summary:  Royalty-free next-generation video format
RPMs: aom aom-extra-tools libaom libaom-devel
Added RPMs:   aom-extra-tools libaom libaom-devel
Dropped RPMs: aom-devel
Size: 9.70 MiB
Size change:  137.58 KiB
Changelog:
  * Tue Sep 11 2018 Robert-Andr?? Mauchin  - 1.0.0-3
  - Update the archive in order to detect the correct version from the changelog

  * Thu Sep 13 2018 Robert-Andr?? Mauchin  - 1.0.0-4
  - Split the package into libs/tools


Package:  clang-7.0.0-0.14.rc3.fc29
Old package:  clang-7.0.0-0.2.rc1.fc29
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs clang-tools-extra 
git-clang-format llvm-test-suite python2-clang
Added RPMs:   llvm-test-suite
Size: 1.10 GiB
Size change:  1.01 GiB
Changelog:
  * Fri Aug 17 2018 Tom Stellard  - 7.0.0-0.3.rc1
  - Recommend the same version of compiler-rt

  * Fri Aug 17 2018 Tom Stellard  - 7.0.0-0.4.rc1
  - Move llvm-test-suite into a sub-package

  * Tue Aug 28 2018 Tom Stellard  - 7.0.0-0.5.rc1
  - Enable unit tests

  * Tue Aug 28 2018 Tom Stellard  - 7.0.0-0.6.rc2
  - 7.0.0-rc2 Release

  * Sat Sep 01 2018 Tom Stellard  - 7.0.0-0.7.rc2
  - Add Fedora specific version string

  * Thu Sep 06 2018 Tom Stellard  - 7.0.0-0.8.rc2
  - Drop all uses of python2 from lit tests

  * Fri Sep 07 2018 Tom Stellard  - 7.0.0-0.9.rc2
  - Drop python2 dependency from clang package

  * Mon Sep 10 2018 Tom Stellard  - 7.0.0-0.10.rc2
  - Drop siod from llvm-test-suite

  * Wed Sep 12 2018 Tom Stellard  - 7.0.0-0.11.rc3
  - 7.0.0-rc3 Release

  * Thu Sep 13 2018 Tom Stellard  - 7.0.0-0.12.rc3
  - Fix clang++-7 symlink

  * Thu Sep 13 2018 Tom Stellard  - 7.0.0-0.13.rc3
  - Rebuild with new llvm-devel that disables rpath on install

  * Thu Sep 13 2018 Tom Stellard  - 7.0.0-0.14.rc3
  - Move unversioned shared objects to devel package


Package:  cockpit-178-1.fc29
Old package:  cockpit-175-1.fc29
Summary:  A user interface for Linux servers
RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc 
cockpit-docker cockpit-kdump cockpit-kubernetes cockpit-machines 
cockpit-machines-ovirt cockpit-networkmanager cockpit-packagekit cockpit-pcp 
cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests 
cockpit-ws
Size: 35.81 MiB
Size change:  -973.96 KiB
Changelog:
  * Wed Sep 05 2018 Martin Pitt  - 177-1
  - Storage: Support LUKS v2
  - Support centrally-managed SSH known hosts
  - Drop support for Internet Explorer

  * Wed Sep 19 2018 Marius Vollmer  - 178-1
  - Dropped support for KubeVirt


Package:  compiler-rt-7.0.0-0.4.rc3.fc29
Old package:  compiler-rt-7.0.0-0.1.rc1.fc29
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 13.06 MiB
Size change:  -4.29 KiB
Changelog:
  * Thu Sep 06 2018 Tom Stellard  - 7.0.0-0.2.rc1
  - Drop BuildRequires: python2

  * Fri Sep 07 2018 Tom Stellard  - 7.0.0-0.3.rc1
  - Use python3 for build scripts

  * Wed Sep 12 2018 Tom Stellard  - 7.0.0-0.4.rc3
  - 7.0.0-rc3 Release


Package:  ddgr-1.5-1.fc29
Old package:  ddgr-1.4-3.fc29
Summary:  DuckDuckGo from the terminal
RPMs: ddgr
Size: 46.80 KiB
Size change:  436 B
Changelog:
  * Tue Sep 11 2018 Robert-Andr?? Mauchin  - 1.5-1
  - Release 1.5


Package:  firefox-62.0-3.fc29
Old package:  firefox-62.0-2.fc29
Summary:  Mozilla Firefox Web browser
RPMs: firefox firefox-wayland
Size: 500.72 MiB
Size change:  -1.63 KiB
Changelog:
  * Mon Sep 17 2018 Martin Stransky  - 62.0-3
  - Added spellchecker.dictionary_path pref pointer to /usr/share/myspell.
Thanks to Peter Oliver (rhbz#1627837)


Package:  ghostscript-9.25-1.fc29
Old package:  ghostscript-9.24-3.fc29
Summary:  Interpreter for PostScript language & PDF
RPMs: ghostscript ghostscript-core ghostscript-doc ghostscript-gtk 
ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing 
ghostscript-x11 libgs libgs-devel
Size: 21.88 MiB
Size change:  22.37 KiB
Changelog:
  * Mon Sep 17 2018 David Kaspar [Dee'Kej]  - 9.25-1
  - rebase to latest u

Re: Release-monitoring github issues?

[Michal Konečný]

On 23.9.2018 23:26, Jerry James wrote:

On Sat, Sep 22, 2018 at 3:42 PM Kevin Fenzi  wrote:

Yep. It's fixed but not yet rolled out to production, we ran into some
other issues we wanted to fix up before rolling it out.

I hope to move this service into our production openshift instance and
update it next week. :)

Sorry for the trouble...

Thanks for fixing it.  Do these other issues involve pages with custom
rules?  I've got a few packages where the last log message says that
the version was retrieved successfully, but it isn't showing the most
recent version.  For example, ntl is one such project.
There was an issue with cron job that is checking for new versions. In 
the current released version, which is running in staging 
(https://stg.release-monitoring.org), this issue is fixed. When the new 
version will be deployed on production this issue should be gone.


mkonecny


Thanks,

___
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