Re: IBM buying RedHat

[John Coughlan]

Yea - Does IBM have any plans on keeping, or discarding any of RH’s open source 
efforts…like this one? Can we as a community still expect the same sort of, and 
level of involvement post sale as we have enjoyed before hand from RH/IBM 
employees? 

-L0ft

> On Oct 30, 2018, at 12:12 PM, Matthew Miller  wrote:
> 
> On Sun, Oct 28, 2018 at 07:44:12PM -0400, Neal Gompa wrote:
>> It'd be nice if someone from up top would deign to come and talk to us
>> directly...
> 
> Communications are pretty carefully controlled for regulatory reasons, and
> the fact is even those at the top don't know everything yet. And speculation
> is basically right out. That said, I'm working on what I can do here. Are
> there specific things you'd like to ask?
> 
> -- 
> 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
___
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: IBM buying RedHat

[Porfirio Andrés Páiz Carrasco]

El dom., 28 de oct. de 2018 a la(s) 21:15, John Coughlan
(johncough...@comcast.net) escribió:
>
> IBM is a cancer. How long have they been working with Watson, and what 
> exactly do they have to show for it?
>
> Also as many others have said their FOSS print is a joke at best.
>
> As a community I feel like we are in some trouble here.
>
> IBM shelled out A TON of money for RH, and the first thing they are going to 
> do if it has not been done already is to crack the books. When they see that 
> RH has been VERY supportive of it’s open source community I don’t think 
> that’s going to fly. I don’t think we as a community are going to make it 
> through this transition.

Believe!

Let's stay positives :)

https://www.youtube.com/watch?v=x7ozaFbqg00

Porfirio.
___
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: Use immutable CRAN URLs

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 30 October 2018 at 16:36, Iñaki Ucar wrote:
> Kind reminder. Any update on this?

Jason asked you to open a ticket in the Packaging Committee tracker
and open a pull request against the guidelines. Have you done that?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Reminder: Daylight Saving Time ends in the US on Sunday

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 30 October 2018 at 21:37, Ben Cotton wrote:
> As a reminder to the community, Daylight Saving Time ends in the the
> US on Sunday, 4 November. Be sure to check your recurring meetings on
> Fedocal[1] to make sure you know when you're meeting. Some meetings
> are set to a fixed time UTC and others are set to a particular time
> zone. If a meeting is not in UTC or a US time zone, you can see time
> change information worldwide[2].
> 
> [1] https://apps.fedoraproject.org/calendar/
> [2] https://www.timeanddate.com/time/dst/2018.html

It ended last Sunday in Europe so we are in the one week of the year
when the US is 1 hour closer to Europe. Enjoy while it lasts. ;)

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: help/info needed: Javascript and CORS - a bodhi <--> bugzilla communication problem

[Mattia Verga]

Il 10/30/18 7:13 PM, Tom Hughes ha scritto:
>
> No it protects against unintended exfiltration of data from
> the server - without it a random web page could have javascript
> that did a background XHR to a web site that required authentication
> and just wait until somebody happens to visit that page who happens
> to have a valid session cookie for the target site.
>
> So allowing CORS access to resources that don't require authentication
> is not normally a problem but allowing it to resources that do require
> some sort of authentication requires that you trust the domain you are
> allowing the access to.

So, for example, it is acceptable that 
https://apps.fedoraproject.org/packages/ sends a 
`access-control-allow-origin: *` header because it doesn't require 
authentication, while BZ must use something more granular, doesn't it?

>
> So for BZ I guess the issue will be figuring out if any of the bugs
> you are getting information on are restricted in any way? or maybe
> that's fine if the bodhi user has access to those bugs and the domain
> can just be validated to restrict it to bodhi?
>
 From what I see, if a bug is somehow restricted (like private bugs) BZ 
will manage that with an error response in the json reply. For example:

https://bugzilla.redhat.com/jsonrpc.cgi?method=Bug.get¶ms=[{%22ids%22:1641325}]

returns me a "You are not authorized to access" even if in the same 
browser session I'm logged in in BZ and I can see the bug content in the 
html view.

___
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

Reminder: Daylight Saving Time ends in the US on Sunday

[Ben Cotton]

As a reminder to the community, Daylight Saving Time ends in the the
US on Sunday, 4 November. Be sure to check your recurring meetings on
Fedocal[1] to make sure you know when you're meeting. Some meetings
are set to a fixed time UTC and others are set to a particular time
zone. If a meeting is not in UTC or a US time zone, you can see time
change information worldwide[2].

[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2018.html

-- 
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: IBM buying RedHat

[Matthew Miller]

On Sun, Oct 28, 2018 at 07:44:12PM -0400, Neal Gompa wrote:
> It'd be nice if someone from up top would deign to come and talk to us
> directly...

Communications are pretty carefully controlled for regulatory reasons, and
the fact is even those at the top don't know everything yet. And speculation
is basically right out. That said, I'm working on what I can do here. Are
there specific things you'd like to ask?

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

Re: help/info needed: Javascript and CORS - a bodhi <--> bugzilla communication problem

[Tom Hughes]

On 30/10/2018 18:13, Tom Hughes wrote:

On 30/10/2018 17:36, Mattia Verga wrote:


What type of security issue may arise with a wildcarded
`Access-Control-Allow-Headers: *` header? As I understand CORS, it's not
a server protection, rather a client protection. In fact, installing a
browser extension like CorsE for Firefox easily bypass that "protection"
and allows the script to run.


No it protects against unintended exfiltration of data from
the server - without it a random web page could have javascript
that did a background XHR to a web site that required authentication
and just wait until somebody happens to visit that page who happens
to have a valid session cookie for the target site.


Of course for non-GET requests this extends beyond exfiltration
to state altering operations, so that background script might place
an order or submit a new bug or whatever using your session cookie.

Tom

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

Re: help/info needed: Javascript and CORS - a bodhi <--> bugzilla communication problem

[Tom Hughes]

On 30/10/2018 17:36, Mattia Verga wrote:


The problem is that the ajax request to Bugzilla fails, because BZ
doesn't provide CORS headers. I've asked BZ guys [2] to add those
headers, but I'm a bit confused about how CORS works and I would need
some help from someone who may have a deeper knowledge on this.
Does the BZ server need to provide the `Access-Control-Allow-Headers`
header or the `Access-Control-Allow-Origin` header? Is it correct what I
asked in the opened bug [3]?


Principally it needs to send Access-Control-Allow-Origin if it is
happy to allow the request - if the request requires unusual headers
then it might need to send the other one as well.


What type of security issue may arise with a wildcarded
`Access-Control-Allow-Headers: *` header? As I understand CORS, it's not
a server protection, rather a client protection. In fact, installing a
browser extension like CorsE for Firefox easily bypass that "protection"
and allows the script to run.


No it protects against unintended exfiltration of data from
the server - without it a random web page could have javascript
that did a background XHR to a web site that required authentication
and just wait until somebody happens to visit that page who happens
to have a valid session cookie for the target site.

So allowing CORS access to resources that don't require authentication
is not normally a problem but allowing it to resources that do require
some sort of authentication requires that you trust the domain you are
allowing the access to.

So for BZ I guess the issue will be figuring out if any of the bugs
you are getting information on are restricted in any way? or maybe
that's fine if the bodhi user has access to those bugs and the domain
can just be validated to restrict it to bodhi?

Tom

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

Re: help/info needed: Javascript and CORS - a bodhi <--> bugzilla communication problem

[Mattia Verga]

Il 10/30/18 6:36 PM, Mattia Verga ha scritto:
>
> [1] https://github.com/mattiaverga/bodhi/tree/manual_bugs
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1641232
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1641232#c6
>
A more precise link to the ajax call to Bugzilla:

https://github.com/mattiaverga/bodhi/blob/625c6d33256418f4135c533aea278359c282420b/bodhi/server/static/js/update_form.js#L315


___
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

help/info needed: Javascript and CORS - a bodhi <--> bugzilla communication problem

[Mattia Verga]

Hi,

I'm working on a Pull Request for Bodhi web interface to allow 
retrieving bugs information when we try to attach them to an update. 
This way we can do some checks on the bug we're trying to attach (is it 
private? is it a Fedora or Fedora EPEL bug?...) and provide some useful 
information in the update submission form.

