Re: [gentoo-dev] Re: usr merge
On Fri, Apr 08, 2016 at 07:58:35AM +, Duncan wrote: > > I would also re-iterate, as I'm sure you're aware .. there ARE > > differences between sbin and bin .. unless of course you spend all your > > time in a Rooted VM where it doesn't matter if you accidentally trash > > your system. Some of us maintain a sensible user/superuser distinction > > for a variety of reasons, and simplifying your filesystem to suit some > > particular package style doesn't really sound like good reasoning for > > causing a lot of headaches for maintainers and a distro overall. > > But... the real important distinction in terms of user vs. superuser > executables is file ownership and permissions, not the directory they're > in. No. With a lightweight / I can install systems with two root filesystems that I rsync once I'm sure there's no regression. If one won't boot after an upgrade, I can just reboot and select the other root filesystem in grub. This is much more easy than anything else. -- Nicolas Sebrecht
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Mon, Feb 08, 2016 at 04:37:28AM -0800, Daniel Campbell wrote: > Wow, that's actually pretty great news. That's enough 'momentum' to > maybe maintain a smaller ecosystem free of any particular init-system > preference! Thanks for sharing! I wouldn't call that much "momentum" since it's about adoption, not contributions. Also, to get things right for this thread, I think it would be best to compare contributions like bug reports and pull requests between udev and evdev. Since most major distributions are running udev at that time, I tend to think that udev is still more viable and stable for the long term. So goes as the default. I expect udev to have much more momentum than eudev, for now at least. -- Nicolas Sebrecht
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius wrote: > Oh, eudev also doesn't handle network link setup given that external > tools already do this just fine. That's another difference, though > not one that matters programmatically. That said, the network-link > setup was added primarily to support systemd's use-case, and there's > very little need or point in having it done by udevd on an rc-based > system. Unless I'm mistaken, you're saying that eudev doesn't handle network link but it doesn't matter because rc-based systems don't requires it. And at the same time, I read in this thread that eudev is in-place replacement for udev without any harm. What will happen to the users wanting systemd AND expect the network link setup? -- Nicolas Sebrecht
Re: [gentoo-dev] It is GSoC season again
Hi, On Tue, Feb 09, 2016 at 11:11:07PM -0700, Denis Dupeyron wrote: >Google Summer of Code 2016 is starting. <...> >In this initial >phase the audience is project mentors. Note that you do not need to be >a Gentoo developer to be a mentor. <...> >If you would like to be a mentor for this year please tell us sooner >rather than later. You can be a mentor following up with students while >they're working on their project, or you can be an expert-mentor in a >specific field who will be called in to advise on an as-needed basis >(or maybe never). We will also need people to help us review project >proposals. In case you can help in any capacity don't hesitate to >contact us. GSoC is seriously fun! >If you want to reach us or have any questions about any of the above, >the easiest way is to ping Calchan or rafaelmartins in the #gentoo-soc >channel on Freenode. I'm seriously thinking about becoming a mentor this year. However, I'd like to apply for the imapfw project¹. imapfw aims at replacing OfflineIMAP in the long term. OfflineIMAP is a known application in the portage tree, I guess. I am the current "upstream" maintainer of both OfflineIMAP and imapfw. IOW, this GSoC project would not be a direct enhancement for the Gentoo's related stuff. It's just an app in the tree. Hence, why am I requesting you? It's mostly about audience and having this GSoC project more widely spread, especially to the students. Also, this could greatly help to find a backup mentor. I don't aim to take a slot in the GSoC in the name of Gentoo if you don't want to. In this case, I'd like to request you to add a final secion to your ideas page like "Other's projects you could like" (or something) and a link to our ideas page (not yet written). Little projects like ours usually have various difficulties for getting things done while our softwares are still appreciated by final-users needing them. For the GSoC, the worse blockers I can think of are: - having potential students know about us, our project and that we are recruiting too; - let know to the GSoC orgs we are not alone in the process and have some kind of support from bigger open communities. I hope you'll agree to help us a bit in this area. Anyone wanting to help me at making this GSoC successful is welcome. Also, I'm open to any advice. [1] https://github.com/OfflineIMAP/imapfw Regards, -- Nicolas Sebrecht
Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users
On Wed, Nov 25, 2015 at 11:10:11AM -0600, William Hubbs wrote: > I would like for us to discuss adding the sbin directories to PATH for > all users. Binaries that can run with user privileges could be symbolic linked to /bin. -- Nicolas Sebrecht
Re: [gentoo-dev] [RFC] luajit global useflag
On Thu, Feb 26, 2015 at 01:36:24PM +0800, Ben de Groot wrote: > Use the lua just-in-time compiler dev-lang/luajit instead > of dev-lang/lua Wouldn't that make them both exclusive each other? -- Nicolas Sebrecht
Re: [gentoo-dev] Hello Everyone
On Sun, Feb 22, 2015 at 05:35:47PM +0530, Tushar Rajput wrote: >Â I am novice programmer and wants to contribute to gentoo.Can you give >me some details? I think you should be aware about some context that might not be all obvious at a first start. * Gentoo is mainly splitted in two: the developers and the council. * Developers must apply to the council policies. * Most of the work happens on the Bugzilla Wall, whether you like it or not, and even if it's a oneline patch. * Gentoo relies on teams, affected on areas and ebuilds. * Only official maintainers commit updates. * Commits are done to the SVN repository, the Great Temple. * Each official maintainer have write access to the full portage tree but occasional commits outside your official affected areas might not be welcome at all. Commited patches are not reviewed and having the keys to the Great Temple is not enough, occasional contributions somewhere else means you should supply your work through the Bugzilla Wall. * As a non-official maintainer, occasional contributions requires you to diligently offer your services to the Eminence official maintainer: you can't understand what maintaining means in Gentoo. * Becoming a Gentoo maintainer is a step by step process: you first make your best to have good scores at fixing bugs in the Bugzilla Wall and being at the top of the Scoreboard, then you request an official position, if someone agrees and takes time to answer your request you must pass the GreatOnlineTestToCheckYourSkills, if you're successfull then you are mentored by the guardians of the temple for some not-much-well-defined times, and finally you might become an official maintainer. * Fun is lost for a long time. * Gentoo's specific workflow, tools, policies and administratives tasks have a long history and are designed for a long time to become this wonderfull 5 starts palace. * And of course, keep your efforts and your energy. ,-) -- Nicolas Sebrecht
[gentoo-dev] missing opengl dependency header
Hello,
I've compiled love2d-0.9.1 from the sources with Gentoo. It first failed
with:
$
<...>
In file included from modules/graphics/opengl/GLee.h:66:0,
from modules/graphics/opengl/OpenGL.h:24,
from modules/graphics/opengl/VertexBuffer.h:29,
from modules/graphics/opengl/VertexBuffer.cpp:21:
/usr/include/GL/gl.h:2055:22: fatal error: GL/glext.h: No such file or
directory
#include
^
compilation terminated.
<...>
$
In fact, /usr/include/GL/glext.h is a relative symlink to
../../lib64/opengl/global/include/GL/glext.h
I'm missing the whole filesystem namespace /usr/lib64/opengl/global:
$ ls /usr/lib64/opengl
ati
nvidia
xorg-x11
$
Same problem with glxext.h.
For now, I've created the missing directories (../opengl/{global/..})
and put the missing files downloaded from the opengl registry at
https://www.opengl.org/registry
but I wonder what I was missing in the first place.
What ebuild creates the missing files in /usr/lib64/opengl/global ? I
wasn't able to figure this out.
What's the policy on such broken symlinks? I mean, wouldn't it be better
for the ebuilds to include the target files in the archive and install
them /if/ they are missing?
--
Nicolas Sebrecht
[gentoo-dev] Re: proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS
The 24/11/12, Diego Elio Pettenò wrote: > No. Being consistently stupid is not a good reason to be consistent. Stop being fallacious, please. > And since as I said the RUBY_TARGETS interface is designed to be _usable > by Ruby developers_, being consistent and breaking that, is not > something I would care about. The request is for Gentoo administration. So, talking about developers of a language is not the question. I am a ruby developer and having ruby18 or ruby_1_8 is not much a problem. There are a lot of package names not matching a command name and it's not a problem either. Talking of ruby developers when it comes to Gentoo admins is wrong. -- Nicolas Sebrecht
[gentoo-dev] Re: udev <-> mdev
The 13/07/12, William Hubbs wrote: > What about using devtmpfs alone? It's quiet fine for very simple systems. -- Nicolas Sebrecht
[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
The 01/06/12, Duncan wrote: > But it seems to me that overlays are the primary use case for commits to > public trees other than gentoo first. Otherwise, the whole rebase-vs- > merge problem goes away, because the first public commit is to the gentoo > tree. But especially with overlays (like kde) that have an overlay- > first, test, then gentoo-tree, policy, that public overlay tree (which is > already in git) is part of the process. Commits MUST go thru the overlay > to get to the tree, and that overlay is public, so constant rebasing is a > definite no-no. The purpose of overlays is to have ebuilds maintained outside of the official Gentoo portage. Importing a ebuild from an overlay whether it uses Git or not means importing the ebuild(s). In the Git context, it means the Gentoo maintainer has to make an import commit the same way it would be done to start a project with somthing like: cp 'files to be commited' . git add . git commit -m 'initial import' So, like explained before your concern is clearly out of the current discussion. Importing commit history from Overlays is not supported and will probably never be. Gentoo doesn't forces (and doesn't want to) overlays maintainers to use Git. -- Nicolas Sebrecht
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
The 03/01/12, G.Wolfe Woodbury wrote: > The problem is that one group of developers is ignoring years of history > and purpose in the separation of /bin and /usr/bin and the ability of > having a separate /usr. This is in the udev development team and they > /deliberately/ placed or used some programs in /usr/bin instead /bin and > requiring that /usr bee in the root partition. The udev team has nothing to do with the /usr mount requirement. Lot of packages hooked themselves via udev while they had binaries or dependencies in /usr. > I will note that the historical separation of the /usr stems from the > days of user home directories being in /usr/home instead of /home. It > is getting to the point that the security aspects of having a read-only > mount for userspace executables is being overridden by developer fiat. It's a joke? -- Nicolas Sebrecht
[gentoo-dev] Re: udev and /usr
The 18/09/11, Duncan wrote: > > I don't see any added benefit from using DBUS on my servers. Insterstingly, Duncan just answered your question... > Interesting question. I hadn't seen the suggestion until this thread, > either, and it bothered me too. >From here: > With a moment's thought, I decided I could probably return to a semi- > static dev setup reasonably easily. I'd potentially turn on the early-dev > option in the kernel that I still have off, ATM, which presumably would > mount a tmpfs on dev and populate it with the earliest devices. After > that, if necessary, I'd copy the existing udev-created nodes out to a > persistent state dir, and copy them back in with a little init-time > script of my own. As long as the device ordering remains stable, this > could include by-label, etc, symlinks, or I could simply kill the by- > label, by-uid stuff in fstab, and go back to traditional devices there, > too. > > Either that, or simply go back to a static /dev entirely. > > People with dynamic ordered devices may have to devise their own scripts, > tho, or perhaps more likely, fork off udev from the pre-union state. ...to here. > But it's also possible that's far enough in the future that we can't > really answer the question now, since technology will have changed enough > to make an answer now look senseless, then. Consider trying to answer > the question in terms of the kernel devfs back before udev. The tech > simply changed and those answers wouldn't really work, today. Upstream changes the init process is done. So, you're free to either: stick to upstream (with best long term support); or fork off upstream (requires knowledges, manpower and time); or go back to 1960 with a full/partial static /dev (asking to manually maintain the crap). See the benenfit, now? -- Nicolas Sebrecht
[gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
Hi, (Mail sent to gentoo-dev & gentoo-scm, please Fu2 gentoo-scm only) On Sat, Mar 07, 2009 at 06:29:08PM -0800, Robin H. Johnson wrote: > On Sat, Mar 07, 2009 at 07:57:02PM -0500, Caleb Cushing wrote: > > On Sat, Mar 7, 2009 at 2:27 PM, Alec Warner wrote: > > > People are working on the whole 'replace cvs with git' thing on the > > > gentoo-scm list. > > I'm supposedly on that list and I haven't gotten a message all week? > > is it low traffic? or do I have a subscription/other problem. > It's fairly low traffic. > > The last discussion was just under 2 weeks ago, was about how Manifests > would need to be changed to cut down on merge conflicts. The last > proposal on that was to consider a form of slim Manifest for developers > only (it would still be a full form going to rsync), where objects in > git were not explicitly tracked in the Manifest, but rather but signed > commits (not tags), as their checksums were tracked by the DVCS anyway. > > Additionally, there is this pending item on a Git resource usage bug > that hurts badly during the initial clone: > http://archives.gentoo.org/gentoo-scm/msg_df7c98ec7d2e313856bec31769df407f.xml Following this discussion on the dev list, it appears that some of us missed the 'replace cvs with git' project going on here (on gentoo-scm). As it's very time consuming to find the relevant previous threads. So, could someone give us more information of the state of the project ? (general expected workflow, technical issues, etc) A brief abstract would be very much appreciated. I've read the above link. Now, I know about the Manifest issue. Also, did you had information on how git hosted overlays work ? Thanks, -- Nicolas Sebrecht
[gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
On Sat, Mar 07, 2009 at 02:22:00AM -0500, Caleb Cushing wrote: > > On Wed, Mar 4, 2009 at 7:50 AM, Nicolas Sebrecht > wrote: > > Give a git access to the developpers beside the current CVS ? > > or replace cvs with git... oh and you can replace rsync too... because > git is faster there as well. Provide a git only access today is not serious. Some developpers may not want to learn/switch to git. It could be a long term goal, however. I'm not thinking of internal tools efficiency. It's all about workflow. Also, rsync just do what it has to do the right way. Git does not fit to that kind of job. -- Nicolas Sebrecht
[gentoo-dev] Re: How to speed up maintenance and other Gentoo work?
On Wed, Mar 04, 2009 at 04:01:36AM +0200, Mart Raudsepp wrote: > I'm collecting ideas from the wider development and contributing > community on how to help maintainers and contributors get work done > quicker, or rephrased - how to get more done in the limited time we > have. Give a git access to the developpers beside the current CVS ? -- Nicolas Sebrecht
Re: [gentoo-dev] Looking for help with kernel maintenance
On Tue, Dec 02, 2008 at 12:59:51PM +0800, Cheng Renquan wrote: > 1. I have written several patches for vanilla kernel since 2.6.21, > mostly very simple, > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=search;st=author;[EMAIL > PROTECTED] I would like to go further in the Linux kernel internal comprehension. Could someone tell me where to find a good starting free documentation ? Most of the documentations I've found are about old kernel versions (2.4 series). -- Nicolas Sebrecht
[gentoo-dev] Re: [gentoo-user] dspam useflags improvement (was "tuning ./configure parameters via emerge")
Enrico Weigelt <[EMAIL PROTECTED]> a écrit:
> which package and which options are you exactly going to change ?
>
> IMHO, it's wise to improve the ebuild and perhaps add some useflag.
I agree. It seems that current useflags doesn't permit enough tuning.
Today, I need to use $EXTRA_ECONF with some packages.
For example, emerge dspam package to make it run with qmail doesn't
work. Here is what the dspam manual says:
-BEGIN--/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--
USER-LEVEL INTEGRATION
If you are only configuring dspam for a small percentage of your users,
this is the best method. Configure dspam to use a standalone local
delivery agent like safecat (if you already use procmail or maildrop as
an LDA, you should call dspam from those tools directly).
First, create a small script called maildir_mod in /usr/local/bin...
#!/bin/sh
VPOPDOMAINS="/home/vpopmail/domains"
if [[ "$2" = "-d" ]]; then
user=`eval echo $3 | cut -f 1 -d "@"`
domain=`eval echo $3 | cut -f 2 -d "@"`
cd $VPOPDOMAINS/"$domain"/"$user"
fi
/usr/local/bin/safecat "$1"/tmp "$1"/new 1>/dev/null
NOTE: Be sure to configure VPOPDOMAINS to point to the path for your
virtual domain directories
Now configure DSPAM:
./configure \
--with-dspam-owner=vpopmail \
--with-dspam-group=vchkpw \
--with-delivery-agent="/usr/local/bin/maildir_mod Maildir -d %u" \
# Your arguments
Next, create a .qmail file in the directory for the user with a line to
call dspam, like this:
| /usr/local/bin/dspam --deliver=innocent --user [EMAIL PROTECTED]
The two environment variables $EXT and $USER are created by the
qmail-local program which begins the local delivery process.
-END/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--
Here is the ebuild content:
-BEGIN--/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-
econf --with-storage-driver=${STORAGE} \
--with-dspam-home="${DSPAM_HOMEDIR}" \
--sysconfdir="${DSPAM_CONFDIR}" \
$(use_enable daemon) \
$(use_enable ldap) \
$(use_enable clamav) \
$(use_enable large-domain large-scale) \
$(use_enable !large-domain domain-scale) \
$(use_enable syslog) \
$(use_enable debug) \
$(use_enable debug bnr-debug) \
$(use_enable debug verbose-debug) \
--enable-long-usernames \
--with-dspam-group=dspam \
--with-dspam-home-group=dspam \
--with-dspam-mode=${DSPAM_MODE} \
--with-logdir="${DSPAM_LOGDIR}" \
${myconf} || die "econf failed"
-END/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-
I run ('\' end-line char added in this mail only):
prompt> EXTRA_ECONF="--with-dspam-owner=vpopmail \
--with-dspam-group=vchkpw \
--with-delivery-agent=\"/usr/local/bin/maildir_mod Maildir \-d %u\"" \
emerge -v dspam
The compilation failed. I think I will make a bug report...
Nevertheless, I guess dspam and qmail integration can be done on
various ways and dspam can work with a lot of other MTA (you can see
/usr/share/doc/dspam-3.8.0-r11/doc/).
In this context, maintain this package (dspam) with useflags fair
system only would be a lot of work.
Having EXTRA_ECONF is enough (but should be probably more documented).
If dspam default ebuild could just compile with extra-parameters, it
would be great.
I hope I didn't missed something.
X-post + Fu2
--
Nicolas Sebrecht
--
gentoo-dev@lists.gentoo.org mailing list
