On Fri, 2012-06-22 at 22:37 -0700, Adam Williamson wrote:
> On Fri, 2012-06-22 at 14:22 +0100, Richard Hughes wrote:
> > On 22 June 2012 13:56, Simo Sorce wrote:
> > > How do we make sure that if package manager goes crazy the user still
> > > have a way to reboot his system that is not 'press pow
On Fri, 2012-06-22 at 14:22 +0100, Richard Hughes wrote:
> On 22 June 2012 13:56, Simo Sorce wrote:
> > How do we make sure that if package manager goes crazy the user still
> > have a way to reboot his system that is not 'press power button for 5
> > seconds' ?
>
> Just make sure the package man
On Fri, Jun 22, 2012 at 14:22:31 +0100,
Richard Hughes wrote:
On 22 June 2012 13:56, Simo Sorce wrote:
How do we make sure that if package manager goes crazy the user still
have a way to reboot his system that is not 'press power button for 5
seconds' ?
Just make sure the package manager d
On 22 June 2012 15:27, Lennart Poettering wrote:
> a) make a snapshot of the fs, and make it where all changes from now on
> are written to, but do not make it the default snapshot to be mounted
> for the next boot.
> b) make the updates
> c) if the update succeeded make the previously created sna
On Fri, 22.06.12 08:56, Simo Sorce (s...@redhat.com) wrote:
> On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote:
> > On 22 June 2012 12:40, Michal Hlavinka wrote:
> > > Well, there is difference between inhibited reboot and "are you really
> > > sure
> > > you want to reboot and break your
On 22 June 2012 13:56, Simo Sorce wrote:
> How do we make sure that if package manager goes crazy the user still
> have a way to reboot his system that is not 'press power button for 5
> seconds' ?
Just make sure the package manager doesn't go crazy. It's just doing a
simple rpm transaction after
Le Ven 22 juin 2012 13:40, Michal Hlavinka a écrit :
> On 06/22/2012 01:16 PM, Ralf Ertzinger wrote:
>> Hi.
>>
>> On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote:
>>
>>> And instead of making the system adapt to system problems (inhibit
>>> reboot during updates) we're making the user ad
On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote:
> On 22 June 2012 12:40, Michal Hlavinka wrote:
> > Well, there is difference between inhibited reboot and "are you really sure
> > you want to reboot and break your system" questions.
>
> Is that a joke? [Click here to break your system] i
On 22 June 2012 12:40, Michal Hlavinka wrote:
> Well, there is difference between inhibited reboot and "are you really sure
> you want to reboot and break your system" questions.
Is that a joke? [Click here to break your system] is never a good idea.
> Anyway, what would happen when user press p
On 06/22/2012 01:16 PM, Ralf Ertzinger wrote:
Hi.
On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote:
And instead of making the system adapt to system problems (inhibit
reboot during updates) we're making the user adapt to system problems
(add forced reboots were they were none before??
Hi.
On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote:
> And instead of making the system adapt to system problems (inhibit
> reboot during updates) we're making the user adapt to system problems
> (add forced reboots were they were none before??)
Inhibiting reboots? I cannot wait to see
Le Mar 19 juin 2012 06:45, Adam Williamson a écrit :
> One trigger for the current proposal was the discovery, quite late in
> F17 cycle, that if you reboot while PK is automatically installing
> security updates, you can entirely screw your system.
And instead of making the system adapt to syste
On 20 June 2012 12:51, Stijn Hoop wrote:
> Good to know, thanks -- although I wonder, in what capacity is this
> supported then?
Well, I've got no idea if it works at all, let alone if it works well ;)
> Would you / others be willing to deal with both update
> timings in this Feature?
It's not
On Wed, 20 Jun 2012 10:22:22 +0100
Richard Hughes wrote:
> On 20 June 2012 08:08, Stijn Hoop wrote:
> > I agree that mind reading computers may not be the final answer...
>
> Well, switching to system-update.service from a running desktop should
> probably kill off everything and start the offl
On 20 June 2012 08:08, Stijn Hoop wrote:
> I agree that mind reading computers may not be the final answer...
Well, switching to system-update.service from a running desktop should
probably kill off everything and start the offline update, so that
would be possible with the new scheme too.
Richa
Hi,
On Wed, 20 Jun 2012 02:22:26 + (UTC)
Ben Boeckel wrote:
> On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote:
> > I wonder if it would be possible to do it on shutdown instead of
> > during start up? I usually do not care if shutdown takes ten
> > seconds or five minutes, but whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote:
> I wonder if it would be possible to do it on shutdown instead of during
> start up? I usually do not care if shutdown takes ten seconds or five
> minutes, but when I start my computer I
On Tue, Jun 19, 2012 at 9:49 AM, Reindl Harald wrote:
>
>
> Am 19.06.2012 06:45, schrieb Adam Williamson:
>> On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote:
>>
>>> if things are working fine they do not need to be reinvented
>>> and developed forever - the problem i see the last years is
>
Am 19.06.2012 06:45, schrieb Adam Williamson:
> On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote:
>
>> if things are working fine they do not need to be reinvented
>> and developed forever - the problem i see the last years is
>> that way to often are wroking things replaced because people
On 06/18/2012 10:53 PM, Lennart Poettering wrote:
Well, even if Mozilla "fixed" that, such a solution wouldn't work for OS
updates, already due to privilege reasons. i.e. "pre-staging" changes as
root which are applied when a user does something simply cannot work if
you care about security or su
On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote:
> if things are working fine they do not need to be reinvented
> and developed forever - the problem i see the last years is
> that way to often are wroking things replaced because people
> can not life with the fact that things sometimes are
On Mon, 2012-06-18 at 12:47 +0100, Richard W.M. Jones wrote:
> On Mon, Jun 18, 2012 at 12:22:16PM +0100, Richard Hughes wrote:
> > On 18 June 2012 12:03, Benny Amorsen wrote:
> > > Why testing the daemons? Any daemon which cannot be restarted by
> > > systemctl restart foo.daemon is broken already
> I wonder if it would be possible to do it on shutdown instead of during
> start up?
Perhaps on shutdown, the default shutdown target gets replaced with the
"system update" target, so that this doesn't affect start up speed.
My issue with this is not the concept or the technical merits, but th
On Mon, Jun 18, 2012 at 4:53 PM, Lennart Poettering
wrote:
> Well, even if Mozilla "fixed" that, such a solution wouldn't work for OS
> updates, already due to privilege reasons. i.e. "pre-staging" changes as
> root which are applied when a user does something simply cannot work if
> you care abou
On Mon, 18.06.12 15:25, Gregory Maxwell (gmaxw...@gmail.com) wrote:
> On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating
> wrote:
> > On 06/18/2012 09:24 AM, Gregory Maxwell wrote:
> >> I run Mozilla's nightly builds and receive updates every day. They
> >> disrupt nothing because Mozilla has built
On Mon, 2012-06-18 at 19:03 +0200, Reindl Harald wrote:
> currently here are much more problems that firefox needs SIGKILL
> without any firefox update - so many of this 0.01% coming
> from users only updated extensions, confirmed restart and nothing
> happend
>
> i still can't count how often th
Am 18.06.2012 18:58, schrieb Richard Hughes:
> On 18 June 2012 17:36, Reindl Harald wrote:
>> and now you come the road and thell us firefox can not be
>> updated while it is running? strange that i apply FF updates
>> since years in my daily workload and after all are finished the
>> browser ge
On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating wrote:
> On 06/18/2012 09:24 AM, Gregory Maxwell wrote:
>> I run Mozilla's nightly builds and receive updates every day. They
>> disrupt nothing because Mozilla has built infrastructure to make that
>> possible. Firefox must be restarted for the updat
On 18 June 2012 17:36, Reindl Harald wrote:
> and now you come the road and thell us firefox can not be
> updated while it is running? strange that i apply FF updates
> since years in my daily workload and after all are finished the
> browser get's restarted or even at the next day if the update
>
Am 18.06.2012 18:09, schrieb Lennart Poettering:
> I mean, have you ever tried to upgrade firefox while running firefox? If
> you did, you know how awfully wrong that goes... [1]
>
> So, you have three problems: a) you cannot safely determine what to
> restart. b) you cannot restart many compone
On Mon, Jun 18, 2012 at 12:09 PM, Lennart Poettering
wrote:
> I mean, have you ever tried to upgrade firefox while running firefox? If
> you did, you know how awfully wrong that goes... [1]
I run Mozilla's nightly builds and receive updates every day. They
disrupt nothing because Mozilla has buil
On Sun, 17.06.12 10:53, Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote:
> > Hi.
> >
> > On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote
> >
> > > One of the most inportant advance of Linux over Windows is the
> > > fact, th
Am 18.06.2012 16:27, schrieb Jared K. Smith:
> On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald wrote:
>> if this is what you call "development" then YES we should
>> stop development now until we have ideas for real
>> improvements instead wasting time by making steps backward
>
> Language like
Am 18.06.2012 16:20, schrieb Richard Hughes:
> On 18 June 2012 00:38, Reindl Harald wrote:
>> the point is that it was perfectly possible in 2005 to make a fedora
>> dist-upgrade at friday night while http, netatalk or samba was
>> fully up and running until saturday sometimes at evening where
>
On 18 June 2012 15:32, Seth Vidal wrote:
> As dbus is required for various things like networkmanager - does this mean
> that if a server happens to be using nm for network setup that in order to
> apply a security patch to dbus, for example, that the server will require a
> reboot?
Well, if we t
On Mon, 18 Jun 2012, Richard Hughes wrote:
On 18 June 2012 00:38, Reindl Harald wrote:
the point is that it was perfectly possible in 2005 to make a fedora
dist-upgrade at friday night while http, netatalk or samba was
fully up and running until saturday sometimes at evening where
you reboo
On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald wrote:
> if this is what you call "development" then YES we should
> stop development now until we have ideas for real
> improvements instead wasting time by making steps backward
Language like this isn't helpful. Might I suggest that if you're
goin
On 18 June 2012 00:38, Reindl Harald wrote:
> the point is that it was perfectly possible in 2005 to make a fedora
> dist-upgrade at friday night while http, netatalk or samba was
> fully up and running until saturday sometimes at evening where
> you rebootet the machine and now EIGHT years later
On 06/18/2012 05:08 AM, Reindl Harald wrote:
> that is not the point because every admin is dong this all the time
>
> the point is that it was perfectly possible in 2005 to make a fedora
> dist-upgrade at friday night while http, netatalk or samba was
> fully up and running until saturday someti
Am 18.06.2012 01:09, schrieb drago01:
> On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen
> wrote:
>> Richard Hughes writes:
>>
>>> It takes me 4 seconds to POST, boot the kernel, get into
>>> system-update.service, and then reboot. Using a new rpm version,
>>> applying several dozen test update
On 06/18/2012 01:22 PM, Richard Hughes wrote:
On 18 June 2012 12:03, Benny Amorsen wrote:
Why testing the daemons? Any daemon which cannot be restarted by
systemctl restart foo.daemon is broken already.
Try booting a few VMs and then doing "systemctl restart
libvirtd.daemon" -- libvirtd resta
On 06/18/2012 01:09 AM, drago01 wrote:
On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen wrote:
Richard Hughes writes:
It takes me 4 seconds to POST, boot the kernel, get into
system-update.service, and then reboot. Using a new rpm version,
applying several dozen test updates takes another 20
On 06/17/2012 06:06 PM, Richard Hughes wrote:
On 17 June 2012 10:53, Richard W.M. Jones wrote:
So this is a problem that needs to be solved, but does it require a
reboot? Not really ... it's possible to list all processes using
zlib, convert that back into a list of packages, then instruct tho
On Mon, Jun 18, 2012 at 02:57:12PM +0300, Alek Paunov wrote:
> However, I never tried to update qemu-system with live VMs.
The update will work, but the VMs will still be running the old code.
You can actually solve that problem using VM migration: live migrate
the VM from the old qemu to the new
On 18.06.2012 14:22, Richard Hughes wrote:
On 18 June 2012 12:03, Benny Amorsen wrote:
Why testing the daemons? Any daemon which cannot be restarted by
systemctl restart foo.daemon is broken already.
Try booting a few VMs and then doing "systemctl restart
libvirtd.daemon" -- libvirtd restarts
On Mon, Jun 18, 2012 at 12:22:16PM +0100, Richard Hughes wrote:
> On 18 June 2012 12:03, Benny Amorsen wrote:
> > Why testing the daemons? Any daemon which cannot be restarted by
> > systemctl restart foo.daemon is broken already.
>
> Try booting a few VMs and then doing "systemctl restart
> libv
On 18 June 2012 12:03, Benny Amorsen wrote:
> Why testing the daemons? Any daemon which cannot be restarted by
> systemctl restart foo.daemon is broken already.
Try booting a few VMs and then doing "systemctl restart
libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the
clients are d
Richard Hughes writes:
> The async-message bus isn't the only problem. You *have* to restart a
> process before it will be running a new library version. That mean
> testing (and probably patching) every single application and daemon in
> our stack
Why testing the daemons? Any daemon which canno
On 18 June 2012 10:10, Richard W.M. Jones wrote:
> I believe there is or was an effort to replace dbus by something
> AMQP-based. However I can't find that right now.
The async-message bus isn't the only problem. You *have* to restart a
process before it will be running a new library version. Th
On 18 June 2012 10:50, Alek Paunov wrote:
> As I understand the proposal, the necessary workaround only affects the
> desktop instances and specifically Gnome ones - I am under the impression
> that my servers will continue to be updated by the normal way.
Exactly. This will not touch either RHN
On 18.06.2012 12:10, Richard W.M. Jones wrote:
On Mon, Jun 18, 2012 at 02:07:08PM +0530, Rahul Sundaram wrote:
On 06/18/2012 01:23 PM, Richard W.M. Jones wrote:
On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote:
On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
On 06/18/2012 02:40 PM, Richard W.M. Jones wrote:
> What we shouldn't do is break things further by making almost all
> updates require a reboot.
What do you want to do? Either we should fix all the possible issues
with restarting things on demand or we can accept this simpler solution
but preten
On Mon, Jun 18, 2012 at 02:07:08PM +0530, Rahul Sundaram wrote:
> On 06/18/2012 01:23 PM, Richard W.M. Jones wrote:
> > On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote:
> >> On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
> >>
> >>> You're asserting that dbus-dae
On 06/18/2012 01:23 PM, Richard W.M. Jones wrote:
> On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote:
>> On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
>>
>>> You're asserting that dbus-daemon etc cannot be restarted, but without
>>> saying why.
>>
>> Because des
On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote:
> On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
>
> > You're asserting that dbus-daemon etc cannot be restarted, but without
> > saying why.
>
> Because designing an asynchronous messaging bus that can be resta
On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote:
> You're asserting that dbus-daemon etc cannot be restarted, but without
> saying why.
Because designing an asynchronous messaging bus that can be restarted
without losing any messages is a difficult problem.
--
Matthew Garret
On 17 June 2012 11:49, Richard W.M. Jones wrote:
> On Sun, Jun 17, 2012 at 05:06:51PM +0100, Richard Hughes wrote:
>> On 17 June 2012 10:53, Richard W.M. Jones wrote:
>> > So this is a problem that needs to be solved, but does it require a
>> > reboot? Not really ... it's possible to list all pr
On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen wrote:
> Richard Hughes writes:
>
>> It takes me 4 seconds to POST, boot the kernel, get into
>> system-update.service, and then reboot. Using a new rpm version,
>> applying several dozen test updates takes another 20 seconds.
>
> Your hardware is t
Richard Hughes writes:
> It takes me 4 seconds to POST, boot the kernel, get into
> system-update.service, and then reboot. Using a new rpm version,
> applying several dozen test updates takes another 20 seconds.
Your hardware is too cheap. BIOS boot time is proportional to price when
the hardwa
On 17 June 2012 18:49, Richard W.M. Jones wrote:
> You're asserting that dbus-daemon etc cannot be restarted, but without
> saying why.
Okay, I'll say why. The core protocol was never designed to support
the dbus-daemon being restarted.
> The current design may make restarting some daemons
> di
On 17 June 2012 20:01, Jochen Schmitt wrote:
> In this case we may save outage time, because we don't have waste time
> for the BIOS POST, loading the bootloader and the kernel.
It takes me 4 seconds to POST, boot the kernel, get into
system-update.service, and then reboot. Using a new rpm versio
On Sun, Jun 17, 2012 at 09:01:11PM +0200, Jochen Schmitt wrote:
> On Sun, Jun 17, 2012 at 08:40:31PM +0200, drago01 wrote:
>
> > Yeah but those where examples not the sole reason why reboots are required.
> > It is not like if we didn't switch to systemd this problem wouldn't
> > exist. (which wa
On Sun, Jun 17, 2012 at 08:40:31PM +0200, drago01 wrote:
> Yeah but those where examples not the sole reason why reboots are required.
> It is not like if we didn't switch to systemd this problem wouldn't
> exist. (which was my point re "blaming").
Do we realy need a complete reboot of the syste
On Sun, Jun 17, 2012 at 8:19 PM, Gregory Maxwell wrote:
> On Sun, Jun 17, 2012 at 2:08 PM, drago01 wrote:
>> A new feature is being added nothing is getting removed so no there is
>> no regression.
>
> Thats newspeak if I ever saw any.
>
> Going from a system which generally doesn't prompt users
On Sun, Jun 17, 2012 at 2:08 PM, drago01 wrote:
> A new feature is being added nothing is getting removed so no there is
> no regression.
Thats newspeak if I ever saw any.
Going from a system which generally doesn't prompt users to reboot to
one that does is a regression.
> dbus is not optional
On Sun, Jun 17, 2012 at 8:08 PM, drago01 wrote:
> [...]
>> If slippery slope arguments are to be dismissed when they're used
>> against new features like systemd (or Wayland or whatever), then
>> Fedora really does need to draw a line in the sand and say no to bad
>> effects when they crop up.
>
>
On Sun, Jun 17, 2012 at 7:59 PM, Gregory Maxwell wrote:
> On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes wrote:
>
> And now some mere userspace daemons mean users will constantly need to
> reboot for upgrades?
No.
> Regressions against featuresets from the '70s and '80s are pretty unfortunate
On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes wrote:
> That's simply not possible. Some processes like dbus-daemon and
> gnome-session just cannot be restarted in this way. It's a complete
> fallacy to believe you can update core libraries on a modern Linux
> system without rebooting.
I upgrad
On Sun, Jun 17, 2012 at 05:06:51PM +0100, Richard Hughes wrote:
> On 17 June 2012 10:53, Richard W.M. Jones wrote:
> > So this is a problem that needs to be solved, but does it require a
> > reboot? Not really ... it's possible to list all processes using
> > zlib, convert that back into a list o
On 17/06/12 17:17, Richard Hughes wrote:
On 17 June 2012 11:00, Frank Murphy wrote:
Not much use to Xfce users.
Xfce doesn't have a native PackageKit client.
If you run the
gnome-settings-daemon updates plugin then it "just works".
Not since F16. iirc
I don't
think XFCE has the manpowe
On 17 June 2012 11:00, Frank Murphy wrote:
> Not much use to Xfce users.
Xfce doesn't have a native PackageKit client. If you run the
gnome-settings-daemon updates plugin then it "just works". I don't
think XFCE has the manpower to re-implement all the stuff needed for
the existing QA release tim
On 16 June 2012 14:04, Reindl Harald wrote:
> the next "have solution, searching problem" of Lennart?
> hopefully this leads not sooner or later in uncareful
> designs where it get more and more a must
No, if you mist blame somebody please send insults to me instead. I
asked Lennarts advice on ho
On 17 June 2012 10:53, Richard W.M. Jones wrote:
> So this is a problem that needs to be solved, but does it require a
> reboot? Not really ... it's possible to list all processes using
> zlib, convert that back into a list of packages, then instruct those
> packages to restart themselves. Job d
On 16/06/12 00:15, Kevin Fenzi wrote:
.fesco 868
#topic ticket 869 F18 Feature: Offline Updates using systemd and
packagekit -
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
.fesco 869
Not much use to Xfce users.
--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
de
On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote:
> Hi.
>
> On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote
>
> > One of the most inportant advance of Linux over Windows is the
> > fact, that there are only a few situations - like kernel updates -
> > which requires a reboo
On Sat, Jun 16, 2012 at 02:57:30PM +0200, Jochen Schmitt wrote:
> On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
>
> > #topic ticket 869 F18 Feature: Offline Updates using systemd and
> > packagekit -
> > https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
> > .fesco 869
>
On Sat, Jun 16, 2012 at 23:58:03 +0200,
Kevin Kofler wrote:
I really hope this is rejected. As already discussed in the relevant thread,
it would add bloat to the live images which would force us to drop useful
software from the KDE spin to fit the size target. And for what gain? We
Be awar
On Sat, Jun 16, 2012 at 11:58 PM, Kevin Kofler wrote:
> Kevin Fenzi wrote:
>> #topic ticket 868 F18 Feature: MiniDebugInfo -
>> https://fedoraproject.org/wiki/Features/MiniDebugInfo
>> .fesco 868
>
> I really hope this is rejected. As already discussed in the relevant thread,
> it would add bloat
Kevin Fenzi wrote:
> #topic ticket 868 F18 Feature: MiniDebugInfo -
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
> .fesco 868
I really hope this is rejected. As already discussed in the relevant thread,
it would add bloat to the live images which would force us to drop useful
software
On Sat, Jun 16, 2012 at 6:03 PM, Jochen Schmitt wrote:
> On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
>
>> #topic ticket 863 F18 Feature: Clojure -
>> https://fedoraproject.org/wiki/Features/Clojure
>> .fesco 863
>
> I think Leiminger may be a better name for this feature.
> the ai
Am 16.06.2012 15:06, schrieb Ralf Ertzinger:
> Hi.
>
> On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote
>
>> One of the most inportant advance of Linux over Windows is the
>> fact, that there are only a few situations - like kernel updates -
>> which requires a reboot of your system.
>
Am 16.06.2012 14:57, schrieb Jochen Schmitt:
> On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
>
>> #topic ticket 869 F18 Feature: Offline Updates using systemd and
>> packagekit -
>> https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
>>> Owner
>>> Name: Richard Hughes
Le samedi 16 juin 2012 à 14:57 +0200, Jochen Schmitt a écrit :
> On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
>
> > #topic ticket 869 F18 Feature: Offline Updates using systemd and
> > packagekit -
> > https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
> > .fesco 869
>
Hi.
On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote
> One of the most inportant advance of Linux over Windows is the
> fact, that there are only a few situations - like kernel updates -
> which requires a reboot of your system.
Linux has, in principle, the same problem as Windows, that
On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
> #topic ticket 869 F18 Feature: Offline Updates using systemd and
> packagekit -
> https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
> .fesco 869
The titel of this feature is a lttle misleading for me and the
description of
On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
> #topic ticket 863 F18 Feature: Clojure -
> https://fedoraproject.org/wiki/Features/Clojure
> .fesco 863
I think Leiminger may be a better name for this feature.
the aim of this feature is the introduction of Lieminger
as an IDE for c
Following is the list of topics that will be discussed in the FESCo
meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on
irc.freenode.net.
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic ticket 861 - Cleanup of maintainers with b
87 matches
Mail list logo
