Re: Maintainer input on release notes
On Mon, May 13, 2013 at 12:52 PM, John J. McDonough wb8...@arrl.net wrote: We had a short discussion of this at this morning's meeting but felt a broader discussion here was warranted. When preparing the Release Notes, we often ask the developers for wiki input, and generally come up dry. More recently, we look though the repos for changes, but the upstream release notes are often very poor or nonexistent. Every release includes literally thousands of changed packages, and while we strive to document significant changes, these poor upstream release notes leave us little clue as to what constitutes significant. Certainly the feature pages get us started, but they only capture a tiny fraction of what changes in a release. But if we think about the maintainers, chances are they begin working on the next thing just as soon as the compose closes for the previous release, if not sooner. Very likely they have an interest in the packages they are maintaining, and it would not be surprising if they viewed some features to be important. But by the time we ask for input, odds are they have moved on and most of the updated packages in the new release are ancient history. However, if we were to open the beats as soon as possible, certainly when the compose closes or even as soon as we have converted the beats to XML, then the developers could make a note in the wiki about what is significant, right at the time they are working on it and interested in it. Of course we would still need to remind the maintainers that we want their input, and especially that it doesn't need to be beautiful prose - all we really need is a clue as to what is important. But I think if we can capture the input early, we have better odds of getting more complete release notes. Is this something we should do? Is there something different we should be doing? --McD I think you should focus on Common Bugs and work with the IRC support SIG. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
On 15 May 2013 06:49, Dan Mashal dan.mas...@gmail.com wrote: On Tue, May 14, 2013 at 6:10 PM, Adam Williamson awill...@redhat.com wrote: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. Sanity: Switching to postfix? That's a matter of opinion and completely unhelpful to this discussion. Adam, like you I seem to remember a subtle difference between MTA and the others. I think its because some MTAs only do local delivery, some do remote and some can do both. Eg sendmail needs procmail to handle the local part from distant memory. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maintainer input on release notes
On Wed, May 15, 2013 at 12:04 AM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, May 13, 2013 at 12:52 PM, John J. McDonough wb8...@arrl.net wrote: We had a short discussion of this at this morning's meeting but felt a broader discussion here was warranted. When preparing the Release Notes, we often ask the developers for wiki input, and generally come up dry. More recently, we look though the repos for changes, but the upstream release notes are often very poor or nonexistent. Every release includes literally thousands of changed packages, and while we strive to document significant changes, these poor upstream release notes leave us little clue as to what constitutes significant. Certainly the feature pages get us started, but they only capture a tiny fraction of what changes in a release. But if we think about the maintainers, chances are they begin working on the next thing just as soon as the compose closes for the previous release, if not sooner. Very likely they have an interest in the packages they are maintaining, and it would not be surprising if they viewed some features to be important. But by the time we ask for input, odds are they have moved on and most of the updated packages in the new release are ancient history. However, if we were to open the beats as soon as possible, certainly when the compose closes or even as soon as we have converted the beats to XML, then the developers could make a note in the wiki about what is significant, right at the time they are working on it and interested in it. Of course we would still need to remind the maintainers that we want their input, and especially that it doesn't need to be beautiful prose - all we really need is a clue as to what is important. But I think if we can capture the input early, we have better odds of getting more complete release notes. Is this something we should do? Is there something different we should be doing? --McD I think you should focus on Common Bugs and work with the IRC support SIG. Dan -- I think the Common Bugs are well handled by the QA team and effectively feature-complete. The docs writers could probably benefit from a feedback loop with the IRC folks, I like that idea. It would help improve the guides - but not the Release Notes. The goal of John's idea is to track changes better by keeping up with the developers. The existing communication channel includes https://fedoraproject.org/wiki/Category:Documentation_beats?rd=Docs/Beats , which gets cleared around branch time and worked on until beta composes start. Opening the release note beats earler is an effort to change the docs process to better align with the packagers' workflow. Here's the question: If we clear this wiki space *now*, at this point in the release cycle, would you use it? If the wiki isn't an effective way to point us at the changes you're currently working on for F20 and beyond, is there something better? I'll cite an example that demonstrates the changelog problem John refers to, then share a little of our process, and the issue might make a little more sense: In writing the release notes, I noticed `pavucontrol` had been bumped to version 2.0. I'm not picking on it's maintainers - I *like* pavucontrol, and pulseaudio as a while - but I couldn't find out what had changed. /usr/share/doc/pavucontrol-*/ had no NEWS or CHANGELOG. The packaging changelog said ~Updating to v2.0. The upstream website had an equally release announcement, and their public git repo hadn't seen a commit since March 2011. Actually getting a diff of the source and sorting out the changes would take more time than a single package might merit. So, a package gets a major version bump and I'm silent about it. There might be some really interesting things in there, and I might be just as silent about well documented changes in other packages because I didn't know or think to look for them. What we do come up with gets piled into the release notes, which is used as a base for marketing materials like release announcements and talking points. These interesting changes might miss marketing attention and press interest they would otherwise have benefited from. The public at large reads the Release Notes (albeit often secondhand) and accepts them as the representation of the package maintainers' work. The docs writers can create a better product with developer help, and we're asking for input on how to make that process work. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
Le mercredi 15 mai 2013 à 07:45 +0100, Peter Robinson a écrit : Adam, like you I seem to remember a subtle difference between MTA and the others. I think its because some MTAs only do local delivery, some do remote and some can do both. Eg sendmail needs procmail to handle the local part from distant memory. The way I see the issue, a software would likely need a interface, ie something that provides /usr/bin/sendmail with this set of supported option. We cannot requires directly this file due to alternative ( I think ), so we may need a Requires/Provides for that. I do not see why a rpm would need to express I need to have something listening on port 25 or anything like that ( and so pull smtpd or anything like this ), from a network point of view ( since anything using the network could use a different host, so this mean a Requires is not the good way to express this dependency ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
2013/5/15 Chris Adams li...@cmadams.net: Once upon a time, Chris Murphy li...@colorremedies.com said: The only things related to networking I change is setting a hostname from localhost to f18s, f19s or f19q; and occasionally adding the b43 firmware if I decide to go wireless. Do you add the changed hostname to /etc/hosts? If not, sendmail (and some other things) will stop for some time trying to resolve the local hostname to an IP address. Why doesn't nss_myhostname resolve local hostname even if it is not in /etc/hosts? Alexey -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 12:56 AM, Jeffrey Bastian wrote: The slowest component on F19 is this new wait service: 10.102s NetworkManager-wait-online.service This service doesn't seem to do anything other than wait until the network is fully up. This really skews unfavorably the boot time reported by systemd-analyze. But if I mask that service and reboot, everthing still appears to work fine and systemd-analyze reports a boot time of only 6.2 seconds. A bit OT... This is not the first time in this thread that someone mentions masking a service. Do you guys have a reason why you mask the service instead of simply disabling it? Is there anything pulling the service into your boot even when it's disabled? Thanks, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Il 15/05/2013 05:43, Adam Williamson ha scritto: On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? FWIW, I found your results here interesting, so I did a little test of my own. I did default DVD installs of F17, F18 and F19 Beta TC4, ran through firstboot, rebooted, then rebooted again and ran systemd-analyze (to let prelink kick in). Results are that F18's slightly slower than F17 and F19 is somewhat slower again. My numbers are way way faster than your numbers overall, though; VMs do seem to perform very quickly on this box for whatever reason. Can you include here the QEMU command line or libvirt XML definition? Unless you have something like cache=none or cache='none' in it (respectively for QEMU and libvirt), chances are that you're using the host memory as a very fast and large disk cache for your VM. :) (VMs tend to be fast in the initramfs anyway, because they do not have much hardware to initialize, especially graphics cards). Paolo F17 --- Startup finished in 493ms (kernel) + 794ms (initramfs) + 2751ms (userspace) = 4039ms 446ms udev-settle.service 345ms NetworkManager.service 268ms systemd-logind.service 266ms ip6tables.service 262ms avahi-daemon.service 261ms iptables.service 173ms mcelog.service 170ms nfs-lock.service 145ms udev-trigger.service 136ms udev.service 135ms abrt-ccpp.service 122ms spice-vdagentd.service 117ms sendmail.service 114ms sm-client.service 110ms media.mount 106ms sys-kernel-debug.mount 105ms fedora-loadmodules.service 105ms dev-hugepages.mount 103ms dev-mqueue.mount 100ms sys-kernel-security.mount 98ms rsyslog.service 91ms remount-rootfs.service 90ms dbus.service 86ms sys-kernel-config.mount 84ms systemd-vconsole-setup.service 84ms acpid.service 77ms boot.mount 62ms systemd-tmpfiles-setup.service 56ms abrt-vmcore.service 53ms fedora-storage-init.service 53ms systemd-user-sessions.service 49ms sshd.service 47ms auditd.service 44ms systemd-remount-api-vfs.service 41ms colord.service 41ms systemd-sysctl.service 38ms bluetooth.service 32ms fedora-storage-init-late.service 28ms fedora-readonly.service 28ms lvm2-monitor.service 27ms systemd-readahead-collect.service 25ms colord-sane.service 18ms udisks2.service 18ms mdmonitor-takeover.service 13ms upower.service 13ms accounts-daemon.service 11ms rtkit-daemon.service 10ms rpcbind.service 9ms fedora-wait-storage.service F18 --- Startup finished in 521ms (kernel) + 616ms (initramfs) + 3348ms (userspace) = 4485ms 742ms iscsid.service 607ms firewalld.service 460ms systemd-udev-settle.service 372ms chronyd.service 369ms restorecond.service 321ms gdm.service 292ms abrt-ccpp.service 279ms ksmtuned.service 231ms accounts-daemon.service 208ms spice-vdagentd.service 208ms auditd.service 182ms systemd-logind.service 174ms avahi-daemon.service 167ms rtkit-daemon.service 163ms sm-client.service 116ms fedora-readonly.service 110ms fedora-loadmodules.service 109ms systemd-udev-trigger.service 104ms NetworkManager.service 101ms mcelog.service 95ms systemd-udevd.service 87ms sendmail.service 84ms sys-kernel-debug.mount 82ms dev-hugepages.mount 82ms dev-mqueue.mount 79ms iscsi.service 74ms systemd-remount-fs.service 64ms sys-kernel-config.mount 56ms systemd-vconsole-setup.service 52ms colord.service 42ms fedora-storage-init.service 41ms systemd-user-sessions.service 35ms udisks2.service 34ms ksm.service 34ms polkit.service 29ms systemd-tmpfiles-setup.service 28ms rpcbind.service 26ms bluetooth.service 24ms fedora-storage-init-late.service 23ms sshd.service 16ms abrt-vmcore.service 15ms upower.service 15ms lvm2-monitor.service 15ms systemd-sysctl.service 13ms systemd-modules-load.service 13ms mdmonitor-takeover.service 10ms boot.mount 4ms tmp.mount F19 --- Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace) = 5.861s 2.745s plymouth-quit-wait.service 2.389s NetworkManager-wait-online.service 1.078s accounts-daemon.service 1.026s firewalld.service 1.007s restorecond.service 987ms avahi-daemon.service 479ms iprupdate.service 385ms iprinit.service 356ms systemd-udev-settle.service
Re: when startup delays become bugs
On Tue, 14.05.13 17:58, Chris Murphy (li...@colorremedies.com) wrote: Static hostname: f19q.localdomain Takes 1.5 minutes before I can ssh into the VM, but the sendmail.service is now about 2 seconds instead of a minute. Is this a non-debug kernel? [root@f19q ~]# systemd-analyze blame 51.688s firewalld.service 50.696s restorecond.service 16.989s avahi-daemon.service 16.023s systemd-logind.service 11.908s NetworkManager-wait-online.service With the recommendations from https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 NM-w-o.s would become a service that is only pulled in when actually needed. It would be good to get this included in F19, as it is completely bogus to delay the boot for everybody just because a few people happen to have static NFS mounts listed in fstab. BTW, systemd-analyze critical-chain (possibly with --fuzz=500ms) is a new tool in F19, which allows a bit more Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 14.05.13 17:30, Dan Williams (d...@redhat.com) wrote: On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. Dan, could you please implement these recommendations for F19: https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 This really shouldn't be pulled in unconditionally... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 14.05.13 15:51, Chris Murphy (li...@colorremedies.com) wrote: 2.911s abrt-uefioops.service I don't understand really why abrt needs to run at all by default. It should be spawned automatically when an actualy crash happens, so that by default nobody has to have this serice running. Abrt guys, any chance you can make use of socket/bus/path activation so that abrt is auto-spawned when needed and not before? You don't even need to patch abrt itself for that (dropping in unit files is sufficient) if it needs only bus or path activation. Only socket activation needs patching. I filed this now, to keep track of this: https://bugzilla.redhat.com/show_bug.cgi?id=963184 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: Let me take the opportunity to dissect some of this: Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace) = 5.861s 2.745s plymouth-quit-wait.service This one is misleading, as this just makes sure the bootsplash is terminated when start-up is complete. 2.389s NetworkManager-wait-online.service https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 479ms iprupdate.service 385ms iprinit.service These appear to be untis that are only necessary for IBM RAID. It's hugely disappointing if this is pulled into all boots. I wonder if we can find a different logic for this, for example pulling it in from a udev rules or so. Or by changing anaconda to install this only onb IBM RAID systemd... Anyone knows what this is about? Also, I don't see either of these listed in the default preset file. This really shouldnt be started by default. 356ms systemd-udev-settle.service This is exlusively LVM's fault. There's really no need to ever have that in the boot unless you run LVM. On many machines LVM is the primary reason why things are slow. I can only recommend everybody to not install on LVM if you can. It's a real shame that LVM hasn't gotten their things together still, after all those years. A service that needs systemd-udev-settle is a broken service! LVM, you are broken! I am hoping for the day LVM gets kicked out of the default install. Oh btrfs, why are you still not around? 297ms ksmtuned.service I thought the kernel did this without user-interaction these days? 236ms spice-vdagentd.service I don't see why this is on by default. According to this bug report this should have been pulled in on-demand only: https://bugzilla.redhat.com/show_bug.cgi?id=876237 233ms abrt-ccpp.service https://bugzilla.redhat.com/show_bug.cgi?id=963184 160ms fedora-loadmodules.service Somebody should file bugs against all packages that still drop something into /etc/sysconfig/modules/. I see that kvm and bluez do this still. I filed these bugs now: https://bugzilla.redhat.com/show_bug.cgi?id=963193 https://bugzilla.redhat.com/show_bug.cgi?id=963198 138ms sm-client.service Oh my, sendmail. What an emabrassement that we still ship this enabled by default... If we could at least turn it into something that is activated on-demand. But I gues touching these sources to implement that would be too awful... 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. 97ms sshd.service Dito. THis is something to start by default only on hosts where a ton of people log in all the time. 80ms isdn.service In very new systemd 'isdn.service' is not enabled any more in the preset file, so this is already gone now. 79ms systemd-modules-load.service Ah, cute, on my machine the only reason this is pulled in is /etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old friend uinput (see above). https://bugzilla.redhat.com/show_bug.cgi?id=963201 78ms iprdump.service IBM RAID again? Jeez... 64ms sendmail.service Urks... 56ms systemd-localed.service Hmm, this one is weird... It should only be loaded when needed, so I am surprised tjat there's something that needs this during boot-up. 54ms ksm.service I thought the kernel would do this internally these days without userspace interaction. 54ms abrt-vmcore.service https://bugzilla.redhat.com/show_bug.cgi?id=963184 45ms rpcbind.service https://bugzilla.redhat.com/show_bug.cgi?id=963189 33ms dmraid-activation.service I wonder if we can change this to pull this in only if DMRAID is actually used... SOunds wrong to spawn this unconditionally... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 12:07, Alexey Torkhov (atork...@gmail.com) wrote: 2013/5/15 Chris Adams li...@cmadams.net: Once upon a time, Chris Murphy li...@colorremedies.com said: The only things related to networking I change is setting a hostname from localhost to f18s, f19s or f19q; and occasionally adding the b43 firmware if I decide to go wireless. Do you add the changed hostname to /etc/hosts? If not, sendmail (and some other things) will stop for some time trying to resolve the local hostname to an IP address. Why doesn't nss_myhostname resolve local hostname even if it is not in /etc/hosts? My suspicion is that sendmail uses res_query() and friends since it needs MX and stuff... THis means NSS is bypassed and hence nss_myhostname and /etc/hosts won't take effect anyway... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 01:36:57PM +0200, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: 356ms systemd-udev-settle.service This is exlusively LVM's fault. There's really no need to ever have that in the boot unless you run LVM. On many machines LVM is the primary reason why things are slow. I can only recommend everybody to not install on LVM if you can. It's a real shame that LVM hasn't gotten their things together still, after all those years. Is there a constructive summary anywhere of what LVM needs to do / change? This problem affects libguestfs too. I am hoping for the day LVM gets kicked out of the default install. Oh btrfs, why are you still not around? I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently -- it reliably fails in mkfs.btrfs :-( I stopped bothering filing bugs about this because they just get ignored because Rawhide isn't new enough (they want us to retest everything on some non-upstream btrfs-next kernel). My colleague ran btrfs on his laptop and had daily crashes. Last week he went back to ext4. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 2013-05-15 at 13:36 +0200, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: Let me take the opportunity to dissect some of this: Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace) = 5.861s 2.745s plymouth-quit-wait.service This one is misleading, as this just makes sure the bootsplash is terminated when start-up is complete. 2.389s NetworkManager-wait-online.service https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 479ms iprupdate.service 385ms iprinit.service These appear to be untis that are only necessary for IBM RAID. It's hugely disappointing if this is pulled into all boots. I wonder if we can find a different logic for this, for example pulling it in from a udev rules or so. Or by changing anaconda to install this only onb IBM RAID systemd... Anyone knows what this is about? Also, I don't see either of these listed in the default preset file. This really shouldnt be started by default. 356ms systemd-udev-settle.service This is exlusively LVM's fault. There's really no need to ever have that in the boot unless you run LVM. On many machines LVM is the primary reason why things are slow. I can only recommend everybody to not install on LVM if you can. It's a real shame that LVM hasn't gotten their things together still, after all those years. A service that needs systemd-udev-settle is a broken service! LVM, you are broken! I am hoping for the day LVM gets kicked out of the default install. Oh btrfs, why are you still not around? 297ms ksmtuned.service I thought the kernel did this without user-interaction these days? 236ms spice-vdagentd.service I don't see why this is on by default. According to this bug report this should have been pulled in on-demand only: https://bugzilla.redhat.com/show_bug.cgi?id=876237 233ms abrt-ccpp.service https://bugzilla.redhat.com/show_bug.cgi?id=963184 160ms fedora-loadmodules.service Somebody should file bugs against all packages that still drop something into /etc/sysconfig/modules/. I see that kvm and bluez do this still. I filed these bugs now: https://bugzilla.redhat.com/show_bug.cgi?id=963193 https://bugzilla.redhat.com/show_bug.cgi?id=963198 138ms sm-client.service Oh my, sendmail. What an emabrassement that we still ship this enabled by default... If we could at least turn it into something that is activated on-demand. But I gues touching these sources to implement that would be too awful... 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. 97ms sshd.service Dito. THis is something to start by default only on hosts where a ton of people log in all the time. 80ms isdn.service In very new systemd 'isdn.service' is not enabled any more in the preset file, so this is already gone now. 79ms systemd-modules-load.service Ah, cute, on my machine the only reason this is pulled in is /etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old friend uinput (see above). https://bugzilla.redhat.com/show_bug.cgi?id=963201 78ms iprdump.service IBM RAID again? Jeez... 64ms sendmail.service Urks... 56ms systemd-localed.service Hmm, this one is weird... It should only be loaded when needed, so I am surprised tjat there's something that needs this during boot-up. 54ms ksm.service I thought the kernel would do this internally these days without userspace interaction. 54ms abrt-vmcore.service https://bugzilla.redhat.com/show_bug.cgi?id=963184 45ms rpcbind.service https://bugzilla.redhat.com/show_bug.cgi?id=963189 33ms dmraid-activation.service I wonder if we can change this to pull this in only if DMRAID is actually used... SOunds wrong to spawn this unconditionally... Lennart -- Lennart Poettering - Red Hat, Inc. Lennart, good. I CC'ed for interested bugs. -- Best Regards, Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 01:36:57PM +0200, Lennart Poettering wrote: 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. There are few parts of iSCSI stack in Fedora. This iscsi.service brings up all targets previously configured. Nevertheless it should only be pulled in when there are actaully some targets discovered: https://bugzilla.redhat.com/show_bug.cgi?id=951951#c3 Other part of stack, iscsid.service, is already socket activable (at least upstream since Mike pulled my patches, in Fedora since 6.2.0.873-4). -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 13:36, Lennart Poettering (mzerq...@0pointer.de) wrote: I have now created a tracker bug WhyWeBotSoSlow to track all these little issues that cause things to be in our boot-up sequence that really shouldn't be there... https://bugzilla.redhat.com/show_bug.cgi?id=963210 Would be fantastic if we could find some volunteers to keep an eye on this and put some pressure behind this! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130515 changes
Compose started at Wed May 15 09:15:02 UTC 2013 Broken deps for x86_64 -- [byzanz] byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit) [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.x86_64 requires libvirt-qmf [freeipa] freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires pki-ca = 0:10.0.1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires krb5-server = 0:1.11.2-1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires 389-ds-base = 0:1.3.0.5 [glusterfs] glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-AppTools] python-AppTools-3.4.0-5.fc19.noarch requires python-TraitsGUI [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-2.fc19.noarch requires python-flask-mongonegine [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tntnet] tntnet-2.1-15.fc19.i686 requires libcxxtools.so.8 tntnet-2.1-15.fc19.x86_64 requires libcxxtools.so.8()(64bit) [xorg-x11-drivers] xorg-x11-drivers-7.7-4.fc19.x86_64 requires xorg-x11-drv-ast [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [byzanz] byzanz-0.3-0.5.fc17.i686 requires libpanel-applet-4.so.0 [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [fence-virt] fence-virtd-libvirt-qmf-0.3.0-11.fc19.i686 requires libvirt-qmf [freeipa] freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires pki-ca = 0:10.0.1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires krb5-server = 0:1.11.2-1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.i686 requires 389-ds-base = 0:1.3.0.5 [glusterfs] glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-kolab-0.4.1-3.fc19.i686 requires php(api) = 0:20100412-x86-32 [ooo2gd] ooo2gd-3.0.0-6.fc19.i686 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq)
Re: when startup delays become bugs
On Wed, 15.05.13 12:55, Richard W.M. Jones (rjo...@redhat.com) wrote: On Wed, May 15, 2013 at 01:36:57PM +0200, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: 356ms systemd-udev-settle.service This is exlusively LVM's fault. There's really no need to ever have that in the boot unless you run LVM. On many machines LVM is the primary reason why things are slow. I can only recommend everybody to not install on LVM if you can. It's a real shame that LVM hasn't gotten their things together still, after all those years. Is there a constructive summary anywhere of what LVM needs to do / change? This problem affects libguestfs too. It should subscribe to block devices coming and going and then assemble things as stuff appears. Right now it expects to be called at a point in time where everything that might show up has shown up. Of course, that's not how modern hardware works (everything is hotpluggable now, hw gives no guarantees when it shows up and we don't have any idea what might still come hence), and requires pulling in of udev-settle. It requires us to delay the boot, in order to keep the promise of everything has shown up now to LVM, which happens to be a promise that we cannot actually hold, since we don't know whether something is missing... LVM should subscribe to udev events like any other daemon, and as soon as all devices it needs have shown up immeidately assemble things. This would guarantee minimal boot times since we would have to wait exactly for the devices that are actually needed, and that's it. We wouldn't have to wait for devices we never know might appear and that nobody actually needs. If it wasn't for LVM we'd have removed the udev-settle functionality from udev already, since it's just broken, and slows down things too. LVM of course has been broken like this for 5 years, and they know that. And they did nothing about it. And that's so disappointing... (Of course, btrfs got assembly right from day 1: it will assemble disks exclusively via udev events and as soon as a device is complete it is made available to the OS. The btrfs folks understood how modern hardware and storage technology works, the LVM folks not so much I fear...) I am hoping for the day LVM gets kicked out of the default install. Oh btrfs, why are you still not around? I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently -- it reliably fails in mkfs.btrfs :-( I stopped bothering filing bugs about this because they just get ignored because Rawhide isn't new enough (they want us to retest everything on some non-upstream btrfs-next kernel). My colleague ran btrfs on his laptop and had daily crashes. Last week he went back to ext4. Well, it works fine for myself and for quite a few other folks I know. I am pretty sure it's time to grow some, make this the default in Fedora, and then fix everything popping up quickyl with the necessary pressure. As it appears not having any pressure to stabilize btrfs certainly doesn't work at all for the project... Lennart PS: I am very good at bitching about LVM. You can book me for your party at very low rates! -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:25 PM, Lennart Poettering wrote: On Wed, 15.05.13 12:55, Richard W.M. Jones (rjo...@redhat.com) wrote: Is there a constructive summary anywhere of what LVM needs to do / change? This problem affects libguestfs too. It should subscribe to block devices coming and going and then assemble things as stuff appears. They have added the lvmetad daemon which does this. And it seems to be used by default on my test F19 installation. I.e. I am not seeing udev-settle being pulled in anymore. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 2013-05-15 at 12:52 +0200, Lennart Poettering wrote: On Tue, 14.05.13 17:30, Dan Williams (d...@redhat.com) wrote: On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. Dan, could you please implement these recommendations for F19: https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 This really shouldn't be pulled in unconditionally... The changes you suggest there seem fine; one question about After=syslog.target being removed though: intentional? I pretty much just take your guidance on the .service files. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 07:45, Dan Williams (d...@redhat.com) wrote: Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. Dan, could you please implement these recommendations for F19: https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 This really shouldn't be pulled in unconditionally... The changes you suggest there seem fine; one question about After=syslog.target being removed though: intentional? I pretty much just take your guidance on the .service files. After=syslog.target is unnecessary these days and should be removed from all unit files, to keep things simple. We nowadays require syslog implementations to be socket activatable, and that socket is around before normal services start, and that's guaranteed, hence nobody has to depend on syslog explicitly anymore. All services will have logging available anyway, out-of-the-box, as default, with no manual configuration necessary, and without any referring to syslog.target. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:48 PM, Lennart Poettering wrote: On Wed, 15.05.13 07:45, Dan Williams (d...@redhat.com) wrote: Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. Dan, could you please implement these recommendations for F19: https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 This really shouldn't be pulled in unconditionally... The changes you suggest there seem fine; one question about After=syslog.target being removed though: intentional? I pretty much just take your guidance on the .service files. After=syslog.target is unnecessary these days and should be removed from all unit files, to keep things simple. We nowadays require syslog implementations to be socket activatable, and that socket is around before normal services start, and that's guaranteed, hence nobody has to depend on syslog explicitly anymore. All services will have logging available anyway, out-of-the-box, as default, with no manual configuration necessary, and without any referring to syslog.target. is it documented? in many of your mails in this thread you wrote nowadays, anymore, default, modern system, modern hardware, etc... does it documented anywhere? what are the assumptions and how nowadays fedora should have to work? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:58 PM, Farkas Levente wrote: On 05/15/2013 02:48 PM, Lennart Poettering wrote: We nowadays require syslog implementations to be socket activatable, and that socket is around before normal services start, and that's guaranteed, hence nobody has to depend on syslog explicitly anymore. All services will have logging available anyway, out-of-the-box, as default, with no manual configuration necessary, and without any referring to syslog.target. is it documented? in many of your mails in this thread you wrote nowadays, anymore, default, modern system, modern hardware, etc... does it documented anywhere? what are the assumptions and how nowadays fedora should have to work? The requirements on syslog implementations to be compatible with systemd are described in: http://www.freedesktop.org/wiki/Software/systemd/syslog Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2013-05-15)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2013-05-15 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1098 F19 Features - Progress on Features 100% Complete .fesco 1098 https://fedorahosted.org/fesco/ticket/1098 = New business = = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 01:01:18PM +0200, Lennart Poettering wrote: On Tue, 14.05.13 15:51, Chris Murphy (li...@colorremedies.com) wrote: 2.911s abrt-uefioops.service I don't understand really why abrt needs to run at all by default. It should be spawned automatically when an actualy crash happens, so that by default nobody has to have this serice running. This specific one is scraping previous kernel crash reports out of pstore, so it should really only be doing something if there's anything there. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Hi, On 05/15/2013 01:36 PM, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: Let me take the opportunity to dissect some of this: snip 236ms spice-vdagentd.service I don't see why this is on by default. According to this bug report this should have been pulled in on-demand only: Adam is running a spice enabled vm, so it is getting started because he has the required virtual hardware. https://bugzilla.redhat.com/show_bug.cgi?id=876237 233ms abrt-ccpp.service https://bugzilla.redhat.com/show_bug.cgi?id=963184 160ms fedora-loadmodules.service Somebody should file bugs against all packages that still drop something into /etc/sysconfig/modules/. I see that kvm and bluez do this still. I filed these bugs now: https://bugzilla.redhat.com/show_bug.cgi?id=963193 https://bugzilla.redhat.com/show_bug.cgi?id=963198 79ms systemd-modules-load.service Ah, cute, on my machine the only reason this is pulled in is /etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old friend uinput (see above). https://bugzilla.redhat.com/show_bug.cgi?id=963201 I'm fine with dropping the config file from spice-vdagent as long as something then creates the /dev/uinput device node, so that module auto-load will actually work, without the device-node pre-existing trying to use /dev/uinput will just cause a -ENOENT failure. snip 54ms ksm.service I thought the kernel would do this internally these days without userspace interaction. At a minimum we should consider not starting these *inside* vms Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. This is attaching to configured iSCSI devices (which at a minimum requires parsing configuration files to see if there are any devices configured), not running a listening daemon. 97ms sshd.service Dito. THis is something to start by default only on hosts where a ton of people log in all the time. SSH host key generation needs to be done in advance (don't want a connecting socket to wait for that). Maybe that could be done with a separate firstboot-like service that gets disabled once run? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 22:21 -0600, Chris Murphy wrote: I've tried both, but when I rename it I'm using 'hostnamectl set-hostname XXX' as I'm not seeing anything obvious in Gnome that does this. This is on the Details panel of System Settings. You're expected to type a pretty hostnames with spaces and caps. You'll end up with something like [michael@victory-road ~]$ hostnamectl Static hostname: victory-road Pretty hostname: Victory Road It doesn't magically become fully qualified. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default-installed MTA (was Re: MTA virtual provides craziness)
Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. Just to pick an example: mdadm (for Linux software RAID) has a monitor mode to notify somebody of disk failures. Failures would already go in the system log (from the kernel); running mdadm --monitor is for sending a more active notice. It is possible for mdadm to run an external alert program; on a desktop, that could use the system bus to notify the logged-in user. How do you handle a headless system, a desktop with nobody logged in, etc.? The only standard way to notifiy somebody off the box is SMTP (I suppose mdadm could use SNMP traps, but that's even more work to configure correctly). You could have mdadm implement a full SMTP client (and hope the network isn't down), but that's what /usr/sbin/sendmail is for. I'm not saying that these are insurmountable issues, just that that's where things stand today (to my knowledge). -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 08:53, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. This is attaching to configured iSCSI devices (which at a minimum requires parsing configuration files to see if there are any devices configured), not running a listening daemon. It should be possible to come up with some form of ConditionPathExists= or ConditionDirectoryNotEmpty= that causes this to be skipped if no targets are configured. https://bugzilla.redhat.com/show_bug.cgi?id=951951 97ms sshd.service Dito. THis is something to start by default only on hosts where a ton of people log in all the time. SSH host key generation needs to be done in advance (don't want a connecting socket to wait for that). Maybe that could be done with a separate firstboot-like service that gets disabled once run? We should really to be as stateless as possible here and not require write access to /etc, which a solution like this would require. Instead I'd propose to splitt the key generation into its own service but then pull this in by the first connection and conditionalize it also with ConditionPathExists= or so: ConditionPathExists=!/etc/ssh/ssh_host_rsa_key I filed this now: https://bugzilla.redhat.com/show_bug.cgi?id=963268 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, 15.05.13 09:08, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Dan Mashal dan.mas...@gmail.com said: Sanity: Switching to postfix? That's a long-time sore point, but the general idea is that sanity is not switching desktops/non-mail-servers from one full-featured MTA to another. The right move is to either remove a local MTA from the default install (which I think has been worked on), or switch to a light-weight daemon that is a local queue-and-forward mail handler. The downside of that would be that configuration of an upstream mail server (possibly requiring SSL and/or authentication) would be required for it to work, while sendmail/postfix/etc. can actually deliver messages (modulo other servers' spam filtering) in the default config. I am pretty sure that the big majority of mail servers on the internet still accept mails from servers in this default mode. An unconfigured mail server doesn't really do anything good. And stuff that needs configuration before being useful shouldn't be in the default install. The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. Just to pick an example: mdadm (for Linux software RAID) has a monitor mode to notify somebody of disk failures. Failures would already go in the system log (from the kernel); running mdadm --monitor is for sending a more active notice. It is possible for mdadm to run an external alert program; on a desktop, that could use the system bus to notify the logged-in user. How do you handle a headless system, a desktop with nobody logged in, etc.? The only standard way to notifiy somebody off the box is SMTP (I suppose mdadm could use SNMP traps, but that's even more work to configure correctly). I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. That would allow people who want everything via logs to get everything via logs. It would make our basic installed set smaller, and boot-up faster. And people who want a mail server can just install one and configure it and things will be magically hooked up with everything else. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 15:38, Hans de Goede (hdego...@redhat.com) wrote: Ah, cute, on my machine the only reason this is pulled in is /etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old friend uinput (see above). https://bugzilla.redhat.com/show_bug.cgi?id=963201 I'm fine with dropping the config file from spice-vdagent as long as something then creates the /dev/uinput device node, so that module auto-load will actually work, without the device-node pre-existing trying to use /dev/uinput will just cause a -ENOENT failure. Yeah, kmod/udev/systemd get this right these days: the kernel modules just export in modalias what node they want to have created, kmod then extracts that and udev/systemd create the device node for it. Then, when userspace opens the deivce the kernel will make sure the module is actually auto-loaded. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 2013-05-15 at 11:58 +0200, Paolo Bonzini wrote: Il 15/05/2013 05:43, Adam Williamson ha scritto: On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? FWIW, I found your results here interesting, so I did a little test of my own. I did default DVD installs of F17, F18 and F19 Beta TC4, ran through firstboot, rebooted, then rebooted again and ran systemd-analyze (to let prelink kick in). Results are that F18's slightly slower than F17 and F19 is somewhat slower again. My numbers are way way faster than your numbers overall, though; VMs do seem to perform very quickly on this box for whatever reason. Can you include here the QEMU command line or libvirt XML definition? Unless you have something like cache=none or cache='none' in it (respectively for QEMU and libvirt), chances are that you're using the host memory as a very fast and large disk cache for your VM. :) That's likely the case, yeah, I'm using a standard VM definition, no tweaks, and I have 16GB of RAM. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-POE] Don't require POE::Test::Loops on EPEL
commit 962c2b925a29a063ba9a7111b5da03f3a127ee9c
Author: Petr Šabata con...@redhat.com
Date: Wed May 15 16:50:15 2013 +0200
Don't require POE::Test::Loops on EPEL
perl-POE.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-POE.spec b/perl-POE.spec
index 9883ca0..87e6864 100644
--- a/perl-POE.spec
+++ b/perl-POE.spec
@@ -1,6 +1,6 @@
Name: perl-POE
Version: 1.354
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: POE - portable multitasking and networking framework for Perl
Group: Development/Libraries
@@ -28,7 +28,8 @@ BuildRequires: perl(HTTP::Request)
BuildRequires: perl(HTTP::Response)
BuildRequires: perl(HTTP::Status)
# POE::Test::Loops unsurprisingly requires POE
-%if 0%{!?perl_bootstrap:1}
+# ...and it's not in EPEL at the moment
+%if 0%{!?perl_bootstrap:1} ! ( 0%{?rhel} )
BuildRequires: perl(POE::Test::Loops) = 1.351
%endif
BuildRequires: perl(Socket) = 1.7
@@ -119,6 +120,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Wed May 15 2013 Petr Šabata con...@redhat.com - 1.354-6
+- Don't require POE::Test::Loops on EPEL
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.354-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: when startup delays become bugs
On Wed, 2013-05-15 at 13:36 +0200, Lennart Poettering wrote: 236ms spice-vdagentd.service I don't see why this is on by default. According to this bug report this should have been pulled in on-demand only: https://bugzilla.redhat.com/show_bug.cgi?id=876237 It probably was. I was testing in a SPICE/qxl KVM. Please don't anyone take it out; I really appreciate having it in all my test VMs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: lua 5.2
On 05/13/2013 03:01 PM, Tom Callaway wrote: On 05/10/2013 04:55 PM, Tom Callaway wrote: You may have noticed me poking random packages, I'm preparing rawhide (and only rawhide) for an update to lua 5.2. Please be patient. :) tolua++ does not have lua 5.2 support, and porting it is beyond my skillset (I can do the C++ bits, but the lua bits... nope. I'm not even entirely sure how to regenerate toluabind_default.c.) This means I'm going to keep liblua-5.1.so around, possibly indefinitely, in a compat-lua-libs subpackage. Additionally, I can't figure out the lua 5.2 equivalent of: lua_replace(L,LUA_GLOBALSINDEX); If anyone can determine that, it would help out a lot. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 04:30:35PM +0200, Lennart Poettering wrote: I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. I'm in support of this general idea, but I think it's a big enough change that we should probably do it as a feature -- mdadm is a key example but probably not the only thing. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 08:53:44AM -0500, Chris Adams wrote: SSH host key generation needs to be done in advance (don't want a connecting socket to wait for that). Maybe that could be done with a separate firstboot-like service that gets disabled once run? Bugzilla # ? :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 10:57:52AM -0400, Matthew Miller wrote: On Wed, May 15, 2013 at 08:53:44AM -0500, Chris Adams wrote: SSH host key generation needs to be done in advance (don't want a connecting socket to wait for that). Maybe that could be done with a separate firstboot-like service that gets disabled once run? Bugzilla # ? :) Oh -- Lennart is ahead of me. (mumbles about the good advice of reading all the messages before sending replies) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 04:21:20PM +0200, Lennart Poettering wrote: https://bugzilla.redhat.com/show_bug.cgi?id=963268 In that bug you suggest that administrators could change back to standalone mode. Given that what you say about frequency of access is true (even on systems where ssh login is a primary activity, time between accesess is generally on a human scale rather hundreds per second), is there a disadvantage to socket activation beyond a very slight delay in the first access? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Once upon a time, Matthew Miller mat...@fedoraproject.org said: In that bug you suggest that administrators could change back to standalone mode. Given that what you say about frequency of access is true (even on systems where ssh login is a primary activity, time between accesess is generally on a human scale rather hundreds per second), is there a disadvantage to socket activation beyond a very slight delay in the first access? Well, SSH connection rate is on human scale until your system is the target of a scan, which can result in at least dozens per second. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap with 3 packages
Hi, I have 3 packages: cego: A relational and transactional database https://bugzilla.redhat.com/show_bug.cgi?id=962189 liblfc: Lemke Foundation Classes https://bugzilla.redhat.com/show_bug.cgi?id=959974 liblfc-xml: Lemke Foundation Classes XML extension https://bugzilla.redhat.com/show_bug.cgi?id=960041 These 3 packages are the core of cego database. Two libs are the BR of cego. Please help review these 3 packages. Thanks. *Yours sincerely,* *Christopher Meng* Always playing in Fedora Project http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, 15 May 2013 10:56:39 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, May 15, 2013 at 04:30:35PM +0200, Lennart Poettering wrote: I'd suggest that mdadm should do what cronie already does these days: try to use sendmail if it's there and only then, and unconditionally log things to syslog. This would the allow us to remove an SMTP server from the default install, and everything would appear in the logs just fine. And as soon as the admin decides to install a mail server and configure it then he will get mails too. I'm in support of this general idea, but I think it's a big enough change that we should probably do it as a feature -- mdadm is a key example but probably not the only thing. Perhaps interested parties could get behind/revive: https://fedoraproject.org/wiki/Features/NoMTA and finish it out for f20? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Glitch in Upgrading from EOL Fedora using yum
but *it is not the same filesystem* if you stay on topic and /var is a own partition Am 14.05.2013 18:41, schrieb Philip Prindeville: I get that part… but that shouldn't stop the directory from being renamed if it's staying on the same filesystem. -Philip On May 14, 2013, at 6:08 AM, Björn Esser bjoern.es...@gmail.com wrote: All those have their corresponding .pid-files inside /var/run. So I guess some of them are keeping an open handle on it. Am Montag, den 13.05.2013, 22:45 -0600 schrieb Philip A. Prindeville: And I had it showed systemd, dbus-daemon, atd, crond, cupsd, avahi-daemon, rpcbind, and all sorts of other things having open files in /var/run. Nothing was using it as a cwd. So I'm not sure why that would stop it from being renamed. On 05/13/2013 08:12 PM, Christopher Meng wrote: Maybe you can try lsof? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
Am 15.05.2013 16:08, schrieb Chris Adams: The core problem is that there's a general long-time Unix assumption that piping something to /usr/sbin/sendmail and/or connecting a TCP socket to localhost:smtp can send email, and so many things don't explicitly specify that need. The idea is that /usr/sbin/sendmail handles connecting to the right host, aliasing, etc. and the assumption is fine as it comnes to more than a desktop hence that is why you can simply write any script in any language run it as cronjob and if it spits out anything you get a mail notify cronjobs like rkhunter use this assumption this behavior is *perfect* a sane script in this context is silent until errors warnings signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap with 3 packages
Hi, On 15/05/13 17:08, Christopher Meng wrote: Hi, I have 3 packages: cego: A relational and transactional database https://bugzilla.redhat.com/show_bug.cgi?id=962189 liblfc: Lemke Foundation Classes https://bugzilla.redhat.com/show_bug.cgi?id=959974 Regarding this one, I foresee a problem: If I am not mistaken, this RPM will generate a liblfc.so, which is already provided by lfc-devel. # rpm -qf /usr/lib64/liblfc.so lfc-devel-1.8.7-1.el6.x86_64 Regards. liblfc-xml: Lemke Foundation Classes XML extension https://bugzilla.redhat.com/show_bug.cgi?id=960041 These 3 packages are the core of cego database. Two libs are the BR of cego. Please help review these 3 packages. Thanks. /Yours sincerely,/ /*Christopher Meng*/ Always playing in Fedora Project http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 10:05:40AM -0500, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: In that bug you suggest that administrators could change back to standalone mode. Given that what you say about frequency of access is true (even on systems where ssh login is a primary activity, time between accesess is generally on a human scale rather hundreds per second), is there a disadvantage to socket activation beyond a very slight delay in the first access? Well, SSH connection rate is on human scale until your system is the target of a scan, which can result in at least dozens per second. Oh, I see. I missed that the idea is to activate sshd each time rather than as a singleton service. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default-installed MTA (was Re: MTA virtual provides craziness)
On Wed, May 15, 2013 at 09:11:32AM -0600, Kevin Fenzi wrote: Perhaps interested parties could get behind/revive: https://fedoraproject.org/wiki/Features/NoMTA and finish it out for f20? *nod* Hmmm -- Percentage of completion: 98% seems optimistic. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap with 3 packages
I've noticed it How to solve it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:21 PM, Lennart Poettering wrote: On Wed, 15.05.13 08:53, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: 112ms iscsi.service This really sounds like something that should be socket actviated on demand rather than run by default. This is attaching to configured iSCSI devices (which at a minimum requires parsing configuration files to see if there are any devices configured), not running a listening daemon. It should be possible to come up with some form of ConditionPathExists= or ConditionDirectoryNotEmpty= that causes this to be skipped if no targets are configured. https://bugzilla.redhat.com/show_bug.cgi?id=951951 97ms sshd.service Dito. THis is something to start by default only on hosts where a ton of people log in all the time. SSH host key generation needs to be done in advance (don't want a connecting socket to wait for that). Maybe that could be done with a separate firstboot-like service that gets disabled once run? We should really to be as stateless as possible here and not require write access to /etc, which a solution like this would require. Instead I'd propose to splitt the key generation into its own service but then pull this in by the first connection and conditionalize it also with ConditionPathExists= or so: ConditionPathExists=!/etc/ssh/ssh_host_rsa_key I filed this now: https://bugzilla.redhat.com/show_bug.cgi?id=963268 I created such service ( ssh-keygen.service ) when I migrated the ssh to unit files. For some reason the maintainers in the distribution chose not to include it.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Swap with 3 packages
On 15.05.2013 17:24, Christopher Meng wrote: I've noticed it How to solve it? See https://fedoraproject.org/wiki/Packaging:Conflicts#Library_Name_Conflicts -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam: 1/2] fixed bugs #657357 and #954345
commit b6f84d3fed56ce66a500e87149f37728aea5559e
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed May 15 09:35:36 2013 -0600
fixed bugs #657357 and #954345
dspam-cron |2 +-
dspam.spec |8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/dspam-cron b/dspam-cron
index a513b26..ad92777 100644
--- a/dspam-cron
+++ b/dspam-cron
@@ -239,7 +239,7 @@ clean_pgsql_drv() {
[ -n ${PgSQLServer} -a -n ${PgSQLUser} -a -n ${PgSQLDb} ]
then
DSPAM_PgSQL_PURGE_SQL=
- DSPAM_PgSQL_PURGE_SQL_FILES=pgsql/pe-purge pgsql/purge
+ DSPAM_PgSQL_PURGE_SQL_FILES=pgsql/purge-pe pgsql/purge
#
# We first search for the purge scripts in the directory the
user has
diff --git a/dspam.spec b/dspam.spec
index 1df1324..09262f2 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -7,11 +7,12 @@
%global dspam_mode 2511
%global dspam_web_docroot %{_localstatedir}/www/dspam
%global __perl_requires %{SOURCE99}
+%global _hardened_build 1
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:6%{?dist}
+Release:7%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -367,6 +368,11 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-7
+- set hardened build to add PIE option since dspam can be long running
+- bug #954345
+- properly fixes #657357 - PostgreSQL purge script works
+
* Thu Jan 17 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-6
- Attempting to fix purge bug #657357
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[dspam: 2/2] merged rebuild
commit e4d8635e2d4b14cae68cd14624dde0a3c7c826de
Merge: b6f84d3 5628b9b
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed May 15 09:36:43 2013 -0600
merged rebuild
dspam.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --cc dspam.spec
index 09262f2,a9c109c..1fe25c5
--- a/dspam.spec
+++ b/dspam.spec
@@@ -12,7 -11,7 +12,7 @@@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
--Release:7%{?dist}
++Release:8%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@@ -368,11 -367,9 +368,14 @@@ exit
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
- * Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-7
++* Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-8
+- set hardened build to add PIE option since dspam can be long running
+- bug #954345
+- properly fixes #657357 - PostgreSQL purge script works
+
+ * Wed Feb 13 2013 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 3.10.2-7
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
* Thu Jan 17 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-6
- Attempting to fix purge bug #657357
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: MTA virtual provides craziness
Adam Williamson (awill...@redhat.com) said: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) smtpdaemon's the oldest one, dating back to at least 1997, so should be standard. smtpd and MTA came along in 2000 when postfix and exim were imported into powertools, so likely came from Simon Mudd (who did the original package before it was imported.) So... accident? server(smtp) was added in 2007 for https://bugzilla.redhat.com/show_bug.cgi?id=380621, as part of a Fedora proposed feature/packaging standard. I don't know that this standard was ever accepted - if it was, we should nuke the rest. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 20:56:59 -0500 Michael Catanzaro mike.catanz...@gmail.com wrote: Well I mean, someone actually has to press the OK button, or the change doesn't happen. Sometimes that can cause delays, at least for big undermanned projects (GNOME in openSUSE isn't too popular). But usually it works really well. Sure. I doubt that model would be accepted in Fedora, though. Different cultures. I'm not opposed to making things easier for patches or others to help, I'm just wanting to try and do it in a way that doesn't cause a pile of communications issues. ;) Yes, but I usually just want to submit the one fix and not co-maintain -- we all help out as we're able. :) Sure. Understood. Plus I mainly use GNOME programs, and GNOME maintainership in Fedora seems to be something of an exclusive cabel anyway (can't complain -- Fedora has the best GNOME, period). I don't really think this is the case... gnome folks in my experience seem happy to get help. ...snip... Yes, but that doesn't work well when the person assigned to your bug has 800 other bugs to deal with. I count four people with that many. Sure, but note that doesn't tell the whole story. I consider myself very responsive in bugzilla, and I have 312 open bugs. :) The vast majority of them are abrt bugs where I asked the submitter what they were doing and if they can duplicate it, and never got an answer. After that are a lot of bugs where the solution is not easy/clear or I am waiting on more info from reporters. Several things that can help filter this mass of stuff: 1. If your bug has a patch and is very easy/clear fix, mark it easyfix: http://fedoraproject.org/easyfix/ 2. Make it clear that there is a patch attached for the issue. Either add '[PATCH]' to the subject or something similar. And Red Hat Bugzilla is actually the *best* open source bugzilla I use, very clean and well-organized, and seems to work great when maintainers have few packages, but this is slightly broken. Well, it could be better for sure. :) I've seen this program is completely broken, here's an 8-line patch sit for two months; this program segfaults, here is an upstream patch sit about that long; this package is missing one essential Requires sit for three. The big name GNOME packagers are awesome, but not enough to deal with that many bugs, that many emails. But 20 pull requests where all that needs to be done is press OK... that's more manageable. Perhaps. If you get 20 pull requests you still need to examine them. You also might get pull requests that do things that are not what you want, especially if they are larger amounts of code. (That's not the only solution, of course; more Bugzilla-foo would work just as well. Emails to this list of unreviewed patches more than two weeks old, for example.) Yeah, there's things we could try and do for sure. Just dumping thoughts. Happy Tuesday! Thanks! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 15.05.13 10:05, Chris Adams (li...@cmadams.net) wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: In that bug you suggest that administrators could change back to standalone mode. Given that what you say about frequency of access is true (even on systems where ssh login is a primary activity, time between accesess is generally on a human scale rather hundreds per second), is there a disadvantage to socket activation beyond a very slight delay in the first access? Well, SSH connection rate is on human scale until your system is the target of a scan, which can result in at least dozens per second. Note that systemd puts a (configurable) limit on the number of concurrent connections, much like sshd does it, so there's very little difference... Also ssh forks of per-connection processes too, so the difference is probably even smaller... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Note that systemd puts a (configurable) limit on the number of concurrent connections, much like sshd does it, so there's very little difference... Also ssh forks of per-connection processes too, so the difference is probably even smaller... The difference is that when sshd is running as a traditional daemon, it can do all of its start-up processing once (parsing config files, loading host keys, etc.), instead of for each connection. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/f18] fixed bugs #657357 and #954345
commit 9b0286684f31ddcef056f61cac336155c62130e9
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed May 15 09:51:14 2013 -0600
fixed bugs #657357 and #954345
dspam-cron | 48 ++--
dspam.spec |7 ++-
2 files changed, 8 insertions(+), 47 deletions(-)
---
diff --git a/dspam-cron b/dspam-cron
index 26e0ae3..1f08bb3 100644
--- a/dspam-cron
+++ b/dspam-cron
@@ -239,7 +239,7 @@ clean_pgsql_drv() {
[ -n ${PgSQLServer} -a -n ${PgSQLUser} -a -n ${PgSQLDb} ]
then
DSPAM_PgSQL_PURGE_SQL=
- DSPAM_PgSQL_PURGE_SQL_FILES=pgsql_pe-purge
+DSPAM_PgSQL_PURGE_SQL_FILES=pgsql/purge-pe pgsql/purge
#
# We first search for the purge scripts in the directory the
user has
@@ -347,7 +347,7 @@ clean_sqlite3_drv() {
then
DSPAM_SQLite3_PURGE_SQL=
[ -f ${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql
- [ -f ${DSPAM_CONFIGDIR}/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite3_purge.sql
+[ -f ${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql
if [ -z ${DSPAM_SQLite3_PURGE_SQL} ]
then
@@ -377,47 +377,6 @@ clean_sqlite3_drv() {
#
-# Function to clean DSPAM SQLite 3.0 data
-#
-clean_sqlite_drv() {
- #
- # SQLite
- #
- [ ${VERBOSE} = true ] echo Running SQLite v2 storage driver
data cleanup
- if [ ${USE_SQL_PURGE} = true ]
- then
- DSPAM_SQLite_PURGE_SQL=
- [ -f ${DSPAM_CONFIGDIR}/config/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite_purge.sql
- [ -f ${DSPAM_CONFIGDIR}/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite_purge.sql
-
- if [ -z ${DSPAM_SQLite_PURGE_SQL} ]
- then
- echo Can not run SQLite purge script:
- echo No sqlite_purge SQL script found
- return 1
- fi
-
- if [ ! -e ${SQLITE_BIN_DIR}/sqlite ]
- then
- echo Can not run SQLite purge script:
- echo ${SQLITE_BIN_DIR}/sqlite does not exist
- return 1
- fi
-
- # Run the SQLite purge script and vacuum
- find ${DSPAM_HOMEDIR} -name *.sdb -print | while read name
- do
- ${SQLITE_BIN_DIR}/sqlite ${name}
${DSPAM_SQLite_PURGE_SQL} /dev/null
- # Enable the next line if you don't vacuum in the purge
script
- # echo vacuum; | ${SQLITE_BIN_DIR}/sqlite ${name}
/dev/null
- done 1/dev/null 21
- return 0
- fi
-
-}
-
-
-#
# Use a lock file to prevent multiple runs at the same time
#
DSPAM_CRON_LOCKFILE=/var/run/$(basename $0 .sh).pid
@@ -737,9 +696,6 @@ if ( set -o noclobber; echo $$
${DSPAM_CRON_LOCKFILE}) 2 /dev/null; then
sqlite3_drv)
clean_sqlite3_drv
;;
- sqlite_drv)
- clean_sqlite_drv
- ;;
*)
RUN_FULL_DSPAM_CLEAN=YES
echo Unknown storage ${foo} driver
diff --git a/dspam.spec b/dspam.spec
index 25754e1..d0e2804 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -7,11 +7,12 @@
%global dspam_mode 2511
%global dspam_web_docroot %{_localstatedir}/www/dspam
%global __perl_requires %{SOURCE99}
+%global _hardened_build 1
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:5%{?dist}
+Release:6%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -367,6 +368,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-6
+- set hardened build to add PIE option since dspam can be long running bug
#954345
+- properly fixes #657357 - PostgreSQL purge script works
+
* Thu Nov 29 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-5
- Fix dspam-web.conf file to work with httpd 2.4 and 2.2 bug#871396
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: when startup delays become bugs
On Tue, May 14, 2013 at 05:58:42PM -0600, Chris Murphy wrote:
And avahi doesn't play nice with the localdomain extension anyway.
Without the extension I ssh into boxes just like I do from Windows or
OS X:
ssh chris@f19q.local
Whereas if I change the hostname to f19q.localdomain, to ssh into the
system now I have to use a non-obvious, nonstandard:
ssh chris@f19q.localdomain
Hmm, that doesn't seem right. I have a .localdomain on all my hostnames
and Avahi and mDNS work just fine with the special .local domain.
[jbastian@tarantula ~]$ hostname
tarantula.localdomain
[jbastian@tarantula ~]$ ip addr show em1 | grep inet | awk '{print $2}'
192.168.1.75/24
fe80::f2de:f1ff:fe15:6496/64
From another system:
[jbastian@gecko ~]$ avahi-resolve-host-name tarantula.local
tarantula.local fe80::f2de:f1ff:fe15:6496
[jbastian@gecko ~]$ ping -n tarantula.local
PING tarantula.local (192.168.1.75) 56(84) bytes of data.
64 bytes from 192.168.1.75: icmp_seq=1 ttl=64 time=0.281 ms
...
Maybe you have iptables blocking mDNS traffic (tcp port 5353)?
Jeff
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 10:53 AM, Jeffrey Bastian wrote: Maybe you have iptables blocking mDNS traffic (tcp port 5353)? UDP -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/el6] fixed bugs #657357 and #954345
commit 47df07f460e42b98bfe35cd5757902f9d709ec96
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed May 15 10:12:27 2013 -0600
fixed bugs #657357 and #954345
dspam-cron | 48 ++--
dspam.spec |7 ++-
2 files changed, 8 insertions(+), 47 deletions(-)
---
diff --git a/dspam-cron b/dspam-cron
index 26e0ae3..4f3afc4 100644
--- a/dspam-cron
+++ b/dspam-cron
@@ -239,7 +239,7 @@ clean_pgsql_drv() {
[ -n ${PgSQLServer} -a -n ${PgSQLUser} -a -n ${PgSQLDb} ]
then
DSPAM_PgSQL_PURGE_SQL=
- DSPAM_PgSQL_PURGE_SQL_FILES=pgsql_pe-purge
+ DSPAM_PgSQL_PURGE_SQL_FILES=pgsql/purge-pe pgsql/purge
#
# We first search for the purge scripts in the directory the
user has
@@ -347,7 +347,7 @@ clean_sqlite3_drv() {
then
DSPAM_SQLite3_PURGE_SQL=
[ -f ${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql
- [ -f ${DSPAM_CONFIGDIR}/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite3_purge.sql
+[ -f ${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql
if [ -z ${DSPAM_SQLite3_PURGE_SQL} ]
then
@@ -377,47 +377,6 @@ clean_sqlite3_drv() {
#
-# Function to clean DSPAM SQLite 3.0 data
-#
-clean_sqlite_drv() {
- #
- # SQLite
- #
- [ ${VERBOSE} = true ] echo Running SQLite v2 storage driver
data cleanup
- if [ ${USE_SQL_PURGE} = true ]
- then
- DSPAM_SQLite_PURGE_SQL=
- [ -f ${DSPAM_CONFIGDIR}/config/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite_purge.sql
- [ -f ${DSPAM_CONFIGDIR}/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite_purge.sql
-
- if [ -z ${DSPAM_SQLite_PURGE_SQL} ]
- then
- echo Can not run SQLite purge script:
- echo No sqlite_purge SQL script found
- return 1
- fi
-
- if [ ! -e ${SQLITE_BIN_DIR}/sqlite ]
- then
- echo Can not run SQLite purge script:
- echo ${SQLITE_BIN_DIR}/sqlite does not exist
- return 1
- fi
-
- # Run the SQLite purge script and vacuum
- find ${DSPAM_HOMEDIR} -name *.sdb -print | while read name
- do
- ${SQLITE_BIN_DIR}/sqlite ${name}
${DSPAM_SQLite_PURGE_SQL} /dev/null
- # Enable the next line if you don't vacuum in the purge
script
- # echo vacuum; | ${SQLITE_BIN_DIR}/sqlite ${name}
/dev/null
- done 1/dev/null 21
- return 0
- fi
-
-}
-
-
-#
# Use a lock file to prevent multiple runs at the same time
#
DSPAM_CRON_LOCKFILE=/var/run/$(basename $0 .sh).pid
@@ -737,9 +696,6 @@ if ( set -o noclobber; echo $$
${DSPAM_CRON_LOCKFILE}) 2 /dev/null; then
sqlite3_drv)
clean_sqlite3_drv
;;
- sqlite_drv)
- clean_sqlite_drv
- ;;
*)
RUN_FULL_DSPAM_CLEAN=YES
echo Unknown storage ${foo} driver
diff --git a/dspam.spec b/dspam.spec
index db60f70..a4e2e23 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -7,11 +7,12 @@
%global dspam_mode 2511
%global dspam_web_docroot %{_localstatedir}/www/dspam
%global __perl_requires %{SOURCE99}
+%global _hardened_build 1
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:2%{?dist}
+Release:3%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -376,6 +377,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-3
+- set hardened build to add PIE option since dspam can be long running bug
#954345
+- properly fixes #657357 - PostgreSQL purge script works
+
* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
- require perl(Mail::MboxParser)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: when startup delays become bugs
Jeffrey Bastian (jbast...@redhat.com) said: On Tue, May 14, 2013 at 03:51:44PM -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. And it was even faster on F17. I had F17 cold booting to a usable Xfce desktop in 3.6 seconds by following Harald Hoyer's guide [1]: Startup finished in 1470ms (kernel) + 2130ms (userspace) = 3601ms But F18 and F19 now take 16 seconds on the same system: Startup finished in 1.061s (kernel) + 15.299s (userspace) = 16.361s The slowest component on F19 is this new wait service: 10.102s NetworkManager-wait-online.service This shouldn't be enabled by default, as Lennart has said - it should only be brought in unconditionally when there's a network filesystem to be mounted at boot; otherwise only on admin configuration. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Lennart Poettering (mzerq...@0pointer.de) said: LVM of course has been broken like this for 5 years, and they know that. And they did nothing about it. And that's so disappointing... lvmetad exists to do this now. All it requires is the patches to plumb it in everywhere. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/el5] fixed bugs #657357 and #954345
commit dfe0f5813431eac5a852603b3122024e8e46c3f9
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Wed May 15 10:17:24 2013 -0600
fixed bugs #657357 and #954345
dspam-cron | 48
dspam.spec |7 ++-
2 files changed, 10 insertions(+), 45 deletions(-)
---
diff --git a/dspam-cron b/dspam-cron
index 26e0ae3..ad92777 100644
--- a/dspam-cron
+++ b/dspam-cron
@@ -148,9 +148,9 @@ clean_mysql_drv() {
# For the 4.1-optimized version see:
# http://securitydot.net/txt/id/32/type/articles/
# Version = 3.9.0 of DSPAM do already include a better
purge script.
- DSPAM_MySQL_PURGE_SQL_FILES=mysql_purge-4.1-optimized
mysql_purge-4.1
+ DSPAM_MySQL_PURGE_SQL_FILES=mysql/purge-4.1-optimized
mysql/purge-4.1
else
- DSPAM_MySQL_PURGE_SQL_FILES=mysql_purge
+ DSPAM_MySQL_PURGE_SQL_FILES=mysql/purge
fi
@@ -239,7 +239,7 @@ clean_pgsql_drv() {
[ -n ${PgSQLServer} -a -n ${PgSQLUser} -a -n ${PgSQLDb} ]
then
DSPAM_PgSQL_PURGE_SQL=
- DSPAM_PgSQL_PURGE_SQL_FILES=pgsql_pe-purge
+ DSPAM_PgSQL_PURGE_SQL_FILES=pgsql/purge-pe pgsql/purge
#
# We first search for the purge scripts in the directory the
user has
@@ -348,6 +348,7 @@ clean_sqlite3_drv() {
DSPAM_SQLite3_PURGE_SQL=
[ -f ${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite3_purge.sql
[ -f ${DSPAM_CONFIGDIR}/sqlite3_purge.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite3_purge.sql
+ [ -f ${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql ]
DSPAM_SQLite3_PURGE_SQL=${DSPAM_PURGE_SCRIPT_DIR}/sqlite3/purge-3.sql
if [ -z ${DSPAM_SQLite3_PURGE_SQL} ]
then
@@ -377,47 +378,6 @@ clean_sqlite3_drv() {
#
-# Function to clean DSPAM SQLite 3.0 data
-#
-clean_sqlite_drv() {
- #
- # SQLite
- #
- [ ${VERBOSE} = true ] echo Running SQLite v2 storage driver
data cleanup
- if [ ${USE_SQL_PURGE} = true ]
- then
- DSPAM_SQLite_PURGE_SQL=
- [ -f ${DSPAM_CONFIGDIR}/config/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/config/sqlite_purge.sql
- [ -f ${DSPAM_CONFIGDIR}/sqlite_purge.sql ]
DSPAM_SQLite_PURGE_SQL=${DSPAM_CONFIGDIR}/sqlite_purge.sql
-
- if [ -z ${DSPAM_SQLite_PURGE_SQL} ]
- then
- echo Can not run SQLite purge script:
- echo No sqlite_purge SQL script found
- return 1
- fi
-
- if [ ! -e ${SQLITE_BIN_DIR}/sqlite ]
- then
- echo Can not run SQLite purge script:
- echo ${SQLITE_BIN_DIR}/sqlite does not exist
- return 1
- fi
-
- # Run the SQLite purge script and vacuum
- find ${DSPAM_HOMEDIR} -name *.sdb -print | while read name
- do
- ${SQLITE_BIN_DIR}/sqlite ${name}
${DSPAM_SQLite_PURGE_SQL} /dev/null
- # Enable the next line if you don't vacuum in the purge
script
- # echo vacuum; | ${SQLITE_BIN_DIR}/sqlite ${name}
/dev/null
- done 1/dev/null 21
- return 0
- fi
-
-}
-
-
-#
# Use a lock file to prevent multiple runs at the same time
#
DSPAM_CRON_LOCKFILE=/var/run/$(basename $0 .sh).pid
diff --git a/dspam.spec b/dspam.spec
index 428a5ed..37aeffb 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -7,11 +7,12 @@
%global dspam_mode 2511
%global dspam_web_docroot %{_localstatedir}/www/dspam
%global __perl_requires %{SOURCE99}
+%global _hardened_build 1
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:2%{?dist}
+Release:3%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -376,6 +377,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed May 15 2013 Nathanael Noblet nathan...@gnat.ca - 3.10.2-3
+- set hardened build to add PIE option since dspam can be long running bug
#954345
+- properly fixes #657357 - PostgreSQL purge script works
+
* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
- require perl(Mail::MboxParser)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
Daily package ownership changes?
Dear all, Ian Weller and Ralf Bean have pushed to producation datagrepper two days ago [1]. This is basically a public API to query messages that went on the fedmsg bus thus given a way to make some statistics and provide some information. I have been playing with it with the idea that not all packages that are orphaned are actually announced on this list. Using datagrepper we can easily retrieve this information. Would it be of interest to have a daily mail with the ownership changes that happened over the last 24h (or make it bi-daily and 48h or weekly...)? I put together something quickly [2] to give an idea of what it could be (see below). Let me know what you think, Pierre [1] http://threebean.org/blog/new-datagrepper-api/ [2] https://github.com/pypingou/fedora-owner-change Change in ownership over the last 48 hours == 6 packages were orphaned gnome-disk-utility [devel,f17,f18,f19] was changed to orphan by tbzatek Disk management application https://admin.fedoraproject.org/pkgdb/acls/name/gnome-disk-utility rsnapshot [EL-5,EL-6,devel,f17,f18,f19] was changed to orphan by xris Local and remote filesystem snapshot utility https://admin.fedoraproject.org/pkgdb/acls/name/rsnapshot yafc [EL-5,EL-6,devel,f17,f18,f19] was changed to orphan by xris Yet Another FTP/SFTP Client https://admin.fedoraproject.org/pkgdb/acls/name/yafc automake17 [devel] was changed to orphan by praiskup A GNU tool for automatically creating Makefiles https://admin.fedoraproject.org/pkgdb/acls/name/automake17 automake14 [devel] was changed to orphan by praiskup A GNU tool for automatically creating Makefiles https://admin.fedoraproject.org/pkgdb/acls/name/automake14 dar [EL-5,EL-6,devel,f17,f18,f19] was changed to orphan by xris Software for making/restoring incremental CD/DVD backups https://admin.fedoraproject.org/pkgdb/acls/name/dar 16 packages changed owner - python-django-piston [EL-6] was changed to mrunge by limb p11-kit [devel,f18,f19] was changed to stefw by stefw python-django-authority [EL-6] was changed to mrunge by ausil libjpeg-turbo [devel,f17,f18,f19] was changed to phracek by phracek python-AppTools [EL-6] was changed to orion by limb libtiff [devel,f17,f18,f19] was changed to phracek by phracek python-django-notification [EL-6] was changed to mrunge by ausil collectd [EL-5,EL-6] was changed to ruben by ruben libthai [devel,f17,f18,f19] was changed to ueno by petersen opencv [devel,f17,f18,f19,f19] was changed to kwizart by kwizart python-django-tagging [EL-6] was changed to mrunge by limb libpng [devel,f17,f18,f19] was changed to phracek by phracek pango [devel,f17,f18,f19] was changed to tagoh by petersen libpng12 [devel,f18,f19] was changed to phracek by phracek python-django-contact-form [EL-6] was changed to mrunge by ausil python-django-pagination [EL-6] was changed to mrunge by limb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM Weekly Status Meeting 2013-05-15
Good day all, Please join us today (Wednesday, May 15th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Kernel Status Update 3) Aarch64 Status Update 4) Fedora 19 for ARM - a) Skipping Alpha, releasing Beta with PA b) Graphics support c) Image format d) Scheduling a VFAD 5) Pidora Status Update 6) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On 05/15/2013 12:59 PM, Pierre-Yves Chibon wrote: Would it be of interest to have a daily mail with the ownership changes that happened over the last 24h (or make it bi-daily and 48h or weekly...)? I put together something quickly [2] to give an idea of what it could be (see below). This looks very useful. If this is done, please note the change in the wiki that currently require you to manually announce such changes here Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Wed, 2013-05-15 at 13:15 -0400, Rahul Sundaram wrote: On 05/15/2013 12:59 PM, Pierre-Yves Chibon wrote: Would it be of interest to have a daily mail with the ownership changes that happened over the last 24h (or make it bi-daily and 48h or weekly...)? I put together something quickly [2] to give an idea of what it could be (see below). This looks very useful. If this is done, please note the change in the wiki that currently require you to manually announce such changes here As you can see from the output at the end of my email, not everyone does it ;-) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: lua 5.2
Just forwarding this reply. I sent it to Alek directly but my CC to the list got bounced due to me not being subscribed. -- Forwarded message -- From: Craig Barnes craigbarne...@gmail.com Date: 13 May 2013 21:19 Subject: Re: lua 5.2 To: Alek Paunov a...@declera.com Cc: Richard W.M. Jones rjo...@redhat.com On 12 May 2013 01:27, Alek Paunov a...@declera.com wrote: Personally, I not have learned all of the guidelines yet and do not feel ready to make proper reviews of other packages ( besides my recent hard times with bunch of stalled tasks :-( ), but there are another unofficial spec [4] and if Craig is willing to become leading maintainer I will be happy to apply as co-maintainer (not because package requires additional care, but as help with the bugs processing duties, if any). @Craig what you think? [4] https://github.com/craigbarnes/packages/blob/master/luajit.spec I'm more than willing to maintain LuaJIT for Fedora but I haven't been sponsored as a packager yet. I submitted a package (discount) about 18 months ago, along with a sponsorship request but it's still awaiting formal review. So, may be Fedora transition to 5.2 is the right moment for LuaJIT to be finally included in the collection (with an additional role as lua51-compat package - alternative provider of lua(abi) = 5.1 on all architectures except s390 and ppc64). Some Lua C modules implement support for both ABIs by using compile-time macros and so won't be loadable by both at runtime. Quite a few Lua packages will probably need some attention/patching and all of them could probably use some testing after such a change. I'd like to help with that too, but without sponsorship or guidance I don't really know where to start or what the procedure is. Regards, Craig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On 05/15/2013 01:22 PM, Pierre-Yves Chibon wrote: As you can see from the output at the end of my email, not everyone does it ;-) Yeah. I am not surprised at all. Automating as much as possible is the only efficient way to handle it Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
Quoting Rahul Sundaram (2013-05-15 19:55:17) On 05/15/2013 01:22 PM, Pierre-Yves Chibon wrote: As you can see from the output at the end of my email, not everyone does it ;-) Yeah. I am not surprised at all. Automating as much as possible is the only efficient way to handle it To play the devil's advocate a bit, if we automate it without requiring announce we end up without any additional info about reasons why package was orphaned. So I'd say announce mail could probably go from MUST to Nice to have. I.e. please explain to prospective new maintainers what to be aware of. Anyway, I am a fan of automation so +1 to this whole thing at least as a test run. It's not visible from your example output, but if the owner just changed from person A to person B instead to orphan, it would be 1 change instead of A-orphan, orphan-B correct? I would probably say daily reports would be overkill. Weekly could be perhaps too long? If I think about it I'd probably invent some crazy complicated stuff so...just pick some schedule and be prepared to change if people complain :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
On Wed, 2013-05-15 at 20:12 +0200, Stanislav Ochotnicky wrote: Quoting Rahul Sundaram (2013-05-15 19:55:17) On 05/15/2013 01:22 PM, Pierre-Yves Chibon wrote: As you can see from the output at the end of my email, not everyone does it ;-) Yeah. I am not surprised at all. Automating as much as possible is the only efficient way to handle it To play the devil's advocate a bit, if we automate it without requiring announce we end up without any additional info about reasons why package was orphaned. So I'd say announce mail could probably go from MUST to Nice to have. I.e. please explain to prospective new maintainers what to be aware of. Anyway, I am a fan of automation so +1 to this whole thing at least as a test run. It's not visible from your example output, but if the owner just changed from person A to person B instead to orphan, it would be 1 change instead of A-orphan, orphan-B correct? If both happened in the period considered yes I would probably say daily reports would be overkill. Weekly could be perhaps too long? If I think about it I'd probably invent some crazy complicated stuff so...just pick some schedule and be prepared to change if people complain :-) That's easy enough to adjust but should also be easy enough to set a filter to ignore it :) Thanks for the feedback, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 20:03:41 -0500 Michael Catanzaro mike.catanz...@gmail.com wrote: Well the open model has already been tried and proven in openSUSE, and they're still using it because it actually works really well. There aren't usually any issues regarding overlap of work, though admittedly that community is a smaller than Fedora's. It's hard to get away with scp /home/*/.ssh/id_rsa evilhost because every change is always reviewed by a small group of maintainers responsible for a collection of packages. How do they deal with a conflict? Imagine someone there splitting texlive into 2500 subpackages and then 100 angry contributors reverting it. What are they going to do in their open model then? -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Wed, 2013-05-15 at 12:21 -0600, Pete Zaitcev wrote: On Tue, 14 May 2013 20:03:41 -0500 Michael Catanzaro mike.catanz...@gmail.com wrote: Well the open model has already been tried and proven in openSUSE, and they're still using it because it actually works really well. There aren't usually any issues regarding overlap of work, though admittedly that community is a smaller than Fedora's. It's hard to get away with scp /home/*/.ssh/id_rsa evilhost because every change is always reviewed by a small group of maintainers responsible for a collection of packages. How do they deal with a conflict? Imagine someone there splitting texlive into 2500 subpackages and then 100 angry contributors reverting it. What are they going to do in their open model then? FWIW, Mandriva used a similar open-commit model - compared to Fedora, basically all packagers were proven packagers and could commit to almost anything, a small range of packages were 'protected' as they are in Fedora - and I don't recall any significant issues like this actually popping up. In general, if you give F/OSS people a collaborative system, they will work collaboratively. It seems pessimistic to assume that people would get into edit wars just because they disagreed. It would be true to say that the Mandriva package corpus overall was on average of somewhat lower quality, in terms of conforming to the distro guidelines, than Fedora's is, but I don't think that can be attributed to the collaborative model so much as to a simple lack of sufficient personpower. If anything it would have been *worse* without motivated packagers being able to go through the whole package base and fix up problems. (Probably the extant Mandriva forks still use such a model, but I'm not really involved in any of them so I can't say for sure.) It is worth remembering that we do have provenpackagers in Fedora, quite a lot of them, and at least some of us with provenpackager status aren't shy about using it. It's not accurate to think about Fedora as being a *strictly* maintainer-only model. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Thursday's FPC Meeting (2013-05-16 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2013-05-16 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-05-16 09:00 Thu US/Pacific 2013-05-16 12:00 Thu US/Eastern 2013-05-16 16:00 Thu UTC - 2013-05-16 17:00 Thu Europe/London 2013-05-16 18:00 Thu Europe/Paris 2013-05-16 18:00 Thu Europe/Berlin 2013-05-16 21:30 Thu Asia/Calcutta --new day-- 2013-05-17 00:00 Fri Asia/Singapore 2013-05-17 00:00 Fri Asia/Hong_Kong 2013-05-17 01:00 Fri Asia/Tokyo 2013-05-17 02:00 Fri Australia/Brisbane Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = #topic #279 Bundling exception for agg in mapnik .fpc 279 https://fedorahosted.org/fpc/ticket/279 = New business = #topic #286 permission on files and directories .fpc 286 https://fedorahosted.org/fpc/ticket/286 #topic #287 Bundling exception request for sigrok-firmware-fx2lafw .fpc 287 https://fedorahosted.org/fpc/ticket/287 #topic #289 Request for permission for usage of autogenerated sources .fpc 289 https://fedorahosted.org/fpc/ticket/289 #topic #290 Octave provides filtering .fpc 290 https://fedorahosted.org/fpc/ticket/290 #topic #291 copylib: mt19937ar.c .fpc 291 https://fedorahosted.org/fpc/ticket/291 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote: I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently Well, it works fine for myself and for quite a few other folks I know. Cool story. I am pretty sure it's time to grow some, make this the default in Fedora, and then fix everything popping up quickyl with the necessary pressure. As it appears not having any pressure to stabilize btrfs certainly doesn't work at all for the project... Playing dangerous games with users data isn't how you effect change. All that switching default right now will achieve is a lot more pissed off users. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning link-grammar
Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 15, 2013, at 4:49 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 14.05.13 17:58, Chris Murphy (li...@colorremedies.com) wrote: Static hostname: f19q.localdomain Takes 1.5 minutes before I can ssh into the VM, but the sendmail.service is now about 2 seconds instead of a minute. Is this a non-debug kernel? Yes. All 3.9.x kernels in the F19 VM, and a 3.9.2 kernel on the F18 host. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning link-grammar
On Wed, May 15, 2013 at 1:45 PM, Johannes Lips johannes.l...@gmail.comwrote: Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I'll take it when you orphan it, unless someone else jumps it. -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provides: icon-theme for *-icon-theme packages
13.05.2013 19:30, Eugene Pivnev пишет: Subj. For packages that requies _any_ icon theme (something like oxygen provides system-kde-icon-theme). Prehistory: as we started RazorQt rpms - some people was crying I have no any icon in main menu!. So we deside to add _any_ icon theme to Razor's Requires. And now 10MB razorqt requies 30MB oxygen-icon-theme :-) Seems I have to make bugeports/featurerequest for _each_ *-icon-theme package :-( -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Wed, 2013-05-15 at 14:41 -0400, Dave Jones wrote: On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote: I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently Well, it works fine for myself and for quite a few other folks I know. Cool story. I am pretty sure it's time to grow some, make this the default in Fedora, and then fix everything popping up quickyl with the necessary pressure. As it appears not having any pressure to stabilize btrfs certainly doesn't work at all for the project... Playing dangerous games with users data isn't how you effect change. All that switching default right now will achieve is a lot more pissed off users. +1 million -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Koji doensn't resolve package dependency
Hallo, I have got an odd issue with koji on building gnustep-base-1.24.4-7.fc19. http://koji.fedoraproject.org/koji/buildinfo?buildID=419373 Koji told me, that the requirement gnustep-make = 2.6.4-13 could not been resolved. An research on bodhi told me, that gnustep-make-2.6.4-13.fc19 is tagged as stable. So it may be nice, if anyone can give me a hint to solve this issue. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning link-grammar
Jon Ciesla wrote: On Wed, May 15, 2013 at 1:45 PM, Johannes Lips johannes.l...@gmail.com mailto:johannes.l...@gmail.com wrote: Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.__org/mailman/listinfo/devel https://admin.fedoraproject.org/mailman/listinfo/devel I'll take it when you orphan it, unless someone else jumps it. I orphaned it, just now! Thanks a lot for taking over! Johannes -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning link-grammar
On Wed, May 15, 2013 at 2:22 PM, Johannes Lips johannes.l...@gmail.comwrote: Jon Ciesla wrote: On Wed, May 15, 2013 at 1:45 PM, Johannes Lips johannes.l...@gmail.com mailto:johannes.lips@gmail.**com johannes.l...@gmail.com wrote: Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.**fedoraproject.orgdevel@lists.fedoraproject.org https://admin.fedoraproject.__**org/mailman/listinfo/devel https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I'll take it when you orphan it, unless someone else jumps it. I orphaned it, just now! Got it. Thanks a lot for taking over! Anytime! -J Johannes -J -- http://cecinestpasunefromage.**wordpress.com/http://cecinestpasunefromage.wordpress.com/ --**-- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 15, 2013, at 9:53 AM, Jeffrey Bastian jbast...@redhat.com wrote: On Tue, May 14, 2013 at 05:58:42PM -0600, Chris Murphy wrote: And avahi doesn't play nice with the localdomain extension anyway. Without the extension I ssh into boxes just like I do from Windows or OS X: ssh chris@f19q.local Whereas if I change the hostname to f19q.localdomain, to ssh into the system now I have to use a non-obvious, nonstandard: ssh chris@f19q.localdomain Hmm, that doesn't seem right. I have a .localdomain on all my hostnames and Avahi and mDNS work just fine with the special .local domain. The mDNS issue likely needs a separate thread in any case, as something is definitely not right with a very basic 3-4 computer, tablet, phone and router with open source firmware. I consistently get the Macs to work with each other (bidirectional ssh and scp, using merely chris@ming). I can ssh into Fedora computers using chris@f19 or chris@f19.local. But I can't do this from Fedora computers with an installed system, it only works when booted from Live media. So upon installation, something isn't right. The .localdomain addon doesn't make sense to me, it's a convention not used on Windows or Macs. On OS X, I can't even add it as an extension. The period is removed and localdomain is just part of the static hostname, i.e. ming.localdomain becomes minglocaldomain.local. So this could be part of the problem, except that from F19 Live media I can ssh to chris@ming, but from an installed F19 system I can't; but the Mac can ssh chris@f19 even without an extension if that's what I've set as the static hostname. *shrug* So I don't know what's going on, I'll do more testing and start a separate thread if I get stuck. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning link-grammar
Johannes Lips wrote: Jon Ciesla wrote: On Wed, May 15, 2013 at 1:45 PM, Johannes Lips johannes.l...@gmail.com mailto:johannes.l...@gmail.com wrote: Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.__org/mailman/listinfo/devel https://admin.fedoraproject.org/mailman/listinfo/devel I'll take it when you orphan it, unless someone else jumps it. I orphaned it, just now! Sorry forgot all the other branches! Just orphaned it in them as well. Thanks a lot for taking over! Johannes -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2013-05-15)
=== #fedora-meeting: FESCO (2013-05-15) === Meeting started by notting at 18:00:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-05-15/fesco.2013-05-15-18.00.log.html . Meeting summary --- * init process (notting, 18:00:18) * #1098 F19 Features - Progress on Features 100% Complete (notting, 18:05:35) * AGREED: give dracut-hostonly and anaconda-newui-followup until next week to update status (+:7, -:0, 0:0) (notting, 18:35:29) * Next week's chair (notting, 18:36:04) * nirik to chair 2013-05-22 meeting (notting, 18:36:27) * Elections (notting, 18:36:45) * note that the FESCo nomination period is open through 2013-05-25 (notting, 18:37:16) * 5 seats open (notting, jwb, nirik, pjones, t8m) (notting, 18:38:03) * Open Floor (notting, 18:39:03) Meeting ended at 18:44:39 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * notting (39) * nirik (20) * jwb (18) * mitr (14) * jreznik_z10 (12) * abadger1999 (11) * t8m (9) * zodbot (7) * mmaslano (5) * pjones (4) * sgallagh (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 18:00:11 notting #startmeeting FESCO (2013-05-15) 18:00:11 zodbot Meeting started Wed May 15 18:00:11 2013 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:15 pjones greetings. 18:00:18 notting #meetingname fesco 18:00:18 zodbot The meeting name has been set to 'fesco' 18:00:18 notting #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:00:18 notting #topic init process 18:00:18 zodbot Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:00:20 nirik morning everyone. 18:01:12 mmaslano hi 18:01:19 abadger1999 greetings 18:02:51 mitr Hello 18:04:37 t8m hello 18:05:06 notting i believe sgallagh was out today. so might as well get started 18:05:35 notting #topic #1098 F19 Features - Progress on Features 100% Complete 18:05:35 notting .fesco 1098 18:05:36 zodbot notting: #1098 (F19 Features - Progress on Features 100% Complete) – FESCo - https://fedorahosted.org/fesco/ticket/1098 18:05:59 notting jreznik_z10? 18:06:20 * jreznik_z10 is on phone, typing slowly 18:06:30 nirik so, we have only 2 that aren't 100% right? 18:06:38 notting oh, *that* z10. 18:06:44 nirik anaconda followup and dracut hostonly. 18:06:45 jreznik_z10 It looks pretty good,take a look on ticket 18:07:09 jreznik_z10 I ping clumens but no reply yet 18:07:14 jreznik_z10 Pinged 18:07:27 jreznik_z10 Harald seems to be out 18:07:28 pjones I think he's pretty much given up talking to you. 18:07:47 nirik so, I would say we ask those two to rebase their pages based on whats landed/done now and move on. 18:08:05 jreznik_z10 Pones, it could be :-) 18:08:23 jreznik_z10 Nirik, yep 18:08:46 t8m nirik, +1 18:08:56 notting the dracut one doesn't list any items not done/fixed, so unsure why it's at 98% 18:09:11 notting the anaconda page hasn't been updated since march 18:09:25 jwb i suspect it won't be 18:09:55 notting jwb: ? 18:10:15 mmaslano why? they move track progress elsewhere? 18:11:10 jwb they've been pinged several times, right? it hasn't been updated since march, right? not sure why it would magically be updated now, or if it is why it wouldn't magically go to 100% 18:11:35 mmaslano that's an attitude 18:11:48 nirik well, ideally they could do one more update, set it to 100% and note the things that were landed. 18:11:55 nirik but I know, the world isn't ideal. 18:12:00 mitr ... if only for the release notes 18:12:06 t8m so the feature page should be dropped 18:12:14 jwb sure 18:12:34 mmaslano yes 18:12:41 jreznik_z10 We need it for release notes with correct content 18:13:13 t8m don't we have also separate process for release notes? or am I confused with the new change process 18:13:23 jwb i don't think that's true. you might need information, but you don't need a feature page 18:14:22 jreznik_z10 The page is now the only source of current status 18:15:09 nirik so, would it help if some of us went thru changelogs and proposed an update to the feature page? or otherwise tried to help gather the info? 18:15:27 jwb jreznik_z10, no it's the only place with a (stale) summarized status 18:15:30 t8m if they are so irritated that it is a Feature page, they can describe the current status of anaconda on a separate place and relnotes can be created from there 18:15:33 notting nirik: no, because that's stupid. 18:15:56 * nirik shrugs. It wouldn't be fun, but what else should we do? 18:16:05 jwb just drop it 18:16:25 nirik the feature? or asking for an update? 18:16:37 jwb the feature page 18:16:54 t8m but that still leaves the problem with release notes
Re: Orphaning link-grammar
On Wed, May 15, 2013 at 2:33 PM, Johannes Lips johannes.l...@gmail.comwrote: Johannes Lips wrote: Jon Ciesla wrote: On Wed, May 15, 2013 at 1:45 PM, Johannes Lips johannes.l...@gmail.com mailto:johannes.lips@gmail.**com johannes.l...@gmail.com wrote: Hi all, I am going to orphan link-grammar in a short while, because I actually have absolutely no use for it and I don't recall, why I picked it up in the first place. So please anyone interested in abiword might want to pick it up. Thanks a lot! Johannes -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.** fedoraproject.org devel@lists.fedoraproject.org https://admin.fedoraproject.__**org/mailman/listinfo/devel https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I'll take it when you orphan it, unless someone else jumps it. I orphaned it, just now! Sorry forgot all the other branches! Just orphaned it in them as well. No worries, I took them. -J Thanks a lot for taking over! Johannes -J -- http://cecinestpasunefromage.**wordpress.com/http://cecinestpasunefromage.wordpress.com/ --**-- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On 05/15/2013 01:56 AM, Michael Catanzaro wrote: I doubt that model would be accepted in Fedora, though. Different cultures. Which difference in culture do you see? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 388 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 283 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6608/Django-1.1.4-2.el5 89 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0366/openconnect-4.08-1.el5 22 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5517/git-1.8.2.1-1.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5711/openvpn-2.3.1-1.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5799/python-virtualenv-1.9.1-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing git-bugzilla-0-0.9.20091211git.el5 perl-Net-SSH-Expect-1.09-6.el5 Details about builds: git-bugzilla-0-0.9.20091211git.el5 (FEDORA-EPEL-2013-5813) Attach patches to a bugzilla bug Update Information: add Requires: perl(LWP::Protocol::https) (RHBZ# 960289) References: [ 1 ] Bug #960289 - Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) https://bugzilla.redhat.com/show_bug.cgi?id=960289 perl-Net-SSH-Expect-1.09-6.el5 (FEDORA-EPEL-2013-5824) Net-SSH-Expect - SSH wrapper to execute remote commands Update Information: Added directories to %files section of spec file ChangeLog: * Tue May 14 2013 Carl Thopmson fed...@red-dragon.com - 1.09-6 - added ownership to directories References: [ 1 ] Bug #894523 - /usr/share/perl5/vendor_perl/Net/SSH/ is unowned https://bugzilla.redhat.com/show_bug.cgi?id=894523 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing:
Age URL
576
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4701/supybot-gribble-0.83.4.1-10.el6
388
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
89
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0376/openconnect-4.08-1.el6
82
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0420/awstats-7.0-3.el6
46
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0823/openstack-keystone-2012.2.3-5.el6
12
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5649/mediawiki119-1.19.6-1.el6
12
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5643/php-sabredav-Sabre_DAV-1.6.5-5.el6
8
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5713/openvpn-2.3.1-1.el6
2
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5789/gallery3-3.0.7-1.el6
1
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5801/python-virtualenv-1.9.1-1.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
cloc-1.58-4.el6
fedmsg-0.6.8-4.el6
ga-5.1.1-2.el6
git-bugzilla-0-0.9.20091211git.el6
nut-2.6.5-2.el6
perl-Net-SSH-Expect-1.09-6.el6
perl-POE-1.354-1.el6
perl-Rose-DB-0.770-1.el6
python-AppTools-4.2.0-1.el6
python-datanommer-consumer-0.4.3-1.el6
python-datanommer-models-0.4.4-1.el6
python-envisage-4.3.0-3.el6
python-traitsui-4.3.0-2.el6
razorqt-0.5.2-9.el6
trac-fedmsg-plugin-0.1.0-1.el6
Details about builds:
cloc-1.58-4.el6 (FEDORA-EPEL-2013-5825)
Count lines of code
Update Information:
Fix autoreqs.
Latest upstream.
ChangeLog:
* Tue May 14 2013 Ricky Elrod codebl...@fedoraproject.org - 1.58-4
- Enable the requires filter. (bz #962783)
* Mon May 13 2013 Ricky Elrod codebl...@fedoraproject.org - 1.58-3
- Refer to pod2man BR by path, the package name varies.
* Mon May 13 2013 Ricky Elrod codebl...@fedoraproject.org - 1.58-2
- Use the tarball release instead.
- Fix license field.
* Mon May 13 2013 Ricky Elrod codebl...@fedoraproject.org - 1.58-1
- Latest upstream release.
* Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.56-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
* Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.56-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
References:
[ 1 ] Bug #962783 - cloc-1.58-3.el6 has wrong autoreq requires for
perl(Win32::File)
https://bugzilla.redhat.com/show_bug.cgi?id=962783
[ 2 ] Bug #962268 - cloc-1.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962268
fedmsg-0.6.8-4.el6 (FEDORA-EPEL-2013-5818)
Tools for Fedora Infrastructure real-time messaging
Update Information:
Relegate daemon-specific config files to their respective subpackages.
ChangeLog:
* Tue May 14 2013 Ralph Bean rb...@redhat.com - 0.6.8-4
- Make file ownership over /etc/fedmsg.d explicit per sub-package.
* Mon Mar 25 2013 Ralph Bean rb...@redhat.com - 0.6.8-3
- Added forgotten mkdir for %{buildroot}%{_unitdir}
* Mon Mar 25 2013 Ralph Bean rb...@redhat.com - 0.6.8-2
- Moved .service files from a dbus folder to a systemd folder
https://github.com/fedora-infra/fedmsg/issues/125
- Marked .service files as no longer %config files.
References:
[ 1 ] Bug #919978 - Relegate config files to subpackages
https://bugzilla.redhat.com/show_bug.cgi?id=919978
ga-5.1.1-2.el6 (FEDORA-EPEL-2013-5819)
Global Arrays Toolkit
Update Information:
New package Global Arrays Toolkit.
References:
[ 1 ] Bug #810336 - Review Request: ga - Global Arrays Toolkit
https://bugzilla.redhat.com/show_bug.cgi?id=810336
Re: Question about what to do if mantainer is absent
On Wed, 2013-05-15 at 12:21 -0600, Pete Zaitcev wrote: How do they deal with a conflict? Imagine someone there splitting texlive into 2500 subpackages and then 100 angry contributors reverting it. What are they going to do in their open model then? -- Pete Well the maintainers would just not accept the requests. :) But probably none would be submitted anyway, since everybody knows that would be what happens. (But #2, the texlive maintainers would never do that since the release team would not approve the maintainers' request - it's a tiered process. Again, probably not appropriate for Fedora.) What does happen sometimes is two people make unrelated changes to the same package, and open build service is not smart enough to handle that very well. (Not a problem with git.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hdf5 update to 1.8.11 in rawhide
I will be updating hdf5 t0 1.8.11 in rawhide tomorrow. This will requires a rebuild of packages built against it. I will try to get to all of those well. cgnslib-3.1-5.r4.fc19.src.rpm dmapd-0.0.51-1.fc20.src.rpm Field3D-1.3.2-9.fc19.src.rpm gdal-1.9.2-5.fc20.src.rpm gdl-0.9.3-6.cvs20130321.fc20.src.rpm grads-2.0.1-6.fc19.src.rpm gtatool-1.5.2-1.fc20.src.rpm h5py-2.1.0-2.fc19.src.rpm hdf5-1.8.10-3.fc19.src.rpm InsightToolkit-4.3.1-11.fc20.src.rpm jhdf5-2.9-1.fc19.src.rpm LabPlot-1.6.0.3-3.fc19.src.rpm mathgl-2.1.2-7.fc20.src.rpm matio-1.5.1-1.fc20.src.rpm ncl-6.1.2-1.fc19.src.rpm netcdf-4.3.0-1.fc20.src.rpm nip2-7.32.1-1.fc20.src.rpm octave-3.6.4-3.fc20.src.rpm OpenImageIO-1.1.3-7.fc20.src.rpm paraview-3.98.1-4.fc20.src.rpm python-tables-2.4.0-2.fc19.src.rpm R-hdf5-1.6.9-20.fc19.src.rpm R-Rsolid-0.9.31-9.fc20.src.rpm scilab-5.4.0-2.fc19.src.rpm vigra-1.9.0-5.fc19.src.rpm vips-7.32.3-1.fc20.src.rpm ViTables-2.1-5.fc19.src.rpm vtk-5.10.1-4.fc19.src.rpm -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 02:41 PM, Dave Jones wrote: On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote: I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently Well, it works fine for myself and for quite a few other folks I know. Cool story. FWIW, I ran btrfs (over LVM, sorry Lennart) on my home system ever since it became available in Fedora. I have seen weird performance issues under swapping load that I couldn't measure with my inferior system tuning chops (the pinnacle of my effort was running iotop), but it's been solid otherwise. I was planning to upgrade to F19 soon, and I kind-of care about the data on that system (I have backup, but corruption would not be welcome, just for the lost time reason). Do people recommend sticking with it? holding off the upgrade? switching back to ext4? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 08:39 PM, Przemek Klosowski wrote: On 05/15/2013 02:41 PM, Dave Jones wrote: On Wed, May 15, 2013 at 02:25:22PM +0200, Lennart Poettering wrote: I Want To Believe in btrfs, but unfortunately it's still excessively buggy. It's actually got worse in Rawhide recently Well, it works fine for myself and for quite a few other folks I know. Cool story. FWIW, I ran btrfs (over LVM, sorry Lennart) on my home system ever since it became available in Fedora. I have seen weird performance issues under swapping load that I couldn't measure with my inferior system tuning chops (the pinnacle of my effort was running iotop), but it's been solid otherwise. I was planning to upgrade to F19 soon, and I kind-of care about the data on that system (I have backup, but corruption would not be welcome, just for the lost time reason). Do people recommend sticking with it? holding off the upgrade? switching back to ext4? Dont we need few brave souls to give Josef something to work with ;) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, May 14, 2013 at 7:56 PM, Michael Catanzaro mike.catanz...@gmail.com wrote: You can even now also mention in your bug that you are a packager and would be willing to co-maintain. Not everyone would be interested, but I suspect a lot of maintainers would be happy for the help and would add you to make your change. Yes, but I usually just want to submit the one fix and not co-maintain -- we all help out as we're able. :) You can always drop the co-maintainership after you've got the ACLs and done your work :) Speaking for myself, if I see someone's contributed a good patch in Bugzilla, I'd much sooner add them as a co-maintainer (even if it's just temporary) than have the entire Fedora project become a free-for-all. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 04:39 PM, Przemek Klosowski wrote: I was planning to upgrade to F19 soon, and I kind-of care about the data on that system (I have backup, but corruption would not be welcome, just for the lost time reason). Do people recommend sticking with it? holding off the upgrade? switching back to ext4? https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F is a reasonably good answer to that question. I would note that traditional linux filesystems have a very long history and time to mature including XFS and Ext4 and only check for metadata integrity unlike Btrfs. If you have a good (and frequent) backup system, it might be worth riding it out but you will have to evaluate the risks and make that determination of your own. FWIW, I am using Btrfs without any (known) issues for a while but I also have almost no data in my laptop that I cannot afford to lose since everything important is an external backup disk and really important files are in another laptop as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 05:36 AM, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: 479ms iprupdate.service 385ms iprinit.service These appear to be untis that are only necessary for IBM RAID. It's hugely disappointing if this is pulled into all boots. I wonder if we can find a different logic for this, for example pulling it in from a udev rules or so. Or by changing anaconda to install this only onb IBM RAID systemd... Anyone knows what this is about? Also, I don't see either of these listed in the default preset file. This really shouldnt be started by default. 78ms iprdump.service IBM RAID again? Jeez... These are from the iprutils package: Summary : Utilities for the IBM Power Linux RAID adapters Description : Provides a suite of utilities to manage and configure SCSI devices supported by the ipr SCSI storage device driver. And are sysv init scripts: /etc/rc.d/init.d/iprdump /etc/rc.d/init.d/iprinit /etc/rc.d/init.d/iprupdate Which is listed a mandatory in the core group of comps. CCing iprutils-owner for comment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM Weekly Status Meeting Minutes 2013-05-15
Thanks to those that were able to join for the status meeting today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-15/fedora-meeting-1.2013-05-15-20.18.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-15/fedora-meeting-1.2013-05-15-20.18.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-15/fedora-meeting-1.2013-05-15-20.18.log.html === #fedora-meeting-1: Fedora ARM weekly status meeting === Meeting started by pwhalen at 20:18:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-15/fedora-meeting-1.2013-05-15-20.18.log.html . Meeting summary --- * 0) Status of ACTION items from our previous meeting (pwhalen, 20:19:20) * LINK: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-08/fedora-meeting-1.2013-05-08-20.00.html (pwhalen, 20:19:20) * COMPLETE - dgilmore to post TC Images to list later today/tomorrow (pwhalen, 20:19:30) * COMPLETE - pwhalen to update wiki with pointers/instructions (to be updated for Beta) (pwhalen, 20:19:31) * INPROGRESS - jonmasters to help review 3.10 test kernels, and assist pwhalen with vexpress (pwhalen, 20:19:31) * INPROGRESS - jonmasters to probe highbank 3.9 instability issue and send update (pwhalen, 20:19:31) * ACTION: jonmasters to help review 3.10 test kernels, and assist pwhalen with vexpress (pwhalen, 20:24:24) * 1) Problem packages (pwhalen, 20:24:41) * 2) Kernel Status Update (pwhalen, 20:28:08) * 3) Aarch64 Status Update (pwhalen, 20:29:24) * 9278 packages built, 4000 to go (bconoboy, 20:31:19) * documentation processing packages such as texlive and doxygen are now built (bconoboy, 20:31:52) * j_dulaney has bootstrapped ghc (bconoboy, 20:32:09) * new foundation model is available which fixes crash issue with image-based rootfs (bconoboy, 20:32:37) * ACTION: pwhalen to post new image/instructions to the wiki for aarch64 quickstart (pwhalen, 20:33:23) * LINK: Participating on the bootstrap starts at https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart (bconoboy, 20:33:52) * 4) Fedora 19 Beta for ARM (pwhalen, 20:39:15) * 4a) Fedora 19 for ARM - Skipping Alpha, releasing Beta with PA (pwhalen, 20:39:21) * 4b) Fedora 19 for ARM - Graphics support (pwhalen, 20:41:05) * beta might not have support for graphics hardware (bconoboy, 20:44:44) * ACTION: jonmasters will check vexpress or omap over weekend (bconoboy, 20:44:59) * ACTION: pwhalen will investigate tegra options (bconoboy, 20:45:05) * 4c) Fedora 19 for ARM - Image format (pwhalen, 20:45:40) * docs on omap booting http://www.omappedia.com/wiki/Bootloader_Project (dgilmore, 20:50:12) * 4d) Fedora 19 for ARM - Scheduling a VFAD (pwhalen, 20:51:02) * Fedora 19 Beta VFAD on Tuesday May 21st @ 11am (provided we have images) (pwhalen, 20:51:52) * 5) Pidora Status Update (pwhalen, 20:54:28) * ACTION: ctyler to send an email to the list with Pidora (Raspberry Pi Fedora 18 Remix armv6hl version) image link (pwhalen, 21:03:00) * 6) Open Floor (pwhalen, 21:05:53) Meeting ended at 21:13:08 UTC. Action Items * jonmasters to help review 3.10 test kernels, and assist pwhalen with vexpress * pwhalen to post new image/instructions to the wiki for aarch64 quickstart * jonmasters will check vexpress or omap over weekend * pwhalen will investigate tegra options * ctyler to send an email to the list with Pidora (Raspberry Pi Fedora 18 Remix armv6hl version) image link Action Items, by person --- * ctyler * ctyler to send an email to the list with Pidora (Raspberry Pi Fedora 18 Remix armv6hl version) image link * jonmasters * jonmasters to help review 3.10 test kernels, and assist pwhalen with vexpress * jonmasters will check vexpress or omap over weekend * pwhalen * jonmasters to help review 3.10 test kernels, and assist pwhalen with vexpress * pwhalen to post new image/instructions to the wiki for aarch64 quickstart * pwhalen will investigate tegra options * **UNASSIGNED** * (none) People Present (lines said) --- * pwhalen (75) * bconoboy (55) * j_dulaney (34) * dgilmore (32) * masta (30) * jonmasters_ (28) * ctyler (27) * zodbot (12) * ddd__ (7) * msalter (4) * ahs3 (3) * dmarlin (2) * jcapik (2) * nirik (1) * kwizart (1) * pbrobinson (0) * agreene (0) * jonmasters (0) * ddd (0) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/15/2013 03:17 PM, Orion Poplawski wrote: On 05/15/2013 05:36 AM, Lennart Poettering wrote: On Tue, 14.05.13 20:43, Adam Williamson (awill...@redhat.com) wrote: 479ms iprupdate.service 385ms iprinit.service These appear to be untis that are only necessary for IBM RAID. It's hugely disappointing if this is pulled into all boots. I wonder if we can find a different logic for this, for example pulling it in from a udev rules or so. Or by changing anaconda to install this only onb IBM RAID systemd... Anyone knows what this is about? Also, I don't see either of these listed in the default preset file. This really shouldnt be started by default. 78ms iprdump.service IBM RAID again? Jeez... These are from the iprutils package: Summary : Utilities for the IBM Power Linux RAID adapters Description : Provides a suite of utilities to manage and configure SCSI devices supported by the ipr SCSI storage device driver. And are sysv init scripts: /etc/rc.d/init.d/iprdump /etc/rc.d/init.d/iprinit /etc/rc.d/init.d/iprupdate Which is listed a mandatory in the core group of comps. CCing iprutils-owner for comment. Interestingly, I only see this installed on a few of my machines. I haven't figured out the common thread yet. I think it may be Fedora 18+, so maybe something changed in anaconda to no longer remove/exclude it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
