Re: Deprecated net-tools? Mass bug filing?

[Jon Kent]

I'd agree with that. In addition so many peoples own scripts rely on them
that the user impact could be huge. That and every SA I know (and me)
dislikes the ip tool with a passion.

Regards,

Jon

On Wed, 17 May 2017, 08:47 Daniel P. Berrange,  wrote:

> On Tue, May 16, 2017 at 11:29:42PM +0100, James Hogarth wrote:
> > Hi,
> >
> > It was pointed out on IRC to me tonight that there are actually a
> > reasonable number of packages that still depend on net-tools[0].
> >
> > This has been deprecated for a long time now and we really should
> > strive to have everything use iproute2 instead so that there is no
> > longer a need to keep the deprecated package about, other than if
> > someone explicitly really wants netstat or ifconfig for some reason.
> >
> > Is the best way to handle this a mass bug filing?
>
> Converting apps from nettools to iproute is often non-trivial piece
> of work. As such isn't really something Fedora package maintainers
> should look to undertake as the risk of introducing regressions is
> non-negligible.  Bug reports really need to go the corresponding
> upstream communities to get anything done.
>
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning ptpd

[Jon Kent]

Hi,

Thanks for that.  Assigned it over you.  When you are OK with things feel
free to remove me from the admins.

Enjoy

Regards,
Jon

On Sat, 18 Feb 2017 at 22:09 Peter Robinson <pbrobin...@gmail.com> wrote:

> On Sat, Feb 18, 2017 at 10:29 AM, Jon Kent <jon.k...@gmail.com> wrote:
> > Hi,
> >
> > I'm afraid I'm going to have to orphan the ptpd package, as I no longer
> have
> > the means to test it.
>
> I can take that, feel free to assign it to me (FAS pbrobinson)
>
> Peter
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning ptpd

[Jon Kent]

Hi,

I'm afraid I'm going to have to orphan the ptpd package, as I no longer
have the means to test it.

Regards

Jon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora AMI build process

[Jon Kent]

Many thanks I'll take a look

Regards,
Jon

On Tue, 16 Feb 2016, 17:49 Kushal Das <m...@kushaldas.in> wrote:

> On 16/02/16, Jon Kent wrote:
> > Hi,
> >
> > I've been trying to see how we build Fedora AMIs but am starting having
> not
> > luck with finding documents on the buiild process. If someone could throw
> > me a link it would be much appreciated.
> >
>
> The first step is about creating raw images from the kickstart files,
> the process is fully documented in [1]. Then fedimg comes up and creates
> the AMI from the raw images. [2] will tell how it is done in simple
> steps.
>
> [1]
> https://worknotes.readthedocs.org/en/latest/cloudimages.html#imagefactory
> [2]
>
> https://stackoverflow.com/questions/24019770/creating-a-custom-ec2-ami-from-a-qcow2-image-file-with-python
>
> Kushal
> --
> Fedora Cloud Engineer
> CPython Core Developer
> http://kushaldas.in
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora AMI build process

[Jon Kent]

That's fine, understandable. Must admit I thought I was subscribed, but
will check.

Jon

On Tue, 16 Feb 2016 15:28 Matthew Miller <mat...@fedoraproject.org> wrote:

> On Tue, Feb 16, 2016 at 02:41:18PM +0000, Jon Kent wrote:
> > Thanks for the info.  I tried mailing the SIG but it got stuck in an
> > approval queue never to be seen again.
>
> The Fedora mailing lists get a huge amount of spam. Like, a
> mind-blowing amount. Therefore, you need to be subscribed in order to
> post to any of our lists. Or, you can use the new hyperkitty interface
>
> https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/
> to post without subscribing.
>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora AMI build process

[Jon Kent]

Thanks for the info.  I tried mailing the SIG but it got stuck in an
approval queue never to be seen again.

Regards,
Jon

