Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/02/13 05:27, Peter Stuge wrote: I, as another user, prefer not to have a whole bunch of firmware installed if I only want one or two of them. +1. Also licences. It's a mess. Not suggesting that *I* have the magic-unicorn-land-perfect solution at hand though. On 09/02/13 10:09, Samuli Suominen wrote: Maybe you don't understand how linux-firmware package works. It only installs what you want -- it uses the savedconfig eclass to handle a list of wanted firmwares. I admit I never bothered to trim down my install of it, but the point is YOU CAN do it. Please correct me if I'm wrong, but this sounds like opt-out. I very much dislike opt-out. - -- 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/ iF4EAREIAAYFAlEYs9sACgkQRtClrXBQc7VAzAD/aJu22LzmrX1gYWl3BgqDslHP Zcpy+RXkGOgpqEY7tlkA/0jrJIdr8EyeMx2mgM8ccY/RX4X5U0q0hVjRfCv2QkZe =phoR -END PGP SIGNATURE-
Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 11/02/13 03:01, Alexis Ballier wrote: Sorry, I was away this week end... Not a problem, I should be reachable anytime today. 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. The reasons about that could be multiple, the facts are those. If you want you application to run in both you pick the Libav 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/'. Not really, the resample library idea was brewing for long even pre-fork, it got released first on FFmpeg because there is this bulimic tendency to add more features in order to be compelling in FFmpeg. I said already what happened when I started to develop the pulse capture and the generic segmenter in my github as another example of stuff developed by unrelated people and curiously landing before deemed ready by the author in ffmpeg git. (prores could be considered yet another funny example). 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. libavfilter is deemed still not ready for general consumption in Libav and just the set of calls that won't change (hopefully) in the future are provided. Meanwhile we are trying to make the whole buffer management less copy-happy and a little more rational. (not sure if you tried to use libavfilter but it is a _bit_ hard to use if compared to vlc filter layer and such) (I'm still looking forward a patch for xbmc and upstreamed patches for mplayer btw) I might spend a little time. 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. The ebuild supports extra parameters for that specific purpose. 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. Nobody is perfect and not everybody has the time to track another project tree every day. 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. That speaks a *bit* about the general support maybe? 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? I have no opinion, I stayed out of the discussion and decision about that before because I know I have a bias. I let other people decide. 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. You can, if you really want, offset ffmpeg so it doesn't clash with Libav. ... and chrome, mplayer, xbmc use ffmpeg :=) Chrome uses its own fork, reverting some changes form FFmpeg and picking what they deem useful. mplayer changes ffmpeg when they need something as they please xbmc used the newimproved libavfilter API to access swscale, the restricted api seems to work just fine. Probably true, but I still consider a quick fix disabling the
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 12:25:36 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 11/02/13 03:01, Alexis Ballier wrote: Sorry, I was away this week end... Not a problem, I should be reachable anytime today. Will ping you. 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. The reasons about that could be multiple, the facts are those. If you want you application to run in both you pick the Libav API. Well, then this raises the question: If libav does not care about what is done around it, why should we care about libav? 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/'. Not really, the resample library idea was brewing for long even pre-fork, it got released first on FFmpeg because there is this bulimic tendency to add more features in order to be compelling in FFmpeg. There was a need for it, FFmpeg made it available with 0.10, one year before libav-9. Why not re-using libswr into libav, possibly reworking it entirely but offering a compatible API? This all sounded to me like 'we do not care, users and applications can take the mess, it is not our problem'. There is a problem we are facing today: Some audio decoders started to output planar audio when historically ffmpeg/libav audio decoders produced only iterleaved audio, how do you suggest to fix this in applications? Manually converting planar audio to interleaved (ala mplayer)? This does not seem very future-proof, this will have to be adapted everytime a new format is added (which will not change lib major and thus break application at runtime for poor usage of the provided API). Or maybe use a library as a fallback that ensures you it will be able to convert any audio format produced by ffmpeg/libav to what you need (ala xbmc)? Which one to chose? If I want to support ffmpeg then I have to use libswr, because that is the one that has this property; If I want to support libav, then I have to use libavr... All of this because ~10 people cannot work together, well, really, thank you :) I said already what happened when I started to develop the pulse capture and the generic segmenter in my github as another example of stuff developed by unrelated people and curiously landing before deemed ready by the author in ffmpeg git. (prores could be considered yet another funny example). Can you point out any important problem? Otherwise, this is simply how open source work: this has been published with a free enough license, if I were working on these parts I'd not start from scratch but from the code available to me... If you want to avoid this, don't publish it or publish it with a restrictive license and relicense your code once pushing to libav. Another funny example are the multithreaded decoders (ffmpeg-mt), which was one of the main publicity material at the beginning of libav, and suffered from numerous problems in the early days... nevertheless it was merged by libav. You are criticizing something that has been done on both sides :) 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. libavfilter is deemed still not ready for general consumption in Libav and just the set of calls that won't change (hopefully) in the future are provided. Meanwhile we are trying to make the whole buffer management less copy-happy and a little more rational. (not sure if you tried to use libavfilter but it is a _bit_ hard to use if compared to vlc filter layer and such) Yes, well, if forces were not scattered due to the split then I'm pretty sure libavfilter would be in a much better state. IIRC, ffmpeg's libavfilter is much more 'copy-less' than current libav's version. [...] 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. Nobody is perfect and not everybody has the time to track another project tree every day. As a Gentoo developer, if you notice a bug in a package, usually the first thing you do is pull upstream's trunk repo and see if there is a fix available. If you don't do that,
[gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
Hi, virtual/libusb:0 has: RDEPEND=|| ( =dev-libs/libusb-compat-0.1.4 =dev-libs/libusb-0.1.12-r7:0 =sys-freebsd/freebsd-lib-8.0[usb] ) However, after building a system from stage3, I still ended with dev-libs/libusb:0 instead of dev-libs/libusb-compat (whereas stage3 has no libusb at all): # equery d libusb * These packages depend on libusb: app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1) app-crypt/gnupg-2.0.19 (usb ? virtual/libusb:0) dev-libs/openobex-1.5 (usb ? virtual/libusb:0) media-libs/libmtp-1.1.5 (virtual/libusb:1) net-libs/libpcap-1.3.0-r1 (canusb ? virtual/libusb) net-wireless/bluez-4.101-r5 (usb ? virtual/libusb:0) sys-apps/pcsc-lite-1.8.6 (libusb ? virtual/libusb:1) sys-apps/usb_modeswitch-1.2.5_p20121109 (virtual/libusb:0) sys-apps/usbutils-006 (virtual/libusb:1) virtual/libusb-0 (=dev-libs/libusb-0.1.12-r7:0) virtual/libusb-1 (=dev-libs/libusb-1.0.9:1) Any idea on what's going on? BFS instead of DFS search when satisfying ||? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2013 11:27 PM, Peter Stuge wrote: 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. Then you, as a user, should use savedconfig or come up with an alternate suggestion for how to handle this. I really am open to a better why to pick firmware that needs to be installed, but maintaining hundreds of individual packages is not that way. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGQABAAoJEKXdFCfdEflKUrwQAKK++u/KTXtO6ELDc13sx8mr uNNVhaIj+kAthnpkeRXovobdZb6X2TOYnMOjfrwQcahgPuKjeh+xLL0dLGorIGC2 F0XQj8MQPI1EeNNK8evZxWEjzT4UNYovsmOq5m9k4ZMpEMzFJ+N7KLsMV51enpXn CSmw7/ZaNDoGFl0t0cLuBGLkz8TbOQ4Elsqm0O5GduSI8S72Zc78Or++sPOWgxG2 BrcYzlljgrM+kjaCuejQFd+Mn+9jF+STuZcZtGiDCa5bQlRLfbdlqRmVKMkBEHa1 vV3DqHPm2ywC/dbsmWP9PoFUrG2Nm63V1g/B+/WQBIeAZyKGWoKz1B9W0xRazlQs Axnpy61TOxzH+SJ/Z6w2BHuXqabIsgLFOjmq7u4hnJFg1CXESNG5E5tFE4XBskjr sf6UcAZLCtUxgA/2QQd+fUPndbVfFr11XC1xpHqi3jMoJCG+kNxSeVdzyZx5l+iG NcCAXujuoUehvkpEmcyCAjKL8gXOsHsfkEUxhQC91u8w8cddi3nfYyY6mLGuxJzG M9ZKns+iRvkZSVPYC1ffzFxhvwa8jMFwMI7/qCGVxTm6Mgt00zyjr7sfcem1qEvL NGsaY9htKSjYDXuUkqVBmYBtRAE9AYZCgt87sY6PfqffQrMKDxyO6Hg8zWG+YlDB adFQPPJ7AABr4du4NdNw =Qpzc -END PGP SIGNATURE-
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2013 04:03 AM, Alexander Berntsen wrote: On 11/02/13 05:27, Peter Stuge wrote: I, as another user, prefer not to have a whole bunch of firmware installed if I only want one or two of them. +1. Also licences. It's a mess. Not suggesting that *I* have the magic-unicorn-land-perfect solution at hand though. On 09/02/13 10:09, Samuli Suominen wrote: Maybe you don't understand how linux-firmware package works. It only installs what you want -- it uses the savedconfig eclass to handle a list of wanted firmwares. I admit I never bothered to trim down my install of it, but the point is YOU CAN do it. Please correct me if I'm wrong, but this sounds like opt-out. I very much dislike opt-out. I'm sorry but emerge linux-firmware is not opt-out that would be the opposite. You are specifically opting in by installing it (as you are with ANY package in gentoo). Nothing pulls in linux-firmware afaik you must install it manually. If you don't like how much is installed use savedconfig or just download the firmware you need and drop it in place and when it breaks you know to update. We didn't cause this issue, as a whole the kernel community is no longer accepting new firmware in the kernel tree. All of it is moved into linux-firmware. Honestly I don't understand why people want broken hardware, but if you do, by all means don't install linux-firmware. Years ago firmware was just included, you always got it, and no one complainedgood times. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGQDFAAoJEKXdFCfdEflKZWEP/jzRjF4fFPyEWQpP8+I8ic5/ aD12BhB1VFWWjgAGAuFWiv9L3kJk+FttW6yUYNpXORA1OOp82l3n30f6pU/q4dG6 E0XvZsfKemvgjaZwWQTJzQHPkDMX2mYhSLb+e6YTxXh78W+g+NhAYqcnYhPlUkFF RUslsAwitLXj3zqCGflwYSmX1V5rbZX+TNvXlR2hHzfrAVMYwlMPV8m69YsLODN5 OhUMFybul5XXoxMp3uGaMYS7U03TU0atr7eSK8F6U4ggKqkvD8F/dZa+yRehFu0E 3Hym/QlWPNwluYBvkoXs+w6Y62NV0VbdqzAEWaofxhBCO8Tm8zSgeFAlrn7T5NgL X3GSPe69P9tkTYOLavstW+g7uYDX+1bPzjltuHnhM5f5r69UVA8Tdu94K4PsxsmH lmvXsMIieT7VHq0op9wbxEXwebPvcK0GeYUwKwB3AftjbH0zFSTX1RtkFXQ+yRid RNPcAkmu8JTknUjhOd+2lfyqOuptT5xqY+0ZRlXZyxrvJHmC/EqMD/3xJRH/YPwK +8Q5ZCJKvDY0TaC+I06Bh3hToXnCTH5gyVuOvxRM67wM1z8cJsFIY7ZkmxtLaxEh L+//l3SvWFEfab3HkL090JdLCRLTWYf/FlDdtD3voKQTwupZENmbAglNy7LbpJ9h OkDR4QWjHWQeSeITjwUz =grUv -END PGP SIGNATURE-
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
Maxim Kammerer wrote: * These packages depend on libusb: One stands out: app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1) app-crypt/gnupg-2.0.19 (usb ? virtual/libusb:0) dev-libs/openobex-1.5 (usb ? virtual/libusb:0) media-libs/libmtp-1.1.5 (virtual/libusb:1) net-libs/libpcap-1.3.0-r1 (canusb ? virtual/libusb) This one has no slotted dependency. Does that matter? In any case it doesn't seem completely correct, since the two APIs are not compatible. Any idea on what's going on? BFS instead of DFS search when satisfying ||? Seems a good explanation.. Can you try swapping the two in the virtual? //Peter
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 11/02/2013 16:17, Peter Stuge wrote: Any idea on what's going on? BFS instead of DFS search when satisfying ||? Seems a good explanation.. Can you try swapping the two in the virtual? Or not. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: On the good usage of subslots
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/02/13 07:52 AM, Alexis Ballier wrote: On Sat, 09 Feb 2013 23:38:35 +1100 Michael Palimaka kensing...@gentoo.org 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. That isn't so much of a concern, imo, as the sub-slot introduction (and therefore change) will most likely not occur on a library until that library is bumped (ie, when an upgrade occurs on the library and therefore also a rebuild of rdeps) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEZENUACgkQ2ugaI38ACPDKtAD8CLuyIbPH7yhzYj0hsShlLgkU LJkJCrtnureSz9dyUPgA/R0GMc71Oys9K62E6p+Qye+xg1AQdP8iEj6IHSFhzv0+ =sxVB -END PGP SIGNATURE-
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 02/11/2013 06:18 AM, Maxim Kammerer wrote: Any idea on what's going on? BFS instead of DFS search when satisfying ||? It searches from left to right. If you can reproduce the problem, then please create a debug logs as follows, and attach it to a bug on bugs.gentoo.org: emerge [args] --pretend --debug debug.log 21 xz -9 debug.log -- Thanks, Zac
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On Mon, Feb 11, 2013 at 5:17 PM, Peter Stuge pe...@stuge.se wrote: net-libs/libpcap-1.3.0-r1 (canusb ? virtual/libusb) This one has no slotted dependency. Does that matter? In any case it doesn't seem completely correct, since the two APIs are not compatible. It doesn't matter in this case, because canusb is disabled anyway. The real dependencies are: app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1) dev-libs/libusb-compat-0.1.4 (virtual/libusb:1) dev-libs/openobex-1.5 (usb ? virtual/libusb:0) media-libs/libmtp-1.1.5 (virtual/libusb:1) net-wireless/bluez-4.101-r5 (usb ? virtual/libusb:0) sys-apps/usb_modeswitch-1.2.5_p20121109 (virtual/libusb:0) sys-apps/usbutils-006 (virtual/libusb:1) virtual/libusb-0 (=dev-libs/libusb-0.1.12-r7:0) virtual/libusb-1 (=dev-libs/libusb-1.0.9:1) Any idea on what's going on? BFS instead of DFS search when satisfying ||? Seems a good explanation.. Can you try swapping the two in the virtual? BFS and DFS both work left-to-right, but in absence of both dev-libs/libusb:0 or :1, the path via libusb-compat to dev-libs/libusb:1 is longer than the immediate path to dev-libs/libusb:0. I think libusb-compat was selected correctly previously (a few months ago), so perhaps and update in portage caused the issue. On the other hand, this is just a hypothesis. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 02/11/2013 07:42 AM, Maxim Kammerer wrote: On Mon, Feb 11, 2013 at 5:17 PM, Peter Stuge pe...@stuge.se wrote: net-libs/libpcap-1.3.0-r1 (canusb ? virtual/libusb) This one has no slotted dependency. Does that matter? In any case it doesn't seem completely correct, since the two APIs are not compatible. It doesn't matter in this case, because canusb is disabled anyway. The real dependencies are: app-crypt/ccid-1.4.8 (usb ? virtual/libusb:1) dev-libs/libusb-compat-0.1.4 (virtual/libusb:1) dev-libs/openobex-1.5 (usb ? virtual/libusb:0) media-libs/libmtp-1.1.5 (virtual/libusb:1) net-wireless/bluez-4.101-r5 (usb ? virtual/libusb:0) sys-apps/usb_modeswitch-1.2.5_p20121109 (virtual/libusb:0) sys-apps/usbutils-006 (virtual/libusb:1) virtual/libusb-0 (=dev-libs/libusb-0.1.12-r7:0) virtual/libusb-1 (=dev-libs/libusb-1.0.9:1) Any idea on what's going on? BFS instead of DFS search when satisfying ||? Seems a good explanation.. Can you try swapping the two in the virtual? BFS and DFS both work left-to-right, but in absence of both dev-libs/libusb:0 or :1, the path via libusb-compat to dev-libs/libusb:1 is longer than the immediate path to dev-libs/libusb:0. I think libusb-compat was selected correctly previously (a few months ago), so perhaps and update in portage caused the issue. On the other hand, this is just a hypothesis. There has been no change in the portage behavior. Since libusb-compat is on the left, it's supposed to be preferred. -- Thanks, Zac
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On Mon, Feb 11, 2013 at 5:40 PM, Zac Medico zmed...@gentoo.org wrote: If you can reproduce the problem, then please create a debug logs as follows, and attach it to a bug on bugs.gentoo.org: Can't reproduce with stage3 + emerge -upvDN. :/ I will look out for this issue in full system builds in the future. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
Diego Elio Pettenò wrote: Can you try swapping the two in the virtual? Or not. I guess that you assumed that I suggested to test this in-tree, so I guess I should clarify that I would expect it to be tested in PORTDIR_OVERLAY. If my guess is correct then you are really way too eager to misunderstand what people intend to transmit, given a less than unambiguous message. In the future, please give me (and why not others) the benefit of the doubt, and ask for clarification if I suggest something that seems like a bad idea to you. It does require more email round trips, but the end result is not only a positive discussion which promotes greater understanding for active and passive participants alike - it also makes you seem much more sympathetic which can only be a good thing. //Peter
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 11/02/2013 17:44, Peter Stuge wrote: If my guess is correct then you are really way too eager to misunderstand what people intend to transmit, given a less than unambiguous message. No, it's because of what Maxim already said: it's not an LTR/RTL issue. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
Diego Elio Pettenò wrote: it's because of what Maxim already said: it's not an LTR/RTL issue. Do you have an idea about what the issue is? //Peter
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 11/02/2013 17:54, Peter Stuge wrote: Do you have an idea about what the issue is? No, but I'm pretty certain that it's not that, because the preference is and has been for a very long time LTR. Which happens to be one of the things the quizzes are there to ensure people know. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On 02/11/2013 08:54 AM, Peter Stuge wrote: Diego Elio Pettenò wrote: it's because of what Maxim already said: it's not an LTR/RTL issue. Do you have an idea about what the issue is? My guess is that there were one or more ebuilds that inappropriately specified dev-libs/libusb:0 instead of virtual/libusb:0, and they have since been fixed. -- Thanks, Zac
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
Zac Medico wrote: My guess is that there were one or more ebuilds that inappropriately specified dev-libs/libusb:0 instead of virtual/libusb:0, and they have since been fixed. I believe they were all changed some months ago, but it's of course still possible if either the snapshot was old or if a new ebuild uses dev-libs. //Peter
Re: [gentoo-dev] libusb-compat preference in virtual/libusb:0 not strong enough?
On Mon, Feb 11, 2013 at 7:09 PM, Zac Medico zmed...@gentoo.org wrote: My guess is that there were one or more ebuilds that inappropriately specified dev-libs/libusb:0 instead of virtual/libusb:0, and they have since been fixed. I did the full build yesterday, with most recent stage3 and portage snapshot. All the involved ebuilds are older than the snapshot. I will try another full build tomorrow, and if the issue persists, try to uncover the culprit (naturally, my build script is somewhat more complex than emerge -upvDN @world I tried above, so hopefully the issue is reproducible). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 17:22:16 +0100 Peter Stuge pe...@stuge.se wrote: Alexis, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) Do you have experience from being in a similar situation? You are being quite judgemental. There are absolutely situations where people so different that cooperation simply can't work. It's pretty lame, but unless you yourself participate at least on the same level as everyone else (on both sides) you really don't get much of a say. Yes, sorry, I now realize what I wrote is understood differently from what I meant. I was not criticizing the people, but rather the current situation. Luca is the one to ask if you want to know more about this, certainly not me. I am simply a consumer annoyed of having to write more and more complicated code to support both sides. I am aware that the split did not come out of nothing, and considering the vast majority of core FFmpeg developers by that time are now involved in libav, libav is likely to be the side of 'those who are right'. However, as I said, maybe with an incorrect tone, I do not think libav ignoring what happens in ffmpeg to be a pragmatic attitude and believe it is mainly hurting applications trying to do their best in supporting both, and users wanting the extra bugfixes or featues from ffmpeg or the better review process from libav. The critic was directed towards this, which I believe should be orthogonal to the reasons of the split. Finally, I would really love to see some will in reopening the discussions, be it to merge back (I think that's very unlikely, but let's not lose hope) or to decide that there is nothing more to be done and find a sane way out of this lose-lose situation (soname change, or anything better). It's easy to tell people to stop fighting, just get along - but I believ that intentional fighting is quite rare. It's more likely about trying to make one's point. That requires communication, but communication is not always possible. (I don't mean transmissions back and forth, I mean desire to understand the transmissions.) For a long time I idealized open source as being an ideal community, where communication always worked because everyone wanted it to. But that's unfortunately not at all the case. Yep, thanks for shaking me on this, it seems I should reread twice before hitting send on an email since I fell in the same trap. Again, apologies if what I wrote has been taken personally, esp. to those that tried their best to avoid the split. [...] I consider FFmpeg superior, but can understand there are different opinions, however, if this is to lower the tree quality Quality is not a very helpful metric, because it means completely different things for different people. Some people value code readability, maintainability, and correctness very high, other people value having a new idea halfway implemented and released even if it only kindasorta works and is not at all reliable and not on par with previous parts of the code. I see a tendency in myself and in others to not care about what happens on the inside when thinking merely as a user. I see many many people complain about the insides when they are not happy with how it performs. I very rarely see people actually dig in to help fix up the insides. The same pattern exists in pretty much all projects that I know of, and it is quite natural - there are more users than developers. Quality here is: Everything that works with FFmpeg works with libav, and vice-versa. Once that is true, then the default can be what is deemed better. In this precise case it is controversial, so once everyone has expressed his arguments and reasons then default should be what the majority prefers (and here, it seems the majority goes with libav). [...] libav should realize they are the actual fork (this is now pretty clear since the takeover failed and ffmpeg didn't collapse...) and also rename their libraries so that the internal libav/ffmpeg fights would not affect their users anymore and projects could use what they think best... Unless libav considers the API too broken to still be functional I don't see the point of differentiation. A little bit of competition can be good overall even though it is more stressful for both sides. The most important thing is what I asked for already - That users inform themselves, and make informed decisions. For distributors it does matter: if we start to have libav-only or ffmpeg-only packages then users get the choice on what package to use, not the implementation. If there is a differentiation, then upstream decides what they think is best and that's about it. It would not kill competition, rather the contrary I believe. Alexis.
[gentoo-dev] Last rites: dev-ruby/rails:3.0
# Hans de Graaff h...@degraaff.org (11 Feb 2013) # No longer supported upstream even for security bugs. # Port your application to another version of Rails. # The Rails 3.0 version in the tree has security issues # and no new 3.0 versions will be released anymore. dev-ruby/rails:3.0 dev-ruby/railties:3.0 dev-ruby/activerecord:3.0 dev-ruby/actionmailer:3.0 dev-ruby/actionpack:3.0 dev-ruby/activeresource:3.0 dev-ruby/activemodel:3.0 dev-ruby/activesupport:3.0 dev-ruby/arel:2.0 dev-ruby/i18n:0.5 dev-ruby/rack-mount:0.6 dev-ruby/rack-test:0.5 dev-ruby/mysql2:0.2
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Alexis - thanks a lot for the awesome response! Alexis Ballier wrote: 'those who are right' (Just a note that I am in no way invested in libav/ffmpeg, I merely speak from experience with another fork.) However, as I said, maybe with an incorrect tone, I do not think libav ignoring what happens in ffmpeg to be a pragmatic attitude and believe it is mainly hurting applications trying to do their best in supporting both, and users wanting the extra bugfixes or featues from ffmpeg or the better review process from libav. Thanks for clarifying that! And I completely agree with you. Especially with forks it's important to keep compatibility a high priority in all projects. The critic was directed towards this, which I believe should be orthogonal to the reasons of the split. Yes, I agree also with that. Separate issues. Finally, I would really love to see some will in reopening the discussions, I guess it was some years ago, but maybe some more time still is good. I know no details, I only recognize the pattern. For a long time I idealized open source as being an ideal community, where communication always worked because everyone wanted it to. But that's unfortunately not at all the case. Yep, thanks for shaking me on this, it seems I should reread twice before hitting send on an email since I fell in the same trap. It's easy. I did too. Again, apologies if what I wrote has been taken personally, esp. to those that tried their best to avoid the split. Not me - but if someone did feel bad about what you wrote I am very sure that they appreciate this! Quality is not a very helpful metric, because it means completely different things for different people. Quality here is: Everything that works with FFmpeg works with libav, and vice-versa. Agree API compatibility is very important. (and here, it seems the majority goes with libav) I for one am sadly uninformed and can not make a decision. :( Unless libav considers the API too broken to still be functional I don't see the point of differentiation. For distributors it does matter: if we start to have libav-only or ffmpeg-only packages then users get the choice on what package to use, not the implementation. Ah! Yes, but that is just a function of what happens upstream, and nothing that can ever really be a distribution's job to resolve. If anything, I think that incompatibilities showing through in the distribution can only help users become more informed about what happens upstream. It can be argued that they shouldn't have to be informed - but actually I don't mind that. It's good to be aware of what is going on even a few layers down. I know that this is not a very common attitude, but I think for Gentoo in particular it wouldn't be bad at all. If there is a differentiation, then upstream decides what they think is best and that's about it. It would not kill competition, rather the contrary I believe. You're right that there would possibly be more activity in both projects if they were going fast in their own direction. On the other hand that fragments the user base (applications) and everyone is already invested in the common API, so I can understand that moving away from that also isn't very desirable. Anyway - good thoughts. Thanks again! //Peter
Re: [gentoo-dev] On the good usage of subslots
AB == Alexis Ballier aball...@gentoo.org writes: AB Well, if we have to advertise the usage of this option that basically AB disables subslot rebuilds, it only means we are doing something AB seriously wrong with subslots :=) So far, I've found the sub slots to be more of a pain in the ass than helpful. They get in the way of things like automated 'emerge --sync;emerge -upvDN', since portage craps out complaining about the subslots rather than showing the list of what need to be built. Perhaps that is just an implementation detail to be worked out, but for now they haven't done anything helpful here. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Your whole email is derailing a bit from discussing the code at hand and it is going deep down on the people, I'd rather not get there since it gets totally unrelated the question at hand. On 11/02/13 14:49, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. Sadly or luckily the whole thing ended with us (the majority) having to give up the name and picking a different one. Hopefully that's the last time I have to touch this point here. lu
Re: [gentoo-dev] On the good usage of subslots
On 2013-02-11, at 3:53 PM, James Cloos cl...@jhcloos.com wrote: AB == Alexis Ballier aball...@gentoo.org writes: AB Well, if we have to advertise the usage of this option that basically AB disables subslot rebuilds, it only means we are doing something AB seriously wrong with subslots :=) So far, I've found the sub slots to be more of a pain in the ass than helpful. They get in the way of things like automated 'emerge --sync;emerge -upvDN', since portage craps out complaining about the subslots rather than showing the list of what need to be built. Perhaps that is just an implementation detail to be worked out, but for now they haven't done anything helpful here. this must be an implementation detail... the point of subslots and slot operators is to allow the revdep-rebuilds to be inlined so that low library updates don't break later application emerges during the -uDN ... the output should be the same as a emerge -uDNpv world plus a revdep-rebuild -p once everything is subslotted... it shouldn't affect your usual emerge process beyond that. is the conflict that emerge craps out on a subslot specific thing or is it a regular slot conflict made harder to read? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] On the good usage of subslots
On 02/11/2013 12:53 PM, James Cloos wrote: AB == Alexis Ballier aball...@gentoo.org writes: AB Well, if we have to advertise the usage of this option that basically AB disables subslot rebuilds, it only means we are doing something AB seriously wrong with subslots :=) So far, I've found the sub slots to be more of a pain in the ass than helpful. They get in the way of things like automated 'emerge --sync;emerge -upvDN', since portage craps out complaining about the subslots rather than showing the list of what need to be built. Perhaps that is just an implementation detail to be worked out, but for now they haven't done anything helpful here. It sounds like this bug: https://bugs.gentoo.org/show_bug.cgi?id=456340 I hope to have it fixed soon (maybe today). -- Thanks, Zac
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Luca Barbato wrote: May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? There was probably a reason for Fabrice to do that, and majority and democracy doesn't have much to do with it. It is more likely that 10 people are right than that 3 are, but a group of 10 is still quite small. I wouldn't mind reading about the backstory. Do you know of some good links beyond the two that were posted already? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. Sadly or luckily the whole thing ended with us (the majority) having to give up the name and picking a different one. I think the name itself doesn't matter much (FWIW I think libav is a much better name) but API compatibility is a big deal, and all branches should really make an effort to stay compatible. //Peter
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On Mon, 11 Feb 2013 22:04:43 +0100 Luca Barbato lu_z...@gentoo.org wrote: Your whole email is derailing a bit from discussing the code at hand and it is going deep down on the people, I'd rather not get there since it gets totally unrelated the question at hand. I'm not sure if you read my reply, but it was not meant at all as going down on the people. I realized it was understood as such and apologized, and apologize again here. On 11/02/13 14:49, Alexis Ballier wrote: All of this because ~10 people cannot work together, well, really, thank you :) May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? I'm perfectly happy to develop my code as long I'm not dragged in the mud with outlandish statement or people annoying the hell of me because they want to force me to merge because would be so better. It would be better. Nobody wants to force you to do anything though. I guess that answers my question on a possible reopening of the discussions. Well, you are talking to one of the two guys that spent about 3 months behind the scenes trying to compose the situation before it ended with the in theory normal demotion of a so-called Leader by democratic means. To be honest, I never understood why this had to be done by a takeover with such a majority of people, and always wondered why what seen publicly was only a poor leader asking for democracy but demoted by force (exagerating a bit). This surely encouraged people to support him. I guess I should ask you for more details in private. Alexis.
[gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
Hello, fellow developers, The current virtualx.eclass API is a bit insane. It seems a bit like stacking of a few next APIs, mostly designed to quickly run 'make check', then extended to general functions. For example running a function 'run_tests' with parameter '--foo' would look like: VIRTUALX_COMMAND=run_tests virtualmake --foo which is really awful, considering that '--foo' is a parameter to 'run_tests' and not virtualmake. My patches introduce a single wrapper with argv-as-parameter syntax. That is, the fore-mentioned example would look like: virtualx run_tests --foo Depending on the maintainer decisions and your feedback, I believe that even all the X* short-hand functions could be deprecated. They are a bit shorter: Xemake check vs: virtualx emake check but I don't think that's much of a difference. What are your thoughts?
[gentoo-dev] [PATCH virtualx.eclass 1/5] Introduce a cleaner alternative to VIRTUALX_COMMAND= virtualmake.
Let's get this straight:
VIRTUALX_COMMAND=foo virtualmake --bar --baz
is just ugly. Instead, introduce a function which can be used as:
virtualx foo --bar -baz
---
gx86/eclass/virtualx.eclass | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/gx86/eclass/virtualx.eclass b/gx86/eclass/virtualx.eclass
index 0621b18..47116fd 100644
--- a/gx86/eclass/virtualx.eclass
+++ b/gx86/eclass/virtualx.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/virtualx.eclass,v 1.43 2012/10/03
22:47:12 chithanh Exp $
@@ -69,11 +69,12 @@ case ${VIRTUALX_REQUIRED} in
;;
esac
-# @FUNCTION: virtualmake
+# @FUNCTION: virtualx
+# @USAGE: argv...
# @DESCRIPTION:
-# Function which attach to running X session or start new Xvfb session
-# where the VIRTUALX_COMMAND variable content gets executed.
-virtualmake() {
+# Attach to a running X session or start a new Xvfb session, then run
+# the command passed as arguments.
+virtualx() {
debug-print-function ${FUNCNAME} $@
local i=0
@@ -83,14 +84,6 @@ virtualmake() {
local XHOST=$(type -p xhost)
local xvfbargs=-screen 0 1280x1024x24
- # backcompat for maketype
- if [[ -n ${maketype} ]]; then
- ewarn QA: ebuild is exporting \$maketype=${maketype}
- ewarn QA: Ebuild should be migrated to use
VIRTUALX_COMMAND=${maketype} instead.
- ewarn QA: Setting VIRTUALX_COMMAND to \$maketype conveniently
for now.
- VIRTUALX_COMMAND=${maketype}
- fi
-
# If $DISPLAY is not set, or xhost cannot connect to an X
# display, then do the Xvfb hack.
if [[ -n ${XVFB} -n ${XHOST} ]] \
@@ -145,10 +138,10 @@ virtualmake() {
# to kill Xvfb
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
if has ${EAPI} 2 3; then
- ${VIRTUALX_COMMAND} $@
+ $@
retval=$?
else
- nonfatal ${VIRTUALX_COMMAND} $@
+ nonfatal $@
retval=$?
fi
@@ -158,16 +151,34 @@ virtualmake() {
debug-print ${FUNCNAME}: attaching to running X display
# Normal make if we can connect to an X display
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
- ${VIRTUALX_COMMAND} $@
+ $@
retval=$?
fi
# die if our command failed
- [[ ${retval} -ne 0 ]] die ${FUNCNAME}: the ${VIRTUALX_COMMAND}
failed.
+ [[ ${retval} -ne 0 ]] die ${FUNCNAME}: ${1} failed.
return 0 # always return 0, it can be altered by failed kill for Xvfb
}
+# @FUNCTION: virtualmake
+# @DESCRIPTION:
+# Function which attach to running X session or start new Xvfb session
+# where the VIRTUALX_COMMAND variable content gets executed.
+virtualmake() {
+ debug-print-function ${FUNCNAME} $@
+
+ # backcompat for maketype
+ if [[ -n ${maketype} ]]; then
+ ewarn QA: ebuild is exporting \$maketype=${maketype}
+ ewarn QA: Ebuild should be migrated to use
VIRTUALX_COMMAND=${maketype} instead.
+ ewarn QA: Setting VIRTUALX_COMMAND to \$maketype conveniently
for now.
+ VIRTUALX_COMMAND=${maketype}
+ fi
+
+ virtualx ${VIRTUALX_COMMAND} $@
+}
+
# @FUNCTION: Xmake
# @DESCRIPTION:
# Same as make, but set up the Xvfb hack if needed.
--
1.8.1.2
[gentoo-dev] [PATCH virtualx.eclass 4/5] Deprecate virtualmake in favor of the new syntax.
---
gx86/eclass/virtualx.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/virtualx.eclass b/gx86/eclass/virtualx.eclass
index 096c37a..f576335 100644
--- a/gx86/eclass/virtualx.eclass
+++ b/gx86/eclass/virtualx.eclass
@@ -172,12 +172,13 @@ virtualmake() {
# backcompat for maketype
if [[ -n ${maketype} ]]; then
- eqawarn ebuild is exporting \$maketype=${maketype}
- eqawarn Ebuild should be migrated to use
VIRTUALX_COMMAND=${maketype} instead.
- eqawarn Setting VIRTUALX_COMMAND to \$maketype conveniently
for now.
VIRTUALX_COMMAND=${maketype}
fi
+ eqawarn Using virtualmake is considered deprecated.
+ eqawarn Please use the new, cleaner API instead:
+ eqawarnvirtualx ${VIRTUALX_COMMAND}
+
virtualx ${VIRTUALX_COMMAND} $@
}
--
1.8.1.2
[gentoo-dev] [PATCH virtualx.eclass 5/5] (Optionally) deprecate all X* wrappers.
The new syntax seems simple enough that we can think of deprecating all
those short-hand forms.
---
gx86/eclass/virtualx.eclass | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/virtualx.eclass b/gx86/eclass/virtualx.eclass
index f576335..9d5045d 100644
--- a/gx86/eclass/virtualx.eclass
+++ b/gx86/eclass/virtualx.eclass
@@ -189,8 +189,10 @@ virtualmake() {
Xmake() {
debug-print-function ${FUNCNAME} $@
- eqawarn you should not execute make directly
- eqawarn rather execute Xemake -j1 if you have issues with parallel
make
+ eqawarn Using Xmake is considered deprecated.
+ eqawarn Please use the new, cleaner API instead:
+ eqawarnvirtualx emake -j1 ...
+
virtualx emake -j1 $@
}
@@ -200,6 +202,10 @@ Xmake() {
Xemake() {
debug-print-function ${FUNCNAME} $@
+ eqawarn Using Xemake is considered deprecated.
+ eqawarn Please use the new, cleaner API instead:
+ eqawarnvirtualx emake ...
+
virtualx emake $@
}
@@ -209,5 +215,9 @@ Xemake() {
Xeconf() {
debug-print-function ${FUNCNAME} $@
+ eqawarn Using Xeconf is considered deprecated.
+ eqawarn Please use the new, cleaner API instead:
+ eqawarnvirtualx econf ...
+
virtualx econf $@
}
--
1.8.1.2
[gentoo-dev] [PATCH virtualx.eclass 2/5] Use eqawarn from eutils.eclass.
Instead of ewarn QA: ...
---
gx86/eclass/virtualx.eclass | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/gx86/eclass/virtualx.eclass b/gx86/eclass/virtualx.eclass
index 47116fd..0da3066 100644
--- a/gx86/eclass/virtualx.eclass
+++ b/gx86/eclass/virtualx.eclass
@@ -9,6 +9,8 @@
# Original author: Martin Schlemmer aza...@gentoo.org
# @BLURB: This eclass can be used for packages that needs a working X
environment to build.
+inherit eutils
+
# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
# @DESCRIPTION:
# Variable specifying the dependency on xorg-server and xhost.
@@ -46,15 +48,15 @@ case ${VIRTUALX_REQUIRED} in
;;
optional|tests)
# deprecated section YAY.
- ewarn QA: VIRTUALX_REQUIRED=optional and
VIRTUALX_REQUIRED=tests are deprecated.
- ewarn QA: You can drop the variable definition completely from
ebuild,
- ewarn QA: because it is default behaviour.
+ eqawarn VIRTUALX_REQUIRED=optional and VIRTUALX_REQUIRED=tests
are deprecated.
+ eqawarn You can drop the variable definition completely from
ebuild,
+ eqawarn because it is default behaviour.
if [[ -n ${VIRTUALX_USE} ]]; then
# so they like to specify the useflag
- ewarn QA: VIRTUALX_USE variable is deprecated.
- ewarn QA: Please read eclass manpage to find out how
to use VIRTUALX_REQUIRED
- ewarn QA: to achieve the same behaviour.
+ eqawarn VIRTUALX_USE variable is deprecated.
+ eqawarn Please read eclass manpage to find out how to
use VIRTUALX_REQUIRED
+ eqawarn to achieve the same behaviour.
fi
[[ -z ${VIRTUALX_USE} ]] VIRTUALX_USE=test
@@ -170,9 +172,9 @@ virtualmake() {
# backcompat for maketype
if [[ -n ${maketype} ]]; then
- ewarn QA: ebuild is exporting \$maketype=${maketype}
- ewarn QA: Ebuild should be migrated to use
VIRTUALX_COMMAND=${maketype} instead.
- ewarn QA: Setting VIRTUALX_COMMAND to \$maketype conveniently
for now.
+ eqawarn ebuild is exporting \$maketype=${maketype}
+ eqawarn Ebuild should be migrated to use
VIRTUALX_COMMAND=${maketype} instead.
+ eqawarn Setting VIRTUALX_COMMAND to \$maketype conveniently
for now.
VIRTUALX_COMMAND=${maketype}
fi
@@ -186,8 +188,8 @@ virtualmake() {
Xmake() {
debug-print-function ${FUNCNAME} $@
- ewarn QA: you should not execute make directly
- ewarn QA: rather execute Xemake -j1 if you have issues with parallel
make
+ eqawarn you should not execute make directly
+ eqawarn rather execute Xemake -j1 if you have issues with parallel
make
VIRTUALX_COMMAND=emake -j1 virtualmake $@
}
--
1.8.1.2
[gentoo-dev] [PATCH virtualx.eclass 3/5] Convert X* functions to the new API.
---
gx86/eclass/virtualx.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/virtualx.eclass b/gx86/eclass/virtualx.eclass
index 0da3066..096c37a 100644
--- a/gx86/eclass/virtualx.eclass
+++ b/gx86/eclass/virtualx.eclass
@@ -190,7 +190,7 @@ Xmake() {
eqawarn you should not execute make directly
eqawarn rather execute Xemake -j1 if you have issues with parallel
make
- VIRTUALX_COMMAND=emake -j1 virtualmake $@
+ virtualx emake -j1 $@
}
# @FUNCTION: Xemake
@@ -199,7 +199,7 @@ Xmake() {
Xemake() {
debug-print-function ${FUNCNAME} $@
- VIRTUALX_COMMAND=emake virtualmake $@
+ virtualx emake $@
}
# @FUNCTION: Xeconf
@@ -208,5 +208,5 @@ Xemake() {
Xeconf() {
debug-print-function ${FUNCNAME} $@
- VIRTUALX_COMMAND=econf virtualmake $@
+ virtualx econf $@
}
--
1.8.1.2
Gentoo email address in VCS. Re: [gentoo-dev] Last rites: dev-ruby/rails:3.0
On 02/11/2013 09:39 PM, Hans de Graaff wrote: # Hans de Graaff h...@degraaff.org (11 Feb 2013) What about using your gentoo email address? One mapping less, please. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
I'd say, Go for it! But on the other hand I wonder if it might make sense to have something more generic, so that one only has to call something in a way such as virtualx_setup run_tests --foo virtualx_cleanup The reason why I'm wondering this is that we need some more virtual environments for testing purposes, really: so many packages need a D-Bus session (and I'd rather have them using a test session than a system one!), and at least in Ruby world we often need a database (sometimes more than one)... Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Mon, Feb 11, 2013 at 11:14 PM, Michał Górny mgo...@gentoo.org wrote: Hello, fellow developers, The current virtualx.eclass API is a bit insane. It seems a bit like stacking of a few next APIs, mostly designed to quickly run 'make check', then extended to general functions. For example running a function 'run_tests' with parameter '--foo' would look like: VIRTUALX_COMMAND=run_tests virtualmake --foo which is really awful, considering that '--foo' is a parameter to 'run_tests' and not virtualmake. My patches introduce a single wrapper with argv-as-parameter syntax. That is, the fore-mentioned example would look like: virtualx run_tests --foo Depending on the maintainer decisions and your feedback, I believe that even all the X* short-hand functions could be deprecated. They are a bit shorter: Xemake check vs: virtualx emake check but I don't think that's much of a difference. What are your thoughts?
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
On 11/02/13 22:33, Peter Stuge wrote: Luca Barbato wrote: May I point you that ~10 people were the majority of what was FFmpeg, thus 10 people were enough to demote democratically the so called Leader and that guy got the name from Fabrice as his personal decision? There was probably a reason for Fabrice to do that, and majority and democracy doesn't have much to do with it. It is more likely that 10 people are right than that 3 are, but a group of 10 is still quite small. I wouldn't mind reading about the backstory. Do you know of some good links beyond the two that were posted already? The reason behind Fabrice actions is probably the same behind me trying for 3 months to not having to go the way it went. I got to change my mind since I was involved, Fabrice hadn't been since ages and he is doing something totally different nowadays. Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. It is not related to users, is related to me being called as swine a traitor and having death threats. *Slightly* less technical than discussing API. I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. The rules in Libav are quite well defined and decently enforced. Again, if you have ~15 people and one is deemed misbehaving by more than 10, which is the fork? lu
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Luca Barbato wrote: Users will never be satisfied. But I guess you agree that API compatibility will certainly avoid extra problems for users. It is not related to users, I was trying to come back on topic. :) is related to me being called as swine a traitor and having death threats. *Slightly* less technical than discussing API. That is of course not acceptable under any circumstance. I'm sorry to hear that you had to deal with that. :( I don't think open source neccessarily is democracy, and of course a disagreement about something fairly fundamental such as that can be more than enough to cause a fork. The rules in Libav are quite well defined and decently enforced. Again, if you have ~15 people and one is deemed misbehaving by more than 10, which is the fork? The fork is always the younger group, but who is right and wrong is another matter. //Peter
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
Am Montag, 11. Februar 2013, 23:14:38 schrieb Michał Górny: What are your thoughts? Same as Diego I like the general idea, but an even more generic framework might make sense. Say test dbus session, say setting up some test file structure, ... Oh, and one more thing... please before you commit anything talk to the kde guys... we inherit virtualx.eclass everywhere via kde4-*.eclass so we can easily use it (and many many kde packages need it for the tests). Changes in virtualx.eclass already broke many kde packages once... [IMHO I'd say it's perfectly fine if you determine the best way to go without specific kde regression testing, but before it goes in we'd like to have a chance to adapt our eclasses...] -- 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] libusb-compat preference in virtual/libusb:0 not strong enough?
On Mon, Feb 11, 2013 at 8:05 PM, Maxim Kammerer m...@dee.su wrote: I will try another full build tomorrow, and if the issue persists, try to uncover the culprit (naturally, my build script is somewhat more complex than emerge -upvDN @world I tried above, so hopefully the issue is reproducible). Not reproducible this time: # emerge -upvDN --with-bdeps y @world | grep /libusb [ebuild N ] dev-libs/libusb-1.0.9:1 USE=-debug -doc -static-libs 413 kB [ebuild N ] virtual/libusb-1:1 0 kB [ebuild N ] dev-libs/libusb-compat-0.1.4 USE=-debug -static-libs 237 kB [ebuild N ] virtual/libusb-0 0 kB Oh well. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: Gentoo email address in VCS. Re: [gentoo-dev] Last rites: dev-ruby/rails:3.0
On Mon, 2013-02-11 at 23:30 +0100, Michael Weber wrote: On 02/11/2013 09:39 PM, Hans de Graaff wrote: # Hans de Graaff h...@degraaff.org (11 Feb 2013) What about using your gentoo email address? One mapping less, please. Too much autopilot, it seems. Fixed. Hans
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. Sometimes it seems that endless mailing list threads are the Gentoo way, its a surprise we get anything done! Ian
