Re: [gentoo-dev] Re: Fixing the TERM mess
On Tue, Sep 06, 2005 at 09:19:51PM +0200, Jan Kundrát wrote:
> Joe Wells wrote:
> > The best solution to this that I can think of is to extend OpenSSH
> > with the capability to copy terminfo information to ~/.terminfo on the
> > remote system.
>
> IMHO automated overwriting files in $HOME on every login is a *very* bad
> thing. And if you wanted to remove those "-via-ssh-#" lines after
> logout, what will happen if your connection hungs?
>
> -jkt
As said ssh can transport environment variables to the other system.
Usualy people use it to transfer $TERM.. why not make a variable
$TERMINFO_DESC ($TERMINFO is allready used by curses for the path to
local terminfo) and put the hole terminfo description into it, mark it
for export via ssh, and write a few commands in your bashrc on the other
side to put $TERMINFO_DESC into a file say ~/.terminfo/${TERM:0:1}/$TERM
if it does not exist... (or do the new-uniqe-name stuff Joe suggested)
Or just simpler, put a termcap descritption into $TERMCAP, and mark that
for ssh export. Downside is that you would have to change TERM to
something that isn't in the other systems terminfo database, or
the $TERMCAP won't be used.
Or better, hack curses to use $TERMINFO_DESC from environment to
override the system terminfo databes, and just export that variable...
Downside is that applications that don't use ncurses won't use it...
But best way is to clear the mess as suggested and persuade konsole,
gnome-terminal and others to use their own terminal type.
--
_
|
YoYo () Siska
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
On Wed, 2005-09-07 at 00:03 +0100, Ciaran McCreesh wrote: > a) Convenience. Testing. Some times we want to get user testing on a specific package or two, and it is easier to distribute it via the normal portage tree than not. Another reason for masking packages is for security reasons. This especially happens when there is no patch or fixed version upstream. It allows the user to decide if they wish to continue running a vulnerable package or not, without forcing the removal of the package from the tree. > b) Sadly, unlike some other distributions we don't refuse to package > things which won't work on all our tier one archs. This is both a pro and a con. There are many packages that we include that will *never* run on architectures but x86/amd64. These are mostly binary applications and games, but from the feedback that I have gotten, our users seem to enjoy that we have these packages in our tree. It is definitely a disadvantage when a source-based package does not work on all architectures, but with the volunteer team that we have, I think we do pretty well. The arch teams also do an excellent job of making sure things either work or don't on their architecture. The only way we could enforce source-based packages working on all of our tier-one architectures would be to have *much* larger arch teams. It would also slow down our productivity greatly. After all, if package foo doesn't work on sparc, they just don't have to keyword it. I find this requires much less manpower than forcing the package to either be removed, no matter how useful it is, or forcing the sparc team to come up with a patch so it can work on that architecture. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Wed, 2005-09-07 at 08:46 +0200, Kevin F. Quinn wrote: > If nobody on x86 is using a given package, is there a need to worry > > about marking it ~x86/x86? > > When I said 'All', I didn't mean to include stuff that's not in x86. > What I was trying to get at, was the idea that if the x86 arch team > is responsible for stable marking x86, then all packages that want > to go x86 need representation on the x86 arch team. No, they don't. That's the idea of an arch team. You don't section off everything *again* as we already have herds for that. Instead, if you're on the x86 arch team (or sparc, or mips or anything, really) than you are responsible for the x86 keyword. All of it. Every package. Now, while there might be some internal "Hey, I use this all the time, so I'll keep up with it" types of things, there's also the "I don't use this package but can test it when needed" area that needs to be kept track of. While fundamentally different, I would say the games team works similarly to this. We have *lots* of packages that we personally don't use, but we maintain. The arch teams do the same thing. They test what is requested of them, and determine if it is ready for stabilization, or even just ~arch keywording. Sometimes, they determine a patch is needed, and add it or send it to the package maintainer for inclusion. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] new eclass: haskell-cabal
Hi there. The Haskell team has created a new eclass. It makes building Haskell packages that conform to the Cabal [1] architecture (an effort that aims at easing packaging and distribution of both Haskell libraries and tools) nearly trivial. I wish to use the opportunity to thank Lennart Kolmodin and Henning Günther, who aren't Gentoo developers, but have had significant part in the design and development of the eclass. The eclass has been developed and tested in the inofficial gentoo-haskell darcs [2] overlay [3], where the code is available for inspection [4]. We plan to include the eclass in the main portage tree later this week. The overlay currently also contains ~10 packages using the eclass. These will be added to the tree shortly after the inclusion of the eclass. More packages using the eclass are likely to follow. Cheers, Andres (kosmikus) [1] http://haskell.org/cabal/ [2] http://darcs.net/ [3] http://haskell.org/~gentoo/gentoo-haskell/ [4] http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/haskell-cabal.eclass pgpYWTT87D41g.pgp Description: PGP signature
[gentoo-dev] use.mask'ing and packages in the testing branch
Hi, I have a question about masked USE flags and packages in the testing branch. I have a problem with "sci-biology/emboss", a sequence analysis package I maintain that was keyworded ~amd64 a few days ago. Six packages (containing various genetic and biological data) in the tree have optional EMBOSS support that may be enabled using the corresponding USE flag. EMBOSS PDEPENDs on these six packages, because they are necessary for a complete EMBOSS installation but cannot be installed before EMBOSS as they have to be indexed using EMBOSS programs. These six packages in turn depend on EMBOSS, but only if optional EMBOSS support is turned on. The reason is these packages may be used without EMBOSS (although that is rarely the case, some users appreciate that and I do not want to force over 200 programs on someone just for installing a small amino acid properties database). The end result is that in order to have EMBOSS work on a given arch, the six depending packages must also be keyworded, *and* the emboss USE flag must be enabled by default. Otherwise, the users would be left with the PDEPENDencies built without EMBOSS support, and many EMBOSS programs (some of which are very important and popular) would be broken. The problem is that on amd64, the "emboss" USE flag is still masked and is not in the default USE flags like it is for other arches that support EMBOSS (see bug #105086 [1]). I was told that demasking USE flags is only done when packages hit the stable branch. (I do not know why and would appreciate an explanation.) It also seems that architecture conditional dependencies are deprecated. I still believe that unmasking the keyword would not break anything since no amd64 stable package has optional EMBOSS support and, of course, no such package should be stabilised until EMBOSS itself is stable. The bottom line is EMBOSS is currently keyworded ~amd64 but broken on amd64. This is a known bug and should be easy to fix, but if we cannot demask the USE flag or use architecture conditional dependencies, I really have no idea how to fix this. Thoughts or suggestions anyone? [1] http://bugs.gentoo.org/show_bug.cgi?id=105086 -- Olivier Fisette (ribosome) Gentoo Linux Developer Scientific applications, Developer relations pgplNeXfPbdvP.pgp Description: PGP signature
Re: [gentoo-dev] use.mask'ing and packages in the testing branch
On Wednesday 07 September 2005 01:16 pm, Olivier Fisette wrote: > I was told > that demasking USE flags is only done when packages hit the > stable branch. this is incorrect demasking a USE flag only requires you not break packages ... so if your USE flag is only used in unstable branches, then it isnt an issue, demask and have a ball :P ... but if you have a stable package which has IUSE=emboss and emboss itself is still unstable then you obviously cant demask yet because you'd break dependency tree for the stable branch > It also seems that architecture conditional > dependencies are deprecated. they arent deprecated, they are straight up not allowed -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Removal of x11-base/y-windows and x11-libs/libiterm-mbt
I will soon mask/remove y-windows due to a dead (and abusive) upstream (see bug http://bugs.gentoo.org/show_bug.cgi?id=100072 ). libiterm-mbt is a library associated with y-windows that will also and app-i18n/fbiterm is the only application that depends on it, belonging to the cjk herd. I'm making this public in case someone has issues with any of the three packages disappearing, particularly fbiterm (since it's outside my herd). I won't do anything to any package until I hear back from someone about fbiterm. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Comparing Openpkg with portage
Hello- I'm investigating the similarities between portage and openpkg. More specifically I was wondering if it is possible to take portage and install in on top of an existing linux installation in its own sandbox (similar to what openpkg does). I've done some googling and found the documentation about the gentoo sandbox (http://bugday.gentoo.org/sandbox.html), but this seems to be a tool for checking that ebuilds behave correctly. I've read through the developer documentation and didn't find anything there. Google hasn't necessarily been very useful either So, is it possible to sandbox a portage installation on top of say a debian or fedora install? If so, can anyone point me in the right direction? Do any of the devs out here have experience with openpkg? thanks matt
[gentoo-dev] Stabilization of new-style Apache
The Gentoo Apache Team is pleased to announce the stabilizing of package updates that have been in the works for over a year. Some of the major changes include: - New configuration and configuration locations to more closely match upstream and reduce confusion for users coming from other distributions. - Modules now use a centralized eclass that builds, installs, and displays standard information on enabling the module. This allows easier maintenance of existing modules, and allows us to more rapidly develop ebuilds for modules that are not yet in the tree. - Expanded USE flags to let you choose which MPM is compiled. - A new gentoo-webroot that will eventually provide a gentoo-themed icon-set, error documents, and default website. This has been put in it's own package, and includes a USE-flag to not install the gentoo-webroot into /var/www/localhost - useful if you put your own website there. - And much more, including the fixing of many many bugs. These changes will stabilized on Sunday, September 18th. These changes have been throughly tested and given a thumbs up by many many users. They also allow you to use the new php (including support for php5) ebuilds when they become fully available. Because of these changes and improvements, when you upgrade to the new revision of Apache, you will need to take care of some things. These are fully documented in our Upgrading Apache document [1], but in summary, this is what you will need to do: - Merge any customizations that you have made to the Apache configuration into the new configuration at /etc/apache2/httpd.conf (The configuration file location has changed). Note that the init script for apache checks for a configuration in the old location and refuses to start if you haven't moved/removed it - this is to avoid the possibility of moving to a configuration that isn't right for your machine. - Update any modules that you used to revisions that support the new eclass. Older modules will not work due to location changes. - Restart Apache We have done our best to make it easy to migrate, but if you have problems, feel free to visit us in #gentoo-apache on irc.freenode.net or on our mailing list gentoo-web-user@gentoo.org and we'll be glad to help. Thanks, The Gentoo Apache Team [1] http://www.gentoo.org/doc/en/apache-upgrading.xml -- Michael Stewart [EMAIL PROTECTED] Gentoo Developerhttp://dev.gentoo.org/~vericgar GnuPG Key ID 0x08614788 available on http://pgp.mit.edu -- signature.asc Description: OpenPGP digital signature
[gentoo-dev] PPC gets more help
The ppc team has found a new minion^W AT to help them out. Matti Bickel (mabi) has stepped up for abuse from JoseJX.. Please welcome him to the team! JoseJX, don't work him to hard! j/k, Where's the whip? ;) -- Homer Parker Gentoo/AMD64 Arch Tester Strategic Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Comparing Openpkg with portage
Icky on the html email :P On Wed, Sep 07, 2005 at 05:45:16PM -0700, m h wrote: > Hello- > I'm investigating the similarities between portage and openpkg. More > specifically I was wondering if it is possible to take portage and > install in on top of an existing linux installation in its own sandbox s/sandbox/prefix/ This is what fink does, and what gentoo-osx is moving towards. > (similar to what openpkg does). I've done some googling and found the > documentation about the gentoo sandbox > ([1]http://bugday.gentoo.org/sandbox.html), but this seems to be a > tool for checking that ebuilds behave correctly. Moreso protection, then ensuring they behave correctly; if they do something they shouldn't they get blocked from what they're attempting. It's an active tool, rather then a 'check' of the ebuild (that and it's limited to linux, no *bsd implementations). Akin to depriving, although depriving is more effective- one can sidestep the sandbox, can't sidestep being de-prived aside from priv escalation. > I've read through > the developer documentation and didn't find anything there. Google > hasn't necessarily been very useful either > So, is it possible to sandbox a portage installation on top of say a > debian or fedora install? If so, can anyone point me in the right > direction? With current ebuilds, nope. There's no global prefix offset in the code for it (root is merge offset, not runtime prefix offset). > Do any of the devs out here have experience with openpkg? Pretty much an extension of rpm spec's, afaik. Beyond that? Heh, nope :) ~harring pgprNbXWpws3d.pgp Description: PGP signature
[gentoo-dev] Last call for media-video/spca50x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This package was due for removal on May 1 2005, having been replaced by media-video/spca5xx. Unless someone objects in the next 7 days, I will remove it from the tree. - -- === Mike Doty [EMAIL PROTECTED] Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7 Gentoo Developer Relations ~ ===GPG Fingerprint=== ~ 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDH7Tm0K3RJaeXx6cRAkEuAJ9/DrSrtcF4Cbl8ovXvqLxbPChnhwCcCaPI 5KvFVCrRYNl9LWw8qCCBnB8= =FjjN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
