Re: Fedora 27 mass rebuild at risk

[Carlos O'Donell]

On 07/07/2017 04:20 PM, Carlos O'Donell wrote:
> On 07/07/2017 08:53 AM, Florian Weimer wrote:
>> We currently have an invalid IFUNC resolver in libgcc.a on POWER
>> (rhbz#1467526).  glibc in rawhide recently started linking that into the
>> library and there are significant problems with that (rhbz#1467518).
>>
>> I'll be on PTO next week, and it does not seem likely that this is going
>> to be resolved upstream before that.  If upstream (both glibc GCC are
>> involved) don't come up with a solution, I'm not sure
>>
>> If we downgrade glibc to 2.25 in rawhide, we will have to rebuild at
>> least the following packages right after that because they have a
>> GLIBC_2.26 symbol version dependency:
>>
>>  inn-2.6.1-6.fc27.src.rpm
>>  remctl-3.13-4.fc27.src.rpm
>>  sudo-1.8.20p2-1.fc27.src.rpm
>>  tmux-2.5-1.fc27.src.rpm
>>  unbound-1.6.4-1.fc27.src.rpm
>>  xorg-x11-server-1.19.3-6.fc27.src.rpm
>>
>> Besides the glibc downgrade, I'm not aware of anything else we could do
>> to get ready for the mass rebuild in time.
> 
> IBM has worked through a patch that will fix the libgcc issue:
> https://sourceware.org/ml/libc-alpha/2017-06/msg01430.html
> 
> All we need to do now is:
> * Get the gcc trunk patch into F27 gcc.
> * Rebuild gcc and libgcc.
> * Rebuild glibc.
> 
> And that should be everything we need to do before the mass rebuild
> start on the 12th.
> 
> I'm reaching out to Jakub/Marek on the gcc side to get help with this.

Status update:

* Get the gcc trunk patch into F27 gcc.

  * Patch committed to trunk [Done -- IBM]

  * Rebuild gcc and libgcc [In progress -- Red Hat]

* Blocked on several header issues and changes which make gcc FTBS.
  Working on fixing the issues.
 
  * Fedora backport [Not started]

* Rebuild gcc and libgcc [Not started]

* Rebuild glibc

  * Patch committed to trunk [In progress -- IBM]

* Second round review complete, and final patch in progress.

  * Sync to Fedora [Waiting -- Red Hat]

  * Rebuild [Waiting -- Red Hat]

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.

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

Re: Using ndb in RPM

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

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

Re: Using ndb in RPM

[Leonid Podolny]

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 Jul 10, 2017, at 9:16 AM, Jos Vos  wrote:
> 
> On Mon, Jul 10, 2017 at 02:30:59PM +0200, Pierre-Yves Chibon wrote:
> 
>> Oups, that was meant to be: On which side?
> 
> LDBM was many factors faster than SQLite.  No concrete figures,
> it was a year ago or so when we decided to go for LMDB (still
> a product in development...).  I had attended some talk from
> Howard Chu (the author) about LMDB and knew quite soon it was
> the way to go.
> 
> -- 
> --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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1469313] New: perl-Dist-Zilla-6.010 is available

[bugzilla]

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

Bug ID: 1469313
   Summary: perl-Dist-Zilla-6.010 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Dist-Zilla
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
psab...@redhat.com



Latest upstream release: 6.010
Current version/release in rawhide: 6.009-2.fc27
URL: http://search.cpan.org/dist/Dist-Zilla/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5898/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora Rawhide-20170710.n.0 compose check report

[Adam Williamson]

On Mon, 2017-07-10 at 15:31 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Atomic qcow2 x86_64
> Workstation live i386
> Server boot i386
> Atomic raw-xz x86_64
> Kde live i386
> 
> Failed openQA tests: 22/137 (x86_64), 1/18 (i386), 1/2 (arm)

There's kind of a grab bag of stuff going on in openQA at the moment,
from Rawhide changes which have invalidated tests through intermittent
failures to straight up genuine bugs. I've made a host of changes to
the tests to deal with some of the problems and will give a detailed
report on what's actually wrong in Rawhide tomorrow. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

On Thu, 2017-07-06 at 10:05 -0400, Matthew Miller wrote:
> On Wed, Jul 05, 2017 at 02:33:01PM -0700, Adam Williamson wrote:
> > With Pungi 4 we really can't do that any more. Composes have a much
> > more solid identity as an actual thing. 'A compose' has a compose ID,
> > production composes have a label, and these can't really be duplicated.
> > There is a bunch of metadata which is produced for the compose *as a
> > whole*; if we do a compose where we try 10 images and 1 fails, the
> > metadata for that compose will list 9 images. If we then ran another
> > compose just to produce that 1 missing image (with properties as
> > similar as possible to the original compose), the metadata for the new
> 
> I understand the value of having something that is an authoritative
> source of truth about release artifacts. I'm not sure at all about the
> value of having The Compose like this. Especially since we already do
> things like assuming that tests which apply to RC 1.4 are probably good
> for 1.5 since we know none of the relevant packages have changed. I
> guess we could solve this with another layer of abstraction: a
> super-compose which could include artifacts from various composes or
> other compose-like sources.

Expect my resignation letter attached to a copy of the fedfind source,
with a note saying "I'm damned if I'm writing ANOTHER layer of this
crap". :P

> > script or something, both of which would be error-prone). It's also not
> > actually that easy just to respin a single image; Pungi 4 isn't really
> > built to do that (you'd have to create a new Pungi compose config file
> > each time you wanted to do it), and releng really doesn't want to do it
> > manually below the Pungi level any more in case of inconsistencies or
> > errors.
> 
> Maybe that just means it needs to be easier to create and update pungi
> compose configs?

Pungi is inherently a complicated thing, because it's a tool for doing
a whole bunch of different tasks for two rather different
distributions. There's a limit to how much we can unilaterally mess
around with this stuff (because we're sharing a tool with RHEL, here)
and a limit to how much we can simplify it, I think.
-- 
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

[Jason L Tibbitts III]

> "RB" == Randy Barlow  writes:

RB> On top of these problems I have also observed a trend away from
RB> having releases and versions at all. Lots of golang programs just
RB> depend on git commit hashes of libraries that don't make
RB> releases. I've also observed this problem in some JavaScript
RB> libraries.

That's true, but we have a scheme for versioning packages containing
such things, and I see no reason that scheme isn't applicable anywhere
we might need to make reference to a version of a particular piece of
software.

 - J<

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


-- 
 Jason L Tibbitts III - ti...@math.uh.edu - 713/743-3486 - 660PGH
 System Manager:  University of Houston Department of Mathematics 
___
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 Mon, 2017-07-10 at 00:05 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Note that for dumb reasons that I hate we actually strip the metadata
> > from the final compose when it's actually approved and shipped out to
> > mirrors, but when a compose completes, the metadata related to that
> > compose is uploaded to PDC: https://pdc.fedoraproject.org/ . Once
> > that's done it's not expected, and it may in fact be impossible, for
> > that metadata to be edited, and it's never removed. So even though the
> > metadata for Alpha, Beta and Final composes can't be found on the
> > mirrors with them, it *can* be seen in PDC.
> 
> All this does not explain why you cannot just drop an ISO file into the 
> directory to be sent to the mirroring. Just ignore all the compose tools and 
> cp or scp or rsync the file in, how hard can that be?

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

[Randy Barlow]

On Mon, 2017-07-10 at 11:40 -0500, Adam Miller wrote:
> The main motivation for bundling as of late is golang[0], it's
> extremely common out in the community for software to pull in
> "Vendored" libraries even if they are exact copies of remote
> upstreams
> (this is common with tools like godep[1]) because golang is
> statically
> compiled by default (you can dynamically link with gcc-go and I
> *think* recent releases of cgo but I've yet to find a golang project
> that officially uses or endorses it's use). It's also extremely
> painful to unbundle these as some more popular software written in
> golang such as docker[2], kubernetes[3], and openshift[4] have
> upwards
> of 100 bundled libs (over 1000 for OpenShift).

On top of these problems I have also observed a trend away from having
releases and versions at all. Lots of golang programs just depend on
git commit hashes of libraries that don't make releases. I've also
observed this problem in some JavaScript libraries.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity WG (once every two weeks)

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG (once every two weeks) on 2017-07-11 from 10:00:00 to 11:00:00 
US/Eastern
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](https://board.net/p/modularity-wg-agendas).



Source: https://apps.fedoraproject.org/calendar/meeting/5249/

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

Re: Intel i915 firmwares

[Chris Murphy]

Another thing that's a big frustrating about this, is when the firmware 
loading, or various other features, is enabled I get:

Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option 
enable_guc_loading - tainting kernel
Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option 
enable_guc_submission - tainting kernel
Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option enable_psr - 
tainting kernel
Jul 09 21:18:04 f26h.localdomain kernel: Setting dangerous option 
disable_power_well - tainting kernel

So it's a catch-22: take no dangerous risk, get no neat features. And it's 
vague danger. Dangerous how? Crashes? Or melt the CPU?


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

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Chris Adams]

Once upon a time, Michael Catanzaro  said:
> On Mon, Jul 10, 2017 at 12:12 PM, Reindl Harald
>  wrote:
> >and how do you imagine systemd to "get fixed"?
> >by allow the rescue target without authentication?
> >
> >at this point you are mostly in the dracut stuff
> >
> >that "popular pattern" needs to be fixed
> 
> One option would be to prompt for username, and allow logins for any
> user in the admin group.
> 
> I don't see much point to having a rescue mode if it's never worked
> for the vast majority of its users (Ubuntu users).

IIRC, the old initscripts used sushell (which just directly starts a
shell), and systemd switched to using sulogin (which requires a
password).

There are arguments for/against each, with "sulogin --force" in between
(my personal preference would be "sulogin --foce", but I recognize
that's just my preference).

What I would like to see with the current systemd setup is for what
shell is called to be more consistently configurable than grepping for
all the service files that call sulogin, copying them to
/etc/systemd/system, and doing a search/replace.  Right now, that means
that if there's a change to one of those service files, or if additional
service files are created that call sulogin/sushell, you'll miss on that
just because you wanted to change local policy for a portion of it.

IMHO it would be much better if there was a single place to set this
policy by default (and admins could still override it on a per-case
basis by replacing the service file).  Either use a file in
/etc/sysconfig or follow a symlink (although the "sulogin --force" can't
currently be achieved directly that way).

-- 
Chris Adams 
___
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 Mon, Jul 10, 2017 at 12:12 PM, Reindl Harald 
 wrote:

and how do you imagine systemd to "get fixed"?
by allow the rescue target without authentication?

at this point you are mostly in the dracut stuff

that "popular pattern" needs to be fixed


One option would be to prompt for username, and allow logins for any 
user in the admin group.


I don't see much point to having a rescue mode if it's never worked for 
the vast majority of its users (Ubuntu users).


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

[Owen Taylor]

On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
> Jaroslav Reznik wrote:
> > = System Wide Change: Graphical Applications as Flatpaks =
> > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl
> > atpaks
> > 
> > Change owner(s):
> > * Owen Taylor 
> 
> This change is leaving several questions unanswered:
> 
> * As I understand it, those Flatpaks are going to be built from RPMs.
> Is the intent to ship both the original RPMs and the Flatpak or only
> the Flatpak (or is this going to depend on the individual package)?
> And if the former, are the shipped RPMs going to be the FHS-compliant 
> version or the one relocated into Flatpak's proprietary prefix?

The rebuilt RPMs are really only interesting within Flatpaks - they
will be available for download from Koji, but there would be no reason
for a user to do so.

As for standard application RPMs, it's really going to be something
we figure out over time. My vision is something like:

 F27: packagers are *able* to create Flatpaks of their application.
  They must also maintain standard RPMs.

 F28: packagers (of graphical applications) are *encouraged* to create
  Flatpaks of their applications along side standard RPM packaging.
  They *may* drop the standard RPM packaging if there is good
  reason to.

 F29: packagers (of graphical applications) must create Flatpaks of
  their applications if possible. They *may* keep standard RPM
  packaging.

But this is really highly dependent on how modularity work happens more
widely in Fedora. "standard RPM packaging" assumes we still have
a F tag in Koji where everything is built together with common
coordinated dependencies. 

The Change proposal, in any case is really only about enabling this as
an something that packagers may opt into if they want to.

> * What is the advantage of shipping Fedora distribution packages
> to Fedora users as Flatpaks? I see only drawbacks compared to RPM,
> because everything not included in the base runtime must be bundled,
> so we have all the usual issues of bundled libraries: larger
> downloads, more disk consumption, more RAM consumption (shared system
> libraries are also shared in RAM), slower and less efficient delivery
> of security fixes, FHS noncompliance, etc. And the portability
> argument is moot when we are talking about delivering Fedora 
> software to Fedora users.

I think this is addressed fairly well in the change proposal (I forgot
to mention sandboxing, so I just edited the proposal to include another
bullet point for that under "Benefit to Fedora".

> I strongly oppose this change.

I appreciate you asking questions anyways!

Owen

> Kevin Kofler
> ___
> 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: Graphical Applications as Flatpaks

[Owen Taylor]

Thanks for the thoughtful comment!

The ability for different applications to bundle different library versions is 
only one of the benefits that Flatpak's bring - other benefits like sandboxing, 
the ability to try out applications from newer and older versions of Fedora, 
and the ability to do robust upgrades without disturbing running applications 
would apply even if Fedora was keeping the idea of a single big package set.

And some of my early attempts to figure out Flaptak building actually assumed 
the big consistent package set.

But because Fedora is moving toward a modular world, the current plan for 
Flatpak support tries to work within that framework rather than the older 
big-package-set idea. And in that world, as long as the libpng maintainer is 
maintaining a libpng-1.6 branch in dist-git, you'll be able to use that for 
your application even if other applications have moved to libpng-1.8.

[ Hypthetical example, libpng should be in the runtime, not bundled with the 
app, because it is security critical. But the same applies to most easy 
examples. ]

But it should also be noted that modularity does not in any way abandon the 
idea of the collective maintenance of packages. There is still a single 
dist-git repository for each library or application, even if it is built into 
multiple different modules. And those dist-git repositories have to have clear 
lifetimes and interrelationships - a maintained branch of libpng can't depend 
on a branch of libz that is no longer maintained.

In some places (for example, security updates) I don't think we've fully 
figured out all the implications of this move to dist-git as the center of 
information, but we'll have to make it work for modularity to work. 

One thing that the Flatpak work does is give some good concrete examples of 
modularity in practice! 

Owen


- Original Message -
> On 07/06/2017 11:05 AM, Jaroslav Reznik wrote:
> 
> 
> 
> = System Wide Change: Graphical Applications as Flatpaks =
> https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> Change owner(s):
> * Owen Taylor  This change is to enable package
> maintainers to build Flatpaks of
> their applications and make those Flatpaks available for installation.
> 
> 
> I do recognize that the containerization trend solves enough problems to be
> an attractive and perhaps inevitable development. My concern is more from
> the Fedora governance side: given that Fedora is historically a coherent
> RPM-based distribution, the containerization has an opportunity cost, in at
> least two ways:
> 
> - it could distract already overworked package maintainers from properly
> coordinating ("I don't have time to deal with those dependencies, I will
> just wrap the stuff I need into a flatpack and have a beer and a movie")
> 
> 
> - it could distract users from demanding a well-put-together base ("I don't
> have time to chase and report this bug; I will just install that flatpack").
> 
> I do appreciate that if there are technical solutions to the downsides of
> containerization (security lifecycle, combinatorial divergence, etc.), it
> may end up replacing the package-based distribution model, but I think it's
> too early to declare such change. So, from the point of view of Fedora's
> available resources, are the benefits to Fedora compelling enough to justify
> this project?
> 
> 
> Please note that I am not arguing against this idea, just pointing out that
> the Fedora community should think through its broader consequences.
> 
> ___
> 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: Coming soon: Pagure service for dist-git

[Pierre-Yves Chibon]

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 but I also think there is a packaging issue at the
root of this question.

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


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

[Neal Gompa]

On Fri, Jul 7, 2017 at 10:24 AM, Jaroslav Reznik  wrote:
> = System Wide Change: Reduce Initial Setup Redundancy =
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
>
> Change owner(s):
> * Michael Catanzaro 
>
> Currently there is a high level of redundancy between the Anaconda
> installer and gnome-initial-setup. This change aims to eliminate these
> redundancies and streamline the initial user experience in Fedora
> Workstation.
>
> == Detailed Description ==
> Firstly, please note that the effects of this change will be
> restricted to Fedora Workstation. We do not propose any changes that
> affect alternative Fedora installers (e.g. Calamares) or initial setup
> tools (e.g. the initial-setup package, not to be confused with
> gnome-initial-setup).
>
> A few years ago, Fedora Workstation developers discussed with Anaconda
> developers the redundancy between many Anaconda settings and
> gnome-initial-setup. The Anaconda developers responded by added a
> configuration file mechanism, /etc/sysconfig/anaconda, which can be
> used to suppress Anaconda spokes if written before Anaconda runs. This
> file is also written by Anaconda to tell the initial-setup tool which
> Anaconda spokes the user has visited, so that the initial-setup tool
> can suppress specific spokes. Although this functionality has existed
> for some time now, the Workstation developers until now failed to
> follow up and begin using it. We now intend to make use of this
> functionality to suppress Anaconda spokes that are redundant with
> gnome-initial-setup. Meanwhile, our friends at Endless OS have added a
> similar configuration file for gnome-initial-setup that allows us to
> suppress some configuration that is best handled in Anaconda. Below,
> we discuss what we plan to do with specific settings.
>
> Language and Keyboard Layout
>
> Although we do not propose it at this time, language and keyboard
> layout selection should be presented to the user *before* entering the
> live session, as it is currently too difficult for users to change
> these settings unless they are already familiar with Fedora, and --
> unless you speak English and use a US keyboard -- these settings must
> be changed for the live session to be usable. Both Anaconda and
> gnome-initial-setup are too late for configuring these settings. (An
> exception would be for netinstalls of Fedora Workstation, where
> Anaconda is the best place for this configuration.) In the meantime,
> until we have a way to prompt users for these settings earlier than
> Anaconda, these panels should be removed from gnome-initial-setup,
> because Anaconda is clearly a better place than gnome-initial-setup
> for this configuration. (This would affect gnome-initial-setup when
> creating the first user account. Additional user accounts created
> later would still receive these panels in gnome-initial-setup.)
>
> Time and Date
>
> We want to remove the time and date spoke from Anaconda, since it is
> largely redundant with the timezone page in gnome-initial-setup.
> However, it might be necessary to remove this page from
> gnome-initial-setup instead, as previously there have been technical
> concerns raised regarding the necessity of configuring the system
> clock before running the installer. This choice will be based on
> technical feedback from the Fedora developer community.
>
> Network
>
> We will remove the network configuration spoke from Anaconda.
> Currently this spoke only allows configuring the system hostname, but
> it places restrictions on the possible characters in the hostname that
> do not match the restrictions used by Fedora Workstation. Fedora
> Workstation uses systemd-hostnamed to allow "pretty" hostnames with
> Unicode characters and spaces, which we expect to be displayed
> properly and consistently in the user interface, but the Anaconda
> configuration does not follow this pattern. Additionally, exposing the
> hostname as network configuration is confusing. We may consider adding
> a simpler "Computer Name" setting that allows "pretty" characters and
> is not presented as a networking setting in the future, but it does
> not seem necessary to prompt the user to set a hostname at all.
>
> Note: this applies only to USB install, obviously not to netinstall.
> We will need some way to differentiate between the two when writing
> the Anaconda configuration file.
>
> User Account
>
> Currently, users have the option of creating the initial user account
> in Anaconda, or not. Anaconda does not require this if the user sets a
> root password. Users who do not create a user account in Anaconda are
> required to create a user account later, by gnome-initial-setup. This
> means we currently have two different ways of creating the first user
> account in Workstation, with (potentially) two different sets of bugs.
> Since Anaconda allows configuring whether the initial user is added to
> the wheel group, it also 

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-07 16:24 GMT+02:00 Jaroslav Reznik :
> = System Wide Change: Reduce Initial Setup Redundancy =
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
>
> Change owner(s):
> * Michael Catanzaro 
>
> Currently there is a high level of redundancy between the Anaconda
> installer and gnome-initial-setup. This change aims to eliminate these
> redundancies and streamline the initial user experience in Fedora
> Workstation.
>
> == Detailed Description ==
> Firstly, please note that the effects of this change will be
> restricted to Fedora Workstation. We do not propose any changes that
> affect alternative Fedora installers (e.g. Calamares) or initial setup
> tools (e.g. the initial-setup package, not to be confused with
> gnome-initial-setup).
>
> A few years ago, Fedora Workstation developers discussed with Anaconda
> developers the redundancy between many Anaconda settings and
> gnome-initial-setup. The Anaconda developers responded by added a
> configuration file mechanism, /etc/sysconfig/anaconda, which can be
> used to suppress Anaconda spokes if written before Anaconda runs. This
> file is also written by Anaconda to tell the initial-setup tool which
> Anaconda spokes the user has visited, so that the initial-setup tool
> can suppress specific spokes. Although this functionality has existed
> for some time now, the Workstation developers until now failed to
> follow up and begin using it. We now intend to make use of this
> functionality to suppress Anaconda spokes that are redundant with
> gnome-initial-setup. Meanwhile, our friends at Endless OS have added a
> similar configuration file for gnome-initial-setup that allows us to
> suppress some configuration that is best handled in Anaconda. Below,
> we discuss what we plan to do with specific settings.
>
> Language and Keyboard Layout
>
> Although we do not propose it at this time, language and keyboard
> layout selection should be presented to the user *before* entering the
> live session, as it is currently too difficult for users to change
> these settings unless they are already familiar with Fedora, and --
> unless you speak English and use a US keyboard -- these settings must
> be changed for the live session to be usable. Both Anaconda and
> gnome-initial-setup are too late for configuring these settings. (An
> exception would be for netinstalls of Fedora Workstation, where
> Anaconda is the best place for this configuration.) In the meantime,
> until we have a way to prompt users for these settings earlier than
> Anaconda, these panels should be removed from gnome-initial-setup,
> because Anaconda is clearly a better place than gnome-initial-setup
> for this configuration. (This would affect gnome-initial-setup when
> creating the first user account. Additional user accounts created
> later would still receive these panels in gnome-initial-setup.)
>
> Time and Date
>
> We want to remove the time and date spoke from Anaconda, since it is
> largely redundant with the timezone page in gnome-initial-setup.
> However, it might be necessary to remove this page from
> gnome-initial-setup instead, as previously there have been technical
> concerns raised regarding the necessity of configuring the system
> clock before running the installer. This choice will be based on
> technical feedback from the Fedora developer community.
>
> Network
>
> We will remove the network configuration spoke from Anaconda.
> Currently this spoke only allows configuring the system hostname, but
> it places restrictions on the possible characters in the hostname that
> do not match the restrictions used by Fedora Workstation. Fedora
> Workstation uses systemd-hostnamed to allow "pretty" hostnames with
> Unicode characters and spaces, which we expect to be displayed
> properly and consistently in the user interface, but the Anaconda
> configuration does not follow this pattern. Additionally, exposing the
> hostname as network configuration is confusing. We may consider adding
> a simpler "Computer Name" setting that allows "pretty" characters and
> is not presented as a networking setting in the future, but it does
> not seem necessary to prompt the user to set a hostname at all.
>
> Note: this applies only to USB install, obviously not to netinstall.
> We will need some way to differentiate between the two when writing
> the Anaconda configuration file.
>
> User Account
>
> Currently, users have the option of creating the initial user account
> in Anaconda, or not. Anaconda does not require this if the user sets a
> root password. Users who do not create a user account in Anaconda are
> required to create a user account later, by gnome-initial-setup. This
> means we currently have two different ways of creating the first user
> account in Workstation, with (potentially) two different sets of bugs.
> Since Anaconda allows configuring whether the initial user is added to
> the wheel group, it also means some 

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Przemek Klosowski]

On 07/06/2017 11:05 AM, Jaroslav Reznik wrote:

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.


I do recognize that the containerization trend solves enough problems to 
be an attractive and perhaps inevitable development. My concern is more 
from the Fedora governance side: given that Fedora is historically a 
coherent RPM-based distribution, the containerization has an opportunity 
cost, in at least two ways:


- it could distract already overworked package maintainers from properly 
coordinating ("I don't have time to deal with those dependencies, I will 
just wrap the stuff I need into a flatpack and have a beer and a movie")


- it could distract users from demanding a well-put-together base ("I 
don't have time to chase and report this bug; I will just install that 
flatpack").


I do appreciate that if there are technical solutions to the downsides 
of containerization (security lifecycle, combinatorial divergence, 
etc.), it may end up replacing the package-based distribution model, but 
I think it's too early to declare such change. So, from the point of 
view of Fedora's available resources, are  the benefits to Fedora 
compelling enough to justify this project?


Please note that I am not arguing against this idea, just pointing out 
that the Fedora community should think through its broader consequences.


___
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

[Adam Williamson]

On Mon, 2017-07-10 at 10:53 -0500, Michael Catanzaro wrote:
> My suggestion is some sort of debug option for Anaconda that would 
> allow QA to set a root password when needed to investigate something 
> going wrong, or for OpenQA. It could even allow visiting arbitrary 
> Anaconda spokes.

We really want to keep the delta between what openQA does and what real
people do as small as possible. The entire point of openQA testing is
to test the bits we('re going to) ship, exactly as they will really be
used by real people. The danger is obvious: what if there's a bug in
anaconda which doesn't show up when it's run in debug mode? The tests
won't catch it...
-- 
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

[Kamil Paral]

On Mon, Jul 10, 2017 at 5:53 PM, Michael Catanzaro  wrote:

> OK, I see the problem.
>
> On the one hand, systemd needs fixed, as disabled root account is already
> a popular pattern on the largest Linux distro out there. This is an issue
> for rescue prompts too.


That would be great.


> But it's true that doesn't help the case where there is no user account at
> all.
>
> One can reboot into Live environment and mount the disks, but that's
>> tedious, and most importantly, it requires a reboot, so we lose the
>> information about the running system (e.g. which process is stuck in a
>> loop). Also, I believe OpenQA uses pre-created root account in anaconda to
>> switch to tty2 and upload any error logs in case of any troubles, in a
>> fully automated way. So it's not just manual testing affected.
>>
>> Thoughts on how to resolve that? It seems we need at least the root
>> password option kept.
>>
>
> My suggestion is some sort of debug option for Anaconda that would allow
> QA to set a root password when needed to investigate something going wrong,
> or for OpenQA. It could even allow visiting arbitrary Anaconda spokes.
> That's already possible if you edit /etc/sysconfig/anaconda before running
> anaconda, which is admittedly one more annoying step that you'd have to
> follow before starting Anaconda in order to debug the problem, but it
> works. OpenQA could also do that, though that's not superb as then OpenQA
> is testing its own special configuration.
>

That's the problem. We want to test *the very same code* the user runs. If
we edit a config file or provide a cmdline argument, we deviate from that
and test a different codepath. It might be a minor change, but the purpose
here is still test exactly the same as experienced by the user. Only that
way we can be sure the composes really work as expected. That's also one of
the reasons we use OpenQA (simulating real user input via keyboard and
mouse) instead of e.g. modifying the anaconda environment and using e.g.
dogtail to control the GUI.

If you're completely convinced that those options need to go away, we'll
have to rethink our goals. But we'd definitely prefer to continue testing
the unaltered environment.

Thinking more about it, specifically for OpenQA, I guess we could do
something like switch to tty2 once we detect "quit" button is active, and
run a command to set root password in the mounted new filesystem. Then
switch back and reboot the machine. That doesn't really modify the
installer codepath and ensures root is reachable. It's a bit annoying for
manually installs, but those are not that important (and for those, we
could use the debug option to show the spokes, when we know we're trying to
reproduce a specific problem).

Adam, wdyt?
___
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

[Adam Miller]

On Sat, Jul 8, 2017 at 10:24 AM, Ville Skyttä  wrote:
>
>
> 7.7.2017 20.45 "Jason L Tibbitts III"  kirjoitti:
>
>
> I would argue that it doesn't remove the ability, but that it does make
> it more difficult to do in an automated fashion.  Basically you can see
> that something has a bundled library but then you need to do manual
> inspection to go further.
>
>
> I think the versioning isn't worth much at all.
>
> If the bundled version corresponds to an upstream release to an extent that
> it can be called that version, and checks like the discussed one could be
> skipped just by looking at the version label, then it must be practically
> the same. So why is it bundled in the first place?
>
> On the other hand if there is a "good" reason it is bundled, that reason
> quite probably is that it is a modified version. So it's different than the
> upstream one, and thus knowledge whether an upstream release is vulnerable
> or not cannot be just assumed based on the version label a packager has
> attached to it. It needs to be checked anyway.
>

The main motivation for bundling as of late is golang[0], it's
extremely common out in the community for software to pull in
"Vendored" libraries even if they are exact copies of remote upstreams
(this is common with tools like godep[1]) because golang is statically
compiled by default (you can dynamically link with gcc-go and I
*think* recent releases of cgo but I've yet to find a golang project
that officially uses or endorses it's use). It's also extremely
painful to unbundle these as some more popular software written in
golang such as docker[2], kubernetes[3], and openshift[4] have upwards
of 100 bundled libs (over 1000 for OpenShift).

-AdamM

[0] - https://golang.org/
[1] - https://github.com/tools/godep
[2] - http://pkgs.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec
[3] - 
http://pkgs.fedoraproject.org/cgit/rpms/kubernetes.git/tree/kubernetes.spec
[4] - http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec

>
> ___
> 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: Bundled Provides Libraries and Versioning

[Adam Miller]

On Sun, Jul 9, 2017 at 5:36 PM, Kevin Kofler  wrote:
> Adam Miller wrote:
>> In today's FESCo meeting we discussed the fact that there are many
>> RPMs currently in Fedora (a reported 244 in Rawhide currently) that
>> are defining a `Provides: bundled() = ` but excluding
>> the version completely[0][1]. This removes that ability to properly
>> perform source code auditing and security vulnerability tracking.
>>
>> My question to the Fedora Contributor Community is, how should we
>> handle this? Is this something that should just simply be fixed by the
>> packages currently violating the Guidelines, should the Guidelines be
>> altered in a way that makes this easier to deal with for Packagers but
>> also provides what is needed for auditing and vulnerability tracking,
>> or is there simply clarification needed by what is required in the
>>  field?
>
> A version number may not even exist at all. Not all code that people copy is
> a library with a version number. Copylibs often don't bother doing releases
> because everyone just embeds it as a git submodule or checks out some random
> revision to copy into their own SCM. Hence, it is not realistic to require a
> version number.

So should we just stop requiring any RPMs be versioned since it's not
realistic to require a version number?

-AdamM

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

[Przemek Klosowski]

On 07/10/2017 09:16 AM, Jos Vos wrote:

On Mon, Jul 10, 2017 at 02:30:59PM +0200, Pierre-Yves Chibon wrote:


Oups, that was meant to be: On which side?

LDBM was many factors faster than SQLite.  No concrete figures,
it was a year ago or so when we decided to go for LMDB (still
a product in development...).  I had attended some talk from
Howard Chu (the author) about LMDB and knew quite soon it was
the way to go.

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 don't doubt your conclusions, but I keep being impressed with 
sqlite---one of my little projects grew to 500MB of data, and it is 
chugging along snappily, to my pleasant surprise. Caveat: I am no 
database guru, just a casual user.


___
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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 10, 2017 at 04:24:06PM +0200, Pierre-Yves Chibon wrote:
> On Mon, Jul 10, 2017 at 02:15:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
> > > On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > > On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> > > >> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> > > >>  wrote:
> > > >> > 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. So to update 
> > > >> > the
> > > >> > description, simply update the package in rawhide.
> > > >> >
> > > >> > You can then simply complement these information with a README file.
> > > >>
> > > >> +1 that looks much better IMO
> > > >
> > > > +1 too, that looks much better.
> > > >
> > > > The icons/links at the bottom look useful, but "Packages" is cryptic
> > > > though — everything is about "packages" in this context.
> > > 
> > > They map to the same as the ones say here
> > > https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
> > 
> > Right. My point is that the icon description shouldn't just be "packages"
> > — it should be something which is legible to outside casual contributors.
> > Maybe "Fedora package administration".
> 
> The `package` app is called `fedora-packages` lives at: 
> https://apps.fedoraproject.org/packages/
> and is meant to be a place for anyone (contributor and non-contributor) to 
> find
> information about the packages in Fedora.
> It is not an admin interface, you cannot login in there.
Oh, I misunderstood what Peter wrote.

> I am most definitively open to rename that link, but I lack a better word.

"Fedora package status overview"?

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

[Michael Catanzaro]

On Mon, Jul 10, 2017 at 9:27 AM, Kamil Paral  wrote:
So if I read correctly, on the first boot the installed system will 
have no user account and no root password.


Yup.

That might be very inconvenient for QA. If anything goes wrong during 
the first boot (and it often does during development), we need to be 
able to log in on TTY2+. Without the ability to create an account 
beforehand, that's not possible. Rebooting into runlevel 1 is also 
not possible without root password (it's required by systemd).


OK, I see the problem.

On the one hand, systemd needs fixed, as disabled root account is 
already a popular pattern on the largest Linux distro out there. This 
is an issue for rescue prompts too. But it's true that doesn't help the 
case where there is no user account at all.


One can reboot into Live environment and mount the disks, but that's 
tedious, and most importantly, it requires a reboot, so we lose the 
information about the running system (e.g. which process is stuck in 
a loop). Also, I believe OpenQA uses pre-created root account in 
anaconda to switch to tty2 and upload any error logs in case of any 
troubles, in a fully automated way. So it's not just manual testing 
affected.


Thoughts on how to resolve that? It seems we need at least the root 
password option kept.


My suggestion is some sort of debug option for Anaconda that would 
allow QA to set a root password when needed to investigate something 
going wrong, or for OpenQA. It could even allow visiting arbitrary 
Anaconda spokes. That's already possible if you edit 
/etc/sysconfig/anaconda before running anaconda, which is admittedly 
one more annoying step that you'd have to follow before starting 
Anaconda in order to debug the problem, but it works. OpenQA could also 
do that, though that's not superb as then OpenQA is testing its own 
special configuration.


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

Fedora Rawhide-20170710.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: 22/137 (x86_64), 1/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170709.n.0):

ID: 119222  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/119222
ID: 119226  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/119226
ID: 119241  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/119241
ID: 119244  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119244
ID: 119263  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/119263
ID: 119276  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/119276
ID: 119281  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/119281

Old failures (same test failed in Rawhide-20170709.n.0):

ID: 119194  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/119194
ID: 119195  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/119195
ID: 119196  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/119196
ID: 119199  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/119199
ID: 119217  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/119217
ID: 119220  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/119220
ID: 119221  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/119221
ID: 119228  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/119228
ID: 119239  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/119239
ID: 119304  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/119304
ID: 119309  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/119309
ID: 119311  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/119311
ID: 119312  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/119312
ID: 119316  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/119316
ID: 119317  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/119317
ID: 119318  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/119318
ID: 119339  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/119339

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

New soft failures (same test did not soft fail in Rawhide-20170709.n.0):

ID: 119283  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/119283
ID: 119299  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/119299
ID: 119335  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/119335

Old soft failures (same test soft failed in Rawhide-20170709.n.0):

ID: 119184  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/119184
ID: 119185  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119185
ID: 119186  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/119186
ID: 119187  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119187
ID: 119204  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/119204
ID: 119206  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/119206
ID: 119207  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/119207
ID: 119208  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119208
ID: 119242  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/119242
ID: 119252  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/119252
ID: 119253  Test: x86_64 universal 

[EPEL-devel] karma wanted for epel-release-7-10

[Kevin Fenzi]

Greetings. 

I would love it if some folks could test: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-eb495217ca

This update changes links from:

mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7=$basearch

to

metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7=$basearch

Yum should work fine with either, but dnf needs the change to work. 

So, both yum and dnf testing welcome. :)

kevin




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

Re: Using ndb in RPM

[Florian Weimer]

* Jos Vos:

> Hi,
>
> On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote:
>
>> The web page has:
>> 
>>Improvements and stabilization of "ndb" (New RPM DB Format database
>>format)
>>
>> [...]
>> 
>> The problem is that "NDB" is a custom homebrew database invented in
>> the RPM codebase.  I agree that because of licensing problems we need
>> to move away from Berkeley DB, but why not switch to the obvious,
>> bulletproof choice - Sqlite?
>
> SQLite is is totally different piece of cake (RDBMS vs. key/value).

But it's already part of the base system anyway.

> Why not use LMDB?  It's the replacement for BerkeleyDB in OpenLDAP.
>
> http://www.lmdb.tech/doc/

This was discussed before:

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

I don't know if LMDB upstream addressed the limitations mentioned in
the bug.
___
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 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?

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

I don't think it is based on the link above.

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


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

[Pierre-Yves Chibon]

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.


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

Re: Fedora rawhide compose report: 20170708.n.0 changes

[Alexander Bokovoy]

On ma, 10 heinä 2017, Stephen Gallagher wrote:

On Mon, Jul 10, 2017 at 9:53 AM Tomasz Torcz  wrote:


On Mon, Jul 10, 2017 at 03:30:02PM +0300, Alexander Bokovoy wrote:
> On la, 08 heinä 2017, Fedora Rawhide Report wrote:
> > [freeipa]
> > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires
libsmbldap.so.0()(64bit)
> > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires
libsmbldap.so.0(SMBLDAP_0)(64bit)
> > [freeipa]
> > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires
libsmbldap.so.0()(64bit)
> > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires
libsmbldap.so.0(SMBLDAP_0)(64bit)
> There seems to be a consistent crash in jvm execution on ppc64le which
> prevents me from applying fixes to freeipa.
> See, for example,
https://koji.fedoraproject.org/koji/taskinfo?taskID=20438824 -- this is a
third
> build in a row where all I get is a crash in jvm when compiling
> a javascript code with rhino:
> ...
> make[5]: Entering directory
'/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> ./../../util/make-ui.sh
> /builddir/build/BUILD/freeipa-4.5.2/install/ui/util/build.sh: line 36:
18474 Segmentation fault  (core dumped) $RHINO $DIR/build/build.js
baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js
> make[5]: *** [Makefile:612: app.js] Error 139
> make[5]: Leaving directory
'/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> make[4]: *** [Makefile:463: all-recursive] Error 1
>
> the latter excerpt is from
https://kojipkgs.fedoraproject.org//work/tasks/8844/20438844/build.log

  It has affected collectd, too:

https://koji.fedoraproject.org/koji/taskinfo?taskID=20381469




My suspicion is that JVM may be hitting
https://bugzilla.redhat.com/show_bug.cgi?id=1467526 which causes segfaults
on ppc64le.

I confirmed that by producing a stacktrace of a java run as part of
freeipa build on ppc64le machine with rawhide mock environment. The
stacktrace is provided as part of that bugzilla.

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

[Miroslav Suchý]

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.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Disable cairo-gl backend in F27

[Mamoru TASAKA]

Hello:

Adam Jackson wrote on 07/06/2017 01:48 AM:

Apologies that this is just after the system-wide change deadline
(thanks for putting that on a holiday btw), but I hadn't had a chance
to dig into this before now and I think it's fairly low impact.

Cairo's OpenGL backend is not especially well maintained or widely
used, and cairo gets linked into literally every gtk process on the
system, so it's a bit expensive to have libGL loaded 80 times and never
used. As far as I can work out we enabled the backend in 2012-ish
because some of the wayland demos wanted it, but they no longer do.

Indeed the API itself does not seem to have very many users in F26:




./rubygem-cairo-1.15.9-1.fc26.x86_64/usr/lib64/gems/ruby/cairo-1.15.9/cairo.so
  U cairo_gl_device_set_thread_aware
  U cairo_gl_surface_create_for_texture
  U cairo_gl_surface_get_height
  U cairo_gl_surface_get_width



I'm not aware of any ruby gems that explicitly require cairo-gl to
work, but I also don't know how i'd even begin to search for that. I
also haven't checked this against any external repositories yet.


While I may be missing something, I don't think current Fedora package
needs ruby cairo-gl bindings.
Also, ruby-cairo gem does not have examples for cairo-gl surface nor have
test suite for that, so I guess the ruby-cairo upstream does not care.

Regards,
Mamoru

___
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

[Kamil Paral]

On Fri, Jul 7, 2017 at 4:24 PM, Jaroslav Reznik  wrote:

> User Account
>
> Currently, users have the option of creating the initial user account
> in Anaconda, or not. Anaconda does not require this if the user sets a
> root password. Users who do not create a user account in Anaconda are
> required to create a user account later, by gnome-initial-setup. This
> means we currently have two different ways of creating the first user
> account in Workstation, with (potentially) two different sets of bugs.
> Since Anaconda allows configuring whether the initial user is added to
> the wheel group, it also means some initial users will be in wheel and
> others will not. We will remove the user account creation spoke in
> Anaconda. All users will create the first user account using
> gnome-initial-setup, and all initial users will be added to the wheel
> group. Of course, this can be easily changed after installation if
> desired.
>
> Root Account
>
> Currently, users have the option of setting a root password in
> Anaconda, or not. Anaconda does not require this if the user creates
> an initial user account and selects the option to add it to the wheel
> group. We will remove the root password creation spoke. All
> Workstation installs will have no root password set by default, as in
> Ubuntu. Having a root password is not useful for nontechnical users,
> and it is confusing to ask users to create multiple passwords. Because
> the initial user created by gnome-initial-setup will be added to the
> wheel group, all administrative functions will continue to be
> available within the desktop environment via Polkit. Additionally, the
> initial user will have sudo access to run commands as root. Of course,
> a root password can be set after installation using `sudo passwd`.
>



So if I read correctly, on the first boot the installed system will have no
user account and no root password. That might be very inconvenient for QA.
If anything goes wrong during the first boot (and it often does during
development), we need to be able to log in on TTY2+. Without the ability to
create an account beforehand, that's not possible. Rebooting into runlevel
1 is also not possible without root password (it's required by systemd).
One can reboot into Live environment and mount the disks, but that's
tedious, and most importantly, it requires a reboot, so we lose the
information about the running system (e.g. which process is stuck in a
loop). Also, I believe OpenQA uses pre-created root account in anaconda to
switch to tty2 and upload any error logs in case of any troubles, in a
fully automated way. So it's not just manual testing affected.

Thoughts on how to resolve that? It seems we need at least the root
password option kept.
___
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

[Pierre-Yves Chibon]

On Mon, Jul 10, 2017 at 02:15:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
> > On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> > >> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> > >>  wrote:
> > >> > 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. So to update the
> > >> > description, simply update the package in rawhide.
> > >> >
> > >> > You can then simply complement these information with a README file.
> > >>
> > >> +1 that looks much better IMO
> > >
> > > +1 too, that looks much better.
> > >
> > > The icons/links at the bottom look useful, but "Packages" is cryptic
> > > though — everything is about "packages" in this context.
> > 
> > They map to the same as the ones say here
> > https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
> 
> Right. My point is that the icon description shouldn't just be "packages"
> — it should be something which is legible to outside casual contributors.
> Maybe "Fedora package administration".

The `package` app is called `fedora-packages` lives at: 
https://apps.fedoraproject.org/packages/
and is meant to be a place for anyone (contributor and non-contributor) to find
information about the packages in Fedora.
It is not an admin interface, you cannot login in there.

I am most definitively open to rename that link, but I lack a better word.


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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 10, 2017 at 02:46:27PM +0100, Peter Robinson wrote:
> On Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> >> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
> >>  wrote:
> >> > 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. So to update the
> >> > description, simply update the package in rawhide.
> >> >
> >> > You can then simply complement these information with a README file.
> >>
> >> +1 that looks much better IMO
> >
> > +1 too, that looks much better.
> >
> > The icons/links at the bottom look useful, but "Packages" is cryptic
> > though — everything is about "packages" in this context.
> 
> They map to the same as the ones say here
> https://admin.fedoraproject.org/pkgdb/package/rpms/neard/

Right. My point is that the icon description shouldn't just be "packages"
— it should be something which is legible to outside casual contributors.
Maybe "Fedora package administration".

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

Re: Fedora rawhide compose report: 20170708.n.0 changes

[Stephen Gallagher]

On Mon, Jul 10, 2017 at 9:53 AM Tomasz Torcz  wrote:

> On Mon, Jul 10, 2017 at 03:30:02PM +0300, Alexander Bokovoy wrote:
> > On la, 08 heinä 2017, Fedora Rawhide Report wrote:
> > > [freeipa]
> > > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires
> libsmbldap.so.0()(64bit)
> > > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires
> libsmbldap.so.0(SMBLDAP_0)(64bit)
> > > [freeipa]
> > > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires
> libsmbldap.so.0()(64bit)
> > > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires
> libsmbldap.so.0(SMBLDAP_0)(64bit)
> > There seems to be a consistent crash in jvm execution on ppc64le which
> > prevents me from applying fixes to freeipa.
> > See, for example,
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20438824 -- this is a
> third
> > build in a row where all I get is a crash in jvm when compiling
> > a javascript code with rhino:
> > ...
> > make[5]: Entering directory
> '/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> > ./../../util/make-ui.sh
> > /builddir/build/BUILD/freeipa-4.5.2/install/ui/util/build.sh: line 36:
> 18474 Segmentation fault  (core dumped) $RHINO $DIR/build/build.js
> baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js
> > make[5]: *** [Makefile:612: app.js] Error 139
> > make[5]: Leaving directory
> '/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> > make[4]: *** [Makefile:463: all-recursive] Error 1
> >
> > the latter excerpt is from
> https://kojipkgs.fedoraproject.org//work/tasks/8844/20438844/build.log
>
>   It has affected collectd, too:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20381469
>
>

My suspicion is that JVM may be hitting
https://bugzilla.redhat.com/show_bug.cgi?id=1467526 which causes segfaults
on ppc64le.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20170708.n.0 changes

[Tomasz Torcz]

On Mon, Jul 10, 2017 at 03:30:02PM +0300, Alexander Bokovoy wrote:
> On la, 08 heinä 2017, Fedora Rawhide Report wrote:
> > [freeipa]
> > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires 
> > libsmbldap.so.0()(64bit)
> > freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires 
> > libsmbldap.so.0(SMBLDAP_0)(64bit)
> > [freeipa]
> > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires 
> > libsmbldap.so.0()(64bit)
> > freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires 
> > libsmbldap.so.0(SMBLDAP_0)(64bit)
> There seems to be a consistent crash in jvm execution on ppc64le which
> prevents me from applying fixes to freeipa.
> See, for example, 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=20438824 -- this is a 
> third
> build in a row where all I get is a crash in jvm when compiling
> a javascript code with rhino:
> ...
> make[5]: Entering directory 
> '/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> ./../../util/make-ui.sh
> /builddir/build/BUILD/freeipa-4.5.2/install/ui/util/build.sh: line 36: 18474 
> Segmentation fault  (core dumped) $RHINO $DIR/build/build.js 
> baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js
> make[5]: *** [Makefile:612: app.js] Error 139
> make[5]: Leaving directory 
> '/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
> make[4]: *** [Makefile:463: all-recursive] Error 1
> 
> the latter excerpt is from 
> https://kojipkgs.fedoraproject.org//work/tasks/8844/20438844/build.log

  It has affected collectd, too:

https://koji.fedoraproject.org/koji/taskinfo?taskID=20381469

-- 
Tomasz TorczTo co nierealne -- tutaj jest normalne.
xmpp: zdzich...@chrome.pl  Ziomale na życie mają tu patenty specjalne.
___
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 Mon, Jul 10, 2017 at 2:38 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
>> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
>>  wrote:
>> > 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. So to update the
>> > description, simply update the package in rawhide.
>> >
>> > You can then simply complement these information with a README file.
>>
>> +1 that looks much better IMO
>
> +1 too, that looks much better.
>
> The icons/links at the bottom look useful, but "Packages" is cryptic
> though — everything is about "packages" in this context.

They map to the same as the ones say here
https://admin.fedoraproject.org/pkgdb/package/rpms/neard/
___
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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 10, 2017 at 01:21:53PM +0100, Peter Robinson wrote:
> On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
>  wrote:
> > 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. So to update the
> > description, simply update the package in rawhide.
> >
> > You can then simply complement these information with a README file.
> 
> +1 that looks much better IMO

+1 too, that looks much better.

The icons/links at the bottom look useful, but "Packages" is cryptic
though — everything is about "packages" in this context.

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

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On x86_64:
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Gtk3-WebKit

[buildsys]

perl-Gtk3-WebKit has broken dependencies in the rawhide tree:
On x86_64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-HTML-FormFu-MultiForm

[buildsys]

perl-HTML-FormFu-MultiForm has broken dependencies in the rawhide tree:
On x86_64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu

[buildsys]

perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-SDL

[buildsys]

perl-SDL has broken dependencies in the rawhide tree:
On x86_64:
perl-SDL-2.546-7.fc26.x86_64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.x86_64 requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-SDL-2.546-7.fc26.armv7hl requires libperl.so.5.24
perl-SDL-2.546-7.fc26.armv7hl requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-SDL-2.546-7.fc26.ppc64le requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64le requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-SDL-2.546-7.fc26.aarch64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.aarch64 requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-SDL-2.546-7.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64 requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-SDL-2.546-7.fc26.i686 requires libperl.so.5.24
perl-SDL-2.546-7.fc26.i686 requires perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-Module-Build-SDL-2.546-7.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Module-Build-SDL-2.546-7.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Module-Build-SDL-2.546-7.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Module-Build-SDL-2.546-7.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Module-Build-SDL-2.546-7.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Module-Build-SDL-2.546-7.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Algorithm-CurveFit

[buildsys]

perl-Algorithm-CurveFit has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-PDL-Graphics-PLplot

[buildsys]

perl-PDL-Graphics-PLplot has broken dependencies in the rawhide tree:
On aarch64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Re: Using ndb in RPM

[Jos Vos]

On Mon, Jul 10, 2017 at 02:30:59PM +0200, Pierre-Yves Chibon wrote:

> Oups, that was meant to be: On which side?

LDBM was many factors faster than SQLite.  No concrete figures,
it was a year ago or so when we decided to go for LMDB (still
a product in development...).  I had attended some talk from
Howard Chu (the author) about LMDB and knew quite soon it was
the way to go.

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

[Pierre-Yves Chibon]

On Mon, Jul 10, 2017 at 02:27:38PM +0200, Pierre-Yves Chibon wrote:
> On Mon, Jul 10, 2017 at 01:51:57PM +0200, Jos Vos wrote:
> > On Mon, Jul 10, 2017 at 02:44:31PM +0300, Alek Paunov wrote:
> > 
> > > If you say:
> > > create table col1(key blob primary key, value blob) without rowid;/
> > > 
> > > you physically get no more/no less simple key/value store (given 30 more 
> > > lines of trivial code for implementing your favorite key/value lib 
> > > operations).
> > > 
> > > But you are right - sqlite is different piece of cake: sqlite has 
> > > powerful query language. Sqlite based backend gives the future advantage 
> > > that big chunk of the rpm code could be elegantly and declarative 
> > > offloaded to the query engine (with efficiency benefits as bonus).
> > 
> > I did performance tests to compare SQLite with LMDB for my own case here
> > (using key/value-like things) and the performance difference is *huge*.
> 
> How which side?

Oups, that was meant to be: On which side?

> Did you blog about your test and findings?
> 
> 
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20170708.n.0 changes

[Alexander Bokovoy]

On la, 08 heinä 2017, Fedora Rawhide Report wrote:

[freeipa]
freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires 
libsmbldap.so.0()(64bit)
freeipa-server-trust-ad-4.5.2-2.fc27.aarch64 requires 
libsmbldap.so.0(SMBLDAP_0)(64bit)
[freeipa]
freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires 
libsmbldap.so.0()(64bit)
freeipa-server-trust-ad-4.5.2-2.fc27.ppc64 requires 
libsmbldap.so.0(SMBLDAP_0)(64bit)

There seems to be a consistent crash in jvm execution on ppc64le which
prevents me from applying fixes to freeipa.
See, for example, https://koji.fedoraproject.org/koji/taskinfo?taskID=20438824 
-- this is a third
build in a row where all I get is a crash in jvm when compiling
a javascript code with rhino:
...
make[5]: Entering directory 
'/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
./../../util/make-ui.sh
/builddir/build/BUILD/freeipa-4.5.2/install/ui/util/build.sh: line 36: 18474 
Segmentation fault  (core dumped) $RHINO $DIR/build/build.js 
baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js
make[5]: *** [Makefile:612: app.js] Error 139
make[5]: Leaving directory 
'/builddir/build/BUILD/freeipa-4.5.2/install/ui/build/freeipa'
make[4]: *** [Makefile:463: all-recursive] Error 1

the latter excerpt is from 
https://kojipkgs.fedoraproject.org//work/tasks/8844/20438844/build.log
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM

[Pierre-Yves Chibon]

On Mon, Jul 10, 2017 at 01:51:57PM +0200, Jos Vos wrote:
> On Mon, Jul 10, 2017 at 02:44:31PM +0300, Alek Paunov wrote:
> 
> > If you say:
> > create table col1(key blob primary key, value blob) without rowid;/
> > 
> > you physically get no more/no less simple key/value store (given 30 more 
> > lines of trivial code for implementing your favorite key/value lib 
> > operations).
> > 
> > But you are right - sqlite is different piece of cake: sqlite has 
> > powerful query language. Sqlite based backend gives the future advantage 
> > that big chunk of the rpm code could be elegantly and declarative 
> > offloaded to the query engine (with efficiency benefits as bonus).
> 
> I did performance tests to compare SQLite with LMDB for my own case here
> (using key/value-like things) and the performance difference is *huge*.

How which side?

Did you blog about your test and findings?


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

[Bug 1469110] perl-Text-Fuzzy-0.26 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Text-Fuzzy-0.26-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=20440744

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1469112] New: perl-Term-ProgressBar-2.19 is available

[bugzilla]

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

Bug ID: 1469112
   Summary: perl-Term-ProgressBar-2.19 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Term-ProgressBar
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.19
Current version/release in rawhide: 2.18-3.fc27
URL: http://search.cpan.org/dist/Term-ProgressBar/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3375/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

[Peter Robinson]

On Mon, Jul 10, 2017 at 10:23 AM, Pierre-Yves Chibon
 wrote:
> 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. So to update the
> description, simply update the package in rawhide.
>
> You can then simply complement these information with a README file.

+1 that looks much better IMO
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1469110] perl-Text-Fuzzy-0.26 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1295798
  --> https://bugzilla.redhat.com/attachment.cgi?id=1295798=edit
[patch] Update to 0.26 (#1469110)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1469110] New: perl-Text-Fuzzy-0.26 is available

[bugzilla]

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

Bug ID: 1469110
   Summary: perl-Text-Fuzzy-0.26 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Text-Fuzzy
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.26
Current version/release in rawhide: 0.25-3.fc27
URL: http://search.cpan.org/dist/Text-Fuzzy/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/9583/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1467122] perl-Mojolicious-7.36 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Mojolicious-7.35 is|perl-Mojolicious-7.36 is
   |available   |available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 7.36
Current version/release in rawhide: 7.35-1.fc27
URL: http://mojolicio.us/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5966/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Bundled Provides Libraries and Versioning

[Bastien Nocera]

- Original Message -
> On Saturday, 08 July 2017 at 17:24, Ville Skyttä wrote:
> [...]
> > If the bundled version corresponds to an upstream release to an extent that
> > it can be called that version, and checks like the discussed one could be
> > skipped just by looking at the version label, then it must be practically
> > the same. So why is it bundled in the first place?
> 
> 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?
___
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]

On Mon, Jul 10, 2017 at 02:44:31PM +0300, Alek Paunov wrote:

> If you say:
> create table col1(key blob primary key, value blob) without rowid;/
> 
> you physically get no more/no less simple key/value store (given 30 more 
> lines of trivial code for implementing your favorite key/value lib 
> operations).
> 
> But you are right - sqlite is different piece of cake: sqlite has 
> powerful query language. Sqlite based backend gives the future advantage 
> that big chunk of the rpm code could be elegantly and declarative 
> offloaded to the query engine (with efficiency benefits as bonus).

I did performance tests to compare SQLite with LMDB for my own case here
(using key/value-like things) and the performance difference is *huge*.

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

[Alek Paunov]

On 2017-07-10 12:28, Jos Vos wrote:

Hi,

On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote:


The web page has:

Improvements and stabilization of "ndb" (New RPM DB Format database
format)

[...]

The problem is that "NDB" is a custom homebrew database invented in
the RPM codebase.  I agree that because of licensing problems we need
to move away from Berkeley DB, but why not switch to the obvious,
bulletproof choice - Sqlite?


Totally agree with Rich. If the problem with sqlite is the lack of SQL 
developers, I am highly motivated to work on all SQL queries needed for 
such backend, leveraging the whole bunch of fantastic features in recent 
sqlite.




SQLite is is totally different piece of cake (RDBMS vs. key/value).


If you say:
create table col1(key blob primary key, value blob) without rowid;/

you physically get no more/no less simple key/value store (given 30 more 
lines of trivial code for implementing your favorite key/value lib 
operations).


But you are right - sqlite is different piece of cake: sqlite has 
powerful query language. Sqlite based backend gives the future advantage 
that big chunk of the rpm code could be elegantly and declarative 
offloaded to the query engine (with efficiency benefits as bonus).


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

Wrote a new blog for OpenSource.Com on evolution of containers.

[Daniel Walsh]

https://opensource.com/article/17/7/how-linux-containers-evolved

If  you like it, please social Media this message out.



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

[Bug 1469031] Please update perl-Plack version

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

   Assignee|rc040...@freenet.de |emman...@seyman.fr



--- Comment #1 from Ralf Corsepius  ---
I do not use nor support EPEL.

May-be Emmanuel wants to look into this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Bundled Provides Libraries and Versioning

[Dominik 'Rathann' Mierzejewski]

On Saturday, 08 July 2017 at 17:24, Ville Skyttä wrote:
[...]
> If the bundled version corresponds to an upstream release to an extent that
> it can be called that version, and checks like the discussed one could be
> skipped just by looking at the version label, then it must be practically
> the same. So why is it bundled in the first place?

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

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: Using ndb in RPM (was: Re: F27 System Wide Change: RPM 4.14)

[Richard W.M. Jones]

On Mon, Jul 10, 2017 at 11:28:13AM +0200, Jos Vos wrote:
> Hi,
> 
> On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote:
> 
> > The web page has:
> > 
> >Improvements and stabilization of "ndb" (New RPM DB Format database
> >format)
> >
> > [...]
> > 
> > The problem is that "NDB" is a custom homebrew database invented in
> > the RPM codebase.  I agree that because of licensing problems we need
> > to move away from Berkeley DB, but why not switch to the obvious,
> > bulletproof choice - Sqlite?
> 
> SQLite is is totally different piece of cake (RDBMS vs. key/value).
> 
> Why not use LMDB?  It's the replacement for BerkeleyDB in OpenLDAP.
> 
> http://www.lmdb.tech/doc/
> 
> It's extremely fast...

TBH I'm not fussed about what specific technology is used as long as
it's not some homebrew thing, is battle-tested, and is reasonably
widely available with as few external dependencies as possible.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM (was: Re: F27 System Wide Change: RPM 4.14)

[Neal Gompa]

On Mon, Jul 10, 2017 at 4:14 AM, Richard W.M. Jones  wrote:
> On Fri, Jul 07, 2017 at 04:15:53PM +0200, Jaroslav Reznik wrote:
>> = System Wide Change: RPM 4.14 =
>> https://fedoraproject.org/wiki/Changes/RPM-4.14
>
> The web page has:
>
>Improvements and stabilization of "ndb" (New RPM DB Format database
>format)
> ...
>Changing database from bdb to ndb requires patching of some programs
>who read/expect /var/lib/rpm/Packages and other files directly
>without using librpm
>
> which were not included in this email.
>
> The problem is that "NDB" is a custom homebrew database invented in
> the RPM codebase.  I agree that because of licensing problems we need
> to move away from Berkeley DB, but why not switch to the obvious,
> bulletproof choice - Sqlite?
>
> Look at the all new nbd code here:
>
>   https://github.com/rpm-software-management/rpm/tree/master/lib/backend/ndb
>
> Inventing a new database including a new disk format and all new code
> is bound to cause problems with database corruption, incorrect
> database synchronization, incorrect handling of parallel queries, and
> a rich source of other bugs for a long time.
>
> Not to mention ‘ndb requires patching of some programs who read/expect
> /var/lib/rpm/Packages and other files directly without using librpm’ -
> this would still require changes, but they are much smaller if you're
> using sqlite.
>
> It was a bad upstream decision, but it's not too late to avoid it by
> sticking with BDB for now and using sqlite in the long run.
>

A long time ago, we did actually have a SQLite backend. It was removed
in RPM 4.9.0[1][2]. I'm not sure *why* it was removed.

[1]: http://rpm.org/wiki/Releases/4.9.0
[2]: 
https://github.com/rpm-software-management/rpm/commit/e2c217b4b76118e6dab9f8dfb3284bb4ddbe2b3e

On Mon, Jul 10, 2017 at 5:28 AM, Jos Vos  wrote:
> Hi,
>
> On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote:
>
>> The web page has:
>>
>>Improvements and stabilization of "ndb" (New RPM DB Format database
>>format)
>>
>> [...]
>>
>> The problem is that "NDB" is a custom homebrew database invented in
>> the RPM codebase.  I agree that because of licensing problems we need
>> to move away from Berkeley DB, but why not switch to the obvious,
>> bulletproof choice - Sqlite?
>
> SQLite is is totally different piece of cake (RDBMS vs. key/value).
>
> Why not use LMDB?  It's the replacement for BerkeleyDB in OpenLDAP.
>
> http://www.lmdb.tech/doc/
>
> It's extremely fast...
>

LMDB has been brought up in the past[3] as well as recently[4].

[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1086784
[4]: https://github.com/rpm-software-management/rpm/issues/128


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

[Bug 1468887] perl-Parse-ErrorString-Perl-0.27 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Parse-ErrorString-Perl
   ||-0.27-1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-07-10 06:44:27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Parse-ErrorString-Perl (master). "0.27 bump"

[notifications]

From be97941c6d6b314ce8700792f42bb091191d37c7 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 12:43:10 +0200
Subject: 0.27 bump

---
 .gitignore   | 1 +
 perl-Parse-ErrorString-Perl.spec | 7 +--
 sources  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index ec03b0d..3c74492 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Parse-ErrorString-Perl-0.11.tar.gz
 /Parse-ErrorString-Perl-0.22.tar.gz
 /Parse-ErrorString-Perl-0.24.tar.gz
 /Parse-ErrorString-Perl-0.26.tar.gz
+/Parse-ErrorString-Perl-0.27.tar.gz
diff --git a/perl-Parse-ErrorString-Perl.spec b/perl-Parse-ErrorString-Perl.spec
index fe0a9fb..2d30b50 100644
--- a/perl-Parse-ErrorString-Perl.spec
+++ b/perl-Parse-ErrorString-Perl.spec
@@ -1,5 +1,5 @@
 Name:   perl-Parse-ErrorString-Perl
-Version:0.26
+Version:0.27
 Release:1%{?dist}
 Summary:Module for parsing error messages
 License:GPL+ or Artistic
@@ -54,13 +54,16 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -delete
 make test
 
 %files
-%doc Changes
+%doc Changes README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 %{_bindir}/check_perldiag
 %{_mandir}/man1/check_perldiag.1.gz
 
 %changelog
+* Mon Jul 10 2017 Jitka Plesnikova  - 0.27-1
+- 0.27 bump
+
 * Mon Jun 26 2017 Jitka Plesnikova  - 0.26-1
 - 0.26 bump
 
diff --git a/sources b/sources
index 52a9a3d..afcfffa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Parse-ErrorString-Perl-0.26.tar.gz) = 
c62d68d1f44e0cba502c4022e9e345ca7c65391e8b2a43d69ef1d7fde1d3ebebd1deb25da738de1ad7a7d45730445a06a6e044df4e33062eb86f8579040b08b7
+SHA512 (Parse-ErrorString-Perl-0.27.tar.gz) = 
2111d3d130e7eeb754e11d6a20cd289be888fd384853d19000820363b8a2bb60f75db029cbf6646ec267ba5a9f25ddc596c335c41623cc07a82b12fce81a9800
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Parse-ErrorString-Perl.git/commit/?h=master=be97941c6d6b314ce8700792f42bb091191d37c7
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Parse-ErrorString-Perl-0.27.tar.gz for perl-Parse-ErrorString-Perl

[notifications]

2111d3d130e7eeb754e11d6a20cd289be888fd384853d19000820363b8a2bb60f75db029cbf6646ec267ba5a9f25ddc596c335c41623cc07a82b12fce81a9800
  Parse-ErrorString-Perl-0.27.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Parse-ErrorString-Perl/Parse-ErrorString-Perl-0.27.tar.gz/sha512/2111d3d130e7eeb754e11d6a20cd289be888fd384853d19000820363b8a2bb60f75db029cbf6646ec267ba5a9f25ddc596c335c41623cc07a82b12fce81a9800/Parse-ErrorString-Perl-0.27.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1468793] perl-SVG-2.78 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-SVG-2.78-1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-07-10 06:13:19



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-SVG (master). "2.78 bump"

[notifications]

From d40d985c7357050dd86cb5658b01e889c5b789ef Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 12:12:10 +0200
Subject: 2.78 bump

---
 .gitignore| 1 +
 perl-SVG.spec | 7 +--
 sources   | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9c5ae30..e372e15 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@ SVG-2.49.tar.gz
 /SVG-2.74.tar.gz
 /SVG-2.76.tar.gz
 /SVG-2.77.tar.gz
+/SVG-2.78.tar.gz
diff --git a/perl-SVG.spec b/perl-SVG.spec
index 53451f2..5377393 100644
--- a/perl-SVG.spec
+++ b/perl-SVG.spec
@@ -1,6 +1,6 @@
 Name:   perl-SVG
-Version:2.77
-Release:2%{?dist}
+Version:2.78
+Release:1%{?dist}
 Summary:An extension to generate stand-alone or inline SGV
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -64,6 +64,9 @@ make test
 
 
 %changelog
+* Mon Jul 10 2017 Jitka Plesnikova  - 2.78-1
+- 2.78 bump
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 2.77-2
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index a6e344a..7c87603 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (SVG-2.77.tar.gz) = 
ac8ffb274cd65250370a9949e4118b3e35c0c18ba1905c70b20bafa0190db96d0eea1007f2b5e355c07eba9a346d0f131556f31b072caf473ccdac18dfd6ee97
+SHA512 (SVG-2.78.tar.gz) = 
fc1642df78a66b1e5f477ffb0cf873c36454d5296f974f2f88b6e1b7fb80b0f79b91dd377e54d9bbaf014ea1ffc11ceebe69750056c6d20a76f79b5fabc49643
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-SVG.git/commit/?h=master=d40d985c7357050dd86cb5658b01e889c5b789ef
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded SVG-2.78.tar.gz for perl-SVG

[notifications]

fc1642df78a66b1e5f477ffb0cf873c36454d5296f974f2f88b6e1b7fb80b0f79b91dd377e54d9bbaf014ea1ffc11ceebe69750056c6d20a76f79b5fabc49643
  SVG-2.78.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-SVG/SVG-2.78.tar.gz/sha512/fc1642df78a66b1e5f477ffb0cf873c36454d5296f974f2f88b6e1b7fb80b0f79b91dd377e54d9bbaf014ea1ffc11ceebe69750056c6d20a76f79b5fabc49643/SVG-2.78.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1467459] perl-Code-TidyAll-0.60 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Code-TidyAll-0.61-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-58b49d8fe8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1468782] perl-Code-TidyAll-0.61 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Code-TidyAll-0.61-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-58b49d8fe8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1469031] New: Please update perl-Plack version

[bugzilla]

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

Bug ID: 1469031
   Summary: Please update perl-Plack version
   Product: Fedora EPEL
   Version: epel7
 Component: perl-Plack
  Assignee: rc040...@freenet.de
  Reporter: clem.ou...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, extras...@fedoraproject.org,
jose.p.oliveira@gmail.com, kwiz...@gmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rc040...@freenet.de



Hi,

for LemonLDAP::NG I need a more recent version of perl-Plack.

We currently have perl-Plack-1.0030-3.el7.noarch, and I would need at least
1.0033.


Thanks a lot for your help.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> Jaroslav Reznik wrote:
> > = System Wide Change: Graphical Applications as Flatpaks =
> > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> > 
> > Change owner(s):
> > * Owen Taylor 
> 
> This change is leaving several questions unanswered:
> 
> * As I understand it, those Flatpaks are going to be built from RPMs. Is the
> intent to ship both the original RPMs and the Flatpak or only the Flatpak
> (or is this going to depend on the individual package)? And if the former,
> are the shipped RPMs going to be the FHS-compliant version or the one
> relocated into Flatpak's proprietary prefix?
> 
> * What is the advantage of shipping Fedora distribution packages to Fedora
> users as Flatpaks? I see only drawbacks compared to RPM, because everything
> not included in the base runtime must be bundled, so we have all the usual
> issues of bundled libraries: larger downloads, more disk consumption, more
> RAM consumption (shared system libraries are also shared in RAM), slower and
> less efficient delivery of security fixes, FHS noncompliance, etc. And the
> portability argument is moot when we are talking about delivering Fedora
> software to Fedora users.

Why do we care about FHS compliance inside a Flatpak? And why would it be
slower to release security fixes?
 
> I strongly oppose this change.

You forgot the positive changes such as:
- sandboxing
- dogfooding and testing for the sandboxing technologies
- make it possible to create Flatpaks quicker for some more complicated apps
- developers not having to learn GPG to sign their releases
- more efficient update tracking than RPM (eg. no need to download 20 megs of
  metadata to know there's nothing to update)

There's plenty more depending on which part of the chain you'd be in.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1468782] perl-Code-TidyAll-0.61 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Code-TidyAll-0.61-1.fc
   ||27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Code-TidyAll (f26). "0.61 bump"

[notifications]

From 2a5c13239f42d55bcd4f711a6c621509381e5114 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 11:59:53 +0200
Subject: 0.61 bump

---
 .gitignore | 1 +
 perl-Code-TidyAll.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 61adc14..290370c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,4 @@
 /Code-TidyAll-0.58.tar.gz
 /Code-TidyAll-0.59.tar.gz
 /Code-TidyAll-0.60.tar.gz
+/Code-TidyAll-0.61.tar.gz
diff --git a/perl-Code-TidyAll.spec b/perl-Code-TidyAll.spec
index 27d92d2..c9327dd 100644
--- a/perl-Code-TidyAll.spec
+++ b/perl-Code-TidyAll.spec
@@ -1,5 +1,5 @@
 Name:   perl-Code-TidyAll
-Version:0.60
+Version:0.61
 Release:1%{?dist}
 Summary:Engine for tidyall, your all-in-one code tidier and validator
 # lib/Test/Code/TidyAll.pm: GPL+ or Artistic
@@ -123,6 +123,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 10 2017 Jitka Plesnikova  - 0.61-1
+- 0.61 bump
+
 * Tue Jul 04 2017 Jitka Plesnikova  - 0.60-1
 - 0.60 bump
 
diff --git a/sources b/sources
index 988ff81..7d3148c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Code-TidyAll-0.60.tar.gz) = 
d43b7b61c92557d9059c0478f38ab7126fd6945e322333ba53670894b18bf7fb04520c821c44c2969efbe95b3c55ae95801afe0a7045aa28192a6f887bdd9a3d
+SHA512 (Code-TidyAll-0.61.tar.gz) = 
4fb4eb50f2d8150149d4df682edee0db91e2f9277652fd98c57d7534b3a992cd7f070d25f80d9171eac67844a1a16b53f44b8689b86c35a28102e15562864ebf
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Code-TidyAll.git/commit/?h=f26=2a5c13239f42d55bcd4f711a6c621509381e5114
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Martin Kolman]

On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
> Jaroslav Reznik wrote:
> > = System Wide Change: Graphical Applications as Flatpaks =
> > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl
> > atpaks
> > 
> > Change owner(s):
> > * Owen Taylor 
> 
> This change is leaving several questions unanswered:
> 
> * As I understand it, those Flatpaks are going to be built from RPMs.
> Is the 
> intent to ship both the original RPMs and the Flatpak or only the
> Flatpak 
> (or is this going to depend on the individual package)? And if the
> former, 
> are the shipped RPMs going to be the FHS-compliant version or the
> one 
> relocated into Flatpak's proprietary prefix?
I can image Flatpak applications that are not available in Fedora as
RPMs (or as a RPM in COPR, etc.) that use Fedora RPMs for their
dependencies, possibly bundling the few missing dependencies on top.

> 
> * What is the advantage of shipping Fedora distribution packages to
> Fedora 
> users as Flatpaks? I see only drawbacks compared to RPM, because
> everything 
> not included in the base runtime must be bundled, so we have all the
> usual 
> issues of bundled libraries: larger downloads, more disk consumption,
> more 
> RAM consumption (shared system libraries are also shared in RAM),
> slower and 
> less efficient delivery of security fixes, FHS noncompliance, etc. 
I see quite a few:
- thanks to how runtimes work it should be possibly to install Flatpack
 applications to older/newer Fedora releases than the one where the
application originates from
- easy to use development versions without breaking the RPM installed
version of an application
- I guess it should be possibly to install multiple version of an
application in parallel (for testing, etc.)
- better sandboxing than RPM installed apps, possibly improving
security


> And the 
> portability argument is moot when we are talking about delivering
> Fedora 
> software to Fedora users.
I would still expect the resulting Flatpacks to work even on let's say
Ubuntu given how (AFAIK) the Flatpak runtimes work. So I don't think
this argument is moot.


> 
> I strongly oppose this change.
As I understand the change this is just an additional mechanism for
graphical application delivery - no one is taking away the normal RPM
based mechanism. So I don't think it makes sense to oppose an effort
that is just providing an additional mechanism to what we already have
now.

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

jplesnik pushed to perl-Code-TidyAll (master). "0.61 bump"

[notifications]

From fa3ce55d8e41073d992a0510593c25d7ab82d32b Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 11:59:53 +0200
Subject: 0.61 bump

---
 .gitignore | 1 +
 perl-Code-TidyAll.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 61adc14..290370c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,4 @@
 /Code-TidyAll-0.58.tar.gz
 /Code-TidyAll-0.59.tar.gz
 /Code-TidyAll-0.60.tar.gz
+/Code-TidyAll-0.61.tar.gz
diff --git a/perl-Code-TidyAll.spec b/perl-Code-TidyAll.spec
index 58742e2..efb85c6 100644
--- a/perl-Code-TidyAll.spec
+++ b/perl-Code-TidyAll.spec
@@ -1,5 +1,5 @@
 Name:   perl-Code-TidyAll
-Version:0.60
+Version:0.61
 Release:1%{?dist}
 Summary:Engine for tidyall, your all-in-one code tidier and validator
 # lib/Test/Code/TidyAll.pm: GPL+ or Artistic
@@ -123,6 +123,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 10 2017 Jitka Plesnikova  - 0.61-1
+- 0.61 bump
+
 * Tue Jul 04 2017 Jitka Plesnikova  - 0.60-1
 - 0.60 bump
 
diff --git a/sources b/sources
index 988ff81..7d3148c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Code-TidyAll-0.60.tar.gz) = 
d43b7b61c92557d9059c0478f38ab7126fd6945e322333ba53670894b18bf7fb04520c821c44c2969efbe95b3c55ae95801afe0a7045aa28192a6f887bdd9a3d
+SHA512 (Code-TidyAll-0.61.tar.gz) = 
4fb4eb50f2d8150149d4df682edee0db91e2f9277652fd98c57d7534b3a992cd7f070d25f80d9171eac67844a1a16b53f44b8689b86c35a28102e15562864ebf
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Code-TidyAll.git/commit/?h=master=fa3ce55d8e41073d992a0510593c25d7ab82d32b
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Code-TidyAll-0.61.tar.gz for perl-Code-TidyAll

