Re: Logwatch - looking for testers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 http://fpaste.org/GEwJ/ Kevin DON'T PANIC On Fri, 4 May 2012, Reindl Harald wrote: Am 04.05.2012 18:16, schrieb Kevin Fenzi: On Fri, 04 May 2012 18:07:04 +0200 Reindl Harald wrote: that is not my point my point is when i make a bugreport for F15/F16 why it is first built for F17, notified and a day later built for F16 There may be any number of reasons for this: * Maintainer is doing additional testing to make sure the update doesn't cause problems to the older stable release. * Maintainer may be waiting for some additional patches/fixes to land so the update can include all of them as well as that fix. * A new upstream release may be pending, and the maintainer may want to wait and push that. I'd suggest being polite and understanding and simply note that you are still waiting for an update for an older release. There are sometimes good reasons not to simply push the same change to all branches and update them at the same time. i do not speak about pushig them to updates-testing or even stable i speak about "give me a koji-build which i can test" in my opinion this is a big difference -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJPpBULAAoJECUta4+ZhgxAW24P/Ag4XcdCAKa8WfWn7SMzfCb8 8uc4QZyAdbJ8Kx73qcdEMa2Tm+eAz90p/JJdpIKCAVy1hmFPocRa0ZuVPwb9jgkF lOqHqH+aAYnEGFTaLwqQVgjUtCuL0A6EiklMl9MjjOmQERulhU4oMETtzN+aBg5j gDljLFep8t/ERJRwMEuqLSweZ8Y765EDUtpv4GdfC0O5RdsT5gMR9Or+Rtf+msJn I43wGx+33/eBQE5BGc/+iGdNC4tVbIqcnm/EonJaSsul4bbTqH5fONcJ9DE9JLoQ sOKr5SISIgpOihKXIYCeq+efNyeJ9wHSNYq/40hI088/y/MkpWMkKinFJTZuun/l m6ZYHVyf52+Xg12vpxuEzhrVn17Xb8egOlk1OtXKo0ajDPaUeFtwFzlQ8Z7Zcm7Y tiJMaAKhe0bOee+2j1Mb44JUy5YiP7mxOf8POIdbFzWKNnQHNEd6MJuf7MM000Ul 3Hi3P1XGnF7jlwtx1C09XZu2tK19m/96NngeyvuCKCJkWapCxdtF2qgZ8rdnT0Cv DkzJLnMWAvT/zKrmR4JPyKt+62ZiepVfQYLhCgzXZc+KKoq0kdul/rFgvp/FwkWa /fg/Jn06gIiINKXNGMyRWzhSLYCwZq1Vpp0Qpnn+dmwpt52Uzrk37qM9iDjIe35X DPrd93W/vq4HjNYqvwL0 =QkR4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Planned Outage - network hardware updates - 2024-08-27 15:00 UTC
The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list. -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide
On Mon, Jan 08, 2024 at 11:05:33AM +0100, Milan Crha wrote: > On Mon, 2024-01-08 at 10:34 +0100, Milan Crha wrote: > > I'll handle those I've commit rights for, which is most of them. > > > > ... > > > >fedpkg build --target=f40-build-side-80962 > > > Hi, > the leftover packages to be done, for which I do not have commit > rights, are: > >elementary-calendar >evolution-chime (which is part of pidgin-chime) >gnome-panel >phosh Phosh is done. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removing deprecated %patch syntax from go-sig's packages
On Tue, Jan 09, 2024 at 05:30:51PM +, Maxwell G wrote: > Hi everyone, > > RPM has deprecated the `%patchN` syntax in favor of `%patch -PN` where > `N` is the patch number. See the RPM documentation for more information > [1]. In current RPM versions, this syntax only emits a deprecation > warning, but support for this syntax has been removed completely on the > rpm master branch [2]. Around 100 packages maintained by the go-sig > still use this syntax. > > Later this week/early next week, I will run this script [3] over the > affected go-sig packages [4] to update them to the modern patch syntax. > For example, the script will change: > > %patch0 -p1 -> %patch -P0 -p1 > %patch0005 -p2 -> %patch -P0005 -p2 > > If anyone has any objections or would like to exclude a package, please > let me know. Thanks for doing this... I assume you plan to get it all done before the mass rebuild starts? (2024-01-17) kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass rebuild: git push --no-verify
On Tue, Jan 16, 2024 at 02:50:43PM -0700, Jerry James wrote: > Given the problems we had with font packages not being rebuilt in the > last mass rebuild, can we ensure that the mass rebuild script uses > "git push --no-verify" instead of plain "git push"? > > See: > - https://bugzilla.redhat.com/show_bug.cgi?id=2233878 > - > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7IIZPEC6B4BEOOOV5YFEUGOONNOH5LZO/ I suppose this might be a good idea... I'd be afraid of what it might break, while fixing the fonts packages though. But of course if it was completely broken it would fail after that anyhow... kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: Mass rebuild: git push --no-verify
On Thu, Jan 18, 2024 at 09:15:18AM -0700, Jerry James wrote: > On Thu, Jan 18, 2024 at 4:50 AM Tomas Hrcka wrote: > > This is not a good idea. Because of a few packages that are not rebuilding > > we would disable the hook for every push the script does. > > My thinking is that the hook is not useful for automated build scripts > anyway, so disabling it doesn't hurt. See my previous replies in this > thread. yeah... * Current setup with the hook: Bunch of fonts don't even get touched by the mass rebuild Some other packages with problems caught by the hook also are completely missed. * With --no-verify: Bunch of fonts do rebuild in the mass rebuild Some packages with problems get a mass rebuild commit at least and attempted build. It might fail, but it's at least tried. The mass rebuild is only doing a bump/rebuild. There's no reason it should ever cause something that be caught by the hook, and if it did, it would be better for it to do the commit anyhow and cause a failed build. IMHO. So, I think we should run with --no-verify. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: Mass rebuild: git push --no-verify
On Thu, Jan 18, 2024 at 08:24:38PM +0100, Björn Persson wrote: > > If, hypothetically, a defect in the mass-rebuild script would corrupt > thousands of spec files, how easy would it be to write a mass-revert > script to repair the damage? The mass-revert script shouldn't just > revert the latest commit in every package, because the corruption might > not have happened in every package, and some might have been reverted > manually in the meantime. The mass-revert script would need to verify > that it reverts only commits done by the defective mass-rebuild script. > > If that's nontrivial to get right, then it seems to me that there is > value in a hook that validates changes made by a script. That seems pretty hypothetical. The pre-push check simply looks at the sources/patches defineed in the spec and checks them against the sources file. The mass rebuild script only uses rpmdev-bumpspec, which should only change the release and add a changelog entry (or even less if the spec is using rpmautospec). Should these font packages get fixed? Absolutely. But I think doing no-verify helps us because we will track more of those packages that were simply skipped. I think it's better to not skip them and have them fail than ignore them. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: Fedora 40 mass rebuild has begun
On Sun, Jan 21, 2024 at 06:13:21PM +, Sérgio Basto wrote: > On Fri, 2024-01-19 at 15:50 +0530, Samyak Jain wrote: > > Hi all, > > > > Per the Fedora Linux f40 schedule [1] we started a mass rebuild on > > 2024-01-17 for Fedora f40 but due to various reasons such as dnf > > issues, and other side-tags not getting merged we had to stop it. > > But we finally managed to overcome those, and we fired the mass > > rebuild today > > We are running this mass rebuild for the changes listed in: > > > > https://pagure.io/releng/issues?status=Open&tags=mass+rebuild&tags=f40&tags=changes > > > > This mass rebuild is done in a side tag (f40-rebuild) and merged > > when completed. > > > > Failures can be seen > > https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html > > <https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html> > > > > We should fix builds to rawhide , right ? or should we build in tag > f40-rebuild ? You can just fix in rawhide as normal. If you need to rebuild things that were built into f40-rebuild by the mass rebuild, thats fine too as when it's merged back, the newer builds will be seen in f40 and the older mass rebuild ones won't be merged. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FAS issue (was Re: Another mass rebuild blocker: glibc qsort regression)
On Tue, Jan 23, 2024 at 09:04:53AM -0600, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > The authentication issue being this one: > > > > https://pagure.io/fedora-infrastructure/issue/11733 > > I'd be interested in an after report on this one... as someone who has > managed FreeIPA, I'd like to know how this happened (so I can file away > how to NOT do the same thing in my own setups). It seemed to be a number of things at once sadly, as often such things are. We took a cluster member down and reinstalled rhel9 on it (to start upgrading the cluster), but then the replication agreements for all nodes were accidentally removed. That might have been easily recoverable, but then we also hit that in our case the cluster was installed a long time ago and didn't have SID's, which became manditory to fix a CVE in the most recent version. And then we also hit some old kruft leftover from when our cluster was in another datacenter long ago. ;( Many kudos to everyone who worked on this. Especially the IPA folks. They have been calm and understanding and really helped us track things down and get back working. > Certainly not bothering anybody while there's still an outage (or while > they're recovering from dealing with it), but when things like this > happen, it's good for everybody to document how it happened - NOT to > cast blame or anything like that (sooner or later, we all do something > that breaks in wildly unexpected ways), but so we can all learn from the > mistake. Absolutely. Things are not fully normal now, but everything should be up from the user perspective. We will be working to get the cluster back to a normal state in the next few days, then we can look at retrospective. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Kan-Ru Chen
On Sat, Jan 27, 2024 at 03:39:06PM +0900, Kan-Ru Chen wrote: > Hello Fedora, > > I have been lurking around the mailing lists, forum, and chats. It's > time for a self introduction! My first distribution was CLE 0.9 which > was based on Red Hat 6.1. Later I have switched between many > distributions then settled on Debian and became a DD. I was interested > by Fedora again when packaging a Flatpak application and came to know > the Silverblue variant. > > I'm now using Silverblue as my daily driver and CoreOS for some of my > hosting needs. I'm looking forward to contribute to Fedora especially > in the i18n area and beta testing. Welcome! You may be interested in the #i18n:fedoraproject.org and #quality:fedoraproject.org matrix channels if you haven't already seen them. :) kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: A reminder: you cannot just "revert" package version bumps
On Tue, Jan 30, 2024 at 01:19:18AM +0100, Kevin Kofler via devel wrote: > Sérgio Basto wrote: > > yes rawhide user should use dnf distro-sync not dnf upgrade > > +1. Rawhide EVRs should be allowed to go backwards, that is an integral part > of being a development branch. distro-sync is nice and all, but it's not a silver bullet. In cases of simple packages a downgrade may not break anything, but in cases where other things already built upon it, where the new one changed conguration or interface, or even where the upgrade changed data, it can leave things in a pretty unfortunate state. rawhide is a place for people to integrate their upsteam work with the other working collection of packages. Of course packages upgrade all the time and you have to adjust and fix your package to continue to work with them. But if packages could also just downgrade all the time it would make things much more a 'shifting sands'. We did recently change this so that releng could untag packages that went out already if it was judged to be a serious enough matter. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: A reminder: you cannot just "revert" package version bumps
On Tue, Jan 30, 2024 at 08:08:54AM +, Daniel P. Berrangé wrote: > On Mon, Jan 29, 2024 at 03:43:39PM -0800, Adam Williamson wrote: > > nirik ran a script that checks for versioning issues in Rawhide today, and > > it found several: https://pagure.io/releng/issue/11922#comment-893797 > > > > Some of these followed a pattern, so I figured a reminder was in order. In > > all these cases, a new version was pushed to Rawhide, then "reverted" some > > time later: > > > > golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2 in > > September > > golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0 in > > October; no 1.58.0 build ever landed, but the revert left the %release much > > lower than before > > python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on > > September 12 > > python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4 later > > the same day > > > > so the reminder is this: you cannot simply "downgrade" RPM package versions > > like this. Especially not if the upgraded version ever made it into a > > Rawhide compose. > > This is the kind of rule that is a prime target for automation. Can we > have Fedora Rawhide gating validate that the NEVR doesn't go backwards, > and block bad builds from getting into the compose. Yeah, seems like it could be a ci test... of course there may be times when it needs to be waived, but we could do that then with full understanding. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
I've very sorry if anyone was upset by fesco wanting to not allow the new packages in while this was discussed. I'm the one who suggested that, but as noted upthread, the idea was simply to allow time for discussion before doing things. There's actually a slightly similar case from long long ago to this one: Fedora only allows one kernel package. ( https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_only_one_kernel_package ) The discussion at the time from what I recall was that if anyone could add custom kernels, it would vastly increase the support burden on the main fedora kernel maintainers. People would report bugs to 'kernel' and ask them about it even if the package was named differently. If Adam's summary is understood by all the involved parties, then I don't think there would be a problem allowing the packages in. Everyone involved should just try and not place undue burdens on others. If there's a flood of reports or issues that take away from real requests to the kde sig, then perhaps things should be re-evaluated. On Tue, Jan 30, 2024 at 06:09:39PM +, Gary Buhrmaster wrote: > > I would suggest that it is entirely reasonable > that there be a threshold where if users > continually report bugs that the KDE SIG > must deal with (i.e. someone else's packages > are causing excessive overhead for the SIG, > even just to close/retarget the bugs/issues) > that they can petition that the offending > packages get suspended/removed. I don't > know what that threshold will be, but I > suspect the SIG will know it when they see > it. I would suggest that the packager of > those other packages monitors all new > bugs/issues and "takes" them early and > often to insure that the SIG is not unduly > burdened, and the threshold petition would > never need to be considered. Yeah, I agree. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unretire request idle and Go packages working through approval
On Tue, Jan 30, 2024 at 01:51:50PM -0600, W. Michael Petullo wrote: > I would like to unretire golang-github-apex-logs, and Mikel Olasagasti > Uranga was kind enough to review and approve my review request [1]. > The unretire request has been idle for a while: > > https://pagure.io/releng/issue/11880 Yeah, appologies... things have been very busy of late. I went and processed that now. However, a few things to mention: IMHO, it's helpfull if you don't open an unretirement request releng ticket until the package has been re-reviewed (if needed). Trying to keep track of old tickets waiting for reviews to finish is not a good workflow. It also results in people filing a ticket, told to do the re-review, then when that finishes a long time later, a new ticket is filed instead of updating the old one. ;( We are also working on automating unretirements... hopefully that will land soon and you will not need to wait on a manual process anymore. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages in repo not signed: fedora-cisco-openh264 repository
On Thu, Aug 25, 2022 at 08:43:38PM -0500, Martin Jackson wrote: > On Thu, 2022-08-25 at 16:28 -0700, Kevin Fenzi wrote: > > Everything should be back to working. Try a 'dnf --refresh...' or a > > 'dnf clean all'. > > > Having just > downloaded > https://codecs.fedoraproject.org/openh264/36/x86_64/os/Packages/m/mozilla-openh264-2.3.0-1.fc36.x86_64.rpm Yes, that unsigned package it still there, but the repodata no longer has anything about it, so dnf won't try and download it. New, fixed versions have been sent... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Users with commit rights in src.fp.o but no more in packager group
On Sat, Aug 27, 2022 at 07:12:46AM +, Mattia Verga via devel wrote: > Il 26/08/22 19:00, Kevin Fenzi ha scritto: > > On Wed, Aug 24, 2022 at 05:30:35PM +, Mattia Verga via devel wrote: > >> ... > >> > >> With the exclusion of *-team, *-sig and *-maint, I think packaging > >> rights should be removed from those users. > > I think these are users who manually removed themselves from the > > packager group, but didn't remove all their acls first. (and legit > > groups/sigs). > Is it possible for users to remove themselves from the packager group? > I've looked into fedora accounts interface, but I didn't found how. Login to accounts.fedoraproject.org, go to https://accounts.fedoraproject.org/group/packager/ and then scroll way down past all the sponsors and there should be a 'leave group' button on the right side at the start of the users in the group list. > >> Also, as per my comment linked above, I think there should be some check > >> to prevent users removed from packager group to maintain commit rights. > >> No idea where/how to implement that. > > I don't think it happens too often. We could make a script that checks > > it from time to time tho. Might be a good cadidate for a toddler ( > > https://pagure.io/toddlers) > I'll try to write one. I suppose we just want to be notified of a list > of users, rather than automatically remove users permissions? yeah. At least initially... > > > > In the mean time I agree we should remove the non team/sig/maint users > > above. > > > Should I file a ticket to releng? Or to fedora-infra? Infra I guess... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Tue, Aug 25, 2020 at 11:19:57AM +0200, Miro Hrončok wrote: > On 25. 08. 20 10:51, Fabio Valentini wrote: > > On Tue, Aug 25, 2020, 10:45 Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > On 25. 08. 20 5:52, Michel Alexandre Salim wrote: > > > I'll properly retire lua-logging and luadoc, but keep lua-sql. > > > > Let's merge the retirement commits to f33 as well? > > > > > > Doesn't "fedpkg retire" do more than just push something to git, e.g. > > publish retirement information to PDC or something? So IIUC just merging > > the retirement commit to f33 won't be enough since it won't block the > > package in koji. > > It used to (with pkgdb) now it doesn't. It emits a commit message with 'dead.package' in it. This is listened for by https://pagure.io/fedora-infra/toddlers/blob/master/f/toddlers/plugins/pdc_retired_packages.py which marks the package eol in pdc. Then, the next rawhide or branched compose runs https://pagure.io/releng/blob/master/f/scripts/block_retired.py which looks in pdc and for every package that is eol in pdc it blocks it in koji. > This is how I retire orphaned packages between branching and beta freeze: > > fedpkg clone $pkg && \ > cd $pkg && \ > fedpkg switch-branch f33 && \ > fedpkg retire "Orphaned for 6+ weeks" && \ > fedpkg switch-branch master && \ > git merge f33 && \ > git push > > (There used to be a rule to retire older branches first, but I suppose that > is no longer required and the command might be simplified.) > > It works fine (except for a slight period when retirements on f33 were > broken, but that was a server side issue, not the command). Either way should work, it's looking for the commit, merge or not. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HOWTO] Keep using Rawhide after branching
On Tue, Aug 25, 2020 at 04:49:05PM +0200, Petr Menšík wrote: > Hi Daniel, > > I am not using any base in fact. I am using container by systemd-nspawn. > I have installed it long ago by command from man systemd-nspawn, Example > 2. at the bottom. > > Since then I am trying rolling updates to keep it Raw(hide). It fails > every release once branched, because signatures cannot be verified. > > I just do dnf upgrade from time to time, when I check something there. > > My main issue is I am too stubborn to turn off gpg verification. > Instead, I want verification working. > > It seems branching was almost correct this time. But fedora-repos-33-0.9 > does not contain arch symlinks. And rawhide contains packages already > signed by the new key. Either install first gpg keys from koji, or > disable gpg when upgrading fedora-gpg-keys. Right, aside from that bug/issue it should have worked to just update fedora-gpg-keys and fedora-repos. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the real value of Release and %changelog metadata?
On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote: > On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller > wrote: > > > > On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote: > > > That makes it extra steps to see changelogs on a not-installed package. > > > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo" > > > (for example, to see what is changed since my installed version). > > > Converting to an installed file means I would have to extract the RPM > > > (possibly after manually downloading) and find it under a different > > > directory for every RPM - much less convenient. > > > > A dnf plugin could be made which shows metadata like this from > > src.fedoraproject.org or bodhi or some other source. > > > > That's not helpful beyond Fedora, though. When it's forked into RHEL > or CentOS, that changelog history from Fedora is preserved today. RHEL > forks Fedora at the git level, so generated changelogs from Git will > still work, and since CentOS gets SRPM imports into its Dist-Git, > they'll be flattened into %changelog sections as appropriate. But if > we rely on a web service to get changelogs, we screw over that > particular transition path. Sure, but how often is that changelog: "Updated to 10.0.1" or "Fixed typo" I pretty much stopped reading changelogs a while back. Looking at the upstream NEWS or announcement is better for releases, and just looking at the git commits is better for isolating some change in packaging. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote: > Do you think it would be a good idea to file bugs for those packages > where a build for f33 was "forgotten"? > Since I already have the "downgrade check" scripted [0] it's a simple task of: > > - check if the package has attempted build for f33 > - if yes, check if it's FTBFS, and don't report a bug > - if no build was attempted for f33, report a bug > > I see ~100 downgraded *binary* packages going from fully updated f32 > to fully updated f33. > The number of affected *source* packages is naturally lower than that. > The script also doesn't account for packages being renamed (but in > those cases, proper Obsoletes and Provides need to be present during > package review, so I don't think this is a problem). Yes, I think that would be lovely. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New version of net-snmp + soname bump
On Wed, Aug 26, 2020 at 07:55:23AM -0400, Josef Ridky wrote: > Never done that before, but it sounds like the right way. > > I've tried to follow this description [1], but I am not able to proceed it > due of lack of privileges. > Do I have to be proven packager to be able to create and use side tags? Do > you have any ideas, where/how to start with this? > > [1] https://docs.pagure.org/releng/sop_adding_side_build_targets.html Wrong doc, thats for release engineers. :) You want: https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ kevin -- > > Regards > > Josef Ridky > Software Engineer > Core Services Team > Red Hat Czech, s.r.o. > > - Original Message - > | From: "Fabio Valentini" > | To: "Development discussions related to Fedora" > > | Sent: Wednesday, August 26, 2020 11:26:15 AM > | Subject: Re: New version of net-snmp + soname bump > | > | On Wed, Aug 26, 2020 at 11:15 AM Josef Ridky wrote: > | > > | > Hi folks, > | > > | > upstream authors has released new major version of net-snmp that is now > | > heading to Rawhide and F33. > | > As part of this update, soname will change from .35 to .40. > | > > | > I would like to ask all maintainers, that rely on some part from net-snmp > | > to rebuild their packages with new version of net-snmp once available. > | > > | > For rawhide, update should be available later today. For F33 override will > | > be provided with availability till September 4th, 2020. > | > | As mentioned by Rathann in his reply, please organize builds and > | rebuilds in side tags. That's what they're for. > | *Especially* if you want to submit an SONAME bump to fedora 33 even > | after the beta freeze ... > | At least that way all affected packages should get pushed at the same > | time without introducing broken dependencies. > | > | Fabio > | ___ > | devel mailing list -- devel@lists.fedoraproject.org > | To unsubscribe send an email to devel-le...@lists.fedoraproject.org > | Fedora Code of Conduct: > | https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > | List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > | List Archives: > | https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > | > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package downgrades from f32 -> f33 (categorized list inside)
On Wed, Aug 26, 2020 at 05:45:24PM +0200, Petr Šplíchal wrote:
> Hi!
>
> > # Packages not included in mass rebuild?
> >
> > - tmt is newer in 32 than in 33:
> > 0:0.20-1.fc32 > 0:0.19-1.fc33
>
> Recently I was unable to build a fresh tmt package for rawhide
> because of a missing build dependency:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48098490
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50191342
>
> Problem: conflicting requests
> - nothing provides libguestfs-tools-c needed by
> python3-testcloud-0.3.5-3.fc33.noarch
>
> Seems the problem happens only for some build host architectures
> (although tmt is noarch). Today I was able to build the package
> successfully (on another build host). Any recommendation on how
> to prevent these random failures? Thanks.
This is because we no longer build a i686 kernel, and libguestfs needs a
kernel. So, it will not be available on i686.
You should be able to:
ExclusiveArch: %{kernel_arches} noarch
and I think koji will now do the right thing.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird
On Wed, Aug 26, 2020 at 11:45:48AM +0200, Fabio Valentini wrote: > On Tue, Aug 25, 2020 at 9:33 PM kevin wrote: > > > > On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote: > > > Do you think it would be a good idea to file bugs for those packages > > > where a build for f33 was "forgotten"? > > > Since I already have the "downgrade check" scripted [0] it's a simple > > > task of: > > > > > > - check if the package has attempted build for f33 > > > - if yes, check if it's FTBFS, and don't report a bug > > > - if no build was attempted for f33, report a bug > > > > > > I see ~100 downgraded *binary* packages going from fully updated f32 > > > to fully updated f33. > > > The number of affected *source* packages is naturally lower than that. > > > The script also doesn't account for packages being renamed (but in > > > those cases, proper Obsoletes and Provides need to be present during > > > package review, so I don't think this is a problem). > > > > Yes, I think that would be lovely. > > > > kevin > > I'm on it. > > By the way, I'm finding some weird issues where packages are tagged > with f33 in koji for a few days but an *older* build is in the repos, > e.g. appliance-tools and ddgr. I am not seeing that here. Could be a mirror issue? I ran out check_latest_build script on f33 (which looks at each package and tries to figure out if the last tagged one is the 'highest'). It gives: containernetworking-plugins-0.8.6-1.fc33 < containernetworking-plugins-0.8.6-11.1.gitbd58999.fc33 crun-0.14.1-1.fc33 < crun-0.14.1-2.fc33 fabtests-1.11.0-1.fc33 < fabtests-1.11.0rc2-1.fc33 igt-gpu-tools-1.25-1.20200818git4e5f76b.fc33 < igt-gpu-tools-1.25-2.20200719git9b964d7.fc33 libfabric-1.11.0-1.fc33 < libfabric-1.11.0rc2-1.fc33 slirp4netns-1.1.4-1.fc33 < slirp4netns-1.1.4-4.dev.giteecccdb.fc33 stdair-1.00.10-5.fc33 < stdair-1.00.10-6.fc33 sympa-6.2.56-2.fc33 < sympa-6.2.56-2.fc33.1 kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird
On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote: > > Hrm. It looks like at least some of those issues were transient, yes. > However, two issues are still left: > > - libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.0.0-3.fc32 > is in the f33 repos f34 should have been fine... f33 the newer one was only tagged in this morning: Wed Aug 26 03:25:54 2020 libdkimpp-2.0.0-6.fc33 tagged into f33 by humaton [still active] So it should be in today's f33 compose, but indeed I don't see it there. Odd. oh. Man. I sure hate timezones. ;) It was tagged after the f33 compose started. > - swift-lang-5.2.5-1.fc33 is tagged with f33 and f34 but 5.2.4-3.fc33 > is in the f33 repos Same here. Tagged in this morning, should be fixed tomorrow. > > Both these packages were built ~two weeks ago, so maybe they were > screwed up by the mass branching somehow? Yeah, possibly so. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HOWTO] Keep using Rawhide after branching
On Fri, Aug 28, 2020 at 06:51:24PM +0200, Vít Ondruch wrote: > > Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a): > > No, unfortunately the key is there, but the package is incomplete. > > > > If you have enabled gpg signatures verification, it would fail. At least > > it does to me. > > > > Check it with: > > > > rpm -ql fedora-gpg-keys | grep fedora-34-$(arch) > > > > It just does not provide correct key. > > > Actually, yesterday I did update of another system with my approach and > you are right that the fedora-gpg-keys-33-0.9 did not contained the > proper links to the key. However, the fedora-gpg-keys-33-0.10 works just > fine (not really sure what caused the difference). I did precisely: the 0.9 one was broken. Incorrect. Had a bug. Mistaken. Not right. Not represenative of how the process is supposed to work. The 0.10 one was fixed and should behave as you note, and work to upgrade to rawhide without disabling any gpg key. Sorry this time it wasn't correct. Mistakes happen. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390x builder issues
Greetings. As many of you know, the s390x builders have been very slow or failing builds with intermittent i/o issues for a while now. I've done what I can to mitigate this on the builder level, but the problem is at a deeper level. I've been asked to try and collect issues that package maintainers are hitting on these builders and provide them to mainframe admins so they can understand the impact on us and prioritize more resources or other corrective measures. To that end, if you are a maintainer and: * A build on s390x being slow affects you (needed for another build, important bug fix, etc) in a serious way or * a build on a s390x builder fails in some odd way that is NOT related to your package (unable to download src.rpm, checksum mismatches, etc). I'd love for you to note: * the link to the failed/slow task * The time (UTC preferred) * which exact builder it was * what the issue was * how it impacted your fedora work into: https://pagure.io/fedora-infrastructure/issue/9232 Please don't post to the list, mail me privately, etc. Just add the info to the above issue. Thanks for your help kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mdapi.fedoraproject.org data not up to date?
On Mon, Aug 31, 2020 at 09:34:48PM +0200, Pierre-Yves Chibon wrote: > On Mon, Aug 31, 2020 at 05:43:14PM +0200, Robert-André Mauchin wrote: > > Hello, > > > > I am trying to retrieve versioning information for some packages through > > mdapi.fedoraproject.org. But several "recent" (some two/three months ago) > > packages are returning a 404 error as if they don't exist. > > > > For ex, this one created 3 days ago: > > > > https://mdapi.fedoraproject.org/koji/srcpkg/golang-github-golangci-lint-1 > > https://src.fedoraproject.org/rpms/golang%2Dgithub%2Dgolangci%2Dlint%2D1 > > > > Or this one created 2 months ago: > > > > https://mdapi.fedoraproject.org/koji/srcpkg/golang-github-gobwas-pool > > https://src.fedoraproject.org/rpms/golang%2Dgithub%2Dgobwas%2Dpool > > > > How often is updated mdapi.fedoraproject.org? Or is this an error? > > Checking > https://apps.fedoraproject.org/datagrepper/raw?category=mdapi&rows_per_page=5 > we > can see that it started running again at around 16:20 UTC today and its first > notification was: > mdapi.repo.update mdapi noticed a koji repomd change: , 0ad, and 71041 others > JSON > > In the mean while I saw nirik's comment on IRC: > > it was broken. I think I fixed it > > So it looks like his fix fixed it :) > > Thanks @Kevin! Yeah, oddly, the cronjob was defined in openshift, but it was not running. Not failing, just not trying to run at all. ;( So, I deleted it and redeployed it from ansible and it started running. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 blocker status
On Mon, Aug 31, 2020 at 02:35:29PM -0700, Adam Williamson wrote: > On Mon, 2020-08-31 at 15:53 -0400, Ben Cotton wrote: > > > > Accepted blockers > > - > > 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST > > abrt-server errors when processing zstd compressed core dumps produced > > by systemd-246~rc1-1.fc33 > > > > FEDORA-2020-59e144acee contains a potential fix, but introduces a new > > blocker (BZ 1873029). It may be moot until the retrace server is > > brought back online. > > I'll just note the same team is responsible for this whole complex - > the retrace and FAF servers, and the abrt/libreport tool cluster - so > ultimately the ask here of that team is: get the whole kaboodle working > so we can actually report crashes in F33. Just to make sure folks know, the retrace server being down is not this teams fault, it's ours (infrastructure). We planned to just have it down for a week or less when moving it to RDU, but it turned out that datacenter move was not at all what we hoped for and it's been down much longer than intended. That said, we have a machine up now there and it's just needing configuration/setup to get the service back up and running. :) So, hopefully soon it will again be online. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Weird Koji build failure
On Tue, Aug 31, 2021 at 10:25:37AM -0500, Justin Forbes wrote: > > No, this was added to one build at the request of releng because > composes are randomly failing in kernel-core %post. As we just call > kernel-install, we first tried calling kernel-install -v, but that > doesn't give much useful information because it doesn't seem to add > any verbosity to the subtasks it runs. The 5.14.0-61 build was done > last night to try and gather some more information for them, and the > strace call is expected to disappear with the next build. In fact, > once they have run the composes and gotten the information needed, 61 > can be untagged, and 60 will be the same kernel without the debugging > calls to kernel-install. It should only impact the very few packages > which have kernel-core as a buildreq. Yeah, sorry to have confused anyone here. We were trying to track down this anoying sporadic failure in kernel-core trigger/new-kernel-pkg. Unfortunately, it caused this OOM issue on ppc64le, so it didn't in the end help us much. I have untagged that kernel and killed the stuck rawhide compose. I'm going to see if I can get it to happen with scratch livemedia against a sidetag with that kernel tagged in now. :( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package Maintainer Docs published
On Tue, Aug 31, 2021 at 07:27:50AM +, Mattia Verga via devel wrote: > Il 31/08/21 07:39, Otto Urpelainen ha scritto: > > Greetings, > > > > Some months ago, I announced [0] that I will move the package maintainer > > docs from wiki to docs.fedoraproject.org. I am happy to announce that > > this task is complete and the docs are public in their new location now > > [1]. Hopefully, this will allow existing and new packagers to find > > relevant documentation more easily, and foster more concentrated efforts > > to make it better. > > > Thanks for this work! > > Just a question from a quick reading of the Joining the Package > Maintainers section: now that Bugzilla is integrated with the Fedora > Account System (we can login with that) is it still mandatory to create > a BZ account? Or should we make new users to login in BZ with FAS > (noggin) to have the account created in BZ? How does that work? It would create it. However, I think we should wait on this a bit longer. The new account system has a bugzilla account field in it. We are close to ready to make that work as you expect (ie, if you put an account name in there it will use that as your bugzilla login/account), but it needs some more work with bugzilla admins before it's live. Right now, you just get your primary email address. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Sources file audit - 2010-01-06
On Sun, 10 Jan 2010 18:21:15 + Christopher Brown wrote: > 2010/1/10 Kevin Fenzi : > > Here's another (more accurate/correct) run of the sources file > > checker. Thats against a 2010-01-06 cvs checkout seed. > > > snecker:BADURL:jokosher-20091128bzr.tar.gz:jokosher > > snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim > > These are both checkouts from vcs. How should this be dealt with? https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Sun, 10 Jan 2010 18:42:41 +
Christopher Brown wrote:
> Which I have done for jokosher unless this means I have to drop the
> bzr suffix?
You have:
Source0: http://www.%{name}.org/downloads/source/%{name}-20091128bzr.tar.gz
That URL is 404. There is no file with that URI.
You should have (IMHO):
# The source for this package was pulled from upstream's vcs. Use the
# following commands to generate the tarball:
#
# tar -czvf foo-20091129bzr.tar.gz foo-20001128
Source0: %{name}-20091228bzr.tar.gz
You should not make up a URL to a nonexistent file.
Just explain in a comment how exactly someone would duplicate your
source file using bzr and tar, and drop the http:// part of the Source.
Does that make sense?
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Sun, 10 Jan 2010 21:11:29 +0200 Jussi Lehtola wrote: > On Sun, 2010-01-10 at 00:06 -0700, Kevin Fenzi wrote: > > jussilehtola:BADSOURCE:agedu-r8768.tar.gz:agedu > > The upstream agedu tarball is generated nightly, so the md5sum changes > the whole time. Should I take out the URL from the source line? Yeah, I would think so. You could leave it in a comment with a note that it changes each time it's fetched/daily. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FWD: orphaning curlftpfs , mod_auth_shadow
I'm forwarding this for David Anderson: From: David Anderson To: fedora-devel-l...@redhat.com Subject: Orphaning curlftpfs , mod_auth_shadow Date: Mon, 11 Jan 2010 11:22:25 + User-Agent: KMail/1.12.4 (Linux/2.6.31.6-166.fc12.x86_64; KDE/4.3.4; x86_64; ;) Greetings, Due to a slow African Internet connection and ever-growing responsibilities, I regret that I have to and am orphanning these two packages: curlftpfs - mount FTP filesystems via FUSE and curl mod_auth_shadow - Apache authentication via /etc/shadow There are a couple of open bugs for curlftpfs which I said I'd fix by upgrading to the latest version, but it's so long since I used the system and I'm battling with the accounts system, expired certificates. Both these packages I originally packaged because I wanted to use them. I'd have thought that they'd both have many users. Many thanks, David signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (20100108) FESCo meeting
On Mon, 11 Jan 2010 12:44:46 + Adam Williamson wrote: > On Thu, 2010-01-07 at 15:53 -0700, Kevin Fenzi wrote: > > > If you would like to add something to this agenda, you can reply to > > this e-mail, file a new ticket at https://fedorahosted.org/fesco, > > e-mail me directly, or bring it up at the end of the meeting, during > > the open floor. > > I filed a ticket for a rather important issue - the privilege > escalation policy issue - some time back: > > https://fedorahosted.org/fesco/ticket/297 > > that's three weeks ago. No-one seems to have picked this up for action > in any way at all. The agenda for this last meeting seems to include > tickets from both before and after this one. Has it been overlooked? > Thanks. Not really overlooked so much as: - This was filed after the last FESCo meeting last year. There were no meetings for xmas/new years holidays. - The new FESCo just met for the first time friday. Likely many of the new members haven't seen this ticket yet as it was not marked 'meeting' and they were not cc'ed on it before they were elected. I'm going to update the ticket, add the meeting keyword so we talk about it at the next meeting and see if we can move it forward. Thanks for the reminder. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Mon, 11 Jan 2010 17:29:40 -0500 Peter Jones wrote: > On 01/10/2010 02:06 AM, Kevin Fenzi wrote: > > pjones:BADURL:dumpet-2.0.tar.bz2:dumpet > > Should be fixed now (forgot to push the tarball to hosted) ok. > > pjones:BADURL:syslinux-3.83.tar.bz2:syslinux > > Not really seeing what's wrong with this one, but I've just updated > it to 3.84, so let's see if it stays broken ;) Looks fine here now. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Mon, 11 Jan 2010 22:43:32 + Mat Booth wrote: > This is a bit suspicious: > > 2010/1/10 Kevin Fenzi : > > > > orphan:BADURL:xerces-c-src_2_8_0.tar.gz:xqilla > > orphan:BADURL:xerces-c-src_2_8_0.tar.gz:xqilla10 > > > > Why is it necessary for xquilla to distribute the source for xerces-c? > Why is a simple dependency on xerces-c-devel not sufficient? :-/ Looks like from: https://bugzilla.redhat.com/show_bug.cgi?id=376541 "xqilla101 source rpm also includes sources of xerces-c -- XQilla build process relies on few xerces-c include files that are not present in standard xerces-c-devel package." but someone should finish the end of life process for these packages if it's not picked up by someone. https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life So they are no longer shipped. Looks like more than a year since the former maintainer touched the packages. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
Charley Wang wrote: > A rebuild was conducted, and a preliminary (unsorted) list of packages > that have implicit linkage errors can be found here: > > https://fedoraproject.org/wiki/DSOLinkBugs I still think that a backwards-incompatible change to something as central as linking semantics (the implicit linking is more or less part of ELF semantics) hitting so many packages is a very bad idea and that it's unrealistic to get them all fixed for F13. I also think that this change will probably force us to ship .la files. The only reason we didn't need them so far was that implicit linking feature. Sadly, my concerns got ignored at the FESCo meeting where this "feature" was discussed:-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
Charley Wang wrote: > Please note that many of the packages may be failing because of a few > DSO's. Further exploration is needed to evaluate this possibility so > we can apply one patch to the source of the problem instead of dozens of > superfluous patches. We also need (and would appreciate help with) the > linking of failed build logs to their package owners. And how would you fix that in the DSO other than by adding a .la file (which is against our packaging guidelines) or a linker script (which basically amounts to the same) to force the extra -l flag? Linking the DSO to the one providing the symbols is not enough due to the very change which is causing the problems. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/seabios/F-12 seabios-0.5.1-669c991.tar.gz, NONE, 1.1 seabios.spec, NONE, 1.1
On Tue, 12 Jan 2010 06:50:16 + (UTC) "Justin M. Forbes" wrote: > Author: jforbes > > Update of /cvs/pkgs/rpms/seabios/F-12 > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15649 > > Added Files: > seabios-0.5.1-669c991.tar.gz seabios.spec > Log Message: > Created initial package > > > --- NEW FILE seabios-0.5.1-669c991.tar.gz --- > ÙÿmÈQ¯Kío~ > æQ2£lݸÏõÿ/½¢ÿÉèxôõq ½ôz·þ÷¬þ`oô¿×Û³¾!½¯OJýú®ÿÓ9¹ 'Äc$¡É*ì4y Please don't check tar.gz files into CVS. :) you will need to: cvs rm -f seabios-0.5.1-669c991.tar.gz cvs commit make new-sources FILES="seabios-0.5.1-669c991.tar.gz" bump release/add changelog to spec cvs commit sources .cvsignore seabios.spec See: https://fedoraproject.org/wiki/Package_update_HOWTO https://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers https://fedoraproject.org/wiki/Package_update_guidelines https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import_Your_Package signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Wed, 13 Jan 2010 12:01:54 +0100 Laurent Rineau wrote: > Le dimanche 10 janvier 2010 08:06:11, Kevin Fenzi a écrit : > > rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe > > rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe > > Does the change of URLs of Source0 worths a rebuild in Rawhide, or is > the cvs commit sufficient? I would say only if the change in the Source0 resulted in using a different source file, ie, if the md5sum changes of the thing you are building. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's (2010-01-15) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. Followups: #298 Revoke Paul Johnsons pacakger access and put him on probation. #291 Man pages Packaging Guideline New business: Finalize new meeting day/time. #301 Sponsor Request: "David A. Wheeler" #302 libssh2 - non-responsive maintainer #297 Please consider the idea of a security (privilege escalation) policy #303 Feature: KDE PolicyKitOneQt ( https://fedoraproject.org/wiki/Features/KDE_PolicyKitOneQt ) #304 Feature: KDE44 ( https://fedoraproject.org/wiki/Features/KDE44 ) #305 Feature: Sugar 0.88 ( https://fedoraproject.org/wiki/Features/Sugar_0.88 ) #306 Feature: Xfce48 ( https://fedoraproject.org/wiki/Features/Xfce48 ) Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. NOTE: The meeting time and day will likely be moving starting next week. Kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: fedora-release-rawhide subpackage
On Thu, 14 Jan 2010 23:26:39 + (UTC) Zing wrote: > On Fri, 08 Jan 2010 09:37:20 -0700, Kevin Fenzi wrote: > > > Because it won't be on the live media that many of the install > > from, or the default groups that would be choosen from the dvd > > install. > > Just FYI, since it seems this is happening anyway, I didn't think > rawhide was available from an anaconda installation and it isn't (I > checked the F12 dvd today). NOTE: Now the live cd... that I don't > know. It's not. However it's present but disabled once you install with any method currently. All it takes now to enable it is to go in and edit /etc/yum.repos.d/fedora-rawhide.repo and change 'enabled=0' to 'enabled=1'. In PackageKit, it should show some text when you enable it, but either the wording is not strong enough, or people are just clicking through that warning to enable it anyhow. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for (2010-01-15) FESCo meeting
Here's the logs from todays meeting. Sorry for the delay in posting it. ;( NOTE that we will be meeting on tuedays at 20:00 UTC moving forward. http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/fesco.2010-01-15-17.00.html http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/fesco.2010-01-15-17.00.log.html http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/fesco.2010-01-15-17.00.log.txt http://meetbot.fedoraproject.org/fedora-meeting/2010-01-15/fesco.2010-01-15-17.00.txt Meeting summary init process (nirik, 17:00:37) Followups on old business (nirik, 17:02:47) Finalize new meeting day/time. (nirik, 17:04:38) http://whenisgood.net/fesco-meeting/results/8kgg3e (nirik, 17:05:20) AGREED: New FESCo meeting time is 20:00 UTC on tuesdays. (nirik, 17:14:53) #301 Sponsor Request: "David A. Wheeler" (nirik, 17:15:25) AGREED: David will do some more reviews and reapply. (nirik, 17:27:03) #302 libssh2 - non-responsive maintainer (nirik, 17:28:04) https://admin.fedoraproject.org/pkgdb/users/packages/cweyl lists 318 packages (cwickert, 17:31:51) AGREED: nirik will try and contact cweyl and get information flowing, failing that will invite him to the next meeting to try and fix things up. (nirik, 17:42:32) #297 Please consider the idea of a security (privilege escalation) policy (nirik, 17:45:21) #303 Feature: KDE PolicyKitOneQt ( https://fedoraproject.org/wiki/Features/KDE_PolicyKitOneQt ) (nirik, 18:06:15) AGREED: Feature is approved. (nirik, 18:08:09) #304 Feature: KDE44 ( https://fedoraproject.org/wiki/Features/KDE44 ) (nirik, 18:08:15) http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule (Kevin_Kofler, 18:12:03) AGREED: Feature has been approved. (nirik, 18:16:13) #305 Feature: Sugar 0.88 ( https://fedoraproject.org/wiki/Features/Sugar_0.88 ) (nirik, 18:16:26) AGREED: This Feature is approved (nirik, 18:19:41) #306 Feature: Xfce48 ( https://fedoraproject.org/wiki/Features/Xfce48 ) (nirik, 18:19:46) https://fedoraproject.org/wiki/Features/Xfce48#Detailed_Description (cwickert, 18:23:30) AGREED: Feature is approved. (nirik, 18:26:32) Open Floor (nirik, 18:26:43) AGREED: packages that have FTBFS for years will be orphaned and removed in the normal orphan removal process. (nirik, 18:50:02) Meeting ended at 18:58:34 UTC (full logs). signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, 15 Jan 2010 22:58:54 +0100 Till Maas wrote: > But what about the other packages by these maintainers that do not > fail to build but are probably as unmaintained as the packages that > fail to build? There may be some cases of that. If so, the non responsive maintainer procedure should be used on those maintainers. > > perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) > > perl-SVN-Simple iburrell > > There is a minor error: I fixed the -Simple package with a patch > submitted in the upstream bugtracker iirc 7 days ago. But I also > noticed that the -Mirror package was removed from debian. > > But what about the other packages from this maintainer? He maintains > around 36 other packages: > https://admin.fedoraproject.org/pkgdb/users/packages/iburrell > > E.g. the jigdo packages also has 4 bug. I looked at two an both did > not receive any comments from the maintainer: > https://bugzilla.redhat.com/show_bug.cgi?id=426847 > https://bugzilla.redhat.com/show_bug.cgi?id=503833 Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. > Therefore the non responsive maintainer procedure, i.e. orphaning all > packages from the affected maintainers, seems to me to be more > appropriate. In this particular case, yes. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas wrote: > > Indeed. I don't see much activity from them. > > Have you tried sending them an email? > > If not, I can. > > No, please go ahead. I took the liberty right after I posted. (Hopefully Ian doesn't mind me passing this along:) Ian Burrell wrote: > I am still around but haven't been busy recently and haven't done > anything with my packages. > > I'll take a look at this weekend. > > - Ian signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 11:08:30 +0100 Hans de Goede wrote: > I don't see who the orphaning without following proper procedure is > appropriate at all. Simply blocking the ones which FTBFS bugs were not > fixed from F-13 inclusion would have been the appropriate response > (as documented in our procedures), not > some adhoc almost random response. These packages have failed to build for over a year. Sure, we could allow them to continue if someone steps in to build them, but then who is answering bugzilla tickets on them? Who is following upstream and updating them, in short: who is maintaining them? Not the maintainer of record it seems. if you want them to go on, take ownership. Sorry for the bug that prevented people from doing this, it's been fixed. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 10:13:32 +0100 Michael Schwendt wrote: > It's a more fundamental problem, though. The AWOL-process is for > people, not for packages. The people may still be active (and even > known to be active somewhere) and not AWOL, but the packages which > are assigned to them would still look orphaned. FTBFS is just one way > to find packages that don't even build. > However, if that happens, it may be much too late. Such a package may > have been in an unmaintained desolate state for a long time already. > With nobody handling the incoming bugzilla tickets. With some bug > reports having been killed in an automated way at dist EOL. And worse > if it turns out that packages which do build are unmaintained > nevertheless, with the same symptoms in bugzilla and in package scm. > > Makes me wonder what bugzilla status report scripts we have? To > create a list of potentially unmaintained packages earlier and to > detect packages with non-responsive owners. Yeah, there was talk a while back about setting something up to try and detect poorly maintained/unmaintained packages, but I fear nothing ever came of it. I think it would be great to have some automated script that used a variety of input info to try and come up with a list of packages and/or maintainers who are not responsive. Unfortunately, this will be tricky to get right as there are a lot of corner cases: This could include: - Process bugzilla. Maintainers: How many bugs are assigned to each maintainer. How many of those have never had a comment by that maintainer. How many of those are over a month old How many of those are over a year old How many of those are over 5 years old. Packages: Packages with the most bugs (would need to weight somehow things like the kernel or X, and/or abrt bugs). Perhaps divide by co-maintainers? Packages that have upstream updates that haven't been acted on. -SCM Commits / Bodhi / Koji Packages: Packages that have had no SCM commits in a cycle. Packages that have had no updates in a cycle. Maintainers: Maintainers who have not commited to anything in a cycle Maintainers who have never submitted an update. Maintainers who have never built anything in koji. Maintainers who haven't built anything in a cycle. Maintainers who haven't built anything in a year. - Mail / FAS: Maintainers who have never posted to fedora* Maintainers who's fedora account system email bounces Maintainers who's fedora account system email is never responded to. Sponsors who have never sponsored anyone. Sponsors who have not sponsored anyone in a year. Sponsors who have not sponsored anyone in 5 years. - Planet: Maintainers who have a feed, but no posts. etc. You can see there is a lot of info out there, but much of it may not apply in reality. Ie, there is a package that doesn't update because it's quite stable. It has no bugs against it and the maintainer isn't doing anything else in Fedora. :) So, it might be nice to have such a tool and have it generate a list of possible maintainers/packages that need help. Then a human should look over the list and try and contact maintainers/gather info on packages and/or start unresponsive maintainer, etc. Any takers for writing such a script? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Any takers for gpsdrive ?
Greetings. I'd like to find some folks interested in co-maintaining or just fully maintaining gpsdrive. It's a nifty gps app that lets you download maps and follow progress and publish your location. This package requires a good bit of work, and I just haven't had the time to sit down and poke at it. It currently fails to build (again) in rawhide. Outstanding bugs: 555961 Fedora new FTBFS gpsdrive-2.10-0.4.pre7.fc13 551769 Fedora assigned[abrt] crash detected in gpsdrive-2.10-0.4.pre7.fc12 Any interested parties let me know and I can release ownership/approve your co-maintaining. Thanks! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's (2010-01-19) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 20:00UTC (3pm EST) in #fedora-meeting on irc.freenode.net. Followups: #298 Revoke Paul Johnsons pacakger access and put him on probation. #291 Man pages Packaging Guideline #302 libssh2 - non-responsive maintainer #297 Please consider the idea of a security (privilege escalation) policy New business: #308 package-swift #309 provenpackager request - tomspur #311 Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging ) #312 Feature: UdisksImprovements ( https://fedoraproject.org/wiki/Features/UdisksImprovements ) #313 Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial ) Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meeting Summary/Minutes for (2010-01-19) FESCo meeting
Here's the summary/minutes from todays meeting: Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-19/fesco.2010-01-19-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-19/fesco.2010-01-19-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-19/fesco.2010-01-19-20.00.log.html Meeting started by nirik at 20:00:35 UTC (full logs). Meeting summary init process (nirik, 20:00:35) FOLLOWUP: #298 Revoke Paul Johnsons pacakger access and put him on probation. (nirik, 20:02:44) #302 libssh2 - non-responsive maintainer (nirik, 20:18:55) #308 package-swift (nirik, 20:31:15) #309 provenpackager request - tomspur (nirik, 21:01:58) AGREED: tomspur is approved for provenpackager. (nirik, 21:06:29) #311 Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging ) (nirik, 21:06:50) AGREED: Feature is approved. (nirik, 21:14:49) #312 Feature: UdisksImprovements ( https://fedoraproject.org/wiki/Features/UdisksImprovements ) (nirik, 21:14:59) AGREED: This Feature is approved. (nirik, 21:17:26) #313 Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial ) (nirik, 21:17:30) AGREED: This Feature is approved. (nirik, 21:19:09) Open Floor (nirik, 21:19:23) Meeting ended at 21:23:14 UTC (full logs). signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Tue, 19 Jan 2010 13:18:33 +0100 Thomas Moschny wrote: > 2010/1/10 Kevin Fenzi : > > thm:BADSOURCE:httperf-0.9.0.tar.gz:httperf > > Project URLs changed. Fixed in CVS, not rebuilt. > > (But why was this BADSOURCE? Checked, and both tar files at old url > ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz and new url > http://httperf.googlecode.com/files/httperf-0.9.0.tar.gz have the same > md5 that is also in the sources file.) Looks like the hp server had some issues and gave up a broken version? --2010-01-07 14:50:53-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz => `./.listing' Resolving ftp.hpl.hp.com... 192.6.29.21 Connecting to ftp.hpl.hp.com|192.6.29.21|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/httperf ... done. ==> PASV ... done.==> LIST ... done. 0K . 70.5M=0s 2010-01-07 14:50:55 (70.5 MB/s) - `./.listing' saved [1264] Removed `./.listing'. --2010-01-07 14:50:55-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz => `./httperf-0.9.0.tar.gz' ==> CWD not required. ==> PASV ... done.==> RETR httperf-0.9.0.tar.gz ... done. Length: 425297 (415K) 0K .. .. .. .. .. 12% 73.2K 5s 50K .. 14% 17.0K=1.3s 2010-01-07 15:05:59 (47.1 KB/s) - Data connection: Connection timed out; Data transfer aborted. Retrying. --2010-01-07 15:06:00-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz (try: 2) => `./httperf-0.9.0.tar.gz' ==> CWD not required. ==> PASV ... Error in server response, closing control connection. Retrying. --2010-01-07 15:06:02-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.9.0.tar.gz (try: 3) => `./httperf-0.9.0.tar.gz' Connecting to ftp.hpl.hp.com|192.6.29.21|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/httperf ... done. ==> PASV ... done.==> REST 425297 ... done. ==> RETR httperf-0.9.0.tar.gz ... done. Length: 425297 (415K), 0 (0) remaining [ skipping 400K ] 400K ,, , 100% 0.00 =0s 2010-01-07 15:06:04 (0.00 B/s) - `./httperf-0.9.0.tar.gz' saved [425297] > > > thm:BADURL:guitone-0.9-1.tgz:guitone > > In this case, the upstream server uses a mismatching certificate, not > sure what to do here besides asking upstream to use another > certificate. yeah, not much to be done except that I fear. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas wrote: > On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote: > > On Sat, 16 Jan 2010 10:39:54 +0100 > > Till Maas wrote: > > > > > > Indeed. I don't see much activity from them. > > > > Have you tried sending them an email? > > > > If not, I can. > > > > > > No, please go ahead. > > > > I took the liberty right after I posted. > > Did also contact the recordmydesktop maintainer? I didn't then, but I did just now. (Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas wrote: > The list of packages you announced that are going to be orphaned and > the list of packages that were orphaned are not the same. > recordmydesktop was on the to-be-orphaned list but afaics was not > orphaned and also was not mentioned in your list about which > provenpackager fixed which package. Odd. Not sure why it wasn't there. I mailed the maintainer and can orphan it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting Summary/Minutes for (2010-01-19) FESCo meeting
On Thu, 21 Jan 2010 17:34:50 +0100 Till Maas wrote: > > On Tue, Jan 19, 2010 at 02:24:39PM -0700, Kevin Fenzi wrote: > > > init process (nirik, 20:00:35) > > FOLLOWUP: #298 Revoke Paul Johnsons pacakger access and put him on > > probation. (nirik, 20:02:44) #302 libssh2 - non-responsive > > maintainer (nirik, 20:18:55) #308 package-swift (nirik, 20:31:15) > > A simple line with a conclusion for each topic would improve the > usefulness of these summaries a log. E.g. #298 was delayed by another > week and I did not really get from the last lines of the other topics, > what was decided. Yeah, perhaps I could manually add that, or just try and make sure to specify some kind of 'agreed' every topic. Even if it's only 'defer to next week'. > Maybe the meetbot could be patched to only accept a topic change > after a #agreed command was used (or some other command except the > #action command, that creates a helpful notice in the logs). For the > init process, something like "x of y Fesco members present" and list > of absent members could be used. Possibly. Patches welcome. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's (2010-01-26) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 20:00UTC (3pm EST) in #fedora-meeting on irc.freenode.net. Followups: #308 package-swift New business: #314 Wordpress bundles libraries #315 Feature: boot.fedoraproject.org ( https://fedoraproject.org/wiki/Features/BFO ) #316 Feature - Bonobo Free Evolution ( https://fedoraproject.org/wiki/Features/BonoboFreeEvolution ) #317 Feature: Fedora 13 Boost 1.41 Uplift ( https://fedoraproject.org/wiki/Features/F13Boost141 ) #318 Feature - Gnome 2.30 ( https://fedoraproject.org/wiki/Features/Gnome2.30 ) #319 Feature: KDE Pulseaudio Integration ( https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration ) #320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) #321 Feature: Protecting binaries using capabilities ( https://fedoraproject.org/wiki/Features/ProtectingBinariesUsingCapabilities ) Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (2010-01-26) FESCo meeting
One more feature for tomorrow's meeting: #323 Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall ) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gvfs causes hangs
Adam Williamson wrote: > I don't believe it was ever escalated as a blocker. I probably didn't > consider promoting it as one at the time as FUSE isn't used for any > normal native Linux mount. Probably the most common use of FUSE is for > mounting NTFS partitions via ntfs-3g, but I'm not sure that's vital / > common enough to block a release. The problem is that gvfs also uses FUSE (AIUI, it can work without, but FUSE mounting for the benefit of non-gvfs-enabled apps is enabled by default). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning xerces-c
Peter Lemenkov wrote: > Seems that things are getting even worse. I found the only way to > completely resign from the maintainership of xerces-c - by pressing > the "Retire Package" button. And now the package has "Deprecated" > status and no other buttons are active. "Retire package" is for when you want to completely remove a package from the distribution, it was the "big red button" you were not supposed to hit. Now only a cvsadmin can fix your mess. But you'd have needed an admin anyway to reassign ownership directly and thus bypass this "automatically reassign to the comaintainer" "feature". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gvfs causes hangs
Steve Grubb wrote:
> Digging into this further, if you run lsof, it hangs when it gets to
> ~/.gvfs:
It is possible to disable FUSE mounting in gvfs, see:
http://lists.fedoraproject.org/pipermail/users/2009-August/084569.html
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenModelica users wanting to have rpms?
Christoph Höger wrote: > I have started converting MetaModelica to autootols to boot-bootstrap > the omc build process. May I suggest using CMake instead? It's easier to use, its new versions are more backwards-compatible with older ones, it's more portable to other (inferior ;-) ) operating systems, it doesn't require or expect you to ship generated files in source tarballs, it supports nice features like progress percentages, it's faster and it's successfully used in more and more upstream projects, including all of KDE. On the other hand, CMake would probably be less than helpful for the SML parts, which comprise a significant portion of the codebase as far as I can see, you'd have to work with add_custom_command which isn't that wonderful. (For common languages like C/C++ and a few others, CMake does a lot of stuff for you, but less common ones aren't really supported and you end up having to write CMake commands equivalent to makefile rules.) So each tool has its advantages and drawbacks. > Building the rml compiler and the related libraries was easy, but now I > could need some help and advice on how to build the testcases. > In the original buildsystem from > https://openmodelica.ida.liu.se/svn/MetaModelica there are some examples > with own makefiles, but those refer to the buildsystem itself. > I am not sure how to handle this with automake (obviously it would > require to build the compiler before the tests). > So currently I am wondering if the examples should have a build system > that requires the compiler to be installed, any thoughts? Normally testsuites can use the just-built compiler directly from the source tree. Look at existing projects and how they handle this. As you're using autotools, I guess GCC would be a good place to look. > On the other hand, there are some "style" questions, I'd like to be > answered: > > This package builds three slightly different libraries in three differen > flavors: called (librml_plain|librml_mask|librml_diff)(_g|_p|).so > Those flavors only differ by the CFLAGS set upon compilation (_p means > -p, _g -g). > Upstream told me, they require them all, but would this be acceptable? Sure, I don't see why not. You just need to be careful when building (you need to build the object files to different places so they don't conflict). > Is the name rml ok for a library in /usr/lib or shall I > use /usr/lib/rml/ by default? (Same for headers) Hmmm, that's a bit at the limit, 3 letters are a bit short for a unique name. :-( But there's no librml.so in Fedora yet as far as repoquery tells me, so at least there's no current conflict. Let's see what others think. > What with the name? Is MetaModelica even a good name, if the main binary > is rmlc? If that's the upstream project name (used in things like tarballs), it's fine. (But is the MixedCase really necessary? :-( Usually things like tarball and package names are all lowercase, but sometimes MixedCase is used by upstream and the Fedora packages usually match that. Probably something to discuss with upstream.) > The package builds a compiler driver, essentially a shell script, by > copying some configuration variables into a shell template (mainly how > to invoke cc). Would this be fine as a /usr/bin script? Yes, but beware of multilib conflicts: if that script is in the same package as some libraries, that package will end up multilibbed due to the libraries and if the script is not identical for 32-bit and 64-bit, there will be a conflict between the 2 multilibbed packages. (Splitting out the libraries into a -libs package is a way to work around that.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary for (2010-01-26) FESCo meeting
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.log.html Meeting started by nirik at 20:01:03 UTC (full logs). Meeting summary init process (nirik, 20:01:03) 314 Wordpress bundles libraries (nirik, 20:03:44) AGREED: Will ask packaging to investigate this issue further before taking action on it. (nirik, 20:14:35) 315 Feature: boot.fedoraproject.org ( https://fedoraproject.org/wiki/Features/BFO ) (nirik, 20:14:46) AGREED: Feature is approved. (nirik, 20:17:20) 316 Feature - Bonobo Free Evolution ( https://fedoraproject.org/wiki/Features/BonoboFreeEvolution ) (nirik, 20:19:00) AGREED: This Feature is NOT approved. (Good work, but not feature worthy) (nirik, 20:23:49) 317 Feature: Fedora 13 Boost 1.41 Uplift ( https://fedoraproject.org/wiki/Features/F13Boost141 ) (nirik, 20:23:58) https://svn.boost.org/trac/boost/wiki/CMake (Kevin_Kofler, 20:29:39) AGREED: Feature is approved (nirik, 20:37:54) 318 Feature - Gnome 2.30 ( https://fedoraproject.org/wiki/Features/Gnome2.30 ) (nirik, 20:38:00) AGREED: Feature is approved (nirik, 20:38:50) 319 Feature: KDE Pulseaudio Integration ( https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration ) (nirik, 20:39:39) AGREED: Feature is approved (nirik, 20:40:50) 320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) (nirik, 20:41:01) AGREED: Defer this feature until next weeks meeting. (nirik, 20:48:58) 323 Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall ) (nirik, 20:49:10) AGREED: Feature is deferred to next week. Will ask feature owner for more info. (nirik, 21:01:52) 324 naming conflict: surf (nirik, 21:02:11) AGREED: Will wait a week for more data. (nirik, 21:15:41) Open Floor (nirik, 21:15:48) Open Floor (redux) (nirik, 21:30:01) Meeting ended at 21:34:16 UTC (full logs). People present (lines said) nirik (124) Kevin_Kofler (74) cwickert (74) pjones (67) dgilmore (39) notting (24) zodbot (14) mitr (5) gholms|mbp (4) tibbs (2) abadger1999 (1) mjg59 (0) ajax (0) skvidal (0) -- 20:01:03 #startmeeting FESCO (2010-01-26) 20:01:03 Meeting started Tue Jan 26 20:01:03 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:03 #meetingname fesco 20:01:03 #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:01:03 #topic init process 20:01:03 Who all is around for the FESCo meeting? 20:01:03 The meeting name has been set to 'fesco' 20:01:03 Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:01:25 yo 20:01:29 here 20:01:30 * notting is here 20:01:57 Present. 20:02:39 * dgilmore is here 20:03:02 ok, I guess we have quorum so we can get started. 20:03:31 * nirik doesn't see skvidal yet, so lets defer package-swift further discussion. 20:03:44 #topic 314 Wordpress bundles libraries 20:03:44 .fesco 314 20:03:46 nirik: #314 (Wordpress bundles libraries) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/314 20:04:08 sounds like we need to have packaging look for a line here on when code should be allowed to be bundled, etc. 20:04:23 This sounds like a big mess of copypasta. :-( 20:04:34 yeah. 20:04:52 so, not sure what we can do now on this, shall we wait for packaging to look at it? 20:04:56 any other input? 20:04:57 There's no way to make it use system libraries when the code it uses is heavily patched. 20:05:12 I doubt this is possible in this case 20:05:20 So I think we'll have to just consider it different code. 20:05:31 Still, this practice really sucks. 20:05:33 I mean, we cannot go to the wp devs and tell them to upstream their changes 20:05:34 that sounds unfortunate, but probably necessary. 20:05:50 cwickert: well, we can, but we might also want to let the changes ride while we do so 20:06:02 cwickert: Why not? 20:06:08 well, it's not all a or b here. 20:06:16 of course we can, but I doubt that it is realistic 20:06:26 They really need to stop this practice of copying code from libraries and randomly adding their own stuff. 20:06:33 some of the things are heavily modified and could be considered new code ish... there are some that aren't and should use the system libs. 20:06:49 where that line is is the question. 20:06:59 Kevin_Kofler: how would you make wp installable without the internal copies? 20:07:26 As a package with proper dependencies, like any other package. 20:07:47 I'm not talking about the rpms but about upstream 20:08:07 They should support only packages, not obsolete monolithic tarballs. 20:08:29 But if they really want the monolithic crap, they can bund
Re: Non-responsive maintainer for socat: Paul Wouters (pwouters)
On Wed, 27 Jan 2010 11:50:44 +0100 Till Maas wrote: > Hi, > > Paul Wouters seems to be non-repsonsive for socat, there a two bugs > open with no response within 6 months: > https://bugzilla.redhat.com/show_bug.cgi?id=511310 > https://bugzilla.redhat.com/show_bug.cgi?id=513720 > > He has been pinged by the reporter of the second bug twice on > 2009-08-17 and 2009-12-13 and today by me. > > If there is no response by the end of the week, I would like to > execute the FastTrack procedure: > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Fast_Track_procedure > > Then as many communication attempts as suggested in the normal case > have been attempted, only with different intervals than one week. > > List of packages: > https://admin.fedoraproject.org/pkgdb/users/packages/pwouters I see that Paul did a commit yesterday and several others last week. Hopefully he's just swamped and would like to find another maintainer for the socat package. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Wed, 27 Jan 2010 15:43:40 +0100 Till Maas wrote: > On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote: > > On Sun, 17 Jan 2010 20:52:12 +0100 > > Till Maas wrote: > > > > > The list of packages you announced that are going to be orphaned > > > and the list of packages that were orphaned are not the same. > > > recordmydesktop was on the to-be-orphaned list but afaics was not > > > orphaned and also was not mentioned in your list about which > > > provenpackager fixed which package. > > > > Odd. Not sure why it wasn't there. > > > > I mailed the maintainer and can orphan it. > > It is still not orphaned afaics. Sorry about that, was hoping I would get a reply. Orphaned in devel. If someone wants to pick it up in other branches just let me know. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
Jesse Keating wrote: > Unblocked orphan gtk-qt-engine This one was basically retired by rdieter (kcm-gtk Obsoletes it, though it contains only the KCM part, the theme engine was unstable and is dead upstream), I guess the retiring process was just not completed properly. So I guess this one can just die. > Unblocked orphan qtoctave I'll pick this one up, it's useful (a Free Software equivalent to the MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, even), there's AFAIK no obvious replacement and upstream seems active. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
Kevin Kofler wrote: > Jesse Keating wrote: >> Unblocked orphan qtoctave > > I'll pick this one up, it's useful (a Free Software equivalent to the > MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, > even), there's AFAIK no obvious replacement and upstream seems active. Actually, it looks like this one already got taken care of (nucleo picked it up), but I filed for comaintainership. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100128 changes
[snip] > New package OpenGTL > Graphics Transformation Languages > New package aseqmm > C++/Qt4 wrapper around the ALSA library sequencer interface > New package bristol > Synthesizer emulator > New package certmonger > Certificate status monitor and PKI enrollment client > New package font-manager > A font management application for the GNOME desktop environment > New package iwl5150-firmware [and it ends here] The report got truncated yet again. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: best practice for packing programs that use strlcpy()?
Eric Smith wrote: > What is considered the best practice for packaging a program that uses > strlcpy()? > Is there a Fedora library that provides strlcpy() and friends? > Should I add an implmentation of strlcpy() to the package as an > additional source or patch? > Should I modify the program to not need strlcpy()? (I really don't like > this idea.) You're the victim of a longstanding feud between people who think strlcpy and friends are essential for security (including the OpenBSD community, who invented them, and several application developers) and those who think they're just useless nonstandard functions (including Ulrich Drepper, the glibc maintainer), with no resolution in sight, unfortunately. :-( Well, technically: > Is there a Fedora library that provides strlcpy() and friends? libkdefakes.so.5 provides strlcat and strlcpy, but as that's part of kdelibs it's probably not the answer you were looking for. ;-) libbsd sounds like a decent solution, probably the best you'll get due to the conflict cited above. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Adam Williamson wrote: > Please do provide any and all feedback on the proposed policy. if we can > get it into a shape which most people on the list would find acceptable, > my next step will be to take it back to FESco for them to review. > Thanks. >From the proposal: > Add, remove, upgrade or downgrade any system-wide application or shared > resource (packaged or otherwise) The current PackageKit policy in F12 updates still allows upgrading (as opposed to installing or removing, not sure about downgrading, does PackageKit even support that?) packages without root authentication. Is this intended to be changed as part of the proposal or should the proposal be fixed instead (just remove "upgrade" from the sentence)? > New and changed privilege escalation mechanisms Is the bureaucracy in this section really necessary? AFAICT what was missing when the F12 PackageKit change was made was the informative part of the proposal, the maintainer just didn't know what he should be allowing and what not. I don't think the enforcement part is really needed, maintainers should be able to get it right on their own given the detailed list of evil things to avoid which the proposal provides and I haven't seen any evidence as to the contrary (again, the PackageKit example is not applicable because the PackageKit maintainer did NOT have such a list to go by when he made his change; there's no reason to believe he'd have made that change in spite of it). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Liu Yu Fei Eric wrote:
> I noticed firefox was stuck on 3.5.6 for a rather long time.
> What about 3.5.7 and the recently 3.6? They are even not in koji.
http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Adam Williamson wrote: > I think it's sensible, yeah. It's not really much bureaucracy; I don't > think it would ever be a good idea to introduce a new privilege > escalation mechanism without FESco knowing about it... Right now we're in a phase where a lot of stuff (system-config-*, several parts of KDE and some other stuff) is getting ported from running the whole app under consolehelper or kdesu to PolicyKit mechanisms. This is generally seen as a *good* thing. It'd be really annoying to have to go through a FESCo vote for every single one of those. At the very least, I'd suggest adding the following clause to that paragraph: "Any mechanism which requires administrative authentication to perform the privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a privilege escalation mechanism for the purposes of this paragraph." Rationale: Such a policy does not impact the system's security as you have to enter the root password before doing anything dangerous, so none of the invariants under "Requirements" can be violated. And additionally, you can always as a user run the whole app under e.g. kdesu and thus "escalate your privileges" using the root password, so it doesn't make sense to police apps providing such a mechanism. What really matters for security is what you can do WITHOUT the root password. This is not really clear from the policy as written now, adding the suggested sentence would clarify it. (That said, I don't see even the clarified policy as being necessary. We have a set of guidelines, maintainers should follow them, why do we have to police them? As I explained before, there is no evidence that this is necessary or useful. The PackageKit issue was caused by lack of a policy, not lack of enforcement.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Wes Shull wrote: > yum --enablerepo=rawhide update firefox NEVER do that!!! You probably have way more Rawhide packages than just Firefox now. At least xulrunner and all the stuff using its "unstable API", probably also sqlite and a lot more stuff. Each time your package depends on a newer library with a new ABI, you end up dragging in the new library, which in turn drags in rebuilt versions of ALL programs using that library! And of course this continues in a transitive chain! That quickly sums up to half of the distro leaving you with an unsupportable mix of F12 and Rawhide. And even if it worked for you, it is a big mistake to recommend this to other users who do not understand the implications. Please NEVER recommend this to another user again!!! (And I'd also STRONGLY recommend against doing that again yourself.) The ONLY safe use of --enablerepo=rawhide is a full "yum --enablerepo=rawhide update", at which point you're running Rawhide with all its warts, something I'd NOT recommend to an average user. Selective upgrades from Rawhide are NOT SUPPORTED and will in many cases NOT work as expected due to dependencies and reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Mail Lists wrote:
> I think we need to use sun java as green tea is not yet on new api
> anyway is it?
The IcedTea plugin is in Fedora (as java-1.6.0-openjdk-plugin). Fedora does
not and will not ship proprietary software such as the Sun Java plugin (from
the non-open JDK or JRE).
A new version of IcedTea with a new plugin which supports Firefox 3.6 is
being imported into Rawhide. This would have to be backported if Firefox 3.6
were to be pushed to F12.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Frank Murphy wrote: > You can update to 3.6 > from Rawhide, > then disable rawhide again. > > Which is what I have done, > no problems yet. NEVER do that!!! You probably have way more Rawhide packages than just Firefox now. At least xulrunner and all the stuff using its "unstable API", probably also sqlite and a lot more stuff. Each time your package depends on a newer library with a new ABI, you end up dragging in the new library, which in turn drags in rebuilt versions of ALL programs using that library! And of course this continues in a transitive chain! That quickly sums up to half of the distro leaving you with an unsupportable mix of F12 and Rawhide. And even if it worked for you, it is a big mistake to recommend this to other users who do not understand the implications. Please NEVER recommend this to another user again!!! (And I'd also STRONGLY recommend against doing that again yourself.) The ONLY safe use of --enablerepo=rawhide is a full "yum --enablerepo=rawhide update", at which point you're running Rawhide with all its warts, something I'd NOT recommend to an average user. Selective upgrades from Rawhide are NOT SUPPORTED and will in many cases NOT work as expected due to dependencies and reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Christopher Brown wrote: > This is because 3.5.7 doesn't affect us. Stability issue is for > Windows people and update notification is patched out for obvious > reasons. > > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.1%3A.7-fixed What about the NTLM issue? That looks like it could affect Fedora users if they are behind a Window$ Vi$ta or 7 proxy. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
Frank Büttner wrote:
> I have done some like at my first package, and then to my was spoken,
> that I use local mock and not the infrastructure. But after some updates
> of mock, mock it now dead. The no response from them maintainer.
Don't worry, even I get away with my intensive use of Koji. ;-) I rarely do
local mock builds (mostly only if I build stuff for repo.calcforge.org or if
I can't use a Koji build for some reason, like not having the right stuff in
the buildroot), I just send everything straight to Koji and I maintain more
stuff than you. ;-)
FWIW, I usually only scratch build if the package is pending review.
Otherwise, I just do this routine:
* commit change
* make tag
* make build BUILD_FLAGS=--nowait
* while (build failed) {
* commit fix
* make tag TAG_OPTS=-F
* koji resubmit taskid --nowait
}
The advantage over scratch builds is: if you scratch-build, once it's
successful, you have to redo the build as a real build, so you waste one
build. With my workflow, you save that build. Saves both Koji resources and
your time. Also saves your time over local mock builds where you also have
this "one wasted build" problem.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to take ownership of a package in rawhide branch? - Was: [Taking ownership of the orphaned packages: bytelist, jcodings, jvyamlb]
Victor Vasilyev wrote: > I'm trying to complete the step 3 of the "Claiming Ownership of an > Orphaned Package Procedure" [1] that says: > "3. Press the "Take Ownership" button for each active branch that you > want to maintain." > > However, I don't see such buttons associated with the rawhide for all > mentioned packages, i.e. bytelist, jcodings, and jvyamlb. > How I can take ownership of the packages in the devel branch, but not in > Fedora 11? Those packages have been marked as retired because they have been orphaned for more than 3 months. You need to submit new review requests, specifying that this are packages which were previously in Fedora and are being resurrected. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > This is one reason I prefer to use the following changelog style > > * Thu Jan 28 2010 Michael Schwendt > - 2.2-10 > - Fix tuple_copy() further (it was completely broken as the mowgli > dict wasn't copied at all). > - 2.2-9 > - Let set_tuple_cb() work on a copied tuple > (the metadata updates flood is too racy IMO). > - Fix tuple_copy(). This style is not compliant with the Fedora packaging guidelines. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Miloslav Trmač wrote: > That's not the intent: "mechanism" is "the code that causes running > something as root", in this case DBus activation, not "the code running > as root" (a DBus server). Oh, if that's the intent, that's of course perfectly fine. I'd be happy to provide any needed documentation about KAuth, but you'll only really need it if you want to run checks on the source code, as KAuth uses existing mechanisms (PolicyKit (both 1 and 0.9 are supported), D-Bus activation) for the actual privilege escalation, it's just a source-level abstraction layer (so for example, you won't find a PolicyKit policy in the source code, but a KAuth policy which is converted to a PolicyKit policy at build time). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Mon, 1 Feb 2010 13:38:13 -0500 Toshio Kuratomi wrote: > On Fri, Jan 22, 2010 at 12:13:06PM -0500, Jarod Wilson wrote: > > On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson > > wrote: > > >> I have no idea if it actually requires them to be alongside the > > >> executables, but hopefully the link will help. > > > > > > It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc > > > to get included in Red Hat Enterprise Linux 5 (a separate review > > > from the Fedora one), and pointed out this same problem, and it > > > was done properly for RHEL5: > > > > > > $ rpm -ql hmaccalc > > > /usr/bin/sha1hmac > > > /usr/bin/sha256hmac > > > /usr/bin/sha384hmac > > > /usr/bin/sha512hmac > > > /usr/lib64/hmaccalc > > > /usr/lib64/hmaccalc/sha1hmac.hmac > > > /usr/lib64/hmaccalc/sha256hmac.hmac > > > /usr/lib64/hmaccalc/sha384hmac.hmac > > > /usr/lib64/hmaccalc/sha512hmac.hmac > > > /usr/share/doc/hmaccalc-0.9.6 > > > /usr/share/doc/hmaccalc-0.9.6/LICENSE > > > /usr/share/doc/hmaccalc-0.9.6/README > > > /usr/share/man/man8/sha1hmac.8.gz > > > /usr/share/man/man8/sha256hmac.8.gz > > > /usr/share/man/man8/sha384hmac.8.gz > > > /usr/share/man/man8/sha512hmac.8.gz > > > > > > It should be simple enough to just update the Fedora packages > > > with the changes in RHEL5 and we can all go eat cake. But first, > > > I'm going to go play some pickup soccer... > > > > Oh. Wait. Crap. We're talking about packages other than hmaccalc > > itself that do integrity checks. But I do agree with Ralf here, the > > checksum files don't belong in /usr/bin/, and there's no > > standard-based need for them to be there. > > > > > So few things that need doing here: > > 1) The present packages need to be fixecd. Sounds like fipscheck, > hmaccalc, and openssh. They are violating the FHS which is > prohibited by the Guidelines. Ralf, have you opened bugs? I see: openssl-0:1.0.0-0.20.beta5.fc13.i686 openssh-clients-0:5.3p1-21.fc13.x86_64 fipscheck-0:1.2.0-4.fc13.x86_64 libgcrypt-0:1.4.5-1.fc13.x86_64 fipscheck-lib-0:1.2.0-4.fc13.i686 openswan-0:2.6.24-1.fc13.x86_64 openssh-server-0:5.3p1-21.fc13.x86_64 fipscheck-lib-0:1.2.0-4.fc13.x86_64 openssl-0:1.0.0-0.20.beta5.fc13.x86_64 libgcrypt-0:1.4.5-1.fc13.i686 hmaccalc-0:0.9.12-1.fc13.x86_64 in rawhide that have *.hmac* files. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines
Bruno Wolff III wrote: > https://fedoraproject.org/wiki/Category:Spins_Fedora_13 > > Some of those are kickstart only and won't have prebuilt isos for > download. In addition to these spins, there are also the 2 permanent live spins (GNOME and KDE) and the non-live installers (DVD, CD set, netinstall). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > Sure it is, it's changelog style #3 of > http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs No, it's not style #3. It's 2 or more style #3 entries collapsed into 1, which is not one of the allowed formats. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for Tomorrow's (2010-02-02) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 20:00UTC (3pm EST) in #fedora-meeting on irc.freenode.net. Followups: #314 Wordpress bundles libraries #324 naming conflict: surf #320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) #323 Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall ) New Business: #325 Fast-track Nonresponsive maintainer: Sindre Pedersen Bjørdal (sindrepb) #327 Feature: StorageFiltering ( https://fedoraproject.org/wiki/Anaconda/Features/StorageFiltering ) #328 Feature: Dogtag Certificate System ( https://fedoraproject.org/wiki/Features/DogtagCertificateSystem ) #329 Feature: KVM Stable PCI addresses ( https://fedoraproject.org/wiki/Features/KVM_Stable_PCI_Addresses ) #330 Feature: Multipath install ( https://fedoraproject.org/wiki/Features/MultipathInstall ) #331 Feature: NetworkManager MobileStatus ( https://fedoraproject.org/wiki/Features/NetworkManagerMobileStatus ) #332 Feature: Virtx2apic ( https://fedoraproject.org/wiki/Features/Virtx2apic ) #333 Feature: VHostNet ( https://fedoraproject.org/wiki/Features/VHostNet ) #334 Late Feature Exception: NetworkManager Cmdline ( https://fedoraproject.org/wiki/Features/NetworkManagerCmdline ) #335 Late Feature Exception: NetworkManager Bluetooth DUN ( https://fedoraproject.org/wiki/Features/NetworkManagerBluetoothDUN ) Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > That is your interpretation. I see nothing on this page to support this > claim. And actually it is contrary to format #3 logic, since its main > difference with other changelog formats is that the version is not part of > the entry header, so there's no reason to limit one entry to one version It's blatantly obvious that all these formats have one thing in common: there's one entry per new EVR. Our automated tools (e.g. make clog as already pointed out by Michael Schwendt) also expect that. But I guess I'll need to get the FPC to officially clarify this. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (05/2010)
Richard Hughes wrote: > On 2 February 2010 15:12, Sebastian Vahl > wrote: >> * setroubleshoot introduced a hard dependency on gnome-packagekit >> (#561001) * The dependency should be made generic or setroubleshoot has >> to be removed from KDE spin. > > Is it just a dep on the PackageKit session API? If so can't we just > add a virtual provide "PackageKit-session" to gnome-packagekit and > kpackagekit, and switch setroubleshoot to require that? It's a dependency on something which is no longer used, it seems (instead, they use yum directly in the current code), so they just removed it in Rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=561001 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > This changelog style conforms to the existing spec, it has been in use in > Fedora for several years, it may surprise you, but changing the spec > retroactively is not the way to prove your point. Uh, the Fedora packaging guidelines DO have the power to change the requirements, they're not cast in stone. Even existing changelogs can be fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary for 2010-02-02 FESCo meeting
=== #fedora-meeting: FESCO (2010-02-02) === Meeting started by nirik at 20:01:34 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-02-02/fesco.2010-02-02-20.01.log.html Meeting summary --- * init process (nirik, 20:01:34) * #324 naming conflict: surf (nirik, 20:05:13) * LINK: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1772215 (dgilmore, 20:17:40) * AGREED: surf package in Fedora should rename to surf-browser along with its binary and man pages, etc. (nirik, 20:21:44) * #320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) (nirik, 20:21:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=560084 (Kevin_Kofler, 20:23:37) * AGREED: Feature is approved. (nirik, 20:26:00) * #325 Fast-track Nonresponsive maintainer: Sindre Pedersen Bjørdal (sindrepb) (nirik, 20:26:11) * LINK: http://fpaste.org/NpTL/ (skvidal, 20:28:52) * LINK: https://www.redhat.com/archives/fedora-extras-commits/2010-January/msg00188.html (nirik, 20:31:32) * AGREED: Maintainer is unresponsive, will find (co)maintainers for his packages. (nirik, 20:40:43) * #327 Feature: StorageFiltering ( https://fedoraproject.org/wiki/Anaconda/Features/StorageFiltering ) (nirik, 20:40:59) * AGREED: Feature is approved. (nirik, 20:42:27) * #328 Feature: Dogtag Certificate System ( https://fedoraproject.org/wiki/Features/DogtagCertificateSystem ) (nirik, 20:42:45) * AGREED: Feature is approved. (nirik, 20:44:05) * #329 Feature: KVM Stable PCI addresses ( https://fedoraproject.org/wiki/Features/KVM_Stable_PCI_Addresses ) (nirik, 20:44:14) * AGREED: Feature is approved. (nirik, 20:46:14) * #330 Feature: Multipath install ( https://fedoraproject.org/wiki/Features/MultipathInstall ) (nirik, 20:46:22) * AGREED: Feature is approved. (nirik, 20:47:57) * #331 Feature: NetworkManager MobileStatus ( https://fedoraproject.org/wiki/Features/NetworkManagerMobileStatus ) (nirik, 20:48:08) * AGREED: Feature is approved. (nirik, 20:49:31) * #332 Feature: Virtx2apic ( https://fedoraproject.org/wiki/Features/Virtx2apic ) (nirik, 20:49:39) * AGREED: Feature is approved. (nirik, 20:51:39) * #333 Feature: VHostNet ( https://fedoraproject.org/wiki/Features/VHostNet ) (nirik, 20:51:47) * AGREED: Feature is approved. (nirik, 20:54:44) * #334 Late Feature Exception: NetworkManager Cmdline ( https://fedoraproject.org/wiki/Features/NetworkManagerCmdline ) (nirik, 20:55:33) * AGREED: Feature is approved. (nirik, 20:58:11) * #335 Late Feature Exception: NetworkManager Bluetooth DUN ( https://fedoraproject.org/wiki/Features/NetworkManagerBluetoothDUN ) (nirik, 20:58:24) * AGREED: Feature is approved. (nirik, 20:59:50) * Open Floor (nirik, 21:00:01) * Potentially Unmaintained script (nirik, 21:00:45) * fesco mailing list archives (nirik, 21:12:51) * AGREED: The fesco list is for nonpublic/sensitive matters. Use trac for public issues. Use of the private list will be kept to a minimum. (nirik, 21:31:43) * Open Floor 2: the return (nirik, 21:31:54) Meeting ended at 21:36:38 UTC. -- 20:01:34 #startmeeting FESCO (2010-02-02) 20:01:34 #meetingname fesco 20:01:34 #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:01:34 #topic init process 20:01:35 Meeting started Tue Feb 2 20:01:34 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:40 The meeting name has been set to 'fesco' 20:01:40 * skvidal is here 20:01:41 Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:01:48 * notting is here 20:01:50 Present. 20:01:57 party people in the house 20:02:05 * abadger1999 takes a seat in the bleachers 20:02:28 * skvidal has never been referred to as a party person 20:02:29 * pjones is here. 20:02:32 I'm sure y'all are all shocked 20:03:15 * dgilmore is here 20:03:25 Hello 20:03:39 ok, I shall we get started? we have a fun packed agenda today. ;) 20:03:53 packed with fun 20:03:57 cwickert: are you present? 20:04:00 an odd expression 20:04:16 indeed. 20:04:49 well, the followup item was about the 'surf' package, which cwickert was following. So, lets skip that and see if he's around later. 20:04:50 * gholms prepares coffee for everyone; it's going to be a long meeting. 20:04:58 sorry for being late 20:05:04 ah, there he is. :) 20:05:13 #topic #324 naming conflict: surf 20:05:13 .fesco 324 20:05:16 nirik: #324 (naming conflict: surf) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/324 20:05:37 no news from the surf problem, cassmodiah tried to contact upstream, but 5 out of 6 mails bounced 20:05:48 and the last one didn't reply yet 20:05:56 next step is a bug in their tracker
Re: Is PulseAudio dead?
I wrote: > s/desktop/GNOME/ > > KDE packages are tracking upstream closely and are regularly updated, > including upstream bugfixes. Plus, we backport or sometimes even develop > bugfixes of our own. > > To me, this shows that a model where upstream versions are tracked by > updates is much more viable than attempting (and miserably failing) to > backport bug fixes only. > > It also shows that KDE SIG actually has more and/or more efficient > packaging (as opposed to upstream development) manpower than the GNOME > folks, unlike what has been frequently claimed. PS: And since PulseAudio is a shared technology also used by other desktops than just GNOME, I'd be willing to pick up comaintainership, but then it'd very likely be maintained in KDE SIG style, aggressively tracking upstream development. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Matthias Clasen wrote: > I was on vacation for two weeks, but I'm back now. So our manpower > should be even again :-) LOL, it's true that you do a lot of work all by yourself. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Neal Becker wrote:
> OK, got mercurial updated for devel, apparantly OK. Now try to update
> f13:
[snip a bunch of git tribulations]
It's quite telling that the git workflow is so arcane and exotic that even
the maintainer of another DVCS cannot figure it out! Git just has to do
everything in its own bizarre, confusing and broken way. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > IMO, if you want to be a co-maintainer, you will have to coordinate > and work with the model preferred by the primary maintainer. Otherwise > disputes will make the process worse and not better. This (or rather, the differences in update conception) is exactly why I haven't applied for comaintainership of PulseAudio. I think that this conservative model is really unhelpful as it often lets bugs linger for ages (backporting is a lot of work, so it's rarely done, and sometimes it's outright impractical, not to mention that some very conservative people judge even backporting of non-critical bugfixes to be inappropriate for an update) and that it's very sad that the Board and FESCo are now actively pushing for such a bad model as a global Fedora policy, despite strong evidence that our users do not want this model, and despite the fact that this makes us lose our niche, compete directly with distributions we CANNOT compete with (we stand no chance against Ubuntu's massive marketing machine) and leave users in our current niche out there in the cold with no way to go. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > I believe a co-maintainer if he/she wants to collaborate wouldn't > constrained by differences in approaches and can participate and help > out regardless of that. If you review bug reports, I suspect you will > find ways to help. It just requires letting go of the notion that my > approach is the only right one. I don't believe it is possible to fix PulseAudio bugs effectively without tracking upstream more closely. Upstream is where Lennart focuses his bugfixing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > Are you comparing git to Mercurial or to a centralized VCS? Both. Git is just a PITA in its own league, but DVCSes as a whole are a broken (*) and unhelpful (inherently hard to use) concept. (*) e.g. because of the strong reliance on hashes, which can make the whole thing break down in the event of a hash collision, and which make commit IDs nonsequential and unpredictable > Some of the complexity is intrinsic to distributed VCS and has to be > weighed against the significant benefits to people who build custom > packages, like me. I don't see how dist-git makes it any easier to build customized packages. If you really want a local git mirror of a centralized repository, you can also use git-cvs, git-svn or the like. For SVN, SVK is also a nice solution. All this dist-git migration has brought us is chaos, a much higher barrier to entry and much harder work for existing packagers. (And yes, I've also tried to make these points BEFORE the migration, but nobody listened.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > Since there is no new upstream release, you will have to triage bugs, > cherry pick patches and push them as updates. What else do you mean by > tracking upstream closely? If there's no new release, I'd just ship a snapshot. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > "Broken" in the past tense is inaccurate: no SHA-1 collision has been > published yet. I would like to see DVCSes switch to a stronger hash > algorithm sooner rather than later, but it's not enough of a concern > that I would avoid using them. If it makes you feel any better, git > will not allow a fetched object to replace a local one with the same > hash, so you can only lose if you fetch from the attacker first. I'm not talking about intentional collisions, I'm talking about accidental collisions, which ALL hash algorithms are vulnerable to, no matter how strong. Hashes are inherently non-injective and mathematically CANNOT be otherwise. Now the probability of an accidental collision is very low, but it is not zero, so the algorithm is unreliable. And low probabilities add up the more projects use DVCSes. Sooner or later some project will be hit by a collision. And the shorter the hash, the more likely a collision (exponentially!), so the "abbreviated hashes" git uses are particularly collision-prone. > For sequential commit numbering, try "git describe". Nobody actually uses those numbers though (and in fact I doubt those numbers can be used in all the ways SVN revision IDs can be used). What everyone uses is hashes, leaving you to wonder whether deadbeef or c0cac01a is the newer revision (assuming that both are snapshots from master or at least from the same branch, which is usually the case when comparing 2 packaged snapshots). > The problems with CVS were amply explained there, but it's less clear to > me whether there were compelling reasons to choose git over (e.g.) SVN + > git-svn or the people involved just happened to like distributed version > control, as I do. Sure they do, but the problem is that they're FORCING their preference onto everyone, whereas using SVN would have allowed them to work their way (using SVK or git-svn) without breaking our workflow, and SVN has all the required features (e.g. atomic commits and thus repository-wide revision IDs). Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > The only potentially confusing behavior was that git defaulted to > pushing all branches. Given that, the push failed due to a concurrent > change to a different branch on the destination, and it was necessary to > switch to that branch in order to perform the merge (well, rebase, but > the difference isn't important here). I see nothing arcane, exotic, > bizarre, or broken about that. And I don't think I would change the > default push behavior: I can envision forgetting to push a change to a > non-current branch until someone complains about it. The whole idea of having more than one branch in a checkout is confusing. I really don't see why I'd want to have a complete clone of the repository on my HDD rather than a working copy which contains all I actually work on (the current revision of one branch; if I work on multiple branches, that's what directories on my file system are for). (And this is another reason why I consider DVCSes to be broken by design.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > Nevertheless, if you really want to try this method, use > http://repos.fedorapeople.org, No thanks. repos.fedorapeople.org is a very sorry excuse for a PPA infrastructure, it's basically only storage with a list of repos, you have to manage everything by hand, there's no build system integration of any kind (e.g. if you try to build 2 packages which depend on each other, you have to build them outside of Koji; and there's also no direct upload from Koji), you can't even run createrepo on the server (or at least the instructions explicitly tell you not to)! I already have more helpful infrastructure than that on repo.calcforge.org, at least I can run createrepo and repoview on the server, and I can also maintain my specfiles and patches on svn.calcforge.org. (And I used to think that my infrastructure is very poor due to how much stuff I have to manage manually. Guess what, the one now officially offered to us is worse!) What is needed to offer proper support for personal repositories: * automatic creation of *-release packages, * self-populating Koji build targets, so dependent packages can be built, * automatic (maybe triggered by Bodhi or some similar tool) uploading of build results from Koji, including signing the output and running createrepo and repoview, * revision control for the custom packages. (Yes, git allows me to put up a repo on my HDD or on fedorapeople.org. No, I don't want to have to do this manually, and a local repo on my HDD makes me vulnerable to data loss. Plus, the manual approach means every maintainer will put his repositories in a different place, so good luck finding some maintainer's repository if you need it.) Frankly, repos.fedorapeople.org is really poor compared to e.g. the OpenSUSE Build Service (OBS), and in fact I'd recommend the latter (it can also target Fedora) if it weren't for some important issues with their Fedora targets: they don't support Rawhide nor Branched (at least last I checked), they build against GA with no updates (unless they fixed that recently) and they do strange things to specfiles (like automatically bumping Revision) and encourage the use of constructs which don't work outside of OBS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote: > I think this may be the main issue here - there is no meaning of "newer" > in git. There is a partial order given by ancestry, and 2 revisions you want to compare WILL in general be ordered. (In fact, whenever it makes sense to numerically compare SVN revision IDs, the commits will also be ordered in a DVCS. Comparing revision IDs from different branches or even different repositories does not make sense in SVN either, but that's not what people are interested in anyway.) > Don't rely on it an you'll be fine. What matters is whether a change is in > a repository or not. Which one is newer hardly ever matters. Nonsense. If, say, Fedora ships foo-12345678 and Ubuntu ships foo-abcdef00, you'll want to know whether 12345678 or abcdef00 is the newer snapshot from the master of foo. (And if they're both snapshots from master, they WILL be ordered unless upstream rewrote their published history, which is just plain evil.) Or, another use case, if we have foo-3.14-0.17.12345678git.fc12 and foo-3.14-0.18.abcdef00git.fc13, how do you verify that the upgrade path is correct and does not in fact downgrade foo when upgrading to F13? The sequence number before (17 vs. 18) might have been incremented due to one or more plain rebuild(s), it doesn't necessarily reflect the sequence of upstream snapshots being packaged. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
