Re: F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

2018-02-04 Thread Sinny Kumari 
On Fri, Feb 2, 2018 at 8:25 PM, Daniel Walsh  wrote:
> On 01/31/2018 06:26 PM, Josh Boyer wrote:
>>
>> On Tue, Jan 30, 2018 at 12:42 PM, Daniel Walsh  wrote:
>>>
>>> On 01/30/2018 11:50 AM, Jan Kurik wrote:

 = Proposed Self Contained Change: Atomic, Cloud and Docker images for
 s390x =


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

 Change owner(s):
 * Sinny Kumari 


 This change is to bring s390x architecture closer to other Fedora
 architectures by adding widely used Fedora variants. This includes
 docker images, Atomic Host (iso, qcow2 and raw format) and regular
 Cloud Images (qcow2 and raw format).


 == Detailed Description ==
 We already ship Atomic, Cloud and Docker images on other 64-bit Fedora
 supported architectures- aarch64, x86_64 and ppc64le. With Fedora 27,
 s390x is part of primary koji build system. Currently, we only ship
 Server and Everything variants for s390x. So, our next steps should be
 to have missing Fedora variants on s390x architecture which users will
 find useful. This brings in shipping Atomic, Cloud and Docker images
 in Fedora for s390x as well.


 == Scope ==
 * Proposal owners:
 These are isolated changes which doesn't impact existing Fedora 28
 release plan on s390x. To have these changes ready to ship in Fedora
 28, we mainly require s390x koji builders configured to run these
 composes, changes in pungi configuration [
 https://pagure.io/pungi-fedora/pull-request/496 ] to enable the
 additional compose and fixing s390x specific issues encountered when
 compose fails to run.

 * Other developers:
 Changes in Fedora infrastructure configs/scripts will be required to
 have s390x builders configured to run additional composes. Fedora
 Infrastructure issue [
 https://pagure.io/fedora-infrastructure/issue/6659 ] has been filed to
 keep track of required changes to be done.

 * Release engineering:
 #Releng 7286: https://pagure.io/releng/issue/7286

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

 * Trademark approval:
 N/A (not needed for this Change)
>>>
>>>
>>> You mean OCI Images...
>>
>> Mostly likely, yes.
>>
>> Relatedly, has there been a change request to move the default
>> container runtime to cri-o or runc or rkt or anything other than
>> docker in Fedora Atomic?  If so, that will be neat and I'm sorry I
>> missed it.  If not, why not?
>
> Not yet.  We are working on packaging podman which would give users the same
> experience as Docker CLI without requiring a Daemon.  That would be the
> thing to replace
> Docker if we went that way.  CRI-O != Docker.  It does not have any of the
> CLI that users would expect.

Thanks Dan! Nice to know about podman.

> Rkt is dead in my opinion.  runc is on Atomic host now, I believe.

Indeed, runc is part of base Atomic Host.

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



-- 
http://sinny.io/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

2018-02-04 Thread David Airlie 
On Thu, Feb 1, 2018 at 12:13 PM, Tomasz Kłoczko 
wrote:

>
> On 1 February 2018 at 01:42, Peter Hutterer 
> wrote:
> [..]
>
>> > So event4 it is in my case touch pad and event5  it is Logitech M185
>> mouse.
>> > In other words: those "libinput bug" log entries looks like are not
>> related
>> > to emitting those short bursts of repeating keystrokes.
>>
>> not directly, but they indicate where the issue is: key repeat is handled
>> in
>> the clients, not in libinput. With delays like this it's easy to see why
>> you
>> would get key repeat - if your key release event is delayed by 300ms or
>> more
>> the client will handle repeats before it gets the events.
>>
>> But the real cause of the issue is that you're getting crazy delays
>> because
>> gnome-shell is too busy with something else. The rest is fallout from
>> that.
>>
>
> So that is quite possible explanation and cause of those delays probably
> is in what I've already described.
> Every few second in kernel messages I have sequence:
>
> [74330.405990] [drm] PCIE gen 2 link speeds already enabled
> [74330.417096] [drm] PCIE GART of 1024M enabled (table at
> 0x00162000).
> [74330.417206] radeon :01:00.0: WB enabled
> [74330.417212] radeon :01:00.0: fence driver on ring 0 use gpu addr
> 0x2c00 and cpu addr 0xd8c75981
> [74330.417216] radeon :01:00.0: fence driver on ring 3 use gpu addr
> 0x2c0c and cpu addr 0x1142ed24
> [74330.417965] radeon :01:00.0: fence driver on ring 5 use gpu addr
> 0x00072118 and cpu addr 0x095357f2
> [74330.434413] [drm] ring test on 0 succeeded in 2 usecs
> [74330.434428] [drm] ring test on 3 succeeded in 7 usecs
> [74330.611793] [drm] ring test on 5 succeeded in 2 usecs
> [74330.611809] [drm] UVD initialized successfully.
> [74330.611949] [drm] ib test on ring 0 succeeded in 0 usecs
> [74330.612118] [drm] ib test on ring 3 succeeded in 0 usecs
> [74331.267267] [drm] ib test on ring 5 succeeded
> [74340.515810] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [74340.515819] swiotlb: coherent allocation failed for device :01:00.0
> size=2097152
> [74340.515827] CPU: 0 PID: 27342 Comm: kworker/0:1 Tainted: GW
> 4.15.0-0.rc9.git4.1.fc28.x86_64 #1
> [74340.515832] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS
> R2087H4 06/15/2012
> [74340.515841] Workqueue: pm pm_runtime_work
> [74340.515849] Call Trace:
> [74340.515862]  dump_stack+0x85/0xbf
> [74340.515871]  swiotlb_alloc_coherent+0xe0/0x150
> [74340.515889]  ttm_dma_pool_get_pages+0x21b/0x620 [ttm]
> [74340.515908]  ttm_dma_populate+0x24d/0x340 [ttm]
> [74340.515923]  ttm_bo_move_memcpy+0x185/0x610 [ttm]
> [74340.515933]  ? lock_acquire+0x9f/0x200
> [74340.515940]  ? reservation_object_wait_timeout_rcu+0xb3/0x500
> [74340.515987]  radeon_bo_move+0x1a7/0x220 [radeon]
> [74340.516003]  ttm_bo_handle_move_mem+0x2a4/0x5d0 [ttm]
> [74340.516021]  ttm_bo_evict+0x186/0x370 [ttm]
> [74340.516046]  ttm_mem_evict_first+0x174/0x1d0 [ttm]
> [74340.516060]  ttm_bo_force_list_clean+0x6d/0x130 [ttm]
> [74340.516089]  radeon_suspend_kms+0x11e/0x3e0 [radeon]
> [74340.516103]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516126]  radeon_pmops_runtime_suspend+0x54/0xc0 [radeon]
> [74340.516135]  pci_pm_runtime_suspend+0x61/0x170
> [74340.516144]  vga_switcheroo_runtime_suspend+0x24/0xa0
> [74340.516151]  __rpm_callback+0xbc/0x1f0
> [74340.516160]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516168]  rpm_callback+0x1f/0x70
> [74340.516175]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516181]  rpm_suspend+0x12d/0x6e0
> [74340.516195]  pm_runtime_work+0x73/0xb0
> [74340.516204]  process_one_work+0x249/0x6b0
> [74340.516219]  worker_thread+0x3a/0x390
> [74340.516229]  ? process_one_work+0x6b0/0x6b0
> [74340.516236]  kthread+0x121/0x140
> [74340.516243]  ? kthread_create_worker_on_cpu+0x70/0x70
> [74340.516253]  ret_from_fork+0x3a/0x50
>
> during which whole desktop is frozen for fraction of the second. During
> those freezes it is not possible even to move mouse cursor.
> Do you have idea what it may be?
>

Try booting with radeon.runpm=0

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

Re: Rawhide buildroot broken?

2018-02-04 Thread Doug Ledford 
On Sun, 2018-02-04 at 14:30 -0800, Kevin Fenzi wrote:
> On 02/04/2018 01:38 PM, Jan Kratochvil wrote:
> > On Sun, 04 Feb 2018 22:14:47 +0100, Doug Ledford wrote:
> > > cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded 
> > > from short plugin name annobin: No such file or directory
> > 
> > ...
> > > So, where is the gcc plugin annobin?
> > 
> > In my fresh Rawhide buildroot
> > https://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=11315754
> > I got
> > annobin-3.1-2.fc28.x86_64.rpm
> > which contains
> > /usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so.0.0.0
> > while latest annobin build
> > annobin-3.3-1.fc28
> > already contains
> > /usr/lib/gcc/x86_64-redhat-linux/8/plugin/annobin.so.0.0.0
> > which is needed for gcc v8 in the buildroot I got
> > gcc-8.0.1-0.9.fc28.x86_64.rpm
> > I am only curious why fresh Rawhide buildroots still have so old annobin 
> > when
> > annobin-3.3-1.fc28 has been built on Jan 30th - 5 days ago.
> 
> Sorry, I caused that. I cleaned out some packages that were stuck in the
> f28-pending tag for signing.
> 
> I've untagged the old annobin now... the next buildreoot regen should be
> ok again.
> 

Thanks, build worked now ;-)

-- 
Doug Ledford 
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

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

2018-02-04 Thread Tomasz Kłoczko 
On 4 February 2018 at 07:00, Samuel Sieb  wrote:

> On 02/02/2018 12:55 PM, Chris Murphy wrote:
>
>> Yeah I'm getting a bunch of clutter messages as well as many lines of
>> gnome shell desktop related stack traces. But there is nothing listed
>> by coredumpctl, or abrt.
>>
>>
>> Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
>> Stack trace for context 0x557b7ae9d000 ==
>>
>
> The gnome shell related stack traces have been going for a while. They're
> really annoying, but not fatal.  However, there is an issue with the Places
> menu extension that cause gnome shell to crash when a USB device is plugged
> in and also other situations.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1538493


In my case it is not necessary to do anything around USB.
Actually they are fatal.
Setting keyboard mapping is not working at all (I'm using as primary Polish
programmer kbd mapping).
Polari IRC client is not able to communicate with shell and by this is
completely useless (after joining channels after |1 min everything
disconnects from iRC server).
Whole desktop initiates incredibly slow (about maybe even 10 times longer
than it was before).
Every 10-20 min shell is dying completely and until it will be not
restarted it is not possible to do anything.

Just started tracing files operations using "strace -fe trace=file -p
" and found that gnome-shell is trying to stat() directories which it
shouldn't be trying to stat()

[pid 25382] stat("/usr/share/pixmaps/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/local/share/pixmaps/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/gnome", {st_mode=S_IFDIR|0755,
st_size=140, ...}) = 0
[pid 25382] stat("/usr/local/share/icons/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/gnome", 0x7ffe80cddd40)
= -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/Adwaita",
0x7ffe80cddd40) = -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/Adwaita", {st_mode=S_IFDIR|0755,
st_size=222, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/hicolor",
{st_mode=S_IFDIR|0700, st_size=58, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/hicolor", {st_mode=S_IFDIR|0755,
st_size=270, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons",
{st_mode=S_IFDIR|0700, st_size=14, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/local/share/icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/icons", {st_mode=S_IFDIR|0755, st_size=120,
...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/share/pixmaps", {st_mode=S_IFDIR|0755, st_size=944,
...}) = 0
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] stat("/home/tkloczko/.local/share/sounds",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid 25382] stat("/usr/local/share/sounds", 0x7ffe80cde5e0) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/sounds", {st_mode=S_IFDIR|0755, st_size=86,
...}) = 0

Of course above is not a cause of current crashes but it would be good to
patch gnome-shell or some gnome libraries which are trying to search cross
some of above directories. and
Looks like gnome-shell is doing sequence of those stats regularly (why?)

Just checked what has been changed on my system at 31 Jan and I found:

# rpm -qa --qf "%{INSTALLTIME:date} %{NAME}\n" | grep "31 Jan 2018" | grep
-v debuginfo | sort -k 7 | grep g
Wed 31 Jan 2018 23:34:25 GMT compat-gdbm
Wed 31 Jan 2018 23:13:41 GMT dbus-glib
Wed 31 Jan 2018 23:28:13 GMT dbus-glib-devel
Wed 31 Jan 2018 23:15:20 GMT gdbm
Wed 31 Jan 2018 23:13:31 GMT gjs<< here
Wed 31 Jan 2018

