[EPEL-devel] Adding EPEL7 branch
Hi - I'm obviously missing something from the docs here. I successfully added a el6 branch to the patchelf fedora package, but I can't add el7. Is this documented somewhere? $ fedpkg request-branch el7 Could not execute request_branch: el7 is a current release branch Thanks Jeremy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UJQJGC4PNBXRR37XXRWAMVJI4QHN4CM4/
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 18/02/18 18:09, Igor Gnatenko wrote: Some packages might be missed due to short koji outage, broken dependencies and so on, but majority of real failures is below. If you fixed package(s), found false positive, found missing packages in list or anything else -- please let me know. I fixed patchelf in patchelf-0.9-7.fc28. Thanks Jeremy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
Michael Cronenworth wrote: It would be nice to have a third option: -Change release names to release theme. We don't really need a name (IMO), but the theme adds a nice touch. A colour would be a nice clear release theme. You could even increment the first letter of the colour for each subsequent release. e.g. Amaranth - Blue - Celadon - ... See e.g http://en.wikipedia.org/wiki/List_of_colors There shouldn't be any major internationalisation issues, except for unlucky colours, which are plain superstition. It would be easy to make a theme which included that colour somewhere. Maybe someone else uses this scheme, however. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
Kévin Raymond wrote: Many Linux distributions are identified by a color. I would personally hate to have a purple, green or orange background… I wouldn't use the colour as the basis of the whole theme, but use it in a tasteful manner in highlights, etc. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: root device on iscsi
Bill Nottingham wrote: Jeremy Sanders (jer...@jeremysanders.net) said: Your patch does -bash-4.2# findmnt -m -n -o fstype,options / ext4 rw,relatime,user_xattr,acl,barrier=0,data=ordered Which doesn't show the _netdev option. If I change this to -bash-4.2# findmnt -s -n -o fstype,options / ext4 _netdev,barrier=0,relatime This works. I don't know whether you want to change -m to -s... Well, -s requires everything to be in fstab. -m would work for things mounted with plain mount -o _netdev, assuming /run/mount/utab is properly populated. I'm assuming on your system it's not? /run/mount/utab is empty. We're using tftpboot and dracut's network initrd support to mount the root, so perhaps that's not properly populating it. Perhaps this is a dracut bug too. Presumably I should file a bug for something so this can be worked on offline. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: root device on iscsi
Bill Nottingham wrote: It would be nice, yes. In the meantime, Jeremy, can you try the attached patch? Thanks very much - it doesn't seem to work in our setup. Dracut is mounting the root iscsi device using the dhcp root-dev option, but we have _netdev set in fstab. -bash-4.2# mount | grep on / /dev/sda on / type ext4 (rw,relatime,user_xattr,acl,barrier=0,data=ordered) -bash-4.2# grep _netdev /etc/fstab /dev/sda/ ext4 _netdev,barrier=0,relatime 1 1 -bash-4.2# mount | grep / /dev/sda on / type ext4 (rw,relatime,user_xattr,acl,barrier=0,data=ordered) Your patch does -bash-4.2# findmnt -m -n -o fstype,options / ext4 rw,relatime,user_xattr,acl,barrier=0,data=ordered Which doesn't show the _netdev option. If I change this to -bash-4.2# findmnt -s -n -o fstype,options / ext4 _netdev,barrier=0,relatime This works. I don't know whether you want to change -m to -s... Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: root device on iscsi
Jeremy Sanders wrote:
This works. I don't know whether you want to change -m to -s...
I tried changing -m to -s.
The network still tries to get shut down, despite the if statement being run
and the exit 1 command being run. This is because the exit command only
exits from the shell looping over the read, not the shell the script is
executing in (I hate shells!).
I had to modify the patch to exit after the loop if the loop had exited
internally.
This fixed version appears to work (attached).
Jeremy
--
http://jeremysanders.net/
--- network.orig 2011-10-25 20:23:32.0 +0100
+++ network 2011-11-30 14:26:20.823326251 +
@@ -174,11 +174,12 @@
[ $EUID != 0 ] exit 4
# Don't shut the network down if root is on NFS or a network
# block device.
-rootfs=$(awk '{ if ($1 !~ /^[ \t]*#/ $2 == / $3 != rootfs) { print $3; }}' /proc/mounts)
-rootopts=$(awk '{ if ($1 !~ /^[ \t]*#/ $2 == /) { print $4; }}' /etc/mtab)
-
- if [[ $rootfs == nfs* || $rootopts =~ _r?netdev ]] ; then
- exit 1
+ if ! findmnt -s -n -o fstype,options / | while read rootfs rootopts; do
+ if [[ $rootfs == nfs* || $rootopts =~ _r?netdev ]] ; then
+ exit 1
+ fi
+ done; then
+ exit 1
fi
# If this is a final shutdown/halt, check for network FS,
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: root device on iscsi
Bill Nottingham wrote: Jeremy Sanders (jer...@jeremysanders.net) said: Hi - is an iscsi root device a supported configuration setup with F16 and systemd? I asked on #systemd, and got pointed here. We're using dracut to boot diskless systems with root devices on iscsi. This works fine for booting using Fedora 16 and systemd. Unfortunately, on shutdown the system hangs. It stops the network interface before mounting the root device read-only or stopping the iscsi service (leaving the fedora iscsi target in a confused state too). On Fedora 14, this worked fine with the old fashioned init system. In the old init system you used to be able to put a _netdev flag in fstab, which would fix this problem. This doesn't seem to work now. What are you using for networking - the old network service or NetworkManager? The old network service. The root device is cloned from a non-iscsi installation, however, as kickstart didn't like to install onto a non- partitioned iscsi device: https://bugzilla.redhat.com/show_bug.cgi?id=757106 I thought that the _netdev option would be sufficient to get the ordering correct. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: root device on iscsi
Hi - is an iscsi root device a supported configuration setup with F16 and systemd? I asked on #systemd, and got pointed here. We're using dracut to boot diskless systems with root devices on iscsi. This works fine for booting using Fedora 16 and systemd. Unfortunately, on shutdown the system hangs. It stops the network interface before mounting the root device read-only or stopping the iscsi service (leaving the fedora iscsi target in a confused state too). On Fedora 14, this worked fine with the old fashioned init system. In the old init system you used to be able to put a _netdev flag in fstab, which would fix this problem. This doesn't seem to work now. Is this a simple bug or a bigger issue? I could imagine we could write some sort of evil systemd service which would run busybox (perhaps copied to tmpfs) to kill processes, remount root, kill off iscsi and run halt or reboot depending on the run level, before the network was stopped. That would be an awful hack (if it even worked). Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: Well spawing your logic further means we should avoid compiled programs at all, what if I want configure $app by editing its source code? Oh wait it is written in C ... If it goes down to want to edit scripts for configuration reasons (which isn't sane anyway) compared to a faster an cleaner boot process I'd opt for the later. Seriously source code is NOT and never was intended to be a configuration system period. It's a great advantage to have non-compiled programs on the system which can be edited: - Debugging packaged python programs - Customizing user interfaces - Understanding logic and parameters That's speaking as a developer and someone who does some sysadmin work. The overhead of a simple scripting language like Lua, awk, Python or Perl is minimal compared to the fork cost. You won't notice the difference between a Lua startup script and a C one. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Bill Nottingham wrote: Jeremy Sanders (jer...@jeremysanders.net) said: Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. If you're going to want them to be editable to pass the lowest-common-denominator test of whatever admins might be editing them, I think bash is probably the only reasonable choice. Perhaps, though C is completely non editable to many sysadmins and lacks easy to use builtin routines helpful in scripting (maps, lists, tuples, string manipulation). At least a simple Lua script should be comprehensible to the average sysadmin in case they need to debug or trace something, even if they never write anything. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. Again the sysadmin case just implies that something *else* is broken. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. What rubbish. For instance, we customised an early Fedora to work on a diskless NFS rooted system, mainly by mucking around with init scripts. Being able to easily edit these files made this project work and work quickly. Trying to get upstream to special case our particular setup wouldn't have happened. You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. There is a clear case for having an open and completely configurable system. It's not going to cost 1 sec of bootup either. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Seth Vidal wrote: +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. Absolutely. I have no idea why you shouldn't use a small and light interpreted language rather than C. You would have a standard library of useful init related functions, so you wouldn't have to fork awk, etc. The actual init scripts would be very small then. C is also missing useful datatypes such as maps, which would require libraries to load. Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