The problem is that the ajax request to Bugzilla fails, because BZ 
doesn't provide CORS headers. I've asked BZ guys [2] to add those 
headers, but I'm a bit confused about how CORS works and I would need 
some help from someone who may have a deeper knowledge on this.
Does the BZ server need to provide the `Access-Control-Allow-Headers` 
header or the `Access-Control-Allow-Origin` header? Is it correct what I 
asked in the opened bug [3]?

What type of security issue may arise with a wildcarded 
`Access-Control-Allow-Headers: *` header? As I understand CORS, it's not 
a server protection, rather a client protection. In fact, installing a 
browser extension like CorsE for Firefox easily bypass that "protection" 
and allows the script to run.
Am I wrong?

Thanks in advance for any help.
Mattia

[1] https://github.com/mattiaverga/bodhi/tree/manual_bugs
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1641232
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1641232#c6

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

Fedora rawhide compose report: 20181030.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181028.n.0
NEW: Fedora-Rawhide-20181030.n.0

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

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

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

= ADDED IMAGES =
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20181030.n.0.iso
Image: Jam_KDE live i386
Path: Labs/i386/iso/Fedora-Jam_KDE-Live-i386-Rawhide-20181030.n.0.iso

= DROPPED IMAGES =
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20181028.n.0.aarch64.raw.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20181028.n.0.ppc64le.tar.xz
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20181028.n.0.s390x.tar.xz

= ADDED PACKAGES =
Package: ghostwriter-1.7.3-1.fc30
Summary: Cross-platform, aesthetic, distraction-free Markdown editor
RPMs:ghostwriter
Size:2.51 MiB

Package: python-test_server-0.0.31-2.fc30
Summary: Server to test HTTP clients, written in Python
RPMs:python-test_server-doc python3-test_server
Size:184.90 KiB


= DROPPED PACKAGES =
Package: TurboGears-1.1.3-20.fc29
Summary: Back-to-front web development in Python
RPMs:TurboGears
Size:1.36 MiB

Package: php-Smarty2-2.6.31-2.fc30
Summary: Smarty - the compiling PHP template engine
RPMs:php-Smarty2
Size:131.06 KiB

Package: python-backports-csv-1.0.5-6.fc30
Summary: Backport of Python 3's csv module for Python 2
RPMs:python3-backports-csv
Size:30.05 KiB

Package: python2-astroid-1.6.4-2.fc29
Summary: Common base representation of python source code for pylint and other 
projects
RPMs:python2-astroid
Size:274.61 KiB

Package: python2-pylint-1.9.0-2.fc29
Summary: Analyzes Python code looking for bugs and signs of poor quality
RPMs:python2-pylint
Size:498.77 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.14.4-2.fc30
Old package:  NetworkManager-1:1.14.4-1.fc30
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-config-connectivity-fedora NetworkManager-config-server 
NetworkManager-dispatcher-routing-rules NetworkManager-libnm 
NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp 
NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan
Size: 25.16 MiB
Size change:  9.47 KiB
Changelog:
  * Mon Oct 29 2018 Thomas Haller  - 1:1.14.4-2
  - dhcp: fix out-of-bounds heap write for DHCPv6 with internal plugin 
(CVE-2018-15688)


