Fedora Rawhide-20180430.n.0 compose check report
No missing expected images. Failed openQA tests: 38/137 (x86_64), 14/24 (i386), 1/2 (arm) ID: 231470 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/231470 ID: 231483 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/231483 ID: 231484 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/231484 ID: 231485 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/231485 ID: 231495 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/231495 ID: 231497 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/231497 ID: 231499 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/231499 ID: 231500 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/231500 ID: 231501 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/231501 ID: 231502 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/231502 ID: 231504 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/231504 ID: 231506 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/231506 ID: 231516 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/231516 ID: 231520 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/231520 ID: 231521 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/231521 ID: 231523 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/231523 ID: 231533 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/231533 ID: 231534 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/231534 ID: 231535 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/231535 ID: 231540 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/231540 ID: 231542 Test: x86_64 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/231542 ID: 231543 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/231543 ID: 231544 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/231544 ID: 231545 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/231545 ID: 231547 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/231547 ID: 231549 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/231549 ID: 231552 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/231552 ID: 231556 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/231556 ID: 231557 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/231557 ID: 231558 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/231558 ID: 231569 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/231569 ID: 231570 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/231570 ID: 231571 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/231571 ID: 231574 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/231574 ID: 231575 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/231575 ID: 231576 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/231576 ID: 231581 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/231581 ID: 231582 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/231582 ID: 231585 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/231585 ID: 231587 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/231587 ID: 231590 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/231590 ID: 231593 Test: x86_64 universal install_lvmthin@uefi
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2018-05-01 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default
On 04/30/2018 02:16 PM, Neal Gompa wrote: > > And there's still the fun restriction of XFS not being able to shrink. It's > not particularly important in the server case, but in the desktop/laptop > case, it happens enough in my experience that I'm not sure I'd want a > default filesystem that can't shrink. Yes! I've been wanting that for a long long time! Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default
On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III wrote: > > "CW" == Colin Walters writes: > CW> I'd say it makes sense to revisit the default here globally in > CW> Anaconda. > Maybe. Have the issues which made XFS less suitable for use on laptops > been resolved? The primary one I recall was that each mounted > filesystem would have a corresponding kernel thread doing about 20 > wakeups per second. This was not really good for battery life and power > consumption in general. > Last I checked (which was 2016 or so) those wakeups were slated to be > around for a while longer. > https://www.spinics.net/lists/xfs/msg40210.html And there's still the fun restriction of XFS not being able to shrink. It's not particularly important in the server case, but in the desktop/laptop case, it happens enough in my experience that I'm not sure I'd want a default filesystem that can't shrink. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default
> "CW" == Colin Walters writes: CW> I'd say it makes sense to revisit the default here globally in CW> Anaconda. Maybe. Have the issues which made XFS less suitable for use on laptops been resolved? The primary one I recall was that each mounted filesystem would have a corresponding kernel thread doing about 20 wakeups per second. This was not really good for battery life and power consumption in general. Last I checked (which was 2016 or so) those wakeups were slated to be around for a while longer. https://www.spinics.net/lists/xfs/msg40210.html - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphaning schroot package
I'm orphaning the schroot package, since I no longer use it or work with it: https://src.fedoraproject.org/rpms/schroot There is currently a serious (crash) bug affecting the package in F28: https://bugzilla.redhat.com/show_bug.cgi?id=1573253 Upstream: https://packages.debian.org/search?keywords=schroot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Stop building 389-ds-base on i686
On 04/05/2018 03:29 PM, Mark Reynolds wrote: On 04/05/2018 07:02 AM, Florian Weimer wrote: On 03/29/2018 10:59 PM, Mark Reynolds wrote: I believe it's our cmocka tests that occur at rpm package time that brought this to our attention. So it is easy to reproduce. Well, I tried, but the package no longer builds on rawhide, even on x86_64: libtool: error: cannot find the library 'libldaputil.la' or unhandled argument 'libldaputil.la' We randomly see this build failure, sometimes the build completes, and sometimes it fails with the the above error, and we are playing wack-a-mole trying to fix it. At first I thought it was a bug in gcc (rawhide), but it still randomly fails. I do have a patch I plan to push upstream, but I don't know if it will fix it 100% of the time. Okay, I assume this has been fixed now. I removed ExcludeArch, enabled the %check section, and got this on i686: https://koji.fedoraproject.org/koji/taskinfo?taskID=26683192 I don't see any test suite failures. I'm afraid, unless you have concrete reproduction steps, I cannot really help you to fix this. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On Mon, Apr 30, 2018 at 10:25 AM, Yaakov Selkowitz wrote: gedit, like most GNOME components, uses gnome-autogen.sh; in this particular case, iirc ACLOCAL_PATH="libgd" also needs to be set. There's also AUTOPOINT='intltoolize --automake --copy' which gedit needs for autoreconf to not break things. Of course, it'd be better to improve gedit's build system, but my point is that there are going to be problems building many modules if we try running autoreconf automatically. And trying to detect and run autogen.sh instead won't work, because it rightly often isn't distributed. On Mon, Apr 30, 2018 at 10:25 AM, Yaakov Selkowitz wrote: like most GNOME components BTW gnome-autogen.sh has been deprecated for a long time, so not much should be using it nowadays. gedit is kinda stuck in the past. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Mon, Apr 30, 2018 at 10:56:10AM -0400, Daniel Walsh wrote: > > Perhaps it is time to update my blog on running systemd in a unprivileged > container. Let's get the base images fixed so that at least that ENV container ... is there by default, to minimize the number of steps that are needed. -- Jan Pazdziora | adelton at #aos*, #brno Sr. Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On Fri, Apr 27, 2018 at 05:27:19PM +0200, Pavel Raiskup wrote: > Hi all, > > just wanted to let you know about trivial experiment [1] with systemd in > container. Non-privileged systemd can now pretty fine run in docker > container (tested on Fedora 27 box). > > Could we support this under fedora-kickstarts, or as a layered image? > > [1] https://github.com/praiskup/systemd-container The pull request https://github.com/fedora-cloud/docker-brew-fedora/pull/45 to add the container environment variable to Fedora based images was merged many month ago but it does not seem to have affected the images that get built. Does anyone have any idea what is the based container image build process these days and in which repository we need to do the same change to have the environment variable set by default? -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On 2018-04-30 09:01, mcatanz...@gnome.org wrote: > On Mon, Apr 30, 2018 at 7:52 AM, Florian Weimer wrote: >> Such we change the guidelines to always run autoreconf? This would >> also help with new architecture bringup because those often need >> autotools fixes, but it will choke on really old or manually patched >> upstream configure scripts. > > Some packages will not build when autoreconf is called outside > autogen.sh, and these packages typically do not distribute autogen.sh. > E.g. gedit. gedit, like most GNOME components, uses gnome-autogen.sh; in this particular case, iirc ACLOCAL_PATH="libgd" also needs to be set. > Packagers would need to work around such issues. FWIW, running autoreconf in one form or another (either directly, or e.g. gnome-autogen.sh or mate-autogen) is standard procedure on Cygwin. While this doesn't work on certain packages, the vast majority can be autoreconf'd. -- Yaakov Selkowitz Software Engineer - Platform Enablement Group Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 30 April 2018 at 15:56, Daniel Walsh wrote:
> On 04/30/2018 10:42 AM, James Hogarth wrote:
>>
>> On 27 April 2018 at 17:47, Pavel Raiskup wrote:
>>>
>>> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) wrote:
> Hi all,
>
> just wanted to let you know about trivial experiment [1] with systemd
> in
> container. Non-privileged systemd can now pretty fine run in docker
> container (tested on Fedora 27 box).
Hmm, IIRC there were at least two isues still, did they get resolved?
Specifically:
1. docker fakes a /dev/console that doesn't behave like a console
usually works, i.e. if a hangup is seen on it then it will destroy
the pty behind it, instead of keeping it around...
>>>
>>> There't toy work-around to have at least something:
>>>
>>> https://github.com/praiskup/systemd-container/blob/master/fedora-rawhide-x86_64/systemd
>>>
>>> Pavel
>>>
2. docker sends SIGTERM to the container's PID 1 when it wants it to
go down even though SIGTERM to PID 1 on SysV systems generally
means "please reexecute", and not "please shut down".
What's the current state on that?
>> Did a bunch of related activities at my work recently ...
>>
>> If you are using Red Hat docker (eg from the RHEL/CentOS extras repo)
>> then this will get a systemd container running for you:
>>
>> Dockerfile:
>> FROM centos:7
>> ENV container docker
>> STOPSIGNAL SIGRTMIN+3
>> ENTRYPOINT ["/sbin/init"]
>> RUN yum -y update && yum clean all
>>
>> Run statement:
>> docker run -dt --name mycontainer mysystemdimage
>>
>> If you are using upstream docker then you need to do the following:
>> mkdir /etc/docker
>> echo '{"seccomp-profile": "/etc/docker/seccomp.json"}' >
>> /etc/docker/daemon.json
>> wget -O /etc/docker/seccomp.json
>> https://src.fedoraproject.org/rpms/docker/raw/master/f/seccomp.json
>>
>> Same dockerfile
>>
>> Run statement:
>> docker run -dt --tmpfs /tmp:exec --tmpfs /run -v
>> /sys/fs/cgroup:/sys/fs/cgroup:ro --name mycontainer mysystemdimage
>>
>> ___
>>
>> The real problem here is docker engines you don't control as the
>> seccomp filter is a potential blocker and potentially the run mount
>> options
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> Perhaps it is time to update my blog on running systemd in a unprivileged
> container.
>
Not a bad idea ...
Oh and for reference the above blurb was mostly based on work we did
in the atomic/cloud/something working group around a year ago
https://pagure.io/atomic-wg/issue/233
https://fedoraproject.org/wiki/Container:Guidelines#systemd_Containers
The exec was added to /tmp since (at least upstream) docker mounts
--tmpfs as noexec and that upsets some applications (especially some
java bits) and if it wasn't clear by "Red Hat docker" that includes
the docker engine shipped in Fedora, not just in EL7.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops
Hi, On 29-04-18 21:03, Alexander Ploumistos wrote: Hello Hans, I've just upgraded a G50-30 and like Christian, I can not reproduce the issue. I logged into MATE and GNOME, played with the brightness settings while plugged in and on battery, it did not hang. # cat /sys/class/scsi_host/host*/link_power_management_policy med_power_with_dipm med_power_with_dipm SMART data: Model Family: Seagate FireCuda 2.5 Device Model: ST1000LX015-1U7172 Serial Number: LU WWN Device Id: 5 000c50 0acde0e96 Firmware Version: SDM1 User Capacity:1,000,204,886,016 bytes [1.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate:5400 rpm Form Factor: 2.5 inches Device is:In smartctl database [for details use: -P show] ATA Version is: ACS-3 T13/2161-D revision 3b SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is:Sun Apr 29 20:48:35 2018 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled I hope that helps, It is good to hear that not everyone with a 50 series seems affected, note though that of the 3 reporters so far only one can reproduce with the brightness keys and the other 2 see a hard-freeze about once every 24 hours, so you might be affected but not know it yet. If you do experience unexplained freezes try disabling the LPM, see: https://fedoraproject.org/wiki/Common_F28_bugs#lpm-hang And then wait for a few days to confirm the freeze is really gone. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops
Hi, On 30-04-18 12:59, Kamil Paral wrote: On Sun, Apr 29, 2018 at 9:26 AM, Hans de Goede mailto:hdego...@redhat.com>> wrote: Hi All, I'm sending this to the fedora-kernel and -devel lists both to get the kernel team aware of this and because it is not entirely clear to me how to best deal with this. I guess we should get this added to the release-notes / common-bugs page for F28, but I'm not sure what the procedure is for that ? Hi Hans, I added it to the common bugs page: https://fedoraproject.org/wiki/Common_F28_bugs#lpm-hang Thank you. Feel free to edit it in any way. If you want to add a new entry in the future, just read the guidelines linked on that page, it's very simple. Thanks :) It looks good, currently we really need to understand the problem better so the generic wording you've chosen works well. Regards, Hans I've just become aware that at least for some users the use of SATA LPM in F28 causes the Lenovo 50 series laptops (confirmed X250, T450s G50-80) freeze/ hang hard under certain conditions when using SATA LPM, independent of the disk used (*). I have T450s and haven't seen any hang yet, but I've been using F28 on it just for 2 days now. I'll let you know if it happens. ___ 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: systemd in non-privileged container
On 04/30/2018 10:42 AM, James Hogarth wrote:
On 27 April 2018 at 17:47, Pavel Raiskup wrote:
On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) wrote:
Hi all,
just wanted to let you know about trivial experiment [1] with systemd in
container. Non-privileged systemd can now pretty fine run in docker
container (tested on Fedora 27 box).
Hmm, IIRC there were at least two isues still, did they get resolved?
Specifically:
1. docker fakes a /dev/console that doesn't behave like a console
usually works, i.e. if a hangup is seen on it then it will destroy
the pty behind it, instead of keeping it around...
There't toy work-around to have at least something:
https://github.com/praiskup/systemd-container/blob/master/fedora-rawhide-x86_64/systemd
Pavel
2. docker sends SIGTERM to the container's PID 1 when it wants it to
go down even though SIGTERM to PID 1 on SysV systems generally
means "please reexecute", and not "please shut down".
What's the current state on that?
Did a bunch of related activities at my work recently ...
If you are using Red Hat docker (eg from the RHEL/CentOS extras repo)
then this will get a systemd container running for you:
Dockerfile:
FROM centos:7
ENV container docker
STOPSIGNAL SIGRTMIN+3
ENTRYPOINT ["/sbin/init"]
RUN yum -y update && yum clean all
Run statement:
docker run -dt --name mycontainer mysystemdimage
If you are using upstream docker then you need to do the following:
mkdir /etc/docker
echo '{"seccomp-profile": "/etc/docker/seccomp.json"}' > /etc/docker/daemon.json
wget -O /etc/docker/seccomp.json
https://src.fedoraproject.org/rpms/docker/raw/master/f/seccomp.json
Same dockerfile
Run statement:
docker run -dt --tmpfs /tmp:exec --tmpfs /run -v
/sys/fs/cgroup:/sys/fs/cgroup:ro --name mycontainer mysystemdimage
___
The real problem here is docker engines you don't control as the
seccomp filter is a potential blocker and potentially the run mount
options
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Perhaps it is time to update my blog on running systemd in a
unprivileged container.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Non-responsive maintainer - Ivan Romanov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! According Non-responsive Maintainer Policy I'm asking the maintainer to respond 3rd time and resolve issues with packages. RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1564875 - -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEGFSlHDlYR1Xq8pxov5n8bdRauQoFAlrnLLIACgkQv5n8bdRa uQrH4A//ScT3Se/KyERafZsMw18KuEJ4EgBrnAkAWItOWNo9VppH12Zq+ZWwcUgo iadXBbj0vV7f+oerFsQIU6U/TdBSqBb74/QAPwB41kftwzke1PX7oMehOJ5xKx4i abbe715QTz+s8RZd2fWs6RoYiRehkA32Rj40N+r6ehAs5IgGGzRmpaz1BaninR2C AkPWqUW9KaN+Uz+6pROJZk1EpKN9uzZsj6iM4N1zRYtP7vvszg3QUtWVUTYdU1XC e0Q8yDPbw/wrwO356wgF77Zzviluj8QKacYwL6OVUeVClvWmbxqFvO0gcD9RL6+R Et5xo4ZGLEX4saQpsmdtwYZkl7sLcc+C2NI6fnL8W2awykZgxKirkuafcqcJn+Mz 3b/nVzEvogUB6mObhVWo/eAlFhpb8Y1Sht09mrnowLBbPpSy1L9bLAZrApZNypis 4VptOTP5rpHJrj/QPzWm218QuNO/ZMjcdJYKEQs1QJExdbQUP1erBZOjSdceymA4 b1mDqxC6EAzqtup0zy4zfdX9OEmVrHPDrNZHKV94VSQD+xVQTU/LOVKE3c/Xt3GG NRzpBA3CmqIdj+dyfR7RPjgzjVcNMkCb3HFPaDwWGvU2qGkLxtRFvGlUcHlGuILx CE01hTMWFhg1C1BVAIUsR8w6SDy0Y7Snv+IczVF0BwsekTjyOig= =fl7I -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd in non-privileged container
On 27 April 2018 at 17:47, Pavel Raiskup wrote:
> On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:
>> On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) wrote:
>>
>> > Hi all,
>> >
>> > just wanted to let you know about trivial experiment [1] with systemd in
>> > container. Non-privileged systemd can now pretty fine run in docker
>> > container (tested on Fedora 27 box).
>>
>> Hmm, IIRC there were at least two isues still, did they get resolved?
>> Specifically:
>>
>> 1. docker fakes a /dev/console that doesn't behave like a console
>>usually works, i.e. if a hangup is seen on it then it will destroy
>>the pty behind it, instead of keeping it around...
>
> There't toy work-around to have at least something:
> https://github.com/praiskup/systemd-container/blob/master/fedora-rawhide-x86_64/systemd
>
> Pavel
>
>> 2. docker sends SIGTERM to the container's PID 1 when it wants it to
>>go down even though SIGTERM to PID 1 on SysV systems generally
>>means "please reexecute", and not "please shut down".
>>
>> What's the current state on that?
>>
Did a bunch of related activities at my work recently ...
If you are using Red Hat docker (eg from the RHEL/CentOS extras repo)
then this will get a systemd container running for you:
Dockerfile:
FROM centos:7
ENV container docker
STOPSIGNAL SIGRTMIN+3
ENTRYPOINT ["/sbin/init"]
RUN yum -y update && yum clean all
Run statement:
docker run -dt --name mycontainer mysystemdimage
If you are using upstream docker then you need to do the following:
mkdir /etc/docker
echo '{"seccomp-profile": "/etc/docker/seccomp.json"}' > /etc/docker/daemon.json
wget -O /etc/docker/seccomp.json
https://src.fedoraproject.org/rpms/docker/raw/master/f/seccomp.json
Same dockerfile
Run statement:
docker run -dt --tmpfs /tmp:exec --tmpfs /run -v
/sys/fs/cgroup:/sys/fs/cgroup:ro --name mycontainer mysystemdimage
___
The real problem here is docker engines you don't control as the
seccomp filter is a potential blocker and potentially the run mount
options
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On Mon, 2018-04-30 at 09:01 -0500, mcatanz...@gnome.org wrote: > On Mon, Apr 30, 2018 at 7:52 AM, Florian Weimer > wrote: > > Such we change the guidelines to always run autoreconf? This > > would > > also help with new architecture bringup because those often need > > autotools fixes, but it will choke on really old or manually > > patched > > upstream configure scripts. > > Some packages will not build when autoreconf is called outside > autogen.sh, and these packages typically do not distribute > autogen.sh. > E.g. gedit. Packagers would need to work around such issues. Since this bug report [1] , It was recommended use autoreconf I try use autoreconf when it is possible . [1] https://bugzilla.redhat.com/show_bug.cgi?id=922257#c0 > Michael -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On 04/30/2018 04:01 PM, mcatanz...@gnome.org wrote: Some packages will not build when autoreconf is called outside autogen.sh, and these packages typically do not distribute autogen.sh. E.g. gedit. Packagers would need to work around such issues. Isn't that against the spirit of the GPLv2 and against the GPLv3 proper? Not distributing build scripts? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On Monday, April 30, 2018 2:52:54 PM CEST Florian Weimer wrote:
> On 04/09/2018 06:07 PM, Yaakov Selkowitz wrote:
> > On 2018-04-09 04:40, Florian Weimer wrote:
> >> On 04/09/2018 11:21 AM, Yaakov Selkowitz wrote:
> >>> On 2018-04-09 03:59, Florian Weimer wrote:
> Is there a recommend way to get libtool to pass through all flags
> specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
> driver sort out which flags to pass to the compiler/assembler/linker?
> >>>
> >>> $ libtool --mode=compile --help
> >>> [snip]
> >>> This mode accepts the following additional options:
> >>> [snip]
> >>> -Wc,FLAG pass FLAG directly to the compiler
> >>>
> >>> $ libtool --mode=link --help
> >>> [snip]
> >>> The following components of LINK-COMMAND are treated specially:
> >>> [snip]
> >>> -Wc,FLAG
> >>> -Xcompiler FLAG pass linker-specific FLAG directly to the compiler
> >>> -Wl,FLAG
> >>> -Xlinker FLAG pass linker-specific FLAG directly to the linker
> >>
> >> That doesn't solve the problem because there is a difference between
> >> passing a flag to the *linker* and passing it to the *compiler driver*
> >> while linking.
> >>
> >>> But, often when this happens, it is the fault of a poorly written
> >>> configure.ac or Makefile.am. Where exactly are you seeing an issue?
> >>
> >> Everywhere? libtool does not pass -specs= arguments in LDFLAGS to the
> >> linker invocation.
> >
> > Then patch libtool. I have in the past for similar issues, e.g.:
> >
> > https://github.com/cygwinports/libtool/blob/master/2.4.5-pass-ldflags.patch
> >
> > You will then have to assure that autoreconf is run within packages to
> > pick up the change.
>
> We also have this in the %configure macro:
>
>[ "%_configure_libtool_hardening_hack" = 1 ] && [ x !=
> "x%{_hardened_ldflags}" ] && \
>for i in $(find . -name ltmain.sh) ; do \
> %{__sed} -i.backup -e
> 's~compiler_flags=$~compiler_flags="%{_hardened_ldflags}"~' $i \
>done ; \
>
> So we rewrite ltmain.sh in the source tree, which is extremely hackish
> and contributes to the difficult-to-explain variance in build behavior.
Hack as hell, yes :-(. Do you have concrete issues with the
difficult-to-explain behavior? I could help maybe.
That hack is opt-in by %_hardened_build (defined by default though) and
opt-out by '%define _configure_libtool_hardening_hack 0' if that matters.
Same as %_configure_gnuconfig_hack (more than hardening that one is
related to new arches).
> Should we factor this out from %configure, so that it can be used for
> packages which do not use autoconf with libtool, only the latter?
Dunno, it depends how much troubles that hack brings probably.
My feeling is that this discussion is driven by the hardening initiative,
which is a very good reason on one hand, no doubts; but on the other hand
we can have very trivial post-build 'brp-*' whatever-script that will
protect us against accidental hardening mistakes.
> Such we change the guidelines to always run autoreconf? This would also
> help with new architecture bringup because those often need autotools
> fixes, but it will choke on really old or manually patched upstream
> configure scripts.
I'd vote against guidelines _forcing_ us to do autoreconf; that would
bring all sort of other issues:
- additional non-determinism
- additional BuildRequires, that means larger buildroots (and the set
of build-requires is sometimes unknown; there might be some 'make
dist' dependency which is hard to obtain, there's also gnulib, etc.)
- harder rebuildability; packages designed for fedora rawhide would be
harder to rebuild against epel-6 (because there are older autotools),
and vice versa -- tarballs released when RHEL5 was a thing would be
harder to rebuild on Rawhide
- upgrading of autotools themselves would be a bit harder because there
would be much larger amount of re-autotooled packages; so more FTBFS
bugs; this might sound lame but btw., even though maintainers wanted
it and IMO it would be probably very good thing -- we've never got acks
for rebasing autotools in RHEL, except for gettext AFAIR
I know Debian guys live somehow with that rule. Still I don't like it.
> In any case, I think we need to document the available options and
> upsides and downsides.
Alright, some guidelines saying why/when yes/no re-autotoolize would be
handy.
Pavel
>
> Thanks,
> Florian
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On Mon, Apr 30, 2018 at 7:52 AM, Florian Weimer wrote: Such we change the guidelines to always run autoreconf? This would also help with new architecture bringup because those often need autotools fixes, but it will choke on really old or manually patched upstream configure scripts. Some packages will not build when autoreconf is called outside autogen.sh, and these packages typically do not distribute autogen.sh. E.g. gedit. Packagers would need to work around such issues. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Recommended way to pass CFLAGS/LDFLAGS through libtool
On 04/09/2018 06:07 PM, Yaakov Selkowitz wrote:
On 2018-04-09 04:40, Florian Weimer wrote:
On 04/09/2018 11:21 AM, Yaakov Selkowitz wrote:
On 2018-04-09 03:59, Florian Weimer wrote:
Is there a recommend way to get libtool to pass through all flags
specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
driver sort out which flags to pass to the compiler/assembler/linker?
$ libtool --mode=compile --help
[snip]
This mode accepts the following additional options:
[snip]
-Wc,FLAG pass FLAG directly to the compiler
$ libtool --mode=link --help
[snip]
The following components of LINK-COMMAND are treated specially:
[snip]
-Wc,FLAG
-Xcompiler FLAG pass linker-specific FLAG directly to the compiler
-Wl,FLAG
-Xlinker FLAG pass linker-specific FLAG directly to the linker
That doesn't solve the problem because there is a difference between
passing a flag to the *linker* and passing it to the *compiler driver*
while linking.
But, often when this happens, it is the fault of a poorly written
configure.ac or Makefile.am. Where exactly are you seeing an issue?
Everywhere? libtool does not pass -specs= arguments in LDFLAGS to the
linker invocation.
Then patch libtool. I have in the past for similar issues, e.g.:
https://github.com/cygwinports/libtool/blob/master/2.4.5-pass-ldflags.patch
You will then have to assure that autoreconf is run within packages to
pick up the change.
We also have this in the %configure macro:
[ "%_configure_libtool_hardening_hack" = 1 ] && [ x !=
"x%{_hardened_ldflags}" ] && \
for i in $(find . -name ltmain.sh) ; do \
%{__sed} -i.backup -e
's~compiler_flags=$~compiler_flags="%{_hardened_ldflags}"~' $i \
done ; \
So we rewrite ltmain.sh in the source tree, which is extremely hackish
and contributes to the difficult-to-explain variance in build behavior.
Should we factor this out from %configure, so that it can be used for
packages which do not use autoconf with libtool, only the latter?
Such we change the guidelines to always run autoreconf? This would also
help with new architecture bringup because those often need autotools
fixes, but it will choke on really old or manually patched upstream
configure scripts.
In any case, I think we need to document the available options and
upsides and downsides.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops
On Sun, Apr 29, 2018 at 9:26 AM, Hans de Goede wrote: > Hi All, > > I'm sending this to the fedora-kernel and -devel lists > both to get the kernel team aware of this and because it > is not entirely clear to me how to best deal with this. > > I guess we should get this added to the release-notes / > common-bugs page for F28, but I'm not sure what the > procedure is for that ? > Hi Hans, I added it to the common bugs page: https://fedoraproject.org/wiki/Common_F28_bugs#lpm-hang Feel free to edit it in any way. If you want to add a new entry in the future, just read the guidelines linked on that page, it's very simple. Thanks :) > > I've just become aware that at least for some users > the use of SATA LPM in F28 causes the Lenovo 50 > series laptops (confirmed X250, T450s G50-80) freeze/ > hang hard under certain conditions when using SATA > LPM, independent of the disk used (*). > I have T450s and haven't seen any hang yet, but I've been using F28 on it just for 2 days now. I'll let you know if it happens. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan: rubygem-ronn, trac-code-comments-plugin
Dne 28.4.2018 v 05:34 Ricky Elrod napsal(a): > I am orphaning the packages: > - rubygem-ronn I'd like to take it ^^ over: https://pagure.io/releng/issue/7471 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