[notifications]

4fb4eb50f2d8150149d4df682edee0db91e2f9277652fd98c57d7534b3a992cd7f070d25f80d9171eac67844a1a16b53f44b8689b86c35a28102e15562864ebf
  Code-TidyAll-0.61.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Code-TidyAll/Code-TidyAll-0.61.tar.gz/sha512/4fb4eb50f2d8150149d4df682edee0db91e2f9277652fd98c57d7534b3a992cd7f070d25f80d9171eac67844a1a16b53f44b8689b86c35a28102e15562864ebf/Code-TidyAll-0.61.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Exception-Class (master). "Update to 1.43 (..more)"

[notifications]

From 4352675533edd7ef0502ba232c8b17dab3f9782e Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Mon, 10 Jul 2017 10:35:24 +0100
Subject: Update to 1.43

- New upstream release 1.43
  - The full_message() method in Exception::Class::Base now calls message()
instead of accessing the object's hash key, which makes it easier to
override message() in a subclass (GH#11)
---
 .rpmlint  |  3 +++
 perl-Exception-Class.spec | 10 --
 sources   |  2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)
 create mode 100644 .rpmlint

diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..671ca8a
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,3 @@
+from Config import *
+
+addFilter("spelling-error %description -l en_US esque -> ")
diff --git a/perl-Exception-Class.spec b/perl-Exception-Class.spec
index 4d3a798..971802e 100644
--- a/perl-Exception-Class.spec
+++ b/perl-Exception-Class.spec
@@ -1,6 +1,6 @@
 Name:   perl-Exception-Class
