Re: copr - hung or out of control build .. ? resolved by itself.

[David Timms]

On 14/11/15 01:18, Miroslav Suchý wrote:
> Dne 13.11.2015 v 13:30 David Timms napsal(a):
>> Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
>> 12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
>> something has gone wrong... No logs yet for it.
>>
>> https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/
> 
> I see it as succeeded, so your problems are likely resolved now :)

Thanks Miroslav, it did finish in 112 mins. That was way longer than
normal, I guess the builders where under heavy load or something. Thanks
anyway.

I'm also none the wiser about the Koji build which failed. Since the
same on COPR eventually finished, I tried Koji again, and succeeded as
expected, so all good.

Dave.
-- 
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: Retire a package from Fedora i686 (not x86_64)

[Germano Massullo]

A clear example of the mentioned problems for Darktable 32 bit
http://redmine.darktable.org/issues/10717
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Proposal to CANCEL: 2015-11-16 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel Monday's QA meeting. We met the last
few weeks and I think pretty much knocked out all the key discussion
topics. I'm going to be out Monday morning, but if anyone has a topic
for a meeting, please just reply to this mail and anyone can pick up
and run the meeting: just follow
https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process . Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: wayland in rawhide

[Ray Strode]

hi,

> Here's one on Ironlake, with two monitors plugged in.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=750610
>
> still not fixed, doesn't fall back.
Well, black screens obviously aren't good, and we should clearly fix this.

If we don't get it fixed by closer to release, than maybe it's a good
data point for switching
back to Xorg for fedora 24.  But note:

1) 3 monitor setups are somewhat more rare than one and two monitor
setups, so it's important to fix, but the impact is more limited so
the problem didn't get as much exposure as it would have otherwise.
2) the bug was reported by a developer who has reproducing hardware
and intimate domain knowledge around the functions related to the
failure (you).

I'm sure we can figure this one out after a few minutes poking at it
with the hardware.  If not you, then me, or Rui, or a hand full of
other people.

Regardless of what this bug means for Fedora 24, I don't think it
should affect what we're doing for rawhide.

--Ray
-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Adam Miller]

On Fri, Nov 13, 2015 at 5:14 PM, Brian C. Lane  wrote:
> On Tue, Nov 10, 2015 at 12:08:25PM -0600, Adam Miller wrote:
>> Hello all,
>> In the Fedora 24 timeframe the Fedora Release Engineering group is
>> aiming to deliver the Layered Image Build Service[0] to allow Fedora
>> contributors to build containers images. In the first iteration of
>> this we're targeting Docker layered image support. Part of this will
>> be to allow Fedora contributors to maintain Dockerfiles much like we
>> maintain rpm spec files via DistGit.
>
> So you're talking about one docker file per package, right? Or are these
> going to pull from multiple packages and have the docker container be a
> different level of object? Or both?

Both, it's mostly at the discretion of the person attempting to
deliver something in a container. Some may be simple "I added httpd on
top of the base Fedora Docker image" and others might be "I put all of
ownCloud into a container so you can just run the whole thing with
this one command"

That being said, I'm not married to the concept. It was just the idea
going into it. If the general consensus among the community is "one
Dockerfile to one package" we could go that route.

>
> If you're talking about a 1:1 package:docker mapping then the only thing
> that makes sense to me is to have them live in the current system next
> to the .spec files. Anything else will easily introduce divergence from
> the rpm packages.

Absolutely, so far there has been the expectation that there will be
divergence because of the more "dynamic" nature of what containers
bring to the table.

>
> I also see that 'container packager' and 'rpm packager' are used in the
> build service page. I don't think these should be separate roles,
> everyone should be a packager. If you have one role working on container
> building for a package and another who only does rpm packaging we're
> going to, again, end up with things diverging.

I believe they will diverge naturally as time goes on. Also, I don' t
think everyone who has rpm packaging expertise is well versed in the
ways of Docker and vice versa.

>
> Some things I'd suggest (given I don't know the answers to the above
> questions):
>
> 1. All bits have to come from koji built rpms. No rebuilding of bits
> for docker, it just installs existing bits.

That is the plan, but configuration can take place inside the context
of the container image build process to allow for single-command
execution.

>
> 2. docker files for packages live in dist-git next to the package spec
> file.

We can, pending the agreement that's all we as a community/project use
Dockerfiles for. The original idea going in to this though is that we
could extend this to provide a more full featured solution for
services that would need more than one package. Even simple things
like httpd modules (mod_wsgi, mod_php, etc) would technically ship
more rpms than they produce in the docker image.

Also in the distant future (out of scope for the original offering),
we'd like to look at delivering multi-container apps via Nulecule[0]
specifications.

>
> 3. Any meta-containers collecting using packages are also an rpm
> package, following whatever naming convention gets decided on.
> fedora-docker-foo would make sense to me.

I'm not sure I follow what you mean here, why would something that
only comes as a Dockerfile also be a rpm?

>
> 4. package level docker files are maintained by the same people who maintain
> the package.
>

This certainly makes sense if we end up going the package:container 1:1 route.

-AdamM

[0] - https://github.com/projectatomic/nulecule

> --
> Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA 
> (PST8PDT)
> --
> 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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Brian C. Lane]

On Tue, Nov 10, 2015 at 12:08:25PM -0600, Adam Miller wrote:
> Hello all,
> In the Fedora 24 timeframe the Fedora Release Engineering group is
> aiming to deliver the Layered Image Build Service[0] to allow Fedora
> contributors to build containers images. In the first iteration of
> this we're targeting Docker layered image support. Part of this will
> be to allow Fedora contributors to maintain Dockerfiles much like we
> maintain rpm spec files via DistGit.

So you're talking about one docker file per package, right? Or are these
going to pull from multiple packages and have the docker container be a
different level of object? Or both?

If you're talking about a 1:1 package:docker mapping then the only thing
that makes sense to me is to have them live in the current system next
to the .spec files. Anything else will easily introduce divergence from
the rpm packages.

I also see that 'container packager' and 'rpm packager' are used in the
build service page. I don't think these should be separate roles,
everyone should be a packager. If you have one role working on container
building for a package and another who only does rpm packaging we're
going to, again, end up with things diverging.

Some things I'd suggest (given I don't know the answers to the above
questions):

1. All bits have to come from koji built rpms. No rebuilding of bits
for docker, it just installs existing bits.

2. docker files for packages live in dist-git next to the package spec
file.

