Re: Summary of accepted Fedora 20 Changes - week 30
On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: > On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote: > > Really? I'd expect most users to be using gmail at this point. Any > > solution needs to account for them as well. > > 1. By the same logic we can ship just a browser, why bother building >LibreOffice if many use just google-docs? Because not everyone uses Google Docs, and so any solution needs to account for those who don't as well. > 2. People can still use gmail and other online services like twitter >via desktop applications (in my case kmail and choqok respectively). But most don't, and therefore an error reporting scheme that depends on users running a local mail client is inappropriate. > Last side note: helping non-expert people get used to quality local > applications which have convenient defaults, is part of the push > for "Freedom" -- if both your data and your applications are locked > in vertical clouds, you aren't left with too much freedom. There are benefits in running local applications, especially when it comes to freedom. However, we are unable to force our users to run local applications. We therefore need a mechanism for providing error data to users that doesn't require them to run a local application. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
Le Sam 27 juillet 2013 21:31, Michael Scherer a écrit : > Sure, so that's 1 person. No, find just a bit more and we will start to > be able to have proper data instead of anecdote. I'm quite sure you'll find more than a bit more such users among Fedora users. And, btw, the burden of proof is on the people who made the unsubstantiated assertion, don't try to reverse it Anyway, I've seen a quite a few bad arguments on this thread so I'll make answers in one go. 1. system MTA is bad, because sendmail is bad → just switch to a modern replacement like postfix 2. system MTA can not use different sender credentials by user → yes it can 3. it's too much work to configure a mail per user → because it's less work to do it once per user and per mua rather than one per user centrally? 4. this is not a simple anaconda patch → I believe it's be way easier to have anaconda write a stable config file that the ever-changing "desktop-only" mess we've forced it to cope with for years 5. users don't want local mail spool, they use gmail → then let them configure at install time the system MTA so it relays mail to gmail 6. nobody understands cron mail, it's obscure, untranslated → nobody is a stretch and anyway this is a property of the sending apps not of the communication medium. Fix the text of the notices, localize it, and then give it to the MTA. You'll need to work on this anyway if you want to do GUI notifications 7. There is no rate limiting on mail notifications → just do the rate limiting at the source with a filter-before-sending program. Again, you'll need to do the same work for GUI notifications 8. but I don't care about those notices, I'll just suppress them, or bury them in the journal, and no one will be the wiser → this is ostrich design. Those notices were created because people found them useful 9. A mail does not permit proper interaction → somehow Amazon, Google, Ebay manage it perfectly. It's just a matter of writing good notification texts, and adding callbacks to your system with single-use tickets (either web links or attachments a specialized app can display in a notification center). When people wanted to play with extensions, there was no such "can not integrate Internet with the deskop" argument 10. users do not expect a desktop that sends mail → users didn't expect smartphones at all. I guess neither Apple, not Google, not Samsung should have spent a dime on them. Users are far more adaptable than you think, what they expect is irrelevant, what matters is whether your implementation sucks or not 11. smtpd has no place on a desktop → neither Microsoft, not Apple, nor Google, are building pure desktop solutions. They're integrating desktops, laptops, servers, appliances, gizmos, cloud, to provide the best user experience and choose technical bricks based on the functionality they want to achieve, not based on archaic silos 12. all users do not know how to filter their mail → a hell of a lot more users know how to filter their mail than how to filter the custom notification systems people want to replace them with. And this will still be the case in the future, since filtering mail is useful for lots of other things, and dealing with a GUI system that will be rewritten anyway in a few years is not 13. there will only be at most one Fedora system per home anyway → If that's the case, Fedora will be a failure. Given plummeting hardware prices the only bottleneck is Fedora execution (see for example the latest Google dongle. Google is *not* settling for a single Google system per home) 14. Fedora users are irrelevant, I want normal users → what has this attitude ever produced except a collapse in Fedora users? Your normal users, when they actually had a vote (ie RHEL side, when an unhappy user can just cancel his subscription), didn't vote the way your "common sense" indicated (and it was not the first time either, see spacial desktop). Use less "common sense" and "design", do more actual user studies (real users not imaginary ones). Removing features never made other features appear by magic 15. it's useless on servers → on the contrary, once the email notifications are streamlined and standardized it'd be trivial for server alerting systems to pick up mail notifications and inject them in a central console (or if you want to be fancy, just take the local notification processing node, and have it queue notifications on a centralized AMPQ bus instead of smtp-side when the bus is available). The main point is to process notifications before deciding how they are sent, instead of the direct app-to-GUI-popup unmanaged inconsistent mess 16. I can do the same with a central syslog → good for you, but even if that was the case it'll be a lot easier for your central system to process notifications that have been streamlined for a little for smtp sending rather than the current inconsistent situation 17. there's no need to work on this, "technical" users will know how to set up an MTA → th
Obsoleting ConsoleKit once and for all
Hi, After discussion on #fedora-devel, my MATE co-maintainer raveit65, Kalev, Misc, and previous conversations with Rex, I am ready to retire ConsoleKit. LightDM seems to fully support systemd-logind. However I have no rights to commit to systemd. Lennart or any proven packager please add the following obsoletes tag to systemd: obsoletes: ConsoleKit obsoletes: ConsoleKit-x11 obsoletes: ConsoleKit-libs I will take care of testing, retiring and blocking the package. Thanks, Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Obsoleting ConsoleKit once and for all
Am Sonntag, den 28.07.2013, 04:03 -0700 schrieb Dan Mashal: > Hi, > > After discussion on #fedora-devel, my MATE co-maintainer raveit65, > Kalev, Misc, and previous conversations with Rex, I am ready to retire > ConsoleKit. Others are not. I am pretty sure ConsoleKit is still needed by LXDM and slim as they don't support systemd-logind and by pcmamfm and thunar for handling permissions of removable devices. > LightDM seems to fully support systemd-logind. > > > However I have no rights to commit to systemd. > > Lennart or any proven packager please add the following obsoletes tag > to systemd: > > obsoletes: ConsoleKit > obsoletes: ConsoleKit-x11 > obsoletes: ConsoleKit-libs I don't see why we need to obsolete it at this point. Sure, at some point it needs to die, but your approach doesn't seem well thought through. > I will take care of testing, retiring and blocking the package. Are you planning other desktops, too? And what about window-managers? Best regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Obsoleting ConsoleKit once and for all
On Sun, Jul 28, 2013 at 4:24 AM, Christoph Wickert wrote: > Am Sonntag, den 28.07.2013, 04:03 -0700 schrieb Dan Mashal: >> Hi, >> >> After discussion on #fedora-devel, my MATE co-maintainer raveit65, >> Kalev, Misc, and previous conversations with Rex, I am ready to retire >> ConsoleKit. > > Others are not. I am pretty sure ConsoleKit is still needed by LXDM and > slim as they don't support systemd-logind and by pcmamfm and thunar for > handling permissions of removable devices. > >> LightDM seems to fully support systemd-logind. >> >> >> However I have no rights to commit to systemd. >> >> Lennart or any proven packager please add the following obsoletes tag >> to systemd: >> >> obsoletes: ConsoleKit >> obsoletes: ConsoleKit-x11 >> obsoletes: ConsoleKit-libs > > I don't see why we need to obsolete it at this point. Sure, at some > point it needs to die, but your approach doesn't seem well thought > through. > >> I will take care of testing, retiring and blocking the package. > > Are you planning other desktops, too? And what about window-managers? Hi Chris, I took ownership of ConsoleKit because I saw what a disaster it would be to retire/block it when Lennart wanted to. I didnt realize so many other things required. By all means add yourself as co maintainer and lets work together to get this resolved. For all I care the package can live until Fedora 30. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20130728 changes
Compose started at Sun Jul 28 08:15:02 UTC 2013 Broken deps for i386 -- [aether-ant-tasks] aether-ant-tasks-1.0-0.7.SNAPSHOT.fc20.noarch requires mvn(org.sonatype.aether:aether-util) aether-ant-tasks-1.0-0.7.SNAPSHOT.fc20.noarch requires mvn(org.sonatype.aether:aether-connector-file) aether-ant-tasks-1.0-0.7.SNAPSHOT.fc20.noarch requires mvn(org.sonatype.aether:aether-connector-asynchttpclient) aether-ant-tasks-1.0-0.7.SNAPSHOT.fc20.noarch requires mvn(org.sonatype.aether:aether-api) [aws] aws-2.11.0-16.fc20.i686 requires libxmlada_unicode.so.4.3w aws-2.11.0-16.fc20.i686 requires libxmlada_schema.so.4.3w aws-2.11.0-16.fc20.i686 requires libxmlada_sax.so.4.3w aws-2.11.0-16.fc20.i686 requires libxmlada_input_sources.so.4.3w aws-2.11.0-16.fc20.i686 requires libxmlada_dom.so.4.3w aws-tools-2.11.0-16.fc20.i686 requires libxmlada_unicode.so.4.3w aws-tools-2.11.0-16.fc20.i686 requires libxmlada_schema.so.4.3w aws-tools-2.11.0-16.fc20.i686 requires libxmlada_sax.so.4.3w aws-tools-2.11.0-16.fc20.i686 requires libxmlada_input_sources.so.4.3w aws-tools-2.11.0-16.fc20.i686 requires libxmlada_dom.so.4.3w [bind10] bind10-1.1.0-1.fc20.i686 requires libbotan-1.8.2.so bind10-devel-1.1.0-1.fc20.i686 requires pkgconfig(botan-1.8) bind10-dhcp-1.1.0-1.fc20.i686 requires libbotan-1.8.2.so bind10-dns-1.1.0-1.fc20.i686 requires libbotan-1.8.2.so bind10-libs-1.1.0-1.fc20.i686 requires libbotan-1.8.2.so [bzrtools] bzrtools-2.5-3.fc19.i686 requires bzr < 0:2.6.0 [coot] coot-0.7-1.20120929svn4458.fc18.i686 requires libssm.so.0 coot-0.7-1.20120929svn4458.fc18.i686 requires libclipper.so.2 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [devtodo2] devtodo2-2.1-5.20120711git8dee6.fc20.i686 requires libgo.so.3 [eclipse-m2e-core] eclipse-m2e-core-1.4.0-1.fc20.noarch requires sisu [gdb-heap] gdb-heap-0.5-12.fc19.i686 requires glibc(x86-32) = 0:2.17 [glusterfs] glusterfs-ufo-3.4.0-3.fc20.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-3.fc20.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-3.fc20.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-3.fc20.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-3.fc20.noarch requires openstack-swift = 0:1.8.0 [gmaven] gmaven-1.4-4.fc19.noarch requires gshell [gr-air-modes] gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires libgruel-3.6.5.so.0.0.0 gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires libgnuradio-core-3.6.5.so.0.0.0 [gr-osmosdr] gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgruel-3.6.5.so.0.0.0 gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgnuradio-fcd-3.6.5.so.0.0.0 gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgnuradio-core-3.6.5.so.0.0.0 gr-osmosdr-devel-0.0.1-3.20130403gite85c68d9.fc20.i686 requires pkgconfig(gnuradio-core) [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [jboss-as] jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3 [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.i686 requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.i686 requires liblutok.so.0 [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1 [maven-indexer] maven-indexer-4.1.2-5.fc19.noarch requires sisu [mingw-cximage] mingw32-cximage-600-8.fc19.noarch requires mingw32(libpng15-15.dll) mingw64-cximage-600-8.fc19.noarch requires mingw64(libpng15-15.dll) [monotone] monotone-1.0-11.fc19.i686 requires libbotan-1.8.2.so [ne7ssh] ne7ssh-1.3.2-15.fc20.i686 requires libbotan-1.8.2.so [nightview] nightview-cli-0.3.3-9.fc20.i686 requires libcfitsio-3.340.so.0 nightview-gui-0.3.3-9.fc20.i686 requires libcfitsio-3.340.so.0 [nodejs-express] nodejs-express-3.3.3-1.fc20.noarch requires npm(connect) >= 0:2.8.3 nodejs-express-3.3.3-1.fc20.noarch requires npm(commander) >= 0:1.2.0 [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 [openlierox] openlierox-0.59-0.11.beta10.fc20.i686 requires libgd.so.2 [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.i686
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On 27.07.2013 05:07, Chris Murphy wrote: On Jul 26, 2013, at 4:53 PM, Pádraig Brady wrote: On 07/26/2013 09:13 PM, Miloslav Trmač wrote: Hello all, with thin provisioning available, the total and free space values reported by a filesystem do not necessarily mean that that much space is _actually_ available (the actual backing storage may be smaller, or shared with other filesystems). If your package reports disk space usage to users, and bases this on filesystem free space, please consider whether it might need to take LVM thin provisioning into account. The same applies if your package automatically allocates a certain proportion of the total or available space. A quick way to check whether your package is likely to be affected, is to look for statfs() or statvfs() calls in C, or the equivalent in your higher-level library / programming language. Anything df(1) should do here? Example: Creating a btrfs raid1 volume from two 2TB drives, df shows it as having 4TB available: # parted -l Error: /dev/sdb: unrecognised disk label Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 2199GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Error: /dev/sdc: unrecognised disk label Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdc: 2199GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: # mkfs.btrfs -d raid1 -m raid1 /dev/sd[bc] WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using adding device /dev/sdc id 2 fs created label (null) on /dev/sdb nodesize 4096 leafsize 4096 sectorsize 4096 size 4.00TB Btrfs v0.20-rc1 # mount /dev/sdb /mnt # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda179G 4.2G 71G 6% / devtmpfs1.5G 0 1.5G 0% /dev tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 1.5G 680K 1.5G 1% /run tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup tmpfs 1.5G 4.0K 1.5G 1% /tmp none224G 87G 138G 39% /media/sf_chris /dev/sdb4.0T 56K 4.0T 1% /mnt The explanation is that the file system isn't raid1, but rather the allocated chunks have this attribute. Presently a volume only allocates with one profile, but the future plan is per subvolume and even per file raid profiles. So establishing how much free space there is on a btrfs volume is absolutely less than clear. Anyway, I think it will cause some confusion if by "available" an application thinks it can write out more than 2TB of data to this example volume. I thought one of the features of combining the block layer and filesystem layer like btrfs does is that the filesystem can actually know the state/topology of the block layer and work more efficiently. Combined with the already existing problem of getting out of diskspace errors long before use hits 100% (has this been fixed since?) this makes any sort of capacity planning difficult if not impossible. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
scalapack armv7hl not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. scalapack-openmpi-devel.fc20.armv7hl is not found: http://kojipkgs.fedoraproject.org//work/tasks/6915/5666915/root.log But the package 'scalapack-openmpi-devel-1.7.5-19.fc20.armv7hl' is successfully built: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=156903 Why is it not recognized ? - -- - Antonio Trande mailto: sagit...@fedoraproject.org Homepage: http://www.fedoraos.worpress.com GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9TbHAAoJED2vIvfUANbEfBcP/0z4q9j8DRvhzKo0f31Va7hZ +DyJ5If5Tp8fylXg9PNugaBvm7vwAWgnwOhtfc96dMXpDHPQgw9TzugZzGmZl7c0 eJ9d0ObaVMGCqoomY5I/2wrDkU9AjisjolaAxKUmWlExUooelJdnKN4qUAh1p8LM fgtFo+THEwiW9kusc1xY0BWTWNY2Ugd6VxC6+D6ogtkhRFHHe/LIHYcsQOfXiqLK eTLfM6HpcmjFwd2w5TfT+DBu6ZXNKtXuuXnXPzxBm0qIco0nGPdgcBXuMFS5xuXL DuTF9+ORdreRcKZJdd2bAcwebaY/UZ15fJZ/eijUEu82ldAqetOHYzEgVtF3uaN2 aSrGjCdUg1Qr54MsX/Mqal7WOg1WW1eB5t1GIxJE4hb3D9HyC2voGOSF1bp3gjm4 T8NSGkCMJN+eaI4mdKO2fhdUhYvAFcP10c2n78Pzbi9gJBRZT1Q2aKIy3lxfmymZ wD4zx87YIq5d0glEc50NKcFE3kXtz6Dg+gCN+x97nVSfr9WS4aoEQoTuzy06q5LV YFZgg/80i2w0okVkTdjhswLWqRqPkmcL8kMY5a7TwMKegFP+FYZ7ktI3HgEcI/mc uWZqmdYZIeNeX0SyFt++B8puIMW6pD0AyEXSj0ItFyolUf68Mf7BtpQXMMbtuxn1 rboxmVH87ZnxFxjGEkhD =w7jB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: scalapack armv7hl not found
I've just imported it from arm koji to koji. It should now be fine Antonio Trande wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Hi all. > >scalapack-openmpi-devel.fc20.armv7hl is not found: >http://kojipkgs.fedoraproject.org//work/tasks/6915/5666915/root.log > >But the package 'scalapack-openmpi-devel-1.7.5-19.fc20.armv7hl' is >successfully built: >http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=156903 > >Why is it not recognized ? > >- -- >- >Antonio Trande > >mailto: sagit...@fedoraproject.org >Homepage: http://www.fedoraos.worpress.com >GPG Key: D400D6C4 >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.4.13 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQIcBAEBAgAGBQJR9TbHAAoJED2vIvfUANbEfBcP/0z4q9j8DRvhzKo0f31Va7hZ >+DyJ5If5Tp8fylXg9PNugaBvm7vwAWgnwOhtfc96dMXpDHPQgw9TzugZzGmZl7c0 >eJ9d0ObaVMGCqoomY5I/2wrDkU9AjisjolaAxKUmWlExUooelJdnKN4qUAh1p8LM >fgtFo+THEwiW9kusc1xY0BWTWNY2Ugd6VxC6+D6ogtkhRFHHe/LIHYcsQOfXiqLK >eTLfM6HpcmjFwd2w5TfT+DBu6ZXNKtXuuXnXPzxBm0qIco0nGPdgcBXuMFS5xuXL >DuTF9+ORdreRcKZJdd2bAcwebaY/UZ15fJZ/eijUEu82ldAqetOHYzEgVtF3uaN2 >aSrGjCdUg1Qr54MsX/Mqal7WOg1WW1eB5t1GIxJE4hb3D9HyC2voGOSF1bp3gjm4 >T8NSGkCMJN+eaI4mdKO2fhdUhYvAFcP10c2n78Pzbi9gJBRZT1Q2aKIy3lxfmymZ >wD4zx87YIq5d0glEc50NKcFE3kXtz6Dg+gCN+x97nVSfr9WS4aoEQoTuzy06q5LV >YFZgg/80i2w0okVkTdjhswLWqRqPkmcL8kMY5a7TwMKegFP+FYZ7ktI3HgEcI/mc >uWZqmdYZIeNeX0SyFt++B8puIMW6pD0AyEXSj0ItFyolUf68Mf7BtpQXMMbtuxn1 >rboxmVH87ZnxFxjGEkhD >=w7jB >-END PGP SIGNATURE- >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel >Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
Am 27.07.2013 21:31, schrieb Michael Scherer: > Le samedi 27 juillet 2013 à 12:54 +0200, Reindl Harald a écrit : >> >> Am 27.07.2013 12:45, schrieb drago01: >>> On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot > Even if we do that ... for most of those user this mails are mostly noise. Where are the facts backing this assertion? >>> >>> Common sense ... >> >> so i am maintaing more than 20 fedora machines and i am >> happy about this mails from my *first day* with Fedora >> many years ago > > Sure, so that's 1 person. No, find just a bit more and we will start to > be able to have proper data instead of anecdote. 5 others around me... in fact anybody *i know* weho is using Linux > I can tell that most of the non technical users ( around 40 in my > office, but I have no reason to believe the 1960 in others offices are > different on that part ) using linux desktop at work ask me why they > receive mail everyday speaking of the backup system not being configured > ( and so mailling them to enable it ) perfect - so why does the admin not his job and configure or remove it? there you see *why* the mails are good *because* they ask > Most have no idea why they receive mail from the computer most have no idea about anything on computers but if they face things they can understand them with remove anything "most have no idea" you can remove the whole operating syetem at all > A mail sent by your computer to say something on a regular basis is not, > except for technical person like you and me ( and usually, when I > receive mail from cron, they are obscure and useless and due to some > failure, so I think people writing cron job do not care that much to > help me seeing what is is wrong ). i can not remember any cron mail which was not clear in doubt Google is everybody's friend >>> where are the facts backing up the opposite? >> >> nobody needs to backing up the opposite! >> >> if somebody comes up and and declares long existing >> things as noise and wants to deprecate them he is >> the one who has to bring facts > > cron output is usually not translated ( cause it is well know that every > admin speak english, why should we take care of that ), and that's > already a problem. really? > A mail do not permit a good interaction ( like "click here to configure > stuff that you should configure" ) while a notification permit that ( at > least on a desktop ) i doubt that a desktop notify permits the user admin-actions and if so which ones so that i can file a bugreport > There is no rate limitation for cronjob output. Usually, no need to send > me 100 mails about "job error, no disk space", I got the message on the > first mail, the 99th are just useless spam that also contribute to the > problem. if you really got the message you would have took action > AFAIK, you cannot easily ( ie, without being minimaly command line savy > ) opt out of the mail notification, except by filtering that on your > mail you *should not* opt out if smartd or mdadm are sending mails you should look at it > For a desktop use case with a single user, that's already enough reasons > to use something else. For a desktop with more than 1 user, the issue > are the same, except that now, someone has to configure the email of > every user in /etc/aliases, thus needing more than a anaconda patch. the user type you are describing all the time has no user cronjobs at all and the root-messages are for whoever calls himself admin and responsible for the machine > And for servers, having 2 ways to get logs of what is running is just > asking for more work than needed. When you setup something to aggregate > the log ( splunk, central syslog ), there is no need to have a second > system that send a different type of log on a different way, just > because "this was done like this before". 2 systems, twice the risk of > failing, twice the work to setup, and of course, they do not match on > feature do you watch all day long syslog of all machines? i do not because i have no time to do so and no place for so many terminals *but* any cronjob mail put via sieve in his folder get attention hence if my scripts are facing something is going wrong they simple echo what is wrong because i can rely that it ends in a notify-mail instead get spotted tomorrow thats why i can work this clean way running 600 domains with php error_reporting E_ALL and twice a hour collect the error log and echo it for a notify - well that is not the desktop case *but* if i had not seen this all at the desktop i would probably not know these things now there are *many* things which got "deperecated" from mostly the same people which are the reason i am doing today the job i do and without them i stil would be only programmer and not sysadmin and *that* is why IMHO it is completly wrong to remove things from which others could learn the same as i did signature.asc Description: OpenPGP digital signature -- devel mailing list devel
Re: scalapack armv7hl not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2013 06:03 PM, Dennis Gilmore wrote: > I've just imported it from arm koji to koji. It should now be fine > Thank you Dennis. - -- - Antonio Trande mailto: sagit...@fedoraproject.org Homepage: http://www.fedoraos.worpress.com GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9VCDAAoJED2vIvfUANbE3TMP/1BpPEs70sx6RNP2kpyRDlUK ovY9pibhMxNxmX+UiOxneGqnuCaAo3yUyrro09xlWVyixO0I8+EJKkqWWKo/eg+G Kuu8mnbyiQYeMs+hWXNlZ4sCkmn6YN5Z7UKNL2KR6p1w7gV20cKvb+vttKccqdlR /LCtddAriR0QYnR4sv+eZdaIeEqmghIPAo0Nvb1hYId/5nvKaIMOofo85DMN05T/ Dmf/09ArNQEwuCyeph0VGzivjddkMw1fz6O6OYy+gyRgyzbidrcFh+vfEcnalezV IAbYecI98wD7LJgcHGbrqejafF0A3CXQpT6QsyXVgUPbbcligkON4JYyOrI7Lg02 /Lg3K6pBVpwgxRwq3vstSkLoszkZfd36dVdCUx0jqQNgY4N+3H6JQaUaD749JhvW Zj8H25dZQq3dX2Pgcsjr+kaxZ83CkID8SGdOHaERf+WuNNiShyBw22m0jHRe7MzJ A1K2MX7pNUmKq7I1rG9IpxpOqL56ysCRr0NDfJbRmx95FV9NYH6raT/Nn56jzV+U +iYowTTjc0+FcOL+s+YyfEjqtjdMEPoAh9aJqn/Hfwn77D+GA0CbiP8fet/lUyBm UbwghATCfmfAfy/Ju3gonObNeM8jRR/IL4ADgl2RUpZdvujc2tjfZDGBZQZkxw/8 e4ff1OvAICosUq5/YaDS =Z0if -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Doc dir related changes coming up
Ville Skyttä wrote:
>The special (pathless) %doc macro now installs docs to unversioned
>/usr/share/doc/%{name} dir in Rawhide.
Not quite, it appears. %{name} is the name of the main package, but
%doc still produces a separate directory for each subpackage.
_docdir_fmt seems to be defined as "%%{NAME}" in current Rawhide, so I
guess NAME is different from name.
>Either way the suggested way to handle this is by
>using the %{_pkgdocdir} macro which is now in Rawhide, in
>redhat-rpm-config >= 9.1.0-50.fc20.
_pkgdocdir is defined as "%{_docdir}/%{name}", so in subpackages it
will differ from what %doc uses. Packagers need to be aware of this.
>%{!?_pkgdocdir: %global _pkgdocdir %{_docdir}/%{name}-%{version}}
And this also differs from what %doc uses for subpackages in earlier
releases, which may or may not be OK depending on how the package was
made before.
--
Björn Persson
Sent from my computer.
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Doc dir related changes coming up
On 2013-07-28 21:17, Björn Persson wrote:
> Ville Skyttä wrote:
> > The special (pathless) %doc macro now installs docs to unversioned
> > /usr/share/doc/%{name} dir in Rawhide.
>
> Not quite, it appears. %{name} is the name of the main package, but
> %doc still produces a separate directory for each subpackage.
Sure.
Regarding subpackages, I'd suggest installing their docs with plain
"special" %doc -- often installing the docs in %install to a temporary
staging dir helps with this. On the other hand with doc-only subpackages
I personally think that it would often make sense to install into the
main package's docdir instead of creating a separate dir, e.g. for a
package named foo, IMO it's better to have all docs in
/usr/share/doc/foo than some in that plus some in /usr/share/doc/foo-doc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ARM Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, I have imported ARM into primary and enabled armv7hl in the arches to be built. right now the KDE stack is not entirely built and brought in due to https://bugzilla.redhat.com/show_bug.cgi?id=988114 as soon as it is resolved we will get everything fixed and brought in. at that point arm will be added to the nightly composes. Regards Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlH1eZUACgkQkSxm47BaWffJ5QCgrE9p/An9pN/SpVKBAIAPH31q yNUAoJLe+jprGLlJeZN7R3WhCu3jBty4 =tUN7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 08:01:25 Matthew Garrett wrote: > On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: > > 1. By the same logic we can ship just a browser, why bother building > >LibreOffice if many use just google-docs? > Because not everyone uses Google Docs, and so any solution needs to > account for those who don't as well. And I thought those few "power-users" would install it by themselves ;-) Or, to make the example more to your taste -- if, as many claimed here, most people use Gmail can't we forgo installing MUA's by default? Hmmm new feature for F21? > > 2. People can still use gmail and other online services like twitter > >via desktop applications (in my case kmail and choqok respectively). > But most don't, and therefore an error reporting scheme that depends on > users running a local mail client is inappropriate. You don't suggest any alternative, so let me suggest an easy one (which btw I use on all my desktops for the last 20 years): * Something important is sent to local MTA. * User get mail notification on their desktop. * User click on the notification. * MUA opens. * User reads mail. All of this is plain configuration on any MUA/desktop-system. Just make these *DEFAULTS* and the "problem" is solved: * Alias root to installing user in /etc/aliases * Configure installed MUA's to include local spool mailbox by default. * Configure your desktop to notify about new mails. > > Last side note: helping non-expert people get used to quality local > > applications which have convenient defaults, is part of the push > > for "Freedom" -- if both your data and your applications are locked > > in vertical clouds, you aren't left with too much freedom. > > There are benefits in running local applications, especially when it > comes to freedom. However, we are unable to force our users to run local > applications. Don't force them -- expose the better value proposition: * Read mail accounts from different providers via single interface. * Get mail notifications, regardless of mail origin. * Subscribe to different IM systems via single IM application Correct default configuration of MTA+MUA is great way to hook people into these benefits -- especially those "newbies" (veterans already know this and configure this for themselves). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Life is a sexually transmitted, 100% lethal disease. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 10:29:47 Nicolas Mailhot wrote: > 17. there's no need to work on this, "technical" users will know how to > set up an MTA → that's what Solaris people thought before Linux people ate > their lunch integrating stuff they didn't want to bother with Very good example, it's called "batteries included". -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Ignore Your Rights And They'll Go Away -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Obsoleting ConsoleKit once and for all
On Sun, Jul 28, 2013 at 01:24:55PM +0200, Christoph Wickert wrote: > Others are not. I am pretty sure ConsoleKit is still needed by LXDM and > slim as they don't support systemd-logind and by pcmamfm and thunar for > handling permissions of removable devices. Slim doesn't require ConsoleKit anymore and works fine with logind. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review Swaps: groonga-normalizer-mysql
Hi all! Are there anybody interested in review swaps about groonga-normalizer-mysq package? Here is the brief description of groonga-normalizer-mysql: MySQL compatible normalizer plugin for groonga Here is the actual review bug: https://bugzilla.redhat.com/show_bug.cgi?id=957053 Thanks. -- HAYASHI Kentaro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)
On Fri, Jul 26, 2013 at 6:40 PM, Reindl Harald wrote: > > > > In the OS/App differentiation, you are expecting each is coming from a > different source. > > Apps are either boxed, or coming from a project. > > The app provider should fix their version of libxml, and the OS provider > should fix their version of libxml > > which is the definition of "fundamentally flawed" > period Lets disagree here. I don't believe it is fundamentally flawed. It seems you are expecting every software developer in the world to accept the versions that a Fedora packager has selected for a release without regards to functionality or changes being exposed. No wonder it it becomes impossible to run any app "on " Fedora for any length of time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swaps: groonga-normalizer-mysql
Exchange https://bugzilla.redhat.com/show_bug.cgi?id=972860 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swaps: groonga-normalizer-mysql
Or this one if you don't like the previous. https://bugzilla.redhat.com/show_bug.cgi?id=989297 fdm - A simple lightweight tool of fetching, filtering and delivering emails -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swaps: groonga-normalizer-mysql
Hi, Thank you for your quick response. I'll review this one! fdm - A simple lightweight tool of fetching, filtering and delivering emails https://bugzilla.redhat.com/show_bug.cgi?id=989297 2013/7/29 Christopher Meng > Or this one if you don't like the previous. > > https://bugzilla.redhat.com/show_bug.cgi?id=989297 > > fdm - A simple lightweight tool of fetching, filtering and delivering > emails > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- HAYASHI Kentaro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to package a set of brushes for Gimp
I am currently writing a spec for gimp-paint-studio. I cannot find a good way to effectively package it so I would like so guide: http://ur1.ca/et1h0 Thanks in advance, Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap for gimp-dds-plugin
Hello, I am looking for a reviewer for gimp-dds-plugin in exchange of swap. The package is very easy to review with all complete test. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=988489 Thank you. Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [SDL/f19] (2 commits) ...Add NAS support
On 2013-07-26, Nicolas Chauvet wrote:
> 2013/7/26 Daniel P. Berrange
>
>> NB I don't care if esound / arts remain in Fedora or not, but if we
>> want to kill them off, lets be consistent and kill them everywhere,
>> not just disable them in SDL
>>
> I'm more concerned about not installing arts/nas/esound by default when I
> only want to use SDL.
Don't worry, it does not run-require any of that libraries. Neither
pulseadio.
> But looking at the commit, this is when %if 0%{?rhel}.
>
These are build-time dependencies. Not run-time dependencies.
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
