[gentoo-dev] net-im/sim contains icons/sounds in source tarball with unclear licensing.
Hello. I found the following bug in debian bugzilla: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386570 Is this an issue for gentoo? Should I repackage tarball(/convince upstream to repackage) and exclude this icons sounds from tarball? Or may be RESTRICT fetch it enough to solve the problem? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [ANNOUNCE] Anonymous CVS and SVN now available
On behalf of Russian translators team members I'd like to say thank you for your work guys! This greatly simplifies translators work to translate and keep translations updated. This also allows to create Russian website synchronized with gentoo.org also with Russian specific additions. Thank you again :) Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
On Sun, 2006-11-12 at 12:15 +, Tavis Ormandy wrote: > The only `hardcoded` editor is the fallback editor for > visudo And this is the problem I'm talking about. I do not see any reasons to keep this not working fallback. There are parts of code that just do not work in Gentoo. > which can be set with the editor default in sudoers. That's good. But some packages (I'm talking about practically *all* crontab, vipw, vigr and may be other applications) do not have such configuration file to configure that default editor. And IMO configuration file should change *sane* defaults but I do not think nano is sane default ;) Thus I suggested either remove non working fallback in packages (patching sources) or fix unpredictable and non-working fallback by adding some sane default (that was /usr/bin/editor in my initial mail). In other cases current behavior is a bug (some part of program is not working as intended by upstream). And note suggested trivial fix as a side effect makes virtual/editor conform glep 37 (also good). Hope I've made points a bit clearer. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
On Sun, 2006-11-12 at 11:06 +, Tavis Ormandy wrote: > You can set `Defaults env_keep=EDITOR` in your sudoers file if you > want, or what I do is `Defaults:%wheel !env_reset`, to allow users in > group wheel to use sudo without the environment being scrubbed. Of course I know about that. And I hope we continue this discussion starting with this mail: http://thread.gmane.org/gmane.linux.gentoo.devel/44218/focus=44238 But to restate the question raised in that mail I'll repeat: Should we remove built in editors from packages or how should we set defaults without keeping them broken? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
On Sun, 2006-11-12 at 05:54 -0500, Mike Frysinger wrote: > in the example usages you cited, people where using `sudo` to just > avoid running `su -` first ... in other words, their sudo was > unlimited ... updating the sudoers file to allow EDITOR via env_keep > would work fine for them > > in that scenario, running any app via EDITOR is not a concern as they > already have the ability to run any command That is right. And I've already raised concerns about this approach in my mail: http://thread.gmane.org/gmane.linux.gentoo.devel/44218/focus=44238 And that is not an answer on question I've asked in this sub-thread: Do you know any way *how* to specify "safe" editors list inside sudoers? I've spent some time and did not found how can I force sudo to edit files with only known editors inside EDITOR. env_keep just keep env variable and does not allow to specify "safe" editors list. I suppose that this is impossible. Or... what do you mean by that: "the sudo file has the ability to specify editor's, so why not tell people to change their sudo config file ?" English is not my native language thus may be I just misunderstood your idea here. Sorry. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
On Sun, 2006-11-12 at 05:26 -0500, Mike Frysinger wrote: > then we end up with having to maintain a list of "safe" EDITORs and > dealing with people who want to edit their own favorite editor > > the sudo file has the ability to specify editor's, so why not tell > people to change their sudo config file ? How? May be I'm wrong, but: Defaults editor=/usr/bin/vim, !env_editor is only to use this list with visudo. And does not prevents sudo from removing EDITOR from environment. Or did you mean something else? Also from man sudoers: "The default is the path to vi on your system." Should we drop this from sources then? Or leave this broken on systems with only nano installed? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
On 2006-11-12 at 04:34 -0500, Mike Frysinger wrote: > why not modify sudo to not filter the EDITOR env var then there is no > more problem Considering that this is the only situation where environment is dropped... yes this fixes sudo problem. The other possible solution is: #!/bin/bash export EDITOR="/usr/bin/editor" /usr/bin/fcrontab -e BUT. 1. upstream uses this in the code. Then to avoid mess and unify approach we should remove all such things from the code itself. In other cases this will stay as a bug in gentoo. 2. And I see possibility to write secure editor, which will write only in predefined locations. Use of such editor became possible only through clumsy wrapper scripts (like above) if we chose to force people never to use built in defaults. And in anyway we need solution to make things more predictable. Peter. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)
Hello. Anatoly raised really important concern and currently I've started to think about fix. One possible solution requires virtual/editor to suite glep 37 and thus affects many packages. So... wondering why this change was not done I'd like to discuss the problem on the list. Problem: There are programs (fcrontab, visudo, vipw and etc.) which require default editor to work. To select editor they use these two steps: 1.) take editor name from environment (EDITOR or VISUAL vars) 2.) if there is not editor use defined at build time compiled in default The problem is that both of methods suck in some special situations which, of course, happen in Gentoo with its extreme configurability. Currently it is impossible to specify build time dependency reliably for virtual/editor: most of packages either use nano or vi (either trough ./configure option or #define in sources) but in the system without nano or vi this package either not emerges [1,2] or fails to work[3,4] (yes... if EDITOR is not set). But EDITOR *is not* set when program is started from sudo because sudo for security reasons drops environment (are there any other cases when environment is dropped?). Well. One possible answer that this is not a problem: build time dependencies are weird, always set EDITOR and never run such programs from sudo because this allows to do everything with the system. But I'd like to point at two points: firstly, some users use sudo just to avoid logging in as root and, secondly, upstream consider compiled in defaults to work. Thus IMO this is a problem. The possible solution is to add virtual/editor ebuild which will besides enumerating all virtual providers install /usr/bin/editor program. This will be a simple wrapper (bash) script which will use EDITOR environment variable to start editor, in case environment variable does not exist use EDITOR from /etc/rc.conf and as the last resolve just issue error message identifying possible ways to setup editor. All programs that use compiled in default editor should use this wrapper script. This will solve ambiguity of build time dependency and allow to use sudo reliably. While I continue playing in my overlay I'd like to know if there are any problems with this solution? Currently this change seems to satisfy KISS concept and fix some problems... thus should be implemented. I'll wait for some time and open two trackers one for virtual/editor providers another for virtual/editor build time dependency users and then add virtual/editor ebuild, remove PROVIDErs and continue working on packages that use compiled in editor defaults. References: [1] https://bugs.gentoo.org/show_bug.cgi?id=124904 [2] https://bugs.gentoo.org/show_bug.cgi?id=94771 [3] https://bugs.gentoo.org/show_bug.cgi?id=149376 [4] https://bugs.gentoo.org/show_bug.cgi?id=149339 Thank you for your time, Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] How get ebuild provider virtual/category.
On 2006-11-10 at 12:24 +0500, Anatoly Shipitsin wrote: > It's app-admin/sudo and sys-process/fcron. > This packages use virtual/editor but by default set nano as default > editor. > I'm don't know how get provider category virtual/editor. But equery > view it as first package. > Any ideas ? Please, next time, ask such questions in gentoo-user mailing list. To solve your problem change EDITOR in /etc/rc, then do: # unset EDITOR # source /etc/profile # emerge -1 sudo fcron Peter. signature.asc Description: This is a digitally signed message part
[gentoo-dev] linking with ld or gcc?
Hello. Short question: What shall we use to link libraries/programs: gcc or ld? Why? A bit longer story: I have a problem during linking of wepattack on amd64 systems. Linking stage issues warning: $ x86_64-pc-linux-gnu-ld -o wepattack wepattack.o rc4.o wepfilter.o log.o modes.o misc.o verify.o keygen.o -lpcap -lz -lcrypto ld: warning: cannot find entry symbol _start; defaulting to 00400e10 And resulted file is not executable. In google I found the most of tutorials/howtos suggest to link with gcc but some programs still use LD. From ld man page it's clear that it should link the program but this is not working. So what is the right way to do that? Why? Thank you for your time, Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] fixing up portage implicit RDEPEND behavior
On 2006-11-03 at 00:43 -0800, Zac Medico wrote: > Also, some ebuilds will loose some implicit RDEPEND that they current > get from eclasses. Why? I suppose more logical solution is to adjoin DEPEND from ebuild and RDEPEND from eclass. Peter. signature.asc Description: This is a digitally signed message part
[gentoo-dev] How to move packages?
Hello. One of packages I maintain changed its name. What shall be done, so users of the package were aware about package name change and upgraded flawlessly? Thank you, Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On 2006-09-11 at 20:30 -0400, Michael Cummings wrote: > Ciaran McCreesh wrote: > > * If no existing file with the intended target name exists, or if the > > existing > > file has identical content to the file to be installed, the file to be > > installed > > is installed as normal. > > Just one poor dev's opinion, but I prefer it when these files are > created as .sample's or examples. .sample or .example files are not related with configuration protection and as it was already decided on such files should go into /usr/share/doc. > Invariably there is some tweaking that needs to be done to the file, > even when it's the initial version of the file. And this breaks General guidelines in gentoo developer handbook: "Your package, when complete and unmasked, is supposed to "just work" for the end-user. Tweaking the installed product to get it to work should be optional; thus you need to install the package with reasonable default settings." Regards, Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] i18n project
On Вск, 2006-06-11 at 02:16 +0200, Marius Mauch wrote: > On Sat, 10 Jun 2006 15:11:50 +0200 > Jan Kundrát <[EMAIL PROTECTED]> wrote: > > b) Localization of Gentoo-developed applications (portage, > > gentoolkit,...) including their manpages > > I don't really like this one. Documentation, sure, but for the tools > themselves I think it could cause more problems than actually help. IIUYC there are tree problems with localized portage tools: 1) for users such bug reports are hard to search 2) for devs it's hard to read localized bug reports 3) "Overtranslation" for all it's hard to understand. Right? 1,2): While generally I agree that output of build process should be in "C" locale at least the following line should be translated on all possible languages: !!! If you need support, post the topmost build error, and the call stack if relevant. Everybody will benefit from translation of this message. ;) 3) Bad translation is "just another bug" that should be fixed. Nothing in reality can be done without errors. But have this stoped anybody? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] i18n project
On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote: > a) Translation of metadata.xml stuff in our tree (Is there any method to > keep them up-to-date when the English text changes? Something like > "revision" attribute that gets bumped when the English text gets updated?) While we do not have "version" or "revision" attribute, just drop all translations whenever you update English. > c) l10n for other packages and sending patches upstream > d) Translation of manpages. man-pages-cs for example sucks :(. Do we really need to do this inside Gentoo i18n project? This tasks are common for many distributions and should be done outside Gentoo. So just translate and send translations upstream. > e) Translation of our documentation (that's the GDP's job, the intention > is just to "share human resources" :) ) and GWN. > > f) Translation/localization of w.g.o. Efforts were already started > (meaning that "the technology is available on at least one experimental > site). Opposed to c) and d) this requires organization inside Gentoo and thus requires i18n project. Fex, to increase the profit from translated GWN translated versions should come out together with English one. > e) Persuading people that having comments in configuration files > *without* an equivalent somewhere on the web is evil. Good example might > be baselayout. Why? Stuff on the web can be translated pretty easily, > configuration files can't. Personally I do not like idea to look at web for package documentation. There already exist decision to put all example files somewhere into /usr/share. I hope one day this happens and then all translated configuration files also can be put there. I think the main goal of i18n should be not translation but organization (at least at first time). Untranslated staff will always remain because devs have lack of time/interest and project can nothing to do with that. But people post bugs with translated metadata, translated documentation and to resolve them we need place to find the right devs for this. And i18n project is the right place to look for them. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: > It's not a "normal" overlay as I see it. You've promoted it to be an > official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. > > As already mentioned at 1), it is an overlay. The devs on sunrise do > > keep an eye on it and all ebuilds do have to pass at least repoman and > > some basic QA checks (currently done when porting them from bugs.g.o) so > > that they don't do some rm -rf / thing. > > Will you also review the code each and every ebuild pull down over the > internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Чтв, 2006-06-08 at 21:20 +0200, Henrik Brix Andersen wrote: > It's not a "normal" overlay as I see it. You've promoted it to be an > official overlay. The difference is huge in my opinion. IMO such overlay should be official! Why not to keep all (partially) broken ebuilds in one place? This is the same story as with German gentoo forum that is outside gentoo.org and thus none of devs wanted to keep eyes there, so forum became much less useful. Another problem with BMG is that it is gnome oriented, as cleary stated on About page and thus I never thought that my, fex, www-apps could be there. > > As already mentioned at 1), it is an overlay. The devs on sunrise do > > keep an eye on it and all ebuilds do have to pass at least repoman and > > some basic QA checks (currently done when porting them from bugs.g.o) so > > that they don't do some rm -rf / thing. > > Will you also review the code each and every ebuild pull down over the > internet? And that is really exciting moment. :) The main difference between such overlay and wiki is that reading text never does `rm -rf /`. How can one stop such jokes? I think if this problem will be solved such overlay should be. Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA subproject, TreeCleaners
On Втр, 2006-06-06 at 00:17 +0200, Diego 'Flameeyes' Pettenò wrote: > That's why we use a SCM for managing the ebuilds: the removed ebuilds > are still found via cvs commands and on sources.gentoo.org But how can I search for removed ebuild in cvs? Is there any quick way for such things? Peter. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Срд, 2006-01-25 at 20:57 +0100, Grobian wrote:
> Are there any objections to removing csh from the tree? If there are no
> problems with csh removal before Feb 1st 2006, then I will starting from
> that date work on getting csh removed by masking it, blocking tcsh and
> csh, and request for updates of the packages that depend on csh.
Thinking a little bit on subject I'd say I object. There is a big
difference in size between csh and tcsh:
-rwxr-xr-x 1 root root 130148 Янв 28 08:11 /bin/csh
-rwxr-xr-x 1 root root 299136 Янв 28 08:13 /bin/tcsh
So tcsh is *2.3 times bigger* then csh. Of course, that's not a big pain
for current desktop or server systems. But gentoo is used for different
purposes... Also personally I like small system and I'm not using csh
for anything except for installing packages. So I do not need anything
except basic csh functionality. Thus for me it's better to leave csh and
remove tcsh (I know this is bad solution ;) ).
> Problem here is that creating a conditional symlink for csh -> tcsh is a
> bit dirty, and leaves the user with a system that has no csh in case the
> csh is unmerged after tcsh was installed.
To solve symlink problem I can suggest the following.
1. As it should be done now, tcsh should create symlink csh -> tcsh if
csh does not exist (in src_install()).
2. csh ebuild should create csh -> tcsh symlink if tcsh exist during
unmerge. This is possible with pkg_postrm:
pkg_postrm () {
[ -e /bin/tcsh ] && ln -s /bin/tcsh /bin/csh
}
3. tcsh should remove csh -> tcsh symlink on unmerge.
pkg_postrm () {
[ -e /bin/tcsh ] && ln -s /bin/tcsh /bin/csh
}
Not a very clean solution, but works.
BTW. Why tcsh is a blocker for csh?
Peter.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] ChangeLogs and rsync time
On Вск, 2006-01-01 at 21:35 +0100, Francesco Riosa wrote: > We have currently 10371 ChangeLog files, > 25 MB totally . > 1365 == 13% with size >= 4096 B, 12 MB totally > > rsync from "emerge --sync" has "--whole-file" between its options, that > mean transfer the whole file if changed. > 2) "rotate" Changelogs, keeping only the last changes, until a size >of 4000 or [choose a preferred size here] bytes. >This would save only about 7Mb of data (max size < 4096). ChangeLog is the only source of information on upgrade reasons and IMO users are interested only in recent information there. Another suggestion is to combine rotate like and exclude list solutions. When ChangeLog size reaches above maximum allowed size echangelog should create ChangeLog.old file and copy tail of ChangeLog there, in order to keep ChangeLog size. Then using excludes list one may drop really old entries in ChangeLog.old, whereas keeping recent information in portage tree. Peter. signature.asc Description: This is a digitally signed message part
