Re: F29 hidden GRUB, problem testing and how to unhide

2018-09-17 Thread Vít Ondruch 
F8 and Esc should work. The change page [1] mentions also holding shift.
It also mentions "sudo grub2-editenv - unset menu_auto_hide".


But it is interesting that:

1. it does not work

2. it does not unhide itself after failed boot.

Both sounds as a bugs to me.


V.


[1] https://fedoraproject.org/wiki/Changes/HiddenGrubMenu



Dne 18.9.2018 v 01:12 Chris Murphy napsal(a):
> I've got a Fedora 29 Silverblue installation in a VM. First boot I see
> the GRUB menu, and after that it's hidden. And I can't figure out how
> to unhide it. Boot is failing before I get multiuser login or ssh, so
> extracting information to troubleshoot/bug report isn't possible.
>
> Repeatedly pressing or holding Esc doesn't work.
> Spacebar doesn't work.
> F8 doesn't work.
>
> So now I'm stuck. Yeah, I can reinstall, and before rebooting make
> sure whatever is hiding the GRUB menu is disabled, every time I do
> installations. But the very reason why people were so vocal about this
> feature not happening is exactly this use case.
>
> This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
> Workstation as well) as guest. Virt-manager is what I'm using for
> interacting with the VM.
>
___
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-20180917.n.0 compose check report

2018-09-17 Thread Fedora compose checker 
No missing expected images.

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

ID: 281610  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/281610
ID: 281626  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/281626
ID: 281629  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/281629
ID: 281632  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/281632

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

ID: 281594  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/281594
ID: 281595  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/281595
ID: 281619  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/281619
ID: 281657  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/281657
ID: 281673  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/281673
ID: 281705  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/281705

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

Skipped openQA tests: 1 of 158
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 compose report: 20180917.n.0 changes

2018-09-17 Thread Fedora Branched Report 
OLD: Fedora-29-20180916.n.0
NEW: Fedora-29-20180917.n.0

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

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

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

= ADDED IMAGES =
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-29-20180917.n.0.x86_64.vagrant-libvirt.box
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-29-20180917.n.0.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-29-20180917.n.0.x86_64.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-29-20180916.n.0.s390x.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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

F29 hidden GRUB, problem testing and how to unhide

2018-09-17 Thread Chris Murphy 
I've got a Fedora 29 Silverblue installation in a VM. First boot I see
the GRUB menu, and after that it's hidden. And I can't figure out how
to unhide it. Boot is failing before I get multiuser login or ssh, so
extracting information to troubleshoot/bug report isn't possible.

Repeatedly pressing or holding Esc doesn't work.
Spacebar doesn't work.
F8 doesn't work.

So now I'm stuck. Yeah, I can reinstall, and before rebooting make
sure whatever is hiding the GRUB menu is disabled, every time I do
installations. But the very reason why people were so vocal about this
feature not happening is exactly this use case.

This is a Fedora 29 host. Fedora 29 (silverblue, maybe it happens with
Workstation as well) as guest. Virt-manager is what I'm using for
interacting with the VM.

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

mpi/fortran with -Wl,--as-needed

2018-09-17 Thread Jeandet Alexis 
Hi,

I saw that -Wl,--as-needed would be enabled by default on Fedora 29, it
seems that we can't build a simple fortran program with this flag
either on Fedora 28 or 29 with openmpi at least.
Is this an MPI bug? Is this flag supposed to work in this context?
Any help here would be really welcome:
https://github.com/mesonbuild/meson/pull/4194

best regards,
Alexis.
___
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 Atomic Host Two Week Release Announcement: 28.20180917.0

2018-09-17 Thread noreply 

A new Fedora Atomic Host update is available via an OSTree update:

Version: 28.20180917.0
Commit(x86_64): 17b11d74047ded1264a57555a64ae6fc5d02a332c556679bfcf32864fc91f11e
Commit(aarch64): 
95cdc6d02ed7f3645bdd513b07b2c2db9b04e91d8aae897fa88e378285a2b551
Commit(ppc64le): 
ca3012e5792f84499783510e5586526b9eaf8d98f535e3de0157ec7f7ad369ae


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180917.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180917.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-28-20180917.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180917.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180917.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-28-20180917.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180917.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180917.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180917.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180917.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-28-20180917.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180917.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-28-20180917.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180917.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-28-20180917.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180917.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-28-updates-20180917.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-28-20180917.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam

Re: Heads Up: python2 is marked as deprecated

2018-09-17 Thread Gerald B. Cox 
On Sun, Sep 16, 2018 at 4:12 PM Kevin Kofler  wrote:

> We CANNOT just drop half of the distribution just because upstream
> arbitrarily decided to desupport its widely used language interpreter in
> favor of an incompatible new major version.
>

Well, to be fair the writing has been on the wall for Python ever since the
release of 3.0 in 2008.  With the sunset date
of 2020 we're talking 12 years.  Ultimately, it's the responsibility of
upstream to do the migration.  It's not like they haven't had
plenty of notice.  If upstream no longer cares, it's not practical for
Fedora to accept the ongoing maintenance for these packages.
That's just not realistic nor sustainable.
___
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: Proposal to modify release criteria for fwraid

2018-09-17 Thread Chris Murphy 
On Mon, Sep 17, 2018 at 9:56 AM, Adam Williamson
 wrote:
> On Mon, 2018-09-17 at 17:25 +0200, Kamil Paral wrote:
>> On Mon, Sep 17, 2018 at 2:45 PM Stephen Gallagher 
>> wrote:
>>
>> > On Mon, Sep 17, 2018 at 5:16 AM Petr Šabata  wrote:
>> >
>> > > I hope this won't just mean we discover the problems later, in practice.
>> >
>> > The policy of Fedora QA is to run all of the GA-blocking tests at Beta as
>> > well.
>> >
>>
>> My goal has always been to run all Final testcases with the publicly
>> released Beta image as soon as possible. I don't think we're too successful
>> at running all Final testcases with pre-Beta images or Beta RCs. I'm not
>> aware of any policy per say. But we certainly try.
>
> I've been saying for a long time that we ought to be doing that, and
> it's why we started doing validation events for nightly composes
> throughout the cycle (instead of starting shortly before Alpha as we
> used to). I definitely would like us to be running the validation tests
> a long time before Beta freeze.

Maybe there needs to be a milestone for it? Something like alpha in
terms of the timing, but non-blocking since there's no release
specific to this hypothetical milestone, but does give you the
resources to plan for and implement it.


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

Re: Am I allowed to package this?

2018-09-17 Thread Simo Sorce 
On Sun, 2018-09-16 at 10:17 +0200, Hans de Goede wrote:
> Hi,
> 
> On 14-09-18 20:03, Simo Sorce wrote:
> > On Fri, 2018-09-14 at 19:37 +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 09/13/2018 07:59 PM, Simo Sorce wrote:
> > > > On Thu, 2018-09-13 at 16:07 +0200, Hans de Goede wrote:
> > > > > Hi,
> > > > > 
> > > > > On 10-09-18 14:40, Abhiram Kuchibhotla wrote:
> > > > > > According to the LICENSE file in their git repo, the code in the 
> > > > > > repo seems to be gplv2. Not sure if that proves anything. I'll do 
> > > > > > the licensecheck -r later and update you guys.
> > > > > > 
> > > > > > On Mon 10 Sep, 2018, 6:08 PM Richard Shaw,  > > > > > > wrote:
> > > > > > 
> > > > > >   On Mon, Sep 10, 2018 at 7:27 AM Rex Dieter 
> > > > > > mailto:rdie...@math.unl.edu>> wrote:
> > > > > > 
> > > > > >   Jan Rybar wrote:
> > > > > > 
> > > > > >> Hi Abhiram,
> > > > > >>
> > > > > >> you can make COPR. No one asks, no harm done, 
> > > > > > everyone's happy.
> > > > > > 
> > > > > >   I don't think copr is appropriate either,
> > > > > >   
> > > > > > https://docs.pagure.org/copr.copr/user_documentation.html#faq
> > > > > > 
> > > > > >   To me, makes it pretty clear that if it can't be in 
> > > > > > fedora, it can't be in
> > > > > >   copr either.
> > > > > > 
> > > > > > 
> > > > > >   You need to go through the code (maybe use licensecheck -r to 
> > > > > > help) to see if all the code is acceptable. If so I'll defer to 
> > > > > > Neal on the COPR acceptability. Another alternative is until formal 
> > > > > > support is added to the kernel you can look at packaging it in RPM 
> > > > > > Fusion. If it's truly FOSS but just not acceptable because it's a 
> > > > > > kernel module it can go in the Free repository. If it's using 
> > > > > > proprietary code (even if the project is GPL licensed) then as long 
> > > > > > as it's redistributable, it can go in the Non-Free repository.
> > > > > 
> > > > > 
> > > > > This looks like a standard realtek driver which realtek creates for 
> > > > > Android devices
> > > > > or some such. The code is not pretty (I really wish realtek would 
> > > > > start contributing
> > > > > proper drivers to the mainline kernel) but it usually is all GPL 
> > > > > licensed, except
> > > > > for the firmware for the NIC. I don't see firmware in the git repo, 
> > > > > so the code
> > > > > may need to be adjusted to use the kernels firmware-load mechanism (I 
> > > > > assume
> > > > > it has the firmware embedded atm).
> > > > > 
> > > > > The firmware files themselves may be distributed under this license:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.rtlwifi_firmware.txt
> > > > > 
> > > > > Note I did not check the files in the git repo, I just took a quick 
> > > > > peek
> > > > > that it is a "standard" out of tree realtek driver.
> > > > > 
> > > > > Also IANAL and TINLA.
> > > > 
> > > > I also have to use this driver for a USB dongle that works very well
> > > > ... when I remember to check dkms didn't fail to build on kernel
> > > > upgrade ...
> > > > 
> > > > There is no firmware needed apparently, but my dongle doesn't work with
> > > > driver 5.2 which is the latest, so maybe a firmware is needed but the
> > > > driver itself doesn't load it ?
> > > > 
> > > > It would be really nice to have this driver in the kernel though as a
> > > > huge amount of cheap dongles use this chipset family, what would be the
> > > > process to get it in ?
> > > 
> > > You can submit it for inclusion into drivers/staging, there are already
> > > some realtek drivers for other chipsets there for similar reasons.
> > > 
> > > Real inclusion would require a complete rewrite of the driver mostly.
> > 
> > Sigh, and I guess there is no party (beyond Realtek) with enough
> > interest/time to do that ...
> 
> Well for some older chips Jes Sorensen did a new driver from scratch using
> the GPL-ed Realtek code as hardware documentation, so it is possible for
> a community member to do this if it itches hard enough for them.
> 
> You could reach out the Jes and ask him how much work this was and if
> he perhaps can write a blog post or 2 (or 3) to summarize his experience
> with this.