3. Any meta-containers collecting using packages are also an rpm
package, following whatever naming convention gets decided on.
fedora-docker-foo would make sense to me.

4. package level docker files are maintained by the same people who maintain
the package.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

python3 rebuild notes: python-testtools

[Jerry James]

I've been looking at some packages that failed the python 3 rebuild
and are sitting underneath some of my packages.  I had hoped to
untangle things, but it's apparent that I'm not going to be able to do
so with the amount of time I have available.  Here are some notes in
case anybody out there in Fedora land has time to take this to
completion.

The basic problem is that python-testtools is involved in multiple
cyclic dependencies.  This works:

1. Build python-extras with tests turned off.
2. Build python-traceback2, with tests turned off like python-extras does
3. Build python-linecache2, with tests turned off like python-extras does
4. Build python-testtools (there is a new version, just released today)
5. Build python-fixtures (there is a newer version, don't know what changed)

The next steps should be the following:
6. Rebuild python-extras with tests turned on
7. Rebuild python-traceback2 with tests turned on
8. Rebuild python-linecache2 with tests turned on

Unfortunately, steps 6-8 are broken, because somebody updated
python-unittest2 from version 0.8.0 to version 1.1.0 yesterday, and
python-traceback2 requires version 0.8.0.  Really requires version
0.8.0.  Try step 6.  The python *2* build fails.  I think
python-unittest2 will have to be rolled back to version 0.8.0, unless
someone wants to figure out how to update python-traceback2.

Anyway, here's hoping somebody has time to finish untangling the
situation.  If not, I'll take it up again when I can find some free
time.  Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Adam Miller]

On Fri, Nov 13, 2015 at 3:47 PM, Ralph Bean  wrote:
> On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
>> Hi,
>>
>> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
>>  wrote:
>> > If we were to go with the former rather than the latter, we would need
>> > to find a way to "namespace" container images so they can be
>> > determined as different. I've thought about this a lot and I worry
>> > about defining a namespace by some alphanumberic sequence because I
>> > just know that at some point there will end up being a piece of
>> > software in the ecosystem that we want to package as a rpm that will
>> > share this pattern and result in problematic filtering. We could
>> > accept that risk and simply say "this sequence is a reserved word" or
>> > use a special character as the leading character in a DistGit
>> > repository name to signify that it is a container.
>>
>> git repositories normally use '/' to separate namespaces, so i'd propose
>>
>> $ fedpkg clone containers/cockpit
>>
>> and maybe add support for
>>
>> $ fedpkg clone srpms/cockpit
>>
>> at the same time.
>>
>> This has the added benefit that cgit will automatically filter docker
>> reposistories when you visit, e.g,
>>
>> http://pkgs.fedoraproject.org/cgit/containers/
>
> I like this too.  Here are three thoughts:
>
> Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
> because presumably there will be some whole new way to build
> containers in 2017, and we'll need to keep our dockerfiles/ repos
> separate from our awesomefiles/ repos.
>
> We could also use this opportunity to move the kickstarts (another
> input to koji builds) away from https://fedorahosted.org/spin-kickstarts
> and over to dist-git as well, with a namespace like 'kickstarts/kde'
> and 'kickstarts/lxde'.
>
> The existing rpm content could be moved to a 'specfiles/' namespace
> (or maybe 'srpms/'?) but we could further add some apache httpd rules that
> respond with a redirect to the 'srpms/' namespace if the requests to
> the base namespaceless-namespace level are met with a 404. -- "when in
> doubt, default to srpms/".  That might help keep some of our existing
> tools working as-is without too much catastrophe.

+1

I'm a big fan of where this is going.

Maybe we should draft a proposal around this (maybe some notes in
gobby?) and then start a new thread under a new name to generate more
general discussion around this in the context of being able to deliver
many different kinds of artifact for Fedora.Next. My only fear of
continuing this topic thread is that folks who aren't interested in
containers or docker might not be tuned in because of the subject
line.

Thoughts?

-AdamM

>
> --
> 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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Ralph Bean]

On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
> Hi,
> 
> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
>  wrote:
> > If we were to go with the former rather than the latter, we would need
> > to find a way to "namespace" container images so they can be
> > determined as different. I've thought about this a lot and I worry
> > about defining a namespace by some alphanumberic sequence because I
> > just know that at some point there will end up being a piece of
> > software in the ecosystem that we want to package as a rpm that will
> > share this pattern and result in problematic filtering. We could
> > accept that risk and simply say "this sequence is a reserved word" or
> > use a special character as the leading character in a DistGit
> > repository name to signify that it is a container.
> 
> git repositories normally use '/' to separate namespaces, so i'd propose
> 
> $ fedpkg clone containers/cockpit
> 
> and maybe add support for
> 
> $ fedpkg clone srpms/cockpit
> 
> at the same time.
> 
> This has the added benefit that cgit will automatically filter docker
> reposistories when you visit, e.g,
> 
> http://pkgs.fedoraproject.org/cgit/containers/

I like this too.  Here are three thoughts:

Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
because presumably there will be some whole new way to build
containers in 2017, and we'll need to keep our dockerfiles/ repos
separate from our awesomefiles/ repos.

We could also use this opportunity to move the kickstarts (another
input to koji builds) away from https://fedorahosted.org/spin-kickstarts
and over to dist-git as well, with a namespace like 'kickstarts/kde'
and 'kickstarts/lxde'.

The existing rpm content could be moved to a 'specfiles/' namespace
(or maybe 'srpms/'?) but we could further add some apache httpd rules that
respond with a redirect to the 'srpms/' namespace if the requests to
the base namespaceless-namespace level are met with a 404. -- "when in
doubt, default to srpms/".  That might help keep some of our existing
tools working as-is without too much catastrophe.


signature.asc
Description: PGP signature
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Jaroslav Nahorny]

Josh Boyer  writes:

> On Fri, Nov 13, 2015 at 1:45 PM, Michael Catanzaro
>  wrote:
>> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>>> In both the FedRTC and debian case how many calls are made a
>>> day/month, what is the volume of XMPP etc? In the later case we
>>> already use both IRC and Telegram within the community, I'm not sure
>>> what value yet another text messaging service provides.
>>
>> Well we could use this to replace our IRC meetings. We could finish
>> meetings much faster over SIP than with IRC. It's kind of primitive
>> that we don't have a good way to do voice and video calls right now.
>
> We don't do IRC because of lack of voice or video.  We do IRC because
> it scales to whomever wants to participate.

+1

