Fedora-Cloud-30-20200507.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
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: Unannounced SONAME bump: libglade-2.so.6() (glade)

[Igor Gnatenko]

Thank you Kalev!

If that soname bump is needed, please rebuild glade and all affected
packages in a side tag next time.

Thanks!

On Thu, May 7, 2020 at 7:19 AM Kalev Lember  wrote:
>
> On Thu, May 7, 2020 at 6:56 AM Igor Gnatenko 
>  wrote:
>>
>> Hello,
>>
>> it seems that glade-3.36.0-1.fc33 changes SONAME from libglade-2.so.6
>> to libglade-2.so.12.
>
>
> Yes, sorry, already untagged from rawhide. I'll investigate what's up with 
> the soname bump and rebuild dependent packages if it was intentional.
>
> Kalev
> ___
> 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: Unannounced SONAME bump: libglade-2.so.6() (glade)

[Kalev Lember]

On Thu, May 7, 2020 at 6:56 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Hello,
>
> it seems that glade-3.36.0-1.fc33 changes SONAME from libglade-2.so.6
> to libglade-2.so.12.
>

Yes, sorry, already untagged from rawhide. I'll investigate what's up with
the soname bump and rebuild dependent packages if it was intentional.

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

PWG meetup May - the latest printing/scanning stack updates

[Zdenek Dohnal]

Hi,

I attended PWG meetup this week - due COVID-19 the meetup was completely
virtual.

The notes from the first day are attached, new PWG standards were
discussed during next days - proposals can be found here
https://ftp.pwg.org/pub/pwg/ipp/wd/?C=M;O=D .

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

OpenPrinting plenary
-

- cups-filters - moving to printer application - no remote PPDs, reliability 
enhancements,
  moves to stable API of poppler
- future - printing in SNAP/flatpack
- new PAPPL project - framework for printer apps
- ippusbxd vs ipp-go for ipp-over-usb printers
- avahi patch - for advertising local services on local machine only - finally 
megred,
  no longer blocks printer applications and ipp-over-usb
- GSoC prolonged by two weeks later due COVID-19
- OP will try to participate in Google Season of Docs 2020 - starts in 
September to November,
  can go to March for longer projects

GSoC 2019-2020
--
- GSoC 2020 selected projects:
  - linux GUI app for IPP system service
  - common print dialog backend with Qt
  - IPP scan server
  - General printapp SDK
  - speed/scaling optimization of cups-browsed - needs specific HW, delayed due 
COVID
  - extract raster data from PDF to direct printing - needs specific HW, 
delayed due COVID
  - configurable printapps
- OP community bridge - funding openprinting projects

Printer Applications

- two printapps - ippeveprinter (ippserver), LPrint
- framework PAPPL

- printapps = replacement for PPD, ppd options are now ipp attributes + driver 
specific UI by printapp
- printapp is ipp everywhere printer - requires only PWG raster/PDF and JPEG 
(for color printers)
- CUPS libs and ippsample are good means how to create printerapp
- compatible with old CUPS 1.4 and older

ippeveprinter

- started as ippserver, has 3 modes - ppd-based postscript printer mode, basic 
legacy postscript/pcl printer, attribute file mode
- good for testing, not for production

- enhancements - in ippsample and ippeveselfcert, Mike will provide pull 
requests to Apple to incorporate the changes in Apple CUPS
  - support resource files
  - clone-printer script - collects attrs, icons and strings from a printer

LPrint
--
- in snap or github
- for common network or USB label printers
- based on ippeveprinter - multiple printer support via subset of IPP system 
service, daemon is run on demand, it doesnt use CUPS backend
- is standalone spooling without CUPS and runs as ipp everywhere printer
- support raw, apple/pwg raster and PNG files

PAPPL
-
- C framework for writing printer apps
- should support any kind of printer or driver in all environments
- base for gutenprint and LPrint
- supports JPEG, PNG, PWG, Apple Raster and "raw" printing to USB/network 
printer
- license the same as CUPS
- framework supports adding others filters
- it generates specific printerapp and web pages based on your provided options

Openprinting projects
-
- cups-filters
  - now supports clustering
  - no longer downloads remote PPD and creates PPD based on IPP  request
  - works with chunks of print queues
  - filters supports zero-page input files -> zero-page output without error
  - fallback during get_printer_attributes - for IPP-1.1 and then without 
media-col-database
  Future:
  - change of license to the same as CUPS
  - move more functions into libcupsfilters
  - filters should be PPD-less, except for foomatic-rip
  - take PPD functions from CUPS and create libppd library to allow converting
legacy drivers into printerapps
  - cups-browsed as printerapp
  - cups-browsed may be forked from cups-filters

- driverless scanning
  - 3 standards - IPP scan(open PWG standard), eSCL(from HP, used by Apple 
AirScan), WSD(from Windows and W3C)
  - 2 projects - escl and airscan - will be merged into one, supporting all 3 
standards and added into sane-backends
  - sane-backends currently has escl backend, but since it will be merged into 
airscan the escl backend was removed
in Fedora
  - works via ipp-over-usb (ippusbxd, ipp-usb)
  - goal is to rework scanning model due sandboxed packaging -> introducing IPP 
Scan:
- scanning drivers will be scanning application, emulates IPP scanner
- IPP scan client is scanning app
- app uses IPP scan SANE backend, old SANE drivers in legacy Scanner 
Application

- ipp-over-usb:
  - ipp-usb
- written in Go, better http handling library, high memory footprint - main 
disapproval from ChromeOS
  - ippusbxd
- written in C, has several problems which are fixed in ipp-usb (due better 
HTTP library in Go)
- ChromeOS person wanted to implement the features which works in ipp-usb, 
but no activity since then

- CUPS Snap:
  - has CUPS, cups-filters, cups-browsed, gs, qpdf, no classic drivers (cannot 
get dropped into Snap
filesystem)


signature.asc
Description: OpenPGP digital signature
___

Unannounced SONAME bump: libglade-2.so.6() (glade)

[Igor Gnatenko]

Hello,

it seems that glade-3.36.0-1.fc33 changes SONAME from libglade-2.so.6
to libglade-2.so.12.

That is breaking:

* anaconda-widgets-devel (anaconda) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832687
* anjuta - https://bugzilla.redhat.com/show_bug.cgi?id=1832688
* gnome-builder - https://bugzilla.redhat.com/show_bug.cgi?id=1832689
* libhandy-devel (libhandy) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832690
* libxfce4ui-devel (libxfce4ui) -
https://bugzilla.redhat.com/show_bug.cgi?id=1832691

And packages which depend on them.

P.S. Consider using side tags for such updates:
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/
___
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

Review swap: psi-notify

[Michel Alexandre Salim]

Would anyone like to swap a review?

psi-notify - https://bugzilla.redhat.com/show_bug.cgi?id=1832623

psi-notify is a minimal unprivileged notifier for system-wide resource 
pressure using PSI.


This can help you to identify misbehaving applications on your machine 
before they start to severely impact system responsiveness, in a way 
which MemAvailable or other metrics cannot.


Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Purusharth Saxena (FAS: purusharths)

[Purusharth Saxena]

Hi folks,

Hope you all are doing well.  Nice to meet ya'll. I'm Purusharth. I've been
using Fedora for 3-4 good years now.I'm working at a project in IITB
(FOSSEE- Free and Open Source software for education), wherein my part is
to visualize mathematical concepts. As the name suggests, being a foss
evangelist is kinda of my job description.

I have been working on packaging tpcclib
 for a while now, with
due help from ankursinha (he is sponsoring me). I have created a review
request for it: https://bugzilla.redhat.com/show_bug.cgi?id=1832562
Please let me know if you have any questions / comments regarding the
build. I'll look forward for all your feedback.




Thanks and Regards,
Purusharth S
___
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: Is dist-git a good place for work?

[Simo Sorce]

On Wed, 2020-05-06 at 20:59 +0200, Pierre-Yves Chibon wrote:
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two other advantages.
> > 
> > 1) they consume less space than tarballs for each version because
> > objects in git repo are deduplicated
> > 2) instead of downloading/uploading tarballs, you can just do
> > something like: git pull --rebase upstream master; git push
> 
> Just a note that this is not something you can do today since a rebase rewrite
> history, so you would have to do `git push --force` which isn't allowed
> currently.
> So if we were to move forward with this model, we will need to find a solution
> for the question that has led us to forbid force pushes until now.

