Re: Release monitoring for stable releases only

2023-01-26 Thread Jaroslav Skarvada
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

2023-01-26 Thread Jaroslav Skarvada
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

2023-01-25 Thread Jaroslav Skarvada
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

2023-01-24 Thread Jaroslav Skarvada
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

2023-01-24 Thread Jaroslav Skarvada
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

2023-01-24 Thread Jaroslav Skarvada
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

2021-01-21 Thread Jaroslav Skarvada
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

2021-01-14 Thread Jaroslav Skarvada


- 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

2020-08-03 Thread Jaroslav Skarvada


- 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

2020-08-03 Thread Jaroslav Skarvada


- 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

2020-07-15 Thread Jaroslav Skarvada
> 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

2020-06-26 Thread Jaroslav Skarvada


- 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

2020-06-26 Thread Jaroslav Skarvada


- 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

2020-06-26 Thread Jaroslav Skarvada


- 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

2020-06-26 Thread Jaroslav Skarvada


- 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

2020-06-22 Thread Jaroslav Skarvada


- 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

2020-05-19 Thread Jaroslav Skarvada

> 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

2017-09-14 Thread Jaroslav Skarvada


- 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

2017-09-14 Thread Jaroslav Skarvada


- 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

2017-09-14 Thread Jaroslav Skarvada
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?

2017-08-16 Thread Jaroslav Skarvada


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

2017-08-14 Thread Jaroslav Skarvada
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?

2017-08-14 Thread Jaroslav Skarvada
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

2017-08-14 Thread Jaroslav Skarvada


- 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

2017-08-11 Thread Jaroslav Skarvada


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

2017-01-16 Thread Jaroslav Skarvada


- 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

2016-12-12 Thread Jaroslav Skarvada


- 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

2016-12-12 Thread Jaroslav Skarvada


- Original Message -
> Mike McLean  wrote:
> 
> > 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

2016-12-12 Thread Jaroslav Skarvada


- 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

2016-12-12 Thread Jaroslav Skarvada


- 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

2016-03-19 Thread Jaroslav Skarvada
- 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

2016-01-12 Thread Jaroslav Skarvada


- 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

2016-01-11 Thread Jaroslav Skarvada


- 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

2016-01-08 Thread Jaroslav Skarvada
$ 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

2015-12-01 Thread Jaroslav Skarvada
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

2015-11-30 Thread Jaroslav Skarvada


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

2015-04-13 Thread Jaroslav Skarvada


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

2015-04-01 Thread Jaroslav Skarvada
  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

2015-03-16 Thread Jaroslav Skarvada
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

2014-12-15 Thread Jaroslav Skarvada
- 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

2014-10-13 Thread Jaroslav Skarvada
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

2014-05-20 Thread Jaroslav Skarvada
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

2012-10-22 Thread Jaroslav Skarvada
 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

2012-10-10 Thread Jaroslav Skarvada
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

2012-07-31 Thread Jaroslav Skarvada
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

2012-07-12 Thread Jaroslav Skarvada
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

2012-04-06 Thread Jaroslav Skarvada
 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

2012-03-26 Thread Jaroslav Skarvada

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

2012-03-02 Thread Jaroslav Skarvada
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?

2012-02-28 Thread Jaroslav Skarvada
 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

2011-10-06 Thread Jaroslav Skarvada
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

2011-10-06 Thread Jaroslav Skarvada
- 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)

2011-09-28 Thread Jaroslav Skarvada
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+

2011-07-19 Thread Jaroslav Skarvada
- 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+

2011-07-19 Thread Jaroslav Skarvada


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

2011-07-19 Thread Jaroslav Skarvada


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

2011-07-19 Thread Jaroslav Skarvada
 
 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

2011-06-22 Thread Jaroslav Skarvada
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+

2011-06-02 Thread Jaroslav Skarvada
- 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

2011-05-16 Thread Jaroslav Skarvada
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 ?

2011-04-06 Thread Jaroslav Skarvada
- 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

2011-03-30 Thread Jaroslav Skarvada
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

2011-03-15 Thread Jaroslav Skarvada
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

2011-01-24 Thread Jaroslav Skarvada
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

2010-11-15 Thread Jaroslav Skarvada
 
 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

2010-11-12 Thread Jaroslav Skarvada
 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

2010-11-10 Thread Jaroslav Skarvada
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

2010-11-08 Thread Jaroslav Skarvada
 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?

2010-11-01 Thread Jaroslav Skarvada
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

2010-11-01 Thread Jaroslav Skarvada

 
 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]

2010-10-04 Thread Jaroslav Skarvada

 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?

2010-09-27 Thread Jaroslav Skarvada
 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!

2010-08-24 Thread Jaroslav Skarvada
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

2010-08-18 Thread Jaroslav Skarvada
 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?

2010-08-04 Thread Jaroslav Skarvada
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

2010-07-08 Thread Jaroslav Skarvada
[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?

2010-06-29 Thread Jaroslav Skarvada
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