Re: [gentoo-dev] dm-crypt reordering BIOs across barriers?
On Fri, 07 Jun 2013 23:47:33 -0400 Richard Yao r...@gentoo.org wrote: When you use dm-crypt, block IO requests to a dm-* device will invoke dm_request_fn() - map_request() - crypt_map(). If a BIO is a write barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(), which will immediately queue it to the device. If a few dozen IOs are queued in rapid succession with multiple write barriers, all write barriers will be executed before any actual write BIOs occur because the write IOs will be processed asynchronously in a work queue. Since the barriers will be long gone by the time the write IOs are queued, they can be queued in any order. Am I misunderstanding this or is dm-crypt ignoring proper write barrier semantics? http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html http://lwn.net/Articles/400541/ -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] app-dict team needs help
2013/6/7 Dennis Lan (dlan) dennis.y...@gmail.com stardict: trivial bugs around but i don't use stardict. Hi Tomas I'm a stardict user, let me know what I can help Hello Dennis, Currently there are 18 open bugs [1], so just looking into them would be nice. Checking if the ebuilds could be moved to latest eapi and cleaned up might be good. Opening stabilisation bug requests for various dictionaries that are for 3+ years in testing is also good idea :-) Also if you have any diffs just sent the mail to me or proxy-maint@g.o and we shall include it in cvs (gosh I want git and gerrit). Cheers Tom [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=stardict
Re: [gentoo-dev] dm-crypt reordering BIOs across barriers?
On 06/08/2013 02:11 AM, Sergei Trofimovich wrote: On Fri, 07 Jun 2013 23:47:33 -0400 Richard Yao r...@gentoo.org wrote: When you use dm-crypt, block IO requests to a dm-* device will invoke dm_request_fn() - map_request() - crypt_map(). If a BIO is a write barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(), which will immediately queue it to the device. If a few dozen IOs are queued in rapid succession with multiple write barriers, all write barriers will be executed before any actual write BIOs occur because the write IOs will be processed asynchronously in a work queue. Since the barriers will be long gone by the time the write IOs are queued, they can be queued in any order. Am I misunderstanding this or is dm-crypt ignoring proper write barrier semantics? http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html http://lwn.net/Articles/400541/ It might be worth stating that I thought flush was a synonym for barrier. It still looks like there is an issue, despite my incorrect terminology. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] app-dict team needs help
On Sat, Jun 8, 2013 at 5:00 PM, Tomáš Chvátal tomas.chva...@gmail.comwrote: 2013/6/7 Dennis Lan (dlan) dennis.y...@gmail.com stardict: trivial bugs around but i don't use stardict. Hi Tomas I'm a stardict user, let me know what I can help Hello Dennis, Currently there are 18 open bugs [1], so just looking into them would be nice. Checking if the ebuilds could be moved to latest eapi and cleaned up might be good. Opening stabilisation bug requests for various dictionaries that are for 3+ years in testing is also good idea :-) Also if you have any diffs just sent the mail to me or proxy-ma...@g.oand we shall include it in cvs (gosh I want git and gerrit). Cheers Tom [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=stardict Hi Tom: ok, I'd plan to bump stardict first, there is already one in gentoo-zh overlay will reach you when I'm ready.. Later I will go through the bugs.. I'm using git, can send you patches, but I'm not sure how we can cooperate with gerrit. Dennis Lan
[gentoo-dev] Re: app-dict team needs help
Dennis Lan (dlan) posted on Sat, 08 Jun 2013 19:11:13 +0800 as excerpted: div dir=ltrbrdiv class=gmail_extrabrbrdiv Please turn off HTML when replying to the list. (I was ignoring, but now that you've posted several times, I thought it worth requesting.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Re: Re: eselect init
On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote: 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. .. 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. Actually the point is how to implement the best solution in Gentoo, which is the point of this mailing-list. To float ideas and see what other perspectives can contribute to the design. For instance, I think Duncan's idea of a single mode, effectively secondary bootloader, is the only thing that makes any sense. It's a Gentoo-specific init-switcher that only runs when the user has initiated a switchover. Implementing an init fallback is unneeded, since the kernel tries so many paths already. And Duncan's mail is at least about the interesting, and *useful* part: making the system ready to switch, and a setup for init-system switching as a whole. Including write to rootfs, eg to change inittab format. 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. No you weren't polite. You wrote an email that had zero technical content in it and that was basically just 'ad-hominem' as has been pointed out to me: http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of-debate-550x417.jpg Review your last email in the context of the above, please. 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. Yes because programmers never make mistakes, and humans are so good at separating the woods from the trees.. 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... Lala. Someone puts the install together: they run (or their script runs): mv /sbin/init /bin/init mv /sbin/einit || error 'unable to setup init' 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. Actually none of this has got anything to do with systemd, nor did I mention it, so please stop banging on about your feelings about it. They're not relevant to this discussion, since it's init-system agnostic, just like the kernel fallback mechanism is, or there's no point to it. On an EFI-stub only system it would require at least a kernel rebuild or a trip to the efi shell if available. No it wouldn't, see above. And http://marc.info/?l=gentoo-devm=136968639518816w=2 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: Ah finally some technical content. Yes, the above was a waste of time, and so was your last email. Just a friendly reminder. - eselect init will be opt-in for the time being, people can be left on their own tools if the want it Yes, but we want a sane and robust implementation in Gentoo, irrespective of who's using 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). You mean use the kernel fallback mechanism? I'm sure you won't be surprised to hear I think that's a good idea. - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. Sounds good. busybox using the standard location with a non-standard format sounds like a mistake though, at least for the default Gentoo config, where it is supposed to live alongside the normal Linux utils. When the user has a saved-config, it is of course up to them what happens. - people wanting to switch init or
[gentoo-dev] Re: Re: Re: eselect init
On Sun, Jun 02, 2013 at 08:48:23PM +0200, Fabio Erculiani wrote: On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: [...] The whole symlink/boot/fallback thing is simply a waste of technical effort. And blanket your opinion and you didn't comment a week ago, so I don't have to deal with the substance of your points don't change that. Waste? We have multiple use cases for that as stated in several places (here, bugzilla, IRC, etc). If such use cases are of no interest for you, then you shouldn't be bothered. The specific idea of reimplementing the kernel fallback mechanism is a waste of technical effort. Not the whole idea of eselect init, as I stated several times. If you lose that idiotic idea, you have a lot less complexity to worry about and can instead get on with the *necessary* complexity: handling whether it is safe to switch boot, and how to make it so given the 'from' init and the 'to' init, which might require write access to the rootfs, eg to swap inittab, or to mkdir -p a necessary path. It could need anything, there's simply no way of knowing, and it will require maintenance over time as init-systems change. That's why the Unix inventors came up with sh. And the best people to maintain it over time, are the users in collaboration with the init-system devs, since they are the ones who have the testcases in front of them, and the motivation to make the software work. While the devs have a broader view, and an interest in keeping things portable (aka: 'generic'.) Please try to read and consider my whole argument, instead of selectively quoting one part and using it to justify YAF ad-hominem. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: [gentoo-dev-announce] New Developer: Mikle zlogene Kolyada
Am Samstag, 8. Juni 2013, 16:21:09 schrieb Markos Chandras: Good day everyone, It is my pleasure to announce a new developer. Mikle zlogene Kolyada is joining us from Yaroslavl, Russia and he will be joining the perl and amd64 teams for now. Most of you already know him since his is an amd64 arch tester for a long time. This is how he describes himself: My name is Mikle. Nowadays i live in Yaroslavl. I have been a Gentoo user for about 4 years, and I'm interested in installing Gentoo to different devices and architectures. When i have free time i like to watch cinema, listen to music and playing with new software and various hardware. Please give him a warm welcome! -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang Yay! Perl! Awesome! :D Welcome Mikle! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/dulwich: dulwich-0.9.0-r1.ebuild dulwich-0.8.7-r1.ebuild ChangeLog dulwich-0.9.0.ebuild dulwich-0.8.7.ebuild
On 06/08/2013 09:20 AM, Ian Delaney (idella4) wrote: idella4 13/06/08 13:20:59 Modified: dulwich-0.8.7-r1.ebuild ChangeLog Added:dulwich-0.9.0-r1.ebuild Removed: dulwich-0.9.0.ebuild dulwich-0.8.7.ebuild Log: revbump, migrate - distutils-r1, add nose to deps for tests, remove old (Portage version: 2.1.11.63/cvs/Linux x86_64, signed Manifest commit with key 0xB8072B0D) You removed the only ebuild with stable keywords. Please don't do that.
[gentoo-dev] repoman warning on python data_files
Hi I have just noticed that if package is using relative paths in:: setup.py data_files = ... Then the files are installed right into /usr in case of CPython (The exact dest is determined by sys.prefix) So, I'm thinking it could be worthwhile to add a warning to repoman if package is using this method as I can imagine this can be easily overlooked when creating a new package or mostly when bumping one.
