Re: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On Fri, 2013-03-08 at 01:38 +0200, Yanko Kaneti wrote: On Thu, 2013-03-07 at 22:03 +0100, Michael Schwendt wrote: The Yum changelog is not detailed enough to tell, If I may. The handling of both this and the bundled presto^Wdeltrarpm new yum ..features on the part of the current yum developers is disappointing. This was supposed to be a bugfix fix, or minor feature, where we showed a problem that existed. As for deltrarpm ... we've moved mature features into core yum a number of times, after they've been field tested as a plugin, and not something I'd term. a significant user change. If you want to see yum change information on that level, you probably want to subscribe to some of the yum mailing lists. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On 10 Mar 2013 16:53, Ian Pilcher arequip...@gmail.com wrote: On 03/09/2013 12:08 PM, Kevin Fenzi wrote: So, I am going to retire this package in rawhide soon unless there's folks with a very strong C++ background wishing to fix issues and basically become the new upstream. Does Fedora currently have a functional soft-phone? Ekiga. Its fairly full featured and while a bit quiet for a few years its picking up steam again. I'm the fedora maintainer and upstream are pretty responsive to bug reports. Peter -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. -- 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: Non responsive state for systemd
On 11 Mar 2013 02:30, Kevin Kofler kevin.kof...@chello.at wrote: Lennart Poettering wrote: True thing. libselinux is a library we really really should avoid linking against. Why the sarcasm? SELinux and libselinux only ever cause problems, why can't we finally kick them out of Fedora? Really? I find used properly on my server systems they fix more problems than they ever cause and its easy enough to disable them at which point they cause very little problem. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
On Mon, 11 Mar 2013 00:07:36 +0100, Sergio Pascual wrote: Hi, I did repoquery --repofrompath=this, http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS--repoid=this --archlist=src --whatrequires cfitsio-devel Huh? You treat it like a static library. More in my reply to Kevin's reply elsewhere in this thread. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
On Mon, 11 Mar 2013 04:55:06 +0100, Kevin Kofler wrote:
Sergio Pascual wrote:
cfitsio function fits_open_file checks at runtime if the version of
cfistio used during compile is the same version used at runtime. If not,
the program aborts. So every program linked with cfitsio must be
recompiled.
That's a totally broken versioning system, the soname needs to be bumped
instead.
That soname is added by a patch in the Fedora package. :-/
Bad idea to begin with, if the library performs such a run-time check.
A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
It would enforce rebuilds whenever the version changes, and due to lack
of symbol versioning, it would also make the automatic soname dependency
in (re)builds against updates of cfitsio more strict (since they might
depend on added symbols).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-03-11 @ ** 15:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-03-11 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again tomorrow / today! Please note the time: as clocks went forward in most places today, the meeting will now be at 15:00 UTC. That should be the same local time as always for most people, but if you don't observe daylight savings or the daylight savings change happens on a different day in your time zone, the meeting may be an hour earlier than usual for you - please check! This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130311 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 19 schedule 3. Test Days 4. Criteria re-design 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
The versioned soname seems a good idea. I will change the soname to
libcfitsio-%{version}.so.0
2013/3/11 Michael Schwendt mschwe...@gmail.com
On Mon, 11 Mar 2013 04:55:06 +0100, Kevin Kofler wrote:
Sergio Pascual wrote:
cfitsio function fits_open_file checks at runtime if the version of
cfistio used during compile is the same version used at runtime. If
not,
the program aborts. So every program linked with cfitsio must be
recompiled.
That's a totally broken versioning system, the soname needs to be bumped
instead.
That soname is added by a patch in the Fedora package. :-/
Bad idea to begin with, if the library performs such a run-time check.
A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
It would enforce rebuilds whenever the version changes, and due to lack
of symbol versioning, it would also make the automatic soname dependency
in (re)builds against updates of cfitsio more strict (since they might
depend on added symbols).
--
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
f18-64: Video Resolution problem on a netbook ASUS 1225C-GRY015U
Hi, I have buy this Asus netbook with Ubuntu pre-installed: ASUS 1225C-GRY015U http://www.monclick.it/schede/asus/1225C-GRY015U/1225c-gry015u.htm With a Video integrate VGA compatible controller Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09) and driver gma500 (see below lspci and lshw) At the first power on, I do not have start Ubuntu, then do not know if the problem (see below) there is with Ubuntu, but I have install straightaway Fedora 18 64 bit. After install and update f18 (kernel 3.8.2-206.fc18.x86_64), I have try to work into Gnome 3.6, but the video performance are very slow and gnome-shell use too many CPU : top - 10:30:02 up 5 min, 3 users, load average: 1,50, 1,19, 0,56 Tasks: 163 total, 2 running, 161 sleeping, 0 stopped, 0 zombie %Cpu0 : 59,5 us, 3,9 sy, 0,0 ni, 34,0 id, 0,0 wa, 1,6 hi, 1,0 si, 0,0 st %Cpu1 : 58,8 us, 2,6 sy, 0,0 ni, 37,0 id, 0,0 wa, 1,3 hi, 0,3 si, 0,0 st %Cpu2 : 71,7 us, 9,1 sy, 0,0 ni, 17,3 id, 0,0 wa, 1,6 hi, 0,3 si, 0,0 st %Cpu3 : 63,5 us, 5,2 sy, 0,0 ni, 29,3 id, 0,0 wa, 1,6 hi, 0,3 si, 0,0 st KiB Mem: 2039580 total, 942292 used, 1097288 free,30068 buffers KiB Swap: 4095996 total,0 used, 4095996 free, 439180 cached pid to signal/kill PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1706 lesca 20 0 1949m 170m 48m S 246,3 8,5 2:13.89 gnome-shell 672 root 20 0 192m 49m 8244 S 19,2 2,5 0:13.80 Xorg 2042 lesca 20 0 115m 1444 1024 R 1,6 0,1 0:00.71 top 65 root 20 0 000 R 1,3 0,0 0:01.14 kworker/2:2 1985 lesca 20 0 720m 16m 11m S 1,3 0,8 0:01.51 gnome-terminal 1407 lesca 20 0 129m 2084 904 S 1,0 0,1 0:03.46 sshd 1473 lesca 20 0 115m 1464 1040 S 1,0 0,1 0:02.84 top Furthermore, the video resolution is fixed to 1366x768 (16:9) and when I attach a video projector (this is very important for me) with a 1024x768 resolution It's not possible to clone the monitors and see what what I'm projecting. Switch via Fn+monitor I can only see netbook monitor or projector... Question: there is some way to resolve the high CPU usage of gnome-shell and change the video resolution when projector is connect? Many thanks. lspci: 00:00.0 Host bridge: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09) 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02) 02:00.0 Network controller: Atheros Communications Inc. AR9485 Wireless Network Adapter (rev 01) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 05) -- Dario Lesca - sip:da...@solinos.it (Inviato dal mio Linux Fedora18+Gnome3) fedorino.bonino.loc description: Notebook product: 1225C (1225C) vendor: ASUSTeK Computer Inc. version: 1.0 serial: C8OAAS048181 width: 64 bits capabilities: smbios-2.7 dmi-2.7 vsyscall32 configuration: boot=normal chassis=notebook family=ASUS Family sku=1225C uuid=8045D240-D3AD-4981-39D9-3085A91803F4 *-core description: Motherboard product: 1225C vendor: ASUSTeK Computer Inc. physical id: 0 version: 1.0 serial: BSN12345678901234567 slot: MIDDLE *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 214 date: 07/06/2012 size: 64KiB capacity: 1984KiB capabilities: pci upgrade shadowing
Re: Making hplip use systemd
On 03/10/2013 10:17 PM, Luya Tshimbalanga wrote: Is it possible to allow hplip use sytemd instead of cron? We're not quite ready for a migration to timer units. Feel free to use them on your system, but before we can do it in Fedora, we need at least to: - add anacron-like mode to systemd - have a packaging policy for timer units Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Regexp-Common-2013030901.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Regexp-Common: 7167ac7a4a647b5411782644b7ba0deb Regexp-Common-2013030901.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: Making hplip use systemd
On 03/10/2013 10:17 PM, Luya Tshimbalanga wrote: Is it possible to allow hplip use sytemd instead of cron? As the script actually just clears logs in /var/log/hp/tmp/ it could be doable with systemd's tmpfiles.d I've added it on TODO list. -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl/f17] Update to perl-5.14.4
commit 4d7016aa084bd1fc8f8d38ca1f7f06f23c530188
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon Mar 11 11:53:48 2013 +0100
Update to perl-5.14.4
.gitignore |1 +
perl-5.14.3-CVE-2013-1667.patch | 172 ---
perl.spec | 15 ++--
sources |2 +-
4 files changed, 10 insertions(+), 180 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fcb7765..de116d2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@ filter-requires.sh
/perl-5.14.1.tar.gz
/perl-5.14.2.tar.bz2
/perl-5.14.3.tar.bz2
+/perl-5.14.4.tar.bz2
diff --git a/perl.spec b/perl.spec
index e0543f2..914630f 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1,4 +1,4 @@
-%global perl_version5.14.3
+%global perl_version5.14.4
%global perl_epoch 4
%global perl_arch_stem -thread-multi
%global perl_archname %{_arch}-%{_os}%{perl_arch_stem}
@@ -27,7 +27,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:223%{?dist}
+Release:224%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -123,9 +123,6 @@ Patch23:
perl-5.14.3-RT-82655-fix-double-free-when-loading-object.patch
# Add NAME heading into CPAN PODs, rhbz#908113, CPANRT#73396
Patch24:
perl-5.16.2-cpan-CPAN-add-NAME-headings-in-modules-with-POD.patch
-# Fix CVE-2013-1667, rhbz#918008
-Patch25:perl-5.14.3-CVE-2013-1667.patch
-
# Update some of the bundled modules
# see http://fedoraproject.org/wiki/Perl/perl.spec for instructions
@@ -140,6 +137,7 @@ BuildRequires: procps, rsyslog
# The long line of Perl provides.
# Compat provides
+Provides: perl(:MODULE_COMPAT_5.14.4)
Provides: perl(:MODULE_COMPAT_5.14.3)
Provides: perl(:MODULE_COMPAT_5.14.2)
Provides: perl(:MODULE_COMPAT_5.14.1)
@@ -1304,7 +1302,6 @@ tarball from perl.org.
%patch22 -p1
%patch23 -p1
%patch24 -p1
-%patch25 -p1
#copy the example script
cp -a %{SOURCE5} .
@@ -1518,7 +1515,6 @@ pushd %{build_archlib}/CORE/
'Fedora Patch22: Fix misparsing of maketext strings (CVE-2012-6329)' \
'Fedora Patch23: Fix double-free when loading Digest::SHA object' \
'Fedora Patch24: Add NAME headings to CPAN modules (CPANRT#73396)' \
-'Fedora Patch25: Fix DoS in rehashing code (CVE-2013-1667)' \
%{nil}
rm patchlevel.bak
@@ -2472,6 +2468,11 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Thu Mar 07 2013 Jitka Plesnikova jples...@redhat.com - 4:5.14.4-224
+- 5.14.4 bump (see
+ https://metacpan.org/module/DOM/perl-5.14.4/pod/perldelta.pod for release
+ notes).
+
* Tue Mar 05 2013 Petr Pisar ppi...@redhat.com - 4:5.14.3-223
- Fix CVE-2013-1667 (DoS in rehashing code) (bug #918008)
diff --git a/sources b/sources
index 20fee49..d059c1f 100644
--- a/sources
+++ b/sources
@@ -2,4 +2,4 @@ aceea3db13a159cd5f7e5f2e3ad9534f perl-5.8.0-libdir64.patch
ad5d07285d6e4914384b43c9abc2bdba filter-requires.sh
1737a36154bb5bca781296794afc6791 perl.stp
df28fe2c574e8807d0a803308c545dca perl-example.stp
-0005793e734e42f62d26e16640b7490d perl-5.14.3.tar.bz2
+04202fd10edaa7e3f4bd418b2af04c9c perl-5.14.4.tar.bz2
--
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: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On Sun, Mar 10, 2013 at 10:05 PM, Kevin Kofler kevin.kof...@chello.at wrote: Time for a big TOLD YOU SO! C'mon Kevin -- comments like this aren't helpful, despite whatever your personal feelings may be for the current owner of MySQL. There's plenty of room for disagreements on the technical front, but I have very little patience for these types of comments that focus on *who* is right and not *what* is right. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On Sun, Mar 10, 2013 at 10:28 PM, Kevin Kofler kevin.kof...@chello.at wrote: Why the sarcasm? SELinux and libselinux only ever cause problems, why can't we finally kick them out of Fedora? I find them very useful on my systems, and I think it's a bit extreme to say that they only ever cause problems. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: locate no longer works on my home dir???
On Fri, Mar 8, 2013 at 3:47 PM, Neal Becker ndbeck...@gmail.com wrote: /dev/sda3 on /home type btrfs (rw,relatime,ssd,space_cache) I suspect this is due to the default btrfs setup /dev/sda3 on / type btrfs (rw,relatime,ssd,space_cache) (posted on -dev cause I think this is a bug in btrfs default setup) Please use bugzilla for reporting bugs. This seems to be #906591, mlocate not being able to handle btrfs subvolumes. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
Le lundi 11 mars 2013 à 03:44 +0100, Kevin Kofler a écrit : Michael Scherer wrote: A few wasted mega of disk space do not seems to be big problem if that permit to have more people on rawhide, faster tests and faster feedback. Old libraries accumulate over the lifetime of an installation, eating many MiB, not just a few. Given the target of rawhide, I expect people to be able to clean the unneeded packages after a while. Heck, like they do for packages that got orphaned and removed. And do you have any number ? Cause I have been running distro with such policy and many MiB still doesn't make much to my experience, so provides credible numbers if you wish to make your point , especially when talking to people who have seen this policy in action. The priority for rawhide should be having something that work first. It feels really wrong to design a whole library packaging policy around Rawhide. I do not see how it would feel wrong to try to fix a issue by changing a policy. And I do not see why Rawhide should be less important than stable for that matter. The focus needs to be on making stable releases clean without useless legacy compatibility baggage, and Rawhide needs to be the development bed for that. Compatibility libraries only make sense where the packages cannot be ported to the new version in time for the release. Usually, you have 3 months for branched to make sure everything is rebuild and that there is only 1 version of a lib. Have you read what Olav said, about packages without source rpm will be removed after 2 weeks, and then they show as having broken deps in report ? The script is not that hard to do, you can even get the one I wrote from svn ( http://svnweb.mageia.org/adm/puppet/modules/mirror_cleaner/ ). Not to mention that having the old version for a few days doesn't mean people cannot go ahead and rebuild their packages as they do now, the only difference is for users, since this permit to have a installable rawhide for a more longer period of time. And I think the problem could be solved ( and in fact, it is already a problem we have for those that install something, then remove the main software without cleaning deps ). The solution for that problem is called yum history undo, and it doesn't solve the old library problem. yum history undo work fine for simple and medium cases, but after a while due to the level of churn on stable release, it can break : http://pastebin.com/Bdt6ngy2 And there is nothing broken on my system according to yum check all. We should not refuse the idea on the ground that this is too complex for some users to understand the concept of soname. Either they don't, and then we should just hide libraries from the UI at some point ( and that's already done ), because with or without soname, that will not change anything, or they are able to understand and then we should not treat them as they couldn't. IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's really confusing. (The only worse way to do things is to append an unreadable suffix for the C++ ABI to that as Debian did with kdelibs4c2a. But if you insist on keeping old ABIs around for any and all ABI changes in Rawhide, we'll eventually end up with the same mess!) That's just package naming. If you are more concerned by the name of the rpm than by having users, there is priority issue. So 2 drawbacks do not seems much, or at least not several. Can you maybe explain others issues so we can find a solution that work fine ? Sorry, there is just no solution that can make soname-suffixed libraries work. That's still not explaining. 2 is not several. And I do not accept solution is not the same as there is no solution. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130309 changes
Dne 9.3.2013 14:57, Fedora Rawhide Report napsal(a): Compose started at Sat Mar 9 08:15:06 UTC 2013 Broken deps for x86_64 -- [rubygem-sequel] rubygem-sequel-3.45.0-1.fc19.noarch requires ruby(release) This was meant to be build in f19-ruby target. But it can wait for merge of the target. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 907125] perl-Rose-DB-Object-0.805 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907125 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Rose-DB-Object-0.805-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Rose-DB-Object-0.805-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7z4JP1hmKIa=cc_unsubscribe -- 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: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Sun, Mar 10, 2013 at 7:16 PM, Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: No, there are commits right up to late Feb in launchpad. But then I don't immediately see that you'd want it for MATE purposes (or really any other Fedora purposes); it's a Unity thing. I packaged and used to own it for my aborted plan to try and package Unity, and it's orphaned because I don't want it any more. I don't think it has any dependencies in Fedora, and I think it's pretty useless if you're not running Unity. libindicator is a dependency of libappindicator, which is very much useful if you want a GTK+ app to integrate properly in KDE Plasma by supporting the current system tray spec rather than the obsolete XEmbed-based one GTK+ itself implements. Sadly, the affected GTK+ apps in Fedora aren't using this because their Fedora maintainers are also upstream GNOME maintainers who hate the library. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel MATE team switched mate-notification-daemon to use libnotify instead of libmatenotify. Don't know if that helps, but I am also now the owner of libnotify. Looking at updating to libnotify 0.80 as well. It was a simple switch and it seems to work (still testing). https://github.com/mate-desktop/mate-notification-daemon/commit/d263541b686f36a8f61c00eaee4d852ce5e8a766 mate-notification-daemon-1.5.2 supports libnotify = 0.70 Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
Dan Mashal wrote: Looking at updating to libnotify 0.80 as well. The latest upstream[1] is 0.7.5. Where is this 0.80? [1] https://git.gnome.org/browse/libnotify -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-Syck] Update to 1.25
commit fb95d72a538bf2880424fbdd25b9bd9d63ac2c71
Author: Paul Howarth p...@city-fan.org
Date: Mon Mar 11 13:57:38 2013 +
Update to 1.25
- New upstream release 1.25
- Bump version number and release to fix a MANIFEST mistake in 1.24
perl-YAML-Syck.spec | 10 +++---
sources |2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-YAML-Syck.spec b/perl-YAML-Syck.spec
index 98e9fe5..194040b 100644
--- a/perl-YAML-Syck.spec
+++ b/perl-YAML-Syck.spec
@@ -1,12 +1,12 @@
Name: perl-YAML-Syck
-Version:1.24
-Release:2%{?dist}
+Version:1.25
+Release:1%{?dist}
Summary:Fast, lightweight YAML loader and dumper
License:BSD and MIT
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-Syck/
Source0:
http://www.cpan.org/authors/id/T/TO/TODDR/YAML-Syck-%{version}.tar.gz
-Patch0:0001-Recognize-all-wide-unicode-characters.patch
+Patch0: 0001-Recognize-all-wide-unicode-characters.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
# Keep bundled inc::Module::Install to break cycle perl-Modules-Install
# → perl-YAML-Tiny → perl-YAML-Syck.
@@ -71,6 +71,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/YAML::Syck.3pm*
%changelog
+* Mon Mar 11 2013 Paul Howarth p...@city-fan.org 1.25-1
+- Update to 1.25
+ - Bump version number and release to fix a MANIFEST mistake in 1.24
+
* Sun Mar 10 2013 Paul Howarth p...@city-fan.org 1.24-2
- Work around test failures on PPC and ARM (#919806, CPAN RT#83825)
diff --git a/sources b/sources
index 76ec6bd..033c278 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-075fd0e5bcd4c67aa27788568b5f5b8b YAML-Syck-1.24.tar.gz
+847f315cbd074b42c44f360383ac13e9 YAML-Syck-1.25.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: review swap
Hi, this is a test message. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-Syck] Created tag perl-YAML-Syck-1.24-2.fc19
The lightweight tag 'perl-YAML-Syck-1.24-2.fc19' was created pointing to: eac058c... Work around test failures on PPC and ARM (#919806, CPAN RT# -- 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
[perl-YAML-Syck] Created tag perl-YAML-Syck-1.25-1.fc19
The lightweight tag 'perl-YAML-Syck-1.25-1.fc19' was created pointing to: fb95d72... Update to 1.25 -- 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: F18, efi-bootable live images
This is just a test message. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18-64: Video Resolution problem on a netbook ASUS 1225C-GRY015U
On Mon, Mar 11, 2013 at 11:03:24AM +0100, Dario Lesca wrote: Question: there is some way to resolve the high CPU usage of gnome-shell and change the video resolution when projector is connect? No. The gma500 devices have no worthwhile free driver support. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130311 changes
Compose started at Mon Mar 11 08:15:06 UTC 2013 Broken deps for x86_64 -- [HippoDraw] HippoDraw-python-1.21.3-6.fc19.x86_64 requires libboost_python.so.1.50.0()(64bit) [OpenEXR_Viewers] OpenEXR_Viewers-1.0.2-10.fc19.x86_64 requires libIlmImf.so.6()(64bit) [aws] aws-2.11.0-13.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) aws-2.11.0-13.fc19.i686 requires libgnutls.so.26 aws-2.11.0-13.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) aws-2.11.0-13.fc19.x86_64 requires libgnutls.so.26()(64bit) aws-tools-2.11.0-13.fc19.x86_64 requires libgnutls.so.26()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) [condor] condor-7.9.5-0.1.fc19.x86_64 requires glexec condor-7.9.5-0.1.fc19.x86_64 requires blahp = 0:1.16.1 [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [couchdb] couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit) [dmapd] dmapd-0.0.50-5.fc19.i686 requires libIlmImf.so.6 dmapd-0.0.50-5.fc19.x86_64 requires libIlmImf.so.6()(64bit) [dmlite-plugins-memcache] dmlite-plugins-memcache-0.5.0-3.fc19.x86_64 requires libprotobuf.so.7()(64bit) [dmlite-plugins-s3] dmlite-plugins-s3-0.5.0-2.fc19.x86_64 requires libprotobuf.so.7()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [enblend] enblend-4.1.1-1.fc19.x86_64 requires libIlmImf.so.6()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [fawkes] fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [fcitx-keyboard] fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit) [fcitx-libpinyin] fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2(LIBPINYIN)(64bit) fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [freeDiameter] freeDiameter-1.1.5-1.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) freeDiameter-1.1.5-1.fc19.i686 requires libgnutls.so.26 freeDiameter-1.1.5-1.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) freeDiameter-1.1.5-1.fc19.x86_64 requires libgnutls.so.26()(64bit) [freeipa] freeipa-server-strict-3.1.2-3.fc19.x86_64 requires krb5-server = 0:1.11 [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gedit-valencia] gedit-valencia-0.3.0-11.20120430gite8a0f500555be.fc18.x86_64 requires libvala-0.18.so.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
Unhelpful update descriptions
Since switching to Fedora I've been noticing most Fedora stable updates are released with a short, helpful description of the update, possibly including a list of bugs fixed, just like in other major distros. But unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I'm not suggesting essays, but at least a unique sentence fragment would be good for each update. Please? :-) Michael Catanzaro 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: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
James Antill wrote: As for deltrarpm ... we've moved mature features into core yum a number of times, after they've been field tested as a plugin, and not something I'd term. a significant user change. This particular one is a significant user change because it's enabled by default, so users who went out of their way to uninstall yum-presto now get it forced on them again and have to disable it in yum.conf now. At the very least, this needs a release note. It's different in the case of e.g. the downloadonly plugin which was also merged into core yum, but which has no effect if you don't specify the --downloadonly switch. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18-64: Video Resolution problem on a netbook ASUS 1225C-GRY015U
Il giorno lun, 11/03/2013 alle 14.41 +, Matthew Garrett ha scritto: Question: there is some way to resolve the high CPU usage of gnome-shell and change the video resolution when projector is connect? No. The gma500 devices have no worthwhile free driver support. Thanks Matthew, this is what I was afraid. There is some workaround? or other driver to use? -- Dario Lesca - sip:da...@solinos.it (Inviato dal mio Linux Fedora18+Gnome3) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-TCP/f17] (5 commits) ...Merge remote-tracking branch 'origin/f18' into f17
Summary of changes: ce61ab5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) 10e47d7... Upstream update. (*) b526b39... Upstream update. (*) 28835e2... Merge cleanup. (*) 065a683... Merge remote-tracking branch 'origin/f18' into f17 (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-Test-TCP/f17: 5/5] Merge remote-tracking branch 'origin/f18' into f17
commit 065a6836ca848e657a0c66a3a916939964bc0419 Merge: 3892859 28835e2 Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon Mar 11 16:46:21 2013 +0100 Merge remote-tracking branch 'origin/f18' into f17 .gitignore |2 +- perl-Test-TCP.spec | 10 +- sources|2 +- 3 files changed, 7 insertions(+), 7 deletions(-) --- -- 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
[ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19
Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around 3AM GMT on March 12. (i.e., about 11 hours from now.) Package HippoDraw (orphan) Package PyPE (orphan) Package Temperature.app (orphan) Package afraid-dyndns (orphan) Package alsamixer-dockapp (orphan) Package aplus-fsf (fails to build) Package aswvdial (orphan) Package auto-nng (orphan) Package bamf (orphan) comaintained by: jspaleta Package blazeblogger (orphan) Package c2050 (orphan) Package c2070 (orphan) Package canto (orphan) Package certmaster (orphan) comaintained by: alikins Package compton (orphan) Package cputnik (orphan) Package dasher (orphan) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mercurial (fails to build) comaintained by: overholt Package em8300 (orphan) Package emacs-ecb (orphan) Package email2trac (fails to build) Package fcron (orphan) Package gkrellm-weather (orphan) Package global (orphan) Package gnome-mag (orphan) Package griffith (orphan) Package gtksourceview2-sharp (fails to build) Package guimup (orphan) Package haildb (orphan) Package inamik-tableformatter (orphan) Package javacsv (orphan) Package libdrizzle (orphan) Package libgnomecups (orphan) Package libopensync-plugin-sunbird (orphan) comaintained by: awjb Package lx (orphan) Package mimetic (orphan) Package mingw-openjpeg (orphan) comaintained by: epienbro Package mlmmj (orphan) Package mtpfs (orphan) Package nagios-plugins-rhev (fails to build) Package ncpfs (orphan) Package nitrogen (orphan) Package obapps (orphan) Package ocaml-cmigrep (orphan) Package pbm2l2030 (orphan) Package pbm2l7k (orphan) Package pclock (orphan) Package perl-Bio-Graphics (orphan) comaintained by: alexlan Package perl-Fedora-Bugzilla (orphan) comaintained by: mmaslano Package perl-bioperl (orphan) comaintained by: alexlan Package perl-bioperl-run (orphan) comaintained by: alexlan Package pidgin-gfire (orphan) Package python-chm (orphan) Package python-drizzle (orphan) Package python-wsgi-jsonrpc (orphan) Package rubygem-acts-as-list (orphan) Package spicebird (orphan) Package trac-agilo-plugin (orphan) comaintained by: kevin Package util-vserver (orphan) Package vdr-skins (orphan) Package vdr-text2skin (orphan) Package vdr-wapd (orphan) Package volpack (orphan) Package wmSun (orphan) Package wmbinclock (orphan) Package wmblob (orphan) Package wmcalc (orphan) Package wmcore (orphan) Package wmcube (orphan) Package wmdrawer (orphan) Package wmeyes (orphan) Package wmnet (orphan) Package wmpuzzle (orphan) Package wmsystemtray (orphan) Package wmtictactoe (orphan) Package wmtop (orphan) Package wmwave (orphan) Package wmweather (orphan) Package xml-writer (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: bamf bamf-qt requires bamf-devel = 0.2.104-4.fc18 gnome-pie requires libbamf3.so.0 gnome-pie requires bamf3-devel = 0.2.104-4.fc18 Removing: certmaster func requires certmaster = 0.28-5.fc19 Removing: libgnomecups libgnomeprint22 requires libgnomecups-1.0.so.1 libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18 Removing: ncpfs medusa requires libncp.so.2.3 medusa requires ncpfs-devel = 2.2.6-18.fc19 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1) Removing: perl-bioperl perl-Bio-ASN1-EntrezGene requires perl(Bio::Index::AbstractSeq) perl-Bio-SamTools requires perl(Bio::PrimarySeq) perl-Bio-SamTools requires perl(Bio::SeqFeature::Lite) Removing: python-chm archmage requires python-chm = 0.8.4-14.fc19 chm2pdf requires python-chm = 0.8.4-14.fc19 Removing: python-wsgi-jsonrpc python-windmill requires python-wsgi-jsonrpc = 0.2.9-3.fc19 Removing: volpack amide requires volpack-devel = 1.0c7-7.fc19 amide requires libvolpack.so.1 The script that generated this page can be found at http://git.fedorahosted.org/cgit/releng/tree/scripts/find-unblocked-orphans.py There you can also report bugs and RFEs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Mon, Mar 11, 2013 at 6:57 AM, Michael Cronenworth m...@cchtml.com wrote: Dan Mashal wrote: Looking at updating to libnotify 0.80 as well. The latest upstream[1] is 0.7.5. Where is this 0.80? [1] https://git.gnome.org/browse/libnotify -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Nevermind. https://bugzilla.redhat.com/show_bug.cgi?id=905120 Confused me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19
On Mon, 2013-03-11 at 11:54 -0400, Bill Nottingham wrote: Package dasher (orphan) I'll try to keep this one going on despite my general lack of expertise in the area. Taking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 11.03.2013 17:06, Jared K. Smith wrote: On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? -- Jared Smith Just an idea: maybe we could introduce the convention of including a link to the upstream changelog in the update description? For instance by inviting package maintainers to paste such a link in an apposite field when doing a fedpkg update? While it's true that users can look up that information on their own, usually package maintainers already know where the upstream changelog can be found, whereas users might need to do some searching. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposal: Rawhide tracker bug
Greetings. I'd like to propose we create a rawhide tracker bug. Probibly name it: RawhideBlocker (But I don't care what colour the bikeshed is) This bug would be used for the following types of bugs against the 'rawhide' version: - bugs that prevent the daily rawhide compose from completing. (In practice this can only be a small subset of packages used for the compose in the chroot) - bugs that break the rawhide buildroot. In practice these are usually noticed pretty quickly and the offending build is just untagged until it can be fixed, but there could be cases where the fix is more complex and has a bug associated with it. - bugs that cause a large number of rawhide systems to be unbootable. This would be things like dracut or kernel or glibc or systemd issues that cause most rawhide installs to fail to boot. (we could add additional criteria as we go) The idea is that folks running rawhide could watch this bug and more easily see issues that are major as they appear and know when they got fixed. They could also add bugs to this and developers could see that the bug is high priority and more resources could be brought to bear on it. Additionally we could gain some insight into how often these kind of bugs happen and how long it takes to fix them. This would of course require people watching the bug to note any bugs added to it that are NOT in the above criteria, but I think that should be easily possible with enough people watching the bug. Thoughts? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Jared K. Smith jsm...@fedoraproject.org writes: On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? FWIW, I tend to say update to upstream release XYZ and give a URL for the upstream release notes for that version. This approach requires an upstream that's well enough organized to have such a webpage for every version, of course; but for my packages this seems to work fine. The upstream notes tend to have way more info than I could cram into an update description, anyway. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? From the time, Kevin sent me a message in a style of One more such update description and I'll will come to Brno to k*ll you I'm trying to provide better description. But it really depends on quality of upstream Changelogs. Sometimes it's just really hard to write more than update to latest upstream version x.y :( Jaroslav -- Jared Smith -- 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: Proposal: Rawhide tracker bug
- bugs that break the rawhide buildroot. In practice these are usually noticed pretty quickly and the offending build is just untagged until it can be fixed, but there could be cases where the fix is more complex and has a bug associated with it. For those of us who are not skilled in building a release, what does this exactly mean? I can imagine bugs that prevent compose (no package repo created), but this one could deserve a closer explanation. - bugs that cause a large number of rawhide systems to be unbootable. This would be things like dracut or kernel or glibc or systemd issues that cause most rawhide installs to fail to boot. What about broken gdm, does it fall into the category? Should critical path packages be also covered by this tracker bug? (Firefox broken, pulseaudio broken, gnome-terminal broken, yum broken, ...) The idea is that folks running rawhide could watch this bug and more easily see issues that are major as they appear and know when they got fixed. They could also add bugs to this and developers could see that the bug is high priority and more resources could be brought to bear on it. Additionally we could gain some insight into how often these kind of bugs happen and how long it takes to fix them. I support this a lot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Improving the Fedora boot experience
Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. - Switch to a simple spinner for the plymouth theme This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/boot.png I know when we've proposed this in the past, there was concern about loosing the one place where the Fedora logo is visible in the boot. I'd like to propose a compromise that will keep the Fedora logo _and_ improve the transition to the login screen: How about we use the spinner as in that mockup, but add a reasonably-sized Fedora logo in the top left corner. - Replace the small print logo on the login screen with a bigger one The idea here is to replace the small-print Fedora text logo that we currently have in that corner by the same Fedora logo thats used in plymouth, so that it remains unchanged as we transition from plymouth to gdm. What do you think ? Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
Michael Scherer wrote: Given the target of rawhide, I expect people to be able to clean the unneeded packages after a while. Heck, like they do for packages that got orphaned and removed. My concern is not Rawhide, my concern is stable releases, especially if one upgrades from one release of Fedora to the next, then to the next etc. Fedora installations usually go through many upgrades, seeing how we release every 6 months. The problem with your proposal is that it is focused on Rawhide and ignores the impact on our actual releases. And do you have any number ? Cause I have been running distro with such policy and many MiB still doesn't make much to my experience, so provides credible numbers if you wish to make your point , especially when talking to people who have seen this policy in action. Let's just take one of the few compatibility stacks we actually have to carry (because porting is far from trivial) as an example: Name: qt3 Version : 3.3.8b Release : 41.fc17 Architecture: i686 Size: 10467741 Name: kdelibs3 Version : 3.5.10 Release : 42.fc17 Architecture: i686 Size: 38669698 Name: kdebase3 Version : 3.5.10 Release : 20.fc17 Architecture: i686 Size: 17612161 Name: kdebase3-libs Version : 3.5.10 Release : 20.fc17 Architecture: i686 Size: 1317496 Now multiply this by the number of soname bumps in the lifetime of an installation (just look at how often there are broken dependencies from a soname bump in the Rawhide reports) and see for yourself what doing the math leaves you with. And in addition to the space issue, the old libraries would also be unmaintained and not get any security fixes. Maintaining all the old libraries with old sonames we ever releases just does not scale! See e.g. how upgrading to a new version for security reasons is explicitly listed as an exception to the policy of not bumping sonames in updates for stable releases in https://fedoraproject.org/wiki/Updates_Policy . It's all the more valid for Rawhide / between different releases (because each individual release goes EOL after ~13 months, Rawhide never goes EOL, nor does Fedora as a whole of course, so old stuff can get REALLY old). Leaving old unmaintained libraries lying around on user systems is a security disaster! I do not see how it would feel wrong to try to fix a issue by changing a policy. And I do not see why Rawhide should be less important than stable for that matter. Because the whole purpose of Rawhide is to serve as a development bed for our stable releases. Rawhide is not and should not be our product, our releases are. And in any cases, the releases do exist and you cannot entirely ignore their existence in your proposal. Usually, you have 3 months for branched to make sure everything is rebuild and that there is only 1 version of a lib. Have you read what Olav said, about packages without source rpm will be removed after 2 weeks, and then they show as having broken deps in report ? Removing the old packages is not enough, you actually have to add Obsoletes to the current version if you don't want the old versions to accumulate on upgrades from one stable release to the next. And who is going to enforce the Obsoletes? It WILL get forgotten more often than not. We already have enough broken upgrade paths as it stands. In addition, having those Obsoletes will make users complain Why does yum want to remove the compatibility library my [broken, not recompiled against the current Fedora] third-party package needs?, whereas not having them will make old (and unmaintained!) versions accumulate (as I said before). The best way to avoid such confusion is to avoid setting false expectations in the first place by just not version-suffixing the libraries. Not to mention that having the old version for a few days doesn't mean people cannot go ahead and rebuild their packages as they do now, the only difference is for users, since this permit to have a installable rawhide for a more longer period of time. Just to avoid a window of a few days, your proposal wants to introduce a version suffix we're stuck with forever. This seems very wrong. yum history undo work fine for simple and medium cases, but after a while due to the level of churn on stable release, it can break : http://pastebin.com/Bdt6ngy2 The use case I was talking about is, you try the package, you don't like it, you uninstall it (before doing any other yum operations). Indeed, undoing an older yum operation may or may not work. But it's not the common case: Why would you want to uninstall a package after deciding you like it? That's just package naming. If you are more concerned by the name of the rpm than by having users, there is priority issue. We have users right now, without your proposal. And naming is an important issue: If you buy beef lasagne, you don't want to have horse meat
Re: New cfitsio (3.330) in rawhide
Michael Schwendt wrote:
A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
Why not libcfitsio.so.%{version}?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: Rawhide tracker bug
On Mon, 11 Mar 2013 12:50:53 -0400 (EDT) Kamil Paral kpa...@redhat.com wrote: - bugs that break the rawhide buildroot. In practice these are usually noticed pretty quickly and the offending build is just untagged until it can be fixed, but there could be cases where the fix is more complex and has a bug associated with it. For those of us who are not skilled in building a release, what does this exactly mean? I can imagine bugs that prevent compose (no package repo created), but this one could deserve a closer explanation. The rawhide compose script ( http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide ) does: mock -r $MOCKCONFIG --uniqueext=$DATE --init mock -r $MOCKCONFIG --uniqueext=$DATE --no-clean --install koji yum createrepo cvs make intltool findutils mash yum-utils rsync repoview hardlink So, I was thinking this was those packages and their deps. If those have broken dependencies, don't install or don't work, there's no rawhide compose until they are fixed. - bugs that cause a large number of rawhide systems to be unbootable. This would be things like dracut or kernel or glibc or systemd issues that cause most rawhide installs to fail to boot. What about broken gdm, does it fall into the category? Should critical path packages be also covered by this tracker bug? (Firefox broken, pulseaudio broken, gnome-terminal broken, yum broken, ...) Well, we could look at adding critpath, but I think that could get us into more hazy territory, and some subjective issues around 'broken'. Especially since rawhide packages can change interfaces, and something behaving differently one person might call 'broken'. Is there any way we could describe this as a more easy to understand criteria? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: Rawhide tracker bug
On Mon, Mar 11, 2013 at 11:07:35 -0600, Kevin Fenzi ke...@scrye.com wrote: Well, we could look at adding critpath, but I think that could get us into more hazy territory, and some subjective issues around 'broken'. Especially since rawhide packages can change interfaces, and something behaving differently one person might call 'broken'. Is there any way we could describe this as a more easy to understand criteria? Still when gdm breaks (which it is right now for me - probably due to software rendering not doing enough) it might be nice to have a bug with suggested work arounds (c-a-f2, login as root, stop gdm, start kdm) so that people can get the work around information quicker. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting assistance with packaging a web app: wikindx
On Mon, 11 Mar 2013 16:04:17 +1100 Ankur Sinha sanjay.an...@gmail.com wrote: On Sun, 2013-03-10 at 23:22 -0500, Michael Cronenworth wrote: You should take a look at mediawiki[1]. It stores its files in /usr/share/mediawiki and provides scripts for creating new wikis. The scripts reference a list of wikis in /etc/mediawiki. Instead of copies the new wikis are symbolic links so that package updates are seamless. [1] http://pkgs.fedoraproject.org/cgit/mediawiki.git/tree/ Hi Michael, I'll go through the package. Thank you for the quick reply. I'm not fully sure I would call mediawiki a good example. ;) There's: http://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications and to expand on that, you should have the vast majority of the files in /usr/share/ and only those files that are config or otherwise change be in /etc and linked to the share versions. Wordpress might be another example. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, 11 Mar 2013 03:49:38 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Miloslav Trmač wrote: If a new package doesn't break tests, it will tagged into rawhide immediately or overnight - just like now. No extra work needed, no change in workflow. Running the tests alone will slow down chain builds significantly, even if the builds get tagged immediately after the tests pass. Well, not sure it would. If builds were tagged into f19-pending and the tests ran from that, then tagged into f19, the max delay would be when a newrepo just started and it has to wait for the next newrepo to be added. The min delay would be that it gets added and newrepo starts right then. So with current newrepo tasks about 13min per newrepo, so thats 13 or 26 min per build. I don't think there is any obvious reason to exempt anaconda from this process. Of course, we start with zero tests, and thus also zero requirements on anaconda; OTOH I expect somebody will propose to add a test that minimal network install should always be working very soon after the infrastructure is ready. Such a test would obviously apply both to anaconda updates and to changes of everything else that may break anaconda. It's quite funny that you're talking about enforcing requirements on Anaconda AFTER FESCo gave Anaconda developers carte blanche to put a KNOWN BROKEN Anaconda into pre-F18 Rawhide and leave it there even when it was known not to get fixed in time for the release, causing release slippage. Does this mean you admit that FESCo made a mistake? Or that FESCo as a whole finally admits to having made a mistake? :-) eye-roll Hasn't this been discussed to death? We could have taken the hit in f18 and landed the new anaconda, or we could have reverted and taken the hit in f19 to land the new anaconda, etc. It had to be done, sooner is better than latter. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Matthias Clasen wrote: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. What would there be instead? A text-mode boot menu? Or nothing at all displayed unless the user happens to know to press some key at the right moment? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 19 Feature Freeze is tomorrow!
REMINDER: Tuesday, March 12 is the Feature Freeze for Fedora 19, the Planning Development phase ends - that means tomorrow! At this point, all accepted features should be substantially complete, and testable. Additionally, if a feature is to be enabled by default, it must be so enabled at Feature Freeze. See [1] and [2]. For more detail, check my previous announcement: http://lists.fedoraproject.org/pipermail/devel-announce/2013-March/001125.html There are still quite a lot of Features not updated recently, you will make my life much more easier by filling the current status (I don't have to ask everyone individually then;-). And of course, thanks to everyone who already updates theirs Features! Thanks Jaroslav [1] https://fedoraproject.org/wiki/Feature_Freeze_Policy [2] https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: Rawhide tracker bug
On Mon, 11 Mar 2013 12:16:31 -0500 Bruno Wolff III br...@wolff.to wrote: Still when gdm breaks (which it is right now for me - probably due to software rendering not doing enough) it might be nice to have a bug with suggested work arounds (c-a-f2, login as root, stop gdm, start kdm) so that people can get the work around information quicker. Well, I'd say that might be a good general tip on the rawhide wiki page? Or noted in mailing lists. This is a good example... so gdm might be broken on software rendering setups. Is that broken enough to add to the tracker? Or is that it works with hardware rendering ok? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 12:58 PM, Matthias Clasen wrote: - Turn off the graphical grub screen I don't know why - I think grub2 is just a PITA to work with compared to grub - but the intention here was that it should be turned off by default in final releases, and on in alpha/beta releases. I think we forgot to turn it off on F18 for some reason. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 12:58 PM, Matthias Clasen wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. IIRC, in f17, the GRUB screen was not visible. (you could still press f11 to bring it up if you needed it to). Does anyone know why this behaviour changed? - Switch to a simple spinner for the plymouth theme This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/boot.png I know when we've proposed this in the past, there was concern about loosing the one place where the Fedora logo is visible in the boot. I'd like to propose a compromise that will keep the Fedora logo _and_ improve the transition to the login screen: How about we use the spinner as in that mockup, but add a reasonably-sized Fedora logo in the top left corner. The current logo also currently behaves as a progress bar (the logo fills up). I know that currently it really doesn't match to any kind of progress, but is the idea here that there will be no progress indicator, just a spinner? Also, is there an intention here to explain to the user (e.g. text or icons) what is happening? In F18, the fedora logo progress bar in plymouth is the same for both bootup and when applying updates. cheers ryanlerch - Replace the small print logo on the login screen with a bigger one The idea here is to replace the small-print Fedora text logo that we currently have in that corner by the same Fedora logo thats used in plymouth, so that it remains unchanged as we transition from plymouth to gdm. What do you think ? Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, 2013-03-11 at 12:06 -0400, Jared K. Smith wrote: I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? Personally I'd prefer some level of information beyond just update to release x.y.z, e.g. snippets from an upstream changelog (or a link, that's great too). But primarily I'm concerned about seeing updates with no description at all. 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: Unhelpful update descriptions
From: Jaroslav Reznik jrez...@redhat.com - Original Message - On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro mike.catanz...@gmail.com wrote: Perhaps the update policy should have a guideline on the minimum amount of information required in this description. E.g. update to latest upstream version might be a perfectly acceptable description for Fedora given the fast pace of updates, but I don't think users should ever be seeing no update information available and especially not here is where you give an explanation of your update. (And I've seen this one multiple times within the past couple of weeks.) I tend to agree here. That being said, most of my package updates are something along the lines of Update to upstream 2.5 release -- would you find that descriptive enough, or still lacking in detail? From the time, Kevin sent me a message in a style of One more such update description and I'll will come to Brno to k*ll you I'm trying to provide better description. But it really depends on quality of upstream Changelogs. Sometimes it's just really hard to write more than update to latest upstream version x.y :( Jaroslav I've often wanted to see better descriptions too. When in admin mode, it would be nice to be able to only have to 'rpm -q --changelog foo' to get what I need. Links to upstream changelogs would be very acceptable. You've made an excellent point here why these are often rather vague. It's very easy to forget the Fedora is merely packaging upstream and is not always upstream. It does seem that there's been a trend forming lately where the rpm's changelog is covering only what's happened as far as the packaging itself goes and less about the software being packaged. Maybe that's all the rpm changelog should ever be? Less useful for what I need, yes, but also more truthful by not providing a false impression. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11.03.13 12:58, Matthias Clasen (mcla...@redhat.com) wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. This is probably relatively easy to do, we'd just need remove a lot of module loading lines from the generated grub.conf. - Switch to a simple spinner for the plymouth theme This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/boot.png I know when we've proposed this in the past, there was concern about loosing the one place where the Fedora logo is visible in the boot. I'd like to propose a compromise that will keep the Fedora logo _and_ improve the transition to the login screen: How about we use the spinner as in that mockup, but add a reasonably-sized Fedora logo in the top left corner. If it was for me I'd remove all of this entirely, and we should get Plymouth to suppress any kind of fancy output until 10s or so into the boot (heck, since ply saves performance data from the previous boot it could even take that into account regarding whether we should show anything at all). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 2013-03-11 18:49, Lennart Poettering wrote: On Mon, 11.03.13 12:58, Matthias Clasen (mcla...@redhat.com) wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. This is probably relatively easy to do, we'd just need remove a lot of module loading lines from the generated grub.conf. Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Hi , On Qua, 2013-03-06 at 09:25 -0600, Richard Shaw wrote: Looks like mariadb has hit rawhide now and I can't build mythtv. I've added conditionals for the direct mysql Requires and BR's but until some of the dependent packages are fixed, MySQL-python, qt4-mysql, etc. How (and when) we fix rawhide ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On 03/11/2013 12:30 AM, Rex Dieter wrote: alekc...@googlemail.com wrote: Last KDE nightly composes failed because of error DEBUG util.py:264: Error creating Live CD : Failed to build transaction : MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64 http://koji.fedoraproject.org/koji/taskinfo?taskID=5100301 http://koji.fedoraproject.org/koji/taskinfo?taskID=5100302 Previous composes before importing new MySQL package was fine, so last composes problem related with new MySQL. There is also other problem with missing MySQL component in bugzilla, looks like for bugzilla MySQL=mysql, it finds mysql bugs for MySQL package. In addition to there not being any MySQL bugzilla component, 1. Shouldn't the 'mysql' component be retired and blocked now? It's done now. 2. Should the best practice be to use Requires: mariadb, BuildRequires: mariadb-devel instead of Requires: mysql, BuildRequires: mysql-devel now? mysql and mysql-devel should be still OK, since only mariadb packages currently provide these symbols (they became only virtual names). 3. And long-term, what to do about MySQL-libs getting pulled into live image composes? can it be blacklisted or something? It won't be problem only in case of live image composes, but in requiring libmysqlclient.so.18 generally, because RPM simply chooses one of the packages providing the same library. It is officially un-deterministic (usually it is the shorter one), but we cannot depend on it right now. So to solve the live image composes issue for now I adjusted the major soname number to libmysqlclient.so.1018. I know it doesn't solve all the issues, though. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19
On Seg, 2013-03-11 at 11:54 -0400, Bill Nottingham wrote: Package PyPE (orphan) I took this one , because still looking for an python IDE, upstream still alive and seems that is easy to maintain. -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On 03/11/2013 06:55 PM, Sérgio Basto wrote: Hi , On Qua, 2013-03-06 at 09:25 -0600, Richard Shaw wrote: Looks like mariadb has hit rawhide now and I can't build mythtv. I've added conditionals for the direct mysql Requires and BR's but until some of the dependent packages are fixed, MySQL-python, qt4-mysql, etc. How (and when) we fix rawhide ? Thanks, Hi, if I understand it correctly that the problem is caused by conflicting library names, then it should be solved today (the enhanced package is already building). Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas leamas.a...@gmail.com wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: seth vidal skvi...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: 03/11/2013 14:03 Subject: Re: Improving the Fedora boot experience Sent by: devel-boun...@lists.fedoraproject.org On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas leamas.a...@gmail.com wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. -sv +1 -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/09/2013 07:20 PM, Reindl Harald wrote: and why in the world is this not solved more pragmatically? my conslusion is * MariaDB will replace mysql as default * any package will be linked against mariadb * Oracle MySQL should only provide the server and not the client-tools This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. so why is MariaDB not obsoleting mysql without all this versioning tricks and mysql-oracle installs the server under /usr/local/mysql-oracle/ and provides a mysql-oracle.service? This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Honza Horak hho...@redhat.com writes: On 03/11/2013 12:30 AM, Rex Dieter wrote: alekc...@googlemail.com wrote: 2. Should the best practice be to use Requires: mariadb, BuildRequires: mariadb-devel instead of Requires: mysql, BuildRequires: mysql-devel now? mysql and mysql-devel should be still OK, since only mariadb packages currently provide these symbols (they became only virtual names). Yeah, I think we will consider mysql and mysql-devel to be virtual Provides now. Generally, dependent packages should still use those for BuildRequires, unless there is some specific reason why you want to build against one particular MySQL clone. Also, if possible it's best not to use Requires: mysql at all, but just let the automatic dependency on libmysqlclient.so do the job. I realize this doesn't work for packages without such a dependency, of course. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 02:02:11PM -0400, seth vidal wrote: On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas leamas.a...@gmail.com wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. “Press ESC for details” is fine. The only problem is that we have to include half of graphical stack to render this text correctly. And in correct locale. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting assistance with packaging a web app: wikindx
Le Lun 11 mars 2013 18:19, Kevin Fenzi a écrit : On Mon, 11 Mar 2013 16:04:17 +1100 Ankur Sinha sanjay.an...@gmail.com wrote: On Sun, 2013-03-10 at 23:22 -0500, Michael Cronenworth wrote: You should take a look at mediawiki[1]. It stores its files in /usr/share/mediawiki and provides scripts for creating new wikis. The scripts reference a list of wikis in /etc/mediawiki. Instead of copies the new wikis are symbolic links so that package updates are seamless. [1] http://pkgs.fedoraproject.org/cgit/mediawiki.git/tree/ Hi Michael, I'll go through the package. Thank you for the quick reply. I'm not fully sure I would call mediawiki a good example. ;) There's: http://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications and to expand on that, you should have the vast majority of the files in /usr/share/ and only those files that are config or otherwise change be in /etc and linked to the share versions. Wordpress might be another example. squirrelmail seems clean to me -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 01:55 PM, Alec Leamas wrote: On 2013-03-11 18:49, Lennart Poettering wrote: On Mon, 11.03.13 12:58, Matthias Clasen (mcla...@redhat.com) wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. This is probably relatively easy to do, we'd just need remove a lot of module loading lines from the generated grub.conf. Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 02:21 PM, Tomasz Torcz wrote: On Mon, Mar 11, 2013 at 02:02:11PM -0400, seth vidal wrote: On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas leamas.a...@gmail.com wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. “Press ESC for details” is fine. The only problem is that we have to include half of graphical stack to render this text correctly. And in correct locale. Does the bootup screen require any keyboard other input at all other than escape to bring up the details? Would there be harm in allowing *any* keypress to bring up and hide the details, and not having a label? cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Hi On Mon, Mar 11, 2013 at 1:49 PM, wrote: It does seem that there's been a trend forming lately where the rpm's changelog is covering only what's happened as far as the packaging itself goes and less about the software being packaged. Maybe that's all the rpm changelog should ever be? Less useful for what I need, yes, but also more truthful by not providing a false impression. The RPM changelog should generally be more about the packaging related changes rather than upstream and bodhi update should have a summary of the upstream changes or atleast a link to the upstream changelog. If upstream doesn't provide a good summary, it doesn't hurt for package maintainers to ask them. I have found that upstream developers are quite responsive to such suggestions especially if you provide them tips to automate the generation of it As a specific example, askbot (which powers http://ask.fedoraproject.org) has a good summary of changes in a easily accessible place after I requested them http://askbot.org/doc/changelog.html Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for Fedora 19
Hi, On 03/11/2013 04:54 PM, Bill Nottingham wrote: Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around 3AM GMT on March 12. (i.e., about 11 hours from now.) Package HippoDraw (orphan) Package PyPE (orphan) Package Temperature.app (orphan) Package afraid-dyndns (orphan) Package alsamixer-dockapp (orphan) Package aplus-fsf (fails to build) Package aswvdial (orphan) Package auto-nng (orphan) Package bamf (orphan) comaintained by: jspaleta Package blazeblogger (orphan) Package c2050 (orphan) Package c2070 (orphan) Package canto (orphan) Package certmaster (orphan) comaintained by: alikins Package compton (orphan) Package cputnik (orphan) Package dasher (orphan) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mercurial (fails to build) comaintained by: overholt Package em8300 (orphan) Package emacs-ecb (orphan) Package email2trac (fails to build) Package fcron (orphan) Package gkrellm-weather (orphan) Package global (orphan) Package gnome-mag (orphan) Package griffith (orphan) Package gtksourceview2-sharp (fails to build) Package guimup (orphan) Package haildb (orphan) Package inamik-tableformatter (orphan) Package javacsv (orphan) Package libdrizzle (orphan) Package libgnomecups (orphan) Package libopensync-plugin-sunbird (orphan) comaintained by: awjb Package lx (orphan) Package mimetic (orphan) Package mingw-openjpeg (orphan) comaintained by: epienbro Package mlmmj (orphan) Package mtpfs (orphan) Package nagios-plugins-rhev (fails to build) Package ncpfs (orphan) Package nitrogen (orphan) Package obapps (orphan) Package ocaml-cmigrep (orphan) Package pbm2l2030 (orphan) Package pbm2l7k (orphan) Package pclock (orphan) Package perl-Bio-Graphics (orphan) comaintained by: alexlan Package perl-Fedora-Bugzilla (orphan) comaintained by: mmaslano Package perl-bioperl (orphan) comaintained by: alexlan Package perl-bioperl-run (orphan) comaintained by: alexlan Package pidgin-gfire (orphan) Package python-chm (orphan) Package python-drizzle (orphan) Package python-wsgi-jsonrpc (orphan) Package rubygem-acts-as-list (orphan) Package spicebird (orphan) Package trac-agilo-plugin (orphan) comaintained by: kevin Package util-vserver (orphan) Package vdr-skins (orphan) Package vdr-text2skin (orphan) Package vdr-wapd (orphan) Package volpack (orphan) Package wmSun (orphan) Package wmbinclock (orphan) Package wmblob (orphan) Package wmcalc (orphan) Package wmcore (orphan) Package wmcube (orphan) Package wmdrawer (orphan) Package wmeyes (orphan) Package wmnet (orphan) Package wmpuzzle (orphan) Package wmsystemtray (orphan) Package wmtictactoe (orphan) Package wmtop (orphan) Package wmwave (orphan) Package wmweather (orphan) Package xml-writer (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: bamf bamf-qt requires bamf-devel = 0.2.104-4.fc18 gnome-pie requires libbamf3.so.0 gnome-pie requires bamf3-devel = 0.2.104-4.fc18 Removing this does implies also removing gnome-pie: [hans@shalem ~]$ sudo repoquery -q --disablerepo=* --enablerepo=rawhide --whatrequires --alldeps gnome-pie [hans@shalem ~]$ Good :) Removing: certmaster func requires certmaster = 0.28-5.fc19 [hans@shalem ~]$ sudo repoquery -q --disablerepo=* --enablerepo=rawhide --whatrequires --alldeps func python-taboot-0:0.4.0-4.fc19.noarch taboot-func-0:0.4.0-4.fc19.noarch [hans@shalem ~]$ sudo repoquery -q --disablerepo=* --enablerepo=rawhide --whatrequires --alldeps python-taboot taboot-func [hans@shalem ~]$ Thus this implies also removing the func python-taboot and taboot-func (sub)packages Removing: libgnomecups libgnomeprint22 requires libgnomecups-1.0.so.1 libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18 [hans@shalem ~]$ sudo repoquery -q --disablerepo=* --enablerepo=rawhide --whatrequires --alldeps libgnomeprint22 conglomerate-0:0.9.1-14.fc19.x86_64 gnome-genius-0:1.0.16-2.fc19.x86_64 gnome-python2-gnomeprint-0:2.32.0-13.fc19.x86_64 gnome-python2-gtksourceview-0:2.32.0-13.fc19.x86_64 gpp-0:0.7.0-9.fc19.x86_64 gtksourceview-1:1.8.5-13.fc19.i686 gtksourceview-1:1.8.5-13.fc19.x86_64 libgnomeprint22-devel-0:2.18.8-6.fc19.i686 libgnomeprint22-devel-0:2.18.8-6.fc19.x86_64 libgnomeprintui22-0:2.18.6-6.fc19.i686 libgnomeprintui22-0:2.18.6-6.fc19.x86_64 linsmith-0:0.99.12-7.fc19.x86_64 ocaml-lablgtk-0:2.16.0-2.fc19.x86_64 perl-Gnome2-Print-0:1.000-18.fc19.x86_64 perl-Gtk2-SourceView-0:1.000-7.fc19.x86_64 ruby-gnomeprint2-0:0.90.4-1.9.fc19.4.x86_64 ruby-gnomeprintui2-0:0.90.4-1.9.fc19.4.x86_64
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 06:49:16PM +0100, Lennart Poettering wrote: We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. It's worth noting that many modern systems will not register keypresses during boot by default. Moving in this direction shouldn't happen until there's worthwhile support in the desktop UI for using the boot indicators spec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Ryan Lerch wrote: Does the bootup screen require any keyboard other input at all other than escape to bring up the details? It must be possible to enter a disk encryption password. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
Kevin Fenzi wrote: Well, not sure it would. If builds were tagged into f19-pending and the tests ran from that, then tagged into f19, the max delay would be when a newrepo just started and it has to wait for the next newrepo to be added. The min delay would be that it gets added and newrepo starts right then. So with current newrepo tasks about 13min per newrepo, so thats 13 or 26 min per build. + the time it takes to run the tests themselves! The more tests you add, the longer they will take. Hasn't this been discussed to death? We could have taken the hit in f18 and landed the new anaconda, or we could have reverted and taken the hit in f19 to land the new anaconda, etc. It had to be done, sooner is better than latter. How is sooner better? It led to a release slippage by months (!) and the installer that was released is still missing features (not only the intentionally dropped ones, which are another issue entirely). It would have been better to punt the new Anaconda to F19 or even F20, if it had to be done at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Honza Horak wrote: So to solve the live image composes issue for now I adjusted the major soname number to libmysqlclient.so.1018. I know it doesn't solve all the issues, though. Thanks, that should mitigate immediate issues mentioned in this thread. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
Honza Horak wrote: This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. And it should not satisfy it. We now changed the Requires in akonadi-mysql to mariadb-server to be sure of what we get. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Honza Horak wrote: On 03/11/2013 12:30 AM, Rex Dieter wrote: 3. And long-term, what to do about MySQL-libs getting pulled into live image composes? can it be blacklisted or something? It won't be problem only in case of live image composes, but in requiring libmysqlclient.so.18 generally, because RPM simply chooses one of the packages providing the same library. It is officially un-deterministic (usually it is the shorter one), but we cannot depend on it right now. So to solve the live image composes issue for now I adjusted the major soname number to libmysqlclient.so.1018. I know it doesn't solve all the issues, though. Can't we just remove MySQL-libs entirely? Or does MySQL-server require the client library? I wish FESCo had decided to just drop MySQL-server entirely, it would have prevented all this fiasco! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, 11 Mar 2013 19:55:39 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: Well, not sure it would. If builds were tagged into f19-pending and the tests ran from that, then tagged into f19, the max delay would be when a newrepo just started and it has to wait for the next newrepo to be added. The min delay would be that it gets added and newrepo starts right then. So with current newrepo tasks about 13min per newrepo, so thats 13 or 26 min per build. + the time it takes to run the tests themselves! The more tests you add, the longer they will take. Only with a 13 minute granularity. Ie, if they take less than 13 minutes, it's only going to take 26 min to land. They would have to take 14-26 min to miss the next one, etc. Hasn't this been discussed to death? We could have taken the hit in f18 and landed the new anaconda, or we could have reverted and taken the hit in f19 to land the new anaconda, etc. It had to be done, sooner is better than latter. How is sooner better? It led to a release slippage by months (!) and the installer that was released is still missing features (not only the intentionally dropped ones, which are another issue entirely). It would have been better to punt the new Anaconda to F19 or even F20, Why? if we reverted no work would have gone on on the new codebase, all work would have happened to bandaid the old codebase into working. So, we would have been in the exact same place for f19 or f20 or whatever. This way it's done and we can move forward with a more sane code base and get it fixed up. if it had to be done at all. https://fedoraproject.org/wiki/Anaconda/NewInstaller http://ohjeezlinux.wordpress.com/2013/02/05/anaconda-retrospective/ kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. On Mar 11, 2013, at 11:39 AM, Máirín Duffy du...@fedoraproject.org wrote: I think we forgot to turn it off on F18 for some reason. The menu has been displayed by default since F16, with the switch to GRUB2. On Mar 11, 2013, at 11:43 AM, Ryan Lerch rle...@redhat.com wrote: IIRC, in f17, the GRUB screen was not visible. (you could still press f11 to bring it up if you needed it to). Does anyone know why this behaviour changed? Esc since at least GRUB 2.00 final, maybe slightly before that. On Mar 11, 2013, at 12:02 PM, seth vidal skvi...@fedoraproject.org wrote: I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. As a Mac user who did go down the GRUB rabbit hole, I sorta wish I had those brain cells returned. OK maybe the brain cells lost were weaklings anyway, but the time lost I definitely would like to have back. A battery acid cocktail would be a kinder, faster way to get rid of enemies. On Mon, 11.03.13 12:58, Matthias Clasen (mcla...@redhat.com) wrote: - Switch to a simple spinner for the plymouth theme This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/boot.png If it weren't for the darker gray background, I'd easily mistake this for OS X booting. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Grub2 displayed a message in rawhide
Grub2 displayed a message in rawhide, fortunately my system boots to fast to read them correctly. The message is something about an obsolete parameter. In which log files i can find messages from grub? thanks, Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Ryan Lerch wrote: With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? Yes, why not display the Grub menu? Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. Not displaying any text at all would make it harder to understand that the time to press that key is now. Many people won't even understand that they have an opportunity to press a key. If the menu is displayed, it takes only a few seconds to understand that there is a choice and a countdown, and hopefully most people will quickly discover that pressing a key stops the countdown. Thus five seconds is a long enough pause. If some text like Press Esc now to choose which operating system to boot. would be displayed, then the pause would need to be long enough for the user to read and understand the instruction and then reach for the right key – and the terser the text is made the harder it will be to understand. I estimate that at least 15 seconds would be needed. Adding Press Enter to save a few seconds. would make it even more text to read and understand. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 02:41 PM, Björn Persson wrote: Yes, why not display the Grub menu? Because it's the year 2013. Not 1999. Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. Not displaying any text at all would make it harder to understand that the time to press that key is now. Many people won't even understand that they have an opportunity to press a key. Does any other computing device you own prompt you for a boot menu? Your mobile phone? Your TV (which likely has embedded Linux)? Your car? Windows? OS X? Why is that? Could it be because a boot menu is not necessary for normal operation? A normal user doesn't need to wonder Hey what kernel do I need to boot today? every time their system boots. If you are a developing developer and need to boot a different kernel or change kernel parameters then you know how to get into the boot menu -- on-screen prompts or no on-screen prompts. There is a time when developers need to distance themselves from user-interfaces and realize they are not the only user of the user-interface. This is one of those times. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Björn Persson bj...@xn--rombobjrn-67a.se Ryan Lerch wrote: With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? Yes, why not display the Grub menu? Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. And if your Fedora boxes are connected through a KVM with USB like mine, you need 2-3 seconds just for the keyboard to become ready so that it's even possible to send a keystroke. I really don't get the let's reduce functionality so we can boot faster mentality. I'd much rather wait an extra few seconds than spend all the time required to adjust configs, risk borking the boot loader's config, rebooting, etc. just so that I can do what I wanted to the first time 'round! -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
On Mon, 11 Mar 2013 03:59:23 +0100, Kevin Kofler wrote: And rest assured, dropping very old obsoletes isn't controversial in general. Oh sure it is! I don't understand why it's recommended practice to do this. I see absolutely no benefit in removing any Obsoletes. It only breaks things for people who skip more releases at a time than we expect them to (currently 1, i.e. upgrading from n-2 to n, no more) and doesn't fix or improve anything. IMHO, Obsoletes should be kept forever Forever? Too extreme IMO. Just because a single user might want to upgrade Red Hat Linux 3.0.3 to Fedora 18, is no reason to keep very old (ancient) Obsoletes in packages forever. Okay, okay, not RHL 3.0.3, let's say RHL 7.3 or 9. ;-) by default (where by default means unless there's a concrete reason to remove the Obsoletes, A concrete reason: Package names (including short-lived subpackages and Obsoletes inherited from obsolete subpackages), which have not been used anymore for a couple of years (e.g. two years), are irrelevant with regard to the upgrade paths we _try to_ support. We also try to get rid of old cruft in virtual Provides and Conflicts, btw. Just recently, I've seen a developer give up supporting C89 in a program's source code. ;-) -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc1.git0.4.fc19.x86_64 loadavg: 0.07 0.14 0.41 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 14:49:10 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 02:41 PM, Björn Persson wrote: Yes, why not display the Grub menu? Because it's the year 2013. Not 1999. There's no need for this kind of sarcastic/snarky response. I don't think Bjorn was asking an unreasonable or rude question. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
On Mon, 11 Mar 2013 18:00:54 +0100, Kevin Kofler wrote:
Michael Schwendt wrote:
A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
Why not libcfitsio.so.%{version}?
That would look more like ordinary (official) library versioning, such as
libcfitsio.so.3 - libcfitsio.so.3.330
but without the .so.3 symlink. No strong feelings though.
--
Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc1.git0.4.fc19.x86_64
loadavg: 0.09 0.48 0.66
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mar 11, 2013, at 1:41 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Ryan Lerch wrote: With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? Yes, why not display the Grub menu? If multiboot OK maybe. But if Fedora only, it's superfluous. The burden should be placed on those who want/need it displayed; not on the majority who have no need for seeing it, let alone interacting with it. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Björn Persson (bjorn@rombobjörn.se) said: Matthias Clasen wrote: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. What would there be instead? A text-mode boot menu? Or nothing at all displayed unless the user happens to know to press some key at the right moment? Ideally, we'd detect whether the previous boot failed in some way and only offer the menu then, or if the user chooses to reboot into the menu. (There's still some systemd/grub interaction work required for both of these.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
On Mon, Mar 11, 2013 at 2:53 PM, Michael Schwendt mschwe...@gmail.com wrote:
On Mon, 11 Mar 2013 18:00:54 +0100, Kevin Kofler wrote:
Michael Schwendt wrote:
A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
Why not libcfitsio.so.%{version}?
That would look more like ordinary (official) library versioning, such as
libcfitsio.so.3 - libcfitsio.so.3.330
but without the .so.3 symlink. No strong feelings though.
Another option which I employ with the opencollada library is to use
arbitrary soversioning. Upstream not only doesn't use library versions
but doesn't use ANY versioning.
I started at 0.1 or something like that and when I build a new package
I check compatibility with abi-compliance-checker. If it's not found
to be compatible, I bump the soversion macro in the spec file before
doing an official build.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11.03.13 19:21, Tomasz Torcz (to...@pipebreaker.pl) wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. “Press ESC for details” is fine. The only problem is that we have to include half of graphical stack to render this text correctly. And in correct locale. I don't think we should generate any message. Nothing at all. My BIOS doesn't print a single line, and neither does the kernel if quiet is used (which is the default). I really don't see why Plymouth or the boot loader should print any more -- unless a real problem happens, or the user explicitly asked for more, or the boot takes very long. Entering the boot loader is something that is a debugging feature, a tool for professionals. It shouldn't be too hard to expect from them to remember something as simple as maybe press shift or Space or Esc to get the boot menu or more verbose output. I mean, honestly, that's probably what most people would try automatically anyway if they want feedback from the machine. We nowadays live in times where BIOS POST takes 500ms, the kernel one second and userspace another one [1], with times like that you really don't need any bootsplash or anything. With Windows 8 the laptop BIOSes finally got fixed to be silent and quick during POST. Now its our turn to achieve the same for the boot loader and the OS, both of which we control. Lennart Footnotes: [1] Yes, we are quite far from that on Fedora, but that's unlikely to change until broken LVM finally gets kicked out of the default install, and we systematically start to care about boot times (For example, why does abrt need to run all the time, it should be absolutely enough to start it when the first coredump happens...). Also, GNOME currently takes another 8s, but I am working on that slowly but surely. -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11.03.13 18:51, Matthew Garrett (mj...@srcf.ucam.org) wrote: On Mon, Mar 11, 2013 at 06:49:16PM +0100, Lennart Poettering wrote: We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. It's worth noting that many modern systems will not register keypresses during boot by default. Moving in this direction shouldn't happen until there's worthwhile support in the desktop UI for using the boot indicators spec. We are working on this in the systemd context. We will provide a tiny mechanism, similar to localed/timedated/hostnamed that can be used by desktop UIs to choose boot into firmware, and boot into other OS features, which can then be exposed on the shutdown button in the UI, or in some configuration applet thingy or wherever the desktop UI wants to put it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 7:57 PM, Bill Nottingham nott...@redhat.com wrote: Björn Persson (bjorn@rombobjörn.se) said: Matthias Clasen wrote: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. What would there be instead? A text-mode boot menu? Or nothing at all displayed unless the user happens to know to press some key at the right moment? Ideally, we'd detect whether the previous boot failed in some way and only offer the menu then, or if the user chooses to reboot into the menu. (There's still some systemd/grub interaction work required for both of these.) It use to only be displayed if there was more than one OS configured or if the CTRL was held down. Having to press a particular key means you have to get it at the second or two where grub isn't displayed. The Ctrl option is quite nice as you can do it before the BIOS disappears. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote: On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. Somebody who is capable of installing multiple operating systems on one machine should easily be savvy enough to remember that pressing shift/esc/space/f2/whatever gets him the boot menu. If you installed multiple OSes and noticed that the boot menu is gone, wouldn't pressing these keys be your natural reaction anyway? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
We nowadays live in times where BIOS POST takes 500ms, HA! I wish mine was that fast. With all the different BIOS chips doing thier own thing for all the add-on cards and peripherals I have, it takes about 45 seconds just to get to GRUB at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11.03.13 20:41, Björn Persson (bjorn@rombobjörn.se) wrote: Ryan Lerch wrote: With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? Yes, why not display the Grub menu? Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. Not displaying any text at all would make it harder to understand that the time to press that key is now. Many people won't even understand that they have an opportunity to press a key. If the menu is displayed, it takes only a few seconds to understand that there is a choice and a countdown, and hopefully most people will quickly discover that pressing a key stops the countdown. Thus five seconds is a long enough pause. If some text like Press Esc now to choose which operating system to boot. would be displayed, then the pause would need to be long enough for the user to read and understand the instruction and then reach for the right key – and the terser the text is made the harder it will be to understand. I estimate that at least 15 seconds would be needed. Adding Press Enter to save a few seconds. would make it even more text to read and understand. Yikes. On a modern system the BIOS POST finishes within 500ms, and kernel+userspace in 2s. And you want us to spend 15s for nothing in the boot loader, for a feature only the fewest people need, and those who need anyway know how to get? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 21:07:32 +0100 Lennart Poettering mzerq...@0pointer.de wrote: I don't think we should generate any message. Nothing at all. My BIOS doesn't print a single line, and neither does the kernel if quiet is used (which is the default). I really don't see why Plymouth or the boot loader should print any more -- unless a real problem happens, or the user explicitly asked for more, or the boot takes very long. Entering the boot loader is something that is a debugging feature, a tool for professionals. It shouldn't be too hard to expect from them to remember something as simple as maybe press shift or Space or Esc to get the boot menu or more verbose output. I mean, honestly, that's probably what most people would try automatically anyway if they want feedback from the machine. I'm mostly concerned with making new professionals. We have to make the secret information discoverable if we want people to poke and prod around. If the bioses and systems years ago had been opaque we wouldn't have gotten this far. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Peter Robinson wrote: It use to only be displayed if there was more than one OS configured or if the CTRL was held down. Having to press a particular key means you have to get it at the second or two where grub isn't displayed. The Ctrl option is quite nice as you can do it before the BIOS disappears. But how are users supposed to discover it? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 6:39 PM, Máirín Duffy du...@fedoraproject.org wrote: On 03/11/2013 12:58 PM, Matthias Clasen wrote: - Turn off the graphical grub screen I don't know why - I think grub2 is just a PITA to work with compared to grub - but the intention here was that it should be turned off by default in final releases, and on in alpha/beta releases. I think we forgot to turn it off on F18 for some reason. https://bugzilla.redhat.com/show_bug.cgi?id=737339 It is not just that simple unfortunately ...but this is a regression which we should fix at some point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 8:07 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 11.03.13 19:21, Tomasz Torcz (to...@pipebreaker.pl) wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. “Press ESC for details” is fine. The only problem is that we have to include half of graphical stack to render this text correctly. And in correct locale. I don't think we should generate any message. Nothing at all. My BIOS doesn't print a single line, and neither does the kernel if quiet is used (which is the default). I really don't see why Plymouth or the boot loader should print any more -- unless a real problem happens, or the user explicitly asked for more, or the boot takes very long. Entering the boot loader is something that is a debugging feature, a tool for professionals. It shouldn't be too hard to expect from them to remember something as simple as maybe press shift or Space or Esc to get the boot menu or more verbose output. I mean, honestly, that's probably what most people would try automatically anyway if they want feedback from the machine. We nowadays live in times where BIOS POST takes 500ms, the kernel one second and userspace another one [1], with times like that you really don't need any bootsplash or anything. With Windows 8 the laptop BIOSes finally got fixed to be silent and quick during POST. Now its our turn to achieve the same for the boot loader and the OS, both of which we control. Clearly you haven't used any modern EFI server systems where I've used systems which take 15 minutes to post (and I can kickstart an entire RHEL-6 install less than 7 mins) and are generally longer than their predecessors Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Lennart Poettering wrote: If some text like Press Esc now to choose which operating system to boot. would be displayed, then the pause would need to be long enough for the user to read and understand the instruction and then reach for the right key – and the terser the text is made the harder it will be to understand. I estimate that at least 15 seconds would be needed. Adding Press Enter to save a few seconds. would make it even more text to read and understand. Yikes. On a modern system the BIOS POST finishes within 500ms, and kernel+userspace in 2s. And you want us to spend 15s for nothing in the boot loader, for a feature only the fewest people need, and those who need anyway know how to get? No, those 15 seconds were my argument for why it should NOT be done that way. As I already wrote, if the Grub menu is simply displayed, then five seconds is enough. Much better. And if you want to save those five seconds you just need to press Enter. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