Thanks I'll ask him.

Simo.

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

Re: Proposal to modify release criteria for fwraid

2018-09-17 Thread Adam Williamson 
On Mon, 2018-09-17 at 08:56 -0700, Adam Williamson wrote:
> On Mon, 2018-09-17 at 17:25 +0200, Kamil Paral wrote:
> > On Mon, Sep 17, 2018 at 2:45 PM Stephen Gallagher 
> > wrote:
> > 
> > > On Mon, Sep 17, 2018 at 5:16 AM Petr Šabata  wrote:
> > > 
> > > > I hope this won't just mean we discover the problems later, in practice.
> > > 
> > > The policy of Fedora QA is to run all of the GA-blocking tests at Beta as
> > > well.
> > > 
> > 
> > My goal has always been to run all Final testcases with the publicly
> > released Beta image as soon as possible. I don't think we're too successful
> > at running all Final testcases with pre-Beta images or Beta RCs. I'm not
> > aware of any policy per say. But we certainly try.
> 
> I've been saying for a long time that we ought to be doing that, and
> it's why we started doing validation events for nightly composes
> throughout the cycle (instead of starting shortly before Alpha as we
> used to). I definitely would like us to be running the validation tests
> a long time before Beta freeze.

Sorry, though to clarify a bit more: we *aim* to run as many of the
tests as possible, as early as possible. But it's an aspirational
thing. We don't *commit* to having the Final tests run by Beta.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Build ID conflict?!?

2018-09-17 Thread Richard Shaw 
On Mon, Sep 17, 2018 at 8:27 AM Richard Shaw  wrote:

> On Sun, Sep 16, 2018 at 5:10 PM Jerry James  wrote:
>
>> On Sun, Sep 16, 2018 at 3:02 PM Richard Shaw 
>> wrote:
>> > Working on a new package and tried to install it only to get:
>> >
>> > Error: Transaction check error:
>> >   file /usr/lib/.build-id/67/7d4bdbbde390cc49fddb539cceb06ccb80efd6
>> from install of ft8call-0.6.4-1.fc28.x86_64 conflicts with file from
>> package hamlib-3.2-1.fc28.x86_64
>> >   file /usr/lib/.build-id/dc/0fdb3cc1c3d70f4eee314404d00591091eb879
>> from install of ft8call-0.6.4-1.fc28.x86_64 conflicts with file from
>> package hamlib-3.2-1.fc28.x86_64
>> >
>> > It does build against hamlib...
>>
>> That probably means that ft8call copied a library or binary from
>> hamlib.  Check your ft8call buildroot for a duplicate with hamlib
>>
>
> Didn't see anything looking through build.log... Built it mock so I COULD
> shell in to inspect manually but is there a way to tell which files are
> affected?
>

To answer my own question since I had never browsed the build-id directory
before, it's just a lot of symlinks to the actual binary or library. The
ft8call package renames the ones that conflict with hamlib but they seem to
generate the same hash anyway...

They are duplicate and not needed to I just patched the build system to not
install them.

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

Re: Proposal to modify release criteria for fwraid

2018-09-17 Thread Adam Williamson 
On Mon, 2018-09-17 at 17:25 +0200, Kamil Paral wrote:
> On Mon, Sep 17, 2018 at 2:45 PM Stephen Gallagher 
> wrote:
> 
> > On Mon, Sep 17, 2018 at 5:16 AM Petr Šabata  wrote:
> > 
> > > I hope this won't just mean we discover the problems later, in practice.
> > 
> > The policy of Fedora QA is to run all of the GA-blocking tests at Beta as
> > well.
> > 
> 
> My goal has always been to run all Final testcases with the publicly
> released Beta image as soon as possible. I don't think we're too successful
> at running all Final testcases with pre-Beta images or Beta RCs. I'm not
> aware of any policy per say. But we certainly try.

I've been saying for a long time that we ought to be doing that, and
it's why we started doing validation events for nightly composes
throughout the cycle (instead of starting shortly before Alpha as we
used to). I definitely would like us to be running the validation tests
a long time before Beta freeze.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to modify release criteria for fwraid

2018-09-17 Thread Kamil Paral 
On Mon, Sep 17, 2018 at 2:45 PM Stephen Gallagher 
wrote:

> On Mon, Sep 17, 2018 at 5:16 AM Petr Šabata  wrote:
>
> >
> > I hope this won't just mean we discover the problems later, in practice.
>
>
> The policy of Fedora QA is to run all of the GA-blocking tests at Beta as
> well.
>

My goal has always been to run all Final testcases with the publicly
released Beta image as soon as possible. I don't think we're too successful
at running all Final testcases with pre-Beta images or Beta RCs. I'm not
aware of any policy per say. But we certainly try.
___
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: Schedule for Monday's FESCo Meeting (2018-09-17)

