Re: [gentoo-dev] New email list and alias for the musl project --- a note for bug wranglers
On 03/07/15 08:20 AM, Anthony G. Basile wrote: Hi everyone, This one is mostly for the bug wranglers. There is a new email list and alias for the musl (sub?)project [1]. List: gentoo-m...@lists.gentoo.org alias: m...@gentoo.org musl is a new C standard lib [2]. It adheres scrictly to POSIX, XOPEN, SUSv3 standards. As a result, a number of packages break with musl. Usually these are small bugs, like missing headers mandated by POSIX, but still even a small error breaks a package. I don't want to burdon the maintainers with these bugs, so I'd like to ask bug wranglers that if they see a bug due to musl, to please assign it to me and cc the maintainer. I'll fix the bugs on the musl overlay [3] and upstream the patches, while keeping the maintainers informed about what's going on. Don't worry, I won't touch any packages. Bug wrangling usually proceeds via the metadata.xml, but there really is no structure there for communicating the above situation. Refs. [1] https://wiki.gentoo.org/wiki/Project:Hardened_musl [2] http://www.musl-libc.org/ [3] https://gitweb.gentoo.org/proj/musl.git why not make a musl component in bugzilla? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] oops: portage-latest.tar.* are off-by-one.
On 04/06/15 11:46 AM, Vadim A. Misbakh-Soloviov wrote: В письме от Чт, 4 июня 2015 11:17:01 пользователь Mike Frysinger написал: if you have a bug to report, please use bugs.gentoo.org -mike I bet, bug will deprecate itself before even bug wranglers takes a look on it. excellent theory, let's see how well it holds up in practice. https://bugs.gentoo.org/buglist.cgi?cmdtype=doremnamedcmd=Bug Wranglersremaction=runsharer_id=46764 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib amd64 news item for review
On 15/03/15 10:11 AM, Michał Górny wrote: In case of issues, blockers especially, the users users are recommended looks OK otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new bitcoin eclass
On 05/02/15 07:11 PM, Anthony G. Basile wrote: Hi everyone, I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds make use of the same codebase, so its probably a good idea to migrate that code to an eclass. Can we have the following eclass reviewed before committing it to the tree: https://gitorious.org/bitcoin/gentoo/source/674d32a2d029aed3bc967a1949f75586828ebe14:eclass/bitcoincore.eclass Thanks. Why can't the ebuilds be merged into one with USE flags? They are even from the same repository. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 23/11/14 08:17 PM, hasufell wrote: packages up for grab: I didn't change metadata.xml, nor bug reports for any of those, because I was too lazy. If you grab one, please do so yourself. how will bug-wranglers know where to assign packages then? app-misc/trash-cli co-maintained by games ga...@gentoo.org games-misc/katawa-shoujo games-roguelike/FTL co-maintained with Lars Wendler polynomia...@gentoo.org media-sound/umurmur I can proxy these if the relevant people agree. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] =udev-217 or =eudev-2.1 upgrade news item
On 07/11/14 07:13 AM, Samuli Suominen wrote: On 29/10/14 13:42, Alex Xu wrote: On 29/10/14 07:28 AM, Samuli Suominen wrote: request for review before committing, suggestions welcome since it's rather short what i got to say thanks, Samuli typical news items are in the format packages no longer/now do thing. [thing is description of thing.] if you need thing, do steps. if you do not need thing, do steps. [blah blah metadata, I hereby assign all copyright for the following text to the Gentoo Foundation] sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace firmware loader. If you require firmware loading support, you must use kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is required if none of your kernel modules need firmware. See [1] for more information on the upgrade. [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217 The news item has been committed today. :-) Sorry for the delay. I'm running out of excuses with my health issues. :-( Thanks and sorry, Samuli oh, I just figured something. what about systemd? looks like IUSE=firmware-loader was removed in 217. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] typo in scrypt USE-Flag
On 02/11/14 11:41 AM, Marco Ziebell wrote: There's a typo in the scrypt USE-FLAG. A bug-report seemed to big for that. Correct would be scrypt: Use libscrypt for the scrypt algorithm so... instead of emailing 4 people (three bug-wranglers plus one maintainer), you email around 300 people (assuming that subscriber count is around the same as #gentoo-dev users, which is probably a severe underestimate). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] =udev-217 or =eudev-2.1 upgrade news item
On 29/10/14 07:28 AM, Samuli Suominen wrote: request for review before committing, suggestions welcome since it's rather short what i got to say thanks, Samuli typical news items are in the format packages no longer/now do thing. [thing is description of thing.] if you need thing, do steps. if you do not need thing, do steps. [blah blah metadata, I hereby assign all copyright for the following text to the Gentoo Foundation] sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace firmware loader. If you require firmware loading support, you must use kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is required if none of your kernel modules need firmware. See [1] for more information on the upgrade. [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11
On 24/10/14 10:31 AM, Anthony G. Basile wrote: HI everyone, I've update the c++ news item for your consideration. I incorporated suggestions, in particular a note about incompatibility between c++11 compiled with different version of gcc differing in minor number (eg 4.7 and 4.8). lgtm. also mime attachments are hard to comment on. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: News item regarding c++98 vs c++11
On 19/10/14 06:53 PM, Anthony G. Basile wrote: the default is still gnu++98 what does this mean, how does it differ from c++98? in the older ABI, can lead to a crippled system. what do you mean, will other packages break too? maybe may lead to non-functioning or possibly broken packages. adjust as necessary; I am not familiar with what may break if incompatible libraries are linked together. However, as c++11 gains in popularity and the number of packages using it increase, it is important that users understand these precautions. what precautions? what am I supposed to do? is there a option to warn me if I try to do something stupid? should I check some packages on my system? remember that gcc-4.7 is literally all (standard) gentoo users, so a news item needs to be clear about who exactly needs to care about the issue, which here appears to be a small subset of all (standard) gentoo users; namely, those who specifically opt in to using C++11 (or are compiling such packages manually). also, strictly speaking, last I checked, the name of the standard is C++11; c++11 is just what gcc takes. and maybe some links about what could break if I link incompatible libraries together would be helpful, since the links don't seem to go over that (at least apparently; I did not read the entire contents). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new virtual: virtual/podofo-build
On 13/10/14 03:46 PM, Zac Medico wrote: Hi, In order to solve bug #503802 [1], I would like to add a virtual/podofo-build package to pull in app-text/podofo and dev-libs/boost. Then packages like app-text/calibre can put virtual/podofo-build in DEPEND and app-text/podofo in RDEPEND. The advantage of this approach is that it makes it possible to use a command like `emerge --depclean --with-bdeps=n` to remove the build-time only boost package (and virtual/podofo-build), since boost is only needed for build-time headers. There may be some other possible ways to specify the dependency, but this approach is the most attractive one that I've seen. In fact, this approach is basically identical to the Virtual for C++ tr1 type_traits example that's given in the dev-manual [2]. Would anyone like to suggest improvements to this idea, alternatives, or raise any objections? [1] https://bugs.gentoo.org/show_bug.cgi?id=503802 [2] http://devmanual.gentoo.org/general-concepts/virtuals/ I feel like there should be a DEPEND specifier for packages required to build against this package. For example, xproto is required to build against SDL (at least using pkg-config), but not to simply use it at runtime. This applies even if one does not directly use xproto headers. It would not be sufficient to specify that DEPEND includes the DEPENDs and RDEPENDs of the dependencies, since then it would be impossible to specify build dependencies that only require the runtime of the dependee, like most build tools. It seems like a poor solution to have to create virtuals for every package that requires such an arrangement. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item review: bash-completion-2.1-r90
On 13/10/14 05:35 AM, Michał Górny wrote: Please review the following news item. - Title: bash-completion-2.1-r90 Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: -MM-DD Revision: 1 News-Item-Format: 1.0 Display-If-Installed: app-shells/bash-completion-2.1-r90 Starting with app-shells/bash-completion-2.1-r90, we are enabling the completion autoloading support. Along with it, we are replacing the eselect-bashcomp module with a new one suited better for the new framework. Users will notice that the new framework is opt-out rather than opt-in. Since completions are loaded on-demand, all of them are enabled by default. If some of them are undesired, eselect-bashcomp can be used to explicitly disable (mask) them. The current eselect-bashcomp setup will *not* be migrated. It may be necessary to rebuild packages installing completions after the upgrade, and remove old configuration symlinks afterwards. For details, please consult the app-shells/bash-completion post-install messages. seems too oriented towards developer audiences, whereas news items are intended to target users; iow, I don't care what's going on behind the scenes, just tell me what I need to do to fix it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add gcc-specs-stack-check() to toolchain-funcs.eclass
On 12/10/14 05:22 PM, Anthony G. Basile wrote:
# @FUNCTION: tc-export_build_env
@@ -578,37 +578,37 @@
gcc-specs-relro() {
local directive
directive=$(gcc-specs-directive link_command)
-return $([[ ${directive/\{!norelro:} != ${directive} ]])
+[[ ${directive/\{!norelro:} != ${directive} ]]
}
# Returns true if gcc sets now
gcc-specs-now() {
local directive
directive=$(gcc-specs-directive link_command)
-return $([[ ${directive/\{!nonow:} != ${directive} ]])
+[[ ${directive/\{!nonow:} != ${directive} ]]
}
# Returns true if gcc builds PIEs
gcc-specs-pie() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!nopie:} != ${directive} ]])
+[[ ${directive/\{!nopie:} != ${directive} ]]
}
# Returns true if gcc builds with the stack protector
gcc-specs-ssp() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fno-stack-protector:} !=
${directive} ]])
+[[ ${directive/\{!fno-stack-protector:} != ${directive} ]]
}
# Returns true if gcc upgrades fstack-protector to fstack-protector-all
gcc-specs-ssp-to-all() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fno-stack-protector-all:} !=
${directive} ]])
+[[ ${directive/\{!fno-stack-protector-all:} != ${directive} ]]
}
# Returns true if gcc builds with fno-strict-overflow
gcc-specs-nostrict() {
local directive
directive=$(gcc-specs-directive cc1)
-return $([[ ${directive/\{!fstrict-overflow:} != ${directive} ]])
+[[ ${directive/\{!fstrict-overflow:} != ${directive} ]]
}
2) Then I'll add gcc-specs-stack-check()
--- toolchain-funcs.eclass2014-10-12 17:19:30.086154455 -0400
+++ /root/toolchain-funcs.eclass2014-10-12 17:19:05.983153358 -0400
@@ -610,6 +610,12 @@
directive=$(gcc-specs-directive cc1)
[[ ${directive/\{!fstrict-overflow:} != ${directive} ]]
}
+# Returns true if gcc builds with fstack-check
+gcc-specs-stack-check() {
+local directive
+directive=$(gcc-specs-directive cc1)
+[[ ${directive/\{!fno-stack-check:} != ${directive} ]]
+}
could merge local directive with the next line too while you're at it
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set
On 05/09/14 01:34 PM, William Hubbs wrote: All, there is a bug open requesting that we add sys-apps/iproute2 to the system set [1]. Originally the request was to drop net-tools, but it has become just adding iproute2. If no one objects, I would like to do this sometime in the next 72 hours by adding sys-apps/iproute2 to profiles/default/linux/packages. Thoughts? William [1] https://bugs.gentoo.org/189149 no, because it's not necessary to bring up a working system. we don't have wpa_supplicant, and we shouldn't have net-tools now that openrc isn't in @system anymore. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] systemd profiles
On 29/08/14 07:09 PM, Jauhien Piatlicki wrote: Hi all, I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles? Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)? Thanks for answers, Jauhien long time question. no simple answer. but basically, systemd is a feature, not a hardware profile. the best architecture should allow one to mix and match features, like funtoo's mixins. search gmane for more details. signature.asc Description: OpenPGP digital signature
tl;dr: [gentoo-dev] Fw: reviewboard and its bugs
tl;dr: python package has nodejs dependencies, we don't have a mechanism like distutils.eclass to install those system-wide. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On 12/08/14 01:29 AM, Duncan wrote: Follow the instructions, as found in the headers of every mail on the list including the one you replied to, or the ones on the site you presumably signed up from? Seriously: s/presumably //, this list is closed-loop. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 28/07/14 08:15 PM, Denis Dupeyron wrote: On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? Denis. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a
On 27/07/14 08:32 PM, James Cloos wrote: PR == Pacho Ramos pa...@gentoo.org writes: PR # Pacho Ramos pa...@gentoo.org (27 Jul 2014) PR # Doesn't build on non-selinux setups (#498032) PR # Removal in a month. PR dev-lang/gforth Did you even try 0.7.3 before coming to that conclusion? It needs a bump, not a dump. And for a GNU package at that. -JimC Please don't crosspost followup messages, especially to the same mailing list twice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using LINGUAS
On 21/07/14 12:23 AM, Thomas Kahle wrote: Hi, the OCR software tesseract has many different plugins for language packs used for OCR for different languages. The ebuild uses the LINGUAS variable to pass the choice of which packages to install to the user. A reverse dependency is app-text/pdfsandwich which roughly puts OCR'ed text in a scanned pdf. Since it uses tesseract it supports exactly those languages that tesseract supports. Should its ebuild have LINGUAS use flags and then depend on tesseract with at least those flags set? While it seems consistent to put the LINGUAS choice in the most user facing package, in this case I would actually not put it in here. It would introduces a point of failure and maintenance work for the each tesseract upgrade (since the language set slightly changes from time to time). A typical user would set LINGUAS in her make.conf anyway. In this case the same choice applies to both packages anyway. Maybe an einfo is sufficient to inform the user it? Cheers, Thomas there are two possible scenarios here. 1. the dependency is COMPILE TIME (ABI, API, whatever). in this scenario, the depender *must* have appropriate LINGUAS, even if that means copying and pasting from the dependee. this is necessary for correct rebuilding, and everything else associated with automagic deps. 2. the dependency is RUN TIME. in this scenario, the case is the same with all other runtime USE dependencies; that is to say, the correct solution is USE_RUNTIME or something along those lines. [0] here, I would say that einfo is superior to copying IUSE, since these flags should be set globally anyways to make sense. [0] please no bikeshedding on whether to call it RUNTIME_USE or ǝsn‾ǝɯıʇunɹ. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Changes in installed ebuilds
On 25/06/14 06:42 PM, Jörg Schaible wrote: Except if they're locally hard masked ... ;-) there's nothing we can do if you intentionally break your own system In that case I think revbump is not warranted since it should continue to work for existing installation and new installations shouldn't be any different beside the dependency and not revbumping eliminates some needless rebuilts. The point is: Why update silently the dependency versions for a stable release? Especially in this case, because the now required versions are the oldest stable ones in the official tree. Therefore anyone with the official tree would have had those anyway. But such an action may affect anyone with a local tree or overlays. wrong, please read the mail regarding the = deps in the first place which you have been referred to repeatedly. I guess you could fork the needed packages (you can always get older versions from cvs) into your custom overlay for old eclipse and maintain them there under some slot. That's what I actually did for all bumped packages in the end. Effort for nothing. broken system is broken signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The infinite git migration
On 10/06/14 06:59 PM, Patrick Lauer wrote: [snip] https://bugs.gentoo.org/show_bug.cgi?id=333531 The current state is almost usable, but it is still obscenely slow (e.g. initial clone taking ~10 CPU-minutes just to figure out what to do), but we can just throw more hardware at it. https://bugs.gentoo.org/show_bug.cgi?id=333685: git 2.0 has pack-bitmap apparently :) so once infra lands that that's basically the end of the major blockers afaik On 10/06/14 06:59 PM, Patrick Lauer wrote: Another part: Few people thought about the difficult problems in the migration. For example the rsync mirrors, which will still be used - the scripts that generate those will need to be changed, tested, and then replaced if a migration ever happens. https://bugs.gentoo.org/show_bug.cgi?id=333701: What comment #2 should have said: This bug is so low priority to the overall initiative that there shouldn't be anyone considering it a blocker, show me the git repo then we can talk :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] /sys/fs/cgroup/openrc/???/tasks sometimes missing
On 03/06/14 02:08 PM, Toralf Förster wrote: If I boot a 32 bit stable Gentoo Linux as a user mode linux guest with current kernels (host is a 32 bit stable Gentoo too), then I do observe sometimes during the boot process error messages from the init system of Gentoo (OpenRC) like the following (for subsystem rngd in this example) : * Starting haveged ... [ ok ] /lib/rc/sh/rc-cgroup.sh: line 87: /sys/fs/cgroup/openrc/rngd/tasks: No such file or directory * Starting rngd ... [ ok ] And indeed, that directory is missing. A restart of the appropriate service however creates those entries. The Gentoo bug entry https://bugs.gentoo.org/show_bug.cgi?id=489386 tells me : It's known race in cgroups, I'm going to address this issue on one of the following weekends. The problem is that issue is not reproducible on my systems. but that's all since 5 months. Now I'm wondering if this just happens for an UML guest and who knows how to fix it ? Please address these mails to gentoo-user@. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Update to elisp-common.eclass
On 18/05/14 02:13 PM, Ulrich Mueller wrote:
if [[ ${EBUILD_PHASE} = *rm ! -e ${sitelisp}/site-gentoo.el ]]; then
ewarn Refusing to create site-gentoo.el in ${EBUILD_PHASE}
phase.
return 0
fi
+ [[ -d ${sitelisp} ]] \
+ || die elisp-site-regen: Directory ${sitelisp} does not exist
+
+ [[ -d ${T} ]] \
+ || die elisp-site-regen: Temporary directory ${T} does not
exist
+
!qefs
if ROOT, EPREFIX, or SITELISP has whitespace, this will throw a syntax
error.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Update to elisp-common.eclass
On 19/05/14 07:17 AM, Ulrich Mueller wrote:
On Mon, 19 May 2014, Alex Xu wrote:
On 18/05/14 02:13 PM, Ulrich Mueller wrote:
if [[ ${EBUILD_PHASE} = *rm ! -e ${sitelisp}/site-gentoo.el ]]; then
ewarn Refusing to create site-gentoo.el in ${EBUILD_PHASE} phase.
return 0
fi
+ [[ -d ${sitelisp} ]] \
+ || die elisp-site-regen: Directory ${sitelisp} does not exist
+
+ [[ -d ${T} ]] \
+ || die elisp-site-regen: Temporary directory ${T} does not
exist
+
!qefs
if ROOT, EPREFIX, or SITELISP has whitespace, this will throw a syntax
error.
Where? In the snippet you quoted, I don't see where whitespace in
${sitelisp} could cause any problems.
Word splitting and filename expansion are not performed on the words
between the `[[' and `]]' -- GNU Bash Reference Manual
Ulrich
/me ponders
hm...
never mind, I was mistaken.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: LTO use in the tree
On 26/04/14 08:34 PM, C. Bergström wrote: Pragmatically nobody gives a f* if grep has been optimized to the max since it's usually not the bottleneck. http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 14/04/14 04:41 AM, Tom Wijsman wrote: There are still other Gentoo Developers listed in some of them, for example owncloud and wpa_supplicant; are they really up for grabs? $ equery -N m $(cat) | grep '^[ HM]' * app-text/fbreader [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.fbreader.org/ * dev-libs/liblinebreak [gentoo] Herd:kde (k...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://vimgadgets.sourceforge.net/liblinebreak/ * net-wireless/madwimax [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://code.google.com/p/madwimax/ * net-wireless/wimax-tools [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.linuxwimax.org * net-wireless/wimax [gentoo] Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://www.linuxwimax.org/ * net-wireless/wpa_supplicant [gentoo] Maintainer: gurlige...@gentoo.org (Bjarke Istrup Pedersen) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Maintainer: zeroch...@gentoo.org (Rick Farina) Homepage:http://hostap.epitest.fi/wpa_supplicant/ * sys-fs/ocfs2-tools [gentoo] Herd:cluster (clus...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://oss.oracle.com/projects/ocfs2-tools/ * www-apps/owncloud [gentoo] Herd:web-apps (web-a...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Maintainer: voyag...@gentoo.org (Bernard Cafarelli) Homepage:http://owncloud.org * www-apps/rutorrent [gentoo] Herd:web-apps (web-a...@gentoo.org) Maintainer: ale...@gentoo.org (Alexey Shvetsov) Homepage:http://code.google.com/p/rutorrent/ So in fact, only app-text/fbreader and net-wireless/*wimax* are up for grabs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy
On 02/04/14 04:02 PM, Rich Freeman wrote: Another option might be to have a tag in metadata.xml that flags packages as never-stable Arguments have been made that such packages do not belong in g-x86. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On 31/03/14 03:36 AM, Dirkjan Ochtman wrote: So, I'm interested... How widely used is the HPN patch set? Are there any good indications that it doesn't negatively impact security? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292932 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693424 https://lists.fedoraproject.org/pipermail/devel/2007-July/105570.html https://aur.archlinux.org/packages/openssh-hpn/ https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/162253 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in https://bugs.gentoo.org/show_bug.cgi?id=504616#c6 to this list again : Since the Debian debakel with fixing an uninitialized memeory I'm very skeptical to distribution specific corrections which are not included upstream. At least I'm wondering if the USE flag hpn should be enabled by the user explicitely - currently it is in IUSE already. 1. Please use a spelling checker. 2. IUSE doesn't mean what you think it means. http://devmanual.gentoo.org/quickstart/#ebuild-with-use-flags signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On 12/03/14 03:15 AM, Yuxuan Shui wrote: Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 While I can't comment too much on the technical aspects, they seem to be relatively sound. However, there are some issues with the, er... other aspects, for lack of better terminology. 1. This is possibly out of scope as a Gentoo project, since ZOL is not really part of Gentoo. If it's not, then you're out of luck, because ZOL is not an accepted organization. 2. This is likely too small to be a GSoC project. Perhaps see [0] for a list of example ideas, if only so you can get a grasp on the size of a good project. It does sound like a good idea though, and even if you can't do it as part of GSoC, you should pursue it anyways. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default
On 08/03/14 05:37 AM, Tom Wijsman wrote:
On Sat, 8 Mar 2014 01:46:52 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
0 1 2 3 4
012345678901234567890123456789012345678901234
Ruby MRI 1.8 removal; 1.9 recommended default
(The latter is GLEP 42's max 44 chars exactly, and accurately
represents the recommended eselect ruby setting.)
$ x=Ruby MRI 1.8 removal; 1.9 recommended default ; echo ${#x}
45
Since you have started with 0 instead of 1, you have one character
more; thus we'll need to find another character to cut, since that
doesn't seem possible I suggest we drop the word default instead.
$ x=Ruby MRI 1.8 removal; 1.9 recommended ; echo ${#x}
37
$ x=Ruby MRI 1.8 removal; 1.9 now recommended ; echo ${#x}
41
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 07/10] Support shallow clones.
On 26/02/14 06:59 AM, Michał Górny wrote: Implementation-wise 'shallow' mode differs only when starting a new branch. In that case, '--depth 1' is used to avoid fetching earlier commits. Further updates are done through plain 'git fetch'. So this fetches all a..b commits. If the package hasn't been updated in a while, wouldn't this be less efficient than a new clone? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
On 26/02/14 10:29 AM, Ulrich Mueller wrote: This is part of normal operation, so maybe downgrade these ewarns to elog? There's nothing the user can do to suppress these warnings, apart from changing his global setting for the clone type, which we won't want him to do. You can put EGIT_CLONE_TYPE in package.env. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Title: =sys-fs/udev-210 upgrade Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2014-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-fs/udev-210 As of sys-fs/udev-210, the options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. A warning will be issued if they are missing when you upgrade. See the package's README in /usr/share/doc/udev-210/ for more optional kernel options. The most reliable way of disabling the new network interface scheme is still the kernel parameter net.ifnames=0. Overriding the 80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream renamed the file to /lib/udev/rules.d/80-net-setup-link.rules. The actual configuration is at /lib/systemd/network/99-default.link, which you can override in /etc/systemd/network/. So, to clarify, you can override the new .rules file or the .link file in /etc but using the kernel parameter is the most reliable way. If you are using sys-fs/udev, you must not use an INSTALL_MASK including /lib/systemd. If you wish to mask unit files, use INSTALL_MASK=/lib/systemd/system. If, for some reason, you do not want any directory named systemd on your disk, use a different device manager, like sys-fs/eudev or sys-fs/mdev. [1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 [2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames signature.asc Description: OpenPGP digital signature
Re: AW: Re: [gentoo-dev] News item draft for =sys-fs/udev-209 upgrade
On 24/02/14 12:48 PM, Lars Wendler (Polynomial-C) wrote: This is another good reason why udev should have _never_ been integrated into systemd! In case someone still wants to retain his original systemd INSTALL_MASK, just use udev ebuilds from poly-c overlay. These ebuilds - still install udevd into /sbin where a daemon belongs to. - disable the crappy new network naming scheme by default - install the new naming scheme config files into /lib/udev/network/ (version =209) - try to prevent most naming pollution of pure udev with systemd crap. I have no plans to stop fixing the annoyances the gentoo udev ebuilds have since udev was integrated into systemd in the ebuilds from my overlay. div Ursprüngliche Nachricht /divdivVon: Mike Gilbert flop...@gentoo.org /divdivDatum:24.02.2014 16:55 (GMT+01:00) /divdivAn: Gentoo Dev gentoo-dev@lists.gentoo.org /divdivBetreff: Re: [gentoo-dev] News item draft for =sys-fs/udev-209 upgrade /divdiv /divOn Mon, Feb 24, 2014 at 7:58 AM, Thomas D. whi...@whissi.de wrote: Hi, not everyone is using systemd. On my systems for example, I don't have /lib/systemd/ (INSTALL_MASK). The current news item draft raises question like When the 'actual configuration' is in /lib/systemd/network/99-default.link... what will happen to people without systemd (and a INSTALL_MASK set)? Would be nice if the news item and Wiki could handle upgrade path for systemd *and* non-systemd users... You need to remove /lib/systemd/ from INSTALL_MASK. If you don't want unit files, mask /lib/systemd/system/ instead. While you're whinging about integration, you're sending bad HTML email. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: git-r3, additional clone types
On 24/02/14 04:00 PM, Michał Górny wrote: Dnia 2014-02-24, o godz. 21:13:15 Peter Stuge pe...@stuge.se napisał(a): Michał Górny wrote: Shallow clone - - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), Hm, why is that? This seems like an unfortunate and inconvenient limitation which might actually reduce usefulness of shallow mode quite severely? :\ Limitation of git design. You can only fetch remote refs, you can't fetch an arbitrary hash. And since we don't download the whole history, we can't use a hash that was past 'depth' of the branch/tag clone. So in order to use an arbitrary hash, we actually have to download the history. Perhaps you could have EGIT_FETCH_REF and EGIT_CHECKOUT? - changing branches may be very inefficient (since it implies re-fetching all objects implied by --depth 1), If it's the same local repo then at least in theory all existing blobs and trees don't strictly need to be transfered, only unseen ones and all the refs. But I'm not sure if git is so good at dealing with this - I haven't looked at exactly how packs are structured. It's not good at all. In fact, if you try to update a shallow clone with 'git fetch --depth 1', it's going to refetch all the objects (while plain 'git fetch' only downloads new objects). It's just another limitation of protocol that we can't do much about. Can't you use `git fetch` as usual to download old..new commits only? This wouldn't help with switching branches though. I would prefer if I needed to allow such mode upgrades explicitly. That sounds like a lot ebuilds failing, requesting you to explicitly change the mode. For example, all Google Code hosted repositories do not support shallow mode. Some projects may require single-branch mode to handle their 'git log' play. Perhaps EGIT_CLONE_MODE could be a USE_EXPAND (yes, another one)? When mirror or single-branch mode is used on a shallow repository, the repository is still marked 'shallow' even if the full history is available. I don't know if this wouldn't break some of 'git foo' uses in the checkout but that probably can't be predicted. Moreover, I don't know if it is safe to remove 'shallow' after doing full-fetch in mirror mode. git fetch --unshallow according to https://stackoverflow.com/questions/6802145/convert-shallow-clone-to-full-clone signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] February 2014 QA policy updates
On 20/02/14 04:46 PM, Mike Gilbert wrote: On Wed, Feb 19, 2014 at 5:07 PM, Chris Reffett creff...@gentoo.org wrote: This does not affect sys-boot/grub's USE=multislot, as that does not mangle the SLOT value like the others (as I understand it). Right. USE=multislot on grub just toggles the renaming of the grub-foo commands to grub2-foo, in case someone (like me) prefers the upstream naming convention. There is also a conditional blocker on sys-boot/grub:0. The SLOT value is always '2'. I would be happy to rename the use flag if anyone else has a better name for it. All other packages use it to mean make multiple versions in a single SLOT installable. I think vanilla should be used, or possibly a different local USE flag, like grub2-bins. The argument of wanting this globally is not valid, since multislot should not be set globally either. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Catalyst news item
On 29/01/14 10:36 PM, Jorge Manuel B. S. Vicetto wrote: On Wed, 29 Jan 2014, Matt Turner wrote: On Wed, Jan 29, 2014 at 7:14 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: +Display-If-Installed: dev-util/catalyst Display-If-Installed: =dev-util/catalyst- Matt, my plan was to show this to anyone using catalyst. I believe this news item is relevant and interesting for anyone using catalyst, but if others disagree, I can restrict it to only those using catalyst-. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer If you insist on showing it to everyone, make it clear that this only affects people on -. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dropping redundant stable keywords
On 28/01/14 11:33 AM, Paweł Hajdan, Jr. wrote: Here's a proposal that may address concerns from the long rfc: revisiting our stabilization policy thread. It seems at least one of the problems is that with old ebuilds being stable on slow arches but not the more recent ebuilds, it is a maintenance burden to keep supporting the old ebuilds even on fast arches where it's still stable. Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? Then these old ebuilds will stay with _only_ slow arch keywords. If they were working back then, they will continue to work now, since there are not that many changes to break things as opposed to faster-moving arches. What do you think? Please let me know if I should clarify this. Paweł I thought there was a general consensus that only the latest stable on a given arch is considered actually-stable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few packages up for grabs
On 21/01/14 10:54 PM, Mike Gilbert wrote: x11-misc/x11vnc I can proxy this if nobody wants. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: overlays.gentoo.org restoration post-mortem
On 18/01/14 05:57 AM, Martin Vaeth wrote: Robin H. Johnson robb...@gentoo.org wrote: FYI: The following repos contained dangling commits/tags/blobs [...] you are encouraged to push again [...] user/mv.git (+blobs) I cannot imagine that the suggested git push removed orphaned blobs: AFAIK it is not possible to execute commands like git prune, git gc --aggressive, or git repack -a -d remotely. Perhaps such things should run as a cron job? From what I know, dangling commits are part of the git workflow if one rewrites history. If you push A - B - C, then reset --hard to B, then push, C will be dangling on the remote and will not be cleaned until git gc is automatically run on the remote, controlled by the gc.auto config variable (on by default). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas
On 17/01/14 08:08 PM, hero...@gentoo.org wrote: Michał Górny mgo...@gentoo.org writes: However, it may be actually beneficial to provide other durations, like weekly deltas. In my tests, the daily updates for this week summed up to almost 50M while the weekly was barely 20M. Is there a way to merge the deltas without the original squashfs? Uh... what? How would that work? how fast is the delta generation? Very. It could be done on the server side on the fly and cached. Too much work. Or we provide a set of 16,8,4,2,1 day deltas, then 16d: 1 piece needed 8d: 2 needed 4d: 4 needed 2d: 8 needed 1d: 16 needed The total of 31 pieces will cover a month (31 days) with at most 5 deltas to be downloaded. e.g. If the system is 19 days old, then we download a 1d, 2d, and 16d. This doesn't really help. Consider that deltas require both a *start* and *end*. It's not as simple as adding it all up, since you would need a 19-3d, then 3-1d, then 1-0d. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On 08/01/14 10:11 AM, Jeroen Roovers wrote: On Tue, 7 Jan 2014 21:12:59 + Robin H. Johnson robb...@gentoo.org wrote: I was also asked by a user to make it possible to adjust the priority of some mirror URLs, instead of only random choice. While we are at it, we could add keywords for (global) regions, so that I can set portage to look for a European mirror and portage will avoid contacting a distant mirror in Asia or America. It's probably worth it in the long run to do a little more here than have users simply express priorities for specific mirrors. We could probably set up the path structure like this: profiles/thirdpartymirrors/gnu/Europe and add a blacklist/whitelist/priority structure in /etc/portage/profiles/thirdpartymirrors, maybe? Portage might even use the local system's timezone to determine what mirror set to use. Eww. Geographically-close files should be made available through GENTOO_MIRRORS and the regular distfiles system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On 06/01/14 03:20 PM, Robin H. Johnson wrote: This is a small feature request, but it will require a modification to PMS, so I describe it here. The present thirdpartymirrors file is unwieldy, and difficult to manage due to it's format with very long lines. It also doesn't permit easy comments. Presently commits to it look very ugly, because diffs are line-based, and we pack a lot into each line. I would like to make it a directory instead of a single file, and extend the internal syntax. I like the idea, but I'm not too sure about the execution. 1. New location: $PROFILEDIR/thirdpartymirrors/$MIRRORNAME 1.1. The name of the mirror is now the name of the file. 1.2. We can have a file extension of .mirrors if somebody would like that. 2. New format (for directory-mode): 2.1. Comments permitted, shell-style. 2.2. Blank lines ignored 2.3. One URL per line, optionally prefixed with - or + 2.4. For stack repos/overlays: 2.4.1. No prefix: replace all prior mirrors from masters with new URLS in this file. 2.4.2. - prefix: remove this URL from the list from masters. 2.4.2. + prefix: append this URL to the list from masters. So if *any* line doesn't have a prefix, then *everything* gets overwritten? What about the prior mirrors listed in the file? There needs to be some mechanism for specifying this, but I don't think this is it. Perhaps a header with a special line? 3. New format (for file-mode): 3.1. This is for cases where thirdpartymirrors is still a file. 3.2. The first token on a line remains the name of the mirror. 3.3. Each subsequent token may be prefixed with + or -, and impacts prior lines/masters. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
On 06/11/13 08:00 PM, Michael Orlitzky wrote: On 11/06/2013 02:11 PM, Thomas D. wrote: This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: I figure everyone here is smart enough to google OCSP before unchecking the box. This isn't the place to argue that the CA system is broken, but I will respond to a few points. I figure everyone here is smart enough not to spread knowingly-incorrect propaganda. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: ... If you are aware about any other know attacks, please share. Replay attacks, mentioned in the RFC (or Google). These could be mitigated, but no one has bothered. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. This is a long way of saying it sends the address of every website you visit to a third party. Addresses, in the context of web browsing, are commonly understood to mean URLs, which include protocol, name, port, and path. OCSP only sends the name portion. Thus, the statement was a long way of saying you are wrong.. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also increase your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. That's cool, but it doesn't exist now and won't for years. And as a visitor you have no way of knowing whether the server supports it (== your privacy will be kept). DH3, and incorrect. Firefox, Apache, and nginx all support OCSP stapling RIGHT NOW. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Only two DNS servers are involved; mine and those of the domain I'm visiting. Not necessarily. Your name server may in fact not be a recursive name server, but delegate some portion to a recursive name server. Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? You're conflating two things here. I trust AES to keep my connection safe. I don't send my data to the CA. You're conflating two things here. If you trust the CA, you trust them not to perform a MitM attack. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation... Well there we agree. Why would you trust the CAs? You don't know them personally and you aren't their customer. Do you trust the governments of the USA and China? (Hint: you shouldn't.) If the answer is no, then you don't trust the CA system. So whether or not you trust them to revoke that authentication is a moot point. False dichotomy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 09/09/13 08:29 PM, Gilles Dartiguelongue wrote:
[1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
[1;32m===[0;0m
[1;32mRCS file:
/var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
[1;32mretrieving revision 1.3[0;0m
[1;32mdiff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild[0;0m
[1;31m--- gdk-pixbuf-2.28.2.ebuild 3 Sep 2013 21:59:11 -
1.3[0;0m
[1;34m+++ gdk-pixbuf-2.28.2.ebuild 9 Sep 2013 22:28:20 -[0;0m
[1;35m@@ -67,6 +67,15 @@[0;0m
[0;0m [0;0m
[0;0m pkg_preinst() {[0;0m
[0;0mgnome2_gdk_pixbuf_savelist[0;0m
[1;34m+[0;0m
[1;34m+ # Make sure loaders.cache belongs to gdk-pixbuf alone[0;0m
[1;34m+ local
cache=usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache[0;0m
[1;34m+[0;0m
[1;34m+ if [[ -e ${ROOT}${cache} ]]; then[0;0m
[1;34m+ cp ${ROOT}${cache} ${D}/${cache} || die[0;0m
[1;34m+ else[0;0m
[1;34m+ touch ${D}/${cache} || die[0;0m
[1;34m+ fi[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m pkg_postinst() {[0;0m
Index: gdk-pixbuf-2.28.2.ebuild
===
RCS file:
/var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v
retrieving revision 1.3
diff -u -B -r1.3 gdk-pixbuf-2.28.2.ebuild
--- gdk-pixbuf-2.28.2.ebuild3 Sep 2013 21:59:11 - 1.3
+++ gdk-pixbuf-2.28.2.ebuild9 Sep 2013 22:28:20 -
@@ -67,6 +67,15 @@
pkg_preinst() {
gnome2_gdk_pixbuf_savelist
+
+ # Make sure loaders.cache belongs to gdk-pixbuf alone
+ local cache=usr/$(get_libdir)/${PN}-2.0/2.10.0/loaders.cache
+
+ if [[ -e ${ROOT}${cache} ]]; then
+ cp ${ROOT}${cache} ${D}/${cache} || die
+ else
+ touch ${D}/${cache} || die
+ fi
}
pkg_postinst() {
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
On 31/08/13 09:00 AM, Gilles Dartiguelongue wrote: And please ensure to remove it in pkg_postrm() when last version of gdk-pixbuf is unmerged. I am not clear on this last sentence. Could you reformulate it please ? Ensure that the loaders.cache file is removed correctly when all versions of gdk-pixbuf have been removed from the system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New license: Adaptec
On 29/08/13 06:29 AM, Tiziano Müller wrote: I would like to add arcconf (binary to manage aacraid-based controllers) to the tree, which is protected by a mandatory clickthrough witch the attached text. The license would be named Adaptec and added to the NON-FREE license group. Objections? Yes. 1. The license expressly forbids redistribution, so RESTRICT=mirror is mandatory. RESTRICT=fetch may be required, but I haven't read it that carefully. 2. The NON-FREE license group does not exist in the g-x86 tree. I don't think this license falls under any current license group. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Moving more arches to dev profiles
On 21/08/13 12:23 PM, Michael Palimaka wrote: Imho the situation is that agos intensive work displaced all the other ones, or they at least rely on ago doing the work and loose focus. At one point before Ago came along, stabilisation of Qt was taking so long we had to start masking reverse dependencies for minor archs, so please don't blame Ago. I believe the point that xmw was trying to make was that ago is doing *too good* of a job, not too poor of a job. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On 20/08/13 11:42 AM, Ian Stakenvicius wrote: It's a feature; all features are optional. It's just not going to be able to be enabled along with FEATURES=distcc is all. I'm sure we have other features that collide with one-another too, so i don't see this being a big issue. FEATURES=nostrip splitdebug neither makes sense nor works. ... similarly, though, i wonder if this would cause issues with i.e. diskless systems or others, that use nfs-mounts for /var/tmp/portage ..? I imagine that that should work fine, since the NFS client is implemented (usually) in the kernel. FUSE mounts *might* be an issue, but I think they should be fine too because the handling process is outside of the sandbox. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 08/08/13 11:26 AM, Rich Freeman wrote: Honestly, we're probably getting to the point where we should offer a choice of init systems in our handbook. It doesn't make sense for Gnome users to go configuring openrc in the handbook only to throw out all that work and start over with systemd. The only lingering problem is that bug 373219, after over 2 years, is still not fixed in-tree. wget https://bugs.gentoo.org/attachment.cgi?id=303775 -O /etc/init.d/functions.sh should not be part of the handbook. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 06/08/13 10:02 AM, hasufell wrote: It seems none of them (except the overview GLEP 57) are implemented yet, although they are roughly 6-8 years old. What is holding it back? Is it just that we don't have a PM implementation yet or is it some political nonsense and PMS blocking progress again? I am not criticizing the portage team in any way here. I just want to push for some attention. -- http://www.gentoo.org/proj/en/glep/glep-0057.html http://www.gentoo.org/proj/en/glep/glep-0058.html http://www.gentoo.org/proj/en/glep/glep-0059.html http://www.gentoo.org/proj/en/glep/glep-0060.html http://www.gentoo.org/proj/en/glep/glep-0061.html https://bugs.gentoo.org/show_bug.cgi?id=64258 http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2709 AFAIK, the status is unimplemented, and nobody's working on it. I believe that the reason is simply that nobody has done the work yet, not due to bikeshedding. I agree that these should be implemented at a rate faster than the current one (i.e. not at all). (FYI, you spelled improvements wrong. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
Further minor grammar/typographical errata: On 04/08/13 11:16 PM, Mike Pagano wrote: Title: vanilla-sources stabilization policy Author: Mike Pagano mpag...@gentoo.org Content-Type: text/plain Posted: 2013-08-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-kernel/vanilla-sources The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, understandably, are unable to keep up with this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest upstream kernel unpatched by Gentoo kernel, we upstream kernel unpatched by Gentoo kernel wat. Possibly intended: For the latest upstream kernel unpatched by Gentoo recommend users add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. gentoo-sources will continue to be a tested and supported version for Gentoo users. Note: This news item only applies to gentoo-sources and vanilla-sources. Other kernels currently maintained in portage have their own policies and procedures in place toda toda? derp. today or just remove it. s/\. /. /g or s/\. ([^ ])/. \1/g (consistently use one space between sentences or two) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On 04/08/13 11:29 PM, Mike Pagano wrote: On Sunday, August 04, 2013 07:24:23 PM Alex Xu wrote: wat. Possibly intended: For the latest upstream kernel unpatched by Gentoo Not intended --- Title: vanilla-sources stabilization policy Author: Mike Pagano mpag...@gentoo.org Content-Type: text/plain Posted: 2013-08-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-kernel/vanilla-sources The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, understandably, are unable to keep up with this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest upstream kernel unpatched by Gentoo, we still not sure that the quotes are really needed here, but it's not a big issue recommend users add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. gentoo-sources will continue to be a tested and supported version for Gentoo users. Note: This news item only applies to gentoo-sources and vanilla-sources. Other kernels currently maintained in portage have their own policies and procedures in place today. LGTM otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [New eclass] twisted-r1.eclass
On 03/08/13 02:29 PM, Michał Górny wrote:
Dnia 2013-08-03, o godz. 17:54:42
Ulrich Mueller u...@gentoo.org napisał(a):
On Sat, 3 Aug 2013, Michał Górny wrote:
2. The eclass comes with a pure bash-3.2 CamelCase converter for
changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant code
can be moved to eutils as portable replacements for bash-4 ${foo^}
and friends.
# obtain octal ASCII code for the first letter.
local ord=$(printf '%o' '${fl})
# check if it's [a-z]. ASCII codes are locale-safe.
if [[ ${ord} -ge 141 ${ord} -le 172 ]]; then
# now substract 040 to make it upper-case.
# fun fact: in range 0141..0172, decimal '- 40' is fine.
local ord=$(( ${ord} - 40))
# and convert it back to the character.
fl=$(printf '\'${ord})
fi
This looks just horrible. You do decimal arithmetic on octal numbers?
Yes. Bash wasn't really happy to do octal arithmetic for me. Yet
in this particular case, with proper assumptions, decimal arithmetic is
practically equivalent.
# obtain decimal ASCII code for the first letter.
local fl=$(printf '%d' '${w})
# check if it's [a-z]. ASCII codes are locale-safe.
if [[ ${ord} -ge 97 ${ord} -le 122 ]]; then
local ord=$(( ${ord} - 32 ))
# and convert it back to the character.
fl=$(printf '\'${ord})
fi
echo -n ${fl}${w:1}
Probably var names should be adjusted, I'm not too familiar with bash
locals.
printf '%d' 'twisted outputs 116 as expected, similar to
printf(%d, *asdf qwerty) in C.
Tested in Bash 4.2.45.
Now time to sit back and wait for it to break in bash
obscure-version-here.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [New eclass] twisted-r1.eclass
On 03/08/13 03:37 PM, Alex Xu wrote:
On 03/08/13 02:29 PM, Michał Górny wrote:
Dnia 2013-08-03, o godz. 17:54:42
Ulrich Mueller u...@gentoo.org napisał(a):
On Sat, 3 Aug 2013, Michał Górny wrote:
2. The eclass comes with a pure bash-3.2 CamelCase converter for
changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant code
can be moved to eutils as portable replacements for bash-4 ${foo^}
and friends.
# obtain octal ASCII code for the first letter.
local ord=$(printf '%o' '${fl})
# check if it's [a-z]. ASCII codes are locale-safe.
if [[ ${ord} -ge 141 ${ord} -le 172 ]]; then
# now substract 040 to make it upper-case.
# fun fact: in range 0141..0172, decimal '- 40' is fine.
local ord=$(( ${ord} - 40))
# and convert it back to the character.
fl=$(printf '\'${ord})
fi
This looks just horrible. You do decimal arithmetic on octal numbers?
Yes. Bash wasn't really happy to do octal arithmetic for me. Yet
in this particular case, with proper assumptions, decimal arithmetic is
practically equivalent.
# obtain decimal ASCII code for the first letter.
local fl=$(printf '%d' '${w})
# check if it's [a-z]. ASCII codes are locale-safe.
if [[ ${ord} -ge 97 ${ord} -le 122 ]]; then
local ord=$(( ${ord} - 32 ))
# and convert it back to the character.
fl=$(printf '\'${ord})
fi
echo -n ${fl}${w:1}
Probably var names should be adjusted, I'm not too familiar with bash
locals.
printf '%d' 'twisted outputs 116 as expected, similar to
printf(%d, *asdf qwerty) in C.
Tested in Bash 4.2.45.
Now time to sit back and wait for it to break in bash
obscure-version-here.
I am dumb. Please disregard the previous message.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
Minor grammar/typographical errata: On 04/08/13 12:53 AM, Mike Pagano wrote: The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla- try not to wrap vanilla-sources on the hyphen if possible sources kernels a week. Arch teams, understandable, are unable to keep up with s/understandable/understandably/ this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest upstream non Gentoo patched vanilla s/non Gentoo patched/non-Gentoo-patched/ or upstream kernel unpatched by Gentoo kernel, we recommend user add 'sys-kernel/vanilla-sources' to their s/user add/adding/;s/their/the/ or similar; recommend user add is not grammatically correct package.accept_keywords file. Gentoo-sources will continue to be a tested and s/Gentoo-sources/gentoo-sources/ supported version for Gentoo users. s/\. /. /g (or vice versa) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] PYTHON flags grammar? why?
On 28/07/13 05:07 PM, Walter Dnes wrote: On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote On Sat, 27 Jul 2013, Leho Kraav wrote: php5-5 vs python2_7 Why, how did that happen? Using the hyphen is cleaner, because the underscore is used as the separator for USE_EXPAND. (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 variable, python2_7 will also work fine.) Out of sheer curiousity, why does make.conf need all 3 of... PYTHON_SINGLE_TARGET=python2_7 Because some packages only accept a single version of Python. e.g. Blender, systemd. I think this also applies to the default Python version for packages that install executables. PYTHON_TARGETS=python2_7 Because the Python ABI [*] requires different libraries to be built for different versions and installed in different places. /usr/lib/python?.? [*] not really a binary interface, but let's call it that USE_PYTHON=2.7 This is deprecated, AFAIK and used for old packages that do not support PYTHON_TARGETS. (something to do with EAPI or eclass or something like that) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 08:09 AM, Vadim A. Misbakh-Soloviov wrote: Hi, list! Many times somebody post buildlogs — they're translated to user's native language due to system's /etc/env.d/02locale. What about adding export LC_ALL=POSIX (or, at least, LC_MESSAGES) to /etc/portage/bashrc by default (out-of-the-box)? That'll 1) fix buildlogs issue This doesn't seem like a major problem. Most errors can be easily deciphered, and if they can't, the user can be asked to run LC_MESSAGES=C emerge. This also introduces a usability problem, in that a user's preference is being overridden. Presumably the user knows that they want their system in a particular language more than we do. 2) fix some python-related compilation breakages, like in xen-tools-4.3.0, for example. This is just papering over the actual issue that needs to be fixed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 10:36 AM, Vadim A. Misbakh-Soloviov wrote: Unfortunately, gentoo.org's archive seems to be broken/frozen, while it is a bit hard to grep 3party archives to find already discussed topics :-/ 27.07.2013 18:31, Jeroen Roovers пишет: We've been over this plenty of times in the past. http://search.gmane.org/?query=lc_all+lc_messagesgroup=gmane.linux.gentoo.develDEFAULTOP=or signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On 24/07/13 10:33 AM, Alexandre Rostovtsev wrote: On Wed, 2013-07-24 at 16:17 +0200, Ulrich Mueller wrote: On Wed, 24 Jul 2013, Michał Górny wrote: Pacho requested that to be able to warn users in GNOME packages that do not work anymore without systemd. Why is the host where the package is built required to run systemd? Wouldn't a warning at runtime better suit the purpose? The purpose of systemd_is_booted() is to provide helpful postinst messages to users depending on whether or not they are running systemd, and for the vast majority of users, the machine where the package is built is the machine where the package will be run. Runtime warnings would require non-trivial patching of the packages in question, so it's not a realistic alternative. Those who have separate build hosts are probably sufficiently technically proficient to understand if the message does not apply to their case. So it is sufficient to add e.g. ewarn_systemd_is_not_booted() (possibly with a better name) to discourage inappropriate use cases? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:37 PM, Peter Stuge wrote: Mike Pagano wrote: Team members working alongside upstream (and downstream) developer Greg k-h have decided to no longer request stabilization of the vanilla sources kernel. Team members and arch teams (understandably) are unable to keep up with the 1-2 weekly kernel releases, and therefore will now direct users to always run the latest vanilla sources Maybe it would make sense to automatically stabilize every v-s kernel right away? //Peter As has been stated, this implies that Gentoo QA has tested the packages and found them to be reasonably safe for use. Although stable kernels *have* been tested by many people before use, Gentoo QA has *not* (officially) tested them, at least not on every architecture. On a technical level, it's not that hard to put sys-kernel/vanilla-sources in your package.accept_keywords. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:49 PM, Peter Stuge wrote: Alex Xu wrote: Maybe it would make sense to automatically stabilize every v-s kernel right away? As has been stated, this implies that Gentoo QA has tested the packages and found them to be reasonably safe for use. .. Although stable kernels *have* been tested by many people before use, Gentoo QA has *not* (officially) tested them, at least not on every architecture. I don't think that matters. If you don't care too much for Gentoo QA, then you are free to run global ~arch on your system. It works reasonably well (no sarcasm), and almost always, someone has tested most packages on most architectures. At least it's been tested by the programmer and maintainer. But that's how KEYWORDS have always been used in Gentoo, as far as I know. On a technical level, it's not that hard to put sys-kernel/vanilla-sources in your package.accept_keywords. But why should Gentoo users have to do that in order to use v-s? So they acknowledge that vanilla-sources has not been officially tested by Gentoo QA. You are free to do the simple procedure once and trust the kernel community to have done adequate testing. If it is intentional to push g-s onto users then it makes good sense - but if I were the sys-kernel team I wouldn't bother with g-s at all and just make v-s as easily available to users as possible.. I can't comment on that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
On 21/07/13 02:25 PM, Zac Medico wrote:
On 07/21/2013 03:53 AM, Pacho Ramos wrote:
El mar, 03-07-2012 a las 10:02 +0200, Michał Górny escribió:
On Mon, 02 Jul 2012 13:45:26 -0700
Zac Medico zmed...@gentoo.org wrote:
On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
Il 02/07/2012 22:01, Zac Medico ha scritto:
On 07/02/2012 12:48 PM, Pacho Ramos wrote:
El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
Hi,
In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:
Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox (unless usersandbox is also
used).
The rationale for having the separate usersandbox setting, to
enable use of sys-apps/sandbox, is that people who enable
userpriv sometimes prefer to have sandbox disabled in order to
slightly improve performance. However, I would recommend to
enable usersandbox by default, for the purpose of logging
sandbox violations.
Note that ebuilds can set RESTRICT=userpriv if they require
superuser privileges during any of the src_* phases that
userpriv affects.
I've been using FEATURES=userpriv usersandbox for years, and I
don't remember experiencing any problems because of it, so I
think that it would be reasonable to have it enabled by default.
Objections?
Looks like non important problems arised and, then, these could
probably be enabled by default, no? :)
I'm not sure about the best way to handle migration for directories
inside $DISTDIR that are used by live ebuilds, since src_unpack
will run with different privileges when userpriv is enabled.
tell the user to chown/remove the files/directories if and when
needed,
How should we tell them? Elog message, news item, or both?
I think this deserves a news item anyway.
unless there is a very good reason (try) to automate it.
I guess something like this might work in pkg_postinst of the portage
ebuild:
find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage
find $DISTDIR -maxdepth 1 -type d -uid 0 -exec \
chown -R portage:portage {} +
I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
This will work only for users who actually keep those in DISTDIR. Some
of them actually redefine E*_STORE_DIR to a more sane location. But
that's probably irrelevant.
Then, is there any other blocker? (apart of the needing of add a news
item)
Thanks :)
I can't think of anything else. I've filed this bug:
https://bugs.gentoo.org/show_bug.cgi?id=477664
userpriv and usersandbox don't work in pypy because os.setgroups isn't
implemented there.
I had a go at it a while back, but the complete and utter lack of any
documentation whatsoever... kinda threw me off.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/base: ChangeLog package.use.force
On 19/07/13 11:46 AM, Michał Górny wrote: Dnia 2013-07-19, o godz. 16:11:52 Markos Chandras hwoar...@gentoo.org napisał(a): On 19 July 2013 16:04, Ian Delaney (idella4) idel...@gentoo.org wrote: idella4 13/07/19 15:04:28 Modified: ChangeLog package.use.force Log: Add entry to force use flags for pypy-bin Revision ChangesPath 1.565profiles/base/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?rev=1.565view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?rev=1.565content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/ChangeLog?r1=1.564r2=1.565 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v retrieving revision 1.564 retrieving revision 1.565 diff -u -r1.564 -r1.565 --- ChangeLog 17 Jul 2013 15:23:53 - 1.564 +++ ChangeLog 19 Jul 2013 15:04:28 - 1.565 @@ -1,6 +1,10 @@ # ChangeLog for Gentoo base-profile # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v 1.564 2013/07/17 15:23:53 chithanh Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/base/ChangeLog,v 1.565 2013/07/19 15:04:28 idella4 Exp $ + + 19 Jul 2013; Ian Delaney idel...@gentoo.org + package.use.force: + Add flags for new pypy-bin 17 Jul 2013; Chí-Thanh Christopher Nguyễn chith...@gentoo.org package.use.mask: 1.37 profiles/base/package.use.force file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?rev=1.37view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?rev=1.37content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.force?r1=1.36r2=1.37 Index: package.use.force === RCS file: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- package.use.force 9 Jul 2013 17:47:25 - 1.36 +++ package.use.force 19 Jul 2013 15:04:28 - 1.37 @@ -1,6 +1,10 @@ # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v 1.36 2013/07/09 17:47:25 graaff Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/base/package.use.force,v 1.37 2013/07/19 15:04:28 idella4 Exp $ + +# Ian Delaney idel...@gentoo.org (17 July 2013) +# Selection of IUSE flags for bin build. +dev-python/pypy-bin bzip2 ncurses sqlite ssl xml # Michał Gorny mgo...@gentoo.org (26 Feb 2013) # Meta-packages which use multilib ebuilds always install development I don't understand that. Why not use +bzip2 +ncurses +sqlite +ssl +xml in the ebuild? I guess that's because they are not optional :). I still don't understand. If they are required to build pypy-bin, why are they USE flags? If they are not required, but build breaks without them, then there should be a bug #. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
(Delayed due to list servers being down)
On 08/07/13 06:48 PM, Alex Xu wrote:
On 08/07/13 04:02 PM, Sven Vermeulen wrote:
On Wed, Jun 26, 2013 at 03:54:47PM +0200, Alex Legler wrote:
I keep track of the stuff at [1], an example output can already be found at
[2].
[1] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki
[2] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki/test
It would appreciate some feedback - things that do not need to be covered
anymore or so (I know our wiki supports some stuff that shouldn't be
rendered anymore).
I don't really like the default MW table style here; it doesn't really
look... Gentoo, if you will. I hacked around the CSS a bit and I'd say
the new look works better. http://i.imgur.com/5eD7FGy.png
Another styling-related concern, the post-dev text is:
All developers can be reached by e-mail using '''nickn...@gentoo.org''' .
It should be:
All developers can be reached by e-mail using
codenickn...@gentoo.org/code.
Also, this output is not correct:
... join the mailing list at{{Mail|
gentoo-harde...@lists.gentoo.org}}.
There is a new line after Mail|. It should be:
... join the mailing list at {{Mail|gentoo-harde...@lists.gentoo.org}}.
c should translate to code, not '''.
inherit output, while a good start, is clearly incorrect. (Ctrl-F
SELinux subproject resources)
Other than that, there don't seem to be any major issues. Excellent work!
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
On 09/07/13 08:29 PM, Alex Legler wrote: On 10.07.2013 01:53, Alex Xu wrote: I don't really like the default MW table style here; it doesn't really look... Gentoo, if you will. I hacked around the CSS a bit and I'd say the new look works better. http://i.imgur.com/5eD7FGy.png Oh god no. The days of these tables are numbered. Okay, maybe they're a little excessive, but I still think the color scheme is a little inconsistent. (too much purple at the top of the page, not enough in the actual content.) Which brings me to... - Developer list: Moves to the sidebar. Not sure how to render that. Maybe in a comment and people remove that once they have added all the members? - Subproject list: Moves to the sidebar as well. Same treatment as for the developer list. I'm not quite sure what you mean here. Another styling-related concern, the post-dev text is: All developers can be reached by e-mail using '''nickn...@gentoo.org''' . It should be: All developers can be reached by e-mail using codenickn...@gentoo.org/code. The line should just be removed altogether. On second thought, I agree. Maybe dev can be changed to show an Email column with mailto: links? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last time touched bugs by year
On 21/06/13 03:27 PM, Sergey Popov wrote: 21.06.2013 23:22, Sergey Popov пишет: 2) package has dead upstream, does not build with current gcc/glibc/binutils/whatever and can not be fixed - bug is closed as OBSOLETE. Of course i am talking about long-standing bugs, that assigned to maintainer-wanted@. That's why OBSOLETE seems to be a better decision, but WONTFIX is reasonable too :-) nobody needs it: OBSOLETE it doesn't work: CANTFIX signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [23]/3 API files
On 16/06/13 03:44 PM, Robin H. Johnson wrote: Image resources: These can be uploaded to the Wiki. How can we ensure later that the media files don't get deleted? Deletion is restricted to administrators, mediawiki also keeps old versions around in case someone reuploads a file. To prevent even that, we can restrict editing certain assets to developers. See my other comment about git-mediawiki maybe, that would satisfy my needs, just having old versions of the images around as needed (not admin-deletable). With modern MediaWiki, it is impossible to permanently remove a page or file without the system administrator (I mean SSH access, not MW sysop) intentionally permitting it or deleting the file archive. https://www.mediawiki.org/wiki/Manual:Image_administration#Undeleting_files https://www.mediawiki.org/wiki/Extension:Oversight https://www.mediawiki.org/wiki/Manual:RevisionDelete signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16/06/13 04:36 PM, Andreas K. Huettel wrote: Hi Kent, IMHO, the criteria for being able to edit the wiki should be lower than the present requirements on being a Gentoo Dev. Only a small subset of official pages is locked, everything else is free to edit for anyone who signs himself up. I'd be interested in seeing if theres' a way to have vetted edits of some kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to edit a page as they see fit, but the changes are only visible to them until they mark their edits done where it can be pushed to a moderation queue for somebody trusted to check over. That exists and is used in the German Wikipedia. (Basically, you get the last vetted page by default, with a small message saying newer versions available.) MediaWiki has a builtin flag mechanism for revisions, but this serves only to try to get all revisions reviewed by at least one person. Pending Changes as implemented by the English Wikipedia uses Extension:FlaggedRevs [0] which, in the most common configuration, allows anyone to edit but hides their changes from the general public until an authorized user approves the changes. [1] [0] https://www.mediawiki.org/wiki/Extension:FlaggedRevs [1] https://en.wikipedia.org/wiki/Wikipedia:Pending_changes signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On 01/06/13 06:36 AM, Ulrich Mueller wrote: On Sat, 1 Jun 2013, Robin H Johnson wrote: Title: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine Too long, maximum 44 characters according to GLEP 42. The above will even be truncated by eselect news. Ulrich echo -n MySQL/MariaDB dropping PrimeBase (PBXT) | wc -c 39 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
Funny. This is starting to sound familiar... almost like some other software that runs at boot, every boot. Hm, what was the name... Oh, a *bootloader*! Something that *loads* different *boot* configurations! But seriously. For people that can install a bootloader, is there really any reconfiguration needed to reboot into a different init system? Just add configuration items as needed for different init systems. We've never automatically added bootloader options if sys-kernel/* is updated; why start now? For those who are on EFI with direct load of Linux, either install a bootloader or use efibootmgr or similar to add entries into the native boot selector (really another bootloader). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect init
On 25/05/13 03:55 PM, Tom Wijsman wrote:
I don't have init= set on my machines and it seems to
start /sbin/init. So that should be correct.
Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
printk(KERN_WARNING Failed to execute %s. Attempting
defaults...\n, execute_command);
}
if (!run_init_process(/sbin/init) ||
!run_init_process(/etc/init) ||
!run_init_process(/bin/init) ||
!run_init_process(/bin/sh))
return 0;
panic(No init found. Try passing init= option to kernel.
See Linux Documentation/init.txt for guidance.);
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Usage of dev-utils/ninja in ebuilds
On 25/05/13 09:53 PM, Ryan Hill wrote: Is NINJAOPTS a variable recognized by ninja or something that would be Gentoo specific? MAKEOPTS is Gentoo-specific anyways. MAKEFLAGS is parsed by at least GNU make. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On 01/05/13 10:11 PM, Duncan wrote as excerpted: Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted: Gentoo is about choice, which to me also means embrace diversitiy. If you want to keep living in your little world, fine, you can and you're very welcome, but also people who want to have fun with new stuff should get the same respect. You mean the respect you've shown me in this email, in my little world? *swoon* you hero. I give up trying to be polite in the face of such crap, it's more than I can stomach. Implementing new stuff also means making things easier, especially in the systemd case. LMAO. You go girl, strut that nonsense like it means something. No way, sunshine. [...] Or at very least be polite when someone queries it. Unfortunately, I believe the above demands a public post... The above is taking it too far. Please take a bit of time to cool off if you need it, then apologize, or if you choose not to do that, refrain from further posts to the list. Agreed in full. I was prepared to write a response, but this is far more eloquent than anything I could have written. I'll go one step further, and say that this is just an example of the toxic behavior that's been shown in the Gentoo community, in particular this mailing list. This complete lack of any semblance of empathy, even in some *Gentoo developers* is entirely unacceptable. Things like a bunch of crybabies, whinging threads, Avoid spreading FUD, Really, please stop spreading FUD. (from different people), Good arguments! As usual I'd say. (sarcasm), Just to annoy people who have successfully used..., ad nauseam are, at best, not remotely productive. Please, just consider for a second how your words will, or even /might/ be perceived by others. Even better: although it might seem beneath you, consider how you yourself might perceive them, were they to be said from someone else. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On 07/04/13 03:36 PM, William Hubbs wrote: According to Gentoo policy, the support for migration from baselayout-1 to baselayout-2 could end on 28 Jun 2012, a year after OpenRc became stable. could end sounds a bit awkward. Try was slated to end or perhaps could have ended. Be more consistent: it's either OpenRC, OpenRc (?) or openrc. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
Notably, NetworkManager generates old-style net files. On 07/04/13 04:13 PM, Roy Bamford wrote: On 2013.04.07 20:36, William Hubbs wrote: All, We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. Here is the news item I want to send out on 10 Apr. Let me know what you think. Thanks, William quote If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. /quote I think you mean If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you may need to reinstall them. The problem is with baselayout-1 and that's what needs to be updated. The you may need to reinstall them is a bit over the top. You can always pick up the pieces with a liveCD. Do you need to point out that the old ( ... ) syntax will no longer be supported, or do you intend to tolerate the baselayout-1 syntax in /etc/conf.d/net and friends a while longer. A friendly link to the update guide http://www.gentoo.org/doc/en/openrc-migration.xml may be in order too. I've seen many users on baselayout-2 with baselayout-1 net files. This news item will bypass them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 06/04/13 03:02 PM, Paweł Hajdan, Jr. wrote: Are there any other formats than unified and context diff? If not, it'd be like another for indoor or outdoor use only or home or office use - i.e. no need to explicitly list all possible options. From the man page: -c, -C NUM, --context[=NUM] output NUM (default 3) lines of copied context -u, -U NUM, --unified[=NUM] output NUM (default 3) lines of unified context -e, --ed output an ed script -n, --rcs output an RCS format diff -y, --side-by-side output in two columns Plus the default. On 06/04/13 03:02 PM, Paweł Hajdan, Jr. wrote: How about having a one guessing and one non-guessing variant of epatch, and encouraging the non-guessing one? User1: how do i put a patch in an ebuild User2: use epatch_guesslevel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Global useflags zeroconf and avahi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kill zeroconf and use dnssd, upnp, ssdp. Problem solved? On 01/04/13 06:43 PM, Andreas K. Huettel wrote: Am Dienstag, 2. April 2013, 00:27:59 schrieb Chí-Thanh Christopher Nguyễn: I would like to suggest unifying use-flag usage, and use zeroconf anywhere. Sounds good. Do you think the same should apply to non-mDNS/DNS-SD based zeroconf like UPnP/SSDP? No idea to be honest... :| opinions? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRWkbRAAoJEJJZfKWYZ3eUmOgP/iUW6ubUy79R/nw92i7HtvR7 g84nyfOwQ5dw2vr0WguJCxrgipzAEdk4NjVQlLk9lUeEOnz3nvvTdxQYVwL1DAup pF0qE6Vc1tBznmaYwdBL6kA10FbSq+lswxhn7xiK6rIj4HoJmN7m2FQ26QBEv5wq 5TvTAaVdFa+RdxSttoq2WrP+pSOUzJA2PLRdRuIOgqBkrfHo1glEEY9wYyOw9eOr RNwFg0ifhjTwgve4tCR5Fmp5oaRipm1xvN8+ksctY8oB067uARGISYdtUz0siV3C j/O/GTkXY6BsVKR7x+TQ9H0S3Snt+BubYSk8u9Dnx+tKMwBH0HlEMwEdLUZuUlgs MjSB5k8105UBX2DZOSUBcEKELda5U1yMTQm4oVB2oJFpeSKDhRvF9g7nwATZL4FR XZvXAjLI7jtbVvhAWXQXSMSRoCEGZ+iCDGhjMoQKJf8uIrbPi8NuQ7d9vFxXKaMP ZbqFDR/8yG/E7yQR+GCg5VW3svPEfiDaRcMLE/XrUYtteEy+WaNd4VFio4abBfYY 2G//Lr+vZCMbA/zN9nY/UGmwK/5D/dYfCfIg6jO5JGQQyf7bIWXI4z9dDXaq0CjO SoIo8gFylhVcx4bFC2lAze7dLsgovJynVv+Ke/3q+VCENPUphLNGPTBBFQGeEh1g PkV0piWKafSJJ+d43y4T =WtVK -END PGP SIGNATURE-
