Re: Koji shows root.log to blame when in fact the error is in build.log

[Miro Hrončok]

On 05. 10. 19 1:37, Dennis Gilmore wrote:

On Fri, Oct 4, 2019 at 6:30 AM Richard W.M. Jones  wrote:



This has happened to me twice this morning, the second time here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=38048038

Rich.

koji uses very simple logic in parsing mock return codes
https://pagure.io/koji/blob/master/f/builder/kojid#_544 it looks like
mock has started using different return codes and koji will need to
learn them all


Since this is (at least) a second time somebody brought this up on this mailing 
list, I've opened https://pagure.io/koji/issue/1679


--
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: "mock exited with status 110, see root.log for more information"; but it's a build failure

[Miro Hrončok]

On 25. 09. 19 22:01, Elliott Sales de Andrade wrote:

On Wed, 25 Sep 2019 at 11:02, Miroslav Suchý  wrote:


Dne 25. 09. 19 v 4:59 Elliott Sales de Andrade napsal(a):

https://koji.fedoraproject.org/koji/buildinfo?buildID=1389518


I looked at this one and:

https://koji.fedoraproject.org/koji/taskinfo?taskID=37850317
and build log:
https://kojipkgs.fedoraproject.org//work/tasks/317/37850317/build.log

exit code 10 according to:
https://github.com/rpm-software-management/mock/wiki#exit-codes
means "error during rpmbuild"


Yes, I know *why* it fails, this is about *how* it fails. Either koji
or mock are confused about what failed. Koji says to look in root.log;
this is wrong, there were no buildroot initialization errors. Mock
also exits with some kind of inconsistency (see original email.)


I've opened https://pagure.io/koji/issue/1679

--
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: what to do without fedocal [was Re: CPE Team Weekly Update: 2019-10-04]

[Adam Williamson]

On Fri, 2019-10-04 at 15:46 -0400, Matthew Miller wrote:
> On Fri, Oct 04, 2019 at 05:58:19PM +0100, Aoife Moloney wrote:
> >Fedocal:  If no maintainer is found by October 18th, it will be
> >decommissioned.
> 
> This is pretty huge, since we use this to keep IRC meeting channels
> coordinated. We used to use this to track people's vacations and
> away-from-project time, but I don't think many people are reliably doing
> that anymore, so from my point of view it's the meetings that are the big
> thing. That is:
> 
> 1. Looking to find the next meetings for a particular team
> 2. Finding an empty meeting spot for a new reoccuring or one-off meeting
> 3. The fancy channel bot stuff which knows about upcoming meetings.
> 
> If no one steps up to take on maintaining this app, I'm going to set up a
> wiki or docs site page to cover #1 and #2. We'll lose #3, and probably some
> other stuff, but... I don't see a good immediate alternative.

QA also uses it for scheduling Test Days (and a few other things, but
that's the biggest). I started a thread about this on test@ back when
fedocal was first floated for being killed, but we didn't come to any
solid conclusions besides "uhhh...google?"
-- 
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://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: Unresponsive Package Maintainer drago01

[Sérgio Basto]

On Fri, 2019-10-04 at 21:11 -0400, Chris wrote:
> HI,
> 
> I'm just following the process identified here: 
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
> 
> 1) I filled this issue back in June/2019: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1720857
> 2) I created a non responsive maintainer a couple of weeks ago: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1755999
> 
> I just thought I'd give the ol' mail list a try since that seems to
> be what is suggested of me next :)
> 
> Thoughts/Advice?

Adding him in CC ;)
> Chris
> 
> 
> ___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
-- 
Sérgio M. B.

___
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

Unresponsive Package Maintainer drago01

[Chris]

HI,

I'm just following the process identified here:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

1) I filled this issue back in June/2019:
https://bugzilla.redhat.com/show_bug.cgi?id=1720857
2) I created a non responsive maintainer a couple of weeks ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1755999

I just thought I'd give the ol' mail list a try since that seems to be what
is suggested of me next :)

Thoughts/Advice?

Chris
___
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: Modularity and the system-upgrade path

[Kevin Kofler]

Miro Hrončok wrote:
> Wouldn't it be easier if the "default stream" would just behave like a
> regular package?

+1

> I can think of two solutions of that:
> 
> 1. (drastic for modular maintainers)
> 
> We keep miantaining the default versions of things as ursine packages. We
> only modularize alternate versions.
> 
> Pros: Users who don't want alternate versions won't be affected by
> imperfections of our modular design. No Ursa Major/Prime needed in the
> buildroot.
> 
> Cons: Modular maintainers who do modules with just one stream because it
> is easier for them would need to rollback to what's easier for everybody
> else but them. Modular maintainers who do multiple modular streams would
> need to maintain both the alternate streams and ursine packages.

In other words, this proposal would ban module-only packages, allowing 
modules only for alternate versions? IMHO, that is the most reasonable 
approach, but:

> 2. (potentially dangerous consequences?)
> 
> We put the default modular stream into our regular repos, similarly to
> what we try to do in the buildroot. "dnf install Foo" would install the
> Foo package and would not enbale any streams or modules. The modular
> maintainers would keep maintaining the modules as now, the infrastructure
> would compose the defaults into the regular repo (or an additional but
> default-enabled one).
> 
> Pros: Maintainers would keep doing what they desire.
> 
> Cons: We would need to make this technically possible and figure out all
> the corner cases (however AFAIK this needs to be done for the "modules in
> buildroot" thing as well).

If that works out, that sounds acceptable to me as well. As long as I am not 
forced to use or care about modules, this works for me.

> WDYT?

I think either of your 2 proposals needs to be implemented ASAP. They are 
both much saner than the overengineered and error-prone solutions the 
Modularity team is proposing for this blocker (see Stephen Gallagher's mail 
that started this thread). Seeing how DNF already has trouble meeting user 
expectations in corner cases (e.g., with Obsoletes, with weak dependencies, 
etc., and now also with Modularity), I don't think expecting more complex 
behavior from it is going to work out well.

Kevin Kofler
___
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: Defining the future of the packager workflow in Fedora

[Kevin Kofler]

Randy Barlow wrote:
> It's not an either-or. If you resolve the conflict, you can have fast-
> forwarding *and* not pass irrelevant/confusing changelogs on to the end
> user.
> 
> I personally avoid if statements in spec files and just resolve
> conflicts.

No. Resolving conflicts implies that you need to do an actual merge, NOT a 
fast forward. Fast-forwarding means that I am shipping the SAME commit on 
all branches, so the changelog must be identical (unless I play games with 
%if in the changelog, which is not going to happen).

In addition, resolving conflicts is extra work compared to a conflict-free 
merge or ideally a fast-forward.

Kevin Kofler
___
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: Defining the future of the packager workflow in Fedora

[Kevin Kofler]

Vít Ondruch wrote:
> It depends how you maintain your packages. My guess is (and I am sorry
> if I am mistaken) that you don't follow the
> 
> https://fedoraproject.org/wiki/Updates_Policy#Philosophy
> 
> If you followed this policy, then you would touch the stable branches
> just rarely and therefore keeping them fast forwardable would be just
> waste of time.

It depends on what, how, and when upstream releases.

If we have different upstream releases in different Fedora releases, then of 
course those releases should have different specfiles. But if we are 
shipping the same upstream release, I don't see why I should clone the 
specfile n times.

There are many possible reasons for shipping the same upstream release 
across different Fedora releases:
* There might just not have been a newer upstream release in this time.
* Heck, there might even not be any new upstream releases at all anymore,
  which is typical for compatibility libraries such as qt3.
* The newer upstream releases might be bugfix-only releases applicable to
  stable Fedora releases just fine. (In other words, there might just not
  have been a newer upstream feature release in this time.)
* It can be necessary for security reasons to upgrade to a newer feature
  release. (E.g., this is the case for browser packages such as firefox or
  chromium. Also for qt5-qtwebengine to some extent, though at least Qt
  maintains LTS branches including QtWebEngine security backports these
  days.)
* It can be necessary to upgrade a library to a backwards-compatible feature
  release because applications are depending on a newer version. (The main
  example there is KF5 (KDE Frameworks 5), which does not maintain bugfix
  branches at all. But, e.g., Qt also sometimes needs to be upgraded to meet
  application demands.)
* There can be other reasons why backporting the newer feature release is a
  good idea. (E.g., if it only adds features and does not remove or break
  anything, and if it has been thouroughly tested for regressions without
  any being found, why would it not be OK to push?)

That said, I am not a fan of the Updates Policy as written because it is 
written in the form "do not push new feature releases as updates unless X, Y 
or Z", whereas I think it should be "do push new feature releases as updates 
unless X', Y' or Z'". Still, I think we all agree that some feature releases 
just need to go out (e.g., because they include security fixes that are 
impractical to backport) whereas some definitely must never go out as 
updates (e.g., anything that breaks user configuration).

Kevin Kofler
___
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: Defining the future of the packager workflow in Fedora

[Kevin Kofler]

Miro Hrončok wrote:
> It goes like this:
> 
>   - master and f31 are at the same commit "aa"
>   - I push a change only possible in rawhide, commit "bb" to master
> (it includes release bump and changelog entry)
>   - a commit relevant for both, "cc" is pushed to master
> (it includes release bump and changelog entry)
>   - on f31, I run `git cherry-pick cc` => conflict
> 
> I don't worry about having "Fedora 31 mass rebuild" or "Rebuilt for python
> 3.8" changelong entries in Fedora 29 (it gives me a little flinch, but
> nothing serious). i worry about the bb commit I cannot merge into f31
> (e.g. if it implements some Fedora 32 change).
> 
> Then obviously, people start inventing %if spaghetti.

