Re: Fedora 27 mass rebuild at risk

[Dan Horák]

On Tue, 11 Jul 2017 21:48:46 -0400
Carlos O'Donell  wrote:

> On 07/11/2017 12:37 AM, Carlos O'Donell wrote:
> > If we're lucky we can get everything ready for the 12th, but we
> > might need another day or two given how long it takes to build gcc
> > on all the arches.
> 
> We are getting more luck. We'll see how tomorrow goes.
> 
> Status update:
> 
> * Get the gcc trunk patch into F27 gcc.
>  
>   * Patch committed to trunk [Done -- IBM]
> 
> * Fedora backport [Done -- Red Hat]
> 
> * Rebuilds of glibc to fix gcc header issues [Done -- fweimer]
> 
> * Rebuild gcc and libgcc [In progress -- jakub]
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=20462687
> 
> * Rebuild glibc
>  
>   * Patch committed to trunk [In progress -- IBM]
> * codonell talking to IBM about fix for static linking.
>  
>   * Sync to Fedora [Waiting -- Red Hat]
> * Waiting for new compiler to retest glibc builds.
> 
>   * Rebuild [Waiting -- Red Hat]
> 
> * Fix Go 1.8.1 for s390x

this is https://bugzilla.redhat.com/show_bug.cgi?id=1460254 -
buggy interaction between golang and new binutils

> 
>   * Recent patches get us to everything but s390x working:
> golang 1.8.1:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20461040 golang
> 1.9:   https://koji.fedoraproject.org/koji/taskinfo?taskID=20457700
> Note: ppc64le are just testsuite issues. 
>   * Fix s390x breakage [In progress -- jcajka]


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Petr Pisar]

On 2017-07-12, mcatanz...@gnome.org  wrote:
> Very few applications actually have SELinux profiles, and they are all
> maintained downstream rather than upstream. The volume of erroneous
> SELinux denials in Bugzilla is too high, and the response time for
> fixing them too slow. SELinux profiles work best when they are
> maintained upstream by application developers who are familiar with
> SELinux, not by SELinux developers who are unfamiliar with the
> application.

The issue with SELinux is that it's monolithic and program-centeric. You
cannot write a SELinux policy that keeps pace with updated libraries.

E.g. you have a program that resolves user names to UIDs via glibc. If
nsswitch changes it's configuration to use LDAP, the program starts
making TCP connection. Or you have a program that links to a library
that enables JIT and then the program starts requiring writetable and
executable memory mapping.

So a change in a dependency out of control of the program upstream
invalidates the policy. That's the reason why SELinux policy is
maintained downstream.

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

Re: Strange situation with Wine on Fedora 27

[Samuel Rakitničan]

> Hello, I'm just trying to install the Wine via dnf and get:
> # dnf install wine ... Error: Transaction check error:
>   file /usr/share/doc/gstreamer1/NEWS from install of 
> gstreamer1-1.12.1-1.fc27.i686
> conflicts with file from package gstreamer1-1.12.0-1.fc27.x86_64
>   file /usr/share/doc/gstreamer1/RELEASE from install of 
> gstreamer1-1.12.1-1.fc27.i686

Maybe, but not with the packages. What most likely happened is that package 
manager died in the middle of an upgrade causing old packages left behind thus 
causing dupes. You would need to resolve this before you can continue to use 
package manager for upgrades.

You can check for dupes with dnf repoquery --dupes

To fix it, you can use following command,
  dnf remove $(dnf repoquery -q --duplicated --latest-limit=-1)

but first make sure you are removing about the same amount of packages as it's 
listed with command:
  dnf repoquery --duplicated --latest-limit=-1 -q | wc -l

I had some issues that that command would remove most packages from the system, 
leaving it in unworkable state.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cbang build error on epel

[Samuel Rakitničan]

> Argument 4 is the "n".  The problem is with the definition of "PRIo64. 
> There was a recent commit attempting to fix that, but it probably needs 
> some adjustment to handle your case.  Check out the lines around line 48 
> in that file and see if you can patch it to work in all cases.  The odd 
> thing is that it only doesn't work on epel7.  I guess you need to 
> compare how old the compiler is on there compared to the Fedora versions.

So Joseph and I managed to fix this for epel7 with following patch:

 src/cbang/tar/TarHeader.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/cbang/tar/TarHeader.cpp b/src/cbang/tar/TarHeader.cpp
index 470b37c..50df710 100644
--- a/src/cbang/tar/TarHeader.cpp
+++ b/src/cbang/tar/TarHeader.cpp
@@ -45,7 +45,8 @@
 #endif
 
 #ifndef PRIo64
-#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__))
+#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) || \
+  defined(__aarch64__) || defined(__ppc64__) || defined(__PPC64__)
 #define PRIo64 "lo"
 #else
 #define PRIo64 "llo"

It seems GCC 4.8 needs these macros defined explicitly, while GCC > 6 inherits 
it from something else (_M_X64 perhaps?), thoughts?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: pure-ftpd 1.0.46 released!

[Vascom]

I am builded it https://koji.fedoraproject.org/koji/taskinfo?taskID=20472651
You can try this build and check it functionality.

Also I can try tslk with maintainers and may be gone comaintainer. Then I
will update package in repos.

ср, 12 июл. 2017 г. в 9:11, Petr Pisar :

> On 2017-07-11, Vascom  wrote:
> > Dominik, are you try communicate with it's maintainers?
> >
> Surely they know about it
>  but their package
> is broken since Fedora 26
> .
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Guido Aulisi]

I'm still using some old 32 bit physical servers with Fedora, and they
still work well!
So I would like to have a 32 bit kernel for some other releases, maybe
f28 if possible.

Guido

2017-07-12 2:18 GMT+02:00 Solomon Peachy :
> On Wed, Jul 12, 2017 at 12:00:05AM +0200, Zdenek Kabelac wrote:
>> The question is - why - certainly not  because CPU got less powerfull that
>
> No, it's because modern desktop environments are much more heavily
> GPU-dependent to the point where the (very lousy) onboard GPUs on
> 2005-era laptops are simply not able to keep up -- or force
> non-optimized software-based rendering fallbacks.
>
>> it's been 10-12 years back -  but  when   gnome clock  needs  30MB,
>> and rendering of html pages  often takes over 100MB - and nobody cares about
>> any performance regression since  new shiny i7 is so fast to 'mask' all
>> programmers faults and 32GB or RAM also needs some usage
>
> The real limitation for that old 2005-era laptop is its ability to hold
> enough memory to allow someone to fire up Chrome and hit facebook.com
> without hitting swap.  The pokey GPU will be the the other problem.
>
> But that's not due to programmers getting sloppy or not caring about
> resource usage -- it's due to the realities of modern computing.  A
> modern web browser is certianly "more bloated" than older ones, but that
> bloat buys you many more capabilities than before, not to mention
> javascript engines that are an order of magnitude faster than the ones
> of a decade ago.  Modern web sites require those capabilities and the
> greatly increased system resources (CPU, GPU, and Memory) those entail.
>
>  - Solomon
> --
> Solomon Peachy pizza at shaftnet dot org
> Delray Beach, FL  ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum videtur.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cbang build error on epel

[Samuel Rakitničan]

> GCC > 6
That should say GCC 6 and newer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cbang build error on epel

[Dan Horák]

On Wed, 12 Jul 2017 08:17:46 -
Samuel Rakitničan  wrote:

> > Argument 4 is the "n".  The problem is with the definition of
> > "PRIo64. There was a recent commit attempting to fix that, but it
> > probably needs some adjustment to handle your case.  Check out the
> > lines around line 48 in that file and see if you can patch it to
> > work in all cases.  The odd thing is that it only doesn't work on
> > epel7.  I guess you need to compare how old the compiler is on
> > there compared to the Fedora versions.
> 
> So Joseph and I managed to fix this for epel7 with following patch:
> 
>  src/cbang/tar/TarHeader.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/cbang/tar/TarHeader.cpp b/src/cbang/tar/TarHeader.cpp
> index 470b37c..50df710 100644
> --- a/src/cbang/tar/TarHeader.cpp
> +++ b/src/cbang/tar/TarHeader.cpp
> @@ -45,7 +45,8 @@
>  #endif
>  
>  #ifndef PRIo64
> -#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__))
> +#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__))
> || \
> +  defined(__aarch64__) || defined(__ppc64__) || defined(__PPC64__)
>  #define PRIo64 "lo"
>  #else
>  #define PRIo64 "llo"
> 
> It seems GCC 4.8 needs these macros defined explicitly, while GCC > 6
> inherits it from something else (_M_X64 perhaps?), thoughts?

I guess it depends if (and how) inttypes.h header gets included, it's
provided by glibc.


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

Re: pure-ftpd 1.0.46 released!

[Vascom]

Rebuild with corrected systemd service file.
https://koji.fedoraproject.org/koji/taskinfo?taskID=20472917

ср, 12 июл. 2017 г. в 11:21, Vascom :

> I am builded it
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20472651
> You can try this build and check it functionality.
>
> Also I can try tslk with maintainers and may be gone comaintainer. Then I
> will update package in repos.
>
> ср, 12 июл. 2017 г. в 9:11, Petr Pisar :
>
>> On 2017-07-11, Vascom  wrote:
>> > Dominik, are you try communicate with it's maintainers?
>> >
>> Surely they know about it
>>  but their package
>> is broken since Fedora 26
>> .
>>
>> -- Petr
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 mass rebuild at risk

[Florian Weimer]

On 07/12/2017 03:48 AM, Carlos O'Donell wrote:
> * Rebuild glibc
>  
>   * Patch committed to trunk [In progress -- IBM]
> * codonell talking to IBM about fix for static linking.

Not needed for the mass rebuild IMHO.

>   * Sync to Fedora [Waiting -- Red Hat]
> * Waiting for new compiler to retest glibc builds.

Current glibc master does not build in rawhide anymore:

malloc.c: In function 'tcache_init.part.9':
malloc.c:1590:50: error: array subscript is above array bounds
[-Werror=array-bounds]
 #define fastbin(ar_ptr, idx) ((ar_ptr)->fastbinsY[idx])
  ^~
malloc.c:3572:26: note: in expansion of macro 'fastbin'
   mfastbinptr *fb = &fastbin (av, idx);
  ^~~

It's probably triggered by constant propagation of the size parameter
into _int_malloc, but we'd have to look at GIMPLE dumps to be sure.

I think I'm going to commit my upstream sync to dist-git anyway because
it contains other adjustments for the upstream sync.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> > Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
> > with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
> > regardless of whether the above change is accepted.
> 
> If you require SSE2, you limit the usefulness of the i686 kernel to 
> basically just a single generation of CPUs, the next generation introduced 
> x86_64.

Right. It probably makes sense to abandon i686 kernels altogether,
then.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Christian Dersch]

On 07/12/2017 02:06 AM, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
>> with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
>> regardless of whether the above change is accepted.
> If you require SSE2, you limit the usefulness of the i686 kernel to 
> basically just a single generation of CPUs, the next generation introduced 
> x86_64.
>
Well, there is one very important CPU family which came some years
later: Intel Atom. There are still many netbooks out there and the first
Atom generations are 32 bit only afaik.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 July 2017 at 12:04, Christian Dersch wrote:
> On 07/12/2017 02:06 AM, Kevin Kofler wrote:
> > Dominik 'Rathann' Mierzejewski wrote:
> >> Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
> >> with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
> >> regardless of whether the above change is accepted.
> > If you require SSE2, you limit the usefulness of the i686 kernel to 
> > basically just a single generation of CPUs, the next generation introduced 
> > x86_64.
> >
> Well, there is one very important CPU family which came some years
> later: Intel Atom. There are still many netbooks out there and the first
> Atom generations are 32 bit only afaik.

https://en.wikipedia.org/wiki/Intel_Atom

The 32 bit-only ones are:
Z5xx (April 2008)
Z6xx (May 2010)
N2xx (June 2008)

I still have my N270 netbook, but I guess even more people still have
Z6xx-based devices. Still, they're over 7 years old at this point.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Sérgio Basto]

On Wed, 2017-07-12 at 11:57 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:
> > Dominik 'Rathann' Mierzejewski wrote:
> > > Considering that SSE2 was introduced by Intel in 2001 and AMD
> > > caught up
> > > with it in 2003, I'd be +1 (with my FESCo hat on) to requiring
> > > SSE2,
> > > regardless of whether the above change is accepted.
> > 
> > If you require SSE2, you limit the usefulness of the i686 kernel
> > to 
> > basically just a single generation of CPUs, the next generation
> > introduced 
> > x86_64.
> 
> Right. It probably makes sense to abandon i686 kernels altogether,
> then.

IIRC my first x86_64 was from 2006 [1], which means all hardware before
that will not run Fedora . Thinking that we are discussing if we still
should support floppy disks ... 
Sometimes I think we should have more balance, please consider also el6
 which have EOL in November 30, 2020 

[1]
https://en.wikipedia.org/wiki/Pentium_Dual-Core
[2]
https://access.redhat.com/support/policy/updates/errata/

Cheers,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Tom Hughes]

On 12/07/17 11:16, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 12 July 2017 at 12:04, Christian Dersch wrote:


Well, there is one very important CPU family which came some years
later: Intel Atom. There are still many netbooks out there and the first
Atom generations are 32 bit only afaik.


https://en.wikipedia.org/wiki/Intel_Atom

The 32 bit-only ones are:
Z5xx (April 2008)
Z6xx (May 2010)
N2xx (June 2008)

I still have my N270 netbook, but I guess even more people still have
Z6xx-based devices. Still, they're over 7 years old at this point.


That may be true but you can actually still buy them today. My firewall 
at home is using an Intel D945GSEJT mini-itx board which you can still 
buy now and which has an Atom N270 on it.


Sounds like I need to plan for rebuilding it in the next year or so anyway.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Strange situation with Wine on Fedora 27

[Thomas Goffin]

Thanks for reaction, the problem was in the duplicate:
* gstreamer1-1.12.1-1.fc27* gstreamer1-1.12.0-1.fc27
Maybe it will be a good idea to use 'installonly_limit=1' into a dnf 
configuration sometimes.



Regards.


On Wednesday, July 12, 2017, 10:50:51 AM GMT+3, Samuel Rakitničan 
 wrote:

> Hello, I'm just trying to install the Wine via dnf and get:
> # dnf install wine ... Error: Transaction check error:
>   file /usr/share/doc/gstreamer1/NEWS from install of 
> gstreamer1-1.12.1-1.fc27.i686
> conflicts with file from package gstreamer1-1.12.0-1.fc27.x86_64
>   file /usr/share/doc/gstreamer1/RELEASE from install of 
> gstreamer1-1.12.1-1.fc27.i686

Maybe, but not with the packages. What most likely happened is that package 
manager died in the middle of an upgrade causing old packages left behind thus 
causing dupes. You would need to resolve this before you can continue to use 
package manager for upgrades.

You can check for dupes with dnf repoquery --dupes

To fix it, you can use following command,
  dnf remove $(dnf repoquery -q --duplicated --latest-limit=-1)

but first make sure you are removing about the same amount of packages as it's 
listed with command:
  dnf repoquery --duplicated --latest-limit=-1 -q | wc -l

I had some issues that that command would remove most packages from the system, 
leaving it in unworkable state.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Christian Dersch]

On 07/12/2017 12:26 PM, Reindl Harald wrote:



Am 12.07.2017 um 12:04 schrieb Christian Dersch:

On 07/12/2017 02:06 AM, Kevin Kofler wrote:

Dominik 'Rathann' Mierzejewski wrote:
Considering that SSE2 was introduced by Intel in 2001 and AMD 
caught up

with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
regardless of whether the above change is accepted.

If you require SSE2, you limit the usefulness of the i686 kernel to
basically just a single generation of CPUs, the next generation 
introduced

x86_64.


Well, there is one very important CPU family which came some years
later: Intel Atom. There are still many netbooks out there and the first
Atom generations are 32 bit only afaik.


you know how old SSE2 is?
they pretty sure support it


Yes they do, I wanted to state that we're not talking about "just a 
single generation of CPUs" because x86_64 came.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/11/2017 10:57 PM, Josh Boyer wrote:

On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
 wrote:

On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:

I ran into this unannounced change:

   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels


I noticed this is categorized as self-contained, which I think is wrong.

I also have hardware that would no longer run Fedora after such change
(a netbook with an older Intel Atom CPU which supports SSE2, but is
32bit). Unless the change proponent can provide some numbers suggesting
that 32bit users are a tiny minority of our userbase, I'll probably
be against such change.


Anyone with 32-bit hardware is going to be against this change.

Well, many 32-bit intels support SSE2. Original i686ers don't.

That said, I am against this step.


 It is
a known downside.  It also doesn't change the fact that i686 kernels
are in a zombie state, where the kernel team does not actively support
them and the community has not significantly stepped up to do so.
That approach was done quite a while ago, and explicitly communicated.

This was a step, anybody with 32bit HW should have being against.

And in deed, I have always considered this decision to be management and 
leadership mistake.



The fact that i686 kernels continue to work in general is basically luck.
You probably will deny this, but in practice it has been so for many 
years, because the i686 has dropped out of RHAT's business interest.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:

Dominik 'Rathann' Mierzejewski wrote:

Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
regardless of whether the above change is accepted.


If you require SSE2, you limit the usefulness of the i686 kernel to
basically just a single generation of CPUs, the next generation introduced
x86_64.


Right. It probably makes sense to abandon i686 kernels altogether,
then.


If you intend to kill Fedora, and furtherly emphasize the impression of 
Fedora not being community driven distro :(


Ralf


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

Re: pure-ftpd 1.0.46 released!

[Martin Sehnoutka]

I was going to rebase it as well. You can find my package here:
https://copr.fedorainfracloud.org/coprs/msehnout/pure-ftpd/

but I also don't have commit access.

On 07/12/2017 10:35 AM, Vascom wrote:
> Rebuild with corrected systemd service file.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20472917
>
> ср, 12 июл. 2017 г. в 11:21, Vascom  >:
>
> I am builded
> it https://koji.fedoraproject.org/koji/taskinfo?taskID=20472651
> You can try this build and check it functionality.
>
> Also I can try tslk with maintainers and may be gone comaintainer.
> Then I will update package in repos.
>
> ср, 12 июл. 2017 г. в 9:11, Petr Pisar  >:
>
> On 2017-07-11, Vascom  > wrote:
> > Dominik, are you try communicate with it's maintainers?
> >
> Surely they know about it
>  but
> their package
> is broken since Fedora 26
> .
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 mass rebuild at risk

[Florian Weimer]

On 07/12/2017 10:44 AM, Florian Weimer wrote:
> On 07/12/2017 03:48 AM, Carlos O'Donell wrote:
>> * Rebuild glibc
>>  
>>   * Patch committed to trunk [In progress -- IBM]
>> * codonell talking to IBM about fix for static linking.
> 
> Not needed for the mass rebuild IMHO.

I was wrong about that.  sln and ldconfig are affected by this issue, so
we need to fix it before the mass rebuild.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 12:16 PM, Dominik 'Rathann' Mierzejewski wrote:


I still have my N270 netbook, but I guess even more people still have
Z6xx-based devices. Still, they're over 7 years old at this point.


The N270s are still supported by Windows 10.

Furthermore: Linux (thus Fedora) has always one of the last resorts for 
people wanting to escape Windows' and their violent HW obsolesence on 
older HW.


Do you want Fedora to join this choir? I don't.

Ralf


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/11/2017 10:43 PM, Matthew Miller wrote:

On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:

I ran into this unannounced change:
   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
If this is accepted, all x86 hardware on which Fedora can run will
support SSE2, and we should reflect that in the i686 build flags.
How likely is it that this proposal is accepted?  Ideally, we would know
this before the mass rebuild so that we can change the compiler flags in
redhat-rpm-config.


Currently i686 users are at about 1/6th of x86_64 users, by mirror
checkins. I don't have an easy way of knowing how many of those i686
checkins are old releases -- I'll need to ask Smooge to make a custom
report -- but I think it's fair to guess that it's significantly tilted
that way. So, taking a SWAG, I'd say maybe 10% of our users would be
impacted. That's pretty big, but on the other hand if the cost is
disproportionate If cost is an issue, consider to drop all these ppc, arm, s370 and mips 

targets.

Their user base is like magnitudes smaller than the i686 user base, 
while these target are having a significant impact (and thus cost) on 
everything in Fedora.



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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Kevin Kofler]

mcatanz...@gnome.org wrote:
>> In the discussed approach where the Flatpak is composed from RPMs, the
>> library is updated by upstream, packaged, the Flatpak is rebuilt with
>> the
>> new library, and that is delivered to the user. So the extra step
>> happens
>> between the packaging of the library and the delivery to the user.
> 
> Maybe. I'm not sure about this. I believe the Flatpaks we're initially
> planning to distribute will be composed from *Fedora* RPMs... not
> upstream Flatpaks, at least not at first. So it should be possible to
> build Fedora infrastructure for using Fedora RPMs as the basis for the
> bundled libraries, and tracking them, and rebuilding affected Flatpaks
> when there is a security problem. And stuff that's bundled frequently
> enough could probably just go into the Fedora runtime.

It is true that automatically rebuilding the Flatpak if one of the RPMs it 
is composed of has changed can speed up things a bit. I think there would 
still be delays incurred in practice though.

> I kinda agree here (though I am a bit surprised, as I did not think you
> were a very big SELinux fan). We absolutely could be investing more in
> SELinux. But we have not been. Very few applications actually have
> SELinux profiles, and they are all maintained downstream rather than
> upstream. The volume of erroneous SELinux denials in Bugzilla is too
> high, and the response time for fixing them too slow. SELinux profiles
> work best when they are maintained upstream by application developers
> who are familiar with SELinux, not by SELinux developers who are
> unfamiliar with the application. But application developers who are
> familiar with SELinux basically do not exist, and never will. So it
> would be useful to have a general sandbox that works for the vast
> majority of desktop apps.

Of course, I agree about those issues with SELinux, that is exactly why I 
don't like it (and in fact don't even have it enabled, to be honest). I 
think the main issue is really that the policy is mandated centrally rather 
than being opted in by the individual application. The seccomp approach is 
much better there, but…

> Yes and yes, both are true. But also: noo. seccomp is useful to
> supplement a general purpose sandbox, but it's not suitable to be the
> primary sandboxing mechanism. A secure, restrictive seccomp policy is
> extremely, *extremely* brittle: if a library you depend on starts using
> a new syscall, your application is going to crash. So it either
> requires bundling libraries, or else never updating system libraries.
> It is basically impossible to use them to construct an effective
> restrictive sandbox unless it is highly targeted to a specific
> application that bundles its dependencies and is maintained by a large
> team of experienced developers. That's why it works well for Chromium.
> (The team maintaining the Chromium sandbox is very good; they have gone
> so far as to block calling syscalls with specific flags that they know
> Chromium never uses, just to reduce the kernel attack surface.) I tried
> a similar approach for WebKit a few years ago and quickly found it to
> be completely unworkable; my favorite anecdote is how a Fedora update
> to libxshmfence caused pages to not render anymore, because
> libxshmfence started using a new syscall (it was memfd_create) that was
> not whitelisted by the sandbox.  We can't have that. Another anecdote
> is the new seccomp sandbox for tracker-extract: whenever a GStreamer
> plugin starts using a new unexpected syscall, or if you just happen to
> have unexpected plugins installed, tracker-extract will crash. The
> sandbox has to know everything about every possible GStreamer plugin
> (so hope you never write your own custom one!). tracker is not the
> greatest example here, because it is not an application, but my point
> is that seccomp certainly cannot be used to construct a restrictive,
> general-purpose sandbox, because applications are different and use
> different syscalls. So if you're going to use seccomp as your primary
> sandboxing mechanism, you'd better bundle all your libraries and not
> allow any plugins. (I don't think you'd like that very much. ;)

… you are right about the libraries. SELinux also has this issue, by the 
way, as Petr Pisar correctly pointed out.

This is actually an issue even for QtWebEngine:
https://bugzilla.redhat.com/show_bug.cgi?id=1438973

I think it would really help if we had a way for libraries to declare their 
own seccomp rules rather than forcing the application to guess.


It is clear that confining applications to a container helps sandboxing a 
lot. But there ought to be a way to do it without physically duplicating 
everything. How about building a virtual file system view (file system 
namespacing exists in the kernel these days, doesn't it?) that contains a 
read-only view of the system /usr (and possibly other needed directories), 
together with other directories mounted off a container ima

Re: super-drafty F28 and F29 schedules

[Kevin Kofler]

Michael Catanzaro wrote:
> We need a GNOME 3.26 release.

Then push it as an update to F26 as is done with KDE Plasma releases.

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

Commencing perl to perl-interpreter rename

[Petr Pisar]

On 2017-06-15, Jan Kurik  wrote:
>= Proposed System Wide Change: perl Package to Install Core Modules =
> https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
>
Because all Fedora branches recognize perl-interpreter dependency now
I will start renaming the dependency in all affected packages. There
will be two rounds:

(1) I will rename BuildRequires in 2300 spec files. The only change will
be the rename. Not Release bump. The commit message will be "perl
dependency renamed to perl-interpreter
".

(2) I will rename Requires (and BuildRequires where presented) in
another 74 packages. These will receive Release bump and they will be
rebuilt in Koji. Everything in one commit with the same commit message.
(The 75th package is "kernel" that will receive only the rename. No
release bump, no rebuild.)

Then I will rename binary perl package to perl-interpreter in perl.spec
and rebuild perl. This will effectively materialize the goal of this
change.

After few days, I will recheck existence of perl dependencies in source
packages and correct them. There is an inevitable window beteen
gathering the package list and applying the changes, thus it's possible
that some packages slip.

-- Petr

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

Re: super-drafty F28 and F29 schedules

[Jakub Jelinek]

On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
> On 07/06/2017 09:15 PM, Matthew Miller wrote:
> > https://fedoraproject.org/wiki/Releases/28/Schedule
> 
> I encourage Jeff Law and Jakub Jelinek to review these schedules
> for compiler related issues.
> 
> This is just a perfunctory review from the glibc perspective with
> regard to base ABI and API issues in this core runtime.
> 
> 2018-01-10 MASS REBUILD
> - This date is ahead of the glibc release on 2018-02-01
>   but after the 2018-01-01 ABI freeze date for glibc.
>   Therefore you will be largely assured a stable ABI upon
>   which to base Fedora, _but_ there is a vanishingly small
>   chance you may need a mass rebuild or a targeted rebuild
>   on 2018-02-01 if something has to be reverted.

2018-01-10 is way too early for a mass rebuild from GCC point of view,
even if we perform the test mass rebuild over the Christmas break,
there won't be enough time to analyze it and fix any GCC issues revealed
during that time.  GCC bugfixing usually starts around November 15th and
needs some time before it can be fixed enough to use widely.
Moving the mass rebuild one week earlier than last time
is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
is a bad idea for both the compiler and Fedora.

As for F29, there is no GCC release around that time, so from GCC POV the
schedule doesn't matter that much.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -
> On Tue, Jul 11, 2017 at 10:55:25PM +0200, Michal Schorm wrote:
> > He won't install it on his home desktop PC or work laptop. He rather find
> > an old dusty laptop from 2005 in his shed and starts to learn there.
> 
> If we're being honest, a typical 2005-era laptop is going to yield a
> rather lousy experience with any modern Linux Desktop.  (And an even
> lousier experience with modern Windows!)

This is my old go-to-blogpost for such comments:
http://www.hadess.net/2015/04/jdll-2015.html

For about 50 dollars/pounds/euros, you can transform a 10 year old machine
into something that'll be decently usable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Date-ICal (master). "perl dependency renamed to perl-interpreter "

[notifications]

From 5430dd6927062178ec833a8594bfe00c0568741e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:13:43 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-Date-ICal.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Date-ICal.spec b/perl-Date-ICal.spec
index f068720..e335d7c 100644
--- a/perl-Date-ICal.spec
+++ b/perl-Date-ICal.spec
@@ -11,7 +11,7 @@ BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 # Run-time:
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Date-ICal.git/commit/?h=master&id=5430dd6927062178ec833a8594bfe00c0568741e
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -

> If you intend to kill Fedora, and furtherly emphasize the impression of
> Fedora not being community driven distro :(

For the distro to be community-driven, somebody needs to get behind the
wheel. Nobody's done that for i686 kernels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Unified database for DNF

[Jaroslav Reznik]

= Proposed Self Contained Change: Unified database for DNF =
https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF

Change owner(s):
* Eduard Čuba 
* Igor Gnatenko 

Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json)
with new unified sqlite database adapted to the current needs of DNF.

== Detailed Description ==
Using single unified database with shared interface enhances data
integrity, safety and performance of package managers in Fedora.
Database is easily expandable for new features (Modularity support in
DNF will use SWDB).

== Scope ==

* Proposal owners: Port DNF to SWDB (patches has been already sent),
Port PackageKit to SWDB

* Other developers: PackageKit developers should review proposed
changes in libdnf for logging PackageKit transactions into SWDB
instead of yumdb. In addition PackageKit developers should consider
using SWDB for reading transaction data instead of using its own
backend.

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: Change affects whole distro rather than some derivable

* Policies and guidelines: Nothing is required

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6886
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-threads-shared (master). "perl dependency renamed to perl-interpreter "

[notifications]

From ddb63aeefc3a7fe8d3beb381763e03e49de728f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:14:30 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-threads-shared.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
index a7c6ae0..5aecaae 100644
--- a/perl-threads-shared.spec
+++ b/perl-threads-shared.spec
@@ -8,7 +8,7 @@ Source0:
http://www.cpan.org/authors/id/J/JD/JDHEDDEN/threads-shared-%{ve
 BuildRequires:  findutils
 BuildRequires:  gcc
 BuildRequires:  make
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-threads-shared.git/commit/?h=master&id=ddb63aeefc3a7fe8d3beb381763e03e49de728f8
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Florian Weimer]

