Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
J. Roeleveld wrote: > I, as a user, prefer not to have to hunt for firmware for devices > supported vy the kernel. I would either install all of them or > filter out the firmwares for devices I am unlikely to get. I, as another user, prefer not to have a whole bunch of firmware installed if I only want one or two of them. //Peter
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Fri, Feb 8, 2013 at 11:53 AM, Samuli Suominen wrote: > Any objections if I slap a generic package.mask on every firmware package > installing to wrong directory? > Half of them install to /$(get_libdir)/firmware as opposed to correct > /lib/firmware. > Most of them are maintainer-needed@ and very old. > > Then intrested parties get to fix what they want and unmask? > > - Samuli > Whatever is correct and sticks should have a pkgmove added so that users don't have long lasting issues. -- Doug Goldstein
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 02/10/2013 03:45 PM, Andreas K. Huettel wrote: > Am Montag, 11. Februar 2013, 00:34:19 schrieb Michał Górny: > >>> >>> actually *do* to one's system? >> >> Out of curiosity, does portage suggest switching to the new profiles >> even if it doesn't support its EAPI? > > Unfortunately, it seems yes. (Feature request?) It's possible to include additional instructions in the deprecated file. All lines after the first one as upgrade instructions. For future portage versions, I've fixed it to behavior better: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=34d8c817080f34f1a0b44cf05b99beacfc0d6314 This fix updates the profile deprecation warning to look like this: !!! Your current profile is deprecated and not supported anymore. !!! Use eselect profile to update your profile. !!! Please upgrade to the following profile if possible: default/linux/x86/13.0/desktop !!! Unable to parse profile: '/usr/portage/profiles/default/linux/x86/13.0/desktop' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' * You must update portage before you can migrate to the above profile. * In order to update portage, run 'emerge --oneshot portage'. -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Sat, 09 Feb 2013 15:12:15 +0100 Luca Barbato wrote: > On 08/02/13 22:46, Alexis Ballier wrote: > > On Fri, 08 Feb 2013 22:41:04 +0100 > > Maciej Mrozowski wrote: > > > >> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: > >> > >>> Tomáš Chvátal wrote: > we as gentoo will provide both while preffered default will be > what major distros use. > >>> > >>> What kind of careless mainstream attitude is that? Really? > >> > >> Quite the opposite, decision to use implementation A over B was > >> taken with utmost care for user in mind. > > > > Not really. I was promised a discussion that hasn't happened yet. > > I'm available for discussion anytime, I got a little busy in the past > days and I will busy the next 3 days, but I should be available today > evening or now. Sorry, I was away this week end... > I stated already what I think about the whole discussion in a blog > post. I'm not fond of discussions via blog posts and do not think it is the right media. I wrote one only to make it clear the decision was not anything near a general consensus, when Tomás made it sound like it was. > To summarize it my take is quite simple, Libav leads the way regarding > the main API, This is only because libav people do not care at all about what FFmpeg defines, while FFmpeg seems to care more about its consumers and users by trying to provide a compatible ABI and API. Moreover, this is not true at all when it comes to the parts where supporting both forks is painful: libavfilter and audio resampling. It is pretty clear that the audio resampling wheel was reinvented on the libav part, with a different library name and in 95% of its use cases going from ffmpeg's audio resampling to libav's is mainly a matter of 'sed s/swr/avr/'. Some parts of libavfilter also appeared later in libav, sometimes with a slightly different API, making it really awful to support both forks in applications. (I'm still looking forward a patch for xbmc and upstreamed patches for mplayer btw) > it offers a more compact surface for attacks if you are > really concerned about security and usually it is a little more > compact If you mean that ffmpeg is libav + ffmpeg additions, then yes. However, if you are concerned by a more compact surface, then libav is not the right answer: you can very well disable selected codecs, (de)muxers, etc at build time. I even started to work on reflecting this into an ebuild some years ago before reaching the conclusion that it would be confusing for little to no gain. This can of course be done if there is some demand, but so far I have not seen any. It is funny to see how libav ignores completely ffmpeg even for bugfixes, I stumbled over this recently and it sounded familiar: http://git.libav.org/?p=libav.git;a=commitdiff;h=89f11f498b9c15bc71494a11a7ec560f4adf630d vs http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1af91978dbab35ba9fdede187577c00d643ae33b now, you can look at the dates, there's a one year lag in libav for reinventing the same bugfix. This is for a format almost nobody uses, but in any case I do not consider this attitude sane. > and a bit more tested over a wider range of architectures. If you are talking about fate, then I cannot comment. fate started before the split, so I assume the owners of said test machines took them within their respective fork. > I'm not for removing ffmpeg overnight since there are features that > might be of use and I'm not so hypocrite to value diversity only when > it is in favor of my interests. Nobody talked about removing anything :) > That said as long the two project are compatible having one or another > as default is just a matter of making our life easier. I fully agree there, but you should be careful with who you include in 'our'. In the case of a default then it is clearly 'the users'. Now, considering there are a couple (very few) of packages that do not compile with libav, do you consider having it as default a good idea? Those packages can very well be fixed, but if patches do not go upstream, this is not going to work in the long term. Also, the only reason why I have not pinned those packages to depend only on media-video/ffmpeg is because libav is not the default (not entirely true btw, see later), meaning those that use libav are those that are willing to help and know what they are doing. If people are to get libav by default and then hit compile failures to be told to use ffmpeg, then it is QA 101 that these packages should be depending on media-video/ffmpeg. [...] > Few large projects such as VLC and Gstreamer switched to Libav as > their default. ... and chrome, mplayer, xbmc use ffmpeg :=) also as I said in another email, I have yet to see a libav based vlc release. > Since Libav is the no-frills variant, notwithstanding the interesting > campaign of "we have more security11ein!" less stuff should break > since it is usually more tested and once we gather the samples > triggering a crash usually we
Re: [gentoo-dev] Re: On the good usage of subslots
On Sun, 10 Feb 2013 01:09:38 +1100 Michael Palimaka wrote: > On 9/02/2013 23:52, Alexis Ballier wrote: > > On Sat, 09 Feb 2013 23:38:35 +1100 > > Michael Palimaka wrote: > > > >> I even noticed some maintainers adding subslots dependencies on > >> libraries that do not yet define subslots. This too seems > >> reasonable, given that there would be no impact until the library > >> defines a (sensible) subslot in the future. > > > > By the way, this could also be discussed: I did not check, but as > > far as I understand it subslot is equal to slot if not defined. > > When said library defines a subslot, the subslot will change and > > thus triggers a (likely useless) rebuild of your package setting > > a := dep. > > > > Alexis. > > > > > > Yeah. This behaviour can be avoided by introducing the explicit > subslot only when the subslot would otherwise need bumping. I would not count on that as this would mean extra care has to be taken when adding a subslot. Alexis.
Re: [gentoo-dev] On the good usage of subslots
On Sat, 9 Feb 2013 20:21:56 +0100 Michał Górny wrote: > On Sat, 9 Feb 2013 09:15:03 -0300 > Alexis Ballier wrote: > > > I hope this will be trivial to most of you but after seeing bug > > #455900 and the vast majority of developers not even thinking twice > > before sedding their dep strings, I believe this needs some > > attention. > > As a note for those who get irritated with those webkit-gtk: > >--ignore-built-slot-operator-deps < y | n > > Ignore the slot/sub-slot := operator parts of > dependencies that have been recorded when packages where built. > This option is intended only for debugging purposes, and it only > affects built packages that specify slot/sub-slot := operator > dependencies which are supported beginning with EAPI 5. > > Sadly, there's probably no way to ignore them only for cases when they > are completely useless, leaving the meaningful uses alone. Well, if we have to advertise the usage of this option that basically disables subslot rebuilds, it only means we are doing something seriously wrong with subslots :=) Alexis.
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 07:18 PM, Maxim Kammerer wrote: > On Mon, Feb 11, 2013 at 1:52 AM, Rick "Zero_Chaos" Farina > wrote: >> I am marked maintainer of linux-firmware due to my desire to make sure >> wifi related things work. I have no desire at all to implement use >> expand for this, HOWEVER, I am willing to accept a patch for that if it >> comes out even close to sane. > > It is possible to start with something much simpler but still very > useful: savedconfig in rsync include format, for glob patterns > support. > Again, I don't have the time (or desire) to implement this at this time. If you have an idea which you think will be sane and an improvement then by all means, please submit it to me when you are ready. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGD6JAAoJEKXdFCfdEflKnJYQAKsW3Mqk9/ru47FekY6DEqYZ 3ebMgPSAe99Pqdm2XhDknlZnAxL5/yAdQnls5TWEFqAx7GynaJ3fwpHBtoOa0pp+ tVmS3a/J86McaNQfisMekFnY70fJBw8hT+w343UKIx51RLuQGPTiWK26dku4MnCc hkVjFQCzxPeayxXslWKblo8Fi3nD2XQxgejeXsXcEddli5WRXgVhO+GPea6KgeTW qnpj7x1dqEAqFWewx0Os843GK6hwmdWo3O0y9GcAjyyI8H9+age2A6qDaqevs2dK L7qBr13moyeENnVoJSDFr9KZ0y9u3dI/+8Ap8MUn8yI1hB92bRuH9CldN2rOgNir /a1zcDs4NNwzimZ1P8/NyD71mP9SJhQkKPdnDeMj+Ck6iUB9bpEqXERAhckmamzt 0O8udf88++5MiuFNW6ju3/VOpS+MV0rFXLztDgVOXoUvE/e2O6MgUnlo0+Mr9EHJ tribU2UlvkkLyfnw44pfkv1zuo/gFkImjlZTOGzfW5iBwdi47dXh7447CoKUHFs+ OWnCAy9c/461uAUD6rizgKXO9tYfxZPBKdEpmJJiBmUz07q86lylKvzCSC0eAcTh ZOjKS5nbxlqjzstEpcDBrFYrPamFzJHg1q3VeN0+WrA6bhZxXm0RMWpfr2L0aztc kS2EoEhpdBjDUj7RmMZk =pPeq -END PGP SIGNATURE-
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-02-10 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-02-10 23h59 UTC. Removals: x11-themes/oxygen-gtk3 2013-02-07 04:13:24 zx2c4 dev-python/wsgiref 2013-02-07 19:02:23 prometheanfire sys-apps/coldplug 2013-02-08 17:33:42 ssuominen sys-apps/hotplug2013-02-08 17:33:42 ssuominen sys-apps/hotplug-base 2013-02-08 17:33:43 ssuominen sys-apps/ezusb2131 2013-02-08 17:34:32 ssuominen media-sound/logitechmediaserver-bin 2013-02-10 07:57:13 pacho net-dialup/misdn2013-02-10 07:58:50 pacho net-dialup/misdnuser2013-02-10 07:59:17 pacho net-misc/asterisk-chan_misdn2013-02-10 07:59:48 pacho www-apache/mod_authn_pam2013-02-10 08:02:03 pacho net-dialup/ltmodem 2013-02-10 08:03:08 pacho www-apache/mod_spin 2013-02-10 08:04:54 pacho dev-dotnet/galago-sharp 2013-02-10 08:07:01 pacho sys-apps/galago-daemon 2013-02-10 08:07:20 pacho dev-libs/libgalago 2013-02-10 08:07:40 pacho www-apache/mod_transform2013-02-10 08:08:36 pacho dev-util/monodevelop-java 2013-02-10 08:14:53 pacho dev-util/monodevelop-python 2013-02-10 08:15:21 pacho dev-util/monodevelop-vala 2013-02-10 08:15:46 pacho app-admin/flexlm2013-02-10 08:16:19 pacho net-misc/cisco-vpnclient-3des 2013-02-10 08:16:58 pacho app-emulation/systemsim-cell2013-02-10 08:17:46 pacho sys-block/gcloop2013-02-10 08:19:18 pacho mail-client/claws-mail-geolocation 2013-02-10 08:27:18 pacho app-admin/profiler 2013-02-10 08:32:39 pacho app-admin/smolt 2013-02-10 08:36:04 pacho Additions: games-rpg/manaplus 2013-02-04 18:23:28 hasufell net-misc/socket 2013-02-04 21:09:13 pinkbyte dev-python/liblarch 2013-02-04 22:29:42 eva app-admin/clustershell 2013-02-05 14:10:48 hasufell dev-games/aseprite 2013-02-07 00:45:59 tomwij x11-themes/oxygen-gtk3 2013-02-07 02:59:03 zx2c4 kde-base/picmi 2013-02-07 04:57:04 alexxy kde-base/print-manager 2013-02-07 04:57:13 alexxy kde-base/nepomuk-widgets2013-02-07 04:57:14 alexxy sys-apps/flock 2013-02-07 15:18:01 aballier dev-ml/menhir 2013-02-07 20:36:44 aballier dev-ml/macaque 2013-02-07 20:43:32 aballier www-servers/meteor 2013-02-07 22:13:06 tomwij dev-util/trinity2013-02-07 22:51:32 radhermit net-irc/iroffer-dinoex 2013-02-08 11:44:38 pinkbyte dev-libs/UTF8Strings2013-02-08 14:35:16 tomwij net-wireless/dump1090 2013-02-08 17:23:51 xmw dev-perl/Devel-Hide 2013-02-09 12:55:28 tove dev-haskell/findbin 2013-02-09 18:54:42 slyfox sys-apps/lnxhc 2013-02-09 18:59:10 creffett dev-util/cdiff 2013-02-09 20:15:38 tomwij sci-geosciences/gpxpy 2013-02-09 22:24:25 xmw dev-python/rply 2013-02-10 06:51:59 patrick dev-perl/Test-LeakTrace 2013-02-10 07:32:41 tove dev-perl/Unicode-UTF8 2013-02-10 07:33:57 tove sys-apps/iotools2013-02-10 09:47:52 vapier app-crypt/ima-evm-utils 2013-02-10 10:23:44 swift sci-geosciences/cdat-lite 2013-02-10 20:19:08 hasufell sci-geosciences/harmonics-dwf-free 2013-02-10 20:28:41 hasufell sci-geosciences/libtcd 2013-02-10 20:45:55 hasufell sci-geosciences/congen 2013-02-10 20:55:36 hasufell sci-geosciences/xtide 2013-02-10 21:08:30 hasufell sci-geosciences/tcd-utils 2013-02-10 21:13:46 hasufell sci-geosciences/tappy 2013-02-10 22:13:59 hasufell sci-geos
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Mon, Feb 11, 2013 at 1:52 AM, Rick "Zero_Chaos" Farina wrote: > I am marked maintainer of linux-firmware due to my desire to make sure > wifi related things work. I have no desire at all to implement use > expand for this, HOWEVER, I am willing to accept a patch for that if it > comes out even close to sane. It is possible to start with something much simpler but still very useful: savedconfig in rsync include format, for glob patterns support. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Mon, Feb 11, 2013 at 1:12 AM, Douglas Freed wrote: > How does having additional firmware installed affect security at all? > Firmware is only loaded when specifically requested by a loaded driver that > needs to use it, and only if that driver is actually in use. That's like > saying a file that can only be written to by root, only normally read when > it's specifically needed, and if for some stupid reason is executed by an > unprivileged process will just result in a crash, affects security (hint: I > just described firmware). I can play captain obvious, too. Regardless, having to explicitly enable firmware based on need (e.g., after installing a wireless card) provides for more security. For instance, the user can opt to not enable the firmware and not use the card, if he doesn't trust manufacturer's software development process. If only the firmware that is actually used is installed, it is easier to go over it and review its security. Some firmware has multiple subversions, with the kernel being able to use any of them; some may be more trusted than others. Some firmware may be unnecessary for correct functioning of hardware, but is still loaded when available. All of these are valid reasons for not installing all possible firmware. Don't assume that your use case is identical to everyone else's. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 04:45 PM, Maxim Kammerer wrote: > On Sun, Feb 10, 2013 at 10:41 PM, Rick "Zero_Chaos" Farina > wrote: >> Honestly while I agree this could have been handled a little more >> carefully we all win by having ONE place for firmware. The firmware >> package is like 20MB, if you don't have that much free harddrive space >> then you can use the savedconfig option to tune for just your hardware > > It's ~45MB when extracted, but the issue is not just with space, since > on a "proper" Gentoo system firmware is about the only thing that's > not compiled from source (besides less significant stuff like fonts, > many of which can be optionally compiled anyway). Combined with > various less-than-free licenses, installing one huge blob of firmware > is problematic for many users, also from a security point of view. Licenses are licenses, we all feel the same about non-free things. I whole heartedly disagree about the firmware, having a firmware on your system doesn't affect security, sorry, it just doesn't. > >> Having 300 -firmware packages is silly. > > I agree, but think that the process can be more user-friendly than a > savedconfig — perhaps a variable as was suggested already. > I am marked maintainer of linux-firmware due to my desire to make sure wifi related things work. I have no desire at all to implement use expand for this, HOWEVER, I am willing to accept a patch for that if it comes out even close to sane. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGDKiAAoJEKXdFCfdEflKBYkQAItoT8QdhnP4V0Nu+BkUqozP fPzDQjPbIXh0JMuVJ56zmXZ5oeiClFdcysf7vZ2sLFl4d2UPsz5EC+5Bk9ryJvjg YrLRmT5cHuZYacW7hNTgfW7Z3gg9oqJU73dn6rUvu3dGUlN3w/Z9UGXeIj+yzmzR w65pD9DLcQ4kPN5ekOhhznaCLANW7cVVQ4FgNDPZwAGpeUd/+OMlltNFrCcF4p4Z /cleFDfZmw01iO86oXKkAoevD7M1Twa9aHqNwxb6xcdagmPSnXhD+TsIFAvZgsdU +5xHL3sD6v5GJHf17lZvkHQxzKFVBqMJmuBW4lx599RDh5QgHK/RMC9bti9+adAu JNEQfC6VBQ48azrhc8BF/5bqZ5E0Rghppr7SRpjM5no0FDeGLo6Um47WTAY15CWj e2xqDJw1S7tWfPjqzz0IEUGHNCHfhm3s+kEQ6uYOuMqRXlJREhZ44PjxLsHBSOQs e+WHj23LujoJ5XqmtTQlMwTa+hzSUR+a8tUmrEu15uwiZWV4wsyoLhdNEPE5cAU5 s4/E10eVmuN65Lz7hYFTBy+irA5r3ugP43m4TzegrkclroCPbSbf65GcDk32hlTO qpw3xjEdcXu+ltUJgaNFueC57N0fPaZBNdPuyQKa1pSxHgfJvl6GiO8EWFqtM66s t2rv7REVyIgt8zPYRb08 =9fk8 -END PGP SIGNATURE-
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 02/10/2013 03:34 PM, Michał Górny wrote: > On Sun, 10 Feb 2013 17:06:39 -0500 > James Cloos wrote: > >>> "AKH" == Andreas K Huettel writes: >> >> AKH> To be honest I did not really see the necessity since the "big red >> AKH> warning" exactly tells you what to do (and even which profile to >> AKH> pick, which would be more complicated in a news item). >> >> But it doesn't tell one why the change was made, what differences to >> expect once it is done. >> >> What does: >> >> diff -uNr profiles/default/linux/amd64/10.0/eapi >> profiles/default/linux/amd64/13.0/eapi >> --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 >> -0400 >> +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 >> -0500 >> @@ -1 +1 @@ >> -2 >> +5 >> >> actually *do* to one's system? > > Out of curiosity, does portage suggest switching to the new profiles > even if it doesn't support its EAPI? Yes, although it's possible to include additional instructions in the deprecated file, as you can see in the code here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=pym/portage/package/ebuild/deprecated_profile_check.py;h=2acf8e3c2e189eb76cfda2ad4743ce238fc81230;hb=HEAD It interprets all lines after the first one as upgrade instructions. -- Thanks, Zac
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Am Montag, 11. Februar 2013, 00:34:19 schrieb Michał Górny: > > > > actually *do* to one's system? > > Out of curiosity, does portage suggest switching to the new profiles > even if it doesn't support its EAPI? Unfortunately, it seems yes. (Feature request?) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On Sun, 10 Feb 2013 17:06:39 -0500 James Cloos wrote: > > "AKH" == Andreas K Huettel writes: > > AKH> To be honest I did not really see the necessity since the "big red > AKH> warning" exactly tells you what to do (and even which profile to > AKH> pick, which would be more complicated in a news item). > > But it doesn't tell one why the change was made, what differences to > expect once it is done. > > What does: > > diff -uNr profiles/default/linux/amd64/10.0/eapi > profiles/default/linux/amd64/13.0/eapi > --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 -0400 > +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 -0500 > @@ -1 +1 @@ > -2 > +5 > > actually *do* to one's system? Out of curiosity, does portage suggest switching to the new profiles even if it doesn't support its EAPI? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
> Combined with various less-than-free licenses, installing one huge blob of > firmware is problematic for many users, also from a security point of view. How does having additional firmware installed affect security at all? Firmware is only loaded when specifically requested by a loaded driver that needs to use it, and only if that driver is actually in use. That's like saying a file that can only be written to by root, only normally read when it's specifically needed, and if for some stupid reason is executed by an unprivileged process will just result in a crash, affects security (hint: I just described firmware). -Doug
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 1:06 PM, Bruno wrote: > On Sun, 10 February 2013 Maxim Kammerer wrote: >> On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos 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) Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. -A > > 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). >
[gentoo-dev] Re: News item
Since I just sent a why to post a news item note, that exactly covers things. Thanks! -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
> "AKH" == Andreas K Huettel writes: AKH> To be honest I did not really see the necessity since the "big red AKH> warning" exactly tells you what to do (and even which profile to AKH> pick, which would be more complicated in a news item). But it doesn't tell one why the change was made, what differences to expect once it is done. What does: diff -uNr profiles/default/linux/amd64/10.0/eapi profiles/default/linux/amd64/13.0/eapi --- profiles/default/linux/amd64/10.0/eapi 2009-08-17 14:54:00.0 -0400 +++ profiles/default/linux/amd64/13.0/eapi 2013-01-20 06:31:02.0 -0500 @@ -1 +1 @@ -2 +5 actually *do* to one's system? A useful news item would have explained what was changing, why it was done, and what to expect once one makes the change. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Sun, Feb 10, 2013 at 10:41 PM, Rick "Zero_Chaos" Farina wrote: > Honestly while I agree this could have been handled a little more > carefully we all win by having ONE place for firmware. The firmware > package is like 20MB, if you don't have that much free harddrive space > then you can use the savedconfig option to tune for just your hardware It's ~45MB when extracted, but the issue is not just with space, since on a "proper" Gentoo system firmware is about the only thing that's not compiled from source (besides less significant stuff like fonts, many of which can be optionally compiled anyway). Combined with various less-than-free licenses, installing one huge blob of firmware is problematic for many users, also from a security point of view. > Having 300 -firmware packages is silly. I agree, but think that the process can be more user-friendly than a savedconfig — perhaps a variable as was suggested already. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)
Am Sonntag, 10. Februar 2013, 16:02:55 schrieb Andreas K. Huettel: > Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:> > > > I suspect most people are interested in understanding what changed > > (since deprecation means that the new thing is better than the old > > one). Moreover, the news item is another way to assure them that > > everything is not as bad as the initial "red warning" might had made > > them think so and "keep calm and use Gentoo" ;-) > > OK, here's a news item (actually two, separate for server and non-server > profiles). Since it's a bit late now, I'll commit this or the improved > version after discussion here in 6h (21:00 UTC) unless there are severe > protests. > And pushed. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 February 2013 Maxim Kammerer wrote: > On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos 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: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 11:54 AM, Fabio Erculiani wrote: > On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman wrote: >> On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos 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 :/ >> >> +1 from me; I've had a few machines break on kernel upgrades because I >> didn't have the proper firmware installed (I guess older kernel >> sources came with the firmware?). > > This is another problem, namely dependency level problem. > I don't see how having kernel sources ebuilds providing /lib/firmware > would fix any of the listed issues without causing other "side > effects". > For starters, if kernel sources provide /lib/firmware, how do you deal > with file collisions? The number of collisions has been reduced drastically in the last ~year, I don't believe there are actually any left now. I think the kernel has almost entirely stopped shipping firmware. It may be time to make linux-firmware an RDEPEND of *-sources - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGAahAAoJEKXdFCfdEflKz2cP/2BbuvVsYgMUHGwuD8Xs5/Iw 70Q1QyXY4SIQGh5p/YZ0XX6Z1uzGGUAwAm2tWbsFUT6VFZWyb0p/Wl5Rf3Vtn9eO 4DXx4JoKPI12bFEbJuhCMe67e01A3h88j/lp0fE372MTDUcutl3FF+i34zz/DckU NGEVw9+IxPxxuohTT+llzPE+3gd1j1LOSL+msv5nFwcKn940iOujLpDvpiscGD68 HBb5lcyxuKcV5XBlG3oRZ8+rP1A0vW2qyMm4/IXHMEehro1N3JxMpYQq+NcUrGT8 tlAHYW4C6+Z7b8zr9kEUbuDVI1dx+AM/MXbd8bdfpSWjnrk9NCnV5Y9mTBaNJB61 kn+CEQIaGi3aNBOzVBfo02ZGONZh7c178uIa7+Lh0deyENdlptU/UdD8wNf1PCK4 MCxsLzuJ6zb0XzaxJaY5snoZ+r8pHPrMUZFv8F0ls3y4maiGQMc48MOy4mJ90hYd 52HF3tjM2H0q7KNasKgP/u4DKylRiAWEvCS7uLF/6mUA74Ph9OVac+BJeUQSVsKh 4606UogOgk03IlBmNiyj41t3auX/MfqGYa3kBdftmFHURMOx1GPL5wqibRdzQ1T6 G8ojPdKxARHowkC9oAYljO6kUoQFD/mBN53KhvoCcu83n1rfvJ2hNBlkais8jEw6 PT7FeADuNUixau15F5jm =rqzh -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 10:55 AM, Maxim Kammerer wrote: > On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen > wrote: >> # Some of these install to wrong directory, /lib64/firmware >> # as opposed to correct /lib/firmware >> # Some of these don't have maintainer >> # Some of these are replaced by the firmware from the >> # linux-firmware package: > >> net-wireless/b43-firmware >> net-wireless/b43legacy-firmware > > These are neither of the above. > > I also don't understand masking packages because the firmware is in > linux-firmware. Is this an official policy? Sometimes firmware > packages are slotted, and it's also easier to install a package than > list and update a changing set of firmware files in > /etc/portage/savedconfig/sys-kernel/linux-firmware (referring to > ar9271, rt2860, rt2870, i2400m). > > On the other hand, firmware is often very stable, so why mask a > package just because it has no maintainer? Who wins by having atmel, > or zd1201/zd1211 masked? There are no open bugs, so what's the point? > Honestly while I agree this could have been handled a little more carefully we all win by having ONE place for firmware. The firmware package is like 20MB, if you don't have that much free harddrive space then you can use the savedconfig option to tune for just your hardware but honestly this package is rather critical for any system that does wifi or video capture and a few other things. I don't want to have to hunt and find firmware packages, the ones that are seperate due to license issues (read: Broadcom) will stay seperate, the rest I'll be poking upstream about including in the firmware tree then killing. Having 300 -firmware packages is silly. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGAXwAAoJEKXdFCfdEflK+xgP/A0F+XHiZLXo5D6rqvavyocE cKJh/E3fSMB5QcqVhK/kWXhcjDiRz+5niMR30oMX05uwvbx6Fo8Kicne6XHw9fhv UHo5E/k5e6lwaPOeI2nr59XaQ7Pj8PbhL9xrGA+CF1Yx7tJ2DqvEzYzOsuHlZG+B /yrFFKQ2TGeftXpKVYY9iQH3pHCzOR5P40PURwW0onvx5Q2LunAVpOmUO520jL3h dGoPWhjxK8RxpCOp/KbzxR27SD8kSWjgROmXpoIG0cfmohk/wfSwHyqg+i3pYDu8 b9Fs0OeOMnu2AxVeBCWHGFITeDz/0XVxlBThbzPj2KTnyQXoWfOHvOmGY9RxhJwh Cye/vWepdzUa7Vsdj37JiGfaHh9F68UwT50OelR1HJYjJHvaMbZZAfvsbENWSzn4 +esRhFxEyF7bk70+n6RXAFTx/mMPCwoADSgIqqwy/Bv5R/Z0b3hWlF3GWVeR3nRc Kd6kqifjYf8uVoUPAe1G5k5J+lQyyEva0Y93ML20y3pR0Ya3kJRioYxY1i2UdfVx reB1R3t/5O62dEXcyHyJeNfKYUef3fTjz4ieNhbvvmn/VueklyNJL0wmGwLCwMJn 92uYVpU0hdQFPxNZc5rHavnB6MOl49y/68/rNEaRhUe5Y38DNKEE5zL94sMXF4pf f4wQkVOOpYFdvaTRLQRR =Pn47 -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
PR> # Pacho Ramos (10 Feb 2013) PR> # Fails with gcc-4.7, crashes (#301946, #312073), problems with PR> # boost (#319921), problems with python-2.7 (#338826), really old PR> # version in the tree, people should move to sci overlay one (#424659). PR> # Removal in a month. PR> sci-visualization/paraview Or, more responsibly, the version in the sci overlay should move to the main tree. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Alec Warner wrote: > >> Having nice mailinglist where users can contribute simple patches > >> would be briliant thing to use :-) > > > > That's still a waste of time compared to gerrit. You should look at > > it if you don't know it already. > > I'll take patchwork over gerrit, honestly ;) Did you use gerrit's ssh interface? //Peter
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani wrote: >> +1 from me; I've had a few machines break on kernel upgrades because I >> didn't have the proper firmware installed (I guess older kernel >> sources came with the firmware?). > > This is another problem, namely dependency level problem. > I don't see how having kernel sources ebuilds providing /lib/firmware > would fix any of the listed issues without causing other "side > effects". > For starters, if kernel sources provide /lib/firmware, how do you deal > with file collisions? I'm sorry, I have no clue about any of this; I was just signalling that I've run into problems twice now, where I: - had an old kernel working fine - upgraded it using the usual mechanism - then the network wouldn't come up on rebooting (bnx2 or tg3, not sure) - with an obscure error message that was really quite hard to connect to missing firmware, and - it turned out to work fine after installing linux-firmware. So it would be great to prevent other users from running into these kinds of trouble. Cheers, Dirkjan
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, Feb 10, 2013 at 7:48 AM, Peter Stuge wrote: > Tomáš Chvátal wrote: >> Having nice mailinglist where users can contribute simple patches >> would be briliant thing to use :-) > > That's still a waste of time compared to gerrit. You should look at > it if you don't know it already. I'll take patchwork over gerrit, honestly ;) -A > > > //Peter >
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman wrote: > On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos 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 :/ > > +1 from me; I've had a few machines break on kernel upgrades because I > didn't have the proper firmware installed (I guess older kernel > sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other "side effects". For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? > > Cheers, > > Dirkjan > -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 6:49 PM, Dirkjan Ochtman wrote: > (I guess older kernel sources came with the firmware?) See e.g. https://bugzilla.kernel.org/show_bug.cgi?id=42689#c5 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos 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 :/ +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). Cheers, Dirkjan
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 5:05 PM, Pacho Ramos 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. 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). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 03:10 AM, Samuli Suominen wrote: > # Samuli Suominen (10 Feb 2013) > # The firmware cleanup, part #1. Can be unmasked after > # cleaning up the package if it's still needed. > # Some of these install to wrong directory, /lib64/firmware > # as opposed to correct /lib/firmware > # Some of these don't have maintainer > # Some of these are replaced by the firmware from the > # linux-firmware package: > # emerge -av linux-firmware > # If you still have a reason to keep the package, please > # let us know by filing a bug report. > net-wireless/ar9271-firmware > net-wireless/atmel-firmware > net-wireless/b43-firmware > net-wireless/b43legacy-firmware > net-wireless/ipw2100-firmware > net-wireless/ipw2200-firmware > net-wireless/libertas-firmware > net-wireless/prism54-firmware > net-wireless/rt2860-firmware > net-wireless/rt2870-firmware > net-wireless/rt61-firmware > net-wireless/rt73-firmware > net-wireless/rtl8192su-firmware > net-wireless/zd1201-firmware > net-wireless/zd1211-firmware > > (I hope I didn't step on anyones toes here. It was certainly not the > intention.) > > atmel-firmware ipw2100-firmware ipw2200-firmware b43-firmware b43legacy-firmware rtl8192su-firmware zd1201-firmware zd1211-firmware None of these are blockers on linux-firmware, none of these are included in linux firmware, none of these should be masked with no replacement as we are breaking approximately 90% of wifi cards on laptops built in the last 5 years. Only the following acctually show masked when I update: - -net-wireless/atmel-firmware - -net-wireless/b43-firmware - -net-wireless/b43legacy-firmware - -net-wireless/rtl8192su Due to the damage this will cause I am removing the mask on these NOW, I will cleanup the ebuilds today but this is bad, really really bad. If we are cleaning up linux-firmware that's great, but someone needs to check that the things we are masking/removing are actually in linux-firmware... Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRF8i0AAoJEKXdFCfdEflKtbEP/1juLtMGpSw7inSnDLJQx5+a aEFASrcmt9tK3aiYHfdOV09sNHAbiDWUNEM82OLH+yDbZwsiVQTgYnUutQelCo4g B6Zdn9PoFoloAP0TbSfE24NI+BO9Z9rvM9NwHKTmejbKlihhzyhLINkrZM/qzM7j yLSTrTyR2BKilC5bdSmJBgFrYOaWrsexNVZaB00x7eXNSIfBIZtR3LnVqFmMMsaO ZiWFCGHTCRcm7MYbRcNxtS6cA4c/PeiKDbbfEqp8izMSux0ESLZtOPaE5O54uCyi Bc8Th7gd6q4x/FxqYWj8Uq40oiEe1nRArgEbj9gHTvPTur9pvdTfCzIHh+qfV3TW KnEyBJh1cUORnnNpxhJa3dkhT2Zx8s4ebsN6sfsXn3U8iJ9NE5vjz+gF6f4FJ8aH NOuCj5y4LsgUwqoz4T/wpXvN1AlKCueyQ8w6P+RYtfTxZY8yWCnqmux0IFmyCLVj nxhz/Ib9RAUjivdqd4PfcVtZhl42OU4jcNxPCJrpw6Ss07RBEw9+u0kE/kfkSRGT Jn5WFa4vJyLqb7lg0FDDm6ijL5o811CQ7kaDcc1h9RjmgrW3nIusokNMkZnP+dE6 BIVgTlX564rcWsKeU9gmP7C68DSVCVr7zyEbSm9/DajJny4dbHSNUUvBNEQUde6j /iVU0w4Af3YwKJ10KEjo =D6qM -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, Feb 10, 2013 at 10:10 AM, Ben de Groot wrote: > On 10 February 2013 20:11, Rich Freeman wrote: >> Otherwise, purpose-driven overlays just make sense - they allow a >> different set of contributors who are more familiar/interested in a >> set of packages to maintain them. > > It makes more sense to let those people be proxy-maintainers and keep > those packages in the main tree. I'm all for that, but until the barriers to that become lower than the barriers to just creating your own overlay, there will always be overlays that contain stuff better maintained that the corresponding stuff in the main tree. I fully support anything that will make proxy-maintenance easier. Rich
Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)
On 10 February 2013 15:02, Andreas K. Huettel wrote: > Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:> >> I suspect most people are interested in understanding what changed >> (since deprecation means that the new thing is better than the old >> one). Moreover, the news item is another way to assure them that >> everything is not as bad as the initial "red warning" might had made >> them think so and "keep calm and use Gentoo" ;-) > > OK, here's a news item (actually two, separate for server and non-server > profiles). Since it's a bit late now, I'll commit this or the improved version > after discussion here in 6h (21:00 UTC) unless there are severe protests. > > -- the non-server profile variant (sparing you a lot of Display-If-Profile > lines) > > Title: New 13.0 profiles and deprecation of 10.0 profiles > Author: Andreas K. Hüttel > Content-Type: text/plain > Posted: 2013-02-10 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Profile: default/linux/alpha/10.0 > Display-If-Profile: default/linux/alpha/10.0/desktop > [...] > Display-If-Profile: default/linux/x86/10.0/desktop/kde > Display-If-Profile: default/linux/x86/10.0/developer > > We have generated a new set of profiles for Gentoo installation. These are now > called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but > please make sure sys-apps/portage is updated to current stable *before* you > switch profile). > This brings (nearly) no user-visible changes. Some new files have been added > to the profile directories that make it possible for the developers to do more > fine-grained use flag masking (see PMS-5 for the details), and this formally > requires a new profile tree with EAPI=5. > > -- the server profile variant (sparing you the headers entirely) > > We have generated a new set of profiles for Gentoo installation. These are now > called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but > please make sure sys-apps/portage is updated to current stable *before* you > switch profile). > This brings (nearly) no user-visible changes. Some new files have been added > to the profile directories that make it possible for the developers to do more > fine-grained use flag masking (see PMS-5 for the details), and this formally > requires a new profile tree with EAPI=5. > In the course of this change, the "server" profiles will be removed; they do > not exist in the 13.0 tree anymore. You should migrate to the corresponding > parent profile. This may change the default value of some use-flags. The > specific setting in "server" was > USE="-perl -python snmp truetype xml" > You may want to check the setting of these flags after switching profile, but > otherwise nothing changes. > > > > > -- > > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/ > Looks good to me. Thanks -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
hasufell wrote: > there should only be two reasons to have ebuilds in a seperate > overlay: they depend on dropped packages or they are unsupportable > (e.g. because they are in early alpha stage or broken in some ways). Keep in mind that there may be lots of other cases which you have not and can not think of. Overlays are a wonderfully powerful way to arbitrarily extend Gentoo. They make Gentoo infinitely more useful. Anyway, in the case of my overlay, the reason that I have it is very simple: me becoming a dev needs way too much effort. It sounds like the sci overlay situation is the same. I don't really mind this situation in practise, but Gentoo of course loses. :\ //Peter
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On Sun, Feb 10, 2013 at 10:10 AM, Samuli Suominen wrote: > # Some of these install to wrong directory, /lib64/firmware > # as opposed to correct /lib/firmware > # Some of these don't have maintainer > # Some of these are replaced by the firmware from the > # linux-firmware package: > net-wireless/b43-firmware > net-wireless/b43legacy-firmware These are neither of the above. I also don't understand masking packages because the firmware is in linux-firmware. Is this an official policy? Sometimes firmware packages are slotted, and it's also easier to install a package than list and update a changing set of firmware files in /etc/portage/savedconfig/sys-kernel/linux-firmware (referring to ar9271, rt2860, rt2870, i2400m). On the other hand, firmware is often very stable, so why mask a package just because it has no maintainer? Who wins by having atmel, or zd1201/zd1211 masked? There are no open bugs, so what's the point? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Tomáš Chvátal wrote: > Having nice mailinglist where users can contribute simple patches > would be briliant thing to use :-) That's still a waste of time compared to gerrit. You should look at it if you don't know it already. //Peter
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/irda-utils: irda-utils-0.9.18-r3.ebuild irda-utils-0.9.18-r4.ebuild ChangeLog
On Sun, Feb 10, 2013 at 3:16 AM, Samuli Suominen wrote: > On 10/02/13 05:08, Mike Gilbert (floppym) wrote: >> >> floppym 13/02/10 03:08:22 >> - insinto /etc/udev/rules.d >> + insinto /lib/udev/rules.d > > > The udevdir is dynamic, not static, so: > > inherit udev > > insinto "$(get_udevdir)"/rules.d > > Thanks > Fixed.
Re: News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)
On 10 February 2013 23:02, Andreas K. Huettel wrote: > Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:> >> I suspect most people are interested in understanding what changed >> (since deprecation means that the new thing is better than the old >> one). Moreover, the news item is another way to assure them that >> everything is not as bad as the initial "red warning" might had made >> them think so and "keep calm and use Gentoo" ;-) > > OK, here's a news item (actually two, separate for server and non-server > profiles). Since it's a bit late now, I'll commit this or the improved version > after discussion here in 6h (21:00 UTC) unless there are severe protests. > > -- the non-server profile variant (sparing you a lot of Display-If-Profile > lines) > > Title: New 13.0 profiles and deprecation of 10.0 profiles > Author: Andreas K. Hüttel > Content-Type: text/plain > Posted: 2013-02-10 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Profile: default/linux/alpha/10.0 > Display-If-Profile: default/linux/alpha/10.0/desktop > [...] > Display-If-Profile: default/linux/x86/10.0/desktop/kde > Display-If-Profile: default/linux/x86/10.0/developer > > We have generated a new set of profiles for Gentoo installation. These are now > called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but > please make sure sys-apps/portage is updated to current stable *before* you > switch profile). > This brings (nearly) no user-visible changes. Some new files have been added > to the profile directories that make it possible for the developers to do more > fine-grained use flag masking (see PMS-5 for the details), and this formally > requires a new profile tree with EAPI=5. > > -- the server profile variant (sparing you the headers entirely) > > We have generated a new set of profiles for Gentoo installation. These are now > called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but > please make sure sys-apps/portage is updated to current stable *before* you > switch profile). > This brings (nearly) no user-visible changes. Some new files have been added > to the profile directories that make it possible for the developers to do more > fine-grained use flag masking (see PMS-5 for the details), and this formally > requires a new profile tree with EAPI=5. > In the course of this change, the "server" profiles will be removed; they do > not exist in the 13.0 tree anymore. You should migrate to the corresponding > parent profile. This may change the default value of some use-flags. The > specific setting in "server" was > USE="-perl -python snmp truetype xml" > You may want to check the setting of these flags after switching profile, but > otherwise nothing changes. > > > > > -- > > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/ > Looks good to me! -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On 10 February 2013 20:11, Rich Freeman wrote: > Otherwise, purpose-driven overlays just make sense - they allow a > different set of contributors who are more familiar/interested in a > set of packages to maintain them. It makes more sense to let those people be proxy-maintainers and keep those packages in the main tree. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
El dom, 10-02-2013 a las 16:05 +0100, hasufell escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/10/2013 12:47 PM, Patrick Lauer wrote:> Would anyone be > > Would anyone be terribly upset if I started pillaging this silly > > overlay? (And any other overlays that look like they are fun) > > > > Go ahead, I will help you. > > > On 02/10/2013 12:59 PM, Pacho Ramos wrote: > > > > That is because looks nobody from sci team has enough time to move > > things from sci overlay to the tree (probably because it's being > > maintained there by people without commit access). > > I take that as a free card to add myself to the sci herd. > That would be nice as, looking to some of its assigned bugs, it needs help on maintaining the lot of packages included there. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Am Sonntag, 10. Februar 2013, 15:59:57 schrieb Patrick Nagel: > > Actually, if you could add a note that before switching to the new profile, > you should update portage if it's old, that would be even more > user-friendly: > Already done, see separate mail... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
El dom, 10-02-2013 a las 17:46 +0300, Sergei Trofimovich escribió: [...] > The source of confusion was non-working device by default. > Maybe 'IUSE=+firmware; RDEPEND="firmware? ( sys-kernel/linux-firmware )"' > for virtual/linux-sources would help user experience a bit. > > Sometimes firmware loader does not even write fw file > it expects to be present on FS in dmesg (like certain broadcom drivers) > thus it's nontrivial for user to figure out needed package to be installed. > > Thanks! > I agree as I have also needed to google and search in forums to get proper firmware installed in the past in some machines :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 12:47 PM, Patrick Lauer wrote:> Would anyone be > Would anyone be terribly upset if I started pillaging this silly > overlay? (And any other overlays that look like they are fun) > Go ahead, I will help you. On 02/10/2013 12:59 PM, Pacho Ramos wrote: > > That is because looks nobody from sci team has enough time to move > things from sci overlay to the tree (probably because it's being > maintained there by people without commit access). I take that as a free card to add myself to the sci herd. As for the overlay discussion, there should only be two reasons to have ebuilds in a seperate overlay: they depend on dropped packages or they are unsupportable (e.g. because they are in early alpha stage or broken in some ways). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRF7czAAoJEFpvPKfnPDWz4gsH/jpvNiLpVKrnLM2T2lwS1oFx uvrfBbBgX6ROEF0aQ6Um8GnJFqMkpW76O7R9hVHoF1ZMISh7iTQKw8eBMMKj/3ib 1O2kgUB6Y4yMXvZrq9RM7BJzupTQp8qdMMaozf8sJ34DhGKMVS8xRHWrgkJRq8FD ZL/tbImEVDd97IazDLXPUxN77shvo2oYHOd9peiI9aVRWti72Kyzg8M6cxQ5ek33 ahLfeNpjw+Bg+k16WM6Fi0v9H64hSOSeeZzwaBoaAO0w3JlTx8ch2/8OBPFSg6gF 2aS3DoIG1K7JR1i+LLJ2x2sPUWPjPKcDlknGuNkZ2HlTP3gZziZusclboy/NjGI= =LGQV -END PGP SIGNATURE-
News item (was: Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations)
Am Sonntag, 10. Februar 2013, 15:15:43 schrieb Markos Chandras:> > I suspect most people are interested in understanding what changed > (since deprecation means that the new thing is better than the old > one). Moreover, the news item is another way to assure them that > everything is not as bad as the initial "red warning" might had made > them think so and "keep calm and use Gentoo" ;-) OK, here's a news item (actually two, separate for server and non-server profiles). Since it's a bit late now, I'll commit this or the improved version after discussion here in 6h (21:00 UTC) unless there are severe protests. -- the non-server profile variant (sparing you a lot of Display-If-Profile lines) Title: New 13.0 profiles and deprecation of 10.0 profiles Author: Andreas K. Hüttel Content-Type: text/plain Posted: 2013-02-10 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/alpha/10.0 Display-If-Profile: default/linux/alpha/10.0/desktop [...] Display-If-Profile: default/linux/x86/10.0/desktop/kde Display-If-Profile: default/linux/x86/10.0/developer We have generated a new set of profiles for Gentoo installation. These are now called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). This brings (nearly) no user-visible changes. Some new files have been added to the profile directories that make it possible for the developers to do more fine-grained use flag masking (see PMS-5 for the details), and this formally requires a new profile tree with EAPI=5. -- the server profile variant (sparing you the headers entirely) We have generated a new set of profiles for Gentoo installation. These are now called 13.0 instead of 10.0. Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). This brings (nearly) no user-visible changes. Some new files have been added to the profile directories that make it possible for the developers to do more fine-grained use flag masking (see PMS-5 for the details), and this formally requires a new profile tree with EAPI=5. In the course of this change, the "server" profiles will be removed; they do not exist in the 13.0 tree anymore. You should migrate to the corresponding parent profile. This may change the default value of some use-flags. The specific setting in "server" was USE="-perl -python snmp truetype xml" You may want to check the setting of these flags after switching profile, but otherwise nothing changes. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Hi, On 2013-02-10 22:06, Andreas K. Huettel wrote: > Am Sonntag, 10. Februar 2013, 14:34:14 schrieb Markos Chandras: new profiles? As a Gentoo user who just got a giant red warning from portage that his active profile was deprecated, I feel like many people are going to be confused about this. >>> >>> Obviously a news item should precede any deprecation of stable profiles. >>> >> >> I think it is too late now. The big red warning is already there. > > To be honest I did not really see the necessity since the "big red warning" > exactly tells you what to do (and even which profile to pick, which would be > more complicated in a news item). > > Then again, that's a matter of personal preference, too. Actually, if you could add a note that before switching to the new profile, you should update portage if it's old, that would be even more user-friendly: I just saw the big red warning on a not-so-well-maintained Gentoo box today, switched to the new profile, and then portage would only do read-only operations. So I had to figure out how to change the profile back manually (because the old profile also isn't shown in eselect anymore), before I could update portage and then switch to the new profile again. Patrick.
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, Feb 10, 2013 at 9:37 AM, Tomáš Chvátal wrote: > no matter what are Richs opinions he is not the one crating global policies > for this, so the defaults still are that we encourage adding all stuff to main > tree where possible. Relax, and don't make it personal. The bottom line is that some encourage putting stuff in the tree, and others like to work from overlays. No developer is going to get banned for working on an overlay on the side. In the end packages in the tree will be better maintained if developers step up and maintain them, and packages in an overlay will be better maintained if developers step up and maintain them. Anything else is just flames on the lists. I never claimed to speak for a majority, and the only time I concern myself with majority opinion is when following policies or voting as a trustee. Rich
RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 10:10:51 +0200 Samuli Suominen wrote: > # Samuli Suominen (10 Feb 2013) > # The firmware cleanup, part #1. Can be unmasked after > # cleaning up the package if it's still needed. > # Some of these install to wrong directory, /lib64/firmware > # as opposed to correct /lib/firmware > # Some of these don't have maintainer > # Some of these are replaced by the firmware from the > # linux-firmware package: > # emerge -av linux-firmware > # If you still have a reason to keep the package, please > # let us know by filing a bug report. > net-wireless/ar9271-firmware I didn't know linux-firmware exists at all when added that to the tree (SRC_URI=http://linuxwireless.org). Fine by me. The source of confusion was non-working device by default. Maybe 'IUSE=+firmware; RDEPEND="firmware? ( sys-kernel/linux-firmware )"' for virtual/linux-sources would help user experience a bit. Sometimes firmware loader does not even write fw file it expects to be present on FS in dmesg (like certain broadcom drivers) thus it's nontrivial for user to figure out needed package to be installed. Thanks! -- Sergei signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 10:01 AM, Pacho Ramos wrote: > # Pacho Ramos (10 Feb 2013) # Fails with > gcc-4.7, crashes (#301946, #312073), problems with # boost > (#319921), problems with python-2.7 (#338826), really old # version > in the tree, people should move to sci overlay one (#424659). # > Removal in a month. sci-visualization/paraview > "people should move to sci overlay one"? Why is it not in the tree? Pointing people to overlays is wrong imo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRF7HdAAoJEFpvPKfnPDWzdekH/0sOPq8riBUlRtfDnLWAuf4J 7md3b0KBg9sP0RZWJsAZdK/N5Zs37iJWXF+L9LAr4wmil8IwxazEMWC3xMu8Dh4E cXIfVVgLWz8C/VW0wQBUX3jo7fr4B0gLKWdRZ6axgPdTV3pIqz6cpzsbbtb4ls+L XteKqDHhQxfZ2vjtkImVcux4wBBZEWZX/Do+21WfC6WWbk9Q5udmrcxCpLTMl84O G/Ia5rfwWiHtIpDzY0PBJgFnTkyfbKlas1hSDYybLDO+Tr1F6YRN3nmFWLFeBPVY NqhGLHnyvWApSJ+qkjb2bszWHs3GVLYDec+W81R8mgO4c/hYugeoKXS6YBhTPNc= =9xsA -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Dne Ne 10. února 2013 13:51:16, Alexander Berntsen napsal(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/02/13 12:47, Patrick Lauer wrote: > > So instead of moving things from random overlays to the tree we > > remove packages now, remove features from other packages because of > > > > that (openfoam) and then ... tell users to use an overlay? > > > > Somehow this appears not well thought out to me. > > +1 > > On 10/02/13 13:11, Rich Freeman wrote: > > There is nothing wrong with having an overlay that provides a > > better experience than the main tree. Most distros actually > > operate this way > > Most distros aren't very good. > > > - just look up your average non-core piece of FOSS software and the > > > > first thing their Ubuntu install instructions will tell you to do > > > > is to add some repository to your list. > > And the second search result is the Ubuntu troubleshooting broken > installs as a result of adding other repositories. > > I accept that there may exist reasons for using overlays. "Ubuntu do > it!" is not one. > Don't worry, no matter what are Richs opinions he is not the one crating global policies for this, so the defaults still are that we encourage adding all stuff to main tree where possible. Even the overlays are supposed to be just plaingrounds where we train upcoming devs, or pose as live ebuild/huge experimantal changes storage space. Even the excuse that it is not maintained so it is to stay in overlay is false, because when somebody mess with the package in overlay they can became maintainers in the main tree too without much fuzz. But I suppose this problem is created simply because people not wanting to work with cvs (and I purely agree that git workflow is much easier wrt this)... Cheers Tom
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 10 February 2013 14:06, Andreas K. Huettel wrote: > Am Sonntag, 10. Februar 2013, 14:34:14 schrieb Markos Chandras: >> > > new profiles? As a Gentoo user who just got a giant red warning from >> > > portage that his active profile was deprecated, I feel like many people >> > > are going to be confused about this. >> > >> > Obviously a news item should precede any deprecation of stable profiles. >> > >> >> I think it is too late now. The big red warning is already there. > > To be honest I did not really see the necessity since the "big red warning" > exactly tells you what to do (and even which profile to pick, which would be > more complicated in a news item). > > Then again, that's a matter of personal preference, too. > > -- > > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/ > I suspect most people are interested in understanding what changed (since deprecation means that the new thing is better than the old one). Moreover, the news item is another way to assure them that everything is not as bad as the initial "red warning" might had made them think so and "keep calm and use Gentoo" ;-) -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Am Sonntag, 10. Februar 2013, 14:34:14 schrieb Markos Chandras: > > > new profiles? As a Gentoo user who just got a giant red warning from > > > portage that his active profile was deprecated, I feel like many people > > > are going to be confused about this. > > > > Obviously a news item should precede any deprecation of stable profiles. > > > > I think it is too late now. The big red warning is already there. To be honest I did not really see the necessity since the "big red warning" exactly tells you what to do (and even which profile to pick, which would be more complicated in a news item). Then again, that's a matter of personal preference, too. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On Feb 10, 2013 8:32 AM, "Ben de Groot" wrote: > > On 10 February 2013 10:43, Douglas Freed wrote: > >> * all 13.0 profiles have been created and are marked stable the same way > >> as > >> 10.0 was > >> * all 10.0 profiles have been removed from profiles.desc > >> * all 10.0 profiles have been deprecated > > > > Suggestion: perhaps a news item should be created for the migration to the > > new profiles? As a Gentoo user who just got a giant red warning from > > portage that his active profile was deprecated, I feel like many people are > > going to be confused about this. > > > > -Doug > > Obviously a news item should precede any deprecation of stable profiles. > > -- > Cheers, > > Ben | yngwin > Gentoo developer > Gentoo Qt project lead, Gentoo Wiki admin > I think it is too late now. The big red warning is already there.
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, Feb 10, 2013 at 7:51 AM, Alexander Berntsen wrote: > > On 10/02/13 13:11, Rich Freeman wrote: >> - just look up your average non-core piece of FOSS software and the >> first thing their Ubuntu install instructions will tell you to do >> is to add some repository to your list. > And the second search result is the Ubuntu troubleshooting broken > installs as a result of adding other repositories. > > I accept that there may exist reasons for using overlays. "Ubuntu do > it!" is not one. I have mixed feelings on this. I'd never advocate doing anything simply because everybody else is doing it - if I wanted to use Ubuntu I'd be using Ubuntu. There are pros/cons to overlays right now: Pros include: 1. More flexible maintenance model. The overlay maintainer can choose who has access to it. They don't have to worry about people making tree-wide commits without knowing what they're doing, because any damage is contained to the overlay (though obviously any package in an overlay could mess with anything on a user's system). 2. More flexible QA model. Usually that means less QA, which has its own pros and cons, but it /could/ actually mean more QA, or just different QA. Right now we have no way of communicating to users (beyond masks) that packages vary in quality level, and overlays could be a way to accomplish this. You could also have a set of related overlays that provide a dev/test/stable experience. Cons include: 1. No relationship to the tree. If somebody messes with one of your dependencies they will not take any care not to break your package. 2. Non-mainstream experience. Because Gentoo tends to be overlay-averse, most users don't use them at all. 3. No real organization. Beyond an entry in the layman list there really isn't any systematic tracking of overlays and their quality/etc. We don't "grade" overlays or anything like that. #1 is the biggest con I'd say. It is made worse by the fact that we don't have a main repository QA cycle (I'm not suggesting we have one). For something like Ubuntu anybody maintaining a 3rd party repository can monitor the release cycle and test against the new dependency versions before they are released and be ready on day one. For Gentoo you would have to pay very close attention to bugzilla, lists, irc, and perhaps even mail aliases (not open to the public) to have any idea that some change is about to happen to one of your dependencies if you aren't in the main tree. A fix for #1 might be some way to allow external parties to register interest in upcoming changes and get alerted. Then those changing libs could just trigger the alerts (and that system might also file bugs against in-tree packages to request testing). We obviously wouldn't consider any outside overlays blockers, but we could be nicer to them. Of course, that takes work and I'm skeptical that this would ever happen. So, those are just my thoughts on overlays. I don't think they're a bad thing. However, there are some things about Gentoo that make them less practical than on other distros. I won't argue that you get the best possible experience if the package is in the tree AND IT IS MAINTAINED. The problem is that in a volunteer-based organization the second half of that is hard to guarantee. Rich
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
On 10/02/13 10:10, Samuli Suominen wrote: # Samuli Suominen (10 Feb 2013) # The firmware cleanup, part #1. Can be unmasked after # cleaning up the package if it's still needed. # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: # emerge -av linux-firmware # If you still have a reason to keep the package, please # let us know by filing a bug report. net-wireless/ipw2100-firmware net-wireless/ipw2200-firmware These two got unmasked after cleaning up the ebuilds. net-wireless/prism54-firmware This one doesn't have license, moved to it's own mask. And new masked package because it's in linux-firmware: net-wireless/i2400m-fw
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/13 12:47, Patrick Lauer wrote: > So instead of moving things from random overlays to the tree we > remove packages now, remove features from other packages because of > that (openfoam) and then ... tell users to use an overlay? > > Somehow this appears not well thought out to me. +1 On 10/02/13 13:11, Rich Freeman wrote: > There is nothing wrong with having an overlay that provides a > better experience than the main tree. Most distros actually > operate this way Most distros aren't very good. > - just look up your average non-core piece of FOSS software and the > first thing their Ubuntu install instructions will tell you to do > is to add some repository to your list. And the second search result is the Ubuntu troubleshooting broken installs as a result of adding other repositories. I accept that there may exist reasons for using overlays. "Ubuntu do it!" is not one. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEXl8QACgkQRtClrXBQc7UKOAD+P7mFavgADIecwTm5jKLEnbq/ h81FRf2qbvwf54X6T9YA/RJ4y1EAesZOvxvpuIVTEKpLwcTipgWJZeExzWReAn/7 =po4x -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Dne Ne 10. února 2013 19:47:58, Patrick Lauer napsal(a): > On 02/10/2013 05:01 PM, Pacho Ramos wrote: > > # Pacho Ramos (10 Feb 2013) > > # Fails with gcc-4.7, crashes (#301946, #312073), problems with > > # boost (#319921), problems with python-2.7 (#338826), really old > > # version in the tree, people should move to sci overlay one (#424659). > > # Removal in a month. > > sci-visualization/paraview > > So instead of moving things from random overlays to the tree we remove > packages now, remove features from other packages because of that > (openfoam) and then ... tell users to use an overlay? Agreed this is pretty bad idea. The teams should actually have their top priority to include user contributions to main tree as much as possible. If the team does not have time to maintain the named package, just add some contributors as maintainers and do proxy-commits for them... The greatest problem at least from my PoV is that we can't just simply git am loads of stuff users are contributing and must convert to cvs (thats actually what takes me most of the time). Having nice mailinglist where users can contribute simple patches would be briliant thing to use :-) Cheers Tom
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, Feb 10, 2013 at 6:48 AM, Michał Górny wrote: > > +1. If you can't manage moving/updating your packages properly > and on-time from the sci overlay, please get rid of it. Seems like the alternative solution is to just not have these ebuilds in the main tree. There is nothing wrong with having an overlay that provides a better experience than the main tree. Most distros actually operate this way - just look up your average non-core piece of FOSS software and the first thing their Ubuntu install instructions will tell you to do is to add some repository to your list. I think the main tree can potentially provide a better experience since it actually gets checked when dependencies are changed. However, that is only true if somebody is maintaining it. Pillaging the overlays is fine as long as somebody actually maintains the package, and it isn't just a one-time copy that resets the clock. Otherwise, purpose-driven overlays just make sense - they allow a different set of contributors who are more familiar/interested in a set of packages to maintain them. Rich
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
El dom, 10-02-2013 a las 19:47 +0800, Patrick Lauer escribió: > On 02/10/2013 05:01 PM, Pacho Ramos wrote: > > # Pacho Ramos (10 Feb 2013) > > # Fails with gcc-4.7, crashes (#301946, #312073), problems with > > # boost (#319921), problems with python-2.7 (#338826), really old > > # version in the tree, people should move to sci overlay one (#424659). > > # Removal in a month. > > sci-visualization/paraview > > So instead of moving things from random overlays to the tree we remove > packages now, remove features from other packages because of that > (openfoam) and then ... tell users to use an overlay? > > Somehow this appears not well thought out to me. Would anyone be > terribly upset if I started pillaging this silly overlay? (And any other > overlays that look like they are fun) > That is because looks nobody from sci team has enough time to move things from sci overlay to the tree (probably because it's being maintained there by people without commit access). Ideally that people would become devs with commit rights but, until then, looks like some packages (usually sci maintained packages) are being maintained better in overlay than main tree :/ I guess wouldn't be problems on pillaging ebuilds from that overlay to the tree... but I guess you would be willing to become its maintainer to update ebuilds from overlay when needed :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On Sun, 10 Feb 2013 19:47:58 +0800 Patrick Lauer wrote: > On 02/10/2013 05:01 PM, Pacho Ramos wrote: > > # Pacho Ramos (10 Feb 2013) > > # Fails with gcc-4.7, crashes (#301946, #312073), problems with > > # boost (#319921), problems with python-2.7 (#338826), really old > > # version in the tree, people should move to sci overlay one (#424659). > > # Removal in a month. > > sci-visualization/paraview > > So instead of moving things from random overlays to the tree we remove > packages now, remove features from other packages because of that > (openfoam) and then ... tell users to use an overlay? > > Somehow this appears not well thought out to me. Would anyone be > terribly upset if I started pillaging this silly overlay? (And any other > overlays that look like they are fun) +1. If you can't manage moving/updating your packages properly and on-time from the sci overlay, please get rid of it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
On 02/10/2013 05:01 PM, Pacho Ramos wrote: > # Pacho Ramos (10 Feb 2013) > # Fails with gcc-4.7, crashes (#301946, #312073), problems with > # boost (#319921), problems with python-2.7 (#338826), really old > # version in the tree, people should move to sci overlay one (#424659). > # Removal in a month. > sci-visualization/paraview So instead of moving things from random overlays to the tree we remove packages now, remove features from other packages because of that (openfoam) and then ... tell users to use an overlay? Somehow this appears not well thought out to me. Would anyone be terribly upset if I started pillaging this silly overlay? (And any other overlays that look like they are fun)
Re: [gentoo-dev] January stabilization candidates
On Sun, 10 Feb 2013 12:22:13 +0100 ""Paweł Hajdan, Jr."" wrote: > I can actually batch invalidate all of them. This will generate some > further bug spam (I apologize), but can save your time dealing with > the mess. Please let me know what's your preference. The URL field is likely not filled out as intended either. So you might want to do that anyway. signature.asc Description: PGP signature
Re: [gentoo-dev] January stabilization candidates
On 1/12/13 11:49 PM, "Paweł Hajdan, Jr." wrote: > Please review attached automatically generated stabilization candidates > for January. Oops, today I've tried my _separate_ script to file stabilization bugs based on a generated list of packages to support that workflow. Now the bug is that the list was the original one from January, and many entries from that list are now stale (the new contents were appended at the end). I hit ctrl-c once I realized the mistake, and I'm going to wait a while for the current batch of bugs to get handled. I can actually batch invalidate all of them. This will generate some further bug spam (I apologize), but can save your time dealing with the mess. Please let me know what's your preference. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
# Pacho Ramos (10 Feb 2013) # Upstream dropped support for linux time ago (#434390), # possible security issues (#360539). You can use Windows # version with PlayOnLinux. Removal in a month. media-gfx/picasa # Pacho Ramos (10 Feb 2013) # Abandoned by upstream, problems building (#362611). # Removal in a month. dev-python/papyon net-voip/telepathy-butterfly # Pacho Ramos (10 Feb 2013) # Fails with gcc-4.7, crashes (#301946, #312073), problems with # boost (#319921), problems with python-2.7 (#338826), really old # version in the tree, people should move to sci overlay one (#424659). # Removal in a month. sci-visualization/paraview # Pacho Ramos (10 Feb 2013) # Doesn't support kernel >= 2.6.22, #453202. Removal in a month. x11-misc/xdaf signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On 10 February 2013 10:43, Douglas Freed wrote: >> * all 13.0 profiles have been created and are marked stable the same way >> as >> 10.0 was >> * all 10.0 profiles have been removed from profiles.desc >> * all 10.0 profiles have been deprecated > > Suggestion: perhaps a news item should be created for the migration to the > new profiles? As a Gentoo user who just got a giant red warning from > portage that his active profile was deprecated, I feel like many people are > going to be confused about this. > > -Doug Obviously a news item should precede any deprecation of stable profiles. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/irda-utils: irda-utils-0.9.18-r3.ebuild irda-utils-0.9.18-r4.ebuild ChangeLog
On 10/02/13 05:08, Mike Gilbert (floppym) wrote: floppym 13/02/10 03:08:22 - insinto /etc/udev/rules.d + insinto /lib/udev/rules.d The udevdir is dynamic, not static, so: inherit udev insinto "$(get_udevdir)"/rules.d Thanks
[gentoo-dev] Lastrite: Firmware cleanup, part #1
# Samuli Suominen (10 Feb 2013) # The firmware cleanup, part #1. Can be unmasked after # cleaning up the package if it's still needed. # Some of these install to wrong directory, /lib64/firmware # as opposed to correct /lib/firmware # Some of these don't have maintainer # Some of these are replaced by the firmware from the # linux-firmware package: # emerge -av linux-firmware # If you still have a reason to keep the package, please # let us know by filing a bug report. net-wireless/ar9271-firmware net-wireless/atmel-firmware net-wireless/b43-firmware net-wireless/b43legacy-firmware net-wireless/ipw2100-firmware net-wireless/ipw2200-firmware net-wireless/libertas-firmware net-wireless/prism54-firmware net-wireless/rt2860-firmware net-wireless/rt2870-firmware net-wireless/rt61-firmware net-wireless/rt73-firmware net-wireless/rtl8192su-firmware net-wireless/zd1201-firmware net-wireless/zd1211-firmware (I hope I didn't step on anyones toes here. It was certainly not the intention.)