Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


its1louder last won the day on May 11 2015

its1louder had the most liked content!

About its1louder

  • Rank

Recent Profile Visitors

642 profile views
  1. Thank you Cardinal, You have confirmed what I guessed based on that notice on the generic page. You are saying that the only difference between the different subarches is the cpuflags, I wasn't sure if that was true or if there was something else beyond that. Like I thought atom was a more radically different CPU type from the pentium/core types. I guess I'm not sure what is meant to convey by the atom brand. In the end, I went ahead with generic gnome, because what I'm really trying to do is make my own personal binary metadistribution (including my overlay for some obscure stuff I need) and I wanted to be as general as possible and support whatever non-arm hardware I may have. But I understand now I should have chosen nehalem subarch (if I want to support a couple of old core2 minipcs I have in addition to the silvermont one). I may try to change the subarch profile and emerge -e the system at some point, but not now.
  2. I've got an embedded machine with a 4 core atom CPU (C2758 @ 2.40GHz) that I've run reliably with silvermont subarch. I've not been able to upgrade from 1.3 to 1.4 without significant dependency issues. I want to convert an old laptop ( Core i5-3317U CPU @ 1.70GHz) to a development machine so I don't have significant downtime on the atom PC. The idea is I'll keep this old hardware around just for being a compile machine for bleeding edge packages that I'll then distribute out as a stage 4 tarball to upgrade and then continue upkeep with qpkg. I originally meant to just go with generic subarch and use this old laptop to serve out to the atom machine as well as some other machines that I don't want to be down for long. but as I went to get the generic_64 stage 3 I read on the webpage how the generic64 was discouraged and you should really use a nehalem stage 3 since it is good for all post 2009 intel CPUs and most recent AMD cpus. Does this include atom processors? I'm assuming generic_64 is truly generic for all x86_64, atom core or whatever. I'm not sure this istrue for the nehalem stage despite what the subarch page implies. PS I know my compile machine is slower than my target machine and this seems perverse. But compile time is not a huge issue it's downtime on the target that is a problem. Also due to Covid, I can't get in to touch my target machine right now, I have to just use what I've got on hand. target cpuino: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 77 model name : Intel(R) Atom(TM) CPU C2758 @ 2.40GHz stepping : 8 microcode : 0x127 cpu MHz : 1200.000 cache size : 1024 KB physical id : 0 siblings : 8 core id : 7 cpu cores : 8 apicid : 14 initial apicid : 14 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb kaiser tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm arat bugs : cpu_meltdown spectre_v1 spectre_v2 bogomips : 4800.23 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: compiler cpuinfo: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz stepping : 9 microcode : 0x15 cpu MHz : 807.188 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 3392.34 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
  3. thanks for the tips. The last 5.x sysresc image is not too stale yet, but It is good to find a replacement now. I also found pentoo because I needed to steal a couple ebuilds from their overlay. Although it is a catalyst/gentoo based system I saw a symlink in the profiles list that was designed to point to either a *.gentoo or *.funtoo file, didn't investigate further.
  4. From Version 6, released Feb 2 2019, SysrescCD is based on Arch Linux. This doesn't necessarily mean we can't still use it as a liveCD or rescue cd in most cases, except I found a corner case where it doesn't work. I happen to run several systems with encrypted LVM as described here. I had the root volume on one system that needed an fsck journal repair. I tried to decrpyt it with the lastest sysresccd and found that the cryptsetup/lvm in the sysresccd 6.0.2 could not see my unencrypted volumes. I rebooted with the last gentoo based sysresccd, 5.3.2 from Nov 2018 and it worked no problem. It may be that the arch linux kernel doesn't include as many cipher options the older gentoo based kernel as my partition is encrypted with the twofish-xts-plain64 cipher. There are some other changes that may make sysresccd less desirable as the default install livecd. no longer fits on an actual CD making the name sort of anachronistic. I realize most people, myself included, put it on a 1-2GB usb stick instead, but it seems to needlessly foreclose on some older systems. no more 32 bit support. May not be a problem if funtoo is also dropping 32 bit support. now inits with systemd instead of openrc, not sure if that would matter once chrooted during install, but maybe. As time goes on the last gentoo based sysresccd is going to be pretty dated. Is there a way to engineer metro to build livecds or something?
  5. OK I am still getting the hang of kits and funtoo style profiles. But wherever basic targets are set for the system I'd rather not override these in make.conf (why I reset the RUBY_TARGETS variable on the commandline). so looking at # ego query v ruby dev-lang/ruby| slot| repo --------------+-----+------------------- 2.2.9| 2.2| ruby-kit/1.1-prime --------------+-----+------------------- 2.3.5| 2.3| ruby-kit/1.1-prime * 2.3.6| | ruby-kit/1.1-prime --------------+-----+------------------- 2.4.2| 2.4| ruby-kit/1.1-prime * 2.4.3| | ruby-kit/1.1-prime virtual/ruby| slot| repo --------------+-----+------------------- 1| 0| ruby-kit/1.1-prime and then https://github.com/funtoo/ruby-kit I decided to try the ruby 1.2 branch of ruby-kit. I added this to /etc/ego.conf: ruby-kit = 1.2-prime then (after ego sync to update the kit git branches) I get # emerge -vauDN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-editors/atom-bin-1.28.0_beta3::editors-kit [1.28.0_beta2::editors-kit] USE="-system-node" 134,818 KiB [ebuild U ] app-editors/vim-core-8.1.0036::editors-kit [8.1.0035::editors-kit] USE="acl nls -minimal" 13,333 KiB [ebuild U ] app-editors/vim-8.1.0036::editors-kit [8.1.0035::editors-kit] USE="X acl gpm nls python vim-pager -cscope -debug -lua -luajit -minimal -perl -racket -ruby (-selinux) -tcl" PYTHON_TARGETS="python2_7 python3_6 -python3_4 -python3_5" 0 KiB [ebuild U ] virtual/rubygems-14::ruby-kit [13::ruby-kit] RUBY_TARGETS="ruby23 ruby24 (-rbx) -ruby25%" 0 KiB [ebuild U ] dev-ruby/rake-12.3.0::ruby-kit [12.1.0::ruby-kit] USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 117 KiB [ebuild U ] dev-ruby/power_assert-1.1.1::ruby-kit [1.1.0::ruby-kit] USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 17 KiB [ebuild U ] dev-ruby/minitest-5.11.1:5::ruby-kit [5.10.3:5::ruby-kit] USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 78 KiB [ebuild R ] dev-ruby/net-telnet-0.1.1-r1:1::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 0 KiB [ebuild R ] dev-ruby/xmlrpc-0.3.0::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 0 KiB [ebuild R ] dev-ruby/kpeg-1.1.0:1::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 0 KiB [ebuild U ] dev-ruby/rubygems-2.7.4::ruby-kit [2.6.14::ruby-kit] USE="-server {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 887 KiB [ebuild U ] dev-ruby/test-unit-3.2.7:2::ruby-kit [3.2.6:2::ruby-kit] USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25% (-ruby22%)" 126 KiB [ebuild R ] dev-ruby/json-2.1.0:2::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 0 KiB [ebuild R ] dev-ruby/racc-1.4.14::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 0 KiB [ebuild U ] dev-ruby/rdoc-6.0.1::ruby-kit [5.1.0::ruby-kit] USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby25%" 681 KiB [ebuild U ] www-client/chromium-66.0.3359.181::net-kit [66.0.3359.170::net-kit] USE="cups hangouts kerberos (pic) proprietary-codecs pulseaudio suid system-ffmpeg -component-build -custom-cflags -gnome-keyring -jumbo-build (-neon) (-selinux) (-system-icu) (-system-libvpx) (-tcmalloc) -widevine" L10N="am ar bg bn ca cs da de el en-GB es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW" 0 KiB Total: 16 packages (11 upgrades, 5 reinstalls), Size of downloads: 150,056 KiB Would you like to merge these packages? [Yes/No] RUBY_TARGETS still wants 2.2 because emerge --info shows RUBY_TARGETS="ruby22 ruby23 ruby24" but the ebuilds in ruby-kit 1.2 seem to only have ruby 2.3, 2.4 and 2.5 masked, so it's not a problem. I prefer this to adding cruft to my make.conf, but your mileage may vary. I guess I'm just adding cruft to my /etc/ego.conf instead, but this link below may be relevant:
  6. yeah When I went to --depclean after @world it purged ruby 2.2, and I felt totally ok with only having two rubies. I suspect that what is going on is ruby 2.2 is in the process of being unsupported and it is taking time for that news to percolate through all the varies ruby library maintainers. In the short term the command line variable setting gets it done while leaving space for the ruby-kit or whatever is setting my RUBY_TARGETS to change in the near future.
  7. I had a similar problem this morning when I went to update @world. It seemed to complain that many many ruby libraries wanted racc and rdoc with ruby 2.2 targets, but couldn't have them. I couldn't get it to run without explicitly turning off ruby 2.2 support. I kind of felt like I could live with only two recent versions of ruby on my machine instead of 3, esp since I don't personally use ruby at all but clearly some dependency along the way does. So maybe some ebuilds upstream are phasing out ruby 2.2 support? prospero ~ # emerge -va racc rdoc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-ruby/racc-1.4.14::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24" 0 KiB [ebuild R ] dev-ruby/rdoc-5.1.0::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB Oops! Conflicts have been encountered: >>> dev-ruby/rdoc, wants rdoc >>> dev-lang/ruby-2.2.9:2.2/2.2::ruby-kit, installed, wants >=dev-ruby/rdoc-4.0.1[ruby_targets_ruby22] My candidates are: >>> dev-ruby/rdoc-5.1.0:0/0::ruby-kit, ebuild scheduled for merge has SLOT 0/0 but not IUSE ruby_targets_ruby22 >>> dev-ruby/rdoc-5.1.0:0/0::ruby-kit, installed has SLOT 0/0 and IUSE ruby_targets_ruby22 We hope this informational output has been useful in identifying the problem. We are continually working to reduce conflicts. Do not hesitate to report a bug at https://bugs.funtoo.org. Thank you! :) prospero ~ # RUBY_TARGETS="ruby23 ruby24" emerge -vauDN @system These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] virtual/rubygems-13::ruby-kit RUBY_TARGETS="ruby23 ruby24 (-rbx) (-ruby22%*)" 0 KiB [ebuild R ] dev-ruby/rake-12.1.0::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB [ebuild R ] dev-ruby/power_assert-1.1.0::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB [ebuild R ] dev-ruby/minitest-5.10.3:5::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB [ebuild R ] dev-ruby/json-2.1.0:2::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB [ebuild R ] dev-ruby/test-unit-3.2.6:2::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 -ruby22*" 0 KiB [ebuild R ] dev-ruby/rdoc-5.1.0::ruby-kit USE="-doc {-test}" RUBY_TARGETS="ruby23 ruby24 (-ruby22%*)" 0 KiB Total: 7 packages (7 reinstalls), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] this got me through my regular updates, but purged ruby 2.2 from my system, and I'm not noticing the loss yet.
  8. Works, thanks. As noted by palica, eix-sync works as well so that's nice. Is it a bug with epro that put the gentoo tag on the mix-ins? This is a new install on blank disk from stage 3. I did some of the mixin and installation stuff a little earlier than usual - normally would have booted into the system before installing x etc.
  9. here it is. I haven't edited it directly, but it was of course changed when I issued commands like epro mix-in +xfce so far I am still operating in the livecd chroot, haven't bootstrapped into the system yet. parent
  10. I'm doing my first funtoo install since all the big changes last summer. I'm trying to get up to speed chasing down all the right news and forum posts, but I am not clear on which tools that I've always used I should no longer use in favor of ego or epro. here is what I think I know: deprecated emerge --sync (use ego sync) eix-sync (use ego sync && eix-update) eselect profile (use epro) I'm not sure what to do if I want to use eix or equery. These are two tools I use alot when analyzing conflicts. Right now both seem to work, but they throw some warnings that make me think I am not running them right: equery: (chroot) sysresccd home # equery uses htop !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Parent 'gentoo:funtoo/1.0/linux-gnu/mix-ins/xfce' not found: '/etc/portage/make.profile/parent' [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-process/htop-2.0.2: U I - - openvz : Enable openvz support + + unicode : Add support for Unicode - - vserver : Enable vserver support eix (chroot) sysresccd home # eix htop warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/xfce of file /etc/portage/make.profile/parent warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/gfxcard-intel-glamor of file /etc/portage/make.profile/parent warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/mediadevice-video-pro of file /etc/portage/make.profile/parent warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/mediadevice-audio-pro of file /etc/portage/make.profile/parent warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/mediaformat-video-extra of file /etc/portage/make.profile/parent warning: ignoring parent gentoo:funtoo/1.0/linux-gnu/mix-ins/mediaformat-audio-extra of file /etc/portage/make.profile/parent [I] sys-process/htop Available versions: 1.0.3 (~)1.0.3-r1 (~)2.0.1 2.0.2{tbz2} {oom openvz unicode vserver KERNEL="FreeBSD linux"} Installed versions: 2.0.2{tbz2}(09:59:41 11/22/17)(unicode -openvz -vserver KERNEL="linux -FreeBSD") Homepage: http://hisham.hm/htop/ Description: interactive process viewer I have recently run ego sync and eix-update in that order. here is my profile set up (chroot) sysresccd home # epro === Enabled Profiles: === arch: x86-64bit build: current subarch: intel64-haswell flavor: desktop mix-ins: xfce mix-ins: gfxcard-intel-glamor mix-ins: mediadevice-video-pro mix-ins: mediadevice-audio-pro mix-ins: mediaformat-video-extra mix-ins: mediaformat-audio-extra === Python kit: === branch: 3.4-prime === All inherited flavor from desktop flavor: === workstation (from desktop flavor) core (from workstation flavor) minimal (from core flavor) === All inherited mix-ins from desktop flavor: === X (from workstation flavor) audio (from workstation flavor) dvd (from workstation flavor) media (from workstation flavor) mediadevice-audio-consumer (from media mix-in) mediadevice-base (from mediadevice-audio-consumer mix-in) mediadevice-video-consumer (from media mix-in) mediadevice-base (from mediadevice-video-consumer mix-in) mediaformat-audio-common (from media mix-in) mediaformat-gfx-common (from media mix-in) mediaformat-video-common (from media mix-in) console-extras (from workstation flavor) print (from desktop flavor) Just ignore the warnings since these tools seem to work otherwise? That seems not right.
  11. I ran into this clusterblock also. I also run a stable system but mixin some unstables w/keyword file when necessary, and I have a few of my own ebuilds in a personal overlay for more arcane scientific software. I don't agree that this is doing it wrong but to each his own. Anyway, I got around the block with reference to this gentoo thread, only slightly tweaked (incr xorg server from r4 to r5). # from https://forums.gentoo.org/viewtopic-p-7833004.html =x11-base/xorg-server-1.16.4-r5 ~amd64 =app-eselect/eselect-opengl-1.3.1-r4 ~amd64 =x11-proto/glproto-1.4.17-r1 ~amd64 =media-libs/mesa-10.3.7-r2 ~amd64 Anyway its emerging 7 of 52 updates right now, so at least it got past the blocker. This server runs a simple intel video chipset so no funny business with fancy driver blobs.
  12. Just did a eix-update and saw sys-boot/refind whiz by. So its in portage now. That's nice I guess, I've been downloading source manually and compiling it within root's home during the system bootstrapping.
  13. Actually I broke a rule, which is I changed two things at once and so I am not sure which fixed it. It might be the grub kernel command or it might be the udev rule I stuck in for usb devices to shut off autosuspend. Not sure which did it, and I am not sure why I only have this problem on my desktop and not my laptop. Off the top of my head, the laptop is running laptop_mode as an init process so maybe the autosuspending is better managed. Anyway its fixed so I am not going to investigate it further. But my original point to the post stands, which is that I am still not sure on the correct syntax for module loading with /etc/conf.d/modules in the case where arguments have a par=val structure rather than just a single argument/flag.
  14. Actually neither of these worked for me in the end I had to add usbcore.autosuspend=-1 to my grub launch line. Still it would be nice to know how to do it in /etc/conf.d/modules, and if this is even incorporated into the genkernel initramfs, perhaps not.
  15. The Documentation for /etc/conf.d/modules is a bit vague. On this page it says OK so at least one of the instances of the word "module" is not meant to be replaced with the name of the module. For example: I need to change usbcore kernel module to prevent my desktop's mouse from going to sleep every 2 seconds. I think what I need to do based on the linked page above is: BTW based on the comments on /etc/conf.d/modules itself I would have thought that it should be this: I am building initramfs files both ways just to be sure.
  • Create New...