date:20180913

Heads up: today's rawhide and F29 updates-testing break gnome-shell login

2018-09-13 Thread Kalev Lember


Hi all,

It turns out mozjs60 60.2.0 (in F29 updates-testing and rawhide)
silently broke ABI and that broke gjs that gnome-shell uses. I've
rebuilt gjs; if you've already updated and can't log in, then
gjs-1.54.0-3.fc29 and gjs-1.54.0-3.fc30 should help.

https://bodhi.fedoraproject.org/updates/FEDORA-2018-bc166c0e29 has the
rebuilt gjs.

Hope this helps someone,
Kalev
___
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

indent license corrected

2018-09-13 Thread Petr Pisar

While rebasing indent package to a fresh new 2.2.12 release (done
after 8 years), I corrected license declaration from "GPLv3+" to
"GPLv3+ and BSD and Verbatim".

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

Re: Am I allowed to package this?

2018-09-13 Thread Hans de Goede

Hi,

On 10-09-18 14:40, Abhiram Kuchibhotla wrote:

According to the LICENSE file in their git repo, the code in the repo seems to
be gplv2. Not sure if that proves anything. I'll do the licensecheck -r later
and update you guys.

On Mon 10 Sep, 2018, 6:08 PM Richard Shaw, mailto:hobbes1...@gmail.com>> wrote:

On Mon, Sep 10, 2018 at 7:27 AM Rex Dieter mailto:rdie...@math.unl.edu>> wrote:

Jan Rybar wrote:

> Hi Abhiram,
>
> you can make COPR. No one asks, no harm done, everyone's happy.

I don't think copr is appropriate either,
https://docs.pagure.org/copr.copr/user_documentation.html#faq

To me, makes it pretty clear that if it can't be in fedora, it can't be
in
copr either.

You need to go through the code (maybe use licensecheck -r to help) to see
if all the code is acceptable. If so I'll defer to Neal on the COPR
acceptability. Another alternative is until formal support is added to the
kernel you can look at packaging it in RPM Fusion. If it's truly FOSS but just
not acceptable because it's a kernel module it can go in the Free repository.
If it's using proprietary code (even if the project is GPL licensed) then as
long as it's redistributable, it can go in the Non-Free repository.

This looks like a standard realtek driver which realtek creates for Android
devices
or some such. The code is not pretty (I really wish realtek would start
contributing
proper drivers to the mainline kernel) but it usually is all GPL licensed,
except
for the firmware for the NIC. I don't see firmware in the git repo, so the code
may need to be adjusted to use the kernels firmware-load mechanism (I assume
it has the firmware embedded atm).

The firmware files themselves may be distributed under this license:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.rtlwifi_firmware.txt

Note I did not check the files in the git repo, I just took a quick peek
that it is a "standard" out of tree realtek driver.

Also IANAL and TINLA.

Regards,

Hans

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
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

Set firefox default home page

2018-09-13 Thread Danishka Navin

Hi,

I am working on a project that require a fedora spin with firefox which
point to specific web url as the default home page.
This will be applicable to all users and I could not find anything on skell
directory against mozilla.

I have manually altered (just for testing)  vim
/home/liveuser/.mozilla/firefox/ogkcrque.default/prefs.js and it worked.
user_pref("browser.startup.homepage", "")

But my requirement is to make this change system wide.

Regards,
-- 
Danishka Navin
http://danishkanavin.blogspot.com
http://twitter.com/danishkanavin
___
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: Changes in packages workflow vs. modular Fedora

2018-09-13 Thread Miro Hrončok


On 13.9.2018 22:44, Petr Šabata wrote:

On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:

Hi,

I was thinking about this for a while and I got the impression that this is
something I don't know the answer for. The question is a bit harder to
formulate simply, so let put it in examples:


I see no one's really responded to this yet (ack!), so let me try...


Thank You! I was starting to feel like nobody cares.


a) A need packaging guideline is about to be discussed. A member of FPC
wants to know how many packages would be affected so they run a quick grep
query over all the rawhide specfiles at [0].


Obviously this wouldn't be enough.  We would need to find all
modules shipped with Rawhide, then all the RPM stream branches
they build from, and grep those as well.  Perhaps we could
do something to generate archives that include all of this
automatically.


Please do, otherwise this would be tedious. There are archives with 
rawhide specs.