2018-09-17 Thread Stephen Gallagher 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

=
#fedora-meeting-1: FESCO (2018-09-17)
=


Meeting started by sgallagh at 15:00:06 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-17/fesco.2018-09-17-15.00.log.html
.



Meeting summary
- ---
* init process  (sgallagh, 15:00:06)

* #1989 Decide status of "Rename Atomic Workstation to Silverblue"
  change  (sgallagh, 15:02:20)
  * LINK: https://pagure.io/fedora-websites/pull-request/864   (nirik,
15:09:02)
  * AGREED: We acknowledge that the change is partially implemented and
users might see the old name is various places, but what was already
done cannot be reverted meaningfully. If the silverblue team
proposes any further changes before GA that need exceptions from the
general policy, they will be reviewed on a case-by-case basis.
Likewise, if there are any problems, they will be reviewed on a
case-by-case basis. (+7,  (sgallagh, 15:21:18)
  * FESCo would like the websites team to make sure the page is accurate
before release.  (zbyszek, 15:21:50)

* Next week's chair  (sgallagh, 15:22:30)
  * ACTION: zbyszek to chair the next meeting on 2018-09-24  (sgallagh,
15:23:00)

* Open Floor  (sgallagh, 15:25:47)
  * zbyszek is moving forward with the docs improvements  (sgallagh,
15:28:06)

Meeting ended at 15:30:40 UTC.




Action Items
- 
* zbyszek to chair the next meeting on 2018-09-24




Action Items, by person
- ---
* zbyszek
  * zbyszek to chair the next meeting on 2018-09-24
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (52)
* nirik (26)
* bowlofeggs (21)
* zodbot (18)
* zbyszek (15)
* contyk (9)
* jsmith (8)
* jforbes (6)
* maxamillion (4)
* bcotton (1)
* tyll (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-
Version: Mailvelope v2.2.2
Comment: https://www.mailvelope.com

wkYEAREIABAFAlufyMwJEHolVWI2uqOjAABDwACdEgzAZWaxTIzLkavIgTJD
6ctzv5cAmwcNHkSAed+/cSmzm5Ar+H3d6pFL
=1cu7
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What does 141 mean?

2018-09-17 Thread Björn Persson 
Tony Nelson wrote:
> No, but googling "kinit 141" leads to
> https://bugzilla.redhat.com/show_bug.cgi?id=1537866
> which suggests trying the kinit command twice in a row.

I would think I must have tried at least twice the first time I had
this problem, but at least that thread gives me some ideas for things
to experiment with after the tickets I currently have have expired.

Björn Persson


pgp2IafzJF_OC.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What does 141 mean?

2018-09-17 Thread Björn Persson 
Jan Pazdziora wrote:
> Can you check the current time on the problematic machine? Is it in
> sync?

It looks pretty well synced I think:

chronyc> sources
210 Number of sources = 18
MS Name/IP address Stratum Poll Reach LastRx Last sample   
===
^- hactar.xn--rombobjrn-67a> 2   6   37740  +1029us[+1029us] +/-   71ms
^- hactar.xn--rombobjrn-67a> 2   6   37711  +1032us[+1032us] +/-   71ms
^- ntp3.flashdance.cx2  10   377  1027   -848us[ -820us] +/-   40ms
^+ kyra.desire.se2  10   377  1002  -1924us[-1896us] +/-   23ms
^+ core.ingressistance.se2  10   377   500  -1564us[-1534us] +/-   20ms
^- ntp-b.0x5e.se 2  10   377   511  -1497us[-1466us] +/-   58ms
^- ns2.posiona.net   2  10   377   154  +1101us[+1101us] +/-   56ms
^- server-185-103-110-248.c> 2  10   377   383  -1007us[-1007us] +/-   62ms
^+ time3.dnaip.fi1  10   37757   +358us[ +358us] +/-   18ms
^- helsinki.fdw.no   2  10   377  1000  -1045us[-1016us] +/-   52ms
^- preben.vps.itpays.cloud   2  10   377   262  -4091us[-4091us] +/-   43ms
^- time.dynet.no 2   9   377 6   +549us[ +549us] +/-   51ms
^- ntp-ext.cosng.net 2  10   377   750   +598us[ +627us] +/-   62ms
^- takk.signal.no2  10   377   786  +2210us[+2240us] +/-   69ms
^* time100.stupi.se  1  10   377   501   -207us[ -176us] +/-   12ms
^+ static-5-103-128-88.ip.f> 1  10   377   305  +7123us[+7123us] +/-   25ms
^- 85.129.0.126  2  10   377   518  -2605us[-2574us] +/-   44ms
^+ 78.156.103.10 2  10   177   101  +7132us[+7132us] +/-   29ms

Björn Persson


pgpYZTboD07Bw.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://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: Build ID conflict?!?

2018-09-17 Thread Richard Shaw 
On Sun, Sep 16, 2018 at 5:10 PM Jerry James  wrote:

> On Sun, Sep 16, 2018 at 3:02 PM Richard Shaw  wrote:
> > Working on a new package and tried to install it only to get:
> >
> > Error: Transaction check error:
> >   file /usr/lib/.build-id/67/7d4bdbbde390cc49fddb539cceb06ccb80efd6 from
> install of ft8call-0.6.4-1.fc28.x86_64 conflicts with file from package
> hamlib-3.2-1.fc28.x86_64
> >   file /usr/lib/.build-id/dc/0fdb3cc1c3d70f4eee314404d00591091eb879 from
> install of ft8call-0.6.4-1.fc28.x86_64 conflicts with file from package
> hamlib-3.2-1.fc28.x86_64
> >
> > It does build against hamlib...
>
> That probably means that ft8call copied a library or binary from
> hamlib.  Check your ft8call buildroot for a duplicate with hamlib
>

Didn't see anything looking through build.log... Built it mock so I COULD
shell in to inspect manually but is there a way to tell which files are
affected?

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

[Guidelines change] Changes to the packaging guidelines

2018-09-17 Thread Jason L Tibbitts III 
Here are the recent changes to the packaging guidelines.

-

The Python packaging guidelines have been updated to reflect the fact
that Python 2 is deprecated.  All relevant information for legacy Python
2 packaging has been moved to the appendix.  Together with this change,
the rule for naming the executables if both Python versions are shipped
has been changed: "The unversioned executable should be the python3
version, unless it would break users expectations, in that case it may
be the python2 version." Examples of that are provided in the appendix.

* https://fedoraproject.org/wiki/Packaging:Python
* https://fedoraproject.org/wiki/Packaging:Python_Appendix
* https://pagure.io/packaging-committee/issue/793

-

The python guidelines were modified to indicate that packagers should
not simply glob all files and directories under the sitelib and sitearch
directories.  Other small changes were made to avoid conflicting with
this requirement.

* https://fedoraproject.org/wiki/Packaging:Python#Files_to_include
* https://pagure.io/packaging-committee/issue/782

-

A section covering the new automatic dependency generator was added to
the Python guidelines.

* 
https://fedoraproject.org/wiki/Packaging:Python#Automatically_generated_dependencies
* https://pagure.io/packaging-committee/issue/740

-

A new guidelines page was added, providing a place to discuss what is
and is not allowed in Fedora. A number of sections were moved there from
the main guidelines, and a new section was added indicating that only a
single kernel package is allowed in the distribution.

* https://fedoraproject.org/wiki/Packaging:What_Can_Be_Packaged
* https://pagure.io/packaging-committee/issue/792

-

Small cleanups were made to the crypto policies guidelines to modernize
them a bit, and a new section was added requiring that newly added
crypto libraries must comply with existing crypto policies.

* https://fedoraproject.org/wiki/Packaging:CryptoPolicies
* https://pagure.io/packaging-committee/issue/785

-

The section on file and directory dependencies has been rewritten to be
clearer and to explicitly indicate which file dependencies are
permissible and which are not.

* 
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Dependencies
* https://pagure.io/packaging-committee/issue/714

-
___
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: Proposal to modify release criteria for fwraid

2018-09-17 Thread Stephen Gallagher 
On Mon, Sep 17, 2018 at 5:16 AM Petr Šabata  wrote:
>
> On Fri, Sep 14, 2018 at 10:22:12AM -0400, Stephen Gallagher wrote:
> > At yesterday's F29 Go/No-Go meeting, we discussed the blocker status
> > of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID
> > device. While the blocker criteria clearly states that this should be
> > a blocker for Beta, many of the people present at the meeting
> > disagreed, for a variety of reasons.
> >
> > * Hardware supporting fwraid is considerably less pervasive than it
> > was when the criterion was written
> >
> > * Testing this criterion can only be done with install media, which
> > limits our testing pool to the very dedicated members of Fedora QA.
> > Yes, anyone *can* download a nightly compose and try it, but in
> > practice this tends to be limited to the core testers. The majority of
> > testing that this feature will get will tend to happen as people try
> > out the Beta release.
> >
> > To that end, I'd like to propose that we make the following change to
> > the criteria going forward:
> >
> > "The blocking criterion for successful installation atop a firmware
> > RAID array is moved to the GA release criteria."
>
> I hope this won't just mean we discover the problems later, in practice.


The policy of Fedora QA is to run all of the GA-blocking tests at Beta as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2018-09-17 Thread Stephen Gallagher 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

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

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


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

= Discussed and Voted in the Ticket =

allow untagging of stratis modules from rawhide
https://pagure.io/fesco/issue/1992
DECISION (+7, 0, -0)

F30 System-Wide Change: FreeIPA Python 2 Removal
https://pagure.io/fesco/issue/1991
DECISION (+7, 0, -0)


= Followups =

#topic #1989 Decide status of "Rename Atomic Workstation to Silverblue" change
https://pagure.io/fesco/issue/1989

= New business =


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

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

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

Re: Changes in packages workflow vs. modular Fedora

2018-09-17 Thread Miro Hrončok 

On 17.9.2018 12:36, Petr Šabata wrote:

On Thu, Sep 13, 2018 at 11:07:50PM +0200, Miro Hrončok wrote:

On 13.9.2018 22:44, Petr Šabata wrote:

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

Hi,

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


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


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


I really hope that's not the case :)


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


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


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


Noted.  I don't have any ETA at this point, though.


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


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


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


Not yet.  I think this is tied to the previous point.  They will
also need that archive or something similar.  Also noted.


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


This would be a new stream of the interpreter module.


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

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


Again the archive ;) We should be including stream-branched
SPEC files as well as currently included modulemds.


Not really here. Parsing specs is hard. We actually need a proper 
repoquery setup.


This is what we have now:

https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython#After_a_side_tag_merge


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


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


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


Same as above.


Same as above. Repoquery, not archive.




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


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


Thanks for looking into this.


We (Modularity WG) are thinking about new way of organizing &
tracking all these things (currently it's mostly just a shared
document).  We'll announce it once ready.


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


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


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


If you're okay with implementing the change in all supported
releases, that just makes it easier.  My point was that if you
change is only applicable to Rawhide, for instance, you should
conditionalize your edits, as modules are typically built for
all of them.


b) A CVE was filled for Django [2]. How does the security team