On 07/12/2017 02:10 PM, Jakub Jelinek wrote:
> On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
>> On 07/06/2017 09:15 PM, Matthew Miller wrote:
>>> https://fedoraproject.org/wiki/Releases/28/Schedule
>>
>> I encourage Jeff Law and Jakub Jelinek to review these schedules
>> for compiler related issues.
>>
>> This is just a perfunctory review from the glibc perspective with
>> regard to base ABI and API issues in this core runtime.
>>
>> 2018-01-10 MASS REBUILD
>> - This date is ahead of the glibc release on 2018-02-01
>>   but after the 2018-01-01 ABI freeze date for glibc.
>>   Therefore you will be largely assured a stable ABI upon
>>   which to base Fedora, _but_ there is a vanishingly small
>>   chance you may need a mass rebuild or a targeted rebuild
>>   on 2018-02-01 if something has to be reverted.
> 
> 2018-01-10 is way too early for a mass rebuild from GCC point of view,
> even if we perform the test mass rebuild over the Christmas break,
> there won't be enough time to analyze it and fix any GCC issues revealed
> during that time.  GCC bugfixing usually starts around November 15th and
> needs some time before it can be fixed enough to use widely.
> Moving the mass rebuild one week earlier than last time
> is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
> is a bad idea for both the compiler and Fedora.
> 
> As for F29, there is no GCC release around that time, so from GCC POV the
> schedule doesn't matter that much.

I also expect that the next glibc cycle will be even worse as far as
glibc stability during the freeze is concerned, so I'm skeptical about a
rebuild in mid-January as well.

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

Re: super-drafty F28 and F29 schedules

[Matthew Miller]

On Wed, Jul 12, 2017 at 02:20:29PM +0200, Florian Weimer wrote:
> > 2018-01-10 is way too early for a mass rebuild from GCC point of view,
> > even if we perform the test mass rebuild over the Christmas break,
> > there won't be enough time to analyze it and fix any GCC issues revealed
> > during that time.  GCC bugfixing usually starts around November 15th and
> > needs some time before it can be fixed enough to use widely.
> > Moving the mass rebuild one week earlier than last time
> > is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
> > is a bad idea for both the compiler and Fedora.
> I also expect that the next glibc cycle will be even worse as far as
> glibc stability during the freeze is concerned, so I'm skeptical about a
> rebuild in mid-January as well.

Do you guys have a suggestion to address this which does not result in
a June or July target date overall? Because I really, really don't want
to do that again.

-- 
Matthew Miller

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

F27 Self Contained Change: Packaging Rust applications/libraries

[Jaroslav Reznik]

= Proposed Self Contained Change: Packaging Rust applications/libraries =
https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries

Change owner(s):
* Igor Gnatenko  (on behalf of Rust SIG)

Add required tools/instructions for packaging applications/libraries
written in Rust. Rust is a systems programming language that runs
blazingly fast, prevents segfaults, and guarantees thread safety.

== Detailed Description ==

During initial research of SIG about packaging we identified that
inability to specify version range dependencies (1.0 <= foo < 2.0) in
RPM is main blocker. This problem hits almost every other language
ecosystem (esp. NodeJS), but it is not very noticable due to having
not more than 2 versions. While packaging some applications we
discovered need of having 3 or more versions of same crate.

The most of the work already has been done and users can consume
applications without needing to do anything from Rust/Playground COPR
repository [1].

== Scope ==

* Proposal owners: Create tool for automatic creation of rpm-spec-file
from crate on crates.io, create RPM macro for easy packaging, write
packaging guidelines.

* Other developers: RPM developers to add support for expressing
version range dependencies.

* Release engineering: #6889 (a check of an impact with Release
Engineering is needed)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: Packaging Guidelines needs to be written
for packaging Rust applications/libraries.

* Trademark approval: N/A (not needed for this Change)

[1] https://copr.fedorainfracloud.org/coprs/g/rust/playground/
[2] https://pagure.io/releng/issue/6889

Thanks,
Jaroslav
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Wed, Jul 12, 2017 at 7:24 AM, Ralf Corsepius  wrote:
> On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:
>>
>> On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:
>>>
>>> Dominik 'Rathann' Mierzejewski wrote:

 Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
 with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
 regardless of whether the above change is accepted.
>>>
>>>
>>> If you require SSE2, you limit the usefulness of the i686 kernel to
>>> basically just a single generation of CPUs, the next generation
>>> introduced
>>> x86_64.
>>
>>
>> Right. It probably makes sense to abandon i686 kernels altogether,
>> then.
>
>
> If you intend to kill Fedora, and furtherly emphasize the impression of
> Fedora not being community driven distro :(

Community driven doesn't mean "I complain and someone else does the
work so I get what I want."  If you would like to see i686 kernels
continue to be supported, please step up and volunteer to lead that
effort.  We asked for community help several releases ago and got
none.

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

F27 Self Contained Change: No More i686 Kernels

[Jaroslav Reznik]

= Proposed Self Contained Change: No More i686 Kernels =
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

Change owner(s):
* Justin Forbes 

Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.

== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing, and
issues frequently appear upstream. These tend to go unnoticed for long
periods of time. When issues are found, it is often a long time before
they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel. With this proposal, the i686
kernel will no longer be built. A kernel headers package will still
exist, and all 32bit packages should continue to build as normal. The
main difference is there would no longer be bootable 32bit images.

== Scope ==

* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.

* Other developers: NA

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issues/6894

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

ppisar pushed to perl-Config-Model-Tester (master). "perl dependency renamed to perl-interpreter "

[notifications]

From 368053f76f9b6057da48947a606e511e7242246c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:28:35 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-Config-Model-Tester.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Config-Model-Tester.spec b/perl-Config-Model-Tester.spec
index 26a4079..70e44ac 100644
--- a/perl-Config-Model-Tester.spec
+++ b/perl-Config-Model-Tester.spec
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/Config-Model-Tester/
 Source0:
http://www.cpan.org/authors/id/D/DD/DDUMONT/Config-Model-Tester-%{version}.tar.gz
 BuildArch:  noarch
 
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 # Bootstrap to prevent circular dependency on perl-Config-Model
 %if !%{defined perl_bootstrap}
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Config-Model-Tester.git/commit/?h=master&id=368053f76f9b6057da48947a606e511e7242246c
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 01:39 PM, Reindl Harald wrote:



Am 12.07.2017 um 13:24 schrieb Ralf Corsepius:

On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:

Dominik 'Rathann' Mierzejewski wrote:
Considering that SSE2 was introduced by Intel in 2001 and AMD 
caught up

with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
regardless of whether the above change is accepted.


If you require SSE2, you limit the usefulness of the i686 kernel to
basically just a single generation of CPUs, the next generation 
introduced

x86_64.


Right. It probably makes sense to abandon i686 kernels altogether,
then.


If you intend to kill Fedora, and furtherly emphasize the impression 
of Fedora not being community driven distro :(


that is FUD and polemic
Well, I of course have disagree. The course Fedora has taken is obvious: 
Servers and  containers.


And the course Fedora i686 has taken leads users directly to Ubuntu, 
Debian, Windows or the trash bin.



i strongly doubt a relevant usebase is on i686 kernels at all for 
reasons mutilple times explained - why would anybody run a bleeding 
edge distribution seriously on ages old hardware


Like I said before, I doubt the arm, powerpc etc. to have a user-base 
which is magnitudes smaller than the i686.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Miller]

On Wed, Jul 12, 2017 at 01:43:53PM +0200, Ralf Corsepius wrote:
> If cost is an issue, consider to drop all these ppc, arm, s370 and
> mips targets.
> 
> Their user base is like magnitudes smaller than the i686 user base,
> while these target are having a significant impact (and thus cost)
> on everything in Fedora.

Ralf, you know how this works: Fedora is made up of people, and
therefore Fedora does what people show up to do. People are showing up
to work on those other architectures, even though they are niche, and
*no one* is showing up for i686. So, while I agree the user impact is
worse, the *cost* isn't equivalent at all.

-- 
Matthew Miller

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

ppisar pushed to perl-Sys-Syslog (master). "perl dependency renamed to perl-interpreter "

[notifications]

From 83945d126fbf0c186456748b8a9ae5ec84b6c8d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:31:44 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-Sys-Syslog.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Sys-Syslog.spec b/perl-Sys-Syslog.spec
index 4fff104..f57565c 100644
--- a/perl-Sys-Syslog.spec
+++ b/perl-Sys-Syslog.spec
@@ -18,7 +18,7 @@ BuildRequires:  findutils
 BuildRequires:  gcc
 BuildRequires:  glibc-common
 BuildRequires:  make
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Sys-Syslog.git/commit/?h=master&id=83945d126fbf0c186456748b8a9ae5ec84b6c8d4
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Software-License (master). "perl dependency renamed to perl-interpreter "

[notifications]

From 92b681b860fac8d564ba190e02d640b9d98af756 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:31:53 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-Software-License.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Software-License.spec b/perl-Software-License.spec
index 1475ac6..7206dd2 100644
--- a/perl-Software-License.spec
+++ b/perl-Software-License.spec
@@ -18,7 +18,7 @@ BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 # Module Runtime
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Software-License.git/commit/?h=master&id=92b681b860fac8d564ba190e02d640b9d98af756
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Miller]

On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:
> >The fact that i686 kernels continue to work in general is basically luck.
> You probably will deny this, but in practice it has been so for many
> years, because the i686 has dropped out of RHAT's business interest.

I don't think this is unreasonable. It is easy for us to support
architectures that a company is paying people to support. It is hard
for us to support architectures that are not getting that that kind of
support. As noted in this thread, this isn't just Red Hat -- it is true
of upstream i686 as well. No one is really interested in this. I
guarantee you that if some non-Red Hat person showed up and said "Hey,
I'm here to work on i686 N hours per week", we would say "awesome", not
"Red Hat doesn't care".

-- 
Matthew Miller

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -

> > - make it possible to create Flatpaks quicker for some more complicated
> > apps
> 
> That just requires shipping the tools for third parties to use, not using
> them to deliver software packaged by Fedora.

The tooling is koji and bohdi. Shipping them isn't enough, hosting them is
necessary as well.

> > - developers not having to learn GPG to sign their releases
> 
> That is a very weak argument. It is very straightforward to set up an RPM
> signing key, not any harder than writing a specfile. And then you just run
> rpmsign --addsign to sign the RPMs.
> 
> And in the end, you are just saying that Flatpak does away with a critical
> security feature. Relying exclusively on the sandboxing for security is a
> very bad idea. Sandbox evasion exploits exist.

"developers not having to learn GPG to sign their *Flatpak* releases"

I really don't understand how you misinterpreted that sentence so badly,
individual Fedora developers never had to GPG sign their Fedora packages...

> > - more efficient update tracking than RPM (eg. no need to download 20 megs
> >   of metadata to know there's nothing to update)
> 
> But less efficient updating, because you will need to download much more
> than 20 megs of bundled libraries.

You download deltas, so the downloading is unlikely to be any worse than
downloading packaged updates. It also means I can update individual apps
without guesswork.

> The only reason the metadata is smaller
> is because there is almost no dependency information encoded (only a single
> dependency on a runtime). But those dependencies are what makes installing
> and updating packages so efficient! Flatpak throws away the main competitive
> advantage of GNU/Linux!

It's not efficient if I need to download 20 megs of data to see that I have
nothing to update. I really don't see why dependencies make installing and
updating packages "so efficient".

> And it is actually possible to solve the metadata size issue, see the work
> on metadata deltas. (There was at least one talk at DevConf on this.)

Right. It's just not done yet.

I started replying from the bottom of the mail, but I stopped midway. The
number of unsubstantiated claims got the better of me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Improved Bay- and Cherry-Trail device support

[Jaroslav Reznik]

= Proposed Self Contained Change: mproved Bay- and Cherry-Trail device support =
https://fedoraproject.org/wiki/Changes/Improved_Bay_Cherry_Trail_Support

Change owner(s):
* Hans de Goede 

Improve support for hardware using Intel Bay Trail and Cherry Trail SoCs.

== Detailed Description ==
There are many affordable x86 laptops / tablets using Intel Bay Trail
and Cherry Trail SoCs this change is about improving support for these
SoCs and the peripherals typically found on devices with these SoCs.
Examples of improvements in progress are fixing battery monitoring,
touchscreen, audio and accelerometers (sometimes) not working.

== Scope ==

* Proposal owners:
Most of the work on this is kernel work and most of this is being done upstream
The Fedora kernel package needs to have the right drivers enabled as
well as some patches backported
Some small userspace changes like adding new entries to hwdb for
accelerometer orientation

* Other developers: The non-upstream kernel and hwdb changes need to
be coordinated with their resp. package owners

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6881

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

Re: super-drafty F28 and F29 schedules

[Florian Weimer]

On 07/12/2017 02:29 PM, Matthew Miller wrote:
> On Wed, Jul 12, 2017 at 02:20:29PM +0200, Florian Weimer wrote:
>>> 2018-01-10 is way too early for a mass rebuild from GCC point of view,
>>> even if we perform the test mass rebuild over the Christmas break,
>>> there won't be enough time to analyze it and fix any GCC issues revealed
>>> during that time.  GCC bugfixing usually starts around November 15th and
>>> needs some time before it can be fixed enough to use widely.
>>> Moving the mass rebuild one week earlier than last time
>>> is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
>>> is a bad idea for both the compiler and Fedora.
>> I also expect that the next glibc cycle will be even worse as far as
>> glibc stability during the freeze is concerned, so I'm skeptical about a
>> rebuild in mid-January as well.
> 
> Do you guys have a suggestion to address this which does not result in
> a June or July target date overall? Because I really, really don't want
> to do that again.

For glibc, we can perhaps make arrangements that we have the people
around to force things into a buildable state.  But considering
upstream's freeze policies, it's still risky.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Hans de Goede]

Hi,

On 11-07-17 22:57, Josh Boyer wrote:

On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
 wrote:

On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:

I ran into this unannounced change:

   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels


I noticed this is categorized as self-contained, which I think is wrong.

I also have hardware that would no longer run Fedora after such change
(a netbook with an older Intel Atom CPU which supports SSE2, but is
32bit). Unless the change proponent can provide some numbers suggesting
that 32bit users are a tiny minority of our userbase, I'll probably
be against such change.


Anyone with 32-bit hardware is going to be against this change.  It is
a known downside.  It also doesn't change the fact that i686 kernels
are in a zombie state, where the kernel team does not actively support
them and the community has not significantly stepped up to do so.


I still have (some) 32 bit hardware in use and I must say that I was
not aware of this zombie state. i686 kernels have been working fine for
me otherwise I would have likely stepped up to fix things (or if that
was too much work replace my last 32bit hardware), but I may just have
been lucky and never hit a bad kernel.

If the kernel team wants some specific help with ia32 support then
2 things need to happen:

1) A clear request for help needs to be send
2) What exactly they need help with needs to be clearly defined

Also this is plainly false advertising:

== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.

Nope, 32 bit i686 users are just plain out of luck, unless they
have a 64 bit capable CPU but are still running a 32 bit OS for some
reason (yes I'm aware this is mentioned later, but it clearly
belongs under this header).

Last as others have said, this is _clearly_ a systemwide change
and the deadline for systemwide change proposals for F27 was July
4th, where as this page was created July 6th, moreover a change as
big as this really needs to be discussed out in the open long before
it gets implemented rather then hidden away in a Changes page.

Regards,

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

ppisar pushed to perl-lib-abs (master). "perl dependency renamed to perl-interpreter "

[notifications]

