Re: systemd questions
On Thu, 19 May 2011 14:59:57 +0200 Lennart Poettering wrote: > > I am sorry that reality bothers you so much, but it is the hard old real > > world ... > > See, I am so young, I still have the idealism that we can fix what is > broken. And you're going to go about it by removing something that people have been using for many years, replacing it with a vague promise of a better solution. Why are you so dead set against leaving what is there now so that people can continue to run their systems? What are they supposed to use? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 19 May 2011 14:16:30 +0100 Matthew Garrett wrote: > On Thu, May 19, 2011 at 08:05:46AM -0400, Simo Sorce wrote: > > > Some other, more data-centered UPSs that handle multiple machines use > > completely proprietary protocols over ethernet for example. > > I thought we were talking about a function that was called as the last > thing before the kernel was halted? How does that work in this case, > given that the network will already have been torn down? > It's called as late as possible before halting the system. Presumably if it depends on networking then it's called just before that gets shut down. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpmbuild issue?
Hi,
Would someone mind casting an eye over the attached spec file, please?
I am trying to build rpms against it on Fedora 15 beta but it errors
saying that "Installed (but unpackaged) file(s) found". However, all the
files listed are those contained in the %files sections for the
sub-packages. rpm-check appears to be ignoring them. Adding them to the
%files for the package removes them from the error list but this seems
wrong.
I can run the same spec file on fedora 14, with only rpm "build
requires" and "requires" versions being different, and it works fine.
Likewise, rpmlint seems to have no problems with it.
Any advice would be greatly appreciated.
Thanks
phantomjinx
--
"I know exactly who reads the papers ...
The Daily Mirror is read by people who think they run the country.
The Guardian is read by people who think they ought to run the country.
The Times is read by people who do actually run the country.
The Daily Mail is read by the wives of the people who run the country.
The Financial Times is read by the people who own the country.
The Morning Star is read by the people who think the country ought to be
run by another country.
The Daily Telegraph is read by the people who think it is."
Jim Hacker, Yes Minister
Name: gtkpod
Version:%{REVISION}
Release:1%{?dist}
Summary:Graphical song management program for Apple's iPod
Group: Applications/Multimedia
# The help documentation is under GFDL, the rest of the code is GPLv2+
License:GPLv2+ and GFDL
URL:http://www.gtkpod.org
Source0:
http://downloads.sourceforge.net/project/%{name}/%{name}/%{name}-%{version}/%{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: desktop-file-utils
BuildRequires: flex
BuildRequires: gettext
BuildRequires: gnome-vfs2-devel
BuildRequires: hal-devel
BuildRequires: intltool
BuildRequires: libgpod-devel >= 0.7.0
BuildRequires: perl(XML::Parser)
BuildRequires: anjuta-devel >= 2.91
BuildRequires: libgdl-devel >= 3.0.0
Requires: lib%{name}%{?_isa} = %{version}-%{release}
%description
gtkpod is a platform independent Graphical User Interface for Apple's
iPod using GTK2. It supports all current iPod models, including
the Mini, Photo, Shuffle, Nano, Video, Classic, Touch, and iPhone.
### libgtkpod rpm ###
%package -n lib%{name}
BuildRequires: curl-devel
BuildRequires: libid3tag-devel >= 0.15
# some of the scripts in the scripts directory use which
Requires: which
Requires: curl
Requires: libid3tag
Summary:Core Library for %{name}
Group: Applications/Multimedia
%description -n lib%{name}
This is the core library and plugins for gtkpod.
### libgtkpod devel rpm ###
%package -n lib%{name}-devel
Requires: %{name}%{?_isa} = %{version}-%{release}
Summary:Development files for the %{name} library
Group: Applications/Multimedia
%description -n lib%{name}-devel
This is the core library and plugins development files for gtkpod.
### coverweb plugin rpm ###
%package plugin-coverweb
Requires: webkitgtk3 >= 1.4
Requires: %{name}%{?_isa} = %{version}-%{release}
BuildRequires: webkitgtk3-devel >= 1.4
Summary:Cover web plugin for %{name}
Group: Applications/Multimedia
%description plugin-coverweb
This provides the cover web plugin for gtkpod, which provides a browser
window internally to gtkpod. This allows the dragging and dropping of
cover art directly from locations on the internet.
### media player rpm ###
%package plugin-media-player
Requires: gstreamer
Requires: gstreamer-plugins-ugly
Requires: %{name}%{?_isa} = %{version}-%{release}
BuildRequires: gstreamer-devel
BuildRequires: gstreamer-plugins-base-devel
Summary:Media player plugin for %{name}
Group: Applications/Multimedia
%description plugin-media-player
This provides a media player plugin for gtkpod, allowing audio and video
tracks to be previewed.
### filetype flac rpm ###
%package plugin-filetype-flac
Requires: flac
Requires: %{name}%{?_isa} = %{version}-%{release}
BuildRequires: flac-devel
Summary:The flac support plugin for %{name}
Group: Applications/Multimedia
%description plugin-filetype-flac
This provides support for flac files in gtkpod.
### filetype mp4 m4a rpm ###
%package plugin-filetype-mp4
Requires: faad2
Requires: libmp4v2 >= 1.5
Requires: %{name}%{?_isa} = %{version}-%{release}
BuildRequires: libmp4v2-devel >= 1.5
Summary:The m4a and mp4 support plugin for %{name}
Group: Applications/Multimedia
%description plugin-filetype-mp4
This provides support for m4a and mp4 files in gtkpod.
### filetype ogg rpm ###
%package plugin-filetype-ogg
Requires: %{name}%{?_isa} = %{version}-%{release}
BuildRequires: libvorbis-devel
Summary:The ogg vorbis audio support plugin for %{name}
Group:
Re: serial kernel console vs. systemd
On 05/19/2011 12:56 PM, Bill Nottingham wrote: > Josh Stone (jist...@redhat.com) said: >>> Anyway, if kmsg msgs are lost for you this probably happens inside of >>> ply or something related, but not systemd. >> >> Is "ply" part of (or short for) plymouth? I took rhgb out of my command >> line, and it's giving me a lot more on serial now. I don't remember >> that being necessary before, but I could be mistaken. But I still don't >> get anything on a hard crash. Any idea where else I could look to >> improve this? > > You can set the console loglevel differently with 'dmesg -n'. > Outside of that, if you get normal kernel messages but not messages on > hard crashes, that may just mean the kernel died before it got a chance to > log - in that case, there's not a lot you can do. Ok. I'm messing with experimental patches, so it might just be that bad. Thanks for the tip. Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serial kernel console vs. systemd
Josh Stone (jist...@redhat.com) said: > > Anyway, if kmsg msgs are lost for you this probably happens inside of > > ply or something related, but not systemd. > > Is "ply" part of (or short for) plymouth? I took rhgb out of my command > line, and it's giving me a lot more on serial now. I don't remember > that being necessary before, but I could be mistaken. But I still don't > get anything on a hard crash. Any idea where else I could look to > improve this? You can set the console loglevel differently with 'dmesg -n'. Outside of that, if you get normal kernel messages but not messages on hard crashes, that may just mean the kernel died before it got a chance to log - in that case, there's not a lot you can do. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
Simo Sorce (sso...@redhat.com) said: > > > What race are we talking about exactly ? > > > > Host requests power down from UPS in 30s. Host then continues shut > > down. If the host now ends up taking more time then expected for > > shutting down it might still be busy at the time of the power going > > away. It's a race between "UPS powering off" and "system finishing > > shutdown". It's a bet that your system is faster than 30s when > > unmounting the remaining file systems, syncing the MD/DM metadata to > > disk, syncing ATA and so on (i.e. all the stuff the kernel does when you > > invoke the reboot() syscall). > > You do realize that it is a race to get it done before the UPS runs out > of battery anyway ? > > It's not perfect, but sysadmins are capable of assessing how much time > each of their server needs to shut down and make the UPS wait long > enough (battery permitting of course). Well, now at least you're agreeing a bit on terms. In short: UPS hooks in shutdown are inherently racy as currently implemented. It doesn't mean they can't be done in systemd. It just means you're accepting that race as a fact of life (not claiming that they don't exist!). So, either: a) drop a binary in /lib/systemd/system-shutdown b) create a service that hooks into shutdown.target c) create a priority-99 SysV service In parallel, work on fixing the late shutdown process so we can fix the UPSes we do support to be less racy. Now, can we work on doing that, instead of shouting at each other? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serial kernel console vs. systemd
On 05/19/2011 11:57 AM, Lennart Poettering wrote: > systemd does not redirect kmsg. > > We actually are no longer reading console= from the kernel cmdline. We > now rely entirely on /sys/class/tty/console/active which gives us > similar information. And we use it only and exclusively to spawn a getty > on the kernel console after finishing. Ok, I was hand-waving because I wasn't sure. > Anyway, if kmsg msgs are lost for you this probably happens inside of > ply or something related, but not systemd. Is "ply" part of (or short for) plymouth? I took rhgb out of my command line, and it's giving me a lot more on serial now. I don't remember that being necessary before, but I could be mistaken. But I still don't get anything on a hard crash. Any idea where else I could look to improve this? Thanks, Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serial kernel console vs. systemd
On Thu, 19.05.11 10:52, Josh Stone (jist...@redhat.com) wrote: > Hi, > > I'm trying to debug some kernel crashes that I'm getting in a virtual > machine running rawhide. Adding "console=ttyS0,57600 console=tty0" to > the guest kernel used to work so "virsh console my-vm" would get me all > the kernel messages. Now in this systemd world, I get *some* messages > as it runs, but not everything that dmesg shows . And I don't get > anything when the kernel actually crashes. > > I've seen hints that systemd is reading the console=... parameters and > remapping them through userspace. That's not too helpful though when > the kernel crashes such that userspace never gets a chance to echo. Is > there a way I can get the kernel messages directly out on serial again? systemd does not redirect kmsg. We actually are no longer reading console= from the kernel cmdline. We now rely entirely on /sys/class/tty/console/active which gives us similar information. And we use it only and exclusively to spawn a getty on the kernel console after finishing. Anyway, if kmsg msgs are lost for you this probably happens inside of ply or something related, but not systemd. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 19.05.11 19:37, Tomasz Torcz (to...@pipebreaker.pl) wrote: > > > > This is not the case and never has been the case. The root disks > > > > traditionally could not be unmounted and hence MD/DM/MP and so on could > > > > not be disassembled before going down. > > > > > > > > Delaying shutdown by 30s is hack, not a fix for a race. > > > > > > What race are we talking about exactly ? > > > > Host requests power down from UPS in 30s. Host then continues shut > > down. If the host now ends up taking more time then expected for > > shutting down it might still be busy at the time of the power going > > away. It's a race between "UPS powering off" and "system finishing > > shutdown". It's a bet that your system is faster than 30s when > > unmounting the remaining file systems, syncing the MD/DM metadata to > > disk, syncing ATA and so on (i.e. all the stuff the kernel does when you > > invoke the reboot() syscall). > > reboot() do not seem to be wise choice. After 30s pass, computer > may be in the middle of boot are even be fully restarted. UPS terminating > power then would made mess it should prevent. reboot() is just the name of the syscall, that halts or reboots the machine or turns off power. The argument to that syscall specifies what to do. See reboot(2) for more information. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request/swap: gnupg-pkcs11-scd and spim
I have two packages that need to be reviewed. I'd be willing to review two others in exchange. -- Spec URL: http://www.flyn.org/SRPMS/spim.spec SRPM URL: http://www.flyn.org/SRPMS/spim-9.0.5-1.fc14.src.rpm spim is a self-contained simulator that runs MIPS32 programs. It reads and executes assembly language programs written for this processor. spim also provides a simple debugger and minimal set of operating system services. -- Spec URL: http://www.flyn.org/SRPMS/gnupg-pkcs11-scd.spec SRPM URL: http://www.flyn.org/SRPMS/gnupg-pkcs11-scd-0.7.2-1.fc15.src.rpm gnupg-pkcs11-scd is a drop-in replacement for the smart-card daemon (scd) shipped with the next-generation GnuPG (gnupg2). The daemon interfaces with smart-cards by using RSA Security Inc.'s PKCS#11 Cryptographic Token Interface. This package allows the use of US DoD smart cards (CAC) with GnuPG. -- Thanks, -- Mike :wq -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
serial kernel console vs. systemd
Hi, I'm trying to debug some kernel crashes that I'm getting in a virtual machine running rawhide. Adding "console=ttyS0,57600 console=tty0" to the guest kernel used to work so "virsh console my-vm" would get me all the kernel messages. Now in this systemd world, I get *some* messages as it runs, but not everything that dmesg shows . And I don't get anything when the kernel actually crashes. I've seen hints that systemd is reading the console=... parameters and remapping them through userspace. That's not too helpful though when the kernel crashes such that userspace never gets a chance to echo. Is there a way I can get the kernel messages directly out on serial again? Thanks, Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, May 18, 2011 at 11:04:33PM +0200, Lennart Poettering wrote: > On Mon, 16.05.11 14:30, Simo Sorce (sso...@redhat.com) wrote: > > > > > On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote: > > > On Mon, 16.05.11 14:32, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > > when ups recieves command for shutdown, it does not shutdown power > > > > immediately, but after 30 seconds. Given that this command should be > > > > executed > > > > after umount, synced disks,... when everything is ready for power off... > > > > 30 seconds proved to be enough time for this. > > > > > > This is not the case and never has been the case. The root disks > > > traditionally could not be unmounted and hence MD/DM/MP and so on could > > > not be disassembled before going down. > > > > > > Delaying shutdown by 30s is hack, not a fix for a race. > > > > What race are we talking about exactly ? > > Host requests power down from UPS in 30s. Host then continues shut > down. If the host now ends up taking more time then expected for > shutting down it might still be busy at the time of the power going > away. It's a race between "UPS powering off" and "system finishing > shutdown". It's a bet that your system is faster than 30s when > unmounting the remaining file systems, syncing the MD/DM metadata to > disk, syncing ATA and so on (i.e. all the stuff the kernel does when you > invoke the reboot() syscall). reboot() do not seem to be wise choice. After 30s pass, computer may be in the middle of boot are even be fully restarted. UPS terminating power then would made mess it should prevent. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Potential python-docutils license change
To get python-docutils building with python-3.2 I've upgraded the F15 and Rawhide versions to a snapshot of 0.8. Unfortunately, this version brings in new code that's licensed under the Apache license. This would change the license from "Public Domain and MIT and Python and GPLv2" to "Public Domain and MIT and Python and Apache and GPLv3+". The ramification that I can see from this would be that code that makes use of python-docutils (note, not invoking its functionality via the commandline tools it ships, just using it as a library) potentially won't be able to use the GPLv2 as a legal license anymore. Converting to GPLv3 (or GPLv3+) would be okay. I've opened a bug upstream to see if upstream would be willing to change the license on this subset of code so that we can continue to use it under the old license terms: https://sourceforge.net/tracker/index.php?func=detail&aid=3304675&group_id=38414&atid=422030 repoquery shows me the following: repoquery -q --whatrequires python-docutils python-docutils-0:0.7-3.fc14.noarch ikiwiki-0:3.20110430-1.fc14.noarch python-sphinx-0:1.0.7-1.fc14.noarch rst2pdf-0:0.16-1.fc14.noarch supybot-meetbot-0:0.1.4-5.fc14.noarch synopsis-0:0.12-4.fc14.x86_64 python-sphinx brings in spyder and supybot-meetbot brings in supybot. There's more packages out there that rely on docutils as an optional dep (I know of at least trac and moin) likely when they have the optional ability to use restructured text. I'm not sure whether this change would propagate through code that relies on docutils (so that, for instance, no supybot plugin could be GPLv2 or no trac plugin could be GPLv2) but that seems likely. I'll keep an eye on the bug and ping the author of the code directly to try and resolve this without relicensing but I felt this was problematic enough that I should warn people now of the potential impact to their packages. -Toshio pgpb5Ivx4PXRp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback needed : Fedora 15 Announcement
On Thu, 2011-05-19 at 08:39 -0700, Adam Williamson wrote: > On Thu, 2011-05-19 at 14:42 +0530, Rahul Sundaram wrote: > > Hi > > > > https://fedoraproject.org/wiki/Fedora_15_announcement > > > > Let me know if you have any comments. Feel free to edit the wiki > > directly if needed. > > I went through and fixed up a few things. actually it appears I didn't because of a fucking mediawiki edit conflict. we should *really* allow edit locking. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback needed : Fedora 15 Announcement
On Thu, 2011-05-19 at 14:42 +0530, Rahul Sundaram wrote: > Hi > > https://fedoraproject.org/wiki/Fedora_15_announcement > > Let me know if you have any comments. Feel free to edit the wiki > directly if needed. I went through and fixed up a few things. The only two that I suppose might be reverted or controversial: I changed LoveLock to Lovelock - I don't believe it's meant to be CamelCased. I changed 'elaborate' to 'powerful' when talking about systemd's dependency resolution mechanism. 'Elaborate' has ambiguous connotations, whereas those of 'powerful' are pretty straightforwardly positive. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager to reconnect silently
On Thu, 2011-05-19 at 22:10 +0900, Misha Shnurapet wrote: > 19.05.2011, 21:12, "n2xssvv.g02gfr12930" : > > On 19/05/11 09:55, Misha Shnurapet wrote: > > > >> Hi. > >> > >> I asked this question in NetworkManager mailing list, but everyone there > >> seems to be busy, so I decided to ask here. > >> > >> I run torrents on my notebook. On an electricity outage NetworkManager > >> starts asking for a new password, so when I'm not around and the light > >> goes back on (powering up the WLAN router), it just stands stalled with > >> the dialog open. > >> > >> Is there a way to tell NM not to ask for a new password ever? Because I > >> use a 63-symbol passphrase once set up on all the (two) machines so to > >> forget about it. > >> > >> Thanks! > >> > >> NetworkManager-gnome-0.8.4-1.fc14.x86_64 > >> > >> -- > >> Best regards, > >> Misha Shnurapet, Fedora Project Contributor > >> https://fedoraproject.org/wiki/Shnurapet > >> shnurapet AT fedoraproject.org, GPG: 00217306 > > > > As far as i can tell there is no easy, if any, solution that would not > > breach the security of your 63-symbol pass phrase. In my experience > > using knetworkmanager a password is required for each secure Wireless > > connection and for security these are stored in a secure encrypted > > area, (kwallet in my case), which needs just a single password for > > access. Hence a password is always required for wireless access to > > reconnect after a power out. > > This is not required for wired connections, so unless you can use some > > wired connection that restarts on power up to do the torrent downloads, > > you have little choice, without breaching the security provided by your > > pass phrase, but to accept the problem. > > From what I can gather you use long random pass phrases for any > > external available access which I heartily recommend. Nearly all > > security breaches are made because it's easy to guess pass phrases that > > relate to the person who created it. > > > > Regards > > > > cpp4ever > > Many thanks for your answer. However, the nm-applet in GNOME does *not* > require you to enter passphrase *each* time you establish the connection > you've *once configured*. And this behavior is absolutely correct. Also, > makes it feel like with a wired connection. > > What is not absolutely correct is that, when it can't get response from the > router, it starts thinking the passphrase has changed (which is wrong because > the router is simply off). As soon as power is back on, the AP is back online > with the same settings and the same passphrase (how mean of a manufacturer > would it be not to implement this). But the client device stands idle > waiting for a passphrase. > > I tested a couple of possible scenarios lately. NetworkManager reconnects > nicely on outages that last no more than ~1 minute. Beyond that, it starts > asking the question. We've wanted to make this behavior better for a long time, and it's still something on the todo list. So it'll happen. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 2011-05-19 at 14:16 +0100, Matthew Garrett wrote: > On Thu, May 19, 2011 at 08:05:46AM -0400, Simo Sorce wrote: > > > Some other, more data-centered UPSs that handle multiple machines use > > completely proprietary protocols over ethernet for example. > > I thought we were talking about a function that was called as the last > thing before the kernel was halted? How does that work in this case, > given that the network will already have been torn down? Good question, I don't remember details though. Perhaps for those models it doesn't really matter, they probably set a much larger delay (say 5 minutes), and then start the shutdown procedure and don't need anymore interaction with the machine. In that case nothing is needed on halt. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, May 19, 2011 at 08:05:46AM -0400, Simo Sorce wrote: > Some other, more data-centered UPSs that handle multiple machines use > completely proprietary protocols over ethernet for example. I thought we were talking about a function that was called as the last thing before the kernel was halted? How does that work in this case, given that the network will already have been torn down? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager to reconnect silently
19.05.2011, 21:12, "n2xssvv.g02gfr12930" : > On 19/05/11 09:55, Misha Shnurapet wrote: > >> Hi. >> >> I asked this question in NetworkManager mailing list, but everyone there >> seems to be busy, so I decided to ask here. >> >> I run torrents on my notebook. On an electricity outage NetworkManager >> starts asking for a new password, so when I'm not around and the light goes >> back on (powering up the WLAN router), it just stands stalled with the >> dialog open. >> >> Is there a way to tell NM not to ask for a new password ever? Because I use >> a 63-symbol passphrase once set up on all the (two) machines so to forget >> about it. >> >> Thanks! >> >> NetworkManager-gnome-0.8.4-1.fc14.x86_64 >> >> -- >> Best regards, >> Misha Shnurapet, Fedora Project Contributor >> https://fedoraproject.org/wiki/Shnurapet >> shnurapet AT fedoraproject.org, GPG: 00217306 > > As far as i can tell there is no easy, if any, solution that would not > breach the security of your 63-symbol pass phrase. In my experience > using knetworkmanager a password is required for each secure Wireless > connection and for security these are stored in a secure encrypted > area, (kwallet in my case), which needs just a single password for > access. Hence a password is always required for wireless access to > reconnect after a power out. > This is not required for wired connections, so unless you can use some > wired connection that restarts on power up to do the torrent downloads, > you have little choice, without breaching the security provided by your > pass phrase, but to accept the problem. > From what I can gather you use long random pass phrases for any > external available access which I heartily recommend. Nearly all > security breaches are made because it's easy to guess pass phrases that > relate to the person who created it. > > Regards > > cpp4ever Many thanks for your answer. However, the nm-applet in GNOME does *not* require you to enter passphrase *each* time you establish the connection you've *once configured*. And this behavior is absolutely correct. Also, makes it feel like with a wired connection. What is not absolutely correct is that, when it can't get response from the router, it starts thinking the passphrase has changed (which is wrong because the router is simply off). As soon as power is back on, the AP is back online with the same settings and the same passphrase (how mean of a manufacturer would it be not to implement this). But the client device stands idle waiting for a passphrase. I tested a couple of possible scenarios lately. NetworkManager reconnects nicely on outages that last no more than ~1 minute. Beyond that, it starts asking the question. -- Best regards, Misha Shnurapet, Fedora Project Contributor https://fedoraproject.org/wiki/Shnurapet shnurapet AT fedoraproject.org, GPG: 00217306 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 19.05.11 02:06, Matthew Garrett (mj...@srcf.ucam.org) wrote: > > On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: > > > > I am pretty sure we don't want to run Java programs at late boot, as > > > root. This would be really bad. > > > > You know, it's not like there is a choice for many models ... > > That's really not a given. For anything short of us having to send http > requests, there's no fundamental reason why this can't be done > in-kernel. For cases where we do have to send http requests, well, > that's kind of a separate issue (you want to run java after you've > unmounted all the filesystems?) > > > It is not necessary, the hook can be called before you do that last > > operation, the driver will command the UPS to wait long enough for that > > operation to finish in time in 99% of the cases. > > For the remaining 1% of the cases, admins will have to re-tune the delay > > once power comes up and they find it wasn't enough time after all. > > Or we could work on fixing the problem. We're not talking about an > incredibly large maount of code. In particular, since the power supply class driver already covers UPS: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/power/power_supply_class.txt Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, 18.05.11 19:42, Simo Sorce (sso...@redhat.com) wrote: > > > > This is not the case and never has been the case. The root disks > > > > traditionally could not be unmounted and hence MD/DM/MP and so on could > > > > not be disassembled before going down. > > > > > > > > Delaying shutdown by 30s is hack, not a fix for a race. > > > > > > What race are we talking about exactly ? > > > > Host requests power down from UPS in 30s. Host then continues shut > > down. If the host now ends up taking more time then expected for > > shutting down it might still be busy at the time of the power going > > away. It's a race between "UPS powering off" and "system finishing > > shutdown". It's a bet that your system is faster than 30s when > > unmounting the remaining file systems, syncing the MD/DM metadata to > > disk, syncing ATA and so on (i.e. all the stuff the kernel does when you > > invoke the reboot() syscall). > > You do realize that it is a race to get it done before the UPS runs out > of battery anyway ? That is unfortunate, but shutting down even earlier than that makes the problem worse, not better. > It's not perfect, but sysadmins are capable of assessing how much time > each of their server needs to shut down and make the UPS wait long > enough (battery permitting of course). Well, if everything goes well. But often things don't go well and since power failures are the exception and not the rule (at least in .de) relying that admins guess the right times is not realistic. > > > You do realize that the *UPS* itself is programmed to shut down after > > > 30 seconds ? there is no sleep(30) here ... > > > > Yes, but that is irrelevant for the race. > > Call it a race, call it a run, doesn't matter it is how things works in > this world right now. > > I guess you could try to convince UPS vendors to use better ways, but > that's not how physical devices available to the public work right > now. Uh? This is a software problem, not a hardware problem! > > > Oh this was *very* clear, no doubt you have never seen one. And given > > > you haven't can you stop prescribing how things should work and instead > > > discuss how we can make things work as things stand now ? > > > > Well, I am not stupid. I can see a race when there is one. Are you claiming > > the race above doesn't exist? > > You are looking at the finger while people are pointing to the moon > right now. And you are sticking your head in the sand. > > > You are the one pushing systemd, it is your duty to address the cases > > > when it has to step out of the perfect world and actually meet the > > > reality of how things actually work out there. > > > > Right, and so I did. And I also pointed out that the current scheme is > > borked. > > I am sorry that reality bothers you so much, but it is the hard old real > world ... See, I am so young, I still have the idealism that we can fix what is broken. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 2011-05-19 at 02:06 +0100, Matthew Garrett wrote: > On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: > > > > I am pretty sure we don't want to run Java programs at late boot, as > > > root. This would be really bad. > > > > You know, it's not like there is a choice for many models ... > > That's really not a given. For anything short of us having to send http > requests, there's no fundamental reason why this can't be done > in-kernel. For cases where we do have to send http requests, well, > that's kind of a separate issue (you want to run java after you've > unmounted all the filesystems?) While most UPSs just use serial commands over USB that's not a given. Some models use more or less documented standards, so you *could* implement something in kernel I guess. Some other, more data-centered UPSs that handle multiple machines use completely proprietary protocols over ethernet for example. It would be nice to be able to have all in kernel neatly and what not, but that's not going to happen soon. Meanwhile we need decent hooks so we can keep using existing models. > > It is not necessary, the hook can be called before you do that last > > operation, the driver will command the UPS to wait long enough for that > > operation to finish in time in 99% of the cases. > > For the remaining 1% of the cases, admins will have to re-tune the delay > > once power comes up and they find it wasn't enough time after all. > > Or we could work on fixing the problem. We're not talking about an > incredibly large maount of code. We are talking about unknown code shipped with unknown devices that has been working for decades. I do not know how much it is, but it is certainly not a trivial amount. And it is not a problem we can solve in a short time, so pretty please, provide a decent hook and let's move on, there are better things on which to reach "perfection" with systemd, this is not one of them, right now. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, 2011-05-18 at 21:15 -0500, Robert Nichols wrote: > On 05/18/2011 06:42 PM, Simo Sorce wrote: > > On Wed, 2011-05-18 at 16:48 -0500, Robert Nichols wrote: > >> On 05/18/2011 04:04 PM, Lennart Poettering wrote: > >>> Host requests power down from UPS in 30s. Host then continues shut > >>> down. If the host now ends up taking more time then expected for > >>> shutting down it might still be busy at the time of the power going > >>> away. It's a race between "UPS powering off" and "system finishing > >>> shutdown". It's a bet that your system is faster than 30s when > >>> unmounting the remaining file systems, syncing the MD/DM metadata to > >>> disk, syncing ATA and so on (i.e. all the stuff the kernel does when you > >>> invoke the reboot() syscall). > >> > >> Here's another race. Host requests power down from UPS in 30s. Host > >> completes shutdown. At some point during that 30s interval, commercial > >> power is restored. Result: Host shuts down and never restarts. Sorry > >> about that. > >> > >> The way I've always prevented that is to have the host do a reboot, > >> not a shutdown, but send an immediate shutdown command to the UPS > >> just before sending control to the BIOS for the reboot. > > > > What you should do is to configure the BIOS to always boot on power-up. > > > > This way the UPS will remove power, figure out power is returned, > > reapply power and the BIOS will reboot the machine. > > Telling my UPS to turn off merely shuts down the inverter. If it is > not currently running on the inverter (because commercial power is > available), that is effectively a no-op, and power at the UPS output > remains on. Telling the BIOS to boot on power-up (which is how mine > is configured, BTW) does nothing since _power_never_went_away_. All > the BIOS sees is a command to shut down, which it does. And stays > that way. Absent manual intervention, the only thing that would bring > the system back up would be a power failure long enough to exceed the > capacity of the essentially unloaded UPS, and that would be _quite_ a > long time. IIRC some UPSs can be commanded to cycle power (ie interrupt all power to the machine) on shutdown anyway. Perhaps not all models do that. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110519 changes
Compose started at Thu May 19 08:15:02 UTC 2011 Broken deps for x86_64 -- R-Rsolid-0.9.31-2.fc15.x86_64 requires libhdf5.so.6()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-10.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) 1:anerley-0.2.14-5.fc15.i686 requires libcamel-1.2.so.23 1:anerley-0.2.14-5.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires hal callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libwfmath-0.3.so.4()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libskstream-0.3.so.4()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libmercator-0.2.so.6()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-8.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.23()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-rss-0.2.90-19.20110307git.fc16.x86_64 requires libcamel-provider-1.2.so.23()(64bit) evolution-rss-0.2.90-19.20110307git.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-sharp-0.21.1-12.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gdl-0.9.1-2.fc16.x86_64 requires libhdf5.so.6()(64bit) gdl-python-0.9.1-2.fc16.x86_64 requires libhdf5.so.6()(64bit) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) giggle-0.5-4.fc15.i686 requires libcamel-1.2.so.23 giggle-0.5-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-jalali-calendar-1.7.1-2.fc15.noarch requires gnome-python2-applet gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires gnome-python2-applet gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-timer-2.1.4-2.fc15.x86_64 requires gnome-python2-applet >= 0:2.16 gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel >= 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel >= 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal) gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1 gnome-device-manager-libs-0.2-6.fc15.i686 requires hal >= 0:0.5.10 gnome-device-manager-libs-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal >= 0:0.5.10 gnome-launch-box-0.4-20.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-phone-manager-0.66-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-phone-manager-telepathy-0.66-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64
Feedback needed : Fedora 15 Announcement
Hi https://fedoraproject.org/wiki/Fedora_15_announcement Let me know if you have any comments. Feel free to edit the wiki directly if needed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
NetworkManager to reconnect silently
Hi. I asked this question in NetworkManager mailing list, but everyone there seems to be busy, so I decided to ask here. I run torrents on my notebook. On an electricity outage NetworkManager starts asking for a new password, so when I'm not around and the light goes back on (powering up the WLAN router), it just stands stalled with the dialog open. Is there a way to tell NM not to ask for a new password ever? Because I use a 63-symbol passphrase once set up on all the (two) machines so to forget about it. Thanks! NetworkManager-gnome-0.8.4-1.fc14.x86_64 -- Best regards, Misha Shnurapet, Fedora Project Contributor https://fedoraproject.org/wiki/Shnurapet shnurapet AT fedoraproject.org, GPG: 00217306 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Call for help: porting Sugar to NetworkManager 0.9 for Fedora 15
Hi Adam. On Thursday, May 19, 2011 12:48:04 AM Adam Williamson wrote: > Hey, all. So, although the Fedora 15 final release has been signed off > on, we gave ourselves a bit of wiggle room. The current Sugar > implementation is known to have some significant issues, the major one > of which is that networking is badly broken. We are aiming to try and > fix these and do the Sugar-on-a-stick live spin late, incorporating > these fixes, as they do not need to touch any of the other live images > or the DVD. > > The problem with networking is the NetworkManager 0.9 API change; it > caught Sugar, both upstream and within Fedora, a bit off guard. When the > change was discussed by FESCo the needs of KDE and anaconda were > considered and a plan developed, but no-one caught that the same problem > affected Sugar: Sugar has its own interface to NetworkManager, and that > needs to be either ported to 0.9, or adjusted to use the fallback 0.8ish > API that was implemented for knetworkmanager to use. I think compat interface is the only possible way to have working port in the specified time frame. I'm not sure about Sugar implementation - it should be easy - take a look on our patch, mostly sed should help (but really depends if it is using DBus interface or glib one?). Altough there are two problems: - compat interface does not contain everything what's available in NM now but that's not a problem - there's at least one bug that makes it hard for some cases Compat interface is only temporary solution, in KDE land we have initial NM 0.9 port but it's not yet ready, target are autumn distros releases. > Unfortunately, our go-to Sugar guy, Peter Robinson, is struggling with > doing this as it's not really in his wheelhouse, and our upstream > contact at Sugar is busy with travel and Sugar release problems, so > getting this done has not been smooth sailing so far. Peter would be > very grateful of any help anyone could offer with the porting effort (to > either the 0.9 or 0.8-ish interface within current NetworkManager; we > don't care which, we just want typical Sugar networking to work. I've never touched Sugar code but I'll try to take a look what's needed. Cannot promise anything! > We'd like to get this done so we can still spin up a Sugar live image > and push it out for release day, which is May 24, but in any case, the > sooner the better. If you'd like to help with this, please contact > Peter, myself, or Jared Smith via email or IRC, or just reply to this > mail. Peter's IRC nick is pbrobinson, mine is adamw, and Jared's is > jsmith. Thanks a lot! -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