-Version:1.42
-Release:3%{?dist}
+Version:1.43
+Release:1%{?dist}
 Summary:Module that allows you to declare real exception classes in 
Perl
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Exception-Class/
@@ -56,6 +56,12 @@ make test
 %{_mandir}/man3/Exception::Class::Base.3*
 
 %changelog
+* Mon Jul 10 2017 Paul Howarth  - 1.43-1
+- Update to 1.43
+  - The full_message() method in Exception::Class::Base now calls message()
+instead of accessing the object's hash key, which makes it easier to
+override message() in a subclass (GH#11)
+
 * Mon Jun 05 2017 Jitka Plesnikova  - 1.42-3
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index 8c11748..1518746 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Exception-Class-1.42.tar.gz) = 
b13f13882a4ca1bb44219dab1ebc7cd730d3b739e8f540b597fa3aa0adc0ede00e927844d293c584f05cce643c23bac73703318873c526c94668b8f9ff98a643
+SHA512 (Exception-Class-1.43.tar.gz) = 
8416f82032dd39c38c9a4e12d7ae23cd0d66e1cbe9b22bde274972031c6218ed2d90cf9caf052a3d201decf92e715d0bf56a42789f35a7a60b9ea66680fb2668
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Exception-Class.git/commit/?h=master=4352675533edd7ef0502ba232c8b17dab3f9782e
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded Exception-Class-1.43.tar.gz for perl-Exception-Class

