Re: Requires for local install

2017-09-23 Thread Matthew Miller 
On Fri, Sep 22, 2017 at 09:47:15PM -0400, David Muse wrote:
> But, when doing a yum localinstall or dnf install with a local path,
> the user has to either install all rpm's or manually resolve
> dependencies.
> 
> Is it common to specify inter-subpackage dependencies using Requires
> to resolve this, or are users just on their own if they're
> installing packages manually?

You should certainly use inter-subpackage requires in any case, if they
are genuine. But that won't help DNF (or Yum), as with local install
they only know about the files they are told about. But, what you
*could* do is:

 1. run "createrepo_c" on your directory of downloaded RPMs,
 2. use `dnf --repofrompath local,.`, and then
 3. use `dnf install packagename`

In step 1, createrepo_c is a drop-in but faster replacement for
createrepo.

In step 2, the syntax is "--repofrompath made-reponame,path", so you
could do '--repofrompath "My Repository",/home/mattdm/Downloads/RPMs'.

In step 3, use the package name not the file name, so no .rpm on the
end.

-- 
Matthew Miller

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

Re: Improving Linux laptop battery life: Testers Wanted

2017-09-23 Thread Germano Massullo 
This message may be useful to others having my similar problem.
On a Thinkpad X220, after having booted the custom kernel, running

[root@machine]# cat /sys/class/scsi_host/host0/link_power_management_policy

I get

max_performance

instead of

med_power_with_dipm


Here some machine details

[root@machine]# cat /etc/rc.d/rc.local
#!/bin/sh

for i in /sys/class/scsi_host/host*/link_power_management_policy; do
    echo med_power_with_dipm > $i
done


[root@machine]# ls -latr /etc/rc.d/rc.local
-rwxrwxr-x. 1 user user 119 13 set 14.53 /etc/rc.d/rc.local


[root@machine]# cat /proc/cpuinfo | grep "model name"
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name  : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz


[root@machine]# cat /sys/class/scsi_device/*/device/model
Samsung SSD 850
(it is a Samsung 850 PRO)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

