Re: COPR + pagure + rpkg HOWTO?

[Miroslav Suchý]

Dne 3.2.2018 v 15:45 Richard Shaw napsal(a):
> 
> so I can stop uploading package to my fedorapeople public_html site and build 
> via URLs.

Another option is to use
  copr-cli build foo.src.rpm
which nowdays can submit src.rpm directly from your machine to Copr. This 
feature is in Copr more than year.

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

Re: binutils 2.30

[Florian Weimer]

On 02/06/2018 08:38 AM, Richard W.M. Jones wrote:

binutils 2.30 has been out for about a week.  Will we get it in
Rawhide soon?  It has some modest enhancements related to the RISC-V
architecture.


No, not before Fedora 28 branches.

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

binutils 2.30

[Richard W.M. Jones]

binutils 2.30 has been out for about a week.  Will we get it in
Rawhide soon?  It has some modest enhancements related to the RISC-V
architecture.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1517786] perl-Mason-Tidy-2.57-7.fc28 FTBFS: Invalid isa 'CODE( 0x162c48310)' for Mason::Tidy->mason_versionis

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
Last Closed||2018-02-06 02:37:07



--- Comment #1 from Jitka Plesnikova  ---
It was fixed by perl-Moo-2.003004-1.fc28.

-- 
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 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:14:59



-- 
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 1522687] Upgrade perl-B-Debug to 1.26

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:14:59



-- 
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 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:14:59



-- 
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 1522696] Upgrade perl-Dist-Zilla-Plugin-Git-Contributors to 0.032

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:14:59



-- 
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 1522693] Upgrade perl-Dist-Zilla-Plugin-CheckChangesHasContent to 0.011

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:14:59



-- 
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 1536730] perl-DateTime-TimeZone-2.16 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1537829] perl-DateTime-TimeZone-2.17 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1511913] perl-Crypt-OpenSSL-X509-1.808 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1537839] perl-Sereal-Encoder-4.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1537837] perl-Sereal-4.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1537838] perl-Sereal-Decoder-4.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:12:41



-- 
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 1536767] perl-CPAN-Perl-Releases-3.46 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:10:42



-- 
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 1536773] perl-Module-CoreList-5.20180120 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:10:42



-- 
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 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:10:42



-- 
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 1529804] perl-Mock-Sub-1.09 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:10:42



-- 
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 1511243] perl-Mail-Message-3.005 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2018-02-06 02:10:42



-- 
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: gnome crashes after today upgrade

[Tomasz Kłoczko]

On 4 February 2018 at 01:51, Sam Varshavchik  wrote:

> Tomasz Kłoczko writes:
>
> On 3 February 2018 at 22:55, Richard Shaw <> com>hobbes1...@gmail.com> wrote:
>>
>>Any news on the cause? I'm waiting to update until this is figured
>> out...
>>
>> Still don't see any update about the issue.
>> It is really pain in the a*s that Linux still has no good support to
>> handle
>>
>
> One option that's available to you is to switch to another desktop. No
> issues here, whatsoever, on my XFCE desktop.
>
> I replaced Gnome with XFCE on all my desktops a number of years ago, and
> haven't looked back.
>

I gave the chance for xfce and here are some my conclusions:
- Pros:
-- much lower memory consumption. Difference is about 1.2GB less RAM. On
one of my laptops with only 8GB RAM it makes really big difference

- Cons:
-- after only 3-4h on m primary desktop I've been able to collect descent
number of core files

# ls -la /var/lib/systemd/coredump/*
-rw-r-+ 1 root root 1628938240 Feb  6 03:28
/var/lib/systemd/coredump/core.chrome.1000.9b34b2ba89514d86a302484519bf2a53.14303.151788763700
-rw-r-+ 1 root root   37933056 Feb  6 04:10
/var/lib/systemd/coredump/core.mission-control.1000.ad37f99486c24da58887b80804c84322.9243.151789023300
-rw-r-+ 1 root root   28282880 Feb  6 03:34
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.2398.151788803900
-rw-r-+ 1 root root   32505856 Feb  6 04:27
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.5645.151789125800

and only this does not look good :/
Chrome as usually is affected by memory leaks which are causing that on
some web pages suddenly some chrome process suddenly puffs and crashes by
passing max memory limit. Of course this issue has nothing to do with xfce.
Other cores may be caused by the same cause(s) which is(are) now affecting
Gnome desktop.

-- xfce needs a lot of work
--- base @Xfce kickstart group drags a lot of dependencies which are not
essential. It wold be IMO good to create something @Xfce-minimal group
--- I've installed xfce by choosing initially set of packages and I've anup
on desktop without window manage so it wold be good to add to one of the
core xfce package "Require: windowmanager" and add to all packages
"Provides: windowmanager" if xfce can be used without xfwm4 or add straight
Requires: xfwm4
My my minimal set of xfce packages:

libxfce4ui
libxfce4util
xfce4-appfinder
xfce4-notifyd
xfce4-panel
xfce4-power-manager
xfce4-screenshooter
xfce4-session
xfce4-session-engines
xfce4-settings
xfce4-taskmanager
xfce4-terminal
xfce4-xkb-plugin
xfce-polkit
xfconf
xfdesktop
xfwm4

I'm opened on any suggestions about what more could be added to such set :)

-- trying to launch any gnome application still is affected by already
discussed in this thread issues.
--- it is not possible to tart working wit xfce desktop because during
first time xfce start it is necessary to answer on few questions. I thing
that it is generally wrong strategy because everything should start with
some default settings. Whatever someone will like/dislike still is possible
to customize later.
--- I think that it wold be really good to prepare initial default desktop
layout to mimic default Gnome desktop. This wold make migration from Gnome
to xfce much smoother.

-- I thing that using xfce4 in many packages should be replaced by just
xfce This will make future transitions to next major version easier. I see
that already some number of xfce packages is not using this "4" in package
names.

- Other:
Looks like changing xkb keyboard layout which started with crashing
gnome-shell under gome is not caused by gnome-shell but by gdm issue. from
logs:

Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_layout" "pl,gb,us"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_variant" ",,"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: syntax error: line
500 of pl
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: The XKEYBOARD
keymap compiler (xkbcomp) reports:
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: > Error:
Error interpreting include file "pl"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
 Exiting
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
 Abandoning symbols file "default"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: Errors from xkbcomp
are not fatal to the X server
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) Error loading
keymap /tmp/server-0.xkm
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) XKB: Failed to
load keymap. Loading default keymap instead.

Cannot find which one xkb map is used in above case. After uncompressing
/lib/kbd/keymaps/xkb/pl.map.gz I see that this file has only 199 lines so
this error message must be about some other (text?) file. So Still I cannot
change keyboard layout to pl 

Re: Upstream installs AppData file in /usr/share/appdata

[Samuel Rakitničan]

> Submit a PR upstream to fix it, and use that patch to change it locally.
So I did, upstream accepted it, but then it applied old location again. As it 
is noted in patch description for compatibility reasons. Now application 
installs on both locations.

Should I remove now this files from the old location or they can stay?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Samuel Sieb]

On 02/05/2018 10:35 AM, Howard Howell wrote:

So far, so good, but I really miss the gamma.gold cursors which
are much easier for me to see and use.

No problems so far.  If it goes one week, I will again attempt
the Gamma.Gold cursors because I need the visibility.  My eyes hurt
after a few hours trying to find the smaller and darker default
cursors.


Maybe try contacting the authors and mention that the theme is 
incomplete.  You could also check yourself to find out which ones are 
missing and make replacements.

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

[Bug 1542279] New: perl-Gearman-2.004.0013 is available

[bugzilla]

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

Bug ID: 1542279
   Summary: perl-Gearman-2.004.0013 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Gearman
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
ru...@rubenkerkhof.com



Latest upstream release: 2.004.0013
Current version/release in rawhide: 2.004.012-1.fc28
URL: http://search.cpan.org/dist/Gearman/

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

-- 
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: Writing Documentation for Fedora - Docs FAD

[Omar Berroterán Sivla]

Hello, 

Great, 

If there are virtual posibility, please add me. 
 

LKF *Omar Berroteran*
Colaborador Proyecto Fedora | Nicaragua
IRC: nadie Canales: #fedora-latam ; #fedora-ni
https://fedoraproject.org/wiki/User:lkf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!

[Umar Parooq]

Wellcome Bro.
On Feb 5, 2018 11:33 PM, "Dusty Mabe"  wrote:

>
>
> On 01/23/2018 10:39 AM, Christian Glombek wrote:
> > Hello World!
> >
> > My name is Christian Glombek (or simply Chris :)
>
> Welcome Chris!
>
> Dusty
> ___
> 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: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Thu, Feb 01, 2018 at 08:29:49AM +, Terry Barnaby wrote:
> 1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE call
> all in one. This would reduce the latency of a small file to 1ms rather than
> 3ms thus 66% faster. Would require the client to delay the OPEN/SETATTR
> until the first WRITE. Not sure how possible this is in the implementations.
> Maybe READ's could be improved as well but getting the OPEN through quick
> may be better in this case ?
> 
> 2. Could go further with an OPEN-SETATTR-WRITE-CLOSE RPC call. (0.5ms vs
> 3ms).

The protocol doesn't currently let us delay the OPEN like that,
unfortunately.

What we can do that might help: we can grant a write delegation in the
reply to the OPEN.  In theory that should allow the following operations
to be performed asynchronously, so the untar can immediately issue the
next OPEN without waiting.  (In practice I'm not sure what the current
client will do.)

I'm expecting to get to write delegations this year

It probably wouldn't be hard to hack the server to return write
delegations even when that's not necessarily correct, just to get an
idea what kind of speedup is available here.

> 3. On sync/async modes personally I think it would be better for the client
> to request the mount in sync/async mode. The setting of sync on the server
> side would just enforce sync mode for all clients. If the server is in the
> default async mode clients can mount using sync or async as to their
> requirements. This seems to match normal VFS semantics and usage patterns
> better.

The client-side and server-side options are both named "sync", but they
aren't really related.  The server-side "async" export option causes the
server to lie to clients, telling them that data has reached disk even
when it hasn't.  This affects all clients, whether they mounted with
"sync" or "async".  It violates the NFS specs, so it is not the default.