Well, a way to allow force pushes would be to have a git hook that
branches the tree before the force push. (creating a branch named
something like audit-force-push-)
That way you can retain data for legal/auditing reasons, while allowing
every day history to be rewritten.
Not sure how "nice" that would be for an auditor that has to
reconstruct what happened over multiple force pushes that way, it also
will generate quite an amount of noisy metadata (branches), but it
could work.

If the only differences are going to be a bunch of "patch-commits" on
top of an upstream tree then you have the same level of churn you have
in dist-git + upstream objects count + these new branches metadata
noise, form the pov of space used.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

[Jerry James]

On Wed, May 6, 2020 at 9:01 AM Ankur Sinha  wrote:
> I can review these. Would you be able to review these two if you have
> some time please?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1827957
> https://bugzilla.redhat.com/show_bug.cgi?id=1828079

Will do.  Thank you, Ankur!
-- 
Jerry James
http://www.jamezone.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: Is dist-git a good place for work?

[clime]

On Wed, 6 May 2020 at 21:00, Pierre-Yves Chibon  wrote:
>
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two other advantages.
> >
> > 1) they consume less space than tarballs for each version because
> > objects in git repo are deduplicated
> > 2) instead of downloading/uploading tarballs, you can just do
> > something like: git pull --rebase upstream master; git push
>
> Just a note that this is not something you can do today since a rebase rewrite
> history, so you would have to do `git push --force` which isn't allowed
> currently.

Good point.

> So if we were to move forward with this model, we will need to find a solution
> for the question that has led us to forbid force pushes until now.
>
>
> 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: Is dist-git a good place for work?

[Pierre-Yves Chibon]

On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> But I would like to note that exploded repos (or source-git repos)
> have at least two other advantages.
> 
> 1) they consume less space than tarballs for each version because
> objects in git repo are deduplicated
> 2) instead of downloading/uploading tarballs, you can just do
> something like: git pull --rebase upstream master; git push

Just a note that this is not something you can do today since a rebase rewrite
history, so you would have to do `git push --force` which isn't allowed
currently.
So if we were to move forward with this model, we will need to find a solution
for the question that has led us to forbid force pushes until now.


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: Is dist-git a good place for work?

[clime]

On Wed, 6 May 2020 at 13:21, Fabio Valentini  wrote:
>
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
> >
> >
> > Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> > > On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
> > >
> > > Hi Tomas,
> > >
> > > I'll respond below with some of my experiences and opinions ...
> > >
> > >> Let’s talk about dist-git, as a place where we work. For us,
> > >> packagers, it’s a well-known place. Yet for newcomers, it may take a
> > >> while to learn all the details. Even though we operate with projects
> > >> in a dist-git repository, the layout doesn’t resemble the respective
> > >> upstream project.
> > >>
> > >> There is a multitude of tasks we tend to perform in a dist-git repo:
> > >> * Bumping a release field for sake of a rebuild.
> > >> * Updating to the latest upstream release.
> > >> * Resolving CVEs.
> > >> * Fixing bugs by…
> > >>   * Changing a spec file.
> > >>   * Pulling a commit from upstream.
> > >>   * Or even backporting a commit.
> > >> * And more...
> > >>
> > >> For some tasks, the workflow is just fine and pretty straightforward.
> > >> But for the other, it’s very gruesome - the moment you need to touch
> > >> patch files, the horror comes in. The fact that we operate with patch
> > >> files, in a git repository, is just mind-boggling to me.
> > >>
> > >> Luckily, we have tooling which supports the repository layout -
> > >> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
> > >> easily inspect the source tree or make sure your local change builds.
> > >>
> > >> Where am I getting with this?
> > >>
> > >> Over the years there have been multiple tools created to improve the
> > >> development experience:
> > >> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> > >> the way Fedora kernel developers work on kernel [k]).
> > > (snip)
> > >
> > >> In the packit project, we work in source-git repositories. These are
> > >> pretty much upstream repositories combined with Fedora downstream
> > >> packaging files. An example: I recently added a project called nyancat
> > >> [n] to Fedora. I have worked [w] on packaging the project in the
> > >> GitHub repo and then just pushed the changes to dist-git using packit
> > >> tooling. These source-git repositories can live anywhere: we have
> > >> support for GitHub right now and are working on supporting pagure.
> > >>
> > >> Would there be an interest within the community, as opt-in, to have
> > >> such source-git repositories created for respective dist-git
> > >> repositories? The idea is that you would work in the source-git repo
> > >> and then let packit handle synchronization with a respective dist-git
> > >> repo. Our aim is to provide the contribution experience you have in
> > >> GitHub when working on your packages. Dist-git would still be the
> > >> authoritative source and a place where official builds are done - the
> > >> source-git repo would work as a way to collaborate. We also don’t have
> > >> plans right now to integrate packit into fedpkg.
> > > So, in my experience, source-git might be a workable solution for
> > > packages with *big* downstream modifications. However, for everything
> > > else, I think it's a way to make it easy to accrue technical debt and
> > > to do cargo-culting with downstream patches.
> > >
> > > The vast majority of packages has *no patches* (or at most, one or two
> > > of them)
> >
>
> (snip)
>
> > I don't really want to argue with this point, I tend to agree. Just out
> > of interest, do we have some statistics to support this? O:-)
>
> I did not have any stats when I wrote this, but now I do.
> Parsing the rawhide spec files from [0] for lines matching
> "^Patch[0-9]*:[ \t]*.*$", I get the following distribution:
>
> number of patches: number of packages
> total: 21970
> 0: 15638
> 1: 3287
> 2: 1232
> 3: 598
> 4: 325
> 5: 221
> 6: 154
> 7: 97
> 8: 83
> 9: 57
> 10: 41
> 11: 27
> 12: 26
> 13: 25
> 14: 13
> 15: 13
> 16: 14
> 17: 15
> 18: 5
> 19: 8
> 20: 2
> 21: 11
> 22: 2
> 23: 4
> 24: 4
> 25: 5
> 26: 3
> 27: 4
> 28: 5
> 29: 5
> 30: 2
> 31: 6
> 32: 4
> 33: 3
> 34: 1
> 35: 4
> 37: 2
> 38: 1
> 41: 1
> 42: 2
> 46: 1
> 47: 1
> 48: 3
> 49: 1
> 50: 2
> 51: 1
> 53: 1
> 54: 1
> 66: 1
> 68: 1
> 71: 1
> 75: 1
> 78: 1
> 79: 1
> 85: 1
> 127: 1
> 170: 1
>
> In relative terms:
>
> - 71% of packages have ZERO patches
> - 15% have ONE patch
> - 5% have TWO patches
> - 3% have THREE patches
> - 5% have MORE than THREE patches
>
> Most packages have none (71%) - or at most two - patches (91%, my
> original "guess" for "vast majority"), some have 3-5 patches (5%), and
> a minority (4%) has six patches or more. So it seems this backs up my
> claim :)

These are some great stats!

But I would like to note that exploded repos (or source-git repos)
have at least two other advantages.

1) they consume less space than tarballs for each version because
objects in git repo are deduplicated
2) instead of downloading/uploading tarballs,

Non-responsive maintainer: jfch2222

[Christian Kellner]

Hi all,

I am trying to get a hold of "jfch", since I need "inih" to be 
updated in order to update gamemode:


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

Anybody knows how to contact them?

Cheers,
CK

___
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: Can we distribute modular .repo files in a separate package?

[Leigh Scott]

+1
___
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: Proposal: Add "Feedback" section to change proposal template

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 06, 2020 at 04:53:58PM +0200, Miro Hrončok wrote:
> On 06. 05. 20 16:31, Ben Cotton wrote:
> >On Wed, May 6, 2020 at 4:03 AM Vít Ondruch  wrote:
> >>I don't know, I am somewhat ambivalent on this. I am not sure who is
> >>going to collect the feedback there. Will it be the owner of the change
> >>or somebody else?
> >The owner of the change would be responsible for it, but they may
> >delegate that to someone for contentious issues as described in the
> >proposed text. In an ideal world, I would love to have someone with
> >journalism-like experience whose job was to perform this kind of
> >summary (and perhaps summaries of our mailing lists more generally). I
> >don't see that happening.
> 
> BTW LWN does a great job at summarizing devel list discussions.
> 
> https://lwn.net/Articles/805180/
> https://lwn.net/Articles/792718/
> https://lwn.net/Articles/811369/
> https://lwn.net/Articles/817426/
> https://lwn.net/Articles/729366/
> 
> (Random sample where I am involved.)

