Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 February 2013 Maxim Kammerer m...@dee.su wrote:
On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos pa...@gentoo.org wrote:
I agree as I have also needed to google and search in forums to get
proper firmware installed in the past in some machines :/
for fw in $(strings -a -n 10 $(find /lib/modules -name '*.ko') | sed
-n 's/^firmware=//p' | sort -u); do
if [ ! -e /lib/firmware/${fw} ]; then
echo ${fw}
fi
done
I guess you can do something similar with vmlinux.bin if compiling
modules into kernel.
Last I looked into that the list of firmwares needed by built-in drivers
is not available as is the case for modules (and in addition those
built-in drivers may need the firmware long before /lib/firmware/ is
available)
Bruno
Looking into kernel sources is more robust, but
gets annoying fast. Full script I am using is here:
https://github.com/mkdesu/liberte/blob/master/src/root/helpers/lst-firmwares
You can encounter superfluous warnings with modules that support
multiple firmware subversions (e.g., iwlwifi).
Re: [gentoo-dev] [Council] ChangeLog generation within Gentoo
On Wed, 26 October 2011 Fabian Groffen grob...@gentoo.org wrote: However, this also allows to do all kinds of other actions to the ChangeLog file, without actually adding an entry for the current change being committed, as we've already seen in practice. The Council would like to remind developers that it is still a requirement that all actions are documented in the ChangeLog and that it is hence the responsibility of the committing developer to make sure this requirement is met. Is there some guideline about old entries in the ChangeLog? Over the past months ChangeLogs represent a big part of the tree, some of them being pretty big and going back many changes (hundreds of them) and years (even for actively maintained ebuilds). In order to not bloat the tree I would like to see old entries purged when there are more than 25-50 of them, especially if they refer to ebuilds gone since more than 3-6 months. Someone in need for long gone ebuild would have to look at VCS anyhow, so looking at ChangeLog/history over there would seem logical. On a compressed tree (squashfs) dropping all ChangeLogs reduces size from ~55MiB to around 35MiB which is quite a lot! Bruno
Re: [gentoo-dev] [Council] ChangeLog generation within Gentoo
On Wed, 26 October 2011 Pacho Ramos pa...@gentoo.org wrote: El mié, 26-10-2011 a las 19:33 +0200, Bruno escribió: On Wed, 26 October 2011 Fabian Groffen grob...@gentoo.org wrote: However, this also allows to do all kinds of other actions to the ChangeLog file, without actually adding an entry for the current change being committed, as we've already seen in practice. The Council would like to remind developers that it is still a requirement that all actions are documented in the ChangeLog and that it is hence the responsibility of the committing developer to make sure this requirement is met. Is there some guideline about old entries in the ChangeLog? Over the past months ChangeLogs represent a big part of the tree, some of them being pretty big and going back many changes (hundreds of them) and years (even for actively maintained ebuilds). In order to not bloat the tree I would like to see old entries purged when there are more than 25-50 of them, especially if they refer to ebuilds gone since more than 3-6 months. Someone in need for long gone ebuild would have to look at VCS anyhow, so looking at ChangeLog/history over there would seem logical. On a compressed tree (squashfs) dropping all ChangeLogs reduces size from ~55MiB to around 35MiB which is quite a lot! Personally, I want to have full ChangeLog easily accessible, I remember to need to look for really old entries when becoming a new maintainer for an old package previously maintained by others. That seems fair, though I guess old ebuilds are needed as well in that case so the not-trimmed ChangeLog probably rather should be a feature of VCS GUI that would take all the changes to ChangeLog and assemble all the additions ignoring the removed lines, possibly connecting that to the history of the individual ebuilds. What I don't know is the reasons for not compressing ChangeLogs by default (well, I don't have a compressed tree, this probably won't be a gain for people using it) Compressing the ChangeLogs in the tree would not help rsync as the beginning of the file changes and thus the compressed binary result is all but a stream to which data got appended. Bruno
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On Tue, 14 June 2011 Brian Harring ferri...@gmail.com wrote: On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring ferri...@gmail.com wrote: The implicit system set dependency thing really, really needs to die; at the time of the rule, portage couldn't handle resolving graphs of that sort. ?PM resolvers for gentoo are generally a fair bit saner now thus doing what you're suggesting isn't really beneficial (frankly it causes some issues for stages, as zac noted). ++ It seems to me that the best policy would be for every package to just list all its dependencies, and then users are free to run the default experience that includes everything in @system, or a more trimmed-down experience. An annoying, but valid complaint agains this is that the deps start getting heavy to maintain for developers, and aren't always viable to represent. Unpackers for example, are a pain in the ass for current EAPIs- that could be reduced in pain via addition of basic implicit deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2). Or devs could just be nudged into adding the appropriate DEPEND. repoman checking for it either way wouldn't be hard. IMHO a big distinction between DEPEND and RDEPEND should be done. For RDEPEND all dependencies should be listed (including those packages provided by @system) This would allow easy installing into chroots with package manager's help, especially in combination with binary packages. For DEPEND it could be sufficient to assume @system is present or at least limit to those dependencies needed by the package/ebuild itself, but not those coming implicitly with features of package manager used (e.g. default unpacking, emake, einstall, do*) Eclasses extending package manager features should include their extra DEPEND needs. On the other hand, it would be nice if package manager could auto-detect at least part of the runtime dependencies (library linking should be easy as package manager already looks for them -- what's completely missing is shebang/interpreter dependencies). This way only version constraints would need to get added to RDEPEND inside ebuilds as needed (and the few cases where dlopen makes it impossible for package manager to see the linking). A nice benefit of this would be that it can adapt to changes caused by INSTALL_MASK, e.g. reduces dependencies that are not needed anymore because some files were not installed. Bruno
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, 30 August 2009 Matthias Schwarzott z...@gentoo.org wrote: The new udev-145 and newer have some new kernel requirements. How should the ebuild verify they are met? Some possible ways: 1. Check config under /usr/src/linux /usr/src/linux is not the best place to look at... Checks should rather be done on first kernel config found in following locations (checked in this order): - KBUILD_OUTPUT - KERNEL_DIR - /usr/src/linux, /proc/config.gz, /lib/modules/$(uname -r)/build/.config Maybe just use linux-info eclass for the checks 2. Check /proc/config.gz This should rather happen in init script, if possible do not check on every boot but only when a new kernel is used (e.g. when uname output changes) 3. Print message for user in pkg_postinst This makes sense in any case. Second point: udev-145 bundles a lot of new extras, but they can only be enabled/disabled all or nothing. These extras are: * udev-acl: Apply consolekit permissions to devices for users (audio, video, joysticks, scanner, cameras, ...) Is this bound to consolekit or does it rather fall under 'acl' use-flag? I guess this includes a kernel requirement (ACL support for tmpfs) * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops (brightness up, next song, www browser, or suspend) * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode * gudev: glib/gobject support for libudev Is gudev just a binding or is it more? If it's just a binding it may be nice to have it tied to a use-flag. This makes udev depend on these libs: libacl, libglib2, libusb, usbutils, pciutils, gperf Bruno
Re: [gentoo-dev] mount portage from squashfs
I'm doing more or less the same here for a few years already, works pretty well. I think others are as well. Doing the sync only on one system (and applying patches to the tree where needed) and then locally copying the image to systems. Big advantage I see is more efficient access to portage tree and less disk usage on all systems (even the master system except for the duration of the sync) On master system I do the following: dd if=/dev/zero of=/tmp/portage.img size=384m mkfs.ext2 /tmp/portage.img mkdir /tmp/portage mount /tmp/portage.img /tmp/portage -o loop cp -a /usr/portage/* /tmp/portage umount /usr/portage mount /tmp/portage /usr/portage --move emerge --sync (apply patches) mksquashfs /usr/portage /tmp/portage.sqsh $options umount /usr/portage rm -f /tmp/portage.img mv /tmp/portage.sqsh $target mount $target /usr/portage -o loop This is pretty quick (and ext2 image on tmpfs uses less memory at the end of the day than what would be needed for putting portage tree on tmpfs) After that I can fetch the sqsh image from any client system when I do updates over there (I even keep a few weeks worth of images on the master in case one would be needed) Only thing to take care of is mounting RW filesystem over /usr/portage/distfiles and /usr/portage/packages or adjusting make.conf so portage can download distfiles and if asked to same binpkgs. If there is some interest, I can share my script which does the whole process. Having tree snapshots that are currently available as tarballs also available as squashfs images would be nice, more or less same download size but easier to access (e.g. no need to unpack) Bruno On Wed, 12 August 2009 Francesco R viv...@gmail.com wrote: Proposal, create snapshots of portage as squashfs iso, to be used in place of /usr/portage directory. prior art: see #1 Already working here: one central server which keep the portage full tree and that after a sync create portage.sqsh a squashfs 4.0 iso. Advantages are mainly: - cleaner root directory (ext4: du -sh /usr/portage ~= 600M | find /g/portage | wc -l ~= 13) - faster `emerge --sync` with fast connections - faster `emerge -uDpvN world` - less cpu/disk load on the server (if not serving from memory) Disadvantages - need to mount portage, or to use autofs - need kernel = 2.6.30 - bigger rsync transfer size (?= 2x) #2 - bigger initial transfer size, lzma snapshot currently weight 30.8M, portage.sqsh 45M How it's done here: Currently on the dispatcher the following run after every emerge --sync: mksquashfs /usr/portage /srv/portage.sqsh \ -noappend -no-exports -no-recovery -force-uid 250 -force-gid 250 The clients run from cron the following: umount /g/portage 2/dev/null \ ; cp /srv/server/portage.sqsh /var/tmp/portage.sqsh \ mount /usr/portage /etc/fstab: /srv/server/portage.sqsh /usr/portage squashfs loop,ro,noauto 1 1 some real data: stats for a portage sync, one day Number of files: 136429 Number of files transferred: 326 Total file size: 180345216 bytes Total transferred file size: 1976658 bytes Literal data: 1976658 bytes Matched data: 0 bytes File list size: 3377038 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 47533 Total bytes received: 4120255 sent 47533 bytes received 4120255 bytes 124411.58 bytes/sec total size is 180345216 speedup is 43.27 stats for a portage.sqsh sync, one day Number of files: 1 Number of files transferred: 1 Total file size: 46985216 bytes Total transferred file size: 46985216 bytes Literal data: 8430976 bytes Matched data: 38554240 bytes File list size: 27 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 48096 Total bytes received: 8454837 sent 48096 bytes received 8454837 bytes 5668622.00 bytes/sec total size is 46985216 speedup is 5.53 #1 http://forums.gentoo.org/viewtopic-p-2218914.html http://www.mail-archive.com/gentoo-...@gentoo.org/msg05240.html #2 May be mitigated by mksquashfs '--sort' option, to be tested - francesco (vivo)
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On Tue, 05 August 2008 Ciaran McCreesh wrote: On Tue, 5 Aug 2008 10:51:09 +0200 Bruno Prémont wrote: Has any progress happened since March for adding support for FILE_CAPABILITIES? Well, Alon still hasn't backed up his claim that Portage supports capabilities... Fairly important to establish that before anything else... In case the package manager has trouble with attributes (or the target filesystem does not support them) a way to keep the system running would be to apply the capabilities during src_install and have the eclass check during pkg_postinst, eventually retrying and finally falling back to suid at that point. Even binpkg would be handled that way. For this to work the eclass would have to remember the list of files from src_install until pkg_postinst so that it can do all the work once again (with a single call from the ebuild). Bruno
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On Sun, 23 Mar 2008 Alon Bar-Lev wrote: Hello All, linux-2.6.24 supports file based capabilities via: CONFIG_SECURITY_FILE_CAPABILITIES This enables the use of filesystem attributes in order to store per executable capabilities list, more information at [1]. This enables improved security level for people who don't wish to move into SELinux or similar. I think a new global USE flags (or use current caps) may enable ebuilds to set correct capabilities on files. On my system at least: ping, ping6, tcpdump, wireshark, samba, ntpd, rlogin, vmware may enjoy this and drop the root suid. In order to make it simple for everybody, a new eclass may be introduced to force dependency on =libcap-2 and provide some atoms. This will provide more secured installation for users with a little effort, less usage of root user. What do you think? Alon. [1] http://www.friedhoff.org/fscaps.html Has any progress happened since March for adding support for FILE_CAPABILITIES? Bruno
Re: [gentoo-dev] packages.gentoo.org lives!
On Wednesday 14 November 2007 03:58:24 Robin H. Johnson wrote: After a LOT of development, Gentoo Infra is pleased to announce the return of the new packages.gentoo.org site. The new site is a complete rewrite. If you had bookmarks to the old style of URL, please consult the FAQ for the new form. We are NOT rewriting these URLs: '/packages/?category=media-sound;name=mp3unicode' (The new form is '/package/media-sound/mp3unicode'). The site is available at: http://packages.gentoo.org/ Please read the entire FAQ before asking any questions! http://packages.gentoo.org/faq/ Thanks to everybody that worked on this: - jokey, starting this version - cla, the visual template for this version - robbat2, way too much coding and infra wrangling Nice to see packages.g.o coming back! One item that's missing on TODO section on FAQ is page navigation. (there's just a mention of global count parameter to change count of entries per page) E.g when looking at categories only the first 'n' items are show and there is no mention on the total count. At a minimum it should display something like: showing packages 1-29 out of 127 on page bottom with note that page browsing still has to be implemented. As mentionned by Ryan the positionning of the logo is quite inappropriate. Would it be possible to set a min-width CSS tag on the left column that would match the width of the logo in order to prevent the unwanted overlapping? I assume it's quite common to have pretty small fonts in order to get more text visible without scrolling... Bruno -- [EMAIL PROTECTED] mailing list
[gentoo-dev] musicbrainz useflag, and a couple others
Hello list, I filed bug 165561 [1] to ask for the musicbrainz useflag to be made global, and in reply I was asked to have it discussed here, so here it goes. According to use.local.desc, the useflag is used in 4 different ebuilds for the same purpose : app-cdr/k3b, media-sound/amarok, media-sound/prokyon3 and media-sound/rhythmbox. Since I filed the bug, I also stumbled on the daap useflag which seems also a good candidate : media-sound/amarok:daap - Enable support for DAAP Music Sharing media-sound/banshee:daap - Build with Daap support media-sound/rhythmbox:daap - support for daap media-video/vlc:daap - Enables DAAP shares services discovery support. Same for real/realmedia (unless I'm confusing some stuff) : media-libs/win32codecs:real - Installs the real video codecs media-sound/amarok:real - Build with real/helix player support media-video/mplayer:real - Adds real video support net-www/mplayerplug-in:realmedia - Real Media Playback Support Cheers, Bruno [1] https://bugs.gentoo.org/show_bug.cgi?id=165561 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On Monday 06 November 2006 17:53, Roy Marples wrote: ... However, one issue is a concern. All baselayouts defined svcdir in /etc/conf.d/rc which defines where we hold the state information of the running services. This defaulted to /var/lib/init.d - which is bad as /var could be on a different partition. In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced to /lib/rcscripts/init.d which is safe as /lib is always on the same partition as /. The 1.13 ebuild will copy across existing state data, this is not the problem. However, downgrading back to 1.12 is a problem as services may have been stop, started etc in the middle. ... How is the case where the / partition always remains ro handled? Is rc-state information put into a tmpfs partition on that location, is the location configured differently for those? Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Saturday 29 July 2006 02:19, Alastair Tse wrote: On Fri, 2006-07-28 at 11:51 -0700, Donnie Berkholz wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. I have to say I agree with Donnie here on this. I've been using private ebuilds for certain things that are installed on my work systems that will never be applicable to anyone except for 4 people on this planet. Yet I use these because then I'm able to take this simple single file, plonk it into another Gentoo machine and recreate the same installation. Maybe it is just because making ebuilds is now just second nature to me. I, as a simple user, also have my overlay, with ebuilds for software I use (at work also company-internal software), some driver that's not in portage, and whatever I need. Big advantage of using ebuilds with portage over manually installing from tarballs is visible at update/uninstall time when old files should get deleted! Ebuild that fetch source from revision system (cvs, svn) are very useful too as recompiling is then as easy as typing emerge mysoftware. Ease of installation on second box comes on second position. Look at my overlay at the moment, half the stuff there have a less than 30% chance of ever making it into the main portage tree. But I still make those ebuilds in the off chance that either (a) I do decide to put them in, or (b) someone else might stumble across them and find it, and (c) there are just things that I cannot test because I don't have the hardware. Through proxy-dev I may contribute ebuild for a few packages and maintain them over the time period I have use for them. E.g. drivers as long as I have given hardware (in use). What would be useful is to have the option for a few users to maintain the same ebuild through one proxy-dev, this way when one user stops having usecase for the ebuild others can continue maintainership. Even maintaining while initial user lacks of time or is away would then not stop or fallback to the dev. Regards, Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Initng in vserver guests
On Saturday 14 January 2006 19:34, Mike Frysinger wrote: On Saturday 14 January 2006 10:26, Bruno wrote: What are your thoughts about this? take it upstream, they have a bugzilla make it a configure option and we'll add a use flag `use_enable vserver` or some such junk otherwise, the answer is no ;) -mike I've opened a bug for it upsteam (Bug #416) with an initial patch which allows detection of vserver profile and appropriate fine-tunig of init scripts. Will not need any special behavior on ebuild side (as distro is detected automatically; works also when building system in chroot) Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Saturday 26 November 2005 18:50, Ned Ludd wrote:
Good afternoon,
Would you be willing to give up space in $ROOT/usr/lib/debug for ELF
executables by default in order to aid in better debugging by or do we
want to only emit it when a FEATURE= is defined.
For me either way is good as long as it's well documented in the install
handbook.
A notice for all those upgrading would be fine as well..
Having a split debug pretty much obsoletes the need to add nostrip to
your features in order to get debug info.
Users wishing to not have debug info can simply add
INSTALL_MASK=/usr/lib/debug ${INSTALL_MASK} to make.conf or the
environment unless we make it FEATURE based.
FEATURE based is probably the best way of doing it...
What's the advantage of splitting out the debug info to some extra location
instead of leaving it in the original binary (maybe smaller foot-print in
memory while the debugging info is not used), and what tools are compatible
with this external debug info?
I'm in favor of it enabled per default but I'd like to know what you
think and why. (advantages of on/off by default etc..)
Having the debug info preserved by default makes it possible for the user to
get debug information which may be used for bug-reporting on program crashes,
but will probably just fill the disk of basic users who do have no interest
in reporting bugs or trying to get more information about the cause of bugs.
Bruno
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tuesday 22 November 2005 16:14, Chris Gianelloni wrote: Give me one example of something that you can do with a stage1 or stage2 tarball that you cannot with a stage3 tarball. It's useful if you have to change compiler or other tool-chain part right from the start (e.g. use 3.4.* on i386, where 3.3.* is default) on PentiumM in order to use -march=pentium-m. It's certainly possible to start with stage 3, but makes total process last longer (Much more to recompile) and is more error-prone. Example of this risk: When installing GCC3.4 one may forget to install old libstdc++ (it has to be unmasked, and depending on use-flags it me not yes be reauested by portage!) and have a missing linking dependency on libstdc++ in python (no more portage to recompile python!) once GCC3.3 is unmerged. For some server-setups it may also be useful to start from a very minimal base in order to avoid hidden dependencies caused by unconditionnal operations of configure which add unwanted dependencies (e.g. USE-flags disables dep, but configure script still uses it, be it directly or indirectly) Sure you can depclean afterwards to removed unneeded packages, but as a precaution a emerge -e world would need to be done (loss of time). It's fine to make stage1/stage2 non-recommended as they bring no advantage over stage3 for most desktop systems, but should stay available and documented for minority who has valid use of it. Bruno -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting Important Updates To Users
On Monday 31 October 2005 21:07, David Morgan wrote:
Why not log all the e{info,warn}s into a file, and then tell the user
about them at the end of the emerge (in the same way they are told about
changes in /etc)? Said file should then be safe to delete if desired.
Mailing this info instead (/as well?) could also be available as an
option (even if the user just wants to use something simple like nbsmtp
to send it to some email address, rather than having to run their
own mailserver).
I guess you could also go for something like freebsd's
/usr/ports/UPGRADING file, which users are supposed to read before
upgrading things, but I'm not sure if people would bother reading it.
Dave
There should also be einfo/ewarn BEFORE emerging (e.g. when calculating
dependencies = before confirmation for --ask, or at end for --pretend)
this way only relevant information for the current merge would be displayed.
That means that ebuilds should output warnings in a function like pkg_setup
but this one must be called at right moment (after deps are calculate, but
before unpacking the first package).
Optionally this method could return a few different return values depending on
the importance of the info.
0 = just a note
1 = important
2 = blocker (fail emerge if not pretend/ask)
Bruno
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Improved ebuild information
On Monday 10 October 2005 14:53, Chris Gianelloni wrote: Here's my question... use.local.desc is already package-specific, so why would we need yet *another* place to put package-specific definitions? Would it not be enough to have use.local.desc overlay on use.desc? If package foo uses global USE flag bar in a way different from the description in use.desc, then it should list the USE flag in use.local.desc with the correct description for that package. The additionnal info about USE flags should not be what is this or that USE flag used differently for, but rather what *exactly* does the use-flag influence. What exact features of the program are enabled/disabled/changed by the given USE flag. Some USE flags are used to either compile against a lib that's shipped with a package or with the system version of that lib. Would be useful to know. Then there are USE flags like static which are very unprecise. Do they mean that the program is 100% stand-alone (e.g. does not link against any lib) or does it have to do with *.a, *.la files being installed, or just reduce the count of libs linked against... In addition, providing the info in the package metadata is cleaner as information about a given package is in one place, and there is not one file with 1k lines with many USE flags and their use for each and every package. The aim is to allow to know what happens without reading the ebuild AND the configure script and makefiles of a package. Bruno -- gentoo-dev@gentoo.org mailing list
