[gentoo-dev] package up for grabs (almost everything in the livecd herd)
[I'm resending this, because I never saw it come through last week.] In the olden days, the livecd herd was basically wolf31o2 and covered any packages that releng had a passing interest in, even if not directly used during the release building process. Since wolf31o2 retired over a year ago, many of the packages owned by the livecd herd have basically become unmaintained (except for the ones that I myself have an interest in). If you are interested in any of the below packages, feel free to steal it (and change the maintainer and herd bit in the metadata.xml). app-arch/pbzip2 - We pondered using it at some point to take advantage of all the shiny new multi-proc boxes that releng and its members had laying around app-admin/pwgen - This is used by the LiveCD to generate a random password. It looks like upstream hasn't touched this since it was last bumped in the tree. dev-python/pyparted - Used by the now defunct GLI sys-apps/hwdata-gentoo - Data used by sys-apps/hwsetup sys-apps/hwsetup - Used for hardware (video mostly) detection for LiveCD sys-apps/parted - Required by dev-python/pyparted sys-fs/squashfs-tools - Used by catalyst to create loop image sys-libs/libkudzu - needed by sys-apps/hwsetup -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Regarding Gentoo CDs and accessibility sizes
On 05/25/2009 07:44 PM, Keith Hinton wrote: Hello, I'm afraidd I'm not seeing the size issues. Adding Speech to a LiveCD should not effect the operations of the minimal installation CDs that much. However, one thing I would suggest is to please be aware of two things: 1. Make sure that some boot prompt exists for users to activate the LiveCD speech output. I.e. Gentoo speech That kind of thing. 2. Lynx and other browsers with Speakup usually need some configuration, along with Irssi. You can't just open Irssi right off the shelf and expect speech-access to it. Why do you keep creating new threads just to interject your random opinion about some other existing thread? Have you ever participated in a mailing list? This isn't IM/IRC. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] rfc: Accessibility on our release media
On 05/23/2009 05:56 PM, Mounir Lamouri wrote: William Hubbs wrote: [snip] My question for the group is, how do you feel about speech software being on our minimal cd as well as our live cd? I agree, it should be in our minimal and live CD's. There is no reason to consider blind persons out of the minimal CD. The real issue here is the size. If these additional packages plus all of the alsa modules add 20MB to the minimal CD, it's just not worth it. It's not minimal anymore. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Andrew D Kirch wrote: I think it's best as a general rule to NEVER _EVER_ under any circumstances emulate paludis. While I'm not personally a fan of paludis, it doesn't help anyone to post crap like that to any mailing list. Please take it elsewhere. Thanks. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Brian Harring wrote: 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes included). - expanding on the first, auto inherits (pkg level) are possible- effectively when eapi gets invoked the manager is in control and can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes, meaning that essentially it won't parse what follows 'eapi 2' till that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. Arguable if -scm is even desired, but being explicit about it not covering this. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option out there- if g54 is forced in, g55 (or at least something that adjusts the extension to make it invisible to current managers) is required. Commentary? Tend to think #4 is the most aesthetically pleasing to folk, but who knows... ~harring I really like this idea, but nobody else seems to have commented on it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.
basile wrote: Point 4 is what I think would be useful to Gentoo mainstream. The speed one gets from RAM totally beats a LiveCD using unionfs which has to periodically return to the slow cdrom. This is already possible. With current genkernel (genkernel- or genkernel-3.4.10.903), you can boot with 'docache unionfs', which will copy the squashfs to tmpfs, mount it, and then use unionfs-fuse to create a union with another tmpfs. Genkernel has offered the 'docache' option for quite a while, which has mostly the safe effect, but without the unionfs, it uses nasty tricks like copying some stuff to a tmpfs and then doing lots of symlinks into the squashfs. Either way, it's entirely memory based after initial boot. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
Cheng Renquan wrote: Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? The file is provided by portage, and the installed location was changed recently to /usr/share/portage/config/make.conf.example. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
Cheng Renquan wrote: On Wed, Jan 21, 2009 at 11:23 AM, Andrew Gaffney agaff...@gentoo.org wrote: Cheng Renquan wrote: Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? The file is provided by portage, and the installed location was changed recently to /usr/share/portage/config/make.conf.example. So then that comment in /etc/make.conf should be fixed? Thanks. I've already made this change in catalyst git, but there is no new release with it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-portage-dev] Time to say goodbye
Marius Mauch wrote: So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. Enjoy your escape. You'll be missed. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?
Andrew Gaffney wrote: Amit Dor-Shifer wrote: Given the following: # qlist -Iv sys-apps/portage sys-apps/portage-2.1.4.5 How do I safely extract the 2.1.4.5? That's probably offtopic for this list, since it really has nothing to do with portage itself. However, you probably want something like: qlist -Iv sys-apps/portage | sed -e 's:^.*-\([0-9][^-_]*\).*$:\1:' And if you want the full version (with RC position and revision): qlist -Iv sys-apps/portage | sed -e 's:^.*-\([0-9].*\)$:\1:' -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] kerberos USE flag
Mart Raudsepp wrote: On Fri, 2008-10-31 at 15:50 -0600, Joe Peterson wrote: Michael Hammer wrote: * Doug Goldstein [EMAIL PROTECTED] [081031 15:53]: If no one opposes, I say we redact this USE flag asap. ++ I was also wondering why kerberos was on by default - I definitely approve of nuking it. I'm believe the primary reason is for release LiveCD's. They ship with evolution-exchange, and that requires evolution/evolution-data-server to be built with USE=kerberos They don't do /etc/portage business, so it's a global USE flag to get things like GRP packages to work right. If that's the case, then I say whack it from global USE and change it to an IUSE default (or whatever is in vogue these days) for eds. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Monthly Gentoo Council Reminder for October
Ciaran McCreesh wrote: On Thu, 09 Oct 2008 12:11:23 -0700 Zac Medico [EMAIL PROTECTED] wrote: I'm guessing it's too late to ask the Council to discuss the EAPI 2 is brokened :( thread? What would be the earliest the Council would be able to make a decision upon that? Unfortunately it's something that could get messy if left for too long. I think that you may be overreacting. The python-2.6 ebuild from bug 240684 is still hard masked in package.mask and I'm doing a sys-apps/portage-2.2_rc12 release today that will fix the problem. What about pkgcore? It's not Gentoo's primary package manager, so it probably doesn't matter if it goes a few days without getting fixed. The worst that happens is a few people get failed builds, right? -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] genkernel support uuid for real_resume
Please submit this through the proper channels (bugzilla). [EMAIL PROTECTED] wrote: This patch add support uuid for real_resume boot option. example: # /boot/grub/menu.lst timeout 30 default 0 color light-gray/bluetitle Gentoo root (hd0,1) kernel /boot/kernel-genkernel-x86-2.6.25-gentoo-r7 real_root=UUID=d5587595-72aa-48e9-a6ba-43daa8e16db1 real_resume=UUID=5f267a01-971a-4440-99aa-04ac28145db1 vga=794 initrd /boot/initramfs-genkernel-x86-2.6.25-gentoo-r7 -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
[gentoo-dev] request for Willikins
At robbat2's request, I'm requesting Willikins's presence in #-server and #-releng. Thanks. My sub to this list is -nomail, so I won't see any replies. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-portage-dev] portage-2.2-rc3 parallel merges quit being parallel
Duncan wrote: --jobs=10 --keep-going --load-average=15 For a dual-dual-core setup, a load average of 4.0 is fully loaded. Anything higher than that and you're just causing jobs to queue up unnecessarily and your system to thrash. have MAKEOPTS=-j -l20 so it's not going to be low all the time). Same thing here. Also, why would you specify different --load-average values in these two places? -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
Re: [gentoo-portage-dev] Connecting source and binary packages.
Jason Cipriani wrote: I have mozilla-firefox-bin installed, but when I update things that depend on firefox (such as epiphany), they attempt to get mozilla-firefox instead. How do I make emerge realize that I already have the binaries installed and don't need the source distribution? This isn't a support forum. Please post this on the gentoo-user mailing list. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev]
Tony wrote: Hi, I am new, but I think I found a problem in thr portage tree, dealing with texlive and tetex. I have a personal overlay, where I changed the dependency in the ebuild from dev-text/tetex to virtual/latex-base. This solved it for the package. I think that the packages will have to transition, because of these conflicts. Also, let me know if this is the right way to do this, and if it is, I suggest you do it soon. (It gets annoying) Don't post without a subject. That's really annoying. Also, this is completely off-topic for this list. Please file a bug at http://bugs.gentoo.org/ -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-dev] renaming of the 'gimli' SVN repo
This email probably isn't necessary, and most people won't care about this. However, sending it was one of robbat2's terms for renaming this SVN repo, so here it is :P The current repo name 'gimli' was the original name of the project a long time ago. The name of the project is now Scire, and we've gotten tired of looking at the old repo name. If you have this repo checked out, you can either check it out again, or use one of the following commands: svn switch --relocate svn+ssh://svn.gentoo.org/var/svnroot/gimli svn+ssh://svn.gentoo.org/var/svnroot/scire (for devs) OR svn switch --relocate http://anonsvn.gentoo.org/repositories/gimli http://anonsvn.gentoo.org/repositories/scire (for users of anonsvn) Thanks. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
userland_* and all other profile-expanded USE flags are magical and arent
available for user consumption. that is how i view IUSE. it was my
understanding that portage was going to get fixed to automatically include
the profile-expanded ones and so adding anything to IUSE now for ebuilds is
dumb when they're just going to get turned around and removed. the same goes
for all implicit/automatic USE expanding things. portage can do this for us,
so having developers track it themselves seems like a waste of time.
-mike
Fair enough, but we need to define a way to automatically include
the profile-expanded ones since none currently exists. One thing
that I don't like about using USE_EXPAND_HIDDEN is that ARCH isn't a
USE_EXPAND. It would have been more consistent if it had been,
along with KERNEL, ELIBC, and USERLAND.
Why not turn it into one? The whole USE=${ARCH} thing is inconsistent with the
USE_EXPANDed KERNEL, ELIBC, AND USERLAND. Yes, I know that it's been around a
lot longer than the others, but that's not a good reason for keeping it the way
it is.
I don't think it would be a difficult transition. Is there any reason that
portage can't set both USE=${ARCH} *and* USE=arch_${ARCH} for a while (until all
ebuilds have been changed to use the new USE_EXPANDed form)? We could even just
have portage set both forms indefinitely (the old form does no harm if nothing
is using it).
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] RFC: replacing packages
Marius Mauch wrote:
On Wed, 24 Oct 2007 13:34:44 -0500
Andrew Gaffney [EMAIL PROTECTED] wrote:
For packages that are in the system set, wouldn't adding the
contents of system.{,r}depend to {,R}DEPEND cause problems in dep
resolution? Would there be a way to prevent the contents of these
files from being added for packages that are themselves in these
files?
Did you miss the part about RESTRICT=system-deps?
I read it before, but didn't register it. Re-reading that sentence in the
context of my question, it makes more sense now :)
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] localization.py
Arfrever Frehtes Taifersar Arahesis wrote: 2007-10-19 17:41:06 Andrew Gaffney napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: Does localization.py exist for a reason? I don't see a localization.py. So you have old Portage. I wouldn't consider 2.1.3.14 old. There is a portage_localization.py, and it's used by portage.py and portage_locks.py. But it could be used by almost all Portage Python modules. Feel free to submit a patch. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] portage.exception.OperationNotPermitted: chown('/var/lib/gentoo/news/news-gentoo.skip', 0, 250)
Please file a bug for this if one doesn't exist already.
Arfrever Frehtes Taifersar Arahesis wrote:
$ emerge -p portage
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-apps/portage-
Traceback (most recent call last):
File /usr/bin/emerge, line 18, in module
retval = _emerge.emerge_main()
File /usr/lib/portage/pym/_emerge/__init__.py, line 6783, in emerge_main
display_news_notification(trees)
File /usr/lib/portage/pym/_emerge/__init__.py, line 4613, in
display_news_notification
portdb, vardb, NEWS_PATH, UNREAD_PATH, repo)
File /usr/lib/portage/pym/_emerge/__init__.py, line 4781, in
checkUpdatedNewsItems
return manager.getUnreadItems( repo_id, update=True )
File /usr/lib/portage/pym/portage/news.py, line 115, in getUnreadItems
self.updateItems(repoid)
File /usr/lib/portage/pym/portage/news.py, line 104, in updateItems
uid=int(self.config[PORTAGE_INST_UID]), gid=portage_gid, mode=0664)
File /usr/lib/portage/pym/portage/util.py, line 594, in apply_permissions
raise OperationNotPermitted(func_call)
portage.exception.OperationNotPermitted:
chown('/var/lib/gentoo/news/news-gentoo.skip', 0, 250)
$
It has happened since r8148.
This bug isn't reproducible when `emerge` is invoked by root.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Latest Gentoo installcd lacks lsusb
Alon Bar-Lev wrote: Hello All, I may be totally wrong here (as usual)... But before I let it go, I think we require some more views regarding this matter. lsusb is not included in latest installcd, I believe that determine available USB devices is important to bootstrap installation, in order to detect network card, ADSL modem, determine which USB mass storage exists and more. Release engineering believes that as there is no dependency of libusb, lsusb should not be provided as it is not required for installation. Ignoring comment#7, bug is available at: https://bugs.gentoo.org/show_bug.cgi?id=195666 If you think lsusb is important or not important for installcd, please help explain why. Seriously, wtf is your problem? Why do you keep challenging the decisions made by release engineering, first on bugs and then on the MLs when you don't get your way? Chris is the head of Release Engineering, which means he gets to make the decisions relevant to the install media. He's been doing it a long time, and there have been very few people that have disagreed with what he does. The install CD is a *minimal* install medium. In very few cases (if any) is it absolutely necessary to be able to identify all USB devices attached to your system in order to do an install. If you are one of the few people who find it absolutely necessary to do so, you're absolutely free to use the LiveCD, which does have lsusb, and if it doesn't, it would be a handy thing to have on there, and you should file bug to have it included on the LiveCD *only*. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer : Mike Pagano (mpagano)
Denis Dupeyron wrote: Yes people, Mike is older than Uncle Seemant, and even older than me. But is he older than nerdboy? Do we have competition for the Crotchety Old Man title? Are we going to hear lots of stories that start with when I was your age? Welcome Mike! -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] NFS oddities
Rumi Szabolcs wrote: Hi! I've got a problem with NFS: This is offtopic for this list. Please take it to gentoo-user, the forums, or #gentoo on freenode. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] stripping out the DO NOT REPLY from bugzie emails
Benno Schulenberg wrote: Robin H. Johnson wrote: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: Please consider lowercasing the first sentence, to stop the yelling, and removing the repetition from the second sentence, which seems to treat the addressee as retarded. Suggested replacement: Well, this really *is* targeting the retarded. There are many people who just don't pay any attention at all and will reply directly to the bugzie email. There's also the people who like to argue with the bug commenter but don't want to do it on the bug (which will make them look like an idiot to *everyone*), so they email the person directly. With this warning, I can completely ignore those retards without feeling bad :) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
[gentoo-dev] stripping out the DO NOT REPLY from bugzie emails
It seems that not everybody loves the new DO NOT REPLY TO THIS EMAIL header at the top of every bugzie email as much as robbat2 does. Because of that, robbat2, KingTaco, and I came up with a procmail recipe that uses sed to filter that new message out of bugzie emails. This has not actually been tested on incoming mails, so it may rape/eat your dog/sister. Enjoy. # Strip out DO NOT REPLY lines from bugzie emails :0 Hfw * ^From: [EMAIL PROTECTED] | sed -e '/^DO NOT REPLY TO THIS EMAIL/,+2d' -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] stripping out the DO NOT REPLY from bugzie emails
Andrew Gaffney wrote: It seems that not everybody loves the new DO NOT REPLY TO THIS EMAIL header at the top of every bugzie email as much as robbat2 does. Because of that, robbat2, KingTaco, and I came up with a procmail recipe that uses sed to filter that new message out of bugzie emails. This has not actually been tested on incoming mails, so it may rape/eat your dog/sister. Enjoy. # Strip out DO NOT REPLY lines from bugzie emails :0 Hfw * ^From: [EMAIL PROTECTED] | sed -e '/^DO NOT REPLY TO THIS EMAIL/,+2d' Okay, I just had it tested in the wild. It works just fine. Double enjoy! -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] SSL-Certificates and CAcert
Hanno Böck wrote: I think compared to self-signed, having cacert-certificates would be a big improvement. Many other free software projects (and more and more other pages) use cacert, so it becomes more and more likely that people will already have the cacert-root-cert installed. How does a CAcert certificate help? Their own certificate for https://www.cacert.org/ can't be verified by Firefox 2.0.0.7, which tells me that their CA isn't trusted by default. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger wrote: we should really rename build to stage1, bootstrap to stage2, and then have catalyst add USE=stage3 during the stage3 step ... that would allow packages to automatically key off of the environment I like this idea (hurray clarity!), but it would add an extra possibly undocumented step for a user to build a system from stage1 (since we don't support stage[12]-stage3 anymore). It would also cause whichever packages that use the 'stage3' flag to be needlessly rebuilt with the first 'emerge -uDN world'. Personally, I don't see either of these relatively minor issues as show stoppers. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Why isn't /root/.bash_profile in the stage tarballs?
Steve Long wrote:
Great. What exactly? How does fulfilling the user requirement with vapier's
solution mess up catalyst?
This is the the first time I've heard of a user requesting this change. It seems
to me that many people prefer to *not* have a .bash{rc,_profile} in /root, which
is the way it's always been. Why not just add the ability to copy these files
with 'emerge --config' to certain ebuilds, and then add a note to the handbook
telling users to run the command if they want to?
Even better, just tell the users to run 'cp -a /etc/skel/* /root/' if they
really want the stuff, and not modify any ebuilds at all?
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote: I didn't say anything about emerge; I was talking about the Stage tarballs. I know, I know: Catalyst uses emerge. But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. Is that really the intention here? To break upstream-defined behavior? First, please don't top-post. Second, you have an odd definition of broken. You seem to have complete glossed over the last part of the sentence that you pasted: if that file exists. Bash will *not* freak out and rape your dog if the file doesn't exist. All it means is that you get nothing more in your env than what's defined by /etc/profile. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote:
On the forums, I've seen the question, Why isn't my .bashrc being
executed when I log in as root but is being executed when I log in as a
normal user?, asked half a dozen times on the forums. Heck, I even
asked it myself a few years ago. Now, two years later, from a slightly
more mature level of domain knowledge, I have to ask why the root cause
shouldn't be addressed. Why can't the simple little default
.bash_profile from /etc/skel be put into /root as well?
When catalyst builds a stage tarball, it doesn't add any additional files. All
files in any stage tarball are created by one of the packages contained within.
In order to do this, a package such as baselayout would have to install the file.
Looking at my local install, it's actually bash that creates
/etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s) of the
bash ebuild (should be the base-system herd) to add that functionality, but I
really doubt you'll convince them.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Last Rites - August 27th - September 2nd 2007
Ryan Hill wrote: Lars Weiler wrote: * Ryan Hill [EMAIL PROTECTED] [07/09/02 17:44 -0600]: plan on doing version-specific masks in the future unless someone can come up with a good argument for it. Slots? That's a good argument. I'm not so sure. The last rites have historically always been for complete removals of a package from the tree. Is there any reason to change it? Just removing an older version of a package from the tree is something that happens all the time. Do we want to clutter up the GWN (as much as it needs content sometimes) with this unimportant information? -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] On my way out....
Gustavo Zacarias wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I resign as gentoo developer. Infra: please remove my accounts. You can't resign! I won't let you! Isn't fmccor the only active dev left on the sparc team? I'm guessing this pretty much means the end of the sparc port for Gentoo. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Luis Medinas wrote: On Fri, 2007-08-03 at 14:28 -0700, Chris Gianelloni wrote: Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Sad to know that our livecd will be xfce based. I think the current live cd gnome based provides a much better environment than xfce and that is good for the users who will preform and instalation. Of course you don't need to build all gnome for the livecd and i bet there will be enough space for another tools (a graphical package manager!?). The main reason that releng has decided to replace gnome with xfce for the LiveCD is space. We (Kugelfang, wolf31o2, and I) had a hell of a time this last release getting the x86/amd64 LiveCDs under 700MB, mostly because many packages (including gnome) grew a bit since the last release. With no differences other than s:gnome-base/gnome:xfce-base/xfce4:, the resulting ISO dropped ~105MB. That's a *lot* of breathing room and a *lot* less headaches for the people building the media. Unless you can magically pull some space out of your butt, don't complain :P -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Samuli Suominen wrote: On Fri, 03 Aug 2007 14:28:26 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: We disabled it to try to get the size of the x86/amd64 LiveCDs down. Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Glad to hear that. Then maybe we could add some stages to livecd? Replace evolution with something usable like claws-mail to do so. The saved space (~105MB with my test build right after 2007.0) would only allow for one stage tarball (the i686 2007.0 stage3 was 103MB, for example), and then we'd be right back where we were with keeping the ISO under 700MB. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Gilles Dartiguelongue wrote: Le samedi 04 août 2007 à 09:08 +0300, Samuli Suominen a écrit : On Fri, 03 Aug 2007 14:28:26 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: We disabled it to try to get the size of the x86/amd64 LiveCDs down. Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Glad to hear that. Then maybe we could add some stages to livecd? Replace evolution with something usable like claws-mail to do so. why would you need a mailer at all on a livecd ? Is the livecd intended to provide a full desktop experience whichever desktop is chosen or is it just provided as a way to have something to do while you are installing and/or tools to fix your install ? if it's not intended to be a full desktop experience (garnome does it very well for gnome afaik) then you could install only gnome-light for a start. The LiveCD is intended to replace the separate GRP and universal CDs when combined with the installer. The installer uses the packages installed on the CD to do the new install. I'm not sure how many times this has been brought up on this list. You people need to pay attention ;) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Gilles Dartiguelongue wrote: Le samedi 04 août 2007 à 16:23 -0500, Andrew Gaffney a écrit : The LiveCD is intended to replace the separate GRP and universal CDs when combined with the installer. The installer uses the packages installed on the CD to do the new install. I'm not sure how many times this has been brought up on this list. You people need to pay attention ;) err, sorry I'm here since 9th june only. I should have check the archives :) I guess I'll let it slide this time, then :) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
Chris Gianelloni wrote: On Thu, 2007-08-02 at 18:53 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. I am very strongly in support of ppds, as I consider it critical for us to make printers easier to set up. This one should be on, actually. It was enabled for 2006.1 but somehow got turned back off for 2007.0's release. We disabled it to try to get the size of the x86/amd64 LiveCDs down. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: 4) What baselayout will be used in the next release? (Maybe that's more of a releng question.) baselayout team just makes baselayout releases. If you mean the LiveCD then ask releng. It'll be whatever version of baselayout is stable at the time we take the initial release snapshot. However, if baselayout-2 will go stable a week after we take the initial snapshot, it would probably be incorporated. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: net-im/pidgin protocols
Eric Polino wrote: If this is truly a problem, then I think the negative USE flags might be the better solution then. This would allow users the ability to disable potential insecure features. But really, I doubt security is an issue here. The negative (or no*) USE flags are generally considered a bad thing. They're icky. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] x86 toolchain changes heads up
Peter Gordon wrote: On Tue, 2007-07-17 at 19:47 -0400, Mike Frysinger wrote: historically, gcc on x86 has always defaulted to i386. some people noticed recently that glibc-2.6 fails to build in this situation as they were only setting -mtune via CFLAGS, not -march. i'll be tweaking gcc so that it will default -march based on your CHOST. so all the i686-* people will now have a default -march=i686 implied in their gcc systems, i586-* people will have -march=i586, etc... keep in mind this is merely the default. -mike Does this mean that any user-set -march flag is overridden for these cases? Just curious. You quoted the answer :) These flags are merely the default. Any user-specified flags will override the default. For example, if you have CFLAGS=-march=i586 with a i686 CHOST, it'd be effectively like calling gcc with 'gcc -march=i686 -march=i586'. The later option would win. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Donnie Berkholz wrote: Matthias Langer wrote: no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. Gentoo's always been exclusively for the developers. Nobody's paying us to do this. It just so happens that the things we want to do also benefit other people, and so they use them. That was my thought as well. We (the developers) owe nothing to the community at large. We are volunteers, and if we want to treat Gentoo as our own personal toy (which we currently aren't), then so be it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Vlastimil Babka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: Donnie Berkholz wrote: Matthias Langer wrote: no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. Gentoo's always been exclusively for the developers. Nobody's paying us to do this. It just so happens that the things we want to do also benefit other people, and so they use them. That was my thought as well. We (the developers) owe nothing to the community at large. We are volunteers, and if we want to treat Gentoo as our own personal toy (which we currently aren't), then so be it. Are you people serious? Let's ban nondevs from bugzilla then? Close #gentoo, disband PR, etc? Not sure if we can keep any sponsors then... You misunderstand. I'm not saying that all non-devs can get bent and their opinions be damned. I'm just saying that at the core, Gentoo is still the same as it was back in the day. Gentoo isn't a commercial distribution, and nobody pays us, so we can do anything we want, whether the user community at large likes it or not. We ultimately answer only to ourselves. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Marius Mauch wrote: I think you're misinterpreting those statements. Consider if you have choose if you spend your time implementing a feature that you personally want to have or one that a user wants (and is of no use to yourself), which one would you choose, assuming that both have the same cost? It's all about priority, nothing more, nothing less. Yep, this is all anyone is trying to say. We aren't paid, so we work on what we feel like working on, and do what we feel like doing (within reason). -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: ML changes
Torsten Veller wrote: * Mike Doty [EMAIL PROTECTED]: 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. What will you do when users start sending mail from dev addresses? There's nothing to prevent that now. That's part of the reason that devs are encouraged to sign their messages to the mailing lists. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
Luca Barbato wrote: Mike Frysinger wrote: get your waaait dont do it votes in now, i plan on pushing: glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86 gcc-4.2.0 ~amd64 ~x86 in the next day or so -mike gcc-4.2.0 won't rape your house and burn your pet anymore? I see they got around to adding the -fno-rape-house-or-burn-pet flag. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Hiatus (sort of)
Paul de Vrieze wrote: On Saturday 31 March 2007, you wrote: Hi all, Me and my wife and son are moving to Australia. We are now waiting for the visa's to arrive, and after that will need some time to set ourselves up. Our computers however are being shipped as we speak and will only arive in australia after roughly 6 weeks. I'm looking to buy a laptop, but connectivity will be problematic anyways. As such I will not be able to contribute as much as I would like. It took a while longer, but I finally have broadband again, and my computers back etc. I'll first be catching up on the email, but I'm back in action again. Now from Hobart, Tasmania (Australia) Welcome back! -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Mike Frysinger wrote: any other potential ideas ? (pretend my idea here isnt the greatest thing since Robot Chicken) Lies...nothing is better than Robot Chicken! -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:07:07 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: no reason to write off something critical like this when it can be addressed It can be addressed by banning binary package creation off an installed filesystem. I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. I use FEATURES=buildpkg myself, so I've always got that backup. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:19:46 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. Then live-filesystem-generated packages could be marked as 'not for redistribution'. That's certainly a lot more feasible. However, it would have to be marked in some way that portage would recognize, and that marking could still likely be easily removed. This still allows the social engineering attack. Someone can get a binpkg created with quickpkg of someone else's baselayout and then remove the marking that would make portage gripe. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: QA issue: No stable skype in Tree
Chris Gianelloni wrote: If the Gentoo developers as a whole decided to dedicate this list to pink ponies, we can. Are pretty purple ponies acceptable as well? -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Fact Injection
Kumba wrote: Anyways, we're off the crab guys. Really. We're pulling in blank pots, the crew is getting restless, and we're almost out of coffee and nicotine. Let's get our heads on straight, our asses in gear, fill our tanks and get back to port so we can get paid and go home. I wonder how many people are going to get that reference :) -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: Retiring (Was Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2)
Chris Gianelloni wrote: Jason, If you leave, the plants win. That has just made my day. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-05-13 23h59 UTC
Enrico Weigelt wrote: * Robin H. Johnson [EMAIL PROTECTED] schrieb: Hi, www-misc/nscache2007-05-07 18:41:07 armin76 www-misc/nsopenssl 2007-05-07 18:41:07 armin76 www-misc/nssha1 2007-05-07 18:41:07 armin76 www-misc/nsxml 2007-05-07 18:41:07 armin76 what did these packages do ? Sounds like mozilla stuff. Am I correct ? I'm pretty certain a few simple google searches would answer this question for you. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Announcing GLI (the installer) 0.5
The Gentoo Linux Installer team would like to announce version 0.5[.4] (we've found a few bugs since the initial 0.5 release) of the installer. This release, which is available on the 2007.0 x86 and amd64 LiveCD/DVDs, has a lot of changes from the previous one (so many that it really should have been a new major version, but we haven't even reached 1.0 yet, so it's a bit hard to jump to 2.0). The major change is that the installer is now interactive, so instead of configuring everything and then letting the install go, it acts more like every other installer that has ever existed. If you're looking for something to do automated installs, check out the installer's sister project, Quickstart at http://dev.gentoo.org/~agaffney/quickstart.php. As always, there are many improvements (and bugfixes) since the last version. * Yet Another Partitioning Code Overhaul: partitioning is now done in real time, so all of the problems that affected previous installer versions are now gone. It is completely and absolutely safe. The worst it can do is mess up when deleting a partition you wanted to delete or creating a new partition, neither of which will result in data loss. * GTK+ frontend redesign: most of the screens have been redesigned from the ground up to go along with the new real-time functionality of the installer. The content of the screens is drawn dynamically as you reach the screen, instead of just disabling elements that don't apply anymore due to previous decisions. This makes the interface seem a lot less clunky. We also have some cool new graphics for the splash screen and banner image thanks to blackace. * GTK+ frontend allows you to choose from 3 modes: Networkless, Standard, and Advanced. * GRP mode is now only available in Networkless mode. * When existing prematurely from the installer, it will offer to clean up after itself (unmount partitions, move logfiles, etc.) * Dialog frontend has been given an overhaul and now has complete i18n support along with 5 translations. * CLI frontend fixup: the non-interactive CLI frontend has been fixed up. It can be used to do automated installs with GLI if you create an install profile by hand if you pre-partition or use the recommended partition layout. As always with improvements, there are new bugs created to go along with them. If you do encounter a bug, make sure to save your /tmp/installprofile.xml and /var/log/installer.log.failed from the LiveCD right after the install fails. File a bug at http://bugs.gentoo.org/. Select the Gentoo Release Media product and the Installer component. If you can't find that, just use the following link: http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Release%20Mediacomponent=Installerformat=guided -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Proctors Episode II - Attack of the clones
Roy Bamford wrote: You can see some of our outfits at http://dev.gentoo.org/~mark_alec/photos/Postbusters.jpg amne is pretty hot as a chick -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: 2007.0 release
Thilo Bangert wrote: Chris Gianelloni [EMAIL PROTECTED] said: I'm simply amazed at the level of complete and total bullshit that some people spout off on this list without bothering to check facts or take 3 seconds to talk to the people in the know. If you don't know what you're talking about, rather than open your mouth and prove to everyone that you are clueless about the particular topic, it's probably best to either ask someone or talk about something you're actually familiar with, instead. this seems to come up more often than you like. is this the release tracker bug? http://bugs.gentoo.org/show_bug.cgi?id=156814 It's not exactly a release tracker...more for the release *snapshot*. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Tears of unfathomable sorrow
Alec Warner wrote: Much to the joy of many I am now retiring from Gentoo. I've already done most of the work (sorry to burden you kloeri I think just the tree-bits are left). Not that I didn't see this coming, but I'm still sad to see you go. You'll be missed. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Piotr Jaroszyński wrote: On Sunday 25 of March 2007 16:58:10 Mike Frysinger wrote: Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here not to put anything in your mouth, but I am a little confused: http://article.gmane.org/gmane.linux.gentoo.devel/46648 Support for an alternative package manager != language bindings for said package manager :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
Petteri Räty wrote: Raúl Porcel kirjoitti: Hi, The mozilla team has decided that the www-client/mozilla-firefox[-bin]-1.5* series will get masked two weeks from now (18 Mar 2007), that is *1 April 2007*. *And will be removed after two weeks from that date*, which will be *15 April 2007*. Shouldn't an application as important as Firefox should get the usual month in package.mask? It's not the whole package, just older versions. With most packages, you wouldn't get the notification beforehand that older versions were disappearing. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
Dan Meltzer wrote: This thread is gay. Well played. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
Steve Long wrote: Mike Frysinger wrote: Yay zmedico! Can I just say he's one of the coolest devs on irc that i've run into, and incredibly helpful to all. if you love him so much why dont you marry him ... i hear Massachusetts is OK -mike Jeez i'd expect that off others, not off you. For shame. Thing is that kinda stuff just puts ppl off; i've seen you carry on bugzilla but i always thought fair enough he's stressed and working on loads a bugs; if you really wanted to say that crap to me, you could have emailed me. Wow, somebody took that completely the wrong way. It was nothing more than a joke. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
Andrej Kacian wrote: On Sat, 10 Mar 2007 12:28:29 -0600 Andrew Gaffney [EMAIL PROTECTED] wrote: Thing is that kinda stuff just puts ppl off; i've seen you carry on bugzilla but i always thought fair enough he's stressed and working on loads a bugs; if you really wanted to say that crap to me, you could have emailed me. Wow, somebody took that completely the wrong way. It was nothing more than a joke. This is a fine example of how different people are in perceiving jokes. BTW, I never understood why are certain people so touchy about homosexuality, while others joke about it with their peers daily (and very personally). The people who get all bent out of shape about a simple joke like that are either homosexual themselves (not a bad thing) or homophobes (definitely a bad thing). -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting
Daniel Robbins wrote: I don't understand half of what you said. You are saying that PMS is a sub-project of QA? Is the PMS spec hosted on Gentoo infrastructure? From all I have read, PMS is meant to define the functionality of Paludis itself, which is not a Gentoo project. Because of this, PMS can't be considered a Gentoo project. That may be what it's meant to do now, but that was not the original purpose. It was originally to be a written specification of EAPI=0, which is essentially portage's current functionality. It's only later that the whole PMS == Paludis thing came about. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
Marijn Schouten (hkBst) wrote: I was wondering what is keeping us from releasing a minimal install cd more often than we do now. Isn't almost everything needed for it already in the stable tree and thus tested? And if so isn't it possible to fully automate generation of these cd's? Time and sanity. Sure, it can be built pretty quickly, but there's a bit of testing that needs to go into it before it can be released to the mirrors. Release time is hectic enough, and you want us (releng) to do it more often than bi-annually? Also, what's the point? Everything you use to install from the minimal is fetched from the internet. The only thing that an updated minimal would give us is a slightly more hardware support during the install. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: more up to date minimal install cd
Tiziano Mueller wrote: Marijn Schouten (hkBst) wrote: I was wondering what is keeping us from releasing a minimal install cd more often than we do now. Isn't almost everything needed for it already in the stable tree and thus tested? And if so isn't it possible to fully automate generation of these cd's? I'd rather like to see that the stages are being updated more often. This would certainly make more sense than updating the minimal CD, but the same reasons for not doing apply as for the minimal. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
Simon Stelling wrote: That being said, I think this is really up to the releng team and noone else. They are doing the work, so we can discuss it far and wide, as long as releng doesn't want to do it, nothing will happen. So maybe we should wait for a statement from Chris before doing anything else. I can tell you right now what Chris's answer is going to be. If you're volunteering to do it, join releng and have at it. As it is now, most members of releng do not have the time and/or desire to do a release more often than bi-annually. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
Rémi Cardona wrote: Robin H. Johnson wrote: As opposed to minimal CDs, I would see weekly builds of stage3 tarballs to be much more useful. ++ on that. Rebuilding _everything_ because openssl changed ABI since the last stage3 install could save users a lot of time/trouble. (that was just an example) Weekly, bi-weekly or even monthly stages feel enough for me :) Those could be released as experimental stages. ...which people will still bitch and moan about when broken. People seem to have an unreasonably expectation for everything we release, even if it's experimental, to work perfectly. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Improvement suggestion for emerge: Not using a new connection for every file
Beginner wrote: Hi, I recommend not to use wget and not to reconnect to the server for every single packet, but to hold the connection therefore spare traffic and download more fast. Uhh, what exactly are you talking about? There is very little overhead to reconnecting to a server to download a second file. Also, how often are multiple files downloaded from the same server? Probably not very often. I've heard of people trying to rice their binaries, but ricing your downloads? :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] imagemagick-6.3.0.5 without truetype doesn't compile
Mohammed Hagag wrote: emerging imagemagick-6.3.0.5 without truetype USE flag which depends on propritary corefonts fails with compilation error. File a bug. This list isn't the place to complain about b0rkage in random packages. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] no binaries amarok-1.4.5 !
Mohammed Hagag wrote: amarok-1.4.5 doesn't install any thing except the .po files when emerging without the kde USE flag, is this normal ? File a bug. This list isn't the place to complain about b0rkage in random packages. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd suggestion: religion
Steve Dibb wrote: I'd like to propose a new herd: religion. The herd would take care of Would the non-believers in the group be able to ignore it like we do the real thing? :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New developer: Vic Fryzel (shellsage)
Ryan Hill wrote: Christian Heim wrote: Please welcome Vic as a new fellow developer among us ! Yay! Welcome to Gentoo. Whenever I see shellsage, I always think shell sausage instead of shell wizard :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Somewhat OT - Making a suggestion for games-emulation/tuxnes
Michael Sullivan wrote: I hope this is the right place for this, or at least the right place to No, not really. write/edit ebuilds yet. Do I even submit them to Gentoo's bugzilla, or should I paddle upstream with them? What should I do? This isn't a bug so much as a behavior that you just don't like. Take it up with upstream. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Versioning the tree
Steve Long wrote: There'll always be GLSA's to respond to. That's another issue that needs to be handled w/ a slow-moving tree. Are you going to restrict changes in the slow-moving tree only to changes against a GLSA? That's what we've said. I don't have a problem with this at all. The slow-moving tree isn't; it's a release tree. The only question I have, which Stuart also mentioned, is whether all security updates go thru the GLSA process. Are you asking if all security updates that are done to the release will have gone through the GLSA process? I'd say the answer is yes, since the only updates that will go in the release tree are security updates from GLSAs :P -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
Stuart Herbert wrote: b) Release trees have a nasty habit of picking up last minute changes (such as gcc 4.1) to suit the release, not stability. Gcc 4.1.1 wasn't a last minute change. I can't agree with you there. It doesn't matter how many months of planning and work you guys put into getting gcc-4.1 fit for stable. If you're doing it off in your own little corner of the world, and then springing it on the rest of us just days before the release happens, then to the much larger dev community, it comes as a last minute change. The 3-4 weeks of releng filing a ton of doesn't build with gcc-4.1.1 bugs wasn't a big enough clue? :) Also, the arch teams (or at least the arch's release coordinator...if they didn't tell the rest of their team, that's not releng's fault) that were moving to it and people in base-system working on it were in the know. The release tree isn't really for minimal breakage. But that is what Steve (who started this thread) asked for. And what he has asked for in his previous thread too. Well, wolf31o2 has been floating around this idea for quite a while, and I'm speaking from the POV of his ideas. The minimal b0rkage tree is far less likely to happen due to the extra manpower involved. The *real* intent (at least from my POV) is to have a non-moving target for vendors to certify their software against (wouldn't it be nice for Oracle to be actually supported on Gentoo 2007.0 or something like that?), Well, there's a dichotamy here. Sun were able to certify Gentoo against their hardware without such a tree. Has anyone approached Oracle and asked them what their actual requirements are? Do Oracle actually want to certify Oracle on Gentoo at all? Certifying hardware and software are 2 completely different things. Also, I'm not sure that Sun certifying their hardware even meant anything. The T2000 dev box has been seeing random lockups and other weird problems, although, that may be related to the fact that it recently lost 16GB of memory due to an error detected by the diagnostics. As for the Oracle example, it was just that...an example. and so admins don't have to do the upgrade dance once a week or even every day (like I do). A slower-moving tree will substantially reduce this amount of work, but it isn't going to go away, unless your boxes are on a private network w/ no local security threats at all. There'll always be GLSA's to respond to. That's another issue that needs to be handled w/ a slow-moving tree. Are you going to restrict changes in the slow-moving tree only to changes against a GLSA? Yes, that's part of wolf31o2's idea. The tree would be non-moving except for GLSA's and any dependencies required by the updated version of the security-affected package. The non-stagnant nature of Gentoo isn't the only reason that people use Gentoo. People use Gentoo for the configurability and customizability. As someone who admins more than a handful of Gentoo servers, I would absolutely *love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades easier to deal with. I honestly don't think you're ever going to get that out of Gentoo, because of the lack of backporting. Can you live with a slower-moving tree? Or do you personally really need a non-moving tree? A slower-moving (or non-moving with security updates) tree is perfect for me, and I'm sure for many other people as well. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Versioning the tree
Steve Long wrote: Chris Gianelloni wrote: From your post we need to add: - strip all USE flags that aren't used from use.mask (per-profile) - strip all packages that aren't available from package.mask (per-profile) What language is the script implemented in? The current script is actually 2 scripts: a python script that I wrote that interfaces with the portage API and a bash script that wolf31o2 wrote that takes the output from my script and does the cleanup. Last night, with the help of ferringb, I started working on a replacement script that uses the pkgcore API. The portage-based script takes quite a while to run, and gets it wrong if there are any p.mask'd stable packages on any arch or other weird things. The pkgcore-based script actually uses the profiles properly and runs over the entire tree with all the stable profiles (according to profiles.desc) in 1m1.869s (on my box). I'll probably end up combining the scripts and doing the cleanup in python to make things easier. Wrt security updates, is it possible to tie into GLSAs so that we could automate updating packages that need it? By updating I mean adding the ebuilds and any dependencies (or dependants that might require updating.) I'm not sure this is the best idea. Caleb Cushing wrote: .. isn't it possible only to sync certain parts of the tree using excludes. maybe some additional functionality saying only sync package X for updates. Would that help in terms of having say, up to date GUI packages, or is it just easier to use overlays? Overlays are definitely best here. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
Stuart Herbert wrote: On 11/29/06, Andrew Gaffney [EMAIL PROTECTED] wrote: The 3-4 weeks of releng filing a ton of doesn't build with gcc-4.1.1 bugs wasn't a big enough clue? :) No. We get those all the time; there's always someone trying out an unsupported release of gcc. From other developers, most of which were releng members? Also, the arch teams (or at least the arch's release coordinator...if they didn't tell the rest of their team, that's not releng's fault) that were moving to it and people in base-system working on it were in the know. What about everyone else, who isn't part of an arch team? Sorry, but I just don't get how you expected us to know it was coming, when you didn't announce it, and you don't even feel that an announcement was your (releng's) responsibility (even though stabilisation of gcc-4.1 was for you). It's stupid to blame releng for the stabilization of gcc-4.1.1. It would have been stabilized soon as part of the normal process of package maintenance whether releng wanted it or not. And really, it was up to each arch to say they wanted it for the release, not releng. We didn't force it on people. And as always, if you wanted to know what was going on as part of the release, the info was there for everyone to see in the usual places (such as the gentoo-releng mailing list or the #gentoo-releng IRC channel). This argument about people not knowing what releng is doing seems to come up after every release. It's crap. Yes, that's part of wolf31o2's idea. The tree would be non-moving except for GLSA's and any dependencies required by the updated version of the security-affected package. How are you going to ensure that all the security fixes that never get a GLSA get into the tree? If it doesn't get a GLSA, it doesn't get in the release tree. This may mean that we need to modify the GLSA process a bit so that ~arch packages found to be vulnerable get GLSAs as well. Although, release tree users won't have these ~arch versions anyway, so I don't see it being *that* big of an issue. A slower-moving (or non-moving with security updates) tree is perfect for me, and I'm sure for many other people as well. Before you release these trees to users, I trust you'll be doing the responsible thing, and ensuring that upgrades from one tree to the next work? You can't take that for granted; package maintainers cannot be relied upon to test upgrades spanning that length of time. (Which is why upgrade early, upgrade often is a practical way to manage Gentoo boxes) Absolutely, it would be stupid to release it to users without testing that the upgrade path is even feasible. However, we can't test the upgrade with *all* packages in the tree, but we can certainly do it with certain profiles (gnome desktop, kde desktop, LAMP server, etc.) to try to cover as many bases as possible. This testing can be easily scripted. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Versioning the tree
Stuart Herbert wrote: On 11/29/06, Chris Gianelloni [EMAIL PROTECTED] wrote: As of this release, I kept a copy of all of the distfiles for the entire release, and can make a DVD of it, on request. This fulfills our requirements with the GPL. What are the arrangements should you go under a bus on the way home from work tonight? I believe they're kept on poseidon, which many people have access to. Please stop arguing just for the sake of arguing. Are you trying to become the next ciaranm (no offense to ciaranm :P)? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
Stuart Herbert wrote: Sorry, I've looked, but the only announcement I found on gentoo-dev was posted two days before gcc-4.1 was stabilised [1]. I must have missed the earlier announcement? Do you just ignore the rest of the thread when responding to individual emails? About 2 hours ago, someone posted the following link in this thread in response to your earlier post about gcc-4.1.1 being a last minute change. http://thread.gmane.org/gmane.linux.gentoo.devel/39848 -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
James Potts wrote: This looks good on the surface, Chris, but what happens in the case where somebody wants to use the Release tree, but also wants (or needs) one or more packages from the Live tree, and doesn't want to switch completely over to the live tree? If I understand what you want to do correctly, the Release tree would include only stable packages. Other packages wouldn't just be masked, they would be completely unavailable to anybody using that tree. This is what overlays are for :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
Stuart Herbert wrote: On 11/28/06, Chris Gianelloni [EMAIL PROTECTED] wrote: As I have said, I've mentioned several times the idea of doing a release tree to go along with each release. The release tree is not the basis for this. a) Releases (and the releng work that goes into it) are exclusively desktop-oriented. You make it sound like releng doesn't care at all about non-desktop packages. The reason for the exclusivity is that the media that's typically built for release (GRP, LiveCD) is targetted for the largest audience...desktop users. If someone wants to volunteer to create a set of server-related GRP and a server LiveCD (as silly as this is for most things), they wouldn't be blocked outright. b) Release trees have a nasty habit of picking up last minute changes (such as gcc 4.1) to suit the release, not stability. Gcc 4.1.1 wasn't a last minute change. The release snapshots are originally created a month or more before the actual release. As stuff is stabilized in the tree, it's stabilized in the release snapshot as well. During the release cycle, we planned for gcc-4.1.1 to be stable by release (at least for x86, amd64, and a few other arches). We had it stable in the release snapshot a few weeks before the tree did and were testing the crap out of it. No version changes on any packages, except those which are necessary due to a security violation, or a vulnerable package's dependencies. Tying a minimal-b0rkage tree to the arbitrary schedule of our releases does not serve all of our users. We are back to the same arguments we had when I said that the Seeds project would have to have its own independent release schedules :( The release tree isn't really for minimal breakage. The *real* intent (at least from my POV) is to have a non-moving target for vendors to certify their software against (wouldn't it be nice for Oracle to be actually supported on Gentoo 2007.0 or something like that?), and so admins don't have to do the upgrade dance once a week or even every day (like I do). Thereś little merit in us creating mostly stagnant trees. Other Linux distros are already very good at doing that - far better than we will be at it - because they have advantages such as a paid workforce and more upstream developers on their books. The non-stagnant nature of Gentoo isn't the only reason that people use Gentoo. People use Gentoo for the configurability and customizability. As someone who admins more than a handful of Gentoo servers, I would absolutely *love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades easier to deal with. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Alexander Gabert (pappy) returns from retirement
Lisa Seelye wrote: Wow, welcome back pappy. Does it mean I've been around a long time when I remember his retirement? Well, I remember it, and when I became a dev, you had already been a dev for quiet a while :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: baselayout-1.13 going into ~ARCH soon
Roy Marples wrote: Actually, before I do that, let me attack this from another angle. What do you gain from keeping it mounted as a ramdisk? If the answer is performance, well you loose performance at start time as you've lost the deptree. So why would you want to keep it? read-only nfsroot or any other root that needs to stay read-only -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo list server dropping mail
Chris Gianelloni wrote: Andrea has worked pretty hard on this. He's made some changes that he thinks has solved the problem. If anyone is having issues currently with emails being dropped to the mailing lists, could they please post on bug #141904 so Andrea can look at them? You'll definitely want the msgid of the failed message for him. In that bug, he says he changed some config option but doesn't go into details. Andrea, can you give a brief synopsis of the issue, so that it could possibly help others avoid the same pitfall in the future? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ignoring/overwriting IUSE from an eclass
Ciaran McCreesh wrote: Your solution is approximately on par with fixing a wobbly chair by sawing off all four legs and then attaching what's left to a crocodile. +1 for creativity and making me literally laugh out loud -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
Caleb Cushing wrote: partition limits are decided by the size of the drive and the other partitions on it. really that seems impossible. GLI told me I couldn't have a boot partion smaller than ~50MB it complained about it. and I think I remember it complaining less because I was able to continue ... about having 140GB /home partition it only wanted to make a 20GB partition. but it absolutely would not do 32MB boot partion I have. it was like giving me a negative number, I assumed these are features not bugs. That's not an installer imposed limit. It's a limitation of the slider bar used for choosing the size. I haven't figured out how to decouple it from the entry fields while still making it useful if you want to use it. Patches are welcome. As for the 20GB partition, I have no idea. Perhaps that's a limit imposed by libparted, but it's not a limit that *I* put into the code. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: On Fri, 13 Oct 2006 02:40:59 -0700 Zac Medico [EMAIL PROTECTED] wrote: | At the profile level, I've added support for package.use | which behaves like /etc/portage/package.use that everyone is familiar | with. The intention is that the IUSE defaults will be used for | default flags that should be enabled regardless of profile. Isn't that why we have base profiles? It's kinda icky moving that metadata partially into ebuilds IMO... Are you saying you like a bunch of php-only USE flags (I'm not picking on php...it was just the first that came to mind) being in the default USE in the profile? Do you also like the nofoo flags? AFAIK, previous discussions said that the per-ebuild default USE would go in the USE stacking order above make.conf and below package.use, so that USE=-* wouldn't remove the default USE flags for the particular ebuild but the user could still disable it via package.use if they *really* wanted to. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
Natanael Copa wrote: btw.. I keep hearing about this paladius. Is it more script-friendly than emerge? It's paludis, and no, the API is currently C++ only, afaik. There are ruby bindings in the works, though. The other alternative, pkgcore, has a python API...as does portage itself. None of the options have an interface that's usable via a bash script. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
Wernfried Haas wrote: On Tue, Oct 10, 2006 at 10:13:41AM +, Duncan wrote: Personally, I'd say 686 is the lowest reasonable to support at this point. Below that, try an appropriate binary distribution and save the days/weeks of compiling. Bollocks. I run a print/samba/backup box at work which is a pentium II 400. Compiling glibc takes 3 hours here and while it may not be the Uhh, P2 is i686, which falls squarely into the realm of supported and reasonable :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Simon Stelling wrote: Roy Bamford wrote: Dropping support for x86 i686 is a debate we need to have some time I suppose, its a question of when. There is clearly only a few users, besides myself using systems that old, since there were very few forums posts about the original 2006.1 x86 media not workign on P1 and AMD k6 based systems. I'm sure I'm not the only one who is using a pentium mmx as a router, so you better think twice about it :P But when was the last time you reinstalled it? :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Zac Medico wrote: (of course, please don't use multiple inheritance in the live tree in ways that will hurt users of the current single inheritance profiles). If someone does, can we blame you? :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Danny van Dyk wrote: I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. By 'not standalone', I assume you mean this profile does not work by itself, and is only meant to be inherited by other profiles. If that's not what you meant, we also need something that does that :) profiles +-obsolete, which contains the old cascaded profiles. Let's remove | the current obsolete/ contents. Doing this will break portage for people who are using old cascaded profiles. Portage would freak out if there wasn't a profile where there was one before, and there wouldn't be a way to do a 'deprecated' file to tell them about the new ones. +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like nptl nptlonly here | +-amd64-linux, inherits default-linux/, base/amd64; standalone | +-amd64-hardened, inherits hardened, base/amd64; standalone | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; standalone This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I can't really comment on the structure, since I don't really do much with profiles myself (no gentoo-x86 commit access). I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. Not necessary. It can just be a separate directory tree under profiles/ much like default-linux/ was created for cascaded profiles originally, and they can all be marked as deprecated or something. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
Tim Yamin wrote: I would like to wish all of you the very best, and would like to thank all of you who have (and haven't) made my time here so enjoyable. So long, and thanks for all the fish... I can't say this was unexpected, but I'm sorry to see you go. Are you going to continue to contribute to various projects you've worked on such as gk4? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Zac Medico wrote: Some of you may recall that I proposed the addition of multiple inheritance to profiles a couple of months ago [1]. The idea is to extend the parent file in profiles so that it supports any number of parents (one per line). Parents listed closer to the bottom of the file will have the ability to override the settings of those listed nearer the top of file. As of portage-2.1 (included in the 2006.1 release media), portage will automatically generate an error if it encounters multiple inheritance (earlier versions would simply ignore anything after the first parent). As long as users follow the profile updating instructions [2] and update portage prior to a profile update, they won't have any trouble. However, if a user has =portage-2.0* and fails to follow the upgrade instructions, portage may attempt to build and install packages without the entire profile being correctly parsed. Should we add multiple inheritance support now? The changes necessary to add this support are minimal and we can have this feature in portage-2.1.2 [3], which I estimate will be ready for a final release in approximately 3 to 5 weeks. Are you proposing just adding the support or creating the new profiles as well? If it's just the support, adding it into portage now certainly won't hurt anything (unless someone really fscks up the current single-parent cascaded profiles in the tree) and is probably a good idea. If you're talking about putting together the new profiles now as well, is it going to be a separate profile tree (much as default-linux/ was created for cascaded profiles)? Will it be directly under profiles/? default-linux/? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] treecleaner removals
Alec Warner wrote: stuff gets fixed (aka pornview) Why doesn't this surprise me? :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Delay in approval of new developers
Peter wrote: On Fri, 22 Sep 2006 10:13:23 -0400, Chris Gianelloni wrote: I just want to prefix this by saying that I was simply going to ignore your posts in this thread completely due to your obviously inflammatory nature at the beginning. Now that you're posting actual constructive criticisms, I'd like to respond. By the way, thank you for changing your tone to something more productive. Bunk! Unnecessary to write. Why not just plonk me and be done with it. Nothing I wrote was inflammatory at all. My criticism of the recruitment process stand. Your response was welcome. The prefix was condescending and offensive. You, as leaders, have to really think through what your intentions are and how you are going to deal with people and factions with various objectives. Telling people they are obviously inflammatory is really not a strong way to begin. I believe you just proved his point. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New project: Gentoo Seeds
Donnie Berkholz wrote: Andrew Gaffney wrote: Mike Frysinger wrote: On Wednesday 20 September 2006 12:38, Alec Warner wrote: I think Chris's primary concern is one of Tell us whats up before it happens. why should he care ? some Gentoo guys take catalyst and produce stage4s directed at certain applications He cares because they're basically extending the roll of releng without it being under releng's control. I know I'd be annoyed if they release a x86 stage4 and then *I* gets bugs, but I know absolutely nothing about it. Having 2 projects doing almost the same thing is just going to confuse users. As somebody's already mentioned, the embedded project releases GNAP and has a releng liaison. There's no reason the seeds project couldn't also have a releng liaison, which seems to resolve the main dispute here. That's not the issue. The issue is that there should *already* be a releng liason, but nobody from releng seems to know anything about this project. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
