Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
On Mon, Aug 19, 2013 at 1:58 PM, 东方巽雷 dongfangxun...@gmail.com wrote: I need to change some arguments in Makefile. AFAIK, there is no way to pause the emerging and resume it. Emerging is like a transaction. You need to write your own ebuild file, maybe add a additional patch. -- Silence is golden. twitter: @AccelReality wikipedia: AleiPhoenix blog: weblog.areverie.org wiki: wiki.areverie.org
Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
if the package uses autoconf/automake: ebuild /usr/portage/cat/pkg/pkg-ver.ebuild configure [edit Makefile] touch /var/tmp/portage/cat//pkg-ver/.configured ebuild /usr/portage/cat/pkg/pkg-ver.ebuild install I think it would be easier to put the package in an overlay and edit the ebuild. Regards. On Mon, Aug 19, 2013 at 12:58 AM, 东方巽雷 dongfangxun...@gmail.com wrote: I need to change some arguments in Makefile. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
2013/8/19 东方巽雷 dongfangxun...@gmail.com: I need to change some arguments in Makefile. You might want to use a low-level interface to the Portage system 'ebuild': ebuild path/to/package.ebuild fetch ebuild path/to/package.ebuild unpack ===make you changes here (where unpacked, in /tmp)=== ebuild path/to/package.ebuild compile ebuild path/to/package.ebuild install ebuild path/to/package.ebuild qmerge -- Regards, Alex
Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
good! Thank you. 2013/8/19 Alexey Mishustin shum...@shumkar.ru 2013/8/19 东方巽雷 dongfangxun...@gmail.com: I need to change some arguments in Makefile. You might want to use a low-level interface to the Portage system 'ebuild': ebuild path/to/package.ebuild fetch ebuild path/to/package.ebuild unpack ===make you changes here (where unpacked, in /tmp)=== ebuild path/to/package.ebuild compile ebuild path/to/package.ebuild install ebuild path/to/package.ebuild qmerge -- Regards, Alex
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 05:42, Daniel Campbell wrote: As a budding programmer I understand that a lot of the functionality that users take for granted in sysvinit scripts is hacked together and prone to bash upgrades breaking them sysvinit scripts have ended up where almost every large project that spans many years ends up: #!/bin/sh # do a standard action here idea.get() # do some weird magic hacked user-defined shit here ??? # do a few more standard things here profit(!) sysvinit, like X11, needs a massive overhaul and a sprint clean. systemd may or may not be a good replacement -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] libreoffice cannot use oxygen theme
On 19/08/2013 06:52, Wang Xuerui wrote: 2013/8/19 东方巽雷 dongfangxun...@gmail.com: libreoffice-bin needs older icu version,libreoffice need so much time to compile libreoffice-bin (at this time only 4.0.4.2 is present) requests icu/51.1, while the latest is slotted 51.2. I don't know of any package that specifically asks for such a new version of icu; a quick equery on my system shows this: equery depends icu * These packages depend on icu: app-i18n/fcitx-4.2.8.1 (icu ? dev-libs/icu) app-office/libreoffice-4.1.0.4 (=dev-libs/icu-4.8.1.1) app-text/libmspub-0.0.6 (dev-libs/icu) app-text/texlive-core-2013 (xetex ? =dev-libs/icu-50) dev-db/sqlite-3.7.17 (icu ? dev-libs/icu) dev-lang/php-5.4.18 (intl ? dev-libs/icu) dev-lang/php-5.5.1-r1 (intl ? dev-libs/icu) dev-libs/boost-1.53.0 (icu ? =dev-libs/icu-3.6) dev-libs/libxml2-2.9.1-r1 (icu ? dev-libs/icu) dev-qt/qtcore-4.8.5 (icu ? =dev-libs/icu-49) dev-qt/qtwebkit-4.8.5 (icu ? dev-libs/icu) dev-tex/bibtexu-3.71_p20130530 (=dev-libs/icu-4.4) media-libs/harfbuzz-0.9.18-r1 (icu ? dev-libs/icu) media-libs/libcdr-0.0.14 (dev-libs/icu) media-libs/libvisio-0.0.30 (dev-libs/icu) media-libs/raptor-2.0.9 (unicode ? dev-libs/icu) net-libs/webkit-gtk-1.8.3-r201 (=dev-libs/icu-3.8.1-r1) net-libs/webkit-gtk-2.0.4 (=dev-libs/icu-3.8.1-r1) net-nds/openldap-2.4.35 (icu ? dev-libs/icu) sys-apps/gptfdisk-0.8.6 (icu ? dev-libs/icu) (icu ? dev-libs/icu[static-libs(+)]) www-client/chromium-29.0.1547.41 (=dev-libs/icu-49.1.1-r1) So at least nothing installed on my system requires a recent icu to run. Thus, you shouldn't have problems setting up libreoffice-bin; if you indeed have to stick with the latest icu, share with us your specific setup and we'll be glad to help. NOT upgrading icu on a whim also comes with massive user benefits: such as, for example, NOT having to rebuild every damn huge piece of software on the box every other week just coz icu decided to change how something is done and shove it into a point release. Again. /rant over -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Advice needed regarding udisks
When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. - Grant
Re: [gentoo-user] Re: Advice needed regarding udisks
On 19/08/2013 09:17, Grant wrote: When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. Don't keyword gvfs, for gvfs: USE=-udisks gdu gvfs doesn't care what does the automounting, as long as something does -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Advice needed regarding udisks
On Mon, Aug 19, 2013 at 2:17 AM, Grant emailgr...@gmail.com wrote: When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. It's going to snowball from there. You could try to keyword gobject-introspection, but it will probably need for you to keyword more packages, which in turn will require even more keyworded packages. It can be done automatically with the --autounmask emerge option, but if you are mixing stable and unstable packages, you need to know what you are doing. GNOME 3.8 is going stable soon (or so I keep hearing); when that happens, the parts of the stack that you need for the new gvfs will be stable. You could wait for it to happen. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 08/19/2013 12:52 AM, Mark David Dumlao wrote: On Mon, Aug 19, 2013 at 5:54 AM, pk pete...@coolmail.se wrote: On 2013-08-18 23:08, Mick wrote: I honestly cannot understand why we/Gentoo are allowing the RHL monolithic development philosophy to break what we have. Is Poettering the only developer available to the Linux world? Are RHL dictating what path Debian and its cousin distros should follow? Problem is that Linux is dependent on udev and udev is in the hands of Kay Sievers which also develops systemd together with Lennart Poettering which in turn used to be a Gnome developer... With that said, what I cannot understand is why people advocating systemd (and the kitchen-and-sink model) are using Gentoo in the first place. Are they just trying to make the rest of the Linux distro landscape as miserable as Fedora? Why don't they stay with Fedora instead of trying to turn Gentoo into Fedora? This kind of response has been repeatedly grating on my nerves on this mailing list. It's just so TECHNICALLY WRONG, but more than that I feel that it hints at a deeper problem about user attitudes and the need to act like a know-it-all that is so prevalent on this mailing list. Systemd is _not_ a monolithic design. I don't know how anyone who has taken even a casual glance at it, or its documentation, can say otherwise. It's so reminiscent of qmail or postfix, where you have a bunch of small programs each doing one thing well, but for init systems rather than for mail, that it's just one step away from being the kind of program you show to kids to teach them how to Unix. It's not monolithic? Okay, then why won't logind work separately after systemd-206? QED. If you cannot separate its parts and use them piecemeal, it's monolithic. Period. Separation of concerns within a project as vast as systemd is to be expected if you want to be able to read the source. That doesn't mean that systemd isn't monolithic when used in an actual system. Systemd swallowed udev and is doing whatever they can to tie logind behavior into the init system to get people to use it. That's the very definition of monolithic. Scroll up further on the random systemd rants on this mailing list and you'll learn that systemd has a binary / xml configuration format (it doesn't, it's plaintext INI, like samba) that requires binary code to run daemons (um, no it doesn't), or that thanks to systemd, old, perfectly working servers will just stop running... You know what I think? You can't understand why some people like or want to support systemd because you don't _want_ to understand. It requires you to learn something new. There's an old problem, _mostly_, but not entirely, solved, where we've swept the ugly parts out of sight so that they don't bug you. The parts of systemd that you don't understand why they should be there are the parts that deal with those ugly things you don't want to learn. I know that feeling, of being forced to learn something new and thinking do I really have to? and I know I hate it. It's the same reason why RTFM is considered rude. But it's basically the appropriate response here. You wanna figure out why systemd does what it does? RTFM. Yes, system initialization SHOULD be simple. Just like mail or web SHOULD be. And heck, If you want to run some bash script to do your web or mail or init, nobody's stopping you. But somebody, somewhere, is going to want features, which is why we have apache or postfix, and what-have-you. And if other projects want to use those features, they're free to want to require those software as they please. You don't like it? Don't use those projects. Or fork them. But stop acting like a pompous know-it-all, quoting software design witticisms as if you've actually looked at the problem domain even half as seriously as the developers involved. Oh but systemd is going to eat up all our software so that nothing will run without it! Don't be ridiculous. They said that about Emacs, Java, Lisp, GNOME, kdepim, The Browser(tm), etc etc etc. If you've paid any attention at all to the history of software, it's obvious that it's not happening. Why the hell would apache, which runs on windows, require systemd? Or firefox? Or google chrome? Or qmail? Or postfix? Or MySQL? Or samba? etc etc etc If there's anything surprising, it's that you seriously thought a software development house (cough cough Redhat) wouldn't try to dogfood their own stuff into their other products (cough cough GNOME) _which already have forks by the way_, so what are you worried about? What he and others are worried about is a single company homogenizing the distribution landscape, starting at the bottom with the init system. By making every distro dependent on them for init, they can systematically homogenize the software ecosystem and kill (mainstream) FOSS. This would benefit their business immensely. It's hard to deny that this isn't being attempted
Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
2013/8/19 东方巽雷 dongfangxun...@gmail.com: good! Thank you. Manually executing phases of ebuild is certainly not a long-term solution; changes won't persist on the next build. You'd better patch the ebuild's src_configure section (before you forget your exact modifications), then put them into your overlay; If you don't have an overlay already, it's a good opportunity to create one.
Re: [gentoo-user] libreoffice cannot use oxygen theme
2013/8/19 Alan McKinnon alan.mckin...@gmail.com: NOT upgrading icu on a whim also comes with massive user benefits: such as, for example, NOT having to rebuild every damn huge piece of software on the box every other week just coz icu decided to change how something is done and shove it into a point release. Again. /rant over Sure... And if you choose to not rebuild things you end up putting a whole lot of packages into @preserved-rebuild, which shows up *every* time emerge completes. Well, I basically get over this by simply ignoring them, but the length of @preserved-rebuild output usually forces me into emerging it every 2 weeks or so. And just consider how much CPU cycles are lost in frequent qtwebkit, webkit-gtk and chromium rebuilds...
Re: [gentoo-user] Re: Advice needed regarding udisks
When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. Don't keyword gvfs, for gvfs: USE=-udisks gdu gvfs doesn't care what does the automounting, as long as something does That's what I have now and I have this ejecting problem. Should I just emerge udisks-2 into a new slot? - Grant
Re: [gentoo-user] Re: Advice needed regarding udisks
On 19/08/2013 10:25, Grant wrote: When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. Don't keyword gvfs, for gvfs: USE=-udisks gdu gvfs doesn't care what does the automounting, as long as something does That's what I have now and I have this ejecting problem. Should I just emerge udisks-2 into a new slot? I have a hunch that won't work and USE=udisks is hard masked for gvfs. Logic tells me that even if udisks:2 is available, gvfs won't use it. But, it's worth a try. I also think you need the maintainer to take a closer look - it all looks like the ebuild needs some tweaking, or maybe it's just a magic combination of USE that we missed. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] libreoffice cannot use oxygen theme
On 19/08/2013 10:10, Wang Xuerui wrote: 2013/8/19 Alan McKinnon alan.mckin...@gmail.com: NOT upgrading icu on a whim also comes with massive user benefits: such as, for example, NOT having to rebuild every damn huge piece of software on the box every other week just coz icu decided to change how something is done and shove it into a point release. Again. /rant over Sure... And if you choose to not rebuild things you end up putting a whole lot of packages into @preserved-rebuild, which shows up *every* time emerge completes. Well, I basically get over this by simply ignoring them, but the length of @preserved-rebuild output usually forces me into emerging it every 2 weeks or so. And just consider how much CPU cycles are lost in frequent qtwebkit, webkit-gtk and chromium rebuilds... webkit* updates have slowed down recently so I'm not too bothered about that. But chromium, that thing drive me to tears, now I just use google-chrome. I don't always need the latest icu - 7-bit ASCII satisfies all my daily needs :-) So I can afford to mask anything after the current version and just leave it as-is until it suits me to rebuild things. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] how can I pause emerge after it finish running configure or cmake and before it do any compilation?
On Mon, 19 Aug 2013 16:00:28 +0800, Wang Xuerui wrote:
You'd better patch the ebuild's src_configure section (before you
forget your exact modifications), then put them into your overlay; If
you don't have an overlay already, it's a good opportunity to create
one.
If the ebuild supports epatch, you can just create a patch for the
makefile and drop it in /etc/portage/patches/cat/pkg
If the ebuild doesn't support epatch, you can for it by putting this
in /etc/portage/env/cat/pkg
post_src_unpack() {
cd ${S}
epatch_user
}
--
Neil Bothwick
Angular Momentum Makes The World Go 'Round
signature.asc
Description: PGP signature
Re: [gentoo-user] Optional /usr merge in Gentoo
On 18 August 2013, at 15:16, pk wrote: ... 1. Most of the time spent when cold booting is spent in the BIOS/UEFI cycle (around 30 seconds), the time from grub display to login (I'm using slim) is 5 seconds (max). Blimey! You must have a slow BIOS cycle. I mean, maybe my servers take that long (I'm not sure, I boot them annually and don't watch them rebooting) but I have a little eMachines nettop here - the first time I tried to enter BIOS, it look me several attempts, it boots past that so quick! I've now enabled the option to wait 5 seconds before loading the bootloader, but quickboot on this system is less than 2 seconds in BIOS cycle. (OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). Stroller.
Re: [gentoo-user] Optional /usr merge in Gentoo
On 19/08/2013 11:21, Stroller wrote: On 18 August 2013, at 15:16, pk wrote: ... 1. Most of the time spent when cold booting is spent in the BIOS/UEFI cycle (around 30 seconds), the time from grub display to login (I'm using slim) is 5 seconds (max). Blimey! You must have a slow BIOS cycle. I mean, maybe my servers take that long (I'm not sure, I boot them annually and don't watch them rebooting) but I have a little eMachines nettop here - the first time I tried to enter BIOS, it look me several attempts, it boots past that so quick! I've now enabled the option to wait 5 seconds before loading the bootloader, but quickboot on this system is less than 2 seconds in BIOS cycle. (OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). What pk says is quite normal in my experience. This laptop is a Dell Precision, from pressing enter on the grub screen to kdm showing on the screen is 3 seconds, another 4 seconds for KDE to appear and start responding to mouse clicks. From power-on to the grub menu showing, that's about 30 seconds. The first 8 or so is a ... blank screen ... then I get the Dell logo, followed by another 20 seconds or so where is does $SOMETHING. Server hardware is even worse - the R[357]* series can easily take 4 MINUTES to get through all the various BIOS thingies. Bi-monthly maintenance reboots get scary, 4 minutes is a lng time when you're flying blind on a critical machine that's physically on the other side of town :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 00:49, Dale wrote: Picking random message sort of. Isn't eudev still going to support a separate /usr? That is my understanding. If eudev is not then I may have to reconsider some things myself here. Yes, that is my understanding as well. But the decision to not support a separate /usr lies higher up in the system hierarchy (as I understand it). Gentoo as a system will not support a separate /usr if we are to believe the conversation (I haven't seen any official notice of this though). That is the sad part. The problem I have, as an engineer, is that everybody says that a separate /usr is broken, that sysvinit is broken without explaining why. In order to fix a problem you need to know what is broken... The people who claims the brokenness are, imo, hand waving and they've managed to convince higher uppers in the Gentoo infrastructure (as it seems). I guess if you repeat something often enough it becomes a truth or said person(s) just agrees to stop the nagging. Best regards Peter K
Re: [gentoo-user] Re: Advice needed regarding udisks
When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. Don't keyword gvfs, for gvfs: USE=-udisks gdu gvfs doesn't care what does the automounting, as long as something does That's what I have now and I have this ejecting problem. Should I just emerge udisks-2 into a new slot? I have a hunch that won't work and USE=udisks is hard masked for gvfs. Logic tells me that even if udisks:2 is available, gvfs won't use it. But, it's worth a try. I tried but no luck. I should hear from the maintainer soon. Another SLOT question. udisks:0 was installed and now udisks:2. What about slot #1? - Grant I also think you need the maintainer to take a closer look - it all looks like the ebuild needs some tweaking, or maybe it's just a magic combination of USE that we missed.
Re: [gentoo-user] Re: Advice needed regarding udisks
On 19/08/2013 11:43, Grant wrote: When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: # udisks --detach /dev/sdb Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb USB device: /sys/devices/pci:00/:00:02.0/usb2/2-6) SYNCHRONIZE CACHE: FAILED: No such file or directory (Continuing despite SYNCHRONIZE CACHE failure.) STOP UNIT: FAILED: No such file or directory # emerge -pv gvfs libgdu [ebuild R] gnome-base/libgdu-3.0.2 USE=-avahi -doc -gnome-keyring 0 kB [ebuild R] gnome-base/gvfs-1.12.3-r1 USE=cdda gdu http udev -afp -archive -avahi -bluetooth -bluray -doc -fuse -gnome-keyring -gphoto2 -ios -samba (-udisks) 0 kB ^^^ There's your problem. thunar depends on gvfs, which can use udisks, but in your case the USE flag is forced, masked, or removed. You need to find out why that happened, it might be a profile thing, maybe it's a local config. Try grep -r udisks /etc/portage/ Nothing comes back from that grep. My profile is default/linux/amd64/13.0/desktop. What else could be preventing me from enabling that USE flag? It might be masked by the profile. As I understand it, recent EAPIs allow USE flags to be forced per-profile. This makes sense - a dev might enable USE=udev everywhere except on gentoo-freebsd profiles, just as an example. But I'm not yet up to speed on how to detect and over-ride such things. I think you should log a bug now at b.g.o. and let the devs tell you what's really going on with your selections. Will do, and I'll report back with the results. Thanks, Grant - From $PORTDIR/profiles/base/package.use.mask: # GNOME gn...@gentoo.org (02 Oct 2012) # Mask USE=udisks and use USE=gdu as the default for gnome-base/gvfs-1.14; # older gvfs releases have problems with recent stable udisks:2 (bug #463792) gnome-base/gvfs-1.14 udisks OK, there it is. If I keyword gvfs I get into trouble because gobject-introspection wants dev-libs/glib-2.33 and gvfs wants =dev-libs/glib-2.36. Don't keyword gvfs, for gvfs: USE=-udisks gdu gvfs doesn't care what does the automounting, as long as something does That's what I have now and I have this ejecting problem. Should I just emerge udisks-2 into a new slot? I have a hunch that won't work and USE=udisks is hard masked for gvfs. Logic tells me that even if udisks:2 is available, gvfs won't use it. But, it's worth a try. I tried but no luck. I should hear from the maintainer soon. Another SLOT question. udisks:0 was installed and now udisks:2. What about slot #1? There is no SLOT 1 for udisks. SLOTs have arbitrary names that can be anything, they are not named numerically in sequence. The maintainers usually name a SLOT after the major version number becuase that is very descriptive, but it's not required There is only one SLOT name that has magic significance, SLOT:0, which is the default if the package is not explicitly in a slot. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
pk wrote: On 2013-08-19 00:49, Dale wrote: Picking random message sort of. Isn't eudev still going to support a separate /usr? That is my understanding. If eudev is not then I may have to reconsider some things myself here. Yes, that is my understanding as well. But the decision to not support a separate /usr lies higher up in the system hierarchy (as I understand it). Gentoo as a system will not support a separate /usr if we are to believe the conversation (I haven't seen any official notice of this though). That is the sad part. The problem I have, as an engineer, is that everybody says that a separate /usr is broken, that sysvinit is broken without explaining why. In order to fix a problem you need to know what is broken... The people who claims the brokenness are, imo, hand waving and they've managed to convince higher uppers in the Gentoo infrastructure (as it seems). I guess if you repeat something often enough it becomes a truth or said person(s) just agrees to stop the nagging. Best regards Peter K Right now, I'm using eudev. If my machine stops booting because it needs a init thingy, this could get interesting. I used dracut for a bit until eudev came along but for me, it was a tool to see if things blow over and some folks come to their senses. As much as I hate Mandriva which had a init thingy, if I have to have one and find myself unable to chroot into Gentoo and make repairs, at least Mandriva installs faster. Yea, you can do a lot in chroot but only if you can figure out what is wrong and know how to fix it. I to hope folks can see the light before this bad dream turns into a nightmare. The further this goes, the harder it is going to be to back peddle and fix it. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] systemd and initramfs
Hi, what binaries and libraries have to be put into an initramfs for a system booting with init=/usr/lib/systemd/systemd ? (I am building the initramsfs myself) Thanks for some hints, Helmut
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 11:31, pk wrote: On 2013-08-19 00:49, Dale wrote: Picking random message sort of. Isn't eudev still going to support a separate /usr? That is my understanding. If eudev is not then I may have to reconsider some things myself here. Yes, that is my understanding as well. But the decision to not support a separate /usr lies higher up in the system hierarchy (as I understand it). Gentoo as a system will not support a separate /usr if we are to believe the conversation (I haven't seen any official notice of this though). That is the sad part. The problem I have, as an engineer, is that everybody says that a separate /usr is broken, that sysvinit is broken without explaining why. In order to fix a problem you need to know what is broken... The people who claims the brokenness are, imo, hand waving and they've managed to convince higher uppers in the Gentoo infrastructure (as it seems). I guess if you repeat something often enough it becomes a truth or said person(s) just agrees to stop the nagging. It's not that separate /usr is broken - it's not. The issue is a separate /usr without an initramfs. And the issue ONLY occurs at early-boot time. The problem is that with modern hardware much code that was traditionally stored in /usr may be needed early in the boot sequence, before /usr is mounted. The obvious case is firmware and drivers, and the usual example cited is bluetooth keyboards. If you need keyboard input at this time, you need to have the bluetooth daemon running, which is on /usr, which is not mounted. The solution is to use an initramfs, and on a technical level it's not any different to needing a way to get the ext4 module off disk so you can mount /. Some may argue that bluetooth keyboards are a rarity and that's tough. Well, there's Macbook hardware, and phones which have soft keyboards. But many scenarios could exist, all due to the fact that hot-pluggable hardware can in theory run any arbitrary code to get itself up and running, and if that code is on a volume that is not mounted... The solution is obvious - all that code should be on / somewhere, or should be mountable using an initramfs. Do you see that although you and I can deal with this with relative ease, Aunt Tillie probably couldn't and the junior sysadmins I have to deal with certainly can't? Personally, I think that splitting / and /usr is a daft idea: a. I have multi-TB hard disks, completely unlike the 5M monsters that Thomson had to deal with in the 70s b. I haven't had /usr break on me during boot requiring busybox in maintenance mode for at least 5 years. Every startup failure in that time required a rescue cd anyway, and I always have one of those handy c. it IS useful for terminal servers, but those tend to have experienced sysadmins, and they really should be OK with an initramfs (or their vendor should ship one) I'm often at the front of the Lennart-bashing parade, and what he says often makes sense but only in his narrow view of the world, but in *this* case, I can't help but admit he does have a point. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19 August 2013, at 10:31, pk wrote: ... The problem I have, as an engineer, is that everybody says that a separate /usr is broken, that sysvinit is broken without explaining why. In order to fix a problem you need to know what is broken... Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] I honestly don't have a horse in this race, I don't much care one way or the other. I tend to like things the old fashioned way, I like things simple, and I like to keep doing things the way I know. I hate the whole initrd thing, but I tend to slap most everything on a single partition, anyway. I could be persuaded either way, were there compelling arguments, but you just undermine your own position by pretending that the reasons for the migration are somehow fictional. Stroller. [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Re: [gentoo-user] libreoffice cannot use oxygen theme
2013/8/19 Alan McKinnon alan.mckin...@gmail.com: webkit* updates have slowed down recently so I'm not too bothered about that. But chromium, that thing drive me to tears, now I just use google-chrome. Well, I choose to temporarily mask chromium if I don't have the time. I have a /etc/portage/package.mask/11temp for (mainly) that (-: I've switched yesterday from firefox to firefox-bin after some mysterious crashes in the graphic backend (with HW acceleration force enabled), only to find my compiler is not at fault... But the binary version indeed fixed another bug, that's the page loading spinner not animating, so I'd stick with that. I don't have to use google-chrome because chromium is usually *still* masked when I feel like upgrading, so it actually doesn't cost me much time. In fact, I usually go to sleep right after starting emerge (-: I don't always need the latest icu - 7-bit ASCII satisfies all my daily needs :-) So I can afford to mask anything after the current version and just leave it as-is until it suits me to rebuild things. As a Chinese, living with Unicode support is a must. But since CJK codepoints are well supported for ages, and most of Chinese users are not researchers who need access to the latest glyphs or complex-layout writing systems, we don't have to upgrade icu that often either. Actually, AFAICT all my icu upgrades are forced on me by the version bump of big things like chromium or libreoffice.
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 1:04 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 19/08/2013 11:31, pk wrote: On 2013-08-19 00:49, Dale wrote: Picking random message sort of. Isn't eudev still going to support a separate /usr? That is my understanding. If eudev is not then I may have to reconsider some things myself here. Yes, that is my understanding as well. But the decision to not support a separate /usr lies higher up in the system hierarchy (as I understand it). Gentoo as a system will not support a separate /usr if we are to believe the conversation (I haven't seen any official notice of this though). That is the sad part. The problem I have, as an engineer, is that everybody says that a separate /usr is broken, that sysvinit is broken without explaining why. In order to fix a problem you need to know what is broken... The people who claims the brokenness are, imo, hand waving and they've managed to convince higher uppers in the Gentoo infrastructure (as it seems). I guess if you repeat something often enough it becomes a truth or said person(s) just agrees to stop the nagging. It's not that separate /usr is broken - it's not. The issue is a separate /usr without an initramfs. And the issue ONLY occurs at early-boot time. The problem is that with modern hardware much code that was traditionally stored in /usr may be needed early in the boot sequence, before /usr is mounted. The obvious case is firmware and drivers, and the usual example cited is bluetooth keyboards. If you need keyboard input at this time, you need to have the bluetooth daemon running, which is on /usr, which is not mounted. The solution is to use an initramfs, and on a technical level it's not any different to needing a way to get the ext4 module off disk so you can mount /. Some may argue that bluetooth keyboards are a rarity and that's tough. Well, there's Macbook hardware, and phones which have soft keyboards. But many scenarios could exist, all due to the fact that hot-pluggable hardware can in theory run any arbitrary code to get itself up and running, and if that code is on a volume that is not mounted... The solution is obvious - all that code should be on / somewhere, or should be mountable using an initramfs. You fail to understand why separate / is required. Had the argument was: If you have special needs then have /usr mounted at boot. I would have agreed. This means that if you are using bluetooth keyboard, well you do have an extra requirement. However, because of your specific configuration drop the ability to recover from filesystem corruptions or be able to repair is totally different issue. Personally, I think that splitting / and /usr is a daft idea: a. I have multi-TB hard disks, completely unlike the 5M monsters that Thomson had to deal with in the 70s You could have mounted several disk at boot even in the 70s. b. I haven't had /usr break on me during boot requiring busybox in maintenance mode for at least 5 years. Every startup failure in that time required a rescue cd anyway, and I always have one of those handy This is your take... and it is totally wrong. c. it IS useful for terminal servers, but those tend to have experienced sysadmins, and they really should be OK with an initramfs (or their vendor should ship one) Who is that vendor? so you along with systemd, udev, gnome, etc... do you suggest the same vendor will also provide initramfs for gentoo... maybe this is the next stage of systemd... I'm often at the front of the Lennart-bashing parade, and what he says often makes sense but only in his narrow view of the world, but in *this* case, I can't help but admit he does have a point. Again, there is no reason why not support separate /usr configuration, people who have special needs, like running systemd or have special complex userland hardware that is a must for single user mode can always mount /usr at early stage. But because of the fact that you are using systemd or have bluetooth keyboard force everyone to merge /usr is something that is unclear to me. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote: Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] How much of that is needed before the contents of /etc/fstab are mounted? I certainly don't need to run a desktop, used a 3G modem, play sounds or load a virtual machine before then. Yes, LVM may be needed, but the needed parts are in /sbin anyway, so that is a red herring too. I understand the need, even desire, of binary distros to cover all bases by taking the safer option, but Gentoo is about choice and all reasonable choices should be permitted. It comes down to what the council means by not supported. If it means will not work that will cause problems for some, but if it means you have to work it out for yourself, well, what's the point of a community if we can't work it out between us? -- Neil Bothwick Death to all fanatics! signature.asc Description: PGP signature
Re: [gentoo-user] libreoffice cannot use oxygen theme
2013/8/18 东方巽雷 dongfangxun...@gmail.com: I download LibreOffice_4.1.0_Linux_x86-64_deb.tar.gz from https://www.libreoffice.org/download/ and extract all the deb files.My desktop is KDE,but libreoffice only uses gtk+ theme. How should I find out the problem? Oh... upon further reading of your question it seems we're all misled by your description. Your real question is Why a GTK application won't pick up KDE's theme settings, and the answer is it simply doesn't know about Qt in the first place. I downloaded the archive you used and ldd'd all the libraries, none seems to depend on Qt. Gentoo's libreoffice-bin packages are build by Gentoo developers (I remember a blog post explaining this), so they're different from the upstream provided ones. I haven't used them, so I can't say if they would help, but it's certain that the official builds does NOT support Qt widgets. Solution: Install oxygen-gtk for Oxygen-looking GTK2 widgets.
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 08:35, Alan McKinnon wrote: sysvinit, like X11, needs a massive overhaul and a sprint clean. Yes, an overhaul is always welcome. But most people criticising these systems (and other systems) just say that they are bad without pointing out what is bad. How can you fix something without knowing what's bad? To me the problem with sysvinit (and X11) seems mostly to be a philosophical one. Some people say: this doesn't work the way I want it to - therefore it's crap!. While others (like me) say: I have no problem with this - it works fine!. From a technical standpoint, does sysvinit fulfill the technical requirements (i.e. the specification)? I honestly don't know, I just think/assume it does since we've been using it for, what, 30 years or so (SVR1 was released in January 1983 acc. to [1]) and I've never had any problems with it. Does the specification need to be updated? I'm sure it does but to throw out everything and start from scratch is not the way I would go (unless it's technically required because of some fundamental issue - and I disagree with people thinking there's a fundamental issue here). Now, some people who thinks the computer should sing and dance to them (seems to me mostly the Gnome crowd) while booting, I can understand that sysvinit may not fit their philosophy. I am not one of them. Basically I want the computer to do as little as possible, i.e. not waste one cycle unless _absolutely_ necessary; _all_ compute power should be available to me and me only for whatever purpose I see fit. The computer is a tool, a hammer if you will and I don't want a hammer with built-in radio, a fan to cool you down, a radiator to warm you up or a tv screen (or whatever). Of course, computers being so complex these days (I started out with a Commodore PET in the late 70ies), there has to be compromises. And I think that sysvinit with it's init scripts (i.e. OpenRC) is a good compromise because I don't care about boot time (as mentioned in another mail most of the time is spent in BIOS/UEFI anyway). Having said that I wouldn't mind if we refined sysvinit/OpenRC carefully, getting rid of bugs (even though I've never encountered any), refining the blueprints/specification so that it fits the customers wishes (within reason). Basically what I'm trying to say is: The technical arguments that have been brought forward pro/con sysvinit(+OpenRC)/systemd I think is bogus. It is just a philosophical disagreement between parties having different goals, which I'm not sure can be fully satisfied by either side. [1] https://en.wikipedia.org/wiki/UNIX_System_V Best regards Peter K
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 14:13, pk wrote: sysvinit, like X11, needs a massive overhaul and a sprint clean. Yes, an overhaul is always welcome. But most people criticising these systems (and other systems) just say that they are bad without pointing out what is bad. How can you fix something without knowing what's bad? To me the problem with sysvinit (and X11) seems mostly to be a philosophical one. Some people say: this doesn't work the way I want it to - therefore it's crap!. While others (like me) say: I have no problem with this - it works fine!. I find sysvinit to be unwieldy and clunky. Perhaps not so much the code itself, but surely the interface it presents to me the sysadmin. All that rc.[0-6] nonsense - what's that all about? In all my days I have never seen a computer running *nix that wasn't fully satisfied with two exclusive running states: - normal operation (whether console, headless, X) - maintenance mode (busybox on console). So why do I have 6 of them? The runlevels themselves are fixed and rigid. I want them somewhat more flexible, I actually don't want a bluetooth daemon *running*all*the*time* - really, it should only start when I enable bluetooth. This may not be the best analogy but you get the point, the OS needs to react to changes in the environment and sometimes those reactions are best dealt with by the service manager. OpenRC to my mind made huge strides in dragging this into modern times by making runlevels declarative. It all make so much sense in Gentoo. As for the bulk of the code, I don't have issue with that. PID=1 does what it needs to do. I suppose I can sum up the changed environment in one word: hotplug X11, well that's another story and probably way off topic. It was designed for hardware and architectures that haven't existed for 20+ years. Almost all factors that made X11 awesome in the 80s and 90s simply are not there anymore. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 04:55, Canek Peláez Valdés wrote: Probably for exactly the same reason you or anyone else uses Gentoo; USE flags, portage, you can customize at your hearts content... USE flags, in my mind, are there for minimising dependencies so that I don't need to install all the crap that binary distros install. That is why I use Gentoo, in order to avoid all the crap that things like Gnome wants to install (for instance, I have -gnome, -dbus, -gconf in my make.conf in order to avoid a heart attack[1]). Customisation are only possible if you allow to minimise dependencies; and it's also dependent on a flexible base system (if you put restrictions on it, say, if /usr can be separate or not[without an initrd], then flexibility decreases). I've never used Fedora. I used RedHay back in the day of RedHat 4.2 (it was my very first use of Linux in 1996), then moved to Mandrake (remember Mandrake?), then Gentoo in 2003. I haven't used any other distro since then. This is rather pointless, but I started using a Linux based OS (don't remember the name, but it came on 9 floppy disks with kernel 0.93) on my Amiga 4000 in the early nineties. I've used Redhat, Mandrake, Debian, Slackware and others, landing with LFS in 2000 which I was happy with but it was too much work so I settled with Gentoo in the early 2000 which is the best compromise I have found. Haven't used any other distro since then either... I want Gentoo to keep being the best possible Linux (I *really* don't care if it works in *BSD, Solaris, or Windows). Believe it or not, I'm I want Gentoo to be the best *OS* for me. To me that is achieved by having the widest possible selection of applications and following standards as closely as possible (POSIX, FHS). I don't really care if it's Linux or not but I'm most comfortable in a UNIX like environment. That said, I think what you are advocating is going in a opposite direction to what I want... to me the changes you seek are making Gentoo going from best to bad; reducing choice/flexibility. pretty sure that for Gentoo to keep being the best possible Linux, it has to use systemd. I fully believe you think that systemd is the best choice for init systems out there, but then again you are a Gnome user (as I understand it) and to me that is quite the opposite from what I want (I abhor the whole Gnome eco system and Lennart is an old Gnome dev so I can see where the influences comes from). I happen to think that many small tools with clearly defined interfaces (i.e. a standard) works so much better and are so much more flexible than ... the one system to rule them all You don't have to agree with that, of course. But please understand that I only support systemd in Gentoo, because I love Gentoo. I understand that. The thing is, as I see it, you support (advocate would perhaps be a better choice of words) systemd and _only_ systemd, thereby forcing it down our throats. And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) I fail to see why I should waste time and resources by having a duplicate set of tools (one in the initramfs and one in /). How is that a *technical* solution? I would call it bandaid. There is no difference from having static binaries in / (it's just a matter of locality). So, yes, I have thought about it and I don't consider it the best *decision* (*gasp*). When you have almost all distributions converging on that, and even You said ... customize at your hearts content To me that assumes flexibility. If you take away choice, you take away flexibility. To me that's a contradiction. That almost all distributions are converging is a non-argument; it says nothing about technical excellence (whatever that means). It may merely mean that the devs in said distros have given up and just eat whatever crap they're served because of lack of manpower or whatever. [1] Yes, I hate Gnome with a passion ever since using it on those distros mentioned above. Best regards Peter K
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 6:04 AM, Alan McKinnon alan.mckin...@gmail.com wrote: It's not that separate /usr is broken - it's not. The issue is a separate /usr without an initramfs. And the issue ONLY occurs at early-boot time. And so, if this is the way it goes, this is the way it goes. As long as I can keep using eudev - even *if* it requires an initramfs for a separate /usr (as long as it doesn't require one if you don't have a separate /usr)... Can anyone answer *that* question please?
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. And the track record speaks for itself, regardless of *any* promises that it won't, it is obvious to anyone with eyes to see and ears to hear that this is a blatant LIE. Everything that is happening is simply setting the stage for precisely that. When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... In my opinion, the single largest reason to *not* switch to systemd in gentoo is the source of the push - in other words, it is coming from Fedora - and GNOME lovers are the maintainers.
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/13 18:55, Neil Bothwick wrote: On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote: Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] How much of that is needed before the contents of /etc/fstab are mounted? I certainly don't need to run a desktop, used a 3G modem, play sounds or load a virtual machine before then. Yes, LVM may be needed, but the needed parts are in /sbin anyway, so that is a red herring too. I understand the need, even desire, of binary distros to cover all bases by taking the safer option, but Gentoo is about choice and all reasonable choices should be permitted. It comes down to what the council means by not supported. If it means will not work that will cause problems for some, but if it means you have to work it out for yourself, well, what's the point of a community if we can't work it out between us? I rather suspect that they are going after the cloud/VM market ... having VM's boot quickly and simply along with no desire/need to fault find and repair ... just rm it and spin up another instance. It makes sense in that market ... what doesn't is pushing it into areas that are not appropriate and people dont want it. I think that Fedora has largely dropped off peoples list of useful distros but more interesting is how Redhat will go when these ideas start to get included in RHE - last I heard that still has not happened. I did try Fedora as a choice on our networking machines for students but took it off as no one used it as it was just not nice - possibly the bad vibes of gnome3 contributing - the surprise was linuxmint being more popular than ubuntu. Gentoo is there but only as a specially configured command line only tool so its not in the running. I still have not seen an adequate explanation as to why systemd isn't a profile as its far more intrusive than a gnome/kde choice and they have profiles. That way some bad choices like polluting systems with systemd files because they are only small and insignificant might be avoided. I have used the mask method but did waste some time on chasing down odd errors due to missing file errors in the logs so I would rather not have them on the system at all. So why not a profile so those guys who want to play can get a configuration that better suits them? - and vice versa if the whole systemd push dies and Redhat drops it as I doubt anyone else big enough will pick it up (they have a foot in both camps at the moment). Smaller distros that jump entirely systemd will be in trouble until they move back. BillK
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 15:23, Tanstaafl wrote: On 2013-08-19 6:04 AM, Alan McKinnon alan.mckin...@gmail.com wrote: It's not that separate /usr is broken - it's not. The issue is a separate /usr without an initramfs. And the issue ONLY occurs at early-boot time. And so, if this is the way it goes, this is the way it goes. As long as I can keep using eudev - even *if* it requires an initramfs for a separate /usr (as long as it doesn't require one if you don't have a separate /usr)... Can anyone answer *that* question please? Honestly, what you want is a full-fledged udev fork from just before systemd tainted it, and fully maintained to go in the direction we understood classic udev to be going. eudev and even mdev are a step in the right direction, but I believe they don't have enough muscle behind them, i.e. they end up cherry picking useful bits out of udev-subsumed-into-systemd. udev needs the same quality of maintainership now in a fork that it used to have. And it's probably only a matter of time before someone with those resources gets fed up with the current scene and does exactly that. For me, I'm not opposed to merging /usr. I'm not opposed to other people using systemd, I am opposed to *me* using it. For your other question, you don't need an initramfs if your /usr is not split off and drivers for your fs on / and chipset are compiled in. That will stay true for ages to come (until some joker starts shipping kernel drivers in /var) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 15:36, William Kenworthy wrote: I still have not seen an adequate explanation as to why systemd isn't a profile as its far more intrusive than a gnome/kde choice and they have profiles. That way some bad choices like polluting systems with systemd files because they are only small and insignificant might be avoided. I have used the mask method but did waste some time on chasing down odd errors due to missing file errors in the logs so I would rather not have them on the system at all. There was an uber-thread on -dev over the last two months that covered most of these bases. I stopped paying attention about halfway through... but it's all there on gmane. The thread started with with a proposed sysvinit - systemd migration script, and it quickly became obvious why profiles and USE flags look OK at first glance but rapidly becomes apparent that they aren't. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Optional /usr merge in Gentoo
On 2013-08-19 11:21, Stroller wrote: Blimey! You must have a slow BIOS cycle. Yes, I bought the motherboard specifically for a slow BIOS cycle... ;-) Joke aside, I have a SAS raid card in the machine which probes the harddrives (four mechanical ones) which takes maybe half that time. I've been toying with the idea of replacing BIOS/UEFI with coreboot/seabios but time is lacking... :-( For the record, I've always felt BIOS have been slow... (OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). I recently bought 4 SSDs (Intel 520 60GB) and have them installed as /usr, /var and /tmp with one spare. However / is still on the SAS raid card and boot time has not improved by much with the SSD. It's matter of what crap you load at boot that will affect your boot time. Best regards Peter K
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. *snip* When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Isn't that what this thread is about? Optional /usr merge in Gentoo Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. -- Alecks Gates
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates aleck...@gmail.com wrote: On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. *snip* When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Isn't that what this thread is about? Optional /usr merge in Gentoo Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. Yeah... it is not complicated to but Windows as well, or IBM os-390!!! You use a tool that hides the initramfs building, and you are amazed it is simple? The files within the initramfs generation tool are compiled using different tool than portage, they are not updated when distribution is updated, and they are not even at same version within portage tree. It may be acceptable for you... but do not expect everyone will accept your setup. Regards, Alon
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 12:04, Alan McKinnon wrote: It's not that separate /usr is broken - it's not. I know. The issue is a separate /usr without an initramfs. And the issue ONLY occurs at early-boot time. It is broken for *some* systems. The problem is that with modern hardware much code that was traditionally stored in /usr may be needed early in the boot sequence, before /usr is mounted. The obvious case is firmware and drivers, and the usual example cited is bluetooth keyboards. If you need keyboard input at this time, you need to have the bluetooth daemon running, which is on /usr, which is not mounted. Yes, bluetooth... the very thing that should not have come to pass. It is broken by design. Wireless is fine but the way bluetooth works... Back to the drawing board, please! The solution is to use an initramfs, and on a technical level it's not any different to needing a way to get the ext4 module off disk so you can mount /. Yes, that is one way of solving it... But I question the sanity by having ext4 as a module if you know you are going to use it on your system; it's not as if you are going to use ext4 one day and reiserfs the next day and XFS the day after that, or? The only ones that benefits from that kind of setup is binary distros that can compile everything as module and probe as they load. I do however have some things compiled as modules (that I only load when needed) but those things are not needed at boot. So for my case it's not needed. Some may argue that bluetooth keyboards are a rarity and that's tough. Well, there's Macbook hardware, and phones which have soft keyboards. But many scenarios could exist, all due to the fact that hot-pluggable hardware can in theory run any arbitrary code to get itself up and running, and if that code is on a volume that is not mounted... The solution is obvious - all that code should be on / somewhere, or should be mountable using an initramfs. Yes, *should* be. Quite optional. As it has always been. Just because people are using bluetooth devices and/or want the computer to sing and dance while booting should not impose restrictions to those who don't want that, which is why I'm protesting. Do you see that although you and I can deal with this with relative ease, Aunt Tillie probably couldn't and the junior sysadmins I have to deal with certainly can't? Yes. But have Gentoo ever been a distro for Aunt Tillie or junior sysadmins? I don't want to discourage them to try it out of course but I don't want to put restrictions on myself (or others) either... Flexibility is the keyword here. Personally, I think that splitting / and /usr is a daft idea: That's fine. I, respectfully, disagree. If I could break the system down into bits and put each bit on a separate harddrive with a massive I/O connection I would (yes, I exaggerate but I'm sure you get the idea). a. I have multi-TB hard disks, completely unlike the 5M monsters that Thomson had to deal with in the 70s Haven't you heard? Size does not matter... ;-) b. I haven't had /usr break on me during boot requiring busybox in maintenance mode for at least 5 years. Every startup failure in that time required a rescue cd anyway, and I always have one of those handy I haven't had /usr break either for at least that time even though I've always had it separate. To me, I like to keep things organised in different compartments using, perhaps somewhat arbitrary, rules. Therefore keeping system administration tools in /sbin, user accessible tools in /usr/bin etc. makes perfect sense (I know you think it's arbitrary and I agree but it works, for me at least). There is no *real* need to keep /usr separate for normal users it's just that I think it's flexible and I want it that way. There is no right or wrong here, merely philosophical differences. How you solve the different problems are technical however. I do have a rescue USB stick handy as well though but since I rarely use it I tend to forget to update it... c. it IS useful for terminal servers, but those tend to have experienced sysadmins, and they really should be OK with an initramfs (or their vendor should ship one) Using an initramfs means you duplicate parts of your OS and copy them into the kernel or using a tool (like dracut or genkernel). If you need it from a technical point of view (bluetooth keyboard), that's fine but if I don't have any hardware that requires it then why use an initramfs? I guess it's a matter of taste (or philosophy if you will)... An initramfs seems like bandaid to me (and it is). I'm often at the front of the Lennart-bashing parade, and what he says often makes sense but only in his narrow view of the world, but in *this* case, I can't help but admit he does have a point. I don't really see it... I don't really care what Lennart does as long as it doesn't affect me (and he may be the greatest person that ever lived) but here we are... I choose to run Gentoo because it suits me best
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev alo...@gentoo.org wrote: On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates aleck...@gmail.com wrote: On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. *snip* When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Isn't that what this thread is about? Optional /usr merge in Gentoo Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. Yeah... it is not complicated to but Windows as well, or IBM os-390!!! You use a tool that hides the initramfs building, and you are amazed it is simple? Dracut isn't *hiding* anything from me, I just don't need anything more complicated -- who said I'm amazed? The files within the initramfs generation tool are compiled using different tool than portage, they are not updated when distribution is updated, and they are not even at same version within portage tree. Why does this matter? Are there some huge security vulnerabilities I'm unaware of? It may be acceptable for you... but do not expect everyone will accept your setup. Don't mind me, I'm just looking for the logic. Feel free to explain it to me. Regards, Alon -- Alecks Gates
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 5:37 PM, Alecks Gates aleck...@gmail.com wrote: On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev alo...@gentoo.org wrote: On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates aleck...@gmail.com wrote: On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. *snip* When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Isn't that what this thread is about? Optional /usr merge in Gentoo Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. Yeah... it is not complicated to but Windows as well, or IBM os-390!!! You use a tool that hides the initramfs building, and you are amazed it is simple? Dracut isn't *hiding* anything from me, I just don't need anything more complicated -- who said I'm amazed? The files within the initramfs generation tool are compiled using different tool than portage, they are not updated when distribution is updated, and they are not even at same version within portage tree. Why does this matter? Are there some huge security vulnerabilities I'm unaware of? It may be acceptable for you... but do not expect everyone will accept your setup. Don't mind me, I'm just looking for the logic. Feel free to explain it to me. What do you mean Don't mind me? I don't mind you... as long as you don't force me to do anything... Regards, Alon -- Alecks Gates
Re: [gentoo-user] systemd and initramfs
On Mon, Aug 19, 2013 at 5:58 AM, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, what binaries and libraries have to be put into an initramfs for a system booting with init=/usr/lib/systemd/systemd ? (I am building the initramsfs myself) You need to get your root filesystem and /usr mounted. Just keep that goal in mind and start adding files to support it. There doesn't need to be anything systemd-specific.
Re: [gentoo-user] systemd and initramfs
On 08/19/2013 10:58 AM, Helmut Jarausch wrote: Hi, what binaries and libraries have to be put into an initramfs for a system booting with init=/usr/lib/systemd/systemd ? (I am building the initramsfs myself) Thanks for some hints, Helmut my 2c would be to autobuild one using genkernel or dracut and then dissemble it this is because I always forget silly things like the special files dev/tty and sda
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 08/19/2013 03:37 PM, Alecks Gates wrote: On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev alo...@gentoo.org wrote: On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates aleck...@gmail.com wrote: On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. Repeat: the primary concern is *not* about separate /usr without initramfs. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. *snip* When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Isn't that what this thread is about? Optional /usr merge in Gentoo Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. Yeah... it is not complicated to but Windows as well, or IBM os-390!!! You use a tool that hides the initramfs building, and you are amazed it is simple? Dracut isn't *hiding* anything from me, I just don't need anything more complicated -- who said I'm amazed? The files within the initramfs generation tool are compiled using different tool than portage, they are not updated when distribution is updated, and they are not even at same version within portage tree. Why does this matter? Are there some huge security vulnerabilities I'm unaware of? If you have one system to keep on top of, it's simple to make sure to update initramfs after a kernel update If you have many systems, and they are remote, it becomes trickier. A borked kernel update remotely can be easily resolved by panic=1 and having a grub failsafe boot option. It doesn't even need a kernel update. I'm a big fan of LVM, but i found that in the upgrade to sys-fs/lvm2-2.02.99-r2 my usb devices were coming up as invalid pvs on LVM start in the default runlevel, after the initramfs. No biggie locally, and only backups were on those devices. but remotely and at system updating times (silly oclock) it's easy to miss a simple thing like initrd update. worse if what is borked is relied upon -- consider a system that only boots 75% -- it doesn't fail but it doesn't start all services in the default runlevel because the initrd is not updated, or is updated incorrectly. being locked out of boxes remotely at silly oclock sucks, and we don't always have the benefit of OOB management, IPVS or DRBD to not worry about it until after sleep has relaxed the mind. this has always been one of the biggest pros of gentoo for me - where everything is a stream of data even the OS is like a slipstream. updating many gentoos however can be a big issue and I do try to keep similar boxes similar hardware because of it -- allowing me to test updates before they get rolled out, and also allows me to add in crucial use flags (dlz, openssl) when they suddenly become required; great to figure out on a test machine first and then roll out x30 rather than figure out 30times over! Because of LVM/LUKS i have used initrd for a long time but i can understand why the migration sucks - first install and testing and then maintenance thereafter. Going up to udev200 was scary enough. . . scary because of that remote system status on NIC naming! Equally we don't always have the benefit of a secondary identical monster server to test new configurations on. i almost would like to request tighter integration between portage/kernel building/initrd but i'm not convinced the ubuntu way is the correct way as that leads to customisations breaking systems, and gentoo is all about customisation, making the OS fit the hardware. It may be acceptable for you... but do not expect everyone will accept your setup. Don't mind me, I'm just looking for the
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 9:36 AM, Alan McKinnon alan.mckin...@gmail.com wrote: For me, I'm not opposed to merging /usr. I'm not opposed to other people using systemd, I am opposed to*me* using it. Agreed, and that is precisely the concern here... For your other question, you don't need an initramfs if your /usr is not split off and drivers for your fs on / and chipset are compiled in. That will stay true for ages to come (until some joker starts shipping kernel drivers in /var) Right, but that wasn't my question, my question was will I be able to continue using eudev (or mdev, or whatever)...
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 9:36 AM, William Kenworthy bi...@iinet.net.au wrote: I rather suspect that they are going after the cloud/VM market ... having VM's boot quickly and simply along with no desire/need to fault find and repair ... just rm it and spin up another instance. Nothing to 'suspect'... they have made it very clear that that is precisely where this (systemd) is coming from. It makes sense in that market ... what doesn't is pushing it into areas that are not appropriate and people dont want it. Exactly, and exactly. I still have not seen an adequate explanation as to why systemd isn't a profile as its far more intrusive than a gnome/kde choice and they have profiles. That way some bad choices like polluting systems with systemd files because they are only small and insignificant might be avoided. I have used the mask method but did waste some time on chasing down odd errors due to missing file errors in the logs so I would rather not have them on the system at all. So why not a profile so those guys who want to play can get a configuration that better suits them? I have to say that makes the most sense to me... Would love to hear *rational* comments from the systemd purveyors as to why this shouldn't be done.
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/13 at 09:36pm, William Kenworthy wrote: So why not a profile so those guys who want to play can get a configuration that better suits them? - and vice versa if the whole systemd push dies and Redhat drops it as I doubt anyone else big enough will pick it up (they have a foot in both camps at the moment). Smaller distros that jump entirely systemd will be in trouble until they move back. Not a systemd supporter in any way but I don't think making a profile makes sense because we already have profiles for kde, gnome, desktop etc. Users will probably want to use systemd in-conjunction with any one of those, so we would need to have kde-systemd, gnome-systemd .. which is absurd. At least I don't see a sane way to achieve it from my rudimentary understanding of profiles. -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 8:17 AM, pk pete...@coolmail.se wrote: On 2013-08-19 04:55, Canek Peláez Valdés wrote: Probably for exactly the same reason you or anyone else uses Gentoo; USE flags, portage, you can customize at your hearts content... USE flags, in my mind, are there for minimising dependencies so that I don't need to install all the crap that binary distros install. That is why I use Gentoo, in order to avoid all the crap that things like Gnome wants to install (for instance, I have -gnome, -dbus, -gconf in my make.conf in order to avoid a heart attack[1]). Customisation are only possible if you allow to minimise dependencies; and it's also dependent on a flexible base system (if you put restrictions on it, say, if /usr can be separate or not[without an initrd], then flexibility decreases). USE flags are for customizations, and they are available *as long as someone supports them*. I don't use KDE (I really don't like it); I don't have nothing KDE related (not even Qt) in any of my systems. AFAIK, that is not possible to do in any distro other than Gentoo. I've never used Fedora. I used RedHay back in the day of RedHat 4.2 (it was my very first use of Linux in 1996), then moved to Mandrake (remember Mandrake?), then Gentoo in 2003. I haven't used any other distro since then. This is rather pointless, but I started using a Linux based OS (don't remember the name, but it came on 9 floppy disks with kernel 0.93) on my Amiga 4000 in the early nineties. I've used Redhat, Mandrake, Debian, Slackware and others, landing with LFS in 2000 which I was happy with but it was too much work so I settled with Gentoo in the early 2000 which is the best compromise I have found. Haven't used any other distro since then either... I want Gentoo to keep being the best possible Linux (I *really* don't care if it works in *BSD, Solaris, or Windows). Believe it or not, I'm I want Gentoo to be the best *OS* for me. This is where you are confused, Peter. Nobody (except you) cares about your particular needs, in the same way that nobody (except me) cares about mine. The developers (Gentoo devs, GNOME devs, systemd devs, OpenRC devs, kernel devs) don't care (and don't have to) about particular cases: they have to care about *the general cases*. Some of them care about some cases, others care about others. As long as a case has someone(s) to support it, that case will be supported. So, if you want Gentoo to be the best *OS* for *you*, don't necessarily expect that anybody will do the work for you. To me that is achieved by having the widest possible selection of applications and following standards as closely as possible (POSIX, FHS). I don't really care if it's Linux or not but I'm most comfortable in a UNIX like environment. That said, I think what you are advocating is going in a opposite direction to what I want... to me the changes you seek are making Gentoo going from best to bad; reducing choice/flexibility. Why? eudev is there, you can use it. OpenRC is there, and if you agree with its maintainer (who wants to stop supporting separated /usr without an initramfs), you can keep using it. And of course, you can freeze all your machines and never upgrade again; what choices are you being denied? What is being discussed is that nobody is going to do work for you, so a bad technical combination (separated /usr without an initramfs) works. pretty sure that for Gentoo to keep being the best possible Linux, it has to use systemd. I fully believe you think that systemd is the best choice for init systems out there, but then again you are a Gnome user (as I understand it) and to me that is quite the opposite from what I want (I abhor the whole Gnome eco system and Lennart is an old Gnome dev so I can see where the influences comes from). I happen to think that many small tools with clearly defined interfaces (i.e. a standard) works so much better and are so much more flexible than ... the one system to rule them all And who is stopping you from using your many small tools with clearly defined interfaces? The code is there; if you are willing and able, you can tune everything as you want. Just don't expect someone will cater to your specific needs. You don't have to agree with that, of course. But please understand that I only support systemd in Gentoo, because I love Gentoo. I understand that. The thing is, as I see it, you support (advocate would perhaps be a better choice of words) systemd and _only_ systemd, thereby forcing it down our throats. First, I maintained an overlay for having only systemd (no OpenRC) for several months, so I would say support. Second, when I have said that I want to force *anyone* to use systemd? Citation please. I want Gentoo to fully support systemd (and we are almost there). I don't want to force no one to use it; where did you get that from? And, putting aside systemd and getting back on topic to the council's decision
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 11:43 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-19 9:36 AM, William Kenworthy bi...@iinet.net.au wrote: I rather suspect that they are going after the cloud/VM market ... having VM's boot quickly and simply along with no desire/need to fault find and repair ... just rm it and spin up another instance. Nothing to 'suspect'... they have made it very clear that that is precisely where this (systemd) is coming from. It makes sense in that market ... what doesn't is pushing it into areas that are not appropriate and people dont want it. Exactly, and exactly. I still have not seen an adequate explanation as to why systemd isn't a profile as its far more intrusive than a gnome/kde choice and they have profiles. That way some bad choices like polluting systems with systemd files because they are only small and insignificant might be avoided. I have used the mask method but did waste some time on chasing down odd errors due to missing file errors in the logs so I would rather not have them on the system at all. So why not a profile so those guys who want to play can get a configuration that better suits them? I have to say that makes the most sense to me... Would love to hear *rational* comments from the systemd purveyors as to why this shouldn't be done. Yohan already say it: you would need to do several combinations (systemd+GNOME, systemd+KDE, systemd+SELinux, etc.) Your polluted files are nothing (3MB, including binaries in a *systemd* installation... if you don't use systemd they should take less than 512KB); you don't want the profile solution for technical reasons, you want it for political reasons. That is not going to happen, and the (majority of) Gentoo maintainers (including the council) already stated that, if you don't want systemd unit files polluting your system, please use INSTALL_MASK. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-18 10:55 PM, Canek Peláez Valdés can...@gmail.com wrote: And, putting aside systemd and getting back on topic to the council's decision of (eventually) not supporting separated /usr without an initramfs; have you ever stopped to consider that, perhaps, that's the best *technical* decision? (*gasp*) That is *not* the concern here, Canek, and that should be obvious from the comments here. It's not obvious at all. Repeat: the primary concern is *not* about separate /usr without initramfs. See the last batch of emails; but even before a lot of people stated that their concern was the separate /usr withouth an initramfs dropping support. The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev or *anything* other than systemd (ie OpenRC/eudev) will. That makes no sense: the OpenRC maintainer is the one pushing the change. And the track record speaks for itself, regardless of *any* promises that it won't, it is obvious to anyone with eyes to see and ears to hear that this is a blatant LIE. Seriosly? If you don't trust the OpenRC maintainer then you are running out of options. Everything that is happening is simply setting the stage for precisely that. Nah. That's FUD, simply. Again, dropping support for separate /usr without initramfs is being pushed by the OpenRC maintainer, because it needs that to effectively competing with systemd. Really, read the Gentoo Project ML. When you have almost all distributions converging on that, and even *the OpenRC maintainer* (which is the one pushing this, BTW, not the systemd guys) supporting that decision, don't you think that perhaps, just*perhaps*, everybody screaming about the sky falling (which, BTW, they are certainly noisy, but I really don't think are that many) are overreacting and even (*gasp* again) wrong? Again, the main issue is not about separate /usr, so please stop trying to deflect the subject... Stop spreding FUD. In my opinion, the single largest reason to *not* switch to systemd in gentoo is the source of the push - in other words, it is coming from Fedora - and GNOME lovers are the maintainers. Who's advocating for switching Gentoo to systemd? Citation please. Really guys, get your facts straight. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] 7zip on ARM compilation error
Hi, I tried to emerge 7zip natively on a Beaglebone black. Which CPU is a ARMv7 Processor rev 2 (v7l) with the features swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls. The gcc is: gcc (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE gcc-copnfig -l armv7a-hardfloat-linux-gnueabi-4.6.3 The emerge failed: armv7a-hardfloat-linux-gnueabi-g++ -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -fPIC -DEXTERNAL_CODECS -DUNICODE -D_UNICODE -c -I. -I../../../myWindows -I../../../ -I../../../include_windows ../../Archive/Hfs/HfsRegister.cpp armv7a-hardfloat-linux-gnueabi-g++ -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -fPIC -DEXTERNAL_CODECS -DUNICODE -D_UNICODE -c -I. -I../../../myWindows -I../../../ -I../../../include_windows ../../Archive/Iso/IsoHandler.cpp ../../Archive/Iso/IsoHandler.cpp: In member function 'virtual LONG NArchive::NIso::CHandler::GetArchiveProperty(PROPID, PROPVARIANT*)': ../../Archive/Iso/IsoHandler.cpp:128:1: error: unrecognizable insn: (insn 571 570 572 31 (set (subreg:SI (reg:DI 306 [ MEM[(const struct CDateTime *)D.17190_71 + 804B].GmtOffset ]) 0) (sign_extend:SI (mem/s:QI (plus:SI (reg/f:SI 156 [ D.17190 ]) (const_int 812 [0x32c])) [0 MEM[(const struct CDateTime *)D.17190_71 + 804B].GmtOffset+0 S1 A16]))) ../../Archive/Iso/IsoIn.h:121 -1 (nil)) ../../Archive/Iso/IsoHandler.cpp:128:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. make[1]: *** [IsoHandler.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-arch/p7zip-9.20.1-r4/work/p7zip_9.20.1/CPP/7zip/Bundles/Format7zFree' make: *** [common7z] Error 2 On request I will mail the logs -- I dont want to pollute the mailing list. How can I avoid this error? Best regards, mcc
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 2013-08-19 19:05, Canek Peláez Valdés wrote: snipped a whole lot of bollocks I'm beginning to think you are a troll since you consistently misinterpret what I'm trying to say. This is the last thing I will say in this matter: Your technical arguments are bogus. Yes, I agree that my point is moot since I don't have the time or resources to steer Gentoo/Linux in a direction that I would like to see so I guess put up or shut up is appropriate... But if I remember correctly someone else (i.e. you) on this list a while ago was whining about systemd is not supported... So I reserve the right to whine about it as well. A hint for the future: Try to get off your high horse! /PK
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 1:55 PM, pk pete...@coolmail.se wrote: On 2013-08-19 19:05, Canek Peláez Valdés wrote: snipped a whole lot of bollocks I'm beginning to think you are a troll since you consistently misinterpret what I'm trying to say. This is the last thing I will say in this matter: Your technical arguments are bogus. Yes, I agree that my point is moot since I don't have the time or resources to steer Gentoo/Linux in a direction that I would like to see so I guess put up or shut up is appropriate... But if I remember correctly someone else (i.e. you) on this list a while ago was whining about systemd is not supported... I didn't whine; I collaborated with bug 318365 [1] so systemd was supported in Gentoo, and then I modified and wrote several ebuilds so we could have an overlay to get rid of OpenRC [3], and then I tried to do as much as possible (bugs 373219, 409385, several others) to get us to where we are today: with systemd almost a first class citizen in Gentoo. When bug 373219 is closed, I would consider that a mission accomplished. So I didn't whine; I worked to bring the changes I wanted into Gentoo. You should try it; it works. So I reserve the right to whine about it as well. Oh, please, whine as much as you want. It doesn't change absolutely nothing, though. A hint for the future: Try to get off your high horse! Seriously? You call telling the facts (with citations, by the way) being on a high horse? Jeez. Regards. [1] https://bugs.gentoo.org/show_bug.cgi?id=318365 [2] https://github.com/canek-pelaez/gentoo-systemd-only [3] https://bugs.gentoo.org/show_bug.cgi?id=373219 [4] https://bugs.gentoo.org/show_bug.cgi?id=409385 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, August 19, 2013 12:55, Neil Bothwick wrote: On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote: Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] How much of that is needed before the contents of /etc/fstab are mounted? I certainly don't need to run a desktop, used a 3G modem, play sounds or load a virtual machine before then. Yes, LVM may be needed, but the needed parts are in /sbin anyway, so that is a red herring too. It is a red herring. I currently use an initramfs, but that is because I decided to put / on LVM as well. When I had / as a normal partition and /usr on LVM, there were no issues with booting. Currently, with the initramfs, I get errors about / and /usr not being able to umount during shutdown. -- Joost
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 19:03, Yohan Pereira wrote: On 19/08/13 at 09:36pm, William Kenworthy wrote: So why not a profile so those guys who want to play can get a configuration that better suits them? - and vice versa if the whole systemd push dies and Redhat drops it as I doubt anyone else big enough will pick it up (they have a foot in both camps at the moment). Smaller distros that jump entirely systemd will be in trouble until they move back. Not a systemd supporter in any way but I don't think making a profile makes sense because we already have profiles for kde, gnome, desktop etc. Users will probably want to use systemd in-conjunction with any one of those, so we would need to have kde-systemd, gnome-systemd .. which is absurd. At least I don't see a sane way to achieve it from my rudimentary understanding of profiles. The only way it could be done is to have additive profiles, i.e. a collection of possible profiles such as gnome, kde, openrc, systemd - pick all that apply. This very rapidly cascades into a total nightmare when one profile say to include thing X and another says to exclude thing X. There's no sane default handling for that, one has to install local policy that applies a precedence rule. USE=systemd is far better (ignoring for the moment the difficulties in actually switching the service manager over) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
Alan McKinnon alan.mckin...@gmail.com wrote: On 19/08/2013 14:13, pk wrote: sysvinit, like X11, needs a massive overhaul and a sprint clean. Yes, an overhaul is always welcome. But most people criticising these systems (and other systems) just say that they are bad without pointing out what is bad. How can you fix something without knowing what's bad? To me the problem with sysvinit (and X11) seems mostly to be a philosophical one. Some people say: this doesn't work the way I want it to - therefore it's crap!. While others (like me) say: I have no problem with this - it works fine!. I find sysvinit to be unwieldy and clunky. Perhaps not so much the code itself, but surely the interface it presents to me the sysadmin. All that rc.[0-6] nonsense - what's that all about? In all my days I have never seen a computer running *nix that wasn't fully satisfied with two exclusive running states: - normal operation (whether console, headless, X) - maintenance mode (busybox on console). So why do I have 6 of them? The runlevels themselves are fixed and rigid. I want them somewhat more flexible, I actually don't want a bluetooth daemon *running*all*the*time* - really, it should only start when I enable bluetooth. This may not be the best analogy but you get the point, the OS needs to react to changes in the environment and sometimes those reactions are best dealt with by the service manager. OpenRC to my mind made huge strides in dragging this into modern times by making runlevels declarative. It all make so much sense in Gentoo. As for the bulk of the code, I don't have issue with that. PID=1 does what it needs to do. I suppose I can sum up the changed environment in one word: hotplug X11, well that's another story and probably way off topic. It was designed for hardware and architectures that haven't existed for 20+ years. Almost all factors that made X11 awesome in the 80s and 90s simply are not there anymore. X11 was still really awesome in 2002. When we used remote graphical logons to different machines. It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;) But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that? -- Joost -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 16:20, Alecks Gates wrote: Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Precisely. It's not hard, it's actually almost automatable. It's vastly simpler than configuring a kernel, something we all seem to take in our stride and wear as badges of honour. It's arguably even easier than figuring grub out the first time through. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 22:32, jo...@antarean.org wrote: X11, well that's another story and probably way off topic. It was designed for hardware and architectures that haven't existed for 20+ years. Almost all factors that made X11 awesome in the 80s and 90s simply are not there anymore. X11 was still really awesome in 2002. When we used remote graphical logons to different machines. It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;) But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that? Agreed. I've gotten so used to all that local *GL* goodness that running almost any app (except maybe xterm) remotely is just so painful it makes me cry... I'm also lucky in that when I managed to foist all the oracle with java installers off onto some other team of luckless suckers, I was left with just the best remote interface ever - ssh and bash. So I can afford to be smug :-) I don't know how to make your RDP problem easier - I treat that the same as allow/deny rules for ssh (or any other kind of access really) and just accept that sometimes I need to ask first for something to be allowed. again, I can afford to be smug here too as the only things I need to RDP to are terminals set up for that very purpose and VirtualBox VMs (that is one more check box at the create stage). -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 18:39, Tanstaafl wrote: On 2013-08-19 9:36 AM, Alan McKinnon alan.mckin...@gmail.com wrote: For me, I'm not opposed to merging /usr. I'm not opposed to other people using systemd, I am opposed to*me* using it. Agreed, and that is precisely the concern here... For your other question, you don't need an initramfs if your /usr is not split off and drivers for your fs on / and chipset are compiled in. That will stay true for ages to come (until some joker starts shipping kernel drivers in /var) Right, but that wasn't my question, my question was will I be able to continue using eudev (or mdev, or whatever)... Surely that depends on how well-maintained eudev remains in the future? And is therefore best answered by the package maintainers? Like I said a little earlier, I really think your best bet is a udev fork (even if it's eudev) maintained with the same effort input as udev was before all this stuff started coming down the pipes. what I do know is that eudev is already lagging behind udev, most likely a symptom of limited time available from the maintainer. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 16:33, pk wrote: Using an initramfs means you duplicate parts of your OS and copy them into the kernel or using a tool (like dracut or genkernel). If you need it from a technical point of view (bluetooth keyboard), that's fine but if I don't have any hardware that requires it then why use an initramfs? I guess it's a matter of taste (or philosophy if you will)... An initramfs seems like bandaid to me (and it is). I snipped most of the thread as I don't want to revisit yet again and old horse that is much flogged already :-) We're not too different, you and I, if I may dare say it when we differ it's you tend a little more towards idealism and I towards realism. Yes, bluetooth sucks, but it was designed by what was available at the time and it's what we have. For that matter USB, spinning disks and lack of fibre into my house also suck, but we have to work with what we have and what we certainly will have soon. Same with initramfs. Does it suck? Of course it does, it just sucks less than any other realistic proposal I've ever seen. And tricky bootstrap problems are tricky - always have been since the 50s and always will be. Which brings me to what I am really trying to say - giving specific examples to highlight general problems is always a nasty road to navigate. Like bluetooth keyboards, there's always a non-trivial number who can claim that the example does not apply to *them*. One can go round and round in circles with that, and skirt the actual issue: Software exists in the context of something bigger and for us that often means maximally useful for the maximum number of folks inclined to use such a package and that sweet spot includes compromises; some things just have to be laid in stone so that everything else works at all - sometimes we just have to accept that. Let's look at /usr by comparing it to /opt. I like /opt - all the crap from Oracle, IBM, Sybase and Sun my managers shove on me goes in there where I can at least corral it. I can agree with that setup. I can even agree with a system vs userspace split ala / vs /usr, although the distinction is very murky indeed, but do I really need it? Yes, it can be useful and even if I make a case for it, does it really need to be it's own partition? I'm carefully dodging around the niche market for terminal servers and /usr mounted over NFS here. I respectfully submit that we could also solve that one using full PXE boot, automount and unionfs or brethren. Like I said earlier, software exists in the context of something bigger, and Gentoo exists in the context of the FOSS community. We consume much more code than we produce and sometimes we have to back down and go with what the world is doing or be prepared to fork. Incidentally, I don't see that anyone has ever proposed the obvious sword to cut this knot - have the kernel automount /usr. it already does / and we have root= ... it wouldn't be hard to add /usr= ... Yes, I know I'm being stupid and Linus would reply with two words, the first starting with an f. He'd tell us to solve it the right way even if that's the hard way. I believe separate /usr without initramfs is rapidly becoming white elephant material, and we are faced with a decision to do it the hard way. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/13 22:20, Alecks Gates wrote: On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl tansta...@libertytrek.org wrote: ... Can someone please explain to me what's so hard and/or complicated about making an initramfs? At this point in time it's extremely simple for me, but I only manage relatively simple systems (although I'd like that to change soon). All I do is add one extra line (for example - dracut -H --kver=3.11.0-rc6) to my kernel install procedure. Granted, the only reason I have an initramfs is for the plymouth splash screen (other systems aren't desktops) -- but from everything I can see it's not too complicated otherwise. Ive had one employment threatening episode when a redhat system using initramfs wouldnt boot (my fault in fact, I got out of sync with initramfs/kernel version on the install) and it was an important server. Since then I eliminated them and surprise never had a failure until recently when I started using genkernel. So now I have mostly systems using initramfs, 3 customised, one of which will no longer hibernate to disk and I am suspecting the initrd. Its fine when it all works, but the question in this case is how many times do I want to crash the system trying to fault-find it? Its not that it doesn't work, or that its generally reliable but that its an unwanted/unneeded extra point of failure built around an extra workload. Distros like Redhat have specialists that do that, we dont and we are NOT competing in Redhats market space so why? I actually think working towards a read-only /usr is a good idea and am ambivalent about it being in the root, its the baggage thats being worked in alongside this thats the problem for me. BillK
[gentoo-user] OT: installing Gentoo on a 2007 Macbook
Hi all, For the duration of my MSc thesis (and for my job) I have lent a laptop from my university. This laptop happens to be a 2007 model Macbook (plus a new SSD, since somebody else has the original drive because his data is still on there), and chances are slim that I will be able to lend a different one for this long a time period (6+ months), since the laptops are mainly there for conferences and such. So I suspect I need to get *this* laptop to work. Now since I am productive with it, I wanted to install Gentoo on it but have thus far failed. So here are my overall goals: - install Gentoo - ideally ditch OS X - boot using EFI instead of in BIOS compatibility mode (e.g., I read that this is a requirement for getting suspend to work) So far, I have followed almost all steps of the installation guide (right before restarting the system), supplemented with Macbook-specific steps I found spread around the internet (see below), which boils down to setting up a GPT partitioned disk with an ESP (EFI System Partition) and setting up GRUB2. The problem seems to be to get the laptops firmware to find the ESP on the SSD. Note that I did this *without* a prior OS X installation. I tried blessing the bootloader with an Apple USB stick (10.4) I also got from the university, but that doesn't do anything (i.e., the installation doesn't show up in the boot menu). Using efibootmgr also does not seem to work. I also tried formatting the ESP as HFS+ instead of FAT32 (it turns out parted can do that). After a lack of results, the Apple Disk Utility then reformatted back to FAT32, so I guess that wasn't the problem :) . Now I decided to try installing OS X and see if I can get it to work with rEFInd, the fork of rEFIt (I set up some free space at the end of the SSD and formated it as HFS+ from the OS X installation disk), but the installation of OS X (10.7) is failing somewhat randomly. Sometimes it doesn't find the SSD, sometimes it hangs during the installation (the progress bar stops and activity from the DVD drive ceases). The farthest I got so far is to the end of the installation, right before it should reboot, but then the ETA starts going negative. *sigh* My search results on Google show that a lot of people just waited it out and that it eventually finished installing (after it got to -20 minutes or -2 hours) , but I just waited at least 10 hours in total. It then hung up after I tried to reboot after it reported -12 hours :( . Before installing Gentoo I also tried installing OS X 10.4 from the aforementioned USB disk, but the installation hung up after the reboot and now every time I boot from it it gives me an installation failed message, followed by the ever so helpful hint of try restarting the installation, which can't work, because quitting the installer reboots the system. So... that's a lot of semi-coherent narrative to take in, sorry :) . Right now I'm thinking that this really *should* work, I mean, the firmware finds the System Rescue CD, which boots perfectly fine in EFI mode, so why shouldn't my installation? Also, if anybody has any tips on getting this to work without an intermediate layer like rEFInd, please speak up! So now the links I took my steps from: - This series of blog posts: http://juliansimioni.com/blog/2012/03/14/installing-gentoo-on-a-macbook-pro/ - http://forums.gentoo.org/viewtopic-p-6988228.html (referenced above), without step 2 because SysRescueCD boots in EFI mode - I tried the grub2-install line from https://wiki.gentoo.org/wiki/GRUB2#UEFI.2FGPT - https://wiki.archlinux.org/index.php/MacBook#Arch_Linux_only tells me that I most likely can in fact ditch OS X. - https://wiki.archlinux.org/index.php/MacBook#Booting_directly_from_GRUB shows that I probably do need to install OS X first and have it set up an EFI System Partition for me in order boot directly to GRUB2, and not just if I want to install rEFInd. - I tried the grub2-install steps from https://plus.google.com/105450642479356031129/posts/F87vrsMtxz4, but they didn't work either - I also tried the steps for setting up the ESP here: http://glandium.org/blog/?p=2830 - I tried installing rEFInd in the fassion explained here: https://astrofloyd.wordpress.com/2008/11/01/installing-gentoo-linux-on-an-apple-macbook/#Installing_a_Bootloader Well, hmm, after going through my sources I found a bit of information on the Arch Linux wiki (see my sources below) that says that I need an EFI system partition set up by the OS X installer in order to be able to boot into GRUB2 directly. If that is correct, then what I need to do is get the OS X installation working. I also want to apologise for the... complexity and perhaps lack of coherence of this email but I'm sort of pressed for time (wasting time on the laptop instead of working) and thought maybe somebody might have a reply while I'm sleeping ;) (it's past midnight here). Greetings -- Marc Joliet -- People who think they know
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, 19 Aug 2013 17:30:16 +0300, Alon Bar-Lev wrote: The files within the initramfs generation tool are compiled using different tool than portage, they are not updated when distribution is updated, and they are not even at same version within portage tree. It may be acceptable for you... but do not expect everyone will accept your setup. That's a limitation of dracut, not of the initramfs per se. -- Neil Bothwick What I need is a list of specific unknown problems we will encounter. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, 19 Aug 2013 17:11:46 +0100, thegeezer wrote: i almost would like to request tighter integration between portage/kernel building/initrd The kernel build system can also build the initramfs if you give it the location of the config file. That way the initramfs is built for each kernel, using the currently installed versions of the various tools. -- Neil Bothwick This virus requires Microsoft Windows XP signature.asc Description: PGP signature
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote: I'm also lucky in that when I managed to foist all the oracle with java installers off onto some other team of luckless suckers, I was left with just the best remote interface ever - ssh and bash. So I can afford to be smug :-) Those of us running ssh and zsh can easily out-smug you :) And those adding screen/tmux into the mix can become truly unbearable... -- Neil Bothwick I am Flatulus of Borg. You will be asphixiated. signature.asc Description: PGP signature
Re: [gentoo-user] OT: installing Gentoo on a 2007 Macbook
I used Linux on a couple of different MacBooks. Usually I had the best experience not using rEFInd as an intermediate layer, but as the EFI boot loader loading the kernel file directly. My setup is based on the ArchLinux Wiki article about it. Every time you update your kernel, you just need to copy the vmlinuz to your EFI partition in the right folder. http://wiki.gentoo.org/wiki/EFI_stub_kernel https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd When using EFI mode, I had a couple of problems, which I haven't had in BIOS mode. Depending on your model, it might not be possible to use brightness settings of your graphics card or using the integrated graphics card (if your model has a discrete one) anymore. Another hint for Linux on MBP: For Wifi, you should use the broadcom-sta Version 6.x which is still masked in portage. Older versions had a lot of latency, performance and disconnect issues on my systems. -- Marc Aurel Kastner Computer Science graduate student http://www.marc-kastner.com
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
J. Roeleveld wrote: On Mon, August 19, 2013 12:55, Neil Bothwick wrote: On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote: Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] How much of that is needed before the contents of /etc/fstab are mounted? I certainly don't need to run a desktop, used a 3G modem, play sounds or load a virtual machine before then. Yes, LVM may be needed, but the needed parts are in /sbin anyway, so that is a red herring too. It is a red herring. I currently use an initramfs, but that is because I decided to put / on LVM as well. When I had / as a normal partition and /usr on LVM, there were no issues with booting. Currently, with the initramfs, I get errors about / and /usr not being able to umount during shutdown. -- Joost I to have / on a traditional partition, ext4, and /boot on a small ext2 partition. Everything else is on LVM. I don't want a init thingy either. I had nightmares with that thing when I used Mandrake years ago. I can't recall the name of that thing that left me with no keyboard/mouse but I still remember that init thingy. Dang, what was that thing that did that? Anyway, as bad a taste as that other thing left, the init thingy is even worse. I still remember the init thingy 10 YEARS later. The other thing was a few years ago. I bet Alan remembers. I was plenty pissed. That is likely the most pissed I ever been on this list. If that guy had been in front of me, I'd be in jail. I got to many trees around here. O-o Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, Aug 19, 2013 at 3:53 PM, Daniel Campbell li...@sporkbox.us wrote: On 08/19/2013 12:52 AM, Mark David Dumlao wrote: On Mon, Aug 19, 2013 at 5:54 AM, pk pete...@coolmail.se wrote: On 2013-08-18 23:08, Mick wrote: I honestly cannot understand why we/Gentoo are allowing the RHL monolithic development philosophy to break what we have. Is Poettering the only developer available to the Linux world? Are RHL dictating what path Debian and its cousin distros should follow? Problem is that Linux is dependent on udev and udev is in the hands of Kay Sievers which also develops systemd together with Lennart Poettering which in turn used to be a Gnome developer... With that said, what I cannot understand is why people advocating systemd (and the kitchen-and-sink model) are using Gentoo in the first place. Are they just trying to make the rest of the Linux distro landscape as miserable as Fedora? Why don't they stay with Fedora instead of trying to turn Gentoo into Fedora? This kind of response has been repeatedly grating on my nerves on this mailing list. It's just so TECHNICALLY WRONG, but more than that I feel that it hints at a deeper problem about user attitudes and the need to act like a know-it-all that is so prevalent on this mailing list. Systemd is _not_ a monolithic design. I don't know how anyone who has taken even a casual glance at it, or its documentation, can say otherwise. It's so reminiscent of qmail or postfix, where you have a bunch of small programs each doing one thing well, but for init systems rather than for mail, that it's just one step away from being the kind of program you show to kids to teach them how to Unix. It's not monolithic? Okay, then why won't logind work separately after systemd-206? Here's the release notes for 205: * logind has been updated to make use of scope and slice units for managing user sessions. As a user logs in he will get his own private slice unit, to which all sessions are added as scope units. We also added support for automatically adding an instance of user@.service for the user into the slice. Effectively logind will no longer create cgroup hierarchies on its own now, it will defer entirely to PID 1 for this by means of scope, service and slice units. Since user sessions this way become entities managed by PID 1 the output of systemctl is now a lot more comprehensive. That's why. Logind used to have more scope than it used to, now it defers some of its functionality to other programs so that it could do it's one thing well. That's the very definition of not monolithic. Why can't you make it work separately after 205? Because 205 is a MAJOR VERSION BUMP on an actively developed program. Nobody's yet written a program that fills the functionality that logind depends on. Better evidence is that it could work outside of systemd in the first place. You don't expect public APIs to remain stable past major version bumps. So there, once again a long, long pompous rant of acting like a know-it-all about stuff you've never bothered reading. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
[gentoo-user] python-3.1.5-r1
During upgrade a got a message: !! The following installed packages are masked: - dev-lang/python-3.1.5-r1::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Michał Górny mgo...@gentoo.org (07 Aug 2013) # These outdated versions of Python are no longer updated or maintained # properly. Python 2.5 started to become a blocker for Python 3.3. # Python 3.1 has proved to become unfriendly to writing portable code. # PyPy is still experimental and we're in process of bringing 2.1. # The remaining packages are backports of functions that targeted only # the very specific version. The masked packages will be removed # in 30 days. Afterwards, ebuild and eclass support for those # implementations will be removed. Bug #480070. My default is set to: python2.7 * Should I remove manually python-3.1.5-r1 -- Joseph
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
Dale rdalek1...@gmail.com wrote: J. Roeleveld wrote: On Mon, August 19, 2013 12:55, Neil Bothwick wrote: On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote: Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. [1] How much of that is needed before the contents of /etc/fstab are mounted? I certainly don't need to run a desktop, used a 3G modem, play sounds or load a virtual machine before then. Yes, LVM may be needed, but the needed parts are in /sbin anyway, so that is a red herring too. It is a red herring. I currently use an initramfs, but that is because I decided to put / on LVM as well. When I had / as a normal partition and /usr on LVM, there were no issues with booting. Currently, with the initramfs, I get errors about / and /usr not being able to umount during shutdown. -- Joost I to have / on a traditional partition, ext4, and /boot on a small ext2 partition. Everything else is on LVM. I don't want a init thingy either. I had nightmares with that thing when I used Mandrake years ago. I can't recall the name of that thing that left me with no keyboard/mouse but I still remember that init thingy. Dang, what was that thing that did that? Anyway, as bad a taste as that other thing left, the init thingy is even worse. I still remember the init thingy 10 YEARS later. The other thing was a few years ago. I bet Alan remembers. I was plenty pissed. That is likely the most pissed I ever been on this list. If that guy had been in front of me, I'd be in jail. I got to many trees around here. O-o Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! I also still remember. Not going to mention it now. But will give a hint. What is the name of the computer that said: I'm sorry Dale, I can't let you do that.? -- Joost -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] python-3.1.5-r1
On Mon, Aug 19, 2013 at 08:55:35PM -0600, Joseph wrote During upgrade a got a message: !! The following installed packages are masked: - dev-lang/python-3.1.5-r1::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Micha?? Górny mgo...@gentoo.org (07 Aug 2013) # These outdated versions of Python are no longer updated or maintained # properly. Python 2.5 started to become a blocker for Python 3.3. # Python 3.1 has proved to become unfriendly to writing portable code. # PyPy is still experimental and we're in process of bringing 2.1. # The remaining packages are backports of functions that targeted only # the very specific version. The masked packages will be removed # in 30 days. Afterwards, ebuild and eclass support for those # implementations will be removed. Bug #480070. My default is set to: python2.7 * Should I remove manually python-3.1.5-r1 I suggest emerge --sync followed by a regular world update. My current python versions are 2.7.5 and 3.2.5-r1. The update should replace your 3.1.5-r1 with the current 3.2 version. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] python-3.1.5-r1
On 8/19/2013 21:55, Joseph wrote: During upgrade a got a message: !! The following installed packages are masked: - dev-lang/python-3.1.5-r1::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Michał Górny mgo...@gentoo.org (07 Aug 2013) # These outdated versions of Python are no longer updated or maintained # properly. Python 2.5 started to become a blocker for Python 3.3. # Python 3.1 has proved to become unfriendly to writing portable code. # PyPy is still experimental and we're in process of bringing 2.1. # The remaining packages are backports of functions that targeted only # the very specific version. The masked packages will be removed # in 30 days. Afterwards, ebuild and eclass support for those # implementations will be removed. Bug #480070. My default is set to: python2.7 * Should I remove manually python-3.1.5-r1 You'll want to check which version of Python provides the 3.x system as well. Just do `eselect python list --python3`. If python3.1 is shown with a *, you need to make sure Python 3.2 is installed (@world updates will take care of that, or emerge python:3.2). Then `eselect python set python3.2 --python3` and then `python-updater` hth -- ♫Dustin http://dustin.hatch.name/
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, August 19, 2013 23:24, Alan McKinnon wrote: On 19/08/2013 16:33, pk wrote: Using an initramfs means you duplicate parts of your OS and copy them into the kernel or using a tool (like dracut or genkernel). If you need it from a technical point of view (bluetooth keyboard), that's fine but if I don't have any hardware that requires it then why use an initramfs? I guess it's a matter of taste (or philosophy if you will)... An initramfs seems like bandaid to me (and it is). I snipped most of the thread as I don't want to revisit yet again and old horse that is much flogged already :-) We're not too different, you and I, if I may dare say it when we differ it's you tend a little more towards idealism and I towards realism. Yes, bluetooth sucks, but it was designed by what was available at the time and it's what we have. For that matter USB, spinning disks and lack of fibre into my house also suck, but we have to work with what we have and what we certainly will have soon. I could have had fibre into my house, but the rest of the neighbourhood didn't want to sign a petition to have it installed. The petition only stated the intent to subscribe. It didn't specify that signatories would be required to actually subscribe. And that is with quite a few IT-people in the area. But that is a different rant ;) Which brings me to what I am really trying to say - giving specific examples to highlight general problems is always a nasty road to navigate. Like bluetooth keyboards, there's always a non-trivial number who can claim that the example does not apply to *them*. One can go round and round in circles with that, and skirt the actual issue: What happened to wireless USB? Bluetooth is nice for mobile phones and in-car audio/handsfree systems. I also don't see the point of using it for keyboards. How would I enter the pincode to link the keyboard to the computer if the keyboard has not been linked yet? ;) Software exists in the context of something bigger and for us that often means maximally useful for the maximum number of folks inclined to use such a package and that sweet spot includes compromises; some things just have to be laid in stone so that everything else works at all - sometimes we just have to accept that. Let's look at /usr by comparing it to /opt. I like /opt - all the crap from Oracle, IBM, Sybase and Sun my managers shove on me goes in there where I can at least corral it. I can agree with that setup. You can scratch Sun from that list, it's Oracle now... They do have some interesting software, part of it pays for the bills. I agree with putting that in /opt, wouldn't want to mess up the base OS with that stuff. Some admins install that into /home/.../, btw. Like I said earlier, software exists in the context of something bigger, and Gentoo exists in the context of the FOSS community. We consume much more code than we produce and sometimes we have to back down and go with what the world is doing or be prepared to fork. Incidentally, I don't see that anyone has ever proposed the obvious sword to cut this knot - have the kernel automount /usr. it already does / and we have root= ... it wouldn't be hard to add /usr= ... Yes, I know I'm being stupid and Linus would reply with two words, the first starting with an f. He'd tell us to solve it the right way even if that's the hard way. I believe separate /usr without initramfs is rapidly becoming white elephant material, and we are faced with a decision to do it the hard way. If Linus would go for that, how long till there would be a /var, /home, /... in there? Maybe an fstab=/path/to/fstab would be a better option? And then make sure that file is on the root-partition? -- Joost
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Mon, August 19, 2013 22:51, Alan McKinnon wrote: On 19/08/2013 22:32, jo...@antarean.org wrote: X11, well that's another story and probably way off topic. It was designed for hardware and architectures that haven't existed for 20+ years. Almost all factors that made X11 awesome in the 80s and 90s simply are not there anymore. X11 was still really awesome in 2002. When we used remote graphical logons to different machines. It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;) But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that? Agreed. I've gotten so used to all that local *GL* goodness that running almost any app (except maybe xterm) remotely is just so painful it makes me cry... For remote access, I can live without all the special effects. I'm also lucky in that when I managed to foist all the oracle with java installers off onto some other team of luckless suckers, I was left with just the best remote interface ever - ssh and bash. So I can afford to be smug :-) ssh -Y host works really well for those. I always feel smug when others first need to figure out how to get a remote-X connection to the server because they use MS Windows. They often claim that a VNC-server is a valid pre-req... Take it from me, that is NOT a requirement to install the software. I don't know how to make your RDP problem easier - I treat that the same as allow/deny rules for ssh (or any other kind of access really) and just accept that sometimes I need to ask first for something to be allowed. again, I can afford to be smug here too as the only things I need to RDP to are terminals set up for that very purpose and VirtualBox VMs (that is one more check box at the create stage). For me the usage case is as follows: 1) I start to do something on my desktop at home 2) I go to the office or customer site 3) I need to continue/finish what I was doing (it's usually for a customer in that case) ... At this point, I can't continue. Unless I remembered to run a VNC server and used vnc to localhost for step 1. With a MS Windows desktop, it is usually (sometimes I get a clean desktop and still can't continue) possible. One option would be to be able to redirect an application to a different X-server and when that one dies/disconnects/... it will reconnect to the initial (my desktop) one. This is also not something I found yet either. For these activities, all the latest *GL* goodies are not necessary and I can easily live without them. Remote 3D gaming isn't something I want to do. -- Joost
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Tue, August 20, 2013 00:33, Neil Bothwick wrote: On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote: I'm also lucky in that when I managed to foist all the oracle with java installers off onto some other team of luckless suckers, I was left with just the best remote interface ever - ssh and bash. So I can afford to be smug :-) Those of us running ssh and zsh can easily out-smug you :) And those adding screen/tmux into the mix can become truly unbearable... When working remotely on a console, I always use screen. Been bitten too often by dodgy links that it is a sane safety feature. -- Joost
Re: [gentoo-user] Re: Advice needed regarding udisks
On 17/08/13 22:00, Grant wrote: This is actually a portage question. How can I install udisks-2 in a way that will fix this problem? I'm confused by how to handle the slotting behavior. I think the issue here is that we are not understanding what the problem is. It happens with an application in particular, or with a desktop environment? It happens when you try to umount the device, or when you disconnect it from the computer? Do you loose data in the camera, or when transferring photos to your computer? Or is only that you don't like the error reported? When trying to eject a USB camera in thunar in xfce4, the error appears and the device does not umount. Here is a command that also produces the error: [ ... ] Just saying you should be using `udisksctl` command instead of the now obsolete `udisks` command udisksctl command = new udisks 2 udisks command = old udisks 1
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On Tue, August 20, 2013 00:20, Neil Bothwick wrote: On Mon, 19 Aug 2013 17:11:46 +0100, thegeezer wrote: i almost would like to request tighter integration between portage/kernel building/initrd The kernel build system can also build the initramfs if you give it the location of the config file. That way the initramfs is built for each kernel, using the currently installed versions of the various tools. Yes, it's a little bit easier then manually adding a new initramfs. But as I update userspace more frequently then the kernel, that would still lead to a version discrepency. I need to always remember to rebuild the initramfs when a part of userspace that sits in the initramfs is updated. An automatic option there would be usefull. If it were included into the kernel, I would need to rebuild the kernel after every update. Just redoing the initramfs is less of a waste of CPU. -- Joost