Re: Changes in packages workflow vs. modular Fedora

2018-09-17 Thread Petr Šabata 
On Thu, Sep 13, 2018 at 11:07:50PM +0200, Miro Hrončok wrote:
> On 13.9.2018 22:44, Petr Šabata wrote:
> > On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:
> > > Hi,
> > > 
> > > I was thinking about this for a while and I got the impression that this 
> > > is
> > > something I don't know the answer for. The question is a bit harder to
> > > formulate simply, so let put it in examples:
> > 
> > I see no one's really responded to this yet (ack!), so let me try...
> 
> Thank You! I was starting to feel like nobody cares.

I really hope that's not the case :)

> > > a) A need packaging guideline is about to be discussed. A member of FPC
> > > wants to know how many packages would be affected so they run a quick grep
> > > query over all the rawhide specfiles at [0].
> > 
> > Obviously this wouldn't be enough.  We would need to find all
> > modules shipped with Rawhide, then all the RPM stream branches
> > they build from, and grep those as well.  Perhaps we could
> > do something to generate archives that include all of this
> > automatically.
> 
> Please do, otherwise this would be tedious. There are archives with rawhide
> specs.

Noted.  I don't have any ETA at this point, though.

> > > b) A CVE is found in a web framework, so bugz are filled for the 
> > > "framewrok"
> > > package to be fixed in Fedora 27, because newer Fedoras have newer version
> > > of the framework where the CVE is not applicable.
> > 
> > Also valid.  Rather than just relying on the non-modular package
> > upgrade path, all currently supported modules and their RPMs
> > would need to be checked.
> 
> Is the Red Hat security response team aware of that? Do they file bugs for
> modules?

