Re: Unexpected NIC naming f23 firewall implications

[Tomasz Torcz]

On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote:
> > em* and p?p? come from biosdevname, which should not be used and is 
> > deprecated.
> 
> I'm merely observing what happened when I updated a bunch of servers
> from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
> at any point.

  But you should have.  Biosdevname what deprecated 3 years ago (with Fedora 19
or 20*), you should have migrated your rules to udev's naming scheme and
remove biosdevname.  This was quite long transition period, even longer 
than biosdevname usage, which was default between Fedora 15 and 19 (2 years).

  * although I can't find the mention in Release Notes for neither F19 nor F20.
We may have underdelivered on this :(

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

-- 
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: What's the current status of mp3-licensing issues?

[Joshua J Cogliati]

I believe that the current status of mp3 is it is patent free in the US
and most or all of the rest of the world. Analysis after the quoted portion.

On Thu, 01 Nov 2007 09:36:07 -0400, "Tom \"spot\" Callaway" wrote:
> On Thu, 2007-11-01 at 10:47 +0300, Peter Lemenkov wrote:
>> What about US?
> 
> The Fraunhofer/Thomson patents have not expired in the US.
> They are not willing to give us an unrestricted patent grant.
> 
> US Patent 5559834 expires September 24, 2013
> US Patent 4942607 expires February 3, 2008
> US Patent 5812672 expires September 2, 2015
> US Patent 5579430 expires November 26, 2013
> US Patent 5321729 expires June 24, 2011
> US Patent 5706309 expires January 6, 2015
> US Patent 5227990 expires July 13, 2010
> US Patent 4821260 expires December 16, 2007
> US Patent 5214742 expires May 25, 2010
> US Patent 6185539 expires February 6, 2018
> US Patent 5703999 expires November 18, 2016
> US Patent 5924060 expires July 13, 2016
> US Patent 5701346 expires February 2, 2015
> US Patent 6009399 expires April 16, 2017
> US Patent 5384811 expires January 24, 2012
> US Patent 5736943 expires April 7, 2015
> US Patent 5742735 expires April 21, 2015
> US Patent 5455833 expires October 3, 2012
> 
> In addition, Alcatel-Lucent holds patents which may relate to MP3 and
> MPEG encoding. This is still pending appeal (Alcatel-Lucent v
> Microsoft). It is not clear whether they will give out an unstricted
> patent grant.
> 
> US Patent 5341457 expires Aug 20, 2013.
> US Patent RE39,080 expires April 25, 2023.
> 
> ~spot

Here are the ones that either the analysis or mine think are
still unexpired (I am assuming we can consider the rest expired):

US Patent 5703999 expires November 18, 2016 -> December 30, 2014
US Patent RE39,080 expires April 25, 2023. -> May 6, 2014
US Patent 5924060 expires July 13, 2016 -> January 14, 2011

US Patent 6185539 expires February 6, 2018 -> February 19, 2017
US Patent 6009399 expires April 16, 2017

Here is why I think 5703999 is expired:

Patent:  5703999
Filed:  18 nov 1996  Granted:  30 dec 1997  Expiration:  32 feb 2015
Summary:  Process for reducing data in the transmission and/or storage
of digital signals from several interdependent channels  Notes:
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5703999 file+20:
[2016, 11, 18] related_patent+20:[2015, 2, 32]
Expiration date listed as November 18, 2016, but it is a continuation of
a patent filed May 18, 1993.  Expiration date should be 17 years from
1997, or Dec 30, 2014

Here is why I think RE39080 is expired:

Patent:  RE39080
Filed:  22 sep 1994  Granted:  06 may 1997  Expiration:  06 may 2014
Summary:  Rate loop processor for perceptual encoder/decoder  Notes:
Reissue of 05627938 filed 13 aug 2002 granted 25 apr 2006
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE39080 file+20:
[2014, 9, 22] related_patent+20:[2008, 12, 32] grant+17:[2014, 5, 6]
Expiration date listed as April 25, 2023.  It is a refile of a
continuation of a patent first filed in Dec 30, 1988.  Original patent
issued May 6, 1998, so expires 17 years or May 6, 2014.

Here is why I think 5924060 is expired:

Patent:  5924060
Filed:  20 mar 1997  Granted:  13 jul 1999  Expiration:  14 jan 2011
First Date:  14 jan 1991
Summary:  Digital coding process for transmission or storage of
acoustical signals by transforming of scanning values into spectral
coefficients  Notes:
http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5924060 file+20:
[2017, 3, 20] related_patent+20:[2011, 1, 14]
This application is a continuation of application Ser. No. 08/650,896,
 filed on May 17, 1996, (now abandoned) which was a continuation of
 application Ser. No. 08/519,620, filed on Sep. 25, 1995, (now abandoned)
 which was a continuation of application Ser. No. 07/977,748, filed on Nov.
 16, 1992, (now abandoned), which was a continuation of application Ser.
 No. 07/816,528, filed on Dec. 30, 1991, (now abandoned), which was a
 continuation of application Ser. No. 07/640,550, filed on Jan. 14, 1991,
 (now abandoned), which was a continuation of application Ser. No.
 07/177,550, filed on Apr. 4, 1991, (now abandoned) as international
 application serial No. PCT/DE87/00384, filed Aug. 29, 1987, claiming
 priority to foreign appl. No. P3629434.9, filed Aug. 29, 1986.
Expiration date is listed as July 13, 2016, but it is a continuation of
a patent filed 1991 and it was continued after 1996, so it expires 20
years after the first file date, or January 14, 2011


That leaves US PATENT 6185539:

http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6185539

and US PATENT 6009399

http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6009399

First of all, these were both filed in 1997.  Since the Final MPEG-1
specification (as ISO/IEC 11172-3) was published in August 1993 the
patents were filed well past the August 1994 cut off date.  Secondly,
looking at the claims, (and I am not a lawyer)  6,185,539 seems to be
discussion MPEG-2, and 6,009,399 seems t

COPR service announcement: builds failed last night

[Patrick Uiterwijk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

Due to issues with the metalink for f22 and f23 updates on ppc64 last night,
a lot of COPR tasks have failed their ppc64le chroot builds.
If you see that the x86_64 builds of of your task have succeeded, but the
ppc64le builds failed, please resubmit you job to COPR.

End of service announcement.

With kind regards,
Patrick Uiterwijk
Fedora Infra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWQV7NAAoJEIZXmA2atR5QXY0QAK8i8kjYCvsNUNbqE1A3/Slr
Jw0I+x4C9bzmTwUrRojCsknOQV1+Ym/8M4zyCJ+vwwaPxOe+/yVynK5geA/pCgq+
WJAzxco2Uad9B1/ETMF7224bwPsIvZsbGQiQPklPWi7rB6wXmJd7GNKyUpvhPiwR
HPhgW6RjZ5Y0kA0Aeo7okFCxigdenpRDMHppOJlsvl/JFe2gQAZ4kylTKN9aJE60
8x/vVDb4dSyTu1/0DixLyn+O282el7UJo4hzyLocyHcpWlmeBQ5RHcdx2H3PrV1i
P5LG8r6PqCmM6AXPGGxK0WCEuYZyXsR8FfuvuHOwBdRnPwhDPmi9N+7rKa5PPAce
1bLcqgJunzCX00oNYfzd2sBURapHthByIY3ldtcZe+XfC420QDr2R3vFh/rpHcVa
Jdw6SQXzeRX8cCumDz+PtabXEp67aAPSy7Skxynz4z//tq1zWm0Z3OUDKBPlRd/u
iKdEZ7DYhniC5oQfkE4mLjxCc23epkgXsH973Vkod5s7V1I8OMSqCOPMamrRCwsn
Onuip/V0xWeQuvzZGWIL38iqR2EJs1FD1yeHr5/10ydM0ynYiXCBjQxJv5c31JCn
c9B1Cqso2x7U2WIuk2NODv9vpKvAXzYmzfsyRCDXzzo21cMaMR9eRFPyDIAweIfz
r2k8uClm5snsV9/1lSXn
=cu1n
-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: Review requests that need reviewers

[gil]

Hi Tom,
Taken!
can you take these for me
https://bugzilla.redhat.com/show_bug.cgi?id=995433
https://bugzilla.redhat.com/show_bug.cgi?id=995435
https://bugzilla.redhat.com/show_bug.cgi?id=995444
https://bugzilla.redhat.com/show_bug.cgi?id=1258274
https://bugzilla.redhat.com/show_bug.cgi?id=1266805
?
Thanks in advance
Regards
gil

Il 09/11/2015 23:27, Tom Callaway ha scritto:

The easy ones (some R packages I need as deps for updating R-DBI):
https://bugzilla.redhat.com/show_bug.cgi?id=1277933
https://bugzilla.redhat.com/show_bug.cgi?id=1277956
https://bugzilla.redhat.com/show_bug.cgi?id=1277961
https://bugzilla.redhat.com/show_bug.cgi?id=1277966
https://bugzilla.redhat.com/show_bug.cgi?id=1277970


--
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: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-09 at 17:11 -0800, Adam Williamson wrote:
> On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote:
> > Kamil Paral wrote:
> > > So we could ignore freeze just for packages not being on any install
> > > medium. But then I'm not sure how much that is helpful and it might be
> > > difficult to implement this in Bodhi.
> > 
> > In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
> > freeze overrides for such packages (with the same arguments as yours, i.e., 
> > it cannot really break anything).
> 
> Yes - and that frequently went wrong. That's precisely why we ditched
> that process and came up with a better one, where the decision isn't
> made on-the-fly by whoever happens to be reading the tickets in releng,
> but is made according to an established process, by a sensible group of
> stakeholders, with proper tracking and a paper trail.

Sorry, I missed that you were talking about packages not on the release
media. Yeah, those are kind of odd because you can argue them either
way: on the one hand pulling them in is unlikely to break anything, on
the other hand, what's the point of doing it? I'd usually still err on
the side of caution and leave them out, just in case they somehow break
the buildroot or do something else strange, if there's no actual
particular reason to push them.

And yes, there is an obvious technical problem - we don't actually have
the ability, right now, to know for sure exactly what packages are
somehow directly involved in building the media.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
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: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote:
> Kamil Paral wrote:
> > So we could ignore freeze just for packages not being on any install
> > medium. But then I'm not sure how much that is helpful and it might be
> > difficult to implement this in Bodhi.
> 
> In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
> freeze overrides for such packages (with the same arguments as yours, i.e., 
> it cannot really break anything).

Yes - and that frequently went wrong. That's precisely why we ditched
that process and came up with a better one, where the decision isn't
made on-the-fly by whoever happens to be reading the tickets in releng,
but is made according to an established process, by a sensible group of
stakeholders, with proper tracking and a paper trail.

>  These days, such freeze override requests 
> get blanket-rejected instead (because it doesn't make much of a difference, 
> so they don't see any reason to make exceptions to the processes).

Nothing gets blanket rejected. Each FE proposal is evaluated
individually on its merits.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

[Samuel Sieb]

On 11/09/2015 03:34 PM, Reindl Harald wrote:



Am 09.11.2015 um 23:57 schrieb Samuel Sieb:

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine


I really wonder where you come from.  I have never seen a grade school,
public or private, that uses thin-clients


http://www8.hp.com/us/en/thin-clients/education.html

I didn't say they didn't exist.  I've certainly heard of them and seen 
them in various places.  I said in all the schools I've been in, I've 
never seen any actually deployed.



As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?


i don't get why i need the most up-to-date software when at the same
time i don't care about my hardware and run a P4 heater because that
indicates low requirements

What does low requirements have to do with up-to-date software?  Why 
should I have to use an old version of LibreOffice just because I'm 
using a 10 year old computer when the latest version works perfectly well?



about money: with the energy costs i saved going away from P4 computers
many years ago my current one is already paied

I would be very surprised if the power savings are really that much.  I 
will do a power check the next time I'm on site.  Besides that, 
electricity is cheap here so it would take a very long time to recoup 
the cost of new 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

Re: Retire a package from Fedora i686 (not x86_64)

[Alexander Ploumistos]

On Tue, Nov 10, 2015 at 1:34 AM, Reindl Harald  wrote:
> about money: with the energy costs i saved going away from P4 computers many
> years ago my current one is already paied

Nobody is saying that a newer computer won't save you money on the
power bill. What they have repeatedly stated and for some (first
world, perhaps?) reason you refuse to acknowledge, is that you can't
trade future power use for a new computer; you have to pay up front,
it's a sort of investment, that not everyone is affluent enough to
make. Not every person or institution can afford to get a new Phenom
or Xeon or whatever every year, or even every X years.
What exactly do you suggest these people do? Get LFS, Gentoo or Arch
and clear all incompatible flags? Or should they apply for a loan to
their bank, detailing the ROI from reduced power usage?
-- 
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 09.11.2015 um 23:57 schrieb Samuel Sieb:

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine


I really wonder where you come from.  I have never seen a grade school,
public or private, that uses thin-clients


http://www8.hp.com/us/en/thin-clients/education.html


As for "wrong operating
system", do you have any suggestions for a different distribution that
is as up-to-date as Fedora that would work on these computers?


i don't get why i need the most up-to-date software when at the same 
time i don't care about my hardware and run a P4 heater because that 
indicates low requirements


about money: with the energy costs i saved going away from P4 computers 
many years ago my current one is already paied



I've always run Fedora on my servers as well


me too






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

[Felix Miata]

Reindl Harald composed on 2015-11-09 23:22 (UTC+0100):

> *yes* capable hardware these days is cheap if you don't need that much 
> performance

Unless and until hardware prices drop to zero, there will be users for whom
any cost is an insurmountable hurdle. And, there will remain users content
with existing capability who only wish to upgrade software in order to
maintain security and/or access to software demanded by their needs. Ordinary
users don't care when SSE3 was introduced. They just want to keep using what
ain't broke as long as possible. Many don't see justification for capability
of newer hardware causing software to demand that capability either,
particularly when it breaks arch portability or produces no more than a
modest, or no, detectable performance improvement, among them, me.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
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)

[Samuel Sieb]

On 11/09/2015 02:22 PM, Reindl Harald wrote:

Am 09.11.2015 um 22:31 schrieb Samuel Sieb:

I manage all the IT for a private school.  There is a computer lab for
the students to use.  They don't have the money to buy new computers,
the computers they have were donated.  They are P4 desktops from around
2005 and they have SSE2.  I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.)  I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


well, i tell you know the same which was told me all the time before the
server spin "maybe you are using the wrong operating system" and frankly
for schools you typically use thin-cients one machine

I really wonder where you come from.  I have never seen a grade school, 
public or private, that uses thin-clients.  As for "wrong operating 
system", do you have any suggestions for a different distribution that 
is as up-to-date as Fedora that would work on these computers?


I've always run Fedora on my servers as well.


with the agrumentations of this thread hardware manufactuers could stop
develop new hardware capabilities if we wait 20 years to consider make
them default - in the IT 10 years is virtually forever and *yes* capable
hardware these days is cheap if you don't need that much performance

"Cheap"?  I might be able to able to build a computer for $300, I 
haven't actually checked lately, that's what it was a few years ago. 
But for a computer lab?  Why would they want to try to come up with that 
much money when the existing computers work perfectly?

--
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 requests that need reviewers

[Tom Callaway]

The easy ones (some R packages I need as deps for updating R-DBI):
https://bugzilla.redhat.com/show_bug.cgi?id=1277933
https://bugzilla.redhat.com/show_bug.cgi?id=1277956
https://bugzilla.redhat.com/show_bug.cgi?id=1277961
https://bugzilla.redhat.com/show_bug.cgi?id=1277966
https://bugzilla.redhat.com/show_bug.cgi?id=1277970

The hard ones (chromium and friends):
https://bugzilla.redhat.com/show_bug.cgi?id=1270355
https://bugzilla.redhat.com/show_bug.cgi?id=1270357
https://bugzilla.redhat.com/show_bug.cgi?id=1270358
https://bugzilla.redhat.com/show_bug.cgi?id=1270364
https://bugzilla.redhat.com/show_bug.cgi?id=1270368
https://bugzilla.redhat.com/show_bug.cgi?id=1270375
https://bugzilla.redhat.com/show_bug.cgi?id=1270405
https://bugzilla.redhat.com/show_bug.cgi?id=1270322

Happy to trade reviews for other reviews. Alternately, will make
packages for you in trade for reviews. Other offers considered.

~tom

==
Red Hat
-- 
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 09.11.2015 um 22:31 schrieb Samuel Sieb:

On 11/07/2015 10:23 AM, Reindl Harald wrote:

these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware


For servers, sure, but that doesn't work for desktops.


how many physical desktops does one use?


talking about a rapid moving distribution like Fedora and at the same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora


I manage all the IT for a private school.  There is a computer lab for
the students to use.  They don't have the money to buy new computers,
the computers they have were donated.  They are P4 desktops from around
2005 and they have SSE2.  I install Fedora on all the computers and
laptops there that I manage. (The older students manage their own
laptops, but even some of them want Fedora installed as well.)  I
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM
they work perfectly for student use.

So yes, I'm using 10 year old hardware with the latest Fedora and it
works great.  (I'll update them to F23 next time I'm there.)


SSE3 was introduced in 2004

well, i tell you know the same which was told me all the time before the 
server spin "maybe you are using the wrong operating system" and frankly 
for schools you typically use thin-cients one machine


with the agrumentations of this thread hardware manufactuers could stop 
develop new hardware capabilities if we wait 20 years to consider make 
them default - in the IT 10 years is virtually forever and *yes* capable 
hardware these days is cheap if you don't need that much performance




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

[Samuel Sieb]

On 11/07/2015 10:23 AM, Reindl Harald wrote:

these days (and i talk about hardware from 2011) you can virtualize
things fast, easy and efficient and consolidate machines on more or less
cheap hardware


For servers, sure, but that doesn't work for desktops.


talking about a rapid moving distribution like Fedora and at the same
time hestitate to use technology available for a decade is strange - i
guess people plan to run their hardware for 10, 12, 15 years are not
using typically a distribution like Fedora

I manage all the IT for a private school.  There is a computer lab for 
the students to use.  They don't have the money to buy new computers, 
the computers they have were donated.  They are P4 desktops from around 
2005 and they have SSE2.  I install Fedora on all the computers and 
laptops there that I manage. (The older students manage their own 
laptops, but even some of them want Fedora installed as well.)  I 
upgraded all the P4 desktops to 2GB RAM and with F22 using a non-3D WM 
they work perfectly for student use.


So yes, I'm using 10 year old hardware with the latest Fedora and it 
works great.  (I'll update them to F23 next time I'm there.)

--
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: Orphaning JBoss Tools package

[Marcus Karlsson]

On Tue, Nov 03, 2015 at 08:22:57PM +, Gerard Ryan wrote:
> On 11/02/2015 11:49 PM, Marcus Karlsson wrote:
> > On Sun, Nov 01, 2015 at 03:56:15PM +, Gerard Ryan wrote:
> >> Hi devel list (and cc'ed eclipse-sig list),
> >>
> >> I'm going to orphan the eclipse-jbosstools package in rawhide, as I'm no
> >> longer able to give it the time that it needs. My understanding is that
> >> if nobody takes it, it will be auto-retired after 6 weeks (please
> >> correct me if I'm wrong here).
> >>
> >> If you're interested in taking it & have any questions, I'm happy to
> >> provide any input I can. I think ideally it would want more than one
> >> active maintainer to get it into the shape that it needs to be (not all
> >> features are currently packaged, and significant effort would be
> >> required there).
> >>
> >> Thanks,
> >> Gerard.
> > 
> > Hi Gerard.
> > 
> > I'm interested in stepping up and maintaining this package as I
> > occasionally use it and would love to see it fully supported on Fedora.
> > :-)
> > 
> > Marcus
> > 
> 
> Hi Marcus,
> 
> That's great to hear that you're interested in it. Like you said, it
> would be great to see all of it in Fedora, since it's great for the kind
> of development that it targets.
> 
> Currently it doesn't build in Rawhide because of missing dependencies.
> Also there's a new release that I spend a couple of weekends trying to
> get to work, but eventually failed.
> 
> Have you had a chance to look at it yet and try it out?
> 
> Gerard.

Hi Gerard.

I started looking at it over the weekend and have now started looking
into getting it upgraded to the latest upstream release. Not a lot of
questions yet as I have found that it has so far been very well
packaged. If you have any ideas or pointers that I should keep in mind
then they are of course highly appreciated. I hope to have something up
fairly soon but it may take some time before it's all there.

Marcus
-- 
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: Unexpected NIC naming f23 firewall implications

[Richard W.M. Jones]

On Mon, Nov 09, 2015 at 04:55:40PM +0100, Harald Hoyer wrote:
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> > On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> >>
> >> Is this something that was expected? It certainly surprised me.
> > 
> > It happened to a bunch of servers when I updated them from F22 to F23.
> > Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> > to boot each one with a display and keyboard and change the network
> > configuration by hand.
> > 
> > "predictable, stable network interface names"
> > https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> > 
> > Rich.
> > 
> 
> em* and p?p? come from biosdevname, which should not be used and is 
> deprecated.

I'm merely observing what happened when I updated a bunch of servers
from F22 to F23.  I didn't intentionally install nor uninstall biosdevname
at any point.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
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: daveisfera's odb_2.3_cern copr build of odb for epel-5-i386 finished with 'failed'

[Sérgio Basto]

I finally open a ticket 

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


On Qua, 2015-10-28 at 18:17 +, Sérgio Basto wrote:
> Hi,
> 
> On Dom, 2015-10-25 at 20:50 -0700, Dave Johansen wrote:
> > The links in the above email don't work. For example, the "Build log"
> > link says "Content Encoding Error" when I load it in Firefox:
> > https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/odb/build.log.gz
> > 
> > This is the link that is listed if I start at the main page and drill
> > down to find the same file and it works:
> > https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/00128590-odb/build.log.gz
> > 
> 
> Yeah, it happened the same to me, seems a redirect problem ... 
> 
> 
> > Is this a known issue? Or should I open a bugzilla/ticket somewhere?
> 
> 
> Maybe you will get a more feedback in copr-devel mailing list [1] ,
> should we forward this email ? 
>  
> [1] copr-de...@lists.fedorahosted.org
> 
> 
> Best regards,

-- 
Sérgio M. B.

-- 
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: koschei/koji build failures

[Kevin Fenzi]

On Sun, 8 Nov 2015 13:40:16 -0700
Kevin Fenzi  wrote:

> ok. I think this might be: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1264198
> which is an rpm bug fixed in rawhide, but not yet in f23. 
> 
> We need a f23 update with that fixed and we can try again. 

There's now a f23 update, I have applied it to buildvm-01 to 09 and
re-added them. 

Please let me know if you see any build failures on these builders that
cannot be duplicated on others. 

kevin


pgpHi_GUfFYhL.pgp
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: Unexpected NIC naming f23 firewall implications

[Dan Williams]

On Sun, 2015-11-08 at 20:36 +0100, Reindl Harald wrote:
> 
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> > On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> >>
> >> Is this something that was expected? It certainly surprised me.
> >
> > It happened to a bunch of servers when I updated them from F22 to F23.
> > Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> > to boot each one with a display and keyboard and change the network
> > configuration by hand.
> >
> > "predictable, stable network interface names"
> > https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> that is simple to solve forever
> 
> * add "net.ifnames=0 biosdevname=0" to your kernel params
> * get rid of NetworkManager

FYI, NetworkManager has nothing to do with device naming at all.  So
disabling NM will do nothing to solve your problems with device names.

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

Re: DNF is completly unable to act with local packages

[Honza Šilhan]

> From: "Matthew Miller" 
> 
> On Sat, Nov 07, 2015 at 04:24:07PM +0100, Michael Schwendt wrote:
> > Btw, it's odd already that "dnf update rpm*.rpm" refuses to install
> > packages that are not installed as older version. Compare that with
> > "rpm -Uvh …" and "rpm -Fvh …". It would make sense to mimic those
> > two commands in tools that install from repositories.

"local update" used to work like that but it was requested to change this 
behaviour
and we made it consistent with "remote update" [1]. You probably want to
use `dnf install *.rpm` as Matthew pointed out.

> This RFE is in these two bugs:
> 
> * https://bugzilla.redhat.com/show_bug.cgi?id=1138700
> * https://bugzilla.redhat.com/show_bug.cgi?id=1160950

it allows the user to install the package by `dnf install ` 
regardless the version - continuation of bug 1138700 (where the
original bug could not be reproduced).


Honza

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1134893
-- 
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: Unexpected NIC naming f23 firewall implications

[Harald Hoyer]

Am 08.11.2015 um 17:14 schrieb Björn Persson:
> Christopher  wrote:
>> I recently updated my desktop to f23, and it went smoothly, for the most
>> part. However, it broke my mediatomb server because the NIC changed from
>> em1 to eno1.
> 
> On any computer where it matters which network interface is connected
> to which network, I recommend writing some Udev rules to set permanent
> interface names based on the MAC address.
> 
> Write a file named /etc/udev/rules.d/01-network-interface-naming.rules 
> with content similar to this:
> 
> SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world"
> SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit"
> SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
> 
> "01" in the filename causes it to be loaded before other files with
> higher numbers. Assignment with ":=" prevents later rules from
> clobbering the names. I found that capital letters don't work in the
> hexadecimal MAC addresses, so write them with small letters.
> 
> We shouldn't have to do this manually, and it definitely shouldn't be
> as difficult as it was to find out how to do it, but on the upside you
> get meaningful names so that you won't have any trouble remembering
> which interface is which.
> 
> (I hope no one turns Udev inside out anytime soon.)
> 
> Björn Persson
> 
> 
> 

Please don't do this. For MAC based name assignment you can use the ifcfg-*
files with HWADDR="".


-- 
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: Unexpected NIC naming f23 firewall implications

[Harald Hoyer]

Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
>> I recently updated my desktop to f23, and it went smoothly, for the most
>> part. However, it broke my mediatomb server because the NIC changed from
>> em1 to eno1.
>>
>> Is this something that was expected? It certainly surprised me.
> 
> It happened to a bunch of servers when I updated them from F22 to F23.
> Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> to boot each one with a display and keyboard and change the network
> configuration by hand.
> 
> "predictable, stable network interface names"
> https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> Rich.
> 

em* and p?p? come from biosdevname, which should not be used and is deprecated.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


7 packages were orphaned

bouncycastle [el6, epel7, el5] was orphaned by stevetraylen
 Bouncy Castle Crypto Package for Java
 https://admin.fedoraproject.org/pkgdb/package/bouncycastle
gdl [el5] was orphaned by orion
 GNU Data Language
 https://admin.fedoraproject.org/pkgdb/package/gdl
gfal2-plugin-xrootd [f23, f22, f21, el6, epel7, el5] was orphaned by adev
 Provide xrootd support for GFAL2
 https://admin.fedoraproject.org/pkgdb/package/gfal2-plugin-xrootd
ipcalculator [master] was orphaned by jhrozek
 A utility for computing broadcast, network, mask, and host ranges
 https://admin.fedoraproject.org/pkgdb/package/ipcalculator
passenger [epel7] was orphaned by orion
 Phusion Passenger application server
 https://admin.fedoraproject.org/pkgdb/package/passenger
python-qutepart  [f23, f22, master, epel7] was orphaned by raphgro
 Source code text editor component
 https://admin.fedoraproject.org/pkgdb/package/python-qutepart 
supervisor [el6, epel7, el5] was orphaned by stevetraylen
 A System for Allowing the Control of Process State on UNIX
 https://admin.fedoraproject.org/pkgdb/package/supervisor

8 packages were retired

gfal2-plugin-xrootd [master] was retired by adev
 Provide xrootd support for GFAL2
 https://admin.fedoraproject.org/pkgdb/package/gfal2-plugin-xrootd
perl-MIME-Lite [el6] was retired by stevetraylen
 MIME::Lite - low-calorie MIME generator
 https://admin.fedoraproject.org/pkgdb/package/perl-MIME-Lite
prototype [master, epel7] was retired by till
 JavaScript framework
 https://admin.fedoraproject.org/pkgdb/package/prototype
scipy [el5] was retired by orion
 Scientific Tools for Python
 https://admin.fedoraproject.org/pkgdb/package/scipy
scriptaculous [master, epel7] was retired by till
 JavaScript library
 https://admin.fedoraproject.org/pkgdb/package/scriptaculous
sitecopy [master] was retired by till
 Tool for easily maintaining remote web sites
 https://admin.fedoraproject.org/pkgdb/package/sitecopy
surf [master] was retired by till
 Simple web browser
 https://admin.fedoraproject.org/pkgdb/package/surf
syntaxhighlighter [master, epel7] was retired by till
 JavaScript syntax highlighter
 https://admin.fedoraproject.org/pkgdb/package/syntaxhighlighter

7 packages unorphaned
-
OpenIPMI [f23, f22, f21, master] was unorphaned by branto
 IPMI (Intelligent Platform Management Interface) library and tools
 https://admin.fedoraproject.org/pkgdb/package/OpenIPMI
eclipse-jbosstools [master] was unorphaned by marcusk
 Eclipse plugins that support JBoss and related technology
 https://admin.fedoraproject.org/pkgdb/package/eclipse-jbosstools
freeipmi [f23, f22, f21, master] was unorphaned by branto
 IPMI remote console and system management software
 https://admin.fedoraproject.org/pkgdb/package/freeipmi
ipmitool [f23, f22, f21, master] was unorphaned by branto
 Utility for IPMI control
 https://admin.fedoraproject.org/pkgdb/package/ipmitool
python-qutepart [f23, f22, master, epel7] was unorphaned by raphgro
 Source code text editor component
 https://admin.fedoraproject.org/pkgdb/package/python-qutepart
quassel [epel7] was unorphaned by lupinix
 A modern distributed IRC system
 https://admin.fedoraproject.org/pkgdb/package/quassel
suitesparse [el5] was unorphaned by orion
 A collection of sparse matrix libraries
 https://admin.fedoraproject.org/pkgdb/package/suitesparse

0 packages were unretired


3 packages were given

asterisk [f23, f22, f21, el6, master] was given by jcollie to jsmith
 The Open Source PBX
 https://admin.fedoraproject.org/pkgdb/package/asterisk
asterisk-sounds-core [f23, f22, f21, master, el6, epel7, el5] was given by 
jcollie to jsmith
 Core sounds for Asterisk
 https://admin.fedoraproject.org/pkgdb/package/asterisk-sounds-core
drupal7-jquery_update [epel7] was given by siwinski to sdodson
 Upgrades the version of jQuery in Drupal core to a newer version of jQuery
 https://admin.fedoraproject.org/pkgdb/package/drupal7-jquery_update

0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
-- 
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: Unexpected NIC naming f23 firewall implications

[Jóhann B . Guðmundsson]

On 11/08/2015 07:29 PM, Richard W.M. Jones wrote:

On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:

I recently updated my desktop to f23, and it went smoothly, for the most
part. However, it broke my mediatomb server because the NIC changed from
em1 to eno1.

Is this something that was expected? It certainly surprised me.

It happened to a bunch of servers when I updated them from F22 to F23.
Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
to boot each one with a display and keyboard and change the network
configuration by hand.

"predictable, stable network interface names"
https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/


The p6p1 and em1 interface names come from ( Dells ) biosdevname not 
systemd and most likely the biosdevname component got removed on upgrade 
or superseded by other udev rules.


Arguably biosdevname component should have been obsoleted in F19 as a 
component and in Anaconda and Dracut when predictable network interface 
names got introduced with systemd in the distribution, to prevent these 
kind of surprises but here we are so "surprise" ...


JBG
--
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: [HEADS UP] Ongoing rebuild of Python3.5 in Rawhide

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/04/2015 06:23 AM, Robert Kuska wrote:
> There is ongoing rebuild of Python3.5 in rawhide's side-tag
> f24-python3.
> 
> I would like to ask all maintainers to rebuild their packages
> (which depend on python3) within the f24-python3 side-tag.
> 
> To rebuild your package simply run: `fedpkg build --target
> f24-python3`
> 

Just to be clear; this needs to have a revision-number bump as well,
doesn't it?

> You can find all packages that were already rebuilt here:
> 
> http://taiga.cloud.fedoraproject.org/project/rkuska-python35-rebuild/kanban
>
>  Feel free to add your package once your build pass successfully.
> Side-tag will be merged hopefully by the end of the week, mass
> rebuild will follow to avoid breakage of rawhide.
> 
> Tracking bug to link rebuild related bugs to: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1269756
> 
> 
> 
> https://fedoraproject.org/wiki/Changes/python3.5


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZAuycACgkQeiVVYja6o6NI4wCfb0sDzytqEAfCYYYss2orNe4V
WhoAn0MISydtLcuEU+bQHdgRbxZQA342
=ilmo
-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: DNF is completly unable to act with local packages

[Matthew Miller]

On Sat, Nov 07, 2015 at 04:24:07PM +0100, Michael Schwendt wrote:
> Btw, it's odd already that "dnf update rpm*.rpm" refuses to install
> packages that are not installed as older version. Compare that with
> "rpm -Uvh …" and "rpm -Fvh …". It would make sense to mimic those
> two commands in tools that install from repositories.

This RFE is in these two bugs:

* https://bugzilla.redhat.com/show_bug.cgi?id=1138700
* https://bugzilla.redhat.com/show_bug.cgi?id=1160950

but they seem to have both been closed as duplicates of each other and
I'm not sure it's actually addressed... 

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

Fedora Rawhide 20151109 compose check report

[Fedora compose checker]

Missing expected images:

Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Generic boot i386
Generic boot x86_64

Images in this compose but not Rawhide 20151108:

Workstation disk raw armhfp

No images in Rawhide 20151108 but not this.

Failed openQA tests: 4 of 5

ID: 8054Test: x86_64 kde_live default_install
ID: 8053Test: i386 kde_live default_install
ID: 8051Test: x86_64 workstation_live default_install
ID: 8050Test: i386 workstation_live default_install

Passed openQA tests: 1 of 5
-- 
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

Re: Unexpected NIC naming f23 firewall implications

[Kevin Kofler]

Richard W.M. Jones wrote:
> Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> to boot each one with a display and keyboard and change the network
> configuration by hand.
> 
> "predictable, stable network interface names"
> https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/

Oh the irony!

Unpredictable, unstable network interface names. (I presume they previously
changed from eth0 to p6p1, so that's already the SECOND breakage.) Hooray
for this "feature"!

Kevin Kofler

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

[Kevin Kofler]

Kalev Lember wrote:
> I wonder if it might be a good time to bump the i686 minimal
> requirements for F24 to include sse2. Not for performance reasons, but
> for compatibility: almost all developers are on x86_64 these days and
> i686 is pretty much just limping along. If we include sse2 on i686, that
> removes another difference between x86_64 and i686 and makes things
> easier for us as a downstream.

I don't think this difference is a real issue.

> Apparently quite a few upstreams these days consider sse2 as a minimal
> requirement and it seems more and more that Fedora packagers need to
> work this around if we don't follow the lead.

This is more of a problem.

This is only a minor annoyance where a portable fallback exists (we can just 
ship the portable C/C++ version in /usr/lib and the SSE2 version in 
/usr/lib/sse2, as we are doing with Qt 5 QtDeclarative). The real problem is 
software which has no portable fallback at all, such as Chromium/QtWebEngine 
or Darktable. This completely screws not only non-SSE2 x86, but also all 
secondary architectures, and in some cases such as Darktable, even the 
primary architecture ARM. It is unfortunate that the number of such non-
portable software seems increasing lately. Portability to any and all CPU 
architectures used to be a big selling point for Free Software. These days, 
more and more projects seem happy to sacrifice this on the altar of 
performance. :-(

I think dropping support for non-SSE2 in all of Fedora would send entirely 
the wrong message to those upstreams and only contribute to the surge of 
non-portable software.

That said, we need a formal policy to deal with such software, which IMHO 
should be treated just like an ExcludeArch, except that you should not 
actually ExcludeArch the package as long as it supports SOME CPUs of that 
architecture. It should still be put on the relevant ExcludeArch tracker 
though, and if a fix/workaround exists, applying it should be required.

> I don't think this is worth doing for performance reasons. I don't think
> a few percentage of possible gain in micro benchmarks is worth it, but
> if it saves some hundreds of hours of developer time for people who are
> working on Fedora and don't have to work around missing sse2, I'd say
> it's very well worth the cost of losing ancient CPU support.

That would unfortunately decrease the usefulness of the i686 distribution a 
lot. Given that we want to push users of 64-bit-capable machines to the 
x86_64 version, it would leave basically only one generation of x86 machines 
for the i686 distribution: the Pentium 4 Northwood generation, including one 
or two generation(s) of AMD CPUs from the same time. Add to that some newish 
low-end Atoms where they removed x86_64 support "to save power" (actually to 
introduce an artificial market segmentation), no idea how popular those are. 
Everything else that has SSE2 also has 64-bit.

Unfortunately, that prerogative ("all 64-bit-capable machines should use 64-
bit binaries") is not universally shared by upstreams. For example, Qt sees 
the primary target of their 32-binaries as being modern machines that would 
also support x86_64, but where the user elected to use 32-bit for whatever 
reason, not old 32-bit-only machines as we see it. That is the primary 
reason for the different stance on non-SSE2 support. (That said, Qt, outside 
of QtWebEngine, does not actually REQUIRE SSE2. They just enable its use by 
default.) My argument that the default option ought to be the safe, portable 
one (non-SSE2) was rejected on the grounds of performance on what they think 
are the vast majority of machines using 32-bit Qt (whereas I argued that it 
was only really one generation, but as I wrote above, they have a completely 
different conception of the purpose of 32-bit binaries).

Kevin Kofler

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

[Martin Kolman]

On Sat, 2015-11-07 at 18:36 -0700, Stephen John Smoogen wrote:
> On 7 November 2015 at 17:51, Neal Gompa  wrote:
> > On Sat, Nov 7, 2015 at 4:39 PM, Stephen John Smoogen <
> > smo...@gmail.com>
> > wrote:
> > > 
> > > 
> > > On Nov 7, 2015 13:50, "Neal Gompa"  wrote:
> > > > 
> > > > Why don't we do emulated builds (like how OBS does it for ARM)?
> > > > 
> > > > 
> > > 
> > > The attempts at emulated builds have usually been slower than the
> > > hardware
> > > builds
> > 
> > Are they unusable? I find it hard to believe that emulated builds
> > are that
> > horrible for building in when we don't have much hardware for ARM
> > builds...
> > 
> > 
> 
> If we are talking about cross-compiling emultation builds (some
> people
> use that term so I need to make sure I am clear) then I think we
> haven't looked into it because we don't do cross-compiles in the main
> build system. If we are talking about using qemu to emulate arm, the
> problem is that the speed was so slow that it was interfering with
> builds thinking they were broken (timed out) when they were just
> really slow. However that was a long time ago (2 years?) so it may
> have improved.
The Mer project OBS[0] uses qemu ARM emulation and the speed seems to
be fine. Also I think the production builds for Sailfish OS are done
the same way.

[0] https://build.merproject.org/
> 
> 
> 
> 
> 
> -- 
> Stephen J Smoogen.
-- 
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)

[Kevin Kofler]

Rex Dieter wrote:
> Qt5 (Gui and Declarative) pretty much requires sse2, and I/kde-sig asked
> about pushing the minimum i686 fedora spec to include sse2, but fesco was
> against that idea at the time.

For what it's worth, I was against it. Using /usr/lib/sse2 as we do now 
works just fine as a solution to this problem. People without SSE2 at least 
get a distribution that works for them, and even Qt 5 builds (except the 
soon-to-be-packaged QtWebEngine module, sadly, unless/until something 
happens at its upstream to fix the V8 non-portability) that work, albeit 
slowly. LXQt should even work at an acceptable speed, given that they use 
QtWidgets for their UI, which does not need the QML 2 interpreter or JIT (so 
you don't get the non-JIT interpreter). And people with SSE2 get SSE2-
optimized .so binaries where it matters.

The only thing the duplication costs is some disk space, but that is the 
price of portability.

Kevin Kofler

-- 
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: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Kamil Paral wrote:
> So we could ignore freeze just for packages not being on any install
> medium. But then I'm not sure how much that is helpful and it might be
> difficult to implement this in Bodhi.

In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
freeze overrides for such packages (with the same arguments as yours, i.e., 
it cannot really break anything). These days, such freeze override requests 
get blanket-rejected instead (because it doesn't make much of a difference, 
so they don't see any reason to make exceptions to the processes).

Kevin Kofler

-- 
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: F24: no rsyslog forwarding

[Reindl Harald]

Am 07.11.2015 um 17:20 schrieb Zbigniew Jędrzejewski-Szmek:

On Sat, Nov 07, 2015 at 01:31:11PM +0100, Reindl Harald wrote:



Am 07.11.2015 um 12:59 schrieb Zbigniew Jędrzejewski-Szmek:

On Fri, Nov 06, 2015 at 06:20:39PM +0100, Reindl Harald wrote:



Am 06.11.2015 um 18:15 schrieb Subhendu Ghosh:


On Nov 6, 2015 9:52 AM, "Reindl Harald" mailto:h.rei...@thelounge.net>> wrote:


who is responsible that nothing is forwarded to the traditional syslog?
systemd or rsyslog?



Journald is probably hold the log socket and not forwarding to syslog


it does not need to Forward the old way hence "ForwardToSyslog=no"
and instead "$ModLoad imjournal" which is nothing new but don't work
at Rawhide currecntly while it dooes on F20/F21/F22/f23

http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html

to say it in other words: i did not ask for "probably", just pointed
out that Rawhide is currently broken, that probably systemd or
probably rsyslog is broken in the one or other direction is clear


I looks like a problem on the rsyslog side, from what you describe.
A permission issue seems the most likely


permission to what?

since rsyslog with "imjournal" reads data from journald than it
sounds more like an systemd regression if it's a permission issue
(no SELinux is part of the game here)

Privileges are needed to read the journal. Please file a bug against
rsyslog, include the output of getfacl /var/log/journal /run/log/journal,
and other useful info, and I'm sure rsyslog maintainers will be able
to figure it out or redirect it back to systemd if necessary.
We're not going to solve it on the mailing list


well, i started to create a bugreport - interesting - now it started to 
work and according to the logs i have no idea which update may have 
fixed that and why


Nov 06 15:41:20 INFO Upgraded: rpm-python3-4.13.0-0.rc1.10.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: rpm-python3-4.13.0-0.rc1.10.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: rpm-python-4.13.0-0.rc1.10.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: rpm-python-4.13.0-0.rc1.10.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: file-5.25-1.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: file-5.25-1.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: 
rpm-plugin-systemd-inhibit-4.13.0-0.rc1.10.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: 
rpm-plugin-systemd-inhibit-4.13.0-0.rc1.10.fc24.x86_64

Nov 06 15:41:20 INFO Upgraded: shadow-utils-2:4.2.1-4.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: shadow-utils-2:4.2.1-4.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: make-1:4.1-4.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: make-1:4.1-4.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: libtool-ltdl-2.4.6-6.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: libtool-ltdl-2.4.6-6.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: libgomp-5.2.1-4.fc24.x86_64
Nov 06 15:41:20 INFO Upgraded: libgomp-5.2.1-4.fc24.x86_64
Nov 06 15:41:21 INFO Upgraded: binutils-2.25.1-9.fc24.x86_64
Nov 06 15:41:21 INFO Upgraded: binutils-2.25.1-9.fc24.x86_64
Nov 06 15:41:23 INFO Installed: kernel-core-4.4.0-0.rc0.git2.1.fc24.x86_64
Nov 06 15:41:23 INFO Installed: kernel-core-4.4.0-0.rc0.git2.1.fc24.x86_64
Nov 06 15:53:20 INFO --- logging initialized ---
Nov 06 15:53:30 INFO Installed: libpipeline-1.4.1-1.fc24.x86_64
Nov 06 15:53:30 INFO Installed: libpipeline-1.4.1-1.fc24.x86_64
Nov 06 15:53:30 INFO Installed: man-db-2.7.4-2.fc24.x86_64
Nov 06 15:53:30 INFO Installed: man-db-2.7.4-2.fc24.x86_64
Nov 06 15:53:30 INFO Installed: less-481-1.fc24.x86_64
Nov 06 15:53:30 INFO Installed: less-481-1.fc24.x86_64
Nov 07 13:33:33 INFO --- logging initialized ---
Nov 07 13:33:34 INFO --- logging initialized ---
Nov 07 13:41:03 INFO Upgraded: 
rpm-plugin-selinux-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: 
rpm-plugin-selinux-4.13.0-0.rc1.11.fc24.x86_64

Nov 07 13:41:03 INFO Upgraded: rpm-libs-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: rpm-libs-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: rpm-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: rpm-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: rpm-build-libs-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: rpm-build-libs-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: libgcc-5.2.1-5.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: libgcc-5.2.1-5.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: libstdc++-5.2.1-5.fc24.x86_64
Nov 07 13:41:03 INFO Upgraded: libstdc++-5.2.1-5.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: rpm-python3-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: rpm-python3-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: rpm-python-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: rpm-python-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: 
rpm-plugin-systemd-inhibit-4.13.0-0.rc1.11.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: 
rpm-plugin-systemd-inhibit-4.13.0-0.rc1.11.fc24.x86_64

Nov 07 13:41:04 INFO Upgraded: libgomp-5.2.1-5.fc24.x86_64
Nov 07 13:41:04 INFO Upgraded: lib

Re: Fedora 23 Final RC10 status is GO !

[Kamil Paral]

> Very frequently in such cases the entire test matrix is not completely
> retested. A lot of prior tests a carried over because they're known
> (or strongly suspected) of not having been touched in any way by the
> fix of one or two blocker bugs.
> 
> If hundreds of packages get unfrozen and sync'd all bets are off. The
> state of the release is now sufficiently non-determinstic that it
> means all testing has to be started completely from scratch. So I
> would say no, this isn't a good idea, just because the resources
> aren't there to do this additional amount of testing.
> 
> The goal isn't to have a release that's super current. It's to have a
> release that's stable and works.

I think that Chris described it very well. I'm quite skeptical that such a 
proposal would work in practice because of these reasons. It's quite demanding 
for us to just fix and test the outstanding blockers. Updating everything would 
mean:
a) retesting everything from scratch, and of course our testing covers only a 
few selected areas, we rely on many people from community to report blockers 
when they find them -- that takes time, not just a few days of testing crunch
b) potentially breaking anything, from boot to installer to desktop environment 
to apps

Of course if things break immediately after first system update, our users are 
not much better off. But at least the install medium booted and installer 
worked. The broken updates can be fixed, they are not baked into the install 
medium.

Maybe we could consider some middle approach, where things not in the critical 
path (not directly affecting the core system and installer) would not be 
affected by freeze. That shouldn't break much and would help many pre-release 
users and maintainers. It can still introduce new blockers, though, if those 
apps are e.g. on Live medium or are installed by Server by default (and then 
don't start). So we could ignore freeze just for packages not being on any 
install medium. But then I'm not sure how much that is helpful and it might be 
difficult to implement this in Bodhi.
-- 
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 swap: openmx

[Marcin Dulak]

Thanks, I take yours gil.

On Sun, Nov 8, 2015 at 3:41 PM, Marcin Dulak  wrote:

> Hi,
>
> I have this review for exchange
> https://bugzilla.redhat.com/show_bug.cgi?id=1156086
>
> Best regards,
>
> Marcin
>
-- 
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: Freerdp update with bundle in guacamole-server

[Pavel Alexeev]

08.11.2015 23:38, Neal Gompa пишет:
On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev >wrote:


Hello.

More than half year in the past freerdp was updated and then
reverted version to current present [1], mostly to allow built
guacamole-server [2].

As I see it still stick with that version.
Meantime freerdp move forward. Remmina, which require fresh
versions of freerdp also can't be updated.

Recently our bundling policy changed [3].

From freerdp depends:
$ dnf repoquery --source --alldeps --whatrequires freerdp-libs
...
freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm
guacamole-server-0.9.7-1.fc23.src.rpm
medusa-2.2-0.rc1.2.fc23.1.src.rpm
remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm
vinagre-3.18.1-1.fc23.src.rpm
vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org )
weston-1.9.0-1.fc23.src.rpm

$ dnf repoquery --source --alldeps --whatrequires freerdp
...
krdc-15.04.2-2.fc23.src.rpm

Today I have try build freerdp [4] from master and all
dependencies against it.

And again, *only* guacamole-server fails to build with:
In file included from rdp_stream.h:29:0,
 from rdp_fs.c:27:
rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such
file or directory
compilation terminated.

It relied on old svc_plugin which has been rid in 2013 year [5].

Main question. Is it a good reason to bundle copy of current
version freerdp into guacamole-server (at least until someone do
not willing port it) and update it for rest of Fedora?

I have not tried to do such bundle yet, but if no one argue I
could try do that with update freerdp and rebuild all other deps too.

[1]
https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html
[2]
https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html
[3] https://fedorahosted.org/fpc/ticket/575
[4] https://github.com/FreeRDP/FreeRDP
[5] https://github.com/FreeRDP/FreeRDP/pull/1574

-- 
With best wishes, Pavel Alexeev.

Yes, I'm a fool - I believe in people, honesty, goodness and
justice. And also in the fact that I can make this world just a
little better unless stop fighting.
http://hubbitus.info


​Given that the last time someone asked about getting guacamole to 
work on the latest FreeRDP, they said they won't do it[1], I'm 
inclined to suggest you should go ahead and try that.
Sorry, but I do not very interesting in guacamole and it seams is not 
very trivial task.
I have asked FreeRDP to put out a release before[2], and they've just 
marked it for "2.0" milestone, whenever that happens...


Another option would be to set up the current FreeRDP library as a 
"compat" package that can be parallel installed with the latest 
FreeRDP from upstream, which might be possible with some finagling.
That may be an option. Do you think it is a better way? It will require 
new review, but still need only for single package.


[1]: https://glyptodon.org/jira/browse/GUAC-1130
[2]: https://github.com/FreeRDP/FreeRDP/issues/2839


--
真実はいつも一つ！/ Always, there's only one truth!


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

rawhide report: 20151109 changes

[Fedora Rawhide Report]

Compose started at Mon Nov  9 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[Mayavi]
Mayavi-4.4.3-2.fc24.i686 requires python-pyface-wx
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python2-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python3-debug-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
gcc-python3-plugin-0.14-4.fc23.i686 requires gcc = 0:5.1.1-4.fc23
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/schema)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/registry)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/pkg)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc2