[gentoo-dev] Timetable for removing digest-* files
As the Manifest 2 format makes the digest-* files unnecessary, does anyone have a timetable for removing the digest files? Would be great if we could make this one of the features of 2007.0. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-video/nvidia-freebsd
# Timothy Redaelli [EMAIL PROTECTED] (09 Jan 2007): # Deprecated by x11-drivers/nvidia-drivers # Pending removal 2007/2/9 media-video/nvidia-freebsd -- Timothy `Drizzt` Redaelli - http://dev.gentoo.org/~drizzt/ FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: OpenPGP digital signature
[gentoo-dev] misc/herds.xml file gone.
Hi all. I just killed the misc/herds.xml file in the gentoo CVS repository so that we only have one copy of herds.xml left now. The remaining copy is in xml/htdocs/proj/en/metastructure/herds. See bug 151324 for the discussion leading to this. I also left a misc/herds.old.xml file pointing to the new location. Hopefully there'll be no more confusion about which copy to update now. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] new eclass: ant-tasks.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've created a new eclass [1] for easier mainenance of new packages which will be created as part of split-ant effort [2]. There will be some 19 packages (dev-java/ant-* except ant-core, ant-tasks and some external tasks like ant-owanttasks) using it, sharing the same distfiles and build logic. Currently they are in a special overlay [3]. I would like to add it to the tree soon, possibly this weekend. [1] https://overlays.gentoo.org/svn/proj/java/split-ant-overlay/eclass/ant-tasks.eclass [2] https://overlays.gentoo.org/proj/java/wiki/Split_Ant [3] https://overlays.gentoo.org/svn/proj/java/split-ant-overlay/dev-java/ Regards, - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo6xntbrAj05h3oQRAo+TAJ9OQlpkXYgR50KfgrmJa5msOEIdiQCfdMtO 6VBobTEOL8e8wTD7qFK3HBc= =GDgH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: sys-apps/pcsc-ase-iiie-drv
Hello, Users that uses the above package should move to: app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb Best Regards, Alon Bar-Lev. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites for games-action/d1x
# Chris Gianelloni [EMAIL PROTECTED] (09 Jan 2007) # This has been dead upstream for close to eternity and is broken with GCC 4.x. # Use games-action/d1x-rebirth instead. This will be removed on (09 Feb 2007). games-action/d1x -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentle reminder about ChangeLog entries on profiles
On Mon, 2007-01-08 at 15:52 -0800, Robin H. Johnson wrote:
I was referring to all of profiles/ in general.
It came to me because antarus was looking for vapier to see why
profiles/lang.desc existed.
I'm thinking that keeping track of the very top level stuff like
thirdpartymirrors, use{,.local}.desc, updates/, desc/ would benefit from
ChangeLogs, for people that have them from rsync, instead of CVS.
Well, I've added a ChangeLog to profiles... If there's any objections
from anyone, they can feel free to remove it, or something.
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] gentoo can't boot
Hi; i am booting gentoo on my Napa machine but it freezes on copying read-write contents to tmpfs. any help? i am using gentoo i686 livecd. with minimal-x86 i am booting fine, but it keeps failing in installer and sometimes decides to shutdown for some reason. Thanks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [gentoo-dev] gentoo can't boot
1. Don't send HTML emails - they just annoy people 2. Try the gentoo-user ml ;) -- -Charlie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo can't boot
On Tue, 2007-01-09 at 11:20 -0800, rami jiossy wrote: Hi; i am booting gentoo on my Napa machine but it freezes on copying read-write contents to tmpfs. any help? i am using gentoo i686 livecd. with minimal-x86 i am booting fine, but it keeps failing in installer and sometimes decides to shutdown for some reason. Thanks There's an installer? Last time I installed Gentoo, all I got was a LiveCD and a link to the handbook. Incidentally, this thread probably belongs on the gentoo-user list. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: Robert Clark (hyakuhei)
It's my pleasure to introduce to you Robert Clark (also known as hyakuhei), our latest addition helping with forensics. Robert is joining from Aberystwyth (that's in Wales, UK). He's currently halfway through his degree (at the University of Wales, Aberystwyth), currently taking part in a one year program with ALICE (no that's not his fiancée, ALICE stands for A Large Ion Collider Experiment operated by CERN in Genève, Switzerland). He's perfectly aware of C/C++, ebuilds and bash scripts, also knows how to work with python. He also has a great interest in information security related stuff (Tavis, look out :)) and spends way to much time on war games servers (his own words!). When he's not sitting in front of his computer, he tries to spend time with his family (only when he's back in England or his fiancée is visiting him in Genève), enjoys shooting others in the rump with arrows ^H^H^H shooting the arrows at the bull's eye and lifting a 1t [1] anvil, ^H^H^H (again) weights. Please welcome Robert as a new fellow developer among us ! [1] http://en.wikipedia.org/wiki/Tonne (Thanks Alec and Joshua) -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timetable for removing digest-* files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: As the Manifest 2 format makes the digest-* files unnecessary, does anyone have a timetable for removing the digest files? Would be great if we could make this one of the features of 2007.0. I think it's still too early. Recall that 2006.1 was the first to to include Manifest 2 support (=sys-apps/portage-2.1). The sooner we eliminate digest-* files, the more false missing digest bug reports we'll get. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) iD8DBQFFpAkW/ejvha5XGaMRAvGkAJ90kap+Q1xO4O3Gay8MEBGr2gbGnQCgw2v4 wCQi1uAkUxYlp6/3fDM2bYo= =Ta7e -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timetable for removing digest-* files
On Tue, 09 Jan 2007 12:12:55 +0200 Petteri Räty [EMAIL PROTECTED] wrote: As the Manifest 2 format makes the digest-* files unnecessary, does anyone have a timetable for removing the digest files? Would be great if we could make this one of the features of 2007.0. Our plan was to disable digest generation in portage-2.1.3 which won't be ready for 2007.0. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Robert Clark (hyakuhei)
On 09/01/07, Christian Heim [EMAIL PROTECTED] wrote: It's my pleasure to introduce to you Robert Clark (also known as hyakuhei), our latest addition helping with forensics. Everyone better read up on securely scrubbing those hard drives ;) Robert is joining from Aberystwyth (that's in Wales, UK). He's currently halfway through his degree (at the University of Wales, Aberystwyth), currently taking part in a one year program with ALICE (no that's not his fiancée, ALICE stands for A Large Ion Collider Experiment operated by CERN in Genève, Switzerland). Mmm, Aberystwyth; land of sea and sheep! He's perfectly aware of C/C++, ebuilds and bash scripts, also knows how to work with python. He also has a great interest in information security related stuff (Tavis, look out :)) and spends way to much time on war games servers (his own words!). Pfft, he's got nothing on Tavis - yet! When he's not sitting in front of his computer, he tries to spend time with his family (only when he's back in England or his fiancée is visiting him in Genève), enjoys shooting others in the rump with arrows ^H^H^H shooting the arrows at the bull's eye and lifting a 1t [1] anvil, ^H^H^H (again) weights. Please welcome Robert as a new fellow developer among us ! Welcome :D Nice to see you got through the forty days of challenges (aka: Quizzes), now it's Pin the Bug on the Newb time. Hereby introducing our resident bug nut, I give you Jakub, with a fresh supply of pins ;) Ciao, Alex -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA checks merged into portage SVN
Alec Warner wrote: Note, the examples above could be improved by prefixing your variables (you don't want global collisions, trust me) So fex KDE_SHOPTS or KDE_OLD_IFS instead of just OLD_IFS. And as Caster pointed out on irc, this is only a problem if a local var won't cut it; a local should work for most cases I think (but not versionator.eclass, which I'm attempting to fix soon). -Alec -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Bug #161045 [1] requests that portage support RESTRICT=sandbox. This is certainly a valid request but a user may wish to reject a package based on certain questionable values of RESTRICT. Examples other than sandbox incude unattended [2] and userpriv [3]. I suggest that we add support for a new incremental variable called ACCEPT_RESTRICT so that a user can accept or reject restrictions. Much like package.keywords, we can also have a package.restrict file located in /etc/portage for per-package settings. Thoughts? [1] http://bugs.gentoo.org/show_bug.cgi?id=161045 [2] http://www.gentoo.org/proj/en/glep/glep-0052.html [3] http://bugs.gentoo.org/show_bug.cgi?id=159876 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) iD8DBQFFpBot/ejvha5XGaMRApz/AJ9EMGSFKUwnZwzYo1TbimLT19hSWQCgqdRD 1cnMmOvVr3/bejMrR6Og+nY= =G2JM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Add LCD_DEVICES to USE_EXPAND
Hi *, both app-misc/lcdproc and app-misc/lcd4linux can use numerous kinds of displays. The device selections are right now handled via environment variables and/or single use flags. I would like to unify possible devices via the USE_EXPAND'ed LCD_DEVICES. Right now, this would contain about 50 devices [1]. Out of these, some common devices should be installed by default (these are considered default by lcdproc upstream, too): LCD_DEVICES=bayrad CFontz CFontz633 curses CwLnx glk lb216 lcdm001 MtxOrb pyramid text This will of course introduce changes in the configurations for lcdproc and lcd4linux users, but I think that it needs to be done and the changes are mostly renaming USE flags and environment variables. If no one objects, I'd like to implement these changes. But there are some questions still open: * Who will add the entries to base/make.defaults? Can I do this? * Should the defaults and the USE_EXPAND entry be in base/ even though both programs do not are not keyworded for all arches? Regards, Robert [1] http://dev.gentoo.org/~rbu/lcd_devices.desc signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Tue, 9 Jan 2007 23:23:55 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico [EMAIL PROTECTED] wrote: | Bug #161045 [1] requests that portage support RESTRICT=sandbox. | This is certainly a valid request but a user may wish to reject a | package based on certain questionable values of RESTRICT. If a RESTRICT value is questionable, it shouldn't be supported or used. Honestly, this strikes me as rather silly and rather dangerous. RESTRICT is not something about which the end user should have to know or care; it should be something entirely between ebuilds and the package manager. And sandbox is not something that should be turned off lightly; making it so easy will only encourage developers to take the nasty way out rather than fixing simple bugs. I agree; it'd be useful to know exactly what is failing the sandbox and why, with the aim of fixing sandbox if it isn't quite up to the job. The only shortcoming I'm aware of in sandbox is bug #135745 (have fopen/open() fail normally if the file does not exist, rather than report a violation). Waiting on azarah to roll a new sandbox version, I think. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
On Wed, 10 Jan 2007 01:15:45 +0100 Robert Buchholz [EMAIL PROTECTED] wrote: | I would like to unify possible devices via the USE_EXPAND'ed | LCD_DEVICES. Right now, this would contain about 50 devices [1]. How standardised is the naming of these devices? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
Ciaran McCreesh schrieb: On Wed, 10 Jan 2007 01:15:45 +0100 Robert Buchholz [EMAIL PROTECTED] wrote: | I would like to unify possible devices via the USE_EXPAND'ed | LCD_DEVICES. Right now, this would contain about 50 devices [1]. How standardised is the naming of these devices? It's not. It's the union of the (upstream) driver's names in lcdproc and lcd4linux. Those devices that are supported by both programs had the lcdproc name staying and the lcd4linux one cut. It's also hard to standardise the names as some of the drivers are not actual devices (as curses or X11) while others stand for a whole family of devices or can talk to several different devices depending on the user configuration. Regdards, Robert signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Kevin F. Quinn wrote: On Tue, 9 Jan 2007 23:23:55 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico [EMAIL PROTECTED] wrote: | Bug #161045 [1] requests that portage support RESTRICT=sandbox. | This is certainly a valid request but a user may wish to reject a | package based on certain questionable values of RESTRICT. If a RESTRICT value is questionable, it shouldn't be supported or used. Honestly, this strikes me as rather silly and rather dangerous. RESTRICT is not something about which the end user should have to know or care; it should be something entirely between ebuilds and the package manager. And sandbox is not something that should be turned off lightly; making it so easy will only encourage developers to take the nasty way out rather than fixing simple bugs. RESTRICT=fetch is between the package, the manager, and the user (as someone has to fetch the files). RESTRICT=unattended is also between the package, the manager, and the user, as the user has to insert CD's for certain packages (most in games). However unattanded is not currently implemented, only proposed. Maybe if we move these to a new metadata key or something, Looking over the other RESTRICT values they all seem to be (ebuild,PM) tuples, not anything the user would care about. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Tue, 09 Jan 2007 21:13:14 -0500 Alec Warner [EMAIL PROTECTED] wrote: | RESTRICT=fetch is between the package, the manager, and the user (as | someone has to fetch the files). Except that the user shouldn't have to care about it then either. The user need only care when a package requires manually downloaded files. In particular, if the files are already fetched, then the value of RESTRICT is irrelevant to the end user. Control over packages requiring manual intervention is good (packages not requiring intervention is, of course, an awful lot better). This proposal doesn't seem to be a very good way of getting it, however. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
