Re: Capitalized name in bugzilla review request and pagure repo

2019-08-08 Thread Miro Hrončok 

On 07. 08. 19 23:44, Jordan Ogas via devel wrote:

In case someone bumps into this in the future, the solution was quite simple:
edit the bugzilla ticket, fix the capitalization (or whatever typo) and then
request a new repo via fedpkg.


Please also retire the wrongly created package:

$ cd Charliecloud
$ fedpkg retire "Moved to charliecloud"

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: Source File Verification

2019-08-08 Thread Joe Orton 
On Thu, Jul 25, 2019 at 07:22:56PM +0200, Björn Persson wrote:
> Jason L Tibbitts III wrote:
> > > "JO" == Joe Orton  writes:  
> > 
> > JO> In the historic CVS-based build system which predated what we now
> > JO> use, we could do GPG key verification at the time of downloading and
> > JO> importing a new tarball.  
> > 
> > You're right; tmz dug up a copy of the old Makefile.common file:
> > https://tmz.fedorapeople.org/tmp/Makefile.common
> 
> It looks like that searched for and verified signatures when the
> packager ran "make download". If they downloaded a new tarball with a
> browser, then it would not be verified automatically. The packager
> could then download the signature too and run "make download-checks"
> manually – if they happened to remember and care. Experience shows that
> most people don't care about security until it's too late, so the
> verification would often not happen. No one else could know whether the
> signature had been verified or not.
> 
> Having that functionality back could be a useful tool, but it would not
> replace verification during the build, which the packager can't just
> forget to do once they have added the one-liner to the spec file.

If you don't enforce GPG verification at or before "fedpkg upload" there 
is no assurance that what hits the lookaside cache is trusted, so I 
agree - doing this at build time is a good example of not caring about 
security until it's too late.

But I assume the FPC is off doing its own thing and will totally ignore 
community feedback as normal, so I'll feel free to carry on ignoring FPC 
output and this whole conversation is pointless.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

A Friday with Infra

2019-08-08 Thread Michal Konecny 

Good Morning Everyone,

As you may remember from [1] the CPE team has started categorizing its 
applications into the following categories:


1. We maintain it, we run it
2. We don’t maintain it, we run it
3. We don’t maintain it, we don’t run it
4. We turn it off

In this process we picked the following four applications that we want 
to move from the first category to the third:


 * elections [2]
 * fedocal
 * nuancier
 * badges

However, we do not want to throw code over the wall to anyone, so we’re 
setting up something we called “A Friday with Infra”. The goal is to 
help on-boarding anyone interested in picking up the maintenance of any 
of these apps by taking time on Friday to work on these apps with them.


We have prepared a wiki page describing this proposal, how to get 
involved in it as well as all the work we believe should be done to have 
a smooth hand-over of the applications:

https://fedoraproject.org/wiki/Infrastructure_2020/Friday_with_Infra

Let us know if you have any questions or (even better) want to be 
involved with any of them :)


Michal
– On behalf of the CPE team



[1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/

[2] elections has actually already found a new maintainer

___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: 20190808.n.0 changes

2019-08-08 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20190807.n.0
NEW: Fedora-Rawhide-20190808.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  7
Dropped packages:5
Upgraded packages:   160
Downgraded packages: 0

Size of added packages:  37.25 MiB
Size of dropped packages:24.05 MiB
Size of upgraded packages:   10.21 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20190807.n.0.iso

= ADDED PACKAGES =
Package: anthy-unicode-1.0.0.20190412-1.fc31
Summary: Japanese character set input library for Unicode
RPMs:anthy-unicode anthy-unicode-devel emacs-anthy-unicode 
xemacs-anthy-unicode
Size:34.48 MiB

Package: charliecloud-0.9.10-10.fc31
Summary: Lightweight user-defined software stacks for high-performance computing
RPMs:charliecloud charliecloud-doc
Size:2.31 MiB

Package: ocaml-mmap-1.1.0-2.fc31
Summary: File mapping functionality
RPMs:ocaml-mmap ocaml-mmap-devel
Size:209.27 KiB

Package: perl-DBIx-Class-Candy-0.005003-2.fc31
Summary: Sugar for your favorite ORM, DBIx::Class
RPMs:perl-DBIx-Class-Candy
Size:32.64 KiB

Package: perl-RDF-TrineX-Compatibility-Attean-0.100-1.fc31
Summary: Compatibility layer between Attean and RDF::Trine
RPMs:perl-RDF-TrineX-Compatibility-Attean
Size:19.65 KiB

Package: perl-Unix-Groups-FFI-0.002-1.fc31
Summary: Interface to Unix group system calls
RPMs:perl-Unix-Groups-FFI
Size:16.72 KiB

Package: python-coveralls-1.8.2-1.fc31
Summary: Coveralls.io provides seamless integration with coverage.py
RPMs:python3-coveralls python3-coveralls-docs
Size:196.91 KiB


= DROPPED PACKAGES =
Package: childsplay-1.6-30.fc31
Summary: Suite of educational games for young children
RPMs:childsplay childsplay-alphabet_sounds_bg childsplay-alphabet_sounds_ca 
childsplay-alphabet_sounds_de childsplay-alphabet_sounds_el 
childsplay-alphabet_sounds_en_GB childsplay-alphabet_sounds_es 
childsplay-alphabet_sounds_fr childsplay-alphabet_sounds_it 
childsplay-alphabet_sounds_lt childsplay-alphabet_sounds_nb 
childsplay-alphabet_sounds_nl childsplay-alphabet_sounds_pt 
childsplay-alphabet_sounds_pt_BR childsplay-alphabet_sounds_ro 
childsplay-alphabet_sounds_ru childsplay-alphabet_sounds_sl 
childsplay-alphabet_sounds_sv
Size:23.76 MiB

Package: obmenu-1.0-29.fc31
Summary: A graphical menu editor for Openbox
RPMs:obmenu
Size:36.60 KiB

Package: pkpgcounter-3.50-18.fc31
Summary: Computes number of pages or quantity of ink needed to print documents
RPMs:pkpgcounter
Size:89.12 KiB

Package: pyfribidi-0.11.0-19.fc31
Summary: A Python binding for GNU FriBidi
RPMs:pyfribidi
Size:137.44 KiB

Package: repo_manager-0.1.0-15.fc31
Summary: Manage your RPM repositories easily
RPMs:repo_manager
Size:33.87 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-openconnect-1.2.6-1.fc31
Old package:  NetworkManager-openconnect-1.2.4-12.fc31
Summary:  NetworkManager VPN plugin for openconnect
RPMs: NetworkManager-openconnect NetworkManager-openconnect-gnome
Size: 2.98 MiB
Size change:  355.61 KiB
Changelog:
  * Wed Aug 07 2019 David Woodhouse  - 1.2.6-1
  - Update to 1.2.6
  - Support all protocols that OpenConnect does (#1714121)
  - Persistent support (#1701157)


Package:  arachne-pnr-0.1-0.7.20190729gitc40fb22.fc31
Old package:  arachne-pnr-0.1-0.7.20170628git7e135ed.fc31
Summary:  Place and route for FPGA compilation
RPMs: arachne-pnr
Size: 55.97 MiB
Size change:  27.22 MiB
Changelog:
  * Wed Aug 07 2019 Vasil Velichkov  - 
0.1-0.7.20190729gitc40fb22
  - Update to upstream git c40fb2289952f4f120cc10a5a4c82a6fb88442dc


Package:  buildah-1.11.0-0.5.dev.git03aa807.fc31
Old package:  buildah-1.9.3-0.67.dev.git4d017d6.fc31
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 37.00 MiB
Size change:  1.24 MiB
Changelog:
  * Fri Aug 02 2019 Lokesh Mandvekar (Bot)  - 
1.9.3-0.68.dev.git3117f5e
  - autobuilt 3117f5e

  * Fri Aug 02 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.1.dev.gitac5031d
  - bump to 1.11.0
  - autobuilt ac5031d

  * Mon Aug 05 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.2.dev.git1de958d
  - autobuilt 1de958d

  * Tue Aug 06 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.3.dev.git232f7c6
  - autobuilt 232f7c6

  * Wed Aug 07 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.4.dev.gitbafcf88
  - autobuilt bafcf88

  * Wed Aug 07 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.5.dev.git03aa807
  - autobuilt 03aa807


Package:  cadvisor-0.33.1-4.20190708git2ccad4b.fc31
Old package:  cadvisor-0.33.1-3.20190708git2ccad4b.fc31
Summary:  Analyzes resource usage and performance characteristics of 
running containers
RPMs: cadvisor golang-github-google-cadvisor-devel
Size: 53.39

Fedora-Rawhide-20190808.n.0 compose check report

2019-08-08 Thread Fedora compose checker 
No missing expected images.

Compose FAILS proposed Rawhide gating check!
12 of 45 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 27/147 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20190807.n.0):

ID: 430185  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/430185
ID: 430190  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/430190
ID: 430192  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/430192

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

ID: 430143  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/430143
ID: 430148  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/430148
ID: 430149  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430149
ID: 430152  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/430152
ID: 430153  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/430153
ID: 430154  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/430154
ID: 430155  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/430155
ID: 430156  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/430156
ID: 430157  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430157
ID: 430158  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/430158
ID: 430159  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/430159
ID: 430160  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/430160
ID: 430167  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430167
ID: 430168  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430168
ID: 430180  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430180
ID: 430183  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/430183
ID: 430198  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/430198
ID: 430200  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/430200
ID: 430201  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/430201
ID: 430262  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/430262
ID: 430270  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/430270
ID: 430273  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/430273
ID: 430274  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/430274
ID: 430276  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/430276
ID: 430277  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/430277

Passed openQA tests: 103/147 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20190807.n.0):

ID: 430132  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/430132
ID: 430133  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/430133
ID: 430165  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/430165
ID: 430166  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/430166
ID: 430213  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/430213
ID: 430218  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/430218
ID: 430260  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/430260
ID: 430267  Test: x86_64 universal install_kickstart_fir

Re: Join the new Minimization Team

2019-08-08 Thread Daniel Walsh 
On 8/7/19 11:24 AM, Colin Walters wrote:
>
> On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
>> If you want small images, just use buildah.
> Dockerfile-based multi-stage builds are significantly more popular than this 
> and should really be mentioned first.
Buildah supports multi-stage builds as well.
> I'm not saying `buildah` is bad, but...what you're talking about here also 
> encourages using the host as a build root which has various negatives.
>
> And I think the main conversation to have is whether we should introduce 
> something more like
> https://github.com/GoogleContainerTools/distroless
> that basically just has:
>
>  - glibc
>  - ca-certificates
>
> Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's 
> it.
> (While people often say both Rust and golang are statically linked, that's 
> true
>  of the language code, but by default  Rust links to glibc, Go does not, and I
>  think what Rust does is better and should be encouraged, so we want a libc
>  in this "ultramin" container)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Retiring FTBFS packages from Fedora 30

2019-08-08 Thread Mohan Boddu 
Hello all,

As per the FTBFS policy [1], we started the retirement of the packages that
have been FTBFS since F30 mass rebuild. Please follow the unretirement
process [2] if you are planning to re-add the package to Fedora.

[1]
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[2]
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

Thanks,
Fedora Release Engineering.
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

2019-08-08 Thread Petr Stodulka 



On 07. 08. 19 19:45, Neal Becker wrote:

Petr Stodulka wrote:




On 07. 08. 19 19:31, Petr Stodulka wrote:


On 07. 08. 19 3:34, Mads Kiilerich wrote:

On 8/6/19 9:35 PM, Petr Stodulka wrote:

So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or



Hi

I agree that something like this kind of is the right thing to do.
Mercurial upstream needs our help to get Python3 support out of beta.
But it will be painful. For developers and users.


Yep. That's it. On the other hand, I am thinking now, whether people will
have enough time to fix everything in case we will put it into the repo
later. I mean, now there is enough time to work on that, bzt doing switch
e.g. 3 months before release would generate more pressure on other
maintainers.



It might get more attention if we take hostages and leave Mercurial
broken for our users, but I would rather avoid that.

Right now all packages that depend on Mercurial are kind of blocked and
can't migrate because there is no official package with Mercurial on
Python3. I think the best way forward is to get it packaged for python3,
next to the existing python2 package. Perhaps as a sub package, or
perhaps as a separate package that can be patched and move fast. That
will give us opportunity and freedom to experiment and migrate each
dependent package as we see fit, with minimal negative impact on our
users.

/Mads
packager, hgview and tortoisehg




I agree that that seems like best options for people,
but honestly I am not sure how much it worth to create
such packages and probably remove the old ones before
we release new system. I mean, from your email I guess
you mean something like this:
  - keep these python2 now:
  mercurial, mercurial-hgk, mercurial-*
  - create new subpkgs for python3
  mercurial3, mercurial3-hgk, mercurial3-*
  (or vice versa; mercurial for py3, and mercurial2 for py2)
Right? As we are talking about temporary state that will be
changed in several weeks (one of those groups will be dropped
before release of 31) and after that there will be additional
release/obsolete set, which jsut beause of that I am not so
big fun. I would honestly rather tell people they should use
copr builds instead. - or we can guide people in case of troubles
to switch to COPR repo for Python2 builds of mercurial and use
just the new in rawhide. That would be solution too. What do you
think about that?

I will be able to spent 1-2 nights with that next week again.
I am able to create the subpackages next week if needed but
I would go rather with ways where COPR is included (creating
mercurial group including all related people - maintainers -
to be able to work there and later switch in rawhide).

Currently, some additional packages that works with mercurial,
have to resolve the troubles already as dependencies for them
will be broken soon because of orphaned rpms.

I would like to hear even opinions of other people around,
especially people around mercurial (including mercurial
maintainers, guys?)




I've tested hg-5.0.2 python3 and I see that many extensions that I depend on
aren't ported yet (and don't work).  I'm not even sure that all the
extensions that ship standard with hg work.  IMO, that is not yet ready for
even rawhide- shipping this will cause too much breakage.