And %if is actually the correct fix for this issue.

See, e.g., the one I had to add to qt5-qtwebengine after you broke it for
F29 with your mass change:
https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/05a52d121d49972989aea8127e22e25f0292333c?branch=master

IMHO, mass changes are only acceptable if the result builds on all supported
Fedora releases. Breaking the build for F29 is only acceptable after it
reaches EOL. So your mass change should have included this %if, or ideally
an update pushed to F29 to make the conditional unnecessary.

Kevin Kofler
___
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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Kevin Kofler]

Stephen John Smoogen wrote:
> What do you mean by breaking breaking because you use that term like a
> sledge hammer for anything from a 'pixel off' bug to 'too old software
> is in repos', 'too young software is in repos' , 'software is not in
> repos' to 'can't boot'. After a while, I assumed the only way I can't
> break a system is to never unbox it.. but I expect there is probably
> some way that is also a broken system.

In this context, it is fairly clear what I meant: any current version of 
Fedora (in around a year, this will mean any version still supported with 
security updates at that point) will not run on those systems at all. It 
will not even boot.

Kevin Kofler
___
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: Koji shows root.log to blame when in fact the error is in build.log

[Dennis Gilmore]

On Fri, Oct 4, 2019 at 6:30 AM Richard W.M. Jones  wrote:
>
>
> This has happened to me twice this morning, the second time here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=38048038
>
> Rich.
koji uses very simple logic in parsing mock return codes
https://pagure.io/koji/blob/master/f/builder/kojid#_544 it looks like
mock has started using different return codes and koji will need to
learn them all

Dennis
___
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 31 Final blocker status email #4

[Ben Cotton]

Action summary


Accepted blockers
-
1. mutter — can't turn zoom off once enabled — NEW
ACTION: upstream to fix issue

2. distribution — Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed —
NEW
ACTION: dnf team to look at adding output message

3. dnf — Revert skip_if_unavailable default back to true — ASSIGNED
ACTION: everyone to give karma to FEDORA-2019-ded8e6872f

4. gnome-control-center — Gnome Control Center crashes upon a typo in
Printers settings — ASSIGNED
ACTION: upstream to diagnose and fix issue

5. gnome-control-center — Apply button stays gray on Network configuration — NEW
ACTION: upstream to diagnose and fix issue

6. gnome-shell — Automatic workspaces are seriously broken — NEW
ACTION: upstream to fix issue

7. mutter — Keyboard shortcuts NOT mapped to keyboard layouts — NEW
ACTION: upstream to diagnose and fix issue

8. sddm — Cannot start Fedora-KDE-Live (F31) in basic graphics mode on
BIOS machine — NEW
ACTION: upstream to diagnose and fix issue

9. blivet-gui — bios boot partition can't be created at the disk
beginning, if a partition already exists in the middle of the disk —
ASSIGNED
ACTION: maintainer to merge PR #131



Proposed blockers
-

1. gnome-shell — numlock handling is seriously broken — NEW
ACTION: upstream to diagnose and fix issue

2. fwupd — fwupd.service fails to start if /var/cache/fwupd doesn't
exist (e.g. clean install)  — ASSIGNED
ACTION: fwupd maintainer to make the package provide /var/cache/fwupd
(and/or backport patches and request SELinux policy change)

3. grub2 — Newer kernels do not boot and have invalid grub.cfg entries
(on Xen DomU guests) — NEW
ACTION: maintainers/QA/reporter to determine scope of failure

4. vte291 — vte crashes due to out of bounds cursor — MODIFIED
ACTION: QA to verify FEDORA-2019-8288e417ac fixes the issue

Bug-by-bug detail
=

Accepted blockers
-
1. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=1749433 — NEW
can't turn zoom off once enabled

Zoom remains enabled, even after logging out and logging back in.
Upstream issue has identified a commit that appears to be the culprit.
Upstream issue: https://gitlab.gnome.org/GNOME/mutter/issues/826

2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1747408 — NEW
Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed

Accepted as a blocker by FESCo, even though it does not affect default
package sets. DNF team is looking at adding an output message that
would address FESCo's short-term concerns. sgallagh has proposed a
longer-term solution.

3. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=1752249 — VERIFIED
Revert skip_if_unavailable default back to true

Update FEDORA-2019-ded8e6872f is confirmed to revert the default
behavior as requested.

4. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=1750394 — ASSIGNED
Gnome Control Center crashes upon a typo in Printers settings

Update FEDORA-2019-be95719373 contains a fix that breaks the search
box. This has been reported upstream.
Upstream issue: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/679

5. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=1750805 — NEW
Apply button stays gray on Network configuration

Wired network connections cannot be configured because the "apply"
button remains inactive. WiFi configuration works.
Upstream issue: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/677

6. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1754630 — NEW
Automatic workspaces are seriously broken

There are several regressions in how workspaces behave, probably
related. Upstream has identified a possible culprit commit.
Upstream bug: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1497

7. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=1754373 — NEW
Keyboard shortcuts NOT mapped to keyboard layouts

All shell keyboard shortcuts are broken, except for those where the
keys happen to be in the same position in both the current keyboard
layout and en_US.
Upstream issue: https://gitlab.gnome.org/GNOME/mutter/issues/822

8. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1728240 — NEW
Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine

This issue only seems to affect BIOS machines when using basic
graphics mode. This appears to be related to an issue encountered in
F30 (RHBZ #1683197).
Upstream issue: https://github.com/sddm/sddm/issues/1204

9. blivet-gui — https://bugzilla.redhat.com/show_bug.cgi?id=1755813 — ASSIGNED
bios boot partition can't be created at the disk beginning, if a
partition already exists in the middle of the disk

blivet tries to place the BIOS boot partition after existing partiions
in certain configurations, which mean

what to do without fedocal [was Re: CPE Team Weekly Update: 2019-10-04]

[Matthew Miller]

On Fri, Oct 04, 2019 at 05:58:19PM +0100, Aoife Moloney wrote:
>Fedocal:  If no maintainer is found by October 18th, it will be
>decommissioned.

This is pretty huge, since we use this to keep IRC meeting channels
coordinated. We used to use this to track people's vacations and
away-from-project time, but I don't think many people are reliably doing
that anymore, so from my point of view it's the meetings that are the big
thing. That is:

1. Looking to find the next meetings for a particular team
2. Finding an empty meeting spot for a new reoccuring or one-off meeting
3. The fancy channel bot stuff which knows about upcoming meetings.

If no one steps up to take on maintaining this app, I'm going to set up a
wiki or docs site page to cover #1 and #2. We'll lose #3, and probably some
other stuff, but... I don't see a good immediate alternative.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[Test-Announce] 2019-10-07 @ 16:00 UTC - Fedora 31 Blocker Review Meeting

[Adam Williamson]

# F31 Blocker Review meeting
# Date: 2019-09-30
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 5 proposed Final blockers and 2 proposed Final freeze
exception to review, so let's have a Fedora 31 blocker review meeting
on Monday!

If you have time today, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F31 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

[Test-Announce] Proposal to CANCEL: 2019-10-07 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
think there's anything urgent right now. There will be a blocker review
meeting.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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: Modularity and the system-upgrade path

[Miro Hrončok]

On 04. 10. 19 16:57, Stephen Gallagher wrote:

Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.

1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
content.

Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.



Wouldn't it be easier if the "default stream" would just behave like a regular 
package?


I can think of two solutions of that:

1. (drastic for modular maintainers)

We keep miantaining the default versions of things as ursine packages. We only 
modularize alternate versions.


Pros: Users who don't want alternate versions won't be affected by imperfections 
of our modular design. No Ursa Major/Prime needed in the buildroot.


Cons: Modular maintainers who do modules with just one stream because it is 
easier for them would need to rollback to what's easier for everybody else but 
them. Modular maintainers who do multiple modular streams would need to maintain 
both the alternate streams and ursine packages.



2. (potentially dangerous consequences?)

We put the default modular stream into our regular repos, similarly to what we 
try to do in the buildroot. "dnf install Foo" would install the Foo package and 
would not enbale any streams or modules. The modular maintainers would keep 
maintaining the modules as now, the infrastructure would compose the defaults 
into the regular repo (or an additional but default-enabled one).


Pros: Maintainers would keep doing what they desire.

Cons: We would need to make this technically possible and figure out all the 
corner cases (however AFAIK this needs to be done for the "modules in buildroot" 
thing as well).


WDYT?

--
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: Defining the future of the packager workflow in Fedora

[Matthew Miller]

On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
> >> The package review becomes then a basic PR. We could leverage the tools we 
> >> are
> >> working on for regular PRs.
> >> If the PR is approved, you get access granted to it.
> >> If the PR is denied, both repo are deleted.
> > This is an interesting idea.
> It is, but I am afraid that then we will have Foo, foo, FOO and fOo
> repositories and we won't be able to get rid of them for similar reasons
> we are not allowed to delete branches in current dist-git.
> 

Maybe we could have a namespace for unapproved ones, and move the repo if
approved?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Old changelog entries removal

[Przemek Klosowski via devel]

On 10/3/19 12:19 PM, Matthew Miller wrote:

On Thu, Oct 03, 2019 at 11:13:32AM -0500, Michael Cronenworth wrote:

Remote changelog URLs might become inaccessible over time, making tracking down
behavior changes & tricky bugs problematic.

Yes, there are systems that do not have Internet access.
Examples:
- Classified systems with no access at all
- Proxy restricted systems (behind a web filter that may block)
It's incredibly helpful to have rpm -q $PKG --changelog available.
Whatever change is made it needs to be available offline.

I think providing whatever as a %doc would fit most use-cases. Or it could
be a special document thing like %license.

Many maintainers put CVE information in their changelog, so it's 
possible to see at a glance whether a particular vulnerability is 
addressed, which is not only convenient but also pretty much required in 
many environments. This is especially important when patches are 
backported and so the overall 'upstream' NVR is not conclusive.


Is there any kind of policy on including CVE info in changelogs? I've 
seen it done enough times that I thought there might be some guidelines 
about it, but then again it doesn't always happen. Is it simply a 
best-practice adopted by some but not all packages?


___
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: Old changelog entries removal

[Matthew Miller]

On Fri, Oct 04, 2019 at 08:52:45AM -0400, Neal Gompa wrote:
> I would personally make the same request as well for anything I've got
> a changelog entry for.

This is reasonable and I think anything which moves changelog entries out of
spec files (and ideally also RPM metadata) must preserve this. 


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Defining the future of the packager workflow in Fedora

[Björn Persson]

Robbie Harwood wrote:
>I have experienced this as a maintainer as well.  The issue for drive-by
>contributors is not so much pull requests as the account system itself.
>For example, I had a contributor from OpenSUSE email me patches to my
>pagure-hosted project (gssproxy) rather than opening a pull request
>because they didn't have a Fedora account.

It's not just the account. Fork → clone → patch → commit → push →
request is a rather long series of hoops to jump through. Clone → edit
→ commit → submit should be sufficient. Or what if I could just upload
a patch and have it turned into a pull request automatically?

Björn Persson


pgpKClAtv5vfn.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: Modularity and the system-upgrade path

[Björn Persson]

Stephen Gallagher wrote:
>* The state `dep_enabled` would be set whenever a stream becomes
>enabled because some other module stream depended on it. This state
>must be entered only if the previous state was `default` or
>`available`. (We don't want `enabled` or `disabled` streams being able
>to transition to this state.)
>
>* The state `default_enabled` would be set whenever a stream becomes
>enabled because a transaction pulled in a package from a default
>stream, causing it to be enabled. This state must only be entered if
>the previous state was `default` or `dep_enabled`. We don't want
>`enabled` or `disabled` to be able to transition to `default_enabled`.
>If a user requests installation of a package provided by a stream
>currently in the `dep_enabled` state, that stream should transition to
>the `default_enabled` state (meaning that now the user would expect it
>to be treated the same as any other default-enabled stream).

It looks like a non-default stream could go through the transitions
available → dep_enabled → default_enabled. Is that desirable?

Björn Persson


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

CPE Team Weekly Update: 2019-10-04

[Aoife Moloney]

Hi Everyone,

Welcome to the CPE team weekly project update mail!


Background: The Community Platform Engineering group is the Red Hat team
combining IT and release engineering from Fedora and CentOS. Our goal is to
keep core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers can
give.

For better communication, we are giving weekly reports to the CentOS and
Fedora communities about the general tasks and work being done.



Fedora:

Rawhide Gating:  


   -

   Moving towards testing in staging with a beta release being built to
   deploy in staging.
   -

   Robosignatory using fedora-messaging deployed in staging.
   -

  There is an issue on documentation here that is also being addressed
  -

   Rawhide compose now fixed & some broken kde deps rebuilt
   -

   Work on staging environment set to start this week
   -

  This broke when we branched F31 in production & ticket tracked in:
  https://pagure.io/releng/issue/8838
  -

   Koji storage issue was fixed and closed
   -

   Overview page of the remaining blockers and dependencies organized at:
   -

  https://hackmd.io/Gbuu9JOPR--Y2yNCBEYI5A?view
  -

 Input welcome for anything that would be missing
 -

  https://github.com/fedora-infra/bodhi/projects/3
  -

 High priority items in the “Ready” column are all hard-dependency
 for pushing multi-builds to production


repoSpanner 


   -

   (Another!) Race condition discovered has been fixed and tested
   -

   Test suite is more stable, but is still an ongoing work for full
   reliability
   -

   Performance testing is underway this week



Application Handover to Community


   -

   Badges: Thread has been started to get a decision with new maintainers
   -

   Packagedb-cli: Retired this week
   -

   Pastebin: Ongoing conversations with future maintainer, expecting an
   update in the next 2 weeks
   -

   Elections: Move to CommuniShift underway with two blockers to fix before
   complete.
   -

   Fedocal:  If no maintainer is found by October 18th, it will be
   decommissioned.
   -

  Please reach out to any of the CPE team if you want to take over this
  project.
  -

   Nuancier: Identified a maintainer and the team are engaging in a
   conversation
   -

   Whatcanidoforfedora.org: Moved to Communishift
   -

   DNS needs to be directed and a new owner is needed for it so this is
  open for volunteers
  -

   Documentation for onboarding contributors to Community OpenShift was
   started with a good mail thread on Fedora Devel



Misc highlights from various parts of the ecosystem:


   -

   FPDC: No Update
   -

   Fedora Container base image released.
   -

   Merged Fedora image PR on Dockerhub
   https://github.com/docker-library/official-images/pull/6702,
   -

Rawhide compose failures, due to podman gating, filed
   https://github.com/fedora-infra/bodhi/issues/3512 are still being worked
   on
   -

   F31 Final freeze will start next Tuesday, 8th October
   -

   Fedora 26 & 27 packages were archived in koji.
   -

   A discussion to define what Minimum Viable Fedora
   

   looks like was started.
   -

  Please get involved! :)
  -

   Bug in Koji plugin was resolved so sending signing messages has resumed.

https://pagure.io/fedora-infrastructure/issue/8158

   -

   cpe/infra-docs repo is being removed from pagure and we are now going to
   use infra-docs-pagure  instead. Working
   with an active contributor in the repo to make sure there are no problems.


CentOS:


   -

The team is working with CERN about koji upgrade process for
   cbs.centos.org
   -

   CentOS CI
   -

  SSL Authentication issue with Fedora Messaging pluginI now solved.
  -

  Shared library being developed
  -

   8.0.1905 docs now published on docs.centos.org.




Comments & feedback are always welcome & have a great weekend!

Aoife
-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
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: Defining the future of the packager workflow in Fedora

[Vít Ondruch]

Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon  wrote:
>> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
>>
>> Thanks for your words, I appreciate the support on the idea.
>>
>>> 1. Creating new packages has become (more of) a pain since the
>>> retirement of pkgdb2. I know I keep complaining about needing to
>>> manually fetch Pagure API keys, but it is actually extremely annoying
>>> when I go to request a repo and realize I need to first request a new
>>> API key before doing anything else. The problem isn't the workflow,
>>> per se, but the infrastructure: reviews could really use a better
>>> platform than bugzilla. If reviews were more integrated into the
>>> tooling, automatic checks like fedora-review could maybe be ran
>>> automatically. Maybe approving a new package could even automatically
>>> create the repository, without the requestor having to do anything!
>> So I've been wondering a little bit how we could solve this and I've been
>> wondering if we couldn't leverage the PR workflow for this.
>> Imagine:
>> - You request a new repo to be created
>> - The new repo is automatically created from your request
>> - You fork it
>> - Push your spec file and patches to your fork
>> - Open a PR against the empty repo
>>
>> The package review becomes then a basic PR. We could leverage the tools we 
>> are
>> working on for regular PRs.
>> If the PR is approved, you get access granted to it.
>> If the PR is denied, both repo are deleted.
> This is an interesting idea.


It is, but I am afraid that then we will have Foo, foo, FOO and fOo
repositories and we won't be able to get rid of them for similar reasons
we are not allowed to delete branches in current dist-git.

