Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Fri, 23 Nov 2012 10:56:24 +0100, Andrew Haley wrote: On 11/13/2012 10:23 PM, Kevin Kofler wrote: Kevin Fenzi wrote: Sometimes things aren't ideal for one group in favor of another. WHAT group is actually in favor of MiniDebugInfo? It has one single person as the feature owner. ABRT developers consider it useless. Who actually wants it? And are you sure those who think they want it realize what it really means? Let's take a simple example: $ gdb --args sleep 10 (gdb) r (press Ctrl-C) (gdb) bt #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in ?? () #3 0x08048f99 in ?? () #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () What MiniDebugInfo will give you (not tested): #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in xnanosleep () from /usr/bin/sleep #3 0x08048f99 in main () from /usr/bin/sleep #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () With coreutils-debuginfo, glibc-debuginfo and glibc-debuginfo-common installed: #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x0804b232 in xnanosleep (seconds=10) at xnanosleep.c:111 #3 0x08048f99 in main (argc=2, argv=0xbfffef24) at sleep.c:147 Spot the difference… I just did. You seem to have proved the point of mini-debuginfo. You seem to have proved different people consider it useless vs. useful. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sun, 11 Nov 2012 18:39:29 +0100, Reindl Harald wrote: please no - O2 is a performance improvement while minidebuginfo is the opposite, not only bloating the size, also bloadting the data to laod from disk FYI minidebuginfo does not affect loading from disk (mostly) in any way. See 'readelf -WSl', '.gnu_debugdata' is in Section Headers but it is not covered in any way by Program Headers so it is ignored during runtime. There are sure just some minor issues of more data load fragmentation etc. just .gnu_debugdata itself is not loaded during execution. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Kofler (kevin.kof...@chello.at) said: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Not to let silly things like facts get in the way of a good rant, but the images went over size because MATE texlive are now getting pulled in via deps when they weren't before, not because of incremental minidebuginfo changes. Carry on... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Jóhann B. Guðmundsson wrote: On 11/12/2012 09:36 PM, Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I see done to making abrt atleast somewhat usable The ABRT developers have said very clearly that that debugging information is not useful to them because it's insufficient and that they'll be downloading the full debuginfo anyway. MiniDebugInfo contains only symbols, no line numbers (those would be much worse bloat!), no way to get function arguments etc. You get very crappy backtraces with only MiniDebugInfo. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. What benefit? * MiniDebugInfo contains only basically the same information already present in the dynamic symbol table of shared objects! (GDB can already use the dynamic symbol tables, it doesn't need a redundant copy of the data.) The only additional information you get is the location of hidden symbols and of symbols in executables. This is a huge penalty for that small additional information. * MiniDebugInfo does not contain necessary information for good backtraces, inluding line numbers (which were proposed as an option by the feature owners, but which would have made the bloat almost an order of magnitude worse!), locations of function arguments etc. The ABRT folks said they were going to treat MiniDebugInfo the same as none at all. * For people who really do not want to download debugging information, there's the ABRT retrace server. WHERE is the benefit of MiniDebugInfo? I don't recall anyone saying Make your image larger then, we don't care. Maybe not these exact words, but that's the essence of what the people voting for the feature said. I've read several comments of the Who cares about CDs anymore? type. Your possible options are: a) target a larger size (which is what you have done?) As I said, we were basically told to do so. b) ask FESCo to reconsider, but you probibly want some kind of NEW data for that, because without that it's just likely to end the same way. That's what we did: * I pointed out that the relative numbers given on the feature page are misleading because they compare compressed debugging information with uncompressed stripped binaries, whereas after compression (i.e. on the images, i.e. where we actually care about size), what matters is compressed vs. compressed (or uncompressed vs. uncompressed), compressed vs. uncompressed is entirely irrelevant. In particular, the statement on the feature page To minimize space use (on the installed system but also on the installer medium) we've decided to only go with the compressed symbols. is incorrect and deceptive, compressed symbols do NOT help the size on the installer media at all because both the live images and the RPMs on the DVD are already xz-compressed (in fact, compression is likely making things much WORSE because the redundancy between the MiniDebugInfo and the dynamic symbol tables cannot be exploited for compression that way). That was ignored (and the false advertising was not held against the feature owner and is still on the feature page). * The OLPC maintainers pointed out that the size hit was also a big issue for them and that they had no way to increase their target size without desupporting all the XO 1.0 devices. * The ABRT developers made clear that the MiniDebugInfo was of no use for them. * Jan Kratochvil, the expert in matters of debugging information, also expressed doubts about the usefulness of MiniDebugInfo on this list. None of this was given sufficient consideration. c) Drop some more stuff from the live to get it back under 700mb. That'd be A LOT of stuff to drop given the 10% (!) bloat from this feature. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Fenzi wrote: Sometimes things aren't ideal for one group in favor of another. WHAT group is actually in favor of MiniDebugInfo? It has one single person as the feature owner. ABRT developers consider it useless. Who actually wants it? And are you sure those who think they want it realize what it really means? Let's take a simple example: $ gdb --args sleep 10 (gdb) r (press Ctrl-C) (gdb) bt #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in ?? () #3 0x08048f99 in ?? () #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () What MiniDebugInfo will give you (not tested): #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in xnanosleep () from /usr/bin/sleep #3 0x08048f99 in main () from /usr/bin/sleep #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () With coreutils-debuginfo, glibc-debuginfo and glibc-debuginfo-common installed: #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x0804b232 in xnanosleep (seconds=10) at xnanosleep.c:111 #3 0x08048f99 in main (argc=2, argv=0xbfffef24) at sleep.c:147 Spot the difference… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Tue, 13 Nov 2012 23:12:57 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. What benefit? ...snip... The problem here is that you are making the same arguments you made before. FESCo didn't find them compelling, so thats unfortunate. A vote was taken, it did not go the way you wanted, you need to move on now. For the record, I voted against mini-debuginfo personally, but since FESCo has voted and decided I've moved on with life. Repeating the arguments made before over and over again doesn't get anywhere. I suppose you could ask candidates for FESCo their feelings on this matter and vote accordingly and then ask the next FESCo to revist this, but just repeating now isn't doing anyone any good. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Bill Nottingham wrote: Not to let silly things like facts get in the way of a good rant, but the images went over size because MATE texlive are now getting pulled in via deps when they weren't before, not because of incremental minidebuginfo changes. MiniDebugInfo definitely DID increase the DVD ISO size and dropping it might be enough to get it either below the limit or at least much closer to it. The ISOs are only ~10% above DVD size, that's about the amount of bloat MiniDebugInfo causes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 2012-11-11 23:43, Panu Matilainen wrote: On 11/12/2012 08:56 AM, Adam Williamson wrote: On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. Meh. Of course not. But unlike yum, pungi deals with space-constrained images and if it ends up pulling useless cruft in those images then it's not doing the best job it can for the very specific task it has. Well, it's one of those things where you have two imperatives and you can't possibly satisfy both: be space efficient but also ensure that any installation done from the images will be complete and sensible. I think pungi makes the choice to prioritize the latter. Any kind of 'space efficiency' code is going to come with a non-zero danger of resulting in dependency problems or odd dependency resolutions, I guess. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. No disagreement there. But quite obviously nothing is currently finding those packaging errors, much of the suspect items list I posted has been there for years already. Just haven't gotten around to mention it anywhere. I'll shut up now and go see if I can actually do something about it. I recommend it - it's not hard to probe out why these things happen (usually), and it can be quite fun. BTW, QA does have a test which looks for non-explicit conflicts or incomplete dependencies on the images and we hit those every so often, so we're pretty used to poking through things like this. It often tracks out to something which was a packaging problem in the first place and needed to be fixed. If you wind up getting stuck, poke dgilmore in #fedora-releng, as he should have the logs of the compose to look through which can help identifying some of the issues. -- 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: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/12/2012 09:43 AM, Panu Matilainen wrote: On 11/12/2012 08:56 AM, Adam Williamson wrote: On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. Meh. Of course not. But unlike yum, pungi deals with space-constrained images and if it ends up pulling useless cruft in those images then it's not doing the best job it can for the very specific task it has. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. No disagreement there. But quite obviously nothing is currently finding those packaging errors, much of the suspect items list I posted has been there for years already. Just haven't gotten around to mention it anywhere. I'll shut up now and go see if I can actually do something about it. FWIW, this is what I get with F18 pungi compose: -rw-r--r--. 1 root root240 Nov 12 21:10 Fedora-18-x86_64-CHECKSUM -rw-r--r--. 1 root root 4687134720 Nov 12 21:10 Fedora-18-x86_64-DVD.iso -rw-r--r--. 2 root root 268435456 Nov 12 19:22 Fedora-18-x86_64-netinst.iso And this is with a patched pungi to filter out obsoleted packages: -rw-r--r--. 1 root root240 Nov 12 21:02 Fedora-18-x86_64-CHECKSUM -rw-r--r--. 1 root root 4550819840 Nov 12 21:01 Fedora-18-x86_64-DVD.iso -rw-r--r--. 2 root root 268435456 Nov 12 19:22 Fedora-18-x86_64-netinst.iso It might not save the whales or even the day, but the difference is simply dead weight of obsoleted packages, and the list of packages excluded this way shockingly matches what the install-everything rpm test found. Here's the diff to pungi in case somebody is interested: [root@turre pypungi]# diff -u __init__.py.orig __init__.py --- __init__.py.orig2012-11-12 19:12:12.592544072 +0200 +++ __init__.py 2012-11-12 21:12:14.139970112 +0200 @@ -336,6 +336,14 @@ pkg_sack.remove(pkg) break +# weed out obsoleted packages +obsoleters = pkg.obsoletedBy(self.ayum.pkgSack.searchObsoletes(pkg.name), limit=1) +if obsoleters: +obs = obsoleters[0] +self.logger.info(Excluding %s.%s (obsoleted by %s.%s) % (pkg.name, pkg.arch, obs.name, obs.arch)) +self.excluded_pkgs[pkg.nvra] = pkg +pkg_sack.remove(pkg) + return pkg_sack def getPackageDeps(self, po): - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/12/2012 09:05 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Adam Williamson wrote: They already aren't. Half the point of going to 1GB would be to include them. There's no way LibreOffice is going to fit on the KDE spin with a 1 GiB target limit. We're already almost there no thanks to MiniDebugInfo. We'd need an even higher target size to fit LibreOffice. Look, Johann already pointed out, the relevant SIG for each spin owns the spin size. It's not a topic for devel@ kibbitzing and voting. I can't stop you posting +1s, but you're wasting your time if you're not a member of the relevant spin SIG. As seems to need pointing out so often, this isn't a democracy, it's a do-ocracy. You don't get anything done by posting indignant messages on mailing lists. I *AM* a member of the KDE SIG and have de-facto maintained the KDE spin kickstart ever since Sebastian Vahl (the official maintainer) has stopped taking care of it. FESCo has clearly said that they don't care about our size target and that we must target a larger size if MiniDebugInfo blows the current target. This is not a do-ocracy at all. It's design by committee. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Jóhann B. Guðmundsson wrote: Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... Their reasoning was simply that nobody uses CDs anymore anyway. :-/ And unfortunately we can only directly decide what goes into the spin at the package level, stuff which bloats every package from the inside like MiniDebugInfo cannot reasonably be opted out per spin. So FESCo should listen to spin maintainers there. Sadly, it didn't. Even when OLPC pointed out that this feature also made THEIR spin oversized and they cannot simply bump the size target without actually desupporting a large subset of their hardware, FESCo ignored the objection. Even just one spin maintainer/SIG vetoing a feature should block it, it's just plain unacceptable that it gets approved over the objections of TWO spins. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Mon, 12 Nov 2012 21:09:42 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/12/2012 09:05 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... Please read all the logs from the fesco meetings where this feature was approved. FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I don't recall anyone saying Make your image larger then, we don't care. Your possible options are: a) target a larger size (which is what you have done?) b) ask FESCo to reconsider, but you probibly want some kind of NEW data for that, because without that it's just likely to end the same way. c) Drop some more stuff from the live to get it back under 700mb. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Mon, 12 Nov 2012 22:12:21 +0100 Kevin Kofler kevin.kof...@chello.at wrote: I *AM* a member of the KDE SIG and have de-facto maintained the KDE spin kickstart ever since Sebastian Vahl (the official maintainer) has stopped taking care of it. FESCo has clearly said that they don't care about our size target and that we must target a larger size if MiniDebugInfo blows the current target. This is not a do-ocracy at all. It's design by committee. It's a community. Sometimes things aren't ideal for one group in favor of another. Anyhow, I don't think this thread is productive anymore, so can we move on? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/12/2012 09:36 PM, Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I see done to making abrt atleast somewhat usable JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/10/2012 11:41 PM, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. For starters it would help if the DVD didn't contain piles of obsoleted, conflicting and in some cases (at least samba), duplicate versions of packages: [root@turre rpm]# ./rpm -Uvh --test --root /home/test/ --nosignature ~pmatilai/mft/f18-dvd-all.mft warning: package grub-1:0.97-91.fc18.x86_64 was already added, replacing with grub2-1:2.00-12.fc18.x86_64 warning: package jaxen-0:1.1.3-5.fc18.noarch was already added, skipping jaxen-bootstrap-0:1.1-6.2.fc18.noarch warning: package maven-common-artifact-filters-1.4-2.fc18.noarch was already added, skipping maven-shared-common-artifact-filters-1.3-24.fc18.noarch warning: package maven-dependency-tree-2.0-1.fc18.noarch was already added, skipping maven-shared-dependency-tree-1.3-24.fc18.noarch warning: package kmod-10-1.fc18.x86_64 was already added, skipping module-init-tools-3.16-6.fc18.x86_64 warning: package libnfsidmap-0.25-4.fc18.x86_64 was already added, skipping nfs-utils-lib-1.1.5-7.fc18.x86_64 warning: package linux-firmware-20120925-0.3.git236367d.fc18.noarch was already added, skipping ql2100-firmware-1.19.38-6.fc18.noarch warning: package linux-firmware-20120925-0.3.git236367d.fc18.noarch was already added, skipping ql2200-firmware-2.02.08-6.fc18.noarch warning: package linux-firmware-20120925-0.3.git236367d.fc18.noarch was already added, skipping ql23xx-firmware-3.03.28-4.fc18.noarch warning: package linux-firmware-20120925-0.3.git236367d.fc18.noarch was already added, skipping rt61pci-firmware-1.2-10.fc18.noarch warning: package linux-firmware-20120925-0.3.git236367d.fc18.noarch was already added, skipping rt73usb-firmware-1.8-10.fc18.noarch warning: package samba-2:4.0.0-150.fc18.rc1.x86_64 was already added, replacing with samba-2:4.0.0-165.fc18.rc4.x86_64 warning: package samba-common-2:4.0.0-150.fc18.rc1.x86_64 was already added, replacing with samba-common-2:4.0.0-165.fc18.rc4.x86_64 warning: package samba-libs-2:4.0.0-150.fc18.rc1.x86_64 was already added, replacing with samba-libs-2:4.0.0-165.fc18.rc4.x86_64 warning: package dvipdfm-0.13.2d-44.fc18.x86_64 was already added, replacing with texlive-dvipdfm-bin-1:2012-0.svn13663.3.20121019_r28030.fc18.noarch warning: package dvipdfmx-0-0.35.20090708cvs.fc18.x86_64 was already added, replacing with texlive-dvipdfmx-bin-1:2012-0.svn26509.3.20121019_r28030.fc18.x86_64 warning: package dvipng-1.14-4.fc18.x86_64 was already added, replacing with texlive-dvipng-bin-1:2012-0.svn26509.3.20121019_r28030.fc18.x86_64 warning: package texlive-1:2012-3.20121019_r28030.fc18.x86_64 was already added, skipping texlive-texmf-2007-42.fc18.noarch warning: package texlive-1:2012-3.20121019_r28030.fc18.x86_64 was already added, skipping texlive-texmf-dvips-2007-42.fc18.noarch warning: package texlive-1:2012-3.20121019_r28030.fc18.x86_64 was already added, skipping texlive-texmf-fonts-2007-42.fc18.noarch warning: package texlive-xdvi-bin-1:2012-0.svn26509.3.20121019_r28030.fc18.x86_64 was already added, skipping xdvik-22.84.14-12.fc18.x86_64 error: Failed dependencies: libpng-devel conflicts with libpng12-devel-1.2.50-2.fc18.x86_64 rsyslog conflicts with sysklogd-1.5-12.fc18.x86_64 [root@turre rpm]# What's the script/tool used to compose the images these days? - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Panu Matilainen pmatilai at laiskiainen.org writes: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. For starters it would help if the DVD didn't contain piles of obsoleted, conflicting and in some cases (at least samba), duplicate versions of packages: The i386 DVD has been very close (around 150M) to the size limit for the last couple of TCs, before TC8. I posted warnings in the text matrix pages. So the package set should be trimmed in any case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 2012-11-11 0:53, Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. For starters it would help if the DVD didn't contain piles of obsoleted, conflicting and in some cases (at least samba), duplicate versions of packages: [root@turre rpm]# ./rpm -Uvh --test --root /home/test/ --nosignature ~pmatilai/mft/f18-dvd-all.mft This is a bad test and is not intended to be possible. There are various reasons why such packages end up on the images. Some are bugs, but some are not. warning: package grub-1:0.97-91.fc18.x86_64 was already added, replacing with grub2-1:2.00-12.fc18.x86_64 This was the case at least for a long time because we used grub on some platforms and grub2 on others. I'm not sure if we're still using grub for anything on F18, but we may be. I'm on my laptop where I don't have an anaconda checkout handy to check. I don't have specific knowledge of the others, but some are obvious - there's a couple of packages which conflict explicitly, which is fine. You're not supposed to be able to install all of the DVD at once, but different bits in different situations. The other classic case is that when a dependency of a package in the set of packages to be included in an image is satisfied by more than one other package, pungi pulls *all* the satisfying packages into the compose, not just one. This seems odd at first glance but not at second thought: it's possible for yum to make a guess at which one should be pulled in on a specific system - I think the rule it uses is 'causes the least amount of extra other dependencies' - but pungi can't do that, because it doesn't know what your eventual installed system is going to contain! If A requires foo, which is provided by GNOME-B and KDE-C, then pungi needs to include both on the DVD if it's including A, because on a GNOME install you'll probably wind up with the dependency fulfilled by GNOME-B, but on a KDE install you'll probably want to have it fulfilled by KDE-C. If we only pulled in GNOME-B to the DVD, a KDE install might look odd. (Just a theoretical example, but you get the point). What's the script/tool used to compose the images these days? pungi, but please consider the quirks of what it's doing before concluding that it's broken. -- 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: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. I've seen mass rebuilds rushed through in less time than what we have from now until the current F18 release target date. And it's the most effective way to hit the target size of the DVD. I really don't understand the cavalier approach to bloat around here. A feature which increases the size of the whole distro should NOT be approved, period. We need to get the live images back to CD size and treat every feature which endangers that as a showstopper. Hardware resources are not infinite, we cannot afford wasting them in this way. FWIW, I also think we need to reopen the discussion of building Fedora with -Os rather than -O2. Size matters, Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Adam Williamson wrote: The other classic case is that when a dependency of a package in the set of packages to be included in an image is satisfied by more than one other package, pungi pulls *all* the satisfying packages into the compose, not just one. This seems odd at first glance but not at second thought: it's possible for yum to make a guess at which one should be pulled in on a specific system - I think the rule it uses is 'causes the least amount of extra other dependencies' - but pungi can't do that, because it doesn't know what your eventual installed system is going to contain! If A requires foo, which is provided by GNOME-B and KDE-C, then pungi needs to include both on the DVD if it's including A, because on a GNOME install you'll probably wind up with the dependency fulfilled by GNOME-B, but on a KDE install you'll probably want to have it fulfilled by KDE-C. If we only pulled in GNOME-B to the DVD, a KDE install might look odd. (Just a theoretical example, but you get the point). That nondeterministic behavior of yum really causes more harm than good. We can never be sure what's actually going to be installed when we Require something. And it doesn't properly solve the problem in your example because the heuristics sometimes do the wrong thing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Am 11.11.2012 18:31, schrieb Kevin Kofler: Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. I really don't understand the cavalier approach to bloat around here. A feature which increases the size of the whole distro should NOT be approved, period. We need to get the live images back to CD size and treat every feature which endangers that as a showstopper. Hardware resources are not infinite, we cannot afford wasting them in this way. +1 FWIW, I also think we need to reopen the discussion of building Fedora with -Os rather than -O2 please no - O2 is a performance improvement while minidebuginfo is the opposite, not only bloating the size, also bloadting the data to laod from disk Size matters yes, but -Os degrades performance while O2 and NO debuginfo at all improves performance with a balance of performance/Size signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/11/2012 05:31 PM, Kevin Kofler wrote: We need to get the live images back to CD size Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sun, Nov 11, 2012 at 9:31 AM, Kevin Kofler kevin.kof...@chello.at wrote: Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. I've seen mass rebuilds rushed through in less time than what we have from now until the current F18 release target date. And it's the most effective way to hit the target size of the DVD. I really don't understand the cavalier approach to bloat around here. A feature which increases the size of the whole distro should NOT be approved, period. We need to get the live images back to CD size and treat every feature which endangers that as a showstopper. Hardware resources are not infinite, we cannot afford wasting them in this way. FWIW, I also think we need to reopen the discussion of building Fedora with -Os rather than -O2. Size matters, Kevin Kofler +1, although I really think the relevant size targets are 700 MB for CD and 4 GB for DVD / USB stick. You need the 700 MB for machines that can't boot a USB stick or DVD. Personally, I think OpenOffice / LibreOffice shouldn't be on live media. You can make a really nice GNOME or KDE Live CD if you free up the humongous amount of space that so-called productivity suite occupies. ;-) By the way, I am moving my computational journalism tool set into beta this week, and I am going to recommend that users install Linux from a net install CD where available. In case you're wondering, it works on Linux Mint 13, Mageia 2, Fedora 17 and 18, openSUSE 12.2, Ubuntu 12.04 LTS and maybe Ubuntu 12.10. I love net installers - they take up about 200 MB, they download quickly and you don't have to run a stinking update of hundreds of packages after the install. The down side is that it takes longer to get the packages installed, but eliminating the second install makes that moot IMHO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 2012-11-11 16:42, M. Edward (Ed) Borasky wrote: On Sun, Nov 11, 2012 at 9:31 AM, Kevin Kofler kevin.kof...@chello.at wrote: Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. I've seen mass rebuilds rushed through in less time than what we have from now until the current F18 release target date. And it's the most effective way to hit the target size of the DVD. I really don't understand the cavalier approach to bloat around here. A feature which increases the size of the whole distro should NOT be approved, period. We need to get the live images back to CD size and treat every feature which endangers that as a showstopper. Hardware resources are not infinite, we cannot afford wasting them in this way. FWIW, I also think we need to reopen the discussion of building Fedora with -Os rather than -O2. Size matters, Kevin Kofler +1, although I really think the relevant size targets are 700 MB for CD and 4 GB for DVD / USB stick. You need the 700 MB for machines that can't boot a USB stick or DVD. Personally, I think OpenOffice / LibreOffice shouldn't be on live media. You can make a really nice GNOME or KDE Live CD if you free up the humongous amount of space that so-called productivity suite occupies. ;-) They already aren't. Half the point of going to 1GB would be to include them. Look, Johann already pointed out, the relevant SIG for each spin owns the spin size. It's not a topic for devel@ kibbitzing and voting. I can't stop you posting +1s, but you're wasting your time if you're not a member of the relevant spin SIG. As seems to need pointing out so often, this isn't a democracy, it's a do-ocracy. You don't get anything done by posting indignant messages on mailing lists. -- 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: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/11/2012 06:35 PM, Adam Williamson wrote: On 2012-11-11 0:53, Panu Matilainen wrote: Reverting mini-debuginfo would require a mass-rebuild which is hardly going to happen at this point of F18 no matter what you think of the feature. For starters it would help if the DVD didn't contain piles of obsoleted, conflicting and in some cases (at least samba), duplicate versions of packages: [root@turre rpm]# ./rpm -Uvh --test --root /home/test/ --nosignature ~pmatilai/mft/f18-dvd-all.mft This is a bad test and is not intended to be possible. There are various reasons why such packages end up on the images. Some are bugs, but some are not. Sure its a stupid test, a truly everything-install from a repository is not a meaningful operation. On a space-constrained media it does at least point out some suspect issues. warning: package grub-1:0.97-91.fc18.x86_64 was already added, replacing with grub2-1:2.00-12.fc18.x86_64 This was the case at least for a long time because we used grub on some platforms and grub2 on others. I'm not sure if we're still using grub for anything on F18, but we may be. I'm on my laptop where I don't have an anaconda checkout handy to check. Bootloader differences between architectures I can understand, but within x86_64 DVD? I don't have specific knowledge of the others, but some are obvious - there's a couple of packages which conflict explicitly, which is fine. You're not supposed to be able to install all of the DVD at once, but different bits in different situations. The other classic case is that when a dependency of a package in the set of packages to be included in an image is satisfied by more than one other package, pungi pulls *all* the satisfying packages into the compose, not just one. This seems odd at first glance but not at second thought: it's possible for yum to make a guess at which one should be pulled in on a specific system - I think the rule it uses is 'causes the least amount of extra other dependencies' - but pungi can't do that, because it doesn't know what your eventual installed system is going to contain! If A requires foo, which is provided by GNOME-B and KDE-C, then pungi needs to include both on the DVD if it's including A, because on a GNOME install you'll probably wind up with the dependency fulfilled by GNOME-B, but on a KDE install you'll probably want to have it fulfilled by KDE-C. If we only pulled in GNOME-B to the DVD, a KDE install might look odd. (Just a theoretical example, but you get the point). Sure there are ambiguous cases - between identical providers and mutually conflicting packages there's no telling what should be pulled in. But most of these cases seem like one-way obsoleted packages, and there's not a whole lot of point installing packages which will get replaced on the first 'yum update' you ever do on the installed system. Such as sysklogd. Or grub on x86_64 - if there are architectures where grub2 cannot be built then it wont exist and wont obsolete anything either, but on x86_64 it'll just get replaced by grub2 immediately. What's the script/tool used to compose the images these days? pungi, but please consider the quirks of what it's doing before concluding that it's broken. Ah, pungi, of course. I know I knew that, only had forgotten... thanks :) Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. -- 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: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On 11/12/2012 08:56 AM, Adam Williamson wrote: On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. Meh. Of course not. But unlike yum, pungi deals with space-constrained images and if it ends up pulling useless cruft in those images then it's not doing the best job it can for the very specific task it has. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. No disagreement there. But quite obviously nothing is currently finding those packaging errors, much of the suspect items list I posted has been there for years already. Just haven't gotten around to mention it anywhere. I'll shut up now and go see if I can actually do something about it. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
I'm more concerned with getting sizes down to fix a cheap 4 GB USB drive than a 4.7 GB DVD. I don't think making install media over 4 GB is a viable option. I will test with the default desktop and the net installer before I'll erase one of my expensive 8 GB USB sticks! On Sat, Nov 10, 2012 at 1:41 PM, Kevin Kofler kevin.kof...@chello.at wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Am 10.11.2012 22:41, schrieb Kevin Kofler: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! +1 generally only few people need any debug-infos if they need - they can install package-debug do NOT BLOAT the whole distribution for more or less nothing 5-10% bigger - one may say these days hard-disks are cheap this is bullshit. in virtual environments with 50,100,500 instances on expensive SAN-storages NOTHING is cheap and you havve to add backups to the install size, mostly mutiplied signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Tomasz Torcz wrote: On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. SARCASMYeah right, because the OBVIOUS solution to bloat added by a useless feature is to remove a useful feature to compensate./SARCASM Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sat, Nov 10, 2012 at 1:56 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. Fine with me - I use GNOME. ;-) But seriously, I have a huge collection of 4 GB USB sticks and will never buy a CD or DVD blank again. I simply won't test anything that won't fit on a 4 GB drive. openSUSE crossed that bridge already, and I suppose the 700 MB CD is a dead duck in all the distros now. But really, if you've got more than 4 GB on your full install media, you're not managing your distro effectively. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
