There are only 4 billion to reverse, not that hard really with a rainbow table... On Thu, 21 May 2020 at 13:08, Michał Górny wrote: > On Thu, 2020-05-21 at 13:57 +0200, Ulrich Mueller wrote: > > > > > > > On Thu, 21 May 2020, Robert Bridge wrote: > > > On Thu, 21 May 2020 at 09:47, Michał Górny wrote: > > > > Option 1: IP-based limiting > > > > === > > > > > > > Preface this with IANAL, check with your own legal counsel... > > > While IP address based methods might be attractive technically, do > > > remember that an IP address is considered Personally Identifiable in > > > European Data Protection law. > > > The fact submissions require an action by the user will probably be > > > sufficient to be explicit consent, any system storing these details > should > > > allow for the use to revoke their consent: If you collect anything > > > personally identifiable, you will need to provide a mechanism for > users to > > > request the removal of all their submissions. > > > Tread carefully with this project. :) > > > > You don't have to store any IP addresses, you can store a cryptographic > > hash like their b2sum (salted if necessary). > > > > Yes, this is as great as storing hashes of phone numbers ;-). > > -- > Best regards, > Michał Górny > >
On Thu, 21 May 2020 at 09:47, Michał Górny wrote: > > Option 1: IP-based limiting > === > Preface this with IANAL, check with your own legal counsel... While IP address based methods might be attractive technically, do remember that an IP address is considered Personally Identifiable in European Data Protection law. The fact submissions require an action by the user will probably be sufficient to be explicit consent, any system storing these details should allow for the use to revoke their consent: If you collect anything personally identifiable, you will need to provide a mechanism for users to request the removal of all their submissions. Tread carefully with this project. :)
On Sat, Jul 31, 2010 at 4:09 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 7/31/10 4:37 AM, Hanno Böck wrote: Though we might discuss if vpx is really a good name or it shouldn't be vp8. It might also be webm. Not sure what's more intuitive for people. Also, nteresting question would be whether to enable the flag by default an in which profiles (desktop?). Speaking as a user, I would ask what the standard file ending is? Most users won't know what the codec is, they will just know is foo.webm or foo.vpx/8. Just a thought if debating the name. RobbieAB.
Speaking as a user, I seem to recall having multiple versions of python installed in the past, and never really knowing or caring which version was being used so long as stuff worked. If you want to install python-3.14159 in the stable tree, than go right ahead, so long as anything that doesn't work with python-3 can still access python-2 and does so without me knowing, it doesn't matter. So the question isn't SHOULD python-3 be stabilised, it's what will break if it is surely?
Patrick Lauer wrote: On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. Interesting, but quite subtly wrong. I'm surprised that you try to slip such an obvious logical mistake in in an attempt to save your arguments. Patrick, in the interest of making this comprehensible to the average schmuck like me, which you seem to be trying to do, could you actually explain WHY this is wrong? Otherwise it looks like you are simply trying the arrogant I am right because I say so line. If you're looking for a formally correct alternative that works in the way you suggest, I already provided one, and you already read about it -- and it still doesn't solve the problems that 55 does. And glep55 doesn't solve the problem either. It's neither formal nor correct, plus in this case ... what on earth are you trying to communicate? Again, see my previous comment. We can encode all the relevant info in the first line of the ebuild starting with EAPI= No we can't. That's *obviously* completely wrong. It's obviously quite specifically not. Can you show any case where that fails or where adding this restriction removes relevant functionality? Both of you need to explain your opinions here. Just my thoughts, R.
Markos Chandras wrote: Some one could say Post it on gentoo.org homepage. I wonder if users ever visit that page to read gentoo news :\ I can safely say that some never do... RobbieAB
Petteri Räty wrote: 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage I have been thinking about this specific option. I will admit I don't know if this has already been noted, but would this create the possibility of multiple ebuilds with the same $C/$P-$PV? Currently the filesystem enforces the uniqueness of that tuple, will that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for the same $C/$P-$PV with different EAPIs?) If not, how is anyone proposing to enforce the uniqueness here? Just a silly thought... RobbieAB
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Tue, 24 Feb 2009 09:36:29 -0700 Joe Peterson lava...@gentoo.org wrote: 2) it makes sense to have these in the filename, but not internal meta-data For those of us who understand the process, it makes sense to have EAPI in the filename too. Which seems to be an enlightened few who... How did we manage before you graced us with your presence?! *humbly prostrates myself before this paragon of enlightenment* Robbie
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Tue, 24 Feb 2009 21:17:57 + Except that once we have EAPI in the file extension, we can change anything we want in arbitrary ways without having to worry about backwards compatibility, so we won't need silly hacks. Like the file name structure?
On Wed, 19 Nov 2008 19:03:12 +0100 Miroslav Šulc (fordfrog) [EMAIL PROTECTED] wrote: I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is modular IDE with 18 modules (clusters). Users can freely choose what support thay want to build in netbeans, though some modules need other modules to compile and work. Are there any objections? As a sometimes programmer who prefers Eclipse, would it be an option to do something similar for that IDE? This obviously leads to the question of when does a package qualify for such an option instead of using a set of regular USE flags... Just a few thoughts, RobbieAB. signature.asc Description: PGP signature
On Sat, 01 Nov 2008 12:05:54 +0100 Ben de Groot [EMAIL PROTECTED] wrote: Hi, I would like to add a new category to the tree: lxde-base, to be used for the LXDE desktop [1,2] packages, in correspondence to the categories for the other desktop environments we have (gnome, kde, xfce). With the help of a few users I have been developing ebuilds for these packages in the lxde overlay , and I would like to move the ebuilds for the release versions into the official tree now. (The overlay also contains live svn ebuilds.) LXDE currently has 14 packages that would go into this new category, which is comparable to what xfce-base has. It also uses x11-wm/openbox as default WM, and x11-misc/pcmanfm as default filemanager, although these can be easily swapped for others. Comments are welcome! As a use who looked at LXDE for older machines, but decided that not to mess around with overlays on otherwise stable x86 boxes, can I vote for this? 1: http://lxde.org/ 2: https://bugs.gentoo.org/157989 3: http://www.bitbucket.org/yngwin/lxde-overlay/src/ signature.asc Description: PGP signature
On Fri, 10 Oct 2008 17:56:37 +0200 Marius Mauch [EMAIL PROTECTED] wrote: On Fri, 10 Oct 2008 14:48:19 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: Whatever. Some of you seem to have some quite agressive dislikement to it. In the end it's just a name/tag. I guess I could live with anything, including c3p0. Well, while I dislike x64 I'm more concerned about using different names (amd64 and x64) for the same architecture (same would apply if you had used i386 or ia32 in some cases instead of x86) and was just checking if there was any functional reason for that difference. I would agree with this. As a user coming to the project, x64 is NOT the same arch as amd64, it has a different name! Select one name for the arch, and use it everywhere. Consistent naming is more important than having the name absolutely technically correct. And seeing as Gentoo uses amd64 for all those arches in the main tree with minimal problems, I personally would vote for using amd64 in -alt to retain consistency with the rest of Gentoo. Just my 2 cents. Rob. signature.asc Description: PGP signature
On Wed, 01 Oct 2008 09:37:25 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] wrote: Can package.use syntax be extended to allow set entries? @compiz-fusion -gnome kde kde4 Perhaps, but we need to clarify how that sort of setting will affect nested sets. For example, if @compiz-fusion contains nested sets, would those USE settings apply to the nested sets as well? Will nested sets be allowed to have independent USE settings from the sets that nest them? Maybe a nested set could inherit the USE flag settings of its parent set unless it has its own entry in package.use. Though what happens if a package is in both sets which have conflicting flags in package.use? I would say that the nested set has to have priority. If not, I can easily imagine people getting confused when their USE settings for a set are being applied to all but one or two packages. It seems to me that the most logical approach would be to do some sort of incremental stacking, similar to the way that USE flags stack in the profiles. Suppose that we have the following settings in package.use: @kde-metafoo bar @kdeedu-meta -foo If the flags are stacked incrementally, analogously to the way that they are stacked in profiles, then the above setting would apply the foo and bar flags to all of @kde-meta except for the @kdeedu-meta subset which would only have bar applied since foo has been disabled incrementally. Does this approach seem reasonable? From a lowly users perspective, I would say this is more intuitive. It fits with the expected policy of the closest flag to the package taking precedence... Rob. signature.asc Description: PGP signature
On Wed, 20 Aug 2008 15:10:18 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: IANAL, but the following line is critical: it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. Given the situation as you outline it, I think the sub-section above expressly permits the binary patch. The request has been made, Adobe have not co-operated, that clause has been invoked... At least, that's how I would read it. Rob. signature.asc Description: PGP signature
On Sat, 16 Aug 2008 09:17:10 +0200 Aniruddha [EMAIL PROTECTED] wrote: Borg hasn't been updated in portage for a while despite the fact that new versions were released over a year ago (see http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest app-office/borg gets removed from portage. Why not put together an ebuild for a recent version? If there are no major changes, an ebuild will probably get it updated quickly enough, in my experience. Rob.
On Sat, 16 Aug 2008 18:42:35 +0200 Aniruddha [EMAIL PROTECTED] wrote: I've filed the bugreport (version bump) a year ago. It looks like borg has no maintainer. So maintain it. You don't need to be a dev to write an ebuild, and there are enough devs who are happy to throw an eye over user donated ebuilds and commit them to the tree... Removing a package from portage simply because no one has commited the up-to-date version you want is silly. If the only problem is no version bumping, provide the ebuild. Someone will commit it. I've done that for a few packages, it's not hard. I don't know anything about borg specifically, but as a user, I would not want to see packages being removed from portage just because the devs are too busy to write version bump ebuilds. Rob.
On Fri, 18 Jul 2008 16:30:20 +0200 Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote: IMHO it would be better to teach users to explicitly specify '@system' during updates, e.g. `emerge -uDN @system @world`. Why not just re-instate the implicit dependency of world on system? Rob. -- firstname.lastname@example.org mailing list
On Fri, 18 Jul 2008 15:16:18 +0100 Sébastien Fabbro [EMAIL PROTECTED] wrote: There was some attempts a few years ago for rolling up a full Gentoo with icc, but it hit several problems if I recall. Now both icc and gcc have improved since then. Including needing package specific CFLAGS because some packages in @system needed mutually exclusive flag settings. I'll see if I can dig up the link for an old blog on the topic later. -- email@example.com mailing list
On Fri, 18 Jul 2008 11:34:11 +0900 Luca Barbato [EMAIL PROTECTED] wrote: Adam Stylinski wrote: The intel C Compiler (icc) icc, xlc, llvm, sunstudio could be interesting fields of discovery. Which are the pitfalls of using icc? lu If I recall correctly, needing some packages compiled with ICC flags set one way, and needing others compiled with the same flag set the oter way. Can it compile a kernel yet? Rob. -- firstname.lastname@example.org mailing list
On Mon, 30 Jun 2008 12:52:02 -0500 Jeremy Olexa [EMAIL PROTECTED] wrote: On a side note: How is the b-w SOP doc coming? It is obvious to me the b-w is tedious a time consuming so I would like to help every now and then but I really am not sure about the rules wrt assignment just by looking at metadata.xml. IMO, b-w'ing is something that anyone can do. I would be happy to give it a try if there is an SOP doc to follow. I may not be a dev, and I'm certainly not massively skilled technically, but if I can bw a few bugs, it's a few less for the good bw. :) Rob. -- email@example.com mailing list
On Thu, 19 Jun 2008 12:11:11 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Thursday 19 June 2008 02:43:12 Chris Gianelloni wrote: Nope. What I see as a problem is that the primary author and current de facto maintainer is so much of an asshole that he was forcibly removed from the Gentoo project, which PMS is supposed to be written for, and has ostracized (at least) one of the package manager's development team with his constant not-so-subtle attacks. Quite frankly, I'd prefer see Gentoo take control over the specification that defines the most important single feature of Gentoo and remove the non-Gentoo developers from its development. No offense, but you're not a Gentoo developer any longer and you shouldn't have a say in how *we* manage ourselves. You're more than welcome to contribute code, fork, or whatever the hell you want. This is open source, after all, but that doesn't mean you should be allowed to hold the position of power over Gentoo that you've been granted. I would like to see Gentoo grow some balls and start banning people from -dev and other media used. I don't mean temporary bans, I mean for life. Yes, it's not nice. Yes, Gentoo should be open for all and encourage participation from all. However, some people have demonstrated time and time again over quite a number of years that they wont change no matter what. These people are posionous . Slightly ironic for me to suggest this, but... It is the gentoo-dev mailing list, restrict posting to gentoo devs (i.e. only people with a @gentoo.org email address) would make a lot of sense. Rob. -- firstname.lastname@example.org mailing list
On Tue, 10 Jun 2008 02:58:54 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. Except any program using .cc or .cpp for code is liable to break on gcc, as they are C++ file extensions, and to the best of my (admittedly limited knowledge) C and C++ are distinct languages... So relying on the file extension seems to be a recipe for misunderstanding. Why limit the functionality of the package manager to rely on the file names? How do you protect the package manager from a malicious ebuild masquerading under the wrong EAPI? Relying on the file name for information is the kind of design decision we laugh at in Windows, so why adopt it here? -- email@example.com mailing list