[notifications]

8416f82032dd39c38c9a4e12d7ae23cd0d66e1cbe9b22bde274972031c6218ed2d90cf9caf052a3d201decf92e715d0bf56a42789f35a7a60b9ea66680fb2668
  Exception-Class-1.43.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Exception-Class/Exception-Class-1.43.tar.gz/sha512/8416f82032dd39c38c9a4e12d7ae23cd0d66e1cbe9b22bde274972031c6218ed2d90cf9caf052a3d201decf92e715d0bf56a42789f35a7a60b9ea66680fb2668/Exception-Class-1.43.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Using ndb in RPM (was: Re: F27 System Wide Change: RPM 4.14)

[Jos Vos]

Hi,

On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote:

> The web page has:
> 
>Improvements and stabilization of "ndb" (New RPM DB Format database
>format)
>
> [...]
> 
> The problem is that "NDB" is a custom homebrew database invented in
> the RPM codebase.  I agree that because of licensing problems we need
> to move away from Berkeley DB, but why not switch to the obvious,
> bulletproof choice - Sqlite?

SQLite is is totally different piece of cake (RDBMS vs. key/value).

Why not use LMDB?  It's the replacement for BerkeleyDB in OpenLDAP.

http://www.lmdb.tech/doc/

It's extremely fast...