Hi Neal,
Can you test the build in copr repo I prepared earlier? There is version
hg-5.1.0 which would be already in better shape maybe. But probably still
many things will be broken.
  # dnf copr enable pstodulk/mercurial

Ah.. I realizes I haven't attached some links earlier. So putting that
here now
  BZ:[0] https://bugzilla.redhat.com/show_bug.cgi?id=1737931
  COPR repo: [1] https://copr.fedorainfracloud.org/coprs/pstodulk/mercurial

Patch (POC) for the current rawhide branch is attached in the BZ as well.

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

Re: Disappearing mouse pointer

2019-08-08 Thread Gwyn Ciesla via devel 
I'm seeing this with Intel graphics, but not involving virt-manager. My pointer 
disappears when I open the GNOME 3 notifications dialog, and reappears when I 
move off it or close it.

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, August 7, 2019 11:48 PM, Antonio M  
wrote:

> same here, but I am using only Intel graphics. Pointer disappears only out of 
> application windows, and sometimes it comes backagain
> Filed a bug against gnome but not sure of the component. Reported link says 
> unavailable
> Antonio Montagnani
> 

> Linux Fedora 30 Workstation
> da/from Gmail
> 

> Il giorno gio 8 ago 2019 alle ore 06:21 Peter Hutterer 
>  ha scritto:
> 

