Re: Review swap requests for tntnet a web app server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2012 03:44 PM, Martin Gansser wrote: > Hi all, > > I've just packaged tntnet - A web application server for web > applications. https://bugzilla.redhat.com/show_bug.cgi?id=821224 > tntnet is needed for vdr-live - An interactive web interface for > VDR > > can someone review this package ? > Taking the review; could you swap with either https://bugzilla.redhat.com/show_bug.cgi?id=827723 or https://bugzilla.redhat.com/show_bug.cgi?id=827809 ? Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP6D6sAAoJEEr1VKujapN6JlwIAIYBRNjQTV7kTARcb6EVis6Z xFVicDE0YWMnWSq+DsfNameZaQ/HydLsdTEjJufxmcxeflfyiefe2j6H7JaopMbm rygoDig8ZeAC98RQwRl0SxKiv1CbX7smiQDlUJfHVNu3uCWui9dAChxEIZO0Ds9x ePpJ7ksAXYfbGZbE+11V+BncfSTRFfcvDvFWbnuP09Y9OjA+MUZQtnqV4uYp70nE BDjLLUbmM1GHlitB0DZ2yjsFex7Lv8X5kVokKs0yHIsOJ3iD9aKBhhPQJtLt9X/q 5Dtpvq3sao9bfljfD7HG90jhOtvZcrabJB2GQLXIHjOjTf3TwLK1EvRY/g01yKY= =UZen -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: multilib conflict with doxygen generated pdf
>
> This build has the pdf file with a different timestamp in the i686 and
> x86_64 build.
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4189461
>
> The pdf file is /usr/share/doc/libbluray-devel-0.2.2/libbluray.pdf from
> libbluray-devel-0.2.2-2.fc18
>
it's a bug in pdftex (part of texlive package) which is used to create pdf
files. pdftex writes the timestamps "CreationDate (%s)" and "ModDate (%s)"
into PDF files.
extract from texk/web2c/pdftexdir/utils.c
---
void printcreationdate()
{
initstarttime();
pdf_printf("/CreationDate (%s)\n", start_time_str);
}
void printmoddate()
{
initstarttime();
pdf_printf("/ModDate (%s)\n", start_time_str);
}
---
Than
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Space wasted by Non English Packages shipped by Default on Fedora 17.
In Add/Remove software, go to Filters ==> Installed ==> and make sure ==> "Only Installed" is checked. Now take a look under section: "Package Collections" There seems to be support for lots of languages other than English, which I don't need, but it seems to be installed by default on Fedora 17. Why? I don't need in alphabetical order: Arabic Support (6.7 MB), Armenian Support (5.4 MB), Assamese Support (2.7 MB) etc etc. too much to list here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: Kerberos default user credential cache location is changing
On Fri, 2012-06-22 at 09:36 +0100, David Howells wrote: > Stephen Gallagher wrote: > > > 1) Credential caches are now stored in a tmpfs location. This is a > > security feature, as a stolen laptop may not be booted in single-user > > mode to extract a valid TGT. > > Is it? Can't tmpfs move stuff arbitrarily out to swap? Ah, true. This could happen in a low-memory case. I should perhaps revise this statement then to be "This is a security feature, as a stolen laptop booted in single user mode will have a much more difficult time of extracting a valid TGT". This of course can be further mitigated by the use of encrypted swap space. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
2012/6/25 Malcolm Turmel : > There seems to be support for lots of languages other than English, which I > don't need, but it seems to be installed by default on Fedora 17. Why? Package Groups are shown as "installed", as soon as all mandatory packages are installed (IIRC at least one package of the group has to be installed). Some groups have no mandatory packages at all. Most of the language support groups have font packages in their list that can already be installed on default system. That way they get displayed as "installed". In reality it means "partially installed". No need to worry. -- If you don't remember something, it never happened... If you aren't remembered, you never existed... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:10:08 -0500 Dennis Gilmore wrote: > El Tue, 19 Jun 2012 12:19:35 -0400 (EDT) > Jaroslav Reznik escribió: > > As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG > > meeting that we would have to break CD size limit (and the breaking > > of CD size image was used as argument to accept this feature). > > > > We agreed that 800 MiB is achievable target: > > - all spins will still fit Multi Desktop Live DVD > > - there's still space available for overlay for USB disks > > - you can still get 800 MiB CD-Rs (may hit HW constraints...) > > > > Other possibility is to go directly to 1 GiB but we are not sure > > there's advantage (at least not now). > > > > Contingency plan - at least for one release we'd like to have a > > 700 MiB KS (with more compromises). > > > > So we'd like to hear from rel-engs, QA etc. what's theirs position > > here. > > from Relengs perspective it doesnt matter what size it is. so long as > it meets the release criteria then its ok. > > Personally i have a serious concern over dropping cd sized media. One > big issue is that the OLPC XO-1 only has 1gb storage for both the OS > and user data. any size increase in the OS reduces the room for user > data. > http://en.wikipedia.org/wiki/One_Laptop_Per_Child#Deployment_of_XO_laptops > lists over 2.5 million XOs deployed a large number of which a xo-1 > most of which run fedora. I spoke with some OLPC people, they really would prefer that we be able to disable the installation of the mini debuginfo. As the devices are all space constrained. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/oZckACgkQkSxm47BaWfdh7gCeKivoQfentzSjTgtZhc7VM0CZ jB8AnRZHltsyiHcufN1AxLeNhZFJFA/6 =7Z0j -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: Kerberos default user credential cache location is changing
On Mon, 2012-06-25 at 09:00 -0400, Stephen Gallagher wrote: > On Fri, 2012-06-22 at 09:36 +0100, David Howells wrote: > > Stephen Gallagher wrote: > > > > > 1) Credential caches are now stored in a tmpfs location. This is a > > > security feature, as a stolen laptop may not be booted in single-user > > > mode to extract a valid TGT. > > > > Is it? Can't tmpfs move stuff arbitrarily out to swap? > > Ah, true. This could happen in a low-memory case. I should perhaps > revise this statement then to be "This is a security feature, as a > stolen laptop booted in single user mode will have a much more difficult > time of extracting a valid TGT". > > This of course can be further mitigated by the use of encrypted swap > space. If you are concerned about security of laptops and do not encrypt swap you do not care about leaking TGTs, IMHO. Of course another solution is to simply have no swap, but that would prevent hybernation I think, which may be a desirable feature. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
Its still taking up valuable space. All the non-english packages should be optional. When I try to remove one of the Package, it tells me its going to also Uninstall lots of other stuff. How would I go about now uninstalling all of them without breaking my system. On Mon, Jun 25, 2012 at 6:10 AM, Julian Leyh wrote: > 2012/6/25 Malcolm Turmel : > > There seems to be support for lots of languages other than English, > which I > > don't need, but it seems to be installed by default on Fedora 17. Why? > > Package Groups are shown as "installed", as soon as all mandatory > packages are installed (IIRC at least one package of the group has to > be installed). Some groups have no mandatory packages at all. Most of > the language support groups have font packages in their list that can > already be installed on default system. That way they get displayed as > "installed". In reality it means "partially installed". > > No need to worry. > > -- > If you don't remember something, it never happened... > If you aren't remembered, you never existed... > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
On Mon, Jun 25, 2012 at 2:27 PM, Malcolm Turmel wrote: > Its still taking up valuable space. > > All the non-english packages should be optional. > > When I try to remove one of the Package, it tells me its going to also > Uninstall lots of other stuff. > > How would I go about now uninstalling all of them without breaking my > system. > > > On Mon, Jun 25, 2012 at 6:10 AM, Julian Leyh wrote: > >> 2012/6/25 Malcolm Turmel : >> > There seems to be support for lots of languages other than English, >> which I >> > don't need, but it seems to be installed by default on Fedora 17. Why? >> >> Package Groups are shown as "installed", as soon as all mandatory >> packages are installed (IIRC at least one package of the group has to >> be installed). Some groups have no mandatory packages at all. Most of >> the language support groups have font packages in their list that can >> already be installed on default system. That way they get displayed as >> "installed". In reality it means "partially installed". >> >> No need to worry. >> >> -- >> If you don't remember something, it never happened... >> If you aren't remembered, you never existed... >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > They are probably shipped by default, since there are people around who don't speak english and also use a different set of letters. I think it's good to give them a good out-of-the-box fedora experience. To say if it's safe to remove the packages one would need to know which packages exactly are removed by the yum transaction. Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 833719] perl-Alien-SDL-1.436 is available
https://bugzilla.redhat.com/show_bug.cgi?id=833719 Jitka Plesnikova changed: What|Removed |Added Assignee|mmasl...@redhat.com |jples...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: How long can a package be in pending status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 24 Jun 2012 18:49:54 -0300 Sergio Belkin wrote: > 2012/6/24 Michael Schwendt : > > On Sun, 24 Jun 2012 14:09:34 -0300, Sergio Belkin wrote: > > > >> Hi, > >> > >> Just I am somewhat surprised that I submitted package cdw for > >> testing and still is in status > > In Pending status I meant :) > > (I remember in previous updates that in a few > >> hours it went to testing) . It's not a reproach, only a question, > >> if something is wrong... Its a process manually run by humans, it happens when it happens. we try to do daily pushes but sometimes that doesnt happen when we hit corner cases. > >> Thanks in advance... > > > > It has been my experience that quite a lot of people like to have a > > few days off over the weekend. That also affects the > > not-fully-automated tasks like starting a repo compose. > > Ok I am waiting :) the signing and pushing process is manual. its run by Kevin Fenzi and myself, Kevin normally pushes on weekends but he is on Holiday so he did not do it, I stayed away from the computer on the weekend. there is a push in progress now. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/oaQwACgkQkSxm47BaWfcKbwCfZOO3GTcXKCwasGn0nqS9GnPh DL0An1IyG/zAIXbcaiFtITESVejoJB9C =cb3T -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 2:39 PM, Jef Spaleta wrote:
> On Sun, Jun 24, 2012 at 12:17 PM, Tom London wrote:
>
>> Haven't checked the crypto changes, but I do notice this spew when I
>> try 'Edit->Preferences':
>
> Okay I think I have the GConf scriptlets fixed:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4191873
>
>
> On local testing.
>
> Install the new scratch build.
> Logout/Login
> run revelation
> open edit/prefs
> No traceback.
>
> Tom can you confirm that the above works for you with the new test package?
>
> I suspect that we'll still get tracebacks unless the logout/login
> happens to restart gconf and have it look for the updated schema. I
> don't know how to have a running gconf "see" the schema updates
> introduced by a package install.
>
>
> -jef
> --
Hmm... Still seeing spew:
Traceback (most recent call last):
File "/usr/bin/revelation", line 206, in
action.connect("activate", lambda w: self.prefs())
File "/usr/bin/revelation", line 1527, in prefs
dialog.run_unique(Preferences, self, self.config)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1324, in run_unique
d = create_unique(dialog, *args)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1282, in create_unique
UNIQUE_DIALOGS[dialog] = dialog(*args)
File "/usr/bin/revelation", line 1623, in __init__
self.__init_section_password(self.page_general)
File "/usr/bin/revelation", line 1762, in __init_section_password
ui.config_bind(self.config, "passwordgen/punctuation",
self.check_punctuation_chars)
File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line
182, in config_bind
id = cfg.monitor(key, cb_get, widget)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
150, in monitor
callback(key, self.get(key), userdata)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
129, in get
raise ConfigError
ConfigError
Here is what I did:
1. I 'rpm -Uvh --force' the new package.
2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had
saved them by moving them to revelation.old before updating/testing
with the previous test build).
3. I rebooted and started revelation
4. Edit->Preferences
I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and
reboot/etc. it will work...
tom
--
Tom London
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Monday's FESCo Meeting (2012-06-25)
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 #830 define requirements for secondary arch promotion .fesco 830 = New business = #topic #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals .fesco 873 #topic #874 F18 Feature: OpenStack Folsom - https://fedoraproject.org/wiki/Features/OpenStack_Folsom .fesco 874 #topic #875 F18 Feature: targetd - https://fedoraproject.org/wiki/Features/targetd .fesco 875 #topic #876 F18 Feature: libstoragemanagement - https://fedoraproject.org/wiki/Features/libstoragemgmt .fesco 876 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
service restart question
Hi, I recently encountered a problem with the Openstack Quantum service. The service was installed by doing the following steps: - sudo yum install openstack-quantum - sudo systemctl enable quantum-server.service - sudo systemctl start quantum-server.service Due to a bug the service terminated. The contents of the file /etc/systemd/system/multi-user.target.wants/quantum-server.service is below: [Unit] Description=OpenStack Quantum Server After=syslog.target network.target [Service] Type=simple User=quantum ExecStart=/usr/bin/quantum-server --config-file /etc/quantum/quantum.conf --log-file /var/log/quantum/server.log PrivateTmp=true [Install] WantedBy=multi-user.target My understanding is that if there is a entry in the "Service" section "Restart=always", then we can rely on systemd to restart the service if it dies. Can someone please explain or clarify why this is not the default value? I can understand that this should not be set if there is another "watcher" process that can restart a failed service. Thanks in advance Gary -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Alien-SDL-1.436.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Alien-SDL: eedfebaf00dca8a8e4806e8dc47bf1ed Alien-SDL-1.436.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: service restart question
On Mon, 25.06.12 16:57, Gary Kotton (gkot...@redhat.com) wrote: > Hi, > > I recently encountered a problem with the Openstack Quantum service. The > service was installed by doing the following steps: > - sudo yum install openstack-quantum > - sudo systemctl enable quantum-server.service > - sudo systemctl start quantum-server.service > Due to a bug the service terminated. > > The contents of the file > /etc/systemd/system/multi-user.target.wants/quantum-server.service is below: > [Unit] > Description=OpenStack Quantum Server > After=syslog.target network.target > > [Service] > Type=simple > User=quantum > ExecStart=/usr/bin/quantum-server --config-file > /etc/quantum/quantum.conf --log-file /var/log/quantum/server.log > PrivateTmp=true > > [Install] > WantedBy=multi-user.target > > My understanding is that if there is a entry in the "Service" section > "Restart=always", then we can rely on systemd to restart the service if > it dies. > > Can someone please explain or clarify why this is not the default value? > I can understand that this should not be set if there is another > "watcher" process that can restart a failed service. Well, simply because we have no policy about it. I think it would make a lot of sense however, to amend the fedora policy to suggest usage of this by default for normal long running services. Of course, there are some services where this functionality makes no sense, for example all those which are of type "oneshot", i.e. are just quickly started at boot to initialize something but then don't run any longer. Or Historically on SysV this functionality was not available, and so far we only did the minimum packaging policy updates for translation of SysV. We probably should fix that, but be careful to make this a recommendation but not a requirement, and leave a lot of room for the individual cases. Also, we need to think about whether Restart=always or Restart=on-failure or even Restart=on-abort is the best option to suggest. I think it would be great if somebody would file an FPC ticket about this, so that the policy gets amended. But for that we'd first have to make our mind up what the best option to recommend is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Alien-SDL] 1.436 bump
commit b38dfb4aadbe10c18270311a329aaedbfb2e5cb5
Author: Jitka Plesnikova
Date: Mon Jun 25 16:06:44 2012 +0200
1.436 bump
.gitignore |1 +
perl-Alien-SDL.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b6564f6..809e8c7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Alien-SDL-1.428.tar.gz
/Alien-SDL-1.430.tar.gz
/Alien-SDL-1.434.tar.gz
+/Alien-SDL-1.436.tar.gz
diff --git a/perl-Alien-SDL.spec b/perl-Alien-SDL.spec
index 00ee495..577cb09 100644
--- a/perl-Alien-SDL.spec
+++ b/perl-Alien-SDL.spec
@@ -1,6 +1,6 @@
Name: perl-Alien-SDL
-Version:1.434
-Release:2%{?dist}
+Version:1.436
+Release:1%{?dist}
Summary:Building, finding and using SDL binaries
License:GPL+ or Artistic
Group: Development/Libraries
@@ -68,6 +68,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Thu Jun 25 2012 Jitka Plesnikova - 1.436-1
+- 1.436 bump
+
* Sun Jun 17 2012 Petr Pisar - 1.434-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index 9799fc7..0af7944 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-377d36fb8a41c86477f337f272cd1566 Alien-SDL-1.434.tar.gz
+eedfebaf00dca8a8e4806e8dc47bf1ed Alien-SDL-1.436.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: How long can a package be in pending status?
2012/6/25 Dennis Gilmore : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sun, 24 Jun 2012 18:49:54 -0300 > Sergio Belkin wrote: > >> 2012/6/24 Michael Schwendt : >> > On Sun, 24 Jun 2012 14:09:34 -0300, Sergio Belkin wrote: >> > >> >> Hi, >> >> >> >> Just I am somewhat surprised that I submitted package cdw for >> >> testing and still is in status >> >> In Pending status I meant :) >> >> (I remember in previous updates that in a few >> >> hours it went to testing) . It's not a reproach, only a question, >> >> if something is wrong... > > Its a process manually run by humans, it happens when it happens. we > try to do daily pushes but sometimes that doesnt happen when we hit > corner cases. > I guessed that >> >> Thanks in advance... >> > >> > It has been my experience that quite a lot of people like to have a >> > few days off over the weekend. That also affects the >> > not-fully-automated tasks like starting a repo compose. >> >> Ok I am waiting :) > > the signing and pushing process is manual. its run by Kevin Fenzi and > myself, Kevin normally pushes on weekends but he is on Holiday so he > did not do it, I stayed away from the computer on the weekend. there is > a push in progress now. Thanks Dennis for your answer! > > Dennis > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > > iEYEARECAAYFAk/oaQwACgkQkSxm47BaWfcKbwCfZOO3GTcXKCwasGn0nqS9GnPh > DL0An1IyG/zAIXbcaiFtITESVejoJB9C > =cb3T > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
On Mon, 25.06.12 16:13, Lennart Poettering (mzerq...@0pointer.de) wrote: > I think it would be great if somebody would file an FPC ticket about > this, so that the policy gets amended. But for that we'd first have to > make our mind up what the best option to recommend is. Hmm, ok, I decided to be that somebody and have now filed an FPC ticket with my recommendations: https://fedorahosted.org/fpc/ticket/191 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
2012/6/25 Malcolm Turmel : > Its still taking up valuable space. It is not. Trust me. You only see the package groups as "installed", because you have packages installed that are on the list of that group. For example, you mentioned the "Arabic Support" group. This group includes "dejavu-sans-fonts" as "default"-packages. You most probably have this font package installed. To remove the group from being listed as "installed" you would have to remove it. You don't want that, do you? -- If you don't remember something, it never happened... If you aren't remembered, you never existed... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Grouping service units for bulk stop/start ?
With OpenStack there are quite a large number of daemons per host, each of which has their own .service unit file. openstack-glance-api.service openstack-glance-registry.service openstack-keystone.service openstack-nova-api.service openstack-nova-cert.service openstack-nova-compute.service openstack-nova-network.service openstack-nova-objectstore.service openstack-nova-scheduler.service openstack-nova-volume.service openstack-swift-account.service openstack-swift-container.service openstack-swift-object.service openstack-swift-proxy.service Currently our OpenStack instructions have such fun commands as: # for svc in api registry; do sudo systemctl start openstack-glance-$svc.service; done # for svc in api objectstore compute network volume scheduler cert; do sudo systemctl start openstack-nova-$svc.service; done What I'd like to be able todo is setup some kind of grouping, so that you can just start/stop/check status of everything in simple commands like: # sudo systemctl start openstack-nova.target # sudo systemctl status openstack-nova.target # sudo systemctl stop openstack-nova.target My naive attempt to make this work was todo - Create a openstack-nova.target containining [Unit] Description=OpenStack Nova WantedBy=multi-user.target - Edit each of openstack-nova-XXX.service to change WantedBy=multi-user.target to WantedBy=openstack-nova.target But after doing this, stopping/starting the target has no effect on the running state of units I associated with it. Also I'd like starting/stopping XXX.target to take account of the enablement state of the individual XXX-YYY.service files. eg so I can disable say, openstack-nova-network.service on a host, but still use openstack-nova.target to bulk stop/start all the other services that are enabled. Either I'm missing some config change, or what I'm attempting is just not the kind of functionality that .target files are intended to offer ? Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
Lennart Poettering writes: > On Mon, 25.06.12 16:57, Gary Kotton (gkot...@redhat.com) wrote: >> My understanding is that if there is a entry in the "Service" section >> "Restart=always", then we can rely on systemd to restart the service if >> it dies. >> >> Can someone please explain or clarify why this is not the default value? >> I can understand that this should not be set if there is another >> "watcher" process that can restart a failed service. > Well, simply because we have no policy about it. See also bug #832029 before being in too much of a hurry to decide that this Must Be A Good Thing. At minimum, it currently seems that we might need per-service tuning of the restart timing parameters before being sure that enabling restart is safe. So while recommending that services enable this after suitable testing *might* be a good idea, turning it on by default seems like a horribly bad one. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
(I'm posting in this thread rather than starting a new one in order to respect people who've spam-canned it) It is being widely reported that Canonical's be signing the kernel, they won't be requiring signed drivers, and won't be restricting runtime functionality while securebooted. What is being claimed is that the only thing they'll be restricting is the bootloader and they're going to write a new bootloader for this in order to avoid signing code written by third parties. This seems a bit incongruent with many of the claims made here about the degree of participation with cryptographic lockdown required and the importance of it. I feel like the entire discussion has been a bit unfair where people were repeatedly challenged to offer alternatives when things claimed to be impossible based on NDAed discussions are, apparently, actually possible and the remaining weak alternatives were discarded as not being usable enough. [1] http://www.h-online.com/open/news/item/Canonical-details-Ubuntu-UEFI-Secure-Boot-plans-162.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap requests for tntnet a web app server
Am Montag, den 25.06.2012, 17:34 +0700 schrieb Michel Alexandre Salim: > On 06/22/2012 03:44 PM, Martin Gansser wrote: > > Hi all, > > > > I've just packaged tntnet - A web application server for web > > applications. https://bugzilla.redhat.com/show_bug.cgi?id=821224 > > tntnet is needed for vdr-live - An interactive web interface for > > VDR > > > > can someone review this package ? > > > Taking the review; could you swap with either > https://bugzilla.redhat.com/show_bug.cgi?id=827723 > > or > > https://bugzilla.redhat.com/show_bug.cgi?id=827809 > > ? > > Thanks, > I know is pretty difficult to get a reviewer this days. Sorry, I can't review your package, because i have no expierence in reviewing packages. Thanks Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 5:36 AM, Tom London wrote: > Hmm... Still seeing spew: > Here is what I did: > > 1. I 'rpm -Uvh --force' the new package. > 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had > saved them by moving them to revelation.old before updating/testing > with the previous test build). > 3. I rebooted and started revelation > 4. Edit->Preferences > > I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and > reboot/etc. it will work... I'd image the problem in your steps is the fact that you did 2 after 1. Get your system into the old state with the old 0.4.11 revelation update to new rpm logout/log back in. tracebacks should stop. I've tested this on a couple of systems now. -jef > > tom > -- > Tom London > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
On Mon, Jun 25, 2012 at 10:30:00 -0400, Tom Lane wrote: See also bug #832029 before being in too much of a hurry to decide that this Must Be A Good Thing. At minimum, it currently seems that we might need per-service tuning of the restart timing parameters before being sure that enabling restart is safe. So while recommending that services enable this after suitable testing *might* be a good idea, turning it on by default seems like a horribly bad one. Since 832029 is not a public bug, can you give the gist of the issue? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
packagekit-glib and packagekit-qt API bump
Hi all, I'm going to build the unstable PackageKit 0.8.1 into rawhide tomorrow. The packagekit-glib and packagekit-qt break ABI, but I'll take care of anything that needs patching / rebuilding. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
Julian Leyh (jul...@vgai.de) said: > It is not. Trust me. You only see the package groups as "installed", > because you have packages installed that are on the list of that > group. > > For example, you mentioned the "Arabic Support" group. This group > includes "dejavu-sans-fonts" as "default"-packages. You most probably > have this font package installed. To remove the group from being > listed as "installed" you would have to remove it. You don't want > that, do you? To elaborate - dejavu-sans-fonts is the default font for English. However, it also happens to have Arabic, Greek, accented European, etc. characters, so 'support' for those languages will show up as being installed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
Tom Lane (t...@redhat.com) said: > > Well, simply because we have no policy about it. > > See also bug #832029 before being in too much of a hurry to decide that > this Must Be A Good Thing. At minimum, it currently seems that we might > need per-service tuning of the restart timing parameters before being > sure that enabling restart is safe. So while recommending that services > enable this after suitable testing *might* be a good idea, turning it on > by default seems like a horribly bad one. Also, having different services have different restart settings can certainly lead to confusion; as it stands now, the policy where no services restart automatically, while possibly suboptimal, is at least predictable for admins. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Space wasted by Non English Packages shipped by Default on Fedora 17.
On Mon, Jun 25, 2012 at 1:11 PM, Bill Nottingham wrote: > To elaborate - dejavu-sans-fonts is the default font for English. However, > it also happens to have Arabic, Greek, accented European, etc. characters, > so 'support' for those languages will show up as being installed. And if you use the web you really do want those characters being installed— otherwise you'll have hexboxes or blank spaces showing up all over Wikipedia articles or in people's usernames on forums. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Also— as this apparently hasn't been mentioned here: https://fedoraproject.org/wiki/Features/SecureBoot and also the actual WIP kernel patches: http://www.codon.org.uk/~mjg59/tmp/ftsoefi/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/25/2012 11:25 AM, Gregory Maxwell wrote: This seems a bit incongruent with many of the claims made here about the degree of participation with cryptographic lockdown required and the importance of it. I think we've made it fairly clear that we don't believe their interpretation is correct. This shouldn't surprise anybody. I feel like the entire discussion has been a bit unfair where people were repeatedly challenged to offer alternatives when things claimed to be impossible based on NDAed discussions are, apparently, actually possible and the remaining weak alternatives were discarded as not being usable enough. I feel like this is quite patronizing. We've stated time and again that we don't believe the scenario you're preaching has any real /viability/, and so we've chosen not to propose it. There's no secret here - it's possible to do, but we don't think it'd last very long before our keys are blacklisted and we're back to a state where Fedora isn't bootable by default on new hardware. This is still completely congruous with what we've been saying all along. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2012-06-25)
(prepared manually, MeetBot-generated version to hopefully follow later) * ticket 830 define requirements for secondary arch promotion NOTE: https://fedorahosted.org/fesco/ticket/830#comment:11 sums up the situation correctly. * ticket #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals AGREED: Feature 256 Color Terminals deferred pending discussion on devel@ (+7) ACTION: mjg59 to start discussion * ticket #874 F18 Feature: OpenStack Folsom - https://fedoraproject.org/wiki/Features/OpenStack_Folsom AGREED: Feature OpenStack Folsom is approved (+9) * ticket #875 F18 Feature: targetd - https://fedoraproject.org/wiki/Features/targetd AGREED: Feature targetd is approved (+9) * ticket #876 F18 Feature: libstoragemanagement - https://fedoraproject.org/wiki/Features/libstoragemgmt AGREED: Feature libstoragemgmt is accepted, please merge it with targetd (+9) * Next week's chair: NOTE: The meeting on July 2 is canceled for lack of quorum ACTION: t8m will chair the meeting on July 9th * Open floor: NOTE: Heads up - https://fedoraproject.org/wiki/Features/SecureBoot was proposed Full meeting log is below. Mirek mitr: #startmeeting FESCO (2012-06-25) #meetingname fesco #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb #topic init process zodbot: Meeting started Mon Jun 25 17:00:07 2012 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. zodbot: Useful Commands: #action #agreed #halp #info #idea #link #topic. - Nastavit téma na: (Meeting topic: FESCO (2012-06-25)) zodbot: The meeting name has been set to 'fesco' zodbot: Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m - Nastavit téma na: init process (Meeting topic: FESCO (2012-06-25)) * notting is here t8m: hello pjones: hi jwb: hi mitr: nirik told us last time that he won't be able to come, limburgher voted in tickets. mjg59: Hi mitr: mmaslano: here? mmaslano: yes, hi mitr: Thanks, let's start... mitr: #topic #830 define requirements for secondary arch promotion .fesco 830 Just a quick check: Robyn had some questions about the outcome of this ticket and the feature - https://fedorahosted.org/fesco/ticket/830#comment:9 Are there any objections to the summing up by Tomas ( https://fedorahosted.org/fesco/ticket/830#comment:11 ) ? - Nastavit téma na: #830 define requirements for secondary arch promotion (Meeting topic: FESCO (2012-06-25)) zodbot: mitr: #830 (define requirements for secondary arch promotion) – FESCo - https://fedorahosted.org/fesco/ticket/830 mjg59: Nope jwb: no pjones: sounds right notting: that ounds correct * mitr assumes that's good enough mitr: #topic #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals .fesco 873 limburgher was +1 in the ticket kevin was +1 in the ticket - Nastavit téma na: #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals (Meeting topic: FESCO (2012-06-25)) zodbot: mitr: #873 (F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals) – FESCo - https://fedorahosted.org/fesco/ticket/873 mitr: I like the idea in general, not sure about the specifics mitr: * Apparently there's no simple way to set TERM=something_old in ~/.ssh/config mjg59: Sure would be nice if this were something that could be negotiated between endpoints mitr: * Using /etc/profile.d/* sounds like too big a hammer, but perhaps not worth arguing about mjg59: But fixing that would be breaking decades of UNIX tradition, I'm sure pjones: yeah, not really solid on the implementation pjones: I like the idea * mjg59 remembers the bad old days of XTERM-DEBIAN notting: that profile.d looks ... wrong jwb: i'm entirely ambivalent notting: in that it automatically assumes anything you use that supports xterm also supports this pjones: yeah, that's not great. mjg59: Yeah. Seems like we should be changing the terminal emulators. mitr: Hm, that profile.d would trigger even when ssh-ing from a non-Linux system, wouldn't it? And in a way that makes it non-trivial to override. notting: mitr: yes. mjg59: How about we punt this back to devel@ for further discussion of the implementation? jwb: sounds good to me mmaslano: fine t8m: mjg59, +1 mitr: +1 It will probably generate some noise, but it should help with the right direction. notting: +1 mjg59: I can bring it up mmaslano: +1 mjg59: Might as well take responsibility for even more pointless argument jwb: you're very good at that mitr: #agreed Feature: 256 Color Terminals deferred pending discussion on devel@ mjg59: Life skills and all that mitr: #action mjg59 to start discussion mitr: #topic #874 F18 Feature: OpenStack Folsom - https://fedoraproject.org/wiki/Features/OpenStack_Folsom .fesco 874 limburgher was +1 in the ticket kevin was +1 in the ticket * mitr is +1 jwb: this is basically a version bump of an existing stack in Fedora, right?
[w3c-markup-validator/el5] Remove un-needed patch
commit 810dd49e0529b75ea643c35af136553b3076167e
Author: Nathanael D. Noblet
Date: Mon Jun 25 12:02:43 2012 -0600
Remove un-needed patch
w3c-markup-validator-0.8.6-hanextra.patch | 59 -
w3c-markup-validator.spec |9 ++--
2 files changed, 5 insertions(+), 63 deletions(-)
---
diff --git a/w3c-markup-validator.spec b/w3c-markup-validator.spec
index 8fec29a..92798f0 100644
--- a/w3c-markup-validator.spec
+++ b/w3c-markup-validator.spec
@@ -1,6 +1,6 @@
Name: w3c-markup-validator
Version:0.8.6
-Release:3%{?dist}
+Release:4%{?dist}
Summary:W3C Markup Validator
Group: Applications/Internet
@@ -19,8 +19,7 @@ Patch2: %{name}-0.8.6-valid-icons.patch
# Not upstreamable,
# https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00020.html
Patch3: %{name}-0.8.6-iso-html.patch
-# Not upstreamable, kept until Encode::HanExtra is packaged
-Patch4: %{name}-0.8.6-hanextra.patch
+
# Post 0.8.6 upstream
Patch5: %{name}-0.8.6-xmlenc.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -65,7 +64,6 @@ rm htdocs/images/markup_validation_service.psd
%patch1 -p1
%patch2 -p1
%patch3 -p1
-%patch4 -p1
mv htdocs/sgml-lib .
@@ -149,6 +147,9 @@ done
%changelog
+* Mon Jun 25 2012 Nathanael Noblet - 0.8.6-4
+- Removed non-needed hans patch as it has been packaged
+
* Tue Apr 13 2010 Nathanael Noblet - 0.8.6-3
- actually fix symlink to xhtml1-dtds
- adjust xhtml1-dtds requirement
--
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
[w3c-markup-validator/el6] Remove un-needed patch
commit 6d1295c0d913afc117082d60031eb77f198490cb
Author: Nathanael D. Noblet
Date: Mon Jun 25 12:00:52 2012 -0600
Remove un-needed patch
w3c-markup-validator-1.0-hanextra.patch | 59 ---
w3c-markup-validator.spec |9 +++--
2 files changed, 5 insertions(+), 63 deletions(-)
---
diff --git a/w3c-markup-validator.spec b/w3c-markup-validator.spec
index bccf9bb..b6c631c 100644
--- a/w3c-markup-validator.spec
+++ b/w3c-markup-validator.spec
@@ -1,6 +1,6 @@
Name: w3c-markup-validator
Version:1.0
-Release:1%{?dist}
+Release:2%{?dist}
Summary:W3C Markup Validator
Group: Applications/Internet
@@ -19,8 +19,7 @@ Patch2: %{name}-1.0-valid-icons.patch
# Not upstreamable,
# https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00020.html
Patch3: %{name}-0.8.6-iso-html.patch
-# Not upstreamable, kept until Encode::HanExtra is packaged
-Patch4: %{name}-1.0-hanextra.patch
+
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -58,7 +57,6 @@ rm htdocs/images/markup_validation_service.psd
%patch1 -p1
%patch2 -p1
%patch3 -p1
-%patch4 -p1
mv htdocs/sgml-lib .
@@ -145,6 +143,9 @@ done
%changelog
+* Mon Jun 25 2012 Nathanael Noblet - 1.0-2
+- Removed non-needed hans patch as it has been packaged
+
* Fri Jun 18 2010 Ville Skyttä - 1.0-1
- Update to 1.0, XML encoding fix applied upstream.
--
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
[w3c-markup-validator/f15] Remove un-needed patch
commit 7d87dc1169c5eeb8164869154fe545dde9eacc7f
Author: Nathanael D. Noblet
Date: Mon Jun 25 11:59:43 2012 -0600
Remove un-needed patch
w3c-markup-validator-1.0-hanextra.patch | 59 ---
w3c-markup-validator.spec |9 +++--
2 files changed, 5 insertions(+), 63 deletions(-)
---
diff --git a/w3c-markup-validator.spec b/w3c-markup-validator.spec
index 6d20f5f..1681b0c 100644
--- a/w3c-markup-validator.spec
+++ b/w3c-markup-validator.spec
@@ -2,7 +2,7 @@
Name: w3c-markup-validator
Version:1.2
-Release:3%{?dist}
+Release:4%{?dist}
Summary:W3C Markup Validator
Group: Applications/Internet
@@ -21,8 +21,7 @@ Patch2: %{name}-1.0-valid-icons.patch
# Not upstreamable,
# https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00020.html
Patch3: %{name}-0.8.6-iso-html.patch
-# Not upstreamable, kept until Encode::HanExtra is packaged
-Patch4: %{name}-1.0-hanextra.patch
+
# From upstream post-1.2 hg (commit 3214)
Patch5: %{name}-1.2-perl512-warnings.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -63,7 +62,6 @@ rm htdocs/images/markup_validation_service.psd
%patch1 -p1
%patch2 -p1
%patch3 -p1
-%patch4 -p1
%patch5 -p1
find . -type f -name "*.orig" -delete # patch backup files
@@ -152,6 +150,9 @@ done
%changelog
+* Mon Jun 25 2012 Nathanael Noblet - 1.2-4
+- Removed non-needed hans patch as it has been packaged
+
* Tue Mar 15 2011 Ville Skyttä - 1.2-3
- Filter unsatisfied perl(W3C::Validator::EventHandler) self-dependency.
--
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
[w3c-markup-validator/f16] Remove un-needed patch
commit c71731d6b2bbb6da7553edd0886044d732fd4561
Author: Nathanael D. Noblet
Date: Mon Jun 25 11:58:44 2012 -0600
Remove un-needed patch
w3c-markup-validator-1.0-hanextra.patch | 59 ---
w3c-markup-validator.spec |9 +++--
2 files changed, 5 insertions(+), 63 deletions(-)
---
diff --git a/w3c-markup-validator.spec b/w3c-markup-validator.spec
index 6d20f5f..1681b0c 100644
--- a/w3c-markup-validator.spec
+++ b/w3c-markup-validator.spec
@@ -2,7 +2,7 @@
Name: w3c-markup-validator
Version:1.2
-Release:3%{?dist}
+Release:4%{?dist}
Summary:W3C Markup Validator
Group: Applications/Internet
@@ -21,8 +21,7 @@ Patch2: %{name}-1.0-valid-icons.patch
# Not upstreamable,
# https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00020.html
Patch3: %{name}-0.8.6-iso-html.patch
-# Not upstreamable, kept until Encode::HanExtra is packaged
-Patch4: %{name}-1.0-hanextra.patch
+
# From upstream post-1.2 hg (commit 3214)
Patch5: %{name}-1.2-perl512-warnings.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -63,7 +62,6 @@ rm htdocs/images/markup_validation_service.psd
%patch1 -p1
%patch2 -p1
%patch3 -p1
-%patch4 -p1
%patch5 -p1
find . -type f -name "*.orig" -delete # patch backup files
@@ -152,6 +150,9 @@ done
%changelog
+* Mon Jun 25 2012 Nathanael Noblet - 1.2-4
+- Removed non-needed hans patch as it has been packaged
+
* Tue Mar 15 2011 Ville Skyttä - 1.2-3
- Filter unsatisfied perl(W3C::Validator::EventHandler) self-dependency.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 1:56 PM, Peter Jones wrote: > I feel like this is quite patronizing. We've stated time and again that we > don't believe the scenario you're preaching has any real /viability/, and Sounds like you're not arguing with me, you're arguing with Canonical. I didn't propose this, the only stuff I proposed fit within the invariants you set out: That the rules of the game required you to restrict the system thusly if Fedora was to boot at all. I was under the impression that you couldn't get a key like that signed in the first place. But what do I know, it seems like the experts at canonical don't agree and are going to try several other routes concurrently. Canonical seems to be giving this a higher level of organizational attention[1], vs pure decision making by the engineering guys deep in the trenches. Obviously this has system implications far beyond a bit of bootloader code. And as a result it appears that they have a plan which will make a better stand for software freedom while simultaneously satisfying the PR interest of "not capitulating to Microsoft", for whatever value that has. > so we've chosen not to propose it. There's no secret here - it's possible > to do, but we don't think it'd last very long before our keys are I'm looking for a message where anyone said "we could do this, but we expect our keys would eventually be blacklisted" can you help me out? I think I'd have said "well, you should do that then, put the ball in Microsoft's court" ::shrugs:: [1] http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 02:10:10PM -0400, Gregory Maxwell wrote: > I was under the impression that you couldn't get a key like that > signed in the first place. But what do I know, it seems like the > experts at canonical don't agree and are going to try several other > routes concurrently. We never said it would be impossible to get a key. It's just msasively unlikely that such a key will be useful for any length of time, and so it's not something that solves any of the problems we're interested in solving. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta wrote: > On Mon, Jun 25, 2012 at 5:36 AM, Tom London wrote: >> Hmm... Still seeing spew: >> Here is what I did: >> >> 1. I 'rpm -Uvh --force' the new package. >> 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had >> saved them by moving them to revelation.old before updating/testing >> with the previous test build). >> 3. I rebooted and started revelation >> 4. Edit->Preferences >> >> I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and >> reboot/etc. it will work... > > I'd image the problem in your steps is the fact that you did 2 after 1. > Get your system into the old state with the old 0.4.11 revelation > update to new rpm > logout/log back in. > tracebacks should stop. > > I've tested this on a couple of systems now. > > > -jef > > Oops Sorry for the fumble. Will redo and report tonight. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 25 Jun 2012, Gregory Maxwell wrote: (I'm posting in this thread rather than starting a new one in order to respect people who've spam-canned it) It is being widely reported that Canonical's be signing the kernel, they won't be requiring signed drivers, and won't be restricting runtime functionality while securebooted. What is being claimed is that the only thing they'll be restricting is the bootloader and they're going to write a new bootloader for this in order to avoid signing code written by third parties. This seems a bit incongruent with many of the claims made here about the degree of participation with cryptographic lockdown required and the importance of it. I feel like the entire discussion has been a bit unfair where people were repeatedly challenged to offer alternatives when things claimed to be impossible based on NDAed discussions are, apparently, actually possible and the remaining weak alternatives were discarded as not being usable enough. The main error of the Surrender before Engagement Argument is: 1. to implicitly assume that the "issue" is smaller than it is The situation is quite different: If we do not here and now stand and fight, likely we will shortly lose the right to own a computer. The issue is so large that it is absurd to allow a small group of engineers from Fedora to engage in secret negotiations with the Englobulators about the issue. The small team is not empowered by me, nor by millions of others, to give away our present practical power to install Fedora on a new x86 home computer by putting in a CD, and setting some values in some configuration files. As of today Red Hat has formally agreed that Microsoft should be given an absolute veto power over ease of installation of a free OS on almost all x86 home computer sold, starting within six months. oo--JS. [1] http://www.h-online.com/open/news/item/Canonical-details-Ubuntu-UEFI-Secure-Boot-plans-162.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap requests for tntnet a web app server
On 2012-06-25 19:26, Martin Gansser wrote: > Sorry, I can't review your package, because i have no expierence in > reviewing packages. The only way to gain that experience is to do it. Just go ahead! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Jay Sulzberger (j...@panix.com) said: > The issue is so large that it is absurd to allow a small group of > engineers from Fedora to engage in secret negotiations with the > Englobulators about the issue. The small team is not empowered > by me, nor by millions of others, to give away our present > practical power to install Fedora on a new x86 home computer by > putting in a CD, and setting some values in some configuration > files. 1. Invalid assumption about 'small group of engineers from Fedora' as if they were working alone in a vacuum. But hey, whatever allows you to belittle people... 2. You are simultaneously ascribing to Fedora the power to move the industry despite anything you do, while claiming that they aren't empowered by you to do so. Given that, why not concentrate your considerable mailbox filling activities towards whomever has allowed Fedora the power to move the industry, or whomever you would *like* to empower to represent you? This is a development list, after all, not a ranting list. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 25, 2012, at 9:25 AM, Gregory Maxwell wrote: > It is being widely reported that Canonical's be signing the kernel, > they won't be requiring signed drivers, and won't be restricting > runtime functionality while securebooted. What is being claimed is > that the only thing they'll be restricting is the bootloader and > they're going to write a new bootloader for this in order to avoid > signing code written by third parties. I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules. > This seems a bit incongruent with many of the claims made here about > the degree of participation with cryptographic lockdown required and > the importance of it. Yes it does, because the Canonical approach effectively turns UEFI Secure Boot into UEFI Secure Pre-Boot. It is such a minimalist implementation that it's rendered meaningless when a signed pre-boot environment hands off control to an unsigned kernel, the veracity of which cannot be confirmed. The kernel itself could be malware. So what's the point of Secure Pre-Boot? > I feel like the entire discussion has been a bit unfair where people > were repeatedly challenged to offer alternatives when things claimed > to be impossible based on NDAed discussions are, apparently, actually > possible and the remaining weak alternatives were discarded as not > being usable enough. I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Koji jobs being killed after 68 minutes 30 seconds?
I started 3 Koji tasks this afternoon. They all died in pretty inexplicable ways, but after examining them I seem to have worked out that they all died after approx 68 minutes and 30 seconds, give or take a few seconds. Is there some new limit on Koji jobs? I'm pretty sure it used to be 24 hours until very recently. libguestfs builds take about 2 hours. http://koji.fedoraproject.org/koji/taskinfo?taskID=4194291 http://koji.fedoraproject.org/koji/taskinfo?taskID=4194635 http://koji.fedoraproject.org/koji/taskinfo?taskID=4194539 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 25, 2012, at 12:22 PM, Jay Sulzberger wrote: > > The main error of the Surrender before Engagement Argument is: > > 1. to implicitly assume that the "issue" is smaller than it is > > The situation is quite different: > > If we do not here and now stand and fight, likely we will shortly > lose the right to own a computer. > The issue is so large that it is absurd to allow a small group of > engineers from Fedora to engage in secret negotiations with the > Englobulators about the issue. The small team is not empowered > by me, nor by millions of others, to give away our present > practical power to install Fedora on a new x86 home computer by > putting in a CD, and setting some values in some configuration > files. > > As of today Red Hat has formally agreed that Microsoft should be > given an absolute veto power over ease of installation of a free > OS on almost all x86 home computer sold, starting within six months. Lacking both reason and logic, this line of argument is ad hominem. My diplomatic response is that you're suffering from psychosis, as in, divorced from reality. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy wrote: > I'm reading they're going to use a modified Intel efilinux, not writing a new > boot loader. And that they will not require either signed kernel or kernel > modules. Thats my understanding. > So what's the point of Secure Pre-Boot? Making Ubuntu work on the hardware people have. Which is the justification given here why Fedora needed to adopt crytographic signing of the kernel/drivers/etc. I think this all would have been a much simpler matter if it wasn't being described as essential for keeping Fedora operable on the computers of the common folk. Of course, users who want more aggressive secureboot would be free to replace the keys in their system with ones which only sign bootloaders which are more thoroughly locked down… but I don't see evidence of the demand. (can you point to some?) > I think for at least 9 months now the idea of a strictly pre-boot > implementation of Secure Boot is possible, but meaningless to the point of > "WTF, why bother?" with the effort required. It's like building a bridge > that's 80% complete, and therefore 100% useless. And the kernel hands off control to a init/systemd which is unsigned— which can be rooted and exploit a vulnerable kernel to prevent updates. It's like building a bridge that is _10%_ complete, and therefore 100% useless. :) … the amount of critical userspace code that runs before updates can be processed is enormous and the kernel and bootloader is just a tiny fraction of that. Why not build the 100% bridge that actually provides a remotely secured platform? Because it's incompatible with software freedom. Central control is Microsoft's strength, not Fedora's. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-25 at 14:10 -0400, Gregory Maxwell wrote: > On Mon, Jun 25, 2012 at 1:56 PM, Peter Jones wrote: > > I feel like this is quite patronizing. We've stated time and again that we > > don't believe the scenario you're preaching has any real /viability/, and > > Sounds like you're not arguing with me, you're arguing with Canonical. That's disingenuous. You were the one that brought it up here, it's entirely fair to respond to you. > I didn't propose this, the only stuff I proposed fit within the > invariants you set out: That the rules of the game required you to > restrict the system thusly if Fedora was to boot at all. The constraint is not "to boot at all", it's "to boot without needing to reconfigure SB". > And as a result it appears that they have a plan > which will make a better stand for software freedom while > simultaneously satisfying the PR interest of "not capitulating to > Microsoft", for whatever value that has. Calculon: And you say you can guarantee me an Oscar? Bender: I can guarantee you anything you want! > > so we've chosen not to propose it. There's no secret here - it's possible > > to do, but we don't think it'd last very long before our keys are > > I'm looking for a message where anyone said "we could do this, but we > expect our keys would eventually be blacklisted" can you help me out? I really feel you're being intentionally dense. Revocation of the ability to execute known malware vectors is the entire point of the Secure Boot exercise. If the signing authority wasn't willing to issue revocations, they'd be failing at their own stated goal. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 25, 2012, at 12:48 PM, Gregory Maxwell wrote: > > >> So what's the point of Secure Pre-Boot? > > Making Ubuntu work on the hardware people have. Which is the > justification given here why Fedora needed to adopt crytographic > signing of the kernel/drivers/etc. That does not answer the question. Ubuntu would work on Secure Boot hardware if they recommended users disable Secure Boot. So why not recommend that, and not support Secure Boot at all? Again, what is the point of Secure Pre-Boot? > And the kernel hands off control to a init/systemd which is unsigned— > which can be rooted and exploit a vulnerable kernel to prevent > updates. It's like building a bridge that is _10%_ complete, and > therefore 100% useless. :) So you have located a vulnerability in SELinux or systemd? And you have an exploit example? The expectation is that even Secure Boot will be broken, but will be fixed. You seem to be using the logic that because something has vulnerability potential, it should not be used. This is absurd. The way it works is we do our best, and fill the holes as needed. There is necessarily a transition from signed binaries, to containment unless the entire OS, programs, apps are going to be signed, so I don't think it's a remarkable hypothetical that there may one day be a vulnerability in systemd found. But that is not a reason to say, OK Secure Boot is totally pointless. It gets used for what it can be used for, then transition to something else. And if you have something more than a hypothetical vulnerability today in SELinux or systemd, presumably you've filed a bug. > Why not build the 100% bridge that actually > provides a remotely secured platform? Because it's incompatible with > software freedom. Central control is Microsoft's strength, not > Fedora's. I observe that this sequence is extremely low signal to noise, poor rationale, and high on derangement. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Term-Animation ownership changed
Package perl-Term-Animation in Fedora 15 was orphaned by lbazan To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Term-Animation -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 3:28 PM, Chris Murphy wrote: > That does not answer the question. Ubuntu would work on Secure Boot hardware > if they recommended users disable Secure Boot. So why not recommend that, and > not support Secure Boot at all? I advocated that. It was argued here that this would be an enormous barrier to usability because common users couldn't figure out how to do that, doubly so because there would be no consistency in the fancy GUI UEFI interfaces, and asking people to disable "security" is likely to scare them even if we could manage good instructions. It was also pointed out that some hardware in the future may not allow it. > So you have located a vulnerability in SELinux or systemd? And you have an > exploit example? Absent those vulnerabilities you don't need secureboot at all. Just use SElinux to prevent the userspace from changing the boot enviroment. The signing only helps if the discretionary access control is already compromised— it helps you get the horse back in the barn, but only if enough of the system is protected by it. In Fedora the kernel+bootloader isn't enough. It's a strict subset it helps with. ... I expect this is part of the reason that we've seen no one requesting this functionality. Can you point me to a bugzilla entry or even a mailing list post on a compromise this actually would have blocked, preferably one that couldn't have been closed without complicating replacing the kernel. > I observe that this sequence is extremely low signal to noise, poor > rationale, and high on derangement. Derangement. Hm. Could you actually _feel_ the excellence flowing through your fingertips as you typed out this message? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
Bruno Wolff III writes: >Tom Lane wrote: >> See also bug #832029 before being in too much of a hurry to decide that >> this Must Be A Good Thing. At minimum, it currently seems that we might >> need per-service tuning of the restart timing parameters before being >> sure that enabling restart is safe. So while recommending that services >> enable this after suitable testing *might* be a good idea, turning it on >> by default seems like a horribly bad one. > Since 832029 is not a public bug, can you give the gist of the issue? Ah, sorry about that. The deal is that mysqld has historically been automatically restarted after crashes by a supervisor script mysqld_safe. When we went over to systemd-land we said "hey, systemd can do that, and we'll have one less process required". However, it's not working so well: (1) systemd is not able to distinguish a crash that should be restarted from, say, failure due to misconfiguration in /etc/my.cnf. (It's not clear whether restart settings other than "always" would help here, but in general it seems obvious that there are likely to be service- specific reasons for restarting after some failures and not others.) (2) Right now it appears that there is a bug in systemd that causes it to ignore its respawn limits, such that if mysqld is indeed exiting immediately due to misconfiguration, it gets restarted immediately. Lather, rinse, repeat. Indefinitely. (3) Even if StartLimitInterval/StartLimitBurst were operating properly, there are scenarios where mysqld will fail to start up, but be slow enough about it (like a couple of seconds) that systemd's respawn suppression logic would not get triggered, so it'd keep on restarting it. So we'd probably need custom-tuned values of those settings if we decide to stay with using systemd for restart logic. I assume that (2) is just a bug that's going to get fixed pretty quick. But (1) and (3) seem like likely risk spots for other services. In the meantime I'm seriously considering reverting to mysqld_safe. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
On Mon, 25 Jun 2012, Tom Lane wrote: Subject: Re: service restart question (1) systemd is not able to distinguish a crash that should be restarted (2) Right now it appears that there is a bug in systemd that causes it to ignore its respawn limits (3) Even if StartLimitInterval/StartLimitBurst were operating properly, there are scenarios where mysqld will fail to start up, but be slow enough about it (like a couple of seconds) that systemd's respawn suppression logic would not get triggered, so it'd keep on restarting In the meantime I'm seriously considering reverting to mysqld_safe. Good to know, because I was thinking about the same thing for openswan's wrapper script. It's a little more complicated there because it supports an option plutorestartoncrash=yes|no. It's really nice for dev's to not get a chain reaction of cores, but in production we really want it to always restart. I was hoping systemd would support that properly for all daemons now via generic options. I'll keep an eye on this issue, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
Paul Wouters (pwout...@redhat.com) said: > On Mon, 25 Jun 2012, Tom Lane wrote: > > >Subject: Re: service restart question > > >(1) systemd is not able to distinguish a crash that should be restarted > > >(2) Right now it appears that there is a bug in systemd that causes > >it to ignore its respawn limits > > >(3) Even if StartLimitInterval/StartLimitBurst were operating properly, > >there are scenarios where mysqld will fail to start up, but be slow > >enough about it (like a couple of seconds) that systemd's respawn > >suppression logic would not get triggered, so it'd keep on restarting > > >In the meantime I'm seriously considering reverting to mysqld_safe. > > Good to know, because I was thinking about the same thing for openswan's > wrapper script. It's a little more complicated there because it supports > an option plutorestartoncrash=yes|no. It's really nice for dev's to not > get a chain reaction of cores, but in production we really want it to > always restart. I was hoping systemd would support that properly for all > daemons now via generic options. I think it's a safe option that systemd would *like* to support this without external helpers where possible. For your case, Restart=on-abort seems like what you want? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji jobs being killed after 68 minutes 30 seconds?
Mystery over. It seems the test is segfaulting, but that's not appearing in the build.log output. Thanks Dennis Gilmore for providing dmesg from the builder for me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 25 Jun 2012, Chris Murphy wrote: > On Jun 25, 2012, at 12:48 PM, Gregory Maxwell wrote: > > >> So what's the point of Secure Pre-Boot? > > Making Ubuntu work on the hardware people have. Which is the > justification given here why Fedora needed to adopt crytographic > signing of the kernel/drivers/etc. That does not answer the question. Ubuntu would work on Secure Boot hardware if they recommended users disable Secure Boot. So why not recommend that, and not support Secure Boot at all? Again, what is the point of Secure Pre-Boot? > And the kernel hands off control to a init/systemd which is unsigned??? > which can be rooted and exploit a vulnerable kernel to prevent > updates. It's like building a bridge that is _10%_ complete, and > therefore 100% useless. :) So you have located a vulnerability in SELinux or systemd? And you have an exploit example? The expectation is that even Secure Boot will be broken, but will be fixed. You seem to be using the logic that because something has vulnerability potential, it should not be used. This is absurd. The way it works is we do our best, and fill the holes as needed. There is necessarily a transition from signed binaries, to containment unless the entire OS, programs, apps are going to be signed, so I don't think it's a remarkable hypothetical that there may one day be a vulnerability in systemd found. But that is not a reason to say, OK Secure Boot is totally pointless. It gets used for what it can be used for, then transition to something else. And if you have something more than a hypothetical vulnerability today in SELinux or systemd, presumably you've filed a bug. > Why not build the 100% bridge that actually > provides a remotely secured platform? Because it's incompatible with > software freedom. Central control is Microsoft's strength, not > Fedora's. I observe that this sequence is extremely low signal to noise, poor rationale, and high on derangement. Chris Murphy Your use of the phrase "Secure Boot" is incorrect, and is, I think, the source of much confusion. Having a computer that only boots a Microsoft OS is not a case of "Secure Boot". Having a computer which you have installed Fedora on, and which Microsoft can remotely disable, is not a case of "Secure Boot". oo--JS> -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 10:02 +0200, Matej Cepl wrote: > On 21/06/12 16:54, Michal Schmidt wrote: > > http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ > > Is there some post-processing tool which would should me all packages > for which there is no reason? Brief look at the source of > packages-cleanup shows that --orphans isn't the one. You want the yumdb command in yum-utils. Eg. yumdb unset reason '*' signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 09:56 +0200, Matej Cepl wrote: > On 21/06/12 16:54, Michal Schmidt wrote: > > On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: > >> Michal Schmidt writes: > >>> We do now. You can set clean_requirements_on_remove=1 in yum.conf > >> > >> in which version that is supported? > > > > Since 3.2.28-13 > > http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ > > Mea culpa! I have missed "we weren’t using the ‘reason’ info we’re now > storing in the yumdb to know what is a dep and what is not" which is a > crucial piece of information. > > Then the curious minds ask ... why clean_requirements_on_remove = 1 > isn't a default? The main two main reasons we didn't just turn it on when written are: 1. New code in a pretty critical operation, needs to be tested a bunch first. 2. Lots of people would have installed packages without a reason set. ...both of which should be gone now, so we could turn it on by default in F18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 10:10 +0200, Nicolas Mailhot wrote:
> Le Jeu 21 juin 2012 14:23, Matej Cepl a écrit :
> > On 19/06/12 15:33, Ales Kozumplik wrote:
> >> Thanks for pointing this out. I considered history a candidate for
> >> dropping because I didn't realize people had usecases for it. It is not
> >> present in the early versions of DNF but I will make sure to put it back
> >> in later.
> >
> > Especially in the situation we have broken dependencies (because we
> > don't have Suggests/Recommends, but that's another issue, which I don't
> > want to open now) we don't have quality uninstall á la aptitude ("remove
> > this package and all packages which were installed just to satisfy its
> > requirements recursively") yum history undo is priceless in the
> > situation when you want to try a package just to find out it brings 50MB
> > of random crap.
>
> BTW if yum is being rewritten can we get a package downloader that sends the
> correct cache-control http headers to refresh data automatically instead of
> complaining metadata is wrong and aborting (for people behind a caching
> proxy)?
Unique metadata was the, much better, solution to this problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 2:48 PM, Gregory Maxwell wrote: > On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy wrote: >> I'm reading they're going to use a modified Intel efilinux, not writing a >> new boot loader. And that they will not require either signed kernel or >> kernel modules. > > Thats my understanding. > >> So what's the point of Secure Pre-Boot? > > Making Ubuntu work on the hardware people have. Which is the > justification given here why Fedora needed to adopt crytographic > signing of the kernel/drivers/etc. > > I think this all would have been a much simpler matter if it wasn't > being described as essential for keeping Fedora operable on the > computers of the common folk. > > Of course, users who want more aggressive secureboot would be free to > replace the keys in their system with ones which only sign bootloaders > which are more thoroughly locked down… but I don't see evidence of > the demand. (can you point to some?) It would appear that right now, it's a matter of a political necessity, unforeseen by the general population, though vaguely bugging the free software development community. I would agree there's not much demonstrated demand, but if we wait til the worst apprehensions come true, we will be at a disadvantage. The general population does not experience the problem that free software developers can more readily anticipate. >> I think for at least 9 months now the idea of a strictly pre-boot >> implementation of Secure Boot is possible, but meaningless to the point of >> "WTF, why bother?" with the effort required. It's like building a bridge >> that's 80% complete, and therefore 100% useless. > > And the kernel hands off control to a init/systemd which is unsigned— > which can be rooted and exploit a vulnerable kernel to prevent > updates. It's like building a bridge that is _10%_ complete, and > therefore 100% useless. :) > > … the amount of critical userspace code that runs before updates can > be processed is enormous and the kernel and bootloader is just a tiny > fraction of that. Why not build the 100% bridge that actually > provides a remotely secured platform? Because it's incompatible with > software freedom. I don't see this. If you choose an authority and can put their keys into your own box, then you're good until that authority is compromised. This, if I am tracking this correctly, is the infrastructure part of the solution. You just have to get out in front with the trusted authority. I would think that if FSF provided keys, that would be pretty trustworthy, though for the following reason I actually don't think they should be out front with this part, because they would clearly be targetted, and we wouldn't want that to happen until there was a developed market in trust authorities. It would not, of course, assure that all "content" and code could be processed freely, but it would create the context in which we could demonstrate that the authorities that provide palladiated "content" and code are restricting people's capacity to compute. Keep up providing authorities that assure software freedom -- do the whack a mole bit if necessary -- and that context will be the context that demonstrates to the people at large that there are people out there that have truly fully-functional computers and they want to have that too. This is not inconsistent with software freedom. You're going to have a root key. If it's your own, you can't do much unless you buy into the englobulators' signing regime; if you want to do more, you have to create some sort of collaborative context that uses a common trusted key. We might have lots of little groups like that, but they will not be able to stand up against the political norms we can easily anticipate being established if we do not come to terms with how to make software freedom viable while using Secure Boot our own selves. So to me that clearly indicates a *political* need for developers who want to keep their freedom, to get out in front and *create* a market in trusted authorities. If your idea of software freedom is decentralized in some sort of resolutely individualistic way, you'll be locked out by the larger forces. That's why it's necessary to get out in front ad establish the infrastructure, and get people offering lots of trust authorities, start trying to conceptualize that market and how and whether it would be competitive. This is the way I see the situation; I feel that I step a bit beyond my expertise or comprehension as I describe it, so somebody please tell me if my conception misses anything. I defer to Jay usually for this very reason. So have at it: let me know what you see when you see me explain this piece of the puzzle. :-) Seth > Central control is Microsoft's strength, not > Fedora's. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproje
Re: F18 DNF and history
On 25/06/12 23:04, James Antill wrote: yumdb unset reason '*' Thanks ... results are interesting. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
inode0 wrote: > The "quota" for these would need to be much higher already as the > Multi-Desktop is now 6.1GB The Multi Desktop Live DVD is dual-layer, it's not expected to fit 4.7 GB. But dual-layer DVDs also have a finite capacity. ;-) So we can allow each spin to grow to a certain extent, but not to an arbitrarily high size or to a full DVD. We need "arbitrary" quota which sum up to at most the size of a dual-layer DVD. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Adam Williamson wrote: > I don't believe there's currently any requirement that target sizes > match some form of physical media. So far they always _have_, but if > there's a requirement that they _must_, I've never seen it. It might have been a misunderstanding, but I read Jóhann B. Guðmundsson as proposing such a requirement (which would IMHO be a bad idea). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 25 Jun 2012, Seth Johnson wrote: > On Mon, Jun 25, 2012 at 2:48 PM, Gregory Maxwell wrote: > On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy wrote: >> I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules. > > Thats my understanding. > >> So what's the point of Secure Pre-Boot? > > Making Ubuntu work on the hardware people have. Which is the > justification given here why Fedora needed to adopt crytographic > signing of the kernel/drivers/etc. > > I think this all would have been a much simpler matter if it wasn't > being described as essential for keeping Fedora operable on the > computers of the common folk. > > Of course, users who want more aggressive secureboot would be free to > replace the keys in their system with ones which only sign bootloaders > which are more thoroughly locked down??? ??but I don't see evidence of > the demand. (can you point to some?) It would appear that right now, it's a matter of a political necessity, unforeseen by the general population, though vaguely bugging the free software development community. I would agree there's not much demonstrated demand, but if we wait til the worst apprehensions come true, we will be at a disadvantage. The general population does not experience the problem that free software developers can more readily anticipate. >> I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless. > > And the kernel hands off control to a init/systemd which is unsigned??? > which can be rooted and exploit a vulnerable kernel to prevent > updates. ??It's like building a bridge that is _10%_ complete, and > therefore 100% useless. :) > > ??? the amount of critical userspace code that runs before updates can > be processed is enormous and the kernel and bootloader is just a tiny > fraction of that. ??Why not build the 100% bridge that actually > provides a remotely secured platform? Because it's incompatible with > software freedom. I don't see this. If you choose an authority and can put their keys into your own box, then you're good until that authority is compromised. This, if I am tracking this correctly, is the infrastructure part of the solution. You just have to get out in front with the trusted authority. I would think that if FSF provided keys, that would be pretty trustworthy, though for the following reason I actually don't think they should be out front with this part, because they would clearly be targetted, and we wouldn't want that to happen until there was a developed market in trust authorities. It would not, of course, assure that all "content" and code could be processed freely, but it would create the context in which we could demonstrate that the authorities that provide palladiated "content" and code are restricting people's capacity to compute. Keep up providing authorities that assure software freedom -- do the whack a mole bit if necessary -- and that context will be the context that demonstrates to the people at large that there are people out there that have truly fully-functional computers and they want to have that too. This is not inconsistent with software freedom. You're going to have a root key. If it's your own, you can't do much unless you buy into the englobulators' signing regime; if you want to do more, you have to create some sort of collaborative context that uses a common trusted key. We might have lots of little groups like that, but they will not be able to stand up against the political norms we can easily anticipate being established if we do not come to terms with how to make software freedom viable while using Secure Boot our own selves. So to me that clearly indicates a *political* need for developers who want to keep their freedom, to get out in front and *create* a market in trusted authorities. If your idea of software freedom is decentralized in some sort of resolutely individualistic way, you'll be locked out by the larger forces. That's why it's necessary to get out in front ad establish the infrastructure, and get people offering lots of trust authorities, start trying to conceptualize that market and how and whether it would be competitive. This is the way I see the situation; I feel that I step a bit beyond my expertise or comprehension as I describe it, so somebody please tell me if my conception misses anything. I defer to Jay usually for this very reason. So have at it: let me know what you see when you see me explain this piece of the puzzle. :-) Seth I will not address directly any particular point in this branch of the thread, but I have some questions about what sort of capabilities the UEFI will have in machines sold later this year: 1. What is the mech
Re: Couldn't we enable 256 colors by default on TERM?
We discussed this in fesco today and had a couple of concerns. The primary one was that handling this in profile seemed a bit fragile. It seems like it would be more "correct" to have the terminals explicitly set xterm-256 themselves if they're capable of it, rather than assuming things about the binaries that a user may have installed. It's a little more work, although not a great deal - by the looks of it vte sets this itself, so a single patch would handle most of the GTK cases. Thoughts? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, Jun 25, 2012 at 09:14:54PM -0400, Jay Sulzberger wrote: > These questions are asked so that I may better lay out some > actual security considerations in a later post. http://www.uefi.org/specs/download/UEFI_2_3_1_Errata_B.pdf sections 27.6, 27.7 and 27.8, along with 7.2 for an overview of authenticated variables. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/25/2012 09:14 PM, Jay Sulzberger wrote: [...] I have some questions about what sort of capabilities the UEFI will have in machines sold later this year: 1. What is the mechanism for remote revocation of signing keys? There's 2 mechanisms here. The first is a key list called DBX. This is just a list of public keys that's checked before DB (the allowed key list). Any key on DBX isn't allowed to boot up. The second mechanism is a facility for signed updates. Basically, you can do a SetVariable() call to append to DBX, and the call parameters must be signed by the KEK. If the appended data isn't signed, or is signed by a key other than the KEK, you get an error code. There's actually a third mechanism, of course, which is that the firmware can add keys, so if you apply a firmware update (which also undergo cryptographic verification), the firmware could add a key on the next reboot. 2. In particular, will the UEFI be able to revoke, at the command of Hardware Key Central, signing keys without a standard (style of) kernel being booted? That is, can the UEFI receive commands over the Net using its own network capabilities? There's no mechanism for automatic network updates or anything like that in the standard, though a UEFI binary run from the firmware could apply an update if it's signed by the KEK. 3. If booting a standard style of kernel is required to revoke, at the command of Hardware Key Central, signing keys, then the standard kernel must be capable of receiving and interpreting such commands, Well, the kernel wouldn't really be the responsible code here. Most likely we'll make that a package update and use rpm %post scripts to apply changes. and also be capable of modifying the memory of the UEFI hardware. No, we don't have this ability. The spec defines this in some general terms, but on x86, here's the basic mechanism. From userland, we set a UEFI variable, using a mechanism such as the existing "efivars" facility. It has flags set to append to the DBX variable, and also a flag that says it's an authenticated variable. It also includes the signed data. The kernel then calls UEFI's runtime services function "SetVariable()", at which point in time firmware code is running again. This code calls the into SMM mode, which is a special processor mode that's always been available on x86, and has been used in the past for many things. At this point the processor signals to the chipset that you're in SMM mode, at which point the chipset makes the flash available. This is also the point at which the signature is validated. If the signature is valid, the write happens on the flash. If it's not, it stores a return code and exits SMM, which as a bi-product blocks our access to the memory in question. That all propagates back up and we get a success or failure from SetVariable(). How will the Englobulators ensure that every signed-by-Microsoft Red Hat kernel will take orders from Hardware Key Central? Note I assume here that Hardware Key Central is controlled by the Englobulators. I don't know what an Englobulator is. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
Once upon a time, Matthew Garrett said: > We discussed this in fesco today and had a couple of concerns. The > primary one was that handling this in profile seemed a bit fragile. It > seems like it would be more "correct" to have the terminals explicitly > set xterm-256 themselves if they're capable of it, rather than assuming > things about the binaries that a user may have installed. It's a little > more work, although not a great deal - by the looks of it vte sets this > itself, so a single patch would handle most of the GTK cases. > > Thoughts? That would make a lot more sense to me - TERM is set by the terminal program to communicate its functionality to the shell and child programs. The shell init (profile) scripts should not change that because they "know better"; if the terminal supports 256 colors, it should set an appropriate TERM value to indicate that. You should basically _never_ override TERM unless you really know what you are doing. For example, when SSHing to something with a smaller terminal info database, you might override TERM with a value known to be a subset of the current TERM, such as replacing xterm-256color with xterm. Otherwise, you should leave it alone. Trying to do this in profile scripts assumes that you only run local terminals that come from Fedora and that have been tested. For example, if you SSH to a Fedora box from an old xterm that doesn't do 256 colors, what happens if profile automagically turns xterm into xterm-256color? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Mon, Jun 25, 2012 at 6:53 PM, Kevin Kofler wrote: > inode0 wrote: >> The "quota" for these would need to be much higher already as the >> Multi-Desktop is now 6.1GB > > The Multi Desktop Live DVD is dual-layer, it's not expected to fit 4.7 GB. > But dual-layer DVDs also have a finite capacity. ;-) So we can allow each > spin to grow to a certain extent, but not to an arbitrarily high size or to > a full DVD. We need "arbitrary" quota which sum up to at most the size of a > dual-layer DVD. Right. We should note also that there is no requirement that the Multi Desktop include the desktops that it currently includes. Right now it includes 5 desktops and while I hope it can continue to include all 5 there is no requirement for it to. And it really would not be the end of the world for the Multi Desktop to not be dual architecture in the future, this is convenient but at some point 32 bit will be dropped anyway and it could just be split into arch specific DVDs if necessary. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On Mon, Jun 25, 2012 at 08:47:16PM -0500, Chris Adams wrote: > Trying to do this in profile scripts assumes that you only run local > terminals that come from Fedora and that have been tested. For example, > if you SSH to a Fedora box from an old xterm that doesn't do 256 colors, > what happens if profile automagically turns xterm into xterm-256color? The proposal actually handles that by parsing the output of the who command, but I'm not sure I'm morally in favour of that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 26 Jun 2012, Matthew Garrett wrote: > On Mon, Jun 25, 2012 at 09:14:54PM -0400, Jay Sulzberger wrote: > These questions are asked so that I may better lay out some > actual security considerations in a later post. http://www.uefi.org/specs/download/UEFI_2_3_1_Errata_B.pdf sections 27.6, 27.7 and 27.8, along with 7.2 for an overview of authenticated variables. -- Matthew Garrett | mj...@srcf.ucam.org Thanks! oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 11:22 AM, Tom London wrote:
> On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta wrote:
>> On Mon, Jun 25, 2012 at 5:36 AM, Tom London wrote:
>>> Hmm... Still seeing spew:
>>> Here is what I did:
>>>
>>> 1. I 'rpm -Uvh --force' the new package.
>>> 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had
>>> saved them by moving them to revelation.old before updating/testing
>>> with the previous test build).
>>> 3. I rebooted and started revelation
>>> 4. Edit->Preferences
>>>
>>> I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and
>>> reboot/etc. it will work...
>>
>> I'd image the problem in your steps is the fact that you did 2 after 1.
>> Get your system into the old state with the old 0.4.11 revelation
>> update to new rpm
>> logout/log back in.
>> tracebacks should stop.
>>
>> I've tested this on a couple of systems now.
>>
>>
>> -jef
>>
>>
>
> Oops Sorry for the fumble.
>
> Will redo and report tonight.
>
> tom
> --
> Tom London
Must be something 'interesting' about my conf files This still fails for me:
Traceback (most recent call last):
File "/usr/bin/revelation", line 206, in
action.connect("activate", lambda w: self.prefs())
File "/usr/bin/revelation", line 1527, in prefs
dialog.run_unique(Preferences, self, self.config)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1324, in run_unique
d = create_unique(dialog, *args)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1282, in create_unique
UNIQUE_DIALOGS[dialog] = dialog(*args)
File "/usr/bin/revelation", line 1623, in __init__
self.__init_section_password(self.page_general)
File "/usr/bin/revelation", line 1762, in __init_section_password
ui.config_bind(self.config, "passwordgen/punctuation",
self.check_punctuation_chars)
File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line
182, in config_bind
id = cfg.monitor(key, cb_get, widget)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
150, in monitor
callback(key, self.get(key), userdata)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
129, in get
raise ConfigError
ConfigError
I copied my 'old' conf files from a backup, reinstalled via 'rpm -Uvh
--force', rebooted, and started revelation.
Something useful I can do? (or just blow the conf dir away?)
tom
--
Tom London
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
Once upon a time, Matthew Garrett said: > On Mon, Jun 25, 2012 at 08:47:16PM -0500, Chris Adams wrote: > > Trying to do this in profile scripts assumes that you only run local > > terminals that come from Fedora and that have been tested. For example, > > if you SSH to a Fedora box from an old xterm that doesn't do 256 colors, > > what happens if profile automagically turns xterm into xterm-256color? > > The proposal actually handles that by parsing the output of the who > command, but I'm not sure I'm morally in favour of that. That wasn't there when I checked before my email, so I didn't know that. It sounds like adding one hack on top of another; trying to parse the output of a command not documented to have a fixed specific format is an even worse idea IMHO. The terminal program has very few standard ways to communicate information to programs running in it: - the TERM environment variable - TTY settings (i.e. erase, rows, columns) - answer-back escape sequences Trying to use anything outside of that data is a bad idea. Trying to divine anything else (or just ignore it and assume you know better) is bound to fail. What if another terminal program comes along that only emulates "traditional" xterm (with only 8 colors)? How does a profile script know that everything that says "xterm" can do 256 colors? Or put it another way: why shouldn't this go in the terminal programs that support 256 colors? That way they can be tested, and if any one of them has a problem, the change can be reverted for just that one (while the rest that work correctly get the benefit of 256 colors). I'm also always looking to avoid having more programs automatically run at the start of a login. If you've ever had to deal with logging into an overloaded system, the last thing you want is a profile script doing "who" and "grep" just to try to override the TERM variable to make it prettier. I'd like to see less of that, not more. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 25 Jun 2012, Peter Jones wrote: On 06/25/2012 09:14 PM, Jay Sulzberger wrote: [...] I have some questions about what sort of capabilities the UEFI will have in machines sold later this year: 1. What is the mechanism for remote revocation of signing keys? There's 2 mechanisms here. The first is a key list called DBX. This is just a list of public keys that's checked before DB (the allowed key list). Any key on DBX isn't allowed to boot up. The second mechanism is a facility for signed updates. Basically, you can do a SetVariable() call to append to DBX, and the call parameters must be signed by the KEK. If the appended data isn't signed, or is signed by a key other than the KEK, you get an error code. There's actually a third mechanism, of course, which is that the firmware can add keys, so if you apply a firmware update (which also undergo cryptographic verification), the firmware could add a key on the next reboot. Is there a hardware switch or jumper that can be set so that no modification of the firmware is possible? My question here is: if I have gross physical possession of the hardware can I disable firmware updates done just via code running on the x86/UEFI chips? 2. In particular, will the UEFI be able to revoke, at the command of Hardware Key Central, signing keys without a standard (style of) kernel being booted? That is, can the UEFI receive commands over the Net using its own network capabilities? There's no mechanism for automatic network updates or anything like that in the standard, though a UEFI binary run from the firmware could apply an update if it's signed by the KEK. Will the UEFI be able to send and receive information over a local network, say via Ethernet? That is, without an old fashioned "kernel" being booted. By "old fashioned" I mean something like the Linux kernel, which, I think runs, usually, in a "space" different from the space where UEFI code runs? 3. If booting a standard style of kernel is required to revoke, at the command of Hardware Key Central, signing keys, then the standard kernel must be capable of receiving and interpreting such commands, Well, the kernel wouldn't really be the responsible code here. Most likely we'll make that a package update and use rpm %post scripts to apply changes. I will attempt to think about this. and also be capable of modifying the memory of the UEFI hardware. No, we don't have this ability. The spec defines this in some general terms, but on x86, here's the basic mechanism. From userland, we set a UEFI variable, using a mechanism such as the existing "efivars" facility. It has flags set to append to the DBX variable, and also a flag that says it's an authenticated variable. It also includes the signed data. The kernel then calls UEFI's runtime services function "SetVariable()", at which point in time firmware code is running again. This code calls the into SMM mode, which is a special processor mode that's always been available on x86, and has been used in the past for many things. At this point the processor signals to the chipset that you're in SMM mode, at which point the chipset makes the flash available. This is also the point at which the signature is validated. If the signature is valid, the write happens on the flash. If it's not, it stores a return code and exits SMM, which as a bi-product blocks our access to the memory in question. That all propagates back up and we get a success or failure from SetVariable(). So, if I have understood (part of) your explanation, the x86 processor must run in order to modify the contents of the flash memory used by the UEFI to hold various tables, including the DBX table. I will attempt to think about this. How will the Englobulators ensure that every signed-by-Microsoft Red Hat kernel will take orders from Hardware Key Central? Note I assume here that Hardware Key Central is controlled by the Englobulators. I don't know what an Englobulator is. Ah, here a long and bulbous discussion threatens to obtrude. -- Peter One more question today: I know that UEFI hardware is available. Which hardware do you recommend, if I want to actually see the UEFI and perhaps try it out? Thank you, Peter! oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/25/2012 11:08 PM, Jay Sulzberger wrote: Is there a hardware switch or jumper that can be set so that no modification of the firmware is possible? My question here is: if I have gross physical possession of the hardware can I disable firmware updates done just via code running on the x86/UEFI chips? There's no real guarantee that any particular machine will have any physical switch, but that doesn't mean you can't just /not run/ the software that does the updates. Will the UEFI be able to send and receive information over a local network, say via Ethernet? That is, without an old fashioned "kernel" being booted. By "old fashioned" I mean something like the Linux kernel, which, I think runs, usually, in a "space" different from the space where UEFI code runs? Some vendor's firmware could, in theory, do that. It's not part of the spec. 3. If booting a standard style of kernel is required to revoke, at the command of Hardware Key Central, signing keys, then the standard kernel must be capable of receiving and interpreting such commands, Well, the kernel wouldn't really be the responsible code here. Most likely we'll make that a package update and use rpm %post scripts to apply changes. I will attempt to think about this. I hope everything comes out okay. I know that UEFI hardware is available. Which hardware do you recommend, if I want to actually see the UEFI and perhaps try it out? I'm really, *really* not in the business of recommending hardware. There are various sites on the internet that do that exclusively. One of them has probably figured out that they should be thinking about UEFI by now. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 25 Jun 2012, Peter Jones wrote: On 06/25/2012 11:08 PM, Jay Sulzberger wrote: Is there a hardware switch or jumper that can be set so that no modification of the firmware is possible? My question here is: if I have gross physical possession of the hardware can I disable firmware updates done just via code running on the x86/UEFI chips? There's no real guarantee that any particular machine will have any physical switch, but that doesn't mean you can't just /not run/ the software that does the updates. Will the UEFI be able to send and receive information over a local network, say via Ethernet? That is, without an old fashioned "kernel" being booted. By "old fashioned" I mean something like the Linux kernel, which, I think runs, usually, in a "space" different from the space where UEFI code runs? Some vendor's firmware could, in theory, do that. It's not part of the spec. 3. If booting a standard style of kernel is required to revoke, at the command of Hardware Key Central, signing keys, then the standard kernel must be capable of receiving and interpreting such commands, Well, the kernel wouldn't really be the responsible code here. Most likely we'll make that a package update and use rpm %post scripts to apply changes. I will attempt to think about this. I hope everything comes out okay. ;) I know that UEFI hardware is available. Which hardware do you recommend, if I want to actually see the UEFI and perhaps try it out? I'm really, *really* not in the business of recommending hardware. There are various sites on the internet that do that exclusively. One of them has probably figured out that they should be thinking about UEFI by now. -- Peter Peter and Matthew, thanks again, for your time and effort given to explain things. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Mon, 2012-06-25 at 23:31 -0400, Peter Jones wrote: > > I know that UEFI hardware is available. > > > > Which hardware do you recommend, if I want to actually see the > > UEFI and perhaps try it out? > > I'm really, *really* not in the business of recommending hardware. There > are various sites on the internet that do that exclusively. One of them has > probably figured out that they should be thinking about UEFI by now. To elaborate, there still seems to be an unwarranted confusion between UEFI and Secure Boot going on here. UEFI-based hardware is available right now and has been for some time. I am typing this on a system with UEFI firmware. Many many systems shipped today are using UEFI-based firmware, though often the copy of Windows that's pre-installed is BIOS-native not UEFI-native, and often the firmware will default to booting other media in BIOS compatibility mode and will only use native UEFI if explicitly instructed to. Secure Boot is a single feature of a later version of the UEFI spec. To my knowledge, no hardware currently generally available is Secure Boot-enabled. Peter, Matthew etc. are all working with pre-production development firmware. Presumably, updates could be shipped which add Secure Boot functionality to already-shipped hardware, I don't know if there are any plans for that. But you cannot, right now, go out and buy hardware that has Secure Boot functionality off the shelf. It's just not there. If you're really interested just in playing with UEFI itself - like Peter I'm not a hardware recommendation site, but I use an Asus P8P67 Deluxe for my UEFI testing, and it's at least capable of successfully booting and installing Fedora UEFI native. I don't know if this is true of later Asus motherboards. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 09:59:55PM -0800, Jef Spaleta wrote:
> On Sun, Jun 24, 2012 at 9:50 PM, Pierre-Yves Chibon
> wrote:
> > I had a number of problem with guake and its gconf schema, so after
> > discussion here I added this to the spec file:
> >
> > %posttrans
> > killall -HUP gconfd-2 > /dev/null || :
> >
> > That pretty much forces gconf to reload.
>
>
> Uhm has this been vetted as not "a bad thing" {tm} by the packaging
> thinktank?
>
The killall was in (very? it's all relative :-) old versions of the
packaging guidelines. At some point it was tested to be unnecessary
anymore. If the scriptlets don't work without it, it's probably a bug in
the GConf2 package. Using the killall in scriptlets would be an okay
workaround (but might have some rpm-update-performance ramifications).
-Toshio
pgpIwSyROddSa.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
