Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org
"Paweł Hajdan, Jr." writes: > Awesome work! > > I was always proud about Gentoo's mailing list archives - no spam, > simple UI. > > Just wanted to say thanks to a3li, and entire Infra team. Oh, and the > new design looks great. Second that. Thanks a3li and infra. Good job. BTW, I love the links of "Find on GMANE/MARC". Benda pgpHFKEHH3Fc6.pgp Description: PGP signature
Re: [gentoo-dev] The bindist USE flag and RESTRICT=bindist
On Tue, Mar 3, 2015 at 4:12 PM, Ulrich Mueller wrote: > While discussing the issue in #-releng, it was also suggested that a > news item should be prepared, to inform users that they cannot rely on > USE=bindist. (They cannot rely on it already now, though.) Does it > make sense to have a news item for this? It's good that this was discussed with releng. Do they have a plan for how they will implement this in stage building? I assume they will want to set ACCEPT_RESTRICT="-bindist". However, if we start adding restrictions like RESTRICT="ecdsa? ( bindist )", to base system packages (like openssl and openssh), that 'ecdsa' use flag will need to get turned off for stage building to work.
Re: [gentoo-dev] Re: Fonts project meeting and elections
On Wed, 4 Mar 2015 20:51:44 +0800 Ben de Groot wrote: > Alexis, can you shed some light on this from the TeX side? What font > formats can be used by various TeX packages? Ahah :) Short answer: All. More or less properly depending on the font and its format. More detailed answer: http://en.wikibooks.org/wiki/LaTeX/Fonts xetex & luatex can use freetype/fontconfig; others usually rely on conversion to tex native format (pk+tfm), automatically I am not sure if the font doesnt come from the texmf tree Alexis.
Re: [gentoo-dev] Re: Fonts project meeting and elections
On 1 March 2015 at 23:36, Guilherme Amadio wrote: > On Sun, Mar 01, 2015 at 08:59:38PM +0800, Ben de Groot wrote: >> On 28 February 2015 at 19:52, Michael Orlitzky wrote: >> > On 02/28/2015 01:47 AM, Ben de Groot wrote: >> >> >> >> If we do the use expand, we should leave it up for users to set. I >> >> suggest we default to only otf, if there is a choice. Other formats >> >> should not be installed by default, unless it's the only option for >> >> that package. >> >> >> > >> > This is going to get confusing fast -- please consider just installing >> > everything by default. If you default to "only OTF," what happens when >> > you install a foo-ttf package? Is it a no-op? What if there's a package >> > that only ships WOFF files? A combination of TTF and WOFF? >> > >> > Most of the fonts are tiny and it's not worth the hassle to avoid a few >> > kilobytes. It will also keep the eclass nice and clean. If you default >> > to installing everything, then when a user goes out of his way to remove >> > (say) WOFF, you can go ahead and just ignore WOFF files even if the >> > result is something stupid like an empty package. >> > >> > (The webfonts might be useful for clients, by the way. If they're not >> > installed locally, your browser downloads them on-demand and caches them >> > for later use.) >> > >> > >> >> Actually, after thinking about it some more, and doing some more >> research, I think this approach is unnecessary. Unless someone can >> tell me otherwise, I don't think we have any software that can handle >> truetype fonts but not opentype fonts. Most if not all of these >> packages use media-libs/freetype, which displays both formats just >> fine. So when we have font packages that offer both ttf and otf, then >> we should just install the superior format, which is OpenType. >> >> For packages that only offer one format, we install that format. >> >> Webfonts are also not an issue, as they are simply repackaged OpenType >> fonts aimed at web delivery. But most web developers use third party >> CDNs for that, such as Google Fonts. For the very few people who want >> to serve WOFF fonts from their own websites, I'm sure they can locate >> them as necessary. >> >> And webfonts are not useful for clients. Users should simply install >> the otf (or ttf) format of those fonts locally, and they will be >> picked up instead of the webfonts. >> >> Summarized, I propose the following policy: >> >> 1. If there is a choice of formats between otf and ttf, install only otf. >> 2. Do not install webfonts. > > I agree with your policy, but I think it's still a good idea to offer a > mechanism to install the other formats for those who need it, maybe via > truetype and woff or webfont USE flags. LaTeX, for example, may not be > able to use OpenType fonts, unless you use XeTeX, or other newer > variant, and sometimes a package you may want to use is only available > for plain LaTeX or PDFTeX (pst-solides3d and pstricks come to mind). > > We could have global USE flags for each popular font format, turn on the > flag for OpenType by default, and let users choose extra formats they > want. Another thing we might want to work on is on a way to convert > fonts for use with legacy LaTeX software that can't use OpenType files. Alexis, can you shed some light on this from the TeX side? What font formats can be used by various TeX packages? -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] The bindist USE flag and RESTRICT=bindist
> On Wed, 4 Mar 2015, Alexis Ballier wrote: > from the rest of your email, I understand that RESTRICT=bindist is > eapi0 (or even not covered by eapi?), right? > is there any information on RESTRICT=bindist ? with these 150 > packages using it, this sounds like something well known that I had > never heard of :/ It is not in PMS/EAPI, presumably because binpkgs are a Portage-only feature. (Things like profiles/license_groups aren't in PMS either...) The feature is documented in emerge(1) and ebuild(5) or https://devmanual.gentoo.org/eclass-reference/ebuild/ though, and it exists since 2007: http://archives.gentoo.org/gentoo-dev/message/a19efeb2d64e2442975d5d9f6175eaf4 But yes, I would be in favour of documenting RESTRICT=bindist and ACCEPT_RESTRICT in the devmanual and in the handbook. Maybe here would be a good place: https://wiki.gentoo.org/wiki/Handbook:Parts/Working/Features#Binary_package_support Ulrich pgpKldWMC9yL6.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: gitweb.gentoo.org; anon git:// moving soon
On 03/04/2015 02:56 AM, Robin H. Johnson wrote: > On Tue, Mar 03, 2015 at 11:57:40PM +0200, Markos Chandras wrote: >> One that that I miss though is the git (+ssh) links for rw access >> to the repositories. It's not obvious what url to use to clone a >> repository for rw access. Is there a way to generate such urls on >> the web interface? > It does clearly say them, in the bottom area of each repo: > > http://gitweb.gentoo.org/proj/elections.git/ Clone > git://anongit.gentoo.org/proj/elections.git > http://anongit.gentoo.org/git/proj/elections.git > git+ssh://g...@git.gentoo.org/proj/elections.git > Hmm true.. I am pretty sure this was not there when I posted this message but I could be wrong :) I was also looking at the http://gitweb.gentoo.org/proj/gmn.git/ (which is empty as it should be) which still doesn't list any links to clone the repo. I realize it's empty but you still need some urls to push data to it so it can stop being empty :) Anyway it's easy to figure the correct url to use. -- Regards, Markos Chandras
Re: [gentoo-dev] The bindist USE flag and RESTRICT=bindist
On Tue, 3 Mar 2015 22:12:07 +0100 Ulrich Mueller wrote: > Hi, > We currently have two mechanisms to influence building of packages > that cannot be binary redistributed. Some 150 packages have > RESTRICT=bindist (unconditional, or USE conditional), whereas > 27 packages have the bindist flag in their IUSE. Until very recently, > the two sets were practically disjoint, with only one single package > (www-client/chromium) in both sets. > > As a consequence, neither building with the well-known USE=bindist nor > with ACCEPT_RESTRICT="* -bindist" (presumably less known and Portage > only?) will guarantee that only redistributable binaries will be > built [1]. > > So a few days ago I filed bug 541408 and dependent bugs, with the goal > that ebuilds with the bindist flag in their IUSE should also add > RESTRICT="!bindist? ( bindist )". However, it turned out that some 10 > packages are using the bindist flag only in REQUIRED_USE but nowhere > else [2] (with foo being some feature flag): > >IUSE="bindist foo" >REQUIRED_USE="bindist? ( !foo )" > > IMHO, the bindist USE flag is redundant in these cases. So we should > get rid of the REQUIRED_USE and add a restriction instead: > >IUSE="foo" >RESTRICT="foo? ( bindist )" > > What do you think? Should we proceed in this direction? > obviously, +1 for this from the rest of your email, I understand that RESTRICT=bindist is eapi0 (or even not covered by eapi?), right? is there any information on RESTRICT=bindist ? with these 150 packages using it, this sounds like something well known that I had never heard of :/ Alexis.
Re: [gentoo-dev] do we need special elog messages for bindist?
On 2/25/15 8:38 PM, Mike Gilbert wrote: > I would like to remove the elog for a couple of reasons: > > 1. The use flag description is there for whoever cares to read it. > There is no need to alert the user every time. > 2. We are not lawyers, and I have no business giving legal advice > about patent law which varies from country to country. > > To take it one step further: I think it would make more sense to call > the flag "h264" or something similar. We could then set > RESTRICT="h264? ( bindist )" if we want to give some indication that > it is not appropriate for binary redistribution. Makes sense. My suggestion for the flag name would actually be proprietary-codecs. This matches config option name in Chromium sources, and it's not just h264 but also e.g. MPEG-4 and MP3. The flag would be disabled by default. I'd then add RESTRICT="proprietary-codecs? ( bindist )" to the ebuild and remove both elog messages. Paweł signature.asc Description: OpenPGP digital signature