Package:  am-utils-5:6.2.0-35.fc30
Old package:  am-utils-5:6.2.0-34.fc29
Summary:  Automount utilities including an updated version of Amd
RPMs: am-utils
Size: 6.22 MiB
Size change:  -132.33 KiB
Changelog:
  * Mon Oct 29 2018 Ian Kent  - 5:6.2.0-34
  - disable hesiod support.


Package:  cryptsetup-2.0.5-1.fc30
Old package:  cryptsetup-2.0.4-1.fc29
Summary:  A utility for setting up encrypted disks
RPMs: cryptsetup cryptsetup-devel cryptsetup-libs cryptsetup-reencrypt 
integritysetup veritysetup
Size: 3.61 MiB
Size change:  30.20 KiB
Changelog:
  * Mon Oct 29 2018 Ondrej Kozina  - 2.0.5-1
  - Update to cryptsetup 2.0.5.


Package:  csmock-2.2.1-1.fc30
Old package:  csmock-2.2.0-1.fc30
Summary:  A mock wrapper for Static Analysis tools
RPMs: csbuild csmock csmock-common csmock-plugin-bandit 
csmock-plugin-clang csmock-plugin-cppcheck csmock-plugin-pylint 
csmock-plugin-shellcheck csmock-plugin-smatch
Size: 151.94 KiB
Size change:  760 B
Changelog:
  * Mon Oct 29 2018 Kamil Dudka  2.2.1-1
  - update to latest upstream release


Package:  debian-keyring-2018.1-1.fc30
Old package:  debian-keyring-2017.7-3.fc29
Summary:  GnuPG archive keys of the Debian archive
RPMs: debian-keyring
Size: 59.32 KiB
Size change:  1.18 KiB
Changelog:
  * Mon Oct 29 2018 Sandro Mani  - 2018.1-1
  - Update to 2018.1


Package:  deepin-desktop-base-2018.7.23-2.fc30
Old package:  deepin-desktop-base-2018.7.23-1.fc30
Summary:  Base component for Deepin
RPMs: deepin-desktop-base deepin-manual-directory
Added RPMs:   deepin-manual-directory
Size: 41.32 KiB
Size change:  8.05 KiB
Changelog:
  * Sun Oct 28 2018 Zamir SUN  - 2018.7.23-2
  - Add subpackage deepin-manual-directory to temporary own dman dir.


Package:  dl_poly-1.10-1.fc30
Old package:  dl_poly-1.9.20140324-22.fc29
Summary:  General purpose classical molecular dynamics (MD) simulation
RPMs: dl_poly-common dl_poly-doc dl_poly-gui dl_poly-mpich 
dl_poly-openmpi
Dropped RPMs: dl_poly

Fedora Rawhide-20181030.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 303244  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303244
ID: 303248  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/303248
ID: 303329  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/303329
ID: 303334  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/303334
ID: 303361  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/303361
ID: 303375  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/303375
ID: 303380  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/303380
ID: 303382  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/303382

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

ID: 303243  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303243
ID: 303245  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303245
ID: 303247  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/303247
ID: 303249  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/303249
ID: 303250  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/303250
ID: 303270  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303270
ID: 303271  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/303271
ID: 303272  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303272
ID: 303273  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303273
ID: 303274  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303274
ID: 303275  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/303275
ID: 303276  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/303276
ID: 303277  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303277
ID: 303287  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303287
ID: 303288  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/303288
ID: 303289  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/303289
ID: 303290  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303290
ID: 303291  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/303291
ID: 303292  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/303292
ID: 303293  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/303293
ID: 303294  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/303294
ID: 303295  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303295
ID: 303297  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/303297
ID: 303304  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/303304
ID: 303307  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/303307
ID: 303308  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/303308
ID: 303310  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/303310
ID: 303311  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303311
ID: 303312  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/303312
ID: 303313  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/303313
ID: 303314  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/303314
ID: 303321  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/303321
ID: 303323  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https:

Re: Use immutable CRAN URLs

[Iñaki Ucar]

Kind reminder. Any update on this?

Iñaki

