Re: [gentoo-dev] markdown docs like README.md
Am 24.09.2013 19:49, schrieb hasufell: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. following that logic we should also consider converting all man and info pages to html... it doesn't make any sense... simply provide or suggest a markdown capable viewer to the user /martin
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
24.09.2013 23:07, 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. I think optimal solution here is to СС unstable arches on stable requests for new versions of packages to let them drop stable keywords. And if they are silent - dropping keywords with all revdeps by maintainer itself when other arches are done with stabilization. -- 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] markdown docs like README.md
Dnia 2013-09-25, o godz. 00:30:27 Tom Wijsman tom...@gentoo.org napisał(a): On Wed, 25 Sep 2013 00:07:15 +0200 Michał Górny mgo...@gentoo.org wrote: 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? And why do I need a special HTML-formatting tool (which is much more expensive) to read documentation in any way? Or rather, to drop all the useless formatting. 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. And how does that help with 'cat' output? Or vim? Or many other standard *console* tools Gentoo users use. 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. And how does this distinguish between HTML cruft converted from Markdown and HTML-only docs? 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. Which is not reason to make it even worse. 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. It's called 'less'. Open a bug against it, ask our devs to include a formatter in 'lesspipe'. Tadaam! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
William Hubbs schrieb: 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 What about busybox[sep-usr]? Is that still supported or is everyone with separate /usr forced to use an initramfs? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
В Вт, 24/09/2013 в 11:46 -0700, Paweł Hajdan, Jr. пишет: 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. But could you comment on how hard it'll be to slot v8 shared library? Keeping libraries bundled is a security nightmare. -- Peter.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On 25/09/13 11:06, Thomas Sachau wrote: William Hubbs schrieb: 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 What about busybox[sep-usr]? Is that still supported or is everyone with separate /usr forced to use an initramfs? I don't see how busybox[sep-usr] would fix the problem of net-wireless/bluez installing to /usr and bluetooth keyboards, or sys-apps/kbd installing keymaps to /usr, and so forth Should just declare it unsupported -- that's doesn't stop people from still using separate /usr. I think the point with declaring it unsupported is to let people know there will be issues, and they have to deal with them.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
Dnia 2013-09-25, o godz. 10:06:43 Thomas Sachau to...@gentoo.org napisał(a): William Hubbs schrieb: 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 What about busybox[sep-usr]? Is that still supported or is everyone with separate /usr forced to use an initramfs? I'd say it's supported as long as it gives a compatible end result. I suspect that the number of cases supported by that is less than those supported by a complete initramfs. However, I'd say the support is mostly the maintainer's discretion. As long as busybox maintainers want to support that, it should work. But don't expect Gentoo developers to check whether that work or encourage users to use that. I think we used to call that 'early boot mechanism' in the past, but I guess just 'initramfs' is easier for users. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Perfect. Seriously? Perfect because one person agrees with you? Sigh. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Wed, Sep 25, 2013 at 4:35 AM, Michał Górny mgo...@gentoo.org wrote: What about busybox[sep-usr]? Is that still supported or is everyone with separate /usr forced to use an initramfs? I'd say it's supported as long as it gives a compatible end result. I suspect that the number of cases supported by that is less than those supported by a complete initramfs. However, I'd say the support is mostly the maintainer's discretion. As long as busybox maintainers want to support that, it should work. But don't expect Gentoo developers to check whether that work or encourage users to use that. I think we used to call that 'early boot mechanism' in the past, but I guess just 'initramfs' is easier for users. If Gentoo actually offered some kind of formal support I'd be more concerned about exactly what is and isn't supported, but for the most part what is and isn't supported is a gray area that varies by developer, with perhaps some hard boundaries at the extremes. We had the conversation of whether mixing keywords was supported and ended up basically where we seem to be with early boot mechanisms. If somebody wanted to run with a separate /usr I would recommend they use an initramfs. That doesn't mean that there aren't other ways of solving the problem. However, an initramfs is what would end up in the handbook/etc as it is probably the most straightforward solution. I guess the questions is whether we really need to advertise the alternatives. 95% of users are probably going to use an initramfs anyway. If some prefer an alternative solution they're likely to already be reading -dev and so on and probably are already using busybox. If the maintainers of the busybox-based solution want to plug their option (and deal with the questions/issues when they arise) I have no objection as long as it doesn't add much to the news item. Rich
Re: [gentoo-dev] markdown docs like README.md
On Wed, 25 Sep 2013 09:57:26 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-25, o godz. 00:30:27 Tom Wijsman tom...@gentoo.org napisał(a): On Wed, 25 Sep 2013 00:07:15 +0200 Michał Górny mgo...@gentoo.org wrote: 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? And why do I need a special HTML-formatting tool (which is much more expensive) to read documentation in any way? Or rather, to drop all the useless formatting. Who says you need to? We're not suggesting completely replacing what we currently have as far as I am aware of; so, if you don't want to see a change in what is installed for you, you'll be able to keep it that way under what is being suggested in this thread. Choice implies that you can keep things the way they have been. 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. And how does that help with 'cat' output? Or vim? Or many other standard *console* tools Gentoo users use. 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. And how does this distinguish between HTML cruft converted from Markdown and HTML-only docs? You just choose to not use a converter. No problem here. 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. Which is not reason to make it even worse. Neither is it a reason to stop progress. Looking at the mailing list history, I could use this binary package argument on many threads. People that want binary packages should live with a default under the current implementation; as for a possible future implementation, that could possibly have split up tarballs so we can selectively install parts of the binary package such that this would not be a problem at all. Discussing binary packages here is off-topic. 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. It's called 'less'. Open a bug against it, ask our devs to include a formatter in 'lesspipe'. Tadaam! Exactly, now this thread wants to make alternatives to that possible; just because one tool exists doesn't mean everyone wants to use it, there is no one size fits all solution. That's where choice comes from. -- 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 08:36:56 +0200 Martin Gysel m.gy...@gmail.com wrote: Am 24.09.2013 19:49, schrieb hasufell: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. following that logic we should also consider converting all man and info pages to html... it doesn't make any sense... Yet there are many websites that show these converted man pages, as well as users looking them up there; that it doesn't make sense for you doesn't necessarily mean that nobody else is doing it. simply provide or suggest a markdown capable viewer to the user Yet another viewer I have to install; imagine that I had to do the same for video formats, then I'd have to install an AVI player, a MKV player, a MP4 player, a MOV player, an OGG player, a VOB player, ... No, I'd rather have a single converted format and/or a single player. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I lost interest. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSQttjAAoJEFpvPKfnPDWzRXYIAIQKnHSRoChJ/gHd56KxaaW+ KGYQG9xW/OAO68qiubRW/1YK6vMRfWk9k/6m/pwwIPmFfYBAucT6jwBkfnR/HgMD TB08WpbooFTYGqX378jB07do0SNoYiQCNOCFJ313K57yAU7fCc5+VdMTM8v9e/i5 M94snDehz7LCTjXT0Q+MH9InWaOT4aHXPKhr6SZZUsR+MjtKhWcL8JjeHZ78mLFt /Ph33fEur3HOAPDJ5s3u+AHeOfKVuBPmGSKI8GfY88XatcYqapaLYIZKfTxIp0Ip b0KKVxQ3vB2o9+MwCMfKmx+Cpyp3eklh/fOUusxQIqGcHccrRhtvK6r7gp8LFRc= =LnLn -END PGP SIGNATURE-
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 William Hubbs schrieb: 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. William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. On 25/09/13 04:06 AM, Thomas Sachau wrote: What about busybox[sep-usr]? Is that still supported or is everyone with separate /usr forced to use an initramfs? My interpretation of the various Council votes on the matter is that it's not officially supported, but the busybox'ers I expect will continue to provide this avenue. Even though the officialness of support is being dropped, this doesn't mean it won't work for various configurations; as far as I've been able to tell, this all just means gentoo dev's are now allowed to treat bugs related to failures from a /usr not being mounted at bootup as RESO/INVALID. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJC7pwACgkQ2ugaI38ACPC76AD9EHQXzywD4CPWOh9Pjv4nZQ6V LViekn/0Jv3LdD9RPzgA/0OF4oZtBwxvTPPTsjy65v140/TtVam7dKtlKHTZ285k =ZxJe -END PGP SIGNATURE-
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. Rich
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/13 10:51 AM, Rich Freeman wrote: On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. Rich How about changing [properly] supporting a separate /usr without an initramfs to supporting a system with /usr missing at boot time ? More generic, indicates the actual problem better. Otherwise sounds great to me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJC+7QACgkQ2ugaI38ACPAXxgEAhbkqYQjs5G1kdklcVSYVoCCd ZXYCAhBVryEqFycMPfABAMCKsbLx0uD0ZGxWbX/PXfpdVSogvd54fOemDWVV6leq =XOnB -END PGP SIGNATURE-
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On 25/09/2013 16:51, Rich Freeman wrote: On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. if you add For more info, see insert detailed wiki doc URL here after that paragraph, most users can have their questions answered in the simplest way possible. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
Am Mittwoch, 25. September 2013, 11:05:24 schrieb Ian Stakenvicius: On 25/09/13 10:51 AM, Rich Freeman wrote: On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. Rich How about changing [properly] supporting a separate /usr without an initramfs to supporting a system with /usr missing at boot time ? More generic, indicates the actual problem better. Otherwise sounds great to me. Maybe some links to articles that explain *why* the so called UsrMerge was needed/done would be a good idea. I have a feeling that many people (still) think a separate /usr partition would be something they needed badly, and that it is all Lennards fault (and his wrecked systemd project) that a separate /usr /suddenly/ needs an initrd. In fact, only really rare cornercases (*) actually *need* a separate /usr partition, and none can't live with an initrd. The most prominent sites would be, I believe, https://fedoraproject.org/wiki/Features/UsrMove/ and http://http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ with references to http://http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ ? Don't understand me wrong, please. I have always worked with a separate /usr partition, and was extremely pissed off when, all of a sudden, I was told that I'd need an initrd to support it further. My thoughts where a bit like: /But why? I need, that! It is highly useful, because because ... erm.. (no idea...) ... Because I've *always* used it that way!/ In the end I found absolutely no reason for _not_ merging /usr into / and did it. Result: No initrd and one partition less to take care of. I have never had any disadvantage by that merge over a year ago on all my machines. And then I took a closer look at all servers (debian, ranging from Sarge over Lenny to Squeeze) at my workplace, and none ever even had a separate /usr. Cheers Sven (*): Like /usr over NFS signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/13 11:27 AM, Sven Eden wrote: Am Mittwoch, 25. September 2013, 11:05:24 schrieb Ian Stakenvicius: On 25/09/13 10:51 AM, Rich Freeman wrote: On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. Rich How about changing [properly] supporting a separate /usr without an initramfs to supporting a system with /usr missing at boot time ? More generic, indicates the actual problem better. Otherwise sounds great to me. Maybe some links to articles that explain *why* the so called UsrMerge was needed/done would be a good idea. This isn't UsrMerge tho. I think bring that discussion into the news item would probably be going too far beyond its intended scope. [ Snip the rest ] Documentation suggesting a separate /usr isn't necessary (or rather, probably, is only necessary for certain things, like /usr-on-NFS or LVM-without-ROOT or crypto-/usr ) does make sense in general but probably that discussion would be better done in the Handbook (or linked to by the Handbook) rather than in the news item. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJDA6gACgkQ2ugaI38ACPA1gwD/bkBLl+XI0xB82C+ZR2e/YvcQ L2JG9Jz1maj55IHTXNMBAJqAPjZs6FZjivVgyG/14TdxfKlpkAqAaBu8c1qUN097 =hQ0d -END PGP SIGNATURE-
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 2:44 AM, Diego Elio Pettenò wrote: On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Perfect. Seriously? Perfect because one person agrees with you? Sigh. Look at the API breaks and talk to v8 upstream - if you have a better solution to actual bugs that people report against Gentoo, I'm all for it. Note that I've spent and keep spending time on unbundling what's possible from chromium. I'm not saying bundled is good or fine, but in the current situation of v8 I honestly think trying to ship a shared library offers us *no* advantages and actually creates problems, mainly because v8 was not designed to be used as a shared library and breaks API/ABI even before patch version bumps like a.b.c.x - a.b.c.y. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 1:16 AM, Peter Volkov wrote: But could you comment on how hard it'll be to slot v8 shared library? Keeping libraries bundled is a security nightmare. Slotting v8 would be hugely impractical and rather a misuse of SLOTs. Slotting makes sense when there are at most 2-3 major versions, each with its own release series, that are incompatible, but packages can depend on one or another series. Thing gtk2 vs. gtk3 for example, or maybe some Java libraries. With v8 API and ABI breaks can (and we've seen that) be introduced even between patch version increments like a.b.c.x vs. a.b.c.y. Trying to slot that would be totally equivalent to bundling at the cost of increased complexity (more custom changes compared to upstream - also headers would need to be handled somehow, currently we don't have a good way for that, especially one that would be consistent across distros). Finally, note that v8 upstream only supports the latest stable v8. Slotting would require us to keep old, _known_ to be vulnerable versions of v8 in the tree. Backporting of patches isn't always possible/feasible, and even then for complex and fast moving software it's not guaranteed to fix all the issues (some security bugs might have been fixed in more recent versions without realizing security implications). At least with bundling upstream _may_ track v8 security vulnerabilities and do something with their copy. With slotting we'd have _known_ vulnerable v8 versions right there in the tree. That'd be a security nightmare. Please let me know if you have more questions. At this moment I'm confident slotting does not address the problem. More deeper, upstream changes should be made, and I'll be working on that but it's going to take time. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/13 11:52 AM, Paweł Hajdan, Jr. wrote: On 9/25/13 2:44 AM, Diego Elio Pettenò wrote: On Tue, Sep 24, 2013 at 7:46 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Perfect. Seriously? Perfect because one person agrees with you? Sigh. Look at the API breaks and talk to v8 upstream - if you have a better solution to actual bugs that people report against Gentoo, I'm all for it. Note that I've spent and keep spending time on unbundling what's possible from chromium. I'm not saying bundled is good or fine, but in the current situation of v8 I honestly think trying to ship a shared library offers us *no* advantages and actually creates problems, mainly because v8 was not designed to be used as a shared library and breaks API/ABI even before patch version bumps like a.b.c.x - a.b.c.y. It would at minimum make sense to have a chromium-bundled v8 and a system v8, if you're not doing that already. Mozilla's do that now; they won't work with a shared libmozjs (indeed, they embed it statically into libXul, which is also internal and package-specific). However, if it's possible to keep the rest of the tree using one system package of v8 (or very small subset), and just maintain that(those) via security backports, would that be viable? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJDCPYACgkQ2ugaI38ACPCbEgD/ZLCT9XFwk2Ara+G0gRQTas7P Wp78He716eSWD9nuaA8BAJlvk7SgBgCpYMORMYhsC1UlhWRLUNYDBf6NlUPDw/3x =hKKg -END PGP SIGNATURE-
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On 9/25/13 9:01 AM, Ian Stakenvicius wrote: However, if it's possible to keep the rest of the tree using one system package of v8 (or very small subset), and just maintain that(those) via security backports, would that be viable? In the current state of v8, no. Latest security-supported v8 is defined as one used by stable chromium. Security backports are not supported by upstream, and are not always even possible with a fast-changing codebase. A good test for this type of questions is look at some of the bugs below: https://bugs.gentoo.org/show_bug.cgi?id=417879 https://bugs.gentoo.org/show_bug.cgi?id=420995 https://bugs.gentoo.org/show_bug.cgi?id=471582 https://bugs.gentoo.org/show_bug.cgi?id=477300 https://bugs.gentoo.org/show_bug.cgi?id=484786 and try to post fixes for them. If you or anyone else can do that, I'm happy to take them and change my opinion (note that I'd apply some quality standards to the patches, not just look whether they happen to work for now). I actually really hope to improve this in the long term (as said before), and we can definitely revisit this in the future. For now I'd like to address real problems that affect users. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
Am Mittwoch, 25. September 2013, 11:39:20 schrieb Ian Stakenvicius: On 25/09/13 11:27 AM, Sven Eden wrote: Am Mittwoch, 25. September 2013, 11:05:24 schrieb Ian Stakenvicius: On 25/09/13 10:51 AM, Rich Freeman wrote: On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius a...@gentoo.org wrote: William, I think what Tom was mentioning here is that he thinks a one-sentence answering the Why would be a good idea to have in the news item, so users that don't have a clue on all of these sep-/usr issues will get an idea of why the change is being made. How about something like: Due to many upstream changes properly supporting a separate /usr without an initramfs has become increasingly difficult - despite all our efforts it already breaks in some exotic configurations, and this is a trend likely to grow worse. Rich How about changing [properly] supporting a separate /usr without an initramfs to supporting a system with /usr missing at boot time ? More generic, indicates the actual problem better. Otherwise sounds great to me. Maybe some links to articles that explain *why* the so called UsrMerge was needed/done would be a good idea. This isn't UsrMerge tho. I think bring that discussion into the news item would probably be going too far beyond its intended scope. Yes, of course. It is just that the mentioned upstream changes are because of the merge, meaning boot relevant stuff is installed in /usr instead of /. [ Snip the rest ] Documentation suggesting a separate /usr isn't necessary (or rather, probably, is only necessary for certain things, like /usr-on-NFS or LVM-without-ROOT or crypto-/usr ) does make sense in general but probably that discussion would be better done in the Handbook (or linked to by the Handbook) rather than in the news item. Yes, maybe the references about why upstream did/does change belongs on a wiki page or something like that. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] markdown docs like README.md
Dnia 2013-09-25, o godz. 14:29:52 Tom Wijsman tom...@gentoo.org napisał(a): 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. Which is not reason to make it even worse. Neither is it a reason to stop progress. Excuse me but *how* is this related to progress at all? You're talking about converting *newer* format files to *older* format that will require special processing for display anyway. Worse than that, you are actually talking about doing the conversion *on files*, that is storing duplicate data. I'd expect progress to go *forward*. Introducing compatibility files for reading non-mandatory files using a web browser doesn't sound anywhere near progress. 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. It's called 'less'. Open a bug against it, ask our devs to include a formatter in 'lesspipe'. Tadaam! Exactly, now this thread wants to make alternatives to that possible; just because one tool exists doesn't mean everyone wants to use it, there is no one size fits all solution. That's where choice comes from. And what benefits do those 'alternatives' give us? Featurism, that's all. Implementing new features for the sake of doing something. Someone throws a random idea, let's implement it for the sake of choice. Seriously, how many people actually *care* about reading /usr/share/doc with a HTML browser? How many people actually need it? That is, how many people get real benefit rather than shiny formatting in their favorite tool. Gentoo is not about bending everything upstream provides to match every tool a particular user likes. Improving the tools give more benefit than pushing compatibility cruft. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] markdown docs like README.md
Dnia 2013-09-25, o godz. 14:38:14 Tom Wijsman tom...@gentoo.org napisał(a): On Wed, 25 Sep 2013 08:36:56 +0200 Martin Gysel m.gy...@gmail.com wrote: Am 24.09.2013 19:49, schrieb hasufell: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. following that logic we should also consider converting all man and info pages to html... it doesn't make any sense... Yet there are many websites that show these converted man pages, as well as users looking them up there; that it doesn't make sense for you doesn't necessarily mean that nobody else is doing it. *Websites* is the keyword here. simply provide or suggest a markdown capable viewer to the user Yet another viewer I have to install; imagine that I had to do the same for video formats, then I'd have to install an AVI player, a MKV player, a MP4 player, a MOV player, an OGG player, a VOB player, ... No, I'd rather have a single converted format and/or a single player. Yet you don't mind most of our users installing a Markdown converter (and possibly even more converters) in the sake of converting docs to the format you like... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Moving project pages to wiki.gentoo.org
On 09/19/2013 01:10 PM, Alex Legler wrote: As discussed [1] on -dev a while ago, project pages will now be moving to wiki.gentoo.org. From now on, you must not create new documents or projects in CVS/on www.gentoo.org. Existing projects are asked to move the contents of their project pages to the Wiki, or to remove outdated contents from CVS. To help this process, we provide an automatically wikified version of the GuideXML documents in /proj/. Please consult the documentation on how to proceed: http://wiki.gentoo.org/wiki/Gentoo_Wiki:Developer_Central/Project_pages Project pages on www.gentoo.org will be removed after the migration. Maintenance for this legacy service as of now is 'best-effort', no new features will be added. Apologies if this has been covered elsewhere, but how are we dealing with herds.xml? Many herds are compiled from the project pages using maintainingproject element. How does that work if the project pages are going away? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
All, here is my latest update, again based on feedback from the list. It seems a bit long to me, but I'm not sure how to make it any shorter if we include the information about why this is happening. Thoughts? 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 Due to many upstream changes, properly supporting Linux systems that have /usr missing at boot time has become increasingly difficult. Despite all our efforts, it already breaks in some exotic configurations, and this is atrend likely to grow worse. 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 the upstream changes and why using an initramfs is the cleanest route forward, see the following URLs: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken https://blog.flameeyes.eu/2013/01/the-boot-process For more information on setting up an initramfs, see this URL: https://wiki.gentoo.org/wiki/Initramfs/HOWTO signature.asc Description: Digital signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/13 03:16 PM, William Hubbs wrote: Due to many upstream changes, properly supporting Linux systems that have /usr missing at boot time has become increasingly difficult. Despite all our efforts, it already breaks in some exotic configurations, and this is atrend likely to grow worse. s/atrend/trend/ Otherwise, looks great to me. Also I don't think it's too long. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlJDNyQACgkQ2ugaI38ACPBmZgEAtFU088Cai2YHAJWa+uA3DUrR z7lihZbqLE5OEzthvqMBAITkIdEkybod01p1oZFOv8+/ho25c1baQpbhbubUCian =KwtT -END PGP SIGNATURE-
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Wed, Sep 25, 2013 at 03:19:00PM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/09/13 03:16 PM, William Hubbs wrote: Due to many upstream changes, properly supporting Linux systems that have /usr missing at boot time has become increasingly difficult. Despite all our efforts, it already breaks in some exotic configurations, and this is atrend likely to grow worse. s/atrend/trend/ How about s/is atrend/trend is/ William signature.asc Description: Digital signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On Wed, Sep 25, 2013 at 3:16 PM, William Hubbs willi...@gentoo.org wrote: It seems a bit long to me, but I'm not sure how to make it any shorter if we include the information about why this is happening. I would use the newspaper article approach - put the most important and actionable material at the top, and supplemental material towards the bottom. Here is a suggested way to accomplish this (attaching both a patch and the new item in its entirety since patches aren't great for re-ordering). Rich new Description: Binary data patch Description: Binary data
Re: [gentoo-dev] markdown docs like README.md
On Wed, 25 Sep 2013 20:07:42 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-25, o godz. 14:29:52 Tom Wijsman tom...@gentoo.org napisał(a): 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. Which is not reason to make it even worse. Neither is it a reason to stop progress. Excuse me but *how* is this related to progress at all? Progress in providing choice, helping to support a single viewer. You're talking about converting *newer* format files to *older* format that will require special processing for display anyway. The age or functionality of a format is not what we should discuss here as it does not matter when talking about this progress. Worse than that, you are actually talking about doing the conversion *on files*, that is storing duplicate data. Only if one chooses to do so, which hasn't even been decided yet. I'd expect progress to go *forward*. Introducing compatibility files for reading non-mandatory files using a web browser doesn't sound anywhere near progress. That depends on how you define what is being progressed in; also if you don't want to see compatibility, then yes, it is not progress for you. 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. It's called 'less'. Open a bug against it, ask our devs to include a formatter in 'lesspipe'. Tadaam! Exactly, now this thread wants to make alternatives to that possible; just because one tool exists doesn't mean everyone wants to use it, there is no one size fits all solution. That's where choice comes from. And what benefits do those 'alternatives' give us? Featurism, that's all. Implementing new features for the sake of doing something. Someone throws a random idea, let's implement it for the sake of choice. Exactly, because an user came up with this; we're not implementing it yet, we're still discussing it which doesn't mean that there is a team of people that back certain decisions or implementation choices yet. Seriously, how many people actually *care* about reading /usr/share/doc with a HTML browser? That's the question; we don't have statistics on this, maybe we could make this a question in a future poll. How many people actually need it? Those whom need it, it's not for us to judge what they should use. That is, how many people get real benefit rather than shiny formatting in their favorite tool. That's exactly one of the reasons people want to use alternatives. Gentoo is not about bending everything upstream provides to match every tool a particular user likes. Actually, it is; Because of its near-unlimited adaptability, we call Gentoo a meta-distribution. — http://www.gentoo.org/main/en/about.xml Improving the tools give more benefit than pushing compatibility cruft. So, instead of storing it in a format the user appreciates we instead patch it up in 20 browsers and make maintenance a lot harder? Or the other option is to implement some kind of conversion HTTP web server daemon from scratch; it's a lot more work to implement, but that's the only still reasonable tool I could come up with. And it doesn't necessarily have to do Markdown to HTML conversion alone; it could possible be used to yield PDFs on the fly, have an interface you can use to browse and search /usr/share/doc and so on... Implementing such daemon wouldn't follow the KISS principle anymore. -- 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 20:15:57 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-25, o godz. 14:38:14 Tom Wijsman tom...@gentoo.org napisał(a): On Wed, 25 Sep 2013 08:36:56 +0200 Martin Gysel m.gy...@gmail.com wrote: Am 24.09.2013 19:49, schrieb hasufell: I wonder if it would make any sense to take the effort to convert markdown docs to html format before installing them. following that logic we should also consider converting all man and info pages to html... it doesn't make any sense... Yet there are many websites that show these converted man pages, as well as users looking them up there; that it doesn't make sense for you doesn't necessarily mean that nobody else is doing it. *Websites* is the keyword here. Yes, it connects the dots between man pages and a browser. simply provide or suggest a markdown capable viewer to the user Yet another viewer I have to install; imagine that I had to do the same for video formats, then I'd have to install an AVI player, a MKV player, a MP4 player, a MOV player, an OGG player, a VOB player, ... No, I'd rather have a single converted format and/or a single player. Yet you don't mind most of our users installing a Markdown converter (and possibly even more converters) in the sake of converting docs to the format you like... Exactly, it is a single tool as opposed to multiple. -- 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] newsitem: initramfs required on Linux systems with separate /usr
On Wed, 25 Sep 2013 15:37:34 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, Sep 25, 2013 at 3:16 PM, William Hubbs willi...@gentoo.org wrote: It seems a bit long to me, but I'm not sure how to make it any shorter if we include the information about why this is happening. I would use the newspaper article approach - put the most important and actionable material at the top, and supplemental material towards the bottom. Here is a suggested way to accomplish this (...) ++ for this version. -- 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] Re: rfc: status of OpenRC's public API
On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote: -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? This library has been around for some time, and there are no known consumers. Since there are no known consumers, there is no need for us to have the overhead of linking a shared library for code that only OpenRC uses. I think the KISS principle [1] applies here very nicely. William [1] http://en.wikipedia.org/wiki/Kiss_principle signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs willi...@gentoo.org wrote: On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote: -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? This library has been around for some time, and there are no known consumers. Since there are no known consumers, there is no need for us to have the overhead of linking a shared library for code that only OpenRC uses. So is your plan to convert it to a static helper library, or to have the openrc binaries link in the necessary object files directly?
Re: [gentoo-dev] Re: [gentoo-dev-announce] Moving project pages to wiki.gentoo.org
On 25.09.2013 20:38, Mike Gilbert wrote: Apologies if this has been covered elsewhere, but how are we dealing with herds.xml? Many herds are compiled from the project pages using maintainingproject element. How does that work if the project pages are going away? The /proj/en/foo entries will be replaced by Project:Foo, or just Foo. Until now, the (raw) herds.xml served didn't expand maintainingproject, I'd like to change that as querying member information isn't as easy as getting /proj/en/foo?passthru=1 anymore. At any rate, I have noted this as a to-do item for when the migration nears completion. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
On Wed, Sep 25, 2013 at 04:27:42PM -0400, Mike Gilbert wrote: On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs willi...@gentoo.org wrote: On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote: -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? This library has been around for some time, and there are no known consumers. Since there are no known consumers, there is no need for us to have the overhead of linking a shared library for code that only OpenRC uses. So is your plan to convert it to a static helper library, or to have the openrc binaries link in the necessary object files directly? OpenRC is just one binary, rc. libeinfo is currently just one c source and one header file, so I'm thinking of just linking the object into the binary directly. What do you think? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: status of OpenRC's public API
On Wed, Sep 25, 2013 at 5:01 PM, William Hubbs willi...@gentoo.org wrote: On Wed, Sep 25, 2013 at 04:27:42PM -0400, Mike Gilbert wrote: On Wed, Sep 25, 2013 at 4:04 PM, William Hubbs willi...@gentoo.org wrote: On Tue, Sep 24, 2013 at 02:22:02PM -0400, Ian Stakenvicius wrote: -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? This library has been around for some time, and there are no known consumers. Since there are no known consumers, there is no need for us to have the overhead of linking a shared library for code that only OpenRC uses. So is your plan to convert it to a static helper library, or to have the openrc binaries link in the necessary object files directly? OpenRC is just one binary, rc. libeinfo is currently just one c source and one header file, so I'm thinking of just linking the object into the binary directly. What do you think? Makes sense.
Re: [gentoo-dev] rfc: status of OpenRC's public API
Dnia 2013-09-13, o godz. 19:16:06 William Hubbs willi...@gentoo.org napisał(a): OpenRC currently has a public api, consisting of librc and libeinfo (rc.h and einfo.h are the headers); however, I do not know of any released software that uses these, so, if there is nothing, I am considering making this code private to OpenRC and getting rid of the API. I won't oppose since I don't use OpenRC anymore and therefore my opinion doesn't really matter here. However, I can't help but notice a particular trend since Roy left the project. I see that OpenRC is slowly regressing towards baselayout-1. First the oldnet thingie being made the default back. While I can understand why people wanted it so badly, this doesn't make this less of a carousel for Gentoo users. I mean, changing defaults with every maintainer change. Then, functions.sh split. While itself good, I don't get what's the benefit of converting the bash script from baselayout-1 while a better one was provided with OpenRC. Now removing the public API because you don't care. While it may have been unused indeed, it's simply crippling the thing, not making it more useful. I'd like to see some kind of plan behind all this. Because as far as I can see, it's just new maintainers slowly dropping all the new features they don't care about without any specific vision. No offense intended. If OpenRC really wants to compete with systemd, it should at least have some design plan, and you really should start working on providing useful features rather than reverting, crippling and rewriting for the sake of changing things. Just some material to think about. -- Best regards, Michał Górny signature.asc Description: PGP signature
