Re: minimal install set tuning [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 08:16:49AM -0500, Michael Cronenworth wrote: > Alexander Larsson wrote: > > Honestly, we should be building glib2 with --disable-fam, since glib > > will prefer the inotify notification module anyway (it has prio 20 and > > fam prio 10). > > It looks[1] like Matthias was watching this thread. Yay! > > [1] > http://pkgs.fedoraproject.org/cgit/glib2.git/commit/?id=3d798c3fdcbab4255323c570fcfc0090bd2980df Let's celebrate one less use of gamin ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121011 changes
Compose started at Thu Oct 11 09:15:30 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [avgtime] avgtime-0-0.2.git20120724.fc18.x86_64 requires libphobos-ldc.so.59()(64bit) [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dragonegg] dragonegg-3.1-7.fc18.x86_64 requires gcc = 0:4.7.1-5.fc18 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedmsg-notify] fedmsg-notify-0.2.0-1.fc18.noarch requires fedmsg >= 0:0.5.3 [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [fontik] fontik-0.6.1-3.20120305git5dbbc513.fc18.x86_64 requires libgee-0.8.so.1()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [gwibber] 1:gwibber-3.4.2-3.fc18.i686 requires libgee-0.8.so.0 1:gwibber-3.4.2-3.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [kismon] kismon-0.6-2.fc18.noarch requires pyclutter [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [maniadrive] raydium-1.2-47.fc18.x86_64 requires libode.so.1()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-
Re: minimal install set tuning [was Re: systemd requires HTTP server and serves QR codes]
On 10/9/12 12:34 PM, Adam Jackson wrote: On 10/9/12 9:18 AM, Lennart Poettering wrote: From the list of packages this minimal set still installs, that I'd really like to see gone: chkconfig gamin info systemd-sysv chkconfig seems like it could have the 'alternatives' bit split off. I've not investigated this in detail. Took a look this morning, it appears alternatives is almost completely orthogonal to the rest of the package. Naturally the bit that ruins everything is translations since the locale data is all mushed together among alternatives chkconfig and ntsysv, but that's straightforward to detangle. (Not that I've done so.) That'd drop the size on disk from ~700k for chkconfig to probably around 400k for just alternatives. Not a huge win, but not terrible either, and certainly Correct for a systemd world. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=865496 Better, though, is looking at what's pulling it in, a Requires(post) in openssh-server (actually for %triggerun and %triggerpostun, but rpm doesn't know how to Requires for those), and in particular for upgrading from versions of openssh-server older than what shipped in F16 Gold. And, the scriptlets are properly immunized against /sbin/chkconfig not existing, which means strictly we could drop the Requires(post) for it already. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=865498 - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package EVR problems in Fedora 2012-10-10
On Wed, 10 Oct 2012 20:01:32 -0600 (MDT) build...@fedoraproject.org wrote: > Broken upgrade path report for tags jive-4-0-dev -> jive-4-0-el6-dev: > --- > Broken paths by builder: > --- > This report generated by Fedora Release Engineering, using > http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgrade-paths.py;hb=HEAD Seems someone at builder.orem.jiveip.net needs to make sure they modify the check scripts they pull from Fedora to mail them and not us. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Taking over orphaned Func and Certmaster packages
Hey guys, I'd like to put my name in to take over ownership of the orphaned Func and Certmaster packages as per the orphaned package takeover procedure. I am the new project maintainer for these projects, and I'd like to add a few tuneups here and there that we've found useful out here at Tumblr. My Fedora Project username is ssalevan and I've applied for commit and bugzilla watching on each package branch; let me know if I can provide any further information, and I very much appreciate the consideration. Thanks! -- Steve Salevan st...@tumblr.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taking over orphaned Func and Certmaster packages
On Thu, 11 Oct 2012, Steve Salevan wrote: Hey guys, I'd like to put my name in to take over ownership of the orphaned Func and Certmaster packages as per the orphaned package takeover procedure. I am the new project maintainer for these projects, and I'd like to add a few tuneups here and there that we've found useful out here at Tumblr. My Fedora Project username is ssalevan and I've applied for commit and bugzilla watching on each package branch; let me know if I can provide any further information, and I very much appreciate the consideration. I just orphaned the packages and I'm vouching for Steve as the new func maintainer. How should I go about having him take them over? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taking over orphaned Func and Certmaster packages
On Thu, Oct 11, 2012 at 12:46:35PM -0400, Seth Vidal wrote: > > > > On Thu, 11 Oct 2012, Steve Salevan wrote: > > >Hey guys, I'd like to put my name in to take over ownership of the orphaned > >Func and Certmaster packages as per the orphaned package takeover procedure. > > I am the new project maintainer for these > >projects, and I'd like to add a few tuneups here and there that we've found > >useful out here at Tumblr. My Fedora Project username is ssalevan and I've > >applied for commit and bugzilla watching on > >each package branch; let me know if I can provide any further information, > >and I very much appreciate the consideration. > > > > > I just orphaned the packages and I'm vouching for Steve as the new > func maintainer. How should I go about having him take them over? > If you're willing to mentor him, it's probably easiest to do this: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer pgpdCEpR0oiAW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taking over orphaned Func and Certmaster packages
Hello, These packages have become semi important to us as well so I'd be willing and interested in being a co-maintainer. On 10/11/2012 10:56 AM, Toshio Kuratomi wrote: On Thu, Oct 11, 2012 at 12:46:35PM -0400, Seth Vidal wrote: On Thu, 11 Oct 2012, Steve Salevan wrote: Hey guys, I'd like to put my name in to take over ownership of the orphaned Func and Certmaster packages as per the orphaned package takeover procedure. I am the new project maintainer for these projects, and I'd like to add a few tuneups here and there that we've found useful out here at Tumblr. My Fedora Project username is ssalevan and I've applied for commit and bugzilla watching on each package branch; let me know if I can provide any further information, and I very much appreciate the consideration. I just orphaned the packages and I'm vouching for Steve as the new func maintainer. How should I go about having him take them over? If you're willing to mentor him, it's probably easiest to do this: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
Chris Adams wrote: > Once upon a time, Seth Vidal said: >> Not every decision a distribution makes is a good one, lets not get >> caught up believing that we cannot make mistakes. >> >> UsrMove was a mistake. End of discussion. Let's go back. > > I agree. The additional churn would be another one-time pain, but then > the Band-Aid™ would be ripped off and we'd be done. Unfortunately, it's much harder to undo UsrMove than it was to do it: UsrMove just required merging some pairs of directories, unmerging them is much trickier. That's yet another reason why UsrMove is broken, it is almost impossible to revert. We've really painted us into a corner. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
David Howells wrote: > Actually, the UsrMove has mucked up at least one way of doing things: we > have/had RHEL customer(s) who kept /usr on AFS and were able to boot just > using the stuff in /bin and /sbin. This is no longer a viable option with > Fedora, and presumably RHEL-7. Actually, systemd had already refused to support this setup before UsrMove, and this was cited as one of the reasons for doing UsrMove (ensuring the draconian way that users won't even try using that setup). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Qua, 2012-10-10 at 13:11 +0300, Serge wrote: > Turning /lib into /usr/lib was also incompatible with every other > Linux > distro, nevertheless it's already done. Don't see why ? ll / lib -> usr/lib lib64 -> usr/lib64 sbin -> usr/sbin bin -> usr/bin What is the difference of /lib and /usr/lib ? What I see in Debian is a big confusion for example, with perl: they have /usr/lib/perl/ /usr/lib/perl5/ /usr/lib/perl5/auto /usr/share/perl/ /usr/share/perl5/ And I have some modules in double and in different versions, which is a mess. If you have just one directory you avoid double version of same software. Regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/10 David Howells wrote: > The contents of /dev vary depending on what hardware the computer has > available - which may change in real time - so it cannot be shared, so > why move it? Ah, no, /dev was moved not because of sharing. It's just original UsrMove among other benefits has the line: > Simpler and cleaner overall file system layout, with full compatibility. I was just trying to actually do that. The best implementation I could come up with is: > /os-- OS, kernel-space > /usr -- user-space, shareable, possibly read-only, > /var -- variable system data, read-write, non-shareable > /home -- variable user data, read-write, shareable > And nothing else. Looks very simple, clean, easy to understand. That was the point for UsrMove. Or at least the UsrMove page says so... > You would _have_ to have symlinks at /dev and /proc - so moving these > gains you nothing. Except "simple and clean file system layout". Does it have any drawbacks? I could not notice any changes in speed, I see no difference in functionality. It works same, but looks better. :) And some years later we may drop those symlinks, as well as /lib, /bin... >> ... But an "eyecandy" kernel module can hide those symlinks, so user >> would see a nice simple layout right now, and not in 10 years. > > Ugh. Don't go there. Really don't. That's for userspace to deal with - > just like hiding files whose name begins with a ".". Well, that was just an idea: show everything for `root` (UID=0), but hide for the rest, so users could see the beauty. :) > Which does not prevent you from leaving /dev and /proc where they are. Well, maybe you're right. I have just listed all the ideas together, trying to look as forward as possible. We can filter the best of them and postpone/throw out the others. That's what the initial email was written for. > Actually, the UsrMove has mucked up at least one way of doing things I agree that UsrMove is not in a good shape now. So it should be either backed out, or moved forward and fixed. That's what I'm trying to do. > we have/had RHEL customer(s) who kept /usr on AFS and were able to boot > just using the stuff in /bin and /sbin. This is no longer a viable option > with > Fedora, and presumably RHEL-7. In my case the goal is to mount /usr using stuff in initramfs. -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
2012/10/11 Adam Williamson wrote: > A proposal to change the filesystem that was synchronized with and > planned to continue to be identical to (or at least fully compatible > with) how it's done in Android and Solaris, with the participation of > Google and Oracle, would be a more interesting proposal Why doing identical if we can do it better? Solaris implemented UsrMove (or rather /sbin-move in their case) in a very weird way. Their initramfs has non-empty /usr directory which contains the files from former /sbin and /lib, necessary to mount /usr. Real /usr is just mounted on top of them hiding the old /usr content. But, I guess you already knew that, since even original UsrMove page mentions "Minimize difference to other Unixes, such as Solaris". I remember someone had even blogged about that [1]. Androids implemented it differently, they also use initramfs for the root filesystem layout. But they do not reuse existing directories, instead they created a set of new directories (/system, /data, /cache...) and then put symlinks there (i.e. /etc -> /system/etc). I tried to make it better. To minimize changes I reused existing/known directories so that their names still matched their content. >> Turning /lib into /usr/lib was also incompatible with every other >> Linux distro, nevertheless it's already done. > > As was already said, that change also had clear concrete benefits; the > incompatibility was acknowledged as a drawback, but the benefit was > traded off against the drawback, and it won. Your proposal seems short > on clear concrete benefits Actually my proposal is based on same benefits, it just adds more (simpler diskless NFS stations, multiple OSes on same partition, etc). It was aiming for a simple layout, and I made it as simple as I could. It was trying to separate different resources, and I separated them, grouping same resources into same directories. And so on. You can compare initial email with UsrMove wiki page. Or are there other UsrMove benefits that were not listed on a wiki page? [1] https://plus.google.com/u/0/115547683951727699051/posts/DiGcrjDaKEb -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