On Wed, 24 Oct 2018 at 17:01, Iñaki Ucar  wrote:
>
> On Wed, 24 Oct 2018 at 15:02, Jason L Tibbitts III  wrote:
> >
> > > "IU" == Iñaki Ucar  writes:
> >
> > IU> This URL format is not recommended by CRAN, but more importantly,
> > IU> the Source0 format does not work anymore, as [1] noted, when a new
> > IU> version is released. However, there is an immutable format
> > IU> available, as [2] pointed out. So my proposal is to use always the
> > IU> following lines instead:
> >
> > IU> URL: https://cran.r-project.org/package=%{packname}
> > IU> Source0: %{url}&version=%{version}
> >
> > That's good to know.  We should consider an %r_source macro similar to
> > the existing %pypi_source macro which is used for python packages.  See:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi
>
> That would be certainly great. I would call it %cran_source instead,
> and a %cran_url would be helpful too, so that we can write the
> following:
>
> URL: %cran_url
> Source0: %cran_source
>
> or maybe something like %cran_origin could directly resolve into the
> above two lines.
>
> > I would be happy to write it, but I don't enough about R packaging to
> > know how uniformly the tags you mention above (%packname, specifically)
> > are adhered to in the current packaging set.
>
> %packname is a global variable defined by the R2spec util. I've
> checked (script attached in case you're interested) and basically all
> the packages use this global. So the new macro(s) would accept up to
> two arguments: the name of the R package, which should default to
> %packname if defined, and the version, by default %version.
>
> > IU> which are both shorter and immutable, and I propose to add this to
> > IU> the R packaging guidelines too.
> >
> > Well you should certainly open a ticket with the packaging committee if
> > you wish to propose changes to the packaging guidelines.
> > https://pagure.io/packaging-committee/
> >
> > You can even send a pull request.
>
> Great. I'll wait for that if you're going to push forward this new macro.
>
> > IU> If we agree on this, is there any easy way to request a system-wide
> > IU> change like that to all existing packages?
> >
> > https://fedoraproject.org/wiki/Mass_package_changes
>
> Thanks for the pointer.
>
> >
> >  - J<
>
> --
> Iñaki Ucar



-- 
Iñaki Ucar
___
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: [HEADS UP] libsolv 0.7

[Igor Gnatenko]

And it's in rawhide!

libdnf, rpm-ostree and perl-BSSolv are rebuilt.
On Sun, Oct 28, 2018 at 4:04 PM Igor Gnatenko
 wrote:
>
> Hello folks,
>
> It is the release towards 1.0 (yes, after more than 10 years) which is out 
> for 4 days now.
>
> I'm going to investigate whether it will affect libdnf and push into the 
> rawhide within few days.
>
> Version 0.7.0
> - soname bump to "1"
> - incompatible API changes:
>   * bindings: Selection.flags is now an attribute
>   * repodata_lookup_num now works like the other lookup_num functions
> - new functions:
>   * selection_make_matchsolvable
>   * selection_make_matchsolvablelist
>   * pool_whatmatchessolvable
>   * repodata_search_arrayelement
>   * repodata_lookup_kv_uninternalized
>   * repodata_search_uninternalized
>   * repodata_translate_dir
> - new repowriter interface to write solv files allowing better
>   control over what gets written
> - support for filtered file lists with a custom filter
> - dropped support of (since a long time unused) REPOKEY_TYPE_U32
>
> Thanks for attention!
___
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 is available now!

[Matthew Miller]

Tomorrow is Halloween, but this week at the Fedora Project, we're
not scared of anything. Today, we officially release Fedora 29!

As always, this release is the result of the hard work of thousands
of people working in Fedora, and many times more working in all of
the upstream projects. Thank you and congratulations to everyone!

Read the official announcement at: 

* https://fedoramagazine.org/announcing-fedora-29/

or just go ahead and grab it from:

* https://getfedora.org/



-- 
Matthew Millermat...@mattdm.org 
Fedora Project Leader  mat...@fedoraproject.org   
___
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

Re: Anyone working on Xen on F29

[Cole Robinson]

On 10/29/2018 05:26 PM, YOUNG, MICHAEL A. wrote:

Incidentally I have now tried the example with virt-install
https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt
updated for fedora 29 and it failed with the error
ERRORinternal error: unsupported input bus usb



This should be fixed with the virt-manager updates-testing FWIW

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

Self Introduction: Carmen

[Carmen Bianca Bakker]

Hi all,

The contribution guide thingamajig told me to post a short message
here.  So as follows: I am Carmen from Friesland, The Netherlands.  I am
currently working on GNOME to make the GNOME desktop available in
Esperanto.  At the current rate, GNOME 3.32 will have its core release
(standard apps, core libraries) completely translated into Esperanto,
which I am fairly proud of :-)