b) A CVE is found in a web framework, so bugz are filled for the "framewrok"
package to be fixed in Fedora 27, because newer Fedoras have newer version
of the framework where the CVE is not applicable.


Also valid.  Rather than just relying on the non-modular package
upgrade path, all currently supported modules and their RPMs
would need to be checked.


Is the Red Hat security response team aware of that? Do they file bugs 
for modules?



c) A new version of interpreted language lands in rawhide. All packages
depending on the interpeter need mass rebuild in a side tag.


This would be a new stream of the interpreter module.


No interpreter module here. An interpreter that lives in non-modular 
Fedora, but various modules possibly use it. I have no idea what modules 
use it (if any) and I have no idea how to easily find out.


I know there is at least one module that uses non-modular Python 2. At 
least we won't rebase that Python to a newer version.



d) A packager decides to retire a library and they check nothing in Fedora
requires it.


Similar to a) and b).  They need to check the currently supported
modules as well.


How? We are mass removing python2 packages from rawhide that nothing in 
rawhide depend on. Our automation has no clue about modules and if there 
are modules that use python2-... packages from nonmodular Fedora, we 
need to know.



I wonder how are such situations meant to be handled with modules?
Do we build modules for rawhide? If so, should Fedora changes (such as, but
not limited to, "the Changes") somehow handle all the modules, or is it the
modular maintainer responsibility to make sure their module works on the
next Fedora version?


We're aware there are many gaps here.  I consider identifying &
resolving them a priority for the Modularity WG at the moment,
so thank you for contributing.


Thanks for looking into this.


a) I was planning to propose a more strict "No more automagic Python
bytecompilation" [1] change for Fedora 30 where we would query all packages
that depend on the old behavior and mass add "%global
_python_bytecompile_extra 1" to all of them, so we could switch the default
to be 0. Normally, we would do it in Rawhide only. But how do I handle
modules? How do I find out what modular packages rely on the old behavior?


Modules typically build the same content in all contexts
(buildroots).  If that's a problem for this particular change
of yours, I think the proper way would be adding %{fedora}
conditionals around that macro definition.


No, I don't want to only add this thing if %fedora. Quite the opposite, 
I need to gather a list of packages that rely on the old behavior, so I 
can hotfix/workaround them with that line. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1626685#c2 for what I did in 
the non-modular world to better understand what I mean.



b) A CVE was filled for Django [2]. How does the security team responsible
for tracking CVEs figure out we have Django 1.6 in modular Fedora? How is a
bugzilla filled against a modular package anyway?


They should file a report against Fedora Modules rather than
Fedora, although in practice I suspect people will report bugs
as usual.  Then it's about the non-modular package maintainer
re-assigning the bug properly, if necessary.


I've added a note to that bug about the modular build. Got no response IIRC.


c) When we recently mass rebuilt Python 3 packages for Python 3.7, should we
go and seek for modules that use Python 3 (how do I do that?) and rebuild
the packages in the modules (or even the modules?)?


Python is part of the "platform" module, so you really need
to check all the RPM stream branches used by the currently
supported modules.


The change is done now. We've checked no modules. What happens now?

How do I see what modules depend on (non modular) Python 3?