I don't understand your proposal.  It sounds like you believe that
mounting on the client side with the "sync" option will make your data
safe even if the "async" option is set on the server side?
Unfortunately that's not how it works.

> 4. The 0.5ms RPC latency seems a bit high (ICMP pings 0.12ms) . Maybe this
> is worth investigating in the Linux kernel processing (how ?) ?

Yes, that'd be interesting to investigate.  With some kernel tracing I
think it should be possible to get high-resolution timings for the
processing of a single RPC call, which would make a good start.

It'd probably also interesting to start with the simplest possible RPC
and then work our way up and see when the RTT increases the most--e.g
does an RPC ping (an RPC with procedure 0, empty argument and reply)
already have a round-trip time closer to .5ms or .12ms?

> 5. The 20ms RPC latency I see in sync mode needs a look at on my system
> although async mode is fine for my usage. Maybe this ends up as 2 x 10ms
> drive seeks on ext4 and is thus expected.

Yes, this is why dedicated file servers have hardware designed to lower
that latency.

As long as you're exporting with "async" and don't care about data
safety across crashes or power outages, I guess you could go all the way
and mount your ext4 export with "nobarrier", I *think* that will let the
system acknowledge writes as soon as they reach the disk's write cache.
I don't recommend that.

Just for fun I dug around a little for cheap options to get safe
low-latency storage:

For Intel you can cross-reference this list:


https://ark.intel.com/Search/FeatureFilter?productType=solidstatedrives=true

of SSD's with "enhanced power loss data protection" (EPLDP) with
shopping sites and I find e.g. this for US $121:

https://www.newegg.com/Product/Product.aspx?Item=9SIABVR66R5680

See the "device=" option in the ext4 man pages--you can use that to give
your existing ext4 filesystem an external journal on that device.  I
think you want "data=journal" as well, then writes should normally be
acknowledged once they hit that SSD's write cache, which should be quite
quick.

I was also curious whether there were PCI SSDs, but the cheapest Intel
SSD with EPLDP is the P4800X, at US $1600.

Intel Optane Memory is interesting as it starts at $70.  It doesn't have
EPLDP but latency of the underlying storage might be better even without
that?

I haven't figured out how to get a similar list for other brands.

Just searching for "SSD power loss protection" on newegg:

This also claims "power loss protection" at $53, but I can't find any
reviews:


https://www.newegg.com/Product/Product.aspx?Item=9SIA1K642V2376_re=ssd_power_loss_protection-_-9SIA1K642V2376-_-Product

Or this?:


https://www.newegg.com/Product/Product.aspx?Item=N82E16820156153_re=ssd_power_loss_protection-_-20-156-153-_-Product

This is another interesting discussion of the problem:


https://blogs.technet.microsoft.com/filecab/2016/11/18/dont-do-it-consumer-ssd/

--b.

Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!

[Dusty Mabe]

On 01/23/2018 10:39 AM, Christian Glombek wrote:
> Hello World!
> 
> My name is Christian Glombek (or simply Chris :) 

Welcome Chris! 

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

Re: Self-Introduction Christian Glombek (lorbus) / NEEDSPONSOR / NEEDREVIEWs / Let's Meet @ DevConf or FOSDEM!

[Christian Glombek]

Thank you all for the warm welcome! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction Matthew Ruszczyk (mruszczyk) NEEDSPONSOR / NEEDREVIEW

[Christian Glombek]

Hi Matthew!

Nice to have you on board :)

Cheers,
Chris

Charalampos Stratakis  schrieb am Mo., 5. Feb. 2018 um
11:05 Uhr:

> Hello Matthew and welcome!
>
> - Original Message -
> > From: "Matthew Ruszczyk" 
> > To: devel@lists.fedoraproject.org
> > Sent: Friday, February 2, 2018 11:18:38 PM
> > Subject: Self Introduction Matthew Ruszczyk (mruszczyk) NEEDSPONSOR /
> NEEDREVIEW
> >
> > Hello,
> > My name is Matthew, I'm interested in joining the Fedora Packagers Group
> to
> > package a piece of software called whipper. I am a 27 year old network
> > administrator at a small company in Pennsylvania, US. I've dabbled in
> open
> > source software for years and Fedora has been my main distribution for a
> > large chunk of that time. I love it's focus on cutting edge technology.
> >
> > I have been working to package an application called whipper that I hope
> to
> > get into fedora proper. It is a fork of an older application called
> morituri
> > that is focused on ripping CDs accurately using libcdio-paranoia. Up
> until
> > now the package clobbered an existing morituri install so I was hesitant
> to
> > submit it but today they tagged a new release that fixes that issue. I
> > largely began packaging it for my own needs but would love to give back
> to
> > the fedora community and maintain it properly. I'm most often found in
> > #whipper on freenode if anyone has any questions for me.
> >
> > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1541566
> > COPR: https://copr.fedorainfracloud.org/coprs/mruszczyk/whipper/
> > Repo: https://github.com/JoeLametta/whipper
> >
> > I hope I can get some constructive criticism and be a valued member of
> this
> > community.
> >
> > Matthew
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
> --
> Regards,
>
> Charalampos Stratakis
> Software Engineer
> Python Maintenance Team, Red Hat
> ___
> 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: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Andrew Lutomirski]

On Thu, Feb 1, 2018 at 11:34 AM, Hans de Goede  wrote:
>
> Hi All,
>
> For the "Improved Laptop Battery Life" feature:
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
>
> I'm working on for Fedora 28 I would like to also try and enable
> Panel Self Refresh on laptops with Intel graphics, some quick tests
> have shown this to save another 0.5W (when idle / nothing on the
> screen changes). This is currently off be default because it is
> known to cause issues on some devices. So I think we will probably
> need a white- or black-list. But first we need more data on this.
>
> If you can spare 10 minutes, please see my blogpost for how to test
> this and send me a mail with the info request in the blogpost:
> https://hansdegoede.livejournal.com/18653.html
>

I suspect that the results may be odd.  After falling into a rabbit
hole when I tried to do this test, I learned a few things about the
i915 driver's PSR support:

 - Intel doesn't currently have any working CI coverage for PSR.

 - There's an Intel person who seems to be actively trying to fix PSR.

 - PSR on 4.15 on newish hardware (at least Skylake) is completely broken.

 - There are other known bugs.

So I'm not sure that trying to tabulate PSR functionality based on
panel type seems like it may be the wrong approach.
___
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 2018-02-06 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: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Dominik 'Rathann' Mierzejewski]

Hello, Hans.

On Thursday, 01 February 2018 at 12:34, Hans de Goede wrote:
[...]
> If you can spare 10 minutes, please see my blogpost for how to test
> this and send me a mail with the info request in the blogpost:
> https://hansdegoede.livejournal.com/18653.html

That's great! However, I'm getting this:

# cat /sys/kernel/debug/dri/0/i915_edp_psr_status
cat: /sys/kernel/debug/dri/0/i915_edp_psr_status: Operation not permitted

as root on my machine. Does that mean it's not supported?

Regards,
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Przemek Klosowski]

On 02/05/2018 01:35 PM, Howard Howell wrote:

My eyes hurt
after a few hours trying to find the smaller and darker default
cursors.


Do you know that you can simply increase the size of the cursors?

dconf write /org/gnome/desktop/interface/cursor-size 48