Furthermore, I am a former intern of the Free Software Foundation Europe
where I worked on the REUSE Initiative (;).  You
can find me at the FSFE booth at SFScon in Bozen/Bolzano, 16 November.

I am joining this list to make sure that `langpacks-eo` will become
available in Fedora 30.  If someone knows some pointers for me there
while I (slowly) work on it, I would greatly appreciate those.

Thanks and with kindness,
Carmen



signature.asc
Description: This is a digitally signed message part
___
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: F30 Self-Contained Change proposal: Pantheon Desktop

[Fabio Valentini]

On Tue, Oct 30, 2018 at 9:01 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Oct 29, 2018 at 05:04:52PM -0400, Ben Cotton wrote:
> > This Change is about simply adding Desktop Environment to fedora.
> > If we decide to make this a spin in the future, that will be a separate 
> > Change.
>
> I'm a bit confused about the scope of this change, probably because I've
> never used Pantheon. Is this change about "adding" or "upgrading"? IIUC,
> some older versions are already packaged in Fedora. Could you add a more
> concrete description of what will be considered a successful implementation
> of this change for F30?

Hi Zbyszek,

I see the source of your confusion now. I seem to have chosen a poor
wording in that sentence.
This Change is about adding the _missing pieces_ to fedora, and fixing
show-stopper bugs.

> Also, if somebody wanted to help, is there a "TODO" list that one could look
> at? Some packages are missing, but are there reviews for them, etc.

The "TODO" list is the bullet points below the packaging status table,
under the "Scope" section. I'll add a separate heading for it or move
it to a new "TODO" section.

I already packaged the "missing" packages, they're available from my
decathorpe/elementary-staging COPR repository. I didn't want to open
review requests for them until I was sure that they work correctly on
fedora. I'm maintaining the .spec files for the "staging" packages in
this GitHub repository for now:
https://github.com/decathorpe/elementary-staging-rpms
I try to closely follow the Packaging Guidelines even for my COPR
packages, so moving them to fedora when they're ready should be a fast
process.

> > == Upgrade/compatibility impact ==
> >
> > Packages for the Pantheon DE and elementary applications have been available
> > since fedora 25 in some cases, and most components have been available since
> > fedora 27. Upgrading to the latest fedora release brings users the latest
> > versions of these packages.
> >
> > However, due to upstream changes, some desktop applications might lose user
> > settings when upgrading from fedora 28 to 29, because upstream changed their
> > GSettings path between releases. For that reason, the updates containing 
> > these
> > breaking changes were not pushed to stable releases < 29.
>
> 29 or 30?

Both, but mainly 29. That's primarily caused by how the fedora and
elementaryOS releases lined up. I was able to push most non-backwards
compatible things to fedora 29 before the release today, but it would
have been way too late to announce an official "Pantheon" desktop for
fedora 29, since there's still some integration work needed.

Getting the components packaged and working on fedora was a multi-year
effort. So, I've tried to follow the relevant Updates Policy for
stable releases - since almost all components (especially the
applications) are independent, and can be used on their own. That's
the reason why the applications that contain non-backwards compatible
changes were not pushed to stable releases, but backwards-compatible
updates were pushed to all stable releases, where possible.