Fedora Rawhide-20180204.n.0 compose check report

2018-02-04 Thread Fedora compose checker 
Missing expected images:

Workstation live i386
Kde live i386

Failed openQA tests: 10/129 (x86_64), 4/22 (i386), 1/2 (arm)

ID: 190720  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/190720
ID: 190750  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/190750
ID: 190751  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/190751
ID: 190752  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/190752
ID: 190753  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/190753
ID: 190754  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/190754
ID: 190755  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/190755
ID: 190765  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/190765
ID: 190767  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/190767
ID: 190768  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/190768
ID: 190788  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/190788
ID: 190794  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/190794
ID: 190836  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/190836
ID: 190843  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/190843
ID: 190849  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/190849

Soft failed openQA tests: 18/129 (x86_64), 3/22 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 190728  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/190728
ID: 190729  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/190729
ID: 190733  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/190733
ID: 190735  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/190735
ID: 190736  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/190736
ID: 190746  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/190746
ID: 190749  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/190749
ID: 190776  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/190776
ID: 190777  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/190777
ID: 190789  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/190789
ID: 190791  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/190791
ID: 190800  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/190800
ID: 190801  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/190801
ID: 190803  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/190803
ID: 190805  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/190805
ID: 190813  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/190813
ID: 190831  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/190831
ID: 190833  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/190833
ID: 190837  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/190837
ID: 190838  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/190838
ID: 190841  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/190841

Passed openQA tests: 88/129 (x86_64), 15/22 (i386)

Skipped openQA tests: 10 of 153
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide buildroot broken?

2018-02-04 Thread Kevin Fenzi 
On 02/04/2018 01:38 PM, Jan Kratochvil wrote:
> On Sun, 04 Feb 2018 22:14:47 +0100, Doug Ledford wrote:
>> cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded 
>> from short plugin name annobin: No such file or directory
> ...
>> So, where is the gcc plugin annobin?
> 
> In my fresh Rawhide buildroot
>   https://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=11315754
> I got
>   annobin-3.1-2.fc28.x86_64.rpm
> which contains
>   /usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so.0.0.0
> while latest annobin build
>   annobin-3.3-1.fc28
> already contains
>   /usr/lib/gcc/x86_64-redhat-linux/8/plugin/annobin.so.0.0.0
> which is needed for gcc v8 in the buildroot I got
>   gcc-8.0.1-0.9.fc28.x86_64.rpm
> I am only curious why fresh Rawhide buildroots still have so old annobin when
> annobin-3.3-1.fc28 has been built on Jan 30th - 5 days ago.

Sorry, I caused that. I cleaned out some packages that were stuck in the
f28-pending tag for signing.

I've untagged the old annobin now... the next buildreoot regen should be
ok again.

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: Rawhide buildroot broken?

2018-02-04 Thread Jan Kratochvil 
On Sun, 04 Feb 2018 22:14:47 +0100, Doug Ledford wrote:
> cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded 
> from short plugin name annobin: No such file or directory
...
> So, where is the gcc plugin annobin?

In my fresh Rawhide buildroot
https://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=11315754
I got
annobin-3.1-2.fc28.x86_64.rpm
which contains
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so.0.0.0
while latest annobin build
annobin-3.3-1.fc28
already contains
/usr/lib/gcc/x86_64-redhat-linux/8/plugin/annobin.so.0.0.0
which is needed for gcc v8 in the buildroot I got
gcc-8.0.1-0.9.fc28.x86_64.rpm
I am only curious why fresh Rawhide buildroots still have so old annobin when
annobin-3.3-1.fc28 has been built on Jan 30th - 5 days ago.


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

Proposal to CANCEL: 2018-02-05 QA Devel Meeting

2018-02-04 Thread Tim Flink 
I'm not aware of any topics that need urgent discussion this week, so I
propose that we cancel the QA Devel meeting on 2018-02-05.

If there are some topics that need discussing, please reply here and
the meeting can happen.

