rubygem-diff-lcs license changed to GPLv2+ or Artistic or MIT

[Vít Ondruch]

rubygem-diff-lcs-1.3-1.fc26 simplified its license to GPLv2+ or Artistic
or MIT.


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

Re: bex represents pagure emails in hyperkitty

[Aurelien Bompard]

Yeah, that's exactly what's happenning. The sender name is updated when an 
email from the same address is sent to the list. It worked well for humans, but 
I have to think about this use case.

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

Re: Unretiring itpp

[Theodore Papadopoulo]

Thank's a lot for the review.
I will analyze all your comments and produce an updated spec file.
I need some time to understand the references you sent.

Thank's again.

Theo.

On 01/19/2017 01:38 AM, Michael Schwendt wrote:
>> Provided I get some guidance (or readings, account settings, ...), I
>> ciuld maintain or co-maintain the package if necessary.
> 
>> Release:0%{?dist}
> 
> First release of a package usually starts with 1 not 0:
> https://fedoraproject.org/wiki/Packaging:Versioning#Release_Tag
> 
>> %package devel
>> Requires:   %{name} = %{version}-%{release}
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
> 
>> Requires:   pkgconfig
> 
> If there are pkgconfig .pc files included in that package, there will
> be automatic Provides/Requires for pkgconfig and the inter-dependencies
> as specified within the .pc files.
> 
>> Requires:   fftw-devel, atlas-devel, gcc-gfortran
> 
> You may want to make them arch-specific, too.
> 
>> %package doc
>> Summary:Documentation for itpp
>> Group:  Development/Libraries
> 
> Wrong group tag for Documentation packages, and the Group tag is not
> necessary for a long time:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
> 
> Most likely, you also want to make this subpackage "BuildArch: noarch".
> 
>> Requires:   %{name} = %{version}-%{release}
> 
> Doubtful. Keep documentation packages free of dependencies when the
> included HTML documentation can be displayed and doesn't need the base
> package.
> 
>> %install
>> rm -rf $RPM_BUILD_ROOT
> 
> Clean up of buildroot is automatic for a long time:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
> 
>> make install DESTDIR=$RPM_BUILD_ROOT LIBDIR=$RPM_BUILD_ROOT/usr/lib64
> 
> What does the LIBDIR definition achieve when you still need to move
> the libs from /usr/lib later?
> 
>> mv $RPM_BUILD_ROOT/usr/lib $RPM_BUILD_ROOT/%{_libdir}
> 
> 
>> %clean
>> rm -rf $RPM_BUILD_ROOT/
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
> 
>> %files
>> %defattr(-,root,root,-)
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
> 
> 
>> %dir %{_docdir}/%{name}
>> %{_docdir}/%{name}/[A-Z]*
> 
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> 
> 
>> %{_bindir}/%{name}-config
> 
> Needs to be checked whether it refers to /usr/lib and /usr/lib64.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.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

Heads up: today's rawhide gnome-shell crashes on startup

[Kalev Lember]

The fix is to update to latest mozjs31 build, mozjs31-31.5.0-1.fc26,
available from https://koji.fedoraproject.org/koji/buildinfo?buildID=834907

Hope this helps save debugging time for someone.

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

Re: F26 Self Contained Change: Docker Overlay 2

[Matthew Miller]

On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
> Change the default Docker Storage to be overlay2 .

I made a couple of edits to this, mostly clarifying that overlay2 is
not a second overlay filesystem, but a second Docker driver for the
same OverlayFS.

-- 
Matthew Miller

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

Re: F26 Self Contained Change: Docker Overlay 2

[Daniel J Walsh]

On 01/19/2017 09:20 AM, Matthew Miller wrote:
> On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
>> Change the default Docker Storage to be overlay2 .
> I made a couple of edits to this, mostly clarifying that overlay2 is
> not a second overlay filesystem, but a second Docker driver for the
> same OverlayFS.
>
Sounds good to me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is there something wrong with the Koji builders?

[Ralf Corsepius]

On 01/18/2017 07:55 PM, Kevin Fenzi wrote:


If you see any further issues like the above, let me know.


https://koji.fedoraproject.org/koji/taskinfo?taskID=17327268
seems to hang on arm7vhl and i386.

The x86_64 built finished ca. 45 minutes after the built was started.

However, I can not spot any activity in the i386 logs
https://koji.fedoraproject.org/koji/taskinfo?taskID=17327272
nor the arm's logs
https://koji.fedoraproject.org/koji/taskinfo?taskID=17327270

ATM, it's > 10 hours since these builts have been started, with me 
expecting them to take approx. 4 hours (The time, fc24 and fc26 builds 
took), but ...


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

Re: Is there something wrong with the Koji builders?

[Charalampos Stratakis]

After some discussions with Christian Heimes, it seems this has something to do 
with the latest kernel (4.9), as the kernel's api used in this test changed 
[0][1]. This will need to be addressed in python, but it is weird
that it happens only on specific architectures.