> > On Wed, Aug 07, 2019 at 09:55:02AM -0600, Chris Murphy wrote:
> > > On Wed, Aug 7, 2019 at 9:03 AM Jerry James  wrote:
> > > >
> > > > I use the default GNOME desktop, using Wayland with Intel graphics.  I
> > > > have a web browser, a terminal, and an editor running on desktop 1.
> > > > On desktop 2 (i.e., where Ctrl-Alt-Down takes you) I have virt-manager
> > > > running, with open windows for whichever VMs are currently in use.
> > > >
> > > > Yesterday, I updated my Fedora 30 machine.  See the list of updated
> > > > packages below.  After rebooting into the new kernel, I interacted
> > > > with a CentOS 7 VM for maybe 10 minutes.  When I moved the mouse
> > > > pointer out of the VM window on desktop 2, the pointer vanished.  That
> > > > is, the mouse pointer is now invisible on desktop 2, except when it is
> > > > inside the VM window.  If I switch back to desktop 1, the mouse
> > > > pointer is visible, unless I move it onto the menu bar at the top of
> > > > the screen, where it also vanishes.
> > > >
> > > > Logging out and then back in restored the mouse pointer, but after
> > > > working with the VM for just a few minutes, the mouse pointer
> > > > disappeared again, exactly as before.  Opening system settings brought
> > > > the mouse pointer back, for some reason.
> > >
> > > Weirdly I'm not seeing this on Fedora 30, I'm only seeing it on
> > > Rawhide, and I haven't figured out a pattern because it doesn't always
> > > happen.
> > >
> > > Also I'm only using Rawhide VM's in virt-manager, so I'm not certain
> > > the guest matters but that's speculative. Definitely it's related to
> > > virt-manager and intel graphics because I'm not using anything other
> > > than those two.
> > >
> > > My Fedora 30 laptop has
> > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake
> > > GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA
> > > controller])
> > >
> > > My Fedora 31 laptop (with this transient issue) has
> > > 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd
> > > Generation Core Processor Family Integrated Graphics Controller
> > > [8086:0126] (rev 09) (prog-if 00 [VGA controller])
> > >
> > > So it might be a controller specific bug, possibly kernel regression.
> > > But I'm not sure what components are responsible for the drawing of
> > > the pointer, and how it's negotiated when it transitions a
> > > virt-manager guest window, and all the ways that could cause confusion
> > > in a way to make the pointer vanish.
> > 

> > maybe https://gitlab.freedesktop.org/spice/spice-gtk/issues/83 or related to
> > it.
> > 

> > Cheers,
> >    Peter
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

seabios / seabios-bin split in Fedora - why?

