Re: Ursa Major (modules in buildroot) enablement
On Mon, Nov 12, 2018 at 11:50 AM Randy Barlow wrote: > > On Mon, 2018-11-12 at 09:04 -0500, Neal Gompa wrote: > > It is not. Arguably, this check should be blocking across the board. > > I > > personally would rather have this check earlier than Bodhi (mark > > builds in Koji as failed if they aren't installable), but that > > appears > > to be a thing we can't do. > > Sometimes builds depend on other builds, so this would not always be > possible. Bodhi is a good place to check things like this, because it > is the first time you have an opportunity to express "these builds ship > together". > That's not actually possible. Builds depending on other builds already fail today without Koji overrides being done first. > It would be nice if there were a way to express this earlier, such as > Pagure PRs. How would we do this? Scratch build IDs would need to be identified somehow, and the builds would need to be captured for this use. This is actually something I've been doing for packages I personally build on COPR, so it's not particularly difficult to implement, provided we can grab repository configs from koji for a scratch build and pull the RPMs in and do the dep check and the install check. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla
On Tue, Nov 13, 2018 at 1:42 PM Peter Robinson wrote: > > On Mon, Nov 12, 2018 at 3:35 PM Jaroslav Mracek wrote: > > > > Hello everyone, > > > > There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) > > into rawhide, but the rebase also ended up in stable branches of Fedora 28 > > and 29. This release could affect not only libsolv users, but also libdnf, > > PackageKit, microdnf, or dnf related applications. > > I would like to ask everyone for intensive testing and reporting any issues > > concerning the rebase. > > How did this this happen? It's kind of strange that people weren't > aware this was happening, what is some auto "git merge master" > mistake. It's a fairly big problem to "accidentally" rebase to a major > new release and not realise it was happening, especially on something > so core as core updates infrastructure. What sort of things are you > going to put in place to ensure random rebases don't just happen > again? It wasn't a random rebase. A FESCo ticket was submitted and approved[1]. However, there was a miscommunication that led to the DNF team not being aware it happened. [1]: https://pagure.io/fesco/issue/2009 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
On Thu, Oct 4, 2018 at 7:27 PM Ray Strode wrote: > > > I suggest that if we think this is a serious issue and that we want to > > get the maximum possible help to those who are forced to pay by the > > bit that we stop sending them mail they don't need all together. Lets > > move this mailing list (and others) to discussion.fedoraproject.org. > Why switch, when we already have > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ? it does good quoting already, you get to click what you want, and i'm > guessing this reply i'm sending will show up plaintext. > You are correct. It worked exactly like that. However, it seems like there just simply wasn't much in the way of promoting the HyperKitty interface after the initial growing pains of deploying it and converting everything over. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
On Tue, Oct 2, 2018 at 9:02 AM Vít Ondruch wrote: > > > > Dne 2.10.2018 v 13:11 Pierre-Yves Chibon napsal(a): > > On Tue, Oct 02, 2018 at 11:53:45AM +0200, Vít Ondruch wrote: > >> > >> Dne 1.10.2018 v 20:00 Jason L Tibbitts III napsal(a): > "BP" == Björn Persson writes: > >>> BP> This was on Fedora 27. So one needs Fedora 28 to help fixing the > >>> BP> formatting of the guidelines then? (Once that other breakage is > >>> BP> fixed I suppose?) > >>> > >>> I believe one could build the antora stack from scratch instead of using > >>> a container. I would hope it wouldn't require F28 to do so, but it's > >>> still way too high of a barrier. > >>> > >>> BP> Yeah, no I don't think I'm going to run any document conversion > >>> BP> programs as root. > >>> > >>> You certainly shouldn't have to. The problem is making it look like it > >>> looks on the web site, since I guess the markup itself is dependent on > >>> stylesheets and extra information which isn't actually included in the > >>> documents. > >>> > >>> For a single page, though, it seems that you can get a reasonable > >>> interpretation merely by installing asciidoc and running "asciidoc > >>> foo.adoc". > >> For a single page, it would be nice if Pagure supported .adoc as it > >> supports other makrdowns > > There is a ticket asking just for this. We'll get to it sooner or later. > > > >> ... > > Not quite sure what this implies > > It is just surprising it is not supported yet out of the box by whatever > library you are using to convert other markups to html. > Pagure is in Python. There are now no useful implementations of *.adoc renderers in Python. It's not that surprising. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
On Tue, Oct 2, 2018 at 7:30 AM Reindl Harald wrote: > > > > Am 02.10.18 um 13:25 schrieb Neal Gompa: > > On Tue, Oct 2, 2018 at 7:01 AM Michal Schorm wrote: > >> > >>> I'm sending you this HTML email because Google dropped possibility to > >>> send plaintext emails. Sorry =( > >> > >> Gmail > >> -> compose > >> -> options (bottom right) > >> -> plain text mode > >> > >> doesn't work for you? > >> > >> (I'm sending this e-mail with this setting so who knows how can check it) > >> > > > > This is not respected by any of the mobile apps. > > so get k9 mail and use imap/smtp - problem solved and a devloper should > be capable to use mail proper > To be quite honest, I am not installing another mail app just for this. There's not a single legitimate reason for me to bother with the inconvenience of setting that up and effectively bypassing things like 2FA and whatnot. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
On Tue, Oct 2, 2018 at 11:59 AM Fabio Valentini wrote: > > On Tue, Oct 2, 2018 at 5:00 PM Neal Gompa wrote: > > > > On Tue, Oct 2, 2018 at 9:02 AM Vít Ondruch wrote: > > > > > > > > > > > > Dne 2.10.2018 v 13:11 Pierre-Yves Chibon napsal(a): > > > > On Tue, Oct 02, 2018 at 11:53:45AM +0200, Vít Ondruch wrote: > > > >> > > > >> Dne 1.10.2018 v 20:00 Jason L Tibbitts III napsal(a): > > > >>>>>>>> "BP" == Björn Persson writes: > > > >>> BP> This was on Fedora 27. So one needs Fedora 28 to help fixing the > > > >>> BP> formatting of the guidelines then? (Once that other breakage is > > > >>> BP> fixed I suppose?) > > > >>> > > > >>> I believe one could build the antora stack from scratch instead of > > > >>> using > > > >>> a container. I would hope it wouldn't require F28 to do so, but it's > > > >>> still way too high of a barrier. > > > >>> > > > >>> BP> Yeah, no I don't think I'm going to run any document conversion > > > >>> BP> programs as root. > > > >>> > > > >>> You certainly shouldn't have to. The problem is making it look like > > > >>> it > > > >>> looks on the web site, since I guess the markup itself is dependent on > > > >>> stylesheets and extra information which isn't actually included in the > > > >>> documents. > > > >>> > > > >>> For a single page, though, it seems that you can get a reasonable > > > >>> interpretation merely by installing asciidoc and running "asciidoc > > > >>> foo.adoc". > > > >> For a single page, it would be nice if Pagure supported .adoc as it > > > >> supports other makrdowns > > > > There is a ticket asking just for this. We'll get to it sooner or later. > > > > > > > >> ... > > > > Not quite sure what this implies > > > > > > It is just surprising it is not supported yet out of the box by whatever > > > library you are using to convert other markups to html. > > > > > > > Pagure is in Python. There are now no useful implementations of *.adoc > > renderers in Python. It's not that surprising. > > After a bit of looking around, it looks like almost no code > highlighting tool supports AsciiDoc (yet). Neither pygments (python) > nor rouge (ruby) support it. > > The only "libraries" supporting AsciiDoc that I could find were > highlight.js and prism.js. But, looking at pagure's source code, it > already seems to use highlight.js. Maybe it's just a version without > AsciiDoc support enabled? > There are some quirks with highlight.js that we're still working through for pagure 5, but highlight.js only supports syntax highlighting, not rendering. The problem is that Pagure is incapable of rendering asciidoc safely right now. We can render Markdown and reStructuredText because there are solid implementations for them that we can use. > Side note: Is AsciiDoc really such an obscure format? > Yes. Unlike most text formats, AsciiDoc is really defined by the tool that renders it. The only other format that was in a similar situation was Markdown, but the CommonMark specification has allowed for a number of independent implementations to exist that behave coherently. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
On Tue, Oct 2, 2018 at 7:56 AM Iñaki Ucar wrote: > > El mar., 2 oct. 2018 a las 13:48, Iñaki Ucar > () escribió: > > > > El mar., 2 oct. 2018 a las 13:44, Neal Gompa () > > escribió: > > > > > > On Tue, Oct 2, 2018 at 7:30 AM Reindl Harald > > > wrote: > > > > > > > > > > > > > > > > Am 02.10.18 um 13:25 schrieb Neal Gompa: > > > > > On Tue, Oct 2, 2018 at 7:01 AM Michal Schorm > > > > > wrote: > > > > >> > > > > >>> I'm sending you this HTML email because Google dropped possibility > > > > >>> to send plaintext emails. Sorry =( > > > > >> > > > > >> Gmail > > > > >> -> compose > > > > >> -> options (bottom right) > > > > >> -> plain text mode > > > > >> > > > > >> doesn't work for you? > > > > >> > > > > >> (I'm sending this e-mail with this setting so who knows how can > > > > >> check it) > > > > >> > > > > > > > > > > This is not respected by any of the mobile apps. > > > > > > > > so get k9 mail and use imap/smtp - problem solved and a devloper should > > > > be capable to use mail proper > > > > > > > > > > To be quite honest, I am not installing another mail app just for > > > this. There's not a single legitimate reason for me to bother with the > > > inconvenience of setting that up and effectively bypassing things like > > > 2FA and whatnot. > > > > IMO, it would be easier for everybody if the mailing list could > > automatically strip out the HTML part. Some projects do this (e.g., > > R). > > i.e., see multipart filtering and conversion to plaintext: > > https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/filtering.html > > It should be easy to set this up for all Fedora mailing lists. > I don't think it's a good idea to convert/transform people's emails in flight... But multipart mail renders as plain text by most plain text mail clients, so I'm not sure it's really a problem from Gmail (which always sends multipart mail when in rich text mode). -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity is still confusing
On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller wrote: > > On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote: > >-- And the one question I have to add on to Christopher's wonderful > > list: I have a package where upstream releases about once a month, > > and each new release must by definition be backwards compatible > > (acpica-tools, specifically). I can think of no scenario where a > > module provides value to me or end-users; in fact, using anything > > other than the most recent causes problems. Do I have to create and > > maintain a module for this package anyway? Or are the defaults > > robust enough that a package can remain a package without touching > > modularity at all? The answer to this is completely unclear to me -- > > what I've read seems to imply that I must create a module definition > > regardless. > > > This actually seems like the ideal case for a single stream -- instead of > maintaining rawhide, f29, f28, epel7, you'd just maintain "latest", > and that would get build into all of these releases simultaneously. > I still don't get why this subset case requires all the extra module goop? Couldn't we just have fedpkg have an "fedpkg build --all-releases" switch to just trigger on the same commit for all releases? -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: package downgrades from f28 to f29
On Wed, Oct 10, 2018 at 7:41 PM Jason L Tibbitts III wrote: > > > "KP" == Kamil Paral writes: > > KP> That policy has been cancelled. Since the upgrade tools started > KP> doing basically "dnf distrosync (--allowerasing)" for upgrades, the > KP> upgrade path between distros stopped being a major issue and the > KP> policy has been dropped. > > If this is true then it's a rather huge change that should be announced > pretty loudly. After all, if we no longer care about ordering between > releases, then we are able to both drop Epoch: tags and remove the > extraneous 'c' from the dist tag. (With the slight caveat that rawhide > users need to use distro-sync at some point.) > I'd personally love to be able to start resetting Epochs. There's no reason for them to persist beyond a release. I dunno if I'd be happy with losing `fc`, though. It's grown on me... :P We still have tons of references to Fedora Extras in our infra too (just look at most of our tracker bug labels!). I wonder if we now have more people in Fedora that came after the Core/Extras merge than before 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
On Tue, Oct 2, 2018 at 7:01 AM Michal Schorm wrote: > > > I'm sending you this HTML email because Google dropped possibility to send > > plaintext emails. Sorry =( > > Gmail > -> compose > -> options (bottom right) > -> plain text mode > > doesn't work for you? > > (I'm sending this e-mail with this setting so who knows how can check it) > This is not respected by any of the mobile apps. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Requesting updated contact info for Matthias Runge (mrunge)
On Thu, Oct 4, 2018 at 8:43 AM Neal Gompa wrote: > > Hey all, > > I've been trying to get in touch with Matthias Runge (mrunge) over the > last couple of days (for getting python-celery into EPEL7 for Pagure > 5). However, his email address listed in FAS bounces with "unable to > connect" errors. > > Does anyone know of another email address or method to get in touch with him? > Sorry, to clarify, I meant for getting python-kombu updated in EPEL7 for getting python-celery into EPEL7. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Requesting updated contact info for Matthias Runge (mrunge)
Hey all, I've been trying to get in touch with Matthias Runge (mrunge) over the last couple of days (for getting python-celery into EPEL7 for Pagure 5). However, his email address listed in FAS bounces with "unable to connect" errors. Does anyone know of another email address or method to get in touch with him? Thanks in advance! -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
On Mon, Oct 1, 2018 at 5:03 PM Björn Persson wrote: > > Jason L Tibbitts III wrote: > > Indeed, asciidoctor works a bit better than asciidoc does but still > > converts quickly. It's actually in the "rubygem-asciidoctor" package. > > Maybe I'll try that next time I have some free time. This is giving me > a "best viewed with Netscape Navigator" feeling though. Not only are > there several different badly designed document authoring languages, > but they're apparently even splitting into tool-specific dialects. > I'm wondering if it was a good idea to use asciidoc in the first place. Unlike reStructuredText, asciidoc implementations seem to be in very poor shape. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Building multiple version of a package from same dist-git repo
On Mon, Sep 3, 2018 at 8:02 AM Adam Samalik wrote: > > > > On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw wrote: >> >> On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik wrote: >>> >>> >>> I thought that Arbitrary Branching (now referred to as Stream Branching) >>> was initially developed for Modularity only. >>> >>> Were there any plans to use it for standalone packages as well? >> >> >> Thank you for bringing this up... I re-read the Wiki including the Factory2 >> link and I'm still confused. I like the idea at a high level but I still >> don't understand how to use it. >> >> One example is that I maintain the package OpenImageIO which has a very >> disciplined upstream that's careful about not making API/ABI breaking >> changes within a minor release. I would like to get branches for each minor >> release that's currently supported, 1.8 for rawhide through F28, 1.8 for F27 >> and 1.5 for EPEL. >> >> Like I said, at a high level it makes since, but I still don't understand >> exactly how to do it or if the process/tools are mature enough to actually >> use yet. > > > The original idea was to use it for modules [1]. You would reference the > branches in your module definition [2]. > There's no particular reason it couldn't be used for regular packages. The only reason it's not done is because of convention. It's certainly workable, but as fedpkg doesn't yet support that workflow, it's a bit more manual. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python2-future on fedora 30+
On Fri, Sep 21, 2018 at 9:23 AM Antonio Trande wrote: > > Hi all. > > Are we ready for excluding python2-future on fedora 30+ ? > > $ dnf repoquery --release rawhide --enablerepo=*-source > --disablerepo=rpmfusion* --whatrequires python2-future > > Last metadata expiration check: 0:00:00 ago on ven 21 set 2018 14:41:49 > CEST. > > buildbot-0:1.3.0-1.fc29.src > buildbot-master-0:1.3.0-1.fc29.noarch > buildbot-worker-0:1.3.0-1.fc29.noarch I can look into moving buildbot to Python 3, but last I checked there were some missing dependencies and not fresh enough ones... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora for Web Development fail
On Tue, Sep 25, 2018 at 10:54 AM Peter Robinson wrote: > > > * Máirín Duffy: > > > > > - Found out it's cloud-info stalling the boot. > > > > I think it's actually cloud-init. > > > > > - Yay I have a login prompt! What's the login info? Ga... > > > - Realize have to run virt-customize --uninstall cloud-init > > > --root-password password:whatever --selinux-relabel -a theimage > > > > I have requested downstream that we ship separate KVM and cloud images > > because cloud-init is a significant security risk when run outside a > > cloud environment which supports instance data injection (which libvirt > > does not provide). cloud-init probes the network and executes scripts > > it finds there as root. It cannot perform authentication because it > > performs customization of the image, and the owner of the VM is not > > known to it before it runs. > > > > A dedicated cloud image with a document procedure for injecting > > authentication information (could be an open root shell on the serial > > console) would help your use case as well and discourage people from > > abusing the insecure cloud images for KVM installs. > > Might be better to move them all to ignition in F-30? How is ignition any better? Aside from it being written in Go (which reduces the architectures and platforms that can be supported), it functions more or less the same way as cloud-init. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: 3 days vs 7 days
On Sat, Sep 22, 2018 at 4:48 PM Jerry James wrote: > > Koji seems to be requiring 7 days in -testing for F29. Shouldn't it > be requiring 3 days at this point? It should... I wonder what's going on here? -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Julio Gonzalez Gil
On Sat, Sep 22, 2018 at 6:35 PM Julio González Gil wrote: > > Hi everyone, > > As requested by maintainers guide, I am introducing myself to the community. > > I am working as Release Engineer for the last 6 years, and since one year ago > for SUSE as Release Engineer for SUSE Manager and the community developed > Uyuni [1] (however keep in mind my participation at Fedora will be strictly > personal). > Welcome to Fedora! I'm glad to see you here (even if it's not for SUSE things). I'll be happy to review your package and sponsor you. :) I hope you enjoy participating in the Fedora community! -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Semi-serious proposal: drop all optional entries from comps
On Sat, Sep 22, 2018 at 2:39 PM Adam Williamson wrote: > > On Sat, 2018-09-22 at 13:07 +0200, Kevin Kofler wrote: > > Adam Williamson wrote: > > > While doing this extremely tedious task, it occurred to me to think: > > > what the hell is the *point* of these 'optional' entries any more, > > > anyway? > > > > They are required for Dnfdragora to list the available packages in a > > categorized manner. Dropping them without replacement is clearly the wrong > > approach, it will badly break Dnfdragora. (Experience with Apper has shown > > that users see browsing groups as an absolutely required feature of a > > package manager. The uncategorized "all packages" list or searches by name > > or description are not suitable replacements for most users.) > > > > If we see maintaining comps as too much of a burden (which is somewhat true, > > because it requires touching files outside of the packages, which has become > > even more tedious when the move to Pagure removed write permissions to the > > comps repository from almost all packagers, forcing us to go through pull > > requests), > > This is, however, a major win in another regard: we can stop people > breaking comps during freezes. Which *did* happen. Quite often. We've > more than once had a candidate compose fail or have a release-blocking > bug because someone tried to change kickstarts or comps during the > freeze, and got it wrong. > > That kinda points up a problem in that we have a single thing - comps - > which serves multiple roles with kinda different requirements. It's not > *really* a big problem to anyone if some group which is not included on > any media, and just exists to be shown in package managers like > dnfdragora, has some bad entries in it. It's absolutely a problem if > someone decides to change @core or @anaconda-tools or @workstation- > product and gets it wrong. It's kinda bad that these things have to be > in the same project, in the same *file*, and thus subject to the same > policies for modification, with the result that there's always going to > be some suboptimal result (either making it too easy to change the > really important stuff, or too hard to change the unimportant stuff). > > > then we should just undeprecate the RPM Group tag and move back > > to that. Dnfdragora already supports Group tags out of the box. (In fact, > > moving to them would allow Dnfdragora upstream to remove the special-case > > code for Fedora.) > > > > The rationale for deprecating RPM Group tags was that comps should be used > > instead. But if we want to get rid of that use of comps (since a comps > > without optional packages is no longer a suitable replacement for Group > > enumeration! A lot of packages that users will want to install will not be > > listed there anymore), what speaks against using Group again? > > > > So I see only 2 alternatives: > > a) keep comps as it is now, including optional packages, OR > > b) undeprecate the RPM Group tag, readd it to all Fedora packages, and > >switch back to it. > > Any other plan will completely break Dnfdragora. > > That's a fair point. I didn't really follow the 'no group tags' > proposal closely and hadn't noticed it suggested comps as an > alternative. > Personally, as dnfdragora upstream, I'd definitely prefer if we killed special cases like this. > But at the same time I think Matt's right that comps -at least as it's > currently set up - is kind of a really *bad* way of doing this, and > that seems fairly well demonstrated by the problem I'm trying to solve > - that comps has tons of broken entries in it. Just from looking > through the file as I do this, I really suspect that no-one is > maintaining quite a lot of the groups and the packages in them may well > just not make much sense any more. > Actually, we might want to consider adopting a variant of SUSE's approach. Their "patterns" used to work the same way our comps do now. However, they made the transition from externally developed and separately injected metadata to being generated from specially set up metapackages. Those metapackages could be controlled by the same kind of ACLs we have now for regular packages, and they could be used as the input to automatically generate comps.xml data, as SUSE does for generating pattern info (for versions of SUSE Linux that don't automatically map pattern requests to metapackage install requests). This would have the added advantage of simplifying our repodata creation process and allow people the flexibility to define their own in a way that the package manager can easily pick up. The only downside to us dropping comps.xml metadata is the loss of translations, unless we support the rpmmd extension SUSE developed for translating package data. I suppose we'd also lose the "inheritance merge" model of comps across repos, but I'm not sure that was a good idea to begin with... (Which of course means we really have to actually standardize the extension so that all the tools can
Re: Semi-serious proposal: drop all optional entries from comps
On Sun, Sep 23, 2018 at 2:13 PM Kevin Kofler wrote: > > Matthew Miller wrote: > > Well, or "find plan c and work to make sure it's integrated in future > > versions of dnfdragora". > > That would have to be done BEFORE we drop the comps entries though. > > > The RPM Group tag is very inflexible — even beyond the "dewey decimal > > system" problem where the categories we had weren't very forward-thinking, > > We don't have to use the historical Red Hat categories. We already mass- > removed the old Groups from specfiles, so we can add new ones now. > > We could use any of: > * https://en.opensuse.org/openSUSE:Package_group_guidelines > * https://wiki.mageia.org/en/RPM_groups_policy > * any other existing category list from another distro, > * a new list defined specifically for Fedora. > > This is purely a policy issue. Software consuming the groups will not care > about what the list of groups is. It just needs to make sense to the users. > I'd be happy to help design a new list for Fedora, if we decide to go down this road. > > they don't allow packages to be part of more than one group, > > That can be seen as a drawback, but also as a feature. We frown upon > .desktop files showing up in more than one menu category. The same arguments > can be used here. Of course, it can make sense to have an application under > two categories (e.g., Amarok both under KDE Applications and under Sound), > but there are also arguments for picking one. > There was a proposal in RPM upstream to add a concept of "tags"/"meta tags", which could be a set of properties that an RPM could be categorized under. However, the idea was not fleshed out enough for us to seriously consider it as something to support in RPM. However, I'm not sure multi-categorization makes sense beyond setting up installation groups. > Overlap can also often be avoided by judicious definition of groups. (E.g., > we probably would not have a "KDE Applications" group, the "KDE" or "Plasma" > group would only contain the KDE Plasma Desktop Workspace itself.) The > current @kde-apps comps group is mainly needed to compose images, but we > would not use the RPM Group tags for that anyway. > > > and depend on the package maintainer rather than on group curation. > > This one, I would definitely consider a feature! > > Even now with comps, the policy says that the package maintainer is > responsible for adding the package to the comps group. The main reason it is > often forgotten is that this is yet another place to touch, outside of the > specfile. If we require the tag in the specfile instead, it will be part of > the review process, and fedora-review can automatically print an error for > missing Group tags (just as there is currently one if Group is missing). For > existing packages, we need a mass change just like "Remove Group" was. And > the really nice thing is: removed packages can never clutter a group listing > because they will just be gone, and their Group tag will be gone along with > them. So the current problem that we have obsolete packages in the comps > groups would go away completely! > This is where I think that transforming comps into metapackages would probably solve the remaining issues we have with the current workflow. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter wrote: > > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote: > > Jonathan Dieter wrote: > > > My proposal would be to make zchunk the rpm compression format for > > > Fedora. > > > > Given that: > > 1. zchunk is based on zstd, which is typically less efficient in terms of > >compression ratio than xz, depending on settings > >(see, e.g., https://github.com/inikep/lzbench), and > > 2. zchunk can by design only compress chunks individually and not benefit > >from the space savings of a solid archive with a global dictionary, > > I fear that this is going to significantly increase the size of the RPMs, > > which matters: > > * for the initial downloads, > > * for storage (e.g., keepcache=1, local mirrors, etc.), and > > * for the people not using deltas for whatever reason. > > > > I think zchunk makes a lot of sense for the metadata, but I am not convinced > > that it is the right choice for the RPMs themselves. > > I suspect the first is true, but zchunk does actually allow for a > global (per-file) dictionary that can be used to compress each chunk. > The difficulty is that the dictionary has to stay the same between file > versions, or the chunk checksums won't match. There would have to be > some thought put into how to generate and store the dictionaries. > > As for how much bigger a zchunked rpm will be compared to an xz rpm, at > the moment it's a bit hand-wavy. Based on zchunked repodata work I've > done, I think we might be looking at a size that's slightly smaller > than a gzipped rpm. I won't know for sure until I put together a > proof-of-concept, but I want to make sure that there aren't any gaping > holes in the proposal before I do that. > I did some work several months ago to evaluate zstd compression for RPMs for Fedora, because of the lower memory and CPU usage for (de)compression. However, the average size increase from xz was pretty large (~20% or more on average, and nothing ever was either the same or smaller), even with heavier compression settings. That might have changed a bit with newer zstd releases that offer some more tunables, but I think it'll remain a tough sell on disk space. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski wrote: > > On 11/18/18 2:29 PM, Richard W.M. Jones wrote: > > I'm not for or against a longer Fedora lifecycle, but I think we need > > a stronger statement of what the problem is we're trying to address. > > > > From your email: > > > > On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote: > >> But there are some good cases for a longer lifecycle. For one thing, > >> this has been a really big blocker for getting Fedora shipped on > >> hardware. Second, there are people who really could be happily running > >> Fedora but since we don't check the tickbox, they don't even look at us > >> seriously. I'd love to change these things. To do that, we need > >> something that lasts for 36-48 months. > > > > this sounds like a very valid problem. > > > > But if this was fixed, what number of manufacturers would adopt Fedora > > and how many installations do they ship (eg per year)? Could it be > > fixed in another way, like a special OEM Fedora release? > > And why haven't these manufacturers already adopted CentOS which is > definitely around longer than 36-48 months? > I think it's quite obvious why. No one can really influence what's in CentOS. Red Hat Enterprise Linux itself is developed mostly behind closed doors, after forking a Fedora release. If we had an equivalent to Fedora Legacy/openSUSE Evergreen to support a specific release for an extended period of time, we could also allow ODMs/OEMs to be part of that process to help improve support of their equipment with Linux and that effort would be able to be pushed upstream with guidance from Fedora to benefit all Linux distributions. And while most people think the relationship is Red Hat -> Fedora, it's actually the other way around. Fedora can be an integration point for PC makers to help those people to benefit the Linux ecosystem as a whole. But I don't think we should extend the lifecycle on a general basis. That's asking for trouble, since it cedes our leadership in the Linux platform and destroys our ability to meet our own values. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reviews needed
On Wed, Jan 2, 2019 at 2:41 PM Tom Callaway wrote: > > When I wasn't looking, asymptote grew a new dependency, which means I > have two new packages that need reviews. > > python-speg: https://bugzilla.redhat.com/show_bug.cgi?id=1663036 > python-cson: https://bugzilla.redhat.com/show_bug.cgi?id=1663037 > > They're very small, very simple packages. Should take about a minute to > review. > > Will trade reviews or other packaging favors. > I'll grab these. In the near future, I will have reviews needed for getting Cavil into Fedora... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
On Mon, Jan 14, 2019 at 3:19 PM Ben Rosser wrote: > > On Fri, Jan 11, 2019 at 12:37 PM Michael Cronenworth wrote: > > > > On 1/11/19 9:18 AM, Matthew Miller wrote: > > > Can we apply the same "flag and remove" approach as currently used in > > > Copr? > > > > I'd rather have a licensing sign-off step. Allow fedora-review to automate > > the spec > > review and build test, but break out the licensing check. Maybe in the > > future we can > > automate that, too, but breaking out the mountain that is package review > > into a > > small rock would still accelerate reviews. > > Well, part of fedora-review is running the license check script. I > don't think it would be too difficult to split this off into a > separate automated step, that runs over the src.rpm on the Bugzilla > ticket. Obviously this won't catch everything, but it can at least > alert the submitter (and any potential reviewers) to obvious licensing > problems. Perhaps if the license check passes, then the rest of the > review automation could run; otherwise, it has to be manually > triggered. > > Or maybe we could just make the review automation use copr directly, > rather than koji, if it's easier to remove things from copr? The > packages/builds could then be deleted from copr once the package gets > approved (or removed if the review is closed WONTFIX, or something). > I'm working on packaging Cavil[1] as an option to replace the licensecheck stuff we currently use. The openSUSE guys have been using this as part of their semi-automated package review process for years now[2], and it may help us move towards less human involvement in reviews, too. [1]: https://github.com/openSUSE/cavil [2]: https://github.com/openSUSE/openSUSE-release-tools/blob/master/legal-auto.py -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 3:17 PM Ben Cotton wrote: > > [This proposal was submitted after the deadline. I am announcing it > for community discussion and will leave the decision on whether or not > to grant an exception to FESCo] > > https://fedoraproject.org/wiki/Changes/GCC9 > > == Summary == > Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 31. > > == Owner == > * Name: [[User:jakub| Jakub Jelínek]] > * Email: ja...@redhat.com > > > == Detailed Description == > GCC 9 is currently in stage4 since January 7th, in prerelease state > with only regression bugfixes and documentation fixes allowed. The > release will happen probably in the middle of April. > rpms have been built are since today in rawhide. > > == Benefit to Fedora == > See http://gcc.gnu.org/gcc-9/changes.html for the list of changes. > > == Scope == > All packages should be rebuilt with the new gcc once it hits f30, or, > if there is not enough time for that, just all packages built after > the new gcc hits the buildroots. > > * Proposal owners: > Build gcc in f30, rebuild packages that have direct dependencies on > exact gcc version (libtool, annobin, gcc-python-plugin). > * Other developers: First few days/weeks just voluntary rebuilds using > the new system gcc, if things fail, look at > http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, > if there is a gcc bug or suspected gcc bug, analyze and report. > * Release engineering: . Mass rebuild requested for F30. > * Policies and guidelines: No policies need to be changed > > == Upgrade/compatibility impact == > No impact > > == How To Test == > GCC has its own testsuite, which is run during the package build, plus > many other packages with automated tests also help to test the new > gcc. > > == User Experience == > Users will be able to see compiled code improvements and use the newly > added features. > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, > or, if they detect a GCC bug, report it. > > == Dependencies == > libtool, annobin, gcc-python-plugin depend on exact gcc version, those > need to be rebuilt. > > == Contingency Plan == > If bugs are discovered, I'd appreciate help from the package owners in > preparing self-contained testcases to speed up analysis and fixing the > bugs. Don't have time to debug issues in > 12000+ packages, especially when in many cases it could be caused by > undefined code in the packages etc. I don't expect we'll have to fall > back to the older gcc, we've never had to do it in the past, > but worst case we can mass rebuild everything with older gcc again. > Jeff Law has performed test mass rebuild on x86_64. > > * Contingency mechanism: Revert to older gcc, mass rebuild everything again > * Contingency deadline: Before release > * Blocks release? Yes > * Blocks product? No > > == Documentation == > http://gcc.gnu.org/gcc-9/ > > == Release Notes == > Fedora 30 comes with GCC 9.1 as primary compiler, see > http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it. > I, for one, am excited for GCC 9. Having the GNU D Compiler in Fedora will make things tons easier for having software written in D be able to have the same hardening applied to it that we have for C/C++ programs. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Heads Up: libmodulemd 2.0 coming soon to a Rawhide near you
On Mon, Dec 10, 2018 at 2:06 PM Kalev Lember wrote: > > On 12/10/2018 07:30 PM, Stephen Gallagher wrote: > > It is versioned, actually. The 1.x API is `pkconfig(modulemd)` and 2.x > > is `pkgconfig(modulemd-2.0)`. The source of the conflict between the > > two -devel subpackages is that they both want to own > > /usr/lib64/libmodulemd.so, symlinked to different objects. > > Perhaps it would then make sense to rename libmodulemd.so to > libmodulemd-2.so in 2.x, so they don't conflict? > No. It's better that the development subpackages conflict. There's zero reason for them to be co-installable. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automating Package Review (Was: fedora-review -- do we have a maintainer?)
On Tue, Dec 11, 2018 at 10:30 AM Sérgio Basto wrote: > > Hi, > > Any news ? > > "But I guess nothing's getting released, for some reason? fedora-review has > been on version 0.6.1 since May 2016; all package activity since then has > been housekeeping rebuilds. " > > may you add me as admin to Fedora-review package ? to release a new version . > There's really one remaining thing for a new release of FedoraReview: porting to Python 3. There's a WIP PR here: https://pagure.io/FedoraReview/pull-request/312 If it doesn't budge this week, I'm hoping to take a crack at it in the next week or so and try to pull it over the finish line. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: make fedora-release archful and add some provides
On Fri, Dec 14, 2018 at 2:50 PM Igor Gnatenko
wrote:
>
> On Fri, Dec 14, 2018 at 8:45 PM Neal Gompa wrote:
> >
> > On Fri, Dec 14, 2018 at 2:34 PM Igor Gnatenko
> > wrote:
> > >
> > > Hello folks,
> > >
> > > for long time we have problem if you have some arch-specific
> > > BuildRequires, you still get one src.rpm from one of arches (not sure
> > > how koji chooses that one) which might not work for your architecture.
> > >
> > > For example if you have following in spec:
> > > %ifarch %{ldc_arches}
> > > BuildRequires: ldc
> > > %endif
> > >
> > > And the src.rpm is taken by koji from x86_64 (included in
> > > %{ldc_arches}), then you won't be able to run `dnf builddep foo`,
> > > because it will complain that ldc package is missing.
> > >
> > > PROPOSAL:
> > > 1. make fedora-release archful
> > > 2. add Provides: system-architecture($arch) to fedora-release, where
> > > $arch is architecture name
> > > 3. use Requires: (foo if (system-architecture(x86_64) or
> > > system-architecture(i686))) in packages
> > >
> > > What do you think? Any suggestions are welcome!
> >
> > In Mageia, we just had the package manager generate virtual Provides
> > for those things, so that packages can use that. Why wouldn't we just
> > make RPM/DNF do the same thing?
>
> What exactly does it generate & where?
urpmi makes a virtual "arch($ARCH)" provide exist that packages can
reference. Mageia kernel packages use that to ensure 32-bit kernels
aren't installed on 64-bit environments and vice versa, among other
things. It's basically the equivalent of a solvable in libsolv.
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: make fedora-release archful and add some provides
On Fri, Dec 14, 2018 at 3:09 PM Igor Gnatenko wrote: > > That makes sense that we can do something like this from DNF code.. > However, it would be kinda hard to do any dependency resolution > checks.. > > Although we already have one which is module(platform:$PLATFORM_ID) > which is automatically populated from os-release by libdnf. Which is > actually causing problems during upgrade. > > I like both approaches. > Is there a reason stuff like this isn't available from RPM itself somehow? It seems like it'd make sense to just make this available as some kind of special Provides property, since RPM knows about it and would allow for dependency resolution to not be dependent on DNF... Failing that, since we apparently have this already for module() Provides, could we do this for system-architecture() too? I'd rather not mess with fedora-release for this... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: make fedora-release archful and add some provides
On Fri, Dec 14, 2018 at 2:34 PM Igor Gnatenko
wrote:
>
> Hello folks,
>
> for long time we have problem if you have some arch-specific
> BuildRequires, you still get one src.rpm from one of arches (not sure
> how koji chooses that one) which might not work for your architecture.
>
> For example if you have following in spec:
> %ifarch %{ldc_arches}
> BuildRequires: ldc
> %endif
>
> And the src.rpm is taken by koji from x86_64 (included in
> %{ldc_arches}), then you won't be able to run `dnf builddep foo`,
> because it will complain that ldc package is missing.
>
> PROPOSAL:
> 1. make fedora-release archful
> 2. add Provides: system-architecture($arch) to fedora-release, where
> $arch is architecture name
> 3. use Requires: (foo if (system-architecture(x86_64) or
> system-architecture(i686))) in packages
>
> What do you think? Any suggestions are welcome!
In Mageia, we just had the package manager generate virtual Provides
for those things, so that packages can use that. Why wouldn't we just
make RPM/DNF do the same thing?
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
On Thu, Dec 20, 2018 at 5:17 AM Hans de Goede wrote: > > Hi, > > On 20-12-18 10:54, Raphael Groner wrote: > >> So what process should I use? Pull Requests or just removing obsolete > >> stuff? > >> I'm ready to do either way. Should I leave this to FESCo? > > > > My vote would go for Pull Requests to give the packagers a (limited) chance > > to look into the proposal individually. Maybe after some elapsed time have > > waited, you or someone else could just merge with the force of > > provenpackager. > > Ugh no I maintain somewhere between a 100 and 200 packages in Fedora, > just push the changes directly please. 100-200 pull-reqs is going to > be a big pain. > > Even just deleting all the notifications from them, without maybe > also accidentally deleting a non automated pullreq is goind to be > a big pain. > > So I say +100 to just pushing the changes directly, as said > people can always revert them. > > Maybe add a note in the changes page about this and a link > to the changes page in the spec file changelog, something like: > -For more info see: http:// > +100 Please, just push the changes. We'll all get notified anyway via fedmsg or other means that a change has been pushed. The PR-based method was too obnoxious when it was done for the Python dependency change. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bugzilla outage/upgrade delayed until 9 December 2018
On Fri, Nov 30, 2018 at 10:14 AM Ben Cotton wrote: > > The upgrade of bugzilla.redhat.com has been delayed a week. It will > now be done on 9 December 2018 from 0:00 to 12:00 UTC. > Aww, anyone know why? -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal : Use OSBS to build the fedora container base image
On Mon, Dec 3, 2018 at 1:39 PM Clement Verna wrote: > > Hi all, > > I would like to get feedbacks on the following proposal. Use OSBS to > build the fedora container base image, indeed OSBS has the capability > to build a base container image using a kickstart file. > To do this OSBS needs a Dockerfile, a kickstart file and an > image-build.conf file stored in dist-git, then OSBS will trigger an > ImageFactory task in Koji in order to build to base image and then it > will build the base container based on the artifacts built in Koji. > Is anyone actively maintaining ImageFactory? Because it's still Python 2 only and I haven't seen anyone really working on fixing that, much less supporting more images easily... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Dec 6, 2018 at 3:54 PM Ken Dreyer wrote: > > On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer wrote: > > I'm worried that this kind of pointless work makes it hard to attract > > talent. > > Florian, you might want to check out rdopkg. > https://github.com/softwarefactory-project/rdopkg . It's a bit like > fedpkg, in that it's a CLI with sub-commands. > > The idea is that you have three Git remotes: > > originssh://ktdre...@pkgs.fedoraproject.org/rpms/remctl > patchesg...@example.com:ktdreyer/remctl > upstreamhttps://git.eyrie.org/git/kerberos/remctl.git > > The "origin" is dist-git, the "upstream" is obviously the upstream > project, and the "patches" remote is a fork of upstream. > > You can maintain all your backports and cherry-picks in the "patches" > remote, in "-patches" branches. So for rawhide, the dist-git branch is > "master", so the patches branch would be "master-patches". This branch > is the upstream point release tag, plus any downstream cherry-picks. > > The "rdopkg patch" command will automatically run git-format-patch > with the proper commit range and inject the patch series into the > .spec file. It will update the %changelog and dist-git commit message > as well. > > We use that to maintain several hundred cherry-picks across many > different releases of Ceph. The RDO teams use it to help maintain over > 800 packages. (I have "rdopkg patch" running in Jenkins also, so the > rest of my team can just do "git cherry-pick -x" for their backports > and not have to touch packaging or dist-git.) > > We get the strong history preservation guarantees that dist-git always > gives us, along with the flexibility to rebase or edit patch series > quickly. The patches remote can live anywhere. It is similar to > Debian's patch-queue concept from git-buildpackage. > > Even if you maintain a package in Fedora that has just one or two > patches, it is really handy to use rdopkg to manage that. You can jump > back and forth between the "-patches" branch and the dist-git branch. > The ability to quickly rebase or amend patches makes packaging fun > again (for me anyway :) > I consider rdopkg a nice compromise between the differing models. It's a shame that rdopkg is behind the terrible contribution process that is RDO/OpenStack (gerrit, though at least that's better than mail queues), otherwise it'd replace my existing tooling for maintaining my more complex packages. I also quibble a bit about it being licensed ASL 2.0 (as that makes it tricky to integrate with the rest of my tooling), but meh. The rdopkg model also permits working with the native VCS, whatever it may be (Git, Mercurial, etc.), while still exporting cleanly to Dist-Git. It also doesn't require us to actually support all the necessary Git features for Git repos in Pagure today. In fact, I had been discussing with the rdopkg author the idea of using it for Mageia a couple years ago to replace mgarepo, though unfortunately he disappeared off the face of the earth after our first conversations, so that never went anywhere. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Dec 6, 2018 at 7:59 AM Florian Weimer wrote: > > * Neal Gompa: > > > The problem with merged source trees (aka source-git) is that it > > implies forking projects. > > But that's true for *any* distribution that wants to integrate things. > I guess you could govern everything by build flags eventually, but > upstreams will rarely be willing to backport those to older branches > (if they even have release branches as such). > > > It's an easy trap to start having vendor trees and maintain your own > > functionality independent from upstream. > > And how does the current dist-git prevent that? I know packages which > have managed to fall into the fork trap even with dist-git. > Sure, fork traps and such do still happen, but they're a lot rarer because that is much more painful with our current packaging model. It's a lot more obvious that package is in bad shape when it has ~100+ patches and is hard to rebase than it is when you have Git trees and can just do merges all the time. Once you've done merges, it becomes impossible to sort out. > > Fundamentally, I don't want having patches to be too easy, because > > then people _will_ do that. Fedora should strive to remain close to > > upstream projects and interact with them to make things better[1]. > > To be honest, that's an awful attitude. > > Do you want me to spend time on packaging work instead of glibc > maintenance? Do you really think that's a good use of my time? > I think that if you're maintaining large patch sets that you might want to consider talking to upstream about doing more releases. If glibc has so many problems that this becomes an issue even with the short life cycle in Fedora, then maybe upstream needs to reconsider its release model a bit and do more frequent releases per version series. Actually, does it even do that now? I'm not actually sure... > Do you really think an unavoidable conflict each time you merge parallel > development into a source RPM provides value? > > > And the thing is, it's not like I'm unfamiliar with merged source > > models. I've worked in distributions that operated that way, and the > > consequence is almost always that things are patched and changed > > without ever interacting with upstream. Of course, that's their choice > > to do so, but most distributions do not have "upstream-first" as a > > specific goal. > > We do that in Fedora, too. > > A recent example is the switch to the C.UTF-8 locale, which is not > upstream *at all*. It was pointed out at the time, and the issue was > completely ignored. > My understanding is that we allowed the feature in because it was actively being shepherded into glibc upstream. However, shortly after it was included in Fedora, the change owners stopped working on it upstream (from what I can tell). As a consequence, the C.UTF-8 locale is probably what I would consider one of our biggest failures. It's present in Fedora, openSUSE, Debian, and now Mageia. But it isn't present upstream. No one is working on it upstream, and I have very little hope for the developers of that locale to finish the job they started. We do not usually screw up that badly in the distribution in such a way that we have such a deviation from upstream and simultaneously stop working on upstreaming the change or consider to drop it because it isn't being upstreamed. > > In addition, it may seem like it makes things easier (and maybe > > faster), but it actually makes things much harder and slower for > > everyone else. Merged source trees make it so that it's stupid easy to > > have light forks of everything, which means people will just patch and > > change things without consequence. That makes it much harder to > > identify changes for rebasing to newer versions, what's safe to drop, > > and so on. > > That's just a matter of tooling. A lot of information can be recovered > from Git history, and it's going to be easier to do this in a single > repository than with copied patches, without tooling that enforces that > the patches actually contain what they say. > It's a lot clearer that patch files applied to a tarball are distinctly packager things vs a cacophony of changes from upstream and downstream mixed together. Aside from the rdopkg triple-repo process that Ken brought up in the thread, I don't know of any clean process for making these changes identifiable. > The point is to keep that history around. With the current model, the > information might theoretically be available somewhere, but with the > split between Fedora, branches, wildly differing patch management > practices, in addition to all the upstream differences we encounter, > it's extremely difficult to recover. > > In a sense, it's the old discussion be
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer wrote: > > On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > > >> In other words, the "technical debt" we are trying to solve here is > > > >> not project wide and doesn't justify slowing down the whole project > > > >> permanently. > > > > I completely disagree. Our release process and tooling is built on > > > > heroism and tech debt. > > > > > > People working on release and people working on packages maintenance are > > > different group - they are not disjunct, but it > > > is not the same group. > > > For example *I* am a maintainer of lots of packages, but the additional > > > works because of the fedora release is about one > > > working day per year - and it is mostly because of fedora-upgrade > > > package. Other packages do not need so much work. I am > > > more affected by upstream releases. > > > > > > Do not forget that annual releases will mean that N-1 release will > > > implicate 24 months support for packages which will > > > mean a much more significant impact on us-the maintaners. > > I'll echo what Paul says below with a +1, but I wanted to touch on > this point a bit because it implies an assumption that the maintenance > model remains the same even if lifecycle options change. I don't > think that needs to be the case, nor do I think it would even be good. > > Of the large number of packages that you maintain, how many of them > are critical to freeze at a specific version for a given Fedora > release? Possibly some, but I would think across the distribution it > would not be a huge number. So if there is no essential need to > freeze them at a specific version, why would you want to maintain the > packages *separately* for each release? That sounds like extra work > for no benefit. If we instead take a maintenance approach that you > maintain package foo and it is built for all releases, then you only > really need to maintain it in a singular instance. > > Today that is something that can be accomplished with modularity, but > I would suggest that we look at stream branching as a solution even > for regular packages. So you wouldn't have fc22-fc32 branches under > package foo. You'd have foo/stream- and you could build that > wherever you'd like. Couple that with automated CI testing and I > believe you actually decrease your maintenance burden while increasing > your quality. > > There are many details that would need to be worked out and I don't > want to trivialize them, but I do want to at least get people thinking > about it in the long term. If we are going to improve the way we > build and deliver our operating system, we shouldn't assume we can do > that without changing the way we maintain it either. > We can change this _today_, actually. fedpkg supports an in-repo config file to specify distro targets to push whenever running `fedpkg build`. So you could do a repo with only a master branch and have it push to all distro targets enabled for the repo at once. This is probably a useful optimization for the overwhelming majority of packages held by packagers. It's just not documented or available as an option for setup when you file a repo creation request. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Announcement: livecd-tools v26.0 and appliance-tools v009.0
Hello all, I've released livecd-tools v26.0 and it is making its way to Fedora and Mageia now. It is currently available in Rawhide, and will be in updates-testing for Fedora 28 and 29 soon. For Mageia, I've pushed it into Cauldron. It will be part of the upcoming Mageia 7. ## What's new This update adds some small changes to re-introduce compatibility with EL7 distributions, such as Red Hat Enterprise Linux 7, CentOS 7, and so on. This was made possible by the inclusion of DNF into Red Hat Enterprise Linux 7.6. The changes were contributed by Pablo Greco from the CentOS Project. Builds of livecd-tools and appliance-tools will be provided in CentOS Extras at some point in the near future by Pablo. ISO creation is now done using GNU Xorriso rather than cdrkit. This was done because Xorriso is actively developed and receiving new features. Also now, if the target distribution supports it, ISOs can be created with ia32 and x64 UEFI support. In addition, appliance-tools is now Python 3 compatible. The ec2-converter tool is deprecated and slated for removal in the next release, due to lack of maintenance and being utterly broken. If there are any users of this tool, patches and pull requests welcome on pagure.io: https://pagure.io/appliance-tools RISC-V is now experimentally supported, thanks to David Abdurachmanov of the Fedora RISC-V group. Python 2 packaging of the imgcreate module has been dropped in Fedora 30+ and Mageia 7. It is still supported for CentOS 7. ## Now what? Please check out the new release! If you have any issues with livecd-tools or appliance-tools, please file them either in Fedora or Mageia bug trackers, or preferably at the appropriate project issue trackers: * livecd-tools: https://github.com/livecd-tools/livecd-tools/issues * appliance-tools: https://pagure.io/appliance-tools/issues Have fun making live Linux systems! Best regards, Neal -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: prevent accidentally creating branches in dist-git
On Tue, Nov 20, 2018 at 9:26 AM Dusty Mabe wrote: > > > I've certainly made the mistake of accidentally creating branches > in dist-git and now being stuck with them because we can't delete > them. Now that src.fedoraproject.org (dist-git) is backed by a newer > version of pagure you can prevent creating new branches by `git push`. > > For your project in the web UI: > > - Go to the `Settings` menu > - Select `Hooks` from the left hand side > - Expand `Prevent creating new branches by git push` > - Click the checkbox > - Click `Update` > > I personally think this should be the default for all projects but > I don't know if there is a way to easily make that happen when a project > gets created. > > Hope this helps someone! This is amazing. Please tell me there's an API call to set this for all my projects? Because I just want this for every package I maintain, excluding forks (obviously)! -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide buildroot broken by dnf or dnf-plugins-core
On Thu, Nov 22, 2018 at 6:25 AM Richard W.M. Jones wrote:
>
> On Thu, Nov 22, 2018 at 12:21:04PM +0100, Jaroslav Mracek wrote:
> > The update of dnf-plugins-core and dnf-plugins-extras is ready for rawhide.
> > But I cannot make fedpkg build due to error:
> > Kerberos authentication fails: unable to obtain a session
> > Could not execute build: Could not login to
> > https://koji.fedoraproject.org/kojihub
> >
> > I will ask a college to do it for me.
>
> I can probably do it. Is it just those two packages,
> dnf-plugins-{core,extras}? Do they need to be built in a particular
> order?
>
If the buildroot is broken, then you won't be able to do it, since
dnf-plugins-core is required for mock.
But ordinarily, no, they only require DNF, so they can be built in parallel.
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Fri, Nov 16, 2018 at 6:03 PM Jonathan Dieter wrote:
>
>
> *Changes*
> The zchunk format would need to be extended to allow for a zchunked rpm
> to contain both the uncompressed chunks that were already on the local
> system and the newly downloaded compressed chunks while still passing
> signature verification. This would also require moving signature
> verification to zchunk.
>
> The rpm file format has to be changed because the zchunk header needs
> to be at the beginning of the file in order for the zchunk library
> figure out which chunks it needs to download. My suggestions for
> changes to the rpm file format are as follows:
>
>1. Signing should be moved to the zchunk format as described at the
> beginning of this section
>2. The rpm header should be stored in one stream inside the zchunk
> file. This allows it to be easily extracted separately from the
> data
>3. The rpm cpio should be stored in a second stream inside the zchunk
> file.
>4. At minimum, an optional zchunk element should be set to identify
> zchunk rpms as rpms rather than regular zchunk files. If desired,
> optional elements could also be set containing %{name}, %[version},
> %{release}, %{arch} and %{epoch}. This would allow this information
> to be read easily without needing to extract the rpm header stream.
>
> *Final notes*
> I realize this is a massive proposal, zchunk is still very young, and
> we're still working on getting the dnf zchunk pull requests reviewed.
> I do think it's feasible and provides an opportunity to eliminate a
> pain point from our compose process while still reducing the download
> size for our users.
>
If we're really considering changing the RPM file format, then we need
a proper discussion on rpm-maint@ and rpm-ecosystem@ mailing lists on
rpm.org. Can you please start a targeted discussion there?
But addressing the specific concrete suggestion here, there's a few
concerns I have:
1. This is a huge format break, which means that for the first time in
a _very_ long time, it would not be possible to reuse RHEL for Fedora
infrastructure _at all_. That's going to be a difficult problem.
There's a large legacy of systems that won't be able to handle that
new format, and unfortunately, rpm is not parallel installable in the
same manner as something like GCC or Python currently. Making it
parallel installable *is* possible (I've done it, and there have been
other attempts before), but it's not a supported thing. This is
probably the thing that would trigger a major version bump for RPM,
since it's a new archive format.
2. This also means the _entire_ ecosystem of RPM archive parsers will
break. This is not particularly insurmountable, actually, as the RPM
file format was not particularly well documented, and a new format is
an opportunity to revisit some of those old issues and try to do a
better job this go around. But it's still a challenge to deal with.
3. When you refer to the rpm cpio, I assume you're referring to only
the archive payload, right? Typically the payload is what is
compressed, and the headers are not. It sounds like you're proposing
both aspects to be compressed, and compressed differently. If we made
the RPM header an uncompressed zchunk stream and the RPM payload a
zstd-compressed zchunk stream, would we be able to support fetching
header deltas for retrieving extra information on the fly? Say, for
example, attributes like arch color, filecap properties, and so on,
that aren't in the rpm-md data for things like transaction tests
without the whole RPM?
4. I'd actually rather make it easier for the header streams to be
fetched instead of trying to make specific attributes easier in the
header payload. History has shown that any attempt at foresight here
tends to fail miserably, and common attributes are already specified
in the rpm-md primary.xml anyway, so if you're fetching the header to
retrieve an attribute, you *need* to do something weird anyway.
5. I'm not exactly sure what you mean by zchunk signing...
6. I'm wondering why we can't do a perfect reconstruction of the
original RPM, given two RPM sources that are both zchunked? We can
pull it off with repodata, so what's different about RPM that makes
that not doable?
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny wrote: > > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote: >> >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek wrote: >>> >>> > * Matthew Miller: >>> > >>> > >>> > Make it cheap to maintain branches. I expect that one what to achieve >>> > this would be to build directly out of Git, with synthesized release >>> > numbers and changelogs. This way, you can apply a lot of fixes to >>> > multiple branches without encountering mandatory conflicts. >>> >>> We are aiming for something similar what you just described. I created this >>> wiki page to describe the work briefly: >>> >>> https://fedoraproject.org/wiki/CI/source-git >>> >>> The actualy work is happening here now: >>> >>> https://github.com/user-cont/source-git >>> >>> We would love to take development off dist-git (but keep dist-git!) and >>> move it to git repos with real source code which match upstream >>> repositories. In such repo you have branches which track respective Fedora >>> versions -- you can easily cherry pick fixes. We would validate every pull >>> request in such repo and stuff would get merged only when it passes >>> testing. Right now we are trying to write minimal code to make such thing >>> work, evaluate it and present at devconf.cz to get some more feedback. >>> >>> Hopefully we would utilize clime's work to help with changelogs and release >>> numbers: https://pagure.io/rpkg-util/pull-request/15 >> >> >> So that would be cool if my work is actually used. I recommend looking at >> https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could >> use that. >> >> I planned to open a PR for python-rpkg do enable this functionality in >> Fedora but I am being delayed by work on rpkg-3.0, which is yet another *pkg >> client. >> >> Anyway, if there is some interest in making this available in Fedora soon, I >> can happily do it first. Just kick (contact) me. >> To be clear, the macros can only do the second point from "What and why?" at >> https://github.com/user-cont/source-git. > > > The README was changed meawhile so the second point from here: > https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md > The problem with merged source trees (aka source-git) is that it implies forking projects. It's an easy trap to start having vendor trees and maintain your own functionality independent from upstream. Fundamentally, I don't want having patches to be too easy, because then people _will_ do that. Fedora should strive to remain close to upstream projects and interact with them to make things better[1]. And the thing is, it's not like I'm unfamiliar with merged source models. I've worked in distributions that operated that way, and the consequence is almost always that things are patched and changed without ever interacting with upstream. Of course, that's their choice to do so, but most distributions do not have "upstream-first" as a specific goal. In addition, it may seem like it makes things easier (and maybe faster), but it actually makes things much harder and slower for everyone else. Merged source trees make it so that it's stupid easy to have light forks of everything, which means people will just patch and change things without consequence. That makes it much harder to identify changes for rebasing to newer versions, what's safe to drop, and so on. I know this because it was a problem where I work before I banished merged source trees where I work, and it remains an issue for Linux distributions that operate this way too. When patches are a burden, you will only do it when needed, and you feel more compelled to try to avoid it. Ironically, that makes it easier to move faster and update more frequently. I have not yet seen a practical example of merged source trees improving the quality of package maintenance. [1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé wrote: > > On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote: > > On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny wrote: > > > > > > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote: > > >> > > >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek > > >> wrote: > > >>> > > >>> > * Matthew Miller: > > >>> > > > >>> > > > >>> > Make it cheap to maintain branches. I expect that one what to achieve > > >>> > this would be to build directly out of Git, with synthesized release > > >>> > numbers and changelogs. This way, you can apply a lot of fixes to > > >>> > multiple branches without encountering mandatory conflicts. > > >>> > > >>> We are aiming for something similar what you just described. I created > > >>> this wiki page to describe the work briefly: > > >>> > > >>> https://fedoraproject.org/wiki/CI/source-git > > >>> > > >>> The actualy work is happening here now: > > >>> > > >>> https://github.com/user-cont/source-git > > >>> > > >>> We would love to take development off dist-git (but keep dist-git!) and > > >>> move it to git repos with real source code which match upstream > > >>> repositories. In such repo you have branches which track respective > > >>> Fedora versions -- you can easily cherry pick fixes. We would validate > > >>> every pull request in such repo and stuff would get merged only when it > > >>> passes testing. Right now we are trying to write minimal code to make > > >>> such thing work, evaluate it and present at devconf.cz to get some more > > >>> feedback. > > >>> > > >>> Hopefully we would utilize clime's work to help with changelogs and > > >>> release numbers: https://pagure.io/rpkg-util/pull-request/15 > > >> > > >> > > >> So that would be cool if my work is actually used. I recommend looking > > >> at https://pagure.io/rpkg-util/blob/master/f/macros specifically if you > > >> could use that. > > >> > > >> I planned to open a PR for python-rpkg do enable this functionality in > > >> Fedora but I am being delayed by work on rpkg-3.0, which is yet another > > >> *pkg client. > > >> > > >> Anyway, if there is some interest in making this available in Fedora > > >> soon, I can happily do it first. Just kick (contact) me. > > >> To be clear, the macros can only do the second point from "What and > > >> why?" at https://github.com/user-cont/source-git. > > > > > > > > > The README was changed meawhile so the second point from here: > > > https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md > > > > > > > The problem with merged source trees (aka source-git) is that it > > implies forking projects. It's an easy trap to start having vendor > > trees and maintain your own functionality independent from upstream. > > Fundamentally, I don't want having patches to be too easy, because > > then people _will_ do that. Fedora should strive to remain close to > > upstream projects and interact with them to make things better[1]. > > > > And the thing is, it's not like I'm unfamiliar with merged source > > models. I've worked in distributions that operated that way, and the > > consequence is almost always that things are patched and changed > > without ever interacting with upstream. Of course, that's their choice > > to do so, but most distributions do not have "upstream-first" as a > > specific goal. > > IMHO this is an overly negative view. It is making a presumption > that package maintainers are in general bad at what they do and > must be made to jump through hoops to "force" them to do the > right thing, no matter what the cost to good maintainers. > This is a fairly realistic view, because I assume packagers are inherently lazy when it comes to maintenance. That is, they'll take the easiest path possible. And that's perfectly rational. > I think we should design our systems around a positive viewpoint, > where package maintainers are in general good at what they do > and make life as easy as possible for those people. > If we designed our systems around "positive viewpoints", t
Re: Bugzilla outage/upgrade on 2 December 2018
On Mon, Nov 26, 2018 at 5:08 PM Jeff Fearn wrote: > > On 27/11/18 02:06, Emmanuel Seyman wrote: > > * Neal Gompa [26/11/2018 11:01] : > >> > >> Out of curiosity, does anyone know where the source code for Red Hat > >> Bugzilla actually is? I tried to find it a while ago, and even tried > >> to send an email asking about it (with no response...). This variant > >> of Bugzilla has features that aren't present in vanilla Bugzilla 5.x, > >> nor are they present in the Mozilla fork (bmo)... > > > > The source code isn't avaliable (although I've been told at least one > > Bugzilla developer has access to it). > > > > https://bugzilla.redhat.com/show_bug.cgi?id=478886 > > This is correct. We are in a very drawn out, and painful, process to get > this opened up. > > Dylan from BMO is helping us out by doing an audit for us, but he is > doing it as a favor, in his own time, so it's taking about as long as > you'd expect to audit a 20 year old code base in your spare time. > > Once Dylan is done, and we are putting no pressure on him to meet or > specify a time line, I'll do another round of infosec/product security > team hand shaking and then we should be able to open it. > My recent interest in RHBZ code stems from two things: * it has working SAML auth * it supports external bug tracking (though I'm not sure if the functionality has completely worked recently, and lacks pagure.io itself...) In Mageia, we're looking at revamping our identity management, and we'd like to use SSO via SAML with our BZ5 system, but sadly this code is not available for vanilla bz5 systems, and BMO uses CAS instead of SAML or OIDC. :( And of course, external bug tracking is useful for obvious reasons. :) -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bugzilla outage/upgrade on 2 December 2018
On Mon, Nov 26, 2018 at 10:59 AM Ben Cotton wrote: > > Hi all, > > If you haven't seen the banner at the top of bugzilla.redhat.com, it > is scheduled to undergo an upgrade from Bugzilla 4 to Bugzilla 5 on > December 2 2018. The outage will begin on 2 December at 0:00 UTC and > end on 2 December at 12:00 UTC. > > For more information on Bugzilla 5, see: > https://partner-bugzilla.redhat.com/page.cgi?id=whats-new.html > https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html > > Bugzilla 5.0 introduces a new REST endpoint to replace XML-RPC and > JSON-RPC. The XML-RPC and JSON-RPC APIs will remain available. > Out of curiosity, does anyone know where the source code for Red Hat Bugzilla actually is? I tried to find it a while ago, and even tried to send an email asking about it (with no response...). This variant of Bugzilla has features that aren't present in vanilla Bugzilla 5.x, nor are they present in the Mozilla fork (bmo)... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Mon, Nov 26, 2018 at 9:27 PM Brendan Conoboy wrote: > > On 11/16/18 7:50 AM, Paul Frields wrote: > [snip] > > We should skip the F31 release cycle and leave F30 in place longer in > > order to focus on improving the tooling and testing changes. These > > tooling changes will improve the overall reliability of Fedora, and > > will decrease the manual effort and complexities involved in producing > > the distribution artifacts. Although we’ve done this before to make > > “editions” happen, the intent is to track this multi-team effort more > > actively so we can (1) use the time as well as possible, and (2) give > > the work maximum transparency. > > If there is going to be a pause F30 seems like a good place to do it: > New glibc, new compiler- and a full year for them to mature. It's a > nice basis for a stable platform. What would the update policy be for > this year- same as today? It seems like you're proposing this as a > one-time event to pay down technical debt, which is great, but would > you perhaps consider doing the same thing for F31, F32, etc? The > basic reasons for technical debt will continue- why not plan to > service the debt regularly? > I'm going to have a longer post to reply about the overall topic brought up over Turkey Day, but for this specific point, I think that it would be a tremendous mistake if we allowed RHEL to influence us into slowing down the core of Fedora (see, I said the "bad" word!). In the past few years, I've been around the block a bit, being involved in different distribution release philosophies and processes. And one thing that is common among all of them is that "stuff rolls downstream". That is, an action from the top part usually has cascading effects downward. Most of us don't consider the "core"/"base platform" of Fedora to be the "top", but it is. All the decisions about how every package is built and shipped is affected by this. It would be incredibly dangerous for Fedora to take a RHEL-like approach to the core, because it means that we're deciding that the core is not a place for innovation and advancement. Now, I'll admit I have a personal stake here: much of what *I* do these days is in that part of the stack, and having that frozen would kill my ability to participate in the development of the distribution. But I'd like us to become less conservative instead of more so. I've been playing with the RHEL 8 beta for a bit now, and I have a pretty good idea what constitutes a "base" system in RHEL, and I'm afraid that it would be terrible if we froze that for a year. However, to the larger point about lifecycles and supporting hardware makers with a Fedora LTS that works for 4 years, this could be a good focus point for a new "Fedora Long-Term" WG that would work to take selected releases of Fedora and stabilize them for a period of time. This would be similar to the original Fedora Legacy and openSUSE Evergreen[1] projects. An interesting twist here is that we could take some inspiration from Debian on how they run their LTS and allow direct sponsorship for releases to be supported past their original life[2]. That means that under the auspices of the Fedora Project, interested volunteers and commercial entities could come together and maintain a release with security fixes past the 13 month life, for an additional 2 years. This approach has some advantages: notably only releases people are interested it would qualify, and the work burden scales with interest and sponsorship. The main disadvantage is that it won't happen "for free", which I think is actually a good thing here. Even Red Hat could participate in this program, though I fully expect that they won't, since they have their hands full with Red Hat Enterprise Linux. But it'd be nice if they did, because it could also be an avenue to improve the transparency between Fedora and RHEL, and give a more direct relationship (and potential for influencing improvements to RHEL that we don't have today!). It would also make it easier for the 22 other product projects that Red Hat has to use Fedora as their upstream rather than CentOS, since some folks in those communities complain Fedora is too fast for them (*hack*RDO*cough*). [1]: https://en.opensuse.org/openSUSE:Evergreen [2]: https://wiki.debian.org/LTS/ -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Tue, Nov 27, 2018 at 9:08 AM John Florian wrote: > > On 11/26/18 3:53 PM, Kevin Fenzi wrote: > > The one issue I see off hand is that koji > > tags are kind of expensive so we can't just tag everything the way we > > may want > > Can you please elaborate a bit on this? What makes them expensive? Koji tags are representations of full repositories. They work more or less the same way that Copr projects do, it's just a lot less obvious because of the way Koji represents them in the various UIs. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Sat, Nov 17, 2018 at 1:15 PM Jonathan Dieter wrote: > > Neal, thanks so much for your thoughts on this. Responses inline: > > On Sat, 2018-11-17 at 09:53 -0500, Neal Gompa wrote: > > > If we're really considering changing the RPM file format, then we need > > a proper discussion on rpm-maint@ and rpm-ecosystem@ mailing lists on > > rpm.org. Can you please start a targeted discussion there? > > Sure. > > > But addressing the specific concrete suggestion here, there's a few > > concerns I have: > > > > 1. This is a huge format break, which means that for the first time in > > a _very_ long time, it would not be possible to reuse RHEL for Fedora > > infrastructure _at all_. That's going to be a difficult problem. > > There's a large legacy of systems that won't be able to handle that > > new format, and unfortunately, rpm is not parallel installable in the > > same manner as something like GCC or Python currently. Making it > > parallel installable *is* possible (I've done it, and there have been > > other attempts before), but it's not a supported thing. This is > > probably the thing that would trigger a major version bump for RPM, > > since it's a new archive format. > > Agreed, that this would be a massive format change and should therefore > be a major version bump for RPM. New versions of RPM should still be > able to read and install old-format rpms, but, as you point out, old > versions of RPM won't be able to read or install new-format rpms. > Unfortunately, I don't see any way around this. > I don't think there's a way around it either. I just hope we do better than the last time someone tried to do this... > > 2. This also means the _entire_ ecosystem of RPM archive parsers will > > break. This is not particularly insurmountable, actually, as the RPM > > file format was not particularly well documented, and a new format is > > an opportunity to revisit some of those old issues and try to do a > > better job this go around. But it's still a challenge to deal with. > > Yes, this is going to be quite a bit of work. > > > 3. When you refer to the rpm cpio, I assume you're referring to only > > the archive payload, right? Typically the payload is what is > > compressed, and the headers are not. It sounds like you're proposing > > both aspects to be compressed, and compressed differently. If we made > > the RPM header an uncompressed zchunk stream and the RPM payload a > > zstd-compressed zchunk stream, would we be able to support fetching > > header deltas for retrieving extra information on the fly? Say, for > > example, attributes like arch color, filecap properties, and so on, > > that aren't in the rpm-md data for things like transaction tests > > without the whole RPM? > > Yes, I'm referring the the archive payload as the cpio. The zchunk > format supports the idea of separate data streams, and I was planning > to use that to put the headers in one stream and the archive payload in > another. If the header chunks are first in the zchunk file, then they > could be read without needing to read any of the rest of the file. > And, yes, we could make the header stream uncompressed if that made it > easier to parse. > Whether it's compressed or not isn't terribly important, but what is important is being able to validate the correctness before beginning any processing, including decompression. > > 4. I'd actually rather make it easier for the header streams to be > > fetched instead of trying to make specific attributes easier in the > > header payload. History has shown that any attempt at foresight here > > tends to fail miserably, and common attributes are already specified > > in the rpm-md primary.xml anyway, so if you're fetching the header to > > retrieve an attribute, you *need* to do something weird anyway. > > The main purpose of putting separate attributes in the zchunk header is > so programs like 'file' can determine some basic information about an > rpm without needing to parse the full rpm header. This data would also > be in the rpm header, so programs that read the rpm header wouldn't > care about the attributes in the zchunk header. > I see, so some simple hints for stuff like that? But that would still require awareness of the format to some degree. I guess we'd have a specific lead magic to let tools know to look for them... > > 5. I'm not exactly sure what you mean by zchunk signing... > > The zchunk format supports signing, but just for the zchunk header. > Because the header contains the checksums for each chunk, this > establishes a chain of trust for verifying the whole file. Which > brings me to... > > > 6. I'm
Re: Fedora Lifecycles: imagine longer-term possibilities
On Sun, Nov 18, 2018 at 5:30 PM Reindl Harald wrote: > > Am 18.11.18 um 23:19 schrieb Neal Gompa: > > I think it's quite obvious why. No one can really influence what's in > > CentOS. Red Hat Enterprise Linux itself is developed mostly behind > > closed doors, after forking a Fedora release. > > that must be why they ship a completly closed source windows But for Windows, ODMs/OEMs benefit from the ecosystem of components already building and targeting for that platform. And even Microsoft does provide toolkits and assistance for major PC makers to better support the Windows platform. And the Windows release lifecycle is directly set up to support PC makers. Fedora has a wonderful advantage in that our ethos and practice in developing the distribution[1] often means we're directly plugged in with the various upstreams and can help make things better. We can provide that ecosystem value for PC makers, and by that token, we can add major value over other Linux distributions and offer a positive relationship to PC makers to encourage them to ship Linux on their PCs, specifically Fedora. [1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal : Use OSBS to build the fedora container base image
On Thu, Jan 3, 2019 at 9:54 AM Dennis Gregorovic wrote: > > Forwarding info I got from Tomas off-line... > > """ > oz should be py3-ready according to clancellete (not tested by me). I've > started some work on ImageFactory, but didn't get too far as there were other > priorities. It seemed to be doable (waited on oz in that time), so if we want > to give it some resources (very rough estimation ~1month/man to get both > things running together) > > About ImageFactory maintaining - I don't think there is anybody actively > maintaining it, nearest shot is Brendan. Both mailing lists are dead from > 2014/2015. > > btw, for OSBS it should be no difference while koji builders are still > python2. ImageFactory is running there and needs to be same python version as > kojid (it is used as library, not separate process). > """ > The PRs for Koji to move to Python 3 are waiting for their review to be completed to be merged: * https://pagure.io/koji/pull-request/1117 * https://pagure.io/koji/pull-request/921 * https://pagure.io/koji/pull-request/891 Basically, as soon as someone gives a crap about it, these can be finished up, merged, and we can have Koji switched to Python 3. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default
On Wed, Jan 2, 2019 at 5:30 AM Panu Matilainen wrote: > > On 12/30/18 12:26 AM, Orcan Ogetbil wrote: > > On Fri, 7 Dec 2018 at 19:37, Ben Cotton wrote: > >> > >> https://fedoraproject.org/wiki/Changes/EnablingPythonGeneratorsByDefault > >> > >> = Enabling Python Generators by default = > > > > No objection on the change. Yet the "Generators" have a well > > established meaning in Python, which is very different than this > > proposal. > > Python Generators have been "enabled" since Python-2.4. > > > > Maybe the proposal can be renamed. > > Yup, it's not the best of names in the Python context. Also on that > note: a change is hardly a self-contained one when it affects hundreds > of Python packages. > It's marked as a system-wide change in the wiki. It was accidentally sent to the ML as a self-contained one. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
On Thu, Jan 10, 2019 at 1:59 PM Ben Rosser wrote: > > Hello, > > We had a recent discussion on this list last month about (among other > things) the current state of Pagure as a replacement for pkgdb [1]. > > I mentioned in that discussion that there are various issues which > have arisen from the deprecation of pkgdb that have made the packager > workflow ever so slightly worse. But it's not just pkgdb-- there are > lots of places where the packager workflow could use improvement. > There are parts of the process that are tedious and manual which could > be replaced with (partial) automation, or parts where automation > exists but is in need of improvement. > > For example, there are tools (namely, the "fedora-review" script) to > automate parts of the package review process. But fedora-review has > been lagging behind the packaging guidelines for some time, and has to > be manually ran by packagers over review requests. But, there's no > reason we couldn't run fedora-review automatically over every package > submission-- which might save both reviewers and submitters a lot of > time. > > Or, as another example, there's currently a lot of work going on in > the distribution to support new packaging formats-- like containers > and modules. New workflows for making containers or modules out of > existing packages are being created, and I think it's vital we make > sure these workflows and processes are designed in such a way to make > things as easy as possible for packagers. > > Anyway, as part of that discussion, I was encouraged to propose a new > Fedora Community Objective focused on improving the packaging > experience and workflow in Fedora. Community Objectives are approved > by the Fedora Council and intended to be 12-18 month goals for the > entire project. The goal of this Objective would be to identify > problems with the current packager workflow(s), put together a group > of packagers interested in fixing things, and then fix them! > > If this sounds like something you'd be interested in helping out with, > great! The Objective will need two things, if it's to succeed: > > 1. People who are interested in helping! Some people did express > interest in the other thread, but I thought I would put out a general > call for interested packagers and volunteers. Anyone who is interested > and thinks they'll have some available time is more than welcome. > Of course, I'm definitely interested! > 2. A concrete list of goals to accomplish. What glitches are there in > the current workflow, and how can they be fixed? What do you wish was > simpler, or better, or easier to do? What, basically, would make your > life easier a packager? > I think when topics like this come up, I think I've complained more or less about the same things. I hope we'll be empowered to actually make such improvements... > I've written an initial draft proposal [2] on the wiki here, though > the list of tasks to focus on is pretty sparse at present. If you are > interested in helping out, please feel free to add your own thoughts > as well. > I'll take a look when I've got a few moments and see if I can add something useful there.. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is Bodhi's fedmsg integration in the UI useful?
On Fri, Jan 11, 2019 at 7:23 AM Randy Barlow wrote: > > On Thu, 2019-01-10 at 08:34 -0800, Adam Williamson wrote: > > Was > > there some kind of design rationale for them? Or were they just added > > because 'hey, fedmsg is cool'? > > I don't know because they were added before my tenure, though I suspect > it was the latter. At least for me, it's the only way I know when my update submission succeeds, because UI responsiveness is *really bad*. But beyond that, it doesn't have much use to me. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
On Fri, Jan 11, 2019 at 7:52 AM Björn Persson wrote: > > Vít Ondruch wrote: > > Dne 10. 01. 19 v 20:47 Artur Iwicki napsal(a): > > > - Now that I've mentioned it, maybe we should add something like "fedpkg > > > fas-login"? Personally I've put "alias koji-init='kinit > > > my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to > > > solve the "koji says I'm unauthenticated" error got boring after the > > > third time. > > > > If you used Gnome Online Accounts, you would not need commands/scripts > > like this. > > I've seen that mentioned a few times. What exactly is this "Gnome > Online Accounts", and is there a reasonable way I can use it without > having to endure the rest of Gnome 3? > GOA is an aspect of the GNOME Desktop that supports linking online accounts to your user. When you log into Google, ownCloud or Nextcloud, and so on during initial setup, those are stored in GOA. GOA has the ability to store kerberos logins and initialize them as part of your login session, too. You cannot leverage GOA without the GNOME Desktop. KDE has its own system, but I am unsure if it has Kerberos support like GOA does. Pantheon Desktop has its own thing too, but that doesn't support Kerberos. > I want my FAS passkey stored in a keyring, encrypted with a master > passphrase, and I don't want to have to authenticate in advance with a > separate command. When I do for example "fedpkg build", I want to be > prompted for the master passphrase to unlock the keyring, unless the > keyring is already open. Then the FAS passkey shall be fetched from > the keyring and used in the Kerberos authentication, while the master > passphrase never leaves my workstation. But I don't want this at the > cost of having my productivity hampered by Gnome 3. > > I have poked around trying to find some "Online Accounts" program or > package, but I didn't find anything I could run from another desktop. > Sorry, you have to take the good with the bad in this case, sadly. I live with the constant kinit runs because GNOME is too much for me to bear. I consider it an acceptable trade-off really. The only reason GOA has Kerberos support is because of all the enterprise desktop stuff. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
On Fri, Jan 11, 2019 at 10:19 AM Matthew Miller wrote: > > On Thu, Jan 10, 2019 at 02:42:05PM -0800, Kevin Fenzi wrote: > > * non free submissions. What if someone submits non free content and we > > build and host it? That would not be great. > > Can we apply the same "flag and remove" approach as currently used in Copr? > My understanding is that it's a lot harder to completely remove stuff from Koji, Dist-Git, etc. than it is from Copr. And there's the whole "Red Hat really doesn't want it in there to begin with" thing... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fw: Re: OUTAGE: Koji system 2019-01-11 -> 2019-01-14
On Sun, Jan 13, 2019 at 10:08 PM Kevin Kofler wrote: > > Neal Gompa wrote: > > Well, strictly speaking, this is really only a problem for IBM > > architectures (ppc64le and s390x) because there's no economical way > > for anyone to be able to care for them. For both ARM architectures we > > support, there are a number of low-cost (in the impulse buy range, > > even!) systems that people can acquire to do local development. For > > the upcoming RISC-V port, it's practically guaranteed that we're going > > to see similar low-cost hardware so that people can be exposed to the > > platform develop relatively soon after the Fedora RISC-V port is > > mainlined. > > Well, those low-cost devices are typically: > * usable only for development/hacking/toying around, due to their form > factor (bare board), peripherals and/or (lack of) computing power, > * extremely slow at everything including building packages (just look at how > slow the relatively fast Koji ARM builders are; low-cost devices are a lot > worse than that), > * so bare that you have to spend a multiple of the purchase price of the > device to add needed development equipment (RAM, storage, I/O peripherals, > etc.), > so I am not convinced that they are really useful targets for developers. > Sorry, I was referring to systems like the OverDrive 1000[1], which are PC form-factor ARM systems. I have one of these myself, and they're very handy for doing reasonable development of software on ARM. [1]: https://softiron.com/development-tools/overdrive-1000/ -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fw: Re: OUTAGE: Koji system 2019-01-11 -> 2019-01-14
On Sun, Jan 13, 2019 at 5:42 AM Dan Horák wrote: > > On Sun, 13 Jan 2019 11:05:33 +0100 > Miro Hrončok wrote: > > > On 12. 01. 19 19:47, Kevin Fenzi wrote: > > > On 1/12/19 5:59 AM, Miro Hrončok wrote: > > >> On 12. 01. 19 14:19, Kevin Kofler wrote: > > >>> Dan Horák wrote: > > This is a reminder that this begins this Friday and will > > probably be in place for 4 days. If there are increased > > downtimes, we will update the data when we know it. > > >>> > > >>> 4 whole DAYS of Koji outage are absolutely unacceptable! > > >>> > > >>> This just shows how bad an idea it was to add those exotic > > >>> secondary architectures to the primary Koji and to make them > > >>> blocking for all builds. > > >>> We really need to go back to building secondary architectures on > > >>> secondary > > >>> Koji instances, so that they do not hold the entire Fedora > > >>> hostage for days! > > >> > > >> While I don't necessarily agree with the tone or wording, Kevin > > >> has a point here. > > > > > > I don't agree with the tone, wording or point. :) > > > > Ah, it seems my e-mail was a little pointless without providing more > > thoughts. Sorry about that. > > > > > When there were secondary arch koji's it took a number of people > > > full time to nurse along koji shadow. Often things would land in > > > primary, secondary would find a bug later and there would need to > > > be a lot of coordination and back and forth before things were > > > fixed in both places. > > > > > > Now all those folks can concentrate on the bugs as they happen in > > > primary koji, fix them faster and everyone wins. > > > > I agree with this. That clearly reduces a lot of work that would > > otherwise be carried by a group of alternate arch fighters. Also, the > > situation is more easily to read etc. > > > > No doubt that having everything in one Koji is beneficial. > > > > > If there were constant outages you might have more of a point, but > > > this is the only multi-day one I can think of, it's over a weekend, > > > noarch packages can keep building and if there's a security or > > > urgent issue we can just Exclude s390x until it's back up. > > > > It's however not just about outages. What bothers me about s390x is: > > > > * From time to time there are situations where the build waits for > > a s390x builder. > > as they wait for other arch builders too > This is actually a really bad situation. If it weren't for the fact Koji tags all resources in and regenerates the internal repos with all the arches at once, I'd suggest we should consider making it possible for each arch to independently tag in and merge into the buildroot repos. There are a number of problems with this suggestion based on how Koji currently works today. It's regrettable that it was so much more work to maintain mostly unusable architectures in shadow Koji instances, because the direct exposure has mostly had a negative effect on the packager experience, since most packagers can't do anything with the architecture and have no knowledge for fixing it. > > * Upstreams don't have access to a s390x CI service and are often > > unable to debug s390x problems without (very slow) virtualization. > > we are aware of the problem, for all non-x86 arches, but there is no > simple solution > Well, strictly speaking, this is really only a problem for IBM architectures (ppc64le and s390x) because there's no economical way for anyone to be able to care for them. For both ARM architectures we support, there are a number of low-cost (in the impulse buy range, even!) systems that people can acquire to do local development. For the upcoming RISC-V port, it's practically guaranteed that we're going to see similar low-cost hardware so that people can be exposed to the platform develop relatively soon after the Fedora RISC-V port is mainlined. The "simple" solution is to develop some way for affordable access to the equipment so that it can be cared for by more people. That's probably a job for IBM and OpenPOWER, but it's something _somebody_ needs to figure out. > > * With ppc64 removal, s390x is the only Big Endian arch in the pool > > (while ppc64 was easier to get to via CentOS CI). > > > > I just think that we are burning a lot of resources without a clear > > visible benefit. Don't get me wrong, I am no architectures expert and > > I don't intent to pretend I am. It's just that all the s390x bugs > > I've seen for packages I happen to help taking care of are from other > > Fedora maintainers who fight FTBFS for their own packages etc., never > > from any actual users. > > > > s390x just feels to me like "that weird thing that often breaks and > > nobody really cares about". I realize this view is very narrow and is > > mostly based on feelings rather than facts, however it just how it > > feels. > > > > Hence I consider it unfortunate that s390x can block the whole > > distro, even if it's just for a couple days. > > is it really such a big problem,
Re: Fw: Re: OUTAGE: Koji system 2019-01-11 -> 2019-01-14
On Sun, Jan 13, 2019 at 8:50 PM Neal Gompa wrote: > > * Buildbot (Python 3) > * Jenkins (Java) > * Vespene (Python 3) > * GoCD (Java + Ruby) > * Zuul (Python) > > Of the four listed above, only the first two are packaged in Fedora. > Buildbot is up-to-date in Fedora, but Jenkins lags behind considerably > and needs love. > Also, regrettably, I can't count. :) Yes, there's actually five options there. Zuul is actually a pretty bad option because it requires Ansible playbooks, which is overkill for 99% of projects. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default
On Fri, Dec 28, 2018 at 11:35 AM Avram Lubkin wrote:
>
> Looks like the dependency generator was turned on in rawhide. Igor has been
> making pull releases against packages because this is now creating duplicate
> requires for some packages. That would seem reasonable, but he never pushed
> the dependency generator to EPEL so packages which maintain a common spec
> file across branches require additional logic and it's creating more work
> instead of less work. The python-rpm-generators package doesn't even exist in
> EPEL. I started looking at what it would take to make it available, but the
> script that's used has no documentation and no tests.
>
python-rpm-generators is not the real upstream for that code (rpm is).
And testability would be a bit difficult because all the script does
is pull stuff from python module metadata using setuptools and print it out.
It's not going to exist in EPEL because in RHEL, the Python dependency
generator doesn't exist at all. If we enabled it for EPEL, we'd have broken
dependencies everywhere, since no RHEL Python modules would have the
necessary generated dependencies. If you'd like to ask Red Hat to add it to
RHEL 7, be my guest. However, I suspect they'll say no.
> I recommend we revert this to opt-in until a couple loose ends are tied up:
> - Tests and a readme file are created for python-rpm-generators
> - The functionality is made available in EPEL6 and EPEL7 (opt-in ok)
> (Requires python-rpm-generators RPM)
>
No. This functionality is not relevant to RHEL until a version of RHEL
includes it in the base. That will happen with RHEL 8, at which point
EPEL8 will have the functionality automatically. That's the whole
point of getting stuff like this done in Fedora first. This is why
this is a *Fedora 30 Change*.
A simple way to check if you should specify manually is to check if
%__pythondist_requires is undefined, like so:
%if ! %{defined __pythondist_requires}
Requires: python3-modA
Requires: python3-modB
...
%endif
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default
On Fri, Dec 28, 2018 at 12:38 PM Avram Lubkin wrote: > > On Fri, Dec 28, 2018 at 11:55 AM Zbigniew Jędrzejewski-Szmek > wrote: >> >> Well, now that this has been enabled, it is likely that there already >> are packages which make use of this functionality, and disabling the >> generator again would break them. So reverting the changes doesn't seem >> like a good idea. It'd also create even more chaos. > > > It's just been a week so I doubt the impact is very large and the fix is > simply to explicitly turn on dependency generation. Igor and Neal are > championing this change, so I think if they can go back and work on the > missed steps, no reason to revert in rawhide, but if no one is signs up to > fix it, then it's clearly not ready. > No. This change has already been implemented in two other Linux distributions for over a decade, Fedora is just late to the party. I *know* it works well. There are a few fixes I need to make, and they'll be made because Igor and I discovered some new corner cases, but we wouldn't have found them unless we turned it on distro-wide. >> >> Maintaining single-spec compatibility with EPEL is the responsibility >> of individual package maintainers that desire that. The changes to use >> the generators are only done in "master", so before merging those >> changes into the epel branches, the maintainers have the chance to add >> the necessary conditionals or some other solution. (Alternatively, >> disabling the generators in that specific package and continuing to >> use the manual deps is also a valid option.) > > > You seen to misunderstand how a common spec works. There are no changes made > between the branch merges. The purpose of this is to make it easier to > maintain packages across branches so packages don't languish unnecessarily. > Yes, it can be disabled per package, but isn't the point of this to save > effort. Seems like it just creates more work for other people. > You seem to misunderstand how this works. This change is not about EPEL. For this context, I couldn't possibly care any less about EPEL. If you are maintaining common specs across distributions, it is *your* responsibility to account for the differences in the distributions. Not mine. I gave you advice on how to handle the change. It's up to you to implement it. And before you think I don't care about EPEL at all, I maintain plenty of packages in EPEL. And I know how to adapt my packages to deal with changes. Heck, a good number of my packages are Fedora/Mageia/openSUSE compatible, so I know how far to go for compatibility. This has been opt-in for several Fedora releases already. There was already a warning that this would change to be opt out in a future Fedora release in Fedora 28. The whole point of this is to make it so that this is the new baseline in Fedora. This is *not* getting ported to EPEL unless the Red Hat Python team wants to implement the necessary pieces in RHEL to make it work. And for what it's worth, this is why we have branches in git corresponding to release targets. If you don't want to deal with supporting a common spec, don't. Use different ones for each target. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default
On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok wrote: > > On 28. 12. 18 18:58, Avram Lubkin wrote: > > Especially since there is no test code! > > And this is the only thing when I agree with you. > > Neal, where would be the best place to add some tests for the generator? > I can scratch something like [1] during next week. > Tests belong in the rpm repository[1]. rpm itself uses autotest, so if you want to wire the test into the existing framework, you can. However, if we're going to have tests for dep generators, you might want to place them in a subfolder in the tests directory[2] and wire them into autotools. [1]: https://github.com/rpm-software-management/rpm [2]: https://github.com/rpm-software-management/rpm/tree/master/tests -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Self-Contained Change Proposal: Enabling Python Generators by default
On Fri, Dec 28, 2018 at 4:12 PM Miro Hrončok wrote: > > On 28. 12. 18 22:10, Neal Gompa wrote: > > On Fri, Dec 28, 2018 at 1:10 PM Miro Hrončok wrote: > >> > >> On 28. 12. 18 18:58, Avram Lubkin wrote: > >>> Especially since there is no test code! > >> > >> And this is the only thing when I agree with you. > >> > >> Neal, where would be the best place to add some tests for the generator? > >> I can scratch something like [1] during next week. > >> > > > > Tests belong in the rpm repository[1]. rpm itself uses autotest, so if > > you want to wire the test into the existing framework, you can. > > However, if we're going to have tests for dep generators, you might > > want to place them in a subfolder in the tests directory[2] and wire > > them into autotools. > > I can contribute tests. Tests is what I understand. > But I would not dare to touch autotools, sorry. > You can make a subfolder and make a test file and ask for help to wire it into autotools. I don't know how to do it either. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Removal of obsolete scriptlets
On Thu, Jan 3, 2019 at 4:16 PM Igor Gnatenko wrote:
>
> I'm going to push multiple commits to packages (I'll send list later)
> which execute scriptlets which are not needed anymore for Fedora.
>
> However, people tend to keep same spec for Fedora and EPEL which makes
> everything much more complicated. So please, if you have such package,
> guard scriptlets by `%if 0%{?rhel} && 0%{?rhel} <= 8` (because I
> believe that RHEL8 doesn't have all required things).
>
> https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
The triggers that obsolete those scriptlets appear to exist in RHEL 8,
judging by the specs for some of the source packages.
Thus, `%if 0%{?rhel} && 0%{?rhel} < 8` is sufficient.
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: DNF: "There are following alternatives to this package"
On Thu, Sep 13, 2018 at 12:58 PM Tomas Orsava wrote:
>
> On 09/13/2018 06:43 PM, Mathieu Bridon wrote:
> > On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
> >> We'd like to propose a new functionality for dnf: When a user tries
> >> to install a package XYZ and dnf doesn't find it, dnf would recommend
> >> them alternative packages. These offered packages would advertise
> >> that they are an alternative for XYZ using a specially formatted
> >> Provides tag.
> >>
> >> For example, packages `python2-requests` and `python3-requests`
> >> would both have the following tag:
> >>
> >> Provides: alternative-for(python-requests) = %{version}-
> >> %{release}
> >>
> >> (Possibly via the already existing and widespread %python_provide
> >> macro in the Python case.)
> >>
> >> And when the user would try to install `python-requests`, dnf would
> >> look for packages with the relevant Provides tag and display them:
> >>
> >> # dnf install python-requests
> >> * There are following alternatives to this package:
> >> python2-requests python3-requests
> >> No match for argument: python-requests
> >> Error: Unable to find a match
> >>
> >> This would be very similar to an already existing functionality that
> >> searches for lowercase package names:
> >>
> >> # dnf install python3-REQUESTS
> >> * Maybe you meant: python3-requests
> >> No match for argument: python3-REQUESTS
> >> Error: Unable to find a match
> >>
> >> (That functionality is broken in some versions—RHBZ#1628514—so you
> >> might not see this result at the moment.)
> >>
> >> What are your thoughts?
> > It's neat, but it doesn't help catch typos, which seems like the most
> > probably case where I'd want such a feature.
> >
> > How about instead of a scheme based on provides, just quickly check if
> > a package has a "similar" name?
> >
> > Basically extend the existing check for lowercase you mention.
>
> Catching typos would be useful, and I'd certainly support that addition,
> but this doesn't really scratch the itch I'm trying to solve.
> We want to tell the user "these are exactly the alternatives available
> to you". Not guess, not rely on some typo resolution. We know what the
> alternatives are, here they are.
>
> I've talked with people working on dnf and this looks like an easy
> mechanism to add, and it will be more reliable for the use cases it covers.
>
I personally am not sure whether this is a good idea, but it
definitely should only be implemented as a plugin.
My feeling about this is that we should just specify the flag release
where we transition python-* to python3-* packages using %python_provide.
Anything else is more work for very little benefit.
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automating Package Review (Was: fedora-review -- do we have a maintainer?)
On Tue, Dec 18, 2018 at 3:10 PM Sérgio Basto wrote: > > Hi, (sorry for duplicates I sent from wrong email before) > > Nothing happened last week . > > Can you add me to https://pagure.io/FedoraReview/ and to > https://src.fedoraproject.org/rpms/fedora-review please . > > My fas user is sergiomb , people want revert mock configurations of > RPMFusion because is not working with current release , we have a non > functional fedora-review in repos , so IMHO this is the most urgent > task to do . > It doesn't matter at the moment. Currently I can't merge *any* PRs in fedora-review, due to a bug in Pagure[1]. I've already got three PRs slated for merge, and once those are out, I'll make a release. [1]: https://pagure.io/pagure/issue/4142 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dracut-sshd in fedora - ssh access to early cryptsetup/dracut shell
On Sun, Jan 27, 2019 at 9:23 AM Georg Sauthoff wrote: > > Hello, > > so I wrote dracut-sshd - a dracut module that adds sshd to the > initramfs such that one is able to remotely access early > userspace for e.g. unlocking an encrypted root filesystem or > dealing with the dracut emergency shell: > > https://github.com/gsauthof/dracut-sshd > > I would like to add it to Fedora because it adds important > functionality that is currently missing. > > There are basically two routes: > > 1) Integrate it into upstream dracut (and package it as new >package in Fedora) > 2) Package it independently and submit a review request to the >Fedora bugzilla (I could maintain that package) > > In May, 2018 I posted to the dracut mailing list > (https://www.spinics.net/lists/linux-initramfs/msg04617.html), but I > didn't receive any reply on that list. > > Thus, I lean towards following route 2) now. > > Any comments/suggestions? > > See also: > > - dracut-sshd copr repository for f28/f29/c7 > https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd/ > - Travis-CI continuous integration (tests run on f29/c7) > https://travis-ci.org/gsauthof/dracut-sshd > - >9 year old open Fedora Bug about this feature > Dracut + encrypted root + networking > https://bugzilla.redhat.com/show_bug.cgi?id=524727 > My comment there: > https://bugzilla.redhat.com/show_bug.cgi?id=524727#c28 > If you'd like to integrate this into dracut proper, just propose it as a pull request to dracut itself: https://github.com/dracutdevs/dracut Alternatively, you can become a packager in Fedora and follow the new package process: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#How_to_join_the_Fedora_Package_Collection_Maintainers.3F -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 9:49 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Nico Kadel-Garcia" > > To: "Development discussions related to Fedora" > > > > Sent: Saturday, January 26, 2019 11:06:39 PM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > It's also only been released for barely 2 weeks, it's marked as a > > major revision number, and it seems a bit late to accept for Fedora > > 30. Mark it as a candidate for Fedora 31, and move on? > > I am fine with doing that. But we are missing a chance to get some early > testing on the latest release. > Is there some way we can (ab)use Koschei to see how things would look for bash 5.0 in Rawhide? Personally, I really don't think we'd have as many problems as people fear, but if there's a way we could do something interesting to prove it, that'd be great too. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 9:55 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Frantisek Zatloukal" > > To: "Development discussions related to Fedora" > > > > Sent: Friday, January 25, 2019 4:16:45 PM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > Why is this Self-Contained Change and not a System Wide Change? > > > > It seems, at least to me, that it should be System Wide Change, according to > > https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . > > Although it's a major version, upstream is not intending to break any > existing scripts. That's why I kept it as a self-contained change. > My understanding is that generally script breakage is considered a bug and would have priority for fixing in bash anyway, so I *really* don't think there's any harm in doing this. GCC is an order of magnitude worse than bash, and we do fine with that *every year*. Something that straight up says it's not intending to break scripts that just happens to say it's a 5.0 release should not be as much of a cause for concern. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 10:01 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" > > > > Cc: "Mikolaj Izdebski" , "Michael Simacek" > > > > Sent: Monday, January 28, 2019 3:52:32 AM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > Is there some way we can (ab)use Koschei to see how things would look > > for bash 5.0 in Rawhide? Personally, I really don't think we'd have as > > many problems as people fear, but if there's a way we could do > > something interesting to prove it, that'd be great too. > > During bash-4.4 rebase, I ran all Red Hat internal tests on it to verify > nothing would break. I would check about the option to test with Koschei too. > Have you run these tests on bash 5.0 rebase yet? Also, would it be possible to get this into Fedora Dist-Git so that the checks could be run as part of any build/update/PR to the package? -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Mon, Jan 28, 2019 at 12:29 PM Ben Cotton wrote: > > == Detailed Description == > Remove packages from the distribution: > [...] > * python-urlgrabber > We don't actually have to drop this one. One of the SUSE guys submitted a pull request to port it to Python 3: https://github.com/rpm-software-management/urlgrabber/pull/8 If someone could take a look at reviewing that so it can be merged, we can keep this package around. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Maintainer test instances
On Thu, Apr 4, 2019 at 10:02 AM Kevin Fenzi wrote: > > Greetings. > > This is a periodic reminder that we have some test instances setup for > package maintainers. Please see: > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > > for more information. > > Additionally, I have just added 2 aarch64 instances (running Fedora 29). > > I hope folks will find them useful. > These are definitely awesome, thanks Kevin! Would it also be possible to get some s390x in here? It seems like it's the only arch we support that we don't have here... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Maintainer test instances
On Thu, Apr 4, 2019 at 3:27 PM Kevin Fenzi wrote: > > On 4/4/19 1:16 PM, Neal Gompa wrote: > > On Thu, Apr 4, 2019 at 10:02 AM Kevin Fenzi wrote: > >> > >> Greetings. > >> > >> This is a periodic reminder that we have some test instances setup for > >> package maintainers. Please see: > >> > >> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > >> > >> for more information. > >> > >> Additionally, I have just added 2 aarch64 instances (running Fedora 29). > >> > >> I hope folks will find them useful. > >> > > > > These are definitely awesome, thanks Kevin! > > > > Would it also be possible to get some s390x in here? It seems like > > it's the only arch we support that we don't have here... > > I'd love to, but sadly the ones we have now are: limited in number, > accessible only via a slowish link, and in a lab where we definitely do > not want to allow unrestricted access. > > I think there may be some ibm resources that have instances available, > but not sure of the details. I can try and look into getting us an > instance somewhere that we could setup as a maintainer test one... > That'd be super useful, as there are times when I have failures only in s390x, and not having a way to debug them makes it very painful. :( -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Loopy rpm subpackages dependencies
On Thu, Mar 28, 2019 at 1:43 PM Tomasz Kłoczko wrote: > > On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý wrote: >> >> Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a): >> > dnf does not provide any signing functions and I was not even aware that >> > someone implemented in base dnf building >> > functionalities (someone is using that?) >> >> No, DNF likely does not user rpmb and rpms. >> Both libraries has 21K + 15K. It is really worth the work? Note that the >> split will affect ~ 16 other packages in >> Fedora. And likely some outside of Fedora. They need to be notified of the >> split, reconsider their dependencies. For >> saving 36K? > > > Yes, I care about every possible (even smallest) cut on the elephant skin > which will die if thousand small cuts on his skin will be done :P > > If that does't matter why the rpm package build produces generates > so many subpackages?? > If on typical system most of those packages are not optional why make so many > subpackages? To make Packages table in rpm database longer only? > Not mentioning about fact that even usability of current grouping of the rpm > files has zero usability in case of multilib scenarios (which could be some > logical reason for thatcase but isn't) > Just for fun/Because we can(tm)? > > If may I point on one cardinal argument which is .. KISS!!! > > There is no any other single package which during build may require signing > library (only). Not keeping sign library in rpm-sign is purely artificial. In > other words probability that this package would be required in some multilib > scenarios is ZERO! > > Other things related to the rpm. > Why in main rpm package is possible to find whole /usr/lib/rpm/platform? That > directory contains ONLY resources used during build!!! Why main rpm package > includes documentation about building packages? =:-# > They can be used at runtime as well, especially if you use runtime-evaluated macros in scriptlets. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Loopy rpm subpackages dependencies
On Thu, Mar 28, 2019 at 7:32 AM Tomasz Kłoczko wrote:
>
> Hi,
>
> Just found that on some minimal system it is not possible to remove some rpm
> subpackages.
>
> * Current state
>
> # rpm -qa | grep rpm
> rpm-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-4.14.2.1-4.fc30.1.x86_64
> python3-rpm-4.14.2.1-4.fc30.1.x86_64
> rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
>
> python3-rpm is required by dnf so it is really hard to have manageable system
> without that part (however in extreme cases it is still possible to drop
> completely dnf).
>
> Problem is that on minimal system rpm-sign-libs and rpm-build-libs
> theoretically should be not needed, however because python module in current
> form combines in single package all its three DSOs:
>
> # rpm -ql python3-rpm | grep so$
> /usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
> /usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
> /usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
>
> it causes that it is not possible to use only core rpm package management on
> minimal system.
> I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
>
> * Proposal
>
> In current form keeping separated rpm-plugin-selinux is a bit pointless so
> that part IMO should be joined with rpm-build.
> As well probably rpm-plugin-ima could be merged with rpm-sign.
>
> With that changes total number of generated packages will be the same and
> will make IMO much more sense in case of non-devel/build systems and systems
> which are used for signing packages.
>
> Comments?
>
No. The rpm plugins are runtime activated things, that's why they are split out.
And why are you complaining about library packages?! It adds very
little in the way of space usage or such. It's also only "loopy" if
you are insane enough to split the updating of these packages into
separate transactions.
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-zstd?
On Mon, Apr 8, 2019 at 8:21 AM Neal Becker wrote: > > Neal Gompa wrote: > > > On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok wrote: > >> > >> On 08. 04. 19 13:28, Neal Becker wrote: > >> > mercurial 4.9 packages zstd and python wrapper. > >> > > >> > I think we need to use system zstd. But I don't see python2-zstd. > >> > > >> > Is anyone working on packaging python2-zstd? It would be needed to > >> > proceed > >> > with mercurial 4.9. (I haven't yet checked on version number > >> > compatibility). > >> > >> To add new python2 package, an exception from FPC or FESCo is needed. > >> > >> Can we instead update to directly to hg 5.0 in May and switch to Python > >> 3? > >> > > > > If all the reverse dependencies of Mercurial in Fedora are made ready > > in time, we probably could. But that's still past the expected release > > date for Fedora 30. > > > > Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing > > we can do is allow python-zstd in the distribution with an exception > > to allow including a python2-zstd subpackage in addition to the > > python3-zstd subpackage. > > > > I think mercurial 5.0 on python3 is not quite ready for production use. I > prefer to plan on mercurial 4.9 and package python-zstd, including a > python2-zstd. I'd like for us to ship Mercurial 5.0 on Python 3 in Fedora Rawhide for sure. I think the six(ish) months of baking in Rawhide should be sufficient for getting Mercurial ready to go for production use on Python 3 and getting the reverse dependencies ported. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-zstd?
On Mon, Apr 8, 2019 at 7:36 AM Miro Hrončok wrote: > > On 08. 04. 19 13:28, Neal Becker wrote: > > mercurial 4.9 packages zstd and python wrapper. > > > > I think we need to use system zstd. But I don't see python2-zstd. > > > > Is anyone working on packaging python2-zstd? It would be needed to proceed > > with mercurial 4.9. (I haven't yet checked on version number > > compatibility). > > To add new python2 package, an exception from FPC or FESCo is needed. > > Can we instead update to directly to hg 5.0 in May and switch to Python 3? > If all the reverse dependencies of Mercurial in Fedora are made ready in time, we probably could. But that's still past the expected release date for Fedora 30. Mercurial 4.9 is supposed to be Fedora 30, so I think the only thing we can do is allow python-zstd in the distribution with an exception to allow including a python2-zstd subpackage in addition to the python3-zstd subpackage. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Beta blocker status mail #1
On Sat, Feb 23, 2019 at 4:51 PM Tomasz Kłoczko wrote: > > On Fri, 22 Feb 2019 at 19:37, Ben Cotton wrote: >> >> As we've now reached the branch point, it's time to start weekly >> blocker status mails. > > > mdadm does not compile on fc30 > https://koji.fedoraproject.org/koji/getfile?taskID=32819259=DEFAULT=build.log=-4000 > https://koji.fedoraproject.org/koji/taskinfo?taskID=32819232 > > It would be really good if someone would create list of packages which build > failed on last fc30 MR. They did. You missed the announcement: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JLNTP72GAH5PW63PIHCG5NLPDHVTIDRH/ Moreover, there's a website to view the failures: https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html And there's a tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1674516 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: APT,Synaptic ... ORPHANED
On Tue, Feb 26, 2019 at 2:37 AM Mosaab Alzoubi wrote: > > Due to like-dead upstream and security issue, I orphan these packages: > > apt I'll take this. Then it can be updated to latest apt-dpkg instead and used for other things. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: dhcp will ship bunded bind libraries
On Thu, Feb 28, 2019 at 8:58 AM Pavel Zhukov wrote: > > All, > tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring > dhcp-libs-static with bundled version of libisc/libdns/etc > > As ISC dropped support of single thread build of BIND libraries [1] and dhcp > requires one we decided to not patch dhcp/bind build scripts anymore and ship > bundled bind libraries just like upstream (ISC) does it. It will allow to > update BIND in Fedora to newest version. So dhcp 4.4.1 can be expected in > rawhide/F31 soon! > I'm aware of FPG recommendation to avoid shipping of bundled libraries due to > its maintenance cost but maintaining of heavy patched build sctipts and > inability to ship newer versions are even worse. > > I have not find any application in Fedora repository which link with > libdhcp/libomapi. Please let me know if you aware of any. > Just add the bundled() Provides if it's building with bundled copies, per the policy: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Broken modules on rawhide
On Wed, Feb 27, 2019 at 2:20 PM Miroslav Suchý wrote: > > Dne 27. 02. 19 v 12:30 Lukas Ruzicka napsal(a): > > > > However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular > > repositories allowed. It fails with an error > > similar to what Mirek has reported. Disabling modular repositories fixed > > the problem and an upgrade was possible, but I > > see this as quite a serious issue and if it is not fixed, I will definitely > > report this as a blocker. > > > > The solution can be > dnf --setopt=module_platform_id=platform:f30 system-upgrade download > --releasever=30 > which I can put in fedora-upgrade(8) script, but will be PITA for official > upgrades. > Supposedly this will be fixed in this PR[1], but I don't know how it will be... Nothing indicates to me how this is getting populated. :/ [1]: https://github.com/rpm-software-management/dnf-plugins-extras/pull/143 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Thu, Feb 28, 2019 at 8:23 PM Dennis Gregorovic wrote: > > I have an update on the koji end. The 1.17 release will not only drop the > yum dependency, it will also have full python 3 support (except for image > building that uses oz / imagefactory). Unfortunately, there is only medium > confidence that the 1.17 release will be ready by the F30 devel freeze on > Tuesday. It depends on whether QE uncovers any issues in its final testing. > If we're not able to land the release on Tuesday, what is the backup plan? > I'm not sure. Honestly, I'd rather take a snapshot of git master that's going to be Koji 1.17 in Python 3 form for F30+ so that we can iterate and get to the final release. None of the Koji components are shipped on any of the media, it's only accessed through the repositories, so there's a very low risk there. Moreover, releng redeploys post-GA for prod, so that gives us a long window to suss out issues. We could even have staging upgraded early to "kick the tires" if need be. The worst thing that could happen if 1.17.0 goes out and there's a problem is that 1.17.1 has to be issued. In the grand scheme of things, that's really not that bad. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ditch RPM in favor of DPKG
On Tue, Feb 19, 2019 at 5:05 AM Dridi Boukelmoune wrote: > > Greetings packagers, > > I know how important RPM is to the Fedora Project, but it breaks > everything downstream and we'd be better off using DPKG as we should > have from day one. > > I'm calling this initiative fedpkg: Fedora Embraces DPKG. > > A bit of background here: I build both RPMs and DEBs for $DAYJOB and > until recently my workflow was quite painful because I needed extra steps > between git checkout and git push that involves a VM, because what we > ship as apt is in reality apt-rpm. > > It finally got enough on my nerves to locally build the things I needed and > after a month I have already amortized my efforts with the time I save not > having to deal with needless extra hoops. > > In order to successfully build debs on Fedora I needed 4 packages that > I'm now submitting for review: > > https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config > https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism > https://bugzilla.redhat.com/show_bug.cgi?id=sbuild > https://bugzilla.redhat.com/show_bug.cgi?id=apt > > I need more than reviews here. > > Three of those packages are heavy on Perl code, and I'm not a Perl > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with > the mailing list address) but bugzilla replied kindly: > > CC: perl-sig did not match anything > > Apt is a mix of C, Perl and C++ code, so I would be reassured if I > could have a C++ co-maintainer too. I'm only a C developer so if > something goes wrong outside of the C realm that would be helpful. > > Two of those packages should be runtime dependencies of debhelper. > > The current apt package should be renamed to apt-rpm, I will look up > the procedure for that to happen. I understand that when someone sees > they should run "apt-get install foo" somewhere on the web it's > helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is > dead upstream and it shouldn't be advertised as apt. > > I hope I CC'd everyone that should get this heads up, and hope to find > help for the reviews and co-maintainership. The packaging does nothing > fancy, there are quirks here and there but overall it was rather easy > to put together. And of course I would be happy to help with reviews > too in exchange. > > And thanks again to the mock developers, its design is so much better > than either sbuild or pdebuild that I barely have pain points left when it > comes to RPM packaging. > For what it's worth, this was a terrible lede for this email. And having worked extensively with both package managers, I can sincerely tell you both are ugly as hell, but rpm is less ugly than dpkg. Thankfully, I don't need to go into the reasons why, because this is not actually about switching to dpkg and its completely terrible system. If all you wanted was the rest of the tooling in so you can build Debian packages in Fedora, that's really not a problem. I made an apt-dpkg package a while ago and worked with APT upstream to make it build and have the tests work (mostly) on Fedora a couple of years ago. I imported it into COPR so you can see it: https://copr.fedorainfracloud.org/coprs/ngompa/apt-dpkg/build/860086/ Instead of renaming the apt package to apt-rpm, we can introduce the apt-dpkg package that conflicts with apt for your purposes. I wish we could have the rpm backend integrated into the Debian upstream apt, but someone needs to drive that effort, and no one really cares anymore. It hasn't happened in the past due to frustrations with working with Debian upstream, and now it's diverged so much that they are separate upstreams. My understanding is that the current upstream developers are interested in an rpm backend, but they don't want to do any effort to make it happen. Also, you can build debs using RPM spec files[1], if you're aware enough to handle the differences. :) [1]: https://github.com/ascherer/debbuild -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On Mon, Feb 18, 2019 at 4:36 PM Dridi Boukelmoune wrote: > > On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/BuildRequires_Generators > > > > = BuildRequires Generators = > > > > == Summary == > > Add possibility to generate build-time dependencies within RPM spec > > file and teach RPM and mock how to handle this. > > > > == Owner == > > * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian > > Festi]], [[User:msuchy|Miroslav Suchý]] > > * Email: ignatenkobr...@fedoraproject.org, ffe...@redhat.com, > > miros...@suchy.cz > > > > == Detailed Description == > > For many languages (Rust, Golang, Node.Js, Ruby, Python), > > BuildRequires can be automatically generated. All it takes, run some > > special tool which will output dependencies in RPM format. > > > > Q: How will it work under the hood? > > A: When you build RPM, something like this will happen under the hood… > > # rpm would perform %prep (which is supposed to abort if some > > dependencies missing and print them) > > # mock would install those dependencies and resume build > > As of today, running %configure or %cmake is part of the %build step, > not the %prep step according to the guidelines. > > Would it mean that we should move this kind of commands in the %prep > step? I think that's technically where they belong. However, focusing > on language stacks won't help for polyglot projects (for example when > using gcc in a Rust project). > Current discussion upstream indicates we'll have a new spec section for generating build dependencies. It'll happen between %prep and %build, most likely. That should not require changing the behavior of how things are done now. > > Q: Will src.rpm contain all generated dependencies? > > A: This is not known yet, we'll update page once it is known. > > > > Q: Does this mean that package builds won't be reproducible anymore? > > A: No, as long as you have same buildroot and tool which is generating > > BuildRequires is doing so in reproducible manner, it should not affect > > reproducibility. > > > > == Benefit to Fedora == > > > > Packagers won't have to pre-generate BuildRequires in the spec file > > which means it will be always updated (and correct) : > > > > * Packagers can focus of making their packages better instead of > > spending all their packaging time copying BuildRequires from > > documentation and third party tools. > > * BuildRequires are dropped as soon as they're no longer necessary > > * Packages can be easily bumped without requiring a manual BuildRequires > > refresh > > * BuildRequires and Requires generation can use similar utilities, > > making sure that the deps packages declare can also be used for > > second-level building. Packages no longer need to declare the deps of > > their second and n-th dependencies because someone forgot to declare > > them in the correct package. > > > > == Scope == > > * Proposal owners: Implement support for a feature in RPM and mock (if > > implemented properly, Koji should just work). Make use of it in Rust > > ecosystem. > > * Other developers: Maintainers of language stacks are advised to use > > this feature. > > * Release engineering: [https://pagure.io/releng/issue/8129 #8129] > > * Policies and guidelines: Packaging Guidelines need to be updated > > with instructions how to use this feature. > > * Trademark approval: N/A (not needed for this Change) > > > > == Upgrade/compatibility impact == > > Packagers and users who use repoquery might be affected (src.rpm might > > not contain generated dependencies). > > > > == How To Test == > > TBD. > > > > == User Experience == > > Users won't notice differences. > > As a mock and RPM user on Fedora, outside of my Fedora endeavors, I > beg to differ ;-) > Yeah, everyone has to update. :) -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ditch RPM in favor of DPKG
On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto wrote: > > On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune wrote: > > Greetings packagers, > > > > I know how important RPM is to the Fedora Project, but it breaks > > everything downstream and we'd be better off using DPKG as we should > > have from day one. > > > > I'm calling this initiative fedpkg: Fedora Embraces DPKG. > > > > A bit of background here: I build both RPMs and DEBs for $DAYJOB and > > until recently my workflow was quite painful because I needed extra > > steps > > between git checkout and git push that involves a VM, because what we > > ship as apt is in reality apt-rpm. > > > > It finally got enough on my nerves to locally build the things I > > needed and > > after a month I have already amortized my efforts with the time I > > save not > > having to deal with needless extra hoops. > > > > In order to successfully build debs on Fedora I needed 4 packages > > that > > I'm now submitting for review: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config > > https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism > > https://bugzilla.redhat.com/show_bug.cgi?id=sbuild > > https://bugzilla.redhat.com/show_bug.cgi?id=apt > > > > I need more than reviews here. > > > > Three of those packages are heavy on Perl code, and I'm not a Perl > > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried > > with > > the mailing list address) but bugzilla replied kindly: > > > > CC: perl-sig did not match anything > > > > Apt is a mix of C, Perl and C++ code, so I would be reassured if I > > could have a C++ co-maintainer too. I'm only a C developer so if > > something goes wrong outside of the C realm that would be helpful. > > > > Two of those packages should be runtime dependencies of debhelper. > > > > The current apt package should be renamed to apt-rpm, I will look up > > the procedure for that to happen. I understand that when someone sees > > they should run "apt-get install foo" somewhere on the web it's > > helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm > > is > > dead upstream and it shouldn't be advertised as apt. > > > > I hope I CC'd everyone that should get this heads up, and hope to > > find > > help for the reviews and co-maintainership. The packaging does > > nothing > > fancy, there are quirks here and there but overall it was rather easy > > to put together. And of course I would be happy to help with reviews > > too in exchange. > > > > And thanks again to the mock developers, its design is so much better > > than either sbuild or pdebuild that I barely have pain points left > > when it > > comes to RPM packaging. > > > > Thanks, > > Dridi > > > > [1] > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig > > [2] I'm not against apt-rpm in the base install for example > > > TLDR , apt-rpm should be retired because nobody use it since more than > 10 years . > Unfortunately, I *do* use it occasionally when working on Linux distros that use apt-rpm, as only apt-rpm can process their repo metadata. There are still a few out there that use it. That said, Fedora's apt config package should probably be retired. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ditch RPM in favor of DPKG
On Tue, Feb 19, 2019 at 7:06 AM Leigh Scott wrote: > > > Greetings packagers, > > > > I know how important RPM is to the Fedora Project, but it breaks > > everything downstream and we'd be better off using DPKG as we should > > have from day one. > > > > I'm calling this initiative fedpkg: Fedora Embraces DPKG. > > > > A bit of background here: I build both RPMs and DEBs for $DAYJOB and > > until recently my workflow was quite painful because I needed extra steps > > between git checkout and git push that involves a VM, because what we > > ship as apt is in reality apt-rpm. > > Perhaps you could post a request to Debian devel-list to switch to RPM ;-) I know this is a joke, but I'm going to answer this seriously anyway, because it's an interesting exercise. :) Well, one of the two package managers for Debian already supports RPM: smart. Gustavo Niemeyer wrote smart to support multiple low level package managers after dealing with the frustration of apt back then, and it still retains that facility today. Smart[1] still works and is present in Debian and Ubuntu. The other, apt, needs someone to contribute the rpm backend. The basic scaffolding was added a little over a decade ago (ironically, after Gustavo gave up and started developing smart), and most of the rpm-specific concepts (like Obsoletes dep clause) are supported in Debian apt but are completely unused. The librpm code in apt-rpm is mostly in its own sources, but it would need some rejiggering to plug into the current apt, as the internal APIs have been shuffled around a bit. The apt-rpm upstream maintainer is still around on this mailing list, and could probably help with this if someone expressed interest in trying to do this. :) Another bit would be a way for debhelper to emit a correctly formed spec file to pass to rpmbuild, or an application built on top of librpmbuild and librpmsign to allow a custom frontend for building RPMs. Alternatively, if they wanted to drop dh automagic, then debbuild[0] can be used as a means of supporting building debs using the RPM spec file format, giving a path to transition in that manner too. Given Debian's culture, I would expect that a rpm building frontend would need to be built rather than getting people to transition to spec files. Most likely, they'd want a way for rpm to accept debs and process them. This in itself would probably not be difficult, since it's just another archive format. In fact, there was a variant of rpm that could do this, so it's not impossible. Once they have that, then it's just a matter of churning things over, supporting both archive formats indefinitely, or even working to develop a new unified format to address pain points of both. Alternatively, a plugin for rpm and a hook for dpkg could be written so that the two package managers know what each are doing. The rpmdb information would be exported to /var/lib/dpkg/status, and dpkg actions would be written into the rpmdb with a key to indicate it was from dpkg. That would give them a path to wind down usage of dpkg/deb and switch things over to rpm. My understanding is that this has actually been done before for supporting migrations both ways by various people, but the code for those things was never released. So if someone wanted to actually seriously propose this in Debian, it *could* be done. But a strategy for the tooling needs to be addressed first. I provided a couple of ideas of how someone could do it if they wanted to. The assumption, of course, is that Debian would want to preserve the average user experience, which means not switching away from apt as their primary package manager interface (even if I think DNF is light-years ahead of it!). [0]: https://github.com/ascherer/debbuild [1]: http://smartpm.github.io/smart/ -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: BuildRequires Generators
On Fri, Feb 22, 2019 at 6:01 AM Petr Viktorin wrote: > > On 2/18/19 9:19 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/BuildRequires_Generators > > > > = BuildRequires Generators = > > > > == Summary == > > Add possibility to generate build-time dependencies within RPM spec > > file and teach RPM and mock how to handle this. > > > I am very excited about this change. Count with me for Python. Is there > a (draft) API to start coding against? > > In Python, there's an effort to enable things like this generator, e.g. > [PEP 517]. > > Here, gathering BuildRequires is a two-step process: > > - the "build backend" is specified in declarative metadata; > - then the build backend can query backend-specific metadata for > additional BuildRequires. > > Is that possible with the current plans? > > > BTW: New versions of Python's usual build system (setuptools/setup.py) > will be forward compatible with PEP 517. Please do not write generators > that use setup.py directly. We currently have no BuildRequires generators written yet, so we can Do It Right(TM) for this. :) That said, I'm not sure how we will be broadly compatible for divining setup_requires if they are specified... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: modular repositories in mock configs: please don't
On Tue, Mar 5, 2019 at 11:01 AM stan wrote: > > On Tue, 5 Mar 2019 09:08:19 +0100 > Adam Samalik wrote: > > > On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth > > wrote: > > > > Why should I care? Please, win me over. (I'm being serious.) > > > > > > > I think you should care if: > > > > a) You need to maintain multiple versions of the same app/runtime/set > > of tools tools in Fedora (or an alternative to something that already > > exists), or > > b) You only want to maintain one source branch per package for all > > Fedora releases, or > > c) You could benefit from having a build recipe in case you maintain > > app/runtime/set of tools tools represented by multiple packages that > > need to be built in the right order > > > > But if any of the above is something that you need/want to do, then > > Modularity won't help you nor hurt you in any way. > > > > > > > I view the current RPM system as reliable, standard, and > > > well-documented. It's > > > served me and the people I know that use it well for decades. I view > > > Modularity as > > > an answer to a question no one asked. It presents new problems that > > > never existed > > > and has been somewhat silently taking over RPM-land with very little > > > community > > > involvement. > > I'm not a packager, I only follow devel to see what is coming down > the pipe as a user. I'm concerned about modularity. Like Michael, I > find rpm works fine for my use case, an individual workstation. I have > a couple of comments, but since I am not the target of modularity, take > them as curiosity. > > It seems that modularity will create one more layer of indirection, so > security holes will be more prone to exist and be harder to find and > fix for the user, particularly on mixed rpm / modularity systems. > Modules are merely collections of rpms built in a special way. Sometimes that's with macro definitions to force overrides for specific configurations, and sometimes that's with filtering packages, or customizing build and runtime content. > Modularity seems to be a workaround to avoid making the system fully > multi version. Admittedly, that is a lot of work, gcc has to be > modified to create a dictionary of libraries and api calls needed in > executables, libraries have to be modified to publish their api calls, > the kernel has to sort through multiple versions of a binary checking > priorities (somehow). rpm has to be modified to allow multiple version > installation, and to do library checking to be sure that an existing > library will cover needed calls. There has to be garbage collection for > libraries no longer needed by executables on the system. etc. The up > side is there is no more shared library so numbers for libraries, so > updates will *always* succeed, and the garbage collector will take > care of no longer needed packages. Is the following a good summarization > of the purpose of modularity? Modularity is a workaround using the > pareto principle to get 80% of the benefits of multi version with only > 20% of the work. > RPM already allows multiversion installation with the caveat that there are no file collisions. The other aspects are things that can be handled by DNF. Modules are only about some of those use cases. The other major cases involve build-time customization and partitioning built packages into supportable or non-supportable groups. > Would it be practical to have a new hierarchy under /usr for > modularity, say /usr/mod, or move the current /usr to /usr/rpm and > let /usr be for modularity? This would make it easier to specify which > version of a binary to run, and which should be default in the path. > So, if I install a module with old, possibly insecure components, > because I need it for legacy purposes, I can specify it in a script, and > let the newer version be the default for general use. No. It should be possible for modular content to become non-modular and vice versa. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: state of fedora-review?
On Sun, Mar 3, 2019 at 6:14 PM Felix Schwarz wrote: > > Hi, > > I am wondering about the state of the "fedora-review" package. It seems to be > a pretty important package to ensure new stuff adhers to the latest Fedora > packaging policy. > > When I ran "fedora-review" I noticed that it was clearly not updated for some > time: There where outdated points about bundled libraries (nowadays without > special FPC exception), a warning about an unnecessary "gcc" build requirement > and many outdated links. > > Well, it turns out fedora-review fails to build from source since July 2018 > [3] (last successful koji build was in March 2018). I think at least some > things are fixed upstream [4] but the RPM package was never updated. > > > Is fedora-review still the preferred tool to do package reviews? > > > Background: > In the last weeks I spent a bit of time checking the review requests for hcc > [1] and hip [2] which form an important part of AMD's "rocm" stack. These > packages are "special snowflakes" in a sense that they are compilers/compiler > wrappers with all the shenanigans this involves (bundled llvm, explicit lib > dependencies, even dependencies on static libraries). > > Approving these libraries would require ignoring quite a few rpmlint > errors/warnings and I don't feel confident in doing so if the fedora-review > tool is obviously outdated. > (Btw: I'd highly appreciate if someone could look at the hcc/hip review > requests. These packages would enable "open source machine learning" in Fedora > and IMHO that area fits Fedora's mission pretty well.) > It is still preferred. I was hoping that the in-progress Python 3 porting PR[1] would land first, but I guess I'll have to push a Git snapshot release in... I don't want to make a new release without Python 3 support. [1]: https://pagure.io/FedoraReview/pull-request/312 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: state of fedora-review?
On Sun, Mar 3, 2019 at 7:48 PM Robert-André Mauchin wrote: > > I've got a COPR based on the devel branch: > > https://copr.fedorainfracloud.org/coprs/eclipseo/fedora-review/ > fedora-review 0.7.0 has been released and updates have been proposed for Fedora: Fedora 30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c663c80f8c Fedora 29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-aa89309322 Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-66722dfef0 Hopefully now it'll be easier to respond and release fixes going forward... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/yum.repos.d -> /etc/distro.repos.d
On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý wrote:
>
> Hi,
> I am curious whether we can move our repo files from
> /etc/yum.repos.d
> to
> /etc/distro.repos.d
>
> In Fedora 31 we are going to wipe away last left overs of YUM, so it really
> does not have sense to keep `yum.repos.d`.
>
> DNF for ages parse config files from:
> {"/etc/yum.repos.d", "/etc/yum/repos.d", "/etc/distro.repos.d"}
> Therefore the move of repo files does not require any change in DNF. It
> should be just change in fedora-repos.
> If anyone put his private repos to /etc/yum.repos.d then DNF will parse it
> too. From DNF point of view, the files can be
> split randomly across all those directories.
>
> Of course, that directory is mentioned everywhere in documentation and it
> will take ages to change it as it is written
> everywhere. But the other option is to stuck with yum.repos.d forever.
>
> Is there anything which can block this move?
>
Nothing except bikeshedding. :)
That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.
That's more or less the mechanism we've adopted for tons of other
things, and it'd be nice to have it in DNF too...
--
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RHEL8 and Mageia7 available in Copr
On Mon, Mar 11, 2019 at 7:05 AM Miroslav Suchý wrote: > > Hi, > I just added those chroots to Copr: > rhelbeta-8-x86_64 > mageia-7-i586 > mageia-7-x86_64 > > Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet. > This chroot is intended for some initial > bootstraping and testing prior RHEL 8 release and it will be removed from > Copr once RHEL 8 - or to be precise CentOS 8 - > will be released. > > Before you ask - the F30 will be added in upcoming hours. > Thanks Mirek! Also, thanks to clime, opensuse-leap-15.1-x86_64 has been enabled as well. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Mon, Mar 11, 2019 at 6:48 AM Stephen John Smoogen wrote: > > On Mon, 11 Mar 2019 at 05:29, Vít Ondruch wrote: > > > > > > Dne 09. 03. 19 v 15:37 Neal Gompa napsal(a): > > > On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > > >> > > >> Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > >>> Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > > >>>>>>>>> "MH" == Miro Hrončok writes: > > >>>> MH> On 08. 03. 19 21:16, Neal Gompa wrote: > > >>>>>> I really wish we'd allow Epochs to be reset on distribution upgrades. > > >>>>>> With dnf distro-sync (which is used by system-upgrade) Epochs don't > > >>>>>> really matter and upgrades work as intended anyway... > > >>>> MH> Let's do a Fedora change? Coordinate with FPC? > > >>>> > > >>>> We (FPC) have talked about this before but I don't think it's really up > > >>>> to FPC. The change process isn't really the right way to do it, > > >>>> either, > > >>>> since this is really a policy revision. I just think FESCo needs to > > >>>> decide whether or not it would like to relax the policy, and if so, > > >>>> how. > > >>>> > > >>>> Here are the relevant points as I see them (unless I'm forgetting > > >>>> something): > > >>>> > > >>>> * dnf system-upgrade generally handles versions going backward without > > >>>> issue. The specific case of epoch being reset is not an issue. > > >>>> > > >>>> * dnf upgrade would not handle this, causing problems for those running > > >>>> rawhide or using unsupported methods of upgrading between releases. > > >>>> > > >>>> * Those running rawhide would have to run distro-sync in order to > > >>>> upgrade (which would of course reset any locally built updated > > >>>> packages and such). They would have to do this every time any > > >>>> installed package drops epoch. > > >>>> > > >>>> * Those using an unsupported method of upgrading would need to > > >>>> incorporate distro-sync. > > >>>> > > >>>> * Dropping epoch outside of rawhide would generally be bad. > > >>>> > > >>>> * Koji and the compose process do handle things "going backwards", as > > >>>> this has happened multiple times in the past without things dying. > > >>>> What's important there is which version was most recently tagged. > > >>>> > > >>>> * Bodhi shouldn't be involved here as this would be restricted to > > >>>> rawhide. > > >>>> > > >>>> Personally I'm in support of relaxing the restriction in some form, but > > >>>> I prefer a single "drop Epoch: day" where epochs in rawhide are > > >>>> _automatically_ removed and the packages rebuilt. This gives a single > > >>>> point in time where rawhide users need to do a distro-sync in order to > > >>>> properly track updates. Allowing epochs to be dropped without > > >>>> coordination seems to me to be a burden on rawhide users, but I don't > > >>>> think a single flag day would be problematic. > > >>>> > > >>>> I would expect the first flag day to be busy. I see 756 Epoch: tags > > >>>> currently, though 161 are set to 0 for whatever reason. Afterwards I > > >>>> would expect no more than a small number of packages per cycle to > > >>>> acquire Epoch: tags. > > >>>> > > >>>> - J< > > >>> If DNF were helpful and was able to report packages, which has higher > > >>> NVR then E(NVR), > > >> > > >> I meant (E)NVR actually. > > >> > > >> > > >> V. > > >> > > >> > > >>> then I can imagine that reset of epoch could work. > > >>> Otherwise I am against resetting epochs. > > >>> > > > I'm confused, why would that matter? And DNF always reports NEVRA... > > > > > > > > > > The epoch are used in cases like: > > > > 1. There is foo version 1.0 > > > > 2. foo i
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé wrote: > > On Fri, Mar 08, 2019 at 03:07:09PM -0500, Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to > > 14.x in f30/rawhide. > > > > I reset it to 1 in subsequent builds. Now adamwill is running builds with > > it bumped to 2 again. > > > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > > even I think) where they have epoch=2. I see this as a feature that lets > > someone install Ceph's epoch=2 packages on a system and not risk > > inadvertently updating with the Fedora Ceph packages. > > The ability to have multiple different builds of the same software which > users can choose between, sounds alot like the use case for modularity. > Abusing Epoch to try to address this kind of situation feels like a pretty > undesirable approach, as this problem with suddenly clashing Epochs will > illustrate. > > If ceph in Fedora were a module, is it possible for Ceph upstream to > provide an alternate module stream of ceph too ? If so, then users > could use the normal modules features in DNF for deciding which stream > to have active on their systems. > If there was a material difference between upstream and downstream, you might have a case for it. Today, there is not. Heck, the spec file that is in Fedora is basically an openSUSE spec with Fedora conditionals in it. It even has the (IMO dumb) license header thing that openSUSE forces for all of its package spec files. Not that it's necessarily a bad thing that the spec files are identical, but I'd rather just say we should not care, since there's no appreciable difference between the two. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 9:12 AM Kaleb Keithley wrote: > > > > On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa wrote: >> >> Heck, the spec file >> that is in Fedora is basically an openSUSE spec with Fedora >> conditionals in it. > > > The ceph.spec file in Fedora is based on the upstream ceph.spec.in file; not > on anything in/from openSUSE. > > The upstream ceph.spec.in file is full of Fedora and SUSE conditionals. > > If openSUSE also used the upstream spec file then it shouldn't surprise > anyone that they are similar. > I'm keenly aware of where that spec file comes from, since I saw how it was developed. It did start out as something for Fedora, but SUSE folks started actively contributing in 2012 and merging their packaging into upstream, changing it from a Fedora-style package to a SUSE-style one. Today, Ceph packaging in OBS is fetched through a source service and used pretty much verbatim from upstream. I imagine you do something similar to bring it downstream, too. I'm not begrudging them of it, mind you. But it's a lie to say that it isn't an openSUSE-style spec file. It's nice to know that we're mostly compatible these days... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Gating Rawhide - Single package updates
On Thu, Mar 7, 2019 at 10:07 AM Pierre-Yves Chibon wrote: > > On Thu, Mar 07, 2019 at 10:24:00PM +0800, Zamir SUN wrote: > > > > > > On 3/2/19 5:02 PM, Pierre-Yves Chibon wrote: > > > On Fri, Mar 01, 2019 at 06:57:48PM -0800, Tom Stellard wrote: > > >> On 03/01/2019 01:19 PM, Ben Cotton wrote: > > >>> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates > > >>> > > >>> == Summary == > > >>> We want to gate packages on test results before they can land in > > >>> rawhide. This will reduce the amount of broken dependency, > > >>> uninstallable packages and broken composes leading to a more stable > > >>> rawhide as well as less work on the infrastructure and rel-eng teams > > >>> to keep composes working. > > >>> > > >> > > >> Does the gating prevent packages from being tagged at all so that they > > >> won't even end up in the buildroot, or does it just gate packages from > > >> going into a compose? > > > > > > It gates the package from entering the buildroot, which will impact the > > > packages > > > going into a compose, but as a side effect. > > > > > > > Given it blocks packages from entering buildroot, I wonder if it is a > > good idea to start gating whole Rawhide lifetime, I mean, from the > > starting of a ready-to-release release branched out of Rawhide? > > > > My case is, we have a set of packages to update each release. They > > cannot do in parallel - they depend on one another. Currently we only > > update them in Rawhide, because each package can get into buildroot > > shortly after we build it, and we don't need to file a > > buildroot-override. Once even packages cannot get into Rawhide > > automatically (for example, I need to click a "waive test result" or > > something), this is more like a burden. > > So what you are describing is basically the case of multi-packages update. You > want to ship as one packages that depend on each other and should be ship as > one > unit. > The current approach specifically does not support this use case. > There are two ways to go about this: > - Do not opt-in into the gating (ie: do not add a gating.yaml in your dist-git > repo) > - Do opt-in but when you need something faster, opt-out, by simply building > the > package in rawhide-candidate (or its equivalent) directly. > > > As for the Single build updates vs multi build updates ratio, I don't > > quite understand what the number is from - does it comes out of Bodhi? > > They do yes and indeed as you're mentioning they are informative but likely > not > fully representative of rawhide. > > > If it means the updates in Bodhi, I want to mention that, in my case, I > > never want to update multi build updates in a stable (or post-freeze) > > release. Thus I seldom file multi build updates in bodhi. Especially we > > don't need to file Bodhi to get packages into Rawhide at this point, > > this maybe misleading in deciding to enable gating for Rawhide. > > The bodhi updates will be filled automatically and if tests pass (or if there > are no gating.yaml) the build will land in rawhide, automatically as well, > just > as it does today. > The point of bodhi is to give us a way to see in which state is a package or > why > a package that was built did not land in the rawhide buildroot in a place that > is accessible to everyone in the community. > > > As a summarize, I think it is a good idea to have some sort of gating. > > But I think we need to think carefully if we do really need to gate Rawhide. > > I don't think there are so many ways to stabilize rawhide so that compose (for > example) pass more often than they fail (there hasn't been a successful > rawhide > compose in a week). CI and gating is one of them and one that is pretty > standard > in our industry. > I hate to be the downer here, but I'm generally opposed to this idea as it stands. My ability to develop against Rawhide is principally centered around the fact I can push packages and have them depend on each other. Today, there is no freely accessible way for people to atomically merge changes into the distribution. There's no way for people to freely create spaces to do a bunch of work on a bunch of packages at once and then merge it. We kind of fake this by having to ask releng to grant unto a packager or packagers a side-tag, which work is done there, and then it's merged back into the distribution. But that model has only worked so far because we have nothing like this in place for Rawhide, so we can push all the stuff there, make sure it works, and then merge it into branches. This is how KDE updates are done, for example. And occasionally, the GNOME desktop is updated in the same manner. The fatal misunderstanding here is that people think there's a distinction between "single" and "multi" updates in Rawhide, when in fact that doesn't exist. This proposal is doomed to failure because it assumes stable updates workflows translate to development workflows. And they don't. The reason why single
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x > in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with it > bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. > > Is there really no other way to get rid of the one or two "bad builds" where > epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? > As of right now, no. Once it goes out in a compose, that's the way it goes... I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... And EVR games like this are really annoying. :( -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > > > Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > >>>>>>> "MH" == Miro Hrončok writes: > >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: > >>>> I really wish we'd allow Epochs to be reset on distribution upgrades. > >>>> With dnf distro-sync (which is used by system-upgrade) Epochs don't > >>>> really matter and upgrades work as intended anyway... > >> MH> Let's do a Fedora change? Coordinate with FPC? > >> > >> We (FPC) have talked about this before but I don't think it's really up > >> to FPC. The change process isn't really the right way to do it, either, > >> since this is really a policy revision. I just think FESCo needs to > >> decide whether or not it would like to relax the policy, and if so, how. > >> > >> Here are the relevant points as I see them (unless I'm forgetting > >> something): > >> > >> * dnf system-upgrade generally handles versions going backward without > >> issue. The specific case of epoch being reset is not an issue. > >> > >> * dnf upgrade would not handle this, causing problems for those running > >> rawhide or using unsupported methods of upgrading between releases. > >> > >> * Those running rawhide would have to run distro-sync in order to > >> upgrade (which would of course reset any locally built updated > >> packages and such). They would have to do this every time any > >> installed package drops epoch. > >> > >> * Those using an unsupported method of upgrading would need to > >> incorporate distro-sync. > >> > >> * Dropping epoch outside of rawhide would generally be bad. > >> > >> * Koji and the compose process do handle things "going backwards", as > >> this has happened multiple times in the past without things dying. > >> What's important there is which version was most recently tagged. > >> > >> * Bodhi shouldn't be involved here as this would be restricted to > >> rawhide. > >> > >> Personally I'm in support of relaxing the restriction in some form, but > >> I prefer a single "drop Epoch: day" where epochs in rawhide are > >> _automatically_ removed and the packages rebuilt. This gives a single > >> point in time where rawhide users need to do a distro-sync in order to > >> properly track updates. Allowing epochs to be dropped without > >> coordination seems to me to be a burden on rawhide users, but I don't > >> think a single flag day would be problematic. > >> > >> I would expect the first flag day to be busy. I see 756 Epoch: tags > >> currently, though 161 are set to 0 for whatever reason. Afterwards I > >> would expect no more than a small number of packages per cycle to > >> acquire Epoch: tags. > >> > >> - J< > > > > If DNF were helpful and was able to report packages, which has higher > > NVR then E(NVR), > > > I meant (E)NVR actually. > > > V. > > > > then I can imagine that reset of epoch could work. > > Otherwise I am against resetting epochs. > > I'm confused, why would that matter? And DNF always reports NEVRA... -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking for an advice on file location in Fedora
On Wed, Mar 20, 2019 at 9:00 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 20, 2019 at 10:44:53AM +0100, Michal Ruprich wrote: > > Hi, > > > > I am preparing FRR so that it could be added to Fedora and since there > > are a lot of experienced packagers here, I would like to ask for an > > advice. FRR is a fork of quagga and it provides a couple of routing > > daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each > > daemon had its own binary in /usr/sbin and each daemon could be started > > via systemctl(including the zebra daemon which is needed to run other > > routing daemons). In FRR the developers have chosen a different > > approach. They provide a script that takes care of the start-up of all > > requested daemons - that means that all daemons are started via a single > > systemctl command. > That doesn't sound like a good idea. It seems that they reimplement > daemon management internally, which usually doesn't go well. > I've experienced this from a number of other projects. This is a seriously bad idea. Have you asked the FRR developers why they feel they can't use the service management facilities of systemd effectively? > > There are a couple of other scripts that are used for > > reloading the daemons etc. I am now wondering about where to place all > > relevant binary files and all the scripts. > Do the daemons have names that are unique enough to not cause conflicts > with other packages? If yes, then it should be OK to put them all in > /usr/bin/. (There's no reason to care about "sbin" vs "bin", since nowadays > both are included in $PATH.) > > > The upstream idea about the location is to put all binary files and all > > the scripts to /usr/lib/frr/ which does not make much sense to me. > It is actually a pretty good choice, except that you say that those > executables are supposed to be called by the users directly. If they > weren't, or if were only rarely, this upstream decision would be > appropriate. In particular, there's no effective difference between > /usr/libexec and /usr/lib/ffr, so using /usr/lib/ffr would be correct. > If you're going to stuff binaries in a non-PATH place, /usr/libexec/frr (I assume FRR is the project name, and not FFR) is where it should go, full stop. > > My > > first idea was to keep the main script in /usr/sbin and put the rest to > > /usr/libexec, but that would only make sense if the binaries and scripts > > were not meant to be run by the user, which is not the case. It is very > > well possible to start each daemon directly without interfering with > > systemd or any of the scripts. Same applies for each of the script. > > > > So the question is whether it is acceptable to keep the scripts in the > > /usr/sbin directory together with the binaries or whether I should put > > them somewhere else? > > > > I would be grateful for any ideas about this. Thanks. > In general, this project seems like it needs some help understanding how services should work. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (Java packages in 3 weeks)
On Tue, Mar 12, 2019 at 8:35 AM Mikolaj Izdebski wrote: > > On Tue, Mar 12, 2019 at 12:36 PM Neal Gompa wrote: > > This whole process was handled in the worst possible way. To sum up: > > * No one knew Java SIG was having manpower issues because Mikolaj > > didn't know how to ask for help > > You did not know that, but the situation in Java SIG is well known to > Java SIG members. Statistics speak for themselves. > I'm not a Java SIG member, so how would I know? > For example, the packager who owns the most of Java packages (point of > contacts for 480 Java packages) made his last commit in February 2017. > The second maintainer (PoC for 94 Java packages) had last commit in > 2015. The fourth (PoC of 55 packages) - last commit in March 2017. And > so on. > > Situation on mailing list is not much better. Less than 20 mail > threads in each of years 2018 and 2017. Compare with more than 150 > threads in year 2013. > > The last Java SIG IRC meeting took place in February 2013. > > > * Now it's too late because he orphaned nearly 1700 packages to force > > modularization > > I did not orphan that many packages. I orphaned about 250 packages only. > Sorry, you're right, it affects nearly that many though. > It is not too late for anything. Orphaned packages can still be > adopted. That's the whole point of this thread. > > > We could have avoided the bad ending if at any point there was an > > official call for help to increase Java SIG manpower. There wasn't. We > > could have avoided this if there was a discussion before the > > orphaning. There wasn't. > > We don't have any official process for calling for help. Other distros > (at least Debian) have it, but not Fedora. > The reason Debian has one is because people generally don't know how to work with each other there. That said, if we need a process for this for some people to be more comfortable, then that probably should be requested from FESCo. > Discussion requires more than one participating party. I started a > thread on java-devel list where I explained the situation and my plans > in detail. There was no reply on the list, not a single message. I > only had one or two private conversations about this problem. > > > We could have avoided the bad ending if people dependent on Java > > packages were given the opportunity to help. As you say, this is a > > community distro. That goes both ways. But that didn't happen. > > IMHO I've been very patient. I've given the community a lot of > opportunity to help. I never refused any help. I was and I am still > working with new contributors that want to become packagers. > At the risk of overwhelming myself with yet another SIG (I'm in Python, Go, and Rust already!), I'm willing to help as a SIG member if that's what it takes to prevent this. I don't know much about Java packaging (I have only a single Java based package), though. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages to be retired (Java packages in 3 weeks)
On Tue, Mar 12, 2019 at 7:29 AM Aleksandar Kurtakov wrote: > > On Tue, Mar 12, 2019 at 1:17 PM Dominik 'Rathann' Mierzejewski > wrote: >> >> On Tuesday, 12 March 2019 at 12:02, Mikolaj Izdebski wrote: >> > On Tue, Mar 12, 2019 at 11:49 AM Jakub Jelen wrote: >> > > >> > > Is there already a way to package the java application as a module or >> > > we will really remove all these package from Fedora? >> > >> > Most of Java packages listed in this thread are already packaged as >> > modules. Their retirement in rawhide won't directly cause their >> > removal from distribution. >> >> Maybe, but it will cause the removal of other packages that depend on >> their regular (non-modular) builds. You are forcing the hands of their >> maintainers before the infrastructure to make modular packages available >> as build dependencies to regular packages is in place to remake their >> packages into modules, let them be retired or pick up your orphans. If >> it were ready, your moving these packages to modules would be a >> non-event for everyone concerned except you. Instead of helping with >> that (or just waiting), you are about to cause the retirement of quite a >> few packages whose maintainers want nothing to do with Modularity. >> That's not excellent. > > > Dominik, that is totally ugly reply to Mikolaj! Whole Java RPM community > (note not only Fedora but Mageia and etc. too) relied on his work to keep > hundreds (or maybe even thousands) of packages rpm installable. And he has > done that for years without ever complaining! Even more he is one of the most > helpful maintainers whenever someone faces an issue. Respect should be shown > when deserved, blaming like that causes nothing but ill feelings. > Everyone should remember that this is *COMMUNITY* project and if/when someone > needs something they should be ready to jump in and do the work - whether > taking packages or helping infra guys or whatever but no one owes others > anything. > > P.S. As Eclipse stack maintainers we are directly hit by this and already > working towards turning it into module as we don't have the manpower to take > over the maintainership of pristine rpms that Mikolaj maintains. Whoever > things that's easy job is welcome to try it out! > This whole process was handled in the worst possible way. To sum up: * No one knew Java SIG was having manpower issues because Mikolaj didn't know how to ask for help * Now it's too late because he orphaned nearly 1700 packages to force modularization * This caused everyone dependent on those packages to freak * And here we are in the bad ending... We could have avoided the bad ending if at any point there was an official call for help to increase Java SIG manpower. There wasn't. We could have avoided this if there was a discussion before the orphaning. There wasn't. We could have avoided the bad ending if people dependent on Java packages were given the opportunity to help. As you say, this is a community distro. That goes both ways. But that didn't happen. So here we are, in the bad ending. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Downgrading glibc from Rawhide removed /bin/sh (!)
On Fri, Mar 8, 2019 at 3:21 AM Panu Matilainen wrote: > > On 3/7/19 5:52 PM, Florian Weimer wrote: > > * Panu Matilainen: > > > >> On 3/7/19 1:13 PM, Florian Weimer wrote: > >>> * Richard W. M. Jones: > >>> > $ sudo dnf install glibc-headers.i686 > >>> … > Downgrading: > >>> > >>> That looks like a bug in itself. > >>> > >>> The last time I looked at something similar, I saw this: RPM would not > >>> adjust a pre-existing symbolic link to a new target very late in the > >>> transaction. Like deleting old files which are gone in an update or > >>> downgrade, this does *not* happen when the unpacking of the replacement > >>> package happens, but towards the conclusion of the transaction. In the > >>> meantime, scriptlets run with the broken file system. > >>> > >>> In your case, maybe one of the scriptlet errors prevented the final step > >>> with the adjustment of the symbolic link by RPM. > >>> > >>> (Just to be clear, the symbolic link is regularly packaged, it's not > >>> something that we manage using scripts.) > >> > >> IIRC the issue is that at when ldconfig runs from the package scripts, > >> on downgrade the newer file is still on disk and thus ldconfig leaves > >> the link the way it is, but at the end of transaction it'll be gone > >> and symlinks can be broken. > > > > Is there a chance that RPM will be changed to run more scriptlets with > > the final disk contents? > > There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that > run after the entire transaction, and then the individual postun-type > scripts/triggers. What is it that you're missing? > > > > >> $ rpm -q --filetriggers glibc-common > >> transfiletriggerin scriptlet (using /bin/sh) -- /lib, /lib64, > >> /usr/lib, /usr/lib64 > >> /sbin/ldconfig > >> transfiletriggerpostun scriptlet (using /bin/sh) -- /lib, /lib64, > >> /usr/lib, /usr/lib64 > >> /sbin/ldconfig > >> > >> The %transfiletriggerpostun would've probably fixed it if it used -p > >> instead of shell. > > > > We switched to the shell for the benefit of rpm-ostree. > > > > Sigh... Will this be the motivator for rpm-ostree to finally support Lua scriptlets[1]? [1]: https://github.com/projectatomic/rpm-ostree/issues/749 -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
