[gentoo-dev] Re: ROMs category suggestion
Chí-Thanh Christopher Nguyễn posted on Wed, 25 Jul 2012 21:58:30 +0200 as excerpted: Kent Fredric schrieb: On 23 July 2012 08:48, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I do see some advantage of the current way of putting the firmware in the category of what it is for... If you wanted, you could do something like x11-drivers/ do , and have a standard of adding a little subcategorization: Could you be more specific? What does x11-drivers/ do that applies here? x11-drivers/xf86-video-ati x11-drivers/xf86-video-intel x11-drivers/xf86-input-evdev From his example: sys-firmware/video-ati ... he's obviously referring to the middle sub-category, -video- -input- etc. But your point about putting that in the category instead, thus having firmware-video, firmware-tv, firmware-sound, etc, instead of putting them all in sys-firmware, DOES make sense. For firmware-* categories that would otherwise just have a single package or two, there could be a firmware-misc, if category-proliferation is seen to be a big issue. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Fraunhofer FDK license
I'd add it, it is a gpl incompatible opensource license. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero Software License for The Fraunhofer FDK AAC Codec Library for Android © Copyright 1995 - 2012 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. All rights reserved. 1.INTRODUCTION The Fraunhofer FDK AAC Codec Library for Android (FDK AAC Codec) is software that implements the MPEG Advanced Audio Coding (AAC) encoding and decoding scheme for digital audio. This FDK AAC Codec software is intended to be used on a wide variety of Android devices. AAC's HE-AAC and HE-AAC v2 versions are regarded as today's most efficient general perceptual audio codecs. AAC-ELD is considered the best-performing full-bandwidth communications codec by independent studies and is widely deployed. AAC has been standardized by ISO and IEC as part of the MPEG specifications. Patent licenses for necessary patent claims for the FDK AAC Codec (including those of Fraunhofer) may be obtained through Via Licensing (www.vialicensing.com) or through the respective patent owners individually for the purpose of encoding or decoding bit streams in products that are compliant with the ISO/IEC MPEG audio standards. Please note that most manufacturers of Android devices already license these patent claims through Via Licensing or directly from the patent owners, and therefore FDK AAC Codec software may already be covered under those patent licenses when it is used for those licensed purposes only. Commercially-licensed AAC software libraries, including floating-point versions with enhanced sound quality, are also available from Fraunhofer. Users are encouraged to check the Fraunhofer website for additional applications information and documentation. 2.COPYRIGHT LICENSE Redistribution and use in source and binary forms, with or without modification, are permitted without payment of copyright license fees provided that you satisfy the following conditions: You must retain the complete text of this software license in redistributions of the FDK AAC Codec or your modifications thereto in source code form. You must retain the complete text of this software license in the documentation and/or other materials provided with redistributions of the FDK AAC Codec or your modifications thereto in binary form. You must make available free of charge copies of the complete source code of the FDK AAC Codec and your modifications thereto to recipients of copies in binary form. The name of Fraunhofer may not be used to endorse or promote products derived from this library without prior written permission. You may not charge copyright license fees for anyone to use, copy or distribute the FDK AAC Codec software or your modifications thereto. Your modified versions of the FDK AAC Codec must carry prominent notices stating that you changed the software and the date of any change. For modified versions of the FDK AAC Codec, the term Fraunhofer FDK AAC Codec Library for Android must be replaced by the term Third-Party Modified Version of the Fraunhofer FDK AAC Codec Library for Android. 3.NO PATENT LICENSE NO EXPRESS OR IMPLIED LICENSES TO ANY PATENT CLAIMS, including without limitation the patents of Fraunhofer, ARE GRANTED BY THIS SOFTWARE LICENSE. Fraunhofer provides no warranty of patent non-infringement with respect to this software. You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses. 4.DISCLAIMER This FDK AAC Codec software is provided by Fraunhofer on behalf of the copyright holders and contributors AS IS and WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE for any direct, indirect, incidental, special, exemplary, or consequential damages, including but not limited to procurement of substitute goods or services; loss of use, data, or profits, or business interruption, however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence), arising in any way out of the use of this software, even if advised of the possibility of such damage. 5.CONTACT INFORMATION Fraunhofer Institute for Integrated Circuits IIS Attention: Audio and Multimedia Departments - FDK AAC LL Am Wolfsmantel 33 91058 Erlangen, Germany www.iis.fraunhofer.de/amm amm-i...@iis.fraunhofer.de
Re: [gentoo-dev] Re: ROMs category suggestion
On Thu, 26 Jul 2012 06:03:53 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Chí-Thanh Christopher Nguyễn posted on Wed, 25 Jul 2012 21:58:30 +0200 as excerpted: Kent Fredric schrieb: On 23 July 2012 08:48, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I do see some advantage of the current way of putting the firmware in the category of what it is for... If you wanted, you could do something like x11-drivers/ do , and have a standard of adding a little subcategorization: Could you be more specific? What does x11-drivers/ do that applies here? x11-drivers/xf86-video-ati x11-drivers/xf86-video-intel x11-drivers/xf86-input-evdev But you are aware that this is *upstream* naming? Similarly, ati-drivers (which is not upstream naming :P) and nvidia-drivers don't follow the suite. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fraunhofer FDK license
On Thu, 26 Jul 2012, Luca Barbato wrote: I'd add it, it is a gpl incompatible opensource license. No problem to add it. But IMHO the usage restriction in section 3 makes it non-free: You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses. Ulrich
Re: [gentoo-dev] Re: ROMs category suggestion
On 26 July 2012 19:32, Michał Górny mgo...@gentoo.org wrote: But you are aware that this is *upstream* naming? Similarly, ati-drivers (which is not upstream naming :P) and nvidia-drivers don't follow the suite. I wasn't aware of that, but thats beside the point I was trying to make. Its just a mechanism that allows an appoximation of a 3-tier system without needing a 3-teir system. ie: sys-firmware/video/ati approximated as sys-firmware/video-ati , which seems slighly better than the competing ways of doing it like: firmware-video/ati-firmware firmware-video/ati and any category name with Firmware in it, will result in lots of redundant names exposed to users/deps if the package /also/ has firmware in the name. There's also the other thing to consider, and thats there's a lot of hardware related stuff that is similar to firmware in a way, but also totally devoid of a central category for it. Namely, kernel level drivers. ( Which are not /that/ far removed from firmware, considering that you can compile firmware into kernels and they're of similar levels of necessity ). We may as well suggest sys-hardware/and put things like tp_smapi and prism54-firmware all in that one category. In essence, the rationale behind having a sys-firmware category for all firmware, but no sys-drivers category for all device drivers/modules seems an oversight. But I think however you do it, the absence of a 3-tier system hamstrings you. net-wireless/prism54-firmware - Alternatives: sys-firmware/prism54-firmware sys-firmware/prism54 sys-firmware/wireless-prism54-firmware sys-firmware/wireless-prism54 firmware-wireless/prism54-firmware firmware-wireless/prism54 sys-hardware/prism54-firmware sys-hardware/wireless-prism54-firmware hardware-wireless/prism54-firmware net-dialup/hsfmodem - Alternatives: sys-driver/hsfmodem sys-driver/dialup-hsfmodem sys-hardware/hsfmodem sys-hardware/dialup-hsfmodem hardware-dialup/hfsmodem The perk of *not* having 'firmware' in the category name means you can put drivers in the category as-is, and add firmware to the category as-is, without needing to have redundant information. In a sys-hardware/* hardware-$class/* layout, things without -firmware are assumed kernel drivers , and things with -firmware are known as firmware. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
[gentoo-dev] [gentoo-dev-announce] Last rites: net-fs/mount-cifs
# Tiziano Müller dev-z...@gentoo.org (24 Jul 2012) # Now part of net-fs/cifs-utils unmaintained by upstream # Security bug #308067 and bugs #427702, #232608, #247809, # #258409, #265183, #337691, #342783, #279074 # Removal in 30 days net-fs/mount-cifs
Re: Re: [gentoo-dev] Fraunhofer FDK license
On Thu, 26 Jul 2012, Luca Barbato wrote: I'd add it, it is a gpl incompatible opensource license. No problem to add it. But IMHO the usage restriction in section 3 makes it non-free: You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses. Ulrich Indeed, and this opens another can of worms since (as far as I can see) there are no specific license clauses in the AAC patent license for applications that may be distributed without cost. I.e., licensing fees still apply as per unit fee. http://www.vialicensing.com/licensing/aac-overview.aspx Sometimes I have the feeling that Fraunhofer (which is after all funded 30% by German federal and state money) just does not get it. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Lastrite: glipper
# Samuli Suominen ssuomi...@gentoo.org (26 Jul 2012) # We are in process of dropping most of GTK+-2.x Ubuntu # Ayatana libraries from tree and unfortunately glipper # has hardcoded dependency on libappindicator's Python # GTK+-2.x bindings # Removal in 30 days x11-misc/glipper
[gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
I've been messing around with namespaces and some of what systemd has been doing with them, and I have an idea for a portage feature. But before doing a brain dump of ideas, how useful would it be to have a FEATURE for portage to do a limited-visibility build? That is, the build would be run in an environment where the root filesystem appears to contain everything in a DEPEND (including @system currently) and nothing else? It might be useful both in development/testing, and also in production use (not sure how performance would work in the real world - I was able in a script to get it to build an enviornment in a few seconds for a few packages). I really crazy idea would be to try to run packages in a similar environment, but I think that needs better kernel/etc level support since the performance hit would be much more noticeable, except for things like daemons that only start once. Implementing it wouldn't necessarily be hard - just create a tmpfs under /var/tmp/portage, unshare off a new mount namespace, and read-only bind-mount everything needed from the root filesystem (including /var/tmp/portage/...), and chroot into it. When the build is done the process governing it terminates and the kernel wipes out all the mounts and then portage unmounts the tmpfs. You wouldn't need to use a tmpfs for the build - it would actually be zero-size as reported by df since it just contains a bazillion bind mounts, though all those mounts would consume slab memory. Thoughts? Rich
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On Thu, Jul 26, 2012 at 2:26 PM, Rich Freeman ri...@gentoo.org wrote: I've been messing around with namespaces and some of what systemd has been doing with them, and I have an idea for a portage feature. But before doing a brain dump of ideas, how useful would it be to have a FEATURE for portage to do a limited-visibility build? That is, the build would be run in an environment where the root filesystem appears to contain everything in a DEPEND (including @system currently) and nothing else? It might be useful both in development/testing, and also in production use (not sure how performance would work in the real world - I was able in a script to get it to build an enviornment in a few seconds for a few packages). I very much like this, as it'd greatly simplify identifying any unintended or unrecognized dependencies in my code. Furthermore, if the mechanism for identifying and declaring specified-required content can be generalized, this would make distributed builds potentially more efficient by allowing the dispatching host to distribute the necessary header and library files to the machines doing the building. (Really, this observation is more about simply making the information available; distcc could consume that information if someone chose to do the work to add that functionality.) I really crazy idea would be to try to run packages in a similar environment, but I think that needs better kernel/etc level support since the performance hit would be much more noticeable, except for things like daemons that only start once. Implementing it wouldn't necessarily be hard - just create a tmpfs under /var/tmp/portage, unshare off a new mount namespace, and read-only bind-mount everything needed from the root filesystem (including /var/tmp/portage/...), and chroot into it. When the build is done the process governing it terminates and the kernel wipes out all the mounts and then portage unmounts the tmpfs. You wouldn't need to use a tmpfs for the build - it would actually be zero-size as reported by df since it just contains a bazillion bind mounts, though all those mounts would consume slab memory. Thoughts? You've done 90% of the conceptual work needed for an idea I had; I've wanted to do something similar at the 'make' level, to make identifying and fixing broken parallel build systems easier. If I could limit a make instance to only be able to see consequences of jobs it declared as dependencies, that'd go a long way. I was going to go by way of FUSE for this, though... -- :wq
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On 07/26/12 14:26, Rich Freeman wrote: I've been messing around with namespaces and some of what systemd has been doing with them, and I have an idea for a portage feature. But before doing a brain dump of ideas, how useful would it be to have a FEATURE for portage to do a limited-visibility build? That is, the build would be run in an environment where the root filesystem appears to contain everything in a DEPEND (including @system currently) and nothing else? It might be useful both in development/testing, and also in production use (not sure how performance would work in the real world - I was able in a script to get it to build an enviornment in a few seconds for a few packages). The Cabal build system for Haskell packages does this and it's extremely useful. It prevents me from forgetting dependencies like 'directory', 'time', etc. that I use without thinking. runghc Setup.hs build Building lwn-epub-0.0... Preprocessing executable 'lwn-epub' for lwn-epub-0.0... src/LWN/Article.hs:12:8: Could not find module `System.Directory' It is a member of the hidden package `directory-1.1.0.2'. Perhaps you need to add `directory' to the build-depends in your .cabal file. Use -v to see a list of the files searched for.
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On Thu, Jul 26, 2012 at 2:40 PM, Michael Mol mike...@gmail.com wrote: (Really, this observation is more about simply making the information available; distcc could consume that information if someone chose to do the work to add that functionality.) Well, I'm not sure how to get the info out of the internals of portage itself (I have to imagine it would be fast since portage has to know about it already), but for a list of packages you can xargs them into qlist to get a list of all files, and then pipe that into a script that will populate a chroot for you. Quick script for those curious to try it out: mkdir newroot mount -t tmpfs none newroot cd newroot unshare -m /bin/bash echo list of packages | xargs qlist | linkfile (poke around) exit (note that bind mounts are gone) cd .. umount newroot ; rmdir newroot (note that all traces gone) Contents of linkfile script: #!/bin/bash install -D /dev/null ./$1 mount -n --bind $1 ./$1 (That -n is important if you don't want to muck up your /etc/mtab ) BTW, unshare is a fun command to play around with if you've never used namespaces. You can do things like replace commands by bind-mounting right over them. Rich
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jul 2012 15:27:41 -0400 Mike Gilbert flop...@gentoo.org wrote: Personally, I think a consolidated systemd/udev package is the best way to go here. A consolidated package means that: - every change made by udev developers would have to be reviewed by systemd team to make sure it doesn't break systemd. udev developers don't use systemd; - every change made by systemd developers would have to be reviewed by udev team to make sure it doesn't break openrc. systemd developers usually don't run openrc; - udev developers will force me to use eclasses they like and force their coding style on me; - i will force eclasses I like and my coding style on udev developers; - new udev wouldn't be able to be stabilized without systemd being stabilized at the same time (and I don't really think systemd is in any condition to go stable), - there will be a few random flags which will either work or not, depending on a state of magical switch flag, - and after all, the ebuild will be basically one big use-conditional. So, since this is blocking up development and people actually solving things, could we just have virtual/udev and be done with it? Upstream obviously reneged on their promise to make the component parts buildable separately, so the virtual seems like the only sane choice right now. /Peter
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On Thu, Jul 26, 2012 at 8:26 PM, Rich Freeman ri...@gentoo.org wrote: I've been messing around with namespaces and some of what systemd has been doing with them, and I have an idea for a portage feature. But before doing a brain dump of ideas, how useful would it be to have a FEATURE for portage to do a limited-visibility build? That is, the build would be run in an environment where the root filesystem appears to contain everything in a DEPEND (including @system currently) and nothing else? It might be useful both in development/testing, and also in production use (not sure how performance would work in the real world - I was able in a script to get it to build an enviornment in a few seconds for a few packages). You mean like cowbuilder? http://wiki.debian.org/cowbuilder I really crazy idea would be to try to run packages in a similar environment, but I think that needs better kernel/etc level support since the performance hit would be much more noticeable, except for things like daemons that only start once. Implementing it wouldn't necessarily be hard - just create a tmpfs under /var/tmp/portage, unshare off a new mount namespace, and read-only bind-mount everything needed from the root filesystem (including /var/tmp/portage/...), and chroot into it. When the build is done the process governing it terminates and the kernel wipes out all the mounts and then portage unmounts the tmpfs. You wouldn't need to use a tmpfs for the build - it would actually be zero-size as reported by df since it just contains a bazillion bind mounts, though all those mounts would consume slab memory. Thoughts? Rich
Re: [gentoo-dev] RFC: virtual/libudev
On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen peter.alfred...@gmail.com wrote: On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jul 2012 15:27:41 -0400 Mike Gilbert flop...@gentoo.org wrote: Personally, I think a consolidated systemd/udev package is the best way to go here. A consolidated package means that: - every change made by udev developers would have to be reviewed by systemd team to make sure it doesn't break systemd. udev developers don't use systemd; - every change made by systemd developers would have to be reviewed by udev team to make sure it doesn't break openrc. systemd developers usually don't run openrc; - udev developers will force me to use eclasses they like and force their coding style on me; - i will force eclasses I like and my coding style on udev developers; - new udev wouldn't be able to be stabilized without systemd being stabilized at the same time (and I don't really think systemd is in any condition to go stable), - there will be a few random flags which will either work or not, depending on a state of magical switch flag, - and after all, the ebuild will be basically one big use-conditional. So, since this is blocking up development and people actually solving things, could we just have virtual/udev and be done with it? Upstream obviously reneged on their promise to make the component parts buildable separately, so the virtual seems like the only sane choice right now. Just to clarify, udev/systemd never promised to make the component parts buildable separately. They promised: we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly. Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build. Where package only what is necessary being the important part for Gentoo. http://lwn.net/Articles/490413/ Certainly they don't care about source-based distributions like Gentoo, but they never promised to make the component parts buildable separately. Anyway, I also support the virtual/udev, since it's the only way for us systemd users to not build udev twice. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On 07/26/2012 11:26 AM, Rich Freeman wrote: Implementing it wouldn't necessarily be hard - just create a tmpfs under /var/tmp/portage, unshare off a new mount namespace, and read-only bind-mount everything needed from the root filesystem (including /var/tmp/portage/...), and chroot into it. When the build is done the process governing it terminates and the kernel wipes out all the mounts and then portage unmounts the tmpfs. You wouldn't need to use a tmpfs for the build - it would actually be zero-size as reported by df since it just contains a bazillion bind mounts, though all those mounts would consume slab memory. It seems like you might need some kind of copy-on-write support, at least to run pkg_setup. Apparently cowbuilder uses cow hardlinks for that. Another way would be to use fiemap (cp --reflink). -- Thanks, Zac
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On 7/26/2012 11:26 AM, Rich Freeman wrote: I've been messing around with namespaces and some of what systemd has been doing with them, and I have an idea for a portage feature. But before doing a brain dump of ideas, how useful would it be to have a FEATURE for portage to do a limited-visibility build? That is, the build would be run in an environment where the root filesystem appears to contain everything in a DEPEND (including @system currently) and nothing else? It might be useful both in development/testing, and also in production use (not sure how performance would work in the real world - I was able in a script to get it to build an enviornment in a few seconds for a few packages). In practice I think it's going to be very hard to make this work in a platform-independent way; however in principle this is a ridiculously sexy idea that has crossed my mind more than once. The challenge is that it requires either o Building very large sandboxes on a per-package basis or o Python-level access to unionfs/aufs-style COW features. Imagine the tree of dependencies which would need to be thrown together for, i.e.: kmail or firefox! This makes the former approach seem damn nearly infeasible. The latter approach holds more promise, I think, but represents a pretty big development effort. Still very sexy idea, if a python-fs-layering API could be coded up. One thing to consider: even if it does work, continuing to support the old way without fancy COW features is going to be required if portage is still going to support Gentoo/Alt in all of its flavors (either that, or unionfs/aufs features would need to be coded up for all those platforms that lack them). -gmt
[gentoo-dev] Re: RFC: virtual/libudev
Canek Peláez Valdés posted on Thu, 26 Jul 2012 17:08:35 -0500 as excerpted: Just to clarify, udev/systemd never promised to make the component parts buildable separately. They promised: we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly. Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build. Where package only what is necessary being the important part for Gentoo. http://lwn.net/Articles/490413/ Certainly they don't care about source-based distributions like Gentoo, but they never promised to make the component parts buildable separately. Anyway, I also support the virtual/udev, since it's the only way for us systemd users to not build udev twice. Actually, they did. 1) It's no secret that gentoo is build-from-source. 2) It's no secret that gentoo is in the distributions not wishing to adopt systemd class, at this point at least. 3) Gentoo's not a tiny micro-distribution, nor one based on some other distribution. Some may argue that gentoo and its ecosystem aren't Debian or Fedora-class, but it's certainly not too tiny to be considered a viable candidate for that distributions not wishing... class, which it's known to be in. 4) They promised, based on your quote: can build udev pretty much the same way as before, however should then use the systemd tarball [...] and package only what is necessary. 5) Building the same as before does *NOT* include building systemd. 6) Package, in the gentoo context, includes building, so ESPECIALLY given the promise to build udev pretty much the same as before, they DID promise that udev would be buildable separately. 7) What they specifically did NOT promise, in fact, quite to the contrary, was that it would be TARBALLed separately, which isn't a huge deal for gentoo, which already has whole desktops (kde) splitting individual packages out of monolithic combined tarballs. 8) The only way around that is if they try to argue point #3, saying gentoo and its ecosystem is /indeed/ too small to be included in the definition of distributions. 9) Otherwise, at very minimum, they're failing the build udev pretty much the same as before clause, if there's no provision within the tarball (such as separate make targets and source directories, with the systemd target not a dependency of udev target) to extract and build only udev, without building systemd as well. Not that such promises hold much credibility anyway... see the kde promise (from Aaron S when he was president of KDE e.v. so as credible a spokesperson as it gets) continued kde3 support as long as there were users. (AFAIK, at least gnome didn't make /that/ sort of promise in the leadup to gnome3. And no, AS cannot be properly argued to have been referring to others, like debian with its slow release cycles, as he was president of kde ev, not president of debian, or of the trinity project, which AFAIK didn't even exist at the time, and didn't specify support from OTHERS, not kde, so he was clearly speaking for kde, not for other entities.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: RFC: virtual/libudev
On Thu, Jul 26, 2012 at 9:37 PM, Duncan 1i5t5.dun...@cox.net wrote: [ snip ] 9) Otherwise, at very minimum, they're failing the build udev pretty much the same as before ./configure make make install You fail to see the matter from their POV. They don't care (that much) about building, because the distributions they care about use binary prebuilt packages. In that sense, build udev pretty much the same as before is the holly trinity of ./configure; make; make install. Otherwise the part about package only what is necessary has not that much sense. Which again leads to the please, add a virtual/udev so the people using systemd don't need to built udev twice. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Detecting ignored *FLAGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/2012 01:44 PM, Diego Elio Pettenò wrote: Il 23/07/2012 10:30, Rick Zero_Chaos Farina ha scritto: Those are two very valid reasons why we can't add these to the profiles, but do you have any suggestions on how we can get more than just yourself running this QA? Add it to the dev profile (I think we have one?) via bashrc, then we should have something. If something breaks on a dev box, I'd say the best effort can be made to fix it. So are we all in agreement to add the needed flags stuff to the dev profile? Anyone want to opt out of may I drop it in base? I would REALLY like to cut down on things like what I saw when I upgraded today: * Messages for package app-emulation/emul-linux-x86-baselibs-20120520: * QA Notice: Missing soname symlink(s): * * usr/lib32/libgnuintl.so.8 - preloadable_libintl.so * * QA Notice: Missing soname symlink(s): * * usr/lib32/libgnuintl.so.8 - preloadable_libintl.so * * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /lib32/libpam.so.0.83.1 * /lib32/libgpm.so.1.20.0 * /lib32/libudev.so.0.11.5 * /lib32/libblkid.so.1.1.0 * /lib32/libhistory.so.6.2 * /lib32/libmount.so.1.1.0 * /lib32/libgudev-1.0.so.0.1.0 * /lib32/libe2p.so.2.3 * /lib32/libbz2.so.1.0.6 * /lib32/libacl.so.1.1.0 * /lib32/libpamc.so.0.82.1 * /lib32/libcrack.so.2.8.1 * /lib32/libncurses.so.5.9 * /lib32/libuuid.so.1.3.0 * /lib32/libkeyutils-1.2.so * /lib32/libcom_err.so.2.1 * /lib32/libreadline.so.6.2 * /lib32/libpcre.so.0.0.1 * /lib32/libpwdb.so.0.62 * /lib32/libncursesw.so.5.9 * /lib32/libusb-0.1.so.4.4.4 * /lib32/libnss_ldap-2.14.1.so * /lib32/libext2fs.so.2.4 * /lib32/libwrap.so.0.7.6 * /lib32/libz.so.1.2.5 * /lib32/libattr.so.1.1.0 * /lib32/libtirpc.so.1.0.10 * /lib32/libpam_misc.so.0.82.0 * /lib32/security/pam_filter.so * /lib32/security/pam_motd.so * /lib32/security/pam_wheel.so * /lib32/security/pam_mkhomedir.so * /lib32/security/pam_localuser.so * /lib32/security/pam_timestamp.so * /lib32/security/pam_xauth.so * /lib32/security/pam_succeed_if.so * /lib32/security/pam_listfile.so * /lib32/security/pam_umask.so * /lib32/security/pam_debug.so * /lib32/security/pam_userdb.so * /lib32/security/pam_keyinit.so * /lib32/security/pam_mail.so * /lib32/security/pam_ldap.so * /lib32/security/pam_namespace.so * /lib32/security/pam_stress.so * /lib32/security/pam_nologin.so * /lib32/security/pam_exec.so * /lib32/security/pam_securetty.so * /lib32/security/pam_rhosts.so * /lib32/security/pam_tally.so * /lib32/security/pam_deny.so * /lib32/security/pam_ftp.so * /lib32/security/pam_pwhistory.so * /lib32/security/pam_faildelay.so * /lib32/security/pam_shells.so * /lib32/security/pam_warn.so * /lib32/security/pam_permit.so * /lib32/security/pam_env.so * /lib32/security/pam_echo.so * /lib32/security/pam_lastlog.so * /lib32/security/pam_rootok.so * /lib32/security/pam_issue.so * /lib32/security/pam_tally2.so * /lib32/security/pam_group.so * /lib32/security/pam_unix.so * /lib32/security/pam_access.so * /lib32/security/pam_cracklib.so * /lib32/security/pam_filter/upperLOWER * /lib32/security/pam_limits.so * /lib32/security/pam_time.so * /lib32/security/pam_loginuid.so * /lib32/libss.so.2.0 * Messages for package app-emulation/emul-linux-x86-db-20120520: * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /usr/lib32/mysql/libmysqlclient_r.so.16.0.0 * /usr/lib32/mysql/plugin/ha_innodb_plugin.so.0.0.0 * /usr/lib32/mysql/libmysqlclient.so.16.0.0 * /usr/lib32/libodbccr.so.2.0.0 * /usr/lib32/libodbcinst.so.2.0.0 * /usr/lib32/libmyodbc5-5.1.6.so * /usr/lib32/libodbc.so.2.0.0 * Messages for package app-emulation/emul-linux-x86-opengl-20120520: * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /usr/lib32/libglut.so.3.9.0 * /usr/lib32/libGLESv1_CM.so.1.1.0 * /usr/lib32/libdrm_nouveau.so.1.0.0 * /usr/lib32/libGLEWmx.so.1.6.0 * /usr/lib32/egl/egl_gallium.so * /usr/lib32/mesa/vmwgfx_dri.so * /usr/lib32/mesa/nouveau_dri.so * /usr/lib32/mesa/r300g_dri.so * /usr/lib32/mesa/r300_dri.so * /usr/lib32/mesa/r200_dri.so * /usr/lib32/mesa/unichrome_dri.so * /usr/lib32/mesa/savage_dri.so * /usr/lib32/mesa/i965_dri.so * /usr/lib32/mesa/sis_dri.so * /usr/lib32/mesa/i965g_dri.so * /usr/lib32/mesa/r600g_dri.so * /usr/lib32/mesa/r128_dri.so * /usr/lib32/mesa/nouveau_vieux_dri.so * /usr/lib32/mesa/i915_dri.so * /usr/lib32/mesa/i915g_dri.so * /usr/lib32/mesa/i810_dri.so * /usr/lib32/mesa/mga_dri.so * /usr/lib32/mesa/swrast_dri.so * /usr/lib32/mesa/tdfx_dri.so * /usr/lib32/mesa/r600_dri.so * /usr/lib32/mesa/swrastg_dri.so * /usr/lib32/mesa/mach64_dri.so * /usr/lib32/mesa/radeon_dri.so * /usr/lib32/libEGL.so.1.0 *