Not yet.  I think this is tied to the previous point.  They will
also need that archive or something similar.  Also noted.

> > > c) A new version of interpreted language lands in rawhide. All packages
> > > depending on the interpeter need mass rebuild in a side tag.
> > 
> > This would be a new stream of the interpreter module.
> 
> No interpreter module here. An interpreter that lives in non-modular Fedora,
> but various modules possibly use it. I have no idea what modules use it (if
> any) and I have no idea how to easily find out.
> 
> I know there is at least one module that uses non-modular Python 2. At least
> we won't rebase that Python to a newer version.

Again the archive ;) We should be including stream-branched
SPEC files as well as currently included modulemds.

> > > d) A packager decides to retire a library and they check nothing in Fedora
> > > requires it.
> > 
> > Similar to a) and b).  They need to check the currently supported
> > modules as well.
> 
> How? We are mass removing python2 packages from rawhide that nothing in
> rawhide depend on. Our automation has no clue about modules and if there are
> modules that use python2-... packages from nonmodular Fedora, we need to
> know.

Same as above.

> > > I wonder how are such situations meant to be handled with modules?
> > > Do we build modules for rawhide? If so, should Fedora changes (such as, 
> > > but
> > > not limited to, "the Changes") somehow handle all the modules, or is it 
> > > the
> > > modular maintainer responsibility to make sure their module works on the
> > > next Fedora version?
> > 
> > We're aware there are many gaps here.  I consider identifying &
> > resolving them a priority for the Modularity WG at the moment,
> > so thank you for contributing.
> 
> Thanks for looking into this.

We (Modularity WG) are thinking about new way of organizing &
tracking all these things (currently it's mostly just a shared
document).  We'll announce it once ready.

> > > a) I was planning to propose a more strict "No more automagic Python
> > > bytecompilation" [1] change for Fedora 30 where we would query all 
> > > packages
> > > that depend on the old behavior and mass add "%global
> > > _python_bytecompile_extra 1" to all of them, so we could switch the 
> > > default
> > > to be 0. Normally, we would do it in Rawhide only. But how do I handle
> > > modules? How do I find out what modular packages rely on the old behavior?
> > 
> > Modules typically build the same content in all contexts
> > (buildroots).  If that's a problem for this particular change
> > of yours, I think the proper way would be adding %{fedora}
> > conditionals around that macro definition.
> 
> No, I don't want to only add this thing if %fedora. Quite the opposite, I
> need to gather a list of packages that rely on the old behavior, so I can
> hotfix/workaround them with that line. See
> https://bugzilla.redhat.com/show_bug.cgi?id=1626685#c2 for what I did in the
> non-modular world to better understand what I mean.

If you're okay with implementing the change in all supported
releases, that just makes it easier.  My point was that if you
change is only applicable to Rawhide, for instance, you should
conditionalize your edits, as modules are typically built for
all of them.

> > > b) A

Re: Managing stream (arbitrary) branch and module lifecycles

2018-09-17 Thread Petr Šabata 
On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote:
> This is a summary of a recent thread [1].
> 
> Traditional branches (such as "f29") have their EOL (end of life) encoded
> in the name. But what about stream branches [2] (such as "2.4" or "latest")?
> 
> Stream branches of RPM packages would always have an EOL associated with
> them. The format would be on of the following:
> a) A date — mostly tied to an upstream version and its EOL.
> b) A specific Fedora release — for release-specific packages.
> c) Forever — rolling forward with upstream, latest development versions,
> etc.
> 
> Module streams would inherit their EOL from the packages they include — the
> earliest EOL would win. This could be optionally overridden on the module
> stream level by specifying one of the following:
> a) A date.
> b) A specific Fedora release.
> 
> There would be a policy that a module can reach its EOL in the middle of a
> Fedora release to prevent madness.
> 
> We need a way to specify the EOL value and to manage it over time, because
> it might change. For RPM stream branches, there is currently a way to
> specify an EOL value when requesting the branch [3] — the actual format
> might change based on this discussion. However, I'm not aware of a way to
> change the value if necessary nor a process associated with that. Also,
> there is currently no way to specify an EOL for modules.
> 
> After we figure this out, we also need to make sure the build system takes
> that into account (some recent progress [4]) and that the client tooling
> (mostly DNF) presents that to the user.
> 
> So... any comments to the concept? Any ideas about workflows or processes
> of managing the EOL values?

I went through both threads and thought I'd offer my point
of view.

From experience I can tell that defining the EOL, be it a module
or a package, is rather difficult.  Even in the rare case where
upstream is clear about their support plans, it doesn't mean we
have to follow that.  We might want to drop the package earlier,
or the opposite -- support it on our own long after it was
abandoned upstream.  I think both cases are somewhat common.
And we rarely, if ever, know this information at the branch
creation time.

So, a few things.

If we need to define these for something, I'd rather only do
it for modules rather than packages.  Not only to simplify
the process for everyone but also because I kinda feel that
the module maintainer is responsible for the packages they
include.  I have a hard time imagining packagers maintaining
stream branches "just in case someone wants to consume them".
They either maintain the module or only care about the release
branches.  Also if you have a module with 200 components and you
derive your module's EOL from the packages' EOLs, you need to be
constantly watching all your components and their "arbitrary"
EOL dates or risk your module being dropped.  I don't think
this is very user friendly.

I think the rolling model would be the most commonly chosen
option.  Basically "supported until I decide to kill it in
Rawhide".  We could then update existing stable modules with a
more specific date, such as the date when that release goes EOL.
Maintainers should still be able to choose a date ahead of
time if they wish but I'd rather not tie it to Fedora release
numbers as that doesn't work very well for EPEL.

Finally, I also don't see a point in really killing package
stream branches.  If someone is consuming these, they are
responsible.  If not, it doesn't matter that they exist.

Not sure how much sense this makes.

P

> [1] Previous thread:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/
> [2] Now "stream branches", formerly "arbitrary branches":
> https://fedoraproject.org/wiki/Changes/ArbitraryBranching
> [3] Requesting a stream branch + specifying its EOL:
> https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_repositories_and_stream_branches_existing_packages
> [4] https://pagure.io/modularity/issue/102
> 
> -- 
> 
> Adam Šamalík
> ---
> Software Engineer
> Red Hat

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



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

NoScript: dropping legacy version (for SeaMonkey et al.)

2018-09-17 Thread Dominik 'Rathann' Mierzejewski 
Dear list,
as mozilla-noscript maintainer I'm dropping the NPAPI/legacy version
of the add-on from the package. I've never actually used it with
SeaMonkey and I don't have any free time to test it. Upstream announced
a long time ago that it will be supported only until September 2018,
when Firefox ESR 52.x becomes EOL. That time has now come.

I'm adding Obsoletes: seamonkey-noscript < 5.1.8.7 in F29+ so that
it can still be resurrected (5.1.8.7 is the last version).

For F28 and older, including EPEL, I'm doing the final update
to 5.1.8.7 as it fixes a CVE.

If anyone wants to pick it up, please open a new Review Request
and assign to me.

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: Proposal to modify release criteria for fwraid

2018-09-17 Thread Petr Šabata 
On Fri, Sep 14, 2018 at 10:22:12AM -0400, Stephen Gallagher wrote:
> At yesterday's F29 Go/No-Go meeting, we discussed the blocker status
> of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID
> device. While the blocker criteria clearly states that this should be
> a blocker for Beta, many of the people present at the meeting
> disagreed, for a variety of reasons.
> 
> * Hardware supporting fwraid is considerably less pervasive than it
> was when the criterion was written
> 
> * Testing this criterion can only be done with install media, which
> limits our testing pool to the very dedicated members of Fedora QA.
> Yes, anyone *can* download a nightly compose and try it, but in
> practice this tends to be limited to the core testers. The majority of
> testing that this feature will get will tend to happen as people try
> out the Beta release.
> 
> To that end, I'd like to propose that we make the following change to
> the criteria going forward:
> 
> "The blocking criterion for successful installation atop a firmware
> RAID array is moved to the GA release criteria."