From 15e66943ab284bcfcd58e293876ae0b84982b59a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:52:15 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-lib-abs.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-lib-abs.spec b/perl-lib-abs.spec
index 9febe06..27d9f8b 100644
--- a/perl-lib-abs.spec
+++ b/perl-lib-abs.spec
@@ -7,7 +7,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/lib-abs/
 Source0:
http://www.cpan.org/authors/id/M/MO/MONS/lib-abs-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(inc::Module::Install)
 BuildRequires:  perl(Module::Install::AutoInstall)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-lib-abs.git/commit/?h=master&id=15e66943ab284bcfcd58e293876ae0b84982b59a
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede  wrote:
> Hi,
>
> On 11-07-17 22:57, Josh Boyer wrote:
>>
>> On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
>>  wrote:
>>>
>>> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:

 I ran into this unannounced change:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>>
>>>
>>> I noticed this is categorized as self-contained, which I think is wrong.
>>>
>>> I also have hardware that would no longer run Fedora after such change
>>> (a netbook with an older Intel Atom CPU which supports SSE2, but is
>>> 32bit). Unless the change proponent can provide some numbers suggesting
>>> that 32bit users are a tiny minority of our userbase, I'll probably
>>> be against such change.
>>
>>
>> Anyone with 32-bit hardware is going to be against this change.  It is
>> a known downside.  It also doesn't change the fact that i686 kernels
>> are in a zombie state, where the kernel team does not actively support
>> them and the community has not significantly stepped up to do so.
>
>
> I still have (some) 32 bit hardware in use and I must say that I was
> not aware of this zombie state. i686 kernels have been working fine for
> me otherwise I would have likely stepped up to fix things (or if that
> was too much work replace my last 32bit hardware), but I may just have
> been lucky and never hit a bad kernel.
>
> If the kernel team wants some specific help with ia32 support then
> 2 things need to happen:
>
> 1) A clear request for help needs to be send
> 2) What exactly they need help with needs to be clearly defined

https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html


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

Re: pure-ftpd 1.0.46 released!

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 12, 2017 at 01:27:09PM +0200, Martin Sehnoutka wrote:
> I was going to rebase it as well. You can find my package here:
> https://copr.fedorainfracloud.org/coprs/msehnout/pure-ftpd/
> 
> but I also don't have commit access.

On 07/12/2017 10:35 AM, Vascom wrote:
> Rebuild with corrected systemd service file.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20472917

Did you apply for acls in pkgdb?

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

Re: pure-ftpd 1.0.46 released!

[Dominik Kucher]

Vascom schrieb am 2017-07-12 um 10:21:
> I am builded
> it https://koji.fedoraproject.org/koji/taskinfo?taskID=20472651
> You can try this build and check it functionality.
>
> Also I can try tslk with maintainers and may be gone comaintainer.
> Then I will update package in repos.
>
> ср, 12 июл. 2017 г. в 9:11, Petr Pisar  >:
>
> On 2017-07-11, Vascom  > wrote:
> > Dominik, are you try communicate with it's maintainers?
> >
> Surely they know about it
>  but their
> package
> is broken since Fedora 26
> .
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
i have build it about a month :-)
it runs on my fedora 25 without problems

the bug numbers are not valid

--
[root@srv-dksoft:]# rpm -qa | grep pure-ftpd
pure-ftpd-1.0.46-6.fc25.20170611.dk.x86_64

---
[builduser@buildsrv:]$cat pure-ftpd.spec
Name:  pure-ftpd
Version:   1.0.46
Release:   7%{?dist}
Summary:   Lightweight, fast and secure FTP server
Group: System Environment/Daemons
License:   BSD
URL:   https://www.pureftpd.org/project/pure-ftpd
Source0:   %{name}-%{version}.tar.bz2
Source1:   %{name}.service

Provides:  ftpserver
BuildRequires: pam-devel
BuildRequires: perl
BuildRequires: python
BuildRequires: libcap-devel
BuildRequires: mariadb-devel
BuildRequires: checkpolicy
Requires:  usermode

%description
Pure-FTPd is a fast, production-quality, standard-comformant FTP server,
based upon Troll-FTPd. Unlike other popular FTP servers, it has no known
security flaw, it is really trivial to set up and it is especially designed
for modern Linux and FreeBSD kernels.

%prep
%setup -q


%build
export CFLAGS="%{optflags} -fPIE -fuse-ld=gold -fuse-linker-plugin"
export CXXFLAGS="$CFLAGS"
export FFLAGS="$CFLAGS"
export CC="gcc $CFLAGS"
export LDFLAGS="-Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -pie $CFLAGS"
%configure  \
 --sysconfdir=%{_sysconfdir}/%{name} \
 --with-capabilities \
 --with-sendfile \
 --with-paranoidmsg \
 --with-altlog \
 --with-puredb \
 --with-pam \
 --with-throttling \
 --with-virtualhosts \
 --with-virtualchroot \
 --with-diraliases \
 --with-mysql \
 --with-privsep \
 --with-rfc2640 \
 --with-boring \
 --without-inetd \
 --without-sysquotas \
 --without-uploadscript \
 --without-ratios \
 --without-quotas \
 --without-ftpwho \
 --without-implicittls \
 --without-tls \
 --without-ldap \
 --without-pgsql \
 --without-peruserlimits \
 --without-usernames \
 --without-bonjour \
 --without-humor \
 --without-inetd \
 --without-debug
%{__make} %{?_smp_mflags}

%install
make install-strip DESTDIR=%{buildroot}
install -d -m 755 %{buildroot}%{_unitdir}
install -p -m 644 %{SOURCE1} %{buildroot}%{_unitdir}/%{name}.service
install -d -m 755 $RPM_BUILD_ROOT%{_sbindir}
rm %{buildroot}%{_sbindir}/pure-ftpwho
%{buildroot}%{_sbindir}/pure-uploadscript
rm -rf %{buildroot}%{_mandir} %{buildroot}%{_sysconfdir}/%{name}

%post
%systemd_post

%files
%{_bindir}/pure-*
%{_sbindir}/pure-*
%{_unitdir}/%{name}.service



[root@srv-dksoft:]# cat /etc/systemd/system/pure-ftpd.service
[Unit]
Description=Pure-FTPd Server

[Service]
Type=forking
ExecStart=/usr/sbin/pure-config.pl /etc/pure-ftpd/pure-ftpd.conf --daemonize
Restart=always
RestartSec=1

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=~CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT
CAP_SYS_MODULE CAP_SYS_PTRACE
RestrictAddressFamilies=AF_LOCAL AF_INET AF_INET6
SystemCallArchitectures=x86-64
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
delete_module fanotify_init finit_module get_mempolicy init_module
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
open_by_handle_at perf_event_open pivot_root process_vm_readv
process_vm_writev ptrace remap_file_pages request_key set_mempolicy
swapoff swapon umount2 uselib vmsplice

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectori

Re: No i686 kernel: Can we require SSE2 for i686?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:
> On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:
> > >The fact that i686 kernels continue to work in general is basically luck.
> > You probably will deny this, but in practice it has been so for many
> > years, because the i686 has dropped out of RHAT's business interest.
> 
> I don't think this is unreasonable. It is easy for us to support
> architectures that a company is paying people to support. It is hard
> for us to support architectures that are not getting that that kind of
> support. As noted in this thread, this isn't just Red Hat -- it is true
> of upstream i686 as well. No one is really interested in this. I
> guarantee you that if some non-Red Hat person showed up and said "Hey,
> I'm here to work on i686 N hours per week", we would say "awesome", not
> "Red Hat doesn't care".

Would it be possible to make this a Prioritized Bug?
It seems to be a classic case of "affects a lot of people, nobody seems
to want to take interest".

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

Re: pure-ftpd 1.0.46 released!

[Dominik Kucher]

bug report -> https://bugzilla.redhat.com/show_bug.cgi?id=1470184

Dominik Kucher schrieb am 2017-07-12 um 15:26:
> Vascom schrieb am 2017-07-12 um 10:21:
>> I am builded
>> it https://koji.fedoraproject.org/koji/taskinfo?taskID=20472651
>> You can try this build and check it functionality.
>>
>> Also I can try tslk with maintainers and may be gone comaintainer.
>> Then I will update package in repos.
>>
>> ср, 12 июл. 2017 г. в 9:11, Petr Pisar > >:
>>
>> On 2017-07-11, Vascom > > wrote:
>> > Dominik, are you try communicate with it's maintainers?
>> >
>> Surely they know about it
>>  but their
>> package
>> is broken since Fedora 26
>> .
>>
>> -- Petr
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> 
>> To unsubscribe send an email to
>> devel-le...@lists.fedoraproject.org
>> 
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> i have build it about a month :-)
> it runs on my fedora 25 without problems
>
> the bug numbers are not valid
>
> --
> [root@srv-dksoft:]# rpm -qa | grep pure-ftpd
> pure-ftpd-1.0.46-6.fc25.20170611.dk.x86_64
>
> ---
> [builduser@buildsrv:]$cat pure-ftpd.spec
> Name:  pure-ftpd
> Version:   1.0.46
> Release:   7%{?dist}
> Summary:   Lightweight, fast and secure FTP server
> Group: System Environment/Daemons
> License:   BSD
> URL:   https://www.pureftpd.org/project/pure-ftpd
> Source0:   %{name}-%{version}.tar.bz2
> Source1:   %{name}.service
>
> Provides:  ftpserver
> BuildRequires: pam-devel
> BuildRequires: perl
> BuildRequires: python
> BuildRequires: libcap-devel
> BuildRequires: mariadb-devel
> BuildRequires: checkpolicy
> Requires:  usermode
>
> %description
> Pure-FTPd is a fast, production-quality, standard-comformant FTP server,
> based upon Troll-FTPd. Unlike other popular FTP servers, it has no known
> security flaw, it is really trivial to set up and it is especially designed
> for modern Linux and FreeBSD kernels.
>
> %prep
> %setup -q
>
>
> %build
> export CFLAGS="%{optflags} -fPIE -fuse-ld=gold -fuse-linker-plugin"
> export CXXFLAGS="$CFLAGS"
> export FFLAGS="$CFLAGS"
> export CC="gcc $CFLAGS"
> export LDFLAGS="-Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -pie $CFLAGS"
> %configure  \
>  --sysconfdir=%{_sysconfdir}/%{name} \
>  --with-capabilities \
>  --with-sendfile \
>  --with-paranoidmsg \
>  --with-altlog \
>  --with-puredb \
>  --with-pam \
>  --with-throttling \
>  --with-virtualhosts \
>  --with-virtualchroot \
>  --with-diraliases \
>  --with-mysql \
>  --with-privsep \
>  --with-rfc2640 \
>  --with-boring \
>  --without-inetd \
>  --without-sysquotas \
>  --without-uploadscript \
>  --without-ratios \
>  --without-quotas \
>  --without-ftpwho \
>  --without-implicittls \
>  --without-tls \
>  --without-ldap \
>  --without-pgsql \
>  --without-peruserlimits \
>  --without-usernames \
>  --without-bonjour \
>  --without-humor \
>  --without-inetd \
>  --without-debug
> %{__make} %{?_smp_mflags}
>
> %install
> make install-strip DESTDIR=%{buildroot}
> install -d -m 755 %{buildroot}%{_unitdir}
> install -p -m 644 %{SOURCE1} %{buildroot}%{_unitdir}/%{name}.service
> install -d -m 755 $RPM_BUILD_ROOT%{_sbindir}
> rm %{buildroot}%{_sbindir}/pure-ftpwho
> %{buildroot}%{_sbindir}/pure-uploadscript
> rm -rf %{buildroot}%{_mandir} %{buildroot}%{_sysconfdir}/%{name}
>
> %post
> %systemd_post
>
> %files
> %{_bindir}/pure-*
> %{_sbindir}/pure-*
> %{_unitdir}/%{name}.service
>
> 
>
> [root@srv-dksoft:]# cat /etc/systemd/system/pure-ftpd.service
> [Unit]
> Description=Pure-FTPd Server
>
> [Service]
> Type=forking
> ExecStart=/usr/sbin/pure-config.pl /etc/pure-ftpd/pure-ftpd.conf --daemonize
> Restart=always
> RestartSec=1
>
> PrivateTmp=yes
> PrivateDevices=yes
> CapabilityBoundingSet=~CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT
> CAP_SYS_MODULE CAP_SYS_PTRACE
> RestrictAddressFamilies=AF_LOCAL AF_INET AF_INET6
> SystemCallArchitectures=x86-64
> SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
> delete_module fanotify_init finit_module get_mempolicy init_module
> io_dest

Re: Fedora 27 mass rebuild at risk

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jul 07, 2017 at 02:53:36PM +0200, Florian Weimer wrote:
> We currently have an invalid IFUNC resolver in libgcc.a on POWER
> (rhbz#1467526).  glibc in rawhide recently started linking that into the
> library and there are significant problems with that (rhbz#1467518).
> 
> I'll be on PTO next week, and it does not seem likely that this is going
> to be resolved upstream before that.  If upstream (both glibc GCC are
> involved) don't come up with a solution, I'm not sure
> 
> If we downgrade glibc to 2.25 in rawhide, we will have to rebuild at
> least the following packages right after that because they have a
> GLIBC_2.26 symbol version dependency:
> 
>  inn-2.6.1-6.fc27.src.rpm
>  remctl-3.13-4.fc27.src.rpm
>  sudo-1.8.20p2-1.fc27.src.rpm
>  tmux-2.5-1.fc27.src.rpm
>  unbound-1.6.4-1.fc27.src.rpm
>  xorg-x11-server-1.19.3-6.fc27.src.rpm
> 
> Besides the glibc downgrade, I'm not aware of anything else we could do
> to get ready for the mass rebuild in time.

So, I had a look at https://bugzilla.redhat.com/show_bug.cgi?id=F26FTBFS,
and the situation is not good :( There's 621 open bugs on that list,
and it's quite likely most of those packages will FTBFS on 27 too.

All packagers should pitch in to reduce this list before the mass rebuild
starts.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Hans de Goede]

Hi,

On 12-07-17 15:18, Josh Boyer wrote:

On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede  wrote:

Hi,

On 11-07-17 22:57, Josh Boyer wrote:


On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
 wrote:


On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:


I ran into this unannounced change:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels



I noticed this is categorized as self-contained, which I think is wrong.

I also have hardware that would no longer run Fedora after such change
(a netbook with an older Intel Atom CPU which supports SSE2, but is
32bit). Unless the change proponent can provide some numbers suggesting
that 32bit users are a tiny minority of our userbase, I'll probably
be against such change.



Anyone with 32-bit hardware is going to be against this change.  It is
a known downside.  It also doesn't change the fact that i686 kernels
are in a zombie state, where the kernel team does not actively support
them and the community has not significantly stepped up to do so.



I still have (some) 32 bit hardware in use and I must say that I was
not aware of this zombie state. i686 kernels have been working fine for
me otherwise I would have likely stepped up to fix things (or if that
was too much work replace my last 32bit hardware), but I may just have
been lucky and never hit a bad kernel.

If the kernel team wants some specific help with ia32 support then
2 things need to happen:

1) A clear request for help needs to be send
2) What exactly they need help with needs to be clearly defined


https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html