I swear I saw it in one of GNOME GUI tools but I can't find it now 
(doesn't seem to be in Settings or Gnome-tweaks)

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

Re: Orphaned packages seeking new point of contact

[Tomasz Torcz ️]

On Mon, Feb 05, 2018 at 07:42:45AM -0500, Josh Boyer wrote:
> On Fri, Feb 2, 2018 at 3:22 PM, Michael Schwendt  wrote:
> > On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
> >
> >> rpms/gqview
> >
> > Really?!
> 
> Congratulations, you have just explained why absentee maintainers are
> bad and why we orphan things.
> 
> > It is unmaintained for over 10 years.
> >
> > It has been forked into Geeqie (package "geeqie") roughly 10 years
> > ago, and Geeqie at least has seen several releases since then.
> 
> Perhaps just take gqview and retire it then?

  Shouldn't it be retired automatically when no one takes it?

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 strange rpmbuild failure

[Alec Leamas]

On 05/02/18 16:06, Petr Viktorin wrote:
> On 02/04/2018 10:08 PM, Alec Leamas wrote:

>> In other words, it's sort of a known bug with fixes under way, slowly...

> We're preparing a Change to fix this exact issue in Fedora 29. Started
> just last week, actually:
> https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation

Right, this is what I had in mind when I wrote my reply. At that point,
lazy me couldn't find that Change page even though I was aware it
existed somewhere in space.

Cheers!

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

Re: Wyland is a disaster

[Howard Howell]

On Sat, 2018-02-03 at 22:58 -0800, Samuel Sieb wrote:
> On 02/03/2018 05:58 PM, Howard Howell wrote:
> > Latest finding...
> > running gpartd, which I wanted to use to reformat an SD card for
> > use 
> > with a raspberry PI, drops me out to login immediately.
> > attached is the latest journalctl after the third attempt.
> > I clicked on gpartd at 17:36:14, and ended up logging back in at
> > 17:37:01
> > 
> > I don't know if this helps, but gpartd seems to fire the issue
> > every time.
> 
> Did you try switching the cursor theme back to the default to see if 
> that makes a difference?  Also, be aware that there's an issue with
> the 
> Places menu extension that gets triggered in various ways which might
> be 
> relevant here.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1538493
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hi, Samuel,
I did switch the cursors back using gnome-tweak-tool.  While
doing that I noticed that there was no selection for the shell theme,
not even the default nor was default or Adwaita available in the pull
down.  I installed the only one I could find from dnf, which was
selene.  Once that was done, the alarm ( a triangle with an "!" in it)
disappeared, and both default and Adwaita appeared in the pull down.  I
selected default.  It appears that the default setup doesn't actually
load the shell theme.

So far, so good, but I really miss the gamma.gold cursors which
are much easier for me to see and use.

No problems so far.  If it goes one week, I will again attempt
the Gamma.Gold cursors because I need the visibility.  My eyes hurt
after a few hours trying to find the smaller and darker default
cursors.

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

Re: Fwd: Broken dependencies: python-biopython

[Antonio Trande]

On 05/02/2018 17:41, Kevin Fenzi wrote:
> On 02/05/2018 03:53 AM, Antonio Trande wrote:
>> Hi all.
>>
>> I'm still receiving this warning even if broken dependency should be
>> corrected with the packaging release number 6:
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1017574
>>
>> Do you know why?
> 
> Should be fixed now. For some reason it was stuck in the signing tag...
> I cleared all those out yesterday.
> 
> kevin
> 
> 
> 

Thank you.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



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

Re: Orphaned packages seeking new point of contact

[Sérgio Basto]

On Mon, 2018-02-05 at 17:46 +0100, Robert-André Mauchin wrote:
> On lundi 5 février 2018 17:11:28 CET Sérgio Basto wrote:
> > On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
> > > rpms/gpm
> > 
> > I want take this one but don't now how , can we have a better
> > wikipage
> > [1] ? please , it means that we should install fedrepo-req  ? and
> > than
> > what should I run after ?
> > 
> > Thanks.
> > 
> > [1]
> > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#H
> > ow_d
> > o_I_adopt_an_orphaned_package_or_unretire_a_package.3F
> > 
> > [2]
> > dnf -y install  fedrepo-req
> 
> The wiki page us pretty clear, you just need to file a ticket with
> RelEng, see 
> an example here https://pagure.io/releng/issue/7273
> When they accept your request, you then have full control of the
> package and 
> manage it like any other one with fedpkg.
> 
> > it means that we should install fedrepo-req
> 
> You should have fedrepo-req installed for creating new package repo
> and new 
> branches. Since it is an orphaned package, it already has existing
> branches 
> and you probably won't need to create new ones. Unless you want to
> add it to 
> EPEL.
> 
> Anyhow it would be a good thing for you to learn how to use this
> tool. There's 
> a howto on Pagure https://pagure.io/fedrepo_req
> 
> Typically for a new package you do:
> $ fedrepo-req -t [Review Request Bug Number] -m [Type of Monitoring]
> [Package 
> Name] [Optional Additional Branch]
> 
> For example:
> $ fedrepo-req -t 1508126 -m monitoring-with-scratch micro f27
> 
> Then you may need to request additional branches, like F26 or EPEL7.
> For that 
> you need to use fedrepo-req-branch
> $ fedrepo-req-branch [Package Name] [Additional Branch]
> 
> For example:
> $ fedrepo-req-branch micro f26
> 
> Then you wait for the ticket to be processed by Gwyn Cierla at
> https://
> pagure.io/releng/fedora-scm-requests/issues It's pretty fast usually.

OK , many thanks for all help and tips . 

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

[EPEL-devel] Re: Adding devtoolset to EPEL

[Todd Zullinger]

Kevin Fenzi wrote:
> On 02/01/2018 07:40 AM, Todd Zullinger wrote:
>> Tom "spot" Callaway wrote:
>>> On 01/31/2018 10:53 AM, Stephen John Smoogen wrote:
 So we have a problem with what is the canonical place for SCL's. I was
 going from http://mirror.centos.org/centos/7/sclo/ which just says x86_64. 
>>>
>>> Even just getting x86_64 devtoolset into the potential buildroot for
>>> EPEL would be hugely helpful to me, because that's all chromium cares
>>> about right now.
>> 
>> I filed a pull request to update mock-core-configs:
>> 
>> https://github.com/rpm-software-management/mock/pull/159
>> 
>> If anyone here knows relevant folks on the SCL team who can
>> provide some input on the preferred/canonical repository
>> URLs (or any other issues with that PR), it would be great.
>> 
>> I tend to think that the mock configs we ship should use
>> whatever URLs the centos-release-scl{,-rh} packages use.
>> That's what end-users would see if they wanted to rebuild
>> packages outside of mock.  If those change we can always
>> update them in mock-core-configs to match.
> 
> Well, that will help people who do local mock builds, but won't do
> anything for koji/epel. ;)

Of course.  :)

Doing the mock part takes a little off the plate of the
folks who have access to make the changes in koji/epel.

More important, I think, is ensuring that local mock builds,
koji/epel builds, and plain old local rpmbuild builds work
as similarly as possible.  The mock-core-config changes were
merged the other day, so with the next release we should see
devtoolset enabled in mock for x86_64.  If/when other arches
move out of testing on CentOS and RHEL we'll just have to
update the mock configs.

> I think at this point it just needs someone to do the
> setup, and I think Peter said he could. If not, I can put
> it on my list, but not sure when I would get to it.

Cool, thanks.  

-- 
Todd
~~
The only difference between a rut and a grave is the depth.



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

[Bug 1541186] perl-bignum-0.48 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-bignum-0.49-1.fc27 has been pushed to the Fedora 27 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb5050056

-- 
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 1541736] perl-bignum-0.49 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-bignum-0.49-1.fc27 has been pushed to the Fedora 27 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb5050056

-- 
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 1541674] perl-Email-Address-XS-1.02 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Email-Address-XS-1.02-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-aeeeffea84

-- 
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: Orphaned packages seeking new point of contact

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2018 at 08:52:43AM -0800, Kevin Fenzi wrote:
> On 02/05/2018 08:48 AM, Kevin Fenzi wrote:
> > On 02/05/2018 08:11 AM, Sérgio Basto wrote:
> >> On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
> >>> rpms/gpm
> >>
> >> I want take this one but don't now how , can we have a better wikipage
> >> [1] ? please , it means that we should install fedrepo-req  ? and than
> >> what should I run after ? 
> > 
> > From the very qmail you are quoting:
> > 
> > "If you are interested in becoming the point of contact for these, please
> > note it in the appropriate ticket below for quickest processing.
> > (no need to reopen the ticket, just add your fas name and what packages
> > you want to take)
> > "
> > 
> > Just do that?
> 
> Ah, it seems zbyszek already requested gpm. Can you just drop him an
> email and I'm sure he would be happy to add you as a comaintainer.

No need, I already saw this thread and added Sérgio.

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

[Bug 1541186] perl-bignum-0.48 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
perl-bignum-0.49-1.fc26 has been pushed to the Fedora 26 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb09627edc

-- 
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: Orphaned packages seeking new point of contact

[Kevin Fenzi]

On 02/05/2018 08:48 AM, Kevin Fenzi wrote:
> On 02/05/2018 08:11 AM, Sérgio Basto wrote:
>> On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
>>> rpms/gpm
>>
>> I want take this one but don't now how , can we have a better wikipage
>> [1] ? please , it means that we should install fedrepo-req  ? and than
>> what should I run after ? 
> 
> From the very qmail you are quoting:
> 
> "If you are interested in becoming the point of contact for these, please
> note it in the appropriate ticket below for quickest processing.
> (no need to reopen the ticket, just add your fas name and what packages
> you want to take)
> "
> 
> Just do that?

Ah, it seems zbyszek already requested gpm. Can you just drop him an
email and I'm sure he would be happy to add you as a comaintainer.

kevin




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

[Bug 1541736] perl-bignum-0.49 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-bignum-0.49-1.fc26 has been pushed to the Fedora 26 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb09627edc

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

Re: Orphaned packages seeking new point of contact

[Kevin Fenzi]

On 02/05/2018 08:11 AM, Sérgio Basto wrote:
> On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
>> rpms/gpm
> 
> I want take this one but don't now how , can we have a better wikipage
> [1] ? please , it means that we should install fedrepo-req  ? and than
> what should I run after ? 

From the very qmail you are quoting:

"If you are interested in becoming the point of contact for these, please
note it in the appropriate ticket below for quickest processing.
(no need to reopen the ticket, just add your fas name and what packages
you want to take)
"

Just do that?

kevin



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

Re: Orphaned packages seeking new point of contact

[Robert-André Mauchin]

On lundi 5 février 2018 17:11:28 CET Sérgio Basto wrote:
> On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
> > rpms/gpm
> 
> I want take this one but don't now how , can we have a better wikipage
> [1] ? please , it means that we should install fedrepo-req  ? and than
> what should I run after ?
> 
> Thanks.
> 
> [1]
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_d
> o_I_adopt_an_orphaned_package_or_unretire_a_package.3F
> 
> [2]
> dnf -y install  fedrepo-req

The wiki page us pretty clear, you just need to file a ticket with RelEng, see 
an example here https://pagure.io/releng/issue/7273
When they accept your request, you then have full control of the package and 
manage it like any other one with fedpkg.

>it means that we should install fedrepo-req

You should have fedrepo-req installed for creating new package repo and new 
branches. Since it is an orphaned package, it already has existing branches 
and you probably won't need to create new ones. Unless you want to add it to 
EPEL.

Anyhow it would be a good thing for you to learn how to use this tool. There's 
a howto on Pagure https://pagure.io/fedrepo_req

Typically for a new package you do:
$ fedrepo-req -t [Review Request Bug Number] -m [Type of Monitoring] [Package 
Name] [Optional Additional Branch]

For example:
$ fedrepo-req -t 1508126 -m monitoring-with-scratch micro f27

Then you may need to request additional branches, like F26 or EPEL7. For that 
you need to use fedrepo-req-branch
$ fedrepo-req-branch [Package Name] [Additional Branch]

For example:
$ fedrepo-req-branch micro f26

Then you wait for the ticket to be processed by Gwyn Cierla at https://
pagure.io/releng/fedora-scm-requests/issues It's pretty fast usually.

Best regards,

Robert-André

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1064  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 827  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 409  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 306  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  75  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  39  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ce6223e559   
GraphicsMagick-1.3.28-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9eb18da891   
moodle-3.1.10-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0d5d190b0   
transmission-2.92-12.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd0bc449d7   
konversation-1.5.1-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fb68becde7   
w3m-0.5.3-36.git20180125.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-18ea640f19   
tomcat-native-1.2.16-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f09712d924   
pdns-3.4.11-4.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ac86cef06d   
p7zip-16.02-9.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

adapta-gtk-theme-3.93.0.103-1.el7
gnome-shell-extension-windowoverlay-icons-27-2.el7
js-jsroot-5.3.5-1.el7
python-resultsdb_api-2.0.0-7.el7

Details about builds:



 adapta-gtk-theme-3.93.0.103-1.el7 (FEDORA-EPEL-2018-d906c9d977)
 An adaptive Gtk+ theme based on Material Design Guidelines

Update Information:

- New upstream release

References:

  [ 1 ] Bug #1540388 - adapta-gtk-theme-3.93.0.103 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1540388
  [ 2 ] Bug #1539334 - adapta-gtk-theme-3.93.0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1539334
  [ 3 ] Bug #1537086 - adapta-gtk-theme-3.93.0.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1537086




 gnome-shell-extension-windowoverlay-icons-27-2.el7 
(FEDORA-EPEL-2018-e271543907)
 Show app icons on top of the windows thumbnails in Activities Overview

Update Information:

First accepted build of GNOME Shell extension WindowOverlay Icons.

References:

  [ 1 ] Bug #1506429 - Review Request: 
gnome-shell-extension-windowoverlay-icons - Show app icons on top of the 
windows thumbnails in Activities Overview
https://bugzilla.redhat.com/show_bug.cgi?id=1506429




 js-jsroot-5.3.5-1.el7 (FEDORA-EPEL-2018-c55e5addd6)
 JavaScript ROOT - Interactive numerical data analysis graphics

Update Information:

## Changes in 5.3.5 1. Fix - correctly show histogram with negative bins and
fill attributes (#143) 2. Fix - correct animation for status line (when visible)
3. Fix - correctly set lin/log settings back top TPad object 4. Fix - correctly
use preloaded d3.js in notebooks/require.js environment 5. Cached Latex regex to
improve drawing speed (#145)




 python-resultsdb_api-2.0.0-7.el7 (FEDORA-EPEL-2018-d20fad7b78)
 Interface api to ResultsDB

Update Information:

Python 2 binary package renamed to python2-resultsdb_api

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

Re: Fwd: Broken dependencies: python-biopython

[Kevin Fenzi]

On 02/05/2018 03:53 AM, Antonio Trande wrote:
> Hi all.
> 
> I'm still receiving this warning even if broken dependency should be
> corrected with the packaging release number 6:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1017574
> 
> Do you know why?

Should be fixed now. For some reason it was stuck in the signing tag...
I cleared all those out yesterday.

kevin




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

Re: Orphaned packages seeking new point of contact

[Sérgio Basto]

On Mon, 2018-02-05 at 16:11 +, Sérgio Basto wrote:
> I want take this one but I don't know how


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

[Bug 1536730] perl-DateTime-TimeZone-2.16 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1537829] perl-DateTime-TimeZone-2.17 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-DateTime-TimeZone-2.17-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1511913] perl-Crypt-OpenSSL-X509-1.808 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Crypt-OpenSSL-X509-1.808-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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: Orphaned packages seeking new point of contact

[Sérgio Basto]

On Fri, 2018-02-02 at 10:32 -0800, Kevin Fenzi wrote:
> rpms/gpm

I want take this one but don't now how , can we have a better wikipage
[1] ? please , it means that we should install fedrepo-req  ? and than
what should I run after ? 

Thanks.

[1] 
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_d
o_I_adopt_an_orphaned_package_or_unretire_a_package.3F

[2]
dnf -y install  fedrepo-req 


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

Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Jakub Cajka" 

Hi Jakub

> I think that it would be best if Nicolas could fold his proposal in to the 
> original draft as
> optional part for simple library/binary packages.

Frankly, that's a lot of work and churn, I don't want the new parts to be 
refused because of something in the old parts, and I certainly do not want to 
spend weeks replacing bits only to put them back in and so on while people made 
up their mind on the things they want replaced or not. The new parts are pretty 
much autonomous and complete, they are sufficient to create working Fedora Go 
packages, they are ready for FPC review.

If someone wants to extract the ready non discussion parts of the old page and 
get them approved I can work with him to merge both elements

I didn't want to write about the old page, but since you put it on the table.

It is full of digressions and elements of no evident applied value while 
packaging Go software. It's not an operational "how to do stuff" document it's 
a "here are various things you may like to know about Go that may or may not 
help you create Fedora Go packages, if they do not help you forget about it and 
run gofed". There are too many WIP non operational bits in the old pages to 
allow merging while in an approval process. And I'm sure any attempt to strip 
the WIP bits from my side will be met with energetic protests.

People, if you want that page to be ever approved by FPC make it more focused 
and accurate. Remove anything that does not explain to a Fedora Go packager how 
to write a Fedora Go spec file and what to ask upstream Go projects in a Fedora 
packager role. And make sure what remains is succinct, easy to read, and 
applicable without undocumented holes or gofed magic.

I know that's a lot of non-fun work. I did this work on the new page. I don't 
particularly *like* writing documentation. For every line I put in the new 
page, I had to ask myself "is the value to the Fedora packager sufficient to 
justify the time spend writing the text, formatting it, linking in the right 
place, proofing the result". I didn't put in stuff I could not justify cleaning 
up myself. If it was too much work to document it was either of insufficient 
value or better automated rather than explained in a manual process.

Any part of the text that can not be finished or serves another role has no 
place in a guideline submitted to FPC. It should be nuked or moved to a 
separate wiki page. All the half-finished and non operational stuff in there is 
the reason the draft has been stuck in pre-approval stage for four years. Just 
put yourself in FPC's place, its mission is to confirm a guideline is ready to 
be used by the average Fedora packager, not to produce it from half-finished 
half-related messy notes of the domain experts.

> As his proposal doesn't cover at least two major use cases, i.e. separate 
> packaging of tests(they
> have no place in devel package as they artificially inflate build root size)

At this point of time my mind is pretty much set. I won't do separate packaging 
of tests because:
1. that raises complex dependency handling questions 
2. the average Go project test code is full of crufty junk
3. the average Go test depends on assets not tracked within Go
4. Go is not designed to separate elements shipped in the same directory
5. no one could answer when I asked the *three* Fedora lists what they were 
using the existing test packages for
6. from what I've seen many of the existing test packages simply can not work 
because they fail to include elements they need
7. even core Go people refuse to touch the subject with a 10 foot pole. Sam 
Boyer tried to demo a very small part of what would be necessary this week end 
at FOSDEM and this part of his demo *failed*. I don't have the level of Go 
understanding Sam Boyer Has.

I am ready to work with people who want to make separate test packages and I 
tried very hard to make them possible in the future but I won't spend time 
trying to ship half-baked stuff that does not work and that no one has a need 
for.

The proposed patterns strip test code from devel packages so build root sizes 
are safe (except for the original package build root, since I *do* execute unit 
tests in check, and they pull their deps in the build root).

You want to test one of my packages, fine, just rebuild it. That will run unit 
tests *and* build the project binaries (which are also a form of code testing, 
and a very thorough one at that).

> and shipping pre-built shared libraries.

The pre-build shared libraries the old guidelines refuse to build or document? 
Why exactly are you stating it's a major use case, Fedora is not doing it today.

"By default, the standard golang compiler produces static libraries. There is 
little value in shipping these prebuilt, especially since these libraries are 
very specifically tied to the exact minor release of the golang compiler."

"Presently the shared object libraries 

Re: KDE print dialog does not see CUPS settings

[Rex Dieter]

Marcel Oliver wrote:

> Hallo,
> 
> I am posting the following to the devel list because it's an annoying
> bug, but I have no idea which component is reponsible to file a bug
> report on bugzilla...
> 
> Since I upgraded to F27, the KDE print dialog (for me the most
> relevant application is okular) fails to see the available printer
> options, nor does it see the printer defaults.  It also does not save
> changed settings from one print job to the next.  Other applications
> (firefox, libreoffice, evince, ...)  see the CUPS settings just fine.
> 
> This happens on the cinnamon desktop (Fedora cinnamon spin).
> 
> I do not know if this is a KDE problem,

It's a Qt problem, that's been fixed recently (in Qt 5.11 development 
branch).

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

Re: F27 strange rpmbuild failure

[Petr Viktorin]

On 02/04/2018 10:08 PM, Alec Leamas wrote:



On 04/02/18 21:36, Steve Grubb wrote:

On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:



Many questions here, and a large package. Still, searching the logs I
cannot see any python files - are there any such at all?


None at all. Its all java, javascript, R, and ELF files.


If not, perhaps  you could disable the byte compulation as described in
[1]?


Bingo! That fixed the build...which leads to the question of why is that
failing?


I think the basic answer is that the byte comoilation script is using
all sorts of strange heuristics. It seems that it determined a that a
non-python file was python.

Efforts are under way to redefine things and make the byte compilation
more explicit. Until this is done, this is probably not the last error
of this sort.

In other words, it's sort of a known bug with fixes under way, slowly...


I'd like to make sure any Python-related automation is limited to Python 
context (/usr/lib*/python*, files with python shebangs, etc.). I'm not 
sure why it's not this way now.


We're preparing a Change to fix this exact issue in Fedora 29. Started 
just last week, actually:

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