2019-08-08 Thread Richard W.M. Jones 
I'm trying to package OpenSBI RISC-V firmware for Fedora
(https://github.com/riscv/opensbi).  It's a similar situation to
SeaBIOS and other architecture firmware.  We have to cross-compile a
binary on potentially any Koji architecture, and end up with a noarch
package, because the final firmware blob can be installed on any
architecture too.

Here's my initial attempt:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=36861731
  http://oirase.annexia.org/reviews/opensbi/opensbi.spec

I needed to use %global _binaries_in_noarch_packages_terminate_build 0
to stop RPM complaining about:

  error: Arch dependent binaries in noarch package

SeaBIOS uses the same workaround:

  https://src.fedoraproject.org/rpms/seabios/blob/master/f/seabios.spec

But also it builds an empty seabios package and then builds the binary
into seabios-bin.  Does anyone remember why that was needed?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: seabios / seabios-bin split in Fedora - why?

2019-08-08 Thread Paolo Bonzini 
On 08/08/19 16:14, Richard W.M. Jones wrote:
> I'm trying to package OpenSBI RISC-V firmware for Fedora
> (https://github.com/riscv/opensbi).  It's a similar situation to
> SeaBIOS and other architecture firmware.  We have to cross-compile a
> binary on potentially any Koji architecture, and end up with a noarch
> package, because the final firmware blob can be installed on any
> architecture too.
> 
> Here's my initial attempt:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=36861731
>   http://oirase.annexia.org/reviews/opensbi/opensbi.spec
> 
> I needed to use %global _binaries_in_noarch_packages_terminate_build 0
> to stop RPM complaining about:
> 
>   error: Arch dependent binaries in noarch package
> 
> SeaBIOS uses the same workaround:
> 
>   https://src.fedoraproject.org/rpms/seabios/blob/master/f/seabios.spec
> 
> But also it builds an empty seabios package and then builds the binary
> into seabios-bin.  Does anyone remember why that was needed?

It's just backwards compatibility.  seabios is a noarch package because
you can use it to run emulated x86 virtual machines on non-x86
architectures.  At the same time, we wanted the build to happen on an
x86 machine so that was done via the empty package + ExclusiveArch.

Fedora builds of seabios and other firmware support cross compilation
these days though, so you don't need the hack anymore.  You only need to
allow arch dependent binaries in noarch packages.  Also, please install
the binaries in /usr/share, not /usr/lib.

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

Re: HEADS UP: Source File Verification

2019-08-08 Thread Björn Persson 
Joe Orton wrote:
> If you don't enforce GPG verification at or before "fedpkg upload" there 
> is no assurance that what hits the lookaside cache is trusted, so I 
> agree - doing this at build time is a good example of not caring about 
> security until it's too late.

I hope most people reading this can see the flaws in that reasoning.

> But I assume the FPC is off doing its own thing and will totally ignore 
> community feedback as normal,

It took a long time and some prodding, but the fact that the source
file verification policy was eventually accepted is proof that this
accusation is false.

Björn Persson


pgpFrWUDXWvVt.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: seabios / seabios-bin split in Fedora - why?

2019-08-08 Thread Daniel P . Berrangé 
On Thu, Aug 08, 2019 at 03:14:15PM +0100, Richard W.M. Jones wrote:
> I'm trying to package OpenSBI RISC-V firmware for Fedora
> (https://github.com/riscv/opensbi).  It's a similar situation to
> SeaBIOS and other architecture firmware.  We have to cross-compile a
> binary on potentially any Koji architecture, and end up with a noarch
> package, because the final firmware blob can be installed on any
> architecture too.
> 
> Here's my initial attempt:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=36861731
>   http://oirase.annexia.org/reviews/opensbi/opensbi.spec
> 
> I needed to use %global _binaries_in_noarch_packages_terminate_build 0
> to stop RPM complaining about:
> 
>   error: Arch dependent binaries in noarch package
> 
> SeaBIOS uses the same workaround:
> 
>   https://src.fedoraproject.org/rpms/seabios/blob/master/f/seabios.spec
> 
> But also it builds an empty seabios package and then builds the binary
> into seabios-bin.  Does anyone remember why that was needed?

Originally we were using the native compilers, which meant we could
only build it on an x86 host. Thus the main seabios package was
ExclusiveArch %{ix86} x86_64.  QEMU's TCG emulators though needed
the resulting firmware available on every arch, so we added the
ROM to the seabios-bin sub-RPM which was Buildarch: noarch.

It thus forced koji to pick an x86 host, but still gave us a noarch
result.

No longer after this though, we switched to using cross compilers,
so I'm not seeing the obvious need to keep this split -bin anymore.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: seabios / seabios-bin split in Fedora - why?

2019-08-08 Thread Daniel P . Berrangé 
On Thu, Aug 08, 2019 at 04:22:33PM +0200, Paolo Bonzini wrote:
> On 08/08/19 16:14, Richard W.M. Jones wrote:
> > I'm trying to package OpenSBI RISC-V firmware for Fedora
> > (https://github.com/riscv/opensbi).  It's a similar situation to
> > SeaBIOS and other architecture firmware.  We have to cross-compile a
> > binary on potentially any Koji architecture, and end up with a noarch
> > package, because the final firmware blob can be installed on any
> > architecture too.
> > 
> > Here's my initial attempt:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=36861731
> >   http://oirase.annexia.org/reviews/opensbi/opensbi.spec
> > 
> > I needed to use %global _binaries_in_noarch_packages_terminate_build 0
> > to stop RPM complaining about:
> > 
> >   error: Arch dependent binaries in noarch package
> > 
> > SeaBIOS uses the same workaround:
> > 
> >   https://src.fedoraproject.org/rpms/seabios/blob/master/f/seabios.spec
> > 
> > But also it builds an empty seabios package and then builds the binary
> > into seabios-bin.  Does anyone remember why that was needed?
> 
> It's just backwards compatibility.  seabios is a noarch package because
> you can use it to run emulated x86 virtual machines on non-x86
> architectures.  At the same time, we wanted the build to happen on an
> x86 machine so that was done via the empty package + ExclusiveArch.
> 
> Fedora builds of seabios and other firmware support cross compilation
> these days though, so you don't need the hack anymore.  You only need to
> allow arch dependent binaries in noarch packages.  Also, please install
> the binaries in /usr/share, not /usr/lib.

If it is just backwards compat, how about we kill the -bin RPM now
to make it clearer to understand

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: seabios / seabios-bin split in Fedora - why?

2019-08-08 Thread Richard W.M. Jones 

Thanks everyone.  I've made some changes which were suggested and have
filed a package review.  Let's continue discussion on the BZ:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

2019-08-08 Thread Owen Taylor 
Recently filed bugs about similar issues:

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

Not sure if they are the *same* problem or different problems. They
look like the same issue (cursor only visible over application
windows) - but one reporter claims is started with a kernel upgrade,
and the other reporter reports an associated shell backtrace in their
log. And while a kernel upgrade could cause this (some problem with
overlays in the intel driver, perhaps), or the backtrace could
potentially cause this (shell is confused about what is an application
window and what is not), it's unexpected that a kernel upgrade would
cause the backtrace!

More information about a) whether that backtrace occurs for everybody
who is seeing the problem b) whether it was associated with a kernel
upgrade, and whether downgrading to an older kernel helps would
definitely be useful!

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

Re: Could not execute clone: [Errno 2] No such file or directory: '/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'

2019-08-08 Thread Mattias Ellert 
ons 2019-08-07 klockan 08:30 +0200 skrev Lubomír Sedlář:

> On my machine git creates the file on any clone. How did you manage to
> configure it to not do so?
> That being said, it's still a bug and should be fixed.

You can prevent fedpkg from adding patterns to the exclude file by
adding the following to your ~/.config/rpkg/fedpkg.conf 

[fedpkg]
git_excludes =

Mattias



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Sundials2 on EPEL7

2019-08-08 Thread Antonio Trande 
Hi all.

Please, can anyone explain to me why an EPEL7 branch for sundials2
cannot be created?

https://src.fedoraproject.org/rpms/sundials2/branches?branchname=master
https://pagure.io/releng/fedora-scm-requests/issue/14973

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

2019-08-08 Thread Tobias Guggenmos 
> * Stephen Gallagher:
> 
> 
> Can we make this happen at the RPM level?  So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)?  I do not see many explicit dependencies on
> anything “x86_64” in Fedora 30, so perhaps this is doable, assuming that
> packages of the other architecture would continue to provide …(…)(64bit)
> for soname dependencies.
> 
> Could we rebuild x86_64 Fedora with a different dist tag and different
> compiler flags, and release that as a new spin?  And retain the x86_64
> for that architecture?
> 
> Regarding doing something like the old i686 packages when we had an i586
> baseline (or the ppc64p7 work that was perhaps never upstreamed to
> Fedora), I'm a bit worried about increasing the complexity of composes.
> We already see upgrade issues doe to i686 packages come and go, and that
> could potentially multiply them.  The advantage is that packaging
> changes themselves will be relatively minor, once we have agreemeent
> which packages should do this.
> 
> ELF multilib DSOs inside RPMs result in code deduplication, affecting
> container image size.  Packaging changes are *not* minor for this
> approach.  It can be tricky to ensure full testing coverage if both DSOs
> are installed.  Currently, there is no dynamic loader support for
> selecting an AVX2 baseline.  Fixing this requires complete agreement
> among all involved parties what the actual CPU requirements are
> (currently, not even glibc and GCC agree what “haswell” means, the
> closest we have to an AVX2 baseline).  But similar fixes are required
> for any baseline update.
> 
> Thanks,
> Florian
> * Stephen Gallagher:
> 
> 
> Can we make this happen at the RPM level?  So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)?  I do not see many explicit dependencies on
> anything “x86_64” in Fedora 30, so perhaps this is doable, assuming that
> packages of the other architecture would continue to provide …(…)(64bit)
> for soname dependencies.
> 
> Could we rebuild x86_64 Fedora with a different dist tag and different
> compiler flags, and release that as a new spin?  And retain the x86_64
> for that architecture?
> 
> Regarding doing something like the old i686 packages when we had an i586
> baseline (or the ppc64p7 work that was perhaps never upstreamed to
> Fedora), I'm a bit worried about increasing the complexity of composes.
> We already see upgrade issues doe to i686 packages come and go, and that
> could potentially multiply them.  The advantage is that packaging
> changes themselves will be relatively minor, once we have agreemeent
> which packages should do this.
> 
> ELF multilib DSOs inside RPMs result in code deduplication, affecting
> container image size.  Packaging changes are *not* minor for this
> approach.  It can be tricky to ensure full testing coverage if both DSOs
> are installed.  Currently, there is no dynamic loader support for
> selecting an AVX2 baseline.  Fixing this requires complete agreement
> among all involved parties what the actual CPU requirements are
> (currently, not even glibc and GCC agree what “haswell” means, the
> closest we have to an AVX2 baseline).  But similar fixes are required
> for any baseline update.
> 
> Thanks,
> Florian