You do not rebuild these packages, you rebuild the modules.
If there's no change to the SPEC files, you'll have to instruct
MBS to do a full rebuild (fedpkg module-build

Re: Intel's Clear Linux optimizations

2018-09-13 Thread Victor Rodriguez

On Thu, Sep 6, 2018 at 12:15 AM, Manas Mangaonkar
 wrote:
>> Fedora is already in glibc 2.28 it is possible to do the > > same approach
>
> TBH I don't really know how that'd be done with the current package,would
> love to learn.
>

Please take a look at my slides :
https://schd.ws/hosted_files/ossna2017/6b/Boosting_GLIBC_GCC.pdf
from last year OSSNA

There is a description of the main idea and how does it work here :

https://www.phoronix.com/scan.php?page=news_item=Clear-Linux-NA2017-Opts

feel free to ping me for any further questons

regards

> On Tue, Aug 28, 2018, 3:09 AM Victor Rodriguez  wrote:
>>
>> On Sun, Aug 26, 2018 at 12:40 PM, Manas Mangaonkar
>>  wrote:
>> > Thank you for the blog link victor , interesting read it is.
>> >
>>
>> Fedora is already in glibc 2.28 it is possible to do the same approach
>>
>> > - Manas
>> >
>> > On Sun, 26 Aug 2018, 23:03 Victor Rodriguez,  wrote:
>> >>
>> >> On Tue, May 15, 2018 at 10:38 PM, Hayden Barnes 
>> >> wrote:
>> >> > Would it be possible to mirror the Clear Linux kernel in copr or a
>> >> > third-party dnf repo?
>> >> >
>> >> > That would allow Fedora to keep it's general purpose kernel but then
>> >> > allow performance hounds to install the Clear Linux kernel.
>> >> >
>> >> > There is something similar already for people who want to use
>> >> > upstream
>> >> > vanilla kernel.
>> >> >
>> >> > The Clear Linux performance metrics posted by Phoronix are
>> >> > compelling.
>> >> > ___
>> >> > devel mailing list -- devel@lists.fedoraproject.org
>> >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >>
>> >> Maybe a great blog to read about Clear Linux could be this:
>> >>
>> >>
>> >>
>> >> https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
>> >>
>> >> Regards
>> >>
>> >> Victor
>> >> ___
>> >> devel mailing list -- devel@lists.fedoraproject.org
>> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> >> List Archives:
>> >>
>> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> >
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> >
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> >
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> 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: Changes in packages workflow vs. modular Fedora

2018-09-13 Thread Petr Šabata

On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:
> Hi,
> 
> I was thinking about this for a while and I got the impression that this is
> something I don't know the answer for. The question is a bit harder to
> formulate simply, so let put it in examples:

I see no one's really responded to this yet (ack!), so let me try...

> a) A need packaging guideline is about to be discussed. A member of FPC
> wants to know how many packages would be affected so they run a quick grep
> query over all the rawhide specfiles at [0].

Obviously this wouldn't be enough.  We would need to find all
modules shipped with Rawhide, then all the RPM stream branches
they build from, and grep those as well.  Perhaps we could
do something to generate archives that include all of this
automatically.

Currently supported modules are tagged in the f*-modular* tags.

> b) A CVE is found in a web framework, so bugz are filled for the "framewrok"
> package to be fixed in Fedora 27, because newer Fedoras have newer version
> of the framework where the CVE is not applicable.

Also valid.  Rather than just relying on the non-modular package
upgrade path, all currently supported modules and their RPMs
would need to be checked.

> c) A new version of interpreted language lands in rawhide. All packages
> depending on the interpeter need mass rebuild in a side tag.

This would be a new stream of the interpreter module.
Supposedly those packages would be also modularized?  In that
case everything that builds against the interpreter module with
stream expansion would need to be "rebuilt".

This also affects platform branching and needs to be solved
before f30.  It should be easy to automate this.  And there's
no point in limiting that to platform branching.

> d) A packager decides to retire a library and they check nothing in Fedora
> requires it.

Similar to a) and b).  They need to check the currently supported
modules as well.

> I wonder how are such situations meant to be handled with modules?
> Do we build modules for rawhide? If so, should Fedora changes (such as, but
> not limited to, "the Changes") somehow handle all the modules, or is it the
> modular maintainer responsibility to make sure their module works on the
> next Fedora version?

We're aware there are many gaps here.  I consider identifying &
resolving them a priority for the Modularity WG at the moment,
so thank you for contributing.

> For the above examples, here are some more specific situations with more
> specific questions:
> 
> 
> a) I was planning to propose a more strict "No more automagic Python
> bytecompilation" [1] change for Fedora 30 where we would query all packages
> that depend on the old behavior and mass add "%global
> _python_bytecompile_extra 1" to all of them, so we could switch the default
> to be 0. Normally, we would do it in Rawhide only. But how do I handle
> modules? How do I find out what modular packages rely on the old behavior?

Modules typically build the same content in all contexts
(buildroots).  If that's a problem for this particular change
of yours, I think the proper way would be adding %{fedora}
conditionals around that macro definition.

> b) A CVE was filled for Django [2]. How does the security team responsible
> for tracking CVEs figure out we have Django 1.6 in modular Fedora? How is a
> bugzilla filled against a modular package anyway?

They should file a report against Fedora Modules rather than
Fedora, although in practice I suspect people will report bugs
as usual.  Then it's about the non-modular package maintainer
re-assigning the bug properly, if necessary.

> c) When we recently mass rebuilt Python 3 packages for Python 3.7, should we
> go and seek for modules that use Python 3 (how do I do that?) and rebuild
> the packages in the modules (or even the modules?)?