[0] 
https://github.com/smuellerDD/libkcapi/commit/be242c387b7030cbccae2c183107efa86d9a3cd6
[1] http://bugs.python.org/issue29324

Anyway I don't think any more attention is required by infra for this specific 
case.

Regards,

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Kevin Fenzi" 
To: devel@lists.fedoraproject.org
Sent: Wednesday, January 18, 2017 7:55:38 PM
Subject: Re: Is there something wrong with the Koji builders?

On Wed, 18 Jan 2017 07:22:49 -0500 (EST)
Charalampos Stratakis  wrote:

> Python 3 started failing on i686, x86_64 and arm only.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17313924
> 
> The failures come from the test_socket.py [0], test_aead_aes_gcm [1]
> and more specifically this line [2] with the message: OSError: [Errno
> 22] Invalid argument
> 
> This test is checking Python's interface for the kernel crypto API
> (added in 3.6 [3]).
> 
> [0]
> https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5473
> [1]
> https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5472
> [2]
> https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5497
> [3] http://bugs.python.org/issue27744

Thats nothing to do with the buildsystem. Or at least if it is, it's
not any of the known issues I was working on. 

As far as I know now everything should be back to working/normal. 

There were 3 issues: 

1. The buildvm's were updated and started crashing under load. They
would spew oopses and finally reboot. This would result in builds on
them getting restarted or dying in strange ways. This seems to be
something particular to their hardware/setup that changed in later
4.8.x and early 4.9.x kernels. We are currently running 4.10rc4 on them
and it's been stable (knock on wood). 

2. Sometimes, very rarely dnf would fail downloading packages for the
build root. We have worked around this by passing dnf via koji several
mirrors where it can download from, so if it fails on one it should
fall back to the next and so on. 
https://pagure.io/fedora-infrastructure/issue/5689

3. In some configurations (where there was more than I host to download
from) koji would fail to download the src.rpm correctly and error out. 
We are working around this now by just pointing koji at one place for
these downloads for now until we can get things fixed. 
https://pagure.io/fedora-infrastructure/issue/5694

Sorry for all the instability the last few days. 

If you see any further issues like the above, let me know. 

kevin

___
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: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Martin Ueding]

Am 16.01.2017 um 17:18 schrieb Kevin Fenzi:
> Did xbacklight work in the past?

Yes, it did.

To work around that bug, I use KDE Plasma and there I can change the
brightness with Fn+PgUp. `xbacklight` does not work there, saying that
no output have backlight property.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Docker Overlay 2

[James Hogarth]

On 19 Jan 2017 2:43 pm, "Daniel J Walsh"  wrote:



On 01/19/2017 09:20 AM, Matthew Miller wrote:
> On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
>> Change the default Docker Storage to be overlay2 .
> I made a couple of edits to this, mostly clarifying that overlay2 is
> not a second overlay filesystem, but a second Docker driver for the
> same OverlayFS.
>
Sounds good to me.


Just to quickly clarify something.

If no storage driver is specified right now and /var/lib/docker is btrfs
the btrfs driver then gets used automatically.

Will I need to be aware of any specific configuration changes on my btrfs
workstations to avoid breakage and keep things working as they are?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Hans de Goede]

Hi,

On 19-01-17 16:14, Martin Ueding wrote:

Am 16.01.2017 um 17:18 schrieb Kevin Fenzi:

Did xbacklight work in the past?


Yes, it did.

To work around that bug, I use KDE Plasma and there I can change the
brightness with Fn+PgUp. `xbacklight` does not work there, saying that
no output have backlight property.


Yes that is an expected result of switching to the modesetting driver,
the intel ddx is the only driver which ever implemented a xrandr backlight
property, non of the others (ati, nouveau) have ever offered this, so
most tools simply write directly to /sys/class/backlight, but xbacklight
relies on the xrandr property (and is the only tool do so AFAICT).

Maybe someone should look into making xbacklight access the sysfs
interface directly like gnome, kde and xfce are doing. This does
require root rights, a patch for this could re-use the

/usr/libexec/xf86-video-intel-backlight-helper

See xf86-video-intel/src/backlight.c for how to use this.

Regards,

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

Re: drop obsolete static uid/gid allocations

[Przemek Klosowski]

On 01/14/2017 07:13 PM, Zbigniew Jędrzejewski-Szmek wrote:

== No need for static allocation, afaict
games, man, slocate, squid, named, postgres, mysql, nscd,
rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci

== The following are completely unused?
console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
pvm, xfs


FWIW, there's also plugdev which I am involved in evicting from udev 
rules. I think by now it's only used by flashrom


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

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

Fedora Rawhide-20170119.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Cloud_base raw-xz x86_64
Atomic raw-xz x86_64

Failed openQA tests: 25/103 (x86_64), 17/17 (i386), 1/2 (arm)

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

ID: 55158   Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/55158
ID: 55159   Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/55159
ID: 55162   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/55162
ID: 55173   Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/55173
ID: 55190   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55190
ID: 55191   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/55191
ID: 55197   Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/55197

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

ID: 55164   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/55164
ID: 55166   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/55166
ID: 55170   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/55170
ID: 55174   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55174
ID: 55175   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/55175
ID: 55178   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55178
ID: 55179   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/55179
ID: 55180   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/55180
ID: 55188   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/55188
ID: 55192   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/55192
ID: 55193   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55193
ID: 55200   Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/55200
ID: 55204   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/55204
ID: 55205   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/55205
ID: 55206   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/55206
ID: 55244   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/55244
ID: 55246   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/55246
ID: 55247   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/55247
ID: 55249   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/55249
ID: 55251   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/55251
ID: 55252   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/55252
ID: 55256   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/55256
ID: 55257   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/55257
ID: 55258   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/55258
ID: 55263   Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/55263
ID: 55265   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/55265
ID: 55266   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/55266
ID: 55268   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/55268
ID: 55269   Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/55269
ID: 55270   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/55270
ID: 55272   Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/55272
ID: 55273   Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/55273
ID: 55274   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/55274
ID: 55277   Test: i386 universal upgrade_desktop_32bit
URL

Re: Heads up: today's rawhide gnome-shell crashes on startup

[Adam Williamson]

On Thu, 2017-01-19 at 14:57 +0100, Kalev Lember wrote:
> The fix is to update to latest mozjs31 build, mozjs31-31.5.0-1.fc26,
> available from https://koji.fedoraproject.org/koji/buildinfo?buildID=834907
> 
> Hope this helps save debugging time for someone.

When you say "today's"...when did this start? All the Workstation
openQA tests on the 20170117.n.0 compose booted to black screens...is
that the same bug?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Docker Overlay 2

[Daniel J Walsh]

On 01/19/2017 10:17 AM, James Hogarth wrote:
>
>
> On 19 Jan 2017 2:43 pm, "Daniel J Walsh"  > wrote:
>
>
>
> On 01/19/2017 09:20 AM, Matthew Miller wrote:
> > On Thu, Jan 19, 2017 at 08:36:02AM +0100, Jan Kurik wrote:
> >> Change the default Docker Storage to be overlay2 .
> > I made a couple of edits to this, mostly clarifying that overlay2 is
> > not a second overlay filesystem, but a second Docker driver for the
> > same OverlayFS.
> >
> Sounds good to me.
>
>
> Just to quickly clarify something.
>
> If no storage driver is specified right now and /var/lib/docker is
> btrfs the btrfs driver then gets used automatically.
>
> Will I need to be aware of any specific configuration changes on my
> btrfs workstations to avoid breakage and keep things working as they are?
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Docker should realize a previous uses backing store and continue to use
it.  This should only effect fresh installs or systems where someone does an

atomic storage reset.


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

xavierb pushed to perl-HTTP-Cache-Transparent (epel7). "Update to 1.1 and clean up spec file"

[notifications]

From f9f05cf6457880a113b205d3fe2e57e177696466 Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman 
Date: Sun, 9 Jun 2013 08:50:02 +0200
Subject: Update to 1.1 and clean up spec file

---
 .gitignore   |  1 +
 perl-HTTP-Cache-Transparent.spec | 20 +---
 sources  |  2 +-
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7568f55..86e52c3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 HTTP-Cache-Transparent-1.0.tar.gz
+/HTTP-Cache-Transparent-1.1.tar.gz
diff --git a/perl-HTTP-Cache-Transparent.spec b/perl-HTTP-Cache-Transparent.spec
index 6b48434..770a1cc 100644
--- a/perl-HTTP-Cache-Transparent.spec
+++ b/perl-HTTP-Cache-Transparent.spec
@@ -1,13 +1,11 @@
 Name:   perl-HTTP-Cache-Transparent
-Version:1.0
-Release:14%{?dist}
+Version:1.1
+Release:1%{?dist}
 Summary:Cache the result of http get-requests persistently
 
-Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/HTTP-Cache-Transparent/
 Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MATTIASH/HTTP-Cache-Transparent-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -18,6 +16,8 @@ BuildRequires:  perl(LWP::UserAgent)
 
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
+%{?perl_default_filter}
+
 %description
 HTTP::Cache::Transparent is an implementation of http get that keeps a
 local cache of fetched pages to avoid fetching the same data from the
@@ -35,28 +35,26 @@ make %{?_smp_mflags}
 
 
 %install
-rm -rf $RPM_BUILD_ROOT
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 
 
-
 %check
 make test
 
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
 %files
-%defattr(-,root,root,-)
 %doc README Changes
 %{perl_vendorlib}/HTTP/
 %{_mandir}/man3/*.3*
 
 
 %changelog
+* Sun Jun 09 2013 Emmanuel Seyman  - 1.1-1
+- Update to 1.1
+- Add perl default filter
+- Remove no-longer-used macros
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 1.0-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
diff --git a/sources b/sources
index e9380f9..587f6ac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e198345ce8eee2562c807e84d65e3b4f  HTTP-Cache-Transparent-1.0.tar.gz
+302dc2d6400ccf7e7d6c0ed45a0efc13  HTTP-Cache-Transparent-1.1.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Cache-Transparent.git/commit/?h=epel7&id=f9f05cf6457880a113b205d3fe2e57e177696466
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

xavierb pushed to perl-HTTP-Cache-Transparent (epel7). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild"

[notifications]

From 48e355f6dc62c30b1ebafe120f61d136129f26fd Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 7 Jun 2014 00:18:42 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

---
 perl-HTTP-Cache-Transparent.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-HTTP-Cache-Transparent.spec b/perl-HTTP-Cache-Transparent.spec
index 43c85db..89ec17c 100644
--- a/perl-HTTP-Cache-Transparent.spec
+++ b/perl-HTTP-Cache-Transparent.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Cache-Transparent
 Version:1.1
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Cache the result of http get-requests persistently
 
 License:GPL+ or Artistic
@@ -50,6 +50,9 @@ make test
 
 
 %changelog
+* Sat Jun 07 2014 Fedora Release Engineering  
- 1.1-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
 * Sat Aug 03 2013 Fedora Release Engineering  
- 1.1-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-HTTP-Cache-Transparent.git/commit/?h=epel7&id=48e355f6dc62c30b1ebafe120f61d136129f26fd
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Heads up: today's rawhide gnome-shell crashes on startup

[Kalev Lember]

On Jan 19, 2017 18:06, "Adam Williamson"  wrote:

On Thu, 2017-01-19 at 14:57 +0100, Kalev Lember wrote:
> The fix is to update to latest mozjs31 build, mozjs31-31.5.0-1.fc26,
> available from https://koji.fedoraproject.org/koji/buildinfo?buildID=
834907
>
> Hope this helps save debugging time for someone.

When you say "today's"...when did this start? All the Workstation
openQA tests on the 20170117.n.0 compose booted to black screens...is
that the same bug?


I think so, yes.

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

Re: Is there something wrong with the Koji builders?

[Daniel P. Berrange]

On Wed, Jan 18, 2017 at 11:55:38AM -0700, Kevin Fenzi wrote:
> On Wed, 18 Jan 2017 07:22:49 -0500 (EST)
> Charalampos Stratakis  wrote:
> 
> > Python 3 started failing on i686, x86_64 and arm only.
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=17313924
> > 
> > The failures come from the test_socket.py [0], test_aead_aes_gcm [1]
> > and more specifically this line [2] with the message: OSError: [Errno
> > 22] Invalid argument
> > 
> > This test is checking Python's interface for the kernel crypto API
> > (added in 3.6 [3]).
> > 
> > [0]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5473
> > [1]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5472
> > [2]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5497
> > [3] http://bugs.python.org/issue27744
> 
> Thats nothing to do with the buildsystem. Or at least if it is, it's
> not any of the known issues I was working on. 
> 
> As far as I know now everything should be back to working/normal. 
> 
> There were 3 issues: 
> 
> 1. The buildvm's were updated and started crashing under load. They
> would spew oopses and finally reboot. This would result in builds on
> them getting restarted or dying in strange ways. This seems to be
> something particular to their hardware/setup that changed in later
> 4.8.x and early 4.9.x kernels. We are currently running 4.10rc4 on them
> and it's been stable (knock on wood). 
> 
> 2. Sometimes, very rarely dnf would fail downloading packages for the
> build root. We have worked around this by passing dnf via koji several
> mirrors where it can download from, so if it fails on one it should
> fall back to the next and so on. 
> https://pagure.io/fedora-infrastructure/issue/5689
> 
> 3. In some configurations (where there was more than I host to download
> from) koji would fail to download the src.rpm correctly and error out. 
> We are working around this now by just pointing koji at one place for
> these downloads for now until we can get things fixed. 
> https://pagure.io/fedora-infrastructure/issue/5694
> 
> Sorry for all the instability the last few days. 
> 
> If you see any further issues like the above, let me know.

I'm still seeing quite alot of problems today - randomly the arm7 or
ppc task will just sit there in "open" status doing nothing for hours.
If I cancel & rerun the build it works fine, presumably because it hit
a different build instance.

Now I've just seen some builds which succeeded in the build phase
get marked as failed because mock throws an exception handling the
results

https://kojipkgs.fedoraproject.org//work/tasks/1011/17331011/mock_output.log


Finish: run
ERROR: list index out of range
Traceback (most recent call last):
  File "/usr/libexec/mock/mock", line 885, in 
raise
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/libexec/mock/mock", line 704, in main
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/buildroot.py", line 545, in 
finalize
self._unlock_buildroot()
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/mounts.py", line 162, in 
umountall
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
81, in trace
frame = inspect.getouterframes(inspect.currentframe())[1][0]
  File "/usr/lib/python3.5/inspect.py", line 1441, in getouterframes
frameinfo = (frame,) + getframeinfo(frame, context)
  File "/usr/lib/python3.5/inspect.py", line 1414, in getframeinfo
lines, lnum = findsource(frame)
  File "/usr/lib/python3.5/inspect.py", line 804, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is there something wrong with the Koji builders?

[Ralf Corsepius]

On 01/19/2017 06:37 PM, Daniel P. Berrange wrote:


Now I've just seen some builds which succeeded in the build phase
get marked as failed because mock throws an exception handling the
results

https://kojipkgs.fedoraproject.org//work/tasks/1011/17331011/mock_output.log


Finish: run
ERROR: list index out of range
Traceback (most recent call last):
  File "/usr/libexec/mock/mock", line 885, in 
raise
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/libexec/mock/mock", line 704, in main
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/buildroot.py", line 545, in 
finalize
self._unlock_buildroot()
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/mounts.py", line 162, in 
umountall
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
81, in trace
frame = inspect.getouterframes(inspect.currentframe())[1][0]
  File "/usr/lib/python3.5/inspect.py", line 1441, in getouterframes
frameinfo = (frame,) + getframeinfo(frame, context)
  File "/usr/lib/python3.5/inspect.py", line 1414, in getframeinfo
lines, lnum = findsource(frame)
  File "/usr/lib/python3.5/inspect.py", line 804, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range
This is what I meanwhile am seeing in before mentioned "hanging" builds, 
as well:


https://kojipkgs.fedoraproject.org//work/tasks/7272/17327272/mock_output.log

Ralf


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

Re: Is there something wrong with the Koji builders?

[Kevin Fenzi]

On Thu, 19 Jan 2017 17:37:23 +
"Daniel P. Berrange"  wrote:

> I'm still seeing quite alot of problems today - randomly the arm7 or
> ppc task will just sit there in "open" status doing nothing for hours.
> If I cancel & rerun the build it works fine, presumably because it hit
> a different build instance.

Well, not sure thats the case yet. This is a NEW AND EXCITING failure I
am looking at this morning. 

I freed all the tasks that were stuck this way and am investigating. 

> Now I've just seen some builds which succeeded in the build phase
> get marked as failed because mock throws an exception handling the
> results
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1011/17331011/mock_output.log

Please post links to the top level task. 
(in this case: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=17331011
)

This was my fault. I was downgrading mock on the builders in an attempt
to see if it was causing the above new and exciting bug, but
unfortunately it caused in progress builds to explode. ;( 

So, resubmit and it should work (unless it gets stuck not processing in
which case I will come along and free it up). 

kevin




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

Re: Heads up: today's rawhide gnome-shell crashes on startup

[Adam Williamson]

On Thu, 2017-01-19 at 18:18 +0100, Kalev Lember wrote:
> On Jan 19, 2017 18:06, "Adam Williamson"  wrote:
> 
> On Thu, 2017-01-19 at 14:57 +0100, Kalev Lember wrote:
> > The fix is to update to latest mozjs31 build, mozjs31-31.5.0-1.fc26,
> > available from https://koji.fedoraproject.org/koji/buildinfo?buildID=
> 
> 834907
> > 
> > Hope this helps save debugging time for someone.
> 
> When you say "today's"...when did this start? All the Workstation
> openQA tests on the 20170117.n.0 compose booted to black screens...is
> that the same bug?
> 
> 
> I think so, yes.

Roger, thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is there something wrong with the Koji builders?

[Ralf Corsepius]

On 01/19/2017 06:55 PM, Kevin Fenzi wrote:

Please post links to the top level task.

My case:

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

https://kojipkgs.fedoraproject.org//work/tasks/7272/17327272/mock_output.log

Approx. at the same time the i686 raised the error above, the arm 
build-job seems to have started.


Ralf

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

Re: F26 Self Contained Change: LXQt Spin

[Christian Dersch]

Hi everyone,

I created a blog entry about the current state: 
https://lupinix.blogspot.de/2017/01/lxqt-spin-proposed-for-fedora-26-new.html


Greetings,
Christian


On 01/16/2017 02:00 PM, Jan Kurik wrote:

= Proposed Self Contained Change: LXQt Spin =
https://fedoraproject.org/wiki/Changes/LXQt_Spin

Change owner(s):
* Christian Dersch 

A Fedora Spin providing the LXQt desktop environment.

== Detailed Description ==
LXQt is a lightweight Qt-based desktop environment. Fedora provides it
since Fedora 22 as a group of packages. Now that LXQt is much more
complete, it is time to provide a live spin to our users. Therefore
some effort has been made to provide a first impression and it is
ready for submission as an official spin.

== Scope ==
* Proposal owners:
Implement this Change, almost done.
https://pagure.io/lxqt-remix

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
Add spin to spin-kickstarts, ensure spin has been tested, and release
with rest of spins

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

* Trademark approval:
requested
https://pagure.io/Fedora-Council/tickets/issue/84

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

Re: RFH: Annotating ELF binaries

[Carlos O'Donell]

On 01/18/2017 12:02 PM, Nick Clifton wrote:
> Hi Carlos,
> 
>> I've added 2 questions to the Toolchain/Watermark wiki but will post them
>> here for posterity:
> 
> Thanks - I'll try answering them here first, and if my answers make sense
> then I will update the wiki.
> 
>> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what 
>> you are proposing?
> 
> Good question, and unfortunately I do not know the answer.  The problem
> is, I have been unable to locate any documentation that describes 
> SHT_GNU_ATTRIBUTES and how it is supposed to be used.
> 
> I think that the two schemes are quite similar, although this new proposal
> is intended to be able to cope with attributes that only apply to part of
> an executable and not necessarily the executable as a whole.  (Also, IMHO,
> my proposal has better documentation...)
 
I'm including Joseph Myers in this discussion.

It's very very well documented by ARM.

The point of SHT_GNU_ATTRIBUTES is to mark a section as containing
GNU-based Attributes for the object in question. Rather than have a generic
SHT_NOTE. The GNU-based attributes can be applied to the file, section, or
symbol (and extended further).

Attributes can be anything you want them to be. Today most of the GNU-attributes
are ABI related and the static linker uses them at link time to issue errors
when objects of mixed incompatible ABIs are attempted to be used together.
That is to say they are Tag_File-based attributes (see binutils source for 
this).

The generic section which holds attributes is SHT_GNU_ATTRIBUTES, but machines
can override this e.g. SHT_ARM_ATTRIBUTES for ARM-specific attributes.

The ELF attributes section design was originally based on the need at the time 
from ARM for ARM EABI Attributes.

See 4.3.6 Build Attributes:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

.gnu.attributes (section)

* , currently 'A' (0x41)
*  (4 byte unsigned int in ELF endian order of all 
subsequent data)
* "vendor name" ("GNU") for generic + NULL pointer.
*   (all things which are file scope) 

*  (all things which are section scope)  
 
*  (all things which are symbol scope)  
 

The ARM documentation goes into a lot of detail about what attributes it
supports.

Given that we have a GNU-generic version of this... might we not extend things
to a new Tag_Range and keep all the existing machinery we already have in 
binutils
for processing all of these attributes?

Again, the SHT_GNU_ATTRIBUTES section was never designed to be loaded by the
dynamic linker, and it's the reason I recommend you look at the design and think
about how we can avoid another attributes format that is incompatible with the
one we already have in binutils.

Harmonize the designs please :-)

>> (2) What is being done to ensure the attributes are space and time
>> efficient for dynamic link comparison in the dynamic linker? 
>> Speed of checking 10,000 DSOs (scalability) for ABI compatibility is 
>> going to be a very important requirement.
> 
> I believe that H.J's design for the dynamic link notes does take efficiency
> into consideration, but I will leave that for him to comment on further.

It does, mostly be using bits, and AND/OR/EQ handling.

I have yet to see exactly how it works.

I might suggest we version the section like .gnu.attributes so we can
increment the version if we have a flag day changing the layout.

> One thing that I have already done for the static notes is to implement a
> new option for objcopy called "--merge-notes" which eliminates redundancies.
> Theoretically this option could be extended to work with the dynamic notes
> too, helping to make them as space efficient as possible.

OK.

> Another possibility is that the linker could be extended so that when it
> creates a dynamic executable it also inserts a "master" dynamic linker note,
> which contains all of the information that the dynamic linker will need,
> without it having to search through all of the shared libraries used by the
> application.  (This does assume that the shared libraries examined at static
> link time are the same ones that are loaded/used at dynamic link time).
 
We can't assume that unfortunately.
 
>> (b) Loadable notes and space/time efficiency vs. non-loadable notes and
>> static analysis tools.
>>
>> Run-time checking of properties is radically different from offline
>> checking of properties and we absolutely need two different designs to
>> meet these needs. However, if we could weld the two together in a compatible
>> way, that would be great. For example if the dynamic loader could map from
>> a 'run-time property' to a 'link-time property' to increase the verbosity
>> of the error in a failure scenario, then that might be beneficial.
> 
> I think that this might not be easy to do in a way that both imposes a low
> code-increase cost on the dynamic linker and a 
> 

pyopencl now contains BSD code

[Igor Gnatenko]

Upstream added parts of random123 project which is BSD-licensed. This
affects only rawhide, since I don't plan to build it for any stable
releases.

Thanks for the time ;)
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unretiring itpp

[Theodore Papadopoulo]

On 01/19/2017 01:38 AM, Michael Schwendt wrote:
>> Provided I get some guidance (or readings, account settings, ...), I
>> ciuld maintain or co-maintain the package if necessary.
> [...]
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> 
> 
>> %{_bindir}/%{name}-config
> 
> Needs to be checked whether it refers to /usr/lib and /usr/lib64.


Is this version better ? I think I incorporated all your suggestions +
some more that are in the same vein to what you suggested.

Theo.
Name:   itpp
Version:4.3.1
Release:1%{?dist}
Summary:C++ library for math, signal/speech processing, and communications

Group:  System Environment/Libraries
License:GPLv2+
URL:http://itpp.sourceforge.net/
Source0:http://downloads.sourceforge.net/itpp/itpp-%{version}.tar.bz2
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# Filed into upstream bugtracker at:
# https://sourceforge.net/tracker/?func=detail&aid=2780001&group_id=37044&atid=418758

BuildRequires:  gcc-gfortran, atlas-devel, fftw-devel
BuildRequires:  tetex-latex
BuildRequires:  cmake, doxygen, ghostscript

%description
IT++ is a C++ library of mathematical, signal processing, speech
processing, and communications classes and functions.  The kernel of
the IT++ library is built upon templated vector and matrix classes
with many functions for their manipulation.  Such a kernel makes IT++
similar to Octave.  IT++ makes extensive use of existing open-source
libraries (but not only) for increased functionality, speed, and
accuracy.


%package devel
Summary:Development files for itpp
Group:  Development/Libraries
Requires:   %{name}%{?_isa} = %{version}-%{release}
Requires:   fftw-devel%{?_isa}, atlas-devel%{?_isa}, gcc-gfortran%{?_isa}

%description devel
This package contains the itpp header files, libs, and man pages.


%package doc
Summary:Documentation for itpp
BuildArch:  noarch

%description doc
This package contains the documentation for itpp.


%prep
%setup -q

%build
%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
make %{?_smp_mflags}

%install
make install DESTDIR=$RPM_BUILD_ROOT
mv $RPM_BUILD_ROOT/usr/lib $RPM_BUILD_ROOT/%{_libdir}
perl -pi -e's:^libdir=\$\{exec_prefix}/lib$:libdir=\${exec_prefix}/lib64:' $RPM_BUILD_ROOT/%{_bindir}/%{name}-config 
perl -pi -e's:^libdir=/usr/lib$:libdir=/usr/lib64:' $RPM_BUILD_ROOT/%{_libdir}/pkgconfig/%{name}.pc
mkdir -p $RPM_BUILD_ROOT/%{_docdir}/%{name}
cp -p COPYING AUTHORS ChangeLog NEWS README \
  $RPM_BUILD_ROOT/%{_docdir}/%{name}


%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig


%files
%dir %{_docdir}/%{name}
%{_docdir}/%{name}/[A-Z]*
%{_libdir}/*.so.*
%{_datadir}/%{name}

%files devel
%{_includedir}/%{name}
%{_libdir}/*.so
%{_libdir}/pkgconfig/%{name}.pc
%{_bindir}/%{name}-config
%{_mandir}/man1/*

%files doc
%{_docdir}/%{name}/html


%changelog
* Wed Jan 18 2017 theodore.papadopo...@inria.fr = 4.3.1-0
- Switched to version 4.3.1
- Adapted to cmake build.

* Wed Jan 18 2017 BogusDateBot
- Eliminated rpmbuild "bogus date" warnings due to inconsistent weekday,
  by assuming the date is correct and changing the weekday.
  Tue Sep 13 2006 --> Tue Sep 12 2006 or Wed Sep 13 2006 or Tue Sep 19 2006 or 
  Sun Oct 28 2006 --> Sun Oct 22 2006 or Sat Oct 28 2006 or Sun Oct 29 2006 or 

* Wed Feb 09 2011 Fedora Release Engineering  - 4.0.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

* Fri Jul 24 2009 Fedora Release Engineering  - 4.0.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild

* Fri Apr 24 2009 Milos Jakubicek  - 4.0.6-1
- Fix FTBFS:
- Update to 4.0.6 bugfix release
- Dropped itpp-gcc43.patch (merged upstream).
- Added itpp-gcc44.patch

* Wed Feb 25 2009 Fedora Release Engineering  - 4.0.0-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild

* Mon Dec 15 2008 Deji Akingunola  - 4.0.0-6
- Rebuild for atlas-3.8.2

* Sun Sep 14 2008 Manuel "lonely wolf" Wolfshant  - 4.0.0-5
- Fix building with gcc4.3

* Fri May 23 2008 Jon Stanley  - 4.0.0-4
- Fix license tag

* Mon Feb 18 2008 Fedora Release Engineering  - 4.0.0-3
- Autorebuild for GCC 4.3

* Sun Dec  9 2007  Ed Hill  - 4.0.0-2
- fix hard-coded libdir error

* Sun Dec  9 2007  Ed Hill  - 4.0.0-1
- new upstream 4.0.0

* Sat Aug 25 2007  Ed Hill  - 3.10.12-1
- new upstream 3.10.12

* Tue Apr 17 2007  Ed Hill  - 3.10.10-1
- new upstream 3.10.10

* Tue Apr 17 2007  Ed Hill  - 3.10.9-2
- fix dir ownership per bz #233842

* Sun Mar 18 2007  Ed Hill  - 3.10.9-1
- new upstream 3.10.9

* Sat Feb 10 2007  Ed Hill  - 3.10.8-1
- new upstream 3.10.8

* Wed Dec  6 2006  Ed Hill  - 3.10.7-1
- new upstream 3.10.7

* Sat Oct 28 2006  Ed Hill  - 3.10.6-1
- new upstream 3.10.6

* Wed Oct 11 2006  Ed Hill  - 3.10.5-7
- explicitly link with -lstdc++

* Tue Oct 10 2006  Ed Hill  - 3.10.5-6
- fix unowned dir

* Sun Oct  8 2006  

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Kevin Kofler]

Hans de Goede wrote:
> most tools simply write directly to /sys/class/backlight, but xbacklight
> relies on the xrandr property (and is the only tool do so AFAICT).

KDE's PowerDevil supports both and prefers XRandR where supported:
https://cgit.kde.org/powerdevil.git/tree/daemon/backends/upower

As you pointed out, the nice thing about the XRandR property is that it does 
not require root access, whereas the sysfs interface requires going through 
a KAuth/PolicyKit helper to get root (which PowerDevil sets up with a 
default policy of "yes" so that all users can use it without a PolicyKit 
password prompt). It is sad that most drivers did not bother implementing 
it.

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

Re: Need assistance to fix LuxRender issue

[Kevin Kofler]

Luya Tshimbalanga wrote:
> After investigating the bug [1] on LuxRender failing to start,
> upstream[2] suggested a problem with qt4 configuration. Normally using
> luxrender should start but traceback with libQt5Core.so which shouldn't
> be used.

For the benefit of those reading the mailing list archives: This happens 
when you link to some library which is in turn linked to Qt 5.

Thankfully, in this case, the offending dependency chain was already tracked 
down and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1412089#c3

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

Re: Unretiring itpp

[Kevin Kofler]

Theodore Papadopoulo wrote:
> The only problem is that libraries got installed (as usual with cmake) in
> /usr/lib and not in /usr/lib64,

Only if the CMakeLists.txt is broken. It should use LIB_INSTALL_DIR and/or 
LIB_SUFFIX. In this case, it was fixed back in 2014 (!):
https://sourceforge.net/p/itpp/git/ci/8ff787c218c31ad90c51c2da54085e79bb7fd1b3/
(The last release is from 2013!)

> which I worked around with a mv (not sure this is teh best solution, but
> it works).

Please fix CMakeLists.txt (just backport the upstream fix) instead.

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

Re: Is there something wrong with the Koji builders?

[Kevin Fenzi]

ok. After a bunch of debugging and digging today it sure looks like the
underlying problem was squid operating in smp mode. 

We switched the squid servers back to non smp mode around 00:00 and I've
not seen any of these failures since then. 

I sure hope everything is back to normal now. 

kevin


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

Schedule for Friday's FESCo Meeting (2017-01-20)

[Kevin Fenzi]

 Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2017-01-20 16:00 UTC'

Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1635 F26 Self Contained Changes
.fesco 1635
https://pagure.io/fesco/issue/1635

= New business =

#topic #1665 Unresponsive maintainer: affix
.fesco 1665
https://pagure.io/fesco/issue/1665

#topic #1668 F26 System Wide Change: GCC7
.fesco 1668
https://pagure.io/fesco/issue/1668

#topic #1669 F26 System Wide Change: Parallel Installable Debuginfo
.fesco 1669
https://pagure.io/fesco/issue/1669

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

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



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

Re: Unretiring itpp

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 20, 2017 at 02:32:22AM +0100, Kevin Kofler wrote:
> Theodore Papadopoulo wrote:
> > The only problem is that libraries got installed (as usual with cmake) in
> > /usr/lib and not in /usr/lib64,
> 
> Only if the CMakeLists.txt is broken. It should use LIB_INSTALL_DIR and/or 
> LIB_SUFFIX. In this case, it was fixed back in 2014 (!):
> https://sourceforge.net/p/itpp/git/ci/8ff787c218c31ad90c51c2da54085e79bb7fd1b3/
> (The last release is from 2013!)
> 
> > which I worked around with a mv (not sure this is teh best solution, but
> > it works).
> 
> Please fix CMakeLists.txt (just backport the upstream fix) instead.

Without looking at the repo, it sounds like packaging a git snapshot would
be easier and better.

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

Re: drop obsolete static uid/gid allocations

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 19, 2017 at 11:33:55AM -0500, Przemek Klosowski wrote:
> On 01/14/2017 07:13 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >== No need for static allocation, afaict
> >games, man, slocate, squid, named, postgres, mysql, nscd,
> >rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
> >tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
> >imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci
> >
> >== The following are completely unused?
> >console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> >pvm, xfs
> 
> FWIW, there's also plugdev which I am involved in evicting from udev
> rules. I think by now it's only used by flashrom
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1330205

This reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=1226704,
another fight with windmills.

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

Re: drop obsolete static uid/gid allocations

[Adam Williamson]

On Sun, 2017-01-15 at 00:13 +, Zbigniew Jędrzejewski-Szmek wrote:
> == The following are completely unused?
> console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> pvm, xfs

haldaemon was HAL:

https://en.wikipedia.org/wiki/HAL_(software)

whose functionality was taken over by udev, years ago.

beagleindex (from the other list) was for the Beagle desktop search
system:

https://en.wikipedia.org/wiki/Beagle_(software)

which died long ago and is functionally replaced by tracker in current
Fedora. So both of those can certainly go.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org