Re: how to have yum prefer one dependency over others
On Mon, 2011-09-19 at 18:11 +0200, drago01 wrote: So I don't get what this flamefest is all about ... catching up on the thread at a remove of a couple of weeks, I'd say mostly it's about giant, swingingegos. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dealing with circular BuildRequires?
So I started experimenting with updating libpng to a new release series, and soon found out that it was impossible to rebuild its dependencies. For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On 10/05/2011 02:41 AM, Adam Williamson wrote: You can try rebuilding your live image with this patch to spin-kickstarts: https://bugzilla.redhat.com/show_bug.cgi?id=739446 to see if it makes any difference. it migrates the livesys stuff to systemd, at least to an extent. -- Migrating livesys itself is just part of it as I found out when I looked at converting the livesys service in what middle of july but due to lack of time/interest from spin SIG we did not make that convertion in time for F16 anyway we are running a bunch of service that dont belong on a livecd/usb ( and on a desktop as well ) as has already be mentioned. If I can recollect then the livecd/usb tools needed to be looked at and patched for proper systemd integration and they seemed to depended on /dev/root which is a pretty broken concept today amongst other things which was amongst few of the gotcha as I ran into while migrating that stuff. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 10/05/2011 12:18 AM, Lennart Poettering wrote: On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote: I have a similar problem with some bind mounts over the root filesystem where systemd mounts them while the rootfs is still ro and hence they all wind up as ro until I remount them. Is there a bugzilla about this? Looks like https://bugzilla.redhat.com/show_bug.cgi?id=718464 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 05/10/11 08:51, Michal Schmidt wrote: On 10/05/2011 12:18 AM, Lennart Poettering wrote: On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote: I have a similar problem with some bind mounts over the root filesystem where systemd mounts them while the rootfs is still ro and hence they all wind up as ro until I remount them. Is there a bugzilla about this? Looks like https://bugzilla.redhat.com/show_bug.cgi?id=718464 Indeed - the stupidity that is NFSv4 is my reason for having the bind mounts in question as well... I was just in the middle of setting up in a test case in a VM and raising a bug but now I guess I don't need to ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/05/2011 12:47 AM, Richard W.M. Jones wrote: On Tue, Oct 04, 2011 at 11:38:18PM +0200, Farkas Levente wrote: On 10/04/2011 05:30 PM, Eric Sandeen wrote: XFS has been proven at this scale on Linux for a very long time, is all. the why rh do NOT support it in 32 bit? there're still system that should have to run on 32 bit:-( 32-bit machines have a 32-bit index into the page cache; on x86, that limits us to 16T for XFS, as well. So 32-bit is really not that interesting for large filesystem use. If you need really scalable filesystems, I'd suggest a 64-bit machine. i mean if you support xfs and think it's better then ext4 why not support it on rhel 32bit? This is a question you should direct through Red Hat's support channels. i'm just like to ask Erik's opinion (who seems to be the fs people at rh:-) -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On 2011-10-05, Tom Lane t...@redhat.com wrote: So I started experimenting with updating libpng to a new release series, and soon found out that it was impossible to rebuild its dependencies. For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. We had similar problem when upgrading Perl to 5.14. First, we choosed dependecy-ordered builds which stopped after rebuilding about one thousand packages. Then we hit circular dependencies blocking remaining eight hunderds packages. Thus we introduced perl-specific bootstrap macro delivered by `perl' package and we conditionalized some parts of spec files by the macro. Unfortunatelly because of lack of time we stopped this process by falling back lying the new perl package provides old Perl capabilities. Naturally, we rebuilt the bootstrapped packages after removing the bootstrap macro from `perl' package again. But the big problem was *where to define the bootstrap macro because SRPMs are rebuilt in Koji within minimal build root and we need the macro available at this early stage*. Fortunatelly `perl' is part of build root, so we put it there. Originally we wanted to put the macro into perl-devel package, but this one is not available in the SRPM build root. I thing this is the real problem. There should be some package in build root driving bootstrapping and the package should be writeable by a lot of packagers. I don't think redhat-rpm-config is the best one. I think redhat-rpm-config should require other packages provided by owneres of bootstrapp-causing packages like perl, libpng etc. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
Hi, On Wed, 2011-10-05 at 00:01 +0200, Lennart Poettering wrote: On Tue, 04.10.11 14:39, Steven Whitehouse (swhit...@redhat.com) wrote: Hi, Heya, I'm looking for some info on systemd and how filesystems are mounted in Fedora. I've started looking into converting the gfs2-utils package to the new init system and run into things which are not documented (so far as I can tell). Currently there are two init scripts in gfs2-utils, one is called gfs2 and the other gfs2-cluster. Converting gfs2-cluster is trivial. It simply runs the gfs_controld daemon on boot. The more complicated conversion is the gfs2 script. This has been used historically to mount gfs2 filesystems (rather than using the system scripts for this). I assume that under the new systemd regime it should be possible to simply tell systemd that gfs2 filesystem mounting requires gfs_controld to be running in addition to the normal filesystem requirement of having the mount point accessible, and then systemd would do the mounting itself. systemd will automatically order all network mounts after network.target. It recognizes network mounts either by _netdev in the options field in fstab, or by the file system type (it has a short static list of known network file systems built in, and gfs2 is actually listed in it). systemd automatically orders mounts by their path. i.e. /foo will always be mounted before /foo/bar. So, probably you should simply order gfs2-cluster before network.target and that's already all you need to do: [Unit] Before=network.target Unfortunately I have: After=network.target because gfs_controld requires the network to be up and working in order to communicate with its peers on other nodes. gfs2-cluster has some prerequisites which require the network (i.e. dlm via the cman initscript and corosync) too. Historically people have used _netdev with gfs2, but it isn't really a good fit since although we require the network to be up and working, we are not a network filesystem as such. Things are slightly more complicated in that gfs_controld is only a requirement for gfs2 when lock_dlm is in use. For lock_nolock filesystems, mounting is just like any other local filesystem. The locking type can be specified either in fstab, or in the superblock (with fstab taking priority). Well, I'd probably recommend to just ask people to enable gfs_controld manually with systemctl enable if they want to make use of it. But if you want an automatic pulling in depending on the mount option you could write a generator. That's a tiny binary (or script) you place in /lib/systemd/system-generators/. It will be executed very very early at boot and could generate the necessary deps by parsing fstab and creating .wants symlinks in the directory the generator gets passes as argv[1]. This is fairly simple to do, but I am tempted to say that manually enabling this service is nicer in this case. Automatisms in some areas are good but manually enabling the service is sometimes an option too. There's little documentation available on generators right now, simply because we don't want to advertise them too widely yet, and prefer if people ping us if they plan to make use of it in some package. Ok, thats not a problem. The manual system you suggest is very similar to the current system, so the doc change will not be very great. Another issue which I suspect is already resolved, but I'm not quite sure how it can be specified in fstab, etc, is that of mount order of filesystems. In particular how to set up bind mounts such that they occur either before or after a specified filesystem? systemd should be smart enought to handle that automatically. For bind mounts we wait until all mount points that are prefixes of either the mount source or the mount destination are mounted before we apply the bind mounts. Lennart -- Lennart Poettering - Red Hat, Inc. Ok, excellent, so there is really just one issue to try and resolve in that case I think, which is the ordering of mounts vs. gfs_controld start, Steve. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 10/05/2011 08:55 AM, Steven Whitehouse wrote: Ok, excellent, so there is really just one issue to try and resolve in that case I think, which is the ordering of mounts vs. gfs_controld start, Hum... Could that be solved either by creating mount/path units ( for the mount point ) and or by adding to gfs_controld.service Before=local-fs.target if it needs network support the unit section of that service file would look something like this.. [Unit] Requires=network.target After=network.target Before=local-fs.target JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 743519] New: RFE: please update to 0.009
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RFE: please update to 0.009 https://bugzilla.redhat.com/show_bug.cgi?id=743519 Summary: RFE: please update to 0.009 Product: Fedora Version: 16 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-Module-Runtime AssignedTo: ppi...@redhat.com ReportedBy: p...@city-fan.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Please update Module::Runtime to 0.009 in F-16 and Rawhide as it's needed by Class::Load 0.11. Could you please add a buildroot override for 0.009 in F-16 too so that Class::Load can be built there without having to wait a week? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: how to have yum prefer one dependency over others
On 10/05/2011 01:51 AM, Adam Williamson wrote: On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote: (That said, there definitely needs to be a way to disable it, and maybe it should even be disabled by default. I personally always uninstall yum- presto. For me, it's much faster to just download packages than to rebuild them from deltas. Only users on really slow connections benefit from it.) My desktop can rebuild deltas at ~3MB/sec. So even my really fast internet connection is slower than delta rebuild. This is a meaningless comment to other people unless you provide information on what the specs of your desktop are or the speed of your internet connection. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/05/2011 04:01 AM, Farkas Levente wrote: On 10/05/2011 12:47 AM, Richard W.M. Jones wrote: On Tue, Oct 04, 2011 at 11:38:18PM +0200, Farkas Levente wrote: On 10/04/2011 05:30 PM, Eric Sandeen wrote: XFS has been proven at this scale on Linux for a very long time, is all. the why rh do NOT support it in 32 bit? there're still system that should have to run on 32 bit:-( 32-bit machines have a 32-bit index into the page cache; on x86, that limits us to 16T for XFS, as well. So 32-bit is really not that interesting for large filesystem use. If you need really scalable filesystems, I'd suggest a 64-bit machine. i mean if you support xfs and think it's better then ext4 why not support it on rhel 32bit? This is a question you should direct through Red Hat's support channels. i'm just like to ask Erik's opinion (who seems to be the fs people at rh:-) Eric is our technical lead for file system and works in the broader file system team. What Red Hat supports is determined by lots of things - some of them technical, some of them practical. Practically, we try to focus our testing and resources on the most common platforms for enterprise users. 32 bit is not that common and certainly not a reasonable choice for large file systems. Most new enterprise class servers are 64 bit these days and have been for years. I can say that as Eric's manager if that helps :) Just to be clear, this is a *Fedora* list, not a Red Hat or RHEL list, so what considerations we as a community make about what is supported in fedora are different. In Fedora, we do worry more about supporting legacy platforms so 32 bit support will go on longer. We still do have concerns about getting sufficient testing/qa resources to validate each platform. thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tuesday, October 04, 2011 10:08:33 PM Adam Williamson wrote: Windows used to have a gui that would show a ruler on your monitor and say hold a real ruler up to this and slide the slider until its the same size. Given what's been said about how windows handles DPI I can only wonder what it did, but it might be a nice thing to have. I think it was more some specific app that did that, wasn't it? I'm almost sure it was either Paint Shop Pro or the GIMP, because obviously, actual physical accuracy is quite important there. Otherwise it was something like Office. It was definitely some specific app where WYSIWYG was important, not an OS. It makes sense to do that when configuring a desktop environment like Gnome or KDE. Regards, J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Mon, Oct 03, 2011 at 15:36:27 -0400, Dave Jones da...@redhat.com wrote: So we're thinking of trying this again this thursday with a focus on 16, (but triage work on older releases is welcomed too). I have a bug (36242 at the unavailable kernel bugzilla and 684424 in Fedora) where sound being played using my motherboard sound chip and high I/O (it seems like network traffic more so than disk) results in a hang. I haven't been able to get a crash dump or traceback once the hang occurs. I'd be interested in getting this bug looked at, but I think I need some suggestions for how to get a traceback, or there isn't going to be enough info to track this down. I tried some kernel boot parameters to get watchdog timeouts, but that didn't work. Maybe I need to rebuild the kernel with a different config to really enable that feature though? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote: On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote: On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote: Let me append The Blame Game. # systemd-analyze blame 32983ms livesys.service 22828ms NetworkManager.service That timing for NM is so vastly different than what I'm seeing on my installed F15 system. I am intrigued. His numbers are all huge as he's booting live, either from an actual rotating shiny disc thing (the antiquity of it all!) or a USB stick. Either of which is going to be slower than an HD or SSD. If this is indeed a boot from CD then it's not really surprising our numbers are bad since seek times on CDs are awful. If people want to spend optimizing the boot time here it should be possible to reorder the files on the squashfs image to minimize seeking. mksquashfs has the -sort option for that. The data would have to be generated in a two-pass way: first burn and boot the unordered image, use it to determine the access order, then pass that to mksquashfs and generate a second, ordered image. You could use systemd-readahead-collect to collect that access order information, but you'd need to write a tool to convert systemd's format to something readable by mksquashfs. Optimizations like this are always thinkable, but then again spending the time on optimizing CD boots sounds like a lot of time wasted on yesterday's technology. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load] Update to 0.11
commit bf9aac4dbf863548c7b15f6ffe58f5c5f5473862
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 5 13:30:54 2011 +0100
Update to 0.11
- New upstream release 0.11:
- Don't accept package names that start with a digit
- Rewrite some of the guts to use Module::Runtime rather than
reimplementing
its functionality
- BR: perl(Module::Runtime) ≥ 0.009
- Drop all support for older distributions as required module
Module::Runtime ≥ 0.009 will not be available prior to F-16
Class-Load-0.08-no-Test::Requires.patch | 25
Class-Load-0.08-stopwords.patch | 13 --
Class-Load-0.09-old-Test::More.patch| 224 ---
Class-Load-0.09-old-eu::mm.patch| 11 --
perl-Class-Load.spec| 48 ++-
sources |2 +-
6 files changed, 12 insertions(+), 311 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index e105277..d1cf845 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,17 +1,12 @@
Name: perl-Class-Load
-Version: 0.10
+Version: 0.11
Release: 1%{?dist}
Summary: A working (require Class::Name) and more
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Class-Load/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Class-Load-%{version}.tar.gz
-Patch0:Class-Load-0.09-old-Test::More.patch
-Patch2:Class-Load-0.09-old-eu::mm.patch
-Patch3:Class-Load-0.08-no-Test::Requires.patch
-Patch5:Class-Load-0.08-stopwords.patch
BuildArch: noarch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
# ===
# Module build requirements
# ===
@@ -20,6 +15,7 @@ BuildRequires:perl(ExtUtils::MakeMaker)
# Module requirements
# ===
BuildRequires: perl(Data::OptList)
+BuildRequires: perl(Module::Runtime) = 0.009
BuildRequires: perl(Package::Stash) = 0.32
BuildRequires: perl(Try::Tiny)
# ===
@@ -36,15 +32,9 @@ BuildRequires: perl(Test::NoTabs)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(Test::Spelling), aspell-en
-# Modules not in EPEL-4
-%if 0%{?fedora} || 0%{?rhel} 4
BuildRequires: perl(Test::Requires)
-%endif
-# Modules not in EPEL-4/5/6
-%if 0%{?fedora} || 0%{?rhel} 6
BuildRequires: perl(Pod::Coverage::Moose)
BuildRequires: perl(Test::CPAN::Changes)
-%endif
# ===
# Runtime requirements
# ===
@@ -67,50 +57,34 @@ provide is_class_loaded 'Class::Name'.
%prep
%setup -q -n Class-Load-%{version}
-# We need to patch the test suite if we have Test::More 0.88
-%if %{?rhel} == 4 || %{?rhel} == 5
-%patch0 -p1
-%endif
-
-# Work around absence of Test::Requires and ancient ExtUtils::MakeMaker if
necessary
-%if %{?rhel} == 4
-%patch2 -p1
-%patch3 -p1
-%endif
-
-# Add extra stopwords to spell check test to account for dictionary
-# coverage differences between distros
-%patch5 -p1
-
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
%{_fixperms} %{buildroot}
%check
-# Pod Coverage test breaks the build if we don't have Pod::Coverage::Moose
-%if ! 0%{?fedora} 0%{?rhel} = 6
-mv t/release-pod-coverage.t .
-%endif
make test RELEASE_TESTING=1
-[ -f release-pod-coverage.t ] mv release-pod-coverage.t t/
-
-%clean
-rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes LICENSE README
%{perl_vendorlib}/Class/
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Wed Oct 5 2011 Paul Howarth p...@city-fan.org - 0.11-1
+- Update to 0.11:
+ - Don't accept package names that start with a digit
+ - Rewrite some of the guts to use Module::Runtime rather than reimplementing
+its functionality
+- BR: perl(Module::Runtime) ≥ 0.009
+- Drop all support for older distributions as required module
+ Module::Runtime ≥ 0.009 will not be available prior to F-16
+
* Tue Sep 6 2011 Paul Howarth p...@city-fan.org - 0.10-1
- Update to 0.10:
- Fix is_class_loaded to ignore $ISA (but still look for @ISA) when trying to
diff --git a/sources b/sources
index c09000f..1823280 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-737bc23977e0240180954c2872faa50d Class-Load-0.10.tar.gz
+02180e505179e1ea718a5a22f93d2c0c Class-Load-0.11.tar.gz
--
Fedora Extras Perl SIG
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 15:09, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote: On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote: On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote: Let me append The Blame Game. # systemd-analyze blame 32983ms livesys.service 22828ms NetworkManager.service That timing for NM is so vastly different than what I'm seeing on my installed F15 system. I am intrigued. His numbers are all huge as he's booting live, either from an actual rotating shiny disc thing (the antiquity of it all!) or a USB stick. Either of which is going to be slower than an HD or SSD. If this is indeed a boot from CD then it's not really surprising our numbers are bad since seek times on CDs are awful. If people want to spend optimizing the boot time here it should be possible to reorder the files on the squashfs image to minimize seeking. mksquashfs has the -sort option for that. The data would have to be generated in a two-pass way: first burn and boot the unordered image, use it to determine the access order, then pass that to mksquashfs and generate a second, ordered image. You could use systemd-readahead-collect to collect that access order information, but you'd need to write a tool to convert systemd's format to something readable by mksquashfs. Optimizations like this are always thinkable, but then again spending the time on optimizing CD boots sounds like a lot of time wasted on yesterday's technology. Might be interesting to just compare the CD boot speed with the same image on a USB stick. That should giva an idea. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote: Results interpretation. --- Knoppix won by a wide margin, while: - Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts) and DE with low resources usage and tailored for desktops - Fedora having systemd parallel boot and DE tailored for small and simple devices ^ huh? Fedora is not tailored for that. Would be great of it it was, but that's simply not the case. We install LVM and iSCSI and all kinds of other enterprisey stuff on even the smallest netbook. [...] This is a great writeup. Why don't you add it to your systemd for sysadmins series? And/or some page on boot speedup in the Fedora wiki? Thanks for the pointers! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Tue, 04.10.11 19:40, Adam Williamson (awill...@redhat.com) wrote: On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote: On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote: 13837ms udev-settle.service 11392ms plymouth-start.service if you use the plot option instead of blame option and produce the svg of the service timing you get a better feel for what Lennart was talking about with regard to the udev settle being problematic. I'll try to break it down for you. Keep the following in mind when you look over the svgs produced in susequent testing. udev-settle.service essentially calls udevadm settle and that's all it does. udevadm settle takes FOREVER (15 seconds) to return during boot up on my live media run But its returns more quickly on on F15 install (3 seconds). I'll check a full F16 beta install soonish. And remember that all udevadm settle does is wait for the udev event queue to empty. So essentially all that's going on here is 'wait for udev to be done', which is a fairly sensible prerequisite for all manner of other bits of boot. Nah, this is not a sensible prerequisite. User code should *not* have to wait for udev to be settled. They key message Kay and I and everybody else involved in udev/systemd and related technologies want to get into everybodies head is that applications should never ever expect that everything is settled, since that is simply not possible (i.e. USB init times are unbounded -- so how do you know that the usb disk fully initialized when you settled the udev queue?) and all attempts to fake that are major sources of slowness at boot (to deal with USB and stuff people basically just wait a couple of seconds, which doesn't fix the problem, just tapes over it). Or in other words: udev settle is a hack and is not part of our boot anymore -- unless LVM pulls it in. And the fact that it pulls it in is sad, and has been a constant source of complaining from us to the LVM folks over the years. They major point to make here is that all components of the system should wait exactly as long as they have to and not longer. More specifically: they should wait for the specific hardware they are needing but not any longer. Example: when mounting the file systems systemd will wait exactly until the point all devices listed in /etc/fstab have shown up -- but not any longer before continuing. And again, in short words: udev settle is a hack. Only broken code needs it. It has no place in a modern system. The reasons why udev takes a while to be 'done' are more interesting and Lennart went into some of them. It is completely fine if some probing done by udev rules takes a long time. It's not just fine, it's even expected. For example, I have a 3G card in my laptop I don't use. Since it has no SIM card it takes about 8s seconds to probe (i.e. the firmware finds it funny to reply with an 8s delay to AT commands if no SIM card is in the card). Now, there's no sensible way around this, since the the hw just takes that long to probe. As long as these 8s are spent in the background they shouldn't matter at all. Except that LVM requires settling of all devices, and hence simply enabling LVM means my boot is delayed for a whole 8s. Now thankfully, I opted out of LVM when I installed Fedora on my machine. That way the 8s probing of the modem continues in the background long after gdm is already up. That's why I mentioned in that earlier mail to ajax that I am not concerned that EDID takes so long: because it is OK. What isn't OK is that LVM has to wait for EDID and for my 3G modem probing to complete, and thus delays our entire boot. LVM needs to be ported to listen to hotplug events, and make use of devices as they show up, instead of expecting that all hardware has already shown up and has been probed before LVM is started. For a number of reasons: to not slow down the boot artificially, to fix the enumeration race and become fully compatible with today's storage technology that is much more dynamic than 10 years ago, and to become robust. Please, don't claim that udev settle was a sensible prerequisite. It isn't. It has no place in today's dynamic hardware. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Wed, 05.10.11 10:17, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote: Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote: Results interpretation. --- Knoppix won by a wide margin, while: - Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts) and DE with low resources usage and tailored for desktops - Fedora having systemd parallel boot and DE tailored for small and simple devices ^ huh? Fedora is not tailored for that. Would be great of it it was, but that's simply not the case. We install LVM and iSCSI and all kinds of other enterprisey stuff on even the smallest netbook. [...] This is a great writeup. Why don't you add it to your systemd for sysadmins series? And/or some page on boot speedup in the Fedora wiki? Thanks for the pointers! Harald posted a blog story about this a while back: http://www.harald-hoyer.de/personal/blog/fedora-15-8-services-you-can-most-likely-disable http://www.harald-hoyer.de/personal/blog/fedora-15-boot-optimization I guess we could do an updated version for F16 of that since a couple of thing changed since then. For example the SELinux policy got updated now so that initrd-less boots do not trigger selinux faults anymore. In fact, initrd-less boots work really nicely nowadays, the only two missing bit to maybe make it a default is basically that a) the kernel cannot boot into a partition by UUID, only by logic name which is a bit fragile [1] and b) Plymouth currently doesn't cope nicely with it since it's called before the video devices are probed if used without an initrd. Lennart [1] What the kernel can do nowadays is mount a GUID partition by the GUID, which might be a pretty good replacement -- at least on machines which have a GUID partition table. -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20111005 changes
Compose started at Wed Oct 5 08:15:57 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicudata.so.46()(64bit) R-core-2.13.1-4.fc17.i686 requires libicuuc.so.46 R-core-2.13.1-4.fc17.i686 requires libicui18n.so.46 R-core-2.13.1-4.fc17.x86_64 requires libicuuc.so.46()(64bit) R-core-2.13.1-4.fc17.x86_64 requires libicui18n.so.46()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave eog-plugins-3.1.2-2.fc16.x86_64 requires libcogl.so.2()(64bit) eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit) fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 15:28, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 04.10.11 19:40, Adam Williamson (awill...@redhat.com) wrote: On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote: On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote: 13837ms udev-settle.service 11392ms plymouth-start.service if you use the plot option instead of blame option and produce the svg of the service timing you get a better feel for what Lennart was talking about with regard to the udev settle being problematic. I'll try to break it down for you. Keep the following in mind when you look over the svgs produced in susequent testing. udev-settle.service essentially calls udevadm settle and that's all it does. udevadm settle takes FOREVER (15 seconds) to return during boot up on my live media run But its returns more quickly on on F15 install (3 seconds). I'll check a full F16 beta install soonish. And remember that all udevadm settle does is wait for the udev event queue to empty. So essentially all that's going on here is 'wait for udev to be done', which is a fairly sensible prerequisite for all manner of other bits of boot. Nah, this is not a sensible prerequisite. User code should *not* have to wait for udev to be settled. They key message Kay and I and everybody else involved in udev/systemd and related technologies want to get into everybodies head is that applications should never ever expect that everything is settled, since that is simply not possible (i.e. USB init times are unbounded -- so how do you know that the usb disk fully initialized when you settled the udev queue?) and all attempts to fake that are major sources of slowness at boot (to deal with USB and stuff people basically just wait a couple of seconds, which doesn't fix the problem, just tapes over it). Or in other words: udev settle is a hack and is not part of our boot anymore -- unless LVM pulls it in. And the fact that it pulls it in is sad, and has been a constant source of complaining from us to the LVM folks over the years. They major point to make here is that all components of the system should wait exactly as long as they have to and not longer. More specifically: they should wait for the specific hardware they are needing but not any longer. Example: when mounting the file systems systemd will wait exactly until the point all devices listed in /etc/fstab have shown up -- but not any longer before continuing. And again, in short words: udev settle is a hack. Only broken code needs it. It has no place in a modern system. The reasons why udev takes a while to be 'done' are more interesting and Lennart went into some of them. It is completely fine if some probing done by udev rules takes a long time. It's not just fine, it's even expected. For example, I have a 3G card in my laptop I don't use. Since it has no SIM card it takes about 8s seconds to probe (i.e. the firmware finds it funny to reply with an 8s delay to AT commands if no SIM card is in the card). Now, there's no sensible way around this, since the the hw just takes that long to probe. As long as these 8s are spent in the background they shouldn't matter at all. Except that LVM requires settling of all devices, and hence simply enabling LVM means my boot is delayed for a whole 8s. Now thankfully, I opted out of LVM when I installed Fedora on my machine. That way the 8s probing of the modem continues in the background long after gdm is already up. That's why I mentioned in that earlier mail to ajax that I am not concerned that EDID takes so long: because it is OK. What isn't OK is that LVM has to wait for EDID and for my 3G modem probing to complete, and thus delays our entire boot. LVM needs to be ported to listen to hotplug events, and make use of devices as they show up, instead of expecting that all hardware has already shown up and has been probed before LVM is started. For a number of reasons: to not slow down the boot artificially, to fix the enumeration race and become fully compatible with today's storage technology that is much more dynamic than 10 years ago, and to become robust. Please, don't claim that udev settle was a sensible prerequisite. It isn't. It has no place in today's dynamic hardware. Just to make sure that the message is clearly understood and there is nothing sensible in making any assumptions ever, like: 'all devices are there / we have settled'. That can never be true on today's systems. Any system service that today relies in its core on 'udevadm settle' or scsi-wait-scan module, or any of the other bad hacks in that category, anything that uses these barriers as a checkpoint to block on, to do its synchronous actions, should be considered non-hotplug capable, need to be fixed or legacy. The Fedora storage assembly shell scripts really need to be replaced by something that fits into today's reality. There are a few valid
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 19:05 -0700, Adam Williamson wrote: 96dpi, however, is almost *never* correct, is it? So just taking a hardcoded number that Microsoft happened to pick a decade ago is hardly improving matters. The X default used to be 72dpi. Maybe it'll be something else in the future, and then I can get bitched at more for having changed it yet again by people still using a fundamentally unreliable API. It still seems to me that taking the EDID number if it seems reasonably plausible and falling back to 96dpi otherwise is likely a better option. I reiterate: X gives you the actual sizes (as best as we can guess) on the RANDR outputs. The global size that we default to 96dpi is broken to rely on in any event, because X simply has no mechanism for updating it besides reconnecting to the display. We could add a request to re-fetch the connection handshake block, but if you're going to update all your apps to use that request, you might as well update all your apps to use the existing RANDR's geometry information instead. If the UI wants to be sensitive to DPI, then do me the favor of using the DPI numbers that map 1:1 to actual monitors, instead of a single number that can never be an accurate reflection of reality. Your examples lean a lot on TVs and projectors, but are those really the key use cases we have to consider? What about laptops and especially tablets, whose resolutions are gradually moving upwards (in the laptop case despite the underlying software problems, in the tablet case because the underlying software doesn't have such a problem)? Is it really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7 tablet and it comes up with zonking huge fonts all over the place? I'm going to not mention the traditional monitors I've seen with bad EDID. I'm going to not mention the laptops I've seen that report 0x0 physical size, or something non-zero and fictitious. I'm going to not mention the laptops where you simply don't get EDID, you get some subset buried in the video ROM, and you get to hope that it might have physical size encoded in it. I'm going to not mention that DPI is only approximately what you want anyway, and that you actually need to know dots per unit arc, which is a function of both display size and view distance. I'm going to simply quote myself from another message in this thread: How people use this information is entirely not my concern. My job is to get the pixels on the screen; it might be to try valiantly to tell you how big they are; it is not to decide if they're big enough. I think it's worth considering that, even though Microsoft's crappiness with resolution independence has probably hindered the market artificially for a while, the 96dpi number which comes from the capabilities of CRT tubes circa 1995 bears increasingly little resemblance to the capabilities of modern displays, and assuming we can just keep hardcoding 96dpi and monitor technology will remain artificially retarded forever is likely not a great thing to do. I don't believe that was a position I was defending. I would caution you against thinking that there's some DPI revolution right around the corner. That's the same fallacy that rages against the TV industry for stalling at 1080p. Linear increases in DPI are quadratic increases in link bandwidth, and maxed-out single-link DVI (the source of the 1080p limit) is already a higher symbol rate than gigabit ethernet. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
On Tue, Oct 04, 2011 at 09:32:28PM -0700, Garrett Holmstrom wrote: On 2011-10-04 12:01, Toshio Kuratomi wrote: So my solyution: foo-0-1.20110120git.fc16 vs Your solution: foo-20110120-1.20110120git.fc16 (Since it's a snapshot, the date has to go into the release string anyway) Which is uglier? Also, since these are snapshots, a date in the upstream version field isn't really that great either. Which branch is this from? Which repository (in the case of DVCS)? With respect to a package's n-v-r, it doesn't matter which repository one's checkout of a given git commit comes from. One of git's main tenets is that a given hash refers to the same object in every repository in which it exists. Git commit hashes are also independent of the branches (if any) that point to them. With respect to recording source URLs, we already require commentary with a list of commands when people pull sources directly from version control. This will necessarily include a URL for the appropriate git repository. Now do we want to put the git hash into the version field too? For the package's n-v-r alone to uniquely refer to a given commit it *must* contain the hash in a case such as this. To comply with packaging guidelines it also needs to contain a date and the string git. This means it would need to contain 20111005git0123456. To clarify what I meant since it seems both you and Ralf read this differently than I intended: I'm starting by saying that using date alone is not sufficient to identify the checkout and therefore should not be used in the upstream Version: field. I then put forward what I think people's next candidate would be: the git hash. At that point, (I thought this but perhaps didn't write it out) you run into the problem where the git hash does not increment and therefore you potentially need to bump epoch with every release. So the git hash is also not a good candidate for the upstream version field. (I would also posit that the date is unnecessary, as it may not identify a unique commit, but that is a topic for another thread.) The rationale is that the Release field is documenting for two audiences. The important audience is the end user. The end user either doesn't know or doesn't want to go through the trouble of verifying what version of software a git hash refers to. They just want to be able to say that a bug was fixed on January 1, 2011 or that Ubuntu has the 0.11 release from February 2, 2012 and then compare that to the Fedora package. The second audience is other packagers and developers of the software. These people may want to grab the exact snapshot of the software from upstream. If they don't want to open up the spec file to see our comments on how to get the snapshot (maybe they're actually Ubuntu devs and don't know how to get at that information easily) the release field may optionally provide this information. -Toshio pgpAjvBypxtOn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
On Wed, Oct 05, 2011 at 06:53:50AM +0200, Ralf Corsepius wrote: On 10/04/2011 09:01 PM, Toshio Kuratomi wrote: Now do we want to put the git hash into the version field too? Yes, because git checkouts by date are not sufficiently reliable to provide deterministic checkouts from git. I hope you don't really mean this. git hashes belong in the Release field; not in the version field. -Toshio pgp8UNwWCOi2U.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Wed, Oct 05, 2011 at 07:33:22AM -0500, Bruno Wolff III wrote: On Mon, Oct 03, 2011 at 15:36:27 -0400, Dave Jones da...@redhat.com wrote: So we're thinking of trying this again this thursday with a focus on 16, (but triage work on older releases is welcomed too). I have a bug (36242 at the unavailable kernel bugzilla and 684424 in Fedora) where sound being played using my motherboard sound chip and high I/O (it seems like network traffic more so than disk) results in a hang. I haven't been able to get a crash dump or traceback once the hang occurs. I'd be interested in getting this bug looked at, but I think I need some suggestions for how to get a traceback, or there isn't going to be enough info to track this down. I tried some kernel boot parameters to get watchdog timeouts, but that didn't work. Maybe I need to rebuild the kernel with a different config to really enable that feature though? The kernel-debug rpm should have everything you'd need. Hardware specific problems like this are a nightmare for us to diagnose. It might even come down to you needing to do a bisect to find the individual kernel change that caused the problem. (assuming you know a 'good' version to start from) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
Lennart Poettering mzerq...@0pointer.de wrote: [Optimize boot on CD] Optimizations like this are always thinkable, but then again spending the time on optimizing CD boots sounds like a lot of time wasted on yesterday's technology. Humm... for a LiveCD for forensic work (at least) it should be worthwhile, and as long as installation DVDs are distributed, it should be considered for them too. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 Ramon de C Valle rcva...@redhat.com changed: What|Removed |Added Status Whiteboard|impact=moderate,public=2010 |impact=moderate,public=2010 |1110,reported=20101201,sour |1110,reported=20101201,sour |ce=redhat,cvss2=4.3/AV:N/AC |ce=redhat,cvss2=4.3/AV:N/AC |:M/Au:N/C:N/I:P/A:N,fedora- |:M/Au:N/C:N/I:P/A:N,fedora- |all/perl-CGI=affected,rhel- |all/perl-CGI=affected,rhel- |6.1/perl=affected,rhel-5/pe |6.1/perl=affected,rhel-5/pe |rl=affected |rl=affected,rhel-4/perl=aff ||ected -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 Ramon de C Valle rcva...@redhat.com changed: What|Removed |Added Depends on||743626 Depends on||743627 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 Ramon de C Valle rcva...@redhat.com changed: What|Removed |Added Status Whiteboard|impact=moderate,public=2010 |impact=moderate,public=2010 |1110,reported=20101201,sour |1110,reported=20101201,sour |ce=redhat,cvss2=4.3/AV:N/AC |ce=redhat,cvss2=4.3/AV:N/AC |:M/Au:N/C:N/I:P/A:N,fedora- |:M/Au:N/C:N/I:P/A:N,fedora- |all/perl-CGI=affected,rhel- |all/perl-CGI=affected,rhel- |6.1/perl=affected,rhel-5/pe |6.1/perl=affected,rhel-5/pe |rl=affected,rhel-4/perl=aff |rl=affected,rhel-4/perl=aff |ected |ected,fedora-all/perl=affec ||ted -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora 16 beta vice Knoppix
On Wed, 05.10.11 11:40, Horst H. von Brand (vonbr...@inf.utfsm.cl) wrote: Lennart Poettering mzerq...@0pointer.de wrote: [Optimize boot on CD] Optimizations like this are always thinkable, but then again spending the time on optimizing CD boots sounds like a lot of time wasted on yesterday's technology. Humm... for a LiveCD for forensic work (at least) it should be worthwhile, and as long as installation DVDs are distributed, it should be considered for them too. If you think that way, then please start working on it. I am sure the Fedora LiveCD folks would be delighted to get patches for this! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/4/11 6:53 PM, Ric Wheeler wrote: On 10/04/2011 07:19 PM, Przemek Klosowski wrote: On 10/03/2011 06:33 PM, Eric Sandeen wrote: On 10/3/11 5:13 PM, Richard W.M. Jones wrote: On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote: testing something more real-world (20T ... 500T?) might still be interesting. Here's my test script: qemu-img create -f qcow2 test1.img 500T \ guestfish -a test1.img \ memsize 4096 : run : \ part-disk /dev/vda gpt : mkfs ext4 /dev/vda1 ... At 100T it doesn't run out of memory, but the man behind the curtain starts to show. The underlying qcow2 file grows to several gigs and I had to kill it. I need to play with the lazy init features of ext4. Rich. Bleah. Care to use xfs? ;) WHy not btrfs? I am testing a 24TB physical server and ext4 creation took forever while btrfs was almost instant. I understand it's still experimental (I hear storing virtual disk images on btrfs still has unresolved performance problems) but vm disk storage should be fine. FWIW I have been using btrfs as my /home at home for some time now; so far so good. Creating an XFS file system is also a matter of seconds (both xfs and btrfs do dynamic inode allocation). Note that ext4 has a new feature that allows inodes to be initialized in the background, so you will see much quicker mkfs.ext4 times as well :) right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. -Eric ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi, Introducing myself as a prospective new package maintainer for Fedora. I recently filed a review request: https://bugzilla.redhat.com/show_bug.cgi?id=743615 I'm the author of a few Nagios plugins, one of which has become widely used. The review above is for this plugin, check_openmanage. I believe it will be a useful addition to Fedora. Target branches are EPEL5, EPEL6 and the current Fedora releases. I work as a system administrator at the University of Oslo, Norway, managing Linux servers and clients. I have been a Linux user for many years. My first distro was Red Hat 4.1, then I briefly tried Slackware for a while before returning to Red Hat. I have been a faithful Fedora/RH user ever since, Fedora personally and RHEL professionally. SRPM and spec file for the package are here: http://folk.uio.no/trondham/review/ Thanks - I'm looking forward to joining the community and helping out. Regards, -- Trond H. Amundsen t.h.amund...@usit.uio.no Center for Information Technology Services, University of Oslo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 --- Comment #18 from Ramon de C Valle rcva...@redhat.com 2011-10-05 10:55:37 EDT --- Created perl-CGI tracking bugs for this issue Affects: fedora-all [bug 743629] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 Ramon de C Valle rcva...@redhat.com changed: What|Removed |Added Depends on||743629 Depends on||743630 --- Comment #17 from Ramon de C Valle rcva...@redhat.com 2011-10-05 10:55:30 EDT --- Created perl tracking bugs for this issue Affects: fedora-all [bug 743630] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 743629] New: perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=743629 Summary: perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting [fedora-all] Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: medium Priority: medium Component: perl-CGI AssignedTo: mmasl...@redhat.com ReportedBy: rcva...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Blocks: 658976 Classification: Fedora Story Points: --- Type: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the Security Response product. Please mention CVE ids in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=658976 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 743629] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=743629 Ramon de C Valle rcva...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG Last Closed||2011-10-05 11:07:41 --- Comment #1 from Ramon de C Valle rcva...@redhat.com 2011-10-05 11:07:41 EDT --- Already fixed. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658976] perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658976 Bug 658976 depends on bug 743629, which changed state. Bug 743629 Summary: perl-CGI, perl-CGI-Simple: CVE-2010-2761 - hardcoded MIME boundary value for multipart content, CVE-2010-4410 - CRLF injection allowing HTTP response splitting [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=743629 What|Old Value |New Value Resolution||NOTABUG Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora kernel bug day.
Once upon a time, Dave Jones da...@redhat.com said: Hardware specific problems like this are a nightmare for us to diagnose. It might even come down to you needing to do a bisect to find the individual kernel change that caused the problem. (assuming you know a 'good' version to start from) I know suspend is another fun area, but are there any good tools to figure out what is wrong when suspend/resume doesn't work right? I've got a problem system (RH BZ 548593) that I don't know what else I can do to try to fix. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
JB jb.1234abcd at gmail.com writes: ... The only difference to previous run is that ethernet cable (with good ISP service) was plugged in during boot time. You can see userspace time, and thus total time reduced by more than 300%. # less -i /var/log/messages ... Oct 5 05:33:51 localhost systemd[1]: Startup finished in 1s 456ms 73us (kernel) + 12s 580ms 860us (initrd) + 1min 6s 747ms 352us (userspace) = 1min 20s 784ms 285us. ... # systemd-analyze blame 35513ms livesys.service 25004ms NetworkManager.service 20153ms bluetooth.service 20103ms ip6tables.service 20101ms iptables.service 19726ms sshd-keygen.service 19710ms abrtd.service 17752ms systemd-logind.service 17708ms avahi-daemon.service 13914ms udev-settle.service 8484ms dbus.service 6019ms fedora-loadmodules.service 4972ms mcelog.service 4782ms fcoe.service 4659ms auditd.service 4494ms multipathd.service 4330ms systemd-vconsole-setup.service 3862ms irqbalance.service 3248ms media.mount 3112ms udev-trigger.service 3102ms rsyslog.service 3046ms abrt-ccpp.service 3022ms mdmonitor-takeover.service 2987ms fedora-readonly.service 2490ms console-kit-log-system-start.service 2446ms systemd-remount-api-vfs.service 2335ms udev.service 1391ms systemd-tmpfiles-setup.service 1225ms fedora-storage-init.service 997ms systemd-sysctl.service 759ms systemd-readahead-collect.service 731ms remount-rootfs.service 577ms sm-client.service 518ms netfs.service 218ms fedora-wait-storage.service 131ms fedora-storage-init-late.service 122ms sendmail.service 92ms lvm2-monitor.service 60ms livesys-late.service 54ms console-kit-daemon.service 37ms sandbox.service 34ms iscsi.service 22ms systemd-user-sessions.service 21ms rtkit-daemon.service 14ms accounts-daemon.service Full outputs to analyze and plot are available below (valid for 30 days). Full /var/log/messages: http://pastebin.com/7jh2rHVk Full 'systemd-analyze plot plot.svg': http://pastebin.com/VY8wFUkt JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to reach a package maintainer for deprecation request
On Mon, 3 Oct 2011 10:03:55 -0700 Steve Jenkins stevejenk...@gmail.com wrote: I'm not sure of the correct protocol in cases like this, so any guidance is appreciated. Early last month, I sent a message to all the addresses I could find for Jim Radford (jradford), the maintainer of the dkim-milter package: https://admin.fedoraproject.org/pkgdb/acls/name/dkim-milter ...snip... https://bugzilla.redhat.com/show_bug.cgi?id=740965 However, still no response. Any suggestions as to what to do next? I'd give him a bit more time to respond on the bug... and then if he doesn't in say another week or so, lets just go ahead and depreciate the package. (Any provenpackager should be able to do that). Feel free to ping me in a week or so if you haven't heard from them and we can get it taken care of. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Tue, Oct 4, 2011 at 6:40 PM, Adam Williamson awill...@redhat.com wrote: So essentially all that's going on here is 'wait for udev to be done', which is a fairly sensible prerequisite for all manner of other bits of boot. The reasons why udev takes a while to be 'done' are more interesting and Lennart went into some of them. Right, and as I've said..in the context of the comparison with Knoppix specifically I found evidence that udev settle use to be a long boot up blocker in previous Knoppix releases. I wouldn't be surprised at all if Knoppix init had been changed in the newest release that JB tried to no longer call the settle function (or call it with a very short timeout) But I'm not going to be downloading Knoppix and dissecting its init to prove that to myself. Its obvious from my testing that settle is one of the big blockers, a blocker multiple live distributions have hit in the last year actually. What I'm trying to do is wrap my head around is even if we defaulted to a no LVM install scenario how could we reconstitute the logic associated with fedora-local-fs so the lvm based need for udev settle was optional. It's seems like digging ourselves out of the hole while still supporting lvm as a non-default option could be complicated. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/5/11 9:58 AM, Eric Sandeen wrote: On 10/4/11 6:53 PM, Ric Wheeler wrote: ... Note that ext4 has a new feature that allows inodes to be initialized in the background, so you will see much quicker mkfs.ext4 times as well :) right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Sorry, Lukas reminds me that this should already be the default mode, with a new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria. -Eric -Eric ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Adam Williamson wrote on Tue, Oct 04, 2011 at 07:08:33PM -0700: On Tue, 2011-10-04 at 16:24 -0400, Casey Dahlin wrote: On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote: For fedora users, as others have mentioned, perhaps a UI that lets users test a couple of possible dpi values might be useful (for those users so inclined). It does have to cross a good chunk of the stack to work well, and seems like a lot of work to get right; but the xrandr improvements are a start. Windows used to have a gui that would show a ruler on your monitor and say hold a real ruler up to this and slide the slider until its the same size. Given what's been said about how windows handles DPI I can only wonder what it did, but it might be a nice thing to have. I think it was more some specific app that did that, wasn't it? I'm almost sure it was either Paint Shop Pro or the GIMP, because obviously, actual physical accuracy is quite important there. Otherwise it was something like Office. It was definitely some specific app where WYSIWYG was important, not an OS. A specific app may have done it as well, but before Vista, the DPI settings dialog box in the Control Panel had that feature. -mat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
Petr Pisar ppi...@redhat.com writes: On 2011-10-05, Tom Lane t...@redhat.com wrote: For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. We had similar problem when upgrading Perl to 5.14. First, we choosed dependecy-ordered builds which stopped after rebuilding about one thousand packages. Then we hit circular dependencies blocking remaining eight hunderds packages. What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File MooseX-Types-Structured-0.28.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-MooseX-Types-Structured: 40f9fc2bd8c66803266a1c16f8fb2742 MooseX-Types-Structured-0.28.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
[perl-MooseX-Types-Structured] update to 0.28
commit cb5c572bd5cc8cd95d14276ad0224c7011730100
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 5 18:31:56 2011 +0200
update to 0.28
.gitignore|1 +
perl-MooseX-Types-Structured.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9d47578..98a98fb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ MooseX-Types-Structured-0.23.tar.gz
/MooseX-Types-Structured-0.25.tar.gz
/MooseX-Types-Structured-0.26.tar.gz
/MooseX-Types-Structured-0.27.tar.gz
+/MooseX-Types-Structured-0.28.tar.gz
diff --git a/perl-MooseX-Types-Structured.spec
b/perl-MooseX-Types-Structured.spec
index 52e6ab9..c7f2723 100644
--- a/perl-MooseX-Types-Structured.spec
+++ b/perl-MooseX-Types-Structured.spec
@@ -1,6 +1,6 @@
Name: perl-MooseX-Types-Structured
-Version:0.27
-Release:2%{?dist}
+Version:0.28
+Release:1%{?dist}
Summary:Structured Type Constraints for Moose
License:GPL+ or Artistic
Group: Development/Libraries
@@ -63,6 +63,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Oct 05 2011 Iain Arnell iarn...@gmail.com 0.28-1
+- update to latest upstream version
+
* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.27-2
- Perl mass rebuild
diff --git a/sources b/sources
index 4e5ba40..3d52378 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-38377f3efd021b4b932cc1d0f1a8aae3 MooseX-Types-Structured-0.27.tar.gz
+40f9fc2bd8c66803266a1c16f8fb2742 MooseX-Types-Structured-0.28.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
[perl-MooseX-Types-Structured/f16] update to 0.28
Summary of changes: cb5c572... update to 0.28 (*) (*) 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-MooseX-Types-Structured/f15] (3 commits) ...update to 0.28
Summary of changes: d8d43b6... update to 0.27 (*) c4d4051... Perl mass rebuild (*) cb5c572... update to 0.28 (*) (*) 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-MooseX-Types-Structured/f14] (6 commits) ...update to 0.28
Summary of changes: ce02159... update to 0.26 (*) e722023... additional provides for packages hidden from PAUSE (*) 45876b0... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) d8d43b6... update to 0.27 (*) c4d4051... Perl mass rebuild (*) cb5c572... update to 0.28 (*) (*) 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
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 10:49 -0500, Matyas Selmeci wrote: Windows used to have a gui that would show a ruler on your monitor and say hold a real ruler up to this and slide the slider until its the same size. Given what's been said about how windows handles DPI I can only wonder what it did, but it might be a nice thing to have. I think it was more some specific app that did that, wasn't it? I'm almost sure it was either Paint Shop Pro or the GIMP, because obviously, actual physical accuracy is quite important there. Otherwise it was something like Office. It was definitely some specific app where WYSIWYG was important, not an OS. A specific app may have done it as well, but before Vista, the DPI settings dialog box in the Control Panel had that feature. ah, OK. thanks for the reminder. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On 10/05/2011 10:02 AM, Tom Lane wrote: What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... Have you looked at smock? It somehow computes the order a set of rpms need to be built in... -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Wed, Oct 05, 2011 at 10:38:18 -0400, Dave Jones da...@redhat.com wrote: The kernel-debug rpm should have everything you'd need. But I can't get the system to crash to get a traceback. It just hangs. I tried using the sysrq commands and NMI timeouts and I haven't been able to get a dump or traceback. Hardware specific problems like this are a nightmare for us to diagnose. It might even come down to you needing to do a bisect to find the individual kernel change that caused the problem. (assuming you know a 'good' version to start from) The issue goes back quite a ways (probably it last worked correctly with 2.6.29.1-68.fc11.i686.PAE). I have a USB headset now so I have been less concerned about the issue. But several months ago there were some USB issues and I switched back to motherboard sound during that time and had a number of hangs, so I opened a new bug (since I am not 100% sure it is really the same bug as 496536). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On Wed, Oct 5, 2011 at 5:02 PM, Tom Lane t...@redhat.com wrote: Petr Pisar ppi...@redhat.com writes: On 2011-10-05, Tom Lane t...@redhat.com wrote: For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. We had similar problem when upgrading Perl to 5.14. First, we choosed dependecy-ordered builds which stopped after rebuilding about one thousand packages. Then we hit circular dependencies blocking remaining eight hunderds packages. What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... regards, tom lane The nearest I can think of is smock.pl, which has a '--dryrun' option providing the dependency order information. There's some information about it here: http://www.bioinformatics.org/wiki/R-repo/setup_for_build Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On Wed, 2011-10-05 at 10:17 -0600, Nathanael D. Noblet wrote: On 10/05/2011 10:02 AM, Tom Lane wrote: What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... Have you looked at smock? It somehow computes the order a set of rpms need to be built in... smock really doesn't do that. 1. a lot of buildreqs are non-trivial to determine the proper provide for 2. it doesn't solve circular build deps. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 743519] RFE: please update to 0.009
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=743519 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-10-05 13:16:28 EDT --- Package perl-Module-Runtime-0.009-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Module-Runtime-0.009-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-Module-Runtime-0.009-1.fc16 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: release number when upstream *only* has git hashes?
On 10/05/2011 04:35 PM, Toshio Kuratomi wrote: On Wed, Oct 05, 2011 at 06:53:50AM +0200, Ralf Corsepius wrote: On 10/04/2011 09:01 PM, Toshio Kuratomi wrote: Now do we want to put the git hash into the version field too? Yes, because git checkouts by date are not sufficiently reliable to provide deterministic checkouts from git. I hope you don't really mean this. Certainly not - version - release mixup on my part :() - Sorry. git hashes belong in the Release field; not in the version field. I was advocating to mandate git hashes as part of the release-string, because checkouts by date do not work well with git. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Pugs-Compiler-Rule (un)retirement
Package perl-Pugs-Compiler-Rule in Fedora devel has been retired by steve To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Pugs-Compiler-Rule -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Pugs-Compiler-Rule (un)retirement
Package perl-Pugs-Compiler-Rule in Fedora 16 has been retired by steve To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Pugs-Compiler-Rule -- 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: GDBM upgrade in F17
On Oct 4, 2011, at 10:31 PM, Adam Williamson wrote: On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote: On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. You're thinking of creating a /new/ build target and build tag/root. That's not what bodhi does. Buildroot overrides for the rawhide tags make no sense, as anything built automatically lands in the build root. So really want they want is a *tag*, not a buildroot override, right? They can have a tag for Rawhide if they request one, I presume? I don't even know what that would mean. Tag is an overloaded term, even within koji itself. A tag is an identifier that can be applied to specific builds. It can also create a unique place to assign package ownership and package membership, e.g. bash does not exist in tag f7-nobash and bash-3.2.5-2.fc17 has been tagged with f16. Tag can also represent what collection of packages is used when a build is done for a certain build target. The f17-candidate build target makes use of the f17-build tag to populate the build root. After the build is done, the f17 tag is applied to the build. Tags also have inheritance, so the f17-build tag inherits data from the f17 tag, which is why when a build is done and is tagged with f17, it will show up in the f17-build tag and be used in the build root. We also make use of override tags, our own terminology here. By injecting a tag between f17-build and f17, we have a way of 'overriding' what will normally appear in the build root by way of f17. Thus we can temporarily 'override' a bad build, or in the case of Fedoras that are managed by updates-testing, we can short-circuit the time it would take for a certain build to wind up in the build root. Further, we can create topic based tags that inherit from a base tag, but keep any builds from winding up in the base tag. We've done this for perl rebuilds and other sweeping changes that would be very disruptive to the day to day activities. For example, we could create a tag f17-perl that inherits data and builds from f17, create a build target f17-perl that makes use of the f17-perl tag to populate the build root, and all builds when finished would get tagged with f17-perl. They would have their own little world in which to prepare a mass rebuild, and when done move it all into f17 proper. I suspect this particular scenario is what some people are looking for in bodhi for rawhide, but there is a (high) cost in the form of repo regeneration. Every time something gets tagged for f17 it will cause a newRepo call for any targets that use build tags that inherit from f17. That would be f17-candidate, and now f17-perl, and any other topic tags that exist. If there was an f18 tag at the time it would also get a repo regeneration, and any f18 topic tags. newRepo tasks are one of the most expensive things our build system does, dealing with 12K~ source packages generating something like 50K rpms on each of our arches. As much speedup as we've tried to do this is still a heavy process on the koji DB and the filesystems. So much so that we have to limit them to only 3 at a time. Once you start adding a lot of topic branches that 3 can be a hindrance and can cause significant delays in our build systems ability to keep its build roots up to date. 20 minutes or so per newRepo, 3 at a time. If you have 9 tags to regenerate it can be over 1 hour between each newRepo for each particular target. tl;dr if you're looking for bodhi to allow on-demand creation of topic-tags for isolating build efforts from rawhide, that's too expensive of an item to allow a free-for-all at this time, in my opinion. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 741576] perl-DateTime-TimeZone-1.39 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=741576 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-DateTime-TimeZone-1.39 ||-1.fc16 Resolution||ERRATA Last Closed||2011-10-05 13:36:11 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 741576] perl-DateTime-TimeZone-1.39 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=741576 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-10-05 13:36:06 EDT --- perl-DateTime-TimeZone-1.39-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora 16 beta vice Knoppix
Jef Spaleta jspaleta at gmail.com writes: On Tue, Oct 4, 2011 at 6:40 PM, Adam Williamson awilliam at redhat.com wrote: So essentially all that's going on here is 'wait for udev to be done', which is a fairly sensible prerequisite for all manner of other bits of boot. The reasons why udev takes a while to be 'done' are more interesting and Lennart went into some of them. Right, and as I've said..in the context of the comparison with Knoppix specifically I found evidence that udev settle use to be a long boot up blocker in previous Knoppix releases. I wouldn't be surprised at all if Knoppix init had been changed in the newest release that JB tried to no longer call the settle function (or call it with a very short timeout) But I'm not going to be downloading Knoppix and dissecting its init to prove that to myself. Its obvious from my testing that settle is one of the big blockers, a blocker multiple live distributions have hit in the last year actually. ... Here it is. # grep -ir udevadm /etc/ ... /etc/init.d/knoppix-autoconfig: /sbin/udevadm settle /etc/init.d/knoppix-autoconfig: udevadm settle /etc/init.d/knoppix-autoconfig: /sbin/udevadm settle /etc/init.d/open-iscsi: udevadm settle /etc/init.d/udev:if udevadm settle; then ... All references to 'udevadm settle' are without parameters, so: $ man udevadm ... udevadm settle [options] Watches the udev event queue, and exits if all current events are handled. --timeout=seconds Maximum number of seconds to wait for the event queue to become empty. The default value is 180 seconds. A value of 0 will check if the queue is empty and always return immediately. You can see knoppix-autoconfig http://pastebin.com/uU5Av6Pf You can see open-iscsi http://pastebin.com/9nRp5JGh You can see udev http://pastebin.com/aGgghx0s JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, Oct 05, 2011 at 09:26:59AM -0700, Adam Williamson wrote: You just did, sorry. ;) Hardware sucks. We know this. Fedora generally takes the position that it's correct to engineer things properly and regretfully explain that the hardware sucks when this causes problems, not engineer hacks and bodges to account for broken hardware. Really? Because honestly if that's the position we generally hold then I'm just closing most of my bugs WONTFIX from here on out. There are multiple issues here. The first is that X reports a 96dpi value because X can only report one value, so it might as well pick something that at least roughly matches user expectations. But like Adam says, randr gives you the per head measurements and you could work things out from there. But then things get awkward. That information is often lies. So we can add a heuristic that clamps the DPI to something in-between 72 and 250 and we probably won't exclude any real displays right now, but we do know that even by absolute standards some people are suddenly going to have tiny fonts and some people are suddenly going to have huge fonts because the hardware lies. But we'll write that off as broken hardware. (You've also changed expected behaviour, because lots of people *want* small fonts on high-DPI screens, but again let's just chalk that up to incorrect expectations and make sure there's an easy UI that lets them change their global font size) So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. But what about the single monitor case? Let's go back to your Vaio. It's got a high DPI screen, so let's adjust to that. Now you're happy. Right up until you plug in an external monitor and now when you run any applications on the external display your fonts are twice the size they should be. WOOHOO GO TEAM of course that won't make us look like amateurs at all. So you need another heuristic to handle that, and of course heuristic is an ancient african word meaning maybe bonghits will make this problem more tractable. We have no technological solution for dealing with the fact that applications may move from one DPI to another at runtime, and may even be displaying on both displays at once. All of which doesn't matter, of course, because we don't even have a well-defined problem statement. What are we actually trying to solve here? Honestly, it's valuable for applications to be able to identify the DPI of the screen they're running on. For certain design purposes it may well be helpful for an application to have 100% map to this is what a sheet of paper the same distance away would look like, and so the fact that this is available to applications is a good thing. But is it valuable for My fonts and icons look different on different displays? Sure, if you only ever use a single display, which is no longer the ubiquitous situation that it used to be. Or, in other words, no. It's not valuable. How about My fonts are too small on my high-DPI laptop? Well, yes, that's a problem. And we should ensure that there's a usable way for you to fix that. But really in that situation my first port of call would be to search the font settings for a button that says Make my fonts bigger, not to look in display settings for something that lets me drag a bar across the screen to line up with a ruler. In summary: Accurate DPI measurement is a means to an end, not an end in itself. Define the problem you're trying to solve, and then work out whether figuring out the real DPI would solve it. Unless your problem statement is unrealistically narrow, the answer is that it wouldn't. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 10/05/2011 12:26 PM, Adam Williamson wrote: You just did, sorry. ;) Hardware sucks. We know this. Fedora generally takes the position that it's correct to engineer things properly and regretfully explain that the hardware sucks when this causes problems, not engineer hacks and bodges to account for broken hardware. That's a joke, right? You can't seriously believe this. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On Wed, Oct 05, 2011 at 09:58:59AM -0500, Eric Sandeen wrote: right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. You almost preempted my question: Could I use this for every ext4 filesystem I make? Honestly from a virt / libguestfs p.o.v. it sounds like something we should always do. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Is there a circumstance where this is bad? I'm thinking perhaps a case where you create a filesystem and immediately try to populate it with lots of files. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On Wed, Oct 05, 2011 at 10:42:37AM -0500, Eric Sandeen wrote: On 10/5/11 9:58 AM, Eric Sandeen wrote: On 10/4/11 6:53 PM, Ric Wheeler wrote: ... Note that ext4 has a new feature that allows inodes to be initialized in the background, so you will see much quicker mkfs.ext4 times as well :) right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Sorry, Lukas reminds me that this should already be the default mode, with a new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria. lazy_itable_init is always on by default now? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
Some details about the triage day we are holding tomorrow. Where: #fedora-kernel on irc.freenode.net When: October 6th 2011 What: The primary focus is going to be on getting things in the best shape possible for Fedora 16's release. However there are some useful things that can be done for all releases. * Fedora 14 At this point in 14's lifecycle, many open bugs are not going to be fixed, due to the amount of work necessary to identify and backport individual fixes. Because of this, identifying open bugs that are still relevant on 15/16 is important, so we don't perpetually have to keep dragging these bugs forward every release. * Fedora 15 F15 bugs that are likely to affect F16 are obviously of importance, so triage assistance on those bugs is useful. If a bug is confirmed to be still present in Fedora 16, add 'F16' to the whiteboard field. * Fedora 16: With the release of the F16 beta, the primary focus will be to make sure the existing bugs are all properly assigned, and triaged. * Rawhide: At the moment, Rawhide is essentially in-sync with F16. The main difference is that Rawhide kernels have debugging enabled by default, whereas F16 doesn't (except for the kernel-debug builds). Because F16 is the upcoming release, we're focusing there but bugs found in Rawhide will likely still occur in F16 as well. However, there are a number of 'perpetual' bugs that are stuck in rawhide (especially Feature requests and WIP items) and those should probably be avoided for now. When in doubt, focus on F16. General info: * See https://fedoraproject.org/wiki/KernelTriage for further 'howto' info. * Of particular importance are bugs that will prevent installation, break networking, or cause system hangs. These bugs should be marked as blocking the f16blocker bug. To do this, you can use the 'f16blocker' alias or the actual bug number 713568. Confirm in IRC before adding them to the tracker bug. If you don't have the Bugzilla powers to add them to the tracker bug, ask in IRC and someone else will be able to do it for you. * Bugs that aren't serious enough to be blockers but might warrant special effort to fix might be added to the F16-accepted tracker (bug number 713566). Again, check in the channel before adding a bug to this tracker. Useful links: All open f14 kernel bugs: http://bit.ly/nmkC8m All open f15 kernel bugs: http://bit.ly/pIpDdM All open f16 kernel bugs: http://bit.ly/ouhRBY -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
Jesse Keating jkeat...@j2solutions.net writes: tl;dr if you're looking for bodhi to allow on-demand creation of topic-tags for isolating build efforts from rawhide, that's too expensive of an item to allow a free-for-all at this time, in my opinion. Fair enough. Is there a policy or guideline on how big a change is big enough to request a topic-tag for, rather than breaking rawhide until the rebuild completes? My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Oct 5, 2011, at 11:07 AM, Tom Lane wrote: Jesse Keating jkeat...@j2solutions.net writes: tl;dr if you're looking for bodhi to allow on-demand creation of topic-tags for isolating build efforts from rawhide, that's too expensive of an item to allow a free-for-all at this time, in my opinion. Fair enough. Is there a policy or guideline on how big a change is big enough to request a topic-tag for, rather than breaking rawhide until the rebuild completes? My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. regards, tom lane When I was handling releng stuff, I liked to use the amount of days it would take to realistically fix things as a hubristic. If it was going to take more than a day or two then it was probably worth it. I also would make sure there has been some prep work, like attempted rebuilds in a local mock to find errors before we spend resources in the build system. Your task of bumping libpng does seem like a reasonable use of a topic tag. Although I'm not releng for Fedora anymore, I would recommend spending some time with mock testing the rebuilds to find errors before we create a divergent line of development. The longer the topic-tag exists, the more risk you have of conflicting changes going on in rawhide vs the changes you're making in the topic-tag that will have to be reconciled. The topic-tag should be used to get the work done, not explore what work might be necessary. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 9:22 AM, JB jb.1234a...@gmail.com wrote: Here it is. No..that's not it.. that is the starting point necessary to understand the udev differences between the two systems. It is not a dissection. To understand what is happening with udev across those systems you have to look really close at the udev rules and the scripts being fired by the rules to make a comparison about the number of udev events which udevd is trying to deal with before settle returns. For all I know knoppix delibrately ships with a very different udev rule set to keep udev settle fast. I'm sure someone will correct me if I'm wrong but I think a udev with no rules to parse will settle faster than a udev with many rules that need to be parsed, and the details of the rule construction will also matter, as will which modules are loaded in initrd I believe. How many udev events is Knoppix actually processing on your hardware? How many events is Fedora Live processing on the same hardware? I'm pretty sure the number of events to process depends a lot of the ruleset. And how much of the time parsing rules is bound up with slow seek performance and unoptimized file layout? Are you doing spinning media for your comparisons or usb? The fact that the udev init script that you pasted calls /lib/udev/write_dev_root_rule script, which we don't provide at all is already an indication that things are very different in terms of udev configuration across the systems.What other differences are lurking _just_ in the udev config in Knoppix? My point is, this is not an apples to apples comparison of sysinit versus systemd...not by a long shot. To understand why udevadm settle is taking longer in our stack you have to ask some very detailed questions about the udev configuration differences...including ruleset details such as timeouts in each rule being parsed..and not just the master overriding timeout that can be given for the settle command. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 13:50 -0400, Peter Jones wrote: On 10/05/2011 12:26 PM, Adam Williamson wrote: You just did, sorry. ;) Hardware sucks. We know this. Fedora generally takes the position that it's correct to engineer things properly and regretfully explain that the hardware sucks when this causes problems, not engineer hacks and bodges to account for broken hardware. That's a joke, right? You can't seriously believe this. It's at least a *standard excuse* I've seen wheeled out when it happens to be convenient. Let's say there's something of a cognitive dissonance effect between the cases where we say 'well, we engineered it right and your hardware sucks, sorry' and the cases where we say 'well, too much hardware sucks so we can't engineer it right for your hardware that doesn't, sorry'... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote: So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. There's no _magic_ way to fix anything, no. Things get fixed by code writers writing code. That would seem to be the obvious thing to do... Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Wed, 2011-10-05 at 15:28 +0200, Lennart Poettering wrote: Please, don't claim that udev settle was a sensible prerequisite. It isn't. It has no place in today's dynamic hardware. Thanks for the correction. (you might want to talk to the anaconda team, then, because liveinst runs 'udevadm settle' when it starts up, and refuses to proceed until udevadm settle is happy.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
Kay Sievers (kay.siev...@vrfy.org) said: Any system service that today relies in its core on 'udevadm settle' or scsi-wait-scan module, or any of the other bad hacks in that category, anything that uses these barriers as a checkpoint to block on, to do its synchronous actions, should be considered non-hotplug capable, need to be fixed or legacy. The Fedora storage assembly shell scripts really need to be replaced by something that fits into today's reality. ... which has been the plan for a few years now, but is waiting on assorted LVM infrastructure work. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote: So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. There's no _magic_ way to fix anything, no. Things get fixed by code writers writing code. That would seem to be the obvious thing to do... Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 15:44 -0400, Simo Sorce wrote: On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote: So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. There's no _magic_ way to fix anything, no. Things get fixed by code writers writing code. That would seem to be the obvious thing to do... Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? If they're sufficiently different in DPI, sure. Or would you really want everything to suddenly become twice as small if you were moving a window from a 100dpi monitor to a 200dpi one? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 10/05/11 12:31, Adam Williamson wrote: Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't_matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Good point Adam. Even if the Xserver correctly intuits the resolution of each display, application behavior is going to be unacceptable. Consider dragging a window from a 200 dpi display to a 100 dpi display. Does the application detect this and correctly re-scale it's window and interior widgets? If the Xserver re-scales the font, how does the app detect the change in bounding box pixel geometry? How's the app supposed to behave if the window straddles monitors? Unless all the graphic toolkits are significantly redesigned, there's no nice way to operate in Xinerama with mis-matched montiors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Adam Williamson awill...@redhat.com writes: [...] But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Perhaps the solution is to bring back Zaphod / classic-multi-head mode for dramatically different (e.g., DPI) outputs, so the issue of dragging windows between them does not arise. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Wed, Oct 5, 2011 at 5:56 AM, Kay Sievers kay.siev...@vrfy.org wrote: There is no general rule, but anything that calls 'udevadm settle' is suspicious and should be carefully checked if it does not rely on assumptions which just bet on luck and can't reliably work in hotplug setups. Kay, Is there a general purpose way to get an accounting of the number of udev events or the maximum length of the unhandled event que since boot( or since some point in time)? Basically a way to ask how many events udev has been asked to handle prior to the existing call to settle as it exists now in the boot process of Fedora. Not all events are equal, but I'd like to make sure that when I'm looking at settle timing in different situations I have a rough idea of how much work udev has been asked to do ahead of that settle call. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 12:49 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 15:44 -0400, Simo Sorce wrote: On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote: So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. There's no _magic_ way to fix anything, no. Things get fixed by code writers writing code. That would seem to be the obvious thing to do... Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? If they're sufficiently different in DPI, sure. Or would you really want everything to suddenly become twice as small if you were moving a window from a 100dpi monitor to a 200dpi one? Are you also proposing to automatically resize all windows when you move them from one display to another ? There lies the road to disaster an pain imo. At least untill all rendering is done with something like svg and not with absolute pixel values this is just going to be a very bad experience. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 15:56 -0400, Simo Sorce wrote: Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? If they're sufficiently different in DPI, sure. Or would you really want everything to suddenly become twice as small if you were moving a window from a 100dpi monitor to a 200dpi one? Are you also proposing to automatically resize all windows when you move them from one display to another ? There lies the road to disaster an pain imo. At least untill all rendering is done with something like svg and not with absolute pixel values this is just going to be a very bad experience. I'm more trying to think ahead about what's going to happen when our current convenient assumptions break down than making specific technical proposals. It just doesn't seem to me like a winning strategy to keep working on the basis that we can simply assume one notional DPI for all displays; sooner or later, given where display technology is going, this is likely to break down. (Unless we just go with what happened when we switched from 72dpi to 96dpi, I guess: wait until some arbitrary 'tipping point' in the adoption of hi-res displays and then say 'okay, new notional dpi is 200, get used to it'. But there may be too long of an overlap period for that to be practical.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, Oct 05, 2011 at 12:31:50PM -0700, Adam Williamson wrote: Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Sure, in the future when we have font renderers that run in GPU shaders we can think about whether there's a plausible way to make applications work when they have to deal with multiple DPIs simultaneously. But we don't have any technology that can do any of that at the moment, and so the simple fact is that right now the decision to have gnome run at 96dpi regardless of the output is an entirely rational one and anyone who argues otherwise gets to explain how all the difficult bits would work. The end. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 21:31 +0100, Matthew Garrett wrote: On Wed, Oct 05, 2011 at 12:31:50PM -0700, Adam Williamson wrote: Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Sure, in the future when we have font renderers that run in GPU shaders we can think about whether there's a plausible way to make applications work when they have to deal with multiple DPIs simultaneously. But we don't have any technology that can do any of that at the moment, and so the simple fact is that right now the decision to have gnome run at 96dpi regardless of the output is an entirely rational one and anyone who argues otherwise gets to explain how all the difficult bits would work. The end. I'm just saying it would probably pay off to put some thought *now* into how to manage things when higher resolution displays become so prevalent that they can't be ignored, rather than desperately scrambling to catch up when you eventually realize it's happened. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Wed, 2011-10-05 at 06:54 -0400, Steve Clark wrote: On 10/05/2011 01:51 AM, Adam Williamson wrote: On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote: (That said, there definitely needs to be a way to disable it, and maybe it should even be disabled by default. I personally always uninstall yum- presto. For me, it's much faster to just download packages than to rebuild them from deltas. Only users on really slow connections benefit from it.) My desktop can rebuild deltas at ~3MB/sec. So even my really fast internet connection is slower than delta rebuild. This is a meaningless comment to other people unless you provide information on what the specs of your desktop are or the speed of your internet connection. No, it isn't, because Kevin rashly made an absolutely categorical statement that 'Only users on really slow connections' benefit from it. You don't need to know what speed my personal internet connection is to know that 3MB/sec (that's mega*bytes*, remember, internet connections are specified in mega*bits* - 3MB/sec is 24Mb/sec) is a hell of a lot faster than many internet connections can manage, handily contradicting his assertion. Yes, my desktop is very fast, but so what? Kevin's statement wasn't conditional upon system specs. (My connection is actually specced at 25Mb/sec, but it rarely manages that to a Fedora mirror; I usually get about 8Mb/sec for package downloads). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, Oct 05, 2011 at 01:34:43PM -0700, Adam Williamson wrote: I'm just saying it would probably pay off to put some thought *now* into how to manage things when higher resolution displays become so prevalent that they can't be ignored, rather than desperately scrambling to catch up when you eventually realize it's happened. The likely outcome of higher density displays is that default font sizes will get larger. It's a problem if and only if it's common to use multiple displays of grossly different density, and fixing that problem is impossible unless we have a huge number of technical advances that nobody's even working on right now. It's worth thinking about. It's just not something that we're anywhere near being able to implement, and as such it's pretty unrelated to the original observation which is that trusting EDID right now will just get you burned. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About Feature enhancement Updates Policy
On Mon, 2011-09-26 at 11:42 -0300, Sergio Belkin wrote: Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed. Is that requirement honored? Because unless I miss something there is a lot of updates that include only enhancements. Is not my will to create a controversy but perhaps there is something in the guideliness that needs (at the risk of sounding repeating) update Perhaps you mean 'enforced' ? Yup, I do, I wrote it in a hurry and my english sometimes is not so good :) Thanks for your explanation, it's somewhat better that I can read at wiki :) Just to make sure something in Kevin's mail is sufficiently emphasized: the thing that's bad in the Abiword example is not the 'feature enhancement' part, it's the 'user experience change' part. The WordStar 4.0 compatibility is fine, it's the pie menus that are a problem. An update which enhances features without changing the normal user experience is not against the policy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Matthew Garrett mj...@srcf.ucam.org writes: We have no technological solution for dealing with the fact that applications may move from one DPI to another at runtime, and may even be displaying on both displays at once. From a technology viewpoint, that is actually theoretically easy to handle on modern hardware: Render everything as 3D objects and let the graphics hardware scale as appropriate. To get it to look pretty you would need fairly high DPI monitors or fancy scaling algorithms though. I can imagine that sub-pixel rendering would be quite tricky to get right when DPI changes halfway through a character. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCO meeting (2011-10-03)
On Mon, 2011-10-03 at 13:46 -0400, Adam Jackson wrote: * #667 Request to fix CRITPATH update process (ajax, 17:06:03) * AGREED: critpath package rules to be modified per sgallagh's proposal above (ajax, 17:14:09) * ACTION: nirik to file bodhi ticket for critpath change (ajax, 17:15:45) to save people the bother of reading the logs, the 'proposal above' involved allowing critpath updates to be pushed with 0 karma after a two week wait. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
On Mon, 2011-10-03 at 15:36 -0400, Dave Jones wrote: On Mon, Aug 22, 2011 at 10:24:45PM -0400, Dave Jones wrote: On Mon, Aug 22, 2011 at 03:33:24PM -0700, Adam Williamson wrote: We'll be doing this in #fedora-kernel next Monday (22nd) I expect that the wiki page will continue to evolve as we start working on this, and perhaps this can even become a regular thing. apologies for not helping with this; turned out to be bad timing for me, I didn't even get to decompress from Alpha last week before I had to spend three days at Linuxcon, and spent most of the weekend in a dazed heap on the couch...sorry again! You didn't miss much. Turned out to be a non-event. Maybe we'll give it another shot in a few weeks. So we're thinking of trying this again this thursday with a focus on 16, (but triage work on older releases is welcomed too). It's a bit late to note now, but Thursday isn't a great choice of day as it's the regular Test Day slot: tomorrow is printing test day, so people who are particularly inclined to join in with test day type events will have to pick one or the other... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-10-05 at 10:06 -0700, Jesse Keating wrote: On Oct 4, 2011, at 10:31 PM, Adam Williamson wrote: On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote: On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. You're thinking of creating a /new/ build target and build tag/root. That's not what bodhi does. Buildroot overrides for the rawhide tags make no sense, as anything built automatically lands in the build root. So really want they want is a *tag*, not a buildroot override, right? They can have a tag for Rawhide if they request one, I presume? I don't even know what that would mean. I was thinking of something like the f16-gnome tag the desktop team uses to do big messy GNOME builds in before re-tagging them so they can be submitted as updates. I didn't know all the issues behind that. :) tl;dr if you're looking for bodhi to allow on-demand creation of topic-tags for isolating build efforts from rawhide, that's too expensive of an item to allow a free-for-all at this time, in my opinion. On demand, no. That's why I said 'if they request one'. I was assuming a manually handled, human-in-the-loop type of 'request', not a fill out the form and bonk on the button type of 'request'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/05/2011 05:42 PM, Eric Sandeen wrote: right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Sorry, Lukas reminds me that this should already be the default mode, with a new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria. yes i know it's not rhel list, but still is it working on rhel-6? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, Oct 05, 2011 at 11:11:38PM +0200, Benny Amorsen wrote: Matthew Garrett mj...@srcf.ucam.org writes: We have no technological solution for dealing with the fact that applications may move from one DPI to another at runtime, and may even be displaying on both displays at once. From a technology viewpoint, that is actually theoretically easy to handle on modern hardware: Render everything as 3D objects and let the graphics hardware scale as appropriate. This... works badly. Really. Open gimp and add some text. Now double the size of the font. Save the image and open it in image viewer, and zoom out so the text is half the size. It doesn't look the same as your original text. Rendering fonts (and even SVGs) well requires you to know the scale that you're rendering to. More pixels mean you can add more detail. If you shrink that then the additional detail is still there, getting in the way of the actually important information. Doing this properly requires that the original object renderer be part of the scaling process, and doing that on the fly with reasonable performance just isn't part of our rendering stack at the moment. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 23:11 +0200, Benny Amorsen wrote: Matthew Garrett mj...@srcf.ucam.org writes: We have no technological solution for dealing with the fact that applications may move from one DPI to another at runtime, and may even be displaying on both displays at once. From a technology viewpoint, that is actually theoretically easy to handle on modern hardware: Render everything as 3D objects and let the graphics hardware scale as appropriate. Your use of the word theoretically reveals much. You would almost certainly be appalled by just how much geometry information is necessary to render a single glyph. Which is why we - and Windows, and OSX - don't do that. When you ask for a glyph at a given transformation matrix, it gets rasterized down to an A8 mask, and we reuse those from then on. (Okay, it's A8R8G8B8 if you're doing subpixel antialiasing). That's the only way you get anything like acceptable performance. If it were easy, we'd already be doing it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Dne 5.10.2011 21:56, Simo Sorce napsal(a): On Wed, 2011-10-05 at 12:49 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 15:44 -0400, Simo Sorce wrote: On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote: On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote: So, ok, now you have some belief about the DPI. But which DPI? If you're dual head, you've got two. Unless they match you're screwed - there's no magic way to get applications to reflow text just because you've moved the window between screens, and what would you do with a window that's halfway between? You can argue that this is a corner case and obviously yes it's a corner case but if you can't even pretend to fix the corner case then your solution isn't a solution any more than 96dpi is. There's no _magic_ way to fix anything, no. Things get fixed by code writers writing code. That would seem to be the obvious thing to do... Like I replied to ajax, I suspect when the problem of assuming everything's 96dpi becomes simply too acute, instead of fixing everything really properly so that all displays correct report their size and all desktops actually do resolution independence perfectly so it doesn't _matter_ if one of your displays is 98dpi and the other is 215dpi, everything still looks perfect, the industry will just wind up with a slightly more sophisticated bodge where we have a few 'standard' resolutions and just figure out which one your displays are closest to. But that's still going to require some kind of sensible handling of the case where one monitor is roughly 100dpi and the other is roughly 200dpi, unless we simply say 'you can't do that, all your displays have to be in the same DPI Category'. Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? If they're sufficiently different in DPI, sure. Or would you really want everything to suddenly become twice as small if you were moving a window from a 100dpi monitor to a 200dpi one? Are you also proposing to automatically resize all windows when you move them from one display to another ? There lies the road to disaster an pain imo. At least untill all rendering is done with something like svg and not with absolute pixel values this is just going to be a very bad experience. Simo. Actually you should think about it in opposite way. Window will have always the same size, e.g. 10x10 cm and who cares how many pixel it is? Have you ever counted? Pixels are so ancient ... Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 743542] New: perl-Config-Properties-1.73 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Config-Properties-1.73 is available https://bugzilla.redhat.com/show_bug.cgi?id=743542 Summary: perl-Config-Properties-1.73 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Config-Properties AssignedTo: xav...@bachelot.org ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: xav...@bachelot.org, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.73 Current version in Fedora Rawhide: 1.72 URL: http://search.cpan.org/dist/Config-Properties/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 743519] RFE: please update to 0.009
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=743519 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||upstream-release-monitoring ||@fedoraproject.org --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-10-05 07:12:18 EDT --- *** Bug 743544 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 743544] perl-Module-Runtime-0.009 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=743544 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||DUPLICATE Last Closed||2011-10-05 07:12:18 --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-10-05 07:12:18 EDT --- *** This bug has been marked as a duplicate of bug 743519 *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Runtime] 0.009 bump
commit 60af100ef54e7cc9a3394e58988a10cff9421978
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 5 13:39:05 2011 +0200
0.009 bump
perl-Module-Runtime.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index 25111ab..28a6550 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Module-Runtime
-Version:0.008
-Release:2%{?dist}
+Version:0.009
+Release:1%{?dist}
Summary:Runtime module handling
License:GPL+ or Artistic
Group: Development/Libraries
@@ -40,12 +40,15 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
./Build test
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed Oct 05 2011 Petr Pisar ppi...@redhat.com - 0.009-1
+- 0.009 bump
+- Remove defattr now
+
* Fri Jul 22 2011 Petr Sabata con...@redhat.com - 0.008-2
- Perl mass rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