Something like this sounds like a good idea to me. 

Would it be possible to work this out into a standardized way to provide 
support for multiple ISA levels, e.g. avx, avx2, avx512 or whatever might come 
up in the future? That way fedora could stay up to date with recent cpu 
developments without regularly having discussions like this one.

Instead of providing multiple x86_64 spins, where each user has to figure out 
on their own which one to use, it might be better to only deliver installers 
with the baseline and let them figure out the right optimized packages at 
install time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

2019-08-08 Thread Michael Cronenworth 
On Aug 8, 2019 10:57 AM, bugzi...@redhat.com wrote:https://bugzilla.redhat.com/show_bug.cgi?id=1675390



Fedora Release Engineering  changed:



   What    |Removed |Added



 Status|ASSIGNED    |CLOSED

 Resolution|--- |EOL

    Last Closed|    |2019-08-08 15:57:42







--- Comment #12 from Fedora Release Engineering  ---

The package was retired.
The retire script has a bug. This package should not have been retired.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

2019-08-08 Thread Antonio M 
I am the reporter of bug https://bugzilla.redhat.com/show_bug.cgi?id=1738614
I have never such an issue before kernels 5..2.x and it is not always true
that clicking on notation bar solves the issue





Antonio Montagnani

Linux Fedora 30 Workstation
da/from Gmail


