Re: Release monitoring for stable releases only
On Thu, Jan 26, 2023 at 1:09 PM Neal Gompa wrote: > > On Thu, Jan 26, 2023 at 7:02 AM Jaroslav Skarvada wrote: > > > > Hi, > > > > it seems Anitya correctly distinguishes stable and pre-release > > releases but where to set that I want Fedora bugs only for the stable > > releases? IIRC Pagure had a switch for it, but I am unable to find it > > on the https://src.fedoraproject.org/rpms/. There is only > > "No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It > > seems there is no information about it in the docs [1] > > > > You configure it on release-monitoring.org for the upstream project, > not src.fedoraproject.org. Where? The release-monitoring.org / Anitya correctly marks it as a pre-release but the bug is still created. There is only a "Pre-release filter" box, but I think it's a helper if the default regex doesn't work, which in my case seems to work Jaroslav ___ 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
Release monitoring for stable releases only
Hi, it seems Anitya correctly distinguishes stable and pre-release releases but where to set that I want Fedora bugs only for the stable releases? IIRC Pagure had a switch for it, but I am unable to find it on the https://src.fedoraproject.org/rpms/. There is only "No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It seems there is no information about it in the docs [1] thanks & regards Jaroslav [1] https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ ___ 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: Bootstrapping package with circular dependencies in koji
On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok wrote: > > On 25. 01. 23 11:50, Vít Ondruch wrote: > > Reading the thread, I was afraid this will be the end result. Nevertheless, > > given this would be used just for side-tags, is there a chance to exclude > > side > > tags from the policy? Who would handle such request? > > > > Although being able to modify one macro means also possibility to edit all > > macros. Not sure this is desired. However one can achieve almost everything > > by > > changing .spec file, so that should not be blocker IMHO. > Or add an option that will mark/unmark the sidetag for bootstrapping, i.e. option that will add only this specific bootstrap macro to the sidetag and nothing more. > I think the "commit the bootstrap conditional directly to bootstrap something" > approach is much more transparent than "fiddling with macros in Koji to save > myself one tiny commit" anyway. > It's one commit per package. If you rebuild more packages there may be more things that need bootstrapping. > --- > > To answer the original question, it can be done like this: > > 1. commit all commits and push them all > 2. fedpkg request-side-tag > 3. koji chain-build --nowait f38-build-side-6 > 'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653e53b5262ec2812' > : ..instert mid deps here... : > 'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61ceb0ff429168d19' > If there already are the boostrap conditionals in the specs the logic progress is to have some support in the infra. Just manually reverting the condition in the spec is, let's say not the optimal solution. Just my two cents. ___ 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: Bootstrapping package with circular dependencies in koji
On Tue, Jan 24, 2023 at 9:37 PM Neal Gompa wrote: > > On Tue, Jan 24, 2023 at 3:00 PM Kevin Fenzi wrote: > > > > On Tue, Jan 24, 2023 at 07:54:29PM +0100, Jaroslav Skarvada wrote: > > > > > > I initially thought about: > > > release bump > > > $ koji edit-tag SIDETAG -x %_with_bootstrap=1 > > > build > > > handle circular dep > > > $ koji edit-tag SIDETAG -r %_with_bootstrap > > > build > > > > > > But I haven't tried it yet because I didn't want to break anything :) > > > Is this the correct way to do it? > > > > That should work, (as long as you bump the release for the second build > > as koji will not let you rebuild the same n-v-r) > > but I am not sure anyone has tried it. > > > > The NVR will automatically change when you flip between modes, since > it changes the DistTag. > Thanks for the info, we will try it. It would be great to have it documented somewhere in the guidelines thanks & regards Jaroslav ___ 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: Bootstrapping package with circular dependencies in koji
On Tue, Jan 24, 2023 at 7:42 PM Neal Gompa wrote: > > On Tue, Jan 24, 2023 at 1:39 PM Jaroslav Skarvada wrote: > > > > Hi, > > > > I need to bootstrap package which has bootstrap support written > > according to the [1]. I am able to bootstrap it locally (rpmbuild, > > mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is > > there support for it in koji? E.g. something like: > > koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do: > > 1. patch: > > - %bcond_with bootstrap > > + %bcond_without bootstrap > > 2. koji build SIDE-TAG SCM > > 3. update the circular dep > > 4. unpatch: > > - %bcond_without bootstrap > > + %bcond_with bootstrap > > 5. release bump > > 6. koji build SIDE-TAG SCM > > > > Or is there some better way? > > > > thanks & regards > > > > Jaroslav > > > > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping > > You might be able to set macros in your build tags to switch back and > forth between bootstrap mode. I don't recall exactly how this is done > from the koji CLI though... > I initially thought about: release bump $ koji edit-tag SIDETAG -x %_with_bootstrap=1 build handle circular dep $ koji edit-tag SIDETAG -r %_with_bootstrap build But I haven't tried it yet because I didn't want to break anything :) Is this the correct way to do it? ___ 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
Bootstrapping package with circular dependencies in koji
Hi, I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do: 1. patch: - %bcond_with bootstrap + %bcond_without bootstrap 2. koji build SIDE-TAG SCM 3. update the circular dep 4. unpatch: - %bcond_without bootstrap + %bcond_with bootstrap 5. release bump 6. koji build SIDE-TAG SCM Or is there some better way? thanks & regards Jaroslav [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping ___ 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: BuildError: error building package (arch s390x), mock exited with status 245
I am encountering the same problem since yesterday. All my builds are failing on s390x this way e.g. [1], [2]. Could somebody fix it? thanks & regards Jaroslav [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=60132339 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60132333 - Original Message - > I met similar issue yesterday (not sure if it was s390x or elsewhere). > New build passed just fine. So I'd say this is some strange > infrastructure issue. > > > Vít > > > Dne 21. 01. 21 v 10:47 Martin Gansser napsal(a): > > Hi, > > > > the koji build for vdr-live fails on s390x arch with the following error > > message: > > > > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > Recommends: vdr-live-debugsource(s390-64) = 3.0.1-1.fc34 > > Checking for unpackaged file(s): /usr/lib/rpm/check-files > > /builddir/build/BUILDROOT/vdr-live-3.0.1-1.fc34.s390x > > Child return code was: -11 > > EXCEPTION: [Error()] > > Traceback (most recent call last): > >File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", > >line 93, in trace > > result = func(*args, **kw) > >File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in > >do_with_status > > raise exception.Error("Command failed: \n # %s\n%s" % (command, > > output), child.returncode) > > mockbuild.exception.Error: Command failed: > > # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps > > /builddir/build/SPECS/vdr-live.spec > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=60131536 > > > > How can I solve this ? > > > > Regards > > Martin > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Jan Zerdik
- Original Message - > > > Le 1/13/21 à 4:25 PM, Jan Zerdik a écrit : > > Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-maintainer. > > My experience with open source projects is mostly just as a user, but I'm > > looking forward to joining the community. > > > > ___ > > 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 > > > > Hi Jan, > > Welcome and I wish you the best around here. > > Frédéric > > Welcome Jan and enjoy Jaroslav ___ 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 Mass Rebuild
- Original Message - > On Mon, Aug 03, 2020 at 01:30:56PM -0400, Jaroslav Skarvada wrote: > > > > Most of my FTBFSs are in form: > > BuildrootError: Requested repo (1785390) is DELETED > > > > Wtf? > > > > E.g.: > > https://bugzilla.redhat.com/show_bug.cgi?id=1863168 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863196 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863197 > > https://bugzilla.redhat.com/show_bug.cgi?id=1863273 > > > > Jaroslav > > This error is from the very beginning of the mass rebuild (more than a > week ago now). I had kojira deleting repos that were expired for more > than 5min. But of course the f33 repo regenerates all the time so it was > not sufficent for the builds when they got around to building, that repo > was gone. > > However, the fails to build from source bug filing script is mistakenly > adding the first rebuild failure, instead of the second one. ;( > > decathorpes script should resubmit these if they are caused by transient > s390x issues. > > kevin > > ___ > 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 > It seems it is not just s390x, but also armv7hl sometimes, maybe more arches, I hadn't time to go through all of them Jaroslav ___ 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 Mass Rebuild
- Original Message - > On 8/3/2020 9:42 AM, Neal Gompa wrote: > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > wrote: > >> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > >> > >>> Most of those are the libcroco->gettext breakage, no? > >> From a very cursory scan (not at all scientific), > >> some percentage are the cmake macro changes. > > CMake macros are documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > Here's an example of how to adjust it: > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > Indeed, using this example appears to have fixed at least one of my > packages. > > > Erich Eickmeyer > Fedora Jam Maintainer > > > > ___ > 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 > Most of my FTBFSs are in form: BuildrootError: Requested repo (1785390) is DELETED Wtf? E.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1863168 https://bugzilla.redhat.com/show_bug.cgi?id=1863196 https://bugzilla.redhat.com/show_bug.cgi?id=1863197 https://bugzilla.redhat.com/show_bug.cgi?id=1863273 Jaroslav ___ 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: Outdated programs in rawhide
> pidgin: https://bugzilla.redhat.com/1856866 Hi, pidgin maintainer here. I really don't understand what are you trying to achieve by this. I am maintaining/co-maintaining over 100 packages in Fedora and if you think the reaction time for bugzillas should be less than 24 hours feel free to help me co-maintaining thanks & regards Jaroslav ___ 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 System-Wide Change proposal: Make nano the default editor
- Original Message - > > -1 for the change. If the so called 'end-user' (whatever does it mean) > > can learn git, she or he can also learn 'vi' or at least how to enable > > the preferred editor. Personally, I can see nothing special on the > > nano, for me it qualifies as very poor editor > > I feel you're completely missing the point, it's about a straight > foward to understand editor by default so they aren't scared away > before they even learn what an environment variable is, it's not about > being the best most special editor. They may well have learned how to > use git on windows or Mac before moving to Linux. I would flip this > around and say anyone who knows vim enough should know how to change > their default editor. > Yes, of course, but it will cost me time to find out where to revert the change (the right way). I just wanted to point out how absurd the arguments in the proposal are. Somebody using the complex git CLI (which was never meant to be to highlevel CLI) is usually skilled enough not to be stopped by the different default editor (especially if the editor gives hints on wrong usage). Unskilled people will usually use GUI so they do not care Jaroslav > Peter > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
- Original Message - > Jaroslav Skarvada 于2020年6月26日周五 下午9:41写道: > > > > > > > > - Original Message - > > > > > > > > > Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道: > > > > > > > > > On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: > > > > What about to provide a prompt to the user telling them the difference > > > > between editors? > > > > For example, when a new user to fedora first invokes git commit > > > > without $EDITOR set, a program named fedora-default-editor comes up > > > > and asks: Which editor do you like? > > > > User can do his or hers choice and the choice will be remembered by > > > > setting $EDITOR in his or hers ~/.bashrc > > > > > > > > The fedora-default-editor can be a small script that shows user all > > > > the difference and set $EDITOR for the user. > > > > > > It's a nice idea, but the problem with things like this is they > > > *always* introduce bugs, and often wind up being unmaintained, because > > > keeping them working is kind of a thankless task. > > > > > > IMHO it's better to keep things simple and just pick a default. And the > > > default should definitely be nano. :D > > > Then I will +1 for this proposal. Yes, this certainly will make Fedora > > > easier > > > use for beginners. And for those who would like to use vi as default, we > > > should make this as easy as possible. > > > > > > I has been asked "how to exit this hell?" multiple times by my > > > new-to-Linux > > > friends, that time I would always suggest them to set nano as default. > > > Vim > > > is great though, it is not for beginners. > > > > > Why not just patch vim-minimal to show the hint on the CTRL+C? > > Problem solved :) > Ctrl + C in vi will give you a > Type :qa and press to exit Vim > > Thanks for info, I didn't know :) So I can't see any problem there and it's just about the personal preference thanks & regards Jaroslav ___ 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 System-Wide Change proposal: Make nano the default editor
- Original Message - > > > Adam Williamson < adamw...@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道: > > > On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: > > What about to provide a prompt to the user telling them the difference > > between editors? > > For example, when a new user to fedora first invokes git commit > > without $EDITOR set, a program named fedora-default-editor comes up > > and asks: Which editor do you like? > > User can do his or hers choice and the choice will be remembered by > > setting $EDITOR in his or hers ~/.bashrc > > > > The fedora-default-editor can be a small script that shows user all > > the difference and set $EDITOR for the user. > > It's a nice idea, but the problem with things like this is they > *always* introduce bugs, and often wind up being unmaintained, because > keeping them working is kind of a thankless task. > > IMHO it's better to keep things simple and just pick a default. And the > default should definitely be nano. :D > Then I will +1 for this proposal. Yes, this certainly will make Fedora easier > use for beginners. And for those who would like to use vi as default, we > should make this as easy as possible. > > I has been asked "how to exit this hell?" multiple times by my new-to-Linux > friends, that time I would always suggest them to set nano as default. Vim > is great though, it is not for beginners. > Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :) Jaroslav ___ 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 System-Wide Change proposal: Make nano the default editor
- Original Message - > El jue., 25 jun. 2020 a las 21:45, Qiyu Yan (< yanq...@fedoraproject.org >) > escribió: > > > What about to provide a prompt to the user telling them the difference > between editors? > For example, when a new user to fedora first invokes git commit > without $EDITOR set, a program named fedora-default-editor comes up > and asks: Which editor do you like? > User can do his or hers choice and the choice will be remembered by > setting $EDITOR in his or hers ~/.bashrc > > The fedora-default-editor can be a small script that shows user all > the difference and set $EDITOR for the user. > ___ > 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 > > Well, I strongy disagree whit this move. > In fact on of the things that I hate of Debian/Ubuntu is the choice of nano > and the poor version that they offer by default of vi. > More friendly for end-users? Really? > Please thinking so, the end-user use GUI's. Nano has no any significative > advantage over vi and even lesser over vim. What's the wrong with vim? > Really I don't understand. > If one end-user wants to use a text editor, he will find kate, gedit and the > like better options. If you don't like a modal editor, propose a better > option not a mediocre one. For example, micro is a non-modal editor but more > powerful that nano. > If has no real benefit, please could you reconsider it and let the community > give his voice? > Thanks in advance. > SB > -- > -- > Sergio Belkin > LPIC-2 Certified - http://www.lpi.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 > -1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor thanks & regards Jaroslav ___ 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: protobuf update coming to rawhide
- Original Message - > I prepared a protobuf update for rawhide to 3.12. It requires a rebuild > of all dependencies and of the 55 dependencies currently 10 fail to > rebuild. The following packages are failing: > > clementine > closure-compiler > fawkes > gazebo > hidviz > kismet > libgadu > mir > mozc > pokerth > > and the failures do not seem to be protobuf related. See > > https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-12/ > > I requested a side-tag to do the rebuilds. > > Adrian > Please try to rebuild with hidviz-0.1.5-5.fc33 thanks & regards Jaroslav ___ 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: Many packages unnecessarily link to libpython
> jskarvad gnuradio gr-air-modes gr-fcdproplus gr-hpsdr gr-iqbal gr-osmosdr > gr-rds hamlib pidgin pidgin - it calls Py_Initialize, so I kept is as is hamlib - fixed & forwarded upstream gnuradio stuff - it doesn't seem it calls Py_Initialize, but linking without -python failed: /usr/bin/ld: ../../lib/libgnuradio-qtgui.so.3.8.1.0: undefined reference to `Py_BuildValue' /usr/bin/ld: ../../lib/libgnuradio-qtgui.so.3.8.1.0: undefined reference to `PyLong_FromVoidPtr' so I kept is as is thanks & regards Jaroslav ___ 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: fedrepo-req is complaining about cookies
- Original Message - > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Thu, 2017-09-14 at 13:18 -0400, Jaroslav Skarvada wrote: > > Hi, > Hi, > > > > I am trying to add new package to fedora, I did: > > > > $ fedrepo-req wsjtx -t 1487776 -m monitoring > > Error: The Bugzilla ticket could not be verified. The following error > > was encountered: > valid or have expired. You may login again to get new cookies or a > > new token.'> > > > > My token was valid, but I requested new one and it still doesn't > > work. > > fedrepo-req-1.6.0-3.fc25.noarch > > > > Also tried to logout and re-login to Pagure in my browser, but it > > still doesn't work > I think you need to login to bugzilla.redhat.com.. > > I was logged in, maybe I could try logging off and on again next time I will use the tool thanks & regards Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedrepo-req is complaining about cookies
- Original Message - > Hi, > > I am trying to add new package to fedora, I did: > > $ fedrepo-req wsjtx -t 1487776 -m monitoring > Error: The Bugzilla ticket could not be verified. The following error was > encountered: have expired. You may login again to get new cookies or a new token.'> > > My token was valid, but I requested new one and it still doesn't work. > fedrepo-req-1.6.0-3.fc25.noarch > > Also tried to logout and re-login to Pagure in my browser, but it still > doesn't work > > thanks & regards > > Jaroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I finally created the request by hand [1], which is not optimal thanks & regards Jaroslav [1] https://pagure.io/dist-git-requests/issue/91 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
fedrepo-req is complaining about cookies
Hi, I am trying to add new package to fedora, I did: $ fedrepo-req wsjtx -t 1487776 -m monitoring Error: The Bugzilla ticket could not be verified. The following error was encountered: My token was valid, but I requested new one and it still doesn't work. fedrepo-req-1.6.0-3.fc25.noarch Also tried to logout and re-login to Pagure in my browser, but it still doesn't work thanks & regards Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: How to request new branch?
- Original Message - > On Mon, Aug 14, 2017 at 06:16:20PM -0400, Jaroslav Skarvada wrote: > > According to the fedrepo doc linked from [1] I did: > > > > $ fedrepo-req-branch preeny f26 > > > > And the ticket [2] was closed with a message: > > > > "The branch in PDC was created. You may now create the branch in Pagure > > using git." > > > > I did: > > > > $ git checkout -b f26 > > Switched to a new branch 'f26' > > $ git push -u origin f26 > > Total 0 (delta 0), reused 0 (delta 0) > > remote: FATAL: C refs/heads/f26 rpms/preeny jskarvad DENIED by > > refs/heads/f[0-9][0-9] > > remote: error: hook declined to update refs/heads/f26 > > To ssh://pkgs.fedoraproject.org/rpms/preeny > > ! [remote rejected] f26 -> f26 (hook declined) > > error: failed to push some refs to > > 'ssh://jskar...@pkgs.fedoraproject.org/rpms/preeny' > > FTR, this has been fixed, we're working on a fix to stop doing this manually > :) > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Thanks for info, I successfully created the branch, but it still doesn't build [1]: BuildError: package preeny not in list for tag f26-updates-candidate thanks & regards Jaroslav [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=21268720 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
How to request new branch?
According to the fedrepo doc linked from [1] I did: $ fedrepo-req-branch preeny f26 And the ticket [2] was closed with a message: "The branch in PDC was created. You may now create the branch in Pagure using git." I did: $ git checkout -b f26 Switched to a new branch 'f26' $ git push -u origin f26 Total 0 (delta 0), reused 0 (delta 0) remote: FATAL: C refs/heads/f26 rpms/preeny jskarvad DENIED by refs/heads/f[0-9][0-9] remote: error: hook declined to update refs/heads/f26 To ssh://pkgs.fedoraproject.org/rpms/preeny ! [remote rejected] f26 -> f26 (hook declined) error: failed to push some refs to 'ssh://jskar...@pkgs.fedoraproject.org/rpms/preeny' Am I missing something? thanks & regards Jaroslav [1] https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_request_a_new_package_or_a_new_branch [2] https://pagure.io/releng/fedora-scm-requests/issue/33 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
How to change upstream release monitoring in pagure?
How to change upstream release monitoring, i.e. how to switch the states between disabled, monitoring, and monitoring with build? I didn't find anything related in [1], so I tried: $ fedrepo-req preeny -m monitoring -t 1479022 But the request [2] was closed as invalid? What's the correct procedure for it? thanks & regards Jaroslav [1] https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb [2] https://pagure.io/releng/fedora-scm-requests/issue/36 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: pagure-over-dist-git: traceback in receive-hook when pushing to new repo
- Original Message - > On Fri, Aug 11, 2017 at 04:55:34AM -0400, Jaroslav Skarvada wrote: > > > > I see the following when pushing to new repo: > > > > $ fedpkg push > > /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: > > DeprecationWarning: fedora.client.bodhi has been deprecated. Please use > > bodhi.client.bindings instead. > > DeprecationWarning) > > Counting objects: 5, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (4/4), done. > > Writing objects: 100% (5/5), 1.11 KiB | 0 bytes/s, done. > > Total 5 (delta 0), reused 0 (delta 0) > > remote: error: insufficient permission for adding an object to repository > > database ./objects > > remote: fatal: failed to write object > > error: unpack failed: unpack-objects abnormal exit > > To ssh://pkgs.fedoraproject.org/rpms/preeny > > ! [remote rejected] master -> master (unpacker error) > > error: failed to push some refs to > > 'ssh://jskar...@pkgs.fedoraproject.org/rpms/preeny' > > Could not execute push: Command '['git', 'push']' returned non-zero exit > > status 1 > > > > Is it known or related? Or is it different issue? It's more than 12 hours > > the repo > > was created. I also reopened [1] > > I do not think this is related and it looks a little different. > > Is it still occurring? > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Yes, I still cannot push to preeny repo. The push still ends with the above mentioned error. I am trying to push to f27, it's the first push to newly created repo. SSH works: ssh -T jskar...@pkgs.fedoraproject.org hello jskarvad, this is jskarvad@pkgs02 running gitolite3 3.6.7-1.el7 on git 1.8.3.1 but the ACLs seems wrong for me: $ git push Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (5/5), 1.11 KiB | 0 bytes/s, done. Total 5 (delta 0), reused 0 (delta 0) remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://pkgs.fedoraproject.org/rpms/preeny ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to 'ssh://jskar...@pkgs.fedoraproject.org/rpms/preeny' Could you fix it? I opened [1] thanks & regards Jaroslav [1] https://pagure.io/fedora-infrastructure/issue/6248 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: pagure-over-dist-git: traceback in receive-hook when pushing to new repo
- Original Message - > On 08/10/2017 03:01 PM, Fabio Valentini wrote: > > I've just pushed an import commit to my first repository that was created > > with fedrepo_req on pagure, and I got the following traceback from the > > remote when it obviously failed to run a post-receive hook: > > > > remote: Traceback (most recent call last): > > remote: File "./hooks/post-receive.default", line 19, in > > remote: import pagure # noqa: E402 > > remote: File "/usr/lib/python2.7/site-packages/pagure/__init__.py", line > > 60, in > > remote: APP.config.from_envvar('PAGURE_CONFIG') > > remote: File "/usr/lib/python2.7/site-packages/flask/config.py", line > > 108, in from_envvar > > remote: return self.from_pyfile(rv, silent=silent) > > remote: File "/usr/lib/python2.7/site-packages/flask/config.py", line > > 128, in from_pyfile > > remote: with open(filename) as config_file: > > remote: IOError: [Errno 13] Unable to load configuration file (Permission > > denied): '/etc/pagure/pagure.cfg' > > remote: Hook ./hooks/post-receive.default failed with error code 1 > > > > My commit shows up fine in the web GUI. > > Should I be worried about this? Is anybody else seeing this error? > > No need to worry and this is tracked in > https://pagure.io/fedora-infrastructure/issue/6235 > > kevin > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I see the following when pushing to new repo: $ fedpkg push /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: DeprecationWarning: fedora.client.bodhi has been deprecated. Please use bodhi.client.bindings instead. DeprecationWarning) Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (5/5), 1.11 KiB | 0 bytes/s, done. Total 5 (delta 0), reused 0 (delta 0) remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://pkgs.fedoraproject.org/rpms/preeny ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to 'ssh://jskar...@pkgs.fedoraproject.org/rpms/preeny' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Is it known or related? Or is it different issue? It's more than 12 hours the repo was created. I also reopened [1] thanks & regards Jaroslav [1] https://pagure.io/dist-git-requests/issue/67 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is there something wrong with the Koji builders?
- Original Message - > I've done two builds for rawhide this morning. > > On the first the armv7hl and ppc64le builds failed because the source > tar file could not be unpacked. > > On the second the aarch64 build failed because the source tar file could > not be unpacked. > > All the other arches built successfully. > > -- > > Kaleb > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I am encountering the same problem even on i686 (when trying to scratch build graphviz [1, 2]), so there is probably something wrong with the builders thanks & regards Jaroslav [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=17302165 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=17302557 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
- Original Message - > > > - Original Message - > > Hi, > > > > Jaroslav wrote: > > > It still doesn't work for me: > > > > > > $ fedpkg scratch-build > > > Could not execute scratch_build: (-1765328370, 'KDC has no support for > > > encryption > > > type') > > > > > > $ klist > > > Default principal: jskarvad(a)FEDORAPROJECT.ORG > > > > > > Valid starting Expires Service principal > > > 12.12.2016 10:21:53 13.12.2016 10:21:48 > > > krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG > > > renew until 19.12.2016 10:21:48 > > > > > > fedora-cert.noarch 0.6.0.0-1.fc24fedora-packager.noarch > > > 0.6.0.0-1.fc24 > > > fedpkg.noarch 1.26-2.fc24koji.noarch 1.11.0-1.fc24 > > > pyrpkg.noarch 1.47-3.fc24python2-cccolutils.x86_64 > > > 1.4-1.fc24 > > > > > > Not counting that the packages are available only through > > > updates-testing > > > in f24 > > > > I was getting the same error, I managed to fix it by creating a: > > > > /etc/krb5.conf.d/redhat_com > > > > With the following: > > > > [realms] > > REDHAT.COM = { > >kdc = $redhat_kdc > >admin_server = $redhat_admin_server > >default_domain = redhat.com > > } > > > > [domain_realm] > > .redhat.com = REDHAT.COM > > redhat.com = REDHAT.COM > > > > In there, with $redhat_kdc / $redhat_admin_server replaced with what > > you've for these in your krb5.conf now. > > > > And then replacing /etc/krb5.conf with the default one from the krb5-libs > > package. After this you will need to redo kinit for both accounts, but then > > it works. > > > > Regards, > > > > Hans > > Hi Hans, > > thanks for info, but it didn't help. Still the same error, even after > removing /etc/krb5.conf.d/redhat_com > > Jaroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I had custom ~/.k5identity, problem resolved by upgrade to pyrpkg-1.47-4.fc24.noarch thanks & regards Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
- Original Message - > Mike McLeanwrote: > > > 1) make sure your krb5.conf has: > > includedir /etc/krb5.conf.d/ > > Should there be something in there other than a crypto-policies symlink? > > David > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Yes, it's there, I got the ticket OK, it's fedpkg which is failing for me, the following: $ koji build --scratch f26 $(fedpkg giturl) works, but: $ fedpkg scratch-build doesn't. I commented to: https://pagure.io/fedora-infrastructure/issue/5614 Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
- Original Message - > Hi, > > Jaroslav wrote: > > It still doesn't work for me: > > > > $ fedpkg scratch-build > > Could not execute scratch_build: (-1765328370, 'KDC has no support for > > encryption > > type') > > > > $ klist > > Default principal: jskarvad(a)FEDORAPROJECT.ORG > > > > Valid starting Expires Service principal > > 12.12.2016 10:21:53 13.12.2016 10:21:48 > > krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG > >renew until 19.12.2016 10:21:48 > > > > fedora-cert.noarch 0.6.0.0-1.fc24fedora-packager.noarch 0.6.0.0-1.fc24 > > fedpkg.noarch 1.26-2.fc24koji.noarch 1.11.0-1.fc24 > > pyrpkg.noarch 1.47-3.fc24python2-cccolutils.x86_64 1.4-1.fc24 > > > > Not counting that the packages are available only through updates-testing > > in f24 > > I was getting the same error, I managed to fix it by creating a: > > /etc/krb5.conf.d/redhat_com > > With the following: > > [realms] > REDHAT.COM = { >kdc = $redhat_kdc >admin_server = $redhat_admin_server >default_domain = redhat.com > } > > [domain_realm] > .redhat.com = REDHAT.COM > redhat.com = REDHAT.COM > > In there, with $redhat_kdc / $redhat_admin_server replaced with what > you've for these in your krb5.conf now. > > And then replacing /etc/krb5.conf with the default one from the krb5-libs > package. After this you will need to redo kinit for both accounts, but then > it works. > > Regards, > > Hans Hi Hans, thanks for info, but it didn't help. Still the same error, even after removing /etc/krb5.conf.d/redhat_com Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
- Original Message - > Greetings. > > As previously announced, releng has made a number of changes as part of > it's 2016 "flag day". > > All package maintainers will want to make sure they have updated to > the > following package versions (some may be in testing as of this email): > > python-cccolutils-1.4-1 > fedpkg-1.26-2 > fedora-packager-0.6.0.0-1 > pyrpkg-1.47-3 > koji-1.11.0-1 > > Please also see the following links for up to date information: > > https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 > > The following changes were made: > > * koji and the source lookaside were changed to use kerberos > authentication > instead of ssl certificates. All maintainers will need to: > > kinit your-fas-accountn...@fedoraaproject.org > > to get a valid kerberos TGT and be able to authenticate to koji and > the lookaside upload cgi. > > See the general kerberos information at: > https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication > for more details. > > Additionally, via GSSAPI many browsers allow you to seamlessly login > to any of our ipsilon using applications simply by clicking on the > login > button ( bodhi, fedorahosted trac, elections, fedocal, mailman3, etc) > > * koji now uses a well known cert for https. > > * pkgs.fedoraproject.org now redirects to https://src.fedoraproject.org > and > that uses a well known cert. Please correct any links you use to use > https://src.fedoraproject.org for packages spec and patch files. > > * rawhide builds now land in the f26-pending tag, where they are signed > and then > added to the f26 tag for compose in the next rawhide compose. This > allows > rawhide packages to be fully signed as well as a point where automated > QA > can take place in the future. > > * packages "sources" files now use sha512 by default instead of md5. > You will need the fedpkg update in order to create and use these new > checksums. > > Questions or concerns as always welcome at #fedora-admin on > irc.freenode.net > or tickets at https://pagure.io/fedora-infrastructure. > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > It still doesn't work for me: $ fedpkg scratch-build Could not execute scratch_build: (-1765328370, 'KDC has no support for encryption type') $ klist Default principal: jskar...@fedoraproject.org Valid starting Expires Service principal 12.12.2016 10:21:53 13.12.2016 10:21:48 krbtgt/fedoraproject@fedoraproject.org renew until 19.12.2016 10:21:48 fedora-cert.noarch 0.6.0.0-1.fc24fedora-packager.noarch 0.6.0.0-1.fc24 fedpkg.noarch 1.26-2.fc24koji.noarch 1.11.0-1.fc24 pyrpkg.noarch 1.47-3.fc24python2-cccolutils.x86_64 1.4-1.fc24 Not counting that the packages are available only through updates-testing in f24 thanks & regards Jaroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 3D printing SIG
- Original Message - > Hi Fedorains, > > I was thinking about creating a 3D printing SIG in Fedora. Would anyone > be interested in that? > > Miro > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > +1 and please add me as member :) J. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
- Original Message - > > > - Original Message - > > On Fri, 8 Jan 2016 11:12:37 -0500 (EST) > > Jaroslav Skarvada <jskar...@redhat.com> wrote: > > > > > $ git push -v > > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > > > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > > > FATAL: W any memtest86+ jskarvad DENIED by fallthru > > > (or you mis-spelled the reponame) > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > > > Apparently I have the correct rights: > > > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > > > > > Any idea what's wrong? > > > > Odd. The rights look correct also in gitolite. ;( > > > > At least right now. Can you try pushing again and confirm it's still > > broken? > > > > kevin > > > Hi Kevin, it's still broken for me. I tried to do fresh checkout (this time > with pure git, no fedpkg front-end): > > $ git clone 'ssh://jskar...@pkgs.fedoraproject.org/memtest86+' > Cloning into 'memtest86+'... > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > remote: Counting objects: 573, done. > remote: Compressing objects: 100% (342/342), done. > remote: Total 573 (delta 275), reused 458 (delta 207) > Receiving objects: 100% (573/573), 241.70 KiB | 0 bytes/s, done. > Resolving deltas: 100% (275/275), done. > Checking connectivity... done. > > Then I updated SPEC file and tried to push the changes: > > $ git push > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > FATAL: W any memtest86+ jskarvad DENIED by fallthru > (or you mis-spelled the reponame) > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > I tried to push into 'grep/master' and it worked. So It seems that only > the memtest86+ is broken for me. It is really weird as I am proven packager > so it shouldn't complain about ACLs > > thanks & regards > > Jaroslav > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Created ticket: https://fedorahosted.org/fedora-infrastructure/ticket/5058 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unable to push into memtest86+/master
- Original Message - > On Fri, 8 Jan 2016 11:12:37 -0500 (EST) > Jaroslav Skarvada <jskar...@redhat.com> wrote: > > > $ git push -v > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ > > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' > > FATAL: W any memtest86+ jskarvad DENIED by fallthru > > (or you mis-spelled the reponame) > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > > > Apparently I have the correct rights: > > https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ > > > > Any idea what's wrong? > > Odd. The rights look correct also in gitolite. ;( > > At least right now. Can you try pushing again and confirm it's still > broken? > > kevin > Hi Kevin, it's still broken for me. I tried to do fresh checkout (this time with pure git, no fedpkg front-end): $ git clone 'ssh://jskar...@pkgs.fedoraproject.org/memtest86+' Cloning into 'memtest86+'... WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' remote: Counting objects: 573, done. remote: Compressing objects: 100% (342/342), done. remote: Total 573 (delta 275), reused 458 (delta 207) Receiving objects: 100% (573/573), 241.70 KiB | 0 bytes/s, done. Resolving deltas: 100% (275/275), done. Checking connectivity... done. Then I updated SPEC file and tried to push the changes: $ git push WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' FATAL: W any memtest86+ jskarvad DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I tried to push into 'grep/master' and it worked. So It seems that only the memtest86+ is broken for me. It is really weird as I am proven packager so it shouldn't complain about ACLs thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unable to push into memtest86+/master
$ git push -v Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+ WARNING: 'memtest86+' is an alias for 'rpms/memtest86+' FATAL: W any memtest86+ jskarvad DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Apparently I have the correct rights: https://admin.fedoraproject.org/pkgdb/package/rpms/memtest86+/ Any idea what's wrong? thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
pkgdb branches requests
Hi, I received mail that EPEL-7 branch was requested for PowerTOP in [1]. Is there any way how to cancel (or at least comment) such requests? Because this request is apparently invalid, PowerTOP is already included in RHEL-7 thanks & regards Jaroslav [1] https://admin.fedoraproject.org/pkgdb/package/powertop/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dealing with rolling release versioning
- Original Message - > On Mon, Nov 30, 2015 at 11:58 AM, Till Maas < opensou...@till.name > wrote: > > > On Mo, Nov 30, 2015 at 11:28:57 -0600, Richard Shaw wrote: > > > Is there any reason not to use the date as the version? It's in MMDD > > format so there shouldn't be a upgrade path issue but this isn't explicitly > > covered in the packaging guidelines that I can find. > > If you make it as a post release from the latest regular release, you > can easily adjust if they go back to normal releases without requiring > an epoch. > > I agree that would work, but staying canonical with upstream, if they ask, > "What version are you using?", 0.4.1 is not the correct answer. I think it > would be different if I was doing actual checkouts but they provide archives > which include the date. > > Thanks, > Richard > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org Hi, they now use 'daily-MMDD' as the version, it is even shown in the about dialog. They provide daily builds. It doesn't seem they are going to change this release model in the near future (but I will recheck with them). Personally I would go with MMDD as the version. Anytime later, if the release model change, we will be able to add epoch and use different numbering. Just my two cents thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
- Original Message - On 01.04.2015 10:29, Jaroslav Skarvada wrote: pm-hibernate is obsolete as others already mentioned. Do the pm-utils maintainers/upstream know this? Hi, I am pm-utils maintainer. I own some other legacy packages and I am retiring them only if there are good reasons for it (e.g. unfixed security bugs, breakage, etc.), because there may be still users using such packages / depending on their functionality. Regarding pm-utils, most of the functionality is currently handled by systemd. If there is anybody still using it, I think it shouldn't be hard to migrate. Also I think this package may be quite confusing for newcomers. Upstream said it's dead, so there are probably good reasons to retire. But currently there are the following packages in rawhide depending on pm-utils: cdm kdebase3 Same as with the 'cdm'. http://pkgs.fedoraproject.org/cgit/kdebase3.git/commit/?id=2221c4 + kdebase3.spec Patch26: kdebase-3.5.5-suspend.patch %define _with_suspend 1 %{?_with_suspend:%patch26 -p1 -b .suspend} --- kdebase-3.5.5-suspend.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kdebase-3.5.5-suspend.patch b/kdebase-3.5.5-suspend.patch index 0462543..e1a5d0a 100644 --- a/kdebase-3.5.5-suspend.patch +++ b/kdebase-3.5.5-suspend.patch @@ -62,8 +62,8 @@ +void KSMShutdownDlg::slotSuspend() +{ +switch ( suspendType ) { -+ case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/pm-hibernate); break; -+ case SUSPEND_TYPE_STANDBY: system(/usr/bin/pm-suspend); break; ++ case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/systemctl hibernate); break; ++ case SUSPEND_TYPE_STANDBY: system(/usr/bin/systemctl suspend); break; +} +reject(); +} ... I will drop pm-utils when resolved regards Jaroslav And that's it. - cdm DONE - kdebase3 DONE - wicd DONE - pm-utils DONE Thanks, retired in master regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
pm-hibernate is obsolete as others already mentioned. Do the pm-utils maintainers/upstream know this? Hi, I am pm-utils maintainer. I own some other legacy packages and I am retiring them only if there are good reasons for it (e.g. unfixed security bugs, breakage, etc.), because there may be still users using such packages / depending on their functionality. Regarding pm-utils, most of the functionality is currently handled by systemd. If there is anybody still using it, I think it shouldn't be hard to migrate. Also I think this package may be quite confusing for newcomers. Upstream said it's dead, so there are probably good reasons to retire. But currently there are the following packages in rawhide depending on pm-utils: cdm kdebase3 wicd I will drop pm-utils when resolved regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Postfix - switching to dynamically loaded database plugins
Hi, dynamically loaded database plugins has been supported in Debian by downstream patch for a while. This patch went finally upstream, so I am also introducing this feature in Fedora Rawhide (f23). Previously, all database map support libraries were linked to the Postfix binary, which required careful downstream selection of what libraries to support and link. For users there was no way how to remove the unneeded dependencies from the Postfix package (not counting recompilation). With the recent Postfix change (since postfix-3.0.0-4.fc23), users can choose database maps they want by simply installing appropriate Postfix subpackage(s). This also allows us to support more types of database maps without adding additional dependencies to the Postfix base package. The following Postfix subpackages were introduced in Rawhide: postfix-cdb postfix-ldap postfix-mysql postfix-pcre postfix-pgsql postfix-sqlite For users upgrading Postfix package in Rawhide it effectively means that they need to install subpackages for all database maps they use. E.g. if they use MySQL and LDAP maps, they need to install postfix-mysql and postfix-ldap subpackages in addition to the base Postfix package, otherwise their postfix setup will not work correctly. I will probably propose f23 Change for this feature later thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Power consumption with Fedora
- Original Message - - Original Message - On Tue, 02 Dec 2014 14:44:59 -0700 Nathanael D. Noblet nathan...@gnat.ca wrote: On Tue, 2014-12-02 at 21:47 +0100, Jan Kratochvil wrote: On Tue, 02 Dec 2014 06:30:57 +0100, Nathanael d. Noblet wrote: I don't know much about it but I hate how bad my battery life is on my laptop... My 3 years old Lenovo X220 lasts for 12 hours (powertop reports so) on Fedora 20 x86_64 with powertop --auto-tune. According to powertop approx. 5.5W is display backlight and 1W is the rest of system. Just to give a reply that Fedora is not bad on all configs/hardware. Well until yesterday I didn't know that Fedora didn't install / configure any of these packages. I've installed tlp and powertop, I didn't know powertop did anything other than monitor. I'll see what powertop --auto-tune does. I don't even know if the tlp package has enabled anything either. I wonder if having tlp installed and running powertop --auto-tune will conflict / fight each other... Time to try stuff out. You might also look at tuned... (I think it was mentioned early in the thread). tuned-adm profile powersave I've probably said this before, but I wouldn't trust tuned one bit, after I was told that 1) no measurements were ever taken Well, it's not easy to objectively measure this, results depends heavily on HW, SW, configuration used and things like moon phase - today's HW manage a lot of on its own in FW by utilizing factory algorithms/optimizations, but attempts were made to evaluate efficiency of the powersave profile regularly accross different HW: http://fedoraproject.org/wiki/Test_Day:2013-11-14_Power_management#Basic_2 http://fedoraproject.org/wiki/Test_Day:2013-04-17_Power_Management#Basic_2 http://fedoraproject.org/wiki/Test_Day:2012-10-11_Power_Management#Test_Results http://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management#Test_Results https://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement#Test_Results These numbers are not bad at all. The powersave profile is targeted for lowest power consumption. I.e. it throttle down your machine - it sets most of the kernel knobs to powersave policy. This can increase you online time if your machine is mostly idle, but it will also increase latency and lowers throughput, so generally balanced profile is better choice for laptop. Patches are welcome, so feel free to do your our measurements/ experiments/scientific research or whatever and provide patches. 2) no attempts to make beneficial configurations the defaults were made (which is probably right, given that they'd have no data to back it up). Tuned is tool/framework to ease management of tunings and also provides dbase of well known tunings. You can use it to e.g. fine tune your system for high throughput, then roll-back and re-tune for e.g. low latency. Tunings are also applied to newly added devices. You can use inheritance when constructing your own profiles for your own workloads/scenarios. Great for benchmarking, experiments, for cases when auto is simply not good enough and you know what you are doing. Currently the project is receiving mostly patches for performance tuning, but patches for other profiles are also welcome. The goal is to be non distro specific upstream. The goal isn't to press anything to distros defaults regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap
Same problem with https://kojipkgs.fedoraproject.org/ I am pretty sure it worked on Friday, Fedora 20 with latest updates, firefox-32.0.2-1.fc20.x86_64 with default configuration, nothing changed on my side, opened ticket [1] thanks regards Jaroslav [1] https://fedorahosted.org/fedora-infrastructure/ticket/4565 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
tcl/tk 8.6 update
Hi, tcl/tk 8.6.1 is in rawhide. There is f21-tcl tag for seamless handling of the update. If your package depends on tcl/tk there are two options: a) update it and build it to tag f21-tcl. E.g. the following command can be used: $ fedpkg build --target=f21-tcl b) let it on me, I will start rebuilding / fixing all affected packages tmrw. For more details see [1], [2] regards Jaroslav [1] https://fedoraproject.org/wiki/Changes/f21tcl86 [2] https://bugzilla.redhat.com/show_bug.cgi?id=889201 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Formal request: non-responsive maintainer Gavin Romig-Koch for squeak-vm
If anyone would like to take over any of these packages, please let me know. I will also take squeak-image thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 18 Power Management testday on Thursday (2012-10-11) also on-site
Hi, I'm glad to announce Power management testday, date: 2012-10-11 (Thursday), link: [1] During this event suspend/hibernate/resume, backlight control as well as tuned daemon will be tested. You can also measure compare power consumption with others. As a new F18 kernel feature suspend to both (AKA hybrid suspend) will be also tested. And there are prepared even more test cases for you. Users with laptops, desktops or even with virtual machines are also very welcome, your report will be useful even if not complete. LiveCD ISOs will be prepared for you for easy testing. As a bonus we prepared on site testday. If you are near to Brno city (Czech Republic) you can bring your HW to Red Hat Brno office [2] (second building, 4th floor - visitors room) from 13.00 to 17.00. There will be prepared live media, calibrated industry standards compliant wattmeter (Chroma 66202), serial cables for kernel oops catching and more we are looking for you testers :) thanks regards Jaroslav PM SIG [1] http://fedoraproject.org/wiki/Test_Day:2012-10-11_Power_Management [2] http://plus.google.com/104659097092746488434/about ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 PM Test day late :) recap
Hi, thanks all for attending F17 PM Test day, late :) recap follows. General results: Number of attendees: 39 Reports received: 52 Unique machines tested: 49 Bugs reported (all trackers counted): 21 Bugs closed so far: 13 Test cases (TC) results (in braces are F16 results): TC passed: 82.48 % (79 %) TC passed with warning: 3.62 % (7 %) TC failed: 13.90 % (14 %) Power consumption benchmark results (active idle test, data mostly taken from ACPI battery by provided script): Average power consumption (average from all machines): 23.36 W Average power savings with tuned enabled: 1.91 W List of bugs reported: FRD Bug 47965 - I can't modify brightness with nVidia 1000m Quadro Bug 713687 - [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 67s! [modprobe:499] in ath5k_pci_eeprom_read Bug 745202 - gnome-shell does not display correctly with NV3x adapters - multicolor corruption of panel, Shell-style menus and text [nvfx] Bug 783715 - Running bluetooth.service makes soft blocked wifi be hard blocked after resume from suspend Bug 784741 - [abrt] kernel: WARNING: at lib/list_debug.c:53 __list_del_entry+0xa1/0xd0() ( Bug 797559 - [abrt] kernel: WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xfa/0x100() Bug 807855 - Please add support for our new tuned 2.0 Bug 809294 - SELinux is preventing /usr/bin/python from using the 'signal' accesses on a process. I was running: systemctl start tuned.service Bug 809812 - No brigtness controls in gnome-control-center screen on lenovo x200 Bug 809832 - avc on tuned-adm profile powersave Bug 809836 - SELinux is preventing tuned from 'execute_no_trans' accesses on the file /usr/lib/tuned/balanced/script.sh. Bug 809837 - SELinux is preventing ls from 'getattr' accesses on the blk_file /dev/sdb. Bug 809838 - SELinux is preventing sysctl from 'getattr' accesses on the file /proc/sys/kernel/nmi_watchdog. Bug 810127 - Brightness level indicator is not shown when changing brightness Bug 810202 - [abrt] kernel: [809524.902004] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3415! Bug 810584 - Brightness and Lock window does not show settings for Brightness Bug 810616 - [HP Elitebook 8460p] Pressing Fn+Brightness control keys has no effect Bug 811018 - HP Elitebook 8560w can't suspend or hibernate Bug 813899 - [abrt] kernel: WARNING: at drivers/base/firmware_class.c:538 _request_firmware+0x488/0x4d0() Bug 813900 - [abrt] kernel: WARNING: at drivers/base/firmware_class.c:538 _request_firmware+0x488/0x4d0() Bug 813904 - SELinux is preventing /usr/libexec/gstreamer-0.10/gst-plugin-scanner from 'create' accesses on the directory .orc. 49 machines (mostly laptops) seems to be nice number to get us a little overview how good (or bad) we are doing. As you probably know we also held this event on-site in Red Hat Brno office. There was prepared meeting room with internet connection, various F17 test day live CDs/USBs, USB CD-ROMs, serial cables for catching kernel backtraces and calibrated Chroma 66202 wattmeter so attendees was able to precisely measure power consumption of their machines. We also focused on newcomers. We had there three spare laptops and newcomers without their own HW could play with Fedora there. They could also (virtually) attend test day with these machines to observe that it is really easy task (one of the goal of this event was to encourage them to attend future test days on their own). I can say that the event went well, but available capacity (space) was a bit underestimated - we did not expect such an interest :). During the event it proved that managing dozens of attendants become pain with the current test day infrastructure. For newcomers it was hard to understand how to fill results into wiki (or the concept of the wiki itself). It was even harder for remotees. Several times we received plain text reports and we had to transfer them into wiki ourself. In rush hours there were so many conflicting edits in the wiki that we had to utilize one people who worked only as a wiki corrector. I cannot imagine how to handle e.g. double number of participants with the current system. I think that some more robust and intuitive system is needed to attract/handle more participants. If designed the right way it could also simplify evaluation of results and could give answers to various queries like what HW worked on which version of Fedora. So again many thanks to all attendees and supporters and hope to see you during F18 PM test day :) thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 07/06/2012 09:55 PM, Bill Nottingham wrote: Package raptor (orphan) I have taken raptor regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
The wiki page says: By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster. Any numbers to support these claims? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest from F17 beta DVD images
- Original Message - I booted the F17 beta ISO (x86_64, if it matters) on two laptops and tried the provided memtest. In both cases it reported insane amounts of errors in test 7 after running successfully through tests 1..6. The reported error addresses are in the 120 MB area. I checked that when memtest is configured to go directly to test 7 the errors appear right away. I have not had the chance to retest with older images but the chance that both laptops independently developed RAM problems in the same area seems small. I'll do more tests and file a Bugzilla report if it checks out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It seems to be related to gcc 4.7 update: https://bugzilla.redhat.com/show_bug.cgi?id=805813 Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
espeak - portaudio drop?
Hi, there is F17 espeak bug: http://bugzilla.redhat.com/show_bug.cgi?id=799137 requesting drop of portaudio from espeak to lower the number of deps. Is anybody against? Thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provenpackager? Want to help out?
3 - we got this message on /var/log/message systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. Probably: http://bugzilla.redhat.com/show_bug.cgi?id=748171 IMHO this message should be harmless because there is inotify workaround in systemd. I thing we want read /var/run/sendmail.pid , are we missing /var ? /run is bind mounted to /var/run regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Power Management Test day (2011-09-29) Stats
Hi, thanks all who attended the Power Management Test day, the feedback was really great. Stats follows thanks regards Jaroslav P.S.: If you missed the event you can still post your results at http://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement --- Power Management Test Day Stats (2011-09-29): Submitted results: 20 Unique testers: 17 Unique machines: 19 Submitted results with valid measurement data (the test day had two parts - usual test cases and very simple measurement / benchmark): 15 Test cases available (sum for all testers): 140 Test cases finished (sum for all testers): 127 Test cases not tested (sum for all testers): 13 All testers finished in total 90.71 % of available test cases. Test cases passed: 100 (e.g. 78.74 % of finished) Test cases passed with warn: 109 (e.g. 85.83 % of finished) Test cases failed: 18 (e.g. 14.17 % of finished) That means better than 85 % success rate if warn is counted as pass. Please note the following results are are provided here only for informative purposes. The measurement method used during the test day was very simple, thus the resulting data are only very rough estimation. Power savings for laptop-battery-powersave tuned profile: Max. reported power savings: 650 mWh Min. reported power savings: -702 mWh (e.g. not savings) Average power savings for all machines (stddev in braces): 138.1 (361.9) mWh Power consumption highlights: The machine that consumed the most energy: HP Pavilion dv6 Energy consumed after 15 mins in active idle (laptop-battery-powersave tuned profile): 10368 mWh The machine that consumed the least energy: EeePC Asus 1000H Energy consumed after 15 mins in active idle (laptop-battery-powersave tuned profile): 2057 mWh Bugs reported or mentioned during the test day: 5 List of bugs: Bug 637397 - [Pineview] Samsung N150 plus netbook: no brightness control Bug 719679 - Sometimes, suspend on close-lid may be the best choice for a docked laptop Bug 742061 - [abrt] kernel: WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x3b/0x41 [mac80211](): TAINTED -W Bug 742325 - SELinux is preventing /usr/libexec/colord from 'read' accesses on the file mtab. Bug 742344 - [nouveau] Resume from suspend is broken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power Management Test day (2011-09-29) Stats
- Original Message - Jaroslav Skarvada wrote: thanks all who attended the Power Management Test day, the feedback was really great. Stats follows On the topic of power management: Is there anything being done to address the regressions[1] in 2.6.38+ kernels? I cannot reproduce these numbers on our testing machine - in [1] power consumption in active idle is +- measurement error, in other tests it is mostly higher power consumption, but also higher performance. Similar for idle graph in [2]. I will try to get one of the mentioned machines and recheck. More detailed comparison of power consumption of various Fedoras is on my todo list regards Jaroslav [1] http://jskarvad.fedorapeople.org/pm-tests/ [2] http://pm-blog.yarda.eu/2011/09/power-consumption-comparison-of-firefox.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16 power management test day will start this Thursday (2011-09-29)
Fedora 16 power management test day will start this Thursday (2011-09-29). The event will be mainly focused on laptops, but even desktop machines can be tested. Everybody is welcome to attend this event and your attendance will help us to make the PM in Fedora better. Special LiveCD was prepared for this event, thus it is really easy to attend. There were created several test cases. Going through all test cases take less an hour. Just visit the PM test day WWW page http://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement and follow the on-site instructions. If you find there test cases you are not interested in (or if you don't have time to test it all), just test what you can and report the results, your feedback will be still valuable to us. thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: cpuspeed removed from f16+
- Original Message - To avoid some confusion: I removed cpuspeed from Rawhide about 10 days ago. It no longer serves any purpose in Fedora and has been effectively replaced by kernel cpufreq stack. All cpufreq modules should now be built-in, with ondemand being the default governor in Fedora. In case you would to use a different governor and/or specific frequency, try the new cpupower.service (provieded by cpupowerutils). Most people shouldn't need this, though. See https://bugzilla.redhat.com/show_bug.cgi?id=713572 for more info. Regards, -- # Petr Sabata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Sad that the daemon gone. It was able to dynamically switch speed (and save power) on systems that have CPUs with high transition latency (e.g. old P4, some Atoms, etc.). On such systems the ondemand governor cannot be used and if you want to save power you need to change the freq from userspace (of course, not too frequently). It was not the best solution, but it worked, e.g.: http://bugzilla.redhat.com/show_bug.cgi?id=697273 Is there any replacement? regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: cpuspeed removed from f16+
- Original Message - On 07/19/2011 09:59 AM, Jaroslav Skarvada wrote: - Original Message - To avoid some confusion: I removed cpuspeed from Rawhide about 10 days ago. It no longer serves any purpose in Fedora and has been effectively replaced by kernel cpufreq stack. All cpufreq modules should now be built-in, with ondemand being the default governor in Fedora. In case you would to use a different governor and/or specific frequency, try the new cpupower.service (provieded by cpupowerutils). Most people shouldn't need this, though. See https://bugzilla.redhat.com/show_bug.cgi?id=713572 for more info. Regards, -- # Petr Sabata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Sad that the daemon gone. It was able to dynamically switch speed (and save power) on systems that have CPUs with high transition latency (e.g. old P4, some Atoms, etc.). On such systems the Actually, no... http://codemonkey.org.uk/2009/01/18/forthcoming-p4clockmod/ So the 1.00GHz ‘frequency’ is actually “run at 2GHz, but only do work 50% of the time”. On the surface, this sounds like a good idea. The other 50%, the CPU is idle, so you’re saving power, right? Not so much. In fact, you could be burning more power. The reason for this is that when the processor is sitting there doing nothing, it isn’t lower frequency, and more importantly, it very likely isn’t entering C states. So you’re burning the same amount of power, but now you’re only doing work for 50% of the time. As a result of this, your workload takes twice as long to complete. I've measured it, and Dave is right. You might get something saying 1.0Ghz but you're not saving anything at all. -Eric It is heating less, but you are not saving power? Sorry, but I cannot understand. The more energy consumed for the same computational load is another story Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: cpuspeed removed from f16+
- Original Message - On 07/19/2011 10:23 AM, Przemek Klosowski wrote: On 07/19/2011 11:07 AM, Eric Sandeen wrote: On 07/19/2011 09:59 AM, Jaroslav Skarvada wrote: Sad that the daemon gone. It was able to dynamically switch speed (and save power) on systems that have CPUs with high transition latency (e.g. old P4, some Atoms, etc.). On such systems the Actually, no... http://codemonkey.org.uk/2009/01/18/forthcoming-p4clockmod/ So the 1.00GHz ‘frequency’ is actually “run at 2GHz, but only do work 50% of the time”. On the surface, this sounds like a good idea. The other 50%, the CPU is idle, so you’re saving power, right? Not so much. In fact, you could be burning more power. The reason for this is that when the processor is sitting there doing nothing, it isn’t lower frequency, and more importantly, it very likely isn’t entering C states. So you’re burning the same amount of power, but now you’re only doing work for 50% of the time. As a result of this, your workload takes twice as long to complete. I've measured it, and Dave is right. You might get something saying 1.0Ghz but you're not saving anything at all. There are second-order effects---the processor probably doesn't use significantly less power but the graphic card and chipset do, for some overall system effects---people quoted numbers like 20% battery savings for 50% slowdown (if p4_clockmod really stopped the CPU 50% of the time, it'd double the battery life, so this really is a very inefficient and crude method). I would suggest getting a wattmeter and measuring it... probably the simplest way to know for sure. I'm pretty sure I measured it directly with a kill-a-watt meter, but I no longer have a P4, so can't retest. -Eric -- Well, I can do it (just for curiosity). But this was not only about P4. Anything with transition latency over 10ms is rejected by ondemand governor (and it should be so) Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: cpuspeed removed from f16+
I would suggest getting a wattmeter and measuring it... probably the simplest way to know for sure. I'm pretty sure I measured it directly with a kill-a-watt meter, but I no longer have a P4, so can't retest. -Eric -- Measured P4 on default F15 install. In active idle the overall power consumption was in average 65W on full speed. On the lowest speed (userspace governor) it lowers about 0.3-0.5W in average. So for P4 the cpufreq is really non-sense regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Hi, if no other is interested, I can provide new home for these: espeak libax25 demorse linpsk LinLog regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest86+
- Original Message - On 06/01/2011 09:59 PM, Genes MailLists wrote: Best I can tell the current version of memtest86+ in Fedora is v4.10 which is too old for Sandy Bridge which needs version v4.20. Anyone know if there is some reason we haven't updated to the current version (released January 2011) ? This also means anyone using the memtest86+ from install (F15 or F14) will not be able to run it if they have Sandy Bridge - it just hangs. Probably worth noting that in the wiki somewhere too .. -- 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please file a bug next time thanks regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
License change for graphviz
The graphviz license changed to EPL (from CPL) since graphviz-2.28 (rawhide) Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug a broken suspend/hibernate ?
- Original Message - Under Fedora 14, my computer, an Asus U31J, cannot suspend/hibernate. It attempts both, but hangs and has to be hard powered off. (I have only tried F14.) How do you debug something like this? I guess I'd need to have some tracing through the shutdown sequence to understand where it stops. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel In case you used the pm-utils, consult the logs: /var/log/pm-powersave.log /var/log/pm-suspend.log There is also script that can present you interesting information: # pm-utils-bugreport-info.sh something useful can be also found in syslog: /var/log/messages Test suspend from runlevels 3, 5 by: # pm-suspend and also directly through sys interface: # echo mem /sys/power/state If the last one fails from runlevel 3 it is probably the kernel and it will require more advanced debugging. Please file bug about it. And also please try the F15, there are various improvements regards Jaroslav Škarvada SIG/PowerManagement -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Power Management Test Day (2011-03-24) recap
Hi, thanks all for participation in Power Management Test Day - we received great response. If you missed the event, you can still participate (all feedback is very valuable for us): http://fedoraproject.org/wiki/Test_Day:2011-03-24 PM Test Day Stats: 28 unique participants 27 unique machines 30 participants in total 260 tests were finished in total 177 tests passed 37 tests passed with warning 46 tests failed It means that: 68% of tests passed 82% of tests passed (if counting warn as pass) Bugzilla: Several bugs were filled into bugzilla during the PM Test Day (listing bugs noted on the wiki): #663993 SELinux is preventing /sbin/consoletype from 'read' accesses on the file /var/log/pm-suspend.log. #684415 SELinux is preventing /usr/sbin/wpa_supplicant from using the 'sys_module' capabilities. #684854 No tab-bar in powertop #690171 Some of tunables aren't changable back to bad #690177 tuned switch (stopping of ktune) profile problem #690194 tuned stalls when changing profiles #690476 pm-suspend does not suspend the system #690601 Acer Aspire: Power button still flashes orange after failed hibernation #691117 pm-hibernate of pm-utils deletes grub thanks Jaroslav Škarvada SIG/PowerManagement http://fedoraproject.org/wiki/SIGs/PowerManagement -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: powertop2 vs powertop
Hi, powertop 2.0 is currently in beta (aka 1.97) and was proposed and approved as feature for F15: https://fedoraproject.org/wiki/Features/PowerManagementF15 regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Power Management SIG meeting
Hi, I would like to re-introduce the Power Management (PM) SIG meetings. The PM SIG (http://fedoraproject.org/w/index.php?title=SIGs/PowerManagement) is a group of Fedora contributors that wants to improve the current state of power management and savings across the whole Fedora distribution. This starts at kernel components, goes over userland improvements up to usability and user experience on the Desktop. There are #fedora-power IRC channel (irc://irc.freenode.net/fedora-power) and power-management mailing list (https://admin.fedoraproject.org/mailman/listinfo/power-management) for discussion about the power management. I would like to start the first 2011 PM meeting on Wednesday 26. 01. at 14:00 UTC on #fedora-meeting (same schedule as previous from http://fedoraproject.org/wiki/Fedora_meeting_channel). Feel free to join us regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer - Chris Ricker
I'll approve it and orphan rrdtool. Were you going to take the EPEL branches as well? Thanks, taken all Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer - Chris Ricker
I have to second someone taking over rrdtool. I handed it off to Chris a while back, but have still done far more work on it since then than he has, and I've not seen him touch an rrdtool bz in ages. :( (And no, I don't want maintainership back.) I am ready to take it (I already own it in RHEL). I think all steps in non-responsive maintainer process have been fulfilled Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive maintainer - Chris Ricker
Hi, I was unsuccessful in all attempts to contact Chris Ricker (kaboom AT oobleck.net). He seems non-responsive for a long time, I did not receive any reply from him at least from February. Tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=554334 Previous attempt to contact through devel: http://lists.fedoraproject.org/pipermail/devel/2010-November/144873.html Personally I am interested in rrdtool (and I can take it), but there are also more packages with unresolved bugs Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning a few packages
powertop I took powertop, thanks Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does anybody know how to contact Chris Ricker?
Does anybody know how to contact Chris Ricker (kaboom AT oobleck.net)? https://bugzilla.redhat.com/show_bug.cgi?id=554334 https://bugzilla.redhat.com/show_bug.cgi?id=631825 and more Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
I plan to put up some scripts to automate part of the review process as soon as I have the time to finish them. Great idea. I hacked a little script some time ago. It may be a little outdated now, non optimally designed, but maybe something could be reused in your project: http://jskarvad.fedorapeople.org/pmreview Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
To clear the confusion, there is no change in the RE syntax in grep-2.7. The old grep silently interprets all these REs the way that probably nobody intended to, e.g. The [:space:] match: ac:eps You can force grep-2.7 to silently process it (above mentioned way, same as with older greps) by setting POSIXLY_CORRECT environment variable. But all such REs are probably typos Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
All three of my newly released GNOME 2.32.0 projects failed to build on koji (f14) today: http://koji.fedoraproject.org/koji/getfile?taskID=2491737name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491754name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491800name=build.log I've been told it's something to do with the way glibc decides to interpret posix rules for character classes, which seems to have broken grep. Can we revert the new glibc from the buildsystem please, until the breakage is fixed upstream. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel AFAIK the following message from build log indicates incorrect regular expressions in docbook-utils: grep: character class syntax is [[:space:]], not [:space:] The character class must be inside bracketed expression, thus double brackets, please see man grep. The new grep-2.7 checks for this common fault: grep now diagnoses (and fails with exit status 2) commonly mistyped regular expression like [:space:], [:digit:], etc. Before, those were silently interpreted as [ac:eps] and [dgit:] respectively. Virtually all who make that class of mistake should have used [[:space:]] or [[:digit:]]. This new behavior is disabled when the POSIXLY_CORRECT environment variable is set. regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New fedpkg build coming to an update repo near you!
Thanks, but I have following problem: $ fedpkg co -B xterm Cloning into bare repository /home/yarda/git-fedora/xterm/fedpkg.git... remote: Counting objects: 657, done. remote: Compressing objects: 100% (333/333), done. remote: Total 657 (delta 274), reused 657 (delta 274) Receiving objects: 100% (657/657), 81.09 KiB | 81 KiB/s, done. Resolving deltas: 100% (274/274), done. Traceback (most recent call last): File /usr/bin/fedpkg, line 1086, in module args.command(args) File /usr/bin/fedpkg, line 425, in clone pyfedpkg.clone_with_dirs(args.module[0], args.user) File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line 413, in clone_with_dirs clone(module, user, top_path, bare_dir=repo_path) File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line 385, in clone repo = git.Repo(module) The fedpkg-0.5.1.2-2.fc13 is working fine: $ fedpkg co -B xterm Cloning into bare repository /home/yarda/git-fedora/NetworkManager/xterm/fedpkg.git... remote: Counting objects: 657, done. remote: Compressing objects: 100% (333/333), done. remote: Total 657 (delta 274), reused 657 (delta 274) Receiving objects: 100% (657/657), 81.09 KiB | 85 KiB/s, done. Resolving deltas: 100% (274/274), done. Bug? Or my wrong setup/use case? Thanks Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 Question: AVerMedia AVerTV Volar Black HD/-A850 availability
So I copied dvb-usb-af9015.fw from some UBUNTU installation to /lib/firmware, and I could watch digital TV with kaffeine. So my question: would it be possible to support that stick in = F15 versions? AFAIK this firmware seems not to be free. Nice query. I have a AVerTV Hybrid Volar HX(A827) and it's the same situation. I use right now the driver/firmware from here: http://www.avermedia.com/avertv/Support/Download.aspx?Action=searchKind=APDriverinterface=3signal=3keyword=linux Works nicely on my F-13, even with latest kernel from updates-testing. +1 for me as I own this device too, but AFAIK it seems there is still no usable kernel driver for it, so probably there is no other option now. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transfer to git breaks my package?
Thanks everybody for info and sorry for missing the original thread. Please could Jesse or somebody also fix this for me? Thanks regards Jaroslav - Original Message - From: Michael Schwendt mschwe...@gmail.com To: devel@lists.fedoraproject.org Sent: Wednesday, August 4, 2010 10:37:30 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: Transfer to git breaks my package? On Wed, 4 Aug 2010 04:29:23 -0400 (EDT), Jaroslav wrote: Hi, I encountered file in initial git repo that differs from version in latest cvs head. I cannot find this change in logs nor I didn't make this change (as far as I remember ;). --VERSIONID(`$Id: submit.mc,v 8.14 2006/04/05 05:54:41 ca Exp $') +-VERSIONID(`$Id: sendmail-8.13.7-pid.patch,v 1.2 2007/08/27 10:25:00 twoerner Exp $') +sinclude(`/usr/share/sendmail-cf/m4/cf.m4')dnl Has come up a few days ago: http://lists.fedoraproject.org/pipermail/devel/2010-August/140094.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
[jskarvad] sendmail: sendmail-milter-8.14.4-8.fc14.x86_64 license added to sendmail-milter-8.14.4-9.fc14 regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcl/tk 8.5.8 update for F13?
AFAIK this shouldn't been related, please see: https://fedorahosted.org/rel-eng/ticket/3815 - Original Message - From: Michael Cronenworth m...@cchtml.com To: devel@lists.fedoraproject.org Sent: Tuesday, June 29, 2010 4:12:21 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: tcl/tk 8.5.8 update for F13? Jaroslav Skarvada wrote: From the repoquery only the tk seems to have exact version dependency on tcl. Also from my test with several packages requiring libtcl/libtk - they worked without rebuild. I don't like to break anything, thus please let me know if you see any problem with such update Are you sure? Email from Kevin Fenzi[1]: Also, pidgin needed to be added to it. It failed rebuild due to a new tcl in the buildroot. This tcl build has been untagged now, so it's been rebuilt and should be added to the update soon. [1] http://lists.fedoraproject.org/pipermail/devel/2010-June/137983.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel