Re: blivet-gui announcement
On Mon, 2014-09-08 at 12:41 +0200, Vratislav Podzimek wrote: > Will do, tomorrow. Or is too late now? Sorry I didn't reply before. I missed the mail. You can post to the magazine whenever you have the time. I see Ryan's already done a post on blivet-gui now, though: http://fedoramagazine.org/manage-your-partitions-like-in-anaconda-with-blivet-gui/ -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 17:29 Matthias Clasen napsal(a): On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote: Has Fedora given up Unix ?? This thread has gone quite far out into the weeds. It started with a fairly concrete question: can we improve the offline update experience by requiring only a single reboot, instead of two ? That's the core of the problem, while other systems have been trying for years to get rid of this nonsense (updates requiring reboots), we are moving the opposite direction. Technical reasons aside(*), this is NOT right for our users. (*) I agree offline updates are the safest way technically but that should be only regarded as a workaround for a more fundamental problem, lying deep below the desktop level. -- Lukáš Tinkl Senior Software Engineer - KDE desktop team, Brno KDE developer Red Hat Inc. http://cz.redhat.com -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 17:36 Miloslav Trmač napsal(a): - Original Message - 2. Ability to detect which processes depend on which versions of which components. We already managed to brought in systemd I can’t see how systemd helps. See the other discussions about Python/Ruby modules that leave no obvious trace of their dependency after being loaded into memory. It has similar complexity and maybe packages could be described just like services - so similar thing could be possibly reused here ? Extra manual dependency information that would get obsolete? Runtime removal of unused packages might be fun. It could be something like 'fstrim' tool to run through cron... 3. Ability to automatically restart such processes without loosing state (either completely transparently or with some user notification for GUIs). I'm not quite sure why we would need restart - simply delayed lazy release of unused packages would do the trick here - doing here state-full design is much more complex thing Because otherwise you end up with an old version of Firefox running for 60 days (or however long a laptop can run with suspends and no restarts; most people about never quit their browser), and that version of Firefox keeping an old version of a system-wide daemon running for 60 days as well.. Sure if user is able to run Firefox for 60 days (though my usually goes out of RAM in just a week or so, if it's not crashing earlier...) - then he is happy user. Until an exploit _that they have already installed an update for_ steals their data. I guess something may show to user some nice gui dialog warning like - 'Hey there is a new version installed - so 'restart' your browser to get new cool feature' (FF normally already detects upgrades and suggest restart) No, that’s not good enough. The OS should restart it for the user (other OSes already can do this). (In the case of user-invisible components there is no other option, and for user-visible GUIs it is also the right thing to do.) As long as Firefox can't restart 'unnoticeable' while playing youtube video - this is not an option - when admins updates machine - it just can't kill every users' running firefox. It's fine to place a warning somewhere and require restart with some 'many hours' timeout - but for almost all "Firefox" updates - it's good enough to restart it just sometimes latest - and for those 'have to restart' - it still upon admins policy - not upon Fedora package maintainer Zdenek -- 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: Proper directory for storing arch-independent data (bytecode)
Hello,
- Original Message -
> Imagine a virtual machine, %VMNAME%, which executes a arch-independent
> bytecode. Where packager should store it? Most notable candidates are
> /usr/share/%VMNAME%, /usr/lib/%VMNAME%.
>
> So far Java has /usr/share/java/, Perl uses %{perl_vendorlib}
> (/usr/share/perl5/vendor_perl), PHP uses /usr/share/php, R uses
> /usr/share/R/library, Ruby uses /usr/share/ruby/vendor_ruby,
> Javascripts are installed into %{_datadir}/javascript, Lisp is using
> %{_datadir}/common-lisp, etc
>
> But
>
> Python stores its arch-independent bytecode into
> /usr/lib/python?.?/site-packages/, Node.js prefers
> %{_prefix}/lib/node_modules, Mono is using /usr/lib/mono.
>
> It seems that there is no consensus on this matter. I personally tend
> to agree with those who use /usr/share, but for example systemd stores
> everything in /usr/lib including arch-independent stuff.
/usr/share is appropriate per FHS. Python is limited by the need for
arch-dependent extensions: it is not possible to write a module which has
arch-independent parts in /usr/share and arch-dependents extensions in
/usr/lib*. I don’t know about node.js and Mono.
systemd is not a good example: /usr/lib/systemd is really /opt/systemd and
violating the FHS, and allowed in Fedora only because fixing it would be too
difficult by now.
Mirek
--
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: Improving the offline updates user experience
- Original Message - > Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a): > > - Original Message - > >>> Well, what we would need is: > >>> 1. Ability to keep multiple versions (both ABI-compatible and > >>> ABI-incompatible) of a single application or library or service installed > >>> and running at the same time. > >> > >> Other distributions allow to install multiple version of same libraries > > > > AFAIK only when the ABI (soname) is different. We also need to allow for > > the case when the ABI stays the same but the internal implementation > > changes (e.g. changing a format of a resource file that is used by the > > library, making old processes incompatible with the newly installed > > resource). > > That's what I mean - when something changes in the library - soname should > change. It's quite broken to release same version of library with the same > name when there is different internal implementation. No. Let me try to explain the issue in detail. libfoo-1.0.0 and libfoo-1.0.1 both use /usr/share/libfoo/magic_database, but the internal format has changed between the versions. It is _internal_ so changing the soname would be both unnecessary and _inappropriate_ (breaking users). Looking at current packaging, neither RPM nor debian would install libfoo-1.0.0 and libfoo-1.0.1 in parallel. Looking at the filesystem (i.e. assuming that we can change packaging), we may have both /usr/lib*/foo-1.0.0.so and /usr/lib*/foo-1.0.1.so installed on the filesystem, but that /usr/share/libfoo/magic_database can only have only one of the versions. (OK, in this case it could be argued that it is the upstream’s fault and that they should version the magic_database path if they change the internal format, to explicitly design for parallel installs. But now consider the distribution patching the library (changing “release” as opposed to “version” in RPM terminology); upstream can’t reasonably for that, parallel installation of same-version-different-release packages must be a distribution-focused filesystem design. > >>> 2. Ability to detect which processes depend on which versions of which > >>> components. > >> > >> We already managed to brought in systemd > > > > I can’t see how systemd helps. See the other discussions about Python/Ruby > > modules that leave no obvious trace of their dependency after being loaded > > into memory. > > It has similar complexity and maybe packages could be described just like > services - so similar thing could be possibly reused here ? Extra manual dependency information that would get obsolete? > >>> 3. Ability to automatically restart such processes without loosing state > >>> (either completely transparently or with some user notification for > >>> GUIs). > >> > >> I'm not quite sure why we would need restart - simply delayed lazy release > >> of > >> unused packages would do the trick here - doing here state-full design is > >> much > >> more complex thing > > > > Because otherwise you end up with an old version of Firefox running for 60 > > days (or however long a laptop can run with suspends and no restarts; most > > people about never quit their browser), and that version of Firefox > > keeping an old version of a system-wide daemon running for 60 days as > > well.. > > Sure if user is able to run Firefox for 60 days (though my usually goes out > of RAM in just a week or so, if it's not crashing earlier...) - then he is > happy user. Until an exploit _that they have already installed an update for_ steals their data. > I guess something may show to user some nice gui dialog warning like - 'Hey > there is a new version installed - so 'restart' your browser to get new cool > feature' (FF normally already detects upgrades and suggest restart) No, that’s not good enough. The OS should restart it for the user (other OSes already can do this). (In the case of user-invisible components there is no other option, and for user-visible GUIs it is also the right thing to do.) Mirek -- 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: Nginx + Php + WebApp
Fantastic, you did it ! I suggest to submit it as a Feature for F22. H. -- 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: Improving the offline updates user experience
On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote: > > Has Fedora given up Unix ?? This thread has gone quite far out into the weeds. It started with a fairly concrete question: can we improve the offline update experience by requiring only a single reboot, instead of two ? I'd still be interested in hearing Lennarts opinion on this. Matthias -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a): - Original Message - Well, what we would need is: 1. Ability to keep multiple versions (both ABI-compatible and ABI-incompatible) of a single application or library or service installed and running at the same time. Other distributions allow to install multiple version of same libraries AFAIK only when the ABI (soname) is different. We also need to allow for the case when the ABI stays the same but the internal implementation changes (e.g. changing a format of a resource file that is used by the library, making old processes incompatible with the newly installed resource). That's what I mean - when something changes in the library - soname should change. It's quite broken to release same version of library with the same name when there is different internal implementation. It's something library package maintainer should take care of... There is also support for versioned symbols. 2. Ability to detect which processes depend on which versions of which components. We already managed to brought in systemd I can’t see how systemd helps. See the other discussions about Python/Ruby modules that leave no obvious trace of their dependency after being loaded into memory. It has similar complexity and maybe packages could be described just like services - so similar thing could be possibly reused here ? Anyway - I've not been thinking too deeply about this... 3. Ability to automatically restart such processes without loosing state (either completely transparently or with some user notification for GUIs). I'm not quite sure why we would need restart - simply delayed lazy release of unused packages would do the trick here - doing here state-full design is much more complex thing Because otherwise you end up with an old version of Firefox running for 60 days (or however long a laptop can run with suspends and no restarts; most people about never quit their browser), and that version of Firefox keeping an old version of a system-wide daemon running for 60 days as well.. Sure if user is able to run Firefox for 60 days (though my usually goes out of RAM in just a week or so, if it's not crashing earlier...) - then he is happy user. I guess something may show to user some nice gui dialog warning like - 'Hey there is a new version installed - so 'restart' your browser to get new cool feature' (FF normally already detects upgrades and suggest restart) I don't see nothing wrong with this case - it's per user and doesn't require upgrade - and if I've something important is running in my browser I could delay restart to the moment I don't care. And surprisingly even Systemd guru realized there is something broken with current filesystem layout - except solving it with Btrfs is not really a fix... The sad thing is that adding more workarounds like namespaces and the like really might be easier than agreeing on making a real change and getting it done :( But we will live with the costs forever. Look at NixOS - there are no namespace or btrfs requirements Zdenek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 21 Alpha Release Candidate 1 (RC1) Available Now!
As per the Fedora 21 schedule [1], Fedora 21 Alpha Release Candidate 1 (RC1) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5940#comment:13 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Ideally, all Alpha priority test cases for each of these test pages [2] should pass in order to meet the Alpha Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5940 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-09-17 @ ** 16:00 UTC ** - F21 Blocker Review
# F21 Blocker Review meeting # Date: 2014-09-17 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Greeting testers! Tomorrow we've got another Blocker Review to do. As of today there are no proposed blockers and 6 proposed FEs for F21 Alpha. The full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist We'll be evaluating these bugs to see if they violate the Alpha Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. Product specific plans are still being solidified, but that should be sorted quickly. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- 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: Improving the offline updates user experience
- Original Message - > > Well, what we would need is: > > 1. Ability to keep multiple versions (both ABI-compatible and > > ABI-incompatible) of a single application or library or service installed > > and running at the same time. > > Other distributions allow to install multiple version of same libraries AFAIK only when the ABI (soname) is different. We also need to allow for the case when the ABI stays the same but the internal implementation changes (e.g. changing a format of a resource file that is used by the library, making old processes incompatible with the newly installed resource). > > 2. Ability to detect which processes depend on which versions of which > > components. > > We already managed to brought in systemd I can’t see how systemd helps. See the other discussions about Python/Ruby modules that leave no obvious trace of their dependency after being loaded into memory. > > 3. Ability to automatically restart such processes without loosing state > > (either completely transparently or with some user notification for GUIs). > > I'm not quite sure why we would need restart - simply delayed lazy release of > unused packages would do the trick here - doing here state-full design is much > more complex thing Because otherwise you end up with an old version of Firefox running for 60 days (or however long a laptop can run with suspends and no restarts; most people about never quit their browser), and that version of Firefox keeping an old version of a system-wide daemon running for 60 days as well.. > And surprisingly even Systemd guru realized there is something broken with > current filesystem layout - except solving it with Btrfs is not really a > fix... The sad thing is that adding more workarounds like namespaces and the like really might be easier than agreeing on making a real change and getting it done :( But we will live with the costs forever. Mirek -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 16:39 Miloslav Trmač napsal(a): - Original Message - Dne 16.9.2014 v 12:21 Richard Hughes napsal(a): On 16 September 2014 10:55, Zdenek Kabelac wrote: Just a thought - but wouldn't be better spend time to enlighten Gnome/Firefox developers how to write applications in a way the could be upgraded runtime So, it's not just the application, it's every application and D-Bus service the application uses. Even glibc opens files-as-resources at So it's time to fix D-Bus then as well! If something is broken - it will not get fixed by hiding broken design behind reboot&upgrade. Quite true. If you can't fix the Firefox (or some other broken tool) and you want to allow install of new version - then you need to allow i.e. parallel installs of such packages - it's that simple - I've been doing this more then 15 years ago at University - so really nothing new here... Well, what we would need is: 1. Ability to keep multiple versions (both ABI-compatible and ABI-incompatible) of a single application or library or service installed and running at the same time. Other distributions allow to install multiple version of same libraries - I've never understood the Fedora policy to recompile whole Fedora when a new version of library is released. This policy design is quite 'show-stopper' for anything like this... 2. Ability to detect which processes depend on which versions of which components. We already managed to brought in systemd 3. Ability to automatically restart such processes without loosing state (either completely transparently or with some user notification for GUIs). I'm not quite sure why we would need restart - simply delayed lazy release of unused packages would do the trick here - doing here state-full design is much more complex thing The primary use-case to target should be to allow reinstall user packages while they are in use. This has all been done before, and can be done again. (And it would make at least half of the userbase clamoring for containers what they need, without playing ugly complex nontransparent namespace games.) But let’s be clear about it, 1. means completely changing our filesystem layout, and 3. means changing our process model to go way beyond int main(...). It is technically possible, it is the right thing to do. Do we want to do it and can we do it? Fedora made not much useful /usr move thing - so maybe it's time to think and design something really useful. As mentioned there are OSes which do handle things much better... And surprisingly even Systemd guru realized there is something broken with current filesystem layout - except solving it with Btrfs is not really a fix... Has Fedora given up Unix ?? The Unix history is actually closer to “edit header files to match your hardware, then rebuild the kernel and userpace with (make world), and reboot“. Packaged applications with an ISV source and an update stream separate from the OS have certainly been built on top of Unix but have never been a major design focus. Arguably the whole point of a “Linux distribution” has been to get closer to the BSD-style single-kernel-and-userspace distribution updated always as a whole. My view rather is - Fedora is taking feature-by-feature away from my box. Zdenek -- 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: Improving the offline updates user experience
- Original Message - > Dne 16.9.2014 v 12:21 Richard Hughes napsal(a): > > On 16 September 2014 10:55, Zdenek Kabelac wrote: > >> Just a thought - but wouldn't be better spend time to enlighten > >> Gnome/Firefox developers how to write applications in a way the could be > >> upgraded runtime > > > > So, it's not just the application, it's every application and D-Bus > > service the application uses. Even glibc opens files-as-resources at > > So it's time to fix D-Bus then as well! > > If something is broken - it will not get fixed by hiding broken design behind > reboot&upgrade. Quite true. > If you can't fix the Firefox (or some other broken tool) and you want to allow > install of new version - then you need to allow i.e. parallel installs of such > packages - it's that simple - I've been doing this more then 15 years ago at > University - so really nothing new here... Well, what we would need is: 1. Ability to keep multiple versions (both ABI-compatible and ABI-incompatible) of a single application or library or service installed and running at the same time. 2. Ability to detect which processes depend on which versions of which components. 3. Ability to automatically restart such processes without loosing state (either completely transparently or with some user notification for GUIs). This has all been done before, and can be done again. (And it would make at least half of the userbase clamoring for containers what they need, without playing ugly complex nontransparent namespace games.) But let’s be clear about it, 1. means completely changing our filesystem layout, and 3. means changing our process model to go way beyond int main(...). It is technically possible, it is the right thing to do. Do we want to do it and can we do it? > This 'reboot' idea is just 'somehow' usable maybe for a single seat single > user desktop - but not anywhere else. > > Has Fedora given up Unix ?? The Unix history is actually closer to “edit header files to match your hardware, then rebuild the kernel and userpace with (make world), and reboot“. Packaged applications with an ISV source and an update stream separate from the OS have certainly been built on top of Unix but have never been a major design focus. Arguably the whole point of a “Linux distribution” has been to get closer to the BSD-style single-kernel-and-userspace distribution updated always as a whole. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes from Env-and-Stacks WG meeting (2014-09-16)
#fedora-meeting: Env and Stacks (2014-09-16) Meeting started by hhorak at 13:01:52 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-09-16/fedora-meeting.2014-09-16-13.01.log.html . Meeting summary --- * init process (hhorak, 13:02:53) * IDEA: developers of Koschei would like to see Koschei promoted and recommend as a good tool for all Fedora packagers (hhorak, 13:08:23) * running Koschei for all Fedora packages (promote and recommend it) (hhorak, 13:09:06) * LINK: http://koschei.cloud.fedoraproject.org/ (bkabrda, 13:09:16) * LINK: https://github.com/msimacek/koschei (bkabrda, 13:09:23) * Koschei only runs scratch builds if overall Koji load is below a certain level, but too many packages would mean they'll be rebuilt in very long intervals not to overload koji (hhorak, 13:12:15) * there are plans to create a dynamic web UI, where packagers would be able to add/remove packages themselves (hhorak, 13:15:52) * ACTION: everbody should find out more about koschei; if everyone likes it, we can vote on some sort of formal recommendation next time (hhorak, 13:17:44) * Language specific mirrors for Fedora Playground compliant packages (hhorak, 13:20:56) * the idea was a bit discussed on ML already: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-September/000507.html (hhorak, 13:20:56) * fully deployment in RPM for everything does not make sense in projects run one-and-only instance in the world (hhorak, 13:25:17) * LINK: http://doc.devpi.net/latest/ (ncoghlan, 13:28:28) * the idea is to be able to have a mirror of upstream repositories where we could do the initial Fedora Playground checks (hhorak, 13:33:34) * for python devpi seems to be the way to go with this (hhorak, 13:33:34) * we could seed the repos by flagging the packages that have already been accepted into Fedora, the incremental review model could look like language mirror -> Fedora Playground -> Fedora (hhorak, 13:33:34) * other languages may have their specifics and not so linux based upstreams (hhorak, 13:33:35) * un-bundling and similar maintaining work would be solved in the step 'playground -> Fedora' (hhorak, 13:38:25) * dependencies on some system libraries are complicated, could be partly solved by new format wheel and some tricks in devpi (hhorak, 13:49:31) * we should first create the devpi instance and start experimenting with different ways of using it; then when we figure out what/how we want to do, we can create a Fedora feature (hhorak, 13:49:32) * ACTION: bkabrda will request an instance in Fedora cloud to start playing around with devpi (hhorak, 13:50:08) * ACTION: ncoghlan will do a write-up after we experiment a bit with bkabrda's devpi instance (hhorak, 13:56:55) * reasons why developers would not use upstream repo directly and rather use Fedora's playground is because they might want the additional level of review that Fedora provides + they would get precompiled C-extension packages (hhorak, 14:04:34) * SCLs, building above them and their position in Fedora/EPEL (hhorak, 14:14:45) * ACTION: mmaslano will figure out how OpenShift is using SCL in their images (mmaslano, 14:26:37) * SCL packaging doesn't have to be mandatory if you use smart enough wrapper script for setting up environment (hhorak, 14:28:15) * tools to get the shebang line and spec file right for non-SCL python packages depending on SCL might not exist yet (hhorak, 14:28:15) * ACTION: hhorak will be chairman for the next meeting (hhorak, 14:32:45) Meeting ended at 14:32:45 UTC. Action Items * everbody should find out more about koschei; if everyone likes it, we can vote on some sort of formal recommendation next time * bkabrda will request an instance in Fedora cloud to start playing around with devpi * ncoghlan will do a write-up after we experiment a bit with bkabrda's devpi instance * mmaslano will figure out how OpenShift is using SCL in their images * hhorak will be chairman for the next meeting Action Items, by person --- * bkabrda * bkabrda will request an instance in Fedora cloud to start playing around with devpi * ncoghlan will do a write-up after we experiment a bit with bkabrda's devpi instance * hhorak * hhorak will be chairman for the next meeting * mmaslano * mmaslano will figure out how OpenShift is using SCL in their images * ncoghlan * ncoghlan will do a write-up after we experiment a bit with bkabrda's devpi instance * **UNASSIGNED** * everbody should find out more about koschei; if everyone likes it, we can vote on some sort of formal recommendation next time People Present (lines said) ---
Nginx + Php + WebApp
Hi, I have open a bug tracker about something which seems to be an interesting feature. Support (out of the box) for nginx + php-fpm + => https://bugzilla.redhat.com/show_bug.cgi?id=1142298 Feel free to subscribe / comment this tracker. Remi -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 12:21 Richard Hughes napsal(a): On 16 September 2014 10:55, Zdenek Kabelac wrote: Just a thought - but wouldn't be better spend time to enlighten Gnome/Firefox developers how to write applications in a way the could be upgraded runtime So, it's not just the application, it's every application and D-Bus service the application uses. Even glibc opens files-as-resources at So it's time to fix D-Bus then as well! If something is broken - it will not get fixed by hiding broken design behind reboot&upgrade. Guys it's 21st. century - it's so much broken idea to reboot 'machine' because I want to upgrade i.e. Firefox - that I simply don't have words for it. If you can't fix the Firefox (or some other broken tool) and you want to allow install of new version - then you need to allow i.e. parallel installs of such packages - it's that simple - I've been doing this more then 15 years ago at University - so really nothing new here... While the old-firefox is in use - new one could be installed in parallel and the old one is removed when the last user closes app - of course this has another problem with dependency hell - again solvable thing - look at i.e. NixOS. Just fix things in their core instead of hiding problem in pointless reboots. Have any of those 'inventors' of reboot&update ever managed multiuser system? This 'reboot' idea is just 'somehow' usable maybe for a single seat single user desktop - but not anywhere else. Has Fedora given up Unix ?? Zdenek -- 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: Trivial Python Review Swap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/2014 09:58 AM, Haïkel wrote: > 2014-09-16 15:24 GMT+02:00 Stephen Gallagher > : I need a review for a trivial Python > library: https://bugzilla.redhat.com/show_bug.cgi?id=1142276 > > I'll swap for a similarly straightforward review if you've got > one. > >> Hi Stephen, > >> I will gladly swap with this similarly trivial review (python >> library too): >> https://bugzilla.redhat.com/show_bug.cgi?id=1141097 > Works for me. Starting on it now. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQYRdIACgkQeiVVYja6o6P22wCfdnZZPUxTcWFtDEX1jkUyD879 T4MAnj/itbGHXfo/rHM64Ldd66DSExmB =xrZa -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: Trivial Python Review Swap
2014-09-16 15:24 GMT+02:00 Stephen Gallagher : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I need a review for a trivial Python library: > https://bugzilla.redhat.com/show_bug.cgi?id=1142276 > > I'll swap for a similarly straightforward review if you've got one. Hi Stephen, I will gladly swap with this similarly trivial review (python library too): https://bugzilla.redhat.com/show_bug.cgi?id=1141097 Regards, H. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iEYEARECAAYFAlQYOf8ACgkQeiVVYja6o6NEvwCfS0xX8JjvYGAQG2eEja6nBx4I > wUQAni8+tlywUwPHUD8hKocE0ViLhYLL > =uNYN > -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 -- 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: Improving the offline updates user experience
On 2014-09-16, Richard Hughes wrote: > The much bigger issues is if you're using a D-Bus service > like most applications seem to do (and most use quite a few system and > session, directly and indirectly) then you've also got to co-ordinate > and handle changing D-Bus API (which typically isn't versioned). Maybe it's time to version the API. Look at microkernel based systems which utilize messaging heavily and the API consumers (applications or another subsystems) have to be prepared for spurious API provider (server) restarts. A server can refuse a message any time (especially if it does not understand the request). Simple operations are usualy implemented as a sequence of requests and responses where initial request obtains a descriptor (a session, a handle) and subsequent requests passe it as context (a session) identifier. If the server is restarted in between, the context identifier becomes unrecognized and it's up to the application to deal with it. Just the fact that somebody calls functions over dbus instead of jumping into a shared library do not free them from maintaing API. -- 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
Trivial Python Review Swap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I need a review for a trivial Python library: https://bugzilla.redhat.com/show_bug.cgi?id=1142276 I'll swap for a similarly straightforward review if you've got one. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQYOf8ACgkQeiVVYja6o6NEvwCfS0xX8JjvYGAQG2eEja6nBx4I wUQAni8+tlywUwPHUD8hKocE0ViLhYLL =uNYN -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: Improving the offline updates user experience
On 16 September 2014 13:29, Przemek Klosowski wrote: > OK, but this is means that we painted ourselves in the corner---something is > wrong if my Android phone, which I don't have to reboot for updates, has > higher uptime than my computer. Right, we certainly have. By not having an OS / app layering policy we've basically lumped everything into the OS layer. We're now as good as Android, when you upgrade releases that you basically do an offline update like we do in GNOME. The only way to do application online updating (IMO) is to solve four things: * Defining an OS platform * Not breaking platform API * Sandboxing * Per-user applications Richard -- 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: Improving the offline updates user experience
On Tue, Sep 16, 2014 at 8:29 AM, Przemek Klosowski wrote: > On 09/16/2014 06:33 AM, Richard Hughes wrote: > > I've triaged many bugs to do with online and offline update failures, and > if we're going to say that we actually care about the users data, it becomes > increasingly hard to defend the "old" way of doing it. I'm sure I could find > numerous bugs numbers where doing an online update made the session/terminal > crash which of course leaves you with duplicate packages on your system > which may or may not be fixable. Richard > > OK, but this is means that we painted ourselves in the corner---something is > wrong if my Android phone, which I don't have to reboot for updates, has > higher uptime than my computer. You don't have to restart your phone for app updates, but the app itself is restarted. For Android updates, it does require you to reboot the phone. Android updates happen rather infrequently. Your analogy is slightly flawed. > We are in a bind: on one hand, the best security practice is to upgrade > daily to avoid emerging vulnerabilities; on the other hand daily reboots > aren't really a nutritious alternative. Something has to give---which one > do we do: > > - create a separate daily security upgrade stream, curated to not require > reboots if at all possible This has been suggested before and it isn't a terrible idea. It requires people to work on it though. > - follow Microsoft and do a fixed 'patch Tuesday' schedule instead of ASAP > updates There have been suggestions around having "levels" of updates. A firehose level, which is the equivalent of today, and then a batched level, etc. Also needs people to work on it. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rpath/runpath in binaries
Hi, I missed the memo about it not being a fatal error now (rpmlint still tells it is an error), but just in case, before attempting to enforce it a package review, I checked what I have right now in my rawhide box... $ for f in /usr/bin/*; do file $f | grep -q ELF && chrpath -l $f | grep -v "no rpath or runpath tag found"; done /usr/bin/afm2pl: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/afm2tfm: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/aleph: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/apper: RUNPATH=/usr/lib64/apper /usr/bin/applygeo: RPATH=/usr/lib64 /usr/bin/bibtex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/bibtex8: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/bibtexu: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/catman: RPATH=/usr/lib64/man-db /usr/bin/certtool: RPATH=/usr/lib64 /usr/bin/chktex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/crywrap: RPATH=/usr/lib64 /usr/bin/ctangle: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/ctie: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/cweave: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/danetool: RPATH=/usr/lib64 /usr/bin/dbus-binding-tool: RPATH=/usr/lib64 /usr/bin/dee-tool: RPATH=/usr/lib64 /usr/bin/detex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dia: RPATH=/usr/lib64/dia /usr/bin/disdvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dt2dv: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dumpiso: RPATH=/usr/lib64 /usr/bin/dv2dt: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvi2tty: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvibook: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dviconcat: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvicopy: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvilj: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvilj2p: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvilj4: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvilj4l: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvipdfmx: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvipng: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvipos: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvips: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dviselect: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvisvgm: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvitodvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/dvitype: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/enca: RPATH=/usr/lib64 /usr/bin/eptex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/euptex: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/eventlogadm: RPATH=/usr/lib64/samba /usr/bin/fribidi: RPATH=/usr/lib64 /usr/bin/gegl: RPATH=/usr/lib64 /usr/bin/geotifcp: RPATH=/usr/lib64 /usr/bin/gftodvi: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/gftopk: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/gftype: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/ggobi: RPATH=/usr/lib64 `/usr/bin/gio-querymodules-32' probably isn't a 64-bit LSB-first ELF file. elf_open: Exec format error /usr/bin/gnutls-cli: RPATH=/usr/lib64 /usr/bin/gnutls-cli-debug: RPATH=/usr/lib64 /usr/bin/gnutls-serv: RPATH=/usr/lib64 /usr/bin/gsftopk: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/gvpack: RPATH=/usr/lib64/graphviz /usr/bin/hbf2gf: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/htdb_dump: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htdb_load: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htdb_stat: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htdig: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htdump: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htfuzzy: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htload: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htmerge: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htnotify: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htpurge: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htsearch: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/htstat: RPATH=/usr/lib64/htdig:/usr/lib64/htdig_db /usr/bin/julia-debug: RUNPATH=$ORIGIN/../lib64/julia:$ORIGIN/../lib64 /usr/bin/kpsewhich: RPATH=/builddir/build/BUILD/texlive-2014/source/inst/lib /usr/bin/ld.bfd: RPATH=/usr/lib64 /usr/bin/lexgrog: RPATH=/usr/lib64/man-db /usr/bin/listgeo: RPATH=/usr/lib64 /usr/bin/luatex: RPATH=/builddir/build/BUILD/texlive-2014/sou
rubygem-uuidtools license revised from MIT to ASL 2.0
Dear all, I have updated rubygem-uuidtools from version 2.1.3 to version 2.1.5 and noticed the license change from MIT to ASL 2.0. Regards, Vít -- 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: Improving the offline updates user experience
On 09/16/2014 06:33 AM, Richard Hughes wrote: I've triaged many bugs to do with online and offline update failures, and if we're going to say that we actually care about the users data, it becomes increasingly hard to defend the "old" way of doing it. I'm sure I could find numerous bugs numbers where doing an online update made the session/terminal crash which of course leaves you with duplicate packages on your system which may or may not be fixable. Richard OK, but this is means that we painted ourselves in the corner---something is wrong if my Android phone, which I don't have to reboot for updates, has higher uptime than my computer. We are in a bind: on one hand, the best security practice is to upgrade daily to avoid emerging vulnerabilities; on the other hand daily reboots aren't really a nutritious alternative. Something has to give---which one do we do: - create a separate daily security upgrade stream, curated to not require reboots if at all possible - follow Microsoft and do a fixed 'patch Tuesday' schedule instead of ASAP updates - rewrite Linux or at least Gnome/DBus for safe updates :) -- 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: F22 Self Contained Change: BIND version 9.10
On 09/16/2014 01:34 PM, Jaroslav Reznik wrote: > = Proposed Self Contained Change: BIND version 9.10 = > https://fedoraproject.org/wiki/Changes/BIND_9.10 > > Change owner(s): Tomas Hozza > > BIND (Berkeley Internet Name Domain) version 9.10 is the latest stable major > update of the widely used DNS server. Besides new features, some settings > defaults have changed since the previous major version (9.9). > > == Detailed Description == > > FULL BIND 9.10 RELEASE NOTES [1] > > === New features === > * New zone file format, "map", stores zone data in a format that can be > mapped > directly into memory, allowing significantly faster zone loading. > * New tool "delv" (domain entity lookup and validation) with dig-like > semantics for looking up DNS data and performing internal DNSSEC validation > has been added. > * New "prefetch" option improving the recursive resolver performance has been > added. > * Improved EDNS processing allowing better resolver performance. > * Substantial improvements have been made in response-policy zone (RPZ) > performance. > * ACLs can now be specified based on geographic location using the MaxMind > GeoIP databases. > * The statistics channel can now provide data in JSON format as well as XML. > * The new "in-view" zone option allows zone data to be shared between views, > so that multiple views can serve the same zones authoritatively without > storing multiple copies in memory. > * Native PKCS#11 API has been added. This allows BIND 9 cryptography > functions > to use the PKCS#11 API natively, so that BIND can drive a cryptographic > hardware service module (HSM) directly instead of using a modified OpenSSL as > an intermediary (Native PKCS#11 is known to work with the Thales nShield HSM > and with SoftHSM version 2 from the Open DNSSEC project.). > * New tool "named-rrchecker" can be used to check the syntax of individual > resource records, and optionally to convert them to the format used for > unknown record types. > * New tool "dnssec-importkey" allows "offline" DNSSEC keys (i.e., keys whose > private data is not stored on the system on which named is running) to be > published or deleted on schedule using automatic DNSKEY management. > * Network interfaces are re-scanned automatically whenever they change. Use > "automatic-interface-scan no;" to disable this feature. > ** Added "rndc scan" to trigger an interface scan manually. > * New "max-zone-ttl" option enforces maximum TTLs for zones. If loading a > zone > containing a higher TTL, the load fails. DDNS updates with higher TTLs are > accepted but the TTL is truncated. > * Multiple DLZ databases can now be configured, and are searched in order to > find one that can answer an incoming query. > * "named-checkzone" and "named-compilezone" can now read journal files. > > === Feature changes === > * The version 3 XML schema for the statistics channel, including new > statistics and a flattened XML tree for faster parsing, is no longer > optional. > The version 2 XML schema is now deprecated. > * "named" now listens on IPv6 as well as IPv4 interfaces by default. > * The internal and export versions of the BIND libraries (libisc, libdns, > etc) > have been unified so that external library clients can use the same libraries > as BIND itself. > * The default setting for the -U option (setting the number of UDP listeners > per interface) has been adjusted to improve performance. > * Adaptive mutex locks are now used on systems which support them. > * "rndc flushtree" now flushes matching records from the address database and > bad cache as well as the DNS cache. (Previously only the DNS cache was > flushed.) > * The isc_bitstring API is no longer used and has been removed from the > libisc > library. > * The timestamps included in RRSIG records can now be read as integers > indicating the number of seconds since the UNIX epoch, in addition to being > read as formatted dates in MMDDHHMMSS format. > > == Scope == > * Proposal owners: Rebase the package to the latest 9.10 minor version and > resolve possible packaging issues. (Also rebuild all currently existing > dependent packages listed below) > > * Other developers: Rebuild dependent packages (dhcp, dnsperf, bind-dyndb- > ldap) > ** Owner of this feature is co-maintainer of all dependent packages. He will > do the necessary rebuilds himself in cooperation with dependent packages > owners. > > * Release engineering: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > > [1] http://ftp.isc.org/isc/bind9/9.10.0-P2/RELEASE-NOTES-BIND-9.10.0-P2.txt > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce > You can try BIND 9.10.1b2 using COPR repo: http://copr-fe.cloud.fedoraproject.org/coprs/thozza/bind-9.10.1b2/ I'll update the COPR in the mean time
F22 Self Contained Change: BIND version 9.10
= Proposed Self Contained Change: BIND version 9.10 = https://fedoraproject.org/wiki/Changes/BIND_9.10 Change owner(s): Tomas Hozza BIND (Berkeley Internet Name Domain) version 9.10 is the latest stable major update of the widely used DNS server. Besides new features, some settings defaults have changed since the previous major version (9.9). == Detailed Description == FULL BIND 9.10 RELEASE NOTES [1] === New features === * New zone file format, "map", stores zone data in a format that can be mapped directly into memory, allowing significantly faster zone loading. * New tool "delv" (domain entity lookup and validation) with dig-like semantics for looking up DNS data and performing internal DNSSEC validation has been added. * New "prefetch" option improving the recursive resolver performance has been added. * Improved EDNS processing allowing better resolver performance. * Substantial improvements have been made in response-policy zone (RPZ) performance. * ACLs can now be specified based on geographic location using the MaxMind GeoIP databases. * The statistics channel can now provide data in JSON format as well as XML. * The new "in-view" zone option allows zone data to be shared between views, so that multiple views can serve the same zones authoritatively without storing multiple copies in memory. * Native PKCS#11 API has been added. This allows BIND 9 cryptography functions to use the PKCS#11 API natively, so that BIND can drive a cryptographic hardware service module (HSM) directly instead of using a modified OpenSSL as an intermediary (Native PKCS#11 is known to work with the Thales nShield HSM and with SoftHSM version 2 from the Open DNSSEC project.). * New tool "named-rrchecker" can be used to check the syntax of individual resource records, and optionally to convert them to the format used for unknown record types. * New tool "dnssec-importkey" allows "offline" DNSSEC keys (i.e., keys whose private data is not stored on the system on which named is running) to be published or deleted on schedule using automatic DNSKEY management. * Network interfaces are re-scanned automatically whenever they change. Use "automatic-interface-scan no;" to disable this feature. ** Added "rndc scan" to trigger an interface scan manually. * New "max-zone-ttl" option enforces maximum TTLs for zones. If loading a zone containing a higher TTL, the load fails. DDNS updates with higher TTLs are accepted but the TTL is truncated. * Multiple DLZ databases can now be configured, and are searched in order to find one that can answer an incoming query. * "named-checkzone" and "named-compilezone" can now read journal files. === Feature changes === * The version 3 XML schema for the statistics channel, including new statistics and a flattened XML tree for faster parsing, is no longer optional. The version 2 XML schema is now deprecated. * "named" now listens on IPv6 as well as IPv4 interfaces by default. * The internal and export versions of the BIND libraries (libisc, libdns, etc) have been unified so that external library clients can use the same libraries as BIND itself. * The default setting for the -U option (setting the number of UDP listeners per interface) has been adjusted to improve performance. * Adaptive mutex locks are now used on systems which support them. * "rndc flushtree" now flushes matching records from the address database and bad cache as well as the DNS cache. (Previously only the DNS cache was flushed.) * The isc_bitstring API is no longer used and has been removed from the libisc library. * The timestamps included in RRSIG records can now be read as integers indicating the number of seconds since the UNIX epoch, in addition to being read as formatted dates in MMDDHHMMSS format. == Scope == * Proposal owners: Rebase the package to the latest 9.10 minor version and resolve possible packaging issues. (Also rebuild all currently existing dependent packages listed below) * Other developers: Rebuild dependent packages (dhcp, dnsperf, bind-dyndb- ldap) ** Owner of this feature is co-maintainer of all dependent packages. He will do the necessary rebuilds himself in cooperation with dependent packages owners. * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://ftp.isc.org/isc/bind9/9.10.0-P2/RELEASE-NOTES-BIND-9.10.0-P2.txt ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20140916 changes
Compose started at Tue Sep 16 07:15:02 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [couchdb] couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-10.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-2.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-4.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-2.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.8.git05ae1bb.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-3.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-5.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-7.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.7.git80db168.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [hibernate-search] hibe
[PkgDB] psabata:perl-Pod-Readme watchcommits set to Approved
user: psabata set for dfateyev acl: watchcommits of package: perl-Pod-Readme from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Pod-Readme -- 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
[PkgDB] psabata:perl-Pod-Readme watchbugzilla set to Approved
user: psabata set for dfateyev acl: watchbugzilla of package: perl-Pod-Readme from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Pod-Readme -- 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
rawhide report: 20140916 changes
Broken deps for i386 -- [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [bustle] bustle-0.4.7-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [cp2k] cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc22.i686 requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [debhelper] debhelper-9.20140613-2.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [elk] elk-openmpi-2.3.22-7.fc21.i686 requires libmpi_usempi.so.1 [elpa] elpa-openmpi-2013.11-4.008.fc21.i686 requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [freefem++] freefem++-3.30-5.fc22.i686 requires libcholmod.so.2 freefem++-mpich-3.30-5.fc22.i686 requires libcholmod.so.2 freefem++-openmpi-3.30-5.fc22.i686 requires libcholmod.so.2 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hgettext] ghc-hgettext-0.1.30-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so ghc-hgettext-0.1.30-3.fc22.i686 requires ghc(setlocale-1.0.0-fa663a40688afbabfd6017337b0554c3) ghc-hgettext-devel-0.1.30-3.fc22.i686 requires libHSsetlocale-1.0.0-ghc7.6.3.so ghc-hgettext-devel-0.1.30-3.fc22.i686 requires ghc-devel(setlocale-1.0.0-fa663a40688afbabfd6017337b0554c3) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.
Re: Improving the offline updates user experience
On 16 September 2014 11:26, Reindl Harald wrote: > and the other side of the story are some hundret dist-upgrades i > made in the past years with YUM (in a screen session for safety) > while just continue to browse the web and read / answer email So you're saying my technical analysis is incorrect because it happens to work for you? I've triaged many bugs to do with online and offline update failures, and if we're going to say that we actually care about the users data, it becomes increasingly hard to defend the "old" way of doing it. I'm sure I could find numerous bugs numbers where doing an online update made the session/terminal crash which of course leaves you with duplicate packages on your system which may or may not be fixable. Richard -- 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: Improving the offline updates user experience
Am 16.09.2014 um 12:21 schrieb Richard Hughes: > On 16 September 2014 10:55, Zdenek Kabelac wrote: >> Just a thought - but wouldn't be better spend time to enlighten >> Gnome/Firefox developers how to write applications in a way the could be >> upgraded runtime > > So, it's not just the application, it's every application and D-Bus > service the application uses. Even glibc opens files-as-resources at > runtime. The much bigger issues is if you're using a D-Bus service > like most applications seem to do (and most use quite a few system and > session, directly and indirectly) then you've also got to co-ordinate > and handle changing D-Bus API (which typically isn't versioned). This > means you've got to restart the system DBus service at the right time > in the on-line update, which means co-ordinating with any other open > sessions on the system. Most desktop apps don't just sit in islands on > their own. It's probably okay to live-update powertop on a single-user > system when it's not being run, but anything much more integrated than > that just isn't going to work very well and the other side of the story are some hundret dist-upgrades i made in the past years with YUM (in a screen session for safety) while just continue to browse the web and read / answer email signature.asc Description: OpenPGP digital 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: Improving the offline updates user experience
On 16 September 2014 10:55, Zdenek Kabelac wrote: > Just a thought - but wouldn't be better spend time to enlighten > Gnome/Firefox developers how to write applications in a way the could be > upgraded runtime So, it's not just the application, it's every application and D-Bus service the application uses. Even glibc opens files-as-resources at runtime. The much bigger issues is if you're using a D-Bus service like most applications seem to do (and most use quite a few system and session, directly and indirectly) then you've also got to co-ordinate and handle changing D-Bus API (which typically isn't versioned). This means you've got to restart the system DBus service at the right time in the on-line update, which means co-ordinating with any other open sessions on the system. Most desktop apps don't just sit in islands on their own. It's probably okay to live-update powertop on a single-user system when it's not being run, but anything much more integrated than that just isn't going to work very well. Richard -- 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: Improving the offline updates user experience
Dne 16.9.2014 v 11:48 Richard Hughes napsal(a): On 16 September 2014 10:36, Roberto Ragusa wrote: If applications would just use libraries correctly, the kernel would be able to let parts of deleted files be available for lazy loading. Sure, as long as all[1] the resources were either open()d when the user started the program, or linked in as resources into the library itself then it works fine. You can certainly design an application that does this correctly, it's just that very few do. A lot of GNOME apps compile in resources into the binary itself, using GResource, and this very much helps live updating. Just a thought - but wouldn't be better spend time to enlighten Gnome/Firefox developers how to write applications in a way the could be upgraded runtime, instead of forcing users to reboot machines which seems seriously ridiculous. And if we can't fix Gnome - then let's have there daemon/systemd service waiting in background till the 'problematic' app is still running - and run upgrade when the app is finally closed (eventually kindly ask user to close the app in case of some CVE) Zdenek -- 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: Improving the offline updates user experience
On 16 September 2014 10:36, Roberto Ragusa wrote: > If applications would just use libraries correctly, the kernel > would be able to let parts of deleted files be available for lazy > loading. Sure, as long as all[1] the resources were either open()d when the user started the program, or linked in as resources into the library itself then it works fine. You can certainly design an application that does this correctly, it's just that very few do. A lot of GNOME apps compile in resources into the binary itself, using GResource, and this very much helps live updating. Richard [1] Including help files, all clipart, all icons, all .ui files, and all the .css for all the dialogs. -- 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: Improving the offline updates user experience
On 09/12/2014 05:47 PM, Richard Hughes wrote: > That's just not safe. Have you ever had firefox open and done a > firefox update? Widgets start disappearing, redraws start having weird > artifects and then after a little while it just crashes. Other > applications like LibreOffice behave the same. Anyone that says things > like "the old version of the library stays in memory" obviously hasn't > actually done much real-world GUI programming in the last decade, or > runs any kind of secure desktop system. You are basically saying that "modern" software is just breaking things which were perfectly solved decades ago. If applications would just use libraries correctly, the kernel would be able to let parts of deleted files be available for lazy loading. -- Roberto Ragusamail at robertoragusa.it -- 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: Improving the offline updates user experience
Am 16.09.2014 um 10:50 schrieb Richard Hughes: > On 15 September 2014 13:06, Miroslav Suchý wrote: >> But *I* do not want to reboot after each upgrade. Those crashes will be >> 0.1% of all crashes on my workstation > > I think you might change your mind when it's you're the one that has > to triage those ABRT-reported bugs. Also, consoling users with lost > data gets tiring really quick well, users which want full control typically disable or even uninstall ABRT - as long offline updates are not becoming mandatory all is fine [harry@srv-rhsoft:~]$ rpm -qa | grep -i ABRT [harry@srv-rhsoft:~]$ signature.asc Description: OpenPGP digital 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: Improving the offline updates user experience
On 15 September 2014 13:06, Miroslav Suchý wrote: > But *I* do not want to reboot after each upgrade. Those crashes will be > 0.1% of all crashes on my workstation I think you might change your mind when it's you're the one that has to triage those ABRT-reported bugs. Also, consoling users with lost data gets tiring really quick. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