Also this ignores possible issues with patented or inappropriately
licensed code.


Vít



>  And it would definitely be better than
> doing the bugzilla dance every time ...
> It would be great if the initial commit could then be squashed when
> it's finally approved and merged :)
>
>>> 2. Release monitoring is a wonderful tool, but it's poorly integrated
>>> with the rest of the project. As a packager maintaining probably more
>>> packages than I should, getting release monitoring notifications to
>>> tell me to pay attention to a particular package is incredibly useful.
>>> But I feel like we could do more with the information. There are
>>> nodejs packages out there, to take an ecosystem at random, that have
>>> had open tickets created by release monitoring for four+ years, and
>>> the only activity on those tickets is the release monitoring bot
>>> detecting new versions. Eventually, maybe, a human comes across the
>>> package and realizes it might be unmaintained, and proceeds with the
>>> nonresponsive maintainer policy or manages to track down the
>>> maintainer to find out why the package hasn't been updated. I don't
>>> say this to criticize anyone in particular, but surely we could be
>>> more proactive here?
>> So there are a few works in the pipes for this.
>> Dist-git in staging already offers a better integration between dist-git and
>> anitya, you can see it for example at:
>> https://src.stg.fedoraproject.org/rpms/guake on the left hand side column.
>> the-new-hotness is being adjusted so that it opens a pull-request rather 
>> than a
>> bugzilla ticket. This doesn't quite solve the issue of "there is no-one to
>> review the ticket/PR" though.
> I have never looked at the patches that the-new-hotness generates, but
> automatically filed PRs would actually be helpful, and easily
> actionable.
> This sounds awesome, and would make simple "bump + build" updates
> pretty much automatic and painless \o/
>
> Thanks for working on all this,
> Fabio
>
>> Packit ( https://github.com/packit-service/packit/ ) is also aimed at helping
>> with speeding up the flow from upstream to downstream.
>>
>>> I would personally advocate starting with a serious look at the review
>>> process, and the tooling around it. If for no other reason than it is
>>> the first thing most new contributors will interact with, so perhaps
>>> it is in our interest to make it as pleasant as possible.
>> Trying to improve the package review process is something that has been in my
>> radar for a while now but not high enough in the priority list.
>>
>>
>> Looking forward to hear your thoughts,
>> Pierre
>> ___
>> 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.fe

Re: Defining the future of the packager workflow in Fedora

[Robbie Harwood]

Pierre-Yves Chibon  writes:

> On Wed, Oct 02, 2019 at 03:17:33PM -0400, Robbie Harwood wrote:
>
>> With about six more emails about it, sure.  And another piece of
>> infrastructure that has to be up and bug-free.
>> 
>> Even the gating and bodhi emails today are rather a lot: I don't want to
>> be notified if everything worked correctly.
>
> Sorry for side-tracking this here. We've cut down on the number of
> emails bodhi sends for rawhide. If this is still too many please open
> a ticket so we can discuss and see if we find a consensus on this.

I appreciate that you have reduced them.  I would like that number to be
zero unless something has gone wrong - I imagine this is not something
there will be consensus around.

Thanks,
--Robbie


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://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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Pavel Raiskup]

On Friday, October 4, 2019 10:46:17 AM CEST Nicolas Chauvet wrote:
> Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup  a écrit :
> >
> > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> > > > wrote:
> > > > > Hi,
> > > > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > > > keep
> > > > > branches mergeable with fast forward , may we merge this into
> > > > > master ?
> > > > > like I did in pngquant [1]
> > > > >
> > > >
> > > > It disables the normal build behavior for all non-master branches, so
> > > > you don't want to do that.
> > >
> > > Well , I want keep my branches mergeable !
> >
> > Same problem.  I came across several epel8 branch requests ... and there
> > always is some default 'package.cfg' file I don't really mind as I
> > observed (the builds against epel8 just succeed without that).  More,
> > sometimes the README.md is added.
>
> I've tried to report the issue here: (although it's for another use-case).
> https://pagure.io/fedpkg/issue/354
> 
> Allowing to have the same package.cfg to describe the appropriate
> behaviour for all branches would be nice.  But there is probably a need
> to improve the package.cfg format and associated behavior.

TBH, TL;DR, I need to study why package.cfg is actually useful.

But since everything worked even without the file, I won't complain.
I just remove it and ... business as usual for now.  It would be just much
nicer if I didn't have to have ugly histories.

The predefined README.md/package.cfg seemed to be trivial enough so anyone
interested could even add that file manually (or request explicitly in
ticket).

> > Could we stop doing that?  Unless it is really reasonable, I don't plan to
> > make differences in maintained branches, and to achieve that with the
> > current approach -- I have to go the ugly way (merge epel8 to master and
> > vice versa, so histories in all branches are ugly forever).
>
> I don't get why people use that, it doesn't solve the problem but make
> it worse.  Best is to merge newer branches into olders and avoid any
> merge commit in master. (some projects forbid that).

I personally don't understand why to diverge branches that _are expected_
to have the same contents (some packages don't allow this).  Any random reviewer
needs to ask what are the differences between the branches (is epel-7 behind
master? is behind f31, etc.), and it is wasting of efforts.  Same hash makes it
absolutely obvious.  And if master is above -- you see the older
fast-forward'able branches in git-log.

Pavel


___
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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Stephen John Smoogen]

On Fri, 4 Oct 2019 at 12:25, Pavel Raiskup  wrote:
>
> On Friday, October 4, 2019 10:57:05 AM CEST Fabio Valentini wrote:
> > On Fri, Oct 4, 2019 at 10:47 AM Nicolas Chauvet  wrote:
> > >
> > > Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup  a écrit :
> > > >
> > > > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> > > > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > > > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > > > > > keep
> > > > > > > branches mergeable with fast forward , may we merge this into
> > > > > > > master ?
> > > > > > > like I did in pngquant [1]
> > > > > > >
> > > > > >
> > > > > > It disables the normal build behavior for all non-master branches, 
> > > > > > so
> > > > > > you don't want to do that.
> > > > >
> > > > > Well , I want keep my branches mergeable !
> > > >
> > > > Same problem.  I came across several epel8 branch requests ... and there
> > > > always is some default 'package.cfg' file I don't really mind as I
> > > > observed (the builds against epel8 just succeed without that).  More,
> > > > sometimes the README.md is added.
> >
> > I'm not sure about this, but I think without the package.cfg file,
> > builds won't be submitted to both epel8 and epel8-playground, but only
> > to epel8? This might not be what you want.
>
> For the packages I maintain, I'm not sure the playground is worth another
> branch.  So I'd personally let this work on someone else probably.  Or
> does the fact that I maintain epel8 imply I have to take care of
> epel8-playground as well?
>

The reason for wanting all epel8 packages in playground-epel8 was that
we were wanting to make sure that people could rely on libfoo being in
both without trying to set up layering logic. Say you wanted a package
in epel8 and a newer one in playground-epel8. If we tried to layer
playground-epel8 on top of epel8 with the idea that playground could
replace epel8 packages.. it works in dnf. It does not work the same
in koji. IN that case koji may just drop both packages from its
buildroot or may choose different version from each which cause rpm
problems in the mock.

So the idea was to make every epel8 packages also be in playground. If
you build X it can be built in epel8 and epel8-playground and then
people can rely just on the playground version if they are building
only for playground.

In the end, this may not work at all.. and we will just tell people to
stick their new stuff in a different build system which works for
these sorts of smaller projects.

-- 
Stephen J Smoogen.
___
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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Pavel Raiskup]

On Friday, October 4, 2019 10:57:05 AM CEST Fabio Valentini wrote:
> On Fri, Oct 4, 2019 at 10:47 AM Nicolas Chauvet  wrote:
> >
> > Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup  a écrit :
> > >
> > > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> > > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> > > > > wrote:
> > > > > > Hi,
> > > > > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > > > > keep
> > > > > > branches mergeable with fast forward , may we merge this into
> > > > > > master ?
> > > > > > like I did in pngquant [1]
> > > > > >
> > > > >
> > > > > It disables the normal build behavior for all non-master branches, so
> > > > > you don't want to do that.
> > > >
> > > > Well , I want keep my branches mergeable !
> > >
> > > Same problem.  I came across several epel8 branch requests ... and there
> > > always is some default 'package.cfg' file I don't really mind as I
> > > observed (the builds against epel8 just succeed without that).  More,
> > > sometimes the README.md is added.
> 
> I'm not sure about this, but I think without the package.cfg file,
> builds won't be submitted to both epel8 and epel8-playground, but only
> to epel8? This might not be what you want.

For the packages I maintain, I'm not sure the playground is worth another
branch.  So I'd personally let this work on someone else probably.  Or
does the fact that I maintain epel8 imply I have to take care of
epel8-playground as well?

Pavel

> > I've tried to report the issue here: (although it's for another use-case).
> > https://pagure.io/fedpkg/issue/354
> >
> > Allowing to have the same package.cfg to describe the appropriate
> > behaviour for all branches would be nice.
> > But there is probably a need to improve the package.cfg format and
> > associated behavior.
> >
> > > Could we stop doing that?  Unless it is really reasonable, I don't plan to
> > > make differences in maintained branches, and to achieve that with the
> > > current approach -- I have to go the ugly way (merge epel8 to master and
> > > vice versa, so histories in all branches are ugly forever).
> > I don't get why people use that, it doesn't solve the problem but make it 
> > worse.
> > Best is to merge newer branches into olders and avoid any merge commit
> > in master. (some projects forbid that).
> > ___
> > 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
> 



___
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: Defining the future of the packager workflow in Fedora

[Fabio Valentini]

On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon  wrote:
>
> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
>
> Thanks for your words, I appreciate the support on the idea.
>
> > 1. Creating new packages has become (more of) a pain since the
> > retirement of pkgdb2. I know I keep complaining about needing to
> > manually fetch Pagure API keys, but it is actually extremely annoying
> > when I go to request a repo and realize I need to first request a new
> > API key before doing anything else. The problem isn't the workflow,
> > per se, but the infrastructure: reviews could really use a better
> > platform than bugzilla. If reviews were more integrated into the
> > tooling, automatic checks like fedora-review could maybe be ran
> > automatically. Maybe approving a new package could even automatically
> > create the repository, without the requestor having to do anything!
>
> So I've been wondering a little bit how we could solve this and I've been
> wondering if we couldn't leverage the PR workflow for this.
> Imagine:
> - You request a new repo to be created
> - The new repo is automatically created from your request
> - You fork it
> - Push your spec file and patches to your fork
> - Open a PR against the empty repo
>
> The package review becomes then a basic PR. We could leverage the tools we are
> working on for regular PRs.
> If the PR is approved, you get access granted to it.
> If the PR is denied, both repo are deleted.

This is an interesting idea. And it would definitely be better than
doing the bugzilla dance every time ...
It would be great if the initial commit could then be squashed when
it's finally approved and merged :)

> > 2. Release monitoring is a wonderful tool, but it's poorly integrated
> > with the rest of the project. As a packager maintaining probably more
> > packages than I should, getting release monitoring notifications to
> > tell me to pay attention to a particular package is incredibly useful.
> > But I feel like we could do more with the information. There are
> > nodejs packages out there, to take an ecosystem at random, that have
> > had open tickets created by release monitoring for four+ years, and
> > the only activity on those tickets is the release monitoring bot
> > detecting new versions. Eventually, maybe, a human comes across the
> > package and realizes it might be unmaintained, and proceeds with the
> > nonresponsive maintainer policy or manages to track down the
> > maintainer to find out why the package hasn't been updated. I don't
> > say this to criticize anyone in particular, but surely we could be
> > more proactive here?
>
> So there are a few works in the pipes for this.
> Dist-git in staging already offers a better integration between dist-git and
> anitya, you can see it for example at:
> https://src.stg.fedoraproject.org/rpms/guake on the left hand side column.
> the-new-hotness is being adjusted so that it opens a pull-request rather than 
> a
> bugzilla ticket. This doesn't quite solve the issue of "there is no-one to
> review the ticket/PR" though.

I have never looked at the patches that the-new-hotness generates, but
automatically filed PRs would actually be helpful, and easily
actionable.
This sounds awesome, and would make simple "bump + build" updates
pretty much automatic and painless \o/

Thanks for working on all this,
Fabio

