Re: mentors.debian.net runs the debexpo code now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 17, 2011, at 12:14, Stefano Zacchiroli wrote: On Thu, Aug 11, 2011 at 07:03:03AM -0400, Asheesh Laroia wrote: Thanks to huge work by Johnny Lamb, Christoph Haas, Jan Dittberner, Kalle Söderman, Serafeim Zanikolas, David Paleino, and Paul Wise, we have had a alpha-level product called Debexpo that can replace mentors.debian.net as the place we do package review for new contributors in Debian. snip It's live: http://mentors.debian.net/ That's a great achievement! Thanks to everyone who has contributed to make it possible. As a minor nitpick, can you add to the footer a link to the code? Many Debian services could benefit from more prominent footer links to the code, to encourage patches are welcome habits and to make it clear that the code for all our services is available. (yes, in this specific case I know that the availability of debexpo code is mentioned at http://wiki.debian.org/Debexpo , but making it more readily available wouldn't hurt, would it?) Excellent point zack, there is a lot of really great tooling in Debian and people saw links to code in the footer of various tools they would likely want to start using it in their projects, hopefully improving it in the process. Regards, Jeremiah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJOS7nnAAoJEPoEpn8G2KIrxK4P/iGxibx2FhF5lZPG2bVgAPYh QirjkNUdULI31qZICGixRqG+VbF4AlFD+TVzlqLJcbpEXwgqyHVSdKE1xBMyVjWS 9zn8R/lA7AeYa3Lq+tdJhlMlJycpm5QvrUgpmxZgMlK1aFTMU8Ul2E3LDHHGNyKA kj3cTLqy6vj+Br0SaF8uzzxpZ+nVgwsFHFZdJ8YkmkVbVZpHnLEa0d7DYoyShibB /rKSC0BVjwfTl2H7b/V2H1x2HA8WclNRNZSqpgF5ysMudr8kW/s7ICDqWvUEgBEl cLFP0RkylHYToonFkjah4AzMhweb1V0aF5pj7to/ShvEjXO/ulLlwb+rC1Nideo7 6bg0TbNjYOXPFRYX8RZSerM3r5q9GYGXzGOA84QeLKKeE8lv8Y5LgZPffLSfslzE x0l+Vor3iGnnUlcrgDUitQahPdPj9hfwuptKGKya3VeWDN8tdMYESDSKYeR3/cl9 DDdcPIvamdNUc46kMCjeg3lIessGxXIN/m9Ms+GCAARicpVRF0Mdv3ShNXXhj0bi XqcZ4O+nGy8axicKAN9vGAVBPN1vhmXSj3+e7BGZn3lm3tc+z2fMGKdompSfqT4z SD3bdOqzfqaSiOF9Ha30O0VMnVV0j/LAwiUoMDZgBQFb23KAEgo+rmQArQQ/yQrZ 6ls71DhPljmxuiF41xbV =gGD2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8653b812-3516-4f47-8a69-19956de8d...@jeremiahfoster.com
Re: Does anyone care about LSB on arm?
On Wed, Jun 1, 2011 at 1:25 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: On Tue, May 31, 2011 at 5:22 PM, Wookey woo...@wookware.org wrote: In my experience anyone distributing binaries actually picks a small set of distros and builds for those explicitly, rather than relying on the LSB. Does that mean that it's not actually useful in the real world? I guess in a sense this posting is to the wrong lists; we're all free software people here who have little use for the LSB. Where do the proprietary software distributors hang out :-) They are starting to hang out in all the familiar Free Software places. :-) sooo... although the situation *right now* is that nobody in the commercial world is the slightest bit interested in LSB because they all do custom builds of complete software stacks, it could be said that *if* the free software community just dropped ready-to-go LSB standards in front of their noses, they'd quite likely use it. Circumspect and balanced as always Mr. Leighton. :) I've been to the commercial world on a temporary visa and they do in fact care about things like standards. In fact I would go so far as to say that this LSB proposal for ARM would significantly improve life for consortia like GENIVI which has members from the ARM and Intel camp. you have to remember that the majority of these companies could not put two lines of code together to save their lives. they literally have to be spoon-fed (in some cases even to the point of being told where to put the screws, let alone the software). they are usually spoon-fed by the CPU manufacturer [and in the case of MStar Semi, they won't even let *you* violate the GPL, they do it entirely for you]. so in that regard, i think it's more a case of if the free software community provides LSB across ARM, it'll get used. I agree. so in _that_ regard, the question becomes: are the efforts of the free software community better off being spent elsewhere? and what benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for ARM? forget the proprietary junkies, they'll suck anything from us that moves and not give a dime in return. In my experience there are dimes to be had, you just have to ask nicely. Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikx_3kfVh=0poP=bs_1ccmyert...@mail.gmail.com
Re: A lot of pending packages
On Jun 11, 2010, at 10:17, Andreas Marschke wrote: On Fri, 2010-06-11 at 00:58 +0200, gregor herrmann wrote: On Fri, 11 Jun 2010 06:01:27 +0800, Thomas Goirand wrote: My 2nd suggestion is coming from the Maemo platform (the OS behind the Nokia n900 that is Debian based). In Maemo, there is a devel repository that includes apps that aren't necessarily in good shape. The users know that fact when they are adding the repository which contains packages that are not necessarily as tested, and wont complain. It is difficult to correlate the Maemo experience with the Debian experience. Remember that Nokia still controls Maemo and it is not free software, there are binary blobs and other things that are proprietary. So there toolchain and work flow are different. I'm not sure I like this idea. Although I also sometimes install inoffical packages, when I look at the packages with RC bugs I'm constantly suprised about the amount of low-quality packages we already have in the archive (when poor lintian has to emit page after page of errors and warnings ...). Ironically enough, there have been calls in Maemo to follow the debian way of doing things, that is to say change the Maemo work flow so packages go into testing, etc. I understand that this new archive area would be non-offical, but still my fear is that users won't distinguish and those packages would be considered as Debian packages and might have the risk of shedding a bad light on Debian quality. Hi! I'm not a DD but I'm thinking that we could rather utilize experimental for such things. For one thing it is OBVIOUSLY NOT recommended to use packages from experimental if all you want is a stable Debian. But it is still a place to EXPERIMENT with new and yet untested packages. So new and fresh package maintainers can try themselves out in experimental rather than cross fingers that enough people found out about this _unofficial_ repository. Any objections? If so please let me know. From my experience working with Maemo, I greatly prefer the Debian quality assurance and packaging process. I think it is far more effective for producing quality software as well as enabling contributions from developers and packagers. It is has been proven effective over time and contributed to Debian's legendary stability. Any change just for the sake of change would seem to be counter-productive. If you need a sandbox to test packages, pbuilder and/or cowbuilder are very useful, and you can create your own repository with reprepro which is an excellent tool. Fundamentally altering the current path that packages take into the stable distribution should have a compelling justification, I don't currently see one provided. Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5c8e25a6-615e-4cc3-84e5-a0d393e3b...@jeremiahfoster.com
ITP: libclass-perl -- Alias for __PACKAGE__
Package: wnpp Severity: wishlist Owner: Jeremiah C. Foster jerem...@jeremiahfoster.com * Package name: libclass-perl Version : 1.00 Upstream Author : Michael G. Schwern mschw...@cpan.org * URL : http://cpan.uwinnipeg.ca/htdocs/CLASS/CLASS.html * License : GPL | Artistic Programming Lang: Perl Description : Alias for __PACKAGE__ CLASS and $CLASS are both synonyms for __PACKAGE__. Easier to type. $CLASS has the additional benefit of working in strings -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: where is /etc/hosts supposed to come from?
On Dec 31, 2009, at 15:04, Vincent Lefevre wrote: On 2009-12-31 14:10:46 +0100, Mike Hommey wrote: On Thu, Dec 31, 2009 at 02:02:36PM +0100, Vincent Lefevre wrote: POSIX says: Have we resolved where the canonical hostname is going to reside or does reside? Debian's policy manual[0] states that `hostname --fqdn` is where this information should be gathered from. Is that the canonical method? Jeremiah 0. http://www.debian.org/doc/debian-policy/ch-customized-programs.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: where is /etc/hosts supposed to come from?
On Dec 29, 2009, at 8:46, Vincent Bernat wrote: OoO En ce doux début de matinée du mardi 29 décembre 2009, vers 08:34, je disais: Details in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099. I do wonder, however, why the system hostname has to appear in /etc/hosts at all? Programs that want to find it out can read /etc/hostname directly, after all. And wtf is 'localdomain' for, anyway? A common way to get hostname is to request node name through uname, then asks for a resolution of this name. If the name does not appear in /etc/hosts, this will lead to a DNS resolution and without network, this can take a long time. And BTW, this is exactly what hostname -f does. It does not read /etc/hostname. On one of my machines apticron uses a call to hostname -f, which fails, while uname -n succeeds. Perhaps it should be a bug to use hostname -f since it unreliable? Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Dec 2, 2009, at 10:26, Sandro Tosi wrote: On Wed, Dec 2, 2009 at 10:17, Ben Finney ben+deb...@benfinney.id.au wrote: Sandro Tosi mo...@debian.org writes: This (and other) rant are a signal we should create a TEAM around any fundamental packages in Debian, and python MUST NOT be and exception. Am I the only one (together with Angus, I'd say) believing python deserves a better maintainership than the one it currently has? You are not alone. What, specifically, are you proposing should be done; to form a team to maintain python core packages (there is already a team on alioth, pkg-python, I think created for this purpose; it currently doesn't have any content in it) The perl binary currently is team maintained inside debian. This is a separate team from the perl packages team which maintains perl modules in debian. Teamwork has allowed us to maintain a huge amount of high-quality debs, as well as enjoy each others company. :) The perl binary team is relatively new, but it has some talented veterans who keep the perl binary up-to-date. I strongly recommend working with a team when contributing to debian, it is an effective way to maintain software. Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: zendframework package with or without bin package
On Sep 23, 2009, at 1:22, Raphael Geissert wrote: Frank Habermann wrote: I also want to rename the package to libphp-zendframework. biased answer: ugh, why? That reminds me some of the libfoo-bar-moo-invent-something-else-here packages we have in the archive. One possible answer to why? is that libfoo-bar-baz allows users easy access to a debian package that directly corresponds to the upstream software. In the case of a perl package on CPAN it would be called Test::File. In debian it would be called libtest-file-perl since the perl module is a library, renamed test-file in accordance with debian policy and - perl added to denote which programming language the package is written in. This allows one to have libtest-file, libtest-file-ruby, etc, without too many namespace collisions. Since a vast majority of debian perl packages are named this way, users know what to look for on a debian system simply by the upstream name. Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian-like tools in teams / early lintian stories
On Jul 20, 2009, at 20:44, martin f krafft wrote: Hey folks, As part of my research[0], I have two questions: Do you know any tools or teams using tools that, like lintian, automatically check packages (or whatever it is that the team is working on) and thereby helps to maintain a common baseline? I am not certain how relevant to your research it is, but the debian perl group uses two tools vaguely similar to lintian. The first is PET (Package Entropy Tracker) which is deployed by the debian perl group here[0] and by other groups inside debian. It is used to create something of a baseline - it compares upstream with debian packages and lists bugs as well as work in progress. The debian perl team also has a tool called 'packagecheck'[1] which checks packages, amazingly enough. :) Warm regards, Jeremiah 0. http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi 1. http://svn.debian.org/viewsvn/pkg-perl/scripts/qa/packagecheck?view=markuppathrev=39384 Also, do any of you remember stories from the early lintian days? 0. http://phd.martin-krafft.net Thank you, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the stripes on the highway began to unreel beneath her in a dizzying blur as if all those grains of sand had lost their bearings and were falling all over each other just trying to get out of the way to make room for the next moment, or instant, or tick of the clock -- mc 900 ft jesus (http://www.theendoftheworld.org/900/spider1.shtml) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mar 4, 2009, at 11:48 AM, Goswin von Brederlow wrote: joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) writes: makes libc a derived work of the program hello world? Jörg Please do read all of the mail and try to follow each step. And if you have a counter argument please first check that it isn't negated further on. The point you are not getting is that the program hello world comes under the GPL because quote [snip] So again we end up with the conclusion that the hello world program requires that both hello world source and libc must be GPL. And the same argument works for mkisofs linked against libschilly and libscg. Wow, great explanation Goswin, thanks very much. You made parts of the GPL much clearer to me. Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Dec 18, 2008, at 8:51 AM, Teemu Likonen wrote: Manoj Srivastava (2008-12-17 17:02 -0600) wrote: If there is sufficient support, we could also scrap the current vote, change our ballot, add options to it, or something, and restart the vote, but that would need a strong grass roots support (I do not think the secretary has the power to do so). I don't know if non-developers' opinions count but since from the outside Debian seems to be pretty much an open community I'll voice my opinion anyway. I've been following the firmware and voting discussion very closely and I think that changing and restarting the vote would _definitely_ be the right thing. As another non-DD but active debian packager hoping to become a DD, I would also like to voice my support, in a grassroots style, for re- structuring the general resolution(s). Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable - testing
On Dec 16, 2008, at 9:52 PM, Noah Slater wrote: To be honest, I'd prefer if Bastian applied his skills to helping a project I'm not a member of. I am not going to comment on his behaviour, your comments may very well be justified. But I do think it would do the project some good if we all learnt to embrace each others commitment levels, attitudes and opinions -- without resorting to rudeness, unkindness, or personal attacks. Well said. This is an attitude that can serve debian well. Regards, Jeremiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ITP: autodie -- Replace functions with ones that succeed or die with lexical scope
Package: wnpp Severity: wishlist Owner: Jeremiah C. Foster [EMAIL PROTECTED] * Package name: libautodie-perl Version : 1.997 Upstream Author : Paul Jamieson Fenwick [EMAIL PROTECTED] * URL : http://search.cpan.org/~pjf/autodie-1.997/lib/autodie.pm * License : GPL, ARTISTIC Programming Lang: Perl Description : Replace functions with ones that succeed or die with lexical scope The autodie pragma provides a convenient way to replace functions that normally return false on failure with equivalents that throw an exception on failure. The autodie pragma has lexical scope, meaning that functions and subroutines altered with autodie will only change their behaviour until the end of the enclosing block, file, or eval. If system is specified as an argument to autodie, then it uses IPC::System::Simple to do the heavy lifting. See the description of that module for more information. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: IPC::System::Simple -- Run commands simply, with detailed diagnostics
Package: wnpp Severity: wishlist Owner: Jeremiah C. Foster [EMAIL PROTECTED] * Package name: libipc-system-simple-perl Version : 0.16 Upstream Author : Paul Jamieson Fenwick [EMAIL PROTECTED] * URL : http://search.cpan.org/~pjf/IPC-System-Simple-0.16/lib/IPC/System/Simple.pm * License : GPL, Artistic Programming Lang: Perl Description : Run commands simply, with detailed diagnostics Calling Perl's in-built system() function is easy, determining if it was successful is hard. Let's face it, $? isn't the nicest variable in the world to play with, and even if you do check it, producing a well- formatted error string takes a lot of work. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume make-up discount
On Nov 24, 2008, at 5:13 AM, Steve Langasek wrote: - The use of the word chick in reference to females. Chick is a slightly derogatory, condescending common usage (slang) expression for a young woman. So linuxchix.org is a slightly derogatory, condescending domain name for young women involved in Linux? Or is this just an example of a gratuitous double-standard? When a term of derision, like chick is used to classify a group, it is hurtful and bigoted. But when a group embraces a term and uses it themselves, acknowledging that it is loaded with bigotry, in fact calling attention to that fact, it is a different thing. That is solely the prerogative of those who self-identify. I can think of a number of concrete examples, most obvious might be the term queer which some people use. In certain situations that term is used as an epithet of political empowerment. It may appear that it is a double standard, but it is rather a turning of the tables - taking away power from the bigot and claiming it for oneself. The double standard would be if they called other people derogatory names. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: libFOO-BAR naming convention
Hello, I vaguely recall seeing a recommendation for library packages for a particular language to follow libFOO-BAR naming convention in Debian, where FOO is the name of a library, and BAR is an arbitrary common suffix (thus, liberror-perl, or libsqlite-ocaml.) Could one point me to where this recommendation is given? In the perl policy document[0] it states: Perl module packages should be named for the primary module provided. The naming convention for module Foo::Bar is libfoo-bar-perl. Packages which include multiple modules may additionally include provides for those modules using the same convention. HTH Jeremiah [0] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packag es.html#s-package_names
libFOO-BAR naming convention
Hello, I vaguely recall seeing a recommendation for library packages for a particular language to follow libFOO-BAR naming convention in Debian, where FOO is the name of a library, and BAR is an arbitrary common suffix (thus, liberror-perl, or libsqlite-ocaml.) Could one point me to where this recommendation is given? In the perl policy document[0] it states: Perl module packages should be named for the primary module provided. The naming convention for module Foo::Bar is libfoo-bar-perl. Packages which include multiple modules may additionally include provides for those modules using the same convention. HTH Jeremiah [0] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on the Debian pkg-perl group presence at YAPC::EU 2007
On Oct 5, 2007, at 9:36 AM, Jos I. Boumans wrote: On Oct 3, 2007, at 5:59 PM, Gunnar Wolf wrote: CPANPLUS will be the main CPAN infrastructure starting with Perl 5.10 (due Real Soon Now). This has major implications for our group, specially for dh-make-perl, as we are probably duplicating work by now - Via the CPANPLUS Dist::Deb [5] infrastructure You can find the instructions to use the repository here: http://debian.pkgs.cpan.org/ These packages are built with a different prefix (cpan-) and are installed in user space on debian boxes, rather than in the official debian locations to avoid conflicts. More details on this on the above instructions page. However, the same APIs used to build the custom packages, can also be used to create 'proper' debian packages, which can go through your QA procedure before being integrated in the official releases, hopefully eliminating a lot of the tedious, repetitive work needed to release CPAN modules, allowing you to focus on the more important QA aspects. I've talked at length with Jeremiah about this, and we found that it's basically a matter of 'just doing it' to make this work, as all the needed interfaces are there. Jeremiah's been investigating how to do this best and I've offered him, and by proxy you all, my best efforts to assist him in doing so. First I want to say that Jos has been very helpful in all this. His knowledge of perl is somewhat better than my own as you might imagine so I have really tested his patience. :-) In trying to replicate the CPANPLUS cron job on my chroot environment I ran into a bug [0] which I think might be solved with dpkg-divert. I think dpkg-divert is what I want from viewing a post on perl.org [1] Like Jos, I would love to see this fixed so that cpanplus works and can be actively used to build debian packages, it seems like it would quickly open up all of CPAN to debian in an nearly automated fashion (I am aware that we will always need to have humans check the packages). I have not had a lot of time to work on this recently, largely because I have been looking for gainful employment which takes away from my real vocation as a debian perl package maintainer, so I welcome any and all co-operation and advice. Best regards, Jeremiah [0] http://rt.cpan.org/Ticket/History.html?id=29259 [1] http://use.perl.org/comments.pl? sid=37084op=Replythreshold=0commentsort=0mode=threadpid=58040 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Oct 1, 2007, at 7:59 PM, Moritz Muehlenhoff wrote: Joey Hess wrote: Surely packages.debian.org is not a good example of a site with generally few Debian users. The scenario seems more likely to me on small non-technical sites that only a few Debian unstable users are likely to visit. For special fun, try browsing from an unusual architecture; that's in the user-agent string too. http://linuxreviews.org/news/2005/01/28_0001/ This is most likely apocryphal. If there is any truth in the above link, it has been blown way out of proportion. Nobody gets arrested for using lynx, which is what that link says. There is little evidence to corroborate the story so I would dismiss this as a red herring. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Oct 4, 2007, at 11:59 AM, Mark Brown wrote: On Thu, Oct 04, 2007 at 10:41:51AM +0200, Jeremiah Foster wrote: This is most likely apocryphal. If there is any truth in the above link, it has been blown way out of proportion. Nobody gets arrested for using lynx, which is what that link says. There is little evidence to corroborate the story so I would dismiss this as a red herring. It did make mainstream sites linke the BBC: http://news.bbc.co.uk/1/hi/england/london/4195339.stm No it didn't. If you read that link carefully, you will find _no_ reference to lynx. Do not misrepresent the facts, people will become confused. The article mentioned above (and cited previously) merely talks about some one who attempted to hack a BT site. This has nothing to do with user agent strings. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic retrieval of information from qa.debian.org
On Oct 4, 2007, at 5:59 PM, Raphael Hertzog wrote: On Thu, 04 Oct 2007, David Paleino wrote: Or should I do some hacky thing with PHP? (caching info, when an user arrives see if the cache is too old, update the cache, show it) That's up to you. But cron is probably better. :-) Well, having the info in a coherent mood with the rest of the site would be better :) iframe src=http://...; / /me runs away :-) You can't run fast enough. Frames are really, really evil . . . (imagine a long flame about frames here) . . . plus you can' t bookmark them and everything you can do with frames you can do with CSS instead. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Sep 22, 2007, at 8:18 PM, Peter Eckersley wrote: On Sep 22, Marco D'Itri [EMAIL PROTECTED] wrote: On Sep 22, Peter Eckersley [EMAIL PROTECTED] wrote: This means, in practice, that many sites will be able to track Debian users by their User-Agent, even if (say) the user is blocking cookies or limiting them to a single session and is changing IP address regularly. This is highly debateable. There may be tens or thousands of users of the same package visiting a web site. I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. There is no question that many, if not all, web sites that track visitors use the UA string in some way or other. Often it is used for tracking and more commonly it is used to create work-arounds for non- standard compliance. For example IE 6 has some quirky CSS behavior that people often have to consider. Or people use the UA string with the IP and create a hash that is the 'signature' of the visitor. This of course breaks easily but it is still done. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Sep 23, 2007, at 1:39 AM, Joerg Jaspert wrote: On 11150 March 1977, Peter Eckersley wrote: This is highly debateable. There may be tens or thousands of users of the same package visiting a web site. I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. I cant believe this. Looking at the stats from packages.debian.org - U-A is the worst possible way to track users. Would be totally dumb to try something with U-A: Whether it is dumb or not, it is widely used. Same for anything matching Firefox/, has 467789 total hits, with more detail, first 15 rows we get 89003 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20061201 Firefox/2.0.0.6 (Ubuntu-feisty) 51159 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 21879 Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 11289 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/ 20061201 Firefox/2.0.0.3 (Ubuntu-feisty) 10975 Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 10217 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 8542 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/ 20061201 Firefox/2.0.0.6 (Ubuntu-feisty) 7572 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 6029 Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 5379 Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 4885 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/ 20070914 Firefox/2.0.0.7 4859 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 4606 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20070725 Firefox/2.0.0.6 4549 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/ 20070919 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6 4472 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: 1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 And thats a quick and very inaccurate way to do it. But it nicely shows that modifying your UA (or forcing others to do so) does not gain you or anyone else anything. The only effect you have is to make statistics more unusable than they already are. I think that is the stated goal. I am still not sure what the issue is from a privacy standpoint. Is it that the EFF fears that information in web server logs might point to a particular user because that user could be identified by the package number of the web browser they are using as stated in the UA string? This seems a pretty flimsy legal premise to identify someone before a court. Not least because that string is completely malleable. Furthermore, the second that package gets updated, the string will change. Packages can change frequently, at least in comparison to new versions of debian itself. Any change from upstream should bump that version string you speak of, as well as a new package inside debian (the last bit of the version string is often the version of the debian package, if the package is not debian native. i.e. the -1 ending in Debian-1.1.4-1). So the package version is a volatile string and not something that a web site analytics software tool (like yaalr for instance :) ) would use to effectively track the user. Furthermore, it seems highly unlikely that a web site would drill down so low into the UA string to get this data and use that as a unique identification. What purpose would that serve? Certainly no web site relies on the package version number of Iceweasel or Firefox to be rendered correctly, and if so they would more likely look for the version string of the software itself, ignoring any debian packaging. I could see one scenario where this might have relevance. That would be if the UA string was logged on several servers. For example, our hypothetical user goes to stealmp3.com and leaves her user string. Then she goes to hacktheNSA.org leaving her version string. She carefully refused any cookies and used different IP addresses, but the version string shows which version of the Iceweasel package she used and the authorities know that that package was only available in a two week period - coincidentally the same time as our user was surfing. The authorities (or RIAA) use this information to narrow down the network and potentially the location of the user (through geolocation perhaps, but that is also unreliable). But this scenario seems highly implausible. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
On Sep 13, 2007, at 11:33 AM, Karl Goetz wrote: On Wed, 2007-09-12 at 20:45 +0200, Roland Mas wrote: John Kelly, 2007-09-12 18:33:12 + : Again, if Debian's highly esteemed social contract is for the benefit of users, then why not let users vote? We do, actually. Those users who do show interest in influencing the course of Debian by concrete actions rather than by mailing-list trolling are entitled to vote. Others aren't. What counts as concrete actions? Here are some: packaging, documenting, filing bugs, fixing bugs. How do we know the difference? The criterion is known as the NM process. It's open to all. NM. Does this mean only packaging counts as concrete actions? If packaging is the only 'concrete action' accepted, the idea that users get a say *is* a joke. karl. So fixing a bug is a joke? No, of course not. There are so many ways to have a say in debian and change the code in debian directly that it renders your statement a non-sequitur. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Sep 7, 2007, at 11:58 AM, Edward Welbourne wrote: Please consider to maintain and/or co-maintain some free packages for the distribution and become a DD. I have asked my boss whether we can treat the time I'd need for this as my training budget allocation; I'll see how that goes ;-) And thank you for the offer to be sponsor - I'll have a look at the work-needing page to see if I find something that appeals, One quick way in might be to join a team, then you can share the burden of maintaining packages. It also provides a way to speak to experienced developers who have encountered many issues previously through the packaging team's mailing list. There are many teams, like the debian-perl team, which I am a member of. If you go to http://alioth.debian.org/ and look on the bottom right- hand corner you'll see Recently Registered Projects. Some of those are packaging teams which you can request to join. Look forward to seeing your @debian.org email address. :^) Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why no Opera?
On Sep 5, 2007, at 4:43 PM, Edward Welbourne wrote: Steffen: For a closed source release it would be lovely if you had a Debian developer amongst your Opera developers who can upload packages to the distribution. That's one of the (too many) things I've got on my todo list - get myself trained as a proper Debian developer. For the moment, I just have some scripts (mostly inherited, I've only had time to clean them up so far) that do the packaging mostly right; the scripts know more about Debian packaging than I do, though. Tollef Fog Heen directed me to http://www.debian.org/doc/manuals/maint-guide/ when he was my Ubuntu contact, so I guess I should familiarize myself with that before asking for a sponsor ! Eddy. IANDD, but I work with the debian-perl packaging team, mostly creating havoc in their subversion repository. :) I am willing to help packaging Opera because I think it might help persuade the powers that be that the Free Software ecosystem is good for software in general and that using a Free Software license for software can add to its quality and increase profits for the company that writes it. I do have reservations though, it would be nice to know that there is consideration of Free Software licensing for Opera's desktop browser. Frankly I do not see how the GPL or similar license could negatively impact the market prospects for Opera as nearly every browser is already under a Free Software license. (I'm thinking of Web-Kit and Firefox, of course IE is an exception but you do not want to be associated with them. ;^) ) I agree with others on this list who state that there is little point helping closed source software and I could not contribute to a closed source project if it were going to remain closed. I live in Gothenburg Sweden, quite near the headquarters of Opera in Oslo, and you have a development team here in Gothenburg if I am not mistaken - perhaps we could meet and talk about packaging issues? Also there is going to be a Free Software conference in Gothenburg, perhaps Opera is interested in attending / participating (if you or someone from Opera is not already)? We have an exciting roster of speakers lined up with some interesting people from the Free Software world and the entire conference is partly sponsored by the Free Software Foundation Europe. I'll relate more to your email address when the press release is out if you wish, don't want people mad at me for advertising on this list. :) Apologies in advance if this mail is off-topic, which it largely appears to be. I will continue any thread that is not germane off list. Kind regards, Jeremiah Foster [EMAIL PROTECTED] --- Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
On Aug 19, 2007, at 2:24 AM, Luca Brivio wrote: Alle mer 15 agosto 2007, martin f krafft ha scritto: also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.08.10.1746 +0200]: Martin Krafft and I jointly gave a talk at Debconf about use of distributed version control systems for Debian packages (this is the quilt/dpatch/other dimension); I would be happy to help documenting that aspect. And I would be happy to contribute to any Debian Packaging Handbook effort, though I can't really write much these days. But I am always up for a chat, live, on IRC, via Email, or on the phone. Manoj and Martin, thank you. :-) I also can't write much by myself, just because my knowledge is so little, but I'm willing to contribute by now in several ways to such efforts (ATM, in my little spare time). Manoj, please don't hesitate to edit that wiki page (and, at your choice, create new pages!). I think this is a terrific idea and would be an excellent compliment to the existing documentation. My father taught English for years so please excuse my rather pedantic editing of the wiki but hopefully that type of editing can help create clarity for new package maintainers and other developers. I am part of the debian-perl team and will try to bring in specific information regarding perl packages as well, unless people think that specific packaging team information is too specialized for this particular wiki page? As someone actually interested in documentation and with a bit of free time, I will try to contribute as much as possible. Regards, Jeremiah Foster [EMAIL PROTECTED] --- Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcdk-perl 4.9.10-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Aug 2007 12:39:04 + Source: libcdk-perl Binary: libcdk-perl Architecture: source i386 Version: 4.9.10-2 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Jeremiah Foster [EMAIL PROTECTED] Description: libcdk-perl - Perl interface for a curses widget library Closes: 279778 Changes: libcdk-perl (4.9.10-2) unstable; urgency=low . * Adopted orphaned package for Debian Perl Group (Closes: #279778) * Added myself to Uploaders * Do not ignore $(MAKE) clean errors in debian/rules * Corrected Homepage in debian/control * Removed emtpy /usr/share/perl5 * Fixed debian/watch * Bumped debhelper version in debian/compat to 5 * Changed to = in Build-Depends * Updated Standards-Version to 3.7.2 from 3.6.2 (no changes) Files: 5785c3980d4439f029ad5c84bca70b80 817 perl optional libcdk-perl_4.9.10-2.dsc 3ae6c10dc801936f8c428f79916aa096 3488 perl optional libcdk-perl_4.9.10-2.diff.gz 491d2504944528d1d04814f709b343b9 227132 perl optional libcdk-perl_4.9.10-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGwa5FHqjlqpcl9jsRAgBBAJ0a0cDAXjv22N6Iisq77Jdgajf+MACfU69w 8R0V9D1aPuGLrJ0KlZg+/Sc= =M7Ry -END PGP SIGNATURE- Accepted: libcdk-perl_4.9.10-2.diff.gz to pool/main/libc/libcdk-perl/libcdk-perl_4.9.10-2.diff.gz libcdk-perl_4.9.10-2.dsc to pool/main/libc/libcdk-perl/libcdk-perl_4.9.10-2.dsc libcdk-perl_4.9.10-2_i386.deb to pool/main/libc/libcdk-perl/libcdk-perl_4.9.10-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libemail-simple-perl 2.003-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 14 Aug 2007 16:34:41 + Source: libemail-simple-perl Binary: libemail-simple-perl Architecture: source all Version: 2.003-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Jeremiah Foster [EMAIL PROTECTED] Description: libemail-simple-perl - Simple parsing of RFC2822 message format and headers Changes: libemail-simple-perl (2.003-1) unstable; urgency=low . * New upstream release * Added myself to uploaders Files: bb1659b163ee2bc8beb66cf4322929e4 1096 perl optional libemail-simple-perl_2.003-1.dsc 29e8cd6961fa690f016fa9789cbf8502 28677 perl optional libemail-simple-perl_2.003.orig.tar.gz 87bfb1cfccdd61e8828783e173c6c84b 2680 perl optional libemail-simple-perl_2.003-1.diff.gz d9500dad315031c2f1a1f85d7a89c56d 19516 perl optional libemail-simple-perl_2.003-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGwdpQHqjlqpcl9jsRAl4EAJ9dgvoGJbKloutOamUgksscSxyVSwCeMwAo DUkuXBCerLWBHrQMc9u5PFE= =406I -END PGP SIGNATURE- Accepted: libemail-simple-perl_2.003-1.diff.gz to pool/main/libe/libemail-simple-perl/libemail-simple-perl_2.003-1.diff.gz libemail-simple-perl_2.003-1.dsc to pool/main/libe/libemail-simple-perl/libemail-simple-perl_2.003-1.dsc libemail-simple-perl_2.003-1_all.deb to pool/main/libe/libemail-simple-perl/libemail-simple-perl_2.003-1_all.deb libemail-simple-perl_2.003.orig.tar.gz to pool/main/libe/libemail-simple-perl/libemail-simple-perl_2.003.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
Can't Canonical devote resources to better Ubuntu's contribution to debian? This seems like a reasonable request since Canonical crows about how they are the number one linux distro and they have excellent support, but surely the reliability of their product rests upon the reliability of debian. Can Canonical allocate paid positions for debian developers to integrate Ubuntu patches back into debian? These would be debian developers tasked with developing fixes for debian from Ubuntu not beholden to any business model or corporate creed. The allocation of resources might assuage some of the smoldering resentment harbored by DDs towards Canonical. Jeremiah
Re: Canonical's business model
On Wed, 2006-01-11 at 10:25 +0100, Jan Nieuwenhuizen wrote: Thomas Bushnell writes: No, I think it's because Ubuntu doesn't cooperate well with Debian, while pretending to cooperate. Could you be more explicit? I know there has been concern about Ubuntu amongst debian developers, and that Mark Shuttleworth has some doubts about working with DCC, although he is rather vague in my opinion. But what are the problems with Ubuntu? Is it an unecessary fork? Or is it not contributing back its changes to debian software? Thanks, Jeremiah