Il giorno gio 8 ago 2019 alle ore 19:10 Owen Taylor  ha
scritto:

> Recently filed bugs about similar issues:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1738614
> https://bugzilla.redhat.com/show_bug.cgi?id=1739169
>
> Not sure if they are the *same* problem or different problems. They
> look like the same issue (cursor only visible over application
> windows) - but one reporter claims is started with a kernel upgrade,
> and the other reporter reports an associated shell backtrace in their
> log. And while a kernel upgrade could cause this (some problem with
> overlays in the intel driver, perhaps), or the backtrace could
> potentially cause this (shell is confused about what is an application
> window and what is not), it's unexpected that a kernel upgrade would
> cause the backtrace!
>
> More information about a) whether that backtrace occurs for everybody
> who is seeing the problem b) whether it was associated with a kernel
> upgrade, and whether downgrading to an older kernel helps would
> definitely be useful!
>
> Owen
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Sundials2 on EPEL7

2019-08-08 Thread Robert-André Mauchin 
On Thursday, 8 August 2019 19:11:32 CEST Antonio Trande wrote:
> Hi all.
> 
> Please, can anyone explain to me why an EPEL7 branch for sundials2
> cannot be created?
> 
> https://src.fedoraproject.org/rpms/sundials2/branches?branchname=master
> https://pagure.io/releng/fedora-scm-requests/issue/14973
It's a bug with the script they are using to create the branch I think.