Up to this point I thought this was just a theoretical issue. Thank you 
for finding a concrete example -- and sorry it had to be you!



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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Mon, Feb 05, 2018 at 08:21:06AM +, Terry Barnaby wrote:
> On 01/02/18 08:29, Terry Barnaby wrote:
> > On 01/02/18 01:34, Jeremy Linton wrote:
> > > On 01/31/2018 09:49 AM, J. Bruce Fields wrote:
> > > > On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton wrote:
> > > > > Have you tried this with a '-o nfsvers=3' during mount? Did that help?
> > > > > 
> > > > > I noticed a large decrease in my kernel build times across
> > > > > NFS/lan a while
> > > > > back after a machine/kernel/10g upgrade. After playing with
> > > > > mount/export
> > > > > options filesystem tuning/etc, I got to this point of timing
> > > > > a bunch of
> > > > > these operations vs the older machine, at which point I
> > > > > discovered that
> > > > > simply backing down to NFSv3 solved the problem.
> > > > > 
> > > > > AKA a nfsv3 server on a 10 year old 4 disk xfs RAID5 on 1Gb
> > > > > ethernet, was
> > > > > slower than a modern machine with a 8 disk xfs RAID5 on 10Gb
> > > > > on nfsv4. The
> > > > > effect was enough to change a kernel build from ~45 minutes
> > > > > down to less
> > > > > than 5.
> > > > 
> > Using NFSv3 in async mode is faster than NFSv4 in async mode (still
> > abysmal in sync mode).
> > 
> > NFSv3 async: sync; time (tar -xf linux-4.14.15.tar.gz -C /data2/tmp;
> > sync)
> > 
> > real    2m25.717s
> > user    0m8.739s
> > sys 0m13.362s
> > 
> > NFSv4 async: sync; time (tar -xf linux-4.14.15.tar.gz -C /data2/tmp;
> > sync)
> > 
> > real    3m33.032s
> > user    0m8.506s
> > sys 0m16.930s
> > 
> > NFSv3 async: wireshark trace
> > 
> > No. Time   Source Destination   Protocol Length Info
> >   18527 2.815884979    192.168.202.2 192.168.202.1 NFS 
> > 216    V3 CREATE Call (Reply In 18528), DH: 0x62f39428/dma.h Mode:
> > EXCLUSIVE
> >   18528 2.816362338    192.168.202.1 192.168.202.2 NFS 
> > 328    V3 CREATE Reply (Call In 18527)
> >   18529 2.816418841    192.168.202.2 192.168.202.1 NFS 
> > 224    V3 SETATTR Call (Reply In 18530), FH: 0x13678ba0
> >   18530 2.816871820    192.168.202.1 192.168.202.2 NFS 
> > 216    V3 SETATTR Reply (Call In 18529)
> >   18531 2.816966771    192.168.202.2 192.168.202.1 NFS 
> > 1148   V3 WRITE Call (Reply In 18532), FH: 0x13678ba0 Offset: 0 Len: 934
> > FILE_SYNC
> >   18532 2.817441291    192.168.202.1 192.168.202.2 NFS 
> > 208    V3 WRITE Reply (Call In 18531) Len: 934 FILE_SYNC
> >   18533 2.817495775    192.168.202.2 192.168.202.1 NFS 
> > 236    V3 SETATTR Call (Reply In 18534), FH: 0x13678ba0
> >   18534 2.817920346    192.168.202.1 192.168.202.2 NFS 
> > 216    V3 SETATTR Reply (Call In 18533)
> >   18535 2.818002910    192.168.202.2 192.168.202.1 NFS 
> > 216    V3 CREATE Call (Reply In 18536), DH: 0x62f39428/elf.h Mode:
> > EXCLUSIVE
> >   18536 2.818492126    192.168.202.1 192.168.202.2 NFS 
> > 328    V3 CREATE Reply (Call In 18535)
> > 
> > This is taking about 2ms for a small file write rather than 3ms for
> > NFSv4. There is an extra GETATTR and CLOSE RPC in NFSv4 accounting for
> > the difference.
> > 
> > So where I am:
> > 
> > 1. NFS in sync mode, at least on my two Fedora27 systems for my usage is
> > completely unusable. (sync: 2 hours, async: 3 minutes, localdisk: 13
> > seconds).
> > 
> > 2. NFS async mode is working, but the small writes are still very slow.
> > 
> > 3. NFS in async mode is 30% better with NFSv3 than NFSv4 when writing
> > small files due to the increased latency caused by NFSv4's two extra RPC
> > calls.
> > 
> > I really think that in 2018 we should be able to have better NFS
> > performance when writing many small files such as used in software
> > development. This would speed up any system that was using NFS with this
> > sort of workload dramatically and reduce power usage all for some
> > improvements in the NFS protocol.
> > 
> > I don't know the details of if this would work, or who is responsible
> > for NFS, but it would be good if possible to have some improvements
> > (NFSv4.3 ?). Maybe:
> > 
> > 1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE
> > call all in one. This would reduce the latency of a small file to 1ms
> > rather than 3ms thus 66% faster. Would require the client to delay the
> > OPEN/SETATTR until the first WRITE. Not sure how possible this is in the
> > implementations. Maybe READ's could be improved as well but getting the
> > OPEN through quick may be better in this case ?
> > 
> > 2. Could go further with an OPEN-SETATTR-WRITE-CLOSE RPC call. (0.5ms vs
> > 3ms).
> > 
> > 3. On sync/async modes personally I think it would be better for the
> > client to request the mount in sync/async mode. The setting of sync on
> > the server side would just enforce sync mode for all clients. If the
> > server is in the default async mode clients can mount using sync or
> > async as to their requirements. This seems to match normal VFS 

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Jakub Cajka" 

> Our as Fedora or yours company/org? I believe that your contribution of those 
> in to Fedora will be much
> appreciated.

Our was meaning the set of specs we are preparing for inclusion. Can't really 
share them before the macros they depend on are merged in rawhide.

You can grab most of those from
https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging

before I nuke it to launch a new build from scratch (if seems a bit of grpc 
bootstraping failed this run so that's back to build log analysis, add 
constrains, scratch, retry, wait 3 days for the result. I s hate the yum 
version in copr, every time there is a dumb decision to make it will make it, 
it manages to make yum in EL7 look smart) 

> But IMHO even your changes will not change this, if you don't have few 
> dedicated packager around to
> do all the bidding.

Sure, the changes will only remove some barriers to new Go packagers, they 
can't replace those packagers, or the people who take care of the baseline core.

Regards,

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

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 12:47 PM, Guido Aulisi wrote:

2018-02-05 12:00 GMT+01:00 Petr Viktorin :

On 02/05/2018 09:32 AM, Guido Aulisi wrote:


Hi,
according to latest python guides, we should avoid calling generic
unversioned python command

(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been
downgraded.

Thanks



Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a
different error: "--freedesktop requires itstool > 2.0.0 to translate
files.".
Could you check if that's not causing the failure?


I found that the check for itstool fails because it gets the
deprecation warning as input, there's a mistake in
output = subprocess.Popen("itstool --version", shell=True,
stderr=subprocess.STDOUT,
stdout=subprocess.PIPE).communicate()[0].splitlines()
stderr is redirected to stdout, so itstool gets DEPRECATION and
version [u'WARNING:']
I will report this upstream, it seems to me that the redirection of
stderr is a mistake.


Ah! I see the problem now: /usr/bin/itstool has a /usr/bin/python 
shebang. I've filed a pull request that should fix this:

https://src.fedoraproject.org/rpms/itstool/pull-request/1


[...]


It looks like waf will be one of the tougher things to figure out. After the
mass rebuild we'll see the effect on the whole distribution, and hopefully
come up with a better strategy for bundled waf.


I will file a bug for waf, if it's the correct thing to do.


If you can wait a bit until itstool maintainers merge the PR, that 
should sort the problem out.

Let me know if you need this soon, I can look for a provenpackager.


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

Re: F28 Self Contained Change: Removing ldconfig scriptlets

[Rex Dieter]

Thomas Haller wrote:

> On Sun, 2018-02-04 at 09:08 -0600, Rex Dieter wrote:
>> Thomas Haller wrote:
>> 
>> > now, building network-manager-applet(fc28) on Fedora 27, it fails:
>> > 
>> > Full log written to /data/src/fedpkg/network-manager-
>> > applet/network-
>> > manager-applet-1.8.10/x86_64-redhat-linux-gnu/meson-
>> > logs/testlog.txt
>> > + %ldconfig_scriptlets -n libnma
>> > /var/tmp/rpm-tmp.YVXizL: line 40: fg: no job control
>> > error: Bad exit status from /var/tmp/rpm-tmp.YVXizL (%check)
>> > Bad exit status from /var/tmp/rpm-tmp.YVXizL (%check)
>> > 
>> > 
>> > This doesn't seem right. Can we fix this? It seems very convenient
>> > to
>> > be able to build a package for f28 across various Fedora versions,
>> > becauseredhat-rpm-config-70-1.fc27 that is how I test the
>> > package...
>> 
>> If you're building locally, do you actually have redhat-rpm-config-
>> 70-1.fc27
>> installed?   (It's currently still in updates-testing).
>> 
>> It is tagged as a koji buildroot override, so koji builds should get
>> it too.
>> 
> 
> Hi,
> 
> yes, redhat-rpm-config-70-1.fc27 fixes the build. Thanks.
> 
> As a suggestion, maybe not update packages in dist-git, before the
> required packages hit Fedora stable...

As far as I know, packages were updated only in master/ branch, where the 
required packages were already available.

-- Rex

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

KDE print dialog does not see CUPS settings

[Marcel Oliver]

Hallo,

I am posting the following to the devel list because it's an annoying
bug, but I have no idea which component is reponsible to file a bug
report on bugzilla...

Since I upgraded to F27, the KDE print dialog (for me the most
relevant application is okular) fails to see the available printer
options, nor does it see the printer defaults.  It also does not save
changed settings from one print job to the next.  Other applications
(firefox, libreoffice, evince, ...)  see the CUPS settings just fine.

This happens on the cinnamon desktop (Fedora cinnamon spin).

I do not know if this is a KDE problem, a problem with KDE integration
in Fedora in general, or with the cinnamon spin in particular, or
possibly related to CUPS, but would be willing to help debug the
issue.

It's not really serious, but pretty annoying and a regression of
something which definitely worked without issues for many years.

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

Re: Orphaned packages seeking new point of contact

[Josh Boyer]

On Fri, Feb 2, 2018 at 3:22 PM, Michael Schwendt  wrote:
> On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
>
>> rpms/gqview
>
> Really?!

Congratulations, you have just explained why absentee maintainers are
bad and why we orphan things.

> It is unmaintained for over 10 years.
>
> It has been forked into Geeqie (package "geeqie") roughly 10 years
> ago, and Geeqie at least has seen several releases since then.

Perhaps just take gqview and retire it then?

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

[Bug 1541736] perl-bignum-0.49 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-bignum-0.49-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb09627edc

-- 
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 1541186] perl-bignum-0.48 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-bignum-0.49-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb5050056

-- 
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 1541186] perl-bignum-0.48 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-bignum-0.49-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb09627edc

-- 
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 1541736] perl-bignum-0.49 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-bignum-0.49-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-dfb5050056

-- 
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 1541736] perl-bignum-0.49 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-bignum-0.49-1.fc28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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 1534885] perl-Dancer2-Plugin-DBIC-0.0100-1.fc28 FTBFS: Can' t call method "resultset" on an undefined value at /usr/share/perl5/ vendor_perl/DBIx/Class/Schema.pm line 547.

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-02-05 07:14: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

[Bug 1517785] perl-DBIx-Class-Schema-Loader-0.07047-3.fc28 FTBFS: tests crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-DBIx-Class-Schema-Load
   ||er-0.07048-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-05 07:10:46