Cheers,

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

[Pierre-Yves Chibon]

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. So to update the
description, simply update the package in rawhide.

You can then simply complement these information with a README file.


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

Re: Mingw RPM deps broken [Re: Fedora rawhide compose report: 20170708.n.0 changes]

[Tomasz Torcz]

On Mon, Jul 10, 2017 at 09:52:18AM +0100, Daniel P. Berrange wrote:
> On Sat, Jul 08, 2017 at 02:40:42PM +, Fedora Rawhide Report wrote:
> 
> > Broken deps for x86_64
> > --
> > [mingw-atkmm]
> > mingw32-atkmm-2.24.2-3.fc26.noarch requires mingw32(libglibmm-2.4-1.dll)
> > mingw64-atkmm-2.24.2-3.fc26.noarch requires mingw64(libglibmm-2.4-1.dll)
> 
> It appears that the /usr/lib/rpm/mingw-find-{requires,provides}.sh scripts
> are broken. New builds are ending up with almost no provides lists, which
> is in turn causing all dependant packages to report broken deps like this.
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1468993
> 
> Early June was the last time I see this working correctly so far, so
> potentially any mingw package built in rawhide since that time has
> broken deps and will need a rebuild once this is fixed

  Did something change recently in autodetecting provides list during
rpm build?  I have similar situation couple weeks ago - package
owfs, subpackage owfs-libs - libftdi was not detected as needed.
I had to manually stick “Requires: libftdi”, earlier this worked automatically.
I remember someone had problems with underspecified Requires: with
some other package, but I cannot remember specifics - it was raised on -devel 
here.

  My build was for Rawhide, I did not build for F26.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mingw RPM deps broken [Re: Fedora rawhide compose report: 20170708.n.0 changes]

