Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
23.09.2013 22:29, Markos Chandras пишет: On 09/23/2013 03:07 PM, Alexis Ballier wrote: we have 'stable', 'dev' and 'exp'; the difference between 'dev' and 'exp' is unclear to me. it could be changed so that broken deps in 'dev' profiles are a repoman error (without -d) but without stable keywords. Alexis. I believe the 'exp' profile makes no sense. It might did in the past, but I believe we are fine having only 'stable' and 'dev'. So unless I am missing something obvious, 'dev' can be used to express ~arch only architectures whether they are in a good or bad state. I think current dedication of pure-unstable arches on well-maintained and dependency consistent arches in dev and arches where dependency consistency is someway broken(Prefix) makes sense. Unless somebody wants to clean up some mess i have seen in Prefix deps by fulling package.use.mask in prefix profiles with tons of deps. Anyway, we have apropriate options in repoman for checking on dev and exp profiles, and, regarding the Prefix, i think we can try to move prefix profiles to dev when Prefix tree will be merged with gentoo-x86 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org wrote: We have four active Gentoo developers in the team and one very helpful user. Plus a number of developers who are working in their narrow areas and supporting us indirectly. That's more than I expected, and the project has bright future. There are a few people who just like to trip us up but I think it'll all end up well in the end. Is there a work-in-progress code repository somewhere? Mailing list? If I'm going to keep hacking on this I should definitely sync up with you guys, I have a growing number of offline patches (some of which might be good enough to go in as-is, some needing some work, and a few abominations). -gmt
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
Dnia 2013-09-24, o godz. 01:40:58 Greg Turner g...@malth.us napisał(a): On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org wrote: We have four active Gentoo developers in the team and one very helpful user. Plus a number of developers who are working in their narrow areas and supporting us indirectly. That's more than I expected, and the project has bright future. There are a few people who just like to trip us up but I think it'll all end up well in the end. Is there a work-in-progress code repository somewhere? Mailing list? If I'm going to keep hacking on this I should definitely sync up with you guys, I have a growing number of offline patches (some of which might be good enough to go in as-is, some needing some work, and a few abominations). Not really, most of the code goes into gx86 directly. Some of it gets masked first (like the late OpenGL batch). We can be reached through multi...@gentoo.org. If you prefer IRC, you're looking for mgorny, pacho2, aballier, _AxS_, iamnr3. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] markdown docs like README.md
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. I see two possibilities: 1. Create one or two eutils functions like domd: will go through all viable implementations like markdown/markdown_py/Markdown.pl, convert the file and dohtml it. Is no impelementation installed on the system it will fall back to plain dodoc. Optionally we could provide md_depend (like DEPEND=$(md_depend)) to ensure that at least one implementation is present (might be useful for very huge docs that are easier to read as html). 2. Introduce something like virtual/markdown... unfortunately the markdown name is already reserved by app-text/discount, so I don't really know how that would work out. And the supported arguments might differ... This is low priority, so if this is going to take more then little work, I'll probably lose interest. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSQdCtAAoJEFpvPKfnPDWzTAUH/iv42uJz9S1Ky0j6jSYYNlYo MGPdo6oQFMVHUOSBuC0tqz/k/sWnk32K3MYYoTfneVK907jMjGK+TLrdAy35nXjD PKDQeu3lZvA9Yd1RhDtKWAKOj32OJTvxtBakX4Q+RielBhgesIzfJVAYVAFGk/l7 igwpabGuKCz8xC13DSvvMScHSod9f/eGuHGcT/4TM5DuMXodWKHuqN9Smy02cPuL 9AluDpmbRcummpyTiWjMgAvPEPhlowsg/DMSzd8Cz/eeeOJsZtIFF+fBQOGP5xHI eIW4SoRFGnBMB8lM35aEBoN7WlrvR6lKmQay/CVqN2a3H0Zyd8Zt1p66pkkx2So= =1R0w -END PGP SIGNATURE-
Re: [gentoo-dev] markdown docs like README.md
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Sep 2013 19:49:33 +0200 hasufell hasuf...@gentoo.org wrote: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. Aren't there thirty seven different incompatible formats all called markdown, all of which require different tools to process correctly? - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlJB0lQACgkQ96zL6DUtXhGGawCgr5uPYjBOTIYyxz1/zUKJCUpg b8oAoMMFn4F1psgiy10rqUNqCJeF1HU3 =jfdj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- IIRC we still don't have an openrc-replacement script in the tree for the /etc/init.d/function.sh symlink to target. Since libeinfo is already public, why not instead of making it private we go the other way -- keep it public, package it out separately in the tree, and make openrc (and others from bug 373219 and elsewhere) depend on it? Because it is a c library, which means that another program would have to be written which provides the einfo/ewarn/etc shell commands and a functions.sh wrapper so the shell scripts can use it. Since the consumers on bug 373219 are shell scripts, why have the complexity of a wrapper and not just provide a shell script? I know I have been slow about it. mostly because I've been doing a lot of work on OpenRC lately wrt bug #482396. That should be wrapping up soon. Out of curiosity, what is the reasoning behind making these libs private? Well, the thought has changed slightly. librc can't be made private currently because of openrc-settingsd. libeinfo, on the other hand, does not have any known consumers, so there is no reason to keep it as a library. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlI98aMACgkQ2ugaI38ACPCTcQD9HIqOTlhia/ktPFANAZdJbfEv DqOh7CUCULZw+FqkOpQBAISPbWdsg+flecvnv5OfWGsnLqnYK6GPG4e23KwDyz1e =OCdp -END PGP SIGNATURE- signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/09/13 02:15 PM, William Hubbs wrote: On Sat, Sep 21, 2013 at 03:21:07PM -0400, Ian Stakenvicius wrote: Out of curiosity, what is the reasoning behind making these libs private? Well, the thought has changed slightly. librc can't be made private currently because of openrc-settingsd. libeinfo, on the other hand, does not have any known consumers, so there is no reason to keep it as a library. That doesn't answer my question, though; yes at this point there's no reason to keep it public, but -why- move it to private? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJB2EoACgkQ2ugaI38ACPC8uwD+PwSGgcRI1Yv4COVjfavrbt4p tag4I4xzueXBvBBeIygA/RPCV+xnK5SHwdGluxQxPUj0Zpg4EPeeJ/+F1gpWVPC7 =cEZR -END PGP SIGNATURE-
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
On 09/23/2013 22:41, Markos Chandras wrote: (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) 11:16 #gentoo-bugs: +bonsaikitten ago: do me a favour and de-keyword all affected packages for s390 Also, nobody give me an award for the commits, so I really don't understand what you mean. -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/22/13 5:24 PM, Peter Stuge wrote: Paweł Hajdan, Jr. wrote: compiling with versions of v8 other than what is included is not currently supported. .. For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often I agree that it isn't worth the effort to try to offer V8 as a library then. Perfect. As soon as upstream stabilizes one API/ABI I think it would be wise to make a package providing that as a library. Yes, and I'll be trying to move upstream in that direction. Not everybody understands it but actually it isn't a library if there isn't a stable API/ABI. Thanks for mentioning that. Totally agreed. At least applicable to a shared library. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/24/2013 07:28 PM, Agostino Sarubbo wrote: On 09/23/2013 22:41, Markos Chandras wrote: (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) 11:16 #gentoo-bugs: +bonsaikitten ago: do me a favour and de-keyword all affected packages for s390 Also, nobody give me an award for the commits, so I really don't understand what you mean. I don't understand why you quote something from Patrick. All I am saying, is to avoid mass-commits for no reason. The stable keywords will be lost during time by removing old version of the packages. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQJ8BAEBCgBmBQJSQeLuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88CYMP/0yTCEJoK3j66St+mOEqwn0a 7n4fW1/GtlQWTI2NLmSA7UzT01wO0AT44rp84zs2nwToY/pQ9h5QPe9ktxkdtpuj spGYsLhtEdLwufYk9nQOOgPeQ9v4y3xzZfmtzqPJrf2mNywECXg58O4AlEWMBQAN p+ntBFub70J4zSk42p4jNr6SEIm3fkzCKLDh2a/CE4CYaG+4U4Bzy1arwj+uRi4P YbHK90x2RvI/gG9VBVTuaDwir8x5qZmAlgOEkFiiSpcvM2Ht6jl1eiF+wgIHXy9B zfZ83JF86iXZo1+naT7F92awcU7sSIS+oFE+ElF/NwCP+idlMM2y7Ui+/irXTPSt xpSgus96fpquM+2Ab38tY1ILQRysKBc2QEi/PJ+FB0yx1tNb8LN1xGTqBMySMhEW p6it2wKcsCEaPzfveuMupe6L2QgA/nvR/FILTQccL9WivfvsBT4zAUzK1DaKowSV NkH4RhL3R6GAXvWDQTXZqpm9SXoRzHQG3Xs74WuCM7b0rYHB0o0UxEB3vjUVraal r26GDxXUqPQjLPcKXf2d+6owVSDW3yNo7Ep0y3UJuzgRdpgFbt7F2chWMNTQFfAr Wo3MO3+Q4W2hck4LSehNKJk0ozR7SHUqkkTC1cPfDye9iqmxycVOSoO0++OsDiS9 9pDh/4YTkgkn0kPBMR/y =9a9b -END PGP SIGNATURE-
Re: [gentoo-dev] markdown docs like README.md
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Sep 2013 19:49:33 +0200 hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. Converting them to HTML format is useful for people whom do not want to use a Markdown viewer and would benefit from reading them in HTML format, as opposed to text mangled with formatting constructs. Do we want to cover this by an USE flag or apply the conversion for every package based on a present implementation? What if someone decides to switch between both? Do we want to keep the original Markdown file installed as well or would we prune it after conversion? I see two possibilities: 1. Create one or two eutils functions like domd: will go through all viable implementations like markdown/markdown_py/Markdown.pl, convert the file and dohtml it. Is no impelementation installed on the system it will fall back to plain dodoc. Treating files as Markdown sounds like a good start. Optionally we could provide md_depend (like DEPEND=$(md_depend)) to ensure that at least one implementation is present (might be useful for very huge docs that are easier to read as html). No idea if such construct is the right way; I generally don't like this when other already implemented approaches exist, like using a virtual. Why wouldn't a virtual suffice? 2. Introduce something like virtual/markdown... unfortunately the markdown name is already reserved by app-text/discount, so I don't really know how that would work out. And the supported arguments might differ... A virtual for converters sounds better to me than $(md_depend); it spares out making eutils more complex, having to inherit eutils and having the dependencies where one would not expect them. (Do we want a virtual for viewers too?) This is low priority, so if this is going to take more then little work, I'll probably lose interest. It's a small change you want to see; it'll take little time if we go for implementing just what is really necessary, the KISS principle. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSQe92AAoJEJWyH81tNOV9+7kIAIMJVjDElGCbvib0v8YiFI7X IKygjcTosHvim9tjN78ShXn+1RvCyPeDZVEGU4+tQ3mYOiHe/mOm5QC6N/tN/ZOy +Vl42Xfwd6QGmObuJHgsMcpPQmjx3GUDKSIq0j3tZfx6MSVz9/QWtXV+h+7ZZo/W jj/lLhc0BQ5ryf+aoB/poutANoiPL0QzxTOpPZ4v/MqY8SUN/Pv7V27kdPdgYzut HkxvWUmpA+Vy8483X8IQPVQxaITv0e+O9v0Zjh0n5yc14qxx1ChlzIN2rfntky8J JHJRwN6gsUhC6eZdxoOUgkOUlRi523tlAEp7on4b0WmBpNSAS/aF14x8Oaxi/kQ= =ejC9 -END PGP SIGNATURE-
Re: [gentoo-dev] markdown docs like README.md
Dnia 2013-09-24, o godz. 19:49:33 hasufell hasuf...@gentoo.org napisał(a): I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. What for? The point of markups like Markdown is for the text to be readable as plain text. Converting it to HTML goes against this principle. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2013 10:15 PM, Michał Górny wrote: Dnia 2013-09-24, o godz. 19:49:33 hasufell hasuf...@gentoo.org napisał(a): I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. What for? The point of markups like Markdown is for the text to be readable as plain text. Converting it to HTML goes against this principle. I am not sure if I can follow that logic. The purpose is to not convert it to html? I am very well aware that it is readable both ways, but some users were requesting to convert installed docs in markdown format into html. I personally don't care much. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSQfkDAAoJEFpvPKfnPDWzTp4H/0ohVRG1VTzLqDgrW8B8AgPP 2z6LPD1O1lkdzjT0rTEmEFmJmFD4IDISXv3PrXXxiN+V2purrz/0cR91so6BHaHJ vMSt4pmfPxyiH7xvEYu0P89iK5HsAtsJEnbrF6D7dvWvNyMt4DuoujgMROeanFjS DGmarLCDlBkgxi/Ym09E/TzBR9J40FW2sc1MxMHABRlHySHqsc1AxCwGxEgit+Uk SuNV4roSDTi51aYSOA/X3ZJqP1jtAtlq9Lg6pHvaJTl8vorj1rqwlkXk1hlR1txC zh/zhilp9g//+n7kvzLUCaSUXSWURbNPdAqcfXn7BxyqzrDmFr/ggDiP2WwuGbA= =c3gv -END PGP SIGNATURE-
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
El mar, 24-09-2013 a las 22:38 +0200, Andreas K. Huettel escribió: Am Dienstag, 24. September 2013, 21:07:26 schrieb Markos Chandras: On 09/24/2013 07:28 PM, Agostino Sarubbo wrote: On 09/23/2013 22:41, Markos Chandras wrote: (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) 11:16 #gentoo-bugs: +bonsaikitten ago: do me a favour and de-keyword all affected packages for s390 Also, nobody give me an award for the commits, so I really don't understand what you mean. I don't understand why you quote something from Patrick. All I am saying, is to avoid mass-commits for no reason. The stable keywords will be lost during time by removing old version of the packages. Yeah, but while this process is ongoing, repoman will barf on the remaining stable set... so better remove it in one go. -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ Maybe repoman could be fixed: if ~sh and sh keywords will be enabled for sh users, why repoman doesn't follow it? (and, then, let both keywords to supply the needed deps)
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
Am Dienstag, 24. September 2013, 21:07:26 schrieb Markos Chandras: On 09/24/2013 07:28 PM, Agostino Sarubbo wrote: On 09/23/2013 22:41, Markos Chandras wrote: (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) 11:16 #gentoo-bugs: +bonsaikitten ago: do me a favour and de-keyword all affected packages for s390 Also, nobody give me an award for the commits, so I really don't understand what you mean. I don't understand why you quote something from Patrick. All I am saying, is to avoid mass-commits for no reason. The stable keywords will be lost during time by removing old version of the packages. Yeah, but while this process is ongoing, repoman will barf on the remaining stable set... so better remove it in one go. -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] markdown docs like README.md
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Sep 2013 18:56:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: hasufell hasuf...@gentoo.org wrote: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. Aren't there thirty seven different incompatible formats all called markdown, all of which require different tools to process correctly? Yeah, there are. But do we need to support them all? A lot of these formats are used on websites alone; so, they are not relevant here. If you boil it down to formats you store, use or process locally, it gets shorter. Do we actually want to process all the alternatives correctly? === TL;DR: Lack of standardization is a mess, let's work with what we have. === When I hear Markdown I think about where it all started: http://daringfireball.net/projects/markdown/ And I would propose we focus on that syntax to start with; if we want to support a widely used alternative, we could implement support for specifying which format is used and use a compatible converter. We then come down to a popular alternative: https://help.github.com/articles/github-flavored-markdown Yes, I can see what you mean, it leads to certain inconsistencies; and David Greenspan (not the actor; founder of EtherPad, now working on Meteor) also noticed that about a year ago. He reached out to Jeff Atwood which shared the same thought and reached out to a lot of people: http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html But apparently, this doesn't seem to have worked out so well; this is because it is often used within the context of a website and the Markdown contents aren't really exchanged among websites. They are not really trying to standardize a protocol here, but rather something people use when writing out a comment on some website; if users then switch from Stack Overflow to Reddit they will barely tell the differences in the particular behavior the syntax would produce. GitHub is kind of an exception here, they allow you to place files in your repository that you can read on their site or read on your device as plain-text, using a Markdown viewer or a converter. While a Markdown viewer has existed before that and you could just do it; I don't recall it being common use in the back of the days, it's only when you plan to exchange it across communities and / or people that a standard becomes a necessity. GitHub has introduced exchanging. But, are there other alternatives? Yes, there is the original; some people might be writing their repository's README.md in that format, unintended, then not noticing that GitHub reads it a bit differently. It's going to be hard, but I think we might want to let the user decide which particular implementation is in favor; or give the user some way to switch back in forth, or let the user have the choice to use some converter that attempts to implement the best of each format. As long as websites use Markdown in their own way; we will be unable to use a standard, let alone ensure that all the Markdown files we get to read are in a particular standard for Markdown files in repositories. Not until the big Markdown consumers step up and change the game. Let's work with what we are given for now; but indeed, we should be well aware that no standard is present and the future can change. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSQgVRAAoJEJWyH81tNOV9lssIALs7e95SC7XnCZ2KpZlFSYvI GqqIe8CrXrGn4f+xugmgSQgDc3QqNIxTj5lib/7K3pMOtZfqxwGsNe+nVWvlQ0sH 3jhUFIGhlcGdnBt+ibkkfrdyFmPa2lKXKzsK/XLzR2on0AezspeHtsWEfQzNLjBn rgMOXDrIwHGgdOUKAerKW//6CJUhvvn6M9gxFImiLcQueKMNLxHBYm09dkbRU+XM 1/Yv5HhvqwbnVOtDIR9up736D3lv02ZmGg0kxvf7EjEJT+1TJDoS7kezamSXk+1o xflwOLGcEURkRTQj39I9qZCO21yBnw6Ge/JDtNn6Tw94KysueTN/u7rtlPp8/rQ= =MpAx -END PGP SIGNATURE-
[gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
All, In the meeting today (24-Sep-2013), the council agreed that all preparations for dropping support for Linux systems with /usr on a separate file system that do not use an initramfs are complete. I am submitting this news item for review, and I plan to commit it on 2013-09-27 if there are no major issues with it. On behalf of the council, William Title: Separate /usr on Linux requires initramfs Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2013-09-27 Revision: 1 News-Item-Format: 1.0 In the meeting on 24-Sep-2013, the Gentoo Council agreed that all preparations for dropping support for Linux systems with /usr on a separate file system that do not use an initramfs are complete. Therefore, starting on 01-Nov-2013, we will consider this configuration to be unsupported. This means if you have a separate /usr configuration, it is important to convert to using an initramfs. If you do not convert and you upgrade packages on or after 01-Nov-2013, you will, at some point, find that your system is unbootable. For more information on creating an initramfs, see the following URL: https://wiki.gentoo.org/wiki/Initramfs/HOWTO signature.asc Description: Digital signature
Re: [gentoo-dev] markdown docs like README.md
On Tue, 24 Sep 2013 22:15:15 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-24, o godz. 19:49:33 hasufell hasuf...@gentoo.org napisał(a): I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. What for? The point of markups like Markdown is for the text to be readable as plain text. Converting it to HTML goes against this principle. You are pulling things out of context. Let me quote [1]: Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML. (1) If it is a formatting syntax, then why would we make text any more readable than it already is; actually, by mangling it with formatting constructs it could even end up being less readable. (2) It is a tool as well, saying it goes against a principle would be denying its existence and usefulness; consider that the global use of Markdown consists of a lot of conversion, we shouldn't neglect that people want to use it as it benefits them. Principle or not, we shouldn't force our users down a particular way to reading them; as that's not what our meta-distribution stands for. [1]: http://daringfireball.net/projects/markdown/ -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
Dnia 2013-09-24, o godz. 23:50:20 Tom Wijsman tom...@gentoo.org napisał(a): On Tue, 24 Sep 2013 22:15:15 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-24, o godz. 19:49:33 hasufell hasuf...@gentoo.org napisał(a): I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. What for? The point of markups like Markdown is for the text to be readable as plain text. Converting it to HTML goes against this principle. Principle or not, we shouldn't force our users down a particular way to reading them; as that's not what our meta-distribution stands for. We shouldn't either work on working for every fancy a single user may have. If there's a real benefit from converting markdown to HTML, please show me one. As far as I can see it, we're either talking about: 1) replacing semi-readable Markdown with unreadable HTML that will require special tools for proper display, 2) installing duplicate files (the same data in markdown and in HTML), 3) adding some more ugly awful magic that will make binary packages even less useful. That said, I'd rather see people using *tools* to display Markdown rather than converting everything 90s-style. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
hasufell hasuf...@gentoo.org writes: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. I'd rather leave it alone, as markdown is more readable than html, IMHO. Anyway, when we read html in the console, it's converted back to plan text.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Tue, 24 Sep 2013 16:43:22 -0500 William Hubbs willi...@gentoo.org wrote: Title: Separate /usr on Linux requires initramfs Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2013-09-27 Revision: 1 News-Item-Format: 1.0 In the meeting on 24-Sep-2013, the Gentoo Council agreed that all preparations for dropping support for Linux systems with /usr on a separate file system that do not use an initramfs are complete. This sentence feels long and yields multiple questions for the user: 1) Where can I read more about this meeting? What is the Gentoo Council? 2) What are these preparations? Does the user need to know about them? 3) Why is support being dropped? Why was it a problem? Since some of these are not really important to start the news with; I would suggest to start the mail about the drop in support and give some reference to another article/mail describing the problem after that. So, something along the lines of: Linux systems with /usr on a separate file system that do not use an initramfs will become unsupported, starting on 01-Nov-2013. Then go on like: This decision has been taken because of [problem]; you can read more about that in [article/mail references]. We could probably leave out the meeting and preparations; remember that the mail is focused towards the user, so should focus on why the situation changes and how the user can accommodate with that. If it is a necessity to add it, please consider doing it at the end. Therefore, starting on 01-Nov-2013, we will consider this configuration to be unsupported. The date has been embedded in my above rewording, avoiding repetition. This means if you have a separate /usr configuration, it is important to convert to using an initramfs. If you do not convert and you upgrade packages on or after 01-Nov-2013, you will, at some point, find that your system is unbootable. For more information on creating an initramfs, see the following URL: https://wiki.gentoo.org/wiki/Initramfs/HOWTO Sounds good; since this is the most important to the user, we might want to restructure this to be mentioned earlier in the news message. Possibly between the two example sentences I gave. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
On Wed, 25 Sep 2013 00:07:15 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-24, o godz. 23:50:20 Tom Wijsman tom...@gentoo.org napisał(a): Principle or not, we shouldn't force our users down a particular way to reading them; as that's not what our meta-distribution stands for. We shouldn't either work on working for every fancy a single user may have. If there's a real benefit from converting markdown to HTML, please show me one. It brings them to the same structure as any other HTML documentation; if I'm going to take a complete opposite idea, we could also consider converting PDFs to HTML for people whom don't want a PDF reader or want to read the documentation on another device that doesn't even support PDF. Furthermore, HTML and CSS gives them control on how the text should be formatting; something both PDF and Markdown does not. PDF is of course not the best example, because the binary of a PDF isn't really readable to a human whereas Markdown was meant to stay readable; but I'm just saying that whereas you might not see a benefit, that doesn't mean that nobody else does. If I want to browse all documentation with a browser, just going to something like file:///usr/share/doc and read them all in the same style (using an extension like Stylebot or so); then it would be neat if Gentoo could bring them down to the same format to me, instead of that I would need to do local conversion or use multiple viewers for what could be in one canonical place. Why do I need a browser, a PDF reader and a Markdown viewer and possibly more clients to read my documentation in a formatted way? As far as I can see it, we're either talking about: 1) replacing semi-readable Markdown with unreadable HTML that will require special tools for proper display, Just some basic CSS will do just fine. 2) installing duplicate files (the same data in markdown and in HTML), This hasn't been discussed yet; but it doesn't need to, it's the usual INSTALL_MASK story. 3) adding some more ugly awful magic that will make binary packages even less useful. For binary packages a choice has to be made; trying to solve things for binary packages is like discussing something to be implemented on a binary distro, you simply can't bring the usefulness we are discussing here to a binary package because of its nature. That said, I'd rather see people using *tools* to display Markdown rather than converting everything 90s-style. I'd rather have a single tool that displays documentation and display it really well; people are still converting things these days, they will continue to do so in the future. Some things aren't compatible. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
On 25 September 2013 10:30, Tom Wijsman tom...@gentoo.org wrote: If I want to browse all documentation with a browser, just going to something like file:///usr/share/doc and read them all in the same style (using an extension like Stylebot or so); then it would be neat if Gentoo could bring them down to the same format to me, instead of that I would need to do local conversion or use multiple viewers for what could be in one canonical place. How about doing it Out of band by a yet-to-exist gentoo tool that can create a format to the users liking on demand? I mean, whatever way you look at it, such a tool *MUST* exist to simply format the markdown to X-Format anyway. So why do this during ebuild phases? Why not have a tool that handles this? This greatly simplifies the problem that will transpire if we want to support more than one markdown standard, namely, an increased bulk of dependencies. As to identifying what standard to use for a given markdown document, I feel trying to do that automatically will result in sorrow, as will trying to develop one tool that handles all formats in the same document. I think maybe we could support a metafile of some description in the doc/$pn-$pv/ directory that describes a list of documents and the relevant format decoder to use for that document. This approach means we can do this for more than just markdown documents, and we can have support of extension-free files that happen to be in RST format instead, or ascii-doc, or whatever, ie: in /doc/$P/formats.meta README.md : markdown/gfm and then any of our tools can translate on demand to the format needed: less $PATH/README.md ^ could even be hooked to discover formats.meta and run the content through a ANSI formatter to translate bold indications into escape codes. And the same tool could be used as a backend for whatever web-browser centric documentation viewer we provide to render the files as html, or even do things like gentoo-fm $PATH/README.md --formatter pdf /tmp/doc.pdf okular /tmp/doc.pdf In the event somebody wants to read a simple markdown document as PDF. ( This also has the benefits of not necessarily adding a large amount of cruft to doc/ for people who don't need the documentation, and means they wont have to rebuild the package *JUST* to get documentation in a different format ) TL;DR - We can provide a tool, it doesn't have to be locked in to the ebuild phase to be useful, and could be more useful to be seperate of ebuild systems, with ebuild systems only providing minimal amounts of context to help a tool know how to process the document. -- Kent
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Tue, Sep 24, 2013 at 6:13 PM, Tom Wijsman tom...@gentoo.org wrote: So, something along the lines of: Linux systems with /usr on a separate file system that do not use an initramfs will become unsupported, starting on 01-Nov-2013. ++ Then go on like: This decision has been taken because of [problem]; you can read more about that in [article/mail references]. -- I wouldn't go too much into the why. I'd focus on the what and in particular on what users need to do about it. Rich
Re: [gentoo-dev] markdown docs like README.md
On Wed, 25 Sep 2013 11:27:50 +1200 Kent Fredric kentfred...@gmail.com wrote: On 25 September 2013 10:30, Tom Wijsman tom...@gentoo.org wrote: If I want to browse all documentation with a browser, just going to something like file:///usr/share/doc and read them all in the same style (using an extension like Stylebot or so); then it would be neat if Gentoo could bring them down to the same format to me, instead of that I would need to do local conversion or use multiple viewers for what could be in one canonical place. How about doing it Out of band by a yet-to-exist gentoo tool that can create a format to the users liking on demand? I mean, whatever way you look at it, such a tool *MUST* exist to simply format the markdown to X-Format anyway. That sounds like a converter. So why do this during ebuild phases? Why not have a tool that handles this? Because we are discussing conversion in an ebuild context. This greatly simplifies the problem that will transpire if we want to support more than one markdown standard, namely, an increased bulk of dependencies. The existence of a tool does not exclude that an ebuild cannot use it; so, I agree with your paragraph but that doesn't necessarily mean we can apply this in an ebuild context. As to identifying what standard to use for a given markdown document, I feel trying to do that automatically will result in sorrow, as will trying to develop one tool that handles all formats in the same document. Yes, automatic detection and applying a whole conversion based on that detection would be bad; writing something that only deals with the common elements, would be more neat. The question being whether we want to focus on the original Markdown or the GitHub Flavored Markdown to base ourselves on. I think maybe we could support a metafile of some description in the doc/$pn-$pv/ directory that describes a list of documents and the relevant format decoder to use for that document. Why does documentation generation and/or conversion so suddenly be done by the user? it needlessly complicates things, especially since the user now has to store those generated or converted in a separate location; this is not the way it has been done and I don't understand why we need any change in that. The maintainer could specify the format in the ebuild; for bugs where it has found to be of a different format, this is an easy fix. This approach means we can do this for more than just markdown documents, and we can have support of extension-free files that happen to be in RST format instead, or ascii-doc, or whatever, ie: This is no longer a discussion with regard to Markdown; but a whole topic on its own, at least if you want to be pursue consistency it might be worth bringing this up its own thread (or at least change the subject to denote it is no longer about Markdown in specific). and then any of our tools can translate on demand to the format needed: ^ could even be hooked to discover formats.meta and run the content through a ANSI formatter to translate bold indications into escape codes. My browser can't; so, I'll need conversion. And the same tool could be used as a backend for whatever web-browser centric documentation viewer we provide to render the files as html, or even do things like What kind of backend would this be? A web server daemon? gentoo-fm $PATH/README.md --formatter pdf /tmp/doc.pdf okular /tmp/doc.pdf In the event somebody wants to read a simple markdown document as PDF. But why should we go through hard hoops to read something simple? Why not just have it installed and opened in the format the user wants? ( This also has the benefits of not necessarily adding a large amount of cruft to doc/ for people who don't need the documentation, and means they wont have to rebuild the package *JUST* to get documentation in a different format ) That doesn't happen as these are controlled with USE flags; eg, USE=pdf. If we plan on introducing more documentation formats, we might want to introduce an USE expand to make it easier for the user to configure; instead of the local USE flags we are using now. TL;DR - We can provide a tool, it doesn't have to be locked in to the ebuild phase to be useful, Tools used by ebuilds and eclasses can usually be used outside that context as well; it isn't really locked, and its usefulness doesn't change depending on where it is used. It's rather what the addition of the context you place it in that matters here. and could be more useful to be seperate of ebuild systems, Perhaps it could be, but I don't see why; it feels less handy to do. with ebuild systems only providing minimal amounts of context to help a tool know how to process the document. If you put the tool in the context of the user, maintainers will not really be aware of or contributing to the context; eg. formats.meta. This would put the format responsibility in the hands of the
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Tue, 24 Sep 2013 19:57:22 -0400 Rich Freeman ri...@gentoo.org wrote: Then go on like: This decision has been taken because of [problem]; you can read more about that in [article/mail references]. -- I wouldn't go too much into the why. I'd focus on the what and in particular on what users need to do about it. ++ True, users can always get more information through support channels. Makes me wonder if the Why? question should be left unanswered; I'm also not quite sure if we can produce a short answer, can the actual problem be summarized in one short clear sentence at all? (This does not mean that I want to see a long answer) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
On 25 September 2013 12:33, Tom Wijsman tom...@gentoo.org wrote: The existence of a tool does not exclude that an ebuild cannot use it; so, I agree with your paragraph but that doesn't necessarily mean we can apply this in an ebuild context. I guess I can agree I would be amenable to a scenario where you could do either. Gentoo is about choices, and if its viable that we provide the choice to generate the alternative formats during build so that a user doesn't have to invoke a command to generate the alternative format later, then why not? Recipients who don't want the overhead of disk cruft can just omit the relevant useflags and get only documentation in its source form ( with maybe a hints file generated by the domd commands instead of performing the full translation ) Just I should make a strong suggestion that such alternative formats should be generated during src_build , *NOT* src_install, mostly due to the differences in privilege separation under userpriv, a problem that has caused at least one bug in the past ( https://bugs.gentoo.org/show_bug.cgi?id=454058 ) -- Kent
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Wed, Sep 25, 2013 at 02:55:49AM +0200, Tom Wijsman wrote: Makes me wonder if the Why? question should be left unanswered; I'm also not quite sure if we can produce a short answer, can the actual problem be summarized in one short clear sentence at all? I will try, but not in this thread. I want this thread to stay focused on the news item. Here is the updated newsitem based on feedback I have received so far. William Title: Separate /usr on Linux requires initramfs Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2013-09-27 Revision: 1 News-Item-Format: 1.0 Linux systems which have / and /usr on separate file systems but do not use an initramfs will not be supported starting on 01-Nov-2013. If you have / and /usr on separate file systems and you are not currently using an initramfs, you must set one up before this date. Otherwise, at some point on or after this date, upgrading packages will make your system unbootable. For more information on setting up an initramfs, see this URL: https://wiki.gentoo.org/wiki/Initramfs/HOWTO signature.asc Description: Digital signature
