[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 164 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c unrtf-0.21.9-8.el6 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4b684248e8 drupal7-7.60-2.el6 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-018b328024 icecast-2.4.4-1.el6 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-307ddb503d php-PHPMailer-5.2.27-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing GraphicsMagick-1.3.31-1.el6 python-modestmaps-1.4.7-2.el6 Details about builds: GraphicsMagick-1.3.31-1.el6 (FEDORA-EPEL-2018-ffa8017033) An ImageMagick fork, offering faster image generation and better quality Update Information: New upstream release, http://www.graphicsmagick.org/NEWS.html#november-17-2018 ChangeLog: * Tue Nov 20 2018 Rex Dieter - 1.3.31-1 - GraphicsMasgick-1.3.31 * Thu Jul 12 2018 Fedora Release Engineering - 1.3.30-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Sun Jul 1 2018 Jitka Plesnikova - 1.3.30-2 - Perl 5.28 rebuild * Sun Jul 1 2018 Rex Dieter - 1.3.30-1 - GraphicsMagick-1.3.30 * Wed Jun 27 2018 Jitka Plesnikova - 1.3.29-2 - Perl 5.28 rebuild * Wed May 2 2018 Rex Dieter - 1.3.29-1 - 1.3.29 (#1574031]) * Wed Mar 7 2018 Rex Dieter - 1.3.28-4 - BR: gcc-c++, %make_build %make_install %ldconfig_scriptlets * Fri Feb 16 2018 Rex Dieter - 1.3.28-3 - use %ldconfig_scriptlets - s/libungif/giflib * Wed Feb 7 2018 Fedora Release Engineering - 1.3.28-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild python-modestmaps-1.4.7-2.el6 (FEDORA-EPEL-2018-cdf4ff7d0b) Modest Maps python port Update Information: Update to 1.4.7 and add a python3 package to Fedora ChangeLog: * Mon Nov 19 2018 Scott K Logan - 1.4.7-2 - Fix python_provide for EPEL * Fri Nov 16 2018 Scott K Logan - 1.4.7-1 - Update to 1.4.7 - Add python3 package - Switch to Github upstream ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1648308] Upgrade perl-Net-UPnP to 1.4.5
https://bugzilla.redhat.com/show_bug.cgi?id=1648308 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Net-UPnP-1.4.5-1.fc30 |perl-Net-UPnP-1.4.5-1.fc30 |perl-Net-UPnP-1.4.5-1.fc27 |perl-Net-UPnP-1.4.5-1.fc27 ||perl-Net-UPnP-1.4.5-1.fc28 --- Comment #9 from Fedora Update System --- perl-Net-UPnP-1.4.5-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1648308] Upgrade perl-Net-UPnP to 1.4.5
https://bugzilla.redhat.com/show_bug.cgi?id=1648308 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Net-UPnP-1.4.5-1.fc30 |perl-Net-UPnP-1.4.5-1.fc30 ||perl-Net-UPnP-1.4.5-1.fc27 Resolution|--- |ERRATA Last Closed||2018-11-20 22:04:32 --- Comment #8 from Fedora Update System --- perl-Net-UPnP-1.4.5-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2018-11-21 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/21/report-389-ds-base-1.4.0.19-20181121git7ee2be8.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Thursday, 15 November 2018 at 13:48, Florian Weimer wrote: > * Przemek Klosowski: > > > I wonder if RedHat could be persuaded to modify their process to adopt > > a Fedora release instead of forking it, and backport into that > > release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate" > > (FLAC-RC :). It would require perhaps more effort on the part of > > RedHat to avoid breakage in the middle of their development cycle, but > > that's probably a good CI practice anyway. > > I'm not sure if the substantial changes in minor releases of Red Hat > Enterprise Linux would be acceptable to device vendors. Red Hat > Enterprise Linux is a commercially supported distribution, but includes > substantially more changes than typical LTS releases. What's "typical LTS", then? If you want fewer changes then you're looking at backporting security fixes only and that becomes a very tedious task as time passes. And you want to talk Fedora community into doing this? Good luck. I did such backports for a handful of EPEL packages and it was a chore. I'd have to be paid a heapload of money to work on such things on a daily basis. I've seen these discussions repeat on fedora-devel over the years. I don't expect it to be any different this time. Fedora LTS is RHEL/CentOS, period. A rolling release would be nice to have, but improving Rawhide would meet that objective just as well. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tuesday, 20 November 2018 at 08:46, Kalev Lember wrote: > On 11/19/2018 10:04 PM, Stephen John Smoogen wrote: > > Centos also ships a lot of non-Red Hat kernels and modules which > > meet various itches that people feel (xen, upstream lts, various > > gluster/ceph/arm32/etc) > > I wonder if something like this could make sense for Fedora as well, to > ship two kernel streams. "kernel" that has latest kernel, and > "kernel-lts" that has the LTS kernel that was latest when this Fedora > version was first released. "kernel" would get continuously rebased to > latest version, and "kernel-lts" would just stay on the same version the > whole life cycle. > > If some classes of users (hardware vendors) prefer LTS kernel, and some > classes of users (people installing their computers themselves and > wanting latest hardware support) prefer latest kernel, we should be able > to make both happy. Who's going to maintain kernel-lts? Having two kernel packages means twice the testing. How are you suggesting QA and Release Engineering handle that without additional manpower? Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] please review: PR 50034 - Fix various issues around dscreate and dsctl
https://pagure.io/389-ds-base/pull-request/50034 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Tue, 2018-11-20 at 12:45 +, Michael Schroeder wrote: > On Mon, Nov 19, 2018 at 08:30:14PM +, Jonathan Dieter wrote: > > Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't > > require extra CPU usage on the client side as they don't go through the > > decompress-recompress cycle that deltarpms do. Re-assembling a zchunk > > file requires no compression or decompression. > > Btw, we can easily do that for deltarpms as well. We only recompress > because we want a rpm that is bit-identical to the remote one. > > Having a '-u' option that makes applydeltarpm write a rpm with an > uncompressed payload and no payload signatures is just a couple of > lines of code. But the problem is that you would lose the signatures. To make this work, we would need to create signatures of both the compressed and uncompressed rpm (which wouldn't be a bad idea). Is there some way we could (ab)use the current rpm format to make this work, or would it be a backwards-incompatible change? Jonathan ___ 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
Hey, thanks for the detailed analysis. Comments inline. On Tue, 2018-11-20 at 00:47 +0100, s...@gmx.com wrote: > Based on work I've done in this area, I'm somewhat sceptical that this > will work out well. I spent a decent amount of time comparing various > approaches to data saving for both compressed data and regular binaries. > This was done a few months ago, so a few of the algos may have changed a > little since then, but I doubt the changes will be huge. Do you have some examples of the data you tested? > > The various things I tested were, in no particular order: > * xdelta3 (and a few similar VCDIFF based algos) > * zstd > * zchunk > * bsdiff > * courgette > * zucchini > And a few others which aren't interesting enough to mention here. > > xdelta3 is old now, but was the standard binary delta compression tool > for a long time. Of the better performing algos it has reasonably good > generation time, and works reasonably well on compressed data (still a > good way behind the top of the pile), but falls far behind on binaries. > > zstd was generally disappointing for both compressed and binary data. It's > really a compression format, not a delta generator, and while it performed > very well compared to traditional compression formats, it was unable to > compete with other tools here. > > zchunk had basically the same problems as zstd, except that the chunking > overhead made files even larger, and small symbol changes could mean that > a very large number of chunks needed to be transmitted. > > bsdiff is a larve improvement over xdelta3 in terms of final size for > binary data. It is considerably more expensive in terms of memory and cpu > to compute, but is fast to apply[0]. It works much less well on compressed > data, and really needs to work on a binary to be at its best. > > courgette is excellent at reducing binary size, and still very good at > compressed data. By data size alone it's the best of all of these, but is > somewhat complex and expensive, particularly in terms of memory. An > over view of how it works is [1] > > zucchini is an experimental delta generation tool for chromium. I can't > see much that's been published externally about it, but I found it to > compress almost as well as courgette but with greatly reduced memory use. > Code is very much a moving target, but is located at [2]. These seem to be a bit apples-to-oranges. xdelta3, bsdiff, courgette and zucchini are designed to generate deltas between two specific files. zstd is just a compression format, while zchunk is designed to download the smallest difference between two arbitrary files. You are absolutely right about the cost of small symbol changes, one of the reasons that courgette does some amount of disassembly and that bsdiff uses what it calls an "add block". Because of zchunk's design, there's no way it can benefit unless we implement some kind of disassembly, and I'm leery of going down that road. > Overall in my tests zstd/schunk gave massively worse compression compared > to modern delta algorithms (courgette, zucchini), and the total time to > download, apply, install was always slowest for zstd based approaches. I'd love to see your test methodology. I'm not surprised about the difference in delta size (which really isn't the same as compression), but I am a bit surprised by the speed differences you saw, assuming your data was compressed. If your data wasn't, do remember that rpms are compressed, so if you're creating a new delta method, it will have to decompress both the old and new rpms before generating the delta (as deltarpm does). zchunk is able to get around this extra step because it is the compression format. > So, then, the only time this would work is if the changed-chunk detection > feature of zchunk actually works effectively for RPMs. Unfortunately, > when binaries change (and when RPMs as a whole change) it's not unusual > for this to manifest as adding/removing significant chunks of data from > near the beginning of the file, which means that the chunk matching fails > and you end up with a huge and slow download. Thats... not how the chunk matching works. The chunking function uses the buzhash algorithm to try to break on consistent patterns, no matter where data is added or removed. If you remove x bytes from the beginning of the file and then add y bytes, at most one or two chunks should be affected. > If you care only about making the 50th %ile case better, then zchunk is > probably at least not any worse than what we have now. However this > will, I believe, come at the cost of making the 95th %ile case pretty > unpleasant for end users. > > I think it'd be far better to explore Howard's proposal, for per-file > delta generation (as opposed to per-RPM), and use modern delta > generation (probably courgette) to compute the delta. Maybe I misunderstood Howard's proposal, but I understood him to be suggesting that rebuilding a full rpm
[Bug 1612860] perl-Net-Pcap-0.18-9.fc29 FTBFS: stubs.inc:357:8: error: redefinition of 'struct pcap_rmtauth'
https://bugzilla.redhat.com/show_bug.cgi?id=1612860 --- Comment #10 from Fedora Update System --- perl-Net-Pcap-0.18-8.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b29814d978 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23
https://bugzilla.redhat.com/show_bug.cgi?id=1651151 --- Comment #5 from Fedora Update System --- perl-FFI-CheckLib-0.23-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-743cb3ece4 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-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", then email based code contribution would have completely died out. We wouldn't have aggravating systems like Gerrit. We wouldn't really look at CI much, either. All of those things are around the "negative" or "pessimistic" viewpoint. With email based contribution, it's designed around forcing people to sift through mail list archives to figure out what's going on, and forcing other people to review changes on a patch by patch basis, rather than as a whole series. Gerrit is a step up from that, but still imposes pain on both sides specifically because it assumes that individual patches are bad. These models are all about inflicting pain. CI systems are designed around the fact that most people do not test or validate their code changes to make sure they work. Or if they do, they don't quite hit all the cases. And CI deals with that. You're confusing this with trust. And yes,
Re: Fedora Lifecycles: imagine longer-term possibilities
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. 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. No matter what we do there will always be maintainers who don't do a good job at sending stuff back upstream. We see that today in places but they are a minority. Most people learn pretty quickly that updating downstream-only patches to work with new versions is painfull and so it is in their own interests to get stuff upstream. Even today though, we could & should do more to identify where we have problems. ie something that looks at patches applied in Fedora, and reports on how long they have existed for, and across how many version rebases they've existed. This could show places where extra help / push is needed to get stuff back upstream. > 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. You can't actually "banish" merged source trees in practice. At most you end up pushing them
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 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 > > As for Fabio's question below if this would imply mirroring upstream Git > repos in our DistGit: If rpkg macros are employed (linked above), then > both use-cases (mirroring and uploading tarballs) will be possible. It > will depend on packager's decision for each individual package and you > could switch between these two anytime. It would also actually mean that > development stays on DistGit and is encouraged there. > > M. > > >> >> >> >> Tomas >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23
https://bugzilla.redhat.com/show_bug.cgi?id=1651151 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-FFI-CheckLib-0.23-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d8d7c922cc -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2018-11-21 from 17:00:00 to 18:00:00 GMT At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. Agenda is in the https://gobby.fedoraproject.org/cgit/infinote/tree/epel-meeting-next Please send items to be talked about to the mailing list epel-devel@lists.fedoraproject.org Source: https://apps.fedoraproject.org/calendar/meeting/9356/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2018-11-21 from 17:00:00 to 18:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. Agenda is in the https://gobby.fedoraproject.org/cgit/infinote/tree/epel-meeting-next Source: https://apps.fedoraproject.org/calendar/meeting/9364/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: prevent accidentally creating branches in dist-git
This is good to know. I should enable it on some of the packages that I maintain. On Tue, Nov 20, 2018 at 9:25 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! > Dusty > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann > wrote: > > > > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500: > > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote: > > > > > > > I understand this argument, but I think more and more desktop users > > > > are being trained that updates happen on a schedule they didn't > > > > choose > > > > and are hard to avoid. This is how most mobile operating systems > > > > function. > > > > > > iOS prompts you for the yearly updates, and it can be avoided if you > > > really want. > > > > > > macOS requires you to specifically choose the yearly update, though > > > they may have changed with Mojave. > > > > > > Not sure about Android, but the fact that Google has had to twist > > > things into a knot to try and get updates out to users indicates that > > > upgrades to Android aren't being pushed out for the most part. > > > > > > Windows is the only one forcing upgrades, and it is perhaps one of > > > the > > > reasons that hardware vendors are showing more interest in Linux as > > > people are now more willing to consider anything other than Windows. > > > > > > Really, the only place where forced upgrades are happening, are > > > accepted, and seem to actually work are on the application side and > > > that is because, demonstrated by the web browsers, frequent updates > > > can be done unobtrusively and reliably. > > > > And with the named examples are you gonna get any support and updates > > if you decide to hold off an upgrade to a newer OS? I doubt. > > I can certainly hold off upgrade to Android 9 on my phone, but that > > doesn't mean I'm gonna get any further updates for Android 8 from the > > phone vendor. > > There is a huuuge difference between "not forcing upgrades" and > > "providing supported and secure way to stay on the current release". > > I think this tied up with one of the major problems we are trying to > solve with Fedora Modularity, the "Too Fast, Too Slow" problem. I think identifying which components move too slow or too fast would be a good start - even if those lists might depend on the specific user or use-case. I am not sure it is bad for Fedora to only have a single supported > "release." If you refuse an upgrade, you're on your own. If you > refuse it because you're going on a trip, have a presentation, etc. > and plan to do it later, you generally don't care. If you do it > because you don't want your system to change, I am not sure Fedora > should be your distribution of choice (I'll introduce you to my > friends CentOS and RHEL). > > If we did a "stable rolling release base" that, described simply and > incompletely, had a beta and stable option where you knew your > hardware would work and your apps would run I think most users, > desktop and server, would be happy. What about aliasing fedora-N to "rolling-beta", and fedora-N-1 to "rolling-stable" (similar to what Debian does)? Every 6 months or so, rolling-stable users would get an upgrade to a fedora release that's been well-used and -tested for about 6 months. (Which I guess is what some people already do manually.) We only need to make sure that the upgrade path always works for, say, the last 4 fedora releases (or however many we need to support upgrading from). Upgrades from N-2 to N are already supposed to work (I think), so this shouldn't be too hard. (Also, silverblue would make this really easy, by "just" automatically switching to the new N-1 branch every 6 months, when N-2 hits EOL). That way, the number of supported fedora releases stays the same, and only the upgrade path needs to be reliable for longer. Fabio We use the "beta" to find > hardware regressions and to signal hardware we are dropping support > for or adding new support for, and we use stable for people who want > to get things done. Layer on Modules. containers and Flatpaks and we > have the apps moving on their own speed on this base. Yes, it creates > a matrix, but it one we have been working on CI to support already and > one that I think users will actually embrace. They don't need to know > the whole matrix, just how to adjust if the defaults aren't what they > want. > > I think this gets us: > * what we think the hardware vendors need (continuous support) > without blowing up our version count > * smaller QA targets for various pieces (and we are already planning > all of these pieces) > * a stable leading edge solution that by "pinning" your app version > feels like a rolling release and a traditional release at the same > time > * reduce our work on keeping releases active and some of our > backporting footprint > * increases the footprint of people testing and using our innovation in > the OS > > regards, > > bex > > > > > Jiri > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >
Re: Fedora Lifecycles: imagine longer-term possibilities
On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann wrote: > > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500: > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote: > > > > > I understand this argument, but I think more and more desktop users > > > are being trained that updates happen on a schedule they didn't > > > choose > > > and are hard to avoid. This is how most mobile operating systems > > > function. > > > > iOS prompts you for the yearly updates, and it can be avoided if you > > really want. > > > > macOS requires you to specifically choose the yearly update, though > > they may have changed with Mojave. > > > > Not sure about Android, but the fact that Google has had to twist > > things into a knot to try and get updates out to users indicates that > > upgrades to Android aren't being pushed out for the most part. > > > > Windows is the only one forcing upgrades, and it is perhaps one of > > the > > reasons that hardware vendors are showing more interest in Linux as > > people are now more willing to consider anything other than Windows. > > > > Really, the only place where forced upgrades are happening, are > > accepted, and seem to actually work are on the application side and > > that is because, demonstrated by the web browsers, frequent updates > > can be done unobtrusively and reliably. > > And with the named examples are you gonna get any support and updates > if you decide to hold off an upgrade to a newer OS? I doubt. > I can certainly hold off upgrade to Android 9 on my phone, but that > doesn't mean I'm gonna get any further updates for Android 8 from the > phone vendor. > There is a huuuge difference between "not forcing upgrades" and > "providing supported and secure way to stay on the current release". I think this tied up with one of the major problems we are trying to solve with Fedora Modularity, the "Too Fast, Too Slow" problem. I am not sure it is bad for Fedora to only have a single supported "release." If you refuse an upgrade, you're on your own. If you refuse it because you're going on a trip, have a presentation, etc. and plan to do it later, you generally don't care. If you do it because you don't want your system to change, I am not sure Fedora should be your distribution of choice (I'll introduce you to my friends CentOS and RHEL). If we did a "stable rolling release base" that, described simply and incompletely, had a beta and stable option where you knew your hardware would work and your apps would run I think most users, desktop and server, would be happy. We use the "beta" to find hardware regressions and to signal hardware we are dropping support for or adding new support for, and we use stable for people who want to get things done. Layer on Modules. containers and Flatpaks and we have the apps moving on their own speed on this base. Yes, it creates a matrix, but it one we have been working on CI to support already and one that I think users will actually embrace. They don't need to know the whole matrix, just how to adjust if the defaults aren't what they want. I think this gets us: * what we think the hardware vendors need (continuous support) without blowing up our version count * smaller QA targets for various pieces (and we are already planning all of these pieces) * a stable leading edge solution that by "pinning" your app version feels like a rolling release and a traditional release at the same time * reduce our work on keeping releases active and some of our backporting footprint * increases the footprint of people testing and using our innovation in the OS regards, bex > > Jiri > ___ > 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 -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1612860] perl-Net-Pcap-0.18-9.fc29 FTBFS: stubs.inc:357:8: error: redefinition of 'struct pcap_rmtauth'
https://bugzilla.redhat.com/show_bug.cgi?id=1612860 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #9 from Fedora Update System --- perl-Net-Pcap-0.18-7.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f4fa442797 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora Upgrade - release criteria update proposal
On Sun, Nov 18, 2018 at 9:49 PM Frantisek Zatloukal wrote: > We have encountered a bug[0] which seemingly “broke” offline updates after > systems were upgraded from an older Fedora to Fedora 29 and had some > multilib packages installed. After the discussion at last week's Release > Retrospective meeting, I am proposing some changes to our blocking > criterions in order to address similar issues in the future: > > What we test now > > We are currently blocking on upgrading from Fedora n-1 and n-2 releases > only with default package set installed. > > What we can test > > We can alter our upgrade test cases to also verify that updates after an > upgrade work. The test case might look like this: > >- > >Install Fedora n-1 >- > >Upgrade to Fedora n (updates-testing disabled) >- > >Enable updates-testing >- > >Update to latest packages >- > >Verify that upgrade and update went fine and that the multilib >packages installed before are still present > > > Apart from that, we can add (Final Blocking) test case > upgrade_dnf_current_workstation_multilib / > upgrade_dnf_current_minimal_multilib which will test upgrades (and then > updates as described above) with at least one i686 package installed on > x86_64 system. The other (less-generic, but closer to what users probably > do have on their systems) approach would be to test upgrade with steam (or > wine) installed. > > > What are our opinions about this? > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1642796 > I think Adam is right and this was not related to just upgraded systems. So the proposal can be to add a "multilib update must work" criterion (and optionally add a test case for it). The question is whether it is needed. If we knew that multilib updates were broken when we discussed that during the blocker bug meeting, would we have accepted it as a blocker (as affecting a large portion of our user base), or not? I think we would've accepted it as a blocker. Updates must work in general, not just for a default system installation. So if others agree with me on this, no new criterion might be needed. If others disagree, they'll probably also disagree with a dedicated criterion for exactly this use case :-) A new test case can of course be added, sure. Or perhaps suggest an optional step to the existing system update test case, if we don't want to have a fully dedicated test case for this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1644251] Upgrade perl-Template-Toolkit to 2.28
https://bugzilla.redhat.com/show_bug.cgi?id=1644251 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Template-Toolkit-2.28- ||1.fc30 Resolution|--- |RAWHIDE Assignee|tcall...@redhat.com |jples...@redhat.com Last Closed||2018-11-20 09:37:10 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
prevent accidentally creating branches in dist-git
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! Dusty ___ 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: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. As for Fabio's question below if this would imply mirroring upstream Git repos in our DistGit: If rpkg macros are employed (linked above), then both use-cases (mirroring and uploading tarballs) will be possible. It will depend on packager's decision for each individual package and you could switch between these two anytime. It would also actually mean that development stays on DistGit and is encouraged there. M. > > > > Tomas > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On Mon, Nov 19, 2018 at 08:30:14PM +, Jonathan Dieter wrote:
> Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't
> require extra CPU usage on the client side as they don't go through the
> decompress-recompress cycle that deltarpms do. Re-assembling a zchunk
> file requires no compression or decompression.
Btw, we can easily do that for deltarpms as well. We only recompress
because we want a rpm that is bit-identical to the remote one.
Having a '-u' option that makes applydeltarpm write a rpm with an
uncompressed payload and no payload signatures is just a couple of
lines of code.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
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: Salman Siddiqui
On Thursday, 15 November 2018 at 15:18, Salman Siddiqui wrote: > Hello everyone! > > I've been working on Java Mission Control. It's a profiling and diagnostics > tools for Java applications that was open-sourced by Oracle earlier this > year (along with Java Flight Recorder). The project is now under the > OpenJDK umbrella and I've been working on packaging it. Welcome, Salman. Fedora needs more Java packagers and your contribution is much appreciated. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
On Tue, Nov 20, 2018, 12:42 Tomas Tomecek > * 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. > So you'd move to mirroring upstream git repositories? I personally wouldn't want to do that for my packages ... I like the current workflow with uploading the official tarballs to the fedora lookaside cache - it feels like a cleaner solution than effectively light-forking basically every open source project in existence ... Additionally, what's the effect on disk usage? git repositories can get quite large. Fabio > Hopefully we would utilize clime's work to help with changelogs and > release numbers: https://pagure.io/rpkg-util/pull-request/15 > > > Tomas > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
> * 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 Tomas ___ 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: Call for libtimidity owners
Thank you Hans. On 20/11/18 09:58, Hans de Goede wrote: > Hi, > > On 17-11-18 12:18, Antonio Trande wrote: >> Regarding https://src.fedoraproject.org/rpms/libtimidity/pull-requests, >> please i need permissions to build libtimidity on epel7 branch. >> >> On 15/11/18 13:22, Antonio Trande wrote: >>> Hello! >>> >>> Please, take a look to >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1630466 >>> https://src.fedoraproject.org/rpms/libtimidity/pull-requests >>> > > Sorry for being slow to respond to this. I see that Igor Gnatenko > has already taken care of this, thank you Igor. > > I've made you a co-admin of the libtimidity package so that you > can directly create any future changes you want to do, including > creating new branches. > > Regards, > > Hans > > -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x6e0331dd1699e4d7 GPG key server: https://keys.fedoraproject.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1651494] Upgrade perl-JSON-XS to 4.0
https://bugzilla.redhat.com/show_bug.cgi?id=1651494 Paul Howarth changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-JSON-XS-4.0-1.fc30 Resolution|--- |RAWHIDE Last Closed||2018-11-20 05:23:40 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=31014940 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1651494] Upgrade perl-JSON-XS to 4.0
https://bugzilla.redhat.com/show_bug.cgi?id=1651494 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|emman...@seyman.fr |p...@city-fan.org -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Call for libtimidity owners
Hi, On 17-11-18 12:18, Antonio Trande wrote: Regarding https://src.fedoraproject.org/rpms/libtimidity/pull-requests, please i need permissions to build libtimidity on epel7 branch. On 15/11/18 13:22, Antonio Trande wrote: Hello! Please, take a look to https://bugzilla.redhat.com/show_bug.cgi?id=1630466 https://src.fedoraproject.org/rpms/libtimidity/pull-requests Sorry for being slow to respond to this. I see that Igor Gnatenko has already taken care of this, thank you Igor. I've made you a co-admin of the libtimidity package so that you can directly create any future changes you want to do, including creating new branches. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1651494] New: Upgrade perl-JSON-XS to 4.0
https://bugzilla.redhat.com/show_bug.cgi?id=1651494 Bug ID: 1651494 Summary: Upgrade perl-JSON-XS to 4.0 Product: Fedora Version: rawhide Component: perl-JSON-XS Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, p...@city-fan.org, perl-devel@lists.fedoraproject.org Latest Fedora delivers 3.04 version. Upstream released 4.0. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1651495] New: Upgrade perl-libintl-perl to 1.31
https://bugzilla.redhat.com/show_bug.cgi?id=1651495 Bug ID: 1651495 Summary: Upgrade perl-libintl-perl to 1.31 Product: Fedora Version: rawhide Component: perl-libintl-perl Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Latest Fedora delivers 1.30 version. Upstream released 1.31. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1651484] New: Upgrade perl-Data-Types to 0.15
https://bugzilla.redhat.com/show_bug.cgi?id=1651484 Bug ID: 1651484 Summary: Upgrade perl-Data-Types to 0.15 Product: Fedora Version: rawhide Component: perl-Data-Types Assignee: robinlee.s...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: ktdre...@ktdreyer.com, m...@v3.sk, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com Latest Fedora delivers 0.14 version. Upstream released 0.15. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
