Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, 2005-26-11 at 12:50 -0500, Ned Ludd wrote: > I'm in favor of it enabled per default but I'd like to know what you > think and why. (advantages of on/off by default etc..) First, I fully support solar's patch, this feature should have been integrated into portage months ago. > Anybody wanting to test or make use of this feature right away can grab > a copy of my prepstrip from > http://dev.gentoo.org/~solar/portage_misc/prepstrip and save it to > /usr/lib/portage/bin/prepstrip or patch portage with > http://dev.gentoo.org/~solar/patch_overlay/sys-apps/portage/portage-2.0.53_rc7-prepstrip.patch > It requires you merge pax-utils for the scanelf util. Second, it's often helpful for development to also have the source code of the libraries when debugging a program (like MSFT has done for years). Red Hat also does that, they have built a tool to extract the list of referenced files from the debug info itself. I've made a patch to integrate that tool into portage and an ebuild for the tool. Patch (apply on top of solar's patch): http://dev.gentoo.org/~tester/prepstrip-keep-sources.patch Fully patched prepstrip: http://dev.gentoo.org/~tester/prepstrip The debugedit ebuild is at: http://dev.gentoo.org/~tester/debugedit-4.4.3-ebuild.tar.bz2 -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-27-11 at 13:03 -0500, Mark Loeser wrote: > Ned Ludd <[EMAIL PROTECTED]> said: > > I really can't give an accurate example. Halcyon who has been testing it > > merged world and he was yeilded with 18M of debug info (I have no idea > > how many packages he has). > > Just for the sake of reference, this was with 95 packages and CFLAGS="-O2 > -march=pentium4 -fomit-frame-pointer -pipe". It is essentially a stage3. I have been building stuff with CFLAGS="-O2 -pipe -ggdb" for a while with my own keepdebug/keepsources patch and I have over 475 MB of debug info and 246 MB of source code, but I have 1.5 GB inside /usr/lib .. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > what's the official status of /usr/libexec directory? > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc Why move the libexec content to libdir? They are all executables, not libraries. Its in the same category as /usr/bin. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 2005-29-11 at 15:27 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > > On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > > > what's the official status of /usr/libexec directory? > > > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > > > Why move the libexec content to libdir? They are all executables, not > > libraries. Its in the same category as /usr/bin. > > libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, > this are internal binaries that end user should never run themselves I was going to quote the FHS to prove you were wrong but it turns out that libexec/ has been pull out of it. And they seem to recommend a libdir subdirectory... In the end it doesn't really matter, but if we change from libexec to lib/misc.. will need to modify a lot of gnome package at least. https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00240.html http://lists.debian.org/debian-devel/2005/05/msg00401.html -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Sun, 2006-15-01 at 01:11 -0500, Mike Frysinger wrote: > the one true solution: > - we add an emerge flag (say '--debug-build') which adds "nostrip" to > FEATURES > and auto sets CFLAGS to DEBUG_CFLAGS and LDFLAGS to DEBUG_LDFLAGS Why not use the splitdebug instead of nostrip? And make building with -g the default, then tell small HD users how to disable it in the docs. And it needs to disable -fomit-frame-pointer at least on x86. I've been building my whole system with splitdebug and yes it does take a lot of space, but its really useful. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: net-nds/gq
On Fri, 2006-10-02 at 10:33 +0100, Jakub Moc wrote: > Otherwise, I suggest to p.mask this in two weeks and then remove from > portage. Is there any other useful gtk ldap browser in the tree ? -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2 use flag must die
On Sun, 2006-02-04 at 13:08 -0400, Mike Frysinger wrote: > On Sunday 02 April 2006 12:05, Jakub Moc wrote: > > This is a (not-so happy) reminder that the agony of gtk2 use flag will > > have been lasting for half a year soon. It *really* needs to die. > > too bad it doesnt address packages which still legitimately utilize gtk/gtk2 Is there a legitimate reason to use gtk1 if the gtk2 support is useable? Either way, there shouldnt be a gtk2 flag.. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer: Thomas Cort (tcort)
On Sun, 2006-16-04 at 20:38 -0400, Thomas Cort wrote: > Olivier Fisette wrote: > > Another dev from Québec city! Welcome to the team, Thomas. > > Thank you for the warm welcome. I'm actually in North Hatley (near > Sherbrooke) in the province of Québec. Another Gentoo developer, > deltacow, also lives in North Hatley. Our conspiracy is defintely growing.. I live in Montreal... We're like 5-6 in Quebec now!! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break
On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote: > Alec Warner wrote: > > Well the semantics of the blocker is that the new driver won't work with > > the old server; is that true? Or just the old drivers won't work with > > the new server? > > New server requires new drivers. Old server requires old drivers. There > is no valid combination of new and old. Then you should probably has new drivers block old servers and new servers block old drivers... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Removing .la files...
On Thu, 2008-06-19 at 14:08 +0200, Rémi Cardona wrote: > > Why only plugins? What's to stop an application from loading a "normal" > > library using libtool's dlopen wrapper (perhaps so it can fail gracefully > > if > > the library is missing, for example)? > > Nothing per se, but I have yet to see any FOSS application dlopen() gtk+ > or libpng. FOSS is the keyword here... the flash plugin dlopens a bunch of stuff -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] system set no longer in part of world set
On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: > This brings out the fun of circular depends. I don't really know how to > address this but a lot of packages are going to have to be updated to > contain proper depends. i.e. C based apps will need > RDEPEND="virtual/libc". C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Should 'imlib' USE flag be on by default in x86 and amd64 desktop profiles?
On Fri, 2008-07-25 at 15:00 -0400, Jim Ramsay wrote: > I've run into it a few times now that fluxbox users running Gentoo > wonder why they can't get icons to work in the fluxbox menus. The > short answer is that 'imlib' is off by default in many profiles, > including default-linux/amd64/2007.0/desktop and > default-linux/x86/2007.0/desktop > > I know that I could turn it on by default for fluxbox only using EAPI-1, > but since it's a global USE flag, the profiles may be a better place. > > I think imlib is something most desktop users would want, since it lets > them see all those pretty graphics. Comments? Concerns? imlib is unmaintained/deprecated. So I don't think it makes sense to push it by default to users using GNOME/KDE at least (because they have better image loading libraries). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer
Re: [gentoo-dev] Packages up for grabs
On Mon, 2008-08-18 at 16:18 +0100, Tony "Chainsaw" Vroon wrote: > sys-auth/thinkfinger I have a thinkpad with the right hardware, so I can take this one, did you already pimp out your other thinkpad packages? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Sun, 2008-09-07 at 02:05 +, Jorge Manuel B. S. Vicetto wrote: > I've been thinking on a different method. With this method [3], we > would keep using the . slots (4.1, 4.2, etc) so we also > wouldn't break the invariancy. We would allow users to select whether > to have an FHS compliant install or not (the way to allow that still > needs to be discussed) and we would set the prefix based on that. In > case the user wants an FHS compliant install, the eclasses would block > all kde packages on other slots - except 3.5 (uses other eclasses) and > the live versions (for the above reason that it will always be > installed under /usr/kde/). The big problem with that idea is that upgrading from one version to another will be very painful as portage will yell with a million blockers. The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, if upstream wanted it to be parallel installable, they would have made it that way (like gnome 1.x vs gnome 2.x). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] giving up app-laptop/i8kutils
Hi, My Inspiron has died so I can no longer test app-laptop/i8kutils, so I can't really maintain it anymore. If any dev wants to take it, its all yours. If there is a user who want to maintain it, I can proxy. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Fri, 2008-10-31 at 19:44 -0700, Josh Saddler wrote: > mikmod - Seriously, how many folks make it a habit to listen to .MOD > music all the time? Even netlabels like Monotonik, which started *out* > as .mod, make it harder to find their old .mod stuff. Agree > ldap - Punt for the same reasons kerberos is being punted. Thats used by some public services like keyserver.pgp.com, so I think it should stay there. > eds - Down with more Evolution things! Though possibly not ideal for > Gnome user? That's a non-starter, we need to keep it in the gnome panel to have the nice integration.. There is an argument to be made that it shouldn't be a use flag in the panel maybe. > esd - no one should be using Enlightenment Sound Daemon, period. Ain't > it deprecated, anyway? No worky? DIE DIE.. Maybe we should replace it with pulseaudio ? > emboss - Seriously. Who needs the European Biology Open Software Suite > on a *desktop* oriented system? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote: > So this is about, if the current "policy" for using EAPI 2 in the tree > is really "good" or it should be improved, when introducing future > EAPI's, where portage supporting that EAPI is still unstable. My > proposal would be, to only use new EAPI with a new version or revision > and also let the last non new EAPI version for unstable packages in the > tree. This would allow users of that unstable package with stable > portage to not downgrade or maintain their local version or forced to > upgrade portage. This would be a start. > > I guess, I'm not the only one, having such a setup and it prevent user's > like me testing unstable packages. I need my PC on a daily basis, I > can't afford, having it to reinstall, only because I played with > unstable software. That's why I'm strict, when it comes to system > packages or important packages to me (and I have to congratulate the > gentoo devs for their work, my system just works like a charm and I'm > very happy with gentoo, only hardware failures could make me headaches). > So what I expect, is to find out, if setups like mine can or should be > somehow supported. I'm fine, when the outcome is, that I won't be > supported, then I know and should rethink my strategy to manage my > gentoo boxes. As a arch developer and mostly stable user, I also find this very frustrating. I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote: > On Mon, 08 Dec 2008 19:09:50 -0500 > Olivier Crête <[EMAIL PROTECTED]> wrote: > > I'd like to go further and ask that for the next EAPI change, we only > > allow ebuilds using it into the tree once a version of portage that > > supports it has gone stable. And then, not make any ebuild with the > > new EAPI stable for 60 more days so that the new EAPI related code in > > portage can be tested properly. > > The "can be tested properly" phase is when it's in ~arch... That also means that to pull a significant number of ebuilds it forces mostly everyone to test it.. and that part is annoying.. The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote: > On Mon, 08 Dec 2008 19:25:44 -0500 > Olivier Crête <[EMAIL PROTECTED]> wrote: > > The testing should be two phased, the first for regression (against > > existing ebuilds), and once thats stable, then we can test with new > > ebuilds... > > Uh, regression testing's handled by the package manager's extensive set > of unit tests, which can cover this with targetted accuracy with much > more reliability than making sure random ebuilds still work. We all know that portage doesn't have an extensive testing suite... And that test suites can't cover all the cases that the whole tree does... > What you're suggesting here is making everyone wait four more months > for no increase in safety. I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] How to speed up maintenance and other Gentoo work?
On Wed, 2009-03-04 at 03:26 +0100, Peter Alfredsen wrote:
> On Wed, 04 Mar 2009 04:01:36 +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.
>
> Something like what Debian does where a central service monitors
> upstream ftp and notifies you when a bump is available.
>
> Per-package eclasses - eblits standardized.
>
> Crazy idea: Not-quite-eclasses. Some way to share small bits of code
> between packages, though the code may not be eclass-worthy. We all know
> the use-cases:
> [[ -f ChangeLog ]] && \
> { dodoc ChangeLog || die "ChangeLog exists but cannot be dodoc'ed" ; }
>
> And bits of code of that ilk.
Maybe we could use the dev wiki for that kind of stuff?
Having a wiki.gentoo.org would be even better...
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
On Tue, 2009-03-10 at 20:42 +0100, Thomas Sachau wrote: > I would like to know, if there is some policy about editing skel.* files or > who owns/maintains them. > Additionally, i suggest some changes to skel.ebuild: > -fix the comment for inherit (afaik $(getlibdir) is provided by multilib > eclass) > -comment out the inherit line > -comment out DEPEND and RDEPEND > -remove the || die from econf > -comment out the complete src_compile It may also be a good time to think about updating skel.eclass to use EAPI=2 -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Make the "policykit" USE flag global
Hello, use.local.desc:app-admin/gnome-system-tools:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:app-admin/system-tools-backends:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:gnome-extra/gnome-lirc-properties:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:gnome-extra/gnome-power-manager:policykit - Enable sys-auth/policykit authentication support use.local.desc:media-sound/pulseaudio:policykit - Enable support for PolicyKit framework. use.local.desc:sys-auth/consolekit:policykit - Use the PolicyKit framework (sys-auth/policykit) to get authorization for suspend/shutdown. Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this global. Unless we decide that PolicyKit is the future and make it compulsory). If no one complains, I will make the changes in a couple days. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] media-video/mpeg4ip to give out or give up
Hello, mpeg4ip is dead upstream and has various bugs [1] (some we patch, some we don't). I'll package.mask/remove it if no one wants to take it over (and effectively become upstream). [1] http://bugs.gentoo.org/show_bug.cgi?id=190959 -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote: > --disable-dependency-tracking: > == > > possible breakage of (custom) configure scripts that don't accept > unknown arguments. Would be nice to pass that for most packages, but > doing it always with econf seems slightly inappropriate, given the > above. > Don't think this is an item for fast-tracked EAPI-3. I'm not a big fan either of this one either, when stuff is patched, you may not want that disabled. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Chromium bundled code
On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> > On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> > > On 04/05/12 14:35, Walter Dnes wrote:
> > > > What could work is a shim or compatability layer that gets
> > > > called, and pre-processes requests and forwards them to mdev.
> > >
> > > That's my idea =)
> >
> > and then, look, you have reimplemented udev.
> >
> > {sigh}
>
> Actually, more like what udev *USED TO BE*, namely a simple devicei
> manager.
Maybe Greg understands how udev was and how it should be better than you
do, since he wrote it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Hi, On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote: > I think expressing my own opinion about Lennart-made software is my > right, after all. I would express my opinion about Fabio made software, but I've never heard of any. > Firstly, it's almost impossible nowadays to avoid including avahi, > systemd and pulseaudio into a desktop distro so, there is no real > choice. This issue became a sensible matter for those users who for > instance, wanted to have a silly mp3 player working without going > through the PA nonsense, really missing the old > ALSA-oh-it-was-always-working days. Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc is because they are better than other solutions out there? Do you think is a fast conspiracy to make your life suck? I believe engineers in every distribution are looking at what's available and picking what they think is the best solution, and it turns out Lennart is pretty damn good at making useful software. Was alsa always working? I remember spending hours trying to figure out the right control in alsamixer and fighting with alsa's arcane configuration languages (it has 3 different ones). And how do you deal with modern technologies like Bluetooth audio without Pulseaudio exactly? > Of course, I am not only bringing my personal opinion here, but the > one of the majority of users I've been talking with. I think you only hear from users who like to complain, others are just happy that everything works for them thanks to Pulseaudio, systemd, etc. If you think that Lennart does not solve problems, maybe it's because you don't even understand what the problems were? For example, I encourage you to read about how the dynamic latency in PA allows for lower power usage or how modern audio hardware is designed to use a userspace sound server, etc. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: > WD> cat /sys/block/sda/removable > WD> 0 > > Note that a 0 there does not imply that the device cannot hotplug. > > My USB drive reports 0. And I'm sure it works fine with udev? "Those who do not understand udev are condemned to reinvent it, poorly". -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: > I *DON'T WANT* "a serious framework", I want a lightweight device > manager... period... end of story. Stick with the unix principle of one > app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: udev <-> mdev
On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote: > On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote > > > I'll venture a guess the solution will be to create a shim daemon > > which turns around and launches udev. > > A quicker-and-dirtier solution would be to create a shim daemon that > runs under the the name "udev", and passes all calls to /sbin/mdev. Seriously, mdev is a just a bad and now useless hack, it does nothing more than using devtmpfs. You do not need udev for a very simple system. If you system is a bit more complicated, than udev is what you want. It works fine on millions of shipping devices. And on any new embedded platform, one should seriously think about using systemd too. It is very lean, replaces most of the giant, unmaintainable shellscripts that you find in many devices with smaller compiled code, and was designed to be a good fit for embedded devices. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: > If somebody really is pushing for an all-out /usr move by all means > speak up, but I think that basically what everybody is advocating is > trying to follow upstream for individual packages. As I've been saying for a while, doing a full merge of /bin, /sbin, /lib into /usr is probably unavoidable in the long term. We should be ready for it, and even try to do it progressively. As currently, the split is entirely arbitrary. Also be ready for a merge of /bin and /sbin.. I'm sure most people can't even explain the difference between them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: > On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > > > I'm sure most people can't > > even explain the difference between them. > > > > /sbin is for bins that only root should be able to run. easy. :) Except when it isn't the case, for example /sbin/ifconfig is a good way to find one's ip address, etc. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: > On 2012-07-17, at 7:07 PM, Olivier Crête wrote: > > > I'm sure most people can't > > even explain the difference between them. > > > > /sbin is for bins that only root should be able to run. easy. :) Or you can try this experiment and see what breaks: chmod og-rwx /sbin/* /usr/sbin/* -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:54 -0400, Richard Yao wrote: > On 07/17/2012 07:07 PM, Olivier Crête wrote: > > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: > >> If somebody really is pushing for an all-out /usr move by all means > >> speak up, but I think that basically what everybody is advocating is > >> trying to follow upstream for individual packages. > > > > As I've been saying for a while, doing a full merge of /bin, /sbin, /lib > > into /usr is probably unavoidable in the long term. We should be ready > > for it, and even try to do it progressively. As currently, the split is > > entirely arbitrary. > > > > Also be ready for a merge of /bin and /sbin.. I'm sure most people can't > > even explain the difference between them. > > > > The difference is simple. You put stuff into /sbin when you do not want > regular users to be able to select it via tab completion by default. That's certainly not how te FHS explains it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:24 -0400, Richard Yao wrote: > GNOME is part of the GNU project, so we should be safe unless they > decide against portability. OpenSuSe and Mageia are other distributions, > so they are not upstream for us. With my GNOME hat on: GNOME does not take any marching orders from RMS or anyone else in the GNU project. We will do any changes that we believe are necessary to produce a better end user experience or to make our code more maintainable. If that means adding dependencies that are Linux specific, we will do it. And we have done it before, for example, we have dependencies on udev for certain features. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote: > > It would be nice if a sensible structure could be proposed and > > agreed by ALL Linux distributions (coordinated with BSD). > > > > +1 > > If a new file system standard is required, my preferences based on a > history of what is worked and changed over the last 20-30 years would > be: > > - OK with requiring / and /usr on the same FS. This has become common > practice with virtualization and small system deployments, and I > haven't seen any compelling advantage for keeping separate on larger > boxes. No one proposes that, the only requirement that you have for modern Linux to work well is that if /usr is on a separate partition, you need to mount it before starting your main system (ie, from an initramfs). > - NOT OK with limitation on allowing /var, /opt, /home, or any other > common server mount points to require use of initramfs/initrd. There > is enough disagreement as to the reliability and ease of maintenance > of initramfs/initrd that it should not be needed for common server > deployments. This is clearly not needed, /run was even invented to allow /var to be mounted later. > - It would be nice if the rootfs used a snapshot based filesystem and > if the bootloader was intelligent enough to easily allow admins to > boot to older snapshots as an expectation for any standard modern unix > system. One of the reasons to put everything in /usr is to allow using a snapshot based FS, so you can run a system where /usr is read-only and where when you can do all upgrade atomically by writing your changes to a read-write snapshot and then switch all at once. So you never have any half-upgraded package on your system. > - Ideally, server motherboards would come with flash based storage > where sysadmins could install rescue environments as part of a normal > unix install, and that the boot loader or bios would be smart enough > to provide the option to boot from it automatically whenever a normal > boot failed. > - NOT OK with removing the distinction between user and system > binaries. Essential binaries required to boot and troubleshoot system > problems should be located separately from user binaries. Security > sensitive or paranoid admins should be able to make the system binary > path read-only or completely remove the user binary directory from > roots PATH if they so wish. The rescue system should be entirely separate from the main system, so it survives mishandled upgrades. So having that should not hinder how your main system is built. So you should have it as a separate partition or you can even have it an initramfs (ie, in a single file on the main system). > - OK with merging / and /usr, but in that case...why not just move > everything in /usr to /...but limit /sbin to system binaries and /bin > to user ones? This would be horrible for migrations though and > possibly confuse many scripts. The idea of putting everything in /usr instead of / is that you can then make /usr read-only and you can share /usr between multiple systems, while / is read-write and contains /root and /etc. > - NOT OK with making systemd the default init system anytime in the > next few years, it is way too immature and like most major system > software changes...probably will take much longer before it really has > the standing to propose being a new standard. I fully expect systemd to be the init system of the next iteration of RedHat Enterprise Linux, which is probably the most "enterprise" of all distributions, with the most QA and support and everything. It's not a side project of dude of his basement, it has the full support of a large team of people at RedHat. There has probably already been more testing done on systemd today than on OpenRC... > - What other elements can new filesystems like btrfs offer that should > be considered? ext3/ext4 has worked great with the older > standards...but it essentially mimicked the capabilities of older > file-systems that the original unix standards were based on. Btrfs > might change our expectations. I'm assuming that btrfs will be the > standard production fs in a few years. The big thing that btrfs brings is snapshots and subvolumes... So it makes it possible to do atomic upgrades and such. Also, you can have "apps" be subvolumes and also handled atomically. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: > While OpenRC is likely perfectly capable of starting/stopping daemons as > a normal user (with some tweaks), I expect systemd replacing init, to > already have a fair bit of isssues with being just a normal unprivileged > user. I may be wrong, of course. However, the notorious reputation of > that piece of software aiming for system-domination doesn't really make > it sound to me like it ever will be a good match for Prefix. You happen to be wrong. systemd runs perfectly as non-pid-1. Part of Lennart's well published plan for world domination is to use systemd as a session manager, so it would replace gnome-session, etc. Lennart & friends are currently pushing kernel patches to make it fully recursive (such as being able to re-parent orphaned processes to the session's systemd instead of the global one. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 20:28 +0200, Fabian Groffen wrote: > On 06-08-2012 11:16:52 -0700, Olivier Crête wrote: > > On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: > > > While OpenRC is likely perfectly capable of starting/stopping daemons as > > > a normal user (with some tweaks), I expect systemd replacing init, to > > > already have a fair bit of isssues with being just a normal unprivileged > > > user. I may be wrong, of course. However, the notorious reputation of > > > that piece of software aiming for system-domination doesn't really make > > > it sound to me like it ever will be a good match for Prefix. > > > > You happen to be wrong. systemd runs perfectly as non-pid-1. Part of > > Lennart's well published plan for world domination is to use systemd as > > a session manager, so it would replace gnome-session, etc. Lennart & > > friends are currently pushing kernel patches to make it fully recursive > > (such as being able to re-parent orphaned processes to the session's > > systemd instead of the global one. > > Good to know that I'm wrong. I didn't know they pursued world > domination too. I wonder how "kernel patches" go well together with > "being in an environment unknown to you, or that you cannot control at > all", though. Seems there is interest for it to support Prefix then. > Looking forward to patches and solutions to complement the challenges of > this year's GSoC task. I think they only want to support systemd-in-systemd, not systemd-in-random-init-system. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
Hi, Let's cut the FUD. On Tue, 2012-08-07 at 08:47 -0400, Sylvain Alain wrote: > 1. The SystemD and Udev projetcs are merged now, so what is the impact > on the Gentoo on a short term period ? Only the build system is merged, they're still separate binaries. > 2. I saw on some lists that Gnome/Kde and Xfce plan to use some > SystemD API, so does it means that we will need to install SystemD > aside of OpenRC ? The APIs that GNOME is using from systemd are simple, well designed and well documented D-Bus APIs [1][2][3]. They are implemented by simple binaries separate from the core systemd. Legacy init systems can just re-use them as-is. Also, systemd includes logind, which replaces ConsoleKit with a much better design. > 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint Old versions of GNOME (and KDE, XFCE, etc) had to have distro-specific code for a bunch of things, such as changing the timezone, the system locale or the hostname. Because these things are in separate places in every distribution for historical reason. So every desktop had to re-implement these things for every distribution, making a lot of duplicated code. The goal is to have a single set of tools using a common D-Bus API that you only have to implement once per distribution and that every desktop can use. > 3. In a long term vision, can OpenRC still exist on a Gentoo > box(OpenRC might be able to boot the box then give the control to > SystemD/Udev for the rest of the boot process) or we will need to > migrate to SystemD to be able to use Gnome/Kde or Xfce ? I expect that in the not so long term, systemd will become an essential user-space component of desktop Linux, just like crond, syslog, dbus, udev or glibc. Sharing that code just makes sense, that allows distributions to focus on their strength instead of having to maintain a nightmare of shell scripts. Sure you can do a Android and write your own crappier version, but that doesn't gain you anything. Refs: [1] http://www.freedesktop.org/wiki/Software/systemd/hostnamed [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/logind -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 10:42 +0200, Luca Barbato wrote: > On 08/07/2012 09:00 PM, Olivier Crête wrote: > > I expect that in the not so long term, systemd will become an essential > > user-space component of desktop Linux, just like crond, syslog, dbus, > > udev or glibc. Sharing that code just makes sense, that allows > > As in completely optional and easily replaceable? That would be a nice > improvement over the current "use it or die" attitude. Sure, you can use bionic and use a shell script as your PID 1. But no one would do that as part of a desktop/server computer. > Repeat after me: having your first process require anything more than > libc is stupid and dangerous. It's lucky that systemd only requires libc, libc-like libraries (libselinux, libcap, libaudit, librt, etc) and it's own libraries (ie, maintained by the systemd team) then? > Most ideas behind systemd are interesting, their current implementation > is sometimes completely wrong and given the experience with pulseaudio > we all know that they won't change even if you provide code for it. This is bullshit, if you have good reasoned arguments, Lennart is a very reasonable guy, but if you just say "your ideas are shit, you code is terrible", then yes, he'll just ignore you. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 13:31 -0500, William Hubbs wrote: > On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote: > > > Most ideas behind systemd are interesting, their current implementation > > > is sometimes completely wrong and given the experience with pulseaudio > > > we all know that they won't change even if you provide code for it. > > > > This is bullshit, if you have good reasoned arguments, Lennart is a very > > reasonable guy, but if you just say "your ideas are shit, you code is > > terrible", then yes, he'll just ignore you. > > Sorry to call you on this one, but that is not the experience I had. > > I proposed adding configure switches to their build system to accomodate > source base distros, such as gentoo, who at times want to use udev > without systemd. I even went out of the way to make sure that I didn't > change their default settings. > > Look at a thread on their ml called minimal builds along with their wiki > page on minimal builds for Lennart's answer. He even went so far as to > say that our package managers are broken, and there was absolutely no > negotiating this point. We are wrong as far as he is concerned. He has a perfectly reasonable argument that build time is really not something you should be optimising for. Build systems easily become overcomplicated if you try to make everyone happy, you do have to make choices. Anyway, I'm not sure how that's related to the quality or design of systemd. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 19:00 -0400, Walter Dnes wrote: > On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote > > On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato wrote: > > > > > Obviously it is always fun seeing people first say "accept it or fork > > > it", then "do not keep your fork you are wasting time" once somebody > > > starts forking and/or working for an alternative. > > > > By all means, fork it. Just allow Gentoo users to use udev/systemd as > > upstream intended. And while we are at it, don't put OpenRC in the > > dependency list of baselayout, otherwise it gets pulled in (and > > sysvinit with it) for all systemd users even if we don't use it at > > all. > > Good idea. While we're at it, please also let's not make > systemd/udevd/dbus/pam mandatory. Can we also have a desktop that doesn't use X? -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote: > On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev > wrote: > > On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote: > >> Beside the fact that these would probably have looked better in > >> /usr/libexec > > > > See Kay Sievers's comment at > > https://bugs.freedesktop.org/show_bug.cgi?id=51617 : > > > > "/usr/lib// is a directory like /usr/libexec/ or even /bin. It > > shares absolutely zero things with the arch-specific $libdir ,or lib64/. > > > > /usr/lib// is the canonical "application private directory". It > > has the multi-lib or arch-specific rules as /bin. > > > > So... where should GRUB2 be installing its modules? Currently they get > installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and > platform are determined by use flags. > > Should we drop the get_libdir and put them in /usr/lib/grub instead? > Should I even worry about it? There really have no reason to be in $(get_libdir) as they're not compiled for the platform implied by $(get_libdir) ! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > In researching this program, I have found that it and ifplugd, which is > the alternative, have been unmaintained for years. Also Debian has > declared netplugd to be obsolete in favor of ifplugd. > > Does anyone have any thoughts about whether we should keep OpenRC > support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote: > On 9/10/12 11:05 PM, William Hubbs wrote: > > On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: > >> On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > >>> In researching this program, I have found that it and ifplugd, which is > >>> the alternative, have been unmaintained for years. Also Debian has > >>> declared netplugd to be obsolete in favor of ifplugd. > >>> > >>> Does anyone have any thoughts about whether we should keep OpenRC > >>> support for one or both of these? > >> > >> The ifplugd author recommends you use NetworkManager for dynamic > >> networking scenarios. > > > > NM seems bloated though unless you are using a desktop environment. It > > wants to install 29 dependencies on my box. > > NM and connman are quite a bit overkill indeed. If you're on a server, you probably want a static configuration anyway, not something dynamic. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] making USE=upnp a global flag
On Sun, 2012-09-30 at 17:44 +0200, Gilles Dartiguelongue wrote: > Le mercredi 19 septembre 2012 à 10:19 +0200, Michał Górny a écrit : > > > > Just to make it clear: > > - USE=upnp for upnp-igd or nat-pmp, > > - USE=dlna for the video magic and so on. > > > > Do I understand correctly? > > No, TV makers and others advertise UPnP as DLNA (digital living network > appliance) but that actually refers to both port forwarding (eg. used in > consoles) and to media streaming (eg. PC to TV). DLNA is actually a subset of UPnP with some strict certification rules. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-06-07 at 13:49 +0100, Ciaran McCreesh wrote: > On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote: > | > Sounds rather flaky and unreliable... > | Sounds rather vague and without arguments. > > Well, you're assuming that > a) everyone's using a C compiler, If you're on Gentoo, I sure hope you have a C compiler > b) that gcc has the slightest clue what it's doing, Again, if you've compiled your whole system with gcc, I guess its a safe bet > c) that the user has no problem using nasty hacks to regain control, Since when is setting your -march/-mnosse/-mnommx/-mno3dnow a nasty hack? > d) that this information is only needed at compile time, I agree this is a problem.. > e) that various gcc internal definitions won't change... We can always change the eclass and check the GCC version if that happens. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [treecleaner] Last rites: media-sound/alsaplayer
On Mon, 2006-21-08 at 18:29 +0530, Abhay Kedia wrote: > On 8/20/06, Brian Harring <[EMAIL PROTECTED]> wrote: > > On Sun, Aug 20, 2006 at 09:14:24AM +0200, Michael Weyersh??user wrote: > > > Abhay Kedia wrote: > > > > Can someone suggest an appropriate alternate please? > > > > > > I don't know if it's appropriate since I never used alsaplayer, but > > > mpeg123 is a good player for "Just play me this file on a console > > > without much hassle". Other candidates would include mplayer and mpd. > > > > he meant mpg123 (as-is), and/or mpg321 (gpl2), not mpeg123... > > > I use alsaplayer to play KDE sounds as it works well with dmix and I > can keep aRts disabled. All KDE sounds are ogg files and when I play > them with mpg321, it just exits without producing any sound. I guess > the only thing left for me to use is mplayer? You can use ogg123 -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] mulltiib cruft: /emul
On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote: > On Tue, Aug 08, 2006 at 11:43:13AM -0400, Mike Frysinger wrote: > > someone remind me why our emul packages install in some obscure directory > > tree > > rooted in /emul > > > > if we moved these things to the standard lib32 dirs, it would certainly > > ease > > the pain of people doing multilib building, both in and out of portage > > > Mike, Sorry I missed you on irc yesterday, didn't get back til later than > expected. > > I'm not sure why /emul was originally chosen though it's a choice I've > just gone along with whilst maintaining these packages. It was chosen because emul packages are put in /emul on ia64. > I've always viewed the emul libs as a temporary measure until we had full > multilib > fuctionality in portage. Afaik the only person working on this was > eradicator who has been mia for a while now so I'm unsure weather this > is ever likely to arise. Given that it looks like we'll be stuck with > these binary libs for some time yet then we may as well do as you > suggest and install them in a standard location to make building against > them a bit easier. I'll look into doing this when I next version bump the > packages. I still believe we should reserve the regular directory for the real multilib stuff, otherwise it will be very painful when we decide to move. And continue to put the stopgap binary packages in /emul. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[gentoo-dev] last rites for net-im/gabber and dev-libs/jabberoo
Hi, There have been no release since June 2004, the newer versions have p.masked since 2004. The older versions doesnt build. They have open bugs #62182, #88929 and #101581. I'll remove them on November 1st. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] X.Org 7.1 is Stable
On Mon, 2006-16-10 at 07:37 -0400, Caleb Cushing wrote: > is evdev (for 7.1) stable now? and by stable I mean can I use it > without it crashing xorg? I should probably test this because I don't > recall it getting updated which means it is still broken. It works if you use it the way they intend it to use it. Read the man page. Otherwise yea it will crash. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[gentoo-dev] last rites for sys-devel/odinmp
Hi, I haven't updated it in years and no one has noticed. I guess no one uses it. And I don't use it anymore either. Bug #67273 has been there for a long time. It is p.masked and will be removed on Nov 16 2006. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer: Ryan Hill (dirtyepic)
On Sun, 2006-22-10 at 16:54 -0400, Patrick McLean wrote: > Petteri Räty wrote: > > So please give dirtyepic the usual warm welcome. > > Welcome Ryan, always nice to have another Canadian :) Go Canooks!! -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eselect module for choosing between gnash and netscape-flash
On Fri, 2006-20-10 at 21:08 +0100, [EMAIL PROTECTED] wrote: > Hi, > > I wrote an eselect module for choosing between the browser plugins from > net-www/gnash and net-www/netscape-flash, and I was wondering if it could > be included in Gentoo (probably not in its current state...). Shouldn't something like this be a Firefox/Seamonkey extension instead ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eselect module for choosing between gnash and netscape-flash
On Tue, 2006-24-10 at 21:57 -0400, Olivier Crête wrote: > On Fri, 2006-20-10 at 21:08 +0100, [EMAIL PROTECTED] wrote: > > Hi, > > > > I wrote an eselect module for choosing between the browser plugins from > > net-www/gnash and net-www/netscape-flash, and I was wondering if it could > > be included in Gentoo (probably not in its current state...). > > Shouldn't something like this be a Firefox/Seamonkey extension instead ? Something like Plugin Manager: http://www.gozer.org/mozilla/extensions/ -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer: Hans de Graaff
On Sat, 2006-04-11 at 16:36 +0100, Christian Heim wrote: > Its my pleasure to introduce to you Hans de Graaff (also known as > graaff), our latest addition helping with emacs/xemacs. Go Emacs! Go Emacs! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Tue, 2006-07-11 at 01:06 +, Ciaran McCreesh wrote: > On Mon, 6 Nov 2006 16:43:24 -0500 Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | infra believes using SPF helps fight spam > > Then infra are wrong. SPF was not designed to fight spam. Isn't preventing email forgery one step in fighting spam ? And that's what SPF is supposed to be used for. That said, I still haven't seen any good explanation how to send mail through the gentoo.org mailserver for exim or postfix. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] last rites for net-im/gabber and dev-libs/jabberoo
On Sun, 2006-01-10 at 11:08 -0400, Olivier Crête wrote: > Hi, > > There have been no release since June 2004, the newer versions have > p.masked since 2004. The older versions doesnt build. They have open > bugs #62182, #88929 and #101581. > > I'll remove them on November 1st. > Gabber is gone.. All hail Gossip! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-core] New profiles/ChangeLog
On Fri, 2007-12-01 at 09:29 -0500, Chris Gianelloni wrote: > There's a ChangeLog file in profiles/ChangeLog now. Please use it when > making changes to things in profiles/*... Almost all entries un profiles/ChangeLog are related to package.mask. We had a little discussion in #gentoo-dev and found it redundant. I think we should exclude changes to package.mask from that changelog otherwise it will drown in noise. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/centericq needs a new maintainer
On Tue, 2007-09-01 at 09:35 +0100, Sune Kloppenborg Jeppesen wrote: > net-im/centericq is without an ebuild maintainer and has an open security bug > #160793 > > https://bugs.gentoo.org/show_bug.cgi?id=160793 > > Anyone willing to take care of this package in the future, please update > metadata.xml and CC yourself on the bug. Its also unmaintained upstream and is showing its age. Its now masked and will be removed in 30 days if no one comes forward, and becomes a new quasi-upstream. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Topic for Feb council meeting
On Sun, 2007-28-01 at 14:24 -0800, Mike Doty wrote: > The subject of what to do if a council member voluntarily leaves the > council came up at the last meeting. The glep doesn't cover what to do > in this case. > > Here are the options: > > 1. re-elect a whole new council. > 2. elect a new member at a reduced term to fill the vacancy. > 3. take the 8th spot from the last election. > > The spirit of the GLEP would indicate option 2, but it's never spelled > out. Speak out now if you have a opinion on the subject. It should definitely be one of 2 or 3. Option 1 is ridiculous. I would personally opt for 3, since it allows the council to keep on functioning properly. Or maybe 3 if there is unanimous approuval from the council or 2 otherwise. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A Gentle Reminder
On Sun, 2007-11-02 at 22:46 +, Stephen Bennett wrote: > On Sun, 11 Feb 2007 22:23:44 +0100 > Jakub Moc <[EMAIL PROTECTED]> wrote: > > > Oh sure... Next time, blame me for Sept 11, keep amusing us by your > > bullshit. > > If you like, I can say that you killed Jesus and were single-handedly > responsible for the extinction of the dinosaurs. Would that make you > happy? Are you implying that he is the One True God ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: How others handle bad behaviour on mailinglists
On Fri, 2007-09-03 at 15:57 +, Jeff Rollin wrote: > > > On 09/03/07, Stephen Bennett <[EMAIL PROTECTED]> wrote: > On Fri, 9 Mar 2007 10:41:57 -0500 > Philip Webb <[EMAIL PROTECTED]> wrote: > > > "Always be parliamentary; > > never be personal; have a point to make; know when to > stop". > > 'Parliamentary' means 'follow the rules for MPs in Ottawa or > > Westminster'. > > If you've seen what goes on in the House of Commons on > occasion, you'd > know that those two are contradictory. > -- > gentoo-dev@gentoo.org mailing list > > > Hahah, yes! - But /which/ House of Commons?! I believe none of them is a great example of civility... (at least ours isn't). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Fwd: RE: New developer: Antoine Raillon (cab)
On Thu, 2007-22-03 at 08:56 +0100, Christian Heim wrote: > Antoine is joining us from Cormeilles en Parisis, France (yay, french > conspiracy++), where he's currently studying Network & Telecommunications > at Jussieu and ENST (Ecole Nationale Superieure des Telecoms). Noo Its a French invasion! Bienvenu à bord! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 2007-29-04 at 20:36 +0100, Ciaran McCreesh wrote: > On Sun, 29 Apr 2007 21:31:52 +0200 > Marius Mauch <[EMAIL PROTECTED]> wrote: > > An alternative that doesn't rely on autotools would be using > > INSTALL_MASK. > > Doesn't solve the "packages take twice as long to compile as they > should" issue. A combination of passing --disable-static to econf and INSTALL_MASK should do it. That said, having a feature/use flag to enable static library might not be such a good idea (and disable it on packages where static libraries are needed). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash -> libflashsupport
On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote: > Jim Ramsay wrote: > > > > 1) Create a single local USE flag (flashsupport or something) that will > > just pull in this dependency. > > > > 2) Use the same set of USE flags as libflashsupport has, with any of > > them adding libflashsupport to the dep list, since these are all global > > flags and will most likely be enabled for both netscape-flash and > > libflashsupport > > > > I'm personally thinking (1) is the better of the 2 options, but I'd > > like to know if anyone has any other wondrous solutions to this. > > Does/will anything else dep on flashsupport? If not, why not just add > the USE flags to netscape-flash and install libflashsupport as part of > the netscape-flash install instead of a separate package. If its a separate package that will be updated separately, then it doesn't make sense to put it in the separate package and I support option 1. Otherwise, if they'll always be together, then just put it in the same package. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash -> libflashsupport
On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote: > Josh Saddler wrote: > > Jim Ramsay wrote: > > > I suppose I could also propose: > > > > > > 4) netscape-flash just RDEPENDS on libflashsupport all the time. > > > It's certainly not a large library to be added on. > > > > > > > That is a terrible idea. Don't make it "depend" on something that it > > clearly does *not* depend on. Flash works just fine without the > > optional add-ons, and those are *definitely* optional. I've never > > needed libflashsupport and would prefer not seeing useless cruft > > attached to a perfectly working Flash installation. > > Point taken - If you don't want the extra features you don't want > libflashsupport at all. > > I could make it so that if all of the USE flags for libflashsupport are > turned off it doesn't actually install the library at all, just gets > added to the list of installed packages. > > > If you're going to add it to USE, then make sure it's *not* on by > > default, thanks. > > This way it will adhere to your current set of global USE flags. If you > have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install > libflashsupport with the appropriate hooks in it. If they are all > off (either globally or specifically for libflashsupport) you will > just get the same old netscape-flash with no add-ons. > > Is this a worthy compromise? This seems even worse.. I think either having one local use flag in netscape-flash is probably the best solution.. The second best is to have all of the use flags and RDEPEND on flash-support if any is enabled. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash -> libflashsupport
On Fri, 2007-11-05 at 13:19 -0600, Jim Ramsay wrote: > Olivier Crête wrote: > > On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote: > > > Josh Saddler wrote: > > > > Jim Ramsay wrote: > > > > > I suppose I could also propose: > > > > > > > > > > 4) netscape-flash just RDEPENDS on libflashsupport all the time. > > > > > It's certainly not a large library to be added on. > > > > > > > > > > > > > That is a terrible idea. Don't make it "depend" on something that > > > > it clearly does *not* depend on. Flash works just fine without the > > > > optional add-ons, and those are *definitely* optional. I've never > > > > needed libflashsupport and would prefer not seeing useless cruft > > > > attached to a perfectly working Flash installation. > > > > > > Point taken - If you don't want the extra features you don't want > > > libflashsupport at all. > > > > > > I could make it so that if all of the USE flags for libflashsupport > > > are turned off it doesn't actually install the library at all, just > > > gets added to the list of installed packages. > > > > > > > If you're going to add it to USE, then make sure it's *not* on by > > > > default, thanks. > > > > > > This way it will adhere to your current set of global USE flags. If > > > you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will > > > install libflashsupport with the appropriate hooks in it. If they > > > are all off (either globally or specifically for libflashsupport) > > > you will just get the same old netscape-flash with no add-ons. > > > > > > Is this a worthy compromise? > > > > This seems even worse.. I think either having one local use flag in > > netscape-flash is probably the best solution.. The second best is to > > have all of the use flags and RDEPEND on flash-support if any is > > enabled. > > Can you explain what you mean by "even worse"? I think my latest > solution is more correct than any of the others yet proposed. In fact, > here's another small improvement on it: > > Have netscape-flash with IUSE="vanilla" (by default it is off), which > when enabled will not pull in libflashsupport. flashsupport should be disabled by default. I still think you should add a positive use flag to netscape-flash (call it flashsupport or or a combination of esd/ssl/gnutls/etc). > This meets the following goals: > > 1) It makes it easy for "regular" users to get netscape-flash with any > additions required by any global USE flags in exactly one step: > - emerge netscape-flash > This is my #1 goal, otherwise I'd just have 'libflashsupport' as its > own separate package and those "in the know" would install it > separately if they want any of the extra features. But users should not > have to have special knowledge to get the features they have already > enabled in their global USE flags. > > 2) It makes it easy for "power" users to not have libflashsupport > actually install anything by disabling all the USE flags. This will > take 3 steps: > - Notice at upgrade or install time that there's this new 'extra' > package being installed > - Enable the 'vanilla' flag for netscape-flash > - Continue with upgrade or install > > Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off > for libflashsupport will have the effect of not actually installing the > library, so the only added cost there is one more entry in the list of > installed packages, which I hope you will agree is basically zero. Installing a package without really installing it is EVIL. The db should represent whats installed on the system, otherwise it will become very very confusion for users. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash -> libflashsupport
On Fri, 2007-11-05 at 13:52 -0600, Jim Ramsay wrote: > Thomas Rösner wrote: > > Jim Ramsay wrote: > > > [snip] > > > Have netscape-flash with IUSE="vanilla" (by default it is off), > > > which when enabled will not pull in libflashsupport. > > > > > > > I don't quite see why this is necessary? Or why you do have this > > discussion? > > I started this discussion to find out the best way to add > libflashsupport to netscape-flash for users who want the extra features > that it offers. > > > > This meets the following goals: > > > > > > 1) It makes it easy for "regular" users to get netscape-flash with > > > any additions required by any global USE flags in exactly one step: > > > - emerge netscape-flash > > > > > > > So, in netscape-flash: > > RDEPEND=" > > ssl? ( foo/libflashsupport ) > > pulseaudio? ( foo/libflashsupport ) > > esd? ( foo/libflashsupport ) > > oss? ( foo/libflashsupport ) > > " > > and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as > > already said, has it's own ebuild)? > > Yes, I considered this, it is option (2) in the original post in this > thread. However, I do not believe this is the best solution. Consider > the case where: > - A user has 'ssl' disabled globally > - A user sees that netscape-flash now has 'ssl' support, so he/she > enables 'ssl' just for the netscape-flash ebuild. > - The ebuild would then install libflashsupport, but do so without > actually adding ssl support, which would be quite frustrating to the > user, and probably generate unnedded bug traffic. > > It would be much more clear to only use the ssl USE flag when it > actually affects ssl support. The solution to this is use-based deps.. The short term workaround is to use built_with_use. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 00:47 -0400, Mike Frysinger wrote: > there are many files out there that contain critical information about your > system ... > however, there are certainly cases where the admin fully knows what they're > doing and they want to create a binary package of their system with these > sensitive files ... so where to meet in the middle. > any other potential ideas ? (pretend my idea here isnt the greatest thing > since Robot Chicken) I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote: > On Wed, 20 Jun 2007 16:27:27 -0400 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > being able to generate binary packages that actually reflect the live > > $ROOT is desirable > > Is being able to generate redistributable binary packages that reflect > the live ROOT desirable? Yes, it is, if you want to redistribute them to trusted parties (like other computers you own). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: > On Wednesday 20 June 2007, Ciaran McCreesh wrote: > > On Wed, 20 Jun 2007 16:54:34 -0400 > > > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > On Wednesday 20 June 2007, Ciaran McCreesh wrote: > > > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > > being able to generate binary packages that actually reflect the > > > > > live $ROOT is desirable > > > > > > > > Is being able to generate redistributable binary packages that > > > > reflect the live ROOT desirable? > > > > > > that's a feature that exists now that there's no reason to > > > disable ... not that it can be disabled > > > > I'm not suggesting forcibly disabling it, merely marking binary > > packages as "designed for distribution" or "not designed for > > distribution", not accepting the latter on other systems and > > requiring explicit user action to turn the latter into the former. > > > > The specific underlying question being, what are the use cases for > > binary packages? > > the use of the binpkg is not an issue, it's the creation ... people blindly > creating tbz2's which could contain their sensitive files and posting them > > i'll just go ahead with the feedback from Olivier and have quickpkg skip > CONFIG_PROTECT by default This will by default create potentially broken packages (since many just wont work without their CONFIG_PROTECTed files). That's why I suggested a big fat warning and accepting that we can't protect users against themselves or against social engineering (aka their own stupidity). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 18:28 -0400, Mike Frysinger wrote: > On Wednesday 20 June 2007, Olivier Crête wrote: > > On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: > > > the use of the binpkg is not an issue, it's the creation ... people > > > blindly creating tbz2's which could contain their sensitive files and > > > posting them > > > > > > i'll just go ahead with the feedback from Olivier and have quickpkg skip > > > CONFIG_PROTECT by default > > > > This will by default create potentially broken packages (since many just > > wont work without their CONFIG_PROTECTed files). That's why I suggested > > a big fat warning and accepting that we can't protect users against > > themselves or against social engineering (aka their own stupidity). > > i think this would only be an issue where quickpkg is being run > non-interactively and the output not being reviewed (which i also dont think > is a common scenario for quickpkg) ... the new output of quickpkg will be > explicit in what it is (or isnt) doing so there wont be any issue of "drive > by" social engineering Well, I often use quickpkg when I want to try a new version of a package (I quickpkg the currently installed one.. and I want to keep all the config files). Then I emerge the new one, and I absolutely want to be able to restore the config files if I want to revert to an older version, either because they have been broken by the pkg_postinst or something else. I still haven't heard a good reason to change anything thats not the printing in quickpkg. > as for dubbing people who are successfully socially engineered "stupid", i > dont really think that's appropriate ... consider noobs on irc in #gentoo who > just want to help and havent learned their way around yet. are they stupid > (well they might be, but lets give them the benefit of the doubt) ? i'd > liken the situation to a kid growing up ... kids arent stupid, they lack > experience and calling them stupid isnt constructive I'm not calling anyone stupid... but I'm talking of our inner stupidity (which we all have)... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> Paul de Vrieze wrote:
> > There are various problems that need to be addressed for cross development
> > and
> > (especially) multilib/abi. One of the other ones that you didn't mention is
> > some kind of subpackage support. For example when one installs 32 bit gtk+
> > to
> > use binary firefox on an 64bit system it can share the headers and docs
> > etc.
> > with the 64 bit version. Removing either of them must however still
> > preserve
> > those files.
>
> A quick and dirty way implies that:
> - only the "main" abi can install stuff /usr/
The secondary need to be able to install into their /usr/${libdir} ..
its actually the only place where stuff from the non-main abis should be
imho.
> - includes live in their /usr/$arch/include/
> - docs may live /usr/$arch/usr/share/doc/ or just be suppressed.
>
> lu
>
> --
>
> Luca Barbato
>
> Gentoo/linux Gentoo/PPC
> http://dev.gentoo.org/~lu_zero
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Wed, 2007-04-07 at 22:11 +1000, Paul de Vrieze wrote:
> On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
> > On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> > > Paul de Vrieze wrote:
> > > > There are various problems that need to be addressed for cross
> > > > development and (especially) multilib/abi. One of the other ones that
> > > > you didn't mention is some kind of subpackage support. For example when
> > > > one installs 32 bit gtk+ to use binary firefox on an 64bit system it
> > > > can share the headers and docs etc. with the 64 bit version. Removing
> > > > either of them must however still preserve those files.
> > >
> > > A quick and dirty way implies that:
> > > - only the "main" abi can install stuff /usr/
> >
> > The secondary need to be able to install into their /usr/${libdir} ..
> > its actually the only place where stuff from the non-main abis should be
> > imho.
>
> If one requires synchronized versions, there should in 99% of the cases not
> be
> any issue with header files and documentation. It will be equal, so can be
> shared. It might indeed be an option to require the "main" abi to be always
> present.
I really don't see how it can be made to work in a generic wait without
requiring that all sub-arches use the same version as the main arch and
without requiring that the main arch be installed (if we were a binary
distro, we could do a common package and a bunch of sub-packages, but
now we can't).
> Paul
> ps. for include headers it is rather straightforward to make forwarding
> headers with architecture dependent redirects (using the architecture
> defines) in case the headers are not arch independent.
In theory, headers in /usr/include should be arch independant. You if
you at glib, it installs its arch dependant header in /usr/lib
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] ML changes
On Thu, 2007-12-07 at 13:24 -0700, Mike Doty wrote: > We're going to change the -dev mailing list from completely open to where only > devs can post, but any dev could moderate a non-dev post. devs who moderate > in > bad posts will be subject to moderation themselves. in addition the > gentoo-project list will be created to take over what -dev frequently becomes. > there is no requirement to be on this new list. What are the proposed guidelines for the different between -project and -dev? What goes where? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/pidgin protocols
On Thu, 2007-19-07 at 15:22 -0700, Chris Gianelloni wrote: > On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote: > > I'm all for doing it now in the profile, but it's not my package. > > Perhaps someone from the net-im herd can make this decision? > > Well, as someone who spends a lot of time working on/with profiles, I > say go for it. Since these changes would only affect the one package > and wouldn't pull in any "strange" dependencies on people, we should > probably do it as high in the profile structure as possible (base? > default-linux?) so it hits the most users. > > I'd like to hear from net-im, as they're ultimately responsible, but I > don't really see the harm in doing it, so we probably should as it will > reduce headaches for our users. Talking with my net-im hat, I'd say go for it.. Except for silc and zephyr (which may or may not work very well) and should probably stay off. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/pidgin protocols
On Fri, 2007-20-07 at 00:57 +0100, Olivier Crête wrote: > On Thu, 2007-19-07 at 15:22 -0700, Chris Gianelloni wrote: > > On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote: > > > I'm all for doing it now in the profile, but it's not my package. > > > Perhaps someone from the net-im herd can make this decision? > > > > Well, as someone who spends a lot of time working on/with profiles, I > > say go for it. Since these changes would only affect the one package > > and wouldn't pull in any "strange" dependencies on people, we should > > probably do it as high in the profile structure as possible (base? > > default-linux?) so it hits the most users. > > > > I'd like to hear from net-im, as they're ultimately responsible, but I > > don't really see the harm in doing it, so we probably should as it will > > reduce headaches for our users. > > Talking with my net-im hat, I'd say go for it.. Except for silc and > zephyr (which may or may not work very well) and should probably stay > off. Again with my net-im hat, I've removed the MSN use flag from net-im/pidgin-2.0.2 (the latest version). The other protocols are rarely used and have nasty dependencies and will stay as use flags. I consider this discussion closed. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: net-im/pidgin protocols
On Fri, 2007-20-07 at 14:40 -0700, Chris Gianelloni wrote: > Anyway, if nobody objects and nobody beats me to it, I'll add the USE > flags for the common protocols to package.use in the profiles. Now, the > real question is what should I enable? All of the ones that have no major dependencies are enabled by default and have been for a while... The other should really stay off by default. I don't think adding it them to the profiles is wise.. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 14:10 +0100, Roy Marples wrote: > OK, so whilst we're gearing up for hopefully the last baselayout-2 > release candidate I thought I would pose to the list a question I've > been struggling with for some time. > > Should hotplugged services affect dependencies by default? > (Note, this is not about enabling hotplugged services by default which > is another topic for debate. Want to talk about that, start a new thread > - but save your breath as I have a laptop and think hotplugging is > good :P) > > By default we've always been YES. But I'm starting now that this should > be NO. I believe services that don't bind to a specific address should probably only depend on net.lo, not net. So then we separate this that really need the network (and probably only a specific interface and then the user should modify the script to depend on that interface) and those that use the network, but don't really need it (like sshd, etc). That said, I now use networkmanager (to be able to easily select wifi networks), I don't know how integrated into the whole baselayout-2. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 15:02 +0100, Roy Marples wrote: > On Wed, 2007-08-15 at 10:09 -0400, Olivier Crête wrote: > > I believe services that don't bind to a specific address should probably > > only depend on net.lo, not net. > > Well, they can actually depend on a specific net service too. > For example, I have this on my home server in /etc/conf.d/lighttpd > RC_NEED="net.vpn" > > You can add those RC_NEED/USE/AFTER/BEFORE directives to any conf.d/ > file and it will append to the stuff in the init script. If you can do that, then well, everything else should just depend on net.lo (and not wait for service plugging then). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Status of xcb
On Wed, 2007-22-08 at 05:58 +0200, Hanno Böck wrote: > Hi, > > With compiz 0.5.4, we get the first version that depends on xcb. > While we still have an open bug asking for use-masking xcb > https://bugs.gentoo.org/show_bug.cgi?id=174434 > I'd like to open the question just the other way round: When can we make xcb > default? > > And: How should I handle that? We don't have a feature like "mask if use xcb > isn't set", so it most probably means all compiz-versions from now on will be > masked till we have xcb. Can't we just install xcb alongside regular Xlib ? If we can't, I would favor making xcb the default. Its significantly better than the old Xlib. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GPL violations with net-misc/vpnc?
On Fri, 2007-31-08 at 16:31 +0200, Christian Faulhammer wrote: > Alexis Ballier <[EMAIL PROTECTED]>: > > > > While we are not distributing binaries, I could easily add a > > > USE flag to enable it; the user compiles it himself, so it is all > > > fine. But now regard the existence of binary hosts, are they > > > distributions of then illegal binaries? > > isn't bindist useflag made for this purpose ? > > Great. Thanks...so what is common practice? Should the ebuild die, > telling people a feature will not be included or just exclude it with > an ewarn only? With bindist, you should just disable any non-distributable feature and print a ewarn.. Dieing is not nice since its used to build the stages, etc. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/centericq needs a new maintainer
On Sat, 2007-13-01 at 15:39 -0500, Olivier Crête wrote: > On Tue, 2007-09-01 at 09:35 +0100, Sune Kloppenborg Jeppesen wrote: > > net-im/centericq is without an ebuild maintainer and has an open security > > bug > > #160793 > > > > https://bugs.gentoo.org/show_bug.cgi?id=160793 > > > > Anyone willing to take care of this package in the future, please update > > metadata.xml and CC yourself on the bug. > > Its also unmaintained upstream and is showing its age. > Its now masked and will be removed in 30 days if no one comes forward, > and becomes a new quasi-upstream. net-im/centericq has now been removed from the tree. Replacements include centerim and finch (pidgin with ncurses use flag) -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Bugzilla improvements
On Wed, 2007-26-09 at 19:04 -0700, Robin H. Johnson wrote: > I went and processed a bunch of pending Bugzilla bugs, and thought folk > might be interested in the changes. > > - "Do not reply" note at the top of bugmail, and a related Reply-To > header. [Bug #181172] Is this really required? It pushes the real content even farther down the window. Or if you really want to keep it for new users, please allow us to disable that. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new-style virtual/editor
On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote: > How many packages depend on virtual/editor? Should it be a virtual at > all? !rdep virtual/editor virtual/editor <- app-admin/sudo sys-process/fcron I think the answer is none that really should, I would favor just removing virtual/editor. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new-style virtual/editor
On Fri, 2007-05-10 at 20:27 +0100, Stephen Bennett wrote: > On Fri, 5 Oct 2007 11:46:29 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > How many packages depend on virtual/editor? Should it be a virtual at > > all? > > The system set depends on it, and last I knew didn't allow for any-of > deps. Does it really depend on it ? Or is it just a convenient dep so its installed as part of the stage1 ? Why not just put nano in the system (which is was gets pulled into the stages anyway). I see that both sudo and fcron, while they have some versions that depend on virtual/editor actually hardcode nano as the default. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Quick last rites for x11-plugins/gaim-libnotify
Two days ago, I removed the beta versions of gaim 2.x, gaim-libnotify depended on it. It has never been So it has been removed from the tree. It is now called x11-plugins/pidgin-libnotify. The rest of gaim will soon follow -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites for sys-auth/pam_keyring
# Olivier Crete <[EMAIL PROTECTED]> (20 Nov 2007) # There is now a better version include in gnome-base/gnome-keyring sys-auth/pam_keyring It will be gone in one month. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-im/gaim and its plugins
net-im/gaim is now called pidgin, I've masked it and all of its plugins, it will be removed in 30 days # Olivier Crete <[EMAIL PROTECTED]> (08 Dec 2007) # Remove gaim and its plugins (now its called pidgin) net-im/gaim app-accessibility/festival-gaim net-im/gaim-blogger net-im/gaim-bnet net-im/gaim-meanwhile net-im/gaim-snpp x11-plugins/autoprofile x11-plugins/bangexec x11-plugins/gaim-assistant x11-plugins/gaim-encryption x11-plugins/gaim-extprefs x11-plugins/gaim-galago x11-plugins/gaim-hotkeys x11-plugins/gaim-latex x11-plugins/gaim-otr x11-plugins/gaim-rhythmbox x11-plugins/gaim-slashexec x11-plugins/gaim-xfire x11-plugins/gaimosd x11-plugins/ignorance x11-themes/gaim-smileys -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Keyword amd64 -> x86_64
On Thu, 2008-02-21 at 16:27 +1100, Andrew Cowie wrote: > On Wed, 2008-02-20 at 19:42 -0600, Ryan Hill wrote: > > But I agree, rekeywording amd64 to x86_64 would probably be more work than > > it's > > worth. > > Can we not just hardwire an alias into the emerge codebase? > > I must admit, from a purely optical standpoint, the idea of saying my > system is "amd64" when it is nothing of the sort really grates. If, > internally, it just translated "x86_64" to "amd64" wouldn't that be ok? I really don't see the problem with AMD64, why it would be more wrong than ia32 or x86 (based on Intel's product numbers!). AMD64 was invented by AMD and they get to pick the name for it. The keyword amd64 in Gentoo when Intel was still dismissing AMD64... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 2009-09-19 at 12:21 -0500, Dale wrote: > Dirkjan Ochtman wrote: > > On Sat, Sep 19, 2009 at 19:06, Alex Legler wrote: > > > >> What is the point of stabilizing it if users shouldn't use it as main > >> interpreter? Just leave it in ~arch until it can be safely used. > >> > > > > Making it easily available so that people can port stuff, so that the > > entire world may be able to use it as their main interpreter sooner? > > > > Seriously, it's out there, there's no reason to keep it from stable. > > Just prevent people from making python invoke 3.x and everything will > > be fine. > > Isn't ~arch supposed to be for testing? Isn't that the point of having > ~arch? ~arch is for testing ebuilds, not the upstream package -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New global USE flag: introspection
On Sun, 2010-06-20 at 20:12 +0530, Arun Raghavan wrote: > I'd like to propose a new global USE-flag: introspection. ... > Any objections? I'll wait till Wed (June 23rd) before adding this if > there aren't any. Do we really want it to be a USE flag ? I would force it on always for everyone. Due to the direction in which GNOME is heading, it will be required by the core desktop anyway. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: New global USE flag: introspection
On Mon, 2010-06-21 at 09:07 +, Duncan wrote: > Paweł Hajdan, Jr. posted on Mon, 21 Jun 2010 09:04:03 +0200 as excerpted: > > > On 6/21/10 8:53 AM, Arun Raghavan wrote: > >> On 21 June 2010 11:43, Alexis Ballier wrote: > > >>>> introspection: Add gobject-introspection support, allowing for the > >>>> dynamic generation of bindings for various languages > > >>> gobject-introspection ? > > >> exceedingly verbose > > > "introspection" is similarly too general. > > gobj-bindings ? > > Bindings is a common enough term in use flag descriptions, etc, that users > should at least have an idea what it means. Introspection? Not so much. It's not the bindings... It's introspection data that describes the API. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New global USE flag: introspection
On Mon, 2010-06-21 at 09:33 +0200, Maciej Mrozowski wrote: > On Sunday 20 of June 2010 16:42:58 Arun Raghavan wrote: > > Hi folks, > > I'd like to propose a new global USE-flag: introspection. > > > > The purpose of the flag is to enable the building of GIR for the > > package using dev-libs/gobject-introspection. gobject-introspection is > > going to be quite important in upcoming GNOME releases, allowing for > > the automated generation of bindings for several languages. > > > > We already have 13 packages using this flag, with several more to > > come. The current description being used in packages' metadata.xml > > sucks - I'll put something more descriptive in the final flag. > > > > Any objections? I'll wait till Wed (June 23rd) before adding this if > > there aren't any. > > I don't mind adding it as globally recognizable USE flag, I'd mind however > having it enabled by default in desktop/base profile. If Gnome needs it, > please enable it in gnome subprofile if you wish (apart from setting all > required USE deps in ebuilds), you can also use IUSE defaults for it which > would allow more fine grained control or if you or Gnome devs decided to drop > the idea at some point. Oh no! You'll have two small data files for each package! That's so terrible! You should definitely look through /usr/share, there are lots of other files you dont absolutely need too. Maybe you should start filing bugs against every package that install these tiny files you don't need! All those wasted inodes! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote: > On 04/13/2010 01:25 PM, Peter Volkov wrote: > > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: > >> * It makes zero sense to manually manage ChangeLogs in git[1] > > > > Once I had stupid cut&paste mistake and entered wrong credits in > > ChangeLog. I don't see how to resolve this issue in case ChangeLog's > > will be generated from git log and until somebody suggests how to edit > > ChangeLogs generated from git I think have to keep ChangeLogs in > > gentoo-x86. > > > > We could abuse git-note Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Fri, 2010-06-25 at 13:00 +0400, Peter Volkov wrote: > В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет: > > On 25 June 2010 14:15, Peter Volkov wrote: > > > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: > > [...] > > >> Or you could review the changes before pushing (since in git these > > >> operations are separate). And live with the consequences of your > > >> mistakes! > > > > > > No. We are humans and thus mistakes are unavoidable. > > > > He didn't say don't make mistakes. He said, be careful and if mistakes > > happen, so be it. > > And I disagreed. This is unacceptable since we are talking about credits > to our users. It's like paying salary to random person and blaming tools > after that. You can just make a new commit with just a message saying "Hey, last time I was wrong, this is from A, not B" if you care enough. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: > Moreover, slow arches introduce another problem as well. If a package is > marked stabled for their arch, but this package is quite old, and they fail to > stabilize a new version, we ( as maintainers ) can't drop the very old > ( and obsolete ) version of this package because we somehow will break > the stable tree for these arches. How should we act in this case? > Keep the old version around forever just to say that "hey, they do have > a stable version for our exotic arch". I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:54 +0300, Markos Chandras wrote: > On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote: > > On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: > > > Moreover, slow arches introduce another problem as well. If a package is > > > marked stabled for their arch, but this package is quite old, and they > > > fail to > > > stabilize a new version, we ( as maintainers ) can't drop the very old > > > ( and obsolete ) version of this package because we somehow will break > > > the stable tree for these arches. How should we act in this case? > > > Keep the old version around forever just to say that "hey, they do have > > > a stable version for our exotic arch". > > > > I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then > > just drop the old ebuild. These arches will slowly lose stable keywords > > until their stable tree gets to a size that they can manage. And > > everyone will be winners. That said, when dropping the old keywords, you > > have to be careful to drop the stable keyword on all dependencies too so > > as to not drop break the tree for them. > > > When dropping an old *stable* ebuild, which in most cases this will be the > only stable ebuild that these arches will have for this packages, the > next world update will be ugly since there will be no *stable * > candidates for that package anymore. In this case, stable users will > start filling package.keywords leading to ~testing migration. So I am > not sure if this is the correct approach to deal with this but I can't > think of anything else That's ok. That way those users will know that no one from the arch team maintains that packages and they will know it has a lower level of QA. And the users will be able to make a choice. Instead of pretending that it is maintained. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote: > which is trivial to fix and anyone with commit privs could have done. it > certainly doesnt warrant a paniced "the sky is falling" message. I think this is a great occasion to dump our stupid custom crap and switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a brain already dropped our stuff. And the lack of use of modern tools is the reason I don't use Gentoo on my work computer anymore. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Mon, 2010-08-23 at 17:05 +0200, Gilles Dartiguelongue wrote: > Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : > [lots of stuff about bashisms and posix] > > So let's stabilize OpenRC and be done with it, and /then/ we can debate > > where we want to go from there. > > > > YES, let's get it stable. > > However please consider not re-adding bashisms and/or not make it less > POSIX shell compliant than it already is at light speed. It is a great > thing that openrc tries to achieve and allows more use of openrc than > basic desktop/server gentoo usage (think embedded and other distros). > At least one other distro did this move a while ago (debian) and I don't > think they will go back. Seeing they are also moving to a dependency > based init system, they probably could just run a fork of openrc (for > their init scripts are not exactly compatible with what we do). Other distributions are going one step further and are going for shell-free boot. We should follow that lead. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