> Doing Fedora meetings in voice or video introduces limitations in the
> number of concurrent attendees, both as participants and lurkers.

And IRC sets much lower bandwidth requirements for users who want to
join. And works better for people with hearing disabilities

> It also enforces some amount of order to the meeting itself.  IRC also
> makes it extremely easy to provide exact logs of the discussions in
> addition to the minutes.

+1

>
> So if we are going to replace that with voice/video, we need to make
> sure it scales to a very large number of people, we have someone doing
> their best to transcribe things, and we have recording capabilities so
> people can replay it if they cannot attend.

+1

To be honest I rarely participate in Fedora IRC meetings. My thoughts
are based on 15+ years of experience with IRC, and alternative instant
communication technologies (XMPP, voice, video).

The biggest advantage of IRC for me is, you can always easily find
interesting pieces of talk by grepping logs. I wouldn't want to watch
hours of videos, to find what I'm looking for.

-- 
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: FedRTC.org SIP and XMPP service - help needed

[Daniel Pocock]

On 13/11/15 19:45, Michael Catanzaro wrote:
> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>> In both the FedRTC and debian case how many calls are made a
>> day/month, what is the volume of XMPP etc? In the later case we
>> already use both IRC and Telegram within the community, I'm not sure
>> what value yet another text messaging service provides.
> 
> Well we could use this to replace our IRC meetings. We could finish
> meetings much faster over SIP than with IRC. It's kind of primitive
> that we don't have a good way to do voice and video calls right now.
> At least I've never used Telegram, or seen anyone using it; it doesn't
> work with Empathy AFAIK; do we even have a GNOME Telegram client?
> 


Telegram is coming to Telepathy/Empathy:

https://akulichalexandr.wordpress.com/2015/03/24/telegram-connection-manager-the-first-release-is-going-on/

https://github.com/TelepathyQt/telepathy-morse

but Telegram is not based on an open server.  The server is proprietary.
 Although they promise that messages are encrypted, they do have
metadata, so they know who you know and when you contacted somebody,
those details alone can be quite valuable for a range of purposes that
are not in the best interests of the user.

XMPP has MUC, a text-based alternative to IRC.  I'm not sure if there is
a compelling reason to change from IRC though.

There are certain situations where voice and video are useful though,
for example, making training presentations, interviewing GSoC students
or demonstrating how well Fedora does multimedia.

Regards,

Daniel
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Josh Boyer]

On Fri, Nov 13, 2015 at 1:45 PM, Michael Catanzaro
 wrote:
> On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
>> In both the FedRTC and debian case how many calls are made a
>> day/month, what is the volume of XMPP etc? In the later case we
>> already use both IRC and Telegram within the community, I'm not sure
>> what value yet another text messaging service provides.
>
> Well we could use this to replace our IRC meetings. We could finish
> meetings much faster over SIP than with IRC. It's kind of primitive
> that we don't have a good way to do voice and video calls right now.

We don't do IRC because of lack of voice or video.  We do IRC because
it scales to whomever wants to participate.  Doing Fedora meetings in
voice or video introduces limitations in the number of concurrent
attendees, both as participants and lurkers.  It also enforces some
amount of order to the meeting itself.  IRC also makes it extremely
easy to provide exact logs of the discussions in addition to the
minutes.

So if we are going to replace that with voice/video, we need to make
sure it scales to a very large number of people, we have someone doing
their best to transcribe things, and we have recording capabilities so
people can replay it if they cannot attend.

josh
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Michael Catanzaro]

On Fri, Nov 13, 2015 at 1:20 AM, Peter Robinson  wrote:
> In both the FedRTC and debian case how many calls are made a
> day/month, what is the volume of XMPP etc? In the later case we
> already use both IRC and Telegram within the community, I'm not sure
> what value yet another text messaging service provides.

Well we could use this to replace our IRC meetings. We could finish
meetings much faster over SIP than with IRC. It's kind of primitive
that we don't have a good way to do voice and video calls right now.
At least I've never used Telegram, or seen anyone using it; it doesn't
work with Empathy AFAIK; do we even have a GNOME Telegram client?
-- 
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: Summary/Minutes for today's FESCo meeting (2015-11-11)

[Matthew Miller]

On Wed, Nov 11, 2015 at 01:54:32PM -0500, Adam Jackson wrote:
> * #1278 establish Fedora Bat-Signal for ultra-critical security updates
>   (ajax, 18:02:25)
>   * LINK: https://fedorahosted.org/fesco/ticket/1278   (ajax, 18:02:31)
>   * Removed from meeting agenda until ticket is updated  (ajax,
> 18:04:24)

FTR, I *did* have a talk with Sparks last week which included this.
I'll continue to follow up.

-- 
Matthew Miller

Fedora Project Leader
-- 
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: Review swaps

[Jerry James]

On Fri, Nov 13, 2015 at 8:18 AM, Sandro Mani  wrote:
> If you're okay with mingw packages, I'd like to have these two reviewed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1265853
> https://bugzilla.redhat.com/show_bug.cgi?id=1265854
>
> Both are straight forward.

Sure, will do.  Thanks, Sandro!
-- 
Jerry James
http://www.jamezone.org/
-- 
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: Python 3.5 for Fedora 23 in COPR

[Abdel G . Martínez L .]

Great work!

2015-11-13 7:52 GMT-05:00 Matej Stuchlik :

> Hey folks,
> a while ago I've created a COPR repo [0] with Python 3.5 for f23,
> I haven't had any bug reports so far, so it should be OK to use.
>
> You can install it with:
>
> $ dnf copr enable -y mstuchli/Python3.5
> $ dnf install -y python35-python3
>
> Then you can use the python3.5 and pip3.5 executables.
>
> Some more information is available at [1].
>
> Enjoy!
>
> [0] https://copr.fedoraproject.org/coprs/mstuchli/Python3.5/
> [1] http://synfo.github.io/2015/11/13/Python-3.5-in-Fedora/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
*Abdel G. Martínez L.*
-- 
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: Review swaps

[Sandro Mani]

On 13.11.2015 16:09, Jerry James wrote:

Here are the next 2 steps on the long slow march to the gap HAP
package for sagemath.  Only a few left to go!  Let me know what I can
review for you in exchange for these reviews.

gap-pkg-smallsemi: https://bugzilla.redhat.com/show_bug.cgi?id=1281664
gap-pkg-semigroups: https://bugzilla.redhat.com/show_bug.cgi?id=1274568