2017-09-23 Thread Michael Catanzaro 
On Fri, Sep 22, 2017 at 4:43 PM, Fabio Valentini  
wrote:
For what it's worth: I just installed the 4.13.2 kernel from the 
kernel-stabilization repo, and the nvidia akmod module (from 
negativo17 repo) failed to build (as expected). But after rebooting 
with the new kernel, the system uses the fallback to nouveau 
correctly - without any manual intervention. So, from my point of 
view, it seems everything works as it is supposed to (well, except 
the compilation failure, but that's got nothing to do with fedora).


Awesome, thanks very much for testing it.

I don't think we have any problem here then.

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

Re: Broken perl-libwww-perl-6.27-1.fc28

2017-09-23 Thread Richard W.M. Jones 
On Fri, Sep 22, 2017 at 11:29:53AM +, Petr Pisar wrote:
> I accidentally build perl-libwww-perl-6.27-1.fc28 that cannot be
> installed because of broken dependencies. There is already
> perl-libwww-perl-6.27-2.fc28 that fixes, but it still has not yet get
> into f28-build target.
> 
> Hopefully next compose will resolve it because it looks like after
> introducing the rawhide autosigning packagers are unable to untag
> thier builds:
> 
> $ koji untag f28 perl-libwww-perl-6.27-1.fc28
> ActionNotAllowed: tag requires autosign permission

I filed a bug about this earlier today having not read this thread until
this moment:

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

Who can tag the new build?  It's blocking builds of anything that
requires LWP.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken perl-libwww-perl-6.27-1.fc28

2017-09-23 Thread Kevin Fenzi 
On 09/23/2017 01:02 PM, Richard W.M. Jones wrote:
> On Fri, Sep 22, 2017 at 11:29:53AM +, Petr Pisar wrote:
>> I accidentally build perl-libwww-perl-6.27-1.fc28 that cannot be
>> installed because of broken dependencies. There is already
>> perl-libwww-perl-6.27-2.fc28 that fixes, but it still has not yet get
>> into f28-build target.
>>
>> Hopefully next compose will resolve it because it looks like after
>> introducing the rawhide autosigning packagers are unable to untag
>> thier builds:
>>
>> $ koji untag f28 perl-libwww-perl-6.27-1.fc28
>> ActionNotAllowed: tag requires autosign permission
> 
> I filed a bug about this earlier today having not read this thread until
> this moment:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1494814
> 
> Who can tag the new build?  It's blocking builds of anything that
> requires LWP.

Sorry for the delay here. I marked this yesterday to look at, but then
got sidetracked.

I just got it retagged and signed and it should appear in the buildroot
soon and in tomorrow's compose.

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

Fedora 27-20170923.n.0 compose check report

2017-09-23 Thread Fedora compose checker 
Missing expected images:

Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 7/128 (x86_64), 2/18 (i386), 1/2 (arm)

New failures (same test did not fail in 27-20170922.n.0):

ID: 146379  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/146379
ID: 146385  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146385
ID: 146392  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/146392
ID: 146406  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146406
ID: 146416  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/146416
ID: 146423  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146423
ID: 146425  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/146425
ID: 146467  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/146467
ID: 146499  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/146499
ID: 146503  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/146503

Soft failed openQA tests: 2/128 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 146396  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/146396
ID: 146415  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/146415

Passed openQA tests: 79/128 (x86_64), 16/18 (i386)

New passes (same test did not pass in 27-20170922.n.0):

ID: 146370  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/146370
ID: 146371  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/146371
ID: 146372  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/146372
ID: 146373  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/146373
ID: 146374  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/146374
ID: 146375  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/146375
ID: 146376  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/146376
ID: 146377  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/146377
ID: 146378  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/146378
ID: 146380  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/146380
ID: 146381  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/146381
ID: 146382  Test: x86_64 Server-dvd-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/146382
ID: 146383  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/146383
ID: 146384  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/146384
ID: 146386  Test: x86_64 Server-dvd-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/146386
ID: 146387  Test: x86_64 Server-dvd-iso server_database_client
URL: https://openqa.fedoraproject.org/tests/146387
ID: 146390  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/146390
ID: 146393  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/146393
ID: 146394  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/146394
ID: 146395  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/146395
ID: 146397  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/146397
ID: 146398  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/146398
ID: 146399  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/146399
ID: 146400  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/146400
ID: 146401  Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/146401
ID: 146402  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproje

Re: Rawhide SONAME change in audacious-libs package

2017-09-23 Thread Michael Schwendt 
On Sat, 2 Sep 2017 20:25:25 +0200, Michael Schwendt wrote:

> Anything depending on Audacious libaudcore will need a rebuild due to a
> SONAME change from libaudcore.so.4 to libaudcore.so.5 that has been
> introduced with the upgrade to Audacious 3.9 in Rawhide.

Same for F27 where the set of Fedora updates/rebuilds is on its ways into
the "updates" repo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: State of Sparkeshare in Fedora

2017-09-23 Thread Luya Tshimbalanga 
On 22/09/17 12:09 AM, James Hogarth wrote:
>
>
> On 22 Sep 2017 4:46 am, "Luya Tshimbalanga"  > wrote:
>
> On 21/09/17 08:02 AM, James Hogarth wrote:
>>
>>
>> On 21 September 2017 at 07:17, Luya Tshimbalanga
>> mailto:l...@fedoraproject.org>> wrote:
>>
>> Sparkleshare package is currently behind upstream which just
>> reach 2.0[1][2]
>> The maintainer was contacted for updating the package with
>> current broken dependency below on Fedora 27 and above:
>>
>>  Problem: package sparkleshare-1.2.0-8.fc26.x86_64 requires
>> mono(webkit-sharp) = 1.1.15.0, but none of the providers can
>> be installed
>>   - conflicting requests
>>   - nothing provides webkitgtk needed by
>> webkit-sharp-0.3-19.fc26.x86_64
>>
>>  but no response so far[3][4].
>> As the application is used by Design Team, could someone make
>> the change because I cannot access it?
>> Thanks in advance,
>>
>> Luya
>>
>> References
>> --
>> [1] https://github.com/hbons/SparkleShare/releases/tag/2.0.0
>> 
>> [2] https://apps.fedoraproject.org/packages/sparkleshare
>> 
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1151172
>> 
>> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1375789
>> 
>>
>>
>>
>> A quick look of course shows this to be an issue with the
>> retiring of webkitgtk as that's no longer in the repos for
>> webkit-sharp to build against, which then means sparkleshare
>> doesn't have its dependency satisfied.
>>
>> According to the sparkleshare release notes[0] the 1.3.0 release
>> added the gtk3 bindings... so any of those ought to help.
>>
>> The build dependencies are more complex than I can do in a few
>> minutes though[1]
>>
>> The 2.0 release the release notes states has breaking changes
>> from 1.X ... 
>>
>> To get this updated someone needs to package webkit2-sharp (and
>> any dependencies that needs to build) ... gtk-sharp3 is already
>> packaged though which should help.
>>
>> They say that as of 2.0 they have a flatpak release - have you
>> tried that so at least you'll have access to the application in F27?
>>
> Wearing Design Suite lab maintainer's hat, I would love to include
> a flatpak version of 2.0 as default for F27 if there is a proper
> mechanism to do so.
>
> Just a quick look, I made a spec file for guideline[1]
>
> References
> ---
> [1]
> https://luya.fedorapeople.org/packages/SPECS/webkit2-sharp.spec
> 
>
>
> -- 
> Luya Tshimbalanga
> Graphic & Web Designer
> E: l...@fedoraproject.org 
> W: http://www.coolest-storm.net
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
>
>
> Ah I thought you meant the application for you to use. Last I heard
> how to formally include a flatpak app in Fedora is still up for debate. 
>
> The Workstation working group may have some ideas there. 
>
> Not making any promises but if no-one else has got to it by the end of
> next week I'll try and get something together. 
>
> I'm not familiar with the app though so it'll take a little getting up
> to speed. 
>
> Based on the fedora update policy and the acknowledged breaking
> changes in 2.0 we should only really update to the most recent 1.x in
> F27 and below at this time. 
>
> The latest version should be a self contained change in F28.
>
>
Fair enough.
Sparkleshare is basically a client based file synchronization similar to
Dropbox or iFolder.
1.5 is the last release for the 1.x according to Sparkleshare website
which should lesser the breakage.

Thanks for the lookup as the update was long overdue.


-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

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

Re: Requires for local install

2017-09-23 Thread Philip Kovacs 
Or use Fedora Copr to create personal repos for your projects.  There is a lot 
of utility in doing that,esp.  when you start dealing with multiple boxes or 
vms.  Doing local installs directly from rpms doesnot scale and becomes tedious 
very quickly.  If you're writing or modifying the spec yourself, try Copr.
https://copr.fedorainfracloud.org/
 

On Saturday, September 23, 2017 9:52 AM, Matthew Miller 
 wrote:
 

 On Fri, Sep 22, 2017 at 09:47:15PM -0400, David Muse wrote:
> But, when doing a yum localinstall or dnf install with a local path,
> the user has to either install all rpm's or manually resolve
> dependencies.
> 
> Is it common to specify inter-subpackage dependencies using Requires
> to resolve this, or are users just on their own if they're
> installing packages manually?

You should certainly use inter-subpackage requires in any case, if they
are genuine. But that won't help DNF (or Yum), as with local install
they only know about the files they are told about. But, what you
*could* do is:

 1. run "createrepo_c" on your directory of downloaded RPMs,
 2. use `dnf --repofrompath local,.`, and then
 3. use `dnf install packagename`

In step 1, createrepo_c is a drop-in but faster replacement for
createrepo.

In step 2, the syntax is "--repofrompath made-reponame,path", so you
could do '--repofrompath "My Repository",/home/mattdm/Downloads/RPMs'.

In step 3, use the package name not the file name, so no .rpm on the
end.

-- 
Matthew Miller

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


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

Re: Requires for local install

2017-09-23 Thread Sérgio Basto 
On Sat, 2017-09-23 at 09:51 -0400, Matthew Miller wrote:
> On Fri, Sep 22, 2017 at 09:47:15PM -0400, David Muse wrote:
> > But, when doing a yum localinstall or dnf install with a local
> > path,
> > the user has to either install all rpm's or manually resolve
> > dependencies.

no , dnf install localpath , resolve all dependencies and install it as
well 


> > Is it common to specify inter-subpackage dependencies using
> > Requires
> > to resolve this, or are users just on their own if they're
> > installing packages manually?
> 
> You should certainly use inter-subpackage requires in any case, if
> they
> are genuine. But that won't help DNF (or Yum), as with local install
> they only know about the files they are told about. But, what you
> *could* do is:
> 
>  1. run "createrepo_c" on your directory of downloaded RPMs,
>  2. use `dnf --repofrompath local,.`, and then
>  3. use `dnf install packagename`

repofrompath and enablerepo and dnf command must be in same instructioni.e.  

dnf --enablerepo=abc --repofrompath=abc,/var/lib/mock/fedora-25-
x86_64/result --refresh update

> In step 1, createrepo_c is a drop-in but faster replacement for
> createrepo.
> 
> In step 2, the syntax is "--repofrompath made-reponame,path", so you
> could do '--repofrompath "My
> Repository",/home/mattdm/Downloads/RPMs'.
> 
> In step 3, use the package name not the file name, so no .rpm on the
> end.
> 
> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: A less "bloated" KDE spin

2017-09-23 Thread Jia Yuan Lo 
> I guess the OP and his friends could create a KDE-Lite spin or try LXQT

The same could be said for GNOME to have a GNOME-Lite (Python Classroom is 
exactly that)

I would happily promote LXQT and MATE Mutter as a lightweight alternative to 
KDE and GNOME respectively
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

soname updates, license changes, and version updates, o my!

2017-09-23 Thread Jerry James 
I would like to update a bunch of the numerical packages in the near
future.  I will do the updates for Rawhide only at first, although if
everything seems stable I may update F-27 as well.  Here is the
proposed list of changes.  Package maintainers and co-maintainers are
CCed to this email.

arb: update from 2.10.0 to 2.11.1

cddlib: polymake used to link with both the GMP and non-GMP versions
of cddlib.  We have some ugly linker tricks in the cddlib package to
support both this and other package's use of cddlib.  The current
version of polymake no longer requires those tricks, but I failed to
notice this when I last updated polymake.  I propose dropping the
linker tricks, which led in some way that I still don't fully
understand to gfan's failure to build during the mass rebuild.

eclib: update from 20170330 to 20170815

fflas-ffpack: build with openblas instead of atlas; see a recent
thread about this on the fedora-devel mailing list.  This change also
lets us drop a workaround in %check for some weird atlas behavior on
ppc64.

flint: rebuild for the ntl update and build with openblas instead of atlas

gap-pkg-float: rebuild for the libfplll update

gf2x: update from 1.1 to 1.2

gfan: update from 0.5 to 0.6.1, which not only fixes the Rawhide FTBFS
but also lets us drop 2 upstreamed patches, and we can also drop an
RPM_LD_FLAGS workaround that was needed due to the linker tricks in
cddlib.  The license changes from GPL+ to GPLv2+ with this release.

giac: rebuild for ntl 10.5.0, but also switch from building with the
reference lapack implementation to openblas.  This package is also
using a broken version scheme, as witnessed by the number of changelog
entries about bumping numbers so a new build has a higher NEVR than
the previous build.  I propose fixing this by moving %{subversion}
from Release to Version.

iml: build with openblas instead of atlas

latte-integrale: rebuild for the ntl update

libfplll: update from 5.0.3 to 5.1.0.  This involves an SONAME update
from libfplll.so.2 to libfplll.so.3

linbox: rebuild for the libfplll and ntl updates.  Build with openblas
instead of atlas.

Macaulay2: rebuild for the ntl update.  Build with openblas instead of atlas.

mathic: update from a 20160320 snapshot to a 20170606 snapshot

mathicgb: update from a 20170104 snapshot to a 20170606 snapshot

normaliz: update from 3.1.4 to 3.4.0

ntl: update from 10.3.0 to 10.5.0.  This involves an SONAME update
from libntl.so.33 to libntl.so.35

polymake: rebuild for the cddlib and normaliz updates

pynac: build with giac support, and make the dependency on python be
explicitly for version 2.  This package could be built for both python
2 and python 3, but since I am neither point of contact nor a
comaintainer, I am reluctant to make such a large change to it.

python-fpylll: update from 0.2.3dev to 0.2.4dev for the libfplll
update.  I know the spec file says to stick with 0.2.3dev because that
is the version that sagemath 7.6 wants, but that version does not
build with libfplll 5.1.0.  Also, sagemath changed 6 months ago to
support these versions, with no apparent ill effects:
https://trac.sagemath.org/ticket/22643 and
https://git.sagemath.org/sage.git/commit?id=d0d5ca778cf897f2b1c9742f9d0b9966625d591e

sagemath: rebuild for the arb, eclib, libfplll, and ntl updates and,
frankly, probably for all of the other updates too.

Singular: rebuild for the cddlib update, and break gfanlib out into
its own package, as I have seen mentions of other projects consuming
gfanlib without consuming the rest of Singular

sympol: rebuild for the cddlib update

TOPCOM: rebuild for the cddlib update

Whew!  If any of the package maintainers object to any part of this
plan, please let me know.  Otherwise, I will launch these builds for
Rawhide around the middle of next week.  Since some of them take many
hours to build, it is probable that the Rawhide report will complain
about broken dependencies somewhere in the middle.

I have already done local builds for x86_64 for all of these packages.
If anything breaks on another architecture, I will fix it.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org