Re: pure-ftpd 1.0.46 released!

[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

Re: super-drafty F28 and F29 schedules

[Alexander Bokovoy]

On ti, 11 heinä 2017, Michael Catanzaro wrote:
On Tue, Jul 11, 2017 at 6:56 PM, Kevin Kofler  
wrote:
IMHO, if you absolutely want to stick to May/October dates, it may 
make

sense to skip a release date as was done with F21 and go for a 9-month
cycle. The schedule as it stands now either WILL slip, or almost all 
the

planned features WILL have to be punted (and F27 will be essentially
identical to F26).


We need a GNOME 3.26 release. I know it's a very short cycle, and 
accordingly there are probably going to be fewer features than usual. 
Having such a short cycle is not ideal, but I think it's better than 
releasing too far after GNOME again. The problem here is not the F27 
schedule, it's that the F26 schedule was a month too far out, plus a 
month of delay on top of that.

One of goals for F27 is to complete OpenSSL migration for majority of a
base system. Unfortunately, with such an aggressive schedule it is
guaranteed to be a failure in OpenSSL migration.

--
/ Alexander Bokovoy
___
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

[mcatanzaro]

Hey Kevin,

Thanks for your detailed response. I usually try not to read or write 
long mails, but I made an exception this time. :)


On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler  
wrote:

Bastien Nocera wrote:

 Why do we care about FHS compliance inside a Flatpak?


Because the proprietary directory layout means the applications (and 
the

libraries!) have to be specially built for it, and in the worst case,
require code and/or build system changes to deal with it.


Yes, this is true. Sometimes minor changes to applications are required 
to adjust paths. And sometimes it can be rather frustrating to debug 
such issues when trying to package an app as a Flatpak. (Debugging 
Flatpak apps is not easy.) So although we can automate most of the work 
of creating the Flatpaks, only a human can make sure they're working 
properly and fix problems when they're not.



 And why would it be slower to release security fixes?


With system libraries, if there is a security issue in a library, the
library is updated by upstream, packaged, and delivered directly to 
the

user.

With bundled libraries, if there is a security issue in a library, the
library is also updated by the library's upstream, but then the 
bundle needs
to be rebuilt with the new library and the whole bundle has to be 
delivered

to the user. The extra step of rebuilding the bundle (which typically
involves an additional maintainer) is what takes extra time.


Yes.


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.


In scenarios where Flatpaks are shipped by upstream, they will also 
have to
rebuild the library in some way, or wait for their distribution to 
update

the package. But in addition, most upstreams will probably just do
cumulative updates of the libraries when they do a new release of 
their own

code (if at all!) and not do timely security updates at all.

There is also the efficiency issue of having to update the whole 
bundle,

which will encourage cumulative updates and discourage quick security
updates. If the bundle is updated for every library security update, 
there
will be a lot to download. People are already complaining about the 
size of
Fedora updates as it stands, without having to update dozens of huge 
bundles

whenever a commonly used library is updated.

And it is also not possible to just stuff all libraries into the 
runtime to
avoid this issue, because then the runtime becomes a huge pile of 
libraries
that the user may or may not actually use, and updating the runtime 
(which
would have to be done the more frequently the more libraries it 
contains)

becomes very inefficient due to its size.


Yes, these are all real disadvantages. And of course there is an 
inherent trade-off in the decision to include more libraries in the 
runtime. I think we'll probably want a fairly large runtime for Fedora, 
though, to reduce the amount of stuff that has to be bundled in 
Flatpaks. (I believe all updates are delta updates, so if only one part 
of the runtime changes, the update shouldn't be too large.)



 You forgot the positive changes such as:
 - sandboxing
 - dogfooding and testing for the sandboxing technologies


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. The other main benefit of 
Flatpaks is that independent application distribution becomes much 
easier, which is very important for Fedora, but not at all a reason to 
replace Fedora packages with Flatpaks. But sandboxing desktop 
applications is a good reason to do so. We have the opportunity to 
hugely improve the security of our operating system, and we should take 
it. The benefits of this sandboxing outweigh the security costs of 
increased library bundling. We will certainly have to be vigilant to 
ensure Flatpaks are routinely updated when there is a security problem 
in a bundled library, but if we are a little too slow, the sandbox will 
often mitigate the problem. In effect, most successful explo

Schedule for Wednesday's FPC Meeting (2017-07-12 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Wednesday at 2017-07-12 17:00 UTC in #fedora-meeting-3 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Wednesday =
2017-07-12 10:00 PDT  US/Pacific
2017-07-12 13:00 EDT  --> US/Eastern <--
2017-07-12 17:00 UTC  UTC   
2017-07-12 18:00 BST  Europe/London 
2017-07-12 19:00 CEST Europe/Berlin 
2017-07-12 19:00 CEST Europe/Paris  
2017-07-12 22:30 IST  Asia/Calcutta 
--- New Day: Thursday 
2017-07-13 01:00 HKT  Asia/Hong_Kong
2017-07-13 01:00 +08  Asia/Singapore
2017-07-13 02:00 JST  Asia/Tokyo
2017-07-13 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followups =

#topic #691 noarch *sub*packages with arch-specific dependencies   
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #696 Many packages are not following the Guidelines for bundled 
libraries 
.fpc 696
https://pagure.io/packaging-committee/issue/696

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

___
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

[Michael Catanzaro]

On Tue, Jul 11, 2017 at 6:56 PM, Kevin Kofler  
wrote:
IMHO, if you absolutely want to stick to May/October dates, it may 
make

sense to skip a release date as was done with F21 and go for a 9-month
cycle. The schedule as it stands now either WILL slip, or almost all 
the

planned features WILL have to be punted (and F27 will be essentially
identical to F26).


We need a GNOME 3.26 release. I know it's a very short cycle, and 
accordingly there are probably going to be fewer features than usual. 
Having such a short cycle is not ideal, but I think it's better than 
releasing too far after GNOME again. The problem here is not the F27 
schedule, it's that the F26 schedule was a month too far out, plus a 
month of delay on top of that.


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

[Michael Catanzaro]

On Tue, Jul 11, 2017 at 8:36 PM, Carlos O'Donell  
wrote:

I encourage Jeff Law and Jakub Jelinek to review these schedules
for compiler related issues.


I don't think we should adjust the schedule much (or even at all) for 
the compiler. We scheduled F26 a month later than usual to accommodate 
GCC, and combined with an extra month of delay on top of that, the 
result is that Ubuntu beat us to a GNOME 3.24 release by three months. 
We have to be more timely in order to remain the premiere distro for 
GNOME users, *especially* considering we're going to be following a 
month behind Ubuntu 18.04 shipping GNOME by default next spring. We 
need to follow up quickly with a rock solid release.


It's very nice to ship with the latest version of GCC, but it's not 
worth delaying our releases very long for. Early May and late October 
are the best possible release times for Workstation and I hope we stick 
to those in the future. So I very much support Matthew's proposal. If 
there are problems with GCC, we have options: we could ship with 
prerelease GCC, or defer the GCC update to the fall release, or ask the 
GCC devs to move their schedule forward a couple of weeks. I'm sure 
we'll settle on something everyone can live with. I just hope we can 
release F28 next spring much earlier than we released F26. We had been 
doing well for several releases, but F26 was too greatly delayed.


Michael
___
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/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

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

-- 
Cheers,
Carlos.
___
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 Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
> This is just a perfunctory review from the glibc perspective with
> regard to base ABI and API issues in this core runtime.
[...]
> Otherwise the schedules look sensible from a glibc perspective.
> We can drive new security, performance, and usability into the
> distribution on these 6 month cycles.

Awesome. Thank you very much, Carlos!

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

[Carlos O'Donell]

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.

> https://fedoraproject.org/wiki/Releases/29/Schedule

2018-07-11 MASS REBUILD
- This date is ahead of the glibc release on 2018-08-01
  but after the 2018-07-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-08-01 if something has to be reverted.

Otherwise the schedules look sensible from a glibc perspective.
We can drive new security, performance, and usability into the
distribution on these 6 month cycles.

-- 
Cheers,
Carlos.
___
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]

Bastien Nocera wrote:
> Why do we care about FHS compliance inside a Flatpak?

Because the proprietary directory layout means the applications (and the 
libraries!) have to be specially built for it, and in the worst case, 
require code and/or build system changes to deal with it.

> And why would it be slower to release security fixes? 

With system libraries, if there is a security issue in a library, the 
library is updated by upstream, packaged, and delivered directly to the 
user.

With bundled libraries, if there is a security issue in a library, the 
library is also updated by the library's upstream, but then the bundle needs 
to be rebuilt with the new library and the whole bundle has to be delivered 
to the user. The extra step of rebuilding the bundle (which typically 
involves an additional maintainer) is what takes extra time.

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.

In scenarios where Flatpaks are shipped by upstream, they will also have to 
rebuild the library in some way, or wait for their distribution to update 
the package. But in addition, most upstreams will probably just do 
cumulative updates of the libraries when they do a new release of their own 
code (if at all!) and not do timely security updates at all.

There is also the efficiency issue of having to update the whole bundle, 
which will encourage cumulative updates and discourage quick security 
updates. If the bundle is updated for every library security update, there 
will be a lot to download. People are already complaining about the size of 
Fedora updates as it stands, without having to update dozens of huge bundles 
whenever a commonly used library is updated.

And it is also not possible to just stuff all libraries into the runtime to 
avoid this issue, because then the runtime becomes a huge pile of libraries 
that the user may or may not actually use, and updating the runtime (which 
would have to be done the more frequently the more libraries it contains) 
becomes very inefficient due to its size.

> You forgot the positive changes such as:
> - sandboxing
> - dogfooding and testing for the sandboxing technologies

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.

We really need sandboxing technologies that work with shared system 
libraries (also allowing the code segments to be shared in RAM). And in 
fact, we already have those technologies:
* Fedora ships and heavily promotes SELinux, which in fact, as far as I
  know, is also part of the sandboxing technologies Flatpak uses.
* seccomp also looks very promising. Chromium (and QtWebEngine) is already
  using it effectively.

Bundling libraries has many drawbacks, including security-related ones (as I 
explained above). (It also wastes download bandwidth, disk space, and RAM.) 
To really improve security, we must provide the benefits of sandboxing 
without bundling libraries.

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

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

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

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

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

Re: Using ndb in RPM

[Florian Weimer]

* Stephen John Smoogen:

> On 11 July 2017 at 16:48, Florian Weimer  wrote:
>> * Stephen John Smoogen:
>>
>>> On 11 July 2017 at 07:52, Michael Schroeder  wrote:
 On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote:
> And we do use SQLite today in DNF with the yumdb, as well as the new
> SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
> in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.

 AFAIR it was removed because it was unbearable slow, nobody used it,
 and nobody wanted to maintain it.

>>>
>>> 1. It was very slow.. and developers complained a lot about how long
>>> it took to get various things done.
>>
>> It looks like the backend was ported from SQLite 2 code initially.
>> The result set processing code indeed loks quite inefficient (result
>> set cells are are allocated individually, memcpy is used to copy an
>> int, and so on).  But I'm still surprised this was observable to
>> users.
>
> Never doubt the amount a developer will complain when either an
> install or build takes longer than it did before. Especially when they
> have to do dozens or hundreds of builds.

In mock?  Yes, that (and installation in general) look rather slow
because *every key lookup* appears to be wrapped in a
getcwd/chroot/chdir/chroot sequence.  It looks like this was
implemented to fix this bug:

  

Unfortunately, the bug doesn't say why the fix took this particular
form (and why the database wasn't always opened outside of the chroot
instead).
___
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 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.


signature.asc
Description: PGP 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?

[Kevin Kofler]

Florian Weimer wrote:
> I ran into this unannounced change:
> 
>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

Since this effectively amounts to desupporting Fedora on i686 hardware, this 
is very much a system-wide change.

Kevin Kofler
___
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?

[Kevin Kofler]

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.

Kevin Kofler
___
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

[Kevin Kofler]

Matthew Miller wrote:
> I took a look at the planned F27 schedule
> https://fedoraproject.org/wiki/Releases/27/Schedule and sketched out
> what the same time periods would look like with a May target for F28,
> and then repeated again for F29, making very drafty preliminary
> schedules:
> 
> https://fedoraproject.org/wiki/Releases/28/Schedule
> https://fedoraproject.org/wiki/Releases/29/Schedule

So you are already planning F28 and F29 schedules when we do not even know 
whether the F27 schedule can be kept even remotely. To me, the F27 schedule 
looks completely unrealistic, with less than 3 months (!) between the F26 
release and the F27 Final Freeze! That's pretty much a halved cycle.

IMHO, if you absolutely want to stick to May/October dates, it may make 
sense to skip a release date as was done with F21 and go for a 9-month 
cycle. The schedule as it stands now either WILL slip, or almost all the 
planned features WILL have to be punted (and F27 will be essentially 
identical to F26).

Kevin Kofler
___
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 Tue, Jul 11, 2017 at 4:00 PM, Zdenek Kabelac  wrote:
> Dne 11.7.2017 v 23:17 Solomon Peachy napsal(a):
>>
>> 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!)
>>
>>
>
>
> The question is - why - certainly not  because CPU got less powerfull that
> 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

A consequence of Moore's law, and deflationary pressure on computer
technology. As that's changing, there's increasing pressure on code
optimization to get performance advances.

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

[Zdenek Kabelac]

Dne 11.7.2017 v 23:17 Solomon Peachy napsal(a):

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





The question is - why - certainly not  because CPU got less powerfull that 
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



Zdenek
___
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 17:03, Justin Forbes  wrote:
> On Tue, Jul 11, 2017 at 3: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 -- 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.
>>
>
> The kernel team quit "supporting" i686 several releases ago, it is
> down to community support, which is pretty much nonexistent.  Sure,
> people file bugs, but rarely do people point to or supply patches for
> those bugs.   The biggest issue is how much it is ignored by upstream
> as well. We have issues where things were never tested on i686, and
> then have to be fixed before we can release necessary and relevant
> updates which impact everyone else.   And discontinuing the i686 build
> for F27 would still mean over a year left of supported Fedora on i686
> hardware.
> When looking at those check ins, it would also be interesting to note
> which of those are running on virt or containers. Containers would
> still be possible, and 32bit userspace in virt guests with a 64bit
> kernel would still be possible. The kernel header package would still
> be built, so all other 32bit i686 packages would continue to build and
> work just fine.
>

Just to head this off. There is no way currently available to
determine if a yum/dnf update was done in a
virt/container/Workstation/Cloud/Server etc. Attempts to get that data
reportable has been stalled for N years.

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



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

[Solomon Peachy]

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.

 - 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: Using ndb in RPM

[Stephen John Smoogen]

On 11 July 2017 at 16:48, Florian Weimer  wrote:
> * Stephen John Smoogen:
>
>> On 11 July 2017 at 07:52, Michael Schroeder  wrote:
>>> On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote:
 And we do use SQLite today in DNF with the yumdb, as well as the new
 SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
 in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.
>>>
>>> AFAIR it was removed because it was unbearable slow, nobody used it,
>>> and nobody wanted to maintain it.
>>>
>>
>> 1. It was very slow.. and developers complained a lot about how long
>> it took to get various things done.
>
> It looks like the backend was ported from SQLite 2 code initially.
> The result set processing code indeed loks quite inefficient (result
> set cells are are allocated individually, memcpy is used to copy an
> int, and so on).  But I'm still surprised this was observable to
> users.

Never doubt the amount a developer will complain when either an
install or build takes longer than it did before. Especially when they
have to do dozens or hundreds of builds. And also never doubt how much
complaining if they find that rpm/yum is now using up more memory.
[There were memory issues in yum which I think went back to this.] Or
if someone uses that speed and memory usage to explain why apt/.deb is
superior to yum/.rpm. Those kinds of complaints end up getting
features yanked.

I do believe the extra memory did cause OOM on certain scenarios which
was another reason for it to be removed.

However it has been a while so I could be remembering 10 other bugs.



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

[Solomon Peachy]

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

 - 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: No i686 kernel: Can we require SSE2 for i686?

[Josh Boyer]

On Tue, Jul 11, 2017 at 4:54 PM, Neal Gompa  wrote:
> On Tue, Jul 11, 2017 at 4: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 -- 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'm actually somewhat against this change at well, as it's quite handy
> to have x86_32 images for constrained VMs/cloudy environments. I use
> it in this manner sometimes, and I know of a few people that do this
> *a lot*, too.

That's a common, and valid, usecase for a 32-bit *userspace* image.
You can run such workloads with an x86_64 kernel though.

The Change is not advocating for droping 32-bit userspace.  Only the kernel.

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?

[Josh Boyer]

On Tue, Jul 11, 2017 at 4:55 PM, Michal Schorm  wrote:
> Idk, but you know - example - somebody starts with Linux.
>
> 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.
>
> I think, a lot of people who are potential new users or IT guys, has only
> access to old HW, nobody else wants.
> Wasn't that a start for all of us? Or you - as a basic windows user - got
> brand new high-end laptop for christmas and guess what - installed that
> weird thing called Linux you never saw before?
>
> I'd like to see it supported.

Enough to volunteer your time to actually do that support?

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?

[Adam Williamson]

On Tue, 2017-07-11 at 22:55 +0200, Michal Schorm wrote:
> Idk, but you know - example - somebody starts with Linux.
> 
> 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.
> 
> I think, a lot of people who are potential new users or IT guys, has only
> access to old HW, nobody else wants.
> Wasn't that a start for all of us? Or you - as a basic windows user - got
> brand new high-end laptop for christmas and guess what - installed that
> weird thing called Linux you never saw before?
> 
> I'd like to see it supported.

Talking about 'brand new high-end' is pushing things a bit. The last
significant generation of non-x64 CPUs was the Intel Core series in
2006; since the Core 2 series came out in 2007 Intel's barely made a
non-x64 CPU any more (they continued production of some existing models
till 2008, but there was a definite handover). That's *ten years ago*.
AMD hasn't made one since 2003 or so, apart from the very niche Geode
series. We don't support i586 any more, no matter whether you can find
one in some dusty basement somewhere. We're gonna have to cut off i686
at *some* point.
-- 
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 11 July 2017 at 16: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.
> That approach was done quite a while ago, and explicitly communicated.
>
> The fact that i686 kernels continue to work in general is basically luck.

Or that they have been broken at various times and no one noticed.



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

[Justin Forbes]

On Tue, Jul 11, 2017 at 3: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 -- 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.
>

The kernel team quit "supporting" i686 several releases ago, it is
down to community support, which is pretty much nonexistent.  Sure,
people file bugs, but rarely do people point to or supply patches for
those bugs.   The biggest issue is how much it is ignored by upstream
as well. We have issues where things were never tested on i686, and
then have to be fixed before we can release necessary and relevant
updates which impact everyone else.   And discontinuing the i686 build
for F27 would still mean over a year left of supported Fedora on i686
hardware.
When looking at those check ins, it would also be interesting to note
which of those are running on virt or containers. Containers would
still be possible, and 32bit userspace in virt guests with a 64bit
kernel would still be possible. The kernel header package would still
be built, so all other 32bit i686 packages would continue to build and
work just fine.

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

Re: F27 System Wide Change: 32 bit UEFI Support

[Chris Murphy]

Does edk2-ovmf provide qemu-kvm with switchable 32-bit and 64-bit
support so this can be more widely tested by QA folks without
hardware?


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 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.
That approach was done quite a while ago, and explicitly communicated.

The fact that i686 kernels continue to work in general is basically luck.

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?

[Florian Weimer]

On 07/11/2017 10:33 PM, Chris Adams wrote:
> Once upon a time, Florian Weimer  said:
>> I ran into this unannounced change:
>>
>>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
> 
> I'm assuming it's a work-in-progress proposal?  For one thing, it says
> it is not a system wide change, but (if I'm understanding it correctly)
> this would be a significant change, as it would remove a supported
> architecture completely.

Well, yes.  But it's tagged as ChangeReadyForWrangler, so I assume it's
close to its final form.

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?

[Michal Schorm]

Idk, but you know - example - somebody starts with Linux.

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.

I think, a lot of people who are potential new users or IT guys, has only
access to old HW, nobody else wants.
Wasn't that a start for all of us? Or you - as a basic windows user - got
brand new high-end laptop for christmas and guess what - installed that
weird thing called Linux you never saw before?

I'd like to see it supported.




--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Tue, Jul 11, 2017 at 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 -- 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.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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?

[Neal Gompa]

On Tue, Jul 11, 2017 at 4: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 -- 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'm actually somewhat against this change at well, as it's quite handy
to have x86_32 images for constrained VMs/cloudy environments. I use
it in this manner sometimes, and I know of a few people that do this
*a lot*, too.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM

[Florian Weimer]

* Stephen John Smoogen:

> On 11 July 2017 at 07:52, Michael Schroeder  wrote:
>> On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote:
>>> And we do use SQLite today in DNF with the yumdb, as well as the new
>>> SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
>>> in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.
>>
>> AFAIR it was removed because it was unbearable slow, nobody used it,
>> and nobody wanted to maintain it.
>>
>
> 1. It was very slow.. and developers complained a lot about how long
> it took to get various things done.

It looks like the backend was ported from SQLite 2 code initially.
The result set processing code indeed loks quite inefficient (result
set cells are are allocated individually, memcpy is used to copy an
int, and so on).  But I'm still surprised this was observable to
users.
___
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 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.

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

[Dominik 'Rathann' Mierzejewski]

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.

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

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.

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?

[Chris Adams]

Once upon a time, Florian Weimer  said:
> I ran into this unannounced change:
> 
>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

I'm assuming it's a work-in-progress proposal?  For one thing, it says
it is not a system wide change, but (if I'm understanding it correctly)
this would be a significant change, as it would remove a supported
architecture completely.

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

No i686 kernel: Can we require SSE2 for i686?

[Florian Weimer]

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.

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

[Colin Walters]

On Tue, Jul 11, 2017, at 03:49 PM, Jean-Baptiste Holcroft wrote:
> Le 11/07/2017 à 19:30, Colin Walters a écrit :
> > specific ones. And we get into a lot of interesting questions around 
> > the intersection
> > of the languages and Workstation, depending on what gets installed by 
> > default.
> 
> can you please elaborate what you mean by languages in this particular 
> context? Is it again the langpack/translation content or is it something 
> else?

Programming languages, and here I mean mostly the dynamic/interpreted ones, 
since
they get installed and hence need to be updated with the host/container.   For 
example,
Vagrant (which I currently have layered on my host).  Another example here is 
e.g.
Python software that acts as part of the host like firewalld. Though
this also applies to some degree if we started to use dynamic linking for e.g. 
golang
or Rust.


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

Re: F27 System Wide Change: 32 bit UEFI Support

[Adam Williamson]

On Thu, 2017-07-06 at 15:42 +0200, Jaroslav Reznik wrote:
> = System Wide Change: 32 bit UEFI Support =
> https://fedoraproject.org/wiki/Changes/32BitUefiSupport
> 
> Change owner(s):
> Peter Jones 
> 
> Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It
> is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel
> and distribution on these systems. So far this setup has not been
> supported in Fedora. This feature is about adding support for
> installing and booting Fedora on this hardware.
> 
> == Detailed Description ==
> To add support for booting Fedora x86_64 on x86 systems with 32 bit
> UEFI firmware a number of (small) changes to grub, various EFI related
> userspace tools and anaconda are necessary. See Scope for more
> details.
> 
> == Scope ==
> * Proposal owners:
> ** The x86_64 grub2 packages will need to include an extra grub build,
> next to the current classic BIOS and 64 bit UEFI build a new 32 bit
> UEFI build will be added to the x86_64 packages.
> ** This new grub will need to be added to the various x86_64 boot media
> ** A few EFI userspace utilities need to be updated to work with 32 bit x86 
> UEFI
> ** The installer (anaconda) needs some changes to the bootloader
> installation code to install the 32 bit UEFI grub binary
> 
> * Other developers:
> 
> No changes are necessary outside of the affected packages
> 
> * Release engineering: [1]
> ** List of deliverables:
> This feature should be enabled on all non cloud/container x86_64 images
> 
> * Policies and guidelines: N/A (not needed for this Change)
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> [1] https://pagure.io/releng/issue/6879

D'oh - why'd this have to get announced *right* after I gave away my
Baytrail tablet? :)
-- 
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

[Jean-Baptiste Holcroft]

Le 11/07/2017 à 19:30, Colin Walters a écrit :
specific ones. And we get into a lot of interesting questions around 
the intersection

of the languages and Workstation, depending on what gets installed by default.


can you please elaborate what you mean by languages in this particular 
context? Is it again the langpack/translation content or is it something 
else?


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

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Pierre-Yves Chibon]

On Tue, Jul 11, 2017 at 08:39:51PM +0200, Andreas Tunek wrote:
> 2017-07-11 20:33 GMT+02:00 Matthew Miller :
> > On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
> >> > I think that's fine. The GUI doesn't need to cover every possible use
> >> > case, and this particular use case does not seem to be in high-priority
> >> > scope for the Workstation target.
> >> Since I like that use case I would really want it to be in the scope
> >> of the Workstation. But I also know that those who do the work gets to
> >> decide.
> >
> > I mean, it's a fine thing to do, but I would expect that in this
> > situation you'd really be managing the system with Ansible or some
> > other config management, or else have some sort of directory service
> > providing identity, authentication, and authorization.
> >
> >
> 
> My setup is the default setup for Fedora since FC1! You have always
> have had to click a check box to make the first user a  user with sudo
> privileges. I always went with the default and I like that setup.

The support of admins users in Fedora is actually fairly recent, before that the
user created wasn't in the wheel group and had to be added there manually. Most
documentation for Fedora that pre-dates this change was referring people to
`su -` or `su -c "command"` as the way to get admin privileges.


Pierre
___
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]

Dominik, are you try communicate with it's maintainers?

вт, 11 июл. 2017 г., 16:09 Dominik Kucher :

> Hi!
>
> No longer maintains pure-ftpd? 1.0.46 is released on Apr. 24 2017
>
> --
> Dominik Kucher
> A-2130 Mistelbach, Ebendorferstraße 7/2/3
> p: +43 (0) 720 511 941
> f: +43 (0) 1 34242 289967
> m: +43 (0) 676 57 68 677
>
>
> ___
> 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: Self Introduction

[Zbigniew Jędrzejewski-Szmek]

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.

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.

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

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 20:33 GMT+02:00 Matthew Miller :
> On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
>> > I think that's fine. The GUI doesn't need to cover every possible use
>> > case, and this particular use case does not seem to be in high-priority
>> > scope for the Workstation target.
>> Since I like that use case I would really want it to be in the scope
>> of the Workstation. But I also know that those who do the work gets to
>> decide.
>
> I mean, it's a fine thing to do, but I would expect that in this
> situation you'd really be managing the system with Ansible or some
> other config management, or else have some sort of directory service
> providing identity, authentication, and authorization.
>
>

My setup is the default setup for Fedora since FC1! You have always
have had to click a check box to make the first user a  user with sudo
privileges. I always went with the default and I like that setup.

/Andreas

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: F27 System Wide Change: Reduce Initial Setup Redundancy

[Matthew Miller]

On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
> > I think that's fine. The GUI doesn't need to cover every possible use
> > case, and this particular use case does not seem to be in high-priority
> > scope for the Workstation target.
> Since I like that use case I would really want it to be in the scope
> of the Workstation. But I also know that those who do the work gets to
> decide.

I mean, it's a fine thing to do, but I would expect that in this
situation you'd really be managing the system with Ansible or some
other config management, or else have some sort of directory service
providing identity, authentication, and authorization.


-- 
Matthew Miller

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

Re: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Adam Williamson]

On Tue, 2017-07-11 at 11:12 -0700, Adam Williamson wrote:
> 
> The best resolution to a situation like this is simply to fix the
> problem that's causing images to fail to build in the first place.

I should note for the record that both the images missing from RC-1.4
were present in RC-1.5, which is what we actually released.
-- 
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: [Fedora-packaging] Bundled Provides Libraries and Versioning

[Dominik 'Rathann' Mierzejewski]

On Monday, 10 July 2017 at 13:56, Bastien Nocera wrote:
> - Original Message -
[...]
> > There can be many reasons: copylibs, no upstream support for building as
> > shared library, no stable API/ABI, etc. Many of them are listed on the
> > wiki page: https://fedoraproject.org/wiki/Bundled_Libraries_Virtual_Provides
> 
> There's no mention of zlib or LZMA SDK libs in there. Should those be added?

Yes, please do.

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: NoDefaultSyslog Breaks Logwatch on Clean Install

[Gerald B. Cox]

Thanks Matt... I did review this earlier and updated before I posted here:
https://bugzilla.redhat.com/show_bug.cgi?id=1462615

By clean install, what I meant was that I had to do a complete reinstall of
my
F25 installation (reformat of partition) because I couldn't get the
recovery tools
on the LiveDVD to function properly.  It got to the point where it was just
faster to
do the re-install than to keep hacking away at the LiveDVD tools.

After I re-installed I applied all the current updates.

I would expect that it "should" work out of the box.  If
changes/pre-requisites are
required due to the syslog change that should have been incorporated into
the
logwatch rpm.

People shouldn't have to do endless Google searches and hack away to get
things to
work.

If we don't want to adequately support logwatch then we should remove it
from the repository and
recommend people use something else or whatever.

Do we have a process for initiating removal due to inadequate support?



On Tue, Jul 11, 2017 at 10:49 AM, Matthew Miller 
wrote:

> On Tue, Jul 11, 2017 at 10:06:45AM -0700, Gerald B. Cox wrote:
> > I found this:
> > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
> > I had to do a clean install of F25 because of problems with the system
> > rescue tools, now I find that Logwatch on a clean install is broken...
> and
> > it appears to be because of the removal of syslog.
>
> Logwatch was updated to address this. See
> . By "clean
> install" do you mean "install and add logwatch from the release tree
> rather than updates"? If it's broken including the update, please
> reopen or file a new bug.
>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Adam Williamson]

On Tue, 2017-07-11 at 11:24 -0400, Matthew Miller wrote:
> On Tue, Jul 11, 2017 at 01:10:52PM +0200, Kevin Kofler wrote:
> > > But we can't "just ignore the compose tools", because we want the
> > > metadata to actually be correct and consistent. If we dump an ISO into
> > > a compose link this, it won't be.
> > 
> > Real users don't care about metadata that you upload to some obscure server 
> > like pdc.fp.o that most users don't even know exists (this thread was the 
> > first time that *I* heard of it, and I am in no way a new user ;-) ). Real 
> > users care about what ends up on the mirrors. Dropping in the ISO into the 
> > mirrored directory perfectly addresses the expectations of actual users.
> 
> I get that having correct metadata is useful for a lot of programmatic
> things (like maybe finally making https://pagure.io/releng/issue/5805 a
> reality), but I agree about the results. Also, we shouldn't have this
> dictated to us by the design of the compose tools. We should look at
> what we want the user-facing results to be and work back from that.

We do: we want the user-facing results to be a consistent set of
deliverables, reliably built using the same process and thus to the
same specifications every time. Throwing together images by hand and
stuffing them into a directory together does not reliably achieve that,
which is why we made things like Pungi.

The best resolution to a situation like this is simply to fix the
problem that's causing images to fail to build in the first place.
-- 
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: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 19:50 GMT+02:00 Matthew Miller :
> On Tue, Jul 11, 2017 at 07:18:39PM +0200, Andreas Tunek wrote:
>> What I wanted to do in the GUI is to revert to the Fedora setup with
>> one root and several "regular" users. That does not seem to be
>> possible with the current GUI tools. This setup would not be possible
>> to create (using the GUI tools) with your suggested design.
>
> I think that's fine. The GUI doesn't need to cover every possible use
> case, and this particular use case does not seem to be in high-priority
> scope for the Workstation target.
>

Since I like that use case I would really want it to be in the scope
of the Workstation. But I also know that those who do the work gets to
decide.

/Andreas

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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

Fedora Rawhide-20170711.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 11/137 (x86_64), 1/18 (i386), 1/2 (arm)

ID: 119611  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/119611
ID: 119635  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/119635
ID: 119636  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/119636
ID: 119643  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/119643
ID: 119649  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/119649
ID: 119653  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/119653
ID: 119654  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/119654
ID: 119722  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/119722
ID: 119724  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/119724
ID: 119727  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/119727
ID: 119729  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/119729
ID: 119730  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/119730
ID: 119754  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/119754

Soft failed openQA tests: 64/137 (x86_64), 14/18 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 119599  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/119599
ID: 119600  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119600
ID: 119601  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/119601
ID: 119602  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119602
ID: 119609  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/119609
ID: 119610  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/119610
ID: 119619  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/119619
ID: 119621  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/119621
ID: 119622  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/119622
ID: 119623  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119623
ID: 119642  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119642
ID: 119656  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/119656
ID: 119657  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119657
ID: 119668  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/119668
ID: 119669  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/119669
ID: 119670  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/119670
ID: 119671  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/119671
ID: 119672  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/119672
ID: 119674  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/119674
ID: 119675  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/119675
ID: 119676  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/119676
ID: 119677  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/119677
ID: 119678  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/119678
ID: 119679  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/119679
ID: 119680  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/119680
ID: 119681  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/119681
ID: 119682  Test: x86_64 universal install_scsi_updates_img
UR

Re: super-drafty F28 and F29 schedules

[Matthew Miller]

On Tue, Jul 11, 2017 at 01:30:32PM -0400, Colin Walters wrote:
> > Hopefully, by the time we are at F28, Modularity will provide a way for
> > us to offer faster streams for people who want them -- but let's also
> > focus on stable releases. 
> 
> But with Modularity, how much does it even make sense to talk about
> "Fedora" releases in a generic fashion with a 6mo cadence? Aren't we
> likely for many modules to only have a single stream (or multiple)
> that may not match that cadence?

I think we're still going to have a large number of packages that
aren't on that model in a year. And, I expect we will still have a base
runtime (or something) that comes out on a six-month cycle -- and
we'll probably want to have some release artifacts (like Workstation)
which also follow that cycle.



> It seems to me offhand that some things like the Change process will be around
> modules, and then changes in those modules get reflected into any editions 
> they
> affect?   A lot of the Changes listed here:
> https://fedoraproject.org/wiki/Releases/26/ChangeSet
> would seem to be for the base module, but there are several 
> desktop/Workstation
> specific ones.  And we get into a lot of interesting questions around the 
> intersection
> of the languages and Workstation, depending on what gets installed by default.
> (My take would be to reduce the amount of things installed by default, and 
> really
>  encourage doing most development in containers, decoupled from the base host
>  lifecycle, like Atomic Host)

Sounds good to me!


-- 
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: Reduce Initial Setup Redundancy

[Matthew Miller]

On Tue, Jul 11, 2017 at 07:18:39PM +0200, Andreas Tunek wrote:
> What I wanted to do in the GUI is to revert to the Fedora setup with
> one root and several "regular" users. That does not seem to be
> possible with the current GUI tools. This setup would not be possible
> to create (using the GUI tools) with your suggested design.

I think that's fine. The GUI doesn't need to cover every possible use
case, and this particular use case does not seem to be in high-priority
scope for the Workstation target.

-- 
Matthew Miller

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

Re: NoDefaultSyslog Breaks Logwatch on Clean Install

[Matthew Miller]

On Tue, Jul 11, 2017 at 10:06:45AM -0700, Gerald B. Cox wrote:
> I found this:
> https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
> I had to do a clean install of F25 because of problems with the system
> rescue tools, now I find that Logwatch on a clean install is broken... and
> it appears to be because of the removal of syslog.

Logwatch was updated to address this. See
. By "clean
install" do you mean "install and add logwatch from the release tree
rather than updates"? If it's broken including the update, please
reopen or file a new bug.



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

[Colin Walters]

On Thu, Jul 6, 2017, at 09:15 PM, Matthew Miller wrote:

> Hopefully, by the time we are at F28, Modularity will provide a way for
> us to offer faster streams for people who want them -- but let's also
> focus on stable releases. 

But with Modularity, how much does it even make sense to talk about "Fedora"
releases in a generic fashion with a 6mo cadence?  Aren't we likely for many
modules to only have a single stream (or multiple) that may not match that 
cadence?

It seems to me offhand that some things like the Change process will be around
modules, and then changes in those modules get reflected into any editions they
affect?   A lot of the Changes listed here:
https://fedoraproject.org/wiki/Releases/26/ChangeSet
would seem to be for the base module, but there are several desktop/Workstation
specific ones.  And we get into a lot of interesting questions around the 
intersection
of the languages and Workstation, depending on what gets installed by default.
(My take would be to reduce the amount of things installed by default, and 
really
 encourage doing most development in containers, decoupled from the base host
 lifecycle, like Atomic Host)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 16:25 GMT+02:00 Michael Catanzaro :
> On Tue, Jul 11, 2017 at 6:40 AM, Andreas Tunek 
> wrote:
>>
>> So you mean that bug 1270953
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
>> fixed/implemented?
>
>
> I'm not sure it was ever broken. Did you make sure there was an another
> administrator first before trying to remove the last one? :)
>
> I just tested it and it is *not* necessary to switch user accounts at all,
> thankfully. You can set or remove the administrator status of any user from
> control-center as long as another administrator exists.
>
> Michael
>

What I wanted to do in the GUI is to revert to the Fedora setup with
one root and several "regular" users. That does not seem to be
possible with the current GUI tools. This setup would not be possible
to create (using the GUI tools) with your suggested design.

/Andreas

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

NoDefaultSyslog Breaks Logwatch on Clean Install

[Gerald B. Cox]

I found this:

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

I had to do a clean install of F25 because of problems with the system
rescue tools, now I find that Logwatch on a clean install is broken... and
it appears to be because of the removal of syslog.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

[Paul W. Frields]

On Mon, Jul 10, 2017 at 05:02:25PM +0200, Pierre-Yves Chibon wrote:
> On Mon, Jul 10, 2017 at 04:49:32PM +0200, Miroslav Suchý wrote:
> > Dne 8.7.2017 v 20:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> > > Nah, most likely stg.fp.o is just some rpi on somebody's desk or a vm
> > > stuck in the corner of the infrastructure. I don't think you can make
> > > any conjectures about performance or reliability based on the staging
> > > instance.
> > 
> > Nope. AFAIK Stg machines are real machines in proper infrastructure. They 
> > may be slow by few percent, but moving to prod
> > will not make it much faster. So if anything is slow in STG then it is 
> > valid issue.
> 
> They are real machines but may have less memory or cpus than prod ones. So it 
> is
> at this stage a little hard to figure how better or worse it will be in prod.

Although also fair to point out there've been numerous performance
improvements thus far, and no reason to think there won't be more.
Pagure is eminently hackable so we are still encouraging contribution
upstream (of which there has been a lot already).

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Matthew Miller]

On Tue, Jul 11, 2017 at 01:10:52PM +0200, Kevin Kofler wrote:
> > But we can't "just ignore the compose tools", because we want the
> > metadata to actually be correct and consistent. If we dump an ISO into
> > a compose link this, it won't be.
> 
> Real users don't care about metadata that you upload to some obscure server 
> like pdc.fp.o that most users don't even know exists (this thread was the 
> first time that *I* heard of it, and I am in no way a new user ;-) ). Real 
> users care about what ends up on the mirrors. Dropping in the ISO into the 
> mirrored directory perfectly addresses the expectations of actual users.

I get that having correct metadata is useful for a lot of programmatic
things (like maybe finally making https://pagure.io/releng/issue/5805 a
reality), but I agree about the results. Also, we shouldn't have this
dictated to us by the design of the compose tools. We should look at
what we want the user-facing results to be and work back from that.


-- 
Matthew Miller

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

Self Introduction

[Felix Yan]

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.

I am currently a developer of the Deepin Desktop team, and also a
developer of Arch Linux [2]. Since the Deepin distribution is based on
Debian, I've been working on a port to Arch [3 & 4] since 2015, and it's
almost finished. I would still like to help the DE to have a broader
reach, and I think Fedora is a good distribution for desktop users.

Besides the Deepin DE packages, I would also like to help on Chinese
i18n packages like IMEs, fonts, etc. But these are plans for the future.
The first package I submit is a low-level dependency in the whole Deepin
tree. Zamir Sun has kindly approved it, but I still need a sponsor. Any
help in getting this into shape would be greatly appreciated.

Thanks for your time and let me know what you think!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1468861
[2] https://www.archlinux.org/people/developers/#fyan
[3] https://www.archlinux.org/groups/x86_64/deepin/
[4] https://www.archlinux.org/groups/x86_64/deepin-extra/

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

RFC: Packing Deepin Desktop Environment packages into Fedora

[Zamir SUN]

Hi all,

Deepin Desktop Environment(Short as Deepin DE in following part) is the
Desktop shipped with Deepin.
Recently we want to pack Deepin DE into Fedora. We are working with one
of the Deepin developers on a Wiki Page[1] aiming at making this easier
for people who want to help and who can help and finally form a SIG to
maintain these packages.

I created a tracking bug to collect package review status here[2]. Some
of the requests might be a little outdated.

As this is a huge task as it involves a lot of packages that is not in
Fedora yet, we want your comments and advises.

Thanks for the kind help.

[1] https://fedoraproject.org/wiki/SIGs/DeepinDE
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1465889

-- 
Ziqian SUN (Zamir)
z...@fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 26 is officially here!

[sixpack13]

No, No, Nooo !
It's aleady here, to 
:-)


THANKS Fedora's for a new release !!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Tue, Jul 11, 2017 at 6:40 AM, Andreas Tunek 
 wrote:

So you mean that bug 1270953
(https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
fixed/implemented?


I'm not sure it was ever broken. Did you make sure there was an another 
administrator first before trying to remove the last one? :)


I just tested it and it is *not* necessary to switch user accounts at 
all, thankfully. You can set or remove the administrator status of any 
user from control-center as long as another administrator exists.


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

Cleaning packages with broken deps

[Mohan Boddu]

Hi,

We have a ticket on how to clean up packages with broken deps:

https://pagure.io/releng/issue/6877

We had a discussion about this issue in our releng meeting on Jul 10th
2017. The problem is that there is no good way of solving this issue, but
we came up two options:

1. Blocking the pkgs at branching and unblock them as necessary, pkg
maintainers will request to unblock them and releng will review them and
unblock them. Advantage is that we will more aware of whats got blocked and
whats got unblocked. But it needs releng handling the tickets and we are
not sure how many will show up per release cycle.

2. Using bodhi with greenwave to block pkgs. And config waiverdb to waive
certain pkgs even if they are having dep issues so that they wont be
blocked. And other pkgs can be blocked which can be unblocked by either
releng or the pkg maintainer. We can configure it how ever we want like
allowing only releng to unblock them when pkg maintainer files a ticket.

Please let us know what you think and we are open to any other suggestions.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pure-ftpd 1.0.46 released!

[Dominik Kucher]

Hi!

No longer maintains pure-ftpd? 1.0.46 is released on Apr. 24 2017

-- 
Dominik Kucher
A-2130 Mistelbach, Ebendorferstraße 7/2/3
p: +43 (0) 720 511 941
f: +43 (0) 1 34242 289967
m: +43 (0) 676 57 68 677




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

Fedora 26 is officially here!

[Matthew Miller]

Fedora 26 is here! Read the official announcement with
hyperlinks and fancy formatting and details and (especially)
thanks to the community at:

  https://fedoramagazine.org/fedora-26-is-here/

or just go ahead and grab it from

  https://getfedora.org/



-- 
Matthew Miller

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

Re: Using ndb in RPM

[Jos Vos]

Hi,

On Mon, Jul 10, 2017 at 12:13:58PM -0400, Przemek Klosowski wrote:

> Could you possibly summarize what you remember about those tests? What 
> scenario did you look at? Was the difference more like seconds vs hours, 
> or microseconds vs milliseconds?

I found some of my old mail back.  In my tests a full processing cycle
for reading and processing (JSON deserializing in my case) data,
measured on a large amount of operations, was 4 times faster in LMDB
than in SQLite.

Note that this includes application processing (at this moment
I can't recall what that test did, it was 1,5 year ago...), so the
pure difference in DB processing time might even be much larger.

In general, I agree that SQLite is a fast DB when comparing, for
example, with ProgreSQL.  I did tests for that too in the past and
the difference is huge (and the feature set difference is huge too ;-)).

BTW, I'm pretty sure Howard Chu, the author of LMDB, would be happy to
discuss things with the Fedora/RPM community, if someone is interested.

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM

[stan]

On Tue, 11 Jul 2017 13:52:32 +0200
Michael Schroeder  wrote:

> So, suggesting different databases is fine and all, but they have
> to be integrated and well tested. We re-added support for multiple
> database just for that, so that we can test things and decide what
> to do.

Does this mean it would be possible to add support for a real
database as an option?  Like postgresql or mariahdb or mysql?  That
would give access to views, triggers, and stored procedures.  Then when
an rpm update occurred, the views of what it depends on and what
depends on it could be updated by a stored procedure triggered by the
update.  This would also simplify, and speed, dnf since it could just
run a sql query to find all dependencies and their versions (I think).
And real databases allow granular access to be defined for users per
table.  Heavy weight solution, but some benefits.

Just curious.
___
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/07/2017 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> If no other reason for a mass rebuild has surfaced, then we should
>> just skip the mass rebuild for the Fedora 27 release.

> Hm, https://pagure.io/releng/issue/6853 is about Go piggy-backing on
> the "normal" mass rebuild

Thanks, but those changes are unlikely to be ready for the mass rebuild,
and a separate rebuild of Go packages will be needed.  (And even Go 1.8
FTBFS on most architectures in rawhide.)

So it's just the s390x import which remains as the rationale for a mass
rebuild.

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

Re: Using ndb in RPM

[Stephen John Smoogen]

On 11 July 2017 at 07:52, Michael Schroeder  wrote:
> On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote:
>> And we do use SQLite today in DNF with the yumdb, as well as the new
>> SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
>> in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.
>
> AFAIR it was removed because it was unbearable slow, nobody used it,
> and nobody wanted to maintain it.
>

1. It was very slow.. and developers complained a lot about how long
it took to get various things done.
2. Because it was slow people would think it was deadlocked and lots
of debugging would be done to show it was just slow.
3. When it did deadlock it was very hard to debug because a lot of the
problems seemed to be system dependent. Move the db over to some other
system and no deadlock. Move it back, deadlock, rebuild the system
maybe it would deadlock maybe it wouldn't.
4. When it was put in there were a lot of people who were happy to
help debug etc, however most of them were not the level of debugging
actually needed as the problems were rarely the queries themselves as
much as the locking/rollback/multiple user code
5. Rollback did not always rollback.

I believe there are about 4 or 5 other reasons that were being
complained about during that time.

> Here's a bit of technical input for discussions about rpm's database:
>
> 1) Background: how rpm uses the database
>
> 2) Problems with Berkeley DB
> 3) What about ndb?
> 4) Does it make sense to use a self-made database?
>

5) This looks to be a cross operating system development versus a RH
NIH development.


> --
> Michael Schroeder   m...@suse.de


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

Strange situation with Wine on Fedora 27

[Thomas Goffin]

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 conflicts with file from package 
gstreamer1-1.12.0-1.fc27.x86_64
  file /usr/share/locale/af/LC_MESSAGES/gstreamer-1.0.mo 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/locale/ast/LC_MESSAGES/gstreamer-1.0.mo 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/locale/az/LC_MESSAGES/gstreamer-1.0.mo 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/locale/be/LC_MESSAGES/gstreamer-1.0.mo 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/locale/bg/LC_MESSAGES/gstreamer-1.0.mo 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/locale/ca/LC_MESSAGES/gstreamer-1.0.mo 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/locale/cs/LC_MESSAGES/gstreamer-1.0.mo 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/locale/da/LC_MESSAGES/gstreamer-1.0.mo 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/locale/de/LC_MESSAGES/gstreamer-1.0.mo 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/locale/el/LC_MESSAGES/gstreamer-1.0.mo 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/locale/en_GB/LC_MESSAGES/gstreamer-1.0.mo 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/locale/eo/LC_MESSAGES/gstreamer-1.0.mo 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/locale/es/LC_MESSAGES/gstreamer-1.0.mo 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/locale/eu/LC_MESSAGES/gstreamer-1.0.mo 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/locale/fi/LC_MESSAGES/gstreamer-1.0.mo 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/locale/fr/LC_MESSAGES/gstreamer-1.0.mo 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/locale/fur/LC_MESSAGES/gstreamer-1.0.mo 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/locale/gl/LC_MESSAGES/gstreamer-1.0.mo 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/locale/hr/LC_MESSAGES/gstreamer-1.0.mo 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/locale/hu/LC_MESSAGES/gstreamer-1.0.mo 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/locale/id/LC_MESSAGES/gstreamer-1.0.mo 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/locale/it/LC_MESSAGES/gstreamer-1.0.mo 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/locale/ja/LC_MESSAGES/gstreamer-1.0.mo 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/locale/lt/LC_MESSAGES/gstreamer-1.0.mo 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/locale/nb/LC_MESSAGES/gstreamer-1.0.mo 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/locale/nl/LC_MESSAGES/gstreamer-1.0.mo 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/locale/pl/LC_MESSAGES/gstreamer-1.0.mo from install of 
gstreamer1-1.12.1-1.fc27.i686 conflicts with file from package 
gstreamer1-1.12.

Re: Using ndb in RPM

[Michael Schroeder]

On Tue, Jul 11, 2017 at 06:41:05AM -0400, Neal Gompa wrote:
> And we do use SQLite today in DNF with the yumdb, as well as the new
> SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
> in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.

AFAIR it was removed because it was unbearable slow, nobody used it,
and nobody wanted to maintain it.


Here's a bit of technical input for discussions about rpm's database:

1) Background: how rpm uses the database

An Rpm package contains a header, which is basically a key->value
store. This header is put in the database as a binary blob (you
need the blob form for verification purposes). Rpm's database
layer maintains a couple of indices for parts of the header
like dependencies or the filelist, so queries are fast.
rpm has just two operations that modify the database: "add a
new header" and "remove an old header".

2) Problems with Berkeley DB

  - license issues
  - way too complex and buggy
  - bad locking scheme (stale locks)
  
3) What about ndb?

  - written as experiment how an ideal database would look like
  - currently optional to gather experience with it

  - main "packages" database written with data safty in mind, i.e.
checksumming, extra tests to make sure data is not overwritten,
simplistic design (1300 lines of code).
  - index databases are basically mmaped hashes
  - the database detects if the index is out of sync and auto-rebuilds
  - reader/writer locking scheme (multiple readers, one writer)

4) Does it make sense to use a self-made database?

There are pros and cons. On the pro side is that the code is pretty small
and tailored for rpm's need (speed & locking). With Berkeley DB, the
database code was a "black box", you couldn't do much which bugzilla
reports about a corrupt rpm database (and there were lots of those).
With the "database" being part of rpm the rpm maintainers can
actively fix issues.
The con side is, of course, that there's a bit more code to maintain.


So, suggesting different databases is fine and all, but they have
to be integrated and well tested. We re-added support for multiple
database just for that, so that we can test things and decide what
to do.

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-10 21:37 GMT+02:00 Michael Catanzaro :
> On Mon, Jul 10, 2017 at 12:04 PM, Andreas Tunek 
> wrote:
>>
>> Will there be any GUI method to remove the sudo rights from the first
>> created user?
>
>
> I believe you can do this from gnome-control-center if and only if you first
> (a) create another admin (wheel) user and log in as that user, or (b) set a
> root password, create a new non-admin user, and log in as that user.
>
> It's designed to not allow removing the only admin account, and I'm not sure
> if it allows you to remove your own admin status.
>
> Michael
>

So you mean that bug 1270953
(https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
fixed/implemented?

/Andreas

> ___
> 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: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Kevin Kofler]

Adam Williamson wrote:
> But we can't "just ignore the compose tools", because we want the
> metadata to actually be correct and consistent. If we dump an ISO into
> a compose link this, it won't be.

Real users don't care about metadata that you upload to some obscure server 
like pdc.fp.o that most users don't even know exists (this thread was the 
first time that *I* heard of it, and I am in no way a new user ;-) ). Real 
users care about what ends up on the mirrors. Dropping in the ISO into the 
mirrored directory perfectly addresses the expectations of actual users.

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

Re: Using ndb in RPM

[Neal Gompa]

On Tue, Jul 11, 2017 at 6:36 AM, Florian Weimer  wrote:
> * Björn 'besser82' Esser:
>
>> Well, the RPM db on my desktop system is about 193 MBytes, from which
>> the most amount (170 MBytes) comes from the 'Packages' db… I'd still
>> consider that several MBytes given today's state of technology and
>> SQLite should be able to deal with databases of that size with
>> reasonable time consumption when it comes to queries.
>
> Obviously, that depends on how the database is defined and if the
> queries are half-decent (so that not everything has to fall back to
> full table scans).
>
> And it's not just about processing time.  With small VMs and
> containers, it's also about not putting everything into RAM.
>
>> There are in fact some technical limits in LMDB, but wouldn't it be more
>> feasable to put man power into fixing those limits, than spending time
>> on some homebrew solution?
>
> I think SQLite would be the better choice, after comparing the
> upstream reactions (not features) when discussing RPM's special
> requirements with them (key sizes, read-only access without locking).

And we do use SQLite today in DNF with the yumdb, as well as the new
SWDB coming soon(TM). I'm not sure why the SQLite backend was removed
in rpm 4.9.0, but maybe it should be revisited for rpm 4.14.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM

[Florian Weimer]

* Björn 'besser82' Esser:

> Well, the RPM db on my desktop system is about 193 MBytes, from which 
> the most amount (170 MBytes) comes from the 'Packages' db… I'd still 
> consider that several MBytes given today's state of technology and 
> SQLite should be able to deal with databases of that size with 
> reasonable time consumption when it comes to queries.

Obviously, that depends on how the database is defined and if the
queries are half-decent (so that not everything has to fall back to
full table scans).

And it's not just about processing time.  With small VMs and
containers, it's also about not putting everything into RAM.

> There are in fact some technical limits in LMDB, but wouldn't it be more 
> feasable to put man power into fixing those limits, than spending time 
> on some homebrew solution?

I think SQLite would be the better choice, after comparing the
upstream reactions (not features) when discussing RPM's special
requirements with them (key sizes, read-only access without locking).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

[Peter Robinson]

On Tue, Jul 11, 2017 at 11:09 AM, Emmanuel Seyman  wrote:
> * Pierre-Yves Chibon [11/07/2017 11:41] :
>>
>> But it is constructed around the idea that there is only one package for a 
>> given
>> name.
>
> I'm not sure the assumption is safe to make. A number of perl modules have two
> packages (one of them coming from the perl core package, the other from the
> package's home on CPAN).

But there's only one source package in that case, in the core case
they're a sub package of the perl package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM

[Björn 'besser82' Esser]

Am 11.07.2017 um 05:49 schrieb Chris Adams:

Once upon a time, Leonid Podolny  said:

Correct me if I'm wrong, but the database here is several thousands rows in 
total, several MBs in size. Every database engine should be fine. We probably 
care much more about things like ease of development, stability, proper locking 
and such.

On my fairly normal desktop system, /var/lib/rpm is 128MB.  There's a
lot of information stored in there: each RPM has a bunch of metadata,
scripts, lists of provides and requires, and a list of all files and
directories (each entry with its own metadata information).

One requirement that tends to set RPM apart from some of the candidate
database libraries is non-root read-only access.  I'm not sure this is
an absolute requirement, but I expect it would cause significant upset
with system administrators if "rpm -q foo" changed to require root
access.



Well, the RPM db on my desktop system is about 193 MBytes, from which 
the most amount (170 MBytes) comes from the 'Packages' db… I'd still 
consider that several MBytes given today's state of technology and 
SQLite should be able to deal with databases of that size with 
reasonable time consumption when it comes to queries.


There are in fact some technical limits in LMDB, but wouldn't it be more 
feasable to put man power into fixing those limits, than spending time 
on some homebrew solution?


Just my 2 cents…

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

Re: Coming soon: Pagure service for dist-git

[Emmanuel Seyman]

* Pierre-Yves Chibon [11/07/2017 11:41] :
>
> But it is constructed around the idea that there is only one package for a 
> given
> name.

I'm not sure the assumption is safe to make. A number of perl modules have two
packages (one of them coming from the perl core package, the other from the
package's home on CPAN).

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

Re: Coming soon: Pagure service for dist-git

[Vít Ondruch]

Dne 11.7.2017 v 11:41 Pierre-Yves Chibon napsal(a):
> On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote:
>>Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
>>
>>  On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
>>
>>
>>  Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
>>
>>  On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
>>
>>  On Fri, Jul 07, 2017 at 03:05:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
>>
>>  3. The default landing page for a package shows a message about
>> the missing readme. Maybe we could show the %description there in
>> such cases?
>>
>>  Or as an interim, show the spec file?
>>
>>  What would you think of: 
>> http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>>
>>  The description comes from the rawhide repo via mdapi.
>>
>>  Is the mdapi already fixed to provide correct information about
>>  overlapped packages?
>>
>>  I feel this is a packaging issue.
>>
>>
>>  https://apps.fedoraproject.org/packages/ruby
>>
>>  I don't think it is based on the link above.
>>
>>  What you are pointing out isn't a problem with mdapi but with 
>> fedora-packages
>>  and it is caching the info
>>
>>Right, I have no idea how it came to conclusion that rubygems is
>>subpackage of ruby, this is not true, never was true and never will be
>>true.
> Oh I can easily answer this one:
> - Download: 
> http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
> - Extract it: bzip2 -d 
> f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
> - Open the database: sqlite3 
> f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite
>  
> - Run the query:
> SELECT name, arch, version, epoch, release, rpm_sourcerpm FROM packages where 
> name ='rubygems';
> Here is the output:
> rubygems|noarch|2.6.10|0|100.fc27|rubygems-2.6.10-100.fc27.src.rpm
> rubygems|noarch|2.6.11|0|79.fc27|ruby-2.4.1-79.fc27.src.rpm
>
> So in the rpm metadata, there is a rubygems package coming from the ruby 
> source
> rpm.
>
> I can't tell you why the metadata think so, but that's what they contain and
> thus why mdapi exposes this.

Well, yes. Unfortunately, I said it the other way. But the "packages"
states:

~~~


ruby

Subpackage of rubygems 
~~~


>  
>>So lets take a look on mdapi:
>>
>>https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems
>>
>>What does the 'basename "rub"' means? One could think that this could be
>>name of the source package, but honestly, I don't know.
> I saw this one yesterday, I wonder if this isn't a bug in mdapi eating the 
> last
> letter (so a y here).
>  
>>https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
>>https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs
>>
>>What is the "co-packages" list? It does not make any sense to me looking
>>at all three links above.
> The co-packages are supposed to be the packages generated by the source 
> package.

But then there are missing quite some packages. I'll borrow the list
from Tom Hughes:

~~~
bericote [~/ruby] % fgrep %package ruby.spec
%package devel
%package libs
%package -n rubygems
%package -n rubygems-devel
%package -n rubygem-rake
%package irb
%package -n rubygem-rdoc
%package doc
%package -n rubygem-bigdecimal
%package -n rubygem-did_you_mean
%package -n rubygem-io-console
%package -n rubygem-json
%package -n rubygem-minitest
%package -n rubygem-openssl
%package -n rubygem-power_assert
%package -n rubygem-psych
%package -n rubygem-net-telnet
%package -n rubygem-test-unit
%package -n rubygem-xmlrpc
~~~

This is 19 packages vs 14 packages listed by mdapi.

>
>>  but I also think there is a packaging issue at the
>>  root of this question.
>>
>>Overlapping packages is nothing new. And as long as repositories and
>>depsolver can handle them, there is no problem with them.
>>
>>Actually it would be pretty natural if one day rubygems is shown as coming
>>from rubygems SRPM and the other day it would say it comes from ruby SRPM.
>>This is how DNF works. But mdapi together with packages are trying to be
>>smarter.
> Maybe it would feel natural to you but certainly not to me.
> mdapi is not smart, quite the opposite, it exposes what is in the sqlite
> databases of the rpm repositories. If it exposes something odd, it is likely
> because there is something odd in the databases.
> But it is constructed around the idea that there is only one package for a 
> given
> name.

But this is wrong assumption. Repository may contain varaious versions
of package. Look at RHEL repositories. Look at Copr. One package per
name is just Fedoraism and it is due to space constrains AFAIK.


>
>>The question is, why there is no trace of "dnf", "libsolv" or "librepo" in
>>the source code of mdapi. This is

Re: Coming soon: Pagure service for dist-git

[Pierre-Yves Chibon]

On Tue, Jul 11, 2017 at 09:50:31AM +0200, Vít Ondruch wrote:
>Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
> 
>  On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
> 
> 
>  Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
> 
>  On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
> 
>  On Fri, Jul 07, 2017 at 03:05:43AM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
>  3. The default landing page for a package shows a message about
> the missing readme. Maybe we could show the %description there in
> such cases?
> 
>  Or as an interim, show the spec file?
> 
>  What would you think of: http://ambre.pingoured.fr/public/Pagure-DistGit.png 
> ?
> 
>  The description comes from the rawhide repo via mdapi.
> 
>  Is the mdapi already fixed to provide correct information about
>  overlapped packages?
> 
>  I feel this is a packaging issue.
> 
> 
>  https://apps.fedoraproject.org/packages/ruby
> 
>  I don't think it is based on the link above.
> 
>  What you are pointing out isn't a problem with mdapi but with fedora-packages
>  and it is caching the info
> 
>Right, I have no idea how it came to conclusion that rubygems is
>subpackage of ruby, this is not true, never was true and never will be
>true.

Oh I can easily answer this one:
- Download: 
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
- Extract it: bzip2 -d 
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite.bz2
- Open the database: sqlite3 
f5ae4c542fa8d9fd4f4bd293a15e650f7b618a400ee086a25da4931d4981ddec-primary.sqlite 
- Run the query:
SELECT name, arch, version, epoch, release, rpm_sourcerpm FROM packages where 
name ='rubygems';
Here is the output:
rubygems|noarch|2.6.10|0|100.fc27|rubygems-2.6.10-100.fc27.src.rpm
rubygems|noarch|2.6.11|0|79.fc27|ruby-2.4.1-79.fc27.src.rpm

So in the rpm metadata, there is a rubygems package coming from the ruby source
rpm.

I can't tell you why the metadata think so, but that's what they contain and
thus why mdapi exposes this.
 
>So lets take a look on mdapi:
> 
>https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems
> 
>What does the 'basename "rub"' means? One could think that this could be
>name of the source package, but honestly, I don't know.

I saw this one yesterday, I wonder if this isn't a bug in mdapi eating the last
letter (so a y here).
 
>https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
>https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs
> 
>What is the "co-packages" list? It does not make any sense to me looking
>at all three links above.

The co-packages are supposed to be the packages generated by the source package.

>  but I also think there is a packaging issue at the
>  root of this question.
> 
>Overlapping packages is nothing new. And as long as repositories and
>depsolver can handle them, there is no problem with them.
> 
>Actually it would be pretty natural if one day rubygems is shown as coming
>from rubygems SRPM and the other day it would say it comes from ruby SRPM.
>This is how DNF works. But mdapi together with packages are trying to be
>smarter.

Maybe it would feel natural to you but certainly not to me.
mdapi is not smart, quite the opposite, it exposes what is in the sqlite
databases of the rpm repositories. If it exposes something odd, it is likely
because there is something odd in the databases.
But it is constructed around the idea that there is only one package for a given
name.

>The question is, why there is no trace of "dnf", "libsolv" or "librepo" in
>the source code of mdapi. This is what you should use to get reliable
>information about packages.

mdapi stands for meta-data API, it is not in any way exposing package
dependencies, it is purely exposing meta data.

>   So to update the
>  description, simply update the package in rawhide.
> 
>  You can then simply complement these information with a README file.
> 
>  I think there should be something like "fedpkg generate-readme", where
>  the generated README could contain badges, which would reference BZ,
>  Koscheji, Koji, whatever else, it could contain the description etc +
>  some useful development tips. This would be in similar manner GitHub can
>  display various badges now. The initial README could be generated during
>  the repository setup. This way, Pagure won't need any specific
>  fedora-infrastructure hacks.
> 
>  Pagure already supports some sort of theming allowing to override templates.
>  This is the mechanism used to display the information above, so this template
>  isn't part of pagure itself.
> 
>But you still need to adjust some templates. I am proposing something more
>generic. To adjust the README, you don't need any server side template.

If you feel strongly about this, I'll welcome any help :)

Re: Coming soon: Pagure service for dist-git

[Vít Ondruch]

Dne 11.7.2017 v 10:24 Tom Hughes napsal(a):
> On 11/07/17 08:50, Vít Ondruch wrote:
>
>> Right, I have no idea how it came to conclusion that rubygems is
>> subpackage of ruby, this is not true, never was true and never will
>> be true.
>
> Err because the spec file says it is? eg on the F26 rpm:

Of course you are right and I meant it the other way around of course.
This is what "packages" app says about it:

~~~


ruby

Subpackage of rubygems 
~~~

https://apps.fedoraproject.org/packages/ruby


Vít

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

Re: Coming soon: Pagure service for dist-git

[Tom Hughes]

On 11/07/17 08:50, Vít Ondruch wrote:

Right, I have no idea how it came to conclusion that rubygems is 
subpackage of ruby, this is not true, never was true and never will be true.


Err because the spec file says it is? eg on the F26 rpm:

bericote [~] % rpm -qi rubygems | fgrep "Source RPM"
Source RPM  : ruby-2.4.1-79.fc26.src.rpm

and, in a dist-git checkout:

bericote [~/ruby] % fgrep %package ruby.spec
%package devel
%package libs
%package -n rubygems
%package -n rubygems-devel
%package -n rubygem-rake
%package irb
%package -n rubygem-rdoc
%package doc
%package -n rubygem-bigdecimal
%package -n rubygem-did_you_mean
%package -n rubygem-io-console
%package -n rubygem-json
%package -n rubygem-minitest
%package -n rubygem-openssl
%package -n rubygem-power_assert
%package -n rubygem-psych
%package -n rubygem-net-telnet
%package -n rubygem-test-unit
%package -n rubygem-xmlrpc

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: Coming soon: Pagure service for dist-git

[Vít Ondruch]

Dne 10.7.2017 v 19:31 Pierre-Yves Chibon napsal(a):
> On Mon, Jul 10, 2017 at 05:17:04PM +0200, Vít Ondruch wrote:
>>
>> Dne 10.7.2017 v 11:23 Pierre-Yves Chibon napsal(a):
>>> On Fri, Jul 07, 2017 at 09:31:22AM -0400, Matthew Miller wrote:
 On Fri, Jul 07, 2017 at 03:05:43AM +, Zbigniew Jędrzejewski-Szmek 
 wrote:
> 3. The default landing page for a package shows a message about
>the missing readme. Maybe we could show the %description there in
>such cases?
 Or as an interim, show the spec file?
>>> What would you think of: 
>>> http://ambre.pingoured.fr/public/Pagure-DistGit.png ?
>>>
>>> The description comes from the rawhide repo via mdapi.
>> Is the mdapi already fixed to provide correct information about
>> overlapped packages?
> I feel this is a packaging issue.
>
>> https://apps.fedoraproject.org/packages/ruby
>>
>> I don't think it is based on the link above.
> What you are pointing out isn't a problem with mdapi but with fedora-packages
> and it is caching the info

Right, I have no idea how it came to conclusion that rubygems is
subpackage of ruby, this is not true, never was true and never will be true.

So lets take a look on mdapi:

https://apps.fedoraproject.org/mdapi/rawhide/pkg/rubygems

What does the 'basename"rub"'means? One could think that this could be
name of the source package, but honestly, I don't know.

https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby
https://apps.fedoraproject.org/mdapi/rawhide/pkg/ruby-libs

What is the "co-packages" list? It does not make any sense to me looking
at all three links above.
> but I also think there is a packaging issue at the
> root of this question.

Overlapping packages is nothing new. And as long as repositories and
depsolver can handle them, there is no problem with them.

Actually it would be pretty natural if one day rubygems is shown as
coming from rubygems SRPM and the other day it would say it comes from
ruby SRPM. This is how DNF works. But mdapi together with packages are
trying to be smarter.

The question is, why there is no trace of "dnf", "libsolv" or "librepo"
in the source code of mdapi. This is what you should use to get reliable
information about packages.

>>>  So to update the
>>> description, simply update the package in rawhide.
>>>
>>> You can then simply complement these information with a README file.
>> I think there should be something like "fedpkg generate-readme", where
>> the generated README could contain badges, which would reference BZ,
>> Koscheji, Koji, whatever else, it could contain the description etc +
>> some useful development tips. This would be in similar manner GitHub can
>> display various badges now. The initial README could be generated during
>> the repository setup. This way, Pagure won't need any specific
>> fedora-infrastructure hacks.
> Pagure already supports some sort of theming allowing to override templates.
> This is the mechanism used to display the information above, so this template
> isn't part of pagure itself.

But you still need to adjust some templates. I am proposing something
more generic. To adjust the README, you don't need any server side template.


Vít
___
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

[Richard Hughes]

On 11 July 2017 at 05:37, 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.

From someone sitting on the sidelines: Thanks for doing this
unglamorous work, lots of people appreciate it!

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