I hope this won't just mean we discover the problems later, in practice.
P


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

Re: What does 141 mean?

2018-09-17 Thread Jan Pazdziora 
On Sun, Sep 16, 2018 at 11:53:08PM +0200, Björn Persson wrote:
> I have a Kerberos authentication problem.
> 
> On one computer running Fedora 27, I run kinit to authenticate to the
> Fedora servers. After I enter my passphrase, kinit returns exit status
> 141. Then I run "fedpkg build", and get these error messages:
> 
> Kerberos authentication fails: (-1765328352, 'Ticket expired')
> Could not execute build: Could not login to 
> https://koji.fedoraproject.org/kojihub
> 
> On another computer also running Fedora 27, I run the exact same kinit
> command. After I enter my passphrase, kinit returns exit status 0. I can
> then run "fedpkg build" successfully.

Can you check the current time on the problematic machine? Is it in
sync?

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

Re: Possibly non-responsive maintainer: hguemar

2018-09-17 Thread Vít Ondruch 


Dne 17.9.2018 v 09:48 Haïkel napsal(a):
> Le lun. 17 sept. 2018 à 08:12, Mattia Verga  a écrit 
> :
>>> Le dim. 16 sept. 2018 à 11:27, Fabio Valentini >> a écrit :
>>>
>>>
>>> The policy mention that you have to try contacting the maintainer
>>> *first*, you never sent me an email or pinged me on irc.
>>> I don't like this kind of passive-aggressive approach, had you
>>> contacted me, we would have sorted this out quickly, co-maintainers
>>> are welcome.
>>>
>>> One more thing, when you want to contact someone in the project =>
>>> >>
>>> Regards,
>>> H.
>>>
>> Trying to contact the maintainer directly before opening the unresponsive 
>> maintainer policy and reply to bugs via email is right, BUT I would expect 
>> bugzilla to be the first contact point and so maintainers should respond in 
>> bugzilla first, not via email.
>>
>> Sometimes a "bug aknowledge, but it's in low priority list" message can keep 
>> users calm...
>>
>> Mattia
> (On the policy)
>
> Yes, first attempt should be through bugzilla, but we are human
> beings, so it happens that a direct ping is necessary.

Haïkel, you might be upset that somebody calls you "Possibly
non-responsive", but frankly, if the message from Fabio was
passive-aggressive to you, then I am not sure you did better job then he
did (especially in the "we are human beings" context).

Vít


> The policy may be subject to interpretation, but it hints that this
> process should be used when you *cannot* reach the maintainer.
> If you have time to mail the list, you have time to mail the person first.
>
> "and asks if anyone knows how to contact the maintainer." => It's
> crystal clear (to me at least) that it assumes that you could not
> reach the
> maintainer through the email registered in FAS (we used to have
> regular pings from the system to verify that users are still
> monitoring these).
>
> If you want access to a package that I happen to be a "Point of
> Contact" (which is semantically different that owner and it's on
> purpose), just ask.
> Nobody owns anything in Fedora.
>
> Regards,
> H.
>
>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Re: Possibly non-responsive maintainer: hguemar

2018-09-17 Thread Haïkel 
Le lun. 17 sept. 2018 à 08:12, Mattia Verga  a écrit :
>
> > Le dim. 16 sept. 2018 à 11:27, Fabio Valentini  > a écrit :
> >
> >
> > The policy mention that you have to try contacting the maintainer
> > *first*, you never sent me an email or pinged me on irc.
> > I don't like this kind of passive-aggressive approach, had you
> > contacted me, we would have sorted this out quickly, co-maintainers
> > are welcome.
> >
> > One more thing, when you want to contact someone in the project =>
> >  >
> > Regards,
> > H.
> >
>
> Trying to contact the maintainer directly before opening the unresponsive 
> maintainer policy and reply to bugs via email is right, BUT I would expect 
> bugzilla to be the first contact point and so maintainers should respond in 
> bugzilla first, not via email.
>
> Sometimes a "bug aknowledge, but it's in low priority list" message can keep 
> users calm...
>
> Mattia

(On the policy)

Yes, first attempt should be through bugzilla, but we are human
beings, so it happens that a direct ping is necessary.
The policy may be subject to interpretation, but it hints that this
process should be used when you *cannot* reach the maintainer.
If you have time to mail the list, you have time to mail the person first.

"and asks if anyone knows how to contact the maintainer." => It's
crystal clear (to me at least) that it assumes that you could not
reach the
maintainer through the email registered in FAS (we used to have
regular pings from the system to verify that users are still
monitoring these).

If you want access to a package that I happen to be a "Point of
Contact" (which is semantically different that owner and it's on
purpose), just ask.
Nobody owns anything in Fedora.

Regards,
H.


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

[Bug 1629605] New: perl-Code-TidyAll-0.71 is available

2018-09-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1629605

Bug ID: 1629605
   Summary: perl-Code-TidyAll-0.71 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Code-TidyAll
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-de...@lists.fedoraproject.org



Latest upstream release: 0.71
Current version/release in rawhide: 0.70-3.fc29
URL: http://search.cpan.org/dist/Code-TidyAll/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/8650/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org