Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 05:53 AM, Diego Elio Pettenò wrote: Does this mean the QA lead finally gets to suspend people who are patently not suited for developing a stable distribution without asking devrel? Because last time we got into the same judge, jury, and executioner argument, which I guess was just sent for the gallows (pun intended). I'm not against that, but I prefer setting some fast track involving at most 3 people and some procedure also for it. E.g. : you can ask for 6h suspension on direct request and by contacting a single devrel person to get an 1week suspension within 2 days. Mind, it's not like I disagree with at least one of the actions that you took recently, but given your surge approach I would like to point out that is not your task judging code quality, and yes that does make me uncomfortable, that you want to pick up the full power at once, and not collaborate with whom should have been involved in the process. As said, this whole thing is just an interim solution till fast-path procedures get deployed. lu
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/19/2013 09:15 PM, g...@malth.us wrote: Sorry to hear you have such a low opinion of the socialization of Gentoo developers. Since I'm not one of them, I'll just put forth my 2c in on this, without fear of consequences. Yet even users not behaving will get a friendly warning and might be restricted in their access to our media. Am I the only one who feels that trolling, abuse, and so forth, are largely in the eye of the beholder, and that lively, impassioned, constructive debate may seem to many readers like hyperbole and ad hominem attack? So better to try to think twice and write when you are sure you are as clear as possible =) As long as I can remember, candid and even ostensibly hostile debate and argument have been a part of the Gentoo process (the same goes for a great many open-source projects). Thus far, although not without some frustration and angst, Gentoo has weathered these storms, and somehow managed to make sound decisions based on technical and practical merit, after all is said and done. Sure, but since we are getting more and more people burnt by the process and nothing is gained or lost between: You suck and this idea is not going to fly at all and I'm sure it will not work Have you considered the possibility, Markos, that, although not pretty to look at, such conflicts provide an important cathartic channel to relieve certain psychological pressures? In environments where everyone is expected, on pain of discipline, to be civil all the time, my experience is that folks start to build up resentments which eventually explode forth, spectacularly, despite -- indeed, one might say, because of -- their best efforts to conform to those expectations. You can be direct and yet not infringe the CoC. IIRC, Gentoo already has rules forbidding a laundry-list of antisocial behaviors like racism, sexism, threats of violence, and so forth, and some provisions in place to handle violators of that policy, does it not? Yes and now is being enforced fully. Further -- and please take this as more of a rhetorical flourish than a genuine concern, but, I wonder, whose job it is to muzzle you, Markos, if you, yourself get out of line, and will they dare perform it? The rest of devrel still does have full power, the quick action of the devrel leader is just a in between once we got to agree on the quick-action protocol. We have a lengthy procedure for major infringement and it doesn't work for small infringements. Has a clear consensus emerged that existing rules are not strong enough? Is not a matter of rules, but procedures to enforce the rules. Or perhaps, are a vocal minority just butt-hurt about some particular discussion that happened recently? I'm asking fully in earnest, and I sincerely hope -- and genuinely presume -- I don't have to worry that I'll be muzzled for doing so, on the basis that I'm trolling or what-have-you. No minorities had been considered, vocal or silent. Why should I even feel the need to say so? Perhaps, that is my problem and sheer paranoia, but surely, you can appreciate how such an announcement can potentially have certain chilling effects, and that the merits of strict enforcement of such well-intended policies are not necessarily so clear as they might seem on first glance. Having a gentler tone would just keep the technical field less prone to be encrusted with pointless emotional hindrances. Everybody likes to side between Good and Evil, here we should just have Working and Broken. lu PS: I'd advise to try to tone down another notch your vocabulary if you are afraid of getting some penalty for foul language.
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/16/2013 02:24 AM, Zac Medico wrote: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). Sounds interesting. Still please notice that the initial and misdelivered point about live ebuild being NOT for everybody beside who develops software should be clear. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 02:34 PM, Vadim A. Misbakh-Soloviov wrote: 15.06.2013 18:50, Diego Elio Pettenò пишет: Over my dead CVS access. Any reasonable/argumented objection? to put in different words: We do not want to use untraceable/transient/ephemeral sources for main ebuilds, live ebuilds are corner cases. Ruby related stuff had it worst regarding mis-packaging and total reliance on git with horrid stories they might tell you later over a large coffee. And, anyway, quoted part is optional behaviour that should just make ebuild-writing easy. Mandatory part is to be able to have restrict://foo.bar and downloadable things at the same time. In fact the restrict part got some proposals and not a terse and stern reject. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for overlays is something paludis gets right - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. lu
Re: [gentoo-dev] Re: Re: eselect init
On 06/03/2013 02:37 AM, Walter Dnes wrote: On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. Let me restate: As long there isn't a strict necessity the whole machinery should not impact the normal systems with the default init. Your situation is a special use-case, i.e. a developer who wants to switch between a production init system, and a test init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? e4rat, bootchart and other addons might be more mainstream than gdb-as-init indeed. BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. It isn't every bootup =) lu
Re: [gentoo-dev] Re: eselect init
On 06/01/2013 11:23 AM, Steven J. Long wrote: That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Your opinion. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? NOTE: If you still wish to pursue a fixed config, then it's easy enough to build it with init=/sbin/einit since presumably you want that setup for your users. Had been considered All I'm saying is: can we please stop trying to reinvent the kernel, which accepts a bootloader parameter from initramfs as well, and focus instead on the difficult part: making sure the system is in a fit state to switch in the first place. ... That's where the development effort is needed, if you are to provide a mechanism to switch. The symlink and hooks etc is a total dead-end, imo. It's simply reinventing the wheel using octagons instead of circles. IMHO you hadn't read enough about it. There's nothing to stop systemd being the default init, should you want to put the install together like that. Because let's be honest: someone has to put this install together, irrespective of how incapable the end-user is of editing a file by themselves. And just because the user can do it simply, that's no reason to make our method to do it any more complex (I've never heard such a bizarre argument.) Just edit the file via script. I do not care about systemd. FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly. You should read the whole thread before commenting like this that late. lu
Re: [gentoo-dev] Re: Re: eselect init
On 06/02/2013 08:20 PM, Steven J. Long wrote: On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: On 06/01/2013 11:23 AM, Steven J. Long wrote: That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Your opinion. That's not an argument for it either. Had been explained in the thread, please read it. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? The typical thing Gentoo users get told is this is a new thing, it will take some time to work out, bear with us as their production servers go tits-up around them. So in this case too, work with upstream to implement better solutions you, and the wider ecosystem, can all use. I'm afraid you never used those nor you are in one of those situation in which you have less options. And STILL the best interim solution till your EFI setup has a bootloader. Again you should read the whole thread, please do, the whole eselect init stuff should stay opt-in for the time being so all this discussion is close to pointless. Consider this email a friendly warning, please do not pollute the Gentoo media with pointless email when you had been already politely told that your concern had been addressed in the previous email in the thread. You're free to work on whatever you want. You just haven't made any case for why the rest of the ecosystem should be crippled to allow for a use-case that would be better served by an existing, far more robust solution. Had it been the case we wouldn't had spent some weeks picking our brains on it. Then it can be runit or whatever else takes your fancy. You are ignoring the point of that paragraph though: someone has to put the install together. Or it isn't a Gentoo install. And you seem to miss the point that all you are telling had been discussed, taken in consideration and in some part agreed with already... Wrt to the first, funnily enough the kernel developers have been here before, just like they had with ethN and wlanN. It's a basic requirement for developing an OS that you be able to switch init and fallback to other options. Again you didn't ready or you forgot. I said already I don't care about systemd many times, yet you failed to remember that. My specific use-case would require a trip to single mode and a second reboot, the way I want to do spares that. On an EFI-stub only system it would require at least a kernel rebuild or a trip to the efi shell if available. Honestly, my goal is a saving of time so people can focus on making the eselect module work properly, and be of real value to an end-user who wants to switch init. To not make this a waste of time here a summary of the whole thing: - eselect init will be opt-in for the time being, people can be left on their own tools if the want it - the default init will stay sysvinit. Discussion ongoing if is better to have it installed in a secondary fallback path is open (e.g. /bin/init). - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. - people wanting to switch init or enable/disable init addons using eselect init might have to refer to /sbin/einit or such custom path (assuming we fail to come to an agreement regarding /bin/init) The wrapper in /sbin/init is mostly needed to get to the point of a clean reboot. The first time you boot on a new system it is executed picking the new init and just that. For addons such as bootchart2 and e4rat it would do slightly more. Assuming upstream doesn't accept custom paths for the inittab, for my specific usecase I might bake something that would remount r/w and pivot the inittabs. Anybody willing to do something more extreme could even consider having /sbin/init as a symlink and have the boot-time configuration switch the symlink, thus making the whole script run just a single boot per switch. Not necessary but surely feasible. lu
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On 05/29/2013 10:55 PM, William Hubbs wrote: On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Because to me and many other EFI users is quite annoying having to rebuild the kernel or do something ugly such as editing a binary file. Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. Because addons such as bootchart2 or e4rat would be much simpler to use through eselect init than doing the whole bootloader or kernel-rebuild dance. Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? Because usually we aren't linux from scratch and we try to automate as much as we could, leaving the options there to be selected =) lu
[gentoo-dev] Re: inittab was: Re: Switchup-mode and boottime selector? Was: eselect init
On 05/30/2013 10:52 PM, William Hubbs wrote: On Thu, May 30, 2013 at 08:30:00AM +0200, Luca Barbato wrote: Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. inittab is only used by sysvinit and busybox init right? By anything that claims to be init-compatible. If so, it is unfortunate that busybox init uses inittab and its inittab is not compatible with sysvinit. Surely is. I'm tending to agree with mgorny that a better fix for this might be to have busybox use an alternate filename for its inittab, i.e. first look for /etc/bb-inittab and use it, then if it can't find that, use /etc/inittab as a fallback. sending patches should be easy. What do you think? I stated the worst cases, I guess is time to draft stuff and see how it does behave. lu
Re: [gentoo-dev] Separate boot/root already [WAS: eselect init]
On 05/28/2013 01:45 AM, Walter Dnes wrote: Out of sheer curiosity... is bb-init based on busybox? If so, a it IS busybox =) separate partition would also prevent standard utilities from stomping all over their busybox symlink equivalants. Add another entry to the grub/lilo menu, and boot from that. You don't need symlinks, you have a startscript that runs busybox ash, then it will use all its applets, init included. This way about all the openrc shell scripts is executed by the same interpreter and sed/grep and such are just function calls and not slightly more pricy fork+exec. Doing this way you get a quite fast boot and depending on your needs you can leverage more busybox applets to replace even more programs (e.g. dhcpcd). That would be the theoretical fastest boot possible short of integrating start-stop-daemon in busybox. lu
Re: [gentoo-dev] eselect init
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)
The really minimal wrapper would be something like
#!/bin/sh
INIT=/bin/init
if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi
exec ${INIT}
With switch-init doing stuff needed, including remounting the rootfs rw
if there are stuff to be changed and if we want stick to symlinks it
could replace itself by a symlink.
Yes, it would be that simple.
lu
Re: [gentoo-dev] eselect init
On 5/28/13 6:19 AM, Michał Górny wrote: And you actually make the boot depend on: 1) valid /bin/sh If it doesn't exist you have a few order of magnitude bigger problem. 2) valid /etc/switch-init which would not interfere with boot process. I guess if you want to switch init system you need that =) With switch-init being executed as a shell script, it can do anything. Yes and that's the beauty of it. And I wouldn't be surprised if you made it do various things you'd like to be done. I would be surprised if I'd make it do various things I won't like to be done, surely a possibility, albeit unlikely. Not to mention what would happen if it gets corrupted into binary mess and shell tries to execute that. Having your rootfs corrupted is quite bad, even horrible if an ephemeral file gets corrupted through reboot. There's no fallback that could handle shell failures, you know. I guess your knowledge of shell needs to be expanded, beside that it is easier to write an example using shell pseudocode to explain how it could work. That said, here a friendly suggestion: try to be less destructive in your comments and fix your mailer. Both can be annoying in the long run. lu
Re: [gentoo-dev] eselect init
On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. openrc is *simpler* much *simpler* than systemd, stop with that. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. Check your facts, systemd either understands a flavour of inittab or the other or none at all. Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. It is not dangerous beside for those that have an inittab with rm -fR / lu
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 5/26/13 9:45 AM, Michał Górny wrote: As in, say, lastrite GNOME and tell users to switch to other distro? Or maybe everything using udev? Sounds much like the way to get the 'one distro' dream some people have. But wasn't the intent opposite? eudev was made on purpose to let people avoid systemd if they wanted, and it is why people involved on it got stalked and had that much fun. lu
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. Making better mousetraps usually works fine: as long you have generators that are good enough to get something working nobody would complain. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Can be done notwithstanding the rest. Considering the design of OpenRC itself, it wouldn't be *that hard*. It is sort of simple. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. A compiler is an option as well, as said unit - runscript should map fine. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. Having stand alone component would probably win you many friends and if the whole thing could work on something non-linux-latest-with-latest-glibc you'd have one less technical concern. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. Or just make something useful, winning or losing is for the people using it. If it works and works fine people will use it. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable - must work on non-linux and non-glibc more or less decently - modular- loose coupling of functionality - robust - the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible - should grok at least a good subset of systemd unit files. On a side note I
Re: [gentoo-dev] eselect init
On 5/26/13 12:57 PM, Michał Górny wrote: On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. Noticed and known issue, I merely stated which are the options on the plate, keep in mind that init addons people use and we distribute do even more evil stuff. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. I read the code up to do_exec, given for me it would require have a roundtrip to the efi shell I was hoping those proposing that would do that basic homework =) In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh as a fallback. That's all I wanted everybody knows, thanks for helping. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. I read it as as complex as the user wants. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? I would expect any sane init would get me at least to their single mode. What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the switch on boot would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. The wrapper could even install and uninstall itself. Again, my object of interest is being able to use bb-init and runit. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like 'telinit' should be *enough* to keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a least
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:31 PM, Robert David wrote: Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. The fact we are already the worst offenders won't make thinking about impacting a little less not that important. System with the problem keep portage in a separate fs. lu
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. Here we have a problem, the people that need more flexibility to actually get work done will see that the inflexibility of the unit format will bite them and bite them hard. A simple example is something fairly easy for a runscript and quite annoying for an unit, multiple instances. for openrc you can just symlink using a proper pattern and have the initscript figure the right configuration and which user/chroot use to drop the daemon. for systemd you have to copy and edit since most fields are immutable (some are with special rules). This is something you tend to use a lot for certain kind of services and is made really easy and uniform in openrc while lsb and freebsd tend to have per-script rules. I have my limits, and I'd really prefer doing something useful rather than setting up random things straight, fighting developers and making sure everything keeps working in a semi-sane way. Your dedication is commendable, I do appreciate your help in Gentoo a lot even if we can disagree on some decisions. I know that discussing systemd can get quite annoying since it can easily drift from technical (e.g. my concern regarding dbus) political (systemd as Trojan horse for something else and other strategical concerns), or personal (some people consider Lennart a dangerous/poisonous person) and gets quite easy to mix things up and end up discounting technical concerns by telling that you said this or that just because you hate Lennart. lu
Re: [gentoo-dev] eselect init
On 5/26/13 2:08 PM, Michał Górny wrote: You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. Worth investigation, not by you, but those that loathe systemd should have a look and see if they could fix some. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. Hopefully not =) I just stated what's the problem and the possible solutions. As said from start I want the whole thing to be an opt-in and to cause the least amount of disruption on current setups. Patching sysvinit and bb-init to accept a -c filename would make the whole thing much simpler if we pick a wrapper solution for my most complex case. lu
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 3:35 PM, Sergei Trofimovich wrote: On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato lu_z...@gentoo.org wrote: You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf feel free to sprinkle %i (and others) for templating. Feel free to check which fields accept %expansions and which do not, last time I heard some fields do not. If it had been fixed I'm glad. lu
Re: [gentoo-dev] eselect init
On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. Apparently it is read when you switch runlevel as well. lu
Re: [gentoo-dev] eselect init
On 5/27/13 12:58 AM, William Hubbs wrote: From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. Nope, it interprets the numbers in a different way. If that's the only difference, do we really need to modify the inittab at all? Yes, I tested it first and got the whole system unworkable, one single mode later I baked something to get at least the minimal functionality, supporting our xdm script properly required some more effort I hadn't time to pour that day. lu
Re: [gentoo-dev] eselect init
On 5/26/13 4:13 PM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. First action at boot, without an initramfs, is too late isn't it? bootchart2 shows that is quite possible and working fine for it =) The current mode to switch init manually for my use-case is to drop to single user, do your stuff, reboot or reload init if the init or the operating system supports it. Drop to single user is quite the same as rebooting anyway. lu
[gentoo-dev] eselect init
Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). In those setup changing bootargs requires a kernel rebuild and some effort, while the eselect approach stays completely transparent. For some switch we might not have just to change the init binary bit also to do some other changes (e.g. use a different format for inittab) # KEYPOINTS - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. - init gets effectively switched only at boot/reboot, eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots, if we use the wrapper approach, it would pick up what's the new init at boot and that would be enough for simple cases, hooks on reboot are still needed for more complex ones. - we could try to not have the changes to the current init systems ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) # FOCUS My interest is mostly if not all on bb-init-openrc and slightly on runit-openrc. There are enough people involved in systemd and since I still consider it a dangerously frail implementation of a bad idea is better if I do not touch it at all. My system with stock openrc gets from linux start to graphical login in less than 6s and I'm not using Gnome so I do not have any reason to use it beside comparing. lu
Re: [gentoo-dev] eselect init
On 05/25/2013 01:29 PM, Sergei Trofimovich wrote: If you can't change options at boot time it's very simple to get unbootable system. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? You write your bootargs in the kernel, if you really must you can go to the efi shell and override by hand. you can surely install an efi ui on top of your efi implementation but that's unrelated. My current setup works decently the way I mentioned and I guess more than a single person might use it. I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? /bin/init is my idea (second in the list in linux fallback), otherwise we can just make the wrapper use a non-taken name and have people willing to play with it just reroll their kernel/boot system. lu
Re: [gentoo-dev] eselect init
On 05/25/2013 01:13 PM, Pacho Ramos wrote: El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió: Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). I use e4rat and, for that, I need to add init=/sbin/e4rat-preload to my grub.conf, I guess this wouldn't change with this, no? :/ mostly you would be able to do # eselect init addon e4rat instead. But the whole eselect init should be an opt-in till we are 100% sure it covers the usual scenarios. The basic idea is that you would have a wrapper (shellscript or binary) that just reads from a known location what to run once and what to run the following times, something along the lines of if (switching) do_switch else exec $real_init With all the possible failovers. lu
Re: [gentoo-dev] eselect init
On 05/25/2013 02:13 PM, hasufell wrote: Isn't eselect for cases where I might want to reconfigure something or add configuration values such as for bash-completion, do testing with java-vm or python implementations during development, switch opengl implementation depending on the graphics driver loaded and whatnot. I don't see any of this applying to init system, nor do I see a reason to randomly switch between those. It's rather something to configure during installation, so I'd rather expect proper documentation. Beside switching completely init system (since there is this itch to try new toys here), you also have addons such as benchmarks such bootchart, fs layout mappers/optimizers such as ureadahead and e4rat. Some are something you want to run on-off. All this started because Fabio had enough people pestering him about systemd and he wanted some simple way so people could try it and get back once burnt or vice-versa. I have my uses for it since beside using bb-init to shave some time spent spawning ephemeral processes on complex runscript, there is also the runit integration in openrc that would feel bad having it rotting in a branch w/out making it available and it has the very same issues you have with systemd. So having an eselect applet for this kind of purposes makes sense. lu
Re: [gentoo-dev] Usage of dev-utils/ninja in ebuilds
On 5/25/13 9:17 PM, Tom Wijsman wrote: On Sat, 25 May 2013 14:48:30 -0400 Mike Gilbert flop...@gentoo.org wrote: For those unaware, dev-util/ninja is a make-replacement created by one of the Chromium guys at Google. Its focus is on making incremental builds of large software faster. I've no idea how this would work out, so I'm asking some questions from different perspective to form a better idea; this may step aside your discussion but on the other hand could help other unaware developers. If I missed earlier ML discussions on this by not paying attention or being too new, feel free to point me to those; no need to repeat. :) Ninja is simpler than make and strives to be as essential as possible, for those that know exotic build system is a close relative to plan9 mk. Ninja doesn't make any effort to make its build rules human readable, as said they have to be generated by something else, not sure how easy/hard would be debug the generated file. Being what it is used by default by upstream, probably it makes sense using it for building chromium. Using it on cmake shouldn't make much, if any, difference speed wise and would just make cmake build require yet another building block so I wouldn't use it if there aren't clear advantages in doing so (somebody could benchmark so we can see how it fares) lu
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 5/25/13 6:48 PM, Michał Górny wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing list, since this discussion doesn't really belong on bugzilla. Seems that *upstream* had to a bit of work in order to support the various bits of systemd (not just the simple unit apparently) I can understand there is some hurry so somebody could gloat and even Gentoo/Sabayon supports systemd, yet I wouldn't *rush* things and I would consider getting something sorted out sanely for everybody. I doubt I would be treated that nicely if I start spamming all the upstreams about supporting runit and demand they to maintain those init rules. We can be kind with difficult upstreams but just up to a point. That said, I'd rather have set something along the lines of: - get the eselect init machinery in place - decide seriously if we want to consider units (and init.d files) as manpages and threat them in the same way. This way nosystemd in the features would spare you some files as it does for manpages. - repeat the same treatment for openrc and runit runscripts. The alternative of having split packages seems a waste of inodes, probably in the end having the package manager keep track of this data would be better. lu
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On 05/21/2013 09:03 AM, Alan McKinnon wrote: On 21/05/2013 05:03, Daniel Campbell wrote: That's missing the point. If you don't run systemd, having unit files is pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems like a hack instead of something more robust. Why include systemd unit files (by default, with no systemd USE flag, thanks to the council...) on a system that's not using it? 154 files isn't negligible unless you're flippant with your system and don't care about bloat. Unused software sitting around *is* a waste of disk-space. Some people (like myself) came to Gentoo to avoid putting systemd on their systems and to make use of the great choice that Gentoo allows. This push to make systemd a first level citizen or whatever reeks of marketing. If there is desire among users for unit files, they can contact upstream or maintain their own set of unit files. It's not like they're hard to write. amused long-term user chipping in This is such a weak argument it's quite laughable. I don't like gnu info files. Neither me nor anyone I know can figure out how to drive info. So, let's rip all the info files out of every package; leaving the 3 users who do know info free to grab their copies from upstream. I mean it's not like it's hard or anything, and info files are easy to write. check the FEATURES variable and be surprise =) (from man make.conf) nodoc Do not install doc files (/usr/share/doc). noinfo Do not install info pages. noman Do not install manpages. Adding a nounits norunscript and such might work and had been proposed. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 03:41 PM, Fabio Erculiani wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And given that the end-plan according to the guys is to kill the distributions shall we just close Gentoo now? And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. Are there specifications regarding logind ? Is that so incredibly terrible write and maintain 1k loc? I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. Science is science, systemd doesn't work with anything but linux, Gentoo in theory should care about not-linux. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Surely sysadmins will be delighted about that. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. I'm upstream for some stuff, vlc was already really close to force-kill pulseaudio because of some cute problems, the thing got otherwise fixed. Upstream does what is most sensible for the users, usually. Freebsd, openbsd and some other operating systems are still there, they have their reasons and usually work better in those fields than other, I'm sure some people would wish to kill them, not going to happen anytime soon. So what do we want to do then? Isolate from the rest of the world? The world is bigger than that and we were making bridges around, *why* severing them because somebody else decided for you? (It's not a sarcastic question). I hope that everybody does their own reality check. Did mine, other experienced the hard way what I said many times. Gnome doesn't seem a good reason to leave in the cold people that do not even care about it. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 05:03 PM, Luca Barbato wrote: On 05/15/2013 03:41 PM, Fabio Erculiani wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. To make it even clearer. In order to support a good amount of users out there that do not care about gnome and cannot use systemd we can see and bake alternatives that are compatible enough. Those that can't use systemd: - those not using the latest glibc (and maybe uclibc) - those not using a recent linux kernel - not sure about cgroups-users, the lxc vs systemd problem should be solved I hope That's what I'm aware of. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 07:26 PM, Tom Wijsman wrote: On Wed, 15 May 2013 17:03:13 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 05/15/2013 03:41 PM, Fabio Erculiani wrote: ... GNOME ... And given that the end-plan according to the guys is to kill the distributions shall we just close Gentoo now? Let's not exaggerate things, there are a ton of other DEs out there; are all of them starting to depend on systemd specific features? Luckily not, yet _that_'s what is in the roadmap apparently. Whether or not it is terrible, it is a time sink; is it worth doing it? For any non-linux, less-than-3.x-linux, non-glibc system user probably. Indeed, the goal here is solely to make systemd more accessible; we shouldn't pursue it to be the main init system or force it upon users, unless there are indicators in the future that it became better (eg. supports BSD, ...) for everyone. And that has my support, there is disagreement on what that entitles. Used GNOME for months, then with 3.6 - 3.8 it started to break on me; it didn't work on either OpenRC or systemd. While I was a happy user at first, recent events made me lose interest in it; I think a discussion regarding init systems and similar software shouldn't be focused on a single DE, so I too am not sure why focus is laid on GNOME here... Since it is the DE forcing all those changes down distribution throats. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files What if openrc/upstart/runit devs start harassing upstream in the same way? Strategically is great, but isn't exactly something nice to do. Probably people caring about alternatives should start bothering upstreams likewise and we'll see how it goes. I'm sure that *everybody* would be delighted to provide those 4-5 different initscripts because one distribution or the other wants others do the work for them... I'm saying again that trying to get a good intermediate representation and have a generator (eselect based maybe) provide the init-specific file would be much better. In the end initscripts are usually distribution dependent since they are an integration step. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/04/2013 03:12 PM, Fabio Erculiani wrote: I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working by miracle for now. mdev is not future proof wrt lvm support. Sounds dangerously bad, I guess the response by the interested parties (e.g. nas builders) will be moving lvm in bb or switch to dragonfly or freebsd. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/04/2013 03:05 PM, Fabio Erculiani wrote: Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? Uhm... sounds quite unpleasant and I'm really wondering why having udev as middle-man for storing userspace metadata. The netlink broadcast should be available to everybody for acting upon, using/extending it for such tasks isn't possible? lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? - genkernel should at least support plymouth (work in progress my side) Looking forward to it. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. Exactly, which is the problem at hand? I'd like to be able to safely switch back and forth sysvinit and bb-init as well. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) Here! o/ Currently in my list are - bootchart2 (as an add-on to the other init systems) - bb-init (requires different custom inittab) - runit (openrc can use it instead thanks to benda xu past GSoC) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) Again it is something I consider an option for a GSoC project, we have already some openrc variant for other systemd-originated daemons in our git. - we put back some fun into Gentoo That's always good. If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. Thank you a lot for your positive attitude and the huge effort =) lu
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/13 22:32, Rich Freeman wrote: On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman tom...@gentoo.org wrote: Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should be on their own, thus I drop -ffast-math because it breaks my browser; but that doesn't mean that those ricer flags should stop stabilization. If we're talking about for general use in CFLAGs clearly -ffast-math isn't something that even could be supported if we wanted to. The flag is just not intended for general use. And if you stop here everything would be agreeable. That isn't the same as saying that we can just break it in cases where it actually is appropriate. Calculating scroll bar movement is exactly the sort of thing that this flag was actually designed for - you don't care if it is off by 1/100th of a pixel. Please check your facts. using -ffast-math could do anything from nothing to cause severe security issues. But, the way to track that sort of a thing is to log those as bugs against appropriate use within individual apps and make them blockers. No. I'd consider things like this valid bugs - but whether they hold things up should depend on real-world impact. I'm not sure how bad the impact on chromium actually is. Absolutely not. Some code is _designed_ to work w/out caring about ieee corner cases and some is _designed_ to work leveraging them. NOT bug. To reinstate: if you use -ffast-math or other known-to-alter-the-standard-behaviour or, even worst, experimental flags you are on your own. lu
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/13 23:21, Rich Freeman wrote: My point was just that: 1. No, the fact that entire packages fail to build/operate using -ffast-math is not a valid bug. From your email the message was the opposite, maybe a not got lost? 2. If individual packages DO carefully use -ffast-math and that breaks, it might be a valid bug, and may or may not be a blocker depending on real-world impact. That doesn't mean users sticking it in their CFLAGS - it means the ebuild or upstream build system carefully applied the flag appropriately. That means that if the upstream cflags do not work (anymore?) with certain compilers we should notify them. Seems sensible to do. 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)
On 12/02/13 08:21, Ian Whyman wrote: Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is better for the user after we turned it around again. There isn't ANYTHING that is impacting users beside those that they might get the next versions of gst-libav just end up with a runtime error if they use ffmpeg (if the upstream authors follow up with their plan) or those users wanting to use mencoder might get some compile errors if I forgot to update the compatibility patch after somebody bumped w/out testing. It really boils down to decide to be extra careful with mplayer and xbmc or being extra careful with gst-libav and maybe vlc. Sadly this whole discussion turned to discussing who is right or wrong, who is the fork or not and who's an evil bastard oppressing the poor Austrian genius or not. I'm ok discussing technical merits and spend time fixing issues, not so much discussing stuff I'd rather not discuss such as if I'm an evil bastard for not working with somebody that joked about my death. lu
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)
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: 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: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 08/02/13 22:46, Alexis Ballier wrote: On Fri, 08 Feb 2013 22:41:04 +0100 Maciej Mrozowski reave...@gmail.com wrote: On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. Not really. I was promised a discussion that hasn't happened yet. I'm available for discussion anytime, I got a little busy in the past days and I will busy the next 3 days, but I should be available today evening or now. I stated already what I think about the whole discussion in a blog post. To summarize it my take is quite simple, Libav leads the way regarding the main API, it offers a more compact surface for attacks if you are really concerned about security and usually it is a little more compact and a bit more tested over a wider range of architectures. I'm not for removing ffmpeg overnight since there are features that might be of use and I'm not so hypocrite to value diversity only when it is in favor of my interests. That said as long the two project are compatible having one or another as default is just a matter of making our life easier. I'm upstream for Libav and a good number of Libav developers are Gentoo users, including Gentoo on special platforms (e.g. aarch64). Few large projects such as VLC and Gstreamer switched to Libav as their default. Since Libav is the no-frills variant, notwithstanding the interesting campaign of we have more security11ein! less stuff should break since it is usually more tested and once we gather the samples triggering a crash usually we do not stop preventing that single crash but the whole class of possible defect (see my work on mov as an example). I cannot and will not say that Libav is perfect or that no bugs are introduced on our side and other outlandish statements, but within my biased point of view I would expect a better experience for the user not caring about which library to use. If you want to discuss on #gentoo-media ping me within 30 min or in 2 hours. I hope somebody not Libav nor FFmpeg committer could come up with a pros-cons list. lu
[gentoo-dev] Re: About dropping ppc-kernel herd
On 20/01/13 10:26, Pacho Ramos wrote: Looks like no package is included in it, I think we should drop that herd then Do you agree? Agreed.
Re: [gentoo-dev] Chromium system ffmpeg
On 19/01/13 20:10, Paweł Hajdan, Jr. wrote: have a way to more simply exclude code that requires CODEC_ID_OPUS. Exclude in chrome or in libavcodec? The latter is a matter of adding --disable-decoder=opus and/or not --enable-libopus in the configure. lu
Re: [gentoo-dev] app-emulation/qemu-user mask
On 16/01/13 20:20, Luca Barbato wrote: Again please do not mix qemu system emulation with qemu userspace wrappers. They have different needs and requirements. qemu-user-1.2.2 in portage. I'll drop the mask as said before. We can discuss on irc or here on what's the best strategy today anytime. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 17/01/13 15:07, Alexis Ballier wrote: On Thu, 17 Jan 2013 10:41:58 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: [...] So yes it works and should not pose any issues to user. I also announced it over blog to get people report more issues they find out so I can be really sure it works out. It turned out the mplayer1 really needs to work under both, which I patched yesterday for stable libav and Luca today for masked libav to work. And this libav-9 patch actually breaks with all non-masked version of both libraries... I've just fixed this, but please stop this madness breaking everything in order to be as quick as possible to make your point... I guess I overlooked something, thanks for fixing it. lu
Re: [gentoo-dev] Chromium system ffmpeg
On 15/01/13 05:34, Paweł Hajdan, Jr. wrote: I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). Now the initial response there is not enthusiastic (which doesn't surprise me), but do you think there are some points useful for the discussion I'm not aware of? What are the main challenges of keeping up-to-date with latest ffmpeg API changes? How do other projects deal with that? I guess it had been stated there, but is worth noting again that chromium has a specific fork of ffmpeg and they merge and adapt/fix as they need. As Libav we try to see what they are doing and when possible either import their fix or redo it in a more general way if it doesn't fit normal consumption (see our review process policy for more details). Their API usage is quite normal nowadays (after we convinced them to use AVIO instead of the deprecate URLProtocol, for our and their respective pleasure since it resulted in slashing a good chunk of cruft) Feel free to nag me if something breaks with a system libav. lu
Re: [gentoo-dev] Chromium system ffmpeg
On 16/01/13 12:54, Alexis Ballier wrote:
On Tue, 15 Jan 2013 21:10:12 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
On 1/15/13 4:55 AM, Alexis Ballier wrote:
On Mon, 14 Jan 2013 20:34:42 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
I'm trying to make Chromium be more compatible with more versions
of ffmpeg:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
(although not stated there, that includes libav).
I've done quite a lot of work for various packages among the past
years on that side, so if you have specific questions, feel free to
ask.
Alright:
1. What's the difference between libav and ffmpeg? Do the projects
merge each other's changes? If not, in what direction do patches flow?
ffmpeg merges daily from libav; for libav, better ask Luca or Diego I
think, but I've seen they manually port some patches from ffmpeg from
time to time.
Libav has defined review rules so patches get hand picked and discussed
as any other contributions, there isn't any kind of fast track.
If somebody wants something in ffmpeg, ffmpeg-chromium,
${personal_libav_fork} and such, can just pick the patch and send over
the mailing list.
2. What are API compatibility policies for ffmpeg and libav?
There's no policy AFAIK. For what I understood, libav doesn't care;
As said above our development policy is quite simple. Regarding API
changes they get discussed as for any other patch, new API can land on
the master, old api gets removed after a major release deprecating it.
3. Same as above for making releases (i.e. how frequent they are, how
much they change, and how much released libav and ffmpeg are in sync
with each other in practice).
In general we aim to have a major release per season, depending on how
involving the update is we postpone till downstream catches up.
Point releases happen when enough bugfixes are piled up. Usually we keep
one or two major release in maintainance mode (releases and fixes) while
we develop the next one.
For the release 9 branch I'm trying to keep the fixes in sync so people
doesn't have to backport them in mass.
Release branches 0.8 and 0.7 are synced more seldom.
4. What are typical incompatibilities (if possible), and usual ways to
deal with them?
Use only the common subset, e.g. Do not use swresample and use avresample.
5. Do you think it's possible / worth trying to convince upstream
ffmpeg / libav to have a more stable API over time? Which one could
be possibly more willing to listen and why?
Libav API is evolving but you have about 1/2 year or more to update.
What when chromium upstream uses code more recent than latest ffmpeg
release and it doesn't compile against latest release?
They will gladly tell you that the patches they use are available and
you should nag upstream.
Jokes aside, tell us and in a way or another you'll have something working.
Now what about libav? At one time I could compile against latest
masked ffmpeg in tree but couldn't compile against latest masked
libav (or any other version of it I think). Ideally I would like to
make it compilable against both. Does that sound like much more
difficult?
It depends what the problem is: it may be just some missing #includes,
some CODEC_ID present in ffmpeg but not in libav in which case you'd
have to #ifdef its usage out, or more complicated if you use an API
from ffmpeg not in libav like some libavfilter stuff.
Usually Libav does not expose private API and depending on the release
timing you might find software not updated fully (see about about the
6-8 months of grace time)
Yup. Just note there is just ~6 weeks before each stable release.
That's not a very long time for most projects, and I think we won't
get other packages into shape that quickly.
If then need arises I think we can snapshot, a monthly point release
might be coordinated if enough people need it.
I could make a leightweight compatibility layer, don't underestimate
Better nag me till your problem isn't solved on our side, chromium is
huge and making changes on the media part of it is gorier than you'd expect.
lu
Re: [gentoo-dev] app-emulation/qemu-user mask
On 12/01/13 05:45, Doug Goldstein wrote: Just wanted to give everyone a heads up. app-emulation/qemu provides all the functionality of app-emulation/qemu-user without all the outstanding security bugs and issues the package has. For users using a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I presently use an arm chroot with app-emulation/qemu. Should there truly be a missing feature, open a bug and I'll fix it. The only item I'm aware of that app-emulation/qemu does not have is the binfmt initscript. But I plan on adding that to the unstable version shortly. If there are no objections for 30 days, I'll send a treecleaner notice in 30 days and remove it 30 days after that (60 days from now). And once I have enough time I will reinstate it... beside the fact qemu-user does NOT have security issues... Again please do not mix qemu system emulation with qemu userspace wrappers. They have different needs and requirements. lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16/01/13 21:09, Alexis Ballier wrote: More seriously: Why ? Who decided this ? I never pushed my weight over it before since as you are involved in FFmpeg directly, I am involved in Libav directly. Thus anything I say on this topic has a clear bias. Same goes for you. Tomas is not related to libav beside one of his core project using it by transition, so I would expect him to be less biased than us. Let's be realistic, both upstreams claim they're better than the other in one way or another, and let's think like serious downstreams, not like upstream playground. VLC uses it since ffmpeg doesn't work with rtmp properly last time they checked and other interesting situations. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) ubuntu and debian just use Libav. As a downstream, I can see plenty of reasons against, but none in favor of this change: - There are still a couple of non-trivial packages that need to be fixed to work with libav while I don't know any that works with libav but not ffmpeg. See above for the other way round. - All (but the one discovered in Nov. 2012) of the security issues fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May 2012 (!!) for ffmpeg according to the website... 8 months before... The security game is fun. Given the number of additional features the surface impact is bigger in FFmpeg and currently all but one of the bugs claimed as security issues originate from the same guy he claim to fix them (sometimes the fix doesn't address the underlying issue but just _that_ specific sample). I'd rather avoid having another mud sliding contest. I stopped caring about FFmpeg since somebody gave a sample of his humor wishing my death. Lu
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 16/01/13 22:31, Alexis Ballier wrote: interesting, did they report it? OTOH, they switched _after_ the 2.0.5 release which happens to be the latest one. Since vlc is probably the ffmpeg/libav interface the most popular in the world (due to their windows and mac builds), I'd like to see an actual release with it and see if there is any regression before claiming they use libav. Reported, dismissed as bug on their side IIRC. gst-ffmpeg/gst-libav works only with libav as per upstream desire (thus the rename) you mean use libav internally? because 'per upstream desire' gst-ffmpeg or gst-libav always only worked with the internal libs :) it also appears to build and work fine with ffmpeg-0.10 To be more clear, latest gst-libav release does not build with latest ffmpeg release, same said for the gst-libav backport. Speaking about bias, the maintainer happens to be part of libav core developers and was even part of what is known as the 'ffmpeg coup' :) Meanwhile I preferred let people pick their poison since it is easy to switch from one to another, in retrospect would had been better if I just removed ffmpeg from the tree from day 0. None of what you cited is a problem for a downstream distribution, except maybe vlc+rtmp which should be fixed regardless. xbmc and mplayer did not build last time I tried. xbmc will be a pain because it uses some libavfilter features not in libav. mplayer2 works decently here. I didn't try to look at xbmc yet. I don't want to verify this and will trust you there, but I still don't consider 8 months to be a correct delay for handling a published vulnerability, whatever its origin may be. Crashes are always bad, we fix a lot of them every day, we obviously introduce few new since we aren't perfect, calling all of them security problems is a tad extreme in my opinion. The problem with the published vulnerabilities had been usually us being prevented from accessing the example vectors, now the situation is way better. I'm sure the fork didn't happen because some day some devs woke up angry because they didn't have had their coffee. However, I'm also sure the fork is a pain for downstream distros and a lot of upstreams. The rationale is on libav.org/about.html, I spent about 3 months trying to prevent it. I failed. lu
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 02/01/13 13:11, Samuli Suominen wrote: On 01/01/13 23:01, Jeff Horelick wrote: I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. And has its share of issues. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. As if glib-2 is any lighter... and since pkgconf upstream doesn't properly follow pkg-config upstream git and do necessary changes, like for bug 445796 it would mean pkg-config related bugs would have to be reported to double upstream and thus, not be maintainable Non sequitur at best. My interaction with both upstreams had been decent though. last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. check glib deps iirc some non-glibc platforms have few problems with it. lu
Re: [gentoo-dev] Moving our/portage stuff to var
On 12/17/12 11:30 AM, Michał Górny wrote: On Mon, 17 Dec 2012 11:23:00 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 17/12/2012 11:19, Tomáš Chvátal wrote: I've always myself override these defaults in make.conf to point for /var/portage/ (not /var/lib because I never bothered enough how to make world and config files to be put elsewhere :P). I would say let's work on that so that portage can keep them there. Although I'm more for /var/cache/portage myself, as both distfiles and tree can be re-generated. +1 on /var/cache. Agreed. Bonus points if we consider suggesting to move it on a dedicated file system ^^; lu
Re: [gentoo-dev] Re: eudev project announcement
On 12/17/12 11:40 AM, Olav Vitters wrote: So systemd still works with a separate /usr and you're continuing to spread misinformation. Demonstrating such behaviour while complaining about the behaviour of upstream is IMO very ironic. No it does not, try by yourself please ^^ (or just issue and ldd over the main binaries) lu
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/2012 02:55 PM, Rich Freeman wrote: On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik xarthis...@gentoo.org wrote: All trouble can be saved by asking user to recompile package with relevant flags on bug report, resolving the bug as NEEDINFO. Instead of forcing everybody out there using Gentoo to have additional XGb for debug, patching troublesome packages like webkit-gtk etc. Bug without valid data is by definition... invalid? Tend to agree. Plus, you can always compile -O0 in such a case and Ages ago I wrote something about how wrong is using -O0 and expect to reproduce issues. IIRC Diego blogged about it as well. Please do not use -O0, it changes a _lot_ the codepats of programs and glibc (and other libc) might or might not switch to compiler specific implementation that might uncover problems. I'd rather suggest the user to install valgrind and run the application under it. lu
Re: [gentoo-dev] Re: eudev project announcement
On 12/17/12 2:25 PM, Olav Vitters wrote: On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote: On 12/17/12 11:40 AM, Olav Vitters wrote: So systemd still works with a separate /usr and you're continuing to spread misinformation. Demonstrating such behaviour while complaining about the behaviour of upstream is IMO very ironic. No it does not, try by yourself please ^^ (or just issue and ldd over the main binaries) I quoted the relevant bits. There has been communication here about it as well as elsewhere. What was said here is that systemd did not support this. It does. Now we can twist words that sometimes Gentoo does not mean Gentoo. That systemd sometimes means as packaged by Gentoo and sometimes upstream. Poor behaviour! Please do use lld over the systemd binaries, if it reports it linking to a library in /usr then you have a problem if /usr is mounted. One of my main annoyance about systemd is the fact it links to a large deal of libraries and that makes it more brittle. As simple as that, really. lu
Re: [gentoo-dev] Re: [gentoo-project] eudev project announcement
On 12/15/2012 01:48 PM, Rich Freeman wrote: On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao r...@gentoo.org wrote: The systemd developers were in the middle of a transition to the LGPL from the GPL when we forked. We inherited the code in the middle of that transition and we see no reason to pursue a different course. Therefore, all future changes that we make to eudev will be available under the LGPL. Not sure what the driver is to use LGPL, but in general the Gentoo social contract requires that all contributions be made under GPLv2+ or the CC BY-SAv2+. We will release our contributions to Gentoo as free software, metadata or documentation, under the GNU General Public License version 2 (or later, at our discretion) or the Creative Commons - Attribution / Share Alike version 2 (or later, at our discretion). Any external contributions to Gentoo (in the form of freely-distributable sources, binaries, metadata or documentation) may be incorporated into Gentoo provided that we are legally entitled to do so. However, Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI). eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC. Why not just use GPLv2+? The LGPL is compatible, so this would not prevent us from merging udev changes. udev and eudev provide: - a daemon - a set of core rules - a library to let applications interact with udev (libudev) - a generic language binding using glib-introspection (libgudev) makes perfectly sense to have libraries using LGPL (or even more permissive licenses). I guess you misunderstood what is Gentoo and what is a Gentoo Project. lu
Re: [gentoo-dev] Re: [gentoo-project] eudev project announcement
On 12/15/2012 05:20 PM, Rich Freeman wrote: On Sat, Dec 15, 2012 at 10:43 AM, Luca Barbato lu_z...@gentoo.org wrote: eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC. OpenRC isn't a Gentoo project, at least, it wasn't in the past. The social contract defines Gentoo as a collection of free knowledge, which includes free software contributed by various developers to the Gentoo Project. The social contract is meaningless if it doesn't apply to Gentoo projects. Gentoo projects cover all the arch teams, portage, and all of our documentation. That part of the social contract section is resembling really closely Debian and shares the same clashing issue when Gentoo has to mix with non-gpl realities such as FreeBSD. We are not going to relicense to GPL all the software we touch, it would be at least rude. Projects are just how we organize the administration of Gentoo. They aren't something distinct from Gentoo. When you work on a Gentoo project, you work on Gentoo. Again, looks like there is a huge misunderstanding on what a project is, the term is much often overloaded since you have Gentoo, the community and the distribution and projects fostered by Gentoo. I guess you misunderstood what is Gentoo and what is a Gentoo Project. Enlighten us, what is Gentoo, if nothing in any Gentoo project is Gentoo? See above =) What exactly do you think that section of the Social Contract actually covers? Or is it a pretty document we stick on our website but ignore when it is somehow inconvenient? The social contract is meant to assure that we will preserve and maintain the freedoms we got as foundation the best we could. That section is clumsy in stating it as is in Debian, agreed. As I said, I'm fine with making exceptions if it makes sense and furthers the overall mission of Gentoo. There is no exception to be made. However, we shouldn't just ignore the social contract without any kind of consideration at all. Again, the document doesn't really relate to any Gentoo project as expressed as anything different from the distribution as whole. If the community doesn't like the social contract we could of course consider amending it as well. Clarifying to avoid such misunderstandings it seems necessary. Gentoo isn't GitHub. When people donate money to Gentoo they're not donating so that a club of elite coders can use the infrastructure to host just anything that suits their fancy. The reason that we let any Gentoo developer just start a project is because it helps promote innovation and cuts through bureaucracy. That doesn't mean that Gentoo holds no interest in the work that is done under its name. Again, we have a number of projects under permissive licenses since we DO want work with the BSD community or we rely on software originated by them, relicensing any software to GPL would be rude and quite pointless. I'm afraid you are ignoring the fact core libraries should not be GPL to not hinder adoption. (check which software uses libudev or libgudev and see how much of it won't work anymore had you relicensed those libraries to GPL) If for whatever reason the fork diverges to a point where we aren't giving back in the form of patches to upstream then I'd argue that it would make sense to move back to the GPL (something trivially done with or without copyright assignment due to the nature of the LGPL). I'd be happy to consider this once we reach this stage and you are among the main contributors. Currently I guess people would be happy to have their udev working as should. lu
Re: [gentoo-dev] new global USE flag: orc
On 12/16/12 5:28 AM, Alexandre Rostovtsev wrote: Currently, the orc local USE flag is used by 11 packages, 9 of them with identical descriptions. I think it's time to make it a global flag. I would suggest the following description: Use dev-lang/orc for just-in-time optimization of array operations Sounds ok.
Re: [gentoo-dev] net-irc/xchat
On 11/26/2012 01:16 PM, Rich Freeman wrote: On Mon, Nov 26, 2012 at 5:33 AM, Mike Frysinger vap...@gentoo.org wrote: along those lines, a news entry is probably not even necessary. So, users will just suddenly have their binary change names, and will need to manually move config files and update logrotate.d files (if in use), and the only notice will be in an elog? Oh, and that elog will appear for a program called hexchat which as far as the user is aware they don't even use. This really seems to be stretching the purpose of package moves, and I don't hear users generally complaining about the fact that we give them too much warning when we're about to break their systems. We really should be using news more, and not less. We can do what we do for mplayer2 and soon mpv. If the program is largely the same adding compatibility symlinks seems to me the simplest solution. lu
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 04:34 PM, Vadim A. Misbakh-Soloviov wrote: To be honest, in my opinion, «killing of separate /usr» can reasonable be continued by moving all it's content to / (/usr/bin - /bin, /usr/lib - lib, and so on) in despite of all objections, as it was invented just because of disk space exhaustion. And since we have lots of wonderful file systems, a neat and interesting device mapper and a plethora of fun way to shot ourselves in the foot not only you have a separate /usr but even fun separate /usr/bin from /usr/share and other strange layout that some people prepared to solve some of their problems. The radical solution is to have a rich early boot able to do this kind of setup, for the transition you might want to not have init and udev non-workable because somebody decided that is useful using glib or some other library residing in /usr/ lu
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 04:47 PM, Diego Elio Pettenò wrote: But yes, many more can't understand that... and neither do I. Then would be nice if everybody shuts up, let people play with their toys and if something useful happens evaluate the result. According to the people that asked me to help the whole thing would had been an experiment to see if would be possible to have a smaller and cleaner udev. I liked the idea since I like alternatives and I consider many choices from upstream a tad narrow minded (beside the entertaining posts from Linus about their bug management). Nobody wanted hype there, just more people willing to chip in some time and effort to get there. lu
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
On 09/29/2012 12:45 PM, Michał Górny wrote: On Sat, 29 Sep 2012 12:00:18 +0200 Tomáš Chvátal tomas.chva...@gmail.com wrote: 2012/9/29 Michał Górny mgo...@gentoo.org: Hello, Instead of the floating patches and p-d-ng modifications I sent earlier, here are the two complete (so far, well, initial :P) eclasses for review. They are designed as 'mostly' drop-in python-distutils-ng replacement. Hi, the eclasses look pretty, so good job, just one question tho, would it be possible to use more debug-something calls so the log file would be populated automatically with whats going on (same like eg git-2 eclass)? Try now :P. Looks even nicer, great! lu
Re: [gentoo-dev] media-video/vlc looking for a new maintainer
On 09/19/2012 04:00 PM, Ben de Groot wrote: Thanks for all you have done maintaining VLC all those years. It is undoubtedly one of the most popular and versatile video players out there. I really hope someone steps up to become its new dedicated maintainer. Given I'm in contact with upstream I might cover the interim since a release is impelling, I prefer shared maintainership though. lu
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On 09/22/2012 09:55 AM, Michał Górny wrote: Hello, The current dependency syntax: [VERSION-OP] PACKAGE-NAME [- PACKAGE-VERSION] suffers a few problems: I like the current syntax. lu
Re: [gentoo-dev] supporting static-libs
On 09/03/2012 10:54 PM, Maciej Mrozowski wrote: On Tuesday 28 of August 2012 02:15:40 hasufell wrote: Is there a reason not to support static-libs in an ebuild if the package supports it? It seems some developers don't care about this option. What's the gentoo policy on this? Isn't this actually a bug? A little remark. For CMake controlled buildsystem (as you're coming here from latest dev- games/simgear), there's no automatic way of building both static and shared libs (simgear allows to choose just one). Complain to cmake devs, hopefully they might come up with a solution. (the alternative is provide a clean autotools-based build system and ask upstream to please keep both. Usually works nice to cover all bases and make all people happy ^^; lu
Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions
On 09/21/2012 06:06 PM, Zac Medico wrote: On 09/20/2012 10:34 AM, Ambroz Bizjak wrote: The question now is, how should this method for checking --crosscompile be implemented? In particular, we have two options: - Environment variable. If so, how to call it? Possible names are CROSSCOMPILE, GENTOO_CROSSCOMPILE, PORTAGE_CROSSCOMPILE, ECROSSCOMPILE... For more generic names (CROSSCOMPILE) it needs to be taken into account that they may inadvertently affect packages. However environment vars have the benefit that it's easy to pass them through programs and scripts. - Internal function, similar to use. Probably is_crosscompile. This may look nicer and reduces the risk of collisions. Since it's just a boolean flag, we could have a special crosscompile USE flag for this, so that the use() function could be used like we currently use it for the test USE flag. The flag would be forced on or off based on your configuration, similar to the test flag [1], so there wouldn't be any danger of the flag being accidentally enabled or disabled. The flag could be bound to FEATURES=crosscompile, or some other package manager configuration variable. Note that if we add a --crosscompile option to emerge, then we'll also have to add it to the ebuid(1) command, so maybe it's better to forgo the commandline option and just toggle it with a configuration variable like FEATURES=crosscompile. Also, it's conceivable that you could drop the CROSS_HDEPEND variable, in favor of HDEPEND=crosscompile? ( foo ) syntax (somewhat in alignment with Brian Harring's DEPENDENCIES proposal). [1] https://bugs.gentoo.org/show_bug.cgi?id=373209 I like the idea. lu
Re: [gentoo-dev] supporting static-libs
On 09/22/2012 05:25 PM, hasufell wrote: add_library(foostatic STATIC foo.cpp foo.h) set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo) add_library(foo SHARED foo.cpp foo.h) Looks a bit kludgy but should work well as a macro, willing to contact upstream and/or ask cmake devs to include it? Looks like you have a simple solution for this problem =) lu
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On 09/22/2012 09:55 AM, Michał Górny wrote: Hello, The current dependency syntax: [VERSION-OP] PACKAGE-NAME [- PACKAGE-VERSION] suffers a few problems: I like the current one your proposal seems quite a problem for a large deal of usecases. 1. It is not really human-friendly. People don't say things like: I need newer than monkey-1.2. They say instead: I need monkey, newer than version 1.2. I need monkey-1.2 or newer sounds natural to me. 2. With long package names and versions, it becomes hard-to-read. Consider the following: =dev-foo/bar-very-long-my-name-is-4-beta-17 Where does the version number start? And yes, this is a valid package name to our rules. 4. Adding, removing and changing versions is not friendly at all. Consider the following dep: =dev-foo/bar-bas-bat-11.2.4_alpha Now, you want to bump the dep to 11.3. You need to find the version number, and modify it. Depending on the configuration, ^w is going to eat the whole package name or just a single component. Use a better editor. Then, you want to remove the whole version. You need to first remove the version number, making sure it doesn't eat a bit of package name as well. Then, you have to go back to the beginning of the string, and remove the operator. PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]] whitespace as separator for atoms looks a huge can of worms waiting to be opened. how you'd pass that to emerge? How you make a list of atoms? Please try not fix/break what is not broken. lu
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
No.
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
Alex Alexander wi...@gentoo.org wrote: On Sep 22, 2012 8:25 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 20:11:48 +0300 Alex Alexander wi...@gentoo.org wrote: On Sep 22, 2012 7:38 PM, Michał Górny mgo...@gentoo.org wrote: emerge 'foo = 1.1' 'bar 1.0'? emerge foo '=' 1.1 bar '' 1.0? How is the above easier to read than emerge =foo-1.1 bar-1.0 Did you even test it? That would create '=foo-1.1' and then fail trying to read 'bar-1.0'. It's rather: emerge '=foo-1.1' 'bar-1.0' Yes, you are right, still much easier to read than your example tho. Testing things is limited to very important stuff atm, I only have an android phone and intermittent 3g available and ssh without a real kb is a pain :-) I think your example is working against you*.* The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P It's no less quoting than in the current case. And it could be simply extended to supporting quoting-less syntax, e.g.: emerge foo -gt 1.1 bar -lt 1.0 I still find whitespace inappropriate for this kind of things. You are trying to replace a single atom that instantly gives you all required information with a format that does not clearly separate atoms, IMHO anyway +1
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Michał Górny mgo...@gentoo.org wrote:
It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.
Use case: xorg packages, ask Matt.
---
gx86/eclass/autotools-multilib.eclass | 72
+++
1 file changed, 72 insertions(+)
create mode 100644 gx86/eclass/autotools-multilib.eclass
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
new file mode 100644
index 000..1a345a1
--- /dev/null
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -0,0 +1,72 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: autotools-multilib.eclass
+# @MAINTAINER:
+# Michał Górny mgo...@gentoo.org
+# @BLURB: autotools-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The autotools-multilib.eclass is an autotools-utils.eclass(5)
wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE=multilib and exports
autotools-utils
+# phase function wrappers which build the package for each supported
ABI
+# if the flag is enabled. Otherwise, it works like regular
+# autotools-utils.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD
with
+# it.
+
+case ${EAPI:-0} in
+ 2|3|4) ;;
+ *) die EAPI=${EAPI} is not supported ;;
+esac
+
+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
+ die ${ECLASS}: multilib support requires out-of-source builds.
+fi
+
+inherit autotools-utils multilib
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+IUSE=multilib
+
+# @FUNCTION: autotools-multilib_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct
+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+#
+# If multilib support is disabled, it just runs the commands. No setup
+# is done.
+autotools-multilib_foreach_abi() {
+ if use multilib; then
+ local ABI
+ for ABI in $(get_all_abis); do
+ multilib_toolchain_setup ${ABI}
+ AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} ${@}
+ done
+ else
+ ${@}
+ fi
+}
+
+autotools-multilib_src_configure() {
+ autotools-multilib_foreach_abi autotools-utils_src_configure
+}
+
+autotools-multilib_src_compile() {
+ autotools-multilib_foreach_abi autotools-utils_src_compile
+}
+
+autotools-multilib_src_test() {
+ autotools-multilib_foreach_abi autotools-utils_src_test
+}
+
+autotools-multilib_src_install() {
+ autotools-multilib_foreach_abi autotools-utils_src_install
+}
How docs and nonbinaries get managed?
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On 9/10/12 11:05 PM, William Hubbs wrote: On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. NM seems bloated though unless you are using a desktop environment. It wants to install 29 dependencies on my box. NM and connman are quite a bit overkill indeed. lu
Re: [gentoo-dev] app-emulation/qemu app-emulation/qemu-kvm folding into one package
On 09/10/2012 03:55 AM, Doug Goldstein wrote: Hey all, Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to app-emulation/qemu at some point this week. The app-emulation/qemu ebuilds will effectively die and be replaced by the app-emulation/qemu-kvm ebuilds. I've brought this up before and there was a bunch of rabble about keep our pristine qemu ebuilds!!!. The fact of the matter is that the app-emulation/qemu just isn't getting the same maintenance care that app-emulation/qemu-kvm is. I've really only got the bandwidth to handle one at a time. Additionally this will bring us inline with a few other distros use of qemu as they're really building their binaries from qemu-kvm. I mostly care for the qemu-user variant (and lately I had been otherwise busy). I like the idea of keeping a single ebuild for the system emulation though. lu
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 08/28/2012 05:35 PM, Sylvain Alain wrote: Hi everyone, I don't want to start a flamewar on that subject, but I would like to know if there's any official position about the current situation. udev might or might not eventually get forked to avoid systemd borg-approach. mdev works fine for a number of people and they are working on getting better support for it even if some guys sometimes try to stomp over them for silly reasons. openrc during the summer got new features developed both for prefix users and for general public hopefully will get merged soon. The consensus is trying to support what makes sense of systemd and let people use it if they really want but not force it upon people happy or needing openrc. Beside that you have drama since there are strong opinions on how broken systemd is or how cool it is. I saw on the forum this thread : https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it could be part of a solution to have OpenRC and udev together. So, is there any developments lately ? Lots =) lu
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On 8/18/12 5:31 AM, Mike Frysinger wrote: i'll probably land it later this weekend/monday. Would be nice having a list of bugs open so people might have a look and see if there is something big left. boost and gnutls seem big enough already to spend some time to get those fixed before unleashing the beast. lu
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/14/2012 09:14 PM, Peter Stuge wrote: But it means nothing for someone who wants to open a box, switch on the power, and go online to $socialmediasite or $emailprovider. Sabayon does a decent job for them. lu
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On 08/10/2012 09:43 AM, Michał Górny wrote: vdr is a first example which comes to my mind. They workaround program configuration limitations and the init.d scripts become a complex extra-configuration parser + plugin loader. Well, another thing here is that upstream AFAIK is not willing to cooperate to fix their config parsing. 'oldnet' is an another example. I'm not saying it should go; I'm saying it should be a stand-alone executable called from the init.d script. Last time I looked, squid init.d was performing post-inst in start(). Many users may find that beneficial but that's not what init.d scripts should be doing. This discussion is really derailing. Currently most people using certain features from openrc feel quite defensive and mildly uneasy with the current situation since systemd is pretty much swallowing components we used to rely on and force radical changes w/out providing explanations to people that do not care and that are perfectly happy with what they have. Now Canek seems to feel like that I'm willing to kill systemd and make it impossible to use it in Gentoo. That's not the case, I consider systemd a bad idea since it is only geared to solve some specific issues and does that in a way that I consider dangerous for the global usage patterns I'm aware of. systemd ideas are interesting and for a dumb linux desktop the implementation would be ok. systemd doesn't work in many scenarios and when it gets pointed apparently there is a disagreement on that because systemd is perfect like it happens with it gets pointed that pulseaudio has shortcomings (that come from its design) or avahi doesn't seem that stable. I can live with a seldom broken audio subsystem and I can cope with the fact pidgin-bonjour could randomly crash, I'm not happy to be forced to move to something with the same attitude as my init system. The whole point of the debate should be if easier to have systemd split itself in usable components so people with certain focuses could leverage it on linux and replace those on non-linux (apparently not a chance) or have what we currently have and works decently and hopefully be compatible (so have a compatible interface for user-daemons, a compatible dbus interface for the desktop integrations and so on), not which project we should help to kill the others. lu
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/07/2012 09:00 PM, Olivier Crête wrote: I expect that in the not so long term, systemd will become an essential user-space component of desktop Linux, just like crond, syslog, dbus, udev or glibc. Sharing that code just makes sense, that allows As in completely optional and easily replaceable? That would be a nice improvement over the current use it or die attitude. distributions to focus on their strength instead of having to maintain a nightmare of shell scripts. Sure you can do a Android and write your own crappier version, but that doesn't gain you anything. Repeat after me: having your first process require anything more than libc is stupid and dangerous. Once that concept gets accepted then we could discuss about why reinventing shellscript may not be that sound and other less glaring, horrid and appalling design choices. Most ideas behind systemd are interesting, their current implementation is sometimes completely wrong and given the experience with pulseaudio we all know that they won't change even if you provide code for it. Obviously it is always fun seeing people first say accept it or fork it, then do not keep your fork you are wasting time once somebody starts forking and/or working for an alternative. lu
Re: [gentoo-dev] Global Systemd USE Flag
On 08/08/2012 04:53 PM, Michał Górny wrote: Yes, and please remove all the occurrences of 'GNU' because I don't like it. We have people working on a clang/freebsd gentoo, you might help them and use that. It sort of works fine. For a project Flameeyes replaced most of system using smaller alternatives to most of the gnu runtime. I'm helping getting musl as a first class libc in Gentoo, if uclibc feels too GNU-ish for you. As strange as it might feel for you we have people working on providing alternatives that might be useful for specific purposes. lu
Re: [gentoo-dev] Last rites: app-text/epdfview
On 08/07/2012 05:00 AM, hero...@gentoo.org wrote: Hi, Andreas K. Huettel dilfri...@gentoo.org writes: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? envision once hits portage, zathura with the proper plugin (remind me to add the mupdf one) I wonder why there isn't a gtk mupdf backed one yet. lu
Re: [gentoo-dev] Opinion against /usr merge
On 07/18/2012 08:27 PM, Michał Górny wrote: I don't think we should give more support to building a system from a statically linked rescue suite tool. For people wanting to shave some seconds from their boot openrc using busybox is quite handy and should be used as default IMHO. lu
Re: [gentoo-dev] Global Systemd USE Flag
On 08/09/2012 10:57 AM, Michał Górny wrote: No. I meant to have 'GNU' tools with 'GNU' stripped. Isn't that what the whole discussion is about? Changing names of tools just for someone's liking? No, we are discussing about an upstream merging two unrelated projects assuring users that nothing would change for them. In a week they claimed that it was unsupported, then backpedaled, then they changed its paths. Forking udev hadn't been considered mostly just on that premise. lu
Re: [gentoo-dev] Global Systemd USE Flag
On 08/09/2012 12:01 PM, Michał Górny wrote: On Thu, 09 Aug 2012 11:20:52 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 08/09/2012 10:57 AM, Michał Górny wrote: No. I meant to have 'GNU' tools with 'GNU' stripped. Isn't that what the whole discussion is about? Changing names of tools just for someone's liking? No, we are discussing about an upstream merging two unrelated projects assuring users that nothing would change for them. In a week they claimed that it was unsupported, then backpedaled, then they changed its paths. Forking udev hadn't been considered mostly just on that premise. So someone should just *finally* fork it, rather than talking about it all the time. I had that[1] since ages, mostly because I was curious about how complex udev is internally. If enough people want to play this game welcome. I expect the same people stomping on mdev complaining about the next little experiment. https://github.com/lu-zero/udev lu
Re: [gentoo-dev] pid 1 design
On 08/09/2012 04:02 PM, Peter Stuge wrote: Luca Barbato wrote: Repeat after me: having your first process require anything more than libc is stupid and dangerous. Why do you say? Because libc supposedly should be stable, other libraries are a bit more prone to radical changes and other annoyances. You wouldn't like to reboot your system if you replace/update dbus or glib, do you? And why is libc different from other libraries, say libuuid or libext2fs? I mean: Why allow pid 1 to require libc, it could just be statically linked. Actually statically linked initial process would be another reason why you'd like to NOT use large libraries and in large number. Obviously if you are thinking about desktop and not system in which replacing kernels should be done w/out downtime (qnx and some linux patches let you do that) it isn't a huge concern. Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... lu
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/09/2012 09:43 PM, Michał Górny wrote: On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato lu_z...@gentoo.org wrote: Repeat after me: having your first process require anything more than libc is stupid and dangerous. But you are aware that glibc is probably much, much worse than most of those 'stupid and dangerous' libraries, right? Then we have a bigger problem, since everything in our system is based on that. Once that concept gets accepted then we could discuss about why reinventing shellscript may not be that sound and other less glaring, horrid and appalling design choices. Yes, exactly. So why does openrc reinvent that horrible shellscript? It is not re-invented, in fact we can use any compatible shell. lu
Re: [gentoo-dev] UTF-8 locale by default
On 07/27/2012 07:24 PM, Mike Frysinger wrote: yes, and i'm waiting on the POSIX group to formalize C.UTF-8. that's the only real option in my mind for making unicode the default. any other amalgamations of various locales is ugly as sin. When they meet? I'd be fine with a pre-release =P lu
Re: [gentoo-dev] Re: udev - mdev
On 07/14/2012 03:21 AM, Olivier Crête wrote:
Seriously, mdev is a just a bad and now useless hack, it does nothing
more than using devtmpfs. You do not need udev for a very simple system.
If you system is a bit more complicated, than udev is what you want. It
works fine on millions of shipping devices.
And on any new embedded platform, one should seriously think about using
systemd too. It is very lean, replaces most of the giant, unmaintainable
shellscripts that you find in many devices with smaller compiled code,
and was designed to be a good fit for embedded devices.
Last time I looked at systemd it was anything that lean.
Obviously you can say that if you already need dbus and glib and ...
${systemd_deplist} it doesn't count.
Likewise if you are already using busybox it comes with a quite rich shell.
Most depends on what you consider embedded.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: udev - mdev
On 07/14/2012 04:34 AM, Canek Peláez Valdés wrote: On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] A lot of that is optional. The only hard dependencies are: =sys-apps/kmod-5 =sys-apps/util-linux-2.20 dev-util/gperf =dev-util/intltool-0.40.0 virtual/pkgconfig virtual/os-headers Everything else is optional. I repeat: the idea that udev is somewhat bloated or fat is really incorrect. Little correction: inherit autotools brings things like automake and libtool, but then again, almost *every* Gentoo installation has those. build dependencies should not count. =) The bare udev shouldn't be that huge, then you start look at the glib integration and such and it might get a bit more than you'd like. Forking udev and making sure it stays as lean as possible isn't that bad. Making mdev a bit richer and enjoy the speed advantage of busybox over stand alone shells could be another option. Most of the perceived speed in non-shell init systems is due not having to spawn as many processes. A full busybox wouldn't spawn many processes. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Fraunhofer FDK license
On 07/26/2012 12:45 PM, Andreas K. Huettel wrote: 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. Tell me where I should categorize it =) lu PS: help in improving libav aac encoder by leveraging atouv would be always welcome. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[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: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 01:41 PM, Thomas Sachau wrote: I guess, you are mixing cross-compile support in multilib profiles and cross-compile support with cross-toolchains, multilib-portage is for the first one, while crossdev is for the second one. My suggestion does not support e.g. compiling for ppc with an amd64 profile, on amd64 it only can support x86 and x32. Since all of these binaries can run with an amd64 kernel and you build for at least one target, you always have a binary around, no need for an extra HOST dependency. You can run an arm binary on amd64 (through binfmt+qemu-user static) I dont know, what exactly you mean with play properly with ld and cross-vs-host paths, so cannot respond to those. multilib works because the runtime linker picked is the right one for each ABI, thanks to qemu makes no difference if that ABI is native or not. cross vs host paths is an annoying problem due the slightly different behaviour between native and cross compiler toolchains, it tends to ignore environment variables and other small differences making dropping an native cross compiler in a qemu chroot, QUITE a creative activity. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 06/29/2012 04:30 PM, Thomas Sachau wrote: It is interesting, still you need a way to define HOST dependencies (stuff you need that has to be built on the host since you run it, e.g. xcb python code generator), something to play properly with ld and cross-vs-host paths for compilers (that part is _really_ annoying for qemu-chroots) lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] spec draft for cross-compile support in future EAPI (EAPI-5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 08:14 PM, Thomas Sachau wrote: and possibly split RDEPEND/DEPEND to have HDEPEND to list build dependencies that need to be run on host. What should the difference between DEPEND and HDEPEND be? Not library but program that have to run. Think about generators. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/hfm8ACgkQ6Ex4woTpDjRrtgCfXm2/b3FlZldoKfbVoNA8DKOf Sx4AoIAy1WEHulrBY3LsDxIyv6JUMjPV =MCO8 -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/20/2012 10:25 PM, Richard Yao wrote: Here is my wishlist for EAPI 5: Multilib (and/or multiarch) support Automated epatch_user support Parallel make checks POSIX Shell compliance Here are some explanations: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. Automated epatch_user support Users should be able to test patches without modifying their ebuilds. This also saves developer time because we don't need to navigate the portage tree (or an overlay), make a change and test it. We could just dump the patch in the appropriate directory and build. Parallel make checks As it stands, `make check` is so slow that few people actually run it and QA suffers as a result. We have the ability to do parallel checks, but we need to explicitly put `emake check` into the ebuild and use autoconf 1.12 to get that. It would be best if this behavior were the default, not the exception. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. It is more likely to succeed either adding to busybox the missing bits of bash we use or forking bash (so eventually it could be developed on a source repo) and making it lean and fast for our specific purposes. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On 06/17/2012 05:39 PM, Michał Górny wrote: But Python doesn't have one. Bindings built using other languages don't have that either. That seems something interesting to tackle with the python community. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] spec draft for cross-compile support in future EAPI (EAPI-5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2012 12:31 PM, Thomas Sachau wrote: Since i am not that sure about my ability to write formal specs, i am presenting my first draft for further review and suggestions for improvement. Currently I'm experimenting with evil hack with qemu-static (hopefully that would make my student life happier later). What would be nice on a full multilib/multiabi system is to have /lib/ld-linux-foo-arch.so.2 for each active architecture /usr/$CTUPLE/ as destdir for each of them PATH and ld.so.conf pointing to them accordingly. and possibly split RDEPEND/DEPEND to have HDEPEND to list build dependencies that need to be run on host. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gvVYACgkQ6Ex4woTpDjQlaQCg1W/PZxOo/2EDktU0XR6/48nf 9RcAoOg40vFoSIX7gNpD82qdym54MB4m =hEyq -END PGP SIGNATURE-