Tim


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

Rawhide buildroot broken?

2018-02-04 Thread Doug Ledford 
I'm having an issue, and as far as I can tell it's not in my package. 
The rdma-core package uses cmake and ninja-build to build itself, and
the very first test in the CMakeLists.txt makefile is the TestCCompiler
test that is shipped with CMake, not one of our own tests.  And it's
failing because it can't run gcc. The failure there is this:

[1/2] Building C object CMakeFiles/cmTC_8f50c.dir/testCCompiler.c.o
FAILED: CMakeFiles/cmTC_8f50c.dir/testCCompiler.c.o 
/usr/bin/cc   -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -o 
CMakeFiles/cmTC_8f50c.dir/testCCompiler.c.o   -c testCCompiler.c
cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded from 
short plugin name annobin: No such file or directory
compilation terminated.
ninja: build stopped: subcommand failed.

So, where is the gcc plugin annobin?  Is there a BuildRequires: that I
need to add with gcc-8.0.1 that I didn't know about?  And if there is,
why isn't it part of the Build package group since the RPM macros the
build system defines are the ones telling gcc to use annobin?

-- 
Doug Ledford 
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

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: F27 strange rpmbuild failure

2018-02-04 Thread Alec Leamas 


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


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

Re: F27 strange rpmbuild failure

2018-02-04 Thread Steve Grubb 
On Sunday, February 4, 2018 1:38:27 PM EST Antonio wrote:
> On 04/02/2018 19:27, Steve Grubb wrote:
> > On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
> >> On 04/02/2018 18:13, Steve Grubb wrote:
> >>> Hello,
> >>> 
> >>> I am building a package locally and run across a failure that seems to
> >>> be unexplained. It gets to the install phase and then abruptly fails
> >>> with the following build log:
>
> I don't see any error apart that you are installing files in not
> permitted file location '/usr/local'.

Its a tangled mess to move it from /usr/local. So, I just make srpm's 
available for people to build on their own.

-Steve


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

Re: F27 strange rpmbuild failure

2018-02-04 Thread Steve Grubb 
On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:
> On 04/02/18 19:30, Steve Grubb wrote:
> > On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
> > 
> >> Not enough information to check signature validity.Show Details
> >>
> >> On 04/02/2018 18:13, Steve Grubb wrote:
> >> 
> >>> Hello,
> 
> >>> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> >>> error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN
> 
> >> Full build log, please.
> > 
> > It's too big for the mail list. I put it here:
> > 
> > http://people.redhat.com/sgrubb/files/build.log
> 
> 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? 

> Another question: brp-python-bytecompile tries to use /usr/bin/python
> which still is python2.7 (I think). So, have you a BR: python2-devel, or
> is the python command just missing in the build environment?

This is being built on my local system. Its has both available:

# rpm -qa | grep python | grep devel
python2-devel-2.7.14-7.fc27.x86_64
python3-devel-3.6.4-7.fc27.x86_64

But this package uses no python anywhere. So, its strange that the build is 
getting tripped up on python.

Thanks for the help. This should let me release an Rstudio 1.1 srpm shortly.

Thanks,
-Steve


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

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

2018-02-04 Thread updates 
The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 936  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 826  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 797  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 137  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  28  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  23  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1049ca4872   
GraphicsMagick-1.3.28-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-369a48191f   
clamav-0.99.3-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab   
tomcat-7.0.84-1.el6


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

beakerlib-1.17-9.el6
mup-6.6-1.el6
p7zip-16.02-9.el6
python-regex-2018.02.03-1.el6

Details about builds:



 beakerlib-1.17-9.el6 (FEDORA-EPEL-2018-402489274f)
 A shell-level integration testing library

Update Information:

- support rxvt terminal colors - phase name sanitization (remove all weird
characters) - allow debug message to to only to console (speeds execution up in
debug) - allow to reboot inside of phase and continue there - fixed persistent
data loading




 mup-6.6-1.el6 (FEDORA-EPEL-2018-b35e9f979e)
 A music notation program that can also generate MIDI files

Update Information:

Update to Mup 6.6




 p7zip-16.02-9.el6 (FEDORA-EPEL-2018-a0fe4d146c)
 Very high compression ratio file archiver

Update Information:

Security fix for CVE-2017-17969 (from Debian)

References:

  [ 1 ] Bug #1538457 - CVE-2017-17969 p7zip: heap-based buffer overflow in 
7zip/Compress/ShrinkDecoder.cpp can allow an attacker to write arbitrary data 
and cause a crash
https://bugzilla.redhat.com/show_bug.cgi?id=1538457




 python-regex-2018.02.03-1.el6 (FEDORA-EPEL-2018-7a5368377e)
 Alternative regular expression module, to replace re

Update Information:

Update to the latest released version.

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

Re: F27 strange rpmbuild failure

2018-02-04 Thread Alec Leamas 


On 04/02/18 19:30, Steve Grubb wrote:
> On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
>> Not enough information to check signature validity.  Show Details
>>
>> On 04/02/2018 18:13, Steve Grubb wrote:
>>> Hello,
>>>

>>> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
>>> error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN

>> Full build log, please.
> 
> It's too big for the mail list. I put it here:
> 
> http://people.redhat.com/sgrubb/files/build.log



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

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

Another question: brp-python-bytecompile tries to use /usr/bin/python
which still is python2.7 (I think). So, have you a BR: python2-devel, or
is the python command just missing in the build environment?



Cheers!
--alec
[1]
https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 strange rpmbuild failure

2018-02-04 Thread Antonio 
On 04/02/2018 19:27, Steve Grubb wrote:
> On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
>> On 04/02/2018 18:13, Steve Grubb wrote:
>>> Hello,
>>>
>>> I am building a package locally and run across a failure that seems to be
>>> unexplained. It gets to the install phase and then abruptly fails with
>>> the following build log:
>>>

I don't see any error apart that you are installing files in not
permitted file location '/usr/local'.

-- 
---
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: F27 strange rpmbuild failure

2018-02-04 Thread Steve Grubb 
On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
> Not enough information to check signature validity.   Show Details
> 
> On 04/02/2018 18:13, Steve Grubb wrote:
> > Hello,
> > 
> > I am building a package locally and run across a failure that seems to be
> > unexplained. It gets to the install phase and then abruptly fails with
> > the
> > following build log:
> > 
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac
> > k- askpass
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac
> > k- editfile
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac
> > k- gitssh
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostbac
> > k- pdfviewer
> > -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass-
> > passthrough
> > + rm -rf /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64//usr/lib64
> > + /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i
> > --build-id-seed 1.1.422-1.fc27 --unique-debug-suffix
> > -1.1.422-1.fc27.x86_64 --unique-debug- src-base
> > R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die-
> > limit 1000 --dwz-max-die-limit 11000 -S debugsourcefiles.list
> > /home/ sgrubb/working/BUILD/rstudio-1.1.422
> > extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio
> > extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession
> > extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics
> > extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> > desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
> > /usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match.
> > 15342 blocks
> > + /usr/lib/rpm/check-buildroot
> > + /usr/lib/rpm/brp-compress
> > + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> > + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> > error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN
> > (%install)
> > 
> > RPM build errors:
> > Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
> > 
> > 
> > Is the output from sepdebugcrcfix indicating a failure? If so, how do you
> > fix this? If its not this, its really weird because there is plenty of
> > disk space and no other indication that something is wrong.
> > 
> > Thanks,
> > -Steve
> 
> Full build log, please.

It's too big for the mail list. I put it here:

http://people.redhat.com/sgrubb/files/build.log

-Steve


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

Re: F27 strange rpmbuild failure

2018-02-04 Thread Antonio Trande 
On 04/02/2018 18:13, Steve Grubb wrote:
> Hello,
> 
> I am building a package locally and run across a failure that seems to be
> unexplained. It gets to the install phase and then abruptly fails with the
> following build log:
> 
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
> askpass
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
> editfile
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
> gitssh
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
> pdfviewer
> -- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass-
> passthrough
> + rm -rf /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64//usr/lib64
> + /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed 
> 1.1.422-1.fc27 --unique-debug-suffix -1.1.422-1.fc27.x86_64 --unique-debug-
> src-base R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die-
> limit 1000 --dwz-max-die-limit 11000 -S debugsourcefiles.list /home/
> sgrubb/working/BUILD/rstudio-1.1.422
> extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio
> extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession
> extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics
> extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
> desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
> /usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match.
> 15342 blocks
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/brp-compress
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN 
> (%install)
> 
> RPM build errors:
> Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)
> 
> 
> Is the output from sepdebugcrcfix indicating a failure? If so, how do you fix
> this? If its not this, its really weird because there is plenty of disk space
> and no other indication that something is wrong.
> 
> Thanks,
> -Steve
> 


Full build log, please.

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

F27 strange rpmbuild failure

2018-02-04 Thread Steve Grubb 
Hello,

I am building a package locally and run across a failure that seems to be
unexplained. It gets to the install phase and then abruptly fails with the
following build log:

-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
askpass
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
editfile
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
gitssh
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/rpostback-
pdfviewer
-- Installing: /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/postback/askpass-
passthrough
+ rm -rf /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64//usr/lib64
+ /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed 
1.1.422-1.fc27 --unique-debug-suffix -1.1.422-1.fc27.x86_64 --unique-debug-
src-base R-studio-desktop-1.1.422-1.fc27.x86_64 --run-dwz --dwz-low-mem-die-
limit 1000 --dwz-max-die-limit 11000 -S debugsourcefiles.list /home/
sgrubb/working/BUILD/rstudio-1.1.422
extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rstudio
extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rsession
extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/diagnostics
extracting debug info from /home/sgrubb/working/BUILDROOT/R-studio-
desktop-1.1.422-1.fc27.x86_64/usr/local/lib/rstudio/bin/rpostback
/usr/lib/rpm/sepdebugcrcfix: Updated 4 CRC32s, 0 CRC32s did match.
15342 blocks
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN 
(%install)

RPM build errors:
Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN (%install)


Is the output from sepdebugcrcfix indicating a failure? If so, how do you fix
this? If its not this, its really weird because there is plenty of disk space
and no other indication that something is wrong.

Thanks,
-Steve

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

Re: The New Hotness builds failing with py2_dist macros

2018-02-04 Thread Jeremy Cline 
On 02/02/2018 11:39 PM, Jason L Tibbitts III wrote:
> Actually comprehending your message, I see it's not you building this
> package at all and it's not doing it in koji, either.  So I wonder what
> environment is present when hotness is trying to build the SRPM.  If
> somehow it doesn't have redhat-rpm-config installed (or epel-rpm-macros
> if running on RHEL) then you would get errors like that do to %py2_dist
> not being defined at all.

It runs on EL7 at the moment, but there are tickets open to move it to
the latest Fedora release since it also doesn't support a lot of the
newer RPM features (Suggests, for example).


-- 
Jeremy Cline
XMPP: jer...@jcline.org
IRC:  jcline



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: F28 Self Contained Change: Removing ldconfig scriptlets

2018-02-04 Thread Rex Dieter 
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.

-- Rex

___
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

2018-02-04 Thread Thomas Haller 
On Tue, 2018-01-30 at 10:04 +0100, Igor Gnatenko wrote:
> For those who didn't check Change page since today's morning: Thanks
> to Jason
> Tibbits (tibbs) who proposed %ldconfig_scriptlets macro and its
> implementation. 
> 
> Now we have 4 macros you could use: %ldconfig, %ldconfig_post,
> %ldconfig_postun, %ldconfig_scriptlets.
> 
> So long story short:
> * If you have %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig,
> replace it
> with %ldconfig_scriptlets
> * If you have just one of those, replace it with %ldconfig_post or
> %ldconfig_postun accordingly
> * If you just call to /sbin/ldconfig from one of your scriptlets in
> shell, just
> replace it with %?ldconfig
> 
> However, if you are not interested to support distro versions less
> than F28,
> then just remove scriptlets  Although on F28+, those macro expand t
> o nothin
> g so it's just matter of having 1-2 additional lines in spec file.

Hi,

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,
because that is how I test the package...

See 
https://src.fedoraproject.org/rpms/network-manager-applet/c/d6f6981153e4bc1512c0d45d34ca23b4624e4d90?branch=master


best,
Thomas


> 
> On Mon, 2018-01-29 at 22:30 +0100, Jan Kurik wrote:
> > = Proposed Self Contained Change: Removing ldconfig scriptlets =
> > https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
> > 
> > Change owner(s):
> > * Igor Gnatenko 
> > * Neal Gompa 
> > 
> > For many years, package maintainers were required to write
> > scriptlets
> > which call ldconfig in %post/%postun if they package shared
> > libraries.
> > 
> > == Detailed Description ==
> > Since time immemorial, Red Hat/Fedora packagers have been required
> > to
> > add a stanza to spec files for packages containing libraries to
> > update
> > the ldconfig cache.
> > 
> > %post -p /sbin/ldconfig
> > %postun -p /sbin/ldconfig
> > 
> > To say this is annoying is to put it mildly. However, there was no
> > standard mechanism to make this boilerplate go away. Now with RPM
> > 4.13+, we should change this to file triggers and make all of that
> > go
> > away.
> > 
> > With this change, these scriptlets can be removed and ldconfig
> > would
> > be run just once per transaction.
> > 
> > If your package places shared libraries in special locations
> > referenced by ld.so.conf, you still need to run ldconfig manually.
> > 
> > For those who concerned about whether this is self-contained or
> > system-wide change: there is no overhead if packagers don't remove
> > ldconfig scriptlets in time, so completion doesn't depend whether
> > packagers remove them or not. We are just making it possible.
> > 
> > 
> > == Scope ==
> > * Proposal owners:
> > Make sure that DSO symlinks are being packagedcommit, add
> > transaction
> > filetriggers to glibccommit + commit.
> > 
> > * Other developers:
> > Package maintainers are advised to remove ldconfig scriptlets in
> > order
> > to achieve benefits specified above.
> > 
> > * Release engineering:
> > #7284: https://pagure.io/releng/issue/7284
> > 
> > * List of deliverables:
> > N/A (not a System Wide Change)
> > 
> > * Policies and guidelines:
> > Packaging guidelines need to be updated to reflect reality.
> > 
> > * Trademark approval:
> > N/A (not needed for this Change)
> > -- 
> > Jan Kuřík
> > Platform & Fedora Program Manager
> > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Bug 1541736] New: perl-bignum-0.49 is available

2018-02-04 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1541736

Bug ID: 1541736
   Summary: perl-bignum-0.49 is available
   Product: Fedora
   Version: rawhide
 Component: perl-bignum
  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



Latest upstream release: 0.49
Current version/release in rawhide: 0.48-1.fc28
URL: http://search.cpan.org/dist/bignum/

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

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

2018-02-04 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1534885



--- Comment #3 from Emmanuel Seyman  ---
Now that we have DBIx-Class-Schema-Loader 0.07048, tests pass.

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

2018-02-04 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1517785



--- Comment #1 from Emmanuel Seyman  ---
Version 0.07048 mitigates the change in behaviour in Hash::Merge and builds
without error.

-- 
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 1539954] perl-CSS-DOM-0.17 is available

2018-02-04 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1539954

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-CSS-DOM-0.17-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-04 04:09:26



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1023770

-- 
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 1541680] perl-Mojolicious-7.62 is available

2018-02-04 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1541680

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.62-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2018-02-04 04:08:11



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1023769

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

2018-02-04 Thread nicolas . mailhot 


- Mail original -
De: "Nicolas Mailhot"

> It's a bit of a Lego guideline, you assemble the spec blocs you need, and 
> ignore those you don't need. The
> example was chosen to include as many blocks as possible, with the 
> walkthrough explaining their respective
> functions. All the blocks are very short and succinct, don't search for long 
> runs of shell code like in the old
> guidelines

That being said if people feel it's useful I can add a barebones lib-only 
example with none of the optional blocks in. However, I fear that the more ways 
the page explains the same stuff, the more confusing and difficult to maintain 
it will be.

So, can people chime in to say whether they feel a supplementary example is 
useful of counter productive?

Regards,

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