On Tue, 16 Feb 2016 14:18 Haïkel <hgue...@fedoraproject.org> wrote:

> 2016-02-16 15:02 GMT+01:00 Jon Kent <jon.k...@gmail.com>:
> > Hi,
> >
> > I've been trying to see how we build Fedora AMIs but am starting having
> not
> > luck with finding documents on the buiild process. If someone could
> throw me
> > a link it would be much appreciated.
> >
> > Thanks,
> > Jon
> >
>
> I suggest that you contact the Fedora Cloud SIG through their own mailing
> list.
>
> In short, AMI are composed by Koji using ImageFactory, fedimg is used
> to upload images.
> http://imgfac.org/
> https://github.com/fedora-infra/fedimg
>
> Regards,
> H.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora AMI build process

[Jon Kent]

Hi,

I've been trying to see how we build Fedora AMIs but am starting having not
luck with finding documents on the buiild process. If someone could throw
me a link it would be much appreciated.

Thanks,
Jon
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Poll: How users use DNF

[Jon Kent]

Hi,

We use yum wrapped up in a python script that runs from a master server and
uses ssh to log into server/servers and run the requested command (the
script doesn't support all, just most -install, downgrade, upgrade etc)
against either a single rpm or upgrade all rpms.  It uses the exit status
from yum to catch errors, log them and either move to the next server or
exit (which is an option to the script).

For the more dangerous yum actions (such as downgrade, remove etc) the
script ask for verification by generating a random number and requesting
you input it (basic yes/no leads to auto typing).

Ideally I'd like this to be a part of dnf or yum suite so that I don't have
to run write a script to perform this.  As we look after 100s of servers,
having the ability to do this has saved large amounts of time for us.
Since I wrote the original (a bash script originally) 10 years ago this is
used globally internally and our SAs expect this to be there and can't
imagine managing our server farms without.  Therefore I strong believe this
is a typical user case that is currently not covered.

Hope that is what you are looking for.

Regards,
Jon



On Tue Dec 09 2014 at 17:29:04 Radek Holy rh...@redhat.com wrote:

 Dear users of YUM and DNF,

 I'm writing to you regarding a request for your feedback. I would be very
 grateful if you could send me a brief description of how you use YUM or DNF
 currently or how would you like to use it. I am particularly interested in
 the occurrences of dnf/yum install calls in your scripts. What does these
 scripts do and what do they expect when they call the install command in
 different situations?

 Please share with me the use cases, not the description of the install
 command. Think twice before you share something because I believe it's not
 as easy as it might seem. As an example I think it might be something like:

 - I call YUM install, because I want to get given packages into my system
 and I don't care whether it requires an upgrade or downgrade or what. or
 - I want to get them there but it should protect me against dangerous
 operations like downgrades or
 - I often make typos, so I expect that the program knows what I mean or
 - it would be nice if it would literally perform the installation; if any
 of the packages cannot be installed because of any reason, it should fail.

 Not something like: that's obvious that the install command should never
 downgrade packages.

 Please focus on *use cases*. The *real* (non-hypothetical) use cases. Not
 on the command's name as it might also result in a new command (while
 preserving the well-known install command together with an appropriate
 behaviour).

 I don't mind if you send it offlist (or to another list). I think there is
 no need to comment on anyone's use case. Every case is valid. Just not
 every case can be supported.

 Thank you very much in advance.
 --
 Radek Holý
 Associate Software Engineer
 Software Management Team
 Red Hat Czech
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Poll: How users use DNF

[Jon Kent]

Hi,

Thanks, I'll take a look.

Jon

On Tue, 9 Dec 2014 22:58 Colin Walters walt...@verbum.org wrote:

 On Tue, Dec 9, 2014, at 04:58 PM, Jon Kent wrote:

 Hi,

 We use yum wrapped up in a python script that runs from a master server
 and uses ssh to log into server/servers and run the requested command


 I'd recommend Ansible, it comes with built in primitives for interacting
 with yum declaratively.  There are other systems out there of course too.
  --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: dnf even allows to uninstall RPM and systemd without warnings

