Re: Fedora 19 Final blocker status: fix and karma requests
On Sat, 2013-06-22 at 22:17 -0700, Adam Williamson wrote: > On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: > > On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 > > > x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I > > > know you're working on it) > > > > I've filed an update with some 20 packages, only removing excess baggage > > from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It > > touches nothing outside /usr/share/doc, so should be fairly safe to let > > in. That will probably only get us part of the way, so I've also cut > > some more things from the package set in the .ks file (gnome-system-log, > > deja-dup). > > > > If that is not enough, next step will probably be removing some of the > > big font packages. > > So Matthias forgot to link to his update, but here it is: > > https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 > > It contains changes to some packages not entirely GNOME-y in nature, > inc. dbus-glib and gtk2, so other people might want to give it the > once-over just to make sure there are no inadvertent errors, and upkarma > it assuming it's all good. I am about to test a live compose with the > update to see the impact on image size. So here's some results. f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), no update: 1019215872 f2e707287dd82cccb05a3fef6b75cb356744ca58 (Jun 14), update: 1017118720 1a0c28fdf638796bda60ed2785f95eac16a85b65 (Jun 22), update: 1005584384 that is, with the old spin-kickstarts and without the above update, we're 19215872 bytes oversize; with the update but old spin-kickstarts, we're 17118720 bytes oversize (the update saves ~2.1MB); and with the update and latest spin-kickstarts, we're 5584384 bytes oversize (the kickstart changes save ~11.5MB). We still need to find another 5.6MB from somewhere. Thanks folks! -- 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 19 Final blocker status: fix and karma requests
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: > On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 > > x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I > > know you're working on it) > > I've filed an update with some 20 packages, only removing excess baggage > from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It > touches nothing outside /usr/share/doc, so should be fairly safe to let > in. That will probably only get us part of the way, so I've also cut > some more things from the package set in the .ks file (gnome-system-log, > deja-dup). > > If that is not enough, next step will probably be removing some of the > big font packages. So Matthias forgot to link to his update, but here it is: https://admin.fedoraproject.org/updates/FEDORA-2013-11471/PackageKit-0.8.9-6.fc19,gtk2-2.24.19-2.fc19,evolution-3.8.3-2.fc19,gedit-3.8.2-2.fc19,gnome-session-3.8.2.1-2.fc19,gdm-3.8.3-2.fc19,eog-3.8.2-2.fc19,telepathy-mission-control-5.14.1-2.fc19,yelp-3.8.1-5.fc19,libchamplain-0.12.4-2.fc19,dbus-glib-0.100-4.fc19,libisofs-1.2.8-2.fc19,libxslt-1.1.28-3.fc19,gnome-contacts-3.8.2-2.fc19,gtkmm24-2.24.2-6.fc19,glibmm24-2.36.2-2.fc19,folks-0.9.2-3.fc19,harfbuzz-0.9.18-3.fc19,tracker-0.16.1-3.fc19,libmx-1.4.7-7.fc19 It contains changes to some packages not entirely GNOME-y in nature, inc. dbus-glib and gtk2, so other people might want to give it the once-over just to make sure there are no inadvertent errors, and upkarma it assuming it's all good. I am about to test a live compose with the update to see the impact on image size. -- 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 19 Final blocker status: fix and karma requests
On Sat, 2013-06-22 at 18:51 -0500, Michael Catanzaro wrote: > On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: > > I've filed an update with some 20 packages, only removing excess baggage > > from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It > > touches nothing outside /usr/share/doc, so should be fairly safe to let > > in. That will probably only get us part of the way, so I've also cut > > some more things from the package set in the .ks file (gnome-system-log, > > deja-dup). > That's a shame; Deja Dup is an excellent GNOME 3 backup app, and > including it by default encourages good (encrypted) backup habits. > > But I guess something has to go if we care about 1 GB. (It just seems > like such a strange target... I don't think you can buy 1 GB USB sticks > anymore.) It was the next 'obvious step up' from 700MB, and at the time was comfortable enough for everything we really needed. Stuff happened. Desktop team might be able to rejig things early in F20 cycle somehow, or we might have to go up in size again. Going too big does have consequences: a, say, 2GB download is pretty slow for some people, some people do still have nasty caps, and at some point you start getting people saying 'why does it have to be so big? What's all the bloat?' If all the lives start getting bigger, we may also not be able to manage the four-desktop-spin live DVD any more. (If anything, it'd be nice to get *more* desktops on that, not fewer, but it seems unlikely). -- 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 19 Final blocker status: fix and karma requests
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: > I've filed an update with some 20 packages, only removing excess baggage > from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It > touches nothing outside /usr/share/doc, so should be fairly safe to let > in. That will probably only get us part of the way, so I've also cut > some more things from the package set in the .ks file (gnome-system-log, > deja-dup). That's a shame; Deja Dup is an excellent GNOME 3 backup app, and including it by default encourages good (encrypted) backup habits. But I guess something has to go if we care about 1 GB. (It just seems like such a strange target... I don't think you can buy 1 GB USB sticks anymore.) Michael Catanzaro signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting rid of systemd-sysv-convert?
Hi On Sat, Jun 22, 2013 at 10:50 AM, Reindl Harald wrote: > > > maybe i woul dnot need to repeat things dozens of times if i would > not see the same types of mistake sover and over again and this has > nothing to do with the distibution revolving around me > You seem to assume that you can change anything in an open source project by constant repetition. It doesn't work that way. If you really want your opinions to carry any weight, you have to get involved by contributing. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Sat, 2013-06-22 at 11:00 -0400, Matthias Clasen wrote: > On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 > > x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I > > know you're working on it) > > I've filed an update with some 20 packages, only removing excess baggage > from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It > touches nothing outside /usr/share/doc, so should be fairly safe to let > in. That will probably only get us part of the way, so I've also cut > some more things from the package set in the .ks file (gnome-system-log, > deja-dup). > > If that is not enough, next step will probably be removing some of the > big font packages. Thanks a lot, Matthias. I'll try and test the changes and see what size a live image with them included comes out at if I get a free moment today. -- 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: Minimal install diff from F16 to F19 (TC6)
On Fri, Jun 21, 2013 at 12:09:57PM -0500, Dan Williams wrote: > > On the other hand, having NetworkManager available all the time enables > > things like management tools to use its API to query system status, > > instead of guessing it from kernel information and heuristic analysis of > > some files under /etc. > > Exactly. And that's why we want to enhance NetworkManager to make > people *want* to use it instead of turning it off. Features I am missing are: - A possibility to make NM ignore an interface from the management tools, which would allow to normally use NM but disable it if one wants to configure a device on the command line. Having to disable interfaces from /etc/sysconfig to be able to use them without NM interfering makes it more cumbersome to use NM at all. - Support NM not interfering with Wi-Fi attack tools such as aircrack-ng, which might only be possible by ignoring the device completely or by adding support to change devices into monitor mode and select static of changing frequencies etc. Probably the features airmon-ng provides would be necessary. - Allow to create tun/tap devices, especially persisted ones with permissions for users Should I file RFEs for these in Red Hat Bugzilla or is there a better place to communicate them to? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Final blocker status: fix and karma requests
On Fri, 2013-06-21 at 14:14 -0700, Adam Williamson wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1 > x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I > know you're working on it) I've filed an update with some 20 packages, only removing excess baggage from /usr/share/doc (duplicate docs, large ChangeLog files, etc). It touches nothing outside /usr/share/doc, so should be fairly safe to let in. That will probably only get us part of the way, so I've also cut some more things from the package set in the .ks file (gnome-system-log, deja-dup). If that is not enough, next step will probably be removing some of the big font packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130622 changes
Compose started at Sat Jun 22 09:15:02 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 0:1.3.1.0 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) < 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ der
Re: Minimal install diff from F16 to F19 (TC6)
On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote: > Once upon a time, Stephen Gallagher said: > > Mind if I ask why you think this way about NetworkManager? The NM > > currently shipping in Fedora 19 has full support for managing static > > NICs, as well as bonding, bridging and VLAN support for enterprise > > use-cases. > > I think most "traditional" system admins see a running NM daemon as an > additional point of failure in a static network. If my server's network > setup is static, I don't want a daemon running attempting to "manage" > it. If it has a bug, gets misconfigured, etc., it might do something to > screw up an otherwise working setup. > > I understand that some servers/setups may be able to take advantage of > NM functionality, but assuming that all servers _need_ NM is too much. > This is all IMHO of course. I have no skin in this game, since I dislike both NM and the "traditional" scripts. Here's what I think they should do[*]: (1) systemctl mask NetworkManager.service (2) Write a shell script that contains the ifconfig/route add (or ip ...) commands they need and have it run at boot. Most simple static network configs are 2 or 3 commands at most. Rich. [*] Not actually tried this outside of simple VMs ... -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