> > == How To Test ==
> >
> > * install the Pantheon Desktop Environment:
> > {{package|pantheon-session-settings}} (metapackages / comps groups not
> > yet available)
> Is adding the comps groups planned for F30?

Yes. See the last three bullet point under "Scope".

> > * choose Pantheon session at login
> > * use the system as usual
> > * try out elementary applications
> > * check if screensaver kicks in (possibly doesn't work yet)
> Is there a bug open for this?

The bug that locking the screen with light-locker on LightDM was
tracked on GitHub (it was opened before the packages were in stable
fedora). The screensaver / screen lock should now work in the LightDM
/ light-locker scenario.
https://github.com/decathorpe/elementary-stable-rpms/issues/9

There's no bug report for lacking screensaver support on GDM yet. I'll
open the necessary bug reports later today.


I'll also update the Change's wiki page with some clarifications.

Fabio

> 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
___
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: Missing Notifications

[Vít Ondruch]

Dne 29. 10. 18 v 23:31 Kevin Fenzi napsal(a):
> On 10/28/18 8:01 AM, Scott Talbert wrote:
>> Hi,
>>
>> What happened to the broken dependency notification emails?
> They got broken a while back by rich deps, then the script was
> re-written entirely and re-enabled, but we haven't re-enabled the emails
> yet due to release taking up everyones time.
>
> Here's an example:
>
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20181028.n.0/logs/depcheck


This does not look like "broken dependencies" but just dependencies.


V.


>
> Hopefully we can enable emails soon.
>
>> Also, it seems that Anitya has not been creating bugs for new upstream
>> releases for several months.  The problem doesn't seem to be with Anitya
>> as it knows about the new releases, but somewhere else in the chain.  I
>> thought I had found a bug for this somewhere but now I can't find it.
> This was/is due to a combination of issues. First there was a problem
> with it's checking script where it would error out early on and just
> never check a lot of things, then once that was fixed, there's been
> github api limits, then now there's some issue with the fedmsgs it's
> emitting not getting to the app that files the bugs. ;( It's now being
> moved to our new messaging bus in hopes of fixing that issue.
>
> I think: https://github.com/release-monitoring/anitya/issues/638 is the
> issue tracking this.
>
> 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


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: F30 Self-Contained Change proposal: Pantheon Desktop

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 29, 2018 at 05:04:52PM -0400, Ben Cotton wrote:
> This Change is about simply adding Desktop Environment to fedora.
> If we decide to make this a spin in the future, that will be a separate 
> Change.

I'm a bit confused about the scope of this change, probably because I've
never used Pantheon. Is this change about "adding" or "upgrading"? IIUC,
some older versions are already packaged in Fedora. Could you add a more
concrete description of what will be considered a successful implementation
of this change for F30?

Also, if somebody wanted to help, is there a "TODO" list that one could look
at? Some packages are missing, but are there reviews for them, etc.

> == Upgrade/compatibility impact ==
> 
> Packages for the Pantheon DE and elementary applications have been available
> since fedora 25 in some cases, and most components have been available since
> fedora 27. Upgrading to the latest fedora release brings users the latest
> versions of these packages.
> 
> However, due to upstream changes, some desktop applications might lose user
> settings when upgrading from fedora 28 to 29, because upstream changed their
> GSettings path between releases. For that reason, the updates containing these
> breaking changes were not pushed to stable releases < 29.

29 or 30?

> == How To Test ==
> 
> * install the Pantheon Desktop Environment:
> {{package|pantheon-session-settings}} (metapackages / comps groups not
> yet available)
Is adding the comps groups planned for F30?

> * choose Pantheon session at login
> * use the system as usual
> * try out elementary applications
> * check if screensaver kicks in (possibly doesn't work yet)
Is there a bug open for this?

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