Note that gap-pkg-semigroups BRs gap-pkg-smallsemi.  Thanks!

Hi

If you're okay with mingw packages, I'd like to have these two reviewed:

https://bugzilla.redhat.com/show_bug.cgi?id=1265853
https://bugzilla.redhat.com/show_bug.cgi?id=1265854

Both are straight forward.

Sandro

--
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: Failing builds on rawhide

[Kalev Lember]

On 11/13/2015 04:01 PM, Antonio Trande wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> still problems on rawhide/python3.5?
> 
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
> Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
> Child return code was: 1
> EXCEPTION: Command failed. See logs for output.
>  # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
> /builddir/build/SPECS/libsbml.spec
> Traceback (most recent call last):
>   File
> "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py", line
> 84, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.4/site-packages/mockbuild/util.py", line 520,
> in do
> raise exception.Error("Command failed. See logs for output.\n #
> %s" % (command,), child.returncode)
> mockbuild.exception.Error: Command failed. See logs for output.
>  # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
> /builddir/build/SPECS/libsbml.spec
> 
> https://kojipkgs.fedoraproject.org//work/tasks/9975/11819975/build.log

The actual error is higher up in the log file. No idea what to make of
it, but maybe it helps you figure out what's going on:

cd /builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python && 
/usr/bin/python3 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py
 -f 
/builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python/pydoc-doxygen.i
 -o 
/builddir/build/BUILD/libSBML-5.12.0-Source/build/src/bindings/python/pydoc-normal.i
 -i 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/../../../docs/src/common-text
 -g 
/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/../../../docs/src/common-graphics
Traceback (most recent call last):
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 808, in 
main()
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 803, in main
graphics_dir, quietly)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 275, in rewrite
return p.sub(lambda match: rewrite_each(match, include_dir, graphics_dir, 
quietly), contents)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 275, in 
return p.sub(lambda match: rewrite_each(match, include_dir, graphics_dir, 
quietly), contents)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 289, in rewrite_each
body = rewrite_one_body(body, include_dir, graphics_dir, quietly)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 317, in rewrite_one_body
body = p.sub(lambda match: rewrite_htmlinclude(match, include_dir, 
quietly), body)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 317, in 
body = p.sub(lambda match: rewrite_htmlinclude(match, include_dir, 
quietly), body)
  File 
"/builddir/build/BUILD/libSBML-5.12.0-Source/src/bindings/python/doc-converter/rewrite_pydoc.py",
 line 599, in rewrite_htmlinclude
parser = RewritePydocHTMLParser(AbstractFormatter(writer))
TypeError: __init__() takes 1 positional argument but 2 were given
src/bindings/python/CMakeFiles/binding_python_swig.dir/build.make:517: recipe 
for target 'src/bindings/python/libsbml_wrap.cpp' failed
make[2]: Leaving directory '/builddir/build/BUILD/libSBML-5.12.0-Source/build'
CMakeFiles/Makefile2:2933: recipe for target 
'src/bindings/python/CMakeFiles/binding_python_swig.dir/all' failed
make[2]: *** [src/bindings/python/libsbml_wrap.cpp] Error 1


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

Review swaps

[Jerry James]

Here are the next 2 steps on the long slow march to the gap HAP
package for sagemath.  Only a few left to go!  Let me know what I can
review for you in exchange for these reviews.

gap-pkg-smallsemi: https://bugzilla.redhat.com/show_bug.cgi?id=1281664
gap-pkg-semigroups: https://bugzilla.redhat.com/show_bug.cgi?id=1274568

Note that gap-pkg-semigroups BRs gap-pkg-smallsemi.  Thanks!
-- 
Jerry James
http://www.jamezone.org/
-- 
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: Failing builds on rawhide

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

still problems on rawhide/python3.5?

RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
Bad exit status from /var/tmp/rpm-tmp.sPV9pz (%build)
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
/builddir/build/SPECS/libsbml.spec
Traceback (most recent call last):
  File
"/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py", line
84, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.4/site-packages/mockbuild/util.py", line 520,
in do
raise exception.Error("Command failed. See logs for output.\n #
%s" % (command,), child.returncode)
mockbuild.exception.Error: Command failed. See logs for output.
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
/builddir/build/SPECS/libsbml.spec

https://kojipkgs.fedoraproject.org//work/tasks/9975/11819975/build.log

- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWRfsqAAoJEF5tK7VWXmU8/sMIAL2Vn/sjloJEAX2OEk2krBkM
kKiIUCHPkbbHpyD781l3GZJicFmRwfLyMQkWj7PovTqGCHy6jMqLq/nanzSvB0Me
R9sv0zFs98pVAsNULfjwmYWE1udzgY/L0/nAbBnNgoZMnC7S6Az/s03d2NkqkiP6
2YWDdSEerQaPoMK6aQUGje9I1YEpgmoR52mRdz+SLWi69TuWDC/hP1PrH2hEtEEd
nxjibBxz56ds80WD+RZpr9GF48UmZ30SYYt7oe7lMTB+Poel4rokS/SftOSm4/Ws
HGt+XTB7RauvgEZTm/1lPJ350Sg8uMMDxyOTyKpLsg0mKKRWls53FTV9hGNnUag=
=YBOi
-END PGP SIGNATURE-
-- 
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: copr - hung or out of control build .. ? infrastructure help

[Miroslav Suchý]

Dne 13.11.2015 v 13:30 David Timms napsal(a):
> Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
> 12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
> something has gone wrong... No logs yet for it.
> 
> https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/

I see it as succeeded, so your problems are likely resolved now :)

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20151113 compose check report

[Fedora compose checker]

Missing expected images:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Workstation live x86_64
Workstation live i386
Minimal disk raw armhfp
Kde disk raw armhfp
Kde live i386
Cloud disk raw x86_64
Kde live x86_64

No images in this compose but not Rawhide 20151112

Images in Rawhide 20151112 but not this:

Mate live i386

Failed openQA tests: 47 of 47

ID: 8288Test: i386 generic_boot default_install
ID: 8287Test: x86_64 generic_boot default_install@uefi
ID: 8286Test: x86_64 generic_boot default_install
ID: 8285Test: i386 universal upgrade_desktop_32bit
ID: 8284Test: i386 universal server_lvmthin
ID: 8283Test: i386 universal server_ext3
ID: 8282Test: i386 universal server_btrfs
ID: 8281Test: i386 universal server_software_raid
ID: 8280Test: i386 universal server_simple_encrypted
ID: 8279Test: i386 universal server_repository_http_graphical
ID: 8278Test: i386 universal server_scsi_updates_img
ID: 8277Test: i386 universal package_set_minimal
ID: 8276Test: x86_64 universal server_no_swap@uefi
ID: 8275Test: x86_64 universal server_lvmthin@uefi
ID: 8274Test: x86_64 universal server_ext3@uefi
ID: 8273Test: x86_64 universal server_btrfs@uefi
ID: 8272Test: x86_64 universal server_software_raid@uefi
ID: 8271Test: x86_64 universal server_multi_empty@uefi
ID: 8270Test: x86_64 universal server_simple_free_space@uefi
ID: 8269Test: x86_64 universal server_simple_encrypted@uefi
ID: 8268Test: x86_64 universal server_delete_partial@uefi
ID: 8267Test: x86_64 universal server_delete_pata@uefi
ID: 8266Test: x86_64 universal server_sata_multi@uefi
ID: 8265Test: x86_64 universal european_language_install
ID: 8264Test: x86_64 universal server_shrink_ntfs
ID: 8263Test: x86_64 universal server_shrink_ext4
ID: 8262Test: x86_64 universal server_updates_img_local
ID: 8261Test: x86_64 universal upgrade_desktop_64bit
ID: 8260Test: x86_64 universal upgrade_minimal_64bit
ID: 8259Test: x86_64 universal server_kickstart_hdd
ID: 8258Test: x86_64 universal server_no_swap
ID: 8257Test: x86_64 universal server_lvmthin
ID: 8256Test: x86_64 universal server_ext3
ID: 8255Test: x86_64 universal server_btrfs
ID: 8254Test: x86_64 universal server_software_raid
ID: 8253Test: x86_64 universal server_multi_empty
ID: 8252Test: x86_64 universal server_simple_free_space
ID: 8251Test: x86_64 universal server_simple_encrypted
ID: 8250Test: x86_64 universal server_delete_partial
ID: 8249Test: x86_64 universal server_repository_http_variation
ID: 8248Test: x86_64 universal server_repository_http_graphical
ID: 8247Test: x86_64 universal server_mirrorlist_graphical
ID: 8246Test: x86_64 universal server_delete_pata
ID: 8245Test: x86_64 universal server_kickstart_user_creation
ID: 8244Test: x86_64 universal server_scsi_updates_img
ID: 8243Test: x86_64 universal server_sata_multi
ID: 8242Test: x86_64 universal package_set_minimal
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Python 3.5 for Fedora 23 in COPR

[Matej Stuchlik]

Hey folks,
a while ago I've created a COPR repo [0] with Python 3.5 for f23,
I haven't had any bug reports so far, so it should be OK to use.

You can install it with:

$ dnf copr enable -y mstuchli/Python3.5
$ dnf install -y python35-python3

Then you can use the python3.5 and pip3.5 executables.

Some more information is available at [1].

Enjoy!

[0] https://copr.fedoraproject.org/coprs/mstuchli/Python3.5/
[1] http://synfo.github.io/2015/11/13/Python-3.5-in-Fedora/ 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

copr - hung or out of control build .. ? infrastructure help

[David Timms]

Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
something has gone wrong... No logs yet for it.

https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/

Can I, should I kill the build and if so how ?

Also, I had earlier tried the same on koji, but that failed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11804001

I can't see what has gone wrong in the logs there ?

- this also doesn't show up in:
http://koji.fedoraproject.org/koji/packageinfo?packageID=1352

btw, local mock build on f22 for rawhide (f24) suceeded.

Dave.
-- 
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: Summary/Minutes for today's FESCo meeting (2015-11-11)

[Josh Boyer]

On Nov 13, 2015 12:03 AM, "Scott Schmit"  wrote:
>
> On Wed, Nov 11, 2015 at 01:54:32PM -0500, Adam Jackson wrote:
> > ===
> > #fedora-meeting: FESCO (2015-11-11)
> > ===
>
> The meeting summary isn't showing the resolutions from the meetings
> properly.  Reading the summary...
>
> > Meeting summary
> > ---
> > * #1491 clarifications/improvements for new bundling policy  (ajax,
> >   18:04:48)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1491   (ajax, 18:04:48)
> >
> > * 1478 F24 Self Contained Changes  (ajax, 18:31:31)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1478   (ajax, 18:31:32)
> >
> > * 1496 OpenH264 solution.fesco 1496  (ajax, 18:41:50)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1496   (ajax, 18:41:51)
>
> ...discussion occurred on these topics, but nothing was agreed upon.
>
> According to the below...
>
> > 18:04:48  #topic #1491 clarifications/improvements for new
> > bundling policy
> > 18:28:29  #approved bundled libs must be appropriately filtered
> > from rpm Provides as documented in
> >
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
> > (+6 -0)
>
> > 18:31:31  #topic 1478 F24 Self Contained Changes
> > 18:33:57  #approved Change is approved (+6 -0)
>
> > 18:41:50  #topic 1496 OpenH264 solution.fesco 1496
> > 18:45:44  #approved Proposal is approved (+7 -0)
>
> ...that was not the case.

Wrong zodbot keyword.  It should have been #agreed.  The items were
approved and the tickets updated correctly though.

josh
-- 
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 is completly unable to act with local packages

[Reindl Harald]

Am 13.11.2015 um 12:13 schrieb Reindl Harald:



Am 13.11.2015 um 12:09 schrieb Honza Šilhan:

From: "Reindl Harald" 
would not be a topic if DNF would not be completly broken for "dnf
update *.rpm", in F22 it works sometimes while in F23 it is just
unuseable 99.9% of the time


That's an important information, it would be great if you would cooperate
mentioning it in your bug report and attaching the debugdata as was
requested
for each system. DNF versions are the same for F22 and F23 so I guess
that would
be a a different packaging of the local packages - we will know from
the debugdata


just download a random set of sub-packages with stricht versioned
inter-package dependencies from koji, type "dnf update *.rpm" and you
have your debug data


you have *all needed* informations to reproduce long ago

dnf downgrade dhcp\*

https://koji.fedoraproject.org/koji/buildinfo?buildID=695813


[root@srv-rhsoft:/downloads]$ dnf update *.rpm
Last metadata expiration check performed 0:11:21 ago on Fri Nov 13 
12:11:48 2015.

Fehler: package dhcp-common-12:4.3.3-6.fc23.noarch is not installable.
package dhcp-libs-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-server-12:4.3.3-6.fc23.x86_64 is not installable
(try to add '--allowerasing' to command line to replace conflicting 
packages)



[root@srv-rhsoft:/downloads]$ ls
insgesamt 1,2M
-rw-r- 1 harry verwaltung 299K 2015-11-13 12:21 
dhcp-client-4.3.3-6.fc23.x86_64.rpm
-rw-r- 1 harry verwaltung 193K 2015-11-13 12:22 
dhcp-common-4.3.3-6.fc23.noarch.rpm
-rw-r- 1 harry verwaltung 137K 2015-11-13 12:21 
dhcp-libs-4.3.3-6.fc23.x86_64.rpm
-rw-r- 1 harry verwaltung 512K 2015-11-13 12:21 
dhcp-server-4.3.3-6.fc23.x86_64.rpm



https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c9

--> Starting dependency resolution
--> Finished dependency resolution
Error: nothing provides dhcp-common = 12:4.3.3-6.fc23 needed by 
dhcp-client-12:4.3.3-6.fc23.x86_64.

package dhcp-common-12:4.3.3-6.fc23.noarch is not installable.
package dhcp-compat-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-libs-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-relay-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-server-12:4.3.3-6.fc23.x86_64 is not installable.
package grep-2.22-1.fc23.x86_64 is not installable.
package nss-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-sysinit-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-tools-3.20.1-1.0.fc23.x86_64 is not installable




signature.asc
Description: OpenPGP digital signature
-- 
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: packaging golang guidelines (like etcd, consul)

[Muayyad AlSadi]

> At this time, Go libraries packaged in Fedora are primarily for the
purpose of being BuildRequires for building Fedora binary RPMs,

since golang is like statically linked and does not prefer .so for
libraries (so far). I suggest never package BuildRequires RPMs for golang
(I think of it like .a libraries)

and for the offline building of golang binaries like etcd we might collect
dependencies in a way similar to python wheel and include them in the
.src.rpm

%build
tar -xzf %SOURCE2 -C golang-path/
...





On Sun, Nov 8, 2015 at 5:35 AM, Adam Goode  wrote:

> On Fri, Nov 06, 2015 at 10:11:08AM -0500, Jakub Cajka wrote:
> > - Original Message -
> > > From: "Adam Goode" 
> > > To: devel at lists.fedoraproject.org
> > > Cc: "Matthew Miller" 
> > > Sent: Friday, November 6, 2015 3:47:42 PM
> > > Subject: Re: packaging golang guidelines (like etcd, consul)
> > >
> > > On Mon, Nov 02, 2015 at 09:05:09AM -0500, Matthew Miller wrote:
> > > > On Sun, Nov 01, 2015 at 05:44:42PM +0100, Jan Chaloupka wrote:
> > > > > >are there some fedora guidelines for golang apps?
> > > > > >are there macros and helpers for rpm?
> > > > > https://fedoraproject.org/wiki/PackagingDrafts/Go
> > > >
> > > > This needs help in going from a draft to real guidelines.
> > > >
> > >
> > > I am also trying to figure this out. Looking at actual
> > > packaged golang things in Fedora, I see quite a difference
> > > between the drafts and what I see in specfiles. There
> > > are a lot of macros copied everywhere.
> > >
> >
> > Could you please elaborate.
> >
>
> I figured it out. The generated packages are all from gofed.
> They all share a lot of generated macros and comments.
>
> > >
> > > Is there any more up to date guidance? It would be an
> > > improvement to even just copy/paste emails of discussions
> > > into the bottom of the wiki draft.
> > >
> >
> > This(https://fedoraproject.org/wiki/PackagingDrafts/Go)
> > should be most up to date. For discussion see FPC ticket
> > https://fedorahosted.org/fpc/ticket/382.
> >
> > Any input will be welcomed.
>
> When I was looking to make the specfile, I jumped right to the
> section in the wiki with the sample. I missed gofed completely.
> I will add a note to the wiki suggesting to try gofed repo2spec
> first before trying one of the sample specfiles in the page.
>
> >
> > Jakub
> >
> > >
> > >
> > > Adam
>
> Thanks for the help!
>
>
> Adam
> --
> 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 is completly unable to act with local packages

[Reindl Harald]

Am 13.11.2015 um 12:09 schrieb Honza Šilhan:

From: "Reindl Harald" 
would not be a topic if DNF would not be completly broken for "dnf
update *.rpm", in F22 it works sometimes while in F23 it is just
unuseable 99.9% of the time


That's an important information, it would be great if you would cooperate
mentioning it in your bug report and attaching the debugdata as was requested
for each system. DNF versions are the same for F22 and F23 so I guess that would
be a a different packaging of the local packages - we will know from the 
debugdata


just download a random set of sub-packages with stricht versioned 
inter-package dependencies from koji, type "dnf update *.rpm" and you 
have your debug data




signature.asc
Description: OpenPGP digital signature
-- 
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 is completly unable to act with local packages

[Honza Šilhan]

> From: "Honza Šilhan" 
> > From: "Michael Schwendt" 
> > If an _upgrade_ introduces new sub-packages or new dependencies, you
> > need a method that can install those new packages *and* update older
> > installed ones at the same time. Running "rpm -U *.rpm" is like asking
> > RPM to "upgrade the installation to the packages specified by *.rpm",
> > which may involve replacing older installed ones as well as adding new
> > packages to the installation.
> 
> I was suggesting that it would be possible to extend `strict` configuration
> option
> for updates. That means with `dnf update *.rpm --strict=0` you would achieve
> what you
> have said in this paragraph.

I made a mistake. It should be this command line `dnf update *.rpm 
--setopt=strict=0`.

Honza
-- 
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 is completly unable to act with local packages

[Honza Šilhan]

> From: "Michael Schwendt" 
> 
> On Thu, 12 Nov 2015 06:38:41 -0500 (EST), Honza Šilhan wrote:
> 
> > "rpm -Uvh …" ~ "dnf install" - only difference is that dnf install can
> > do downgrades too if you specify the version of the package
> 
> So, if you run "dnf install *.rpm" and one of the local .rpm files is
> older than what is installed, you cannot use that command because it
> would want to perform a downgrade?

If you don't want the downgrade to be applied you should exclude that package
from cmdline (-x) or from the folder beforehand.

> From: "Reindl Harald" 
> would not be a topic if DNF would not be completly broken for "dnf
> update *.rpm", in F22 it works sometimes while in F23 it is just
> unuseable 99.9% of the time

That's an important information, it would be great if you would cooperate
mentioning it in your bug report and attaching the debugdata as was requested
for each system. DNF versions are the same for F22 and F23 so I guess that would
be a a different packaging of the local packages - we will know from the 
debugdata.

> From: "Michael Schwendt" 
> If an _upgrade_ introduces new sub-packages or new dependencies, you
> need a method that can install those new packages *and* update older
> installed ones at the same time. Running "rpm -U *.rpm" is like asking
> RPM to "upgrade the installation to the packages specified by *.rpm",
> which may involve replacing older installed ones as well as adding new
> packages to the installation.

I was suggesting that it would be possible to extend `strict` configuration 
option
for updates. That means with `dnf update *.rpm --strict=0` you would achieve 
what you
have said in this paragraph.


Honza
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Daniel Pocock]

On 13/11/15 10:20, Peter Robinson wrote:
> On Fri, Nov 13, 2015 at 8:19 AM, Daniel Pocock  wrote:
>>
>>
>> On 13/11/15 00:00, Jared K. Smith wrote:
>>>
>>> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock >> > wrote:
>>>
>>> I've been looking at ways to expand on the fedrtc.org
>>>  service and would
>>> like to start creating a team around the service just as we did in
>>> Debian[1].
>>>
>>>
>>>
>>> Ordinarily I'd probably be the first to encourage this, but having done
>>> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
>>> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
>>> Talk, we saw that the service wasn't used very much, and while the
>>> maintenance burden on the Infra team wasn't big, it was still one more
>>> thing they had to worry about, and something that the didn't feed 100%
>>> confident in administering.  Do you have any statistics on how much the
>>> service is being used by Fedora contributors?
>>>
>>
>>
>> I replied to those same queries on the infrastructure mailing list[1]
>> and I've largely copied the reply.
> 
> 
> 
>> Actual stats: 26 people have tried the service so far.  In Debian, we
>> have had over 200 people (about 25% of developers).  FedRTC.org has not
>> been promoted as an official service so I think it is reasonable to
>> suggest usage will increase if it becomes officially supported and if
>> XMPP is part of it too.
> 
> Those aren't stats. By "tried" do you mean created an account and
> logged a SIP/XMPP client to the service? Or are actively use it?
> 

I'm not monitoring it and reporting on it to the same extent.  The
previous service, based on Asterisk, would have been collecting call
records in a CSV file but SIP proxies don't exactly work like a PBX so
they don't log to a CSV file.  For example, would every status update or
chat message be logged just like a voice call?  SIP proxies can also
operate statelessly, so the INVITE that starts a call may pass through
one proxy and the BYE to end the call may pass through another.  This
architecture is distributed, resilient and lightweight but not ideal for
fine-grained activity monitoring.

I do have a task to add Ganglia integration to the SIP proxy, this would
track a number of things like SIP requests and responses per second:
https://www.resiprocate.org/bugzilla/show_bug.cgi?id=98

That is intended for operational purposes such as capacity planning but
I could also provide some metrics useful for evaluating community
engagement.

The Prosody XMPP server could do something similar.  If the buddy lists
are stored in PostgreSQL then the usage can be evaluated with an SQL query.


> In both the FedRTC and debian case how many calls are made a
> day/month, what is the volume of XMPP etc? In the later case we
> already use both IRC and Telegram within the community, I'm not sure
> what value yet another text messaging service provides.
> 
> What happens if it was possible to delegate a DNS record(s) and
> provide FAS integration and have it hosted somewhere else in the short
> to medium term to see how popular it is with proper named and "buddy
> lists" than can be migrated if it becomes overwhelmingly popular with
> proper stats to back it up?
> 

Yes, it would be very easy to migrate:

- install the packages from EPEL7

- dump and load the PostgreSQL databases

- copy stuff from /etc/repro, /etc/reTurn and /etc/prosody and use sed
to swap the IP addresses

- change DNS entries

If it is running on my own servers as suggested in the alternative
strategy then I would be happy to give access to somebody from the
Fedora infrastructure team so they can take a snapshot of the data
(buddy lists and password hashes) whenever they like.  We could even
look at a hybrid approach where the servers connect to a PostgreSQL
instance on Fedora infrastructure.

Regards,

Daniel
-- 
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: F23: r8169 stopped working

[Jos Vos]

On Fri, Nov 13, 2015 at 08:02:58AM +0100, Jos Vos wrote:

> I did some further tests:
> 
> -  Also the F23 Live image works fine (with 4.2.3 kernel), no issues
>with the Ethernet, I get an immediate connection, flawless...
>And: also suspend/resume works fine there (see below).
> 
> -  F23 installed (with all updates): no Ethernet working and resume
>after suspend doesn't turn on backlight of the laptop (system is
>running fine, I can remotely login via wifi), while resuming with
>backlight works perfectly using the F23 live image.

Update: the suspend issue was solved by *removing* "nomodeset" from
the boot command line in the grub config (I compared the command lines
of the Live image and the installed version).

The Ethernet card started working when I *enabled* secure boot in the
BIOS, but it (in most cases?) stays working when I disable it again.
Confused, as I'm wondering if this can influence the Ethernet driver
or is this just a random coincidence?

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--Amsterdam, The Netherlands| Fax: +31 20 6948204
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Peter Robinson]

On Fri, Nov 13, 2015 at 8:19 AM, Daniel Pocock  wrote:
>
>
> On 13/11/15 00:00, Jared K. Smith wrote:
>>
>> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock > > wrote:
>>
>> I've been looking at ways to expand on the fedrtc.org
>>  service and would
>> like to start creating a team around the service just as we did in
>> Debian[1].
>>
>>
>>
>> Ordinarily I'd probably be the first to encourage this, but having done
>> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
>> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
>> Talk, we saw that the service wasn't used very much, and while the
>> maintenance burden on the Infra team wasn't big, it was still one more
>> thing they had to worry about, and something that the didn't feed 100%
>> confident in administering.  Do you have any statistics on how much the
>> service is being used by Fedora contributors?
>>
>
>
> I replied to those same queries on the infrastructure mailing list[1]
> and I've largely copied the reply.



> Actual stats: 26 people have tried the service so far.  In Debian, we
> have had over 200 people (about 25% of developers).  FedRTC.org has not
> been promoted as an official service so I think it is reasonable to
> suggest usage will increase if it becomes officially supported and if
> XMPP is part of it too.

Those aren't stats. By "tried" do you mean created an account and
logged a SIP/XMPP client to the service? Or are actively use it?

In both the FedRTC and debian case how many calls are made a
day/month, what is the volume of XMPP etc? In the later case we
already use both IRC and Telegram within the community, I'm not sure
what value yet another text messaging service provides.

What happens if it was possible to delegate a DNS record(s) and
provide FAS integration and have it hosted somewhere else in the short
to medium term to see how popular it is with proper named and "buddy
lists" than can be migrated if it becomes overwhelmingly popular with
proper stats to back it up?


-- 
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: Retire a package from Fedora i686 (not x86_64)

[Reindl Harald]

Am 12.11.2015 um 21:49 schrieb Przemek Klosowski:

On the other hand, Harald, I have to say that in this case my irony
detector bent the needle. You often voice your displeasure in this forum
that some setup you used for years was broken by new stuff, and yet you say

you CAN NOT HAVE both - leading edge software and legacy support forever


I just see this quoted back at you in the future :)


it's a difference replacing working software with some 
alpha/beta-quality stuff lacking half of the features and waiting years 
to get useable as before or just drop the support for hardware older 
than 10 years for the sake of use capabilities of more recent one




signature.asc
Description: OpenPGP digital signature
-- 
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: FedRTC.org SIP and XMPP service - help needed

[Daniel Pocock]

On 13/11/15 00:00, Jared K. Smith wrote:
> 
> On Thu, Nov 12, 2015 at 2:36 PM, Daniel Pocock  > wrote:
> 
> I've been looking at ways to expand on the fedrtc.org
>  service and would
> like to start creating a team around the service just as we did in
> Debian[1].
> 
> 
> 
> Ordinarily I'd probably be the first to encourage this, but having done
> a lot of the work to setup Fedora Talk many years ago, I'm not sure this
> is a good fit for Fedora Infrastructure.  Why?  Because with Fedora
> Talk, we saw that the service wasn't used very much, and while the
> maintenance burden on the Infra team wasn't big, it was still one more
> thing they had to worry about, and something that the didn't feed 100%
> confident in administering.  Do you have any statistics on how much the
> service is being used by Fedora contributors?
> 


I replied to those same queries on the infrastructure mailing list[1]
and I've largely copied the reply.

Some key things to remember when comparing statistics for debian.org and
fedrtc.org:
a) debian.org also has XMPP, this engages more people.  I didn't offer
XMPP on fedrtc.org because it will be inconvenient for people to move
their buddy lists to fedoraproject.org
b) debian.org runs it as an official service, it has been announced in
the newsletter and debian-devel-announce mailing list and other places
over a period of almost 2 years now.

I've also started a separate thread on the infrastructure list with an
alternative hosting solution[2]

Fedora Talk was based on Asterisk.
https://fedoraproject.org/wiki/Infrastructure/Asterisk
Asterisk has lots of great features (voicemail, queues, etc) but it is
mainly for voice, it emphasizes SIP and at the time it was also quite
bad with IPv6, TLS and NAT.  FedRTC.org is based on a SIP proxy, not
Asterisk.  SIP proxies (and XMPP servers) tend to have a much bigger
emphasis on connectivity and they also tend to have less features, so
they are easier to support.  The repro SIP proxy has exceptionally good
TLS and IPv6 support.  Asterisk is not really optimized for federation
but federation is quite easy with a SIP proxy because of the emphasis on
connectivity.

FedRTC.org also has a TURN server, this boosts success for people behind
NAT.

Times have changed too:

- WebRTC is here, millions of users have WebRTC capable browsers.  It is
not just voice, it lets you do voice and video with just a little HTML.
 Have a look at the page source behind fedrtc.org to see what I mean.
The only server-side scripting is the PHP for password creation.

- Google is deprecating their standards-based XMPP.  People wanting to
continue talking to friends who use real XMPP are looking for alternatives.

- Mobile: apps for mobile VoIP, video and messaging are everywhere.
Open source apps like Lumicall (for SIP) and Conversations (for XMPP)
are trivial to install.  I recently submitted a patch to K-9 Mail on
Android so people can reply to any email with a SIP or XMPP call
https://github.com/k9mail/k-9/pull/866
Android devices are, by their nature, optimized for making calls, so
these apps tend to work a lot more intuitively than first generation
desktop softphones.

The service itself is not just for usage by developers, there are two
other purposes it serves:

- it gives people a stable point of reference for testing any softphones
or chat applications packaged in Fedora.

- it it useful for demonstrations.  I demonstrated federated calling
between FedRTC.org and rtc.debian.org in several talks, including the
Debian and Ubuntu Community Conference (DUCC) in Milan earlier this year.

Actual stats: 26 people have tried the service so far.  In Debian, we
have had over 200 people (about 25% of developers).  FedRTC.org has not
been promoted as an official service so I think it is reasonable to
suggest usage will increase if it becomes officially supported and if
XMPP is part of it too.

Interaction with other communities is another big drawcard.  There are
various others doing it: Debian (both SIP and XMPP), GNOME (XMPP) and
FSFE (XMPP).  The Lumicall app allows anybody to create a SIP account
based on their phone number and FedRTC.org users can call Lumicall users
and vice-versa.  Both the SIP and XMPP services have been built for
secure federation.  Some developers already run their own private XMPP
servers and will be happy to talk to people who have a fedoraproject.org
XMPP address.

I understand the concern about this potentially creating extra work for
the infrastructure team.  In Debian, we didn't want the service to
become a burden on the DSA team and so we created a dedicated RTC team
to handle issues specific to the services.
https://wiki.debian.org/Teams/RTC
The DSA team only have to worry about keeping the machines running,
backups, package updates and dumping some data from LDAP into the files
we need.  The RTC team test and propose changes to the configuration
files and engage in discussion with

Re: Failing builds on rawhide

[Jan Synacek]

Peter Robinson  writes:

> On Thu, Nov 12, 2015 at 12:47 PM, Peter Robinson  wrote:
>> On Thu, Nov 12, 2015 at 12:41 PM, Jan Synacek  wrote:
>>> I'm getting this error:
>>>
>>> bash: /usr/bin/rpmbuild: No such file or directory
>>>
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=11804093
>>
>> I suspect that's due to python 3.5 being tagged in, it should be OK
>> shortly,  I'm keeping an eye on it.
>
> I think we should be good now, I resbumitted your task
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11804206

Thank you!
-- 
Jan Synacek
Software Engineer, Red Hat


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