We can add a link to the lwn article (when there's one for some
change) or to other distros when they do something similar in the
feedback section too.

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: Is dist-git a good place for work?

[Kamil Dudka]

On Wednesday, May 6, 2020 4:35:11 PM CEST Vít Ondruch wrote:
> I am not concerned about remote branches disappearing. I am concerned
> about the complete opposite, when the remote branches appearing in my
> local copy and not disappearing once the remote copies go.

Isn't this exactly what `git remote prune` and `git fetch --prune` are for?

You can also use `git config` to make it the default behavior if you like.

Kamil

___
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: Review swaps

[Ankur Sinha]

Hi Jerry,

On Tue, May 05, 2020 15:16:03 -0600, Jerry James wrote:
> The latest version of gap-pkg-semigroups has two new dependencies.
> Who would like to swap reviews?  I need these two:
> 
> gap-pkg-ferret: https://bugzilla.redhat.com/show_bug.cgi?id=1830322
> gap-pkg-images: https://bugzilla.redhat.com/show_bug.cgi?id=1830323

I can review these. Would you be able to review these two if you have
some time please?

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


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: Proposal: Add "Feedback" section to change proposal template

[Miro Hrončok]

On 06. 05. 20 16:31, Ben Cotton wrote:

On Wed, May 6, 2020 at 4:03 AM Vít Ondruch  wrote:

I don't know, I am somewhat ambivalent on this. I am not sure who is
going to collect the feedback there. Will it be the owner of the change
or somebody else?

The owner of the change would be responsible for it, but they may
delegate that to someone for contentious issues as described in the
proposed text. In an ideal world, I would love to have someone with
journalism-like experience whose job was to perform this kind of
summary (and perhaps summaries of our mailing lists more generally). I
don't see that happening.


BTW LWN does a great job at summarizing devel list discussions.

https://lwn.net/Articles/805180/
https://lwn.net/Articles/792718/
https://lwn.net/Articles/811369/
https://lwn.net/Articles/817426/
https://lwn.net/Articles/729366/

(Random sample where I am involved.)

--
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: Can we distribute modular .repo files in a separate package?

[Vitaly Zaitsev via devel]

On 06.05.2020 15:12, Miro Hrončok wrote:
> Hello, as a Fedora user, who doesn't consume any modules, I'd like an
> easy way to disable modular repos to save some traffic (both for myself
> and on the mirrors).

I think this is a great idea.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Is dist-git a good place for work?

[Vít Ondruch]

Dne 06. 05. 20 v 16:15 Robbie Harwood napsal(a):
> Vít Ondruch  writes:
>
>> Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
>>> Tomas Tomecek  writes:
>>>
 Thank you all for raising all the questions and concerns.

 Before I reply, I'd like to stress that we are still in a prototype
 phase - not everything is solved (clearly) and at this point, we
 experiment with the workflow mostly.

 Luckily, force-pushes are not allowed in dist-git,
>>> That's a "current state of affairs" statement, not an ideal, as I
>>> understand it.  Assuming that force-pushes aren't allowed means we'll
>>> never be able to have, e.g., non-distro branches (for testing etc.)
>>> that we can force push.
>>>
>>> This has been a pain point with RHEL dist-git; among other things, it
>>> means that branches can't be deleted.
>> That this is problem only when you cannot use PRs. If you can use PRs,
>> pushing some random branches into remote git repo is the biggest sin
>> IMO, because while you might delete the branch in remote repo once it
>> is not needed, I have this branch very likely pulled to my repo and
>> the amount of branches in my local repo I have no clue about just
>> rises. So if deleting branches was a point of RHEL dist-git, then this
>> is sad news for me. Pushing branches was probably useful in CVS days,
>> but that should not be the case anymore.
> Well, your workflow is not my workflow.


Probably. But applying CVS workflow to Git workflow with PR is probably
not the best idea.


>
> I very often have to ship test builds (bugfixes, new features,
> compatibility testing, ...).  Yes, the build itself goes in COPR most of
> the time (or scratch on brewkoji), but the source needs to live
> somewhere - and I'd prefer it be "not just my laptop".


Right, then can live in your fork and that does not necessarily means
your local copy. More likely it is remote as it commonly understood.


>
> A branch disappearing on the remote doesn't break anything.  You don't
> lose your local copy.  Even a force push is pretty easy to adjust to
> (git reset or git rebase).  This happens all the time for development
> branches and I honestly doubt you notice.  Force pushes are only a
> problem if you're basing work on the branch.


I am not concerned about remote branches disappearing. I am concerned
about the complete opposite, when the remote branches appearing in my
local copy and not disappearing once the remote copies go.


>
> But sure, maybe I'm sinning by doing my job.  More pull requests won't
> help either way.


Honestly, this is not necessarily about PRs, but about work
organization. I would argue the doing pushes into your fork or into the
origin makes no difference for the workflow. At the end the changes has
to appear somehow in the origin/master and PR is just one of the mechanisms.

But doing pushes into origin/somebranch might have negative impact on my
workflow which is not what I like.

It has also negative impact on yourself, because then you want to be
able to force push to delete or update the branch, while in my fork, it
is not concern at all, because I am free to do there whatever I want,
including force push.


Vít





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

Re: Proposal: Add "Feedback" section to change proposal template

[Ben Cotton]

On Wed, May 6, 2020 at 4:03 AM Vít Ondruch  wrote:
>
> I don't know, I am somewhat ambivalent on this. I am not sure who is
> going to collect the feedback there. Will it be the owner of the change
> or somebody else?

The owner of the change would be responsible for it, but they may
delegate that to someone for contentious issues as described in the
proposed text. In an ideal world, I would love to have someone with
journalism-like experience whose job was to perform this kind of
summary (and perhaps summaries of our mailing lists more generally). I
don't see that happening.

>What will be the structure? Will it be just bunch or
> quotes from random sources?
>
It could be, although the idea is to have a curated summary. I don't
want to prescribe a format, at least not until we have some experience
with this, because the feedback summary could range from "no one
provided feedback" to "here are the 20 objections people had and how
we responded to them". That said, if anyone has some examples of
proposals (either in Fedora or other projects) that do a good job of
summarizing feedback, I'd be happy to add those as references in the
guidance.

> Wouldn't it be better to utilize the "discussion" tab/feature of the
> wiki instead?
>
We could do that, but including it in the text itself makes it more
portable if the change gets republished somewhere else (say, for
example, we move from Mediawiki to another wiki platform or we archive
accepted change proposals as static pages).

> Or wouldn't it be better to include the devel ML reference?
>
For simple feedback, that would be sufficient. For long threads, it
adds little value. I do include a link to the thread when submitting
changes to FESCo, but it would be helpful to have a quick summary to
read instead of re-reading the whole thread (and yes, someone could
write the summary to intentionally misrepresent the feedback, but I
trust the community to act in good faith).

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Can we distribute modular .repo files in a separate package?

[Christopher]

On Wed, May 6, 2020 at 9:13 AM Miro Hrončok  wrote:
>
> Hello, as a Fedora user, who doesn't consume any modules, I'd like an easy way
> to disable modular repos to save some traffic (both for myself and on the 
> mirrors).
>
> Disclaimer: I do not propose to change any defaults, just the delivery 
> mechanism.
>
> Currently, I can do it by editing all /etc/yum.repos.d/*-modular.repo and 
> changing:
>
>  enabled=1
>
> To:
>
>  enabled=0
>
> This has downsides: When the files are changed in next update, I won't get 
> them
> updated, because they are shipped as %config(noreplace). (If they were not
> shipped as %config(noreplace), it would be even worse, as my changes would be
> overridden.)
>
> Side note: It would be great if DNF supported system-repos in /usr/share and
> override options in /etc, but that is not (yet) the case.
>
> In order to not to have to resort to manually editing RPM-package shipped
> configuration, I'd like to have a better way of disabling modular repos, 
> namely
> via: sudo dnf remove fedora-repos-modular.
>
>
> Can we please have modular repos in separate package again?

I think this is a great idea. Although I do use rpmconf after every
update to resolve upstream merge conflicts with config files, I'd much
prefer to avoid the need to edit the files.

>
> Basically revert this plus some extra comps/kickstarts changes:
>
> https://src.fedoraproject.org/rpms/fedora-repos/c/7b32bee388d093c446017f1e33309d9b96b24e15
>
> Constraint: modular repos are still installed and enabled by default (e.g. 
> when
> we ship nonmodular repos in kickstarts/comps, we also ship modular).
>
> (Nonmodular repos package could possibly recommend modular repos package,
> although I am not so happy about that, due to rhbz#1699672.)
>
> What do you think?
>
> --
> 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
___
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: Proposal: Add "Feedback" section to change proposal template

[Zbigniew Jędrzejewski-Szmek]

I'm not the author of the proposal, but my take on this:

On Wed, May 06, 2020 at 10:02:19AM +0200, Vít Ondruch wrote:
> I don't know, I am somewhat ambivalent on this. I am not sure who is
> going to collect the feedback there. Will it be the owner of the change
> or somebody else? What will be the structure? Will it be just bunch or
> quotes from random sources?
Yes, the idea is that the author(s) of the change or some people
working in coordination with the authors will collect and succinctly
summarize feedback and the rejected options.

> Wouldn't it be better to utilize the "discussion" tab/feature of the
> wiki instead?
It's much less visible and the idea is to have items summarized.
This is in parallel to the Change itself: we want the Change page to
be self-contained, and we don't just refer the reader to the discussion
on the mailing list. The Change page is adjusted to incorporate feedback.

> Or wouldn't it be better to include the devel ML reference?
The ML reference is added automatically by FPM, but our threads are
often very long and circuitous. 

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: Is dist-git a good place for work?

[Robbie Harwood]

Vít Ondruch  writes:

> Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
>> Tomas Tomecek  writes:
>>
>>> Thank you all for raising all the questions and concerns.
>>>
>>> Before I reply, I'd like to stress that we are still in a prototype
>>> phase - not everything is solved (clearly) and at this point, we
>>> experiment with the workflow mostly.
>>>
>>> Luckily, force-pushes are not allowed in dist-git,
>>
>> That's a "current state of affairs" statement, not an ideal, as I
>> understand it.  Assuming that force-pushes aren't allowed means we'll
>> never be able to have, e.g., non-distro branches (for testing etc.)
>> that we can force push.
>>
>> This has been a pain point with RHEL dist-git; among other things, it
>> means that branches can't be deleted.
>
> That this is problem only when you cannot use PRs. If you can use PRs,
> pushing some random branches into remote git repo is the biggest sin
> IMO, because while you might delete the branch in remote repo once it
> is not needed, I have this branch very likely pulled to my repo and
> the amount of branches in my local repo I have no clue about just
> rises. So if deleting branches was a point of RHEL dist-git, then this
> is sad news for me. Pushing branches was probably useful in CVS days,
> but that should not be the case anymore.

Well, your workflow is not my workflow.

I very often have to ship test builds (bugfixes, new features,
compatibility testing, ...).  Yes, the build itself goes in COPR most of
the time (or scratch on brewkoji), but the source needs to live
somewhere - and I'd prefer it be "not just my laptop".

A branch disappearing on the remote doesn't break anything.  You don't
lose your local copy.  Even a force push is pretty easy to adjust to
(git reset or git rebase).  This happens all the time for development
branches and I honestly doubt you notice.  Force pushes are only a
problem if you're basing work on the branch.

But sure, maybe I'm sinning by doing my job.  More pull requests won't
help either way.

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: Can we distribute modular .repo files in a separate package?

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 06, 2020 at 03:12:08PM +0200, Miro Hrončok wrote:
> Can we please have modular repos in separate package again?
> 
> Basically revert this plus some extra comps/kickstarts changes:
> 
> https://src.fedoraproject.org/rpms/fedora-repos/c/7b32bee388d093c446017f1e33309d9b96b24e15
> 
> Constraint: modular repos are still installed and enabled by default
> (e.g. when we ship nonmodular repos in kickstarts/comps, we also
> ship modular).
> 
> (Nonmodular repos package could possibly recommend modular repos
> package, although I am not so happy about that, due to
> rhbz#1699672.)
> 
> What do you think?

Yep, I think it's reasonable. Gives the flexibility to opt out of modules
for people who want to, and does change much (as long as the upgrade path
is done correctly) for people using modules.

When the package split is done correctly, with Obsoletes in both new
packages, upgrades will be handled correctly, and
Recommends:fedora-repos-modular should not be necessary. But if people
want to have the Recommends, I think it can be added, because it's not
something worth fighting over. (With Recommends, this will be slightly
less useful to opt-out users, but still better than status quo.)

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: Can we distribute modular .repo files in a separate package?

[Neal Gompa]

On Wed, May 6, 2020 at 9:39 AM Dan Čermák
 wrote:
>
> Miro Hrončok  writes:
>
> >
> > Side note: It would be great if DNF supported system-repos in /usr/share and
> > override options in /etc, but that is not (yet) the case.
>
> slightly off-topic, but I'm just going to leave libeconf (a library to
> achieve exactly that easily) here:
> https://github.com/openSUSE/libeconf
>

We do have libeconf in Fedora: https://src.fedoraproject.org/rpms/libeconf

It's just waiting on DNF team to use 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

Re: Can we distribute modular .repo files in a separate package?

[Dan Čermák]

Miro Hrončok  writes:

>
> Side note: It would be great if DNF supported system-repos in /usr/share and 
> override options in /etc, but that is not (yet) the case.

slightly off-topic, but I'm just going to leave libeconf (a library to
achieve exactly that easily) here:
https://github.com/openSUSE/libeconf


Cheers,

Dan


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: Is dist-git a good place for work?

[Vít Ondruch]

Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a):
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
>>
>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
>>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
>>>
>>> Hi Tomas,
>>>
>>> I'll respond below with some of my experiences and opinions ...
>>>
 Let’s talk about dist-git, as a place where we work. For us,
 packagers, it’s a well-known place. Yet for newcomers, it may take a
 while to learn all the details. Even though we operate with projects
 in a dist-git repository, the layout doesn’t resemble the respective
 upstream project.

 There is a multitude of tasks we tend to perform in a dist-git repo:
 * Bumping a release field for sake of a rebuild.
 * Updating to the latest upstream release.
 * Resolving CVEs.
 * Fixing bugs by…
   * Changing a spec file.
   * Pulling a commit from upstream.
   * Or even backporting a commit.
 * And more...

 For some tasks, the workflow is just fine and pretty straightforward.
 But for the other, it’s very gruesome - the moment you need to touch
 patch files, the horror comes in. The fact that we operate with patch
 files, in a git repository, is just mind-boggling to me.

 Luckily, we have tooling which supports the repository layout -
 `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
 easily inspect the source tree or make sure your local change builds.

 Where am I getting with this?

 Over the years there have been multiple tools created to improve the
 development experience:
 rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
 the way Fedora kernel developers work on kernel [k]).
>>> (snip)
>>>
 In the packit project, we work in source-git repositories. These are
 pretty much upstream repositories combined with Fedora downstream
 packaging files. An example: I recently added a project called nyancat
 [n] to Fedora. I have worked [w] on packaging the project in the
 GitHub repo and then just pushed the changes to dist-git using packit
 tooling. These source-git repositories can live anywhere: we have
 support for GitHub right now and are working on supporting pagure.

 Would there be an interest within the community, as opt-in, to have
 such source-git repositories created for respective dist-git
 repositories? The idea is that you would work in the source-git repo
 and then let packit handle synchronization with a respective dist-git
 repo. Our aim is to provide the contribution experience you have in
 GitHub when working on your packages. Dist-git would still be the
 authoritative source and a place where official builds are done - the
 source-git repo would work as a way to collaborate. We also don’t have
 plans right now to integrate packit into fedpkg.
>>> So, in my experience, source-git might be a workable solution for
>>> packages with *big* downstream modifications. However, for everything
>>> else, I think it's a way to make it easy to accrue technical debt and
>>> to do cargo-culting with downstream patches.
>>>
>>> The vast majority of packages has *no patches* (or at most, one or two
>>> of them)
> (snip)
>
>> I don't really want to argue with this point, I tend to agree. Just out
>> of interest, do we have some statistics to support this? O:-)
> I did not have any stats when I wrote this, but now I do.
> Parsing the rawhide spec files from [0] for lines matching
> "^Patch[0-9]*:[ \t]*.*$", I get the following distribution:
>
> number of patches: number of packages
> total: 21970
> 0: 15638
> 1: 3287
> 2: 1232
> 3: 598
> 4: 325
> 5: 221
> 6: 154
> 7: 97
> 8: 83
> 9: 57
> 10: 41
> 11: 27
> 12: 26
> 13: 25
> 14: 13
> 15: 13
> 16: 14
> 17: 15
> 18: 5
> 19: 8
> 20: 2
> 21: 11
> 22: 2
> 23: 4
> 24: 4
> 25: 5
> 26: 3
> 27: 4
> 28: 5
> 29: 5
> 30: 2
> 31: 6
> 32: 4
> 33: 3
> 34: 1
> 35: 4
> 37: 2
> 38: 1
> 41: 1
> 42: 2
> 46: 1
> 47: 1
> 48: 3
> 49: 1
> 50: 2
> 51: 1
> 53: 1
> 54: 1
> 66: 1
> 68: 1
> 71: 1
> 75: 1
> 78: 1
> 79: 1
> 85: 1
> 127: 1
> 170: 1
>
> In relative terms:
>
> - 71% of packages have ZERO patches
> - 15% have ONE patch
> - 5% have TWO patches
> - 3% have THREE patches
> - 5% have MORE than THREE patches
>
> Most packages have none (71%) - or at most two - patches (91%, my
> original "guess" for "vast majority"), some have 3-5 patches (5%), and
> a minority (4%) has six patches or more. So it seems this backs up my
> claim :)
>
> Fabio


Thank you very much indeed!


Vít

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

Can we distribute modular .repo files in a separate package?

[Miro Hrončok]

Hello, as a Fedora user, who doesn't consume any modules, I'd like an easy way 
to disable modular repos to save some traffic (both for myself and on the mirrors).


Disclaimer: I do not propose to change any defaults, just the delivery 
mechanism.

Currently, I can do it by editing all /etc/yum.repos.d/*-modular.repo and 
changing:

enabled=1

To:

enabled=0

This has downsides: When the files are changed in next update, I won't get them 
updated, because they are shipped as %config(noreplace). (If they were not 
shipped as %config(noreplace), it would be even worse, as my changes would be 
overridden.)


Side note: It would be great if DNF supported system-repos in /usr/share and 
override options in /etc, but that is not (yet) the case.


In order to not to have to resort to manually editing RPM-package shipped 
configuration, I'd like to have a better way of disabling modular repos, namely 
via: sudo dnf remove fedora-repos-modular.



Can we please have modular repos in separate package again?

Basically revert this plus some extra comps/kickstarts changes:

https://src.fedoraproject.org/rpms/fedora-repos/c/7b32bee388d093c446017f1e33309d9b96b24e15

Constraint: modular repos are still installed and enabled by default (e.g. when 
we ship nonmodular repos in kickstarts/comps, we also ship modular).


(Nonmodular repos package could possibly recommend modular repos package, 
although I am not so happy about that, due to rhbz#1699672.)


What do you think?

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

Fedora-Cloud-31-20200506.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
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: Is dist-git a good place for work?

[Miroslav Suchý]

Dne 04. 05. 20 v 17:05 Tomas Tomecek napsal(a):
> The main reason I am sending this is to gather feedback from all of
> you whether there is an interest in such a workflow. 
I am +1 as long as:

a) this is opt-in (cannot imagine anything else)
b) you resolve the gordic knot of easy sync of changes from dist-git back to 
source-git. It must be easy for both
maintainer and for proven packager doing the changes directly in dist-git.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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: Is dist-git a good place for work?

[Miroslav Suchý]

Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> So, in my experience, source-git might be a workable solution for
> packages with *big* downstream modifications. 

Big +1. Been there, done that (with Tito).

> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just one
> commit), or "git format-patch -o ../" if there are multiple commits,
> and then delete the exploded sources again.

When I am forced to do this, I quite often spend a lot of time at resolving 
conflicts. I can easily spend half of the
day on it. While when I am working with source-git I spent like 30 seconds on 
whole release process.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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: Is dist-git a good place for work?

[Fabio Valentini]

On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
>
>
> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> > On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
> >
> > Hi Tomas,
> >
> > I'll respond below with some of my experiences and opinions ...
> >
> >> Let’s talk about dist-git, as a place where we work. For us,
> >> packagers, it’s a well-known place. Yet for newcomers, it may take a
> >> while to learn all the details. Even though we operate with projects
> >> in a dist-git repository, the layout doesn’t resemble the respective
> >> upstream project.
> >>
> >> There is a multitude of tasks we tend to perform in a dist-git repo:
> >> * Bumping a release field for sake of a rebuild.
> >> * Updating to the latest upstream release.
> >> * Resolving CVEs.
> >> * Fixing bugs by…
> >>   * Changing a spec file.
> >>   * Pulling a commit from upstream.
> >>   * Or even backporting a commit.
> >> * And more...
> >>
> >> For some tasks, the workflow is just fine and pretty straightforward.
> >> But for the other, it’s very gruesome - the moment you need to touch
> >> patch files, the horror comes in. The fact that we operate with patch
> >> files, in a git repository, is just mind-boggling to me.
> >>
> >> Luckily, we have tooling which supports the repository layout -
> >> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
> >> easily inspect the source tree or make sure your local change builds.
> >>
> >> Where am I getting with this?
> >>
> >> Over the years there have been multiple tools created to improve the
> >> development experience:
> >> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> >> the way Fedora kernel developers work on kernel [k]).
> > (snip)
> >
> >> In the packit project, we work in source-git repositories. These are
> >> pretty much upstream repositories combined with Fedora downstream
> >> packaging files. An example: I recently added a project called nyancat
> >> [n] to Fedora. I have worked [w] on packaging the project in the
> >> GitHub repo and then just pushed the changes to dist-git using packit
> >> tooling. These source-git repositories can live anywhere: we have
> >> support for GitHub right now and are working on supporting pagure.
> >>
> >> Would there be an interest within the community, as opt-in, to have
> >> such source-git repositories created for respective dist-git
> >> repositories? The idea is that you would work in the source-git repo
> >> and then let packit handle synchronization with a respective dist-git
> >> repo. Our aim is to provide the contribution experience you have in
> >> GitHub when working on your packages. Dist-git would still be the
> >> authoritative source and a place where official builds are done - the
> >> source-git repo would work as a way to collaborate. We also don’t have
> >> plans right now to integrate packit into fedpkg.
> > So, in my experience, source-git might be a workable solution for
> > packages with *big* downstream modifications. However, for everything
> > else, I think it's a way to make it easy to accrue technical debt and
> > to do cargo-culting with downstream patches.
> >
> > The vast majority of packages has *no patches* (or at most, one or two
> > of them)
>

(snip)

> I don't really want to argue with this point, I tend to agree. Just out
> of interest, do we have some statistics to support this? O:-)

I did not have any stats when I wrote this, but now I do.
Parsing the rawhide spec files from [0] for lines matching
"^Patch[0-9]*:[ \t]*.*$", I get the following distribution:

number of patches: number of packages
total: 21970
0: 15638
1: 3287
2: 1232
3: 598
4: 325
5: 221
6: 154
7: 97
8: 83
9: 57
10: 41
11: 27
12: 26
13: 25
14: 13
15: 13
16: 14
17: 15
18: 5
19: 8
20: 2
21: 11
22: 2
23: 4
24: 4
25: 5
26: 3
27: 4
28: 5
29: 5
30: 2
31: 6
32: 4
33: 3
34: 1
35: 4
37: 2
38: 1
41: 1
42: 2
46: 1
47: 1
48: 3
49: 1
50: 2
51: 1
53: 1
54: 1
66: 1
68: 1
71: 1
75: 1
78: 1
79: 1
85: 1
127: 1
170: 1

In relative terms:

- 71% of packages have ZERO patches
- 15% have ONE patch
- 5% have TWO patches
- 3% have THREE patches
- 5% have MORE than THREE patches

Most packages have none (71%) - or at most two - patches (91%, my
original "guess" for "vast majority"), some have 3-5 patches (5%), and
a minority (4%) has six patches or more. So it seems this backs up my
claim :)

Fabio

[0]: https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz

> > , and uses *unmodified upstream sources / tarballs*.
> > I never want to deal with exploded upstream sources, unless I'm
> > creating a patch for something.
> >
> > When it's an upstream commit that applies cleanly to the latest
> > sources, I'll just add it in the .spec file, and let the tooling
> > handle the rest. It's pretty neat to directly link to upstream commits
> > (it works with github and gitlab and pagure, as far as I know), and
> > let our tooling (spectool, fedpkg) do everything else. I don't have to
> > download, patch, or touch so

Fedora-Cloud-32-20200506.0 compose check report

[Fedora compose checker]

No missing expected images.

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

ID: 593706  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/593706
-- 
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: sorting of git N-V-R tags in rpm package repositories

[clime]

> Well, if you don't push the tag and you do a build, you will get N-V-R
> like foo-1.0-1.git.3.abcdef12. E.g. it won't be a clean N-V-R because

I meant "I.e." there, not "E.g."...just to be clear.

> it doesn't come from a tagged commit. If you push a tag and repeat a
> build from that same commit (or from that tag, see above), you will
> now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{
> git_dir_release }}} is used in the spec file to enable the automatic
> generation of release. The annotated tags represent releases. if you
> build an unreleased commit, you get a "work-in-progress" N-V-R and
> also changelog won't be populated with the latest changes. This
> workflow needs "pushing a tag" to be a build trigger so that it is
> convenient.
>
> Best regards
> clime
>
> >
> > Thanks,
> > Florian
___
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: sorting of git N-V-R tags in rpm package repositories

[clime]

On Wed, 6 May 2020 at 11:00, Florian Weimer  wrote:
>
> >> >> Tags can also be added retroactively and backdated.  These things
> >> >> conflict with the advantages you list (in particular, with NVR
> >> >> auto-generation, git is not the sole source of truth).
> >> >
> >> > If the tag ordering function is done properly, I believe even
> >> > retroactive tagging (i.e. tagging into past) and/or tag backdating
> >> > would be supported and NVR auto-generation would work correctly. So I
> >> > don't think it needs to conflict. But can you perhaps expand more on
> >> > "Tags can also be added retroactively and backdated", please?
> >> > I.e. why/when would one do that.
> >>
> >> No, you can push tags with incorrect dates.  This can change the
> >> auto-generation.
> >
> > It really depends on what the tag ordering function is. If the
> > function does not consider dates at all, this wouldn't be a problem.
>
> The commit graph is ordered, but everything else is not.  Tags (whether
> annotated or not) are outside the commit graph, so their order is not
> fixed.

Well, the assumption is that the order of tags will become fixed by
our tooling, i.e. that we will supply the ordering.

>
> I think this is different with Mercurial, where tags are part of the
> commit graph.

Interesting, I will look into it.

>
> >> You can only avoid this if you use data from commits (both current and
> >> earlier) *on the same branch* exclusively for generating metadata (or
> >> hash-linked from there).  Everything else can get of sync and change
> >> over time even if the commit hash stays the same, so the repository
> >> state at a specific commit hash is longer the sole source of truth.
> >> (Because you need to reconstruct that other state *at the right time*.)
> >
> > What do you mean by "everything else which can get out of sync and
> > change"? If you are talking about tags (or refs in general), it's true
> > that you can add tags into past which may or may not affect
> > auto-generation depending on the ordering function.
>
> What kind of ordering function could tell apart a retroactively added
> tag and one that was there when the build was submitted?

Generally speaking, yes, N-V-R and changelog will be affected by
adding a tag retroactively.
I.e. you build some commit, you add some tag, you build the same
commit again => NVR and changelog can now be different.

What can be done here, is that when we build from a tag, build system
will pass that tag name (or tag object ID) to the tooling through
environment so the tooling will use that provided tag as the "latest
one" instead of identifying it through sort.
I.e. if you build from a tag, you will always get the same N-V-R over
and over again, no matter what happens in time. You can get a
different changelog, however, if someone tags some older commit by an
older version, i.e. my current version of software is foo-1.1-3 but
someone wants me to do an official release/build of an older version
for some reason, so i'll tag an old commit with e.g. foo-1.0-2 and the
changelog record for foo-1.0-2 will now additionally appear in all new
builds.

But I personally think that N-V-R uniqueness is a more important
property than N-V-R sameness when you build the same commit across
time repeteadly. N-V-R sameness for tagged commits can be implemented
by adding a special handling of tag/release builds as opposed to
testing commit builds for which N-V-R sameness won't hold. Changelog
sameness can't also be assured (at least not easily) but it may or
might not be an issue.

By N-V-R uniqueness I mean that you can't get the same N-V-R for two
builds of two different commits.

>
> >> That's why I proposed to auto-generate release numbers and changelogs
> >> based on the commits going back to the last Release: line and %changelog
> >> section update in the spec file.  That would be stable (unless the tool
> >> changes how it generates those spec file parts).
> >
> > I don't think you can automatically generate %changelog and Release
> > and at the same time base their auto-generation on their last change
> > in spec file in git history. That somehow doesn't seem that it would
> > work.
>
> I don't know of any problems, and I have implemented this in the past
> (although in a very different context).

I would need and like to see the implementation so that I understand
what you meant exactly.

>
> > Tagging into past is imho rather a theoretical use-case but useful to
> > consider.
>
> Is it?  It can easily happen if you forget to push a tag and then do a
> build, and push it later.

Well, if you don't push the tag and you do a build, you will get N-V-R
like foo-1.0-1.git.3.abcdef12. E.g. it won't be a clean N-V-R because
it doesn't come from a tagged commit. If you push a tag and repeat a
build from that same commit (or from that tag, see above), you will
now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{
git_dir_release }}} is used in the spec file to enable the automatic
gen

Re: Is dist-git a good place for work?

[Tomas Tomecek]

On Wed, May 6, 2020 at 11:31 AM Vít Ondruch  wrote:
>
> This is a bit of irony:
>
> ~~~
>
>   post-upstream-clone:
>   - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/python3.spec
>   - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/idle3.appdata.xml
>   - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/idle3.desktop
>   - curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/check-pyc-timestamps.py
>   # packit will apply the patches itself
>   - sed '/^Patch/d' -i python3.spec
>   # patckit uses %autosetup - and yes, the line below doesn't make sense
> given
>   # how python3's spec look, this is just a demonstration of packit's
> functionality
>   - sed '/^%patch/d' -i python3.spec
>
> ~~~
>
> So why does not Packit do this by itself? Just the `curl -O
> https://src.fedoraproject.org/rpms/python3/raw/master/f/python3.spec`
> should be kept in some form 
>
>
> Vít

Víťo, you are getting off track here. I'd love to focus the discussion
around dist-git and source-git workflows, not talking about the
internals of how packit works. If you want to discuss such topic,
please start a new thread, or even better, open an upstream issue [1]
and we can have the discussion there.


[1] https://github.com/packit-service/packit/issues/new


Thank you,
Tomas
___
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: Is dist-git a good place for work?

[Tomas Tomecek]

On Tue, May 5, 2020 at 7:25 PM Neal Gompa  wrote:
>
> Hello Tomas,
>
> I have a fair bit of experience with operating in both so-called
> "source-git" and "dist-git" workflows. I've known them by the names of
> "merged-source" and "split-source" trees respectively, so forgive me
> if I use that terminology, since it makes conveying the point a bit
> easier.

Thank you for the description and context.

I'm actually not a fan of the term "source-git" honestly - I'd love to
call it "upstream git" since that's what we are trying to do - use the
repository layout which is well-known in the upstream community.

> Obviously, you understand the advantages of this approach (managing
> patches is easier as Git commits, you have access to rebase and merge
> logic for code, etc.). However, in my experience seeing these in use
> at a large scale, the major downside is that it inhibits the need to
> work with the software developers of the project to contribute
> improvements. Sometimes this is unavoidable (the RHEL ipa, kernel,
> rpm, samba, and systemd packages come to mind here), but most of the
> time, I don't see these large fork trees being necessary in RHEL or
> Fedora. In general, where I've seen this implemented on a distro-wide
> scale, the contribution levels from the distribution drop by a large
> margin. There is also the added issue of it becoming a lot more
> difficult to sort through the differences between upstream and
> downstream changes. They all look the same in the merged-source model,
> which makes it hard for others to discover Fedora-only changes and
> potentially help to bring those changes upstream.

I'd say this is a good point and I still recall as we discussed this
in person on Summit last year.

What I really love about Fedora (and Red Hat) is the upstream first
principle - when a downstream bug (or just a problem) appears, the
maintainers are focused on bringing the solution upstream as the first
thing to do. I can still see how people do this and I'm just so proud.

Neal, you're right that with the source-git model, maintainers may be
tempted not to bring the changes upstream - I'd say that should be a
point where we should introduce changes to the system to motivate
people to follow upstream first and help them achieve it.

> There is also that any source-git/merged-source model would require
> forking into Fedora's server (src.fedoraproject.org) in a new
> namespace (sources) and have the same restrictions that the
> split-source/dist-git model has (no rebasing, no branch deletion, no
> tag updating, etc.). Not doing so would cause major problems in terms
> of reproducible builds, but this also makes working with the source
> tree a lot more painful. Perhaps if we never directly built from it
> and exported released sources as tarballs, then it wouldn't be
> necessary, but those are details to figure out if we move forward with
> this idea.

+1


Neal, thank you for the great feedback and thorough insights,
Tomas
___
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: Is dist-git a good place for work?

[Vít Ondruch]

Dne 06. 05. 20 v 11:19 Tomas Tomecek napsal(a):
> On Tue, May 5, 2020 at 6:16 PM Miro Hrončok  wrote:
 In what way does keeping the spec file in our fork help us?
>>> (speechless for like a minute)
>> I don't really understand this comment. Speechless because our workflow is 
>> tedious?
> I just couldn't understand why you are asking me about source-git when
> you already track your downstream patches as git commits :D
>
>>> Don't you wanna create (S)RPMs out of that repository? Don't you wanna
>>> be sure that when you add a change to that repository it builds fine
>>> on rawhide and the latest stable fedora?
>> That would be cool. I don't understand why do I have to keep the spec file in
>> there for that.
> You don't.
>
> With these ~20 lines you can get RPM builds for every PR in chroots of
> your choice:
>
> https://github.com/TomasTomecek/cpython/pull/1


This is a bit of irony:

~~~

  post-upstream-clone:
  - curl -O
https://src.fedoraproject.org/rpms/python3/raw/master/f/python3.spec
  - curl -O
https://src.fedoraproject.org/rpms/python3/raw/master/f/idle3.appdata.xml
  - curl -O
https://src.fedoraproject.org/rpms/python3/raw/master/f/idle3.desktop
  - curl -O
https://src.fedoraproject.org/rpms/python3/raw/master/f/check-pyc-timestamps.py
  # packit will apply the patches itself
  - sed '/^Patch/d' -i python3.spec
  # patckit uses %autosetup - and yes, the line below doesn't make sense
given
  # how python3's spec look, this is just a demonstration of packit's
functionality
  - sed '/^%patch/d' -i python3.spec

~~~

So why does not Packit do this by itself? Just the `curl -O
https://src.fedoraproject.org/rpms/python3/raw/master/f/python3.spec`
should be kept in some form 


Vít


>
> (the build is failing, even SRPM can't be created, seems like there is
> a file in the repo which can't be processed by tar & gzip, need to
> take a closer look)
>
> The spec file is being fetched from rawhide's dist-git for every
> build. Your use case is a little bit more complex since you patch
> conditionally so we'd probably need a mechanism in packit:
> 1. not to add 'Patch: 0001...' lines into spec
> 2. not touch %setup line
> 3. and map respective git commits to Patch lines within a spec
>
> so that all would work well for your use case - there are also
> different ways how to solve it but that would be a lot of typing
>
>
> Tomas
> ___
> 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: Is dist-git a good place for work?

[Nicolas Mailhot via devel]

Hi,

Also Fedora is driving a lot of spec syntax enhancements, both at the
rpm and the macro layer. Pushing spec files upstream is a sure way to
freeze spec syntax in stone and have everything behave in rpm 3.x mode
(with rpm 3.x limitations) 20 years from now.

The whole thing is just a variation of the bundling/vendoring aproach,
relocate everything in a single private place to avoid the hassle of
interacting with the upstreams the project depends on, with the usual
result that the apex of the vendored pyramid is well maintained,
everything bellow suffers, and the project becomes impossible to
contribute to independently without cloning its complex closed garden
environment.

Every Fedora package has a dual upstream, the source project for the
project code, and Fedora rpm/macro enhancements for the spec code.

Regards,

-- 
Nicolas Mailhot
___
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: Is dist-git a good place for work?

[Tomas Tomecek]

On Tue, May 5, 2020 at 6:16 PM Miro Hrončok  wrote:
>
> >> In what way does keeping the spec file in our fork help us?
> > (speechless for like a minute)
>
> I don't really understand this comment. Speechless because our workflow is 
> tedious?

I just couldn't understand why you are asking me about source-git when
you already track your downstream patches as git commits :D

> > Don't you wanna create (S)RPMs out of that repository? Don't you wanna
> > be sure that when you add a change to that repository it builds fine
> > on rawhide and the latest stable fedora?
>
> That would be cool. I don't understand why do I have to keep the spec file in
> there for that.

You don't.

With these ~20 lines you can get RPM builds for every PR in chroots of
your choice:

https://github.com/TomasTomecek/cpython/pull/1

(the build is failing, even SRPM can't be created, seems like there is
a file in the repo which can't be processed by tar & gzip, need to
take a closer look)

The spec file is being fetched from rawhide's dist-git for every
build. Your use case is a little bit more complex since you patch
conditionally so we'd probably need a mechanism in packit:
1. not to add 'Patch: 0001...' lines into spec
2. not touch %setup line
3. and map respective git commits to Patch lines within a spec

so that all would work well for your use case - there are also
different ways how to solve it but that would be a lot of typing


Tomas
___
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: sorting of git N-V-R tags in rpm package repositories

[Florian Weimer]

>> >> Tags can also be added retroactively and backdated.  These things
>> >> conflict with the advantages you list (in particular, with NVR
>> >> auto-generation, git is not the sole source of truth).
>> >
>> > If the tag ordering function is done properly, I believe even
>> > retroactive tagging (i.e. tagging into past) and/or tag backdating
>> > would be supported and NVR auto-generation would work correctly. So I
>> > don't think it needs to conflict. But can you perhaps expand more on
>> > "Tags can also be added retroactively and backdated", please?
>> > I.e. why/when would one do that.
>>
>> No, you can push tags with incorrect dates.  This can change the
>> auto-generation.
>
> It really depends on what the tag ordering function is. If the
> function does not consider dates at all, this wouldn't be a problem.

The commit graph is ordered, but everything else is not.  Tags (whether
annotated or not) are outside the commit graph, so their order is not
fixed.

I think this is different with Mercurial, where tags are part of the
commit graph.

>> You can only avoid this if you use data from commits (both current and
>> earlier) *on the same branch* exclusively for generating metadata (or
>> hash-linked from there).  Everything else can get of sync and change
>> over time even if the commit hash stays the same, so the repository
>> state at a specific commit hash is longer the sole source of truth.
>> (Because you need to reconstruct that other state *at the right time*.)
>
> What do you mean by "everything else which can get out of sync and
> change"? If you are talking about tags (or refs in general), it's true
> that you can add tags into past which may or may not affect
> auto-generation depending on the ordering function.

What kind of ordering function could tell apart a retroactively added
tag and one that was there when the build was submitted?

>> That's why I proposed to auto-generate release numbers and changelogs
>> based on the commits going back to the last Release: line and %changelog
>> section update in the spec file.  That would be stable (unless the tool
>> changes how it generates those spec file parts).
>
> I don't think you can automatically generate %changelog and Release
> and at the same time base their auto-generation on their last change
> in spec file in git history. That somehow doesn't seem that it would
> work.

I don't know of any problems, and I have implemented this in the past
(although in a very different context).

> Tagging into past is imho rather a theoretical use-case but useful to
> consider.

Is it?  It can easily happen if you forget to push a tag and then do a
build, and push it later.

Thanks,
Florian
___
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: Is dist-git a good place for work?

[Vít Ondruch]

Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  wrote:
>
> Hi Tomas,
>
> I'll respond below with some of my experiences and opinions ...
>
>> Let’s talk about dist-git, as a place where we work. For us,
>> packagers, it’s a well-known place. Yet for newcomers, it may take a
>> while to learn all the details. Even though we operate with projects
>> in a dist-git repository, the layout doesn’t resemble the respective
>> upstream project.
>>
>> There is a multitude of tasks we tend to perform in a dist-git repo:
>> * Bumping a release field for sake of a rebuild.
>> * Updating to the latest upstream release.
>> * Resolving CVEs.
>> * Fixing bugs by…
>>   * Changing a spec file.
>>   * Pulling a commit from upstream.
>>   * Or even backporting a commit.
>> * And more...
>>
>> For some tasks, the workflow is just fine and pretty straightforward.
>> But for the other, it’s very gruesome - the moment you need to touch
>> patch files, the horror comes in. The fact that we operate with patch
>> files, in a git repository, is just mind-boggling to me.
>>
>> Luckily, we have tooling which supports the repository layout -
>> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
>> easily inspect the source tree or make sure your local change builds.
>>
>> Where am I getting with this?
>>
>> Over the years there have been multiple tools created to improve the
>> development experience:
>> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
>> the way Fedora kernel developers work on kernel [k]).
> (snip)
>
>> In the packit project, we work in source-git repositories. These are
>> pretty much upstream repositories combined with Fedora downstream
>> packaging files. An example: I recently added a project called nyancat
>> [n] to Fedora. I have worked [w] on packaging the project in the
>> GitHub repo and then just pushed the changes to dist-git using packit
>> tooling. These source-git repositories can live anywhere: we have
>> support for GitHub right now and are working on supporting pagure.
>>
>> Would there be an interest within the community, as opt-in, to have
>> such source-git repositories created for respective dist-git
>> repositories? The idea is that you would work in the source-git repo
>> and then let packit handle synchronization with a respective dist-git
>> repo. Our aim is to provide the contribution experience you have in
>> GitHub when working on your packages. Dist-git would still be the
>> authoritative source and a place where official builds are done - the
>> source-git repo would work as a way to collaborate. We also don’t have
>> plans right now to integrate packit into fedpkg.
> So, in my experience, source-git might be a workable solution for
> packages with *big* downstream modifications. However, for everything
> else, I think it's a way to make it easy to accrue technical debt and
> to do cargo-culting with downstream patches.
>
> The vast majority of packages has *no patches* (or at most, one or two
> of them)


I don't really want to argue with this point, I tend to agree. Just out
of interest, do we have some statistics to support this? O:-)


> , and uses *unmodified upstream sources / tarballs*.
> I never want to deal with exploded upstream sources, unless I'm
> creating a patch for something.
>
> When it's an upstream commit that applies cleanly to the latest
> sources, I'll just add it in the .spec file, and let the tooling
> handle the rest. It's pretty neat to directly link to upstream commits
> (it works with github and gitlab and pagure, as far as I know), and
> let our tooling (spectool, fedpkg) do everything else. I don't have to
> download, patch, or touch sources myself in any way for that.


Unfortunately, in Ruby world, this unfortunately works less and less,
because the released packages does not contain test suite these days. So
if there is fix for some feature and associated test, then the patch has
to be modified (the test part has to be stripped or split out).
Otherwise I like this approach as well.


>
> When I need to make changes that I am able to push back upstream, I
> don't do that in packaging, but fork upstream, do my changes, create a
> pull request, and again point my .spec file to the patches from there.
> No need to touch dist-git there, instead I'm working closely with
> upstream.
>
> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just one
> commit), or "git format-patch -o ../" if there are multiple commits,
> and then delete the exploded sources again.


Having infrastructure for exploding sources from the package would be
very interesting.

Vít



>
> I maintain ~400 packages in fedora, and the only one with substantial
> downstream modifications (

Re: Is dist-git a good place for work?

[Vít Ondruch]

Dne 05. 05. 20 v 18:42 Adam Williamson napsal(a):
> On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
>> On Tue, May 5, 2020 at 1:41 PM Petr Pisar  wrote:
>>> On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
 Petr, I should have probably stressed that our target is Fedora (or
 even all Red Hat operating systems). Yes, there are hundreds of
 distributions and we cannot solve their problems. We are open for
 collaboration though - we cannot drive changes in distributions which
 we don't know or use.

>>> If you only target Fedora, then it means that the same amount of Fedora
>>> maintainers will maintain twofold amount of repositories. Does it indeed 
>>> save
>>> work? What's the benefit of maintaining more repositories?
>> My personal expectation here would be that if I enabled source-git for
>> my packages, I wouldn't want to touch dist-git and only work in the
>> source-git repos. Yes, there would still be changes coming to
>> dist-git, and I'd inspect those from source-git. I'd even ask
>> contributors to use source-git for PR contributions if possible.
> To give a provenpackager perspective on this - it rarely turns out to
> be possible. Usually when we need to touch someone else's package, it's
> to deal with an urgent problem - say an unannounced soname bump that
> requires a bunch of packages to be rebuilt, a bug preventing a nightly
> compose from running or causing a serious problem in it, something like
> that.
>
> In those situations we usually want to fix the problem *now*, not
> "whenever someone has time to review the 'upstream' PR and merge it and
> do whatever they have to do to trigger a build 'downstream'".
>
> So when I'm trying to fix an urgent issue in a package that tries to
> keep its spec file elsewhere, I usually just fix it in dist-git and
> issue apologies later. I don't see a way this is ever going to not be
> the case unless you give all provenpackagers commit rights to the
> 'upstream' repo, or have a completely automated PR merging system that
> also triggers a downstream build, or something like that.


On this place, I would like to remind this guideline:


https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity


And I don't think this is in place just due to one off fixes as Adam
mentioned, but because of mass cleanup of Fedora .spec files. In recent
history, I remember removal of %clean sections, Group tags and removing
the scriptlets.


Vít
___
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: Proposal: Add "Feedback" section to change proposal template

[Vít Ondruch]

I don't know, I am somewhat ambivalent on this. I am not sure who is
going to collect the feedback there. Will it be the owner of the change
or somebody else? What will be the structure? Will it be just bunch or
quotes from random sources?

Wouldn't it be better to utilize the "discussion" tab/feature of the
wiki instead?

Or wouldn't it be better to include the devel ML reference?


Vít



Dne 05. 05. 20 v 21:28 Ben Cotton napsal(a):
> churchyard suggested we add a "Feedback" section to the Change
> proposal template[1]. I see two benefits to this:
>
> 1. It provides FESCo a useful summary of the community feedback (and
> in particular the reasoning behind rejecting alternatives) to simplify
> the voting process
> 2. It improves the historical record so that future Fedorans can
> understand why a change was implemented in a particular way and not
> another
>
> I have drafted proposed edits[2] to the Changes documentation that
> would add an optional Feedback section to the template. I am opening
> this up for community discussion before submitting it to FESCo for
> approval.
>
> The reason we chose to go with making this optional is that making it
> mandatory would necessarily add additional wait time before proposals
> are sent to FESCo. And also it's better to ease people into the idea.
> :-)
>
> [1] https://fedoraproject.org/wiki/Changes/EmptyTemplate
> [2] https://pagure.io/fedora-pgm/pgm_docs/pull-request/2
>

___
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: [External] Re: Fedora+Lenovo

[Cătălin George Feștilă]

It is a good idea to have a fast operating system when you buy a device.

I don't think it will be bought like that due to the price in Europe.

It was a Fedora wiki with hardware requirements, I don't know if it still
exists.

My opinion is that we still fit into this answer:

What are the cheap laptops that have very good hardware to run Fedora 32
very well?
___
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: Is dist-git a good place for work?

[Vít Ondruch]

Dne 05. 05. 20 v 21:26 Robbie Harwood napsal(a):
> Tomas Tomecek  writes:
>
>> Thank you all for raising all the questions and concerns.
>>
>> Before I reply, I'd like to stress that we are still in a prototype
>> phase - not everything is solved (clearly) and at this point, we
>> experiment with the workflow mostly.
>>
>> Luckily, force-pushes are not allowed in dist-git,
> That's a "current state of affairs" statement, not an ideal, as I
> understand it.  Assuming that force-pushes aren't allowed means we'll
> never be able to have, e.g., non-distro branches (for testing etc.) that
> we can force push.
>
> This has been a pain point with RHEL dist-git; among other things, it
> means that branches can't be deleted.


That this is problem only when you cannot use PRs. If you can use PRs,
pushing some random branches into remote git repo is the biggest sin
IMO, because while you might delete the branch in remote repo once it is
not needed, I have this branch very likely pulled to my repo and the
amount of branches in my local repo I have no clue about just rises. So
if deleting branches was a point of RHEL dist-git, then this is sad news
for me. Pushing branches was probably useful in CVS days, but that
should not be the case anymore.


Vít


>
> Thanks,
> --Robbie



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-Cloud-30-20200506.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
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