[Sandro Mani]

On 10.07.2017 10:52, Daniel P. Berrange wrote:
It appears that the /usr/lib/rpm/mingw-find-{requires,provides}.sh 
scripts

are broken. New builds are ending up with almost no provides lists, which
is in turn causing all dependant packages to report broken deps like this.

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

Early June was the last time I see this working correctly so far, so
potentially any mingw package built in rawhide since that time has
broken deps and will need a rebuild once this is fixed
Actually it looks like it works again now, I rebuilt mingw-LibRaw and 
mingw-glibmm24 yesterday for F27 and both got its provides again. Not 
sure what cause the script to fail before though.


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

Mingw RPM deps broken [Re: Fedora rawhide compose report: 20170708.n.0 changes]

[Daniel P. Berrange]

On Sat, Jul 08, 2017 at 02:40:42PM +, Fedora Rawhide Report wrote:

> Broken deps for x86_64
> --
> [mingw-atkmm]
>   mingw32-atkmm-2.24.2-3.fc26.noarch requires mingw32(libglibmm-2.4-1.dll)
>   mingw64-atkmm-2.24.2-3.fc26.noarch requires mingw64(libglibmm-2.4-1.dll)
> [mingw-freeimage]
>   mingw32-freeimage-3.17.0-7.fc26.noarch requires mingw32(libraw-16.dll)
>   mingw64-freeimage-3.17.0-7.fc26.noarch requires mingw64(libraw-16.dll)
> [mingw-gtkmm24]
>   mingw32-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw32(libgiomm-2.4-1.dll)
>   mingw32-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw64(libgiomm-2.4-1.dll)
>   mingw64-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-gtkmm30]
>   mingw32-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw32(libgiomm-2.4-1.dll)
>   mingw32-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw64(libgiomm-2.4-1.dll)
>   mingw64-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-gtkspellmm30]
>   mingw32-gtkspellmm30-3.0.5-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkspellmm30-3.0.5-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-libglademm24]
>   mingw32-libglademm24-2.6.7-22.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
> [mingw-libvirt-glib]
>   mingw32-libvirt-glib-1.0.0-2.fc26.noarch requires mingw32(libvirt-0.dll)
>   mingw32-libvirt-gobject-1.0.0-2.fc26.noarch requires 
> mingw32(libvirt-0.dll)
>   mingw64-libvirt-glib-1.0.0-2.fc26.noarch requires mingw64(libvirt-0.dll)
>   mingw64-libvirt-gobject-1.0.0-2.fc26.noarch requires 
> mingw64(libvirt-0.dll)
> [mingw-libxml++]
>   mingw32-libxml++-2.40.1-3.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-libxml++-2.40.1-3.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-pangomm]
>   mingw32-pangomm-2.40.1-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-pangomm-2.40.1-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-plotmm]
>   mingw32-plotmm-0.1.2-22.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-plotmm-0.1.2-22.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)

