Bug#703483: ITP: libmessage-passing-perl -- simple way of doing messaging
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libmessage-passing-perl Version : 0.111 Upstream Author : Tomas (t0m) Doran * URL : http://search.cpan.org/dist/Message-Passing/ * License : AGPL-3 Programming Lang: Perl Description : simple way of doing messaging Message::Passing is a library for building high performance, loosely coupled and reliable/reseliant applications, structured as small services which communicate over the network by passing messages. -- 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/20130320081125.25473.4723.report...@auryn.jones.dk
Re: Public service announcement about dependencies on gawk
Hello,
On Tue, 19 Mar 2013 23:44:22 +
"brian m. carlson" wrote:
> > Well, as far as I know, mawk has some sort of terrible UTF-8
> > support, so it's a no way for many applications.
> Could you please explain? And if you haven't filed a bug report,
> could you please do so? Searching Google, the only UTF-8-related
> bugs I found are bugs mandated by POSIX (and one that updating mawk
> to 1.3.4 would fix).
$ echo привет | mawk '{ print length($0) }'
12
$ echo привет | gawk '{ print length($0) }'
6
$ echo привет | mawk '{ printf substr($0, 1, 1) }' | hd
d0|.|
0001
I don't think it's mandated by POSIX (or is it?). Anyway, it's obviously
not what most of the applications want.
> Also, my original post was inspired by the fact that most packages
> depending on gawk invoke "awk" as their binary. In that case, the
> dependency is wrong and unnecessary.
I just always put #!/usr/bin/gawk -f in the beginning of the file and
declare an explicit dependency on gawk. And also, I don't support
running those scriptf on broken awk implementations.
--
WBR, Andrew
signature.asc
Description: PGP signature
Bug#703488: ITP: libpackage-variant-perl -- parameterizable packages
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libpackage-variant-perl Version : 1.001002 Upstream Author : Matt S. Trout (cpan:MSTROUT) * URL : http://search.cpan.org/dist/Package-Variant/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : parameterizable packages Package::Variant allows you to build packages that return different variations depending on what parameters are given. . Users of your package will receive a subroutine able to take parameters and return the name of a suitable variant package. The implmentation does not care about what kind of package it builds. -- 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/20130320093813.32470.7280.report...@auryn.jones.dk
Bug#703491: ITP: libanyevent-handle-udp-perl -- client/server UDP handles for AnyEvent
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libanyevent-handle-udp-perl Version : 0.039 Upstream Author : Leon Timmermans * URL : http://search.cpan.org/dist/AnyEvent-Handle-UDP/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : client/server UDP handles for AnyEvent AnyEvent::Handle::UDP is an abstraction around UDP sockets for use with AnyEvent. -- 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/20130320095628.7477.63106.report...@auryn.jones.dk
sprezzos apt-show-rewrite complete (report + numbers)
This is a followup to my post to debian-devel, debian-derivatives, deity,
and sprezzos-dev last Monday entitled "apt-show-versions rewrite". This
post is strictly informative, and does not advocate any policy.
Documentation has been substantially embeefened, including design notes:
https://www.sprezzatech.com/wiki/index.php/Raptorial
https://github.com/dankamongmen/raptorial
rapt-show-versions(1), part of the RAPTORIAL suite, has become
feature-equivalent to the native apt-show-versions(1) tool, as predicted.
Despite fleshing out the features, I've managed to retain its speed.
[recombinator](0) $ ./rapt-show-versions -h
rapt-show-versions v0.1.5 by nick black
invoked as /home/dank/raptorial/.libs/lt-rapt-show-versions
usage: rapt-show-versions [ options ] packageregex
options:
-s|--status-file= Status file (def: /var/lib/dpkg/status)
-l|--list-dir= List directory (def: /var/lib/apt/lists)
-a|--allversionsPrint all available versions
-h|--help Display this usage summary
[recombinator](0) $
Anyone who was offended by discussion "without the code written" last
week ought hopefully be able to join in without bias now. The entirety of
the codebase, including the common libraptorial(3) library, is 1650 lines
of heavily-commented POSIX C:
[recombinator](0) $ wc -l src/bin/rapt-show-versions.c src/lib/*[ch]
217 src/bin/rapt-show-versions.c
233 src/lib/aac.c
31 src/lib/aac.h
96 src/lib/config.h
898 src/lib/packages.c
12 src/lib/paths.c
163 src/lib/raptorial.h
1650 total
[recombinator](0) $
All modes of apt-show-versions have been implemented:
- print packages from command line arguments, and status/upgrade info
- print all installed package, and status/upgrade info
- print all package versions using either of these two modes
And now, the timings [drumroll]
I am testing on two machines, a Core i7 2600K quadcore with HyperThreading,
overclocked to 5.0GHz ("skynet"), and a Core 2 Duo 6600 at stock 2.4GHz
("recombinator"). I ran each mode 10 times with each binary on each machine,
without interleaving. As the working set of each binary can be kept easily
within page cache on either machine, these tests probably do not reflect true
disk i/o. Disk I/O would be expected to only help RAPTORIAL relative to
apt-show-versions, given that RAPTORIAL will issue its disk reads in parallel,
rather than sequentially, and that they can all fit in page cache. These tests
use RAPTORIAL 0.1.5, Libblossom 1.2.2, and the native SprezzOS APT databases of
the machines.
Case 1: Print selected packages and status/upgrade info
Quadcore:
[skynet](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%ems real %Ums user
%P util" ./rapt-show-versions apt raptorial > /dev/null ; done
0.09ms real 0.21ms user 234% util
0.10ms real 0.22ms user 245% util
0.11ms real 0.22ms user 227% util
0.10ms real 0.23ms user 242% util
0.10ms real 0.22ms user 249% util
0.11ms real 0.24ms user 225% util
0.14ms real 0.30ms user 230% util
0.11ms real 0.24ms user 233% util
0.10ms real 0.25ms user 250% util
0.13ms real 0.29ms user 238% util
[skynet](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%ems real %Ums user
%P util" apt-show-versions apt raptorial > /dev/null ; done
0.36ms real 0.32ms user 97% util
0.35ms real 0.32ms user 98% util
0.35ms real 0.34ms user 98% util
0.36ms real 0.34ms user 97% util
0.36ms real 0.33ms user 97% util
0.35ms real 0.33ms user 97% util
0.37ms real 0.34ms user 97% util
0.35ms real 0.31ms user 97% util
0.36ms real 0.34ms user 97% util
0.35ms real 0.33ms user 98% util
[skynet](0) $
Dualcore:
[recombinator](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%es real %Us
user %P util" apt-show-versions apt raptorial > /dev/null ; done
0.52s real 0.48s user 98% util
0.52s real 0.42s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.44s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.46s user 97% util
0.52s real 0.48s user 97% util
0.51s real 0.45s user 98% util
0.52s real 0.50s user 97% util
0.52s real 0.44s user 97% util
[recombinator](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%es real %Us
user %P util" ./rapt-show-versions apt raptorial > /dev/null ; done
0.16s real 0.26s user 164% util
0.15s real 0.26s user 165% util
0.15s real 0.24s user 164% util
0.15s real 0.24s user 165% util
0.15s real 0.24s user 165% util
0.14s real 0.24s user 174% util
0.14s real 0.25s user 175% util
0.16s real 0.26s user 159% util
0.15s real 0.25s user 169% util
0.15s real 0.24s user 163% util
[recombinator](0) $
Call it 13ms vs 36ms on the quadcore and 15ms vs 51ms on the dualcore.
Quadcore winner: RAPTORIAL at 36% running time
Dualcore winner: RAPTORIAL at 29% running time
Champion: RAPTORIAL
Case 2: Print all installed packages and status/upgrade info
Quadcore:
[skynet](0) $ for i in `seq 1 10` ; do /usr/bin/time -f "%es real %Us user %P
util" apt-show-versions >
Bug#703501: ITP: libdata-record-perl -- "split" on steroids
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libdata-record-perl Version : 0.02 Upstream Author : Curtis "Ovid" Poe * URL : http://search.cpan.org/dist/Data-Record/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : "split" on steroids Sometimes we need data split into records and a simple split on the input record separator (C<$/>) or some other value fails because the values we're splitting on may allowed in other parts of the data. Perhaps they're quoted. Perhaps they're embedded in other data which should not be split up. . Data::Record allows you to specify what you wish to split the data on, but also speficy an "unless" regular expression. If the text in question matches the "unless" regex, it will not be split there. This allows us to do things like split on newlines unless newlines are embedded in quotes. -- 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/20130320112207.2554.15739.report...@auryn.jones.dk
Bug#703502: ITP: libmoox-options-perl -- add option keywords to your object (Mo/Moo/Moose)
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libmoox-options-perl Version : 3.77 Upstream Author : celogeek * URL : http://search.cpan.org/dist/MooX-Options/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : add option keywords to your object (Mo/Moo/Moose) MooX::Options will add "option" which act as "has" but support additional feature for getopt. . You will have "new_with_options" to instanciate new object for command line. -- 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/20130320114539.13851.50230.report...@auryn.jones.dk
Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: re2 Version : 20130115 Upstream Author : Stefano Rivera * URL : http://code.google.com/p/re2 * License : BSD-3 Programming Lang: C++ Description : fast, safe C++ regular expression library RE2 is a fast, safe, thread-friendly alternative to backtracking regular expression engines like those used in PCRE, Perl, and Python. It is a C++ library. Backtracking engines are typically full of features and convenient syntactic sugar but can be forced into taking exponential amounts of time on even small inputs. RE2 uses automata theory to guarantee that regular expression searches run in time linear in the size of the input. RE2 implements memory limits, so that searches can be constrained to a fixed amount of memory; RE2 is engineered to use a small fixed C++ stack footprint no matter what inputs or regular expressions it must process; thus RE2 is useful in multithreaded environments where thread stacks cannot grow arbitrarily large. -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If there were no counterfactuals, this sentence would not have been paradoxical. signature.asc Description: Digital signature
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
On 20.03.2013 12:21, Peter Pentchev wrote: * Package name: re2 Version : 20130115 Upstream Author : Stefano Rivera This appears to have been in the archive for a couple of years already - http://packages.qa.debian.org/r/re2.html Regards, Adam -- 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/6d38369df1f3e3bd2fe0d66dda4a1...@mail.adsl.funky-badger.org
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
Hello, On 20 March 2013 13:38, Adam D. Barratt wrote: > This appears to have been in the archive for a couple of years already - > http://packages.qa.debian.org/r/re2.html I wonder why is it still in experimental. Maybe it's worth re-uploading it to unstable? -- WBR, Andrew -- 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/camb-mayutf0kuasjybwdughdjlqhc0w3se6k3_rtj8c-jxb...@mail.gmail.com
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
Andrew Shadura writes: > On 20 March 2013 13:38, Adam D. Barratt wrote: >> This appears to have been in the archive for a couple of years already - >> http://packages.qa.debian.org/r/re2.html > > I wonder why is it still in experimental. Maybe it's worth > re-uploading it to unstable? bugs.debian.org/598990 > re2 will live as a static-only library in experimental until upstream > decides that stable ABIs are nice to have. -- 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/87li9inoyw@mitoraj.siccegge.de
Re: sprezzos apt-show-rewrite complete (report + numbers)
On 20 Mar 2013 05:33, "nick black" wrote:
>
>
>
> I am testing on two machines, a Core i7 2600K quadcore with
HyperThreading,
> overclocked to 5.0GHz ("skynet"), and a Core 2 Duo 6600 at stock 2.4GHz
> ("recombinator"). I ran each mode 10 times with each binary on each
machine,
> without interleaving. As the working set of each binary can be kept easily
> within page cache on either machine, these tests probably do not reflect
true
> disk i/o. Disk I/O would be expected to only help RAPTORIAL relative to
> apt-show-versions, given that RAPTORIAL will issue its disk reads in
parallel,
> rather than sequentially, and that they can all fit in page cache. These
tests
> use RAPTORIAL 0.1.5, Libblossom 1.2.2, and the native SprezzOS APT
databases of
> the machines.
There is no need to guess... Us the drop-cache proc file to trigger I/O.
-Rob
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
On Wed, 20 Mar 2013 14:59:32 +0100 Andrew Shadura wrote: > On 20 March 2013 13:38, Adam D. Barratt wrote: > > This appears to have been in the archive for a couple of years already - > > http://packages.qa.debian.org/r/re2.html > > I wonder why is it still in experimental. Maybe it's worth > re-uploading it to unstable? This may help explain why: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591935#5 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpSHtGOig8Pa.pgp Description: PGP signature
Re: bugs.debian.org: something's wrong...
Hi, On Montag, 18. März 2013, Wouter Verhelst wrote: > > Now it's appearently back online, but a web tracking has been > > added, as seen in #703298. That's disgusting. > It's not tracking, it's showing an avatar. That's not quite the same thing. this is not tracking, those are facebook like buttons?!? Seriously, (I havent realized before) these embedded images from gravatar.com *are* webbugs, allowing automation.com to track BTS usage. I too find this totally unacceptable default (to have this enabled by default with just the not even yet implemented option to opt-out). Before filing a serious bug about this, I'd like to get some feedback what other think. (Too tired after traveling yesterday..) And, I feel really sorry for Don that this feature which looked really nice at first sight has turned out to be so, aeh, difficult. cheers, Holger -- 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/201303201046.04610.hol...@layer-acht.org
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
On 20.03.2013 13:59, Andrew Shadura wrote: On 20 March 2013 13:38, Adam D. Barratt wrote: This appears to have been in the archive for a couple of years already - http://packages.qa.debian.org/r/re2.html I wonder why is it still in experimental. Maybe it's worth re-uploading it to unstable? It was removed from unstable due to a lack of ABI stability - see #598990. In terms of future plans, it's probably worth asking the maintainer... :-) Regards, Adam -- 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/e790e3650e036da8cc8f52227e0b9...@mail.adsl.funky-badger.org
Bug#703523: ITP: libstring-crc-cksum-perl -- Perl extension for calculating cksum-compatible checksums
Package: wnpp Severity: wishlist Owner: "Ernesto Hernández-Novich (USB)" * Package name: libstring-crc-cksum-perl Version : 0.91 Upstream Author : Andrew Clarke * URL : http://search.cpan.org/dist/String-CRC-Cksum/ * License : Artistic Programming Lang: Perl Description : Perl extension for calculating cksum-compatible checksums String::CRC::Cksum calculates a 32 bit CRC, generating the same CRC value as the POSIX cksum program. If called in a list context, returns the length of the data object as well, which is useful for fully emulating the cksum program. The returned checksum will always be a non-negative integral number in the range 0..2^32-1. -- 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/20130320152530.16615.4834.report...@trillian.ius.cc
Re: bugs.debian.org: something's wrong...
Hi, On Wed, Mar 20, 2013 at 10:46 AM, Holger Levsen wrote: > Hi, > > On Montag, 18. März 2013, Wouter Verhelst wrote: >> > Now it's appearently back online, but a web tracking has been >> > added, as seen in #703298. That's disgusting. >> It's not tracking, it's showing an avatar. That's not quite the same thing. > > this is not tracking, those are facebook like buttons?!? > > Seriously, (I havent realized before) these embedded images from gravatar.com > *are* webbugs, allowing automation.com to track BTS usage. > > I too find this totally unacceptable default (to have this enabled by default > with just the not even yet implemented option to opt-out). > > Before filing a serious bug about this, I'd like to get some feedback what > other think. (Too tired after traveling yesterday..) I would have much preferred to have this disabled by default. In short: I don't see the BTS as a social website and thus I don't quite see the value added by the pictures. To the contrary, I see them as possibly causing prejudice based on look and getting in the way of the - perhaps too romantic - view of meritocracy in action. But I don't understand that one could argue that: - If you chose to have your picture on Gravatar, you chose to go public and it's ok, and - You can use a different email address to interact with the BTS. The above are fine for the future. But the fact is that it's enabled "retroactively" and "on" by default. That's the part that makes me the most uncomfortable. > And, I feel really sorry for Don that this feature which looked really nice at > first sight has turned out to be so, aeh, difficult. Same here. I've no doubt that was done with good intentions, thinking that was a cool feature. Cheers, -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca) Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca) -- 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/CAJNNDm=zjoy6xqnsrjni+jo_yiyxu63gfgw1ofp_xisz__q...@mail.gmail.com
Re: Bug#703507: ITP: re2 -- fast, safe C++ regular expression library
On Wed, Mar 20, 2013 at 12:38:11PM +, Adam D. Barratt wrote: > On 20.03.2013 12:21, Peter Pentchev wrote: > >* Package name: re2 > > Version : 20130115 > > Upstream Author : Stefano Rivera > > This appears to have been in the archive for a couple of years > already - http://packages.qa.debian.org/r/re2.html Ah oops! Yeah, there were some problems with a local Debian mirror that caused me to take "experimental" out for a couple of days - and see where it got me! Thanks a lot - and sorry for the noise :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I had to translate this sentence into English because I could not read the original Sanskrit. signature.asc Description: Digital signature
Re: bugs.debian.org: something's wrong...
On 03/20/2013 11:54 PM, Pascal Giard wrote: > I would have much preferred to have this disabled by default. I would have preferred the picture thing to be hosted without gravatar support (libravatar is hosted by a DD, and you can host your avatar yourself if you like to). > In short: > I don't see the BTS as a social website I do feel like it's a social thing, and that you do interact with humans. > and thus I don't quite see the > value added by the pictures. I do. > To the contrary, I see them as possibly causing prejudice based on > look Nobody forces anyone to upload a picture in libravatar. Nobody forces anyone to upload *only* "real" picture of you on libravatar, you may well send a picture of mickey mouse (well, if like me you believe that 100 years of copyright for Disney is more than enough...). > and getting in the way of the - perhaps too romantic - view of > meritocracy in action. I think it's just fun ! > The above are fine for the future. But the fact is that it's enabled > "retroactively" and "on" by default. I think it's like facebook. If you decide to post something on a public site, don't complain it is later on ... public! > That's the part that makes me the most uncomfortable. Then don't upload anything to gravatar or libravatar. > Same here. I've no doubt that was done with good intentions, thinking > that was a cool feature. But *IT IS* a cool and funny feature. I'd like to keep it, if the gravatar tracking thing can be removed (I do trust the libravatar). Thomas -- 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/5149fcb6.5080...@debian.org
Re: bugs.debian.org: something's wrong...
On Wed, Mar 20, 2013 at 10:46:00AM -0400, Holger Levsen wrote: > Hi, > > On Montag, 18. März 2013, Wouter Verhelst wrote: > > > Now it's appearently back online, but a web tracking has been > > > added, as seen in #703298. That's disgusting. > > It's not tracking, it's showing an avatar. That's not quite the same thing. > > this is not tracking, those are facebook like buttons?!? > > Seriously, (I havent realized before) these embedded images from gravatar.com > *are* webbugs, allowing automation.com to track BTS usage. > > I too find this totally unacceptable default (to have this enabled by default > with just the not even yet implemented option to opt-out). > > Before filing a serious bug about this, I'd like to get some feedback what > other think. (Too tired after traveling yesterday..) Since you ask, I suggest to disable it now and enable it later only after opt-in. Regards, Bart Martens -- 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/20130320181719.gg28...@master.debian.org
Re: bugs.debian.org: something's wrong...
On Wed, Mar 20, 2013 at 2:15 PM, Thomas Goirand wrote: > > and thus I don't quite see the > > value added by the pictures. > I do. I still don't. But I can live with it. > Nobody forces anyone to upload a picture in libravatar. > > Nobody forces anyone to upload *only* "real" picture of > you on libravatar, you may well send a picture of mickey > mouse (well, if like me you believe that 100 years of > copyright for Disney is more than enough...). I totally understand that argument. I managed to mistype a sentence in my previous email. You should have read: "But I _do_ understand that one could argue that:". So "do" instead of "don't". > Then don't upload anything to gravatar or libravatar. Oh, I'm not concerned for myself. I decided to put a real picture of myself on gravatar long before this change and I live very well with it. Perhaps I should simply let those with objections speak for themselves. -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca) Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca) -- 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/cajnndmnsca1vdtfuoiuk8md3_aeperrgs8tdjgzzn8t+cz4...@mail.gmail.com
Re: bugs.debian.org: something's wrong...
On 20.03.2013 19:15, Thomas Goirand wrote: >> To the contrary, I see them as possibly causing prejudice based on >> look > > Nobody forces anyone to upload a picture in libravatar. ... which "assign[s] random color shit to [your] name" [1]. You've got the choice to use an avatar, or someone assigns one to you. Well, I'd prefer if we had other choices than that too, but on the other hand we surely got more important problems. Either way, there is a thread on debian-project and maybe we could stick with one. [1] <87hakcbfjy@gkar.ganneff.de> -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: bugs.debian.org: something's wrong...
On 2013-03-21 02:15:18 +0800 (+0800), Thomas Goirand wrote:
> On 03/20/2013 11:54 PM, Pascal Giard wrote:
> > I would have much preferred to have this disabled by default.
>
> I would have preferred the picture thing to be hosted
> without gravatar support (libravatar is hosted by a DD,
> and you can host your avatar yourself if you like to).
[...]
The bigger concern is that this is a web bug, whether it wants to be
or not. Whoever hosts any of the images being included knows the IP
address and time of every visitor to a bug report.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
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/20130320195816.gy29...@yuggoth.org
Re: bugs.debian.org: something's wrong...
Hi Arno, Arno Töll writes: > ... which "assign[s] random color shit > to [your] name" [1]. You've got the choice to use an avatar, or someone > assigns one to you. FYI, this is not a technical necessity. If called correctly, gravatar (so probably libravatar, too) can return a specific image, e.g. a transparent 1-pixel PNG, in case the user has no avatar. It just needs to be changed in the BTS code :-). -- Best regards, Michael -- 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/x6r4j9akqw@midna.zekjur.net
Re: bugs.debian.org: something's wrong...
Hi, On Mittwoch, 20. März 2013, Arno Töll wrote: > ... which "assign[s] random color shit > to [your] name" [1]. You've got the choice to use an avatar, or someone > assigns one to you. that has been fixed. > Either way, there is a > thread on debian-project and maybe we could stick with one. I actually think this is more on topic here than there. cheers, Holger -- 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/201303201625.54992.hol...@layer-acht.org
libravatar in the BTS [Re: bugs.debian.org: something's wrong...]
On Wed, 20 Mar 2013, Holger Levsen wrote: > I too find this totally unacceptable default (to have this enabled > by default with just the not even yet implemented option to > opt-out). It has already been implemented. See http://lists.debian.org/debian-devel/2013/03/msg00302.html And I will be implementing caching to address the concerns about web tracking, and more importantly, the lack of federation. See #703119 et al. Don Armstrong -- A Democracy lead by politicians and political parties, fails. http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20130320203456.gx5...@teltox.donarmstrong.com
Bug#703579: ITP: PCL (Point Cloud Library) -- Framework for 3D point clouds data processing
Package: wnpp Severity: wishlist Owner: Paride Legovini * Package name: PCL (Point Cloud Library) Version : 1.6 Upstream Author : Open Perception, Inc. (http://www.openperception.org/) * URL : http://www.pointclouds.org/ * License : BSD-3-clause Programming Lang: C++ Description : Framework for 3D point clouds data processing PCL (Point Cloud Library) is a standalone open-source framework including numerous state-of-the art algorithms for n-dimensional point clouds and 3D geometry processing. The library contains algorithms for filtering, feature estimation, surface reconstruction, registration, model fitting, and segmentation. PCL is developed by a large consortium of researchers and engineers around the world. It is written in C++ and released under the BSD license. -- 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/20130321015135.20897.11741.report...@helix.invasodromo.lan
Re: bugs.debian.org: something's wrong...
On Thu, Mar 21, 2013 at 3:58 AM, Jeremy Stanley wrote: > The bigger concern is that this is a web bug, whether it wants to be > or not. Whoever hosts any of the images being included knows the IP > address and time of every visitor to a bug report. Only if you use a web browser that is obeying other people's web servers instead of obeying you the user. I suggest that everyone in this thread should fix their web browser so that it obeys them, as I have done. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6EOi_a2y+8=2=bpx1m11_x3gnyfuhpqzt4cuocal-b...@mail.gmail.com
Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]
On Wed, Mar 20, 2013 at 01:34:56PM -0700, Don Armstrong wrote: > On Wed, 20 Mar 2013, Holger Levsen wrote: > > I too find this totally unacceptable default (to have this enabled > > by default with just the not even yet implemented option to > > opt-out). > > It has already been implemented. See > http://lists.debian.org/debian-devel/2013/03/msg00302.html I don't think that adding avatar=no is what was meant with opt-out, at least not what I meant with opt-in. I meant that avatars should not be retrieved for anyone except for bts users who chose (opt-in) to be on a list maintained on a debian machine. > > And I will be implementing caching to address the concerns about web > tracking, and more importantly, the lack of federation. See #703119 et > al. The caching is a good idea, although I don't think it fully solves the discussed concerns. Anyhow thanks for your excellent work on the bts. The bts is really important to Debian, so your contributions are making a big difference for Debian. Regards, Bart Martens -- 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/20130321062355.gf28...@master.debian.org
Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]
On Thu, 21 Mar 2013, Bart Martens wrote: > The caching is a good idea, although I don't think it fully solves > the discussed concerns. Which concerns discussed doesn't it address? 1. Caching on the BTS side means that no one besides bugs.debian.org knows which bugs you are viewing. 2. The only other concern is whether the image is appropriate or somehow exploits bugs in the image renderer, but there are ways of dealing with that (such as only allowing certain size images, and converting them in place and allowing for domains to be blacklisted if necessary.) [Plus, it's not like we don't already allow uploading fairly arbitrary content to the BTS.] Don Armstrong -- What prison taught me was that some people are born into a life where they're going to be subjected to intense life experiences and personal tragedy on an almost daily basis. [...] I don't think you get enlightenment after something like that. I think all anyone really wants, if they're honest with themselves, is a quiet, easy life surrounded by people that love them. Anything else is conceit[ed]. -- OP from 99chan http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20130321064047.gf5...@teltox.donarmstrong.com