--- Comment #2 from Petr Pisar  ---
Thank you for the notification.

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

Fwd: Broken dependencies: python-biopython

[Antonio Trande]

Hi all.

I'm still receiving this warning even if broken dependency should be
corrected with the packaging release number 6:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1017574

Do you know why?

 Forwarded Message 
Subject: Broken dependencies: python-biopython
Date: Sun,  4 Feb 2018 21:06:57 + (UTC)
From: build...@fedoraproject.org
To: python-biopython-ow...@fedoraproject.org



python-biopython has broken dependencies in the rawhide tree:
On x86_64:
python3-biopython-1.70-5.fc28.x86_64 requires python3-mysql-connector
On armhfp:
python3-biopython-1.70-5.fc28.armv7hl requires python3-mysql-connector
On ppc64le:
python3-biopython-1.70-5.fc28.ppc64le requires python3-mysql-connector
On aarch64:
python3-biopython-1.70-5.fc28.aarch64 requires python3-mysql-connector
On ppc64:
python3-biopython-1.70-5.fc28.ppc64 requires python3-mysql-connector
On s390x:
python3-biopython-1.70-5.fc28.s390x requires python3-mysql-connector
On i386:
python3-biopython-1.70-5.fc28.i686 requires python3-mysql-connector
Please resolve this as soon as possible.





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

Re: Ambiguous python version in waf

[Guido Aulisi]