The branch exists in PDC: 
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=sundials2

The branch has not been created in dist-git, but you can create it manually 
and it should work:

git checkout -b epel7
git push --set-upstream origin epel7


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

Re: Sundials2 on EPEL7

2019-08-08 Thread Antonio Trande 
Thank you Robert.

On 08/08/19 20:45, Robert-André Mauchin wrote:
> On Thursday, 8 August 2019 19:11:32 CEST Antonio Trande wrote:
>> Hi all.
>>
>> Please, can anyone explain to me why an EPEL7 branch for sundials2
>> cannot be created?
>>
>> https://src.fedoraproject.org/rpms/sundials2/branches?branchname=master
>> https://pagure.io/releng/fedora-scm-requests/issue/14973
> It's a bug with the script they are using to create the branch I think.
> 
> The branch exists in PDC: 
> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=sundials2
> 
> The branch has not been created in dist-git, but you can create it manually 
> and it should work:
> 
> git checkout -b epel7
> git push --set-upstream origin epel7
> 
> 


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

2019-08-08 Thread Owen Taylor 
On Thu, Aug 8, 2019 at 2:34 PM Antonio M 
wrote:

> I am the reporter of bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1738614
> I have never such an issue before kernels 5..2.x and it is not always true
> that clicking on notation bar solves the issue
>

Do you think you could try downgrading your system to an older kernel? If
that fixes the issue, that woudl make it clear that it's not some other
package that was coincidentally upgraded at the same time as the kernel.

Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

2019-08-08 Thread Antonio M 
confirmed that running on 5.1.20-300 this issue is not present
Antonio Montagnani

Linux Fedora 30 Workstation
da/from Gmail


Il giorno gio 8 ago 2019 alle ore 21:43 Owen Taylor  ha
scritto:

> On Thu, Aug 8, 2019 at 2:34 PM Antonio M 
> wrote:
>
>> I am the reporter of bug
>> https://bugzilla.redhat.com/show_bug.cgi?id=1738614
>> I have never such an issue before kernels 5..2.x and it is not always
>> true that clicking on notation bar solves the issue
>>
>
> Do you think you could try downgrading your system to an older kernel? If
> that fixes the issue, that woudl make it clear that it's not some other
> package that was coincidentally upgraded at the same time as the kernel.
>
> Thanks!
> Owen
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Xorg 1.20.4-7.el7

2019-08-08 Thread Bojan Smojver via devel 
Just tried building a scratch build of xorgxrdp, but this still pulls in the 
old Xorg, before RHEL 7.7 version. Could someone please change that, so that 
builds pick the latest package up.

All in relation to:

https://bugzilla.redhat.com/show_bug.cgi?id=1738669 
id="-x-evo-selection-start-marker">

Thanks,
-- 
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

2019-08-08 Thread Miro Hrončok 

On 08. 08. 19 19:23, Michael Cronenworth wrote:


On Aug 8, 2019 10:57 AM, bugzi...@redhat.com wrote:

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

Fedora Release Engineering  changed:

    What    |Removed |Added

  Status|ASSIGNED    |CLOSED
  Resolution|--- |EOL
     Last Closed|    |2019-08-08 15:57:42



--- Comment #12 from Fedora Release Engineering  
---
The package was retired.


The retire script has a bug. This package should not have been retired.


What's the bug? Why should have it not been retired exactly? It didn't build 
since Fedora 26.



--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: I wish to drop python2-Cython

2019-08-08 Thread Mikolaj Izdebski 
On Tue, Aug 6, 2019 at 3:23 PM Fabio Valentini  wrote:
> On Tue, Aug 6, 2019, 15:17 Miro Hrončok  wrote:
>> > On Tue, 6 Aug 2019 at 13:11, Miro Hrončok > > > wrote:
>> > On 06. 08. 19 14:07, Mat Booth wrote:
>> > Eclipse will be shipping in modules only from F31.
>
>
> If that's the case, do you plan to retire the packages in non-modular 
> branches? Right now, they're all broken, and "pollute" dependency queries 
> (this also affects the Stewardship SIG).

We can't retire Eclipse packages as others depend on them. But after
the recent mass-retirement of packages Eclipse packages are FTBFS [1]
in rawhide and will be retired by releng, unless someone fixes them
before Fedora 32 branching.

[1] https://apps.fedoraproject.org/koschei/groups/eclipse?collection=f31

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

gettext retired, rawhide broken

2019-08-08 Thread Fabio Valentini 
Can somebody please unretire and fix gettext? It was just automatically
retired because it didn't build successfully since fedora 29. And now the
world is broken.

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