Re: [gentoo-dev] Maintainer needed for app-portage/flagedit app-portage/profuse dev-util/libconf
Just wondering, why did you abuse classes that badly and hack way through optparse? If it limits your needs you might want to take a look at argparse. Domen On Wed, 2010-11-03 at 14:48 +0100, Michał Górny wrote: > On Wed, 3 Nov 2010 08:32:07 +0100 > Torsten Veller wrote: > > > If nobody is interested, I'll mask them for removal in one week. > > If nobody is interested indeed, I'd appreciate a longer removal period > as I'm currently working on a replacement script, called flaggie [1]. > > Although it can be considered working already, I'd like to polish it > a little and implement the basic feature set before the first release. > > [1] http://github.com/mgorny/flaggie > signature.asc Description: This is a digitally signed message part
[gentoo-dev] layman and filesystem permissions
As some of developers noticed, current gpypi2[0] implementation (tool for querying Python Package Index to create ebuilds) needs root permissions for two reasons: - to write ebuild in overlay managed by layman - to unpack source for setup.py introspection with "ebuild foobar unpack" It just seems wrong for such a tool for the need of root permissions, so I'm asking what are the options to drop layman to root:portage or something similar. Discussion about the approach is open, I'm not *really* sure what would be the proper way. Cheers, Domen #0 http://docs.fubar.si/gpypi2/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] council manifesto for ferringb
Clear reference for usnig git http://gitref.org/ On Thu, 2010-06-24 at 07:56 +0200, Jeroen Roovers wrote: > On Thu, 24 Jun 2010 07:31:07 +0200 > "Paweł Hajdan, Jr." wrote: > > > I'd rather have git soon with longer, but acceptable outage, than in > > the future, with a very small outage. > > I'd like some documentation to be finished before the switch is made. I > have no idea how to commit patches using git yet, let alone how to > change my workflow or how sources.g.o is going to display these or > how packages.g.o is going to be adapted for git use. I could go on. :) > > > jer > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
This should probably be updated: http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#flash On Fri, 2010-06-18 at 15:58 +0200, Angelo Arrifano wrote: > On 18-06-2010 12:16, Alec Warner wrote: > > On Fri, Jun 18, 2010 at 2:08 AM, Lars Wendler > > wrote: > >> Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring: > >>> On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote: > Lars Wendler wrote: > > Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: > >> On 16-06-2010 14:40, Jim Ramsay wrote: > >>> Chí-Thanh Christopher Nguyễn wrote: > One notable section is 7.6 in which Adobe reserves the right to > download and install additional Content Protection software on the > user's PC. > >>> > >>> Not like anyone will actually *read* the license before adding it to > >>> their accept group, but if they did this would indeed be an important > >>> thing of which users should be aware. > >> > >> I defend it is our job to warn users about this kind of details. To me > >> it sounds that a einfo at post-build phase would do the job, what do > >> you guys think? > > > > Definitely yes! This is a very dangerous snippet in Adobe's license > > which should be pretty clearly pointed at to every user. > > Could that also include a alternative to adobe? If there is one. > >>> > >>> The place to advocate free alternatives (or upstreams that are > >>> nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs or at > >>> best in metadata.xml... einfo should be "this is the things to watch > >>> for in using this/setting it up" not "these guys are evil, use one of > >>> the free alternatives!". > > Why? You are running a free and opensource operating system, what's > wrong suggesting *other* free and opensource alternatives? You are just > providing the user a choice, not to actually oblige him to install anything. > > Also, I'm pretty sure seeing nvidia-drivers suggesting the use of the > kernel driver when using the hardened profile. > >> > >> Maybe I expressed myself a bit misinterpretative. I don't want to request > >> an > >> elog message telling users about alternative packages. But in my opinion an > >> elog message pointing at the bald-faced parts of Adobe's license should be > >> added. These parts about allowing Adobe to install further content > >> protection > >> software is just too dangerous in my opinion. > > > > I will ignore the technical portion where basically any binary on your > > system; even binaries you compiled yourself have the ability to > > 'install things you do not like' when run as root (and sometimes when > > run as a normal user as well.) > > For all the years running Linux, I never found that case. > > > > The real meat here is that you want Gentoo to take some kind of stand > > on particular licensing terms. I don't think this is a good > > precedent[0] to set for our users. It presumes we will essentially > > read the license in its entirety and inform users of the parts that we > > think are 'scary.'[1] The user is the person who is installing and > > running the software. The user is the person who should be reading > > and agreeing with any licensing terms lest they find the teams > > unappealing. I don't find it unreasonable to implement a tool as > > Duncan suggested because it is not a judgement but a statement of > > fact. "The license for app/foo has changed from X to Y. You should > > review the changes accordingly by running " > > I'm the person who initially proposed warning users on elog. The initial > proposal only states about: > 1) A warning about change of licensing terms. > 2) A warning that "additional Content Protection software" might be > installed without users consent. > > In fact, portage already warns the users about bad coding practices, > install of executables with runtime text relocations, etc.. How is this > different? > If me, as a user, didn't know about such detail (who reads software > license agreements anyway?) and someday I hypothetically find a > executable running without my permission as my user account and I'm able > to associate it with Adobe's flash, I would be pissed off to no extent. > And guess what? First thing I would *blame* is flash maintainers. > I expect package maintainers to be more familiar with the packages they > maintain than me. As consequence, I expect them to advice me about > non-obvious details on those packages. At least that's what I try to do > on the packages I maintain. > GNU/Linux is all about choice. Stating, during install, that a package > might later install additional stuff will just provide a choice to the > user, not conditioning it. > > Regards, > - Angelo > > > > [0] There is an existing precedent for reading the license and > > ensuring Gentoo itself is not violating the license by distributing > > said software. Gentoo takes measures to reduce its own liability in > > case a lawsuit a
Re: [gentoo-dev] Tone in Gentoo
http://xkcd.com/386/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] [GSOC] Python, GSoC and distutils2
Greetings, I'm working on g-pypi2 project over this summer for Gentoo, and among other things, I learned a lot about how Gentoo handles Python package distributions. There are quite some students working on distutils2 implementations, so I thought Gentoo as source distribution has a lot to say how would upstream Python tools help towards better standard and API to make life just a little bit easier. I have put together a piratepad/etherpad for easier collaboration if anyone is willing to drop his thoughts how Python distribution of packages could be improved, follow the link http://piratepad.net/EIYOmjJKaJ .. read more about GSoC team http://bitbucket.org/tarek/distutils2/wiki/GSoC_2010_teams .. blog planet with reports http://teckla.idyll.org/~t/planet-distutils/ Cheers, Domen signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, 2010-06-06 at 14:41 +0200, Thomas Sachau wrote: > Am 06.06.2010 13:50, schrieb Domen Kožar: > >> And if you add a python slot or remove one, portage currently is not able > >> to see that and to > >> reinstall packages, which had modules installed for that slot. You need > >> another tool > >> (python-updater) to check that and to call the needed reinstalls. > > > > I agree with this fact, user should not be required to read additional > > documenation for portage to function as wanted. > > > > I'm very unfamiliar with inner workings of portage, but using > > python-updater implementation, USE_PYTHON behaviour shouldn't be that > > hard to implement? > > You want some additional switch to portage, which does the work of > python-updater? That would just > move the code, but would still have the same limitations. What does speak > against explicit user > control for optional features/slots, including dependency handling by the > package manager like in my > proposal? > Maybe I expressed myself wrong. Portage would only reuse python-updater to detect and repair changes with python installation. If I understand correctly, one solution would be to pull stable 2.x, and only install other slots according to USE_PYTHON. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
> The current python eclass also uses some vars to specify the supported slots, > yes, but it is more > complex and harder to maintain in addition to the fact, that the dependency > part is hidden from the > package manager. > > I dont think, that you can tell portage with the current implementation, that > it should only install > python modules for python-2.6 by default and additionally python modules for > python-3.1 for selected > packages. Portage will also install newer slots of python, even when the user > does not request them > and no package requires them, which will result in unneeded and unused > versions on disk. Beg my pardon, but that is untrue AFAIK. Portage will install packages only for active python version, unless USE_PYTHON is set. > And if you add a python slot or remove one, portage currently is not able to > see that and to > reinstall packages, which had modules installed for that slot. You need > another tool > (python-updater) to check that and to call the needed reinstalls. I agree with this fact, user should not be required to read additional documenation for portage to function as wanted. I'm very unfamiliar with inner workings of portage, but using python-updater implementation, USE_PYTHON behaviour shouldn't be that hard to implement? > > With my solution, there are only modules installed for selected slots. And if > you have selected a > slot, the related python version is pulled in by portage. If you disable that > slot, you can > reinstall those packages with --newuse option and then can remove that python > slot with --depclean. > No need for another tool, simple handling by the package manager Explicit is than implicit:) Cheers, Domen signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] showing file diffs as root
difflib is one of the best Python libraries out there. It does it's job perfectly. difflib can generate diff in text, any it's very pluggable (go through documentation, you will see) On Sun, 2010-05-30 at 11:27 -0400, Christopher Harvey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/30/10 11:21, Domen Kožar wrote: > > Hey! > > > > Maybe I am missing something, but why not use difflib and pygments on > > top of that? > > > > Cheers, Domen > > > > That's a good option. > Pros: > Can easily integrate the diff viewer into my application. > > Cons: > Doesn't seem to be a way to interactively merge files (not a big deal > for me) > > As for generating the diff is it ok to use difflib to generate the diff > text? I hear there is a diff environment variable..(but I can't seem to > find it now) should I use that instead? > > - -- > My GnuPGP key at: > www.basementcode.com/public_key.txt > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJMAoPtAAoJEDqfZIFeqFH7+NYH/3J6IS4woiS5KI3KIDdPA5eU > 9VBaC8xRJEJ/fwYXoxaRqkWft2hAd/FahbPMzZI9RiA3tEu8Cv8NE6nvtXTJoe6U > zJ/8gIszJVEG3QnADvzdSr03kCWCsom5iZBuEYP0eK/VT9cgsjiTsc71p0h7zcIK > TosCrKMkya3IJ3svBXLnJhgtcekfmP2Qk8gQt4o/UMW1D7abP5kI2zxidgsGEL1V > YBu4HOirte9RFzEIZBClFW0LpUZ0Ix2Rpf614GvAEW+5HK34hfQHMxdmPCVVLv7W > KNMspLUOaOEVnufhz8i5UvKvbMCjj5PItTvEQlsJ/xzrB2bZqIWK1iYZp07PdmI= > =CWy/ > -END PGP SIGNATURE- > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] showing file diffs as root
Hey!
Maybe I am missing something, but why not use difflib and pygments on
top of that?
Cheers, Domen
On Sun, 2010-05-30 at 10:59 -0400, Christopher Harvey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello gentoo-dev,
>
> I'm working on an app for GSoC that needs to show a diff of two files
> to the user. Right now I've just been calling meld from the python
> os.system call. I tried running my application as root to show diffs
> of system files that belong to root. I got this error:
>
> Traceback (most recent call last):
> File "/usr/bin/meld", line 90, in
> meldapp.main()
> File "/usr/lib/meld/meldapp.py", line 982, in main
> app = MeldApp()
> File "/usr/lib/meld/meldapp.py", line 562, in __init__
> self.prefs = MeldPreferences()
> File "/usr/lib/meld/meldapp.py", line 435, in __init__
> super(MeldPreferences, self).__init__("/apps/meld", self.defaults)
> File "/usr/lib/meld/prefs.py", line 92, in __init__
> self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE)
> glib.GError: Failed to contact configuration server; some possible
> causes are that you need to enable TCP/IP networking for ORBit, or you
> have stale NFS locks due to a system crash. See
> http://projects.gnome.org/gconf/ for information. (Details - 1:
> Failed to get connection to session: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the
> message bus security policy blocked the reply, the reply timeout
> expired, or the network connection was broken.)
>
> I haven't looked into why this is happening very much because calling
> os.system("meld file1 file2 &") in python is putting up so many red
> flags in my head it's not funny. If anybody could tell me the proper
> gentoo/linux/python way to present a root level diff to a user running
> a program through su or sudo I'd really appreciate the help.
>
> thanks,
> Chris
>
> - --
> My GnuPGP key at:
> www.basementcode.com/public_key.txt
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMAn1RAAoJEDqfZIFeqFH7brQH/RqeUmCHuopa+SufkzNNT4Ys
> 7IJArQCik3vBLJLpeTM3gf3NL3KMWjyzlxxQ8L74KAhItPuA3cVUQKQrSnOCBiDa
> y6yfDttBbOptOtcUYn7WkXQDm+BYEdpviMfjtym5ZF2nlGOMzZMxknP4ywXnhLZN
> q2169haoG0p1g0D11q2H9B4Vk++PUil7VLgzOfAOcLQ9YpFDkXIdxy5FRaRkx8K4
> lcPfmzFha8OkdBpsXPJdhtY5pmzOEf+ziprDlyD7eCkE1xAkRNhjsNtEz9CTXeLh
> l46/tUCZTx+aX9ABW0m13Ache8jGN36+TvsRzRKfzqaMJ0z/wEOeESooPFYHnl0=
> =FxxJ
> -END PGP SIGNATURE-
>
>
signature.asc
Description: This is a digitally signed message part