It appears that the /usr/lib/rpm/mingw-find-{requires,provides}.sh scripts
are broken. New builds are ending up with almost no provides lists, which
is in turn causing all dependant packages to report broken deps like this.

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

Early June was the last time I see this working correctly so far, so
potentially any mingw package built in rawhide since that time has
broken deps and will need a rebuild once this is fixed

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Using ndb in RPM (was: Re: F27 System Wide Change: RPM 4.14)

[Richard W.M. Jones]

On Fri, Jul 07, 2017 at 04:15:53PM +0200, Jaroslav Reznik wrote:
> = System Wide Change: RPM 4.14 =
> https://fedoraproject.org/wiki/Changes/RPM-4.14

The web page has:

   Improvements and stabilization of "ndb" (New RPM DB Format database
   format)
...
   Changing database from bdb to ndb requires patching of some programs
   who read/expect /var/lib/rpm/Packages and other files directly
   without using librpm

which were not included in this email.

The problem is that "NDB" is a custom homebrew database invented in
the RPM codebase.  I agree that because of licensing problems we need
to move away from Berkeley DB, but why not switch to the obvious,
bulletproof choice - Sqlite?

Look at the all new nbd code here:

  https://github.com/rpm-software-management/rpm/tree/master/lib/backend/ndb

Inventing a new database including a new disk format and all new code
is bound to cause problems with database corruption, incorrect
database synchronization, incorrect handling of parallel queries, and
a rich source of other bugs for a long time.