Python is part of the "platform" module, so you really need
to check all the RPM stream branches used by the currently
supported modules.

You do not rebuild these packages, you rebuild the modules.
If there's no change to the SPEC files, you'll have to instruct
MBS to do a full rebuild (fedpkg module-build --optional
rebuild_strategy=all).  We also plan to add more options to
limit these rebuilds to specific platforms so you wouldn't be
rebuilding for all three or more releases if not required.

> d) (this example is not real (yet)) We decide to retire (remove)
> python2-sphinx because upstream Sphinx no longer supports Python 2. We make
> sure that nothing in Fedora requires or buildrequires it, as all Fedora's
> Python packages use python3-sphinx or no Sphinx at all. However there is a
> Django 1.6 module where python-django uses python2-sphinx to build the docs,
> while python2-sphinx is not part of the module itself. How do we find out
> about this and is it our reprehensibility to keep it in rawhide or add it to
> the module?

I wouldn't say it's your responsibility to resolve the issue
but it is your responsibility to file a bug for the

Re: Set firefox default home page

2018-09-13 Thread David Sommerseth

On 13/09/18 22:16, Danishka Navin wrote:
> Hi,
> 
> I am working on a project that require a fedora spin with firefox which point
> to specific web url as the default home page.
> This will be applicable to all users and I could not find anything on skell
> directory against mozilla.
> 
> I have manually altered (just for testing)  vim
> /home/liveuser/.mozilla/firefox/ogkcrque.default/prefs.js and it worked.
> user_pref("browser.startup.homepage", "")
> 
> But my requirement is to make this change system wide.

I don't recall the details, but I believe this is what /etc/firefox/pref is for.

There is also /usr/lib64/firefox/defaults/preferences, but this is owned by
the firefox package and can be overwritten.

At least a few places to look further.


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

Fedora 29 Beta status is No-Go

2018-09-13 Thread Ben Cotton

Release status of the Fedora 29 Beta is NO-GO.

Due to in-progress RC2 for the F29 Beta release and presence of
blocker bugs, the decision is “No Go”. The Beta release slips for one
week to “Target #1” date (September 25th)[1]. We are not going to slip
the Final GA yet.

For more information please check the minutes from the F29 Beta
Go/No-Go meeting [2].

The next Go/No-Go meeting will be held Thursday, 2018-09-20 at 1700
UTC in #fedora-meeting-1.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-13/f29-beta-go_no_go-meeting.2018-09-13-17.00.html

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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
___
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

Retiring procedure for nini and smuxi packages

2018-09-13 Thread Antonio Trande

Hi all.

I'm going to retire the packages 'nini' and 'smuxi' on rawhide within
24h since now. Both upstream project look like over.

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

Fedora Rawhide-20180913.n.0 compose check report

2018-09-13 Thread Fedora compose checker

No missing expected images.

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

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

ID: 279381  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/279381
ID: 279384  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/279384
ID: 279387  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/279387
ID: 279441  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/279441

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

ID: 279369  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/279369
ID: 279370  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/279370
ID: 279371  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/279371
ID: 279385  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/279385
ID: 279396  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/279396
ID: 279402  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/279402
ID: 279420  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/279420
ID: 279421  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/279421
ID: 279422  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/279422
ID: 279423  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/279423
ID: 279463  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/279463
ID: 279464  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/279464
ID: 279474  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/279474
ID: 279484  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/279484
ID: 279485  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/279485

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

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

ID: 279364  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/279364
ID: 279365  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/279365
ID: 279443  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/279443

Passed openQA tests: 108/132 (x86_64), 18/24 (i386)

New passes (same test did not pass in Rawhide-20180912.n.0):

ID: 279399  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/279399
ID: 279428  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/279428
ID: 279429  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/279429
ID: 279430  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/279430
ID: 279449  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/279449
ID: 279450  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/279450
ID: 279451  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/279451

Skipped openQA tests: 10 of 158

Installed system changes in test x86_64 Server-boot-iso install_default: 
2 packages(s) removed since previous compose: python3-librepo, 
python3-smartcols
System load changed from 1.16 to 1.51
Previous test data: https://openqa.fedoraproject.org/tests/278753#downloads
Current test data: https://openqa.fedoraproject.org/tests/279338#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
2 packages(s) removed since previous compose: python3-librepo, 
python3-smartcols
Previous test data: https://openqa.fedoraproject.org/tests/278754#downloads
Current test data: https://openqa.fedoraproject.org/tests/279339#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
Used mem changed from 169 MiB to 198 MiB
Previous test data: https://openqa.fedoraproject.org/tests/278756#downloads
Current test data: https://openqa.fedoraproject.org/tests/279341#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi:

Fedora rawhide compose report: 20180913.n.0 changes

2018-09-13 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180912.n.0
NEW: Fedora-Rawhide-20180913.n.0

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

Size of added packages:  371.45 KiB
Size of dropped packages:0 B
Size of upgraded packages:   2.93 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-outcome-1.0.0-1.fc30
Summary: Capture the outcome of Python function calls
RPMs:python3-outcome
Size:21.05 KiB

Package: roca-detect-1.2.12-4.fc30
Summary: Key fingerprinting tools for CVE-2017-15361
RPMs:roca-detect
Size:317.63 KiB

Package: rust-quickcheck0.6-0.6.2-2.fc30
Summary: Automatic property based testing with shrinking
RPMs:rust-quickcheck0.6-devel
Size:32.77 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  annobin-8.33-1.fc30
Old package:  annobin-8.32-1.fc30
Summary:  Binary annotation plugin for GCC
RPMs: annobin
Size: 1.00 MiB
Size change:  21.56 KiB
Changelog:
  * Wed Sep 12 2018 Nick Clifton  - 8.33-1
  - Add timing tool to report on speed of the checks.
  - Add check for conflicting use of the -fshort-enum option.
  - Add check of the GNU Property notes.
  - Skip check for -O2 if compiled with -Og.  (#1624162)


Package:  attr-2.4.48-4.fc30
Old package:  attr-2.4.48-3.fc29
Summary:  Utilities for managing filesystem extended attributes
RPMs: attr libattr libattr-devel
Size: 589.79 KiB
Size change:  -20.74 KiB
Changelog:
  * Fri Aug 31 2018 Filipe Brandenburger  2.4.48-4
  - Switch compatibility functions back to syscall() to prevent issue in
interaction with fakechroot (https://github.com/dex4er/fakechroot/issues/57)


Package:  bakefile-0.2.11-3.fc30
Old package:  bakefile-0.2.11-2.fc29
Summary:  A cross-platform, cross-compiler native makefiles generator
RPMs: bakefile
Size: 1.31 MiB
Size change:  -7.87 KiB
Changelog:
  * Thu Sep 13 2018 Scott Talbert  - 0.2.11-3
  - Indicate that we don't want to bytecompile the extra python files


Package:  clang-7.0.0-0.11.rc3.fc30
Old package:  clang-7.0.0-0.10.rc2.fc30
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
Size: 1.10 GiB
Size change:  6.01 KiB
Changelog:
  * Wed Sep 12 2018 Tom Stellard  - 7.0.0-0.11.rc3
  - 7.0.0-rc3 Release


Package:  ecj-1:4.9-1.fc30
Old package:  ecj-1:4.7.3a-2.fc29
Summary:  Eclipse Compiler for Java
RPMs: ecj
Size: 2.58 MiB
Size change:  33.09 KiB
Changelog:
  * Wed Sep 12 2018 Mat Booth  - 1:4.9-1
  - Update to latest release
  - Amend license tag


Package:  eclipse-cdt-2:9.5.3-1.fc30
Old package:  eclipse-cdt-1:9.6.0-0.1.fc30
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: 417.99 MiB
Size change:  -40.96 KiB
Changelog:
  * Wed Sep 12 2018 Mat Booth  - 2:9.5.3-1
  - Update to latest release and correct version number


Package:  eclipse-dtp-1.14.102-1.fc30
Old package:  eclipse-dtp-1.14.101-1.fc30
Summary:  Eclipse Data Tools Platform
RPMs: eclipse-dtp
Size: 12.80 MiB
Size change:  416 B
Changelog:
  * Wed Sep 12 2018 Mat Booth  - 1.14.102-1
  - Update to latest release
  - Amend license tag


Package:  eclipse-linuxtools-7.1.0-0.3.fc30
Old package:  eclipse-linuxtools-7.1.0-0.2.fc30
Summary:  Linux specific Eclipse plugins
RPMs: eclipse-linuxtools eclipse-linuxtools-changelog 
eclipse-linuxtools-docker eclipse-linuxtools-gcov eclipse-linuxtools-gprof 
eclipse-linuxtools-javadocs eclipse-linuxtools-libhover 
eclipse-linuxtools-manpage eclipse-linuxtools-oprofile eclipse-linuxtools-perf 
eclipse-linuxtools-rpm-editor eclipse-linuxtools-systemtap 
eclipse-linuxtools-tests eclipse-linuxtools-vagrant eclipse-linuxtools-valgrind
Size: 22.93 MiB
Size change:  669.26 KiB
Changelog:
  * Wed Sep 12 2018 Mat Booth  - 7.1.0-0.3
  - Update to latest snapshot


Package:  eclipse-m2e-core-1.9.1-2.fc30
Old package:  eclipse-m2e-core-1.9.1-0.1.fc30
Summary:  Maven integration for Eclipse
RPMs: eclipse-m2e-core eclipse-m2e-core-javadoc eclipse-m2e-core-tests
Size: 4.16 MiB
Size change:  5.40 KiB
Changelog:
  * Wed Sep 12 2018 Mat Booth  - 1.9.1-1
  - Update to latest release

  * Wed Sep 12 2018 Mat Booth  - 1.9.1-2
  - Add BR/R on maven-wagon-http


Package:  eclipse-photran-9.2.0-1.fc30
Old package:  eclipse-photran-9.1.4-2.fc29
Summary:  Fortran Development Tools (Photran) for Eclipse
RPMs: eclipse-photran

Re: DNF: "There are following alternatives to this package"

2018-09-13 Thread Mathieu Bridon

On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
> We'd like to propose a new functionality for dnf: When a user tries
> to install a package XYZ and dnf doesn't find it, dnf would recommend
> them alternative packages. These offered packages would advertise
> that they are an alternative for XYZ using a specially formatted
> Provides tag.
> 
> For example, packages `python2-requests` and `python3-requests`
> would both have the following tag:
> 
>  Provides: alternative-for(python-requests) = %{version}-
> %{release}
> 
> (Possibly via the already existing and widespread %python_provide
> macro in the Python case.)
> 
> And when the user would try to install `python-requests`, dnf would
> look for packages with the relevant Provides tag and display them:
> 
>  # dnf install python-requests
>* There are following alternatives to this package: 
> python2-requests python3-requests
>  No match for argument: python-requests
>  Error: Unable to find a match
> 
> This would be very similar to an already existing functionality that 
> searches for lowercase package names:
> 
>  # dnf install python3-REQUESTS
>* Maybe you meant: python3-requests
>  No match for argument: python3-REQUESTS
>  Error: Unable to find a match
> 
> (That functionality is broken in some versions—RHBZ#1628514—so you
> might not see this result at the moment.)
> 
> What are your thoughts?

It's neat, but it doesn't help catch typos, which seems like the most
probably case where I'd want such a feature.

How about instead of a scheme based on provides, just quickly check if
a package has a "similar" name?

Basically extend the existing check for lowercase you mention.

  $ git stats
  git: 'stats' is not a git command. See 'git --help'.
  
  The most similar command is
  status


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

Re: [Fedora-packaging] DNF: "There are following alternatives to this package"

2018-09-13 Thread Petr Šabata

On Thu, Sep 13, 2018 at 06:17:39PM +0200, Tomas Orsava wrote:
> Hi!
> We'd like to propose a new functionality for dnf: When a user tries to
> install a package XYZ and dnf doesn't find it, dnf would recommend them
> alternative packages. These offered packages would advertise that they are
> an alternative for XYZ using a specially formatted Provides tag.
> 
> For example, packages `python2-requests` and `python3-requests` would both
> have the following tag:
> 
>     Provides: alternative-for(python-requests) = %{version}-%{release}

You could probably achieve that behavior with normal provides
we have today and a DNF plugin.

Just guessing.  And people who care for such a feature could just
get the plugin, you know...

P


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

Re: Am I allowed to package this?

2018-09-13 Thread Simo Sorce

On Thu, 2018-09-13 at 16:07 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10-09-18 14:40, Abhiram Kuchibhotla wrote:
> > According to the LICENSE file in their git repo, the code in the repo seems 
> > to be gplv2. Not sure if that proves anything. I'll do the licensecheck -r 
> > later and update you guys.
> > 
> > On Mon 10 Sep, 2018, 6:08 PM Richard Shaw,  > > wrote:
> > 
> > On Mon, Sep 10, 2018 at 7:27 AM Rex Dieter  > > wrote:
> > 
> > Jan Rybar wrote:
> > 
> >  > Hi Abhiram,
> >  >
> >  > you can make COPR. No one asks, no harm done, everyone's happy.
> > 
> > I don't think copr is appropriate either,
> > https://docs.pagure.org/copr.copr/user_documentation.html#faq
> > 
> > To me, makes it pretty clear that if it can't be in fedora, it 
> > can't be in
> > copr either.
> > 
> > 
> > You need to go through the code (maybe use licensecheck -r to help) to 
> > see if all the code is acceptable. If so I'll defer to Neal on the COPR 
> > acceptability. Another alternative is until formal support is added to the 
> > kernel you can look at packaging it in RPM Fusion. If it's truly FOSS but 
> > just not acceptable because it's a kernel module it can go in the Free 
> > repository. If it's using proprietary code (even if the project is GPL 
> > licensed) then as long as it's redistributable, it can go in the Non-Free 
> > repository.
> 
> 
> This looks like a standard realtek driver which realtek creates for Android 
> devices
> or some such. The code is not pretty (I really wish realtek would start 
> contributing
> proper drivers to the mainline kernel) but it usually is all GPL licensed, 
> except
> for the firmware for the NIC. I don't see firmware in the git repo, so the 
> code
> may need to be adjusted to use the kernels firmware-load mechanism (I assume
> it has the firmware embedded atm).
> 
> The firmware files themselves may be distributed under this license:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.rtlwifi_firmware.txt
> 
> Note I did not check the files in the git repo, I just took a quick peek
> that it is a "standard" out of tree realtek driver.
> 
> Also IANAL and TINLA.

I also have to use this driver for a USB dongle that works very well
... when I remember to check dkms didn't fail to build on kernel
upgrade ...

There is no firmware needed apparently, but my dongle doesn't work with
driver 5.2 which is the latest, so maybe a firmware is needed but the
driver itself doesn't load it ?

It would be really nice to have this driver in the kernel though as a
huge amount of cheap dongles use this chipset family, what would be the
process to get it in ?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: DNF: "There are following alternatives to this package"

2018-09-13 Thread Gerald B. Cox

On Thu, Sep 13, 2018 at 9:17 AM, Tomas Orsava  wrote:

> Hi!
> We'd like to propose a new functionality for dnf: When a user tries to
> install a package XYZ and dnf doesn't find it, dnf would recommend them
> alternative packages. These offered packages would advertise that they are
> an alternative for XYZ using a specially formatted Provides tag.
>
>
I'm all for improving and expanding the functionality of DNF - but
shouldn't we finish outstanding requests before
proposing new ones:

This one at the time was considered somewhat important and now it is almost
2 years old.

Expand Upgrade function to optionally perform "offline" upgrades
https://bugzilla.redhat.com/show_bug.cgi?id=1382063
___
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: "There are following alternatives to this package"

2018-09-13 Thread Tomas Orsava


Hi!
We'd like to propose a new functionality for dnf: When a user tries to 
install a package XYZ and dnf doesn't find it, dnf would recommend them 
alternative packages. These offered packages would advertise that they 
are an alternative for XYZ using a specially formatted Provides tag.


For example, packages `python2-requests` and `python3-requests` would 
both have the following tag:


    Provides: alternative-for(python-requests) = %{version}-%{release}

(Possibly via the already existing and widespread %python_provide macro 
in the Python case.)


And when the user would try to install `python-requests`, dnf would look 
for packages with the relevant Provides tag and display them:


    # dnf install python-requests
  * There are following alternatives to this package: 
python2-requests python3-requests

    No match for argument: python-requests
    Error: Unable to find a match

This would be very similar to an already existing functionality that 
searches for lowercase package names:


    # dnf install python3-REQUESTS
  * Maybe you meant: python3-requests
    No match for argument: python3-REQUESTS
    Error: Unable to find a match

(That functionality is broken in some versions—RHBZ#1628514—so you might 
not see this result at the moment.)


What are your thoughts?

One possible addition would be to include a parameter for weight in the 
Provides tag, so that python3-requests could be listed as the preferred 
option before python2-requests.


All the best,
Tomas Orsava
___
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: "There are following alternatives to this package"

2018-09-13 Thread Neal Gompa

On Thu, Sep 13, 2018 at 12:58 PM Tomas Orsava  wrote:
>
> On 09/13/2018 06:43 PM, Mathieu Bridon wrote:
> > On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
> >> We'd like to propose a new functionality for dnf: When a user tries
> >> to install a package XYZ and dnf doesn't find it, dnf would recommend
> >> them alternative packages. These offered packages would advertise
> >> that they are an alternative for XYZ using a specially formatted
> >> Provides tag.
> >>
> >> For example, packages `python2-requests` and `python3-requests`
> >> would both have the following tag:
> >>
> >>   Provides: alternative-for(python-requests) = %{version}-
> >> %{release}
> >>
> >> (Possibly via the already existing and widespread %python_provide
> >> macro in the Python case.)
> >>
> >> And when the user would try to install `python-requests`, dnf would
> >> look for packages with the relevant Provides tag and display them:
> >>
> >>   # dnf install python-requests
> >> * There are following alternatives to this package:
> >> python2-requests python3-requests
> >>   No match for argument: python-requests
> >>   Error: Unable to find a match
> >>
> >> This would be very similar to an already existing functionality that
> >> searches for lowercase package names:
> >>
> >>   # dnf install python3-REQUESTS
> >> * Maybe you meant: python3-requests
> >>   No match for argument: python3-REQUESTS
> >>   Error: Unable to find a match
> >>
> >> (That functionality is broken in some versions—RHBZ#1628514—so you
> >> might not see this result at the moment.)
> >>
> >> What are your thoughts?
> > It's neat, but it doesn't help catch typos, which seems like the most
> > probably case where I'd want such a feature.
> >
> > How about instead of a scheme based on provides, just quickly check if
> > a package has a "similar" name?
> >
> > Basically extend the existing check for lowercase you mention.
>
> Catching typos would be useful, and I'd certainly support that addition,
> but this doesn't really scratch the itch I'm trying to solve.
> We want to tell the user "these are exactly the alternatives available
> to you". Not guess, not rely on some typo resolution. We know what the
> alternatives are, here they are.
>
> I've talked with people working on dnf and this looks like an easy
> mechanism to add, and it will be more reliable for the use cases it covers.
>

I personally am not sure whether this is a good idea, but it
definitely should only be implemented as a plugin.

My feeling about this is that we should just specify the flag release
where we transition python-* to python3-* packages using %python_provide.

Anything else is more work for very little benefit.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: "There are following alternatives to this package"

2018-09-13 Thread Tomas Orsava


On 09/13/2018 06:43 PM, Mathieu Bridon wrote:

On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:

We'd like to propose a new functionality for dnf: When a user tries
to install a package XYZ and dnf doesn't find it, dnf would recommend
them alternative packages. These offered packages would advertise
that they are an alternative for XYZ using a specially formatted
Provides tag.

For example, packages `python2-requests` and `python3-requests`
would both have the following tag:

  Provides: alternative-for(python-requests) = %{version}-
%{release}

(Possibly via the already existing and widespread %python_provide
macro in the Python case.)

And when the user would try to install `python-requests`, dnf would
look for packages with the relevant Provides tag and display them:

  # dnf install python-requests
* There are following alternatives to this package:
python2-requests python3-requests
  No match for argument: python-requests
  Error: Unable to find a match

This would be very similar to an already existing functionality that
searches for lowercase package names:

  # dnf install python3-REQUESTS
* Maybe you meant: python3-requests
  No match for argument: python3-REQUESTS
  Error: Unable to find a match

(That functionality is broken in some versions—RHBZ#1628514—so you
might not see this result at the moment.)

What are your thoughts?

It's neat, but it doesn't help catch typos, which seems like the most
probably case where I'd want such a feature.

How about instead of a scheme based on provides, just quickly check if
a package has a "similar" name?

Basically extend the existing check for lowercase you mention.


Catching typos would be useful, and I'd certainly support that addition, 
but this doesn't really scratch the itch I'm trying to solve.
We want to tell the user "these are exactly the alternatives available 
to you". Not guess, not rely on some typo resolution. We know what the 
alternatives are, here they are.


I've talked with people working on dnf and this looks like an easy 
mechanism to add, and it will be more reliable for the use cases it covers.


Tomas



   $ git stats
   git: 'stats' is not a git command. See 'git --help'.
   
   The most similar command is

   status



___
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

46 matches

Mail list logo