2018-02-05 12:00 GMT+01:00 Petr Viktorin :
> On 02/05/2018 09:32 AM, Guido Aulisi wrote:
>>
>> Hi,
>> according to latest python guides, we should avoid calling generic
>> unversioned python command
>>
>> (https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)
>>
>> But what should we do if it's called inside waf? waf is provided
>> upstream, should we patch it to call either python2 or python3, or use
>> PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?
>>
>> I got this problem in recent ardour5 rawhide builds
>> (https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
>> Now I'm seeing that builds are back to normal and python2 has been
>> downgraded.
>>
>> Thanks
>
>
> Thanks for the question, and sorry for the inconvenience!
>
> The python2 message is, so far, only a warning. I see the log contains a
> different error: "--freedesktop requires itstool > 2.0.0 to translate
> files.".
> Could you check if that's not causing the failure?

I found that the check for itstool fails because it gets the
deprecation warning as input, there's a mistake in
output = subprocess.Popen("itstool --version", shell=True,
stderr=subprocess.STDOUT,
stdout=subprocess.PIPE).communicate()[0].splitlines()
stderr is redirected to stdout, so itstool gets DEPRECATION and
version [u'WARNING:']
I will report this upstream, it seems to me that the redirection of
stderr is a mistake.

> If the python2 message is breaking your build, then please file a bug and
> set an environment variable, as described in the Change. (Do file the bug,
> though – that ensures we'll contact you before we remove the workaround.)

> Background:
>
> We do want everyone to avoid calling /usr/bin/python, but we realize it's
> not always easy. That's why we added the warning -- it will allow us to grep
> the logs to figure out what is using it (and why). And of course, in simple
> cases it can be fixed right away.
> Some tools do fail if there's extra output on stderr; that's the reason for
> the "Quick Opt-Out" workaround.
>
> It looks like waf will be one of the tougher things to figure out. After the
> mass rebuild we'll see the effect on the whole distribution, and hopefully
> come up with a better strategy for bundled waf.

I will file a bug for waf, if it's the correct thing to do.

> --
> Petr Viktorin

Many thanks for your reply

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

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> , "Discussion of RPM packaging
> standards and practices for Fedora" 
> Sent: Monday, February 5, 2018 12:16:14 PM
> Subject: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> > I think one of the main responsibilities of Fedora packager is to work with
> > upstreams, help them
> > mature and generally improve their projects.
> 
> Sure but expecting everything to be perfect and consistent before shipping
> anything just DOES NOT WORK. Reality is not black and white, it's messy with
> shades of gray
> 
> Even the C/C++ guys do not manage to ship a compat-free package ecosystem,
> and their projects had a few more decades than Go projects to mature, and
> rpm was pretty much built around C/C++ expectations.
> 
> Compat packages are a fact of life in any large software ecosystem, where you
> can't achieve perfect cohesion. Go is getting *very* large. It needs compat
> packages. That does not mean there will be hundreds of them because,
> creating packages is *work*, that does not need they will need maintaining
> for years, because the aim of each compat package is to get obsoleted as
> fast as possible, but there will always be some of them at any given time.
> We are not building a cathedral. Bazaars are messy when full of life.
> 
> > Do you have any evidence supporting this claim? From my point of view Jan
> > and other packages has
> > been spending lot of time on on boarding packagers and working on tooling.
> 
> No one (and certainly not me) is accusing you or Jan not to spend a crazy
> amount of time and energy trying to make things work. But you did not
> achieve a satisfactory Go state in Fedora, read again what Owen wrote, I
> didn't put any word in his mouth, even though I could have written pretty
> much the same message a few months ago.
> 
> Again, no one (and certainly not me) disputes your level of dedication to the
> "cause". You just made some choices in the past (trying to avoid working
> within rpm via godep, refusing to include different states of the same Go
> code in the distro when major Go apps *disagree* on the correct state to
> include) that didn't work out in practice, with the hindsight of several
> years of Fedora Go packaging and the Go package state achieved in Fedora
> after those years.
> 
> It's time to adjust those choices a bit.
> 
> > From my perspective distribution will end up with crazy amount of
> > bitrotting, backport, constant
> > attention requiring package crud..., IMHO basically same as now, apart of
> > it we will have few 1000s
> > of Go based packages with compat names nobody cares about, instead of
> > current 500 or so packages.
> 
> Fedora has lots of Go packages no one cares about because they do not permit
> building the apps people *do* care about.
> 
> Building the apps people care about requires a more aggressive update policy,
> and accepting people will work in parallel on apps, that demand different
> code states, of common dependencies. And there are not so many of those, I
> count 18 of them in our repo out of 476 Go packages, even though the work is
> not completely finished, and finalizing the build of complex tip apps is
> almost certain to increase the proportion a little. That's awfully *good*
> and *nice* given the "no Go API compatibility" scarecrows people like to
> invoke.
> 
> You won't *ever* attract a large pool of packagers, to work on a package
> baseline, that will eventually in some years permit building apps, but never
> this year, because upstream state is not conflict and compat-free yet.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> 

Our as Fedora or yours company/org? I believe that your contribution of those 
in to Fedora will be much appreciated.
But IMHO even your changes will not change this, if you don't have few 
dedicated packager around to do all the bidding.

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

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Jakub Cajka" 

> I think one of the main responsibilities of Fedora packager is to work with 
> upstreams, help them
> mature and generally improve their projects.

Sure but expecting everything to be perfect and consistent before shipping 
anything just DOES NOT WORK. Reality is not black and white, it's messy with 
shades of gray

Even the C/C++ guys do not manage to ship a compat-free package ecosystem, and 
their projects had a few more decades than Go projects to mature, and rpm was 
pretty much built around C/C++ expectations.

Compat packages are a fact of life in any large software ecosystem, where you 
can't achieve perfect cohesion. Go is getting *very* large. It needs compat 
packages. That does not mean there will be hundreds of them because, creating 
packages is *work*, that does not need they will need maintaining for years, 
because the aim of each compat package is to get obsoleted as fast as possible, 
but there will always be some of them at any given time. We are not building a 
cathedral. Bazaars are messy when full of life.

> Do you have any evidence supporting this claim? From my point of view Jan and 
> other packages has
> been spending lot of time on on boarding packagers and working on tooling.

No one (and certainly not me) is accusing you or Jan not to spend a crazy 
amount of time and energy trying to make things work. But you did not achieve a 
satisfactory Go state in Fedora, read again what Owen wrote, I didn't put any 
word in his mouth, even though I could have written pretty much the same 
message a few months ago.

Again, no one (and certainly not me) disputes your level of dedication to the 
"cause". You just made some choices in the past (trying to avoid working within 
rpm via godep, refusing to include different states of the same Go code in the 
distro when major Go apps *disagree* on the correct state to include) that 
didn't work out in practice, with the hindsight of several years of Fedora Go 
packaging and the Go package state achieved in Fedora after those years.

It's time to adjust those choices a bit.

> From my perspective distribution will end up with crazy amount of bitrotting, 
> backport, constant
> attention requiring package crud..., IMHO basically same as now, apart of it 
> we will have few 1000s
> of Go based packages with compat names nobody cares about, instead of current 
> 500 or so packages.

Fedora has lots of Go packages no one cares about because they do not permit 
building the apps people *do* care about.

Building the apps people care about requires a more aggressive update policy, 
and accepting people will work in parallel on apps, that demand different code 
states, of common dependencies. And there are not so many of those, I count 18 
of them in our repo out of 476 Go packages, even though the work is not 
completely finished, and finalizing the build of complex tip apps is almost 
certain to increase the proportion a little. That's awfully *good* and *nice* 
given the "no Go API compatibility" scarecrows people like to invoke.

You won't *ever* attract a large pool of packagers, to work on a package 
baseline, that will eventually in some years permit building apps, but never 
this year, because upstream state is not conflict and compat-free yet.

Regards,

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

Re: Ambiguous python version in waf

[Petr Viktorin]

On 02/05/2018 09:32 AM, Guido Aulisi wrote:

Hi,
according to latest python guides, we should avoid calling generic
unversioned python command
(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been downgraded.

Thanks


Thanks for the question, and sorry for the inconvenience!

The python2 message is, so far, only a warning. I see the log contains a 
different error: "--freedesktop requires itstool > 2.0.0 to translate 
files.".

Could you check if that's not causing the failure?

If the python2 message is breaking your build, then please file a bug 
and set an environment variable, as described in the Change. (Do file 
the bug, though – that ensures we'll contact you before we remove the 
workaround.)



Background:

We do want everyone to avoid calling /usr/bin/python, but we realize 
it's not always easy. That's why we added the warning -- it will allow 
us to grep the logs to figure out what is using it (and why). And of 
course, in simple cases it can be fixed right away.
Some tools do fail if there's extra output on stderr; that's the reason 
for the "Quick Opt-Out" workaround.


It looks like waf will be one of the tougher things to figure out. After 
the mass rebuild we'll see the effect on the whole distribution, and 
hopefully come up with a better strategy for bundled waf.



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

Re: Packaging wiki: shortcoming in Github Source0 (?)

[Michael Šimáček]

On 2018-02-02 17:52, Jason L Tibbitts III wrote:

"PM" == Panu Matilainen  writes:


PM> Yes spectool was recommended by somebody else already, but
PM> ultimately only rpm itself can truly parse a spec, spectool is just
PM> a rough approximation (but usually does work in the more common
PM> cases, yes)

Actually the current spectool uses rpm to parse the spec (as it calls
rpmbuild -bp with a number of additional options).  It would probably be
simpler if it called rpmspec -P as my python rewrite of it from years
ago did, but right now it really should just work for everything that
rpm can parse.  And at least it seems to be able to handle expansions of
significant complexity without problems.



It currently doesn't work for everything that rpm can parse. For an 
example, see nasm [0].


msimacek ~/rpms/nasm (master) $ /usr/bin/spectool --debug -g nasm.spec
temp dir: /tmp/spectool_TU_klSJmj3
temp spec filename: /tmp/spectool_TU_klSJmj3/spec_hSY36atjuD
stderr filename: /tmp/spectool_TU_klSJmj3/stderr_2MEZDwuZkx
msimacek ~/rpms/nasm (master) $ cat 
/tmp/spectool_TU_klSJmj3/stderr_2MEZDwuZkx

error: line 68: Unclosed %if

So, I'd definitely appreciate if your rewrite went upstream.

[0] https://src.fedoraproject.org/rpms/nasm/blob/master/f/nasm.spec


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

Re: Self Introduction Matthew Ruszczyk (mruszczyk) NEEDSPONSOR / NEEDREVIEW

[Charalampos Stratakis]

Hello Matthew and welcome!

- Original Message -
> From: "Matthew Ruszczyk" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, February 2, 2018 11:18:38 PM
> Subject: Self Introduction Matthew Ruszczyk (mruszczyk) NEEDSPONSOR / 
> NEEDREVIEW
> 
> Hello,
> My name is Matthew, I'm interested in joining the Fedora Packagers Group to
> package a piece of software called whipper. I am a 27 year old network
> administrator at a small company in Pennsylvania, US. I've dabbled in open
> source software for years and Fedora has been my main distribution for a
> large chunk of that time. I love it's focus on cutting edge technology.
> 
> I have been working to package an application called whipper that I hope to
> get into fedora proper. It is a fork of an older application called morituri
> that is focused on ripping CDs accurately using libcdio-paranoia. Up until
> now the package clobbered an existing morituri install so I was hesitant to
> submit it but today they tagged a new release that fixes that issue. I
> largely began packaging it for my own needs but would love to give back to
> the fedora community and maintain it properly. I'm most often found in
> #whipper on freenode if anyone has any questions for me.
> 
> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1541566
> COPR: https://copr.fedorainfracloud.org/coprs/mruszczyk/whipper/
> Repo: https://github.com/JoeLametta/whipper
> 
> I hope I can get some constructive criticism and be a valued member of this
> community.
> 
> Matthew
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Removing ldconfig scriptlets

[Thomas Haller]

On Sun, 2018-02-04 at 09:08 -0600, Rex Dieter wrote:
> Thomas Haller wrote:
> 
> > now, building network-manager-applet(fc28) on Fedora 27, it fails:
> > 
> > Full log written to /data/src/fedpkg/network-manager-
> > applet/network-
> > manager-applet-1.8.10/x86_64-redhat-linux-gnu/meson-
> > logs/testlog.txt
> > + %ldconfig_scriptlets -n libnma
> > /var/tmp/rpm-tmp.YVXizL: line 40: fg: no job control
> > error: Bad exit status from /var/tmp/rpm-tmp.YVXizL (%check)
> > Bad exit status from /var/tmp/rpm-tmp.YVXizL (%check)
> > 
> > 
> > This doesn't seem right. Can we fix this? It seems very convenient
> > to
> > be able to build a package for f28 across various Fedora versions,
> > becauseredhat-rpm-config-70-1.fc27 that is how I test the
> > package...
> 
> If you're building locally, do you actually have redhat-rpm-config-
> 70-1.fc27 
> installed?   (It's currently still in updates-testing).
> 
> It is tagged as a koji buildroot override, so koji builds should get
> it too.
> 

Hi,

yes, redhat-rpm-config-70-1.fc27 fixes the build. Thanks.

As a suggestion, maybe not update packages in dist-git, before the
required packages hit Fedora stable...

best,
Thomas

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

Re: gobject-introspection broken requires

[Vít Ondruch]

I had different case with weird shebang in template:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/16

I think that the brp-mangle-shebangs script should be more careful with
the shebangs. If the shebang contains slashes or some other weird
characters, it should fail the build rather then breaking the package.


Vít


Dne 3.2.2018 v 14:23 Richard Shaw napsal(a):
> DEPRECATION WARNING: python2 invoked with /usr/bin/python.
>     Use /usr/bin/python3 or /usr/bin/python2
>     /usr/bin/python will be removed or switched to Python 3 in the future.
>     If you cannot make the switch now, please follow instructions at
> https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out
> DEPRECATION WARNING: python2 invoked with /usr/bin/python.
>     Use /usr/bin/python3 or /usr/bin/python2
>     /usr/bin/python will be removed or switched to Python 3 in the future.
>     If you cannot make the switch now, please follow instructions at
> https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out
> + /usr/lib/rpm/brp-python-hardlink
> + /usr/lib/rpm/redhat/brp-mangle-shebangs
> *** WARNING: mangling shebang in ./usr/bin/g-ir-scanner from
> #!/usr/bin/env /usr/bin/python to #!/usr/bin//usr/bin/python2. This
> will become an ERROR, fix it manually!
> *** WARNING: mangling shebang in ./usr/bin/g-ir-annotation-tool from
> #!/usr/bin/env /usr/bin/python to #!/usr/bin//usr/bin/python2. This
> will become an ERROR, fix it manually!
> *** WARNING: mangling shebang in ./usr/bin/g-ir-doc-tool from
> #!/usr/bin/env /usr/bin/python to #!/usr/bin//usr/bin/python2. This
> will become an ERROR, fix it manually!
> Processing files: gobject-introspection-1.54.1-3.fc28.x86_64
>
> Looks like brp-mangle-shebangs incorrectly updated the python
> invocation. Since this requirement cannot be met it's breaking any
> package from building that depends on it.
>
>
> Thanks,
> Richard
>
>
> ___
> 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: Packaging wiki: shortcoming in Github Source0 (?)

[Panu Matilainen]

On 02/02/2018 04:51 PM, Tomasz Kłoczko wrote:
On 2 February 2018 at 08:49, Panu Matilainen > wrote:

[..]

You need to download Source0 first.
Try:

$ wget -P ~/rpmbuild/SOURCES $(rpmbuild -bp --define "prep
%dump" bettercap.spec 2>&1 | awk '/SOURCEURL0/ {print $3}')


That's a rather arcane way of getting something out of the spec, you
might want to give 'rpmspec --parse' a try. Eg

$ rpmspec --parse rpm.spec |awk '/Source/ {print $2}'
http://rpm.org/releases/testing/rpm-4.14.90-git14108.tar.bz2



Just try to change in the spec file s/Source/SOurce/ and you will find 
that your onliner will fail when mine still will be working.


And case-sensitivity on matching is of course is an insurmountable 
problem to solve...


/me rolls eyes

Use whatever works for you, I just felt obliged to point out that there 
is an actually "official" rpm upstream tool for obtaining information 
from the spec, without relying on arcane hacks that rely on what amounts 
to a flaw in rpm (ability to redefine section names).


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

Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> 
> Sent: Friday, February 2, 2018 4:54:10 PM
> Subject: Re: Proposed Fedora packaging guideline:  More Go packaging
> 
> On mardi 30 janvier 2018 16:11:49 CET nicolas.mail...@laposte.net wrote:
> > Hi,
> > 
> > Now the technical PR is submitted
> > https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1
> > 
> > and waiting for action from the go-srpm-macros maintainers, I took (quite a
> > long) time to refresh and flesh out the corresponding packaging guidelines
> > proposal. It should be fairly complete now:
>  
> > https://fedoraproject.org/wiki/More_Go_packaging
> > 
> > I'd appreciate review to check if I have forgotten an important case, if
> > people understand the text, if they have enhancements or corrections to
> > propose, and so on.
>  
> > Then I will push it FPC side again.
> > 
> > Actual practice should be fairly simple and self-explanatory, the proposal
> > length can be scary but that's because it documents all kinds of corner
> > cases that required digging through specs and mailing lists to find
> > resolution examples before. The basic Go packaging skeleton will be
> > sufficient is most cases without requiring to read any documentation.
>  
> > Regards,
> > 
> > --
> > Nicolas Mailhot
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Hello Nicolas,
> 
> Could you add two full examples, one for binary package, one for library
> package, like in https://fedoraproject.org/wiki/PackagingDrafts/
> Go#Sample_RPM_Spec
> 
> Putting it all together (https://fedoraproject.org/wiki/
> More_Go_packaging#Putting_it_all_together) is nice but don't understand if it
> is for a binary or a library.
> 
> Also, is there any plan to update Gofed with these new guidelines? If it's
> not
> automated like today, we will lose time instead of gaining some in the end.
> 
> Best regards,
> 
> Robert-André
> 

I think that it would be best if Nicolas could fold his proposal in to the 
original draft as optional part for simple library/binary packages.

As his proposal doesn't cover at least two major use cases, i.e. separate 
packaging of tests(they have no place in devel package as they artificially 
inflate build root size) and shipping pre-built shared libraries.

Just my opinion,

JC

> ___
> 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 1541674] perl-Email-Address-XS-1.02 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Email-Address-XS-1.02-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-aeeeffea84

-- 
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] Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" 
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> , "Discussion of RPM packaging
> standards and practices for Fedora" 
> Sent: Saturday, February 3, 2018 4:27:36 PM
> Subject: Re:  [Fedora-packaging] Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> De: "Jakub Cajka"
> 
> Hi Jakub
> 
> > I'm strongly against general unrestricted practice of compat packages as
> > proposed. If you need compat package you
> > need to work with usptreams on stabilizing the API/project, fork it, or
> > just use COPR as your projects(or its
> > dependencies) are not yet mature enough for Fedora.
> 
> I appreciate the sentiment, and I quite hate compat packages, but the
> restrictions you want did not work in practice for Fedora.
> 
> Making compat package creation hard does not result in faster fixing to use
> new code. What it actually does is to block the packaging of all the
> projects that need a more recent package state, because packagers that need
> the old state for one of their packages, will drag their feet on updating
> common dependencies till the code of their packages is fixed upstream, or
> they have the time to fix it themselves.
> 

I think one of the main responsibilities of Fedora packager is to work with 
upstreams, help them mature and generally improve their projects.

> And blocking packaging of new part means you do not get the new packagers
> that would join because they're interested in the new parts, and would
> contribute to the maintenance of common deps (not all of which need
> compat-ing), and would relieve part of the pressure on the existing
> packagers, that prevents them from working as much a they'd like to on
> updating their packages. It's a death spiral. It results in a massively
> obsolete Go package baselines, full of holes, because all the energy is
> poured in making existing stuff work, at the expense of onboarding new
> packages and packagers.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 

Do you have any evidence supporting this claim? From my point of view Jan and 
other packages has been spending lot of time on on boarding packagers and 
working on tooling.
From my perspective distribution will end up with crazy amount of bitrotting, 
backport, constant attention requiring package crud..., IMHO basically same as 
now, apart of it we will have few 1000s of Go based packages with compat names 
nobody cares about, instead of current 500 or so packages.

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

[Bug 1541674] perl-Email-Address-XS-1.02 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Email-Address-XS-1.02-
   ||1.fc28



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

Ambiguous python version in waf

[Guido Aulisi]

Hi,
according to latest python guides, we should avoid calling generic
unversioned python command
(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been downgraded.

Thanks

Guido Aulisi
FAS: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Chris Murphy]

http://vger.kernel.org/vger-lists.html#linux-nfs



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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Terry Barnaby]

On 01/02/18 08:29, Terry Barnaby wrote:

On 01/02/18 01:34, Jeremy Linton wrote:

On 01/31/2018 09:49 AM, J. Bruce Fields wrote:

On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton wrote:

Have you tried this with a '-o nfsvers=3' during mount? Did that help?

I noticed a large decrease in my kernel build times across NFS/lan 
a while
back after a machine/kernel/10g upgrade. After playing with 
mount/export
options filesystem tuning/etc, I got to this point of timing a 
bunch of
these operations vs the older machine, at which point I discovered 
that

simply backing down to NFSv3 solved the problem.

AKA a nfsv3 server on a 10 year old 4 disk xfs RAID5 on 1Gb 
ethernet, was
slower than a modern machine with a 8 disk xfs RAID5 on 10Gb on 
nfsv4. The
effect was enough to change a kernel build from ~45 minutes down to 
less

than 5.


Using NFSv3 in async mode is faster than NFSv4 in async mode (still 
abysmal in sync mode).


NFSv3 async: sync; time (tar -xf linux-4.14.15.tar.gz -C /data2/tmp; 
sync)


real    2m25.717s
user    0m8.739s
sys 0m13.362s

NFSv4 async: sync; time (tar -xf linux-4.14.15.tar.gz -C /data2/tmp; 
sync)


real    3m33.032s
user    0m8.506s
sys 0m16.930s

NFSv3 async: wireshark trace

No. Time   Source Destination   Protocol Length Info
  18527 2.815884979    192.168.202.2 192.168.202.1 NFS  
216    V3 CREATE Call (Reply In 18528), DH: 0x62f39428/dma.h Mode: 
EXCLUSIVE
  18528 2.816362338    192.168.202.1 192.168.202.2 NFS  
328    V3 CREATE Reply (Call In 18527)
  18529 2.816418841    192.168.202.2 192.168.202.1 NFS  
224    V3 SETATTR Call (Reply In 18530), FH: 0x13678ba0
  18530 2.816871820    192.168.202.1 192.168.202.2 NFS  
216    V3 SETATTR Reply (Call In 18529)
  18531 2.816966771    192.168.202.2 192.168.202.1 NFS  
1148   V3 WRITE Call (Reply In 18532), FH: 0x13678ba0 Offset: 0 Len: 
934 FILE_SYNC
  18532 2.817441291    192.168.202.1 192.168.202.2 NFS  
208    V3 WRITE Reply (Call In 18531) Len: 934 FILE_SYNC
  18533 2.817495775    192.168.202.2 192.168.202.1 NFS  
236    V3 SETATTR Call (Reply In 18534), FH: 0x13678ba0
  18534 2.817920346    192.168.202.1 192.168.202.2 NFS  
216    V3 SETATTR Reply (Call In 18533)
  18535 2.818002910    192.168.202.2 192.168.202.1 NFS  
216    V3 CREATE Call (Reply In 18536), DH: 0x62f39428/elf.h Mode: 
EXCLUSIVE
  18536 2.818492126    192.168.202.1 192.168.202.2 NFS  
328    V3 CREATE Reply (Call In 18535)


This is taking about 2ms for a small file write rather than 3ms for 
NFSv4. There is an extra GETATTR and CLOSE RPC in NFSv4 accounting for 
the difference.


So where I am:

1. NFS in sync mode, at least on my two Fedora27 systems for my usage 
is completely unusable. (sync: 2 hours, async: 3 minutes, localdisk: 
13 seconds).


2. NFS async mode is working, but the small writes are still very slow.

3. NFS in async mode is 30% better with NFSv3 than NFSv4 when writing 
small files due to the increased latency caused by NFSv4's two extra 
RPC calls.


I really think that in 2018 we should be able to have better NFS 
performance when writing many small files such as used in software 
development. This would speed up any system that was using NFS with 
this sort of workload dramatically and reduce power usage all for some 
improvements in the NFS protocol.


I don't know the details of if this would work, or who is responsible 
for NFS, but it would be good if possible to have some improvements 
(NFSv4.3 ?). Maybe:


1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE 
call all in one. This would reduce the latency of a small file to 1ms 
rather than 3ms thus 66% faster. Would require the client to delay the 
OPEN/SETATTR until the first WRITE. Not sure how possible this is in 
the implementations. Maybe READ's could be improved as well but 
getting the OPEN through quick may be better in this case ?


2. Could go further with an OPEN-SETATTR-WRITE-CLOSE RPC call. (0.5ms 
vs 3ms).


3. On sync/async modes personally I think it would be better for the 
client to request the mount in sync/async mode. The setting of sync on 
the server side would just enforce sync mode for all clients. If the 
server is in the default async mode clients can mount using sync or 
async as to their requirements. This seems to match normal VFS 
semantics and usage patterns better.


4. The 0.5ms RPC latency seems a bit high (ICMP pings 0.12ms) . Maybe 
this is worth investigating in the Linux kernel processing (how ?) ?


5. The 20ms RPC latency I see in sync mode needs a look at on my 
system although async mode is fine for my usage. Maybe this ends up as 
2 x 10ms drive seeks on ext4 and is thus expected.


Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a 
certain NFS mounted directory over a slow link (NFS over Openvpn over 
FTTP 80/20Mbps), just after mounting the file 

Re: gnome crashes after today upgrade

[Chris Murphy]

On Sat, Feb 3, 2018 at 5:53 PM, Tomasz Kłoczko  wrote:
> On 3 February 2018 at 22:55, Richard Shaw  wrote:
>>
>> Any news on the cause? I'm waiting to update until this is figured out...
>
>
> Still don't see any update about the issue.
> It is really pain in the a*s that Linux still has no good support to handle
> such cases like it is on for example on Solaris where is possible to
> generate using zfs snapshots and cloning separated BEs (boot environments)
> on each upgrade or even new package install which adds to grub menu new boot
> entry which allows preserve 100% state from before any packages operations.

It's not a Linux limitation, the infrastructure is there. SUSE has had
state preserving rollbacks for several years. Their Btrfs patches for
GRUB, which I think are now upstream so we might also have them,
discover Btrfs snapshots made by snapper before and after every
package change, and build menu entries for each snapshot. Pick one,
and you get a read only one time rollback to the chosen snapshot.

Fedora repo does have both snapper and a dnf snapper plugin that'll
take snapshots of rootfs before any dnf update, and it's possible to
use snapper to rollback - I've only ever done it with a Btrfs rootfs
but I think snapper also supports LVM thinly provisioned volumes and
snapshots. The gotcha compared to what SUSE folks are doing is, on
Fedora it's possible (likely) to get a disconnect between the kernels
located in /boot vs the modules installed on the rolledback rootfs,
because /boot is not snapshot along with rootfs on Fedora since
they're separate file systems. So that'll inevitably snare things
unless you manually 'cp -a --reflink' copy the latest modules dir from
a current tree into a rolledback tree. And the reason for this is the
Fedora installer enforces /boot being on a plain ext4 or XFS volume,
it can't be on Btrfs due to a now 6+ year old grubby bug that causes
grubby to not update grub.cfg if /boot is a Btrfs subvolume.


> Just checked a bit dnf documentation and seems that dnf supports rollback
> operation. However as long as Fedora repo holds only latest versions of the
> each package I'm only curious how it is handled as rpm no longer supports
> repackage and rollback operations (?).

I've never tried doing rollbacks from dnf itself. If I need to
rollback, I just pick one I'm doing to rollback to, update the fstab
inside that snapshot to reflect the correct snapshot/subvolume name
used by the subvol= mount option, reboot, and then I manually edit the
boot entry's rootflags=subvol= parameter to reflect the name of the
snapshot I want to boot. Done, I've rolled back.

Of course you've just rolled back everything except home. So even your
journal log is rolledback on Fedora since it's located in the root
subvolume, whereas on SUSE they've got one of the longest fstabs
mankind has imagined, in order to carve out with a scalpel exactly
what is and is not subject to rollbacks.


>
> Can someone share some details how to use dnf rollback and/or is it now
> supported by Fedora rawhide?
> Issues like this one with crashing gnome may happen always an no one should
> be bashing anyone for such faults as rawhide is devel by definition however
> details about how system needs to be prepared to handle rollback using dnf
> are quite important.

I'm seeing it in Fedora 27.

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