Which is yet another generic, non specific call for help. Which
unsurprisingly (given its unspecificness) did probably not get
a lot of response.

What would be helpful is a concrete list of things people who
care about i686 can work about. For example an i686 kernel tracker
bug + link to that on the https://fedoraproject.org/wiki/Kernel
page.

I believe that something among the lines of: "we need help, but we
are not really specifying what, still please do something" is not
going to get you a lot of help.

OTOH "here is a prioritized list of TODO items, if all of the
high prio items have not been solved before $date, then we are
going to have to drop ia32 support from F28" OTOH will likely
be much more effective IMHO. This will cut 2 ways:
1) It will likely get the kernel team more help
2) If the kernel team does not get help, or not enough, then
you have a strong argument that not enough people care about
ia32 bit support and it should be dropped

Regards,

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

Re: super-drafty F28 and F29 schedules

[Remi Collet]

Le 07/07/2017 à 03:15, Matthew Miller a écrit :

> I took a look at the planned F27 schedule
> https://fedoraproject.org/wiki/Releases/27/Schedule 

Less than 4 months between F26 and F27 ?
Seriously ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: No More i686 Kernels

[Hans de Goede]

Hi,

On 12-07-17 14:36, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: No More i686 Kernels =
> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>

I hereby formally object against this being
categorized as a "Self Contained Change" it clearly
is not.

Regards,

Hans



Change owner(s):
* Justin Forbes 

Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.

== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing, and
issues frequently appear upstream. These tend to go unnoticed for long
periods of time. When issues are found, it is often a long time before
they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel. With this proposal, the i686
kernel will no longer be built. A kernel headers package will still
exist, and all 32bit packages should continue to build as normal. The
main difference is there would no longer be bootable 32bit images.

== Scope ==

* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.

* Other developers: NA

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issues/6894

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


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Solomon Peachy]

On Wed, Jul 12, 2017 at 08:17:06AM -0400, Bastien Nocera wrote:
> > If we're being honest, a typical 2005-era laptop is going to yield a
> > rather lousy experience with any modern Linux Desktop.  (And an even
> > lousier experience with modern Windows!)
> 
> This is my old go-to-blogpost for such comments:
> http://www.hadess.net/2015/04/jdll-2015.html
> 
> For about 50 dollars/pounds/euros, you can transform a 10 year old machine
> into something that'll be decently usable.

Oddly enough, you inadvertently made my point -- That link doesn't refer 
to a 2005-era laptop, instead it's a nearly-three-year newer "bookend" 
system containing a CPU capable of both SSE2 and x86_64 (ie an Intel 
Core2Duo), better I/O, and more upgradability opportunities than a 
laptop from a few years prior.

(Those 2-3 years represent the difference in hardware generations being 
discussed here!)

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: pure-ftpd 1.0.46 released!

[Dominik Kucher]

i have build it about a month 
it runs on my fedora 25 without problems

the bug numbers are not valid

--
[root@srv-dksoft:]# rpm -qa | grep pure-ftpd
pure-ftpd-1.0.46-6.fc25.20170611.dk.x86_64

---
[builduser@buildsrv:]$cat pure-ftpd.spec
Name:  pure-ftpd
Version:   1.0.46
Release:   7%{?dist}
Summary:   Lightweight, fast and secure FTP server
Group: System Environment/Daemons
License:   BSD
URL:   https://www.pureftpd.org/project/pure-ftpd
Source0:   %{name}-%{version}.tar.bz2
Source1:   %{name}.service

Provides:  ftpserver
BuildRequires: pam-devel
BuildRequires: perl
BuildRequires: python
BuildRequires: libcap-devel
BuildRequires: mariadb-devel
BuildRequires: checkpolicy
Requires:  usermode

%description
Pure-FTPd is a fast, production-quality, standard-comformant FTP server,
based upon Troll-FTPd. Unlike other popular FTP servers, it has no known
security flaw, it is really trivial to set up and it is especially designed
for modern Linux and FreeBSD kernels.

%prep
%setup -q


%build
export CFLAGS="%{optflags} -fPIE -fuse-ld=gold -fuse-linker-plugin"
export CXXFLAGS="$CFLAGS"
export FFLAGS="$CFLAGS"
export CC="gcc $CFLAGS"
export LDFLAGS="-Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -pie $CFLAGS"
%configure  \
 --sysconfdir=%{_sysconfdir}/%{name} \
 --with-capabilities \
 --with-sendfile \
 --with-paranoidmsg \
 --with-altlog \
 --with-puredb \
 --with-pam \
 --with-throttling \
 --with-virtualhosts \
 --with-virtualchroot \
 --with-diraliases \
 --with-mysql \
 --with-privsep \
 --with-rfc2640 \
 --with-boring \
 --without-inetd \
 --without-sysquotas \
 --without-uploadscript \
 --without-ratios \
 --without-quotas \
 --without-ftpwho \
 --without-implicittls \
 --without-tls \
 --without-ldap \
 --without-pgsql \
 --without-peruserlimits \
 --without-usernames \
 --without-bonjour \
 --without-humor \
 --without-inetd \
 --without-debug
%{__make} %{?_smp_mflags}

%install
make install-strip DESTDIR=%{buildroot}
install -d -m 755 %{buildroot}%{_unitdir}
install -p -m 644 %{SOURCE1} %{buildroot}%{_unitdir}/%{name}.service
install -d -m 755 $RPM_BUILD_ROOT%{_sbindir}
rm %{buildroot}%{_sbindir}/pure-ftpwho
%{buildroot}%{_sbindir}/pure-uploadscript
rm -rf %{buildroot}%{_mandir} %{buildroot}%{_sysconfdir}/%{name}

%post
%systemd_post

%files
%{_bindir}/pure-*
%{_sbindir}/pure-*
%{_unitdir}/%{name}.service



[root@srv-dksoft:]# cat /etc/systemd/system/pure-ftpd.service
[Unit]
Description=Pure-FTPd Server

[Service]
Type=forking
ExecStart=/usr/sbin/pure-config.pl /etc/pure-ftpd/pure-ftpd.conf --daemonize
Restart=always
RestartSec=1

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=~CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT
CAP_SYS_MODULE CAP_SYS_PTRACE
RestrictAddressFamilies=AF_LOCAL AF_INET AF_INET6
SystemCallArchitectures=x86-64
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
delete_module fanotify_init finit_module get_mempolicy init_module
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
open_by_handle_at perf_event_open pivot_root process_vm_readv
process_vm_writev ptrace remap_file_pages request_key set_mempolicy
swapoff swapon umount2 uselib vmsplice

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root
InaccessibleDirectories=-/etc/dbus-1
InaccessibleDirectories=-/etc/modprobe.d
InaccessibleDirectories=-/etc/modules-load.d
InaccessibleDirectories=-/etc/sysctl.d
InaccessibleDirectories=-/run/console
InaccessibleDirectories=-/run/dbus
InaccessibleDirectories=-/run/lock
InaccessibleDirectories=-/run/mount
InaccessibleDirectories=-/run/systemd/generator
InaccessibleDirectories=-/run/systemd/system
InaccessibleDirectories=-/run/systemd/users
InaccessibleDirectories=-/run/udev
InaccessibleDirectories=-/run/user
InaccessibleDirectories=-/usr/local/scripts
InaccessibleDirectories=-/var/lib/dbus
InaccessibleDirectories=-/var/lib/dnf
InaccessibleDirectories=-/var/lib/rpm
InaccessibleDirectories=-/var/lib/systemd
InaccessibleDirectories=-/var/lib/yum
InaccessibleDirectories=-/var/spool

InaccessibleDirectories=-/etc/httpd
InaccessibleDirectories=-/etc/postfix
InaccessibleDirectories=-/etc/ssh

InaccessibleDirectories=-/data/backup
InaccessibleDirectories=-/data/dokuments/
InaccessibleDirectories=-/data/scripts
InaccessibleDirectories=-/server/vmware

ReadOnlyDirectories=-/data/se

Re: No i686 kernel: Can we require SSE2 for i686?

[Hans de Goede]

Hi,

On 12-07-17 14:40, Matthew Miller wrote:

On Wed, Jul 12, 2017 at 01:43:53PM +0200, Ralf Corsepius wrote:

If cost is an issue, consider to drop all these ppc, arm, s370 and
mips targets.

Their user base is like magnitudes smaller than the i686 user base,
while these target are having a significant impact (and thus cost)
on everything in Fedora.


Ralf, you know how this works: Fedora is made up of people, and
therefore Fedora does what people show up to do. People are showing up
to work on those other architectures, even though they are niche, and
*no one* is showing up for i686.


That is not true. Let me quote my reply to Josh on this:

"""

> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html

Which is yet another generic, non specific call for help. Which
unsurprisingly (given its unspecificness) did probably not get
a lot of response.

What would be helpful is a concrete list of things people who
care about i686 can work about. For example an i686 kernel tracker
bug + link to that on the https://fedoraproject.org/wiki/Kernel
page.

I believe that something among the lines of: "we need help, but we
are not really specifying what, still please do something" is not
going to get you a lot of help.

OTOH "here is a prioritized list of TODO items, if all of the
high prio items have not been solved before $date, then we are
going to have to drop ia32 support from F28" OTOH will likely
be much more effective IMHO. This will cut 2 ways:
1) It will likely get the kernel team more help
2) If the kernel team does not get help, or not enough, then
you have a strong argument that not enough people care about
ia32 bit support and it should be dropped

"""

I believe there are 2 problems here:

1) i686 support is limping on in a state where it more or less
still just works, so there are no itches to scratch and thus no
volunteers

2) There have been some requests of help, but they have IMHO
not been specific enough. A request for help should really be
seen as sort of a bug report and just like "the program does
not work" or "the program is broken" are not useful bug reports
"we need help" is not a useful request for help.

Regards,

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 12-07-17 15:18, Josh Boyer wrote:
>>
>> On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 11-07-17 22:57, Josh Boyer wrote:


 On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
  wrote:
>
>
> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:
>>
>>
>> I ran into this unannounced change:
>>
>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>
>
>
> I noticed this is categorized as self-contained, which I think is
> wrong.
>
> I also have hardware that would no longer run Fedora after such change
> (a netbook with an older Intel Atom CPU which supports SSE2, but is
> 32bit). Unless the change proponent can provide some numbers suggesting
> that 32bit users are a tiny minority of our userbase, I'll probably
> be against such change.



 Anyone with 32-bit hardware is going to be against this change.  It is
 a known downside.  It also doesn't change the fact that i686 kernels
 are in a zombie state, where the kernel team does not actively support
 them and the community has not significantly stepped up to do so.
>>>
>>>
>>>
>>> I still have (some) 32 bit hardware in use and I must say that I was
>>> not aware of this zombie state. i686 kernels have been working fine for
>>> me otherwise I would have likely stepped up to fix things (or if that
>>> was too much work replace my last 32bit hardware), but I may just have
>>> been lucky and never hit a bad kernel.
>>>
>>> If the kernel team wants some specific help with ia32 support then
>>> 2 things need to happen:
>>>
>>> 1) A clear request for help needs to be send
>>> 2) What exactly they need help with needs to be clearly defined
>>
>>
>> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
>
>
> Which is yet another generic, non specific call for help. Which
> unsurprisingly (given its unspecificness) did probably not get
> a lot of response.
>
> What would be helpful is a concrete list of things people who
> care about i686 can work about. For example an i686 kernel tracker
> bug + link to that on the https://fedoraproject.org/wiki/Kernel
> page.

That's a great idea.  Are you volunteering to triage all the bugs and
create it and maintain that list?

> I believe that something among the lines of: "we need help, but we
> are not really specifying what, still please do something" is not
> going to get you a lot of help.
>
> OTOH "here is a prioritized list of TODO items, if all of the
> high prio items have not been solved before $date, then we are
> going to have to drop ia32 support from F28" OTOH will likely
> be much more effective IMHO. This will cut 2 ways:
> 1) It will likely get the kernel team more help
> 2) If the kernel team does not get help, or not enough, then
> you have a strong argument that not enough people care about
> ia32 bit support and it should be dropped

I have no vested interest in the kernel team any longer other than
history and sympathy for the workload they face, but it is 100%
acceptable for a team with that much workload to simply say "we are
not prioritizing this anymore" irrespective of what other people want.
To be honest, they've done much more to keep it building and working
than I would have.  So while you may want them to define concrete
actionable items, I don't find that acceptable.  They don't do that
for arm, ppc64le, or s390x yet those continue to build and work just
fine.  People that care about i686 should be able to step in and
define those themselves.  If they can't then I'd suggest the kernel
team just ExcludeArch i686 at the next build break.  At least that is
an immediate actionable item.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Xavier Bachelot]

On 11/07/2017 23:30, Solomon Peachy wrote:

On Tue, Jul 11, 2017 at 04:43:27PM -0400, Matthew Miller wrote:

Currently i686 users are at about 1/6th of x86_64 users, by mirror
checkins. I don't have an easy way of knowing how many of those i686
checkins are old releases


It's worth pointing out that won't tell us how many of those i686 users
are doing so on hardware that lacks x86_64 capabilities.


Is there a way to cross-grade from i686 to x86_64 ?
Or rather, as I know the answer to this question is very likely no, 
would there be a way to do that with a DNF plugin ?
It might be difficult to do from a running system, but could be easier 
from a system-upgrade target ?
That may help transition people with x86_64 capable hardware that are 
still running an i686 Fedora.


On a side note, I do have a bunch of old 32 bits only hardware (VIA C3 
and friends) that would sadly need to find a new distro to keep being 
useful if i686 kernel ever gets dropped from Fedora.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Stephen John Smoogen]

On 12 July 2017 at 09:09, Hans de Goede  wrote:
> Hi,
>
> On 11-07-17 22:57, Josh Boyer wrote:
>>
>> On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
>>  wrote:
>>>
>>> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:

 I ran into this unannounced change:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>>
>>>
>>> I noticed this is categorized as self-contained, which I think is wrong.
>>>
>>> I also have hardware that would no longer run Fedora after such change
>>> (a netbook with an older Intel Atom CPU which supports SSE2, but is
>>> 32bit). Unless the change proponent can provide some numbers suggesting
>>> that 32bit users are a tiny minority of our userbase, I'll probably
>>> be against such change.
>>
>>
>> Anyone with 32-bit hardware is going to be against this change.  It is
>> a known downside.  It also doesn't change the fact that i686 kernels
>> are in a zombie state, where the kernel team does not actively support
>> them and the community has not significantly stepped up to do so.
>
>
> I still have (some) 32 bit hardware in use and I must say that I was
> not aware of this zombie state. i686 kernels have been working fine for
> me otherwise I would have likely stepped up to fix things (or if that
> was too much work replace my last 32bit hardware), but I may just have
> been lucky and never hit a bad kernel.
>
> If the kernel team wants some specific help with ia32 support then
> 2 things need to happen:
>
> 1) A clear request for help needs to be send

You missed all the emails from mid 2014 to now? I mean heck I even
wrote a horrible blog post to try and get attention to it 2.5 years
ago.

2015-01 
http://smoogespace.blogspot.com/2015/01/devils-proposal-moving-fedora-to-64-bit.html

Josh made a reasoned explanation of what was causing this

2015-01 http://jwboyer.livejournal.com/49909.html

2015-02 
https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
2015-08 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GSIXKLR5RP5OIF6XMDP2WWYOKD4Y5LFM/
2016-12 https://pagure.io/fesco/issue/1655

There were several others on multiple other lists.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Chris Murphy]

On Wed, Jul 12, 2017 at 7:09 AM, Hans de Goede  wrote:

> If the kernel team wants some specific help with ia32 support then
> 2 things need to happen:
>
> 1) A clear request for help needs to be send
> 2) What exactly they need help with needs to be clearly defined

Has happened multiple times over two years.

https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSIXKLR5RP5OIF6XMDP2WWYOKD4Y5LFM/

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NJF45R5WFYVDJQJILQEWU2I4ADRYMAFN/

I'm not sure how it could be more clear.


Of course, it could have been trolled better by someone, by wiping out
the original subject and substituting -- Fedora: "death to i686!" --



> Last as others have said, this is _clearly_ a systemwide change
> and the deadline for systemwide change proposals for F27 was July
> 4th, where as this page was created July 6th, moreover a change as
> big as this really needs to be discussed out in the open long before
> it gets implemented rather then hidden away in a Changes page.

I see it both ways. It is self-contained in that it's strictly the
kernel without affecting user space at all. But it's system-wide in
that it does affect the distribution, it's effectively dropping the
hardware support for an entire architecture. But anyway, dropping i686
kernel is not a surprise to me, this has been a rather long leadout
train.


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

After reading this, I think there's a false dichotomy here:

On Tue, Jul 11, 2017 at 9:26 PM,   wrote:
> On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler 
> wrote:
>>
>> There ought to be better ways to sandbox applications than to turn them
>> into
>> what is essentially a full container (i.e., almost a full VM, only minus
>> the
>> kernel), bundling all the libraries. The split into an application and a
>> runtime that Flatpak does is only a partial workaround.
>
>
> I don't think there are better ways to sandbox applications. Sandboxing is
> what has really sold me on Flatpak.

Flatpak provides two things that are very nearly orthogonal: packaging
and sandboxing.  Packaging is the system of bundles, apps, runtimes,
etc that allows you to build a Flatpak, send it to a different
machine, and run it there, even if the other machine runs a different
distro.

Sandboxing is Flatpak's system of portals, confinement, etc.

Aside from the fact that both are based on namespaces, I see no reason
at all that they need to be conflated.  It should be entirely possible
for Flatpak ro run an "app" that is actually a conventional RPM
installed on the host system using host libraries.  Flatpak would just
map all of /usr into its namespace rather than mapping a container
bundle into its namespace.  The sandbox would work exactly the same as
for any other Flatpak except that the sandboxed app would be able to
read all of /usr.  Arguably, in a model where all of /usr is visible
in the app's namespace, development and debugging might be
considerably easier.

Perhaps Fedora should consider a scheme where graphical application
RPMs are augmented with the metadata needed to run them inside Flatpak
while still packaging them the old-fashioned way with old-fashioned
RPM library dependencies and old-fashioned build tools.  This would
almost certainly entail modifications to Flatpak, but I bet they'd be
fairly minor modifications and quite possibly much less complex than
all the tooling needed to get the average graphical application RPM to
build a functional Flatpak bundle.

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

Re: super-drafty F28 and F29 schedules

[Jeff Law]

On 07/12/2017 06:10 AM, Jakub Jelinek wrote:
> On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
>> On 07/06/2017 09:15 PM, Matthew Miller wrote:
>>> https://fedoraproject.org/wiki/Releases/28/Schedule
>>
>> I encourage Jeff Law and Jakub Jelinek to review these schedules
>> for compiler related issues.
>>
>> This is just a perfunctory review from the glibc perspective with
>> regard to base ABI and API issues in this core runtime.
>>
>> 2018-01-10 MASS REBUILD
>> - This date is ahead of the glibc release on 2018-02-01
>>   but after the 2018-01-01 ABI freeze date for glibc.
>>   Therefore you will be largely assured a stable ABI upon
>>   which to base Fedora, _but_ there is a vanishingly small
>>   chance you may need a mass rebuild or a targeted rebuild
>>   on 2018-02-01 if something has to be reverted.
> 
> 2018-01-10 is way too early for a mass rebuild from GCC point of view,
> even if we perform the test mass rebuild over the Christmas break,
> there won't be enough time to analyze it and fix any GCC issues revealed
> during that time.
Right.  Optimistically, we'd let the test mass rebuild run over the
break giving the GCC team a nice pile of issues to look at in the start
of the new year.  But even in that scenario I can't in good conscience
recommend Fedora start mass rebuilds on 01-10 -- it's just not enough
time to triage the issues from the mass rebuild and get them fixed.

01-25 is probably the earliest I'd recommend scheduling a mass rebuild
from GCC's point of view.  Even that may be overly optimistic.


  GCC bugfixing usually starts around November 15th and
> needs some time before it can be fixed enough to use widely.
> Moving the mass rebuild one week earlier than last time
> is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
> is a bad idea for both the compiler and Fedora.
FWIW I would like to see everything in the GCC process shift earlier by
a couple weeks.  I haven't had much success convincing folks to make
that shift though.



> 
> As for F29, there is no GCC release around that time, so from GCC POV the
> schedule doesn't matter that much.
Right.  The odd Fedora releases tend to just pick up whatever the latest
point release of GCC is available.   They don't tend to cause much work
or stress from a toolchain standpoint.

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

Re: Self Introduction

[Felix Yan]

On 07/12/2017 03:04 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 11, 2017 at 11:22:55PM +0800, Felix Yan wrote:
>> Hi,
>>
>> My name is Felix Yan, and I am building my first Fedora package [1]. I
>> hope it can be accepted into the Fedora project.
> 
> Hi,
> 
> welcome to Fedora!
> 
> #1468861 has already been approved (pending sponsorship), so that's pretty
> good progress.
> 
> I can sponsor you. Please do two or three reviews of other packages:
> since you're involved in Deepin, anything from
> https://bugzilla.redhat.com/show_bug.cgi?id=DeepinDEPackageReview,
> or otherwise anything from 
> http://fedoraproject.org/PackageReviewStatus/NEW.html.

Here are two reviews I did:

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

According to the wiki I should be in the packager group to follow the
further assign step, please correct me if I am wrong though.

> Did you set up your mock / fedora-review environment? If not, please
> do that. There are some docs:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Install_the_developer_client_tools,
> https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds, but
> neither page is very clear or up to date. Drop me an e-mail (at zbyszek@...)
> or ping me on IRC (zbyszek @ #fedora-devel) if you need help.

I ran mockbuild of the package I submit, but fedora-review did give me
some errors and I managed to fix them. Thanks for the tips :)

-- 
Regards,
Felix Yan



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Stephen John Smoogen]

On 11 July 2017 at 16:43, Matthew Miller  wrote:
> On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:
>> I ran into this unannounced change:
>>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>> If this is accepted, all x86 hardware on which Fedora can run will
>> support SSE2, and we should reflect that in the i686 build flags.
>> How likely is it that this proposal is accepted?  Ideally, we would know
>> this before the mass rebuild so that we can change the compiler flags in
>> redhat-rpm-config.
>
> Currently i686 users are at about 1/6th of x86_64 users, by mirror
> checkins. I don't have an easy way of knowing how many of those i686
> checkins are old releases -- I'll need to ask Smooge to make a custom
> report -- but I think it's fair to guess that it's significantly tilted
> that way. So, taking a SWAG, I'd say maybe 10% of our users would be
> impacted. That's pretty big, but on the other hand if the cost is
> disproportionate -- and having heard from the kernel people about this
> for several years, I think it might be -- it's probably something we
> should do anyway.
>

I will take that as a queue to send a report. For 2017 and F25, the
average number of users per day was

x86_32 6112.86
x86_64 101186
percentage x86_32 5.44475
percentage x86_64 93.9021

Now this doesn't say whether that hardware could run x86_64 kernels
with an x86_32 userspace. It just says that on average of ~6% of users
are using x86_32 currently.

For some images https://smooge.fedorapeople.org/stats-f25/

[The raw numbers are not as useful as the ratios due to the way
numbers of users get their internet these days. A single user in India
and China will show up as multiple ip addresses at the 'same time' as
their public ip address is rolled around via NAT over NAT hardware.
What this means is that while the raw numbers show a growth in x86_32
users in May->July those all came from India with an equal ratio
growth in x86_64 users. ]


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Hans de Goede]

Hi,

On 12-07-17 16:33, Josh Boyer wrote:

On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede  wrote:

Hi,


On 12-07-17 15:18, Josh Boyer wrote:


On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede 
wrote:


Hi,

On 11-07-17 22:57, Josh Boyer wrote:



On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
 wrote:



On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:



I ran into this unannounced change:

 https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels




I noticed this is categorized as self-contained, which I think is
wrong.

I also have hardware that would no longer run Fedora after such change
(a netbook with an older Intel Atom CPU which supports SSE2, but is
32bit). Unless the change proponent can provide some numbers suggesting
that 32bit users are a tiny minority of our userbase, I'll probably
be against such change.




Anyone with 32-bit hardware is going to be against this change.  It is
a known downside.  It also doesn't change the fact that i686 kernels
are in a zombie state, where the kernel team does not actively support
them and the community has not significantly stepped up to do so.




I still have (some) 32 bit hardware in use and I must say that I was
not aware of this zombie state. i686 kernels have been working fine for
me otherwise I would have likely stepped up to fix things (or if that
was too much work replace my last 32bit hardware), but I may just have
been lucky and never hit a bad kernel.

If the kernel team wants some specific help with ia32 support then
2 things need to happen:

1) A clear request for help needs to be send
2) What exactly they need help with needs to be clearly defined



https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html



Which is yet another generic, non specific call for help. Which
unsurprisingly (given its unspecificness) did probably not get
a lot of response.

What would be helpful is a concrete list of things people who
care about i686 can work about. For example an i686 kernel tracker
bug + link to that on the https://fedoraproject.org/wiki/Kernel
page.


That's a great idea.  Are you volunteering to triage all the bugs and
create it and maintain that list?


I believe that something among the lines of: "we need help, but we
are not really specifying what, still please do something" is not
going to get you a lot of help.

OTOH "here is a prioritized list of TODO items, if all of the
high prio items have not been solved before $date, then we are
going to have to drop ia32 support from F28" OTOH will likely
be much more effective IMHO. This will cut 2 ways:
1) It will likely get the kernel team more help
2) If the kernel team does not get help, or not enough, then
you have a strong argument that not enough people care about
ia32 bit support and it should be dropped


I have no vested interest in the kernel team any longer other than
history and sympathy for the workload they face, but it is 100%
acceptable for a team with that much workload to simply say "we are
not prioritizing this anymore" irrespective of what other people want.
To be honest, they've done much more to keep it building and working
than I would have.  So while you may want them to define concrete
actionable items, I don't find that acceptable.  They don't do that
for arm, ppc64le, or s390x yet those continue to build and work just
fine.  People that care about i686 should be able to step in and
define those themselves.  If they can't then I'd suggest the kernel
team just ExcludeArch i686 at the next build break.  At least that is
an immediate actionable item.


I find this response not helpful at all, what I see happening here is:

Person a: We need help
Person b: Ok what can I do
Person a: We need help figure it out yourself
Person b: Huh, so there is nothing to do. Ok then I guess I will go and do 
something else.

Feel free to substitute me for person b because any desire I had
to make time to help with this just went out the window.

More importantly I've the feeling that you can substitute a lot
of potential volunteers for person b in the above exchange.

To me the we need help or we will just drop support mantra,
combined with not willing to put some effort into organizing
said help feels a lot like the we need help is just an excuse
to just drop ia32 support as that is what you really want
to do all along.

Regards,

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Chris Murphy]

On Wed, Jul 12, 2017 at 8:14 AM, Hans de Goede  wrote:

>> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
>
>
> Which is yet another generic, non specific call for help. Which
> unsurprisingly (given its unspecificness) did probably not get
> a lot of response.

Find bugs.
Fix bugs.

Seems specific.


> OTOH "here is a prioritized list of TODO items, if all of the
> high prio items have not been solved before $date, then we are
> going to have to drop ia32 support from F28" OTOH will likely
> be much more effective IMHO. This will cut 2 ways:
> 1) It will likely get the kernel team more help
> 2) If the kernel team does not get help, or not enough, then
> you have a strong argument that not enough people care about
> ia32 bit support and it should be dropped

An example was given of what the kernel team will not do anymore
because they don't have the resources. And that entails becoming aware
of bugs, so you'd need a way to become aware of i686 bugs, and then
fix them, and then interface with upstream to get a fix if they have
one, or push a fix if you find one, and then patch Fedora's kernel in
the interim before the patch is accepted upstream. Literally the job
description of what the kernel team does day in and day out, they
aren't going to do for i686 kernels.

That's been my take away for like, two years.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Wed, Jul 12, 2017 at 12:23 PM, Hans de Goede  wrote:
> Hi,
>
>
> On 12-07-17 16:33, Josh Boyer wrote:
>>
>> On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 12-07-17 15:18, Josh Boyer wrote:


 On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede 
 wrote:
>
>
> Hi,
>
> On 11-07-17 22:57, Josh Boyer wrote:
>>
>>
>>
>> On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
>>  wrote:
>>>
>>>
>>>
>>> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:



 I ran into this unannounced change:


 https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>>
>>>
>>>
>>>
>>> I noticed this is categorized as self-contained, which I think is
>>> wrong.
>>>
>>> I also have hardware that would no longer run Fedora after such
>>> change
>>> (a netbook with an older Intel Atom CPU which supports SSE2, but is
>>> 32bit). Unless the change proponent can provide some numbers
>>> suggesting
>>> that 32bit users are a tiny minority of our userbase, I'll probably
>>> be against such change.
>>
>>
>>
>>
>> Anyone with 32-bit hardware is going to be against this change.  It is
>> a known downside.  It also doesn't change the fact that i686 kernels
>> are in a zombie state, where the kernel team does not actively support
>> them and the community has not significantly stepped up to do so.
>
>
>
>
> I still have (some) 32 bit hardware in use and I must say that I was
> not aware of this zombie state. i686 kernels have been working fine for
> me otherwise I would have likely stepped up to fix things (or if that
> was too much work replace my last 32bit hardware), but I may just have
> been lucky and never hit a bad kernel.
>
> If the kernel team wants some specific help with ia32 support then
> 2 things need to happen:
>
> 1) A clear request for help needs to be send
> 2) What exactly they need help with needs to be clearly defined




 https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
>>>
>>>
>>>
>>> Which is yet another generic, non specific call for help. Which
>>> unsurprisingly (given its unspecificness) did probably not get
>>> a lot of response.
>>>
>>> What would be helpful is a concrete list of things people who
>>> care about i686 can work about. For example an i686 kernel tracker
>>> bug + link to that on the https://fedoraproject.org/wiki/Kernel
>>> page.
>>
>>
>> That's a great idea.  Are you volunteering to triage all the bugs and
>> create it and maintain that list?
>>
>>> I believe that something among the lines of: "we need help, but we
>>> are not really specifying what, still please do something" is not
>>> going to get you a lot of help.
>>>
>>> OTOH "here is a prioritized list of TODO items, if all of the
>>> high prio items have not been solved before $date, then we are
>>> going to have to drop ia32 support from F28" OTOH will likely
>>> be much more effective IMHO. This will cut 2 ways:
>>> 1) It will likely get the kernel team more help
>>> 2) If the kernel team does not get help, or not enough, then
>>> you have a strong argument that not enough people care about
>>> ia32 bit support and it should be dropped
>>
>>
>> I have no vested interest in the kernel team any longer other than
>> history and sympathy for the workload they face, but it is 100%
>> acceptable for a team with that much workload to simply say "we are
>> not prioritizing this anymore" irrespective of what other people want.
>> To be honest, they've done much more to keep it building and working
>> than I would have.  So while you may want them to define concrete
>> actionable items, I don't find that acceptable.  They don't do that
>> for arm, ppc64le, or s390x yet those continue to build and work just
>> fine.  People that care about i686 should be able to step in and
>> define those themselves.  If they can't then I'd suggest the kernel
>> team just ExcludeArch i686 at the next build break.  At least that is
>> an immediate actionable item.
>
>
> I find this response not helpful at all, what I see happening here is:
>
> Person a: We need help
> Person b: Ok what can I do
> Person a: We need help figure it out yourself
> Person b: Huh, so there is nothing to do. Ok then I guess I will go and do
> something else.

No, you're completely misconstruing the email thread I linked to.  We
said people interested in helping could do so, and gave a link to some
bugs that could be looked at.  But the crux of the original post
wasn't a cry for help.  It was a clarification of where the kernel
team would be spending their time.  So to phrase it in conversational
form it's more like:

Person a: We're going to be spending our time looking at x86_64 and
fixing issues there.  i686 isn'

Re: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Wed, Jul 12, 2017 at 10:24 AM, Hans de Goede  wrote:
> Hi,
>
> On 12-07-17 14:40, Matthew Miller wrote:
>>
>> On Wed, Jul 12, 2017 at 01:43:53PM +0200, Ralf Corsepius wrote:
>>>
>>> If cost is an issue, consider to drop all these ppc, arm, s370 and
>>> mips targets.
>>>
>>> Their user base is like magnitudes smaller than the i686 user base,
>>> while these target are having a significant impact (and thus cost)
>>> on everything in Fedora.
>>
>>
>> Ralf, you know how this works: Fedora is made up of people, and
>> therefore Fedora does what people show up to do. People are showing up
>> to work on those other architectures, even though they are niche, and
>> *no one* is showing up for i686.
>
>
> That is not true. Let me quote my reply to Josh on this:
>
> """
>
>> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
>
> Which is yet another generic, non specific call for help. Which
> unsurprisingly (given its unspecificness) did probably not get
> a lot of response.
>
> What would be helpful is a concrete list of things people who
> care about i686 can work about. For example an i686 kernel tracker
> bug + link to that on the https://fedoraproject.org/wiki/Kernel
> page.
>
> I believe that something among the lines of: "we need help, but we
> are not really specifying what, still please do something" is not
> going to get you a lot of help.
>
> OTOH "here is a prioritized list of TODO items, if all of the
> high prio items have not been solved before $date, then we are
> going to have to drop ia32 support from F28" OTOH will likely
> be much more effective IMHO. This will cut 2 ways:
> 1) It will likely get the kernel team more help
> 2) If the kernel team does not get help, or not enough, then
> you have a strong argument that not enough people care about
> ia32 bit support and it should be dropped
>
> """
>
> I believe there are 2 problems here:
>
> 1) i686 support is limping on in a state where it more or less
> still just works, so there are no itches to scratch and thus no
> volunteers

That seems accurate, except for the bugs that the kernel team did fix
along the way for whatever reason.

> 2) There have been some requests of help, but they have IMHO
> not been specific enough. A request for help should really be
> seen as sort of a bug report and just like "the program does
> not work" or "the program is broken" are not useful bug reports
> "we need help" is not a useful request for help.

This is not accurate.  As I said in my other reply, the kernel team
isn't asking for help with i686.  It simply isn't a priority at all.

Also, in the context of overall i686 HW support, it is worth pointing
out that none of the Editions has a 32-bit release blocking artifact.
Most of them don't care about 32-bit installs either, with some of
them not even having them produced.

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

Re: F27 Self Contained Change: No More i686 Kernels

[Josh Boyer]

On Wed, Jul 12, 2017 at 10:16 AM, Hans de Goede  wrote:
> Hi,
>
> On 12-07-17 14:36, Jaroslav Reznik wrote:
>> = Proposed Self Contained Change: No More i686 Kernels =
>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>
>
> I hereby formally object against this being
> categorized as a "Self Contained Change" it clearly
> is not.

Agreed.  It should be System Wide.

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

Re: super-drafty F28 and F29 schedules

[Stephen John Smoogen]

On 12 July 2017 at 10:15, Remi Collet  wrote:
> Le 07/07/2017 à 03:15, Matthew Miller a écrit :
>
>> I took a look at the planned F27 schedule
>> https://fedoraproject.org/wiki/Releases/27/Schedule
>
> Less than 4 months between F26 and F27 ?
> Seriously ?

Yes, I realize a lot of people are waking up from the bender that was
the 1-2 month slippage for F26, but when people said "if we slip it
has to be taken out of F27" they meant it. The sobering reality is
that various stuff being proposed for F27 is going to have to be moved
to F28 and that is going to be a painful process of meetings and
compromises.


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Dan Williams]

On Wed, 2017-07-12 at 09:05 -0600, Chris Murphy wrote:
> On Wed, Jul 12, 2017 at 7:09 AM, Hans de Goede 
> wrote:
> 
> > If the kernel team wants some specific help with ia32 support then
> > 2 things need to happen:
> > 
> > 1) A clear request for help needs to be send
> > 2) What exactly they need help with needs to be clearly defined
> 
> Has happened multiple times over two years.
> 
> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.
> html
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/message/GSIXKLR5RP5OIF6XMDP2WWYOKD4Y5LFM/
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/message/NJF45R5WFYVDJQJILQEWU2I4ADRYMAFN/
> 
> I'm not sure how it could be more clear.
> 
> 
> Of course, it could have been trolled better by someone, by wiping
> out
> the original subject and substituting -- Fedora: "death to i686!" --
> 
> 
> 
> > Last as others have said, this is _clearly_ a systemwide change
> > and the deadline for systemwide change proposals for F27 was July
> > 4th, where as this page was created July 6th, moreover a change as
> > big as this really needs to be discussed out in the open long
> > before
> > it gets implemented rather then hidden away in a Changes page.
> 
> I see it both ways. It is self-contained in that it's strictly the
> kernel without affecting user space at all. But it's system-wide in
> that it does affect the distribution, it's effectively dropping the
> hardware support for an entire architecture. But anyway, dropping
> i686
> kernel is not a surprise to me, this has been a rather long leadout
> train.

While you're at it Chris, I (possibly ill-advisedly) touched https://bu
gzilla.redhat.com/show_bug.cgi?id=1185518 if you've still got that
machine with the ipw2100 around.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 July 2017 at 13:30, Ralf Corsepius wrote:
> On 07/12/2017 12:16 PM, Dominik 'Rathann' Mierzejewski wrote:
> 
> > I still have my N270 netbook, but I guess even more people still have
> > Z6xx-based devices. Still, they're over 7 years old at this point.
> 
> The N270s are still supported by Windows 10.
> 
> Furthermore: Linux (thus Fedora) has always one of the last resorts for
> people wanting to escape Windows' and their violent HW obsolesence on older
> HW.
> 
> Do you want Fedora to join this choir? I don't.

Me neither. However, I don't have the time to spare on working on i686
bugs. I will probably submit bug reports if something is broken, but
won't have time to fix them myself.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 July 2017 at 13:24, Ralf Corsepius wrote:
> On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:
> > On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:
> > > Dominik 'Rathann' Mierzejewski wrote:
> > > > Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
> > > > with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
> > > > regardless of whether the above change is accepted.
> > > 
> > > If you require SSE2, you limit the usefulness of the i686 kernel to
> > > basically just a single generation of CPUs, the next generation introduced
> > > x86_64.
> > 
> > Right. It probably makes sense to abandon i686 kernels altogether,
> > then.
> 
> If you intend to kill Fedora, and furtherly emphasize the impression of
> Fedora not being community driven distro :(

That's ridiculous. You can't just demand that things be done in a
"community driven distro". If you or someone else doesn't step up to
maintain the i686 kernel and fix bugs, then it should be dropped as
there's no point in having a kernel that doesn't work. Complaining
about it and doing nothing is just noise. So far, I've only seen you
complain. If you have a specific proposal and resources to continue
supporting this 7 year old platform then by all means, step up.
Otherwise I suggest you stop complaining.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Miller]

On Wed, Jul 12, 2017 at 04:24:22PM +0200, Hans de Goede wrote:
> Which is yet another generic, non specific call for help. Which
> unsurprisingly (given its unspecificness) did probably not get
> a lot of response.
> 
> What would be helpful is a concrete list of things people who
> care about i686 can work about. For example an i686 kernel tracker
> bug + link to that on the https://fedoraproject.org/wiki/Kernel
> page.
> 
> I believe that something among the lines of: "we need help, but we
> are not really specifying what, still please do something" is not
> going to get you a lot of help.

I think this is missing the point. It's not that there are specific
things that need to be fixed that need extra emergency attention. I
mean, there are, but the problem is higher than that. It's that there
is no one interested owning the *overall general maintenance*. That
includes making and maintaining the specific help-wanted list you are
looking for. If we don't even have anyone who wants to do that, how can
we possibly reasonably support the architecture?

Meanwhile, I don't personally care about PowerPC (for example), but I
know that if there's a problem, these people
https://fedoraproject.org/wiki/Architectures/PowerPC#Members are there
to answer.


-- 
Matthew Miller

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Miller]

On Wed, Jul 12, 2017 at 01:44:29PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > support. As noted in this thread, this isn't just Red Hat -- it is true
> > of upstream i686 as well. No one is really interested in this. I
> > guarantee you that if some non-Red Hat person showed up and said "Hey,
> > I'm here to work on i686 N hours per week", we would say "awesome", not
> > "Red Hat doesn't care".
> Would it be possible to make this a Prioritized Bug?
> It seems to be a classic case of "affects a lot of people, nobody seems
> to want to take interest".

Hmmm. I'm not sure it's a good fit. I hope for priotized bugs to be
things we can chase down and get some action on in the near term. This
seems bigger and less specific than that.


-- 
Matthew Miller

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Miller]

On Wed, Jul 12, 2017 at 02:36:22PM +0200, Ralf Corsepius wrote:
> >that is FUD and polemic
> Well, I of course have disagree. The course Fedora has taken is
> obvious: Servers and  containers.

I don't understand this perception. Yes, servers and containers are
important. But we pretty clearly have a prominent top-level
desktop-focused edition (Workstation, of course) plus *seven* other
desktop spins plus several desktop-focused labs. A large portion of the
articles we publish on Fedora Magazine are desktop-focused. And a huge 
number of Fedora contributors are interested in Linux on the desktop.

Our strategy is and has been to make Fedora relevant in three major
areas: the server room, the cloud, *and* desktops.


-- 
Matthew Miller

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Przemek Klosowski]

On 07/12/2017 07:43 AM, Ralf Corsepius wrote:

Currently i686 users are at about 1/6th of x86_64 users, by mirror
checkins. I don't have an easy way of knowing how many of those i686
checkins are old releases -- I'll need to ask Smooge to make a custom
report -- but I think it's fair to guess that it's significantly tilted
that way. So, taking a SWAG, I'd say maybe 10% of our users would be
impacted. That's pretty big, but on the other hand if the cost is
disproportionate If cost is an issue, consider to drop all these ppc, 
arm, s370 and mips 


Their user base is like magnitudes smaller than the i686 user base, 
while these target are having a significant impact (and thus cost) on 
everything in Fedora.


Yes, but in the resource limited world, it's reasonable to support ARM 
because it's a viable, expanding platform, whereas x686 is obsolete and 
even you would probably agree that it is in attrition mode. Even 
PPC/MIPS/S370 aren't like that---there are active precisely because some 
people still make new ones. and are willing to invest time and/or money 
in them.


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

Re: F27 Self Contained Change: No More i686 Kernels

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 12 July 2017 at 18:40, Josh Boyer wrote:
> On Wed, Jul 12, 2017 at 10:16 AM, Hans de Goede  wrote:
> > Hi,
> >
> > On 12-07-17 14:36, Jaroslav Reznik wrote:
> >> = Proposed Self Contained Change: No More i686 Kernels =
> >> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> >>
> >
> > I hereby formally object against this being
> > categorized as a "Self Contained Change" it clearly
> > is not.
> 
> Agreed.  It should be System Wide.

+1, as mentioned already in the other thread. Since it's too late to
submit a system wide change for F27, this needs to be rescheduled
as a F28 System Wide Change.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Starting an x86_32 SIG

[Stephen John Smoogen]

This is a notice to see if people are really interested in having a
SIG on 32 bit Intel. I haven't created a SIG so I am researching what
is needed but I started with this page

https://fedoraproject.org/wiki/Architectures/x86

which mirrors the various other Architecture pages I looked at. A
Special Interest Group etc would be founded on this. I don't know if a
'mailing' list is wanted etc.

The steps I see are:
1. Whatever chartering work is needed to get a SIG together.
2. A formal statement as requested by some users about the architecture
3. A survey of problems on the architecture.
4. A hardware selection the SIG are going to focus on.
5. What product the SIG is planning to deliver.

I expect there are other things, but I just want to get those out of
the way as should haves.



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

Re: No i686 kernel: Can we require SSE2 for i686?

[Chuck Anderson]

On Wed, Jul 12, 2017 at 10:27:06AM +0200, Guido Aulisi wrote:
> I'm still using some old 32 bit physical servers with Fedora, and they
> still work well!
> So I would like to have a 32 bit kernel for some other releases, maybe
> f28 if possible.

Maybe you could keep the F26 kernel and try running it with F27 and F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Samuel Sieb]

On 07/12/2017 06:09 AM, Hans de Goede wrote:

I still have (some) 32 bit hardware in use and I must say that I was
not aware of this zombie state. i686 kernels have been working fine for
me otherwise I would have likely stepped up to fix things (or if that
was too much work replace my last 32bit hardware), but I may just have
been lucky and never hit a bad kernel.


I help out a small school with all tech related issues.  They were 
donated a pile of (I think) Pentium D desktops from another school that 
was upgrading theirs.  I set up a computer lab for them running Fedora 
with a lighter WM and it's been working great.  When I saw that mailing 
list post a while back, I took one of the computers home with me for 
testing purposes, but from my view so far, there has never been an issue 
with the 32-bit kernel or userspace that has needed investigation.  More 
recently, we received some similar computers with Pentium 4 CPUs that we 
are using now.  I upgraded them all to 2GB of RAM and they work fine for 
web browsing, LibreOffice, gcompris, etc.


Of course now that I checked the CPU flags, this whole email is 
irrelevant.  Besides supporting SSE2 (which is what I was looking for), 
I just noticed they also have the x86-64 flag...  I guess if this change 
goes through I will be looking into how to run a 64-bit kernel and 
32-bit userspace.  We also still have a few laptops that are running 
32-bit Fedora, but they don't have to and they will all be retired 
within a year anyway.


As an aside, I also have a wall-embedded touchscreen Geode computer, but 
it stopped being able to run Fedora a long time ago.  I now have a 
buildroot system on it with the minimum to run an X server and remote 
display the app.

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Matthew Smith]

On Wed, Jul 12, 2017 at 8:03 PM, Samuel Sieb  wrote:
> I guess if this change goes through I
> will be looking into how to run a 64-bit kernel and 32-bit userspace.  We
> also still have a few laptops that are running 32-bit Fedora, but they don't
> have to and they will all be retired within a year anyway.

Why do you want to keep the 32-bit userspace?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[stan]

On Wed, 12 Jul 2017 14:45:29 -0400
Chuck Anderson  wrote:

> On Wed, Jul 12, 2017 at 10:27:06AM +0200, Guido Aulisi wrote:
> > I'm still using some old 32 bit physical servers with Fedora, and
> > they still work well!
> > So I would like to have a 32 bit kernel for some other releases,
> > maybe f28 if possible.  
> 
> Maybe you could keep the F26 kernel and try running it with F27 and
> F28.

Or, use a later kernel and compile and install the src.rpm locally.  

https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM

https://fedoraproject.org/wiki/Building_a_custom_kernel

This will probably require some custom configuration and dependency
tweaking, but should work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Starting an x86_32 SIG

[Jan Kratochvil]

On Wed, 12 Jul 2017 20:32:57 +0200, Stephen John Smoogen wrote:
> 2. A formal statement as requested by some users about the architecture
> 3. A survey of problems on the architecture.
> 4. A hardware selection the SIG are going to focus on.
> 5. What product the SIG is planning to deliver.

Just to consider for various "small virtual machines" an x32 arch may be
a better match than the i686 being deprecated:
https://en.wikipedia.org/wiki/X32_ABI


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Samuel Sieb]

On 07/12/2017 12:12 PM, Matthew Smith wrote:

On Wed, Jul 12, 2017 at 8:03 PM, Samuel Sieb  wrote:

I guess if this change goes through I
will be looking into how to run a 64-bit kernel and 32-bit userspace.  We
also still have a few laptops that are running 32-bit Fedora, but they don't
have to and they will all be retired within a year anyway.


Why do you want to keep the 32-bit userspace?


I could be wrong, but since they only have 2GB of RAM, I think that the 
32-bit userspace takes less runtime memory.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Samuel Sieb]

On 07/12/2017 05:44 AM, Bastien Nocera wrote:

"developers not having to learn GPG to sign their *Flatpak* releases"

I really don't understand how you misinterpreted that sentence so badly,
individual Fedora developers never had to GPG sign their Fedora packages...


That "*Flatpak*" was not in the original sentence and it really confused 
me too.  I was pretty sure individual maintainers didn't sign the RPMs, 
so I wondered why that was a benefit of flatpaks.  So now I understand 
that the point is that Fedora signs the flatpaks instead of the 
developers of the applications.

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

Re: Fedora 27 mass rebuild at risk

[Carlos O'Donell]

On 07/12/2017 03:34 AM, Dan Horák wrote:
>> * Fix Go 1.8.1 for s390x
> 
> this is https://bugzilla.redhat.com/show_bug.cgi?id=1460254 -
> buggy interaction between golang and new binutils

That's right, we knew what it was, but fixing it is not that
easy since it's generic binutils machinery that should be
working correctly.

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

Re: [SONAME change] MySQL, MariaDB

[Adam Williamson]

On Mon, 2017-07-03 at 15:12 +0200, Michal Schorm wrote:
> Hello everybody!
> 
> Since MariaDB 10.2 is finally stable and I resolved all issues that blocked
> it for Fedora, I'd like to propose an update for Rawhide.
> 
> Current version of MariaDB: 10.1.24
> Update planned to: 10.2.6 (or newer)
> 
> *This change introduces change of library name from "libmysqlclient.so" to
> "libmariadb.so".*
> *There are many dependant packages affected.*
> 
> The current (optimistic) plan is to deliver the update before Fedora 27 mass
> rebuild  at 12.7.2017.
> Either the rebuild of all depending packages is inevitable.
> 
> -
> 
> We actively track the issue here
> . There is also a list
> of affected packages.
> We have a work repository in COPR, where you can find builds of your
> packages here
> .
> 
> We go through all of the issues and we are trying to solve all of those,
> which are caused by the library change. More information will appear in
> bugzillas connected to the tracker.
> 
> Issues are also consulted with MariaDB upstream.
> I was told, that there should be strong API and ABI compatibility.
> 
> -
> 
> Notes:
>  - this means also drop of symlinks to "libmysqlclient.so.18.0.0" library.
>  - the version of the library in MariaDB 10.2.6 is "mariadb.so.3", however
> in mariadb-connector-c it is only "mariadb.so.2". That should sync in next
> big update in about a month, I believe.
> 
> -
> 
> Feel free to ask any questinos here or in tracker BZ, I'll try to search
> for all answers.

So this is now happening, but I'm a bit confused - specifically about
these two bits from the text:

"Either the rebuild of all depending packages is inevitable."
"this means also drop of symlinks to "libmysqlclient.so.18.0.0"
library"

However, the recent mariadb package builds by mschorm - mariadb-10.2.6-
1.fc27 and mariadb-10.2.6-2.fc27 - included symlinks from
'libmariadb.so' to 'libmysqlclient.so' and 'libmysqlclient.so.18'.
Which seems to imply that the library *should* still be ABI-compatible
with libmysqlclient.so.18 and that things built against that library
should *not* need rebuilding.

The libmysqlclient.so.18 symlink was initially put in the -devel
subpackage, which was clearly wrong, and after discussion with mschorm
I moved it to the -libs subpackage. But after reading some more on this
I'm really not at all clear on why this symlink exists, whether it was
intended to, whether it's *correct* that it exists, whether it's only a
temporary stopgap, etc. etc. So I thought I'd send out a mail about the
situation so we can discuss it on the public record.

There's still a problem with the -3 build I did, with the symlink
moved: the -libs package does not automatically get a Provides: for the
libmysqlclient.so.18 symlink, for some reason. I *could* do a rebuild
with the Provides: manually added, but now I'm unsure whether that's
the right thing to do.

This is a bit of a problem because it prevents various things from
building; the one that got me into this mess is initial-setup , which
needs rebuilding to fix a blocker bug, but the build failed because
somehow on s390 (only) initial-setup build requires net-snmp and net-
snmp requires libmysqlclient.so.18...

Can we sort this out, one way or another? Thanks!
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Eric Griffith]

My own two cents in this whole thing, after reading this entire thread... 
Matt's right.

This isn't a call to action because the release is a week away and there's 
critical 32-but bugs that need fixed. This isn't a call for support because 
there's specific bugs that need fixed. 

This is a call to arms for a handful of people--a team-- to own 32-bit kernels 
and their issues both now AND into the future. To deep dive EVERY issue that 
comes in and figure out the problem, and fix it. 

Hans, the reason you're not getting a list of specific bugs, is because thats 
kind of the point. "What can we do to help?" isn't really a helpful question. 
It implies specific issues, which misses the point. 

What you, or anyone else, can do to help is step up and say "I am willing to 
own i686 kernels from this moment and going into the future. I will triage 
bugzilla and prioritize things, I will ask for help on specific issues once I 
have identified them." And then go down that. 

Unless someone steps up, the reality is i686 kernels are gonna die. They may 
not OFFICIALLY die, but they'll die a slow death because no one cares, and no 
one is testing outside of OpenQA. Bugs will occur, breaks will happen, maybe 
they'll get reported or maybe they won't. 

Personally I couldn't care less about i686 kernels or whether or not they work. 
Every machine I own is 64bit capable and has 4Gb of RAM or more. 

If anyone out there DOES care about these kernels, AND has the time to donate 
AND has the skills necessary to support them, AND actually cares about this 
enough to actually put in the time.. then they need to speak up. 

Cheers!
Eric

> On Jul 12, 2017, at 15:17, Samuel Sieb  wrote:
> 
>> On 07/12/2017 12:12 PM, Matthew Smith wrote:
>>> On Wed, Jul 12, 2017 at 8:03 PM, Samuel Sieb  wrote:
>>> I guess if this change goes through I
>>> will be looking into how to run a 64-bit kernel and 32-bit userspace.  We
>>> also still have a few laptops that are running 32-bit Fedora, but they don't
>>> have to and they will all be retired within a year anyway.
>> Why do you want to keep the 32-bit userspace?
> 
> I could be wrong, but since they only have 2GB of RAM, I think that the 
> 32-bit userspace takes less runtime memory.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Matthew Miller]

On Wed, Jul 12, 2017 at 02:10:30PM +0200, Jakub Jelinek wrote:
> 2018-01-10 is way too early for a mass rebuild from GCC point of view,
> even if we perform the test mass rebuild over the Christmas break,
> there won't be enough time to analyze it and fix any GCC issues revealed
> during that time.  GCC bugfixing usually starts around November 15th and
> needs some time before it can be fixed enough to use widely.
> Moving the mass rebuild one week earlier than last time
> is maybe doable, but not one month.  And not rebuilding F27 with GCC 8
> is a bad idea for both the compiler and Fedora.

So, "one week earlier than last time" would be January 31st. (Or 30th?
Depends if we want that on a Tuesday like everything else or Wednesday
like this time around, if it matters.) Is that enough to help? Let me
rework it and let's see what that looks like...



-- 
Matthew Miller

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

Re: No i686 kernel: Can we require SSE2 for i686?

[Adam Williamson]

On Wed, 2017-07-12 at 13:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:
> > On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:
> > > > The fact that i686 kernels continue to work in general is basically 
> > > > luck.
> > > 
> > > You probably will deny this, but in practice it has been so for many
> > > years, because the i686 has dropped out of RHAT's business interest.
> > 
> > I don't think this is unreasonable. It is easy for us to support
> > architectures that a company is paying people to support. It is hard
> > for us to support architectures that are not getting that that kind of
> > support. As noted in this thread, this isn't just Red Hat -- it is true
> > of upstream i686 as well. No one is really interested in this. I
> > guarantee you that if some non-Red Hat person showed up and said "Hey,
> > I'm here to work on i686 N hours per week", we would say "awesome", not
> > "Red Hat doesn't care".
> 
> Would it be possible to make this a Prioritized Bug?
> It seems to be a classic case of "affects a lot of people, nobody seems
> to want to take interest".

It's not a question of a single specific bug, though. It's a question
of having someone or a group of someones interesting in the *ongoing
requirement* for making sure i686 still works.

To give an example outside of the kernel, the installer 'Reclaim Space'
function has been broken on i686 for about 10 months, and no-one seems
to be lining up to fix that one either:

https://bugzilla.redhat.com/show_bug.cgi?id=1375732
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Stephen John Smoogen]

On 12 July 2017 at 16:32, Adam Williamson  wrote:

> To give an example outside of the kernel, the installer 'Reclaim Space'
> function has been broken on i686 for about 10 months, and no-one seems
> to be lining up to fix that one either:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1375732

Thanks I have added it to https://fedoraproject.org/wiki/Architectures/x86


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

Re: No i686 kernel: Can we require SSE2 for i686?

[Adam Williamson]

On Wed, 2017-07-12 at 13:32 -0700, Adam Williamson wrote:
> On Wed, 2017-07-12 at 13:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:
> > > On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:
> > > > > The fact that i686 kernels continue to work in general is basically 
> > > > > luck.
> > > > 
> > > > You probably will deny this, but in practice it has been so for many
> > > > years, because the i686 has dropped out of RHAT's business interest.
> > > 
> > > I don't think this is unreasonable. It is easy for us to support
> > > architectures that a company is paying people to support. It is hard
> > > for us to support architectures that are not getting that that kind of
> > > support. As noted in this thread, this isn't just Red Hat -- it is true
> > > of upstream i686 as well. No one is really interested in this. I
> > > guarantee you that if some non-Red Hat person showed up and said "Hey,
> > > I'm here to work on i686 N hours per week", we would say "awesome", not
> > > "Red Hat doesn't care".
> > 
> > Would it be possible to make this a Prioritized Bug?
> > It seems to be a classic case of "affects a lot of people, nobody seems
> > to want to take interest".
> 
> It's not a question of a single specific bug, though. It's a question
> of having someone or a group of someones interesting in the *ongoing
> requirement* for making sure i686 still works.
> 
> To give an example outside of the kernel, the installer 'Reclaim Space'
> function has been broken on i686 for about 10 months, and no-one seems
> to be lining up to fix that one either:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1375732

To make an implicit point explicit: if this bug had affected, say, ARM,
or PPC, or s390, I would've known exactly who to CC and say 'hey look,
here's a bug specific to the arch you care about'. That's the value of
those arch SIGs/WGs (I forget what we call things). There is no i686
WG/SIG, no more informal but well-known 'group of people who care about
and help fix i686 bugs', so I can't do it for that bug.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: super-drafty F28 and F29 schedules

[Matthew Miller]

On Wed, Jul 12, 2017 at 04:30:12PM -0400, Matthew Miller wrote:
> So, "one week earlier than last time" would be January 31st. (Or 30th?
> Depends if we want that on a Tuesday like everything else or Wednesday
> like this time around, if it matters.) Is that enough to help? Let me
> rework it and let's see what that looks like...

So, what does updated
https://fedoraproject.org/wiki/Releases/28/Schedule#Key_Milestones look
like to you? That puts the mass rebuild on January 31st.

There's only 20 days until the branch, with that — maybe that's okay?
It's about what we had this cycle too. The (current!) F27 schedule,
which I based this off of, as a 34-day span there. We could push back
branching another week or even two — right up against the Bodhi
activation point. I don't think we can realistically move the
milestones _after_ that, though. It's basically one month for beta
stabilization and one month for final stabilization.

-- 
Matthew Miller

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

Re: super-drafty F28 and F29 schedules

[Jakub Jelinek]

On Wed, Jul 12, 2017 at 04:45:56PM -0400, Matthew Miller wrote:
> On Wed, Jul 12, 2017 at 04:30:12PM -0400, Matthew Miller wrote:
> > So, "one week earlier than last time" would be January 31st. (Or 30th?
> > Depends if we want that on a Tuesday like everything else or Wednesday
> > like this time around, if it matters.) Is that enough to help? Let me
> > rework it and let's see what that looks like...
> 
> So, what does updated
> https://fedoraproject.org/wiki/Releases/28/Schedule#Key_Milestones look
> like to you? That puts the mass rebuild on January 31st.

LGTM.

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

Re: cbang build error on epel

[Samuel Rakitničan]

> I guess it depends if (and how) inttypes.h header gets included, it's
> provided by glibc.
>
>
>   Dan

Find out some more information, do in both Fedora and EPEL __STDC_FORMAT_MACROS 
is not defined. The difference is in following patch:

https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/generic/inttypes.h;h=95d781815b6023f49305a1539d03672d13525542;hp=dc97519056b885a315e970be946177c5cee0d491;hb=1ef74943ce2f114c78b215af57c2ccc72ccdb0b7;hpb=ae9552cf7b7f43591a1dfd54baf48d31fbbe9fac
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org