Not to mention ‘ndb requires patching of some programs who read/expect
/var/lib/rpm/Packages and other files directly without using librpm’ -
this would still require changes, but they are much smaller if you're
using sqlite.

It was a bad upstream decision, but it's not too late to avoid it by
sticking with BDB for now and using sqlite in the long run.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Implementing Referential Integrity by using a queue instead of a file

[Ludwig]

On 07/10/2017 12:13 AM, William Brown wrote:

On Fri, 2017-07-07 at 11:44 +0200, Ludwig Krispenz wrote:

On 07/07/2017 10:44 AM, Ludwig Krispenz wrote:

On 07/07/2017 07:10 AM, William Brown wrote:

Any thoughts or objections on the above would be welcome.

The only problem with going to a queue is if the server goes down
unexpectedly.  In such a case those RI updates would be lost.

We already have this issue because there is a delay between the change
to the object and the log being sync() to disk. So we can already lose
changes here. TBH the only fix is ot remove the async model. I actually
question why we still need async/delay processing of the refint
plugin ...

Historically speaking, a long time ago, we used to see high CPU when the
RI plugin was engaged.  Setting the delay to 1 second, and allowing the
log thread to do the work, improved performance.  Of course this is now
obsolete with the betxn plugin model and other improvements, but I
wanted to share why the feature even existed.

I guess that would be related to internal op searches / lack of
indexing. These days it's not as big of an issue.

boldly said. How do you know, did you verify it ?
we have seen many customer issues with refereint which were resolved
by making it async, just removing this option without proof of a
better solution is no good.
I also am not sure if we need to tie anything into the betxn. There
are operations, which, in my opinion, can be delayed, even redone by
fixup tasks, so it is not necessary to have it in one txn, and if the
option is there to delay it if you want, we should not take it away

So, lets open a ticket to remove delayed processing mode then?

you can, but I will oppose to implement it :-)

I would even go and suggest to implement the delay feature for memberof,
like a continuous fixup task.

I disagree: Right now a delayed / async mode causes us issue because you
have a seperation between "the change" then the database reflecting
that. Be it through memberof or refint. We have lost the atomic nature
of the DB as a result.
yes and no. A client operation does not know which plugins are enabled, 
if they are delayed, betxn or postop plugins, or if they are temporarily 
disabled. We still have the ACID property for the client.
if we set the delay the main operation and the secondary operation eg 
meberof or refint are no longer atomic. But this is deliberate decision, 
you also cannot prevent an admin to disable memberof for some time and 
later run fixup, in that period group changes and memberof also are not 
atomic.


Memberof especially so because SSSD uses this for membership. If we
implemented this we could cause undue delays to access controls be it
addition or removal while a consumer waits for the processing to occur.

who said that we have to use a delay in this deployment ?


Additionally, the async modes *force* the plugin to run on a single
master, rather than all masters lest we cause many replication
conflicts.

No.


For the sake of replication master consistency being able to run the
same configuration on all masters is extremely important.

yes, but you're argument about repl conflicts is not correct


Finally, any delays in refint/memberof processing:

* We have a better MO algorithm there, it's just not been implemented
yet.
* Perhaps refint is missing indexes, or needs an algorithmic change of
it's own.


I think that it's a better investment of time to *fix* our problems,
rather than hide and delay them behind async processing tasks (which
arguably, will cause other random delays by being batched, and holding
the write lock for a longer time period than a single write).
I fully agree. but there is no need for investment for a delay in 
refint, it is there and is used by a few deployments - and you want to 
invest into takeing this away and/or replcaing it while there is no need 
or requirement to do so


So, I will open this ticket, and I think that given your concerns about
this Ludwig, we'll need to keep in mind that refint processing
performance is a key aspect of this change, and that we will need to
perform some significant load testing to guarantee we will not cause a
regression in this space.



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


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

dist.upgradepath FAILED for perl-Parse-ErrorString-Perl-0.26-1.fc24

[notifications]

dist.upgradepath FAILED for perl-Parse-ErrorString-Perl-0.26-1.fc24

https://taskotron.fedoraproject.org/artifacts/all/55232992-6541-11e7-8b03-5254008e42f6/task_output/perl-Parse-ErrorString-Perl-0.26-1.fc24.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Locale-MO-File (master). "Initial import"

[notifications]

From 1518641f76f123af556ac5e20b377743380d440a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 09:04:24 +0200
Subject: Initial import

---
 .gitignore   |  1 +
 perl-Locale-MO-File.spec | 76 
 sources  |  1 +
 3 files changed, 78 insertions(+)
 create mode 100644 perl-Locale-MO-File.spec

diff --git a/.gitignore b/.gitignore
index e69de29..e771c5e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Locale-MO-File-0.06.tar.gz
diff --git a/perl-Locale-MO-File.spec b/perl-Locale-MO-File.spec
new file mode 100644
index 000..865315a
--- /dev/null
+++ b/perl-Locale-MO-File.spec
@@ -0,0 +1,76 @@
+Name:   perl-Locale-MO-File
+Version:0.06
+Release:1%{?dist}
+Summary:Write and read gettext MO files
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Locale-MO-File/
+Source0:
http://www.cpan.org/authors/id/S/ST/STEFFENW/Locale-MO-File-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  make
+BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(:VERSION) >= 5.6.1
+BuildRequires:  perl(Config)
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires:  sed
+# Run-times
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(charnames)
+BuildRequires:  perl(Const::Fast)
+BuildRequires:  perl(Encode)
+BuildRequires:  perl(English)
+
+BuildRequires:  perl(IO::File)
+BuildRequires:  perl(Moo) >= 1.003001
+BuildRequires:  perl(MooX::StrictConstructor)
+BuildRequires:  perl(MooX::Types::MooseLike::Base)
+BuildRequires:  perl(namespace::autoclean)
+BuildRequires:  perl(Params::Validate)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Tests
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(File::Find)
+BuildRequires:  perl(Hash::Util)
+BuildRequires:  perl(Test::Differences) >= 0.60
+BuildRequires:  perl(Test::Exception)
+BuildRequires:  perl(Test::HexDifferences)
+BuildRequires:  perl(Test::More)
+BuildRequires:  perl(Test::NoWarnings)
+# Optional tests
+BuildRequires:  perl(Pod::Coverage::Moose)
+BuildRequires:  perl(Test::Pod) >= 1.14
+BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(Moo) >= 1.003001
+
+# Remove under-specified dependencies
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\((Moo)\\)$
+
+%description
+The module allows to write or read gettext MO files.
+
+%prep
+%setup -q -n Locale-MO-File-%{version}
+sed -i -e 's/\r//' README Changes example/*
+sed -i -e '1s|#!.*perl|%(perl -MConfig -e 'print $Config{startperl}')|' 
example/*
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes example README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Jun 29 2017 Jitka Plesnikova  - 0.06-1
+- Initial release
diff --git a/sources b/sources
index e69de29..f8afc25 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (Locale-MO-File-0.06.tar.gz) = 
574c86c66455ce8b58a9a25f6779e3c1ec39e8e5ebf09ea3f0d0ad460176bb4b8f6be24f3a6363acd22bf9100d2bb56ebb81ad365654587679518f3549e4b178
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Locale-MO-File.git/commit/?h=master=1518641f76f123af556ac5e20b377743380d440a
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Locale-MO-File-0.06.tar.gz for perl-Locale-MO-File

[notifications]

574c86c66455ce8b58a9a25f6779e3c1ec39e8e5ebf09ea3f0d0ad460176bb4b8f6be24f3a6363acd22bf9100d2bb56ebb81ad365654587679518f3549e4b178
  Locale-MO-File-0.06.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Locale-MO-File/Locale-MO-File-0.06.tar.gz/sha512/574c86c66455ce8b58a9a25f6779e3c1ec39e8e5ebf09ea3f0d0ad460176bb4b8f6be24f3a6363acd22bf9100d2bb56ebb81ad365654587679518f3549e4b178/Locale-MO-File-0.06.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed ppisar's 'approveacls' permission on rpms/perl-Locale-MO-File (master) to 'Approved'

[notifications]

jplesnik changed ppisar's 'approveacls' permission on rpms/perl-Locale-MO-File 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-MO-File/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed ppisar's 'watchbugzilla' permission on rpms/perl-Locale-MO-File (master) to 'Obsolete'

[notifications]

jplesnik changed ppisar's 'watchbugzilla' permission on 
rpms/perl-Locale-MO-File (master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-MO-File/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed ppisar's 'watchcommits' permission on rpms/perl-Locale-MO-File (master) to 'Obsolete'

[notifications]

jplesnik changed ppisar's 'watchcommits' permission on rpms/perl-Locale-MO-File 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-MO-File/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik changed perl-sig's 'commit' permission on rpms/perl-Locale-MO-File (master) to 'Obsolete'

[notifications]

jplesnik changed perl-sig's 'commit' permission on rpms/perl-Locale-MO-File 
(master) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-MO-File/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-MooX-Singleton (master). "Initial import"

[notifications]

From 5847c872bf5521323b90ea0ef69e0578387ae548 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 10 Jul 2017 08:51:54 +0200
Subject: Initial import

---
 .gitignore   |  1 +
 perl-MooX-Singleton.spec | 50 
 sources  |  1 +
 3 files changed, 52 insertions(+)
 create mode 100644 perl-MooX-Singleton.spec

diff --git a/.gitignore b/.gitignore
index e69de29..dd72fa1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/MooX-Singleton-1.20.tar.gz
diff --git a/perl-MooX-Singleton.spec b/perl-MooX-Singleton.spec
new file mode 100644
index 000..dac862a
--- /dev/null
+++ b/perl-MooX-Singleton.spec
@@ -0,0 +1,50 @@
+Name:   perl-MooX-Singleton
+Version:1.20
+Release:1%{?dist}
+Summary:Turn your Moo class into singleton
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/MooX-Singleton/
+Source0:
http://www.cpan.org/authors/id/A/AJ/AJGB/MooX-Singleton-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  make
+BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Run-time
+BuildRequires:  perl(Role::Tiny)
+# Tests
+BuildRequires:  perl(File::Find)
+BuildRequires:  perl(File::Temp)
+BuildRequires:  perl(Moo)
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+This is a Moo role that provides "instance" method turning your object
+into singleton.
+
+%prep
+%setup -q -n MooX-Singleton-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Jul 03 2017 Jitka Plesnikova  - 1.20-1
+- Initial release
diff --git a/sources b/sources
index e69de29..ca2a169 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (MooX-Singleton-1.20.tar.gz) = 
6fea66cc67440bab49766b658d0443373ca70ef101bb46191c79f7ad47e35f52a4813759769194f9f964981e639e187e071e01e2f1193833da14eefbe5131d8d
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-MooX-Singleton.git/commit/?h=master=5847c872bf5521323b90ea0ef69e0578387ae548
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded MooX-Singleton-1.20.tar.gz for perl-MooX-Singleton

[notifications]

6fea66cc67440bab49766b658d0443373ca70ef101bb46191c79f7ad47e35f52a4813759769194f9f964981e639e187e071e01e2f1193833da14eefbe5131d8d
  MooX-Singleton-1.20.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-MooX-Singleton/MooX-Singleton-1.20.tar.gz/sha512/6fea66cc67440bab49766b658d0443373ca70ef101bb46191c79f7ad47e35f52a4813759769194f9f964981e639e187e071e01e2f1193833da14eefbe5131d8d/MooX-Singleton-1.20.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org