> Packit ( https://github.com/packit-service/packit/ ) is also aimed at helping
> with speeding up the flow from upstream to downstream.
>
> > I would personally advocate starting with a serious look at the review
> > process, and the tooling around it. If for no other reason than it is
> > the first thing most new contributors will interact with, so perhaps
> > it is in our interest to make it as pleasant as possible.
>
> Trying to improve the package review process is something that has been in my
> radar for a while now but not high enough in the priority list.
>
>
> Looking forward to hear your thoughts,
> Pierre
> ___
> 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: Defining the future of the packager workflow in Fedora

[Pierre-Yves Chibon]

On Thu, Oct 03, 2019 at 08:07:33AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Yep. Not every package is the same. For stuff like simple
> python/nodejs/rust/ruby/perl/… packages, I know that the only thing
> I do is mechanically bump the version and rebuild. I don't take a careful
> look at the changes in the package, I don't do any non-automated checks;
> if it builds, it gets shipped. For such packages, there really would be
> no difference if a bot was doing all the steps I'm doing now.

That's the thing which I think we're missing, how much of our packages are
simple: bump & rebuild? (40%, 50%, 75%?)
Automating the build from a commit and the update from a build was very much
something I thought would be useful for these packages.

The challenge is to find a way to improve this simple workflow without
penalizing the more complex ones.


Pierre
___
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: Defining the future of the packager workflow in Fedora

[Pierre-Yves Chibon]

On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:

Thanks for your words, I appreciate the support on the idea.

> 1. Creating new packages has become (more of) a pain since the
> retirement of pkgdb2. I know I keep complaining about needing to
> manually fetch Pagure API keys, but it is actually extremely annoying
> when I go to request a repo and realize I need to first request a new
> API key before doing anything else. The problem isn't the workflow,
> per se, but the infrastructure: reviews could really use a better
> platform than bugzilla. If reviews were more integrated into the
> tooling, automatic checks like fedora-review could maybe be ran
> automatically. Maybe approving a new package could even automatically
> create the repository, without the requestor having to do anything!

So I've been wondering a little bit how we could solve this and I've been
wondering if we couldn't leverage the PR workflow for this.
Imagine:
- You request a new repo to be created
- The new repo is automatically created from your request
- You fork it
- Push your spec file and patches to your fork
- Open a PR against the empty repo

The package review becomes then a basic PR. We could leverage the tools we are
working on for regular PRs.
If the PR is approved, you get access granted to it.
If the PR is denied, both repo are deleted.

> 2. Release monitoring is a wonderful tool, but it's poorly integrated
> with the rest of the project. As a packager maintaining probably more
> packages than I should, getting release monitoring notifications to
> tell me to pay attention to a particular package is incredibly useful.
> But I feel like we could do more with the information. There are
> nodejs packages out there, to take an ecosystem at random, that have
> had open tickets created by release monitoring for four+ years, and
> the only activity on those tickets is the release monitoring bot
> detecting new versions. Eventually, maybe, a human comes across the
> package and realizes it might be unmaintained, and proceeds with the
> nonresponsive maintainer policy or manages to track down the
> maintainer to find out why the package hasn't been updated. I don't
> say this to criticize anyone in particular, but surely we could be
> more proactive here?

So there are a few works in the pipes for this.
Dist-git in staging already offers a better integration between dist-git and
anitya, you can see it for example at:
https://src.stg.fedoraproject.org/rpms/guake on the left hand side column.
the-new-hotness is being adjusted so that it opens a pull-request rather than a
bugzilla ticket. This doesn't quite solve the issue of "there is no-one to
review the ticket/PR" though.
Packit ( https://github.com/packit-service/packit/ ) is also aimed at helping
with speeding up the flow from upstream to downstream.

> I would personally advocate starting with a serious look at the review
> process, and the tooling around it. If for no other reason than it is
> the first thing most new contributors will interact with, so perhaps
> it is in our interest to make it as pleasant as possible.

Trying to improve the package review process is something that has been in my
radar for a while now but not high enough in the priority list.


Looking forward to hear your thoughts,
Pierre
___
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: Defining the future of the packager workflow in Fedora

[Pierre-Yves Chibon]

On Wed, Oct 02, 2019 at 03:17:33PM -0400, Robbie Harwood wrote:
> With about six more emails about it, sure.  And another piece of
> infrastructure that has to be up and bug-free.
> 
> Even the gating and bodhi emails today are rather a lot: I don't want to
> be notified if everything worked correctly.

Sorry for side-tracking this here. We've cut down on the number of emails bodhi
sends for rawhide. If this is still too many please open a ticket so we can
discuss and see if we find a consensus on this.

Thanks,
Pierre


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

Fedocal will be decommissioned on October 15th

[Aoife Moloney]

Hi Everyone,

We have tried for a number of weeks now to find a new maintainer for
Fedocal.

Unfortunately this has not been successful and the CPE team will
decommission Fedocal at close of business EST on Friday, October 15th.

If a maintainer steps up between now and then we will of course work with
you and help transition ownership to you.

Please reach out here or to any member of the CPE team if you feel you can
take on the maintenance of Fedocal.



Thanks,
Aoife
-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
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

Usage of wildcards in systemd RPM scriptlets broken on fedora >= 31?

[Fabio Valentini]

Hi everybody,

To provide a bit of context: Syncthing ships unit files for both
system services and user services, where the system service can be
instantiated with the $USER the service should run as. The user
service obviously doesn't need this argument, but will only run when
the user is logged in.

In the syncthing.spec file, I have the following scriptlets for
correctly handling the syncthing service:

%post
%systemd_post 'syncthing@*.service'
%systemd_user_post syncthing.service

%preun
%systemd_preun 'syncthing@*.service'
%systemd_user_preun syncthing.service

%postun
%systemd_postun_with_restart 'syncthing@*.service'
%systemd_user_postun_with_restart syncthing.service

The variants for restarting all instances of the system service work
up to fedora 30, and successfully restart the syncthing service when
the packages is upgraded (as far as I can tell).

I now got a but report that this scriptlet no longer works on fedora
>= 31, and it throws this error:

"Invalid unit name "syncthing@*.service" was escaped as
"syncthing@\x2a.service" (maybe you should use systemd-escape?)"

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

It looks like systemd changed its behavior wrt. using wildcards for
instances of services.

Does somebody know how to fix this? Doing some Google-fu didn't help me.

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

Re: Defining the future of the packager workflow in Fedora

[Neal Gompa]

On Fri, Oct 4, 2019 at 11:03 AM Robbie Harwood  wrote:
>
> Björn Persson  writes:
>
> > Panu Matilainen wrote:
> >> On 10/2/19 8:33 PM, Matthew Miller wrote:
> >>> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> >>>
> > ○ Every changes to dist-git is done via pull-requests
> 
>  Erm, no thank you.  Pull requests are a terrible workflow.
> >>>
> >>> It's definitely the winning workflow in the open source world today,
> >>> particularly for smaller and drive-by contributions, which I think
> >>> we'd like to encourage.
> >>
> >> It's an awesome workflow for those cases. Not so much when you are
> >> the maintainer of said piece.
> >
> > In the drive-by contributor role I've always found pull requests
> > unwieldy. I thought they were intended for frequent contributors or
> > project members, for whom the added clicking might be a small burden
> > compared to all the work they do for the project.
> >
> > Perhaps pull requests are convenient for a maintainer who receives
> > them in large numbers – I've only ever received one pull request so I
> > can't judge – but I don't see how they would encourage drive-by
> > contributions.  If you want to encourage drive-by contributions, then
> > you should make it easy to submit a patch without first registering an
> > account, forking a project and so on.
>
> I have experienced this as a maintainer as well.  The issue for drive-by
> contributors is not so much pull requests as the account system itself.
> For example, I had a contributor from OpenSUSE email me patches to my
> pagure-hosted project (gssproxy) rather than opening a pull request
> because they didn't have a Fedora account.
>
> If you look at GitLab, for example, they support a *ton* of federated
> sign-ins: GitLab supports Google, Twitter, GitHub, Bitbucket, and
> Salesforce.
>

I think it'd be cool if we could support logging in via account
services of major Linux distros (Fedora, Mageia, openSUSE, etc.) and
linking them together to make it easier for cross-distro
collaboration.

I think we're a bit away from being able to do that, but it'd be *very
cool* if we could do it.





--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[Bug 1758586] perl-MLDBM for EL8

[bugzilla]

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



--- Comment #1 from Xavier Bachelot  ---
No matching package to install: 'perl(FreezeThaw)'

-- 
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://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/perl-de...@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Robbie Harwood]

Björn Persson  writes:

> Panu Matilainen wrote:
>> On 10/2/19 8:33 PM, Matthew Miller wrote:
>>> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:  
>>>
> ○ Every changes to dist-git is done via pull-requests

 Erm, no thank you.  Pull requests are a terrible workflow.
>>> 
>>> It's definitely the winning workflow in the open source world today,
>>> particularly for smaller and drive-by contributions, which I think
>>> we'd like to encourage.
>> 
>> It's an awesome workflow for those cases. Not so much when you are
>> the maintainer of said piece.
>
> In the drive-by contributor role I've always found pull requests
> unwieldy. I thought they were intended for frequent contributors or
> project members, for whom the added clicking might be a small burden
> compared to all the work they do for the project.
>
> Perhaps pull requests are convenient for a maintainer who receives
> them in large numbers – I've only ever received one pull request so I
> can't judge – but I don't see how they would encourage drive-by
> contributions.  If you want to encourage drive-by contributions, then
> you should make it easy to submit a patch without first registering an
> account, forking a project and so on.

I have experienced this as a maintainer as well.  The issue for drive-by
contributors is not so much pull requests as the account system itself.
For example, I had a contributor from OpenSUSE email me patches to my
pagure-hosted project (gssproxy) rather than opening a pull request
because they didn't have a Fedora account.

If you look at GitLab, for example, they support a *ton* of federated
sign-ins: GitLab supports Google, Twitter, GitHub, Bitbucket, and
Salesforce.

Thanks,
--Robbie


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

Modularity and the system-upgrade path

[Stephen Gallagher]

Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.

1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
content.

Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.


The Modularity WG has generally agreed that we want and need to
support behavior of the following use-cases:


Use Case 1:

On Fedora 30, user Alice runs

yum install Foo

The package "Foo" is provided by a module "foo" with a default stream
"v1.0". Because it's available in a default stream, the package is
installed and the module stream "foo:v1.0" is implicitly enabled for
the system.



Fedora 31 is released. On Fedora 31, the module "foo" has a new
default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
Alice expects the package Foo she installed to be upgraded to version
1.1, because that's what would have happened if it was provided as a
package from the non-modular repositories.



Use Case 2:

On Fedora 30, user Bob runs

yum enable foo:v1.0

In this case, the "v1.0" stream of the "foo" module has a dependency
on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
the system also implicitly enables "bar:v2.4".



Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
about "foo:v1.0" would expect the upgrade to complete, adjusting the
dependencies as needed.


At Flock and other discussions, we've generally come up with a
solution, but it's not yet recorded anywhere. I'm sending it out for
wider input, but this is more or less the solution we intend to run
with, barring someone finding a severe flaw.

Proposed Solution:

What happens today is that once the stream is set, it is fixed and
unchangeable except by user decision. Through discussions with UX
folks, we've more or less come to the decision that the correct
behavior is as follows:

* The user's "intention" should be recorded at the time of module
enablement. Currently, module streams can exist in four states:
"available, enabled, disabled, default". We propose that there should
be two additional states (names TBD) representing implicit enablement.
The state "enabled" would be reserved for any stream that at some
point was enabled by name. For example, a user who runs `yum install
freeipa:DL1` is making a conscious choice to install the DL1 stream of
freeipa. A user who runs `yum install freeipa-client` is instead
saying "give me whatever freeipa-client is the default".

* The state `dep_enabled` would be set whenever a stream becomes
enabled because some other module stream depended on it. This state
must be entered only if the previous state was `default` or
`available`. (We don't want `enabled` or `disabled` streams being able
to transition to this state.)

* The state `default_enabled` would be set whenever a stream becomes
enabled because a transaction pulled in a package from a default
stream, causing it to be enabled. This state must only be entered if
the previous state was `default` or `dep_enabled`. We don't want
`enabled` or `disabled` to be able to transition to `default_enabled`.
If a user requests installation of a package provided by a stream
currently in the `dep_enabled` state, that stream should transition to
the `default_enabled` state (meaning that now the user would expect it
to be treated the same as any other default-enabled stream).

* When running `dnf update`, if a module stream's dependency on
another module changes to another stream, the transaction should cause
that new stream to be enabled (replacing the current stream) if it is
in the `dep_enabled` state.
When running `dnf update` or `dnf system-upgrade`, if the default
stream for a module installed on the system changes and the module's
current state is `default_enabled`, then the transaction should cause
the new default stream to be enabled.

* If stream switching during an update or upgrade would result in
other module dependency issues, that MUST be reported and returned to
the user.

This requires some constraints to be placed on default and dependency changes:

* Any stream upgrade such as this must guarantee that any artifacts of
the stream that is exposed as "API" MUST support RPM-level package
upgrades from any previous stream in this stable release. (Example:
"freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30
launch. Later updates move this to depending on "pki-core

Re: Highlights from the latest Copr release

[Kamil Paral]

On Fri, Oct 4, 2019 at 3:37 PM Pavel Raiskup  wrote:

> Hello,
>
> today (on Oct 4, 2019), new Copr release landed production.
>
> This was mostly a bugfix release, with some optimization/reliability
> patches interesting for copr administrators.  But there were few exciting
> changes for the end-users:
>
> Multilib projects
> -
>
> If you go to the project settings, there's a new "multilib" checkbox.
> When you (a) enable this feature and (b) you enable chroots that form a
> "multilib pair" (for example fedora-rawhide-x86_64 and
> fedora-rawhide-i386), the repofile generated for your users will contain
> two repos with two baseurls, one for x86_64 and one for i386.  So in turn
> packages for both architectures will be available.  This is also fixed in
> `dnf enable copr USER/PROJECT` use-case on affected systems, but you need
> to wait for `dnf-plugins-core >= 4.0.10`.
>

Awesome! Thank you.
___
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: FreeGLUT update with soname bump

[Gwyn Ciesla via devel]

I did, in fact, mean that, but a. mistyped b. failed to include it in the chain 
build. I'll remedy that. Sorry. :)


-- 
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 Friday, October 4, 2019 8:33 AM, Adam Jackson  wrote:

> On Fri, 2019-10-04 at 13:23 +, Gwyn Ciesla via devel wrote:
> 

> > Hi! I'll be updating FreeGLUT to 3.2.1 today. Since this includes a
> > soname bump, I'll do so with a chained rebuild for:
> > 
> > mesa
> 

> I think you mean mesa-demos for the source package here. mesa proper
> doesn't link to glut.
> 

> -   ajax



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

Highlights from the latest Copr release

[Pavel Raiskup]

Hello,

today (on Oct 4, 2019), new Copr release landed production.

This was mostly a bugfix release, with some optimization/reliability
patches interesting for copr administrators.  But there were few exciting
changes for the end-users:

Multilib projects
-

If you go to the project settings, there's a new "multilib" checkbox.
When you (a) enable this feature and (b) you enable chroots that form a
"multilib pair" (for example fedora-rawhide-x86_64 and
fedora-rawhide-i386), the repofile generated for your users will contain
two repos with two baseurls, one for x86_64 and one for i386.  So in turn
packages for both architectures will be available.  This is also fixed in
`dnf enable copr USER/PROJECT` use-case on affected systems, but you need
to wait for `dnf-plugins-core >= 4.0.10`.

Better builder-live.log handling


For some time, we have been automatically compressing the builder-live.log
into builder-live.log.gz.  Previously, we kept a "stub" builder-live.log
file with info that the file was moved to the compressed variant.  Newly
the stub file is removed, and we automatically redirect from
builder-live.log to builder-live.log.gz if the former doesn't exist (i.e.,
when the build already finished).  Frontend UI correctly references either
the log/log.gz variant depending on which state the build is in.  We now
also provide direct links to live log for particular chroot builds, try to
click on the chroot status icon.

Parallel handling of backend actions


Actions like "delete build", "delete project", "create repo", "fork", etc.
requested on frontend are now processed on backend concurrently; the
effect is that the action queue is processed much faster and the
action-reaction is quicker because even very slow actions do not block
other actions.

Forking projects is fixed
-

Previously the forked projects contained an incomplete set of builds; this
bug was fixed.

Please report any issues to https://pagure.io/copr/copr/issues

Happy building!
Pavel


___
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: FreeGLUT update with soname bump

[Adam Jackson]

On Fri, 2019-10-04 at 13:23 +, Gwyn Ciesla via devel wrote:
> Hi! I'll be updating FreeGLUT to 3.2.1 today. Since this includes a
> soname bump, I'll do so with a chained rebuild for:
> 
> mesa

I think you mean mesa-demos for the source package here. mesa proper
doesn't link to glut.

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

FreeGLUT update with soname bump

[Gwyn Ciesla via devel]

Hi! I'll be updating FreeGLUT to 3.2.1 today. Since this includes a soname 
bump, I'll do so with a chained rebuild for:
plib
libcaca
libfreenect
libwebp
mesa
OpenColorIO
asymptote
FlightGear
FlightGear-Atlas
gauche
gl-117
glglobe
gtengine
Io-language
jasper
ocaml-lablgl
OpenMesh
openni
perl-OpenGL
pfstools
player
python-pyopengl
qepcad-B
rubygem-glut
smoldyn
stormbaancoureur
torcs
wiiuse
xmakemol
embree2
fawkes
mathgl
mrpt
OpenSceneGraph
Everything looks ok from here, but if you run into issues, please let me know.

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

Sent with ProtonMail Secure Email.

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

Fedora-31-20191004.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191003.n.1):

ID: 463075  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/463075
ID: 463082  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/463082

Old failures (same test failed in Fedora-31-20191003.n.1):

ID: 463041  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/463041
ID: 463054  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/463054
ID: 463077  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/463077
ID: 463088  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/463088

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

New soft failures (same test not soft failed in Fedora-31-20191003.n.1):

ID: 463157  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/463157

Old soft failures (same test soft failed in Fedora-31-20191003.n.1):

ID: 463158  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/463158

Passed openQA tests: 146/153 (x86_64)

New passes (same test not passed in Fedora-31-20191003.n.1):

ID: 463048  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/463048
ID: 463070  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/463070
ID: 463118  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/463118

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.69 to 0.48
Previous test data: https://openqa.fedoraproject.org/tests/462756#downloads
Current test data: https://openqa.fedoraproject.org/tests/463046#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 736 MiB to 916 MiB
System load changed from 2.19 to 2.00
Average CPU usage changed from 1.67142857 to 83.09047619
Previous test data: https://openqa.fedoraproject.org/tests/462771#downloads
Current test data: https://openqa.fedoraproject.org/tests/463061#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 958 MiB to 726 MiB
1 services(s) removed since previous compose: pcscd.service
System load changed from 1.04 to 0.32
Previous test data: https://openqa.fedoraproject.org/tests/462773#downloads
Current test data: https://openqa.fedoraproject.org/tests/463063#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run/user/1000 contents changed to 87.65591398% of previous size
Previous test data: https://openqa.fedoraproject.org/tests/462789#downloads
Current test data: https://openqa.fedoraproject.org/tests/463079#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.09 to 0.22
Previous test data: https://openqa.fedoraproject.org/tests/462790#downloads
Current test data: https://openqa.fedoraproject.org/tests/463080#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 2.40 to 0.89
Previous test data: https://openqa.fedoraproject.org/tests/462838#downloads
Current test data: https://openqa.fedoraproject.org/tests/463128#downloads
-- 
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://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: Old changelog entries removal

[Neal Gompa]

On Fri, Oct 4, 2019 at 4:39 AM Daniel P. Berrangé  wrote:
>
> On Thu, Oct 03, 2019 at 01:12:10PM -0500, Jason L Tibbitts III wrote:
> > > "MM" == Matthew Miller  writes:
> >
> > MM> Whether or not it's documented policy (and I can't remember or find
> > MM> anything either), many packages have the practice of trimming very
> > MM> old entries.
> >
> > You can't always do this.  I tried to purge changelog entries from a
> > package older than 2010 and was not permitted to do so:
> >
> > https://src.fedoraproject.org/rpms/cyrus-imapd/c/4672136ce3276859bc1971075a87a30a47f9995b?branch=master
> >
> > All I could figure was that the person who originally developed the
> > packages back before 2006 had objected that their changelog entries had
> > been removed.  There might even have been some kind of agreement between
> > them and Red Hat which of course isn't documented anywhere, and
> > shouldn't apply to Fedora anyway.
>
> Given that the RPM build is purging all changelogs older than 2 years
> in the generated binary RPMs, this commit reverting your specfile changelog
> purge seems particularly pointless. I wouldn't be surprised if whomever
> asked for this didn't realize it was culled from the binary RPM regardless.
>

It's not pointless. The full changelog is shipped in the spec file in
the SRPM. So the attribution is still preserved in the source
artifacts.

I would personally make the same request as well for anything I've got
a changelog entry for.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: New updates straight to obsolete after Epoch bump?!?

[Rex Dieter]

Rex Dieter wrote:

> Appears to be a bodhi one

make that bodhi *bug*

-- Rex
___
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: New updates straight to obsolete after Epoch bump?!?

[Rex Dieter]

Richard Shaw wrote:

> I messed up and build PySide2 5.13.x before I relealized that I should
> have built the latest 5.12.x as the MAJOR.MINOR has to match the version
> of Qt and we have not updated to 5.13 yet.
> 
> So I bumped the Epoch in the spec file and built 5.12.5 but when I
> submitted updates for f31 and 30 they pretty much went straight to
> obsolete. The auto-update for rawhide worked fine.
> 
> f31: https://bodhi.fedoraproject.org/updates/FEDORA-2019-51f88396ca
> f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-005d5f20fb
> 
> What's going on here?

Appears to be a bodhi one, one that folks are aware of and working ... where 
it allows an multiple updates for the same build, or zero builds.

See
https://bodhi.fedoraproject.org/updates/FEDORA-2019-521db81bfa

the one that's obsoleting things has no builds associated with it.

-- Rex
___
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 31 compose report: 20191004.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191003.n.1
NEW: Fedora-31-20191004.n.0

= SUMMARY =
Added images:0
Dropped images:  0
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 =

= DROPPED IMAGES =

= 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://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: Defining the future of the packager workflow in Fedora

[Björn Persson]

Panu Matilainen wrote:
> On 10/2/19 8:33 PM, Matthew Miller wrote:
> > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:  
> >>> ○ Every changes to dist-git is done via pull-requests  
> >> Erm, no thank you.  Pull requests are a terrible workflow.  
> > 
> > It's definitely the winning workflow in the open source world today,
> > particularly for smaller and drive-by contributions, which I think we'd
> > like to encourage.   
> 
> It's an awesome workflow for those cases. Not so much when you are the 
> maintainer of said piece.

In the drive-by contributor role I've always found pull requests
unwieldy. I thought they were intended for frequent contributors or
project members, for whom the added clicking might be a small burden
compared to all the work they do for the project.

Perhaps pull requests are convenient for a maintainer who receives them
in large numbers – I've only ever received one pull request so I can't
judge – but I don't see how they would encourage drive-by contributions.
If you want to encourage drive-by contributions, then you should make
it easy to submit a patch without first registering an account, forking
a project and so on.

Björn Persson


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

Provisional pyproject RPM macros: Dynamic BuildRequires for Python packages

[Miro Hrončok]

Hello fellow Python packagers. This is an announcement about a new set of RPM 
macros you can use to build PEP 517/518 enabled packages, that is Python 
packages that have the pyproject.toml file.


  https://www.python.org/dev/peps/pep-0517/
  https://www.python.org/dev/peps/pep-0518/
  https://snarky.ca/clarifying-pep-518/

The set of macros is designed for modern packaging with dynamic buildrequires in 
mind.

The macros are in the pyproject-rpm-macros package and you can use them like 
this:

BuildRequires:  pyproject-rpm-macros

%prep
...

%generate_buildrequires
%pyproject_buildrequires -t

%build
%pyproject_wheel

%install
%pyproject_install

%check
%tox

See the full documentation of the macros:
 https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/README.md

See example spec files:
 https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/tests

(These use setuptools (setup.py), flit and poetry for build backends, but you 
cannot tell that from the specfiles - BuildRequires are generated dynamically 
from upstream metadata.)


The macros are **provisional**, i.e. their API may be changed upon feedback 
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt, 
but rather in early adopters.


If you have questions, ask here. We'll gladly extend the docs if something is 
not clear.

If you find bugs, report them in bugzilla or here. Likewise for RFEs.

Happy hacking,
Python Maintenance
___
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

Koji shows root.log to blame when in fact the error is in build.log

[Richard W.M. Jones]

This has happened to me twice this morning, the second time here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=38048038

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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

Self Introduction: Matěj Grabovský

[Matej Grabovsky]

Hi all,

My name is Matěj and I would like to contribute to the Fedora
community by packaging some interesting and potentially useful
software. I have submitted my first review request for procdump
recently [1].

Currently, I'm a Master's student of IT security, with a focus on
usable security and developer experience, and of environmental
studies. Earlier this year, I started working at Red Hat where I'm
part of the team maintaining the Automated Bug Reporting Tool (ABRT).

I have been contributing to open source software on-and-off for about
ten years now. For the past six years, I have been using GNU/Linux
exclusively, mostly Arch and more recently Fedora. I also maintain a
few packages in the Arch User Repository (AUR). My other interests
include winemaking, category theory and papercraft.

Thanks for having me and see you around.

Cheers,
Matěj Grabovský

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1758499
___
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

Fwd: fedora 31 some funky mouse behavior

[Thomas via devel]

is this the right place for this sort of note?

some sort of Wayland or Gnome behavior.

I saw it the first time today, so I suspect the update yesterday.  This is
an ASUS laptop with an external display and usb mouse, i.e. being used as a
regular machine.

To reproduce a person must boot with the usb mouse plugged in.  Then after
boot things will look normal, however, when clicking on the topbar, and
getting a system menu, for example, to restart, clicking the buttons on the
menu does nothing.

Going to the upper left corner brings up activities as expected.  Typing
'terminal' brings up a terminal.  When the mouse pointer enters the
terminal window, it disappears.  There is no mouse action in the terminal.
  A person can type in it, but there is no mouse action.

Grabbing the laptop from the shelf, opening the lid, going into display 1
and 2 mode, and the internal touchpad mouse works.

Booting without the usb mouse plugged in, then plugging it in after boot,
and it works.

thought you might want to know

go figure ..
___
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: separate authentication for override creation

[Fabio Valentini]

On Fri, Oct 4, 2019 at 11:43 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> git push — requires an ssh key (cached)
> fedpkg build — requires a kerberos ticket (cached)
> fedpkg override – asks for a password every damn time
>
> What's so special about buildroot overrides? Can we make
> them behave more like the other stuff?

Creating buildroot overrides uses the bodhi python client bindings,
which are a bit broken since bodhi 4.0 (which is also the reason why
fedora-easy-karma has been broken for a while). If things work, they
*should* cache some credentials via the OpenIDBaseClient stuff from
python-fedora, but that doesn't seem to work reliably either (maybe
removing the cache file once helps?)

Fabio


> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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

separate authentication for override creation

[Zbigniew Jędrzejewski-Szmek]

Hi,

git push — requires an ssh key (cached)
fedpkg build — requires a kerberos ticket (cached)
fedpkg override – asks for a password every damn time

What's so special about buildroot overrides? Can we make
them behave more like the other stuff?

Zbyszek
___
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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Fabio Valentini]

On Fri, Oct 4, 2019 at 10:47 AM Nicolas Chauvet  wrote:
>
> Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup  a écrit :
> >
> > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> > > > wrote:
> > > > > Hi,
> > > > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > > > keep
> > > > > branches mergeable with fast forward , may we merge this into
> > > > > master ?
> > > > > like I did in pngquant [1]
> > > > >
> > > >
> > > > It disables the normal build behavior for all non-master branches, so
> > > > you don't want to do that.
> > >
> > > Well , I want keep my branches mergeable !
> >
> > Same problem.  I came across several epel8 branch requests ... and there
> > always is some default 'package.cfg' file I don't really mind as I
> > observed (the builds against epel8 just succeed without that).  More,
> > sometimes the README.md is added.

I'm not sure about this, but I think without the package.cfg file,
builds won't be submitted to both epel8 and epel8-playground, but only
to epel8? This might not be what you want.

Fabio

> I've tried to report the issue here: (although it's for another use-case).
> https://pagure.io/fedpkg/issue/354
>
> Allowing to have the same package.cfg to describe the appropriate
> behaviour for all branches would be nice.
> But there is probably a need to improve the package.cfg format and
> associated behavior.
>
> > Could we stop doing that?  Unless it is really reasonable, I don't plan to
> > make differences in maintained branches, and to achieve that with the
> > current approach -- I have to go the ugly way (merge epel8 to master and
> > vice versa, so histories in all branches are ugly forever).
> I don't get why people use that, it doesn't solve the problem but make it 
> worse.
> Best is to merge newer branches into olders and avoid any merge commit
> in master. (some projects forbid that).
> ___
> 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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master

[Nicolas Chauvet]

Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup  a écrit :
>
> On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> > > wrote:
> > > > Hi,
> > > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > > keep
> > > > branches mergeable with fast forward , may we merge this into
> > > > master ?
> > > > like I did in pngquant [1]
> > > >
> > >
> > > It disables the normal build behavior for all non-master branches, so
> > > you don't want to do that.
> >
> > Well , I want keep my branches mergeable !
>
> Same problem.  I came across several epel8 branch requests ... and there
> always is some default 'package.cfg' file I don't really mind as I
> observed (the builds against epel8 just succeed without that).  More,
> sometimes the README.md is added.
I've tried to report the issue here: (although it's for another use-case).
https://pagure.io/fedpkg/issue/354

Allowing to have the same package.cfg to describe the appropriate
behaviour for all branches would be nice.
But there is probably a need to improve the package.cfg format and
associated behavior.

> Could we stop doing that?  Unless it is really reasonable, I don't plan to
> make differences in maintained branches, and to achieve that with the
> current approach -- I have to go the ugly way (merge epel8 to master and
> vice versa, so histories in all branches are ugly forever).
I don't get why people use that, it doesn't solve the problem but make it worse.
Best is to merge newer branches into olders and avoid any merge commit
in master. (some projects forbid that).
___
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: Old changelog entries removal

[Daniel P . Berrangé]

On Thu, Oct 03, 2019 at 01:12:10PM -0500, Jason L Tibbitts III wrote:
> > "MM" == Matthew Miller  writes:
> 
> MM> Whether or not it's documented policy (and I can't remember or find
> MM> anything either), many packages have the practice of trimming very
> MM> old entries.
> 
> You can't always do this.  I tried to purge changelog entries from a
> package older than 2010 and was not permitted to do so:
> 
> https://src.fedoraproject.org/rpms/cyrus-imapd/c/4672136ce3276859bc1971075a87a30a47f9995b?branch=master
> 
> All I could figure was that the person who originally developed the
> packages back before 2006 had objected that their changelog entries had
> been removed.  There might even have been some kind of agreement between
> them and Red Hat which of course isn't documented anywhere, and
> shouldn't apply to Fedora anyway.

Given that the RPM build is purging all changelogs older than 2 years
in the generated binary RPMs, this commit reverting your specfile changelog
purge seems particularly pointless. I wouldn't be surprised if whomever
asked for this didn't realize it was culled from the binary RPM regardless.

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