[Jon Kent]

Been reading this for a while and I'm getting annoyed by the 'you should
know what you are doing' mob. There can be no reason not to have safe
guards in dnf to save you from the oh sh#t moments. Everyone has those at
some time and those who are learning Linux need these guards to avoid them
trashing their system. Everyone starts from a little knowledge base and we
should (must) take that on-board.

It's irrelevant whether yum does or doesn't have this. If dnf is the new
and improved then it should have these from the off else what's to gain
from an end SAs point of view.  No point in just creating a like-for-like
replication.  Make it better and safer or don't bother.

Jon


On 24 Jun 2014 10:37, Richard Hughes hughsi...@gmail.com wrote:

 On 24 June 2014 10:31, Thomas Bendler m...@bendler-net.de wrote:
  you need to unlock the gun before you can shoot in your foot...
  ...and modern systems ask you up to four, five times

 How many different locks does a gun have? Last time I checked there
 was one safety catch -- DNF asks you for 'y/N' confirmation with a
 HUGE list of packages to be removed. If you're not sure whether
 removing systemd or glibc is a bad idea, perhaps having root access
 isn't the best plan in the world. There are _so_ _many_ _ways_ to hose
 your system with root access, I really don't think we can or should
 baby-proof just one low level command.

 Richard
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: F22 System Wide Change: Replace Yum With DNF

[Jon Kent]

fpm (fedora package manager).  Flows nicely off the keyboard too 

I'd agree that dnf is perhaps not the best name in the world, always makes
me think 'did not finish' which isn't good really.

Jon
On 17 Jun 2014 08:07, Jan Zelený jzel...@redhat.com wrote:

 On 16. 6. 2014 at 19:49:35, Peter Oliver wrote:
  On 16 June 2014 08:31, Jan Zelený jzel...@redhat.com wrote:
   On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
   So I propose we keep calling the project DNF and the package dnf, but
   start the transition to a generic command name for the tool that
   installs, removes, and updates packages.  I propose that this command
   name be called pkg.  We can keep backwards compatibility to both the
   yum command name and the dnf command name indefinitely.
  
   Sounds like an interesting idea and we will definitely give this some
   thought.
  If you decide to go this route, it's worth bearing in mind that
  Solaris 11 and FreeBSD 10 both already have tools called pkg that
  perform this function.  They are incompatible with yum and dnf, but
  have a similar-enough command-line that people searching the web for,
  say, pkg install will find information about the wrong one.

 Any other suggestions then? Cause `pkg` would be my #1 choice.

 Thanks
 Jan
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: F22 System Wide Change: Replace Yum With DNF

[Jon Kent]

Hi,

Been monitoring this debate and if nothing else this seems to point out
that the reasoning for dnf, as opposed to fixing/rewriting yum haven't been
laid out very well. I'm on yum side of the fence as I don't see that the
reasoning so far is been put forward very well for moving to dnf, and that
dnf has crept up on people rather than being 'out there'.

Played with dnf, and from as SA point of view (i.e. mine), I don't see the
difference really, does what I need, which is good.  But then so does yum,
and there lies the problem.  Bad/undocumented api's is not a good reason
for starting something from starch, but a good reason to write this.  At
present, this feels like a pet project, rather than a project with good
reasoning for existing.  I'm sure that not the case, but its not good that
I, and others, feel this well and points to really bad communication.

So my message is simple, write up why dnf is better than yum, from both a
users and devs point of view, then maybe this'll win people over.  Till I
see that, I'll back the guys who want to stick with yum.

Cheers,
Jon



On Sat, Jun 14, 2014 at 11:55 AM, Reindl Harald h.rei...@thelounge.net
wrote:


 Am 14.06.2014 12:26, schrieb Michael Scherer:
  Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
  Am 14.06.2014 03:42, schrieb Michael Scherer:
  Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
  So maybe you should propose to have dnf named yum 4.0, and then since
  that's a major version, we would be ok to change the behavior,
 command
  lines switch, configuration and backend in a backward incompatible
  way?
 
  yes
 
  so, just to be clear, that's ok to change the behavior, command lines
  switch, configuratio and backend in backward _incompatible_ for yum 4.0
  aka dnf, for you ?
 
  it is *NEVER* ok to break user interfaces without a damned good reason
  there is no single reason to break command line switches at all
 
  So why do you say yes at the proposal that should be ok to break
  command line switch if you mean no ?

 to show you how weird your come on let us break compatibility is

  So you are in favor of keeping the current behavior as is for how long ?
  (because it sound like forever for you)

 yes forever to say it clear
 if it ain't broken don't fix it

  Well, yes, because that's the developer that has to make the effort. It
  is easy to say do that and going back to your business. In the end,
  those who work decide. And so far, I do not see patches coming from you

 i am fine with YUM for many years as others are too
 there was and is no valid reason to break CLI interfaces

  That's why the developers do ask what is missing. That's also why I
  ask for you what compatibility you exactly want, and you keep avoiding
  giving a clear answer

 *full* compatibility - is that so hard to understand and why?

  Yes. And I would be in favor personally, so that let developers free to
  change the interface and anything if they see fit without having to keep
  old code for the old interface.

 why do you need to keep old code for compatible CLI interfaces?

  People who want the old yum can keep it alive, the others can use the
  dnf name

 and because of that attitude Linux don't have that big marketshare
 while often on that list is talked about competitors and marketshare

 you will never gain a large userbase if you signal all the time
 that it's worthless for non-tech users to learn how to deal with
 whatever Linux systems because they have to learn again and again
 how to do the same things instead spend the time for learning
 how to do new things with their computers


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://about.me/jonkent
-- 
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: F22 System Wide Change: Replace Yum With DNF

[Jon Kent]

Concerns me greatly when someone thinks cli is the wrong way to automate
things. Agree Reindl comment 're this statement.
On 14 Jun 2014 13:41, Reindl Harald h.rei...@thelounge.net wrote:


 Am 14.06.2014 14:31, schrieb drago01:
  And recently there is even a trend where people (and the press)
  complains lack of change == lack of innovation ... that does not
  mean that we should do changes for the sake of doing changes but we
  should not be afraid of doing so either.

 the same sort of people who complain about business numbers
 bad because only a few hundret millions more income than
 the year before

  you can rename internal functions, move code, use different
  libraries all day long, but if it comes to command lines and
  user interfaces (CLI params are a user interface) you need
  always to be very careful
 
  Depends obscure options that are hardly used by the majority of users
  are different from common options that everyone uses.

 dnf remove yum dnf kernel ruins your system
 yum don't allow that for good reasons

 that's unacepptable behavior and was refused to change

 dnf needs much more RAM currently while the feature page
 pretends it has a smaller footprint - so it's not ready
 or the feature page is a would nice to be not backed
 by the reality

  FWIW using a CLI interface to automate things is imo the wrong
  approach if there is an api that can be used instead (cleaner, less
  hacky, more efficient, etc) (and yes this changes here too, because
  the old API was really horrible but that's not the point)

 no idea what is your daily job, sysadmin obviously not

 shell scripts are the Unix way and overall more efficient
 just because you write tiny scripts for different tasks
 and plug them together - efficient is not only a matter
 of runtime measure


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
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: F22 System Wide Change: Replace Yum With DNF

[Jon Kent]

I have a script I wrote that we've been using for years to manage large
number of servers using yum to manage rpm install/upgrades etc via ssh from
management server. So long as that usecase is covered still, ie dnf can be
scripted around with sane exit codes, than I'm a happy bunny.  From what
I've seen this would appear to be the case.

Obviously comments around cli make me nervous with the above being a common
approach to managing server farms.

Jon
 On 14 Jun 2014 13:56, Michael Scherer m...@zarb.org wrote:

 Le samedi 14 juin 2014 à 13:45 +0100, Jon Kent a écrit :
  Concerns me greatly when someone thinks cli is the wrong way to
  automate things. Agree Reindl comment 're this statement.

 CLI is not scalable, you need to fork processes for that. There is also
 no way to communicate errors to the software that do the automation,
 since you can only transmit string without any formatting or
 translation.

 You are also mixing something mean for a user and something meant for a
 software.
 --
 Michael Scherer

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Another bug on OpenSSL

[Jon Kent]

At present I have more trust in the OpenBSD guys than OpenSSL based upon
their previous work. So I'd prefer to move to LibreSSL once stable

Just my 2c worth.

Jon
On 8 Jun 2014 15:21, Álvaro Castillo net...@fedoraproject.org wrote:

 Dear mailing list,

 Few days was built an patch to solve an another vulnerability into
 OpenSSL(
 http://bits.blogs.nytimes.com/2014/06/05/new-bug-found-in-widely-used-openssl-encryption/?_php=true_type=blogs_r=0
 ).
 Some sources talks about that's bug was discovered a long time ago but
 does not fixed.

 However, OpenBSD was created a fork called LibreSSL try to solve this
 issues. Should Fedora to move LibreSSL (http://www.libressl.org/)? Or
 still use OpenSSL and wait what's bug could be found today, or
 tomorrow, or few months to go similar Adobe Flash bugs?
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

SSL cert rejected

[Jon Kent]

Hi,

I getting the usual:

Could not execute new_sources: Lookaside failure: (58, 'SSL peer rejected
your certificate as revoked.')

when running 'fedpkg new-sources', even though I've re-run
fedora-packager-setup.  Is there a problem, or I am missing something?

Thanks,

Jon
-- 
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: SSL cert rejected

[Jon Kent]

Hi,

That showing:
fedora-cert -v
Verifying Certificate
cert expires: 2014-10-15
CRL Checking not implemented yet

Which looks good to me, unless I'm misreading this.

Cheers,
Jon





On Sun, Jun 8, 2014 at 7:56 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Sun, 8 Jun 2014 19:52:21 +0100
 Jon Kent jon.k...@gmail.com wrote:

  Hi,
 
  I getting the usual:
 
  Could not execute new_sources: Lookaside failure: (58, 'SSL peer
  rejected your certificate as revoked.')

 Note that you can only have one valid cert at a time.
 
  when running 'fedpkg new-sources', even though I've re-run
  fedora-packager-setup.  Is there a problem, or I am missing something?

 What does 'fedora-cert -v' show?

 kevin

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://about.me/jonkent
-- 
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: SSL cert rejected

[Jon Kent]

Hi,

Sorted it.  Instead of fedora-packager-setup I used fedora-cert to update
my certificate and it all working now.

Cheers,
jon



On Sun, Jun 8, 2014 at 8:00 PM, Jon Kent jon.k...@gmail.com wrote:

 Hi,

 That showing:
 fedora-cert -v
 Verifying Certificate
 cert expires: 2014-10-15
 CRL Checking not implemented yet

 Which looks good to me, unless I'm misreading this.

 Cheers,
 Jon





 On Sun, Jun 8, 2014 at 7:56 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Sun, 8 Jun 2014 19:52:21 +0100
 Jon Kent jon.k...@gmail.com wrote:

  Hi,
 
  I getting the usual:
 
  Could not execute new_sources: Lookaside failure: (58, 'SSL peer
  rejected your certificate as revoked.')

 Note that you can only have one valid cert at a time.
 
  when running 'fedpkg new-sources', even though I've re-run
  fedora-packager-setup.  Is there a problem, or I am missing something?

 What does 'fedora-cert -v' show?

 kevin

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




 --
 http://about.me/jonkent




-- 
http://about.me/jonkent
-- 
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: ROLLING FEDORA

[Jon Kent]

Well rawhide could be considered as such but can break your build.
On 7 Jun 2014 20:04, مصعب الزعبي moc...@hotmail.com wrote:

 Hi List,

 Any plans for rolling Fedora ??

 Regards
 Mosaab

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
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: Incorrect order of /usr/bin and /usr/sbin in path

[Jon Kent]

Hi,

That's my recollection as well. Heard that confusion about sbin being for
superuser before.

Jon
 On 5 May 2014 15:29, Adam Jackson a...@redhat.com wrote:

 On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:

  however, the semantics of /usr/sbin is to contain superuser
  binaries which should not be overriden because a binary
  with the same name exists in /usr/bin

 My memory is that the s was more for static not superuser.
 There's some conceptual overlap, static binaries being there to recover
 even if your shared libraries are hosed which is normally a superuser
 kind of operation, but.

 - ajax

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Make fails with fedora build options set

[Jon Kent]

Hi,

I'm trying to get a GnuBatch package into Fedora, which is currently
being reviewed. One of the points raised in the review was that I was
running make without any Fedora options. I've added these as requested
so the make line now looks like:

make %{?_smp_mflags} CFLAGS=%{optflags} BINDIR=%{_bindir}

This expands out to :

make -j4 CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic BINDIR=/usr/bin

However with these options the build is now failing where is was working
fine before using just make. The errors are related to being unable to
find the header files (i.e. config.h). I've tried added -I option
pointing to the header directory but this did not help.

What I don't understand is why this worked before, where as with these
make options set the build now fails. Any pointers much appreciated as
I'm just going in circles here trying to resolve this problem.

The below is an part of the output I get when this fails:

make[4]: Entering directory
`/home/jon/rpmbuild/BUILD/gnubatch-1.10/util'
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic   -c -o helpparse.o helpparse.c
helpparse.c:18:20: fatal error: config.h: No such file or directory
 #include config.h

Thanks,
Jon
-- 
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: Make fails with fedora build options set

[Jon Kent]

Thats an idea, hadn't thought of that.  Will take a look.

Thanks


On Thu, May 1, 2014 at 12:46 PM, Dan Horák d...@danny.cz wrote:

 On Thu, 1 May 2014 12:34:43 +0100
 Jon Kent jon.k...@gmail.com wrote:

  Hi,
 
  I'm trying to get a GnuBatch package into Fedora, which is currently
  being reviewed. One of the points raised in the review was that I was
  running make without any Fedora options. I've added these as requested
  so the make line now looks like:
 
  make %{?_smp_mflags} CFLAGS=%{optflags} BINDIR=%{_bindir}
 
  This expands out to :
 
  make -j4 CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
  -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
  -grecord-gcc-switches -m64 -mtune=generic BINDIR=/usr/bin
 
  However with these options the build is now failing where is was
  working fine before using just make. The errors are related to being
  unable to find the header files (i.e. config.h). I've tried added -I
  option pointing to the header directory but this did not help.
 
  What I don't understand is why this worked before, where as with these
  make options set the build now fails. Any pointers much appreciated as
  I'm just going in circles here trying to resolve this problem.
 
  The below is an part of the output I get when this fails:
 
  make[4]: Entering directory
  `/home/jon/rpmbuild/BUILD/gnubatch-1.10/util'
  gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
  -fstack-protector-strong --param=ssp-buffer-size=4
  -grecord-gcc-switches -m64 -mtune=generic   -c -o helpparse.o
  helpparse.c helpparse.c:18:20: fatal error: config.h: No such file or
  directory
   #include config.h

 I guess the CFLAGS set on the make command line override the project's
 Makefile ones causing the header not being found. You should merge the
 Fedora flags with the relevant ones from the project.


 Dan
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://about.me/jonkent
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct