default messaging/VoIP client for Debian 8/Jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'd like to propose that Jitsi be considered as the default messaging, VoIP and webcam client for the next major Debian release (jessie). This would mean it is installed by default in a desktop install and it is the default handler for sip: and xmpp: URIs. Currently, Empathy is installed by default There are several reasons I am suggesting this and it is possible that Empathy could address some of them before the release freeze in November but we should be completely prepared to go with Jitsi if they continue to be the leaders in this area. * Google dependency: Empathy is hard-coded[1] to use Google media relay (TURN) servers for NAT traversal. It can't be configured to use a TURN server on a Debian server, even though we have three TURN servers packaged for our users. This means that when Google shifts the goal posts (as they already did, ditching true XMPP to promote Google hangouts[2]) or when they have a service outage[3] then Debian's users are left high and dry. There are also privacy concerns, Google themselves report a 120% increase in the amount of data they officially and knowingly give to their government[4]. Jitsi supports any user-specified TURN server for XMPP and they plan to support TURN for SIP too. * Convenient NAPTR discovery. Empathy does not autoconfigure itself with services (such as Debian.org's own SIP proxy) that have NAPTR records in DNS[5]. With Jitsi, this just works. * WebRTC integration (calling from browsers to Jitsi desktop). This depends on new media stream features (e.g. DTLS-SRTP and AVPF) that are not supported in Empathy yet[6]. * ZRTP - peer to peer encryption, like PGP for VoIP. Once again, it has been in Jitsi for ages but is not in Empathy[7] * Upstream. Both Empathy and Jitsi upstreams are very good developers. Jitsi seem to have an edge though. Just look at how quickly they turned out the JitMeet multi-party video conferencing solution[8] for WebRTC browsers - it is a phenomenal achievement and delivered in good time to help free software gain traction in the emerging WebRTC space before any vested interests try to monopolize the technology. The whole real-time communications (RTC) space is very important for free software in general. If it fails to work conveniently and reliably, the peer pressure of family and friends pull people back into dangerous non-free solutions. Some of these solutions are a threat to the whole concept of free software on mainstream desktops. With all the recent attention on communications privacy, there has never been a better time for Debian to try and fill this gap with a solution like Jitsi on the front-end and the various free SIP/XMPP/TURN servers in the back-end. To put it simply, the Jitsi team are blazing a trail in this area and a Debian initiative to install Jitsi on every desktop will give them more momentum and ensure more people can talk to each other in line with our agreed definition of freedom. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704234 2. https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging 3. http://www.cnet.com/news/outage-hits-google-talk-hangouts/ 4. http://www.bbc.com/news/technology-26786593 5. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736149#10 6. http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html 7. https://bugzilla.gnome.org/show_bug.cgi?id=589778 8. https://jitsi.org/Projects/JitMeet -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTN94bAAoJEOm1uwJp1aqDRkgP/0jKZ2GfrIIxTy70p8b5PFDo e9KKTkDTEINpwAdeyP2BpX5BLTEtuzgRZh+AQi7HZHbPAfCq8Cf24FjJfQyY0AgC jDpzuX05ahNExPbpWOW4OGwinJ4S3kaPG5/o/IQC66y9tUdH0Lrh8AIvmvEgIJ9j K0Nb669heMCdrn77ihbk9MtJlGvCE1KVOnrg+SrQLSEE1HsXk8iTXlyoGfE2T/ho 24PxrKwhnjFoojIe0c2f/cMTMOL3prHyndYZB/Q86AiKExCow+6WtSwzb3po153i USHFS/e+lA1+GquJXYiJq1FMUB+HiPaLer241yodqr7R5mqSD4igiF7/oQzywYId OcxjqaLZVGxcqd5s+hmv2vCf3FXC21uDeBULZYP6TulELPGK1i6EJPpg0JqiWZbD rE8Zs1a9W0zLOamc6jpMMx/rMC1Pml00Y69ek/c1uXW3YfxaEsiyV4cv+i99XU5B hkkmQf5DbV+P3nQqblIkNPTydWlN/spsaLitWQsfr0cG3l4ZH+zCHKoNVl87g7Sy CCv8FsnyhJy2wOdB//1OreDRmNK28UWwv+GM3Kf2/BI9oylbBmGbN8q3luy8KlQd NHAledDQ0c2xEnCK0VF5NtOCQyY+cQriPcTUt1MSpq+m2mnqYj40VqBiDJITf/zz xF+ESMftdl5n0cqmMNQJ =UwwC -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: https://lists.debian.org/5337de1f.9000...@pocock.pro
Re: FTPMaster position statement about package contents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/03/14 22:14, Steve Langasek wrote: > On Fri, Mar 28, 2014 at 09:49:44PM +0100, Bas Wijnen wrote: >> On Thu, Mar 27, 2014 at 07:41:50PM -0700, Steve Langasek wrote: >>> I can understand the ftp team's desire to sidestep any moral >>> questions here, but in the process I think your guidelines have >>> wound up vague and overbroad, as they suggest that as a project >>> we will never take a stand for anything but only do what's >>> safe. > >> I think you are mistaken. The statement says that before >> uploading, we should ask the ftp team for advice. Not that they >> will always deny the upload. > >> What it means, is that they don't want rigid rules where there >> are problems when we get a new member from a new country, but >> instead leave the decision to humans (the ftp team). I think >> that is very wise. > > If your interpretation is correct, then the mail from Joerg in > practice provides *no* new guidance, and the only reason the > software in question is blocked from the archive is "because the > ftp team says so". > > That's an even worse policy than how I interpreted it. > I find it relieving that when these things have to happen (as was necessary after the proposal to package some controversial content) Debian is able to discuss it and document the decision in public. While not everybody will agree with the outcome, the process of decision making and public documentation of the decision is much better than the way secret lists of blocked websites are being assembled in various countries that pretend to have free and democratic values. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTN+ELAAoJEOm1uwJp1aqDzRUQAKKz/Vbcek5zdpsERN7M8BDF culUU6a4zEDx85YCRgGngFITRf3OBLiZQAeeAqa4xpstMIDLdGv3FsNST4cvnl4D YQoVEMgjtnAj1Svc4wrVBKOFPmEMpC3I2ADKB3tfEfEkewNOA9cjqh5Wzg4k/pRt rNYD1KYI7+4K336Y1HQRnFCNN7GGoxigxF/qhkOJaJ/Xd12YDEj5V70EQF+7DC8A bpSO7n0No/oIhSY962S0cL3q54emPcTWISJVQHcWcSqL6JS5M6ju8FiSVfnr1bAQ kGVj/19RR/OvWBQ9yUzRnowGVtPEwrofxMW1tPTdxcPb56eo4F+is9sFOsTwXmdT eVFe8CicWhCXHXU23LjOgRRHAUX3vxjKf0Wa2s4LqTQvG6zpB1c7A1NutOiX6zll yJspegDhZrk/wR0H/XJ9G/HFZ90QRPbATalKqVTnGNs820dBTd4Ni9d95piXa0nz bFfnEfgywWqXBvnUmy5kxuAEIC6PdjB+HmnDvDDZadjMwo/vzwEzrFgXTXHDDs7/ Jo8nXPGSAlHLBxhcPwGcl/X6aTvzK8/2x6drVp7fwLr26Fxq9TFCO1ze/nBsc2UO VbI/jvg9w9P9Kw/vJHZC4mWY0rc4u7P2qgUxjrZaqf8vi+5IDOC9iLwA3CmKBn7D MaWtx7hPPhnDGzH7wD0O =XY1+ -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: https://lists.debian.org/5337e10b.2090...@pocock.pro
Re: default messaging/VoIP client for Debian 8/Jessie
On Sun, Mar 30, 2014 at 5:04 PM, Daniel Pocock wrote: > Currently, Empathy is installed by default The default desktop is now Xfce, which doesn't use Empathy. http://metadata.ftp-master.debian.org/changelogs/main/t/tasksel/unstable_changelog If you want GNOME to switch from Empathy to jitsi I think that would be a conversation that should be had with upstream, not with Debian. I doubt they would be interested in it due to the Java requirement though. -- 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: https://lists.debian.org/caktje6egbfpyyorugzv_xceybolypbg0beun9zacrkh9med...@mail.gmail.com
Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 11:22, Paul Wise wrote: > On Sun, Mar 30, 2014 at 5:04 PM, Daniel Pocock wrote: > >> Currently, Empathy is installed by default > > The default desktop is now Xfce, which doesn't use Empathy. > > http://metadata.ftp-master.debian.org/changelogs/main/t/tasksel/unstable_changelog Their wiki doesn't emphasize any particular IM/VoIP client, although Jitsi is mentioned there: https://wiki.xfce.org/recommendedapps Even if no client is installed by the default window manager package's declared dependencies, it is still quite reasonable to include an IM/VoIP client (such as Jitsi) in task-desktop for example. > > If you want GNOME to switch from Empathy to jitsi I think that would > be a conversation that should be had with upstream, not with Debian. I > doubt they would be interested in it due to the Java requirement > though. Whichever desktop is in use, why does Debian have to accept what upstream recommends as an IM/VoIP client if we know something else is going to give users far greater chance of success? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5337e894.1060...@pocock.pro
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 05:04 PM, Daniel Pocock wrote: > ZRTP - peer to peer encryption, like PGP for VoIP. Once again, > it has been in Jitsi for ages but is not in Empathy[7] To me, this is the most important feature of them all, and is IMO mandatory nowadays. But do you know if Asterisk (or other VoIP servers) are configured to accept such important feature by default? On 03/30/2014 05:04 PM, Daniel Pocock wrote: >JitMeet multi-party video conferencing solution[8] for WebRTC >browsers You should remove the "s" at browsers. It only supports Chrome(ium). By the way, do you know if it's easy to setup conference calls the way there is with JitMeet / Hangout, but without a web browser, eg directly on a VoIP software? Can Jitsi do that? Cheers, Thomas P.S: I don't really care which client is the default, because I find the concept of default app bad in itself, and I think users should be given the choice, and it isn't the role of a distribution to choose for its users. However, if we *have* to have a default, probably Jitsi is a good choice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5337f218.60...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
Hi, Thomas Goirand: > P.S: I don't really care which client is the default, because I find the > concept of default app bad in itself, and I think users should be given > the choice, and it isn't the role of a distribution to choose for its > users. However, if we *have* to have a default, probably Jitsi is a good > choice. > Most new users don't know enough to choose. Worse, for almost any task Debian has a heap of different packages whose description sounds like it'd fit the requirements, but which actually does something else. It's the difference between "give them a choice if they want to" and "overwhelm them with choices". -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: default messaging/VoIP client for Debian 8/Jessie
Quoting Daniel Pocock (2014-03-30 11:04:31) > I'd like to propose that Jitsi be considered as the default messaging, > VoIP and webcam client for the next major Debian release (jessie). > This would mean it is installed by default in a desktop install and it > is the default handler for sip: and xmpp: URIs. > > Currently, Empathy is installed by default > > There are several reasons I am suggesting this and it is possible that > Empathy could address some of them before the release freeze in > November but we should be completely prepared to go with Jitsi if they > continue to be the leaders in this area. Thanks for all your tremendous work in this field, Daniel. Is there some comparison available e.g. at our wiki? I am thinking something like https://wiki.debian.org/Groupware - I know there is https://wiki.debian.org/UnifiedCommunications and a bunch of sub-pages but there I have located only install guides, no comparison, which I find essential for a discussion like you raise here. Putting it on wiki instead of summarizing in an email, you encourage contribution from others (I happen to use Pidgin, for example, and might attempt to fill in the bits for that in a comparison chart if it existed, but I don't feel knowledgeable enough to put up a chart myself - you seem quite knowledgeable and might even have the data already. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: default messaging/VoIP client for Debian 8/Jessie
Hi, On Sun, Mar 30, 2014 at 11:04:31AM +0200, Daniel Pocock wrote: > -BEGIN PGP SIGNED MESSAGE- [Snip an impressive list of arguments for Jitsi] > To put it simply, the Jitsi team are blazing a trail in this area and > a Debian initiative to install Jitsi on every desktop will give them > more momentum and ensure more people can talk to each other in line > with our agreed definition of freedom. I generally agree and I'm generally quite happy with Jitsi, but I'd like to point out some issues: 1. I was not abot to get "bonjour" instant-messaging working. Does Jitsi support it? This is soemthing I want to use on the LAN at work. 2. The user interface could use some improvement. It feels a bit out of place. Not a deal-breaker, though. 3. I haven't used empathy extensively. I used pidgin. Jitsi seems to consume more resources than pidgin. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330103603.go16...@lemon.cohens.org.il
Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 12:29, Thomas Goirand wrote: > On 03/30/2014 05:04 PM, Daniel Pocock wrote: >> ZRTP - peer to peer encryption, like PGP for VoIP. Once again, >> it has been in Jitsi for ages but is not in Empathy[7] > > To me, this is the most important feature of them all, and is IMO > mandatory nowadays. But do you know if Asterisk (or other VoIP servers) > are configured to accept such important feature by default? > > > On 03/30/2014 05:04 PM, Daniel Pocock wrote: >>JitMeet multi-party video conferencing solution[8] for WebRTC >>browsers > > You should remove the "s" at browsers. It only supports Chrome(ium). Most of my own WebRTC stuff started out only supporting Chromium but Firefox support was not hard to add as well. Chrome developers are also moving to be more Firefox-like (e.g. using DTLS-SRTP and dropping SDES) and that will force many projects to get in sync. > By the way, do you know if it's easy to setup conference calls the way > there is with JitMeet / Hangout, but without a web browser, eg directly > on a VoIP software? Can Jitsi do that? > http://packages.qa.debian.org/r/reconserver.html is trivial to use and compiles cleanly on wheezy, proper backport coming soon. Asterisk has the MeetMe conferencing module If you don't need packages, there are additional options like FreeSWITCH conferencing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5337fd7d.6040...@pocock.pro
Re: default messaging/VoIP client for Debian 8/Jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/03/14 12:57, Jonas Smedegaard wrote: > Quoting Daniel Pocock (2014-03-30 11:04:31) >> I'd like to propose that Jitsi be considered as the default >> messaging, VoIP and webcam client for the next major Debian >> release (jessie). This would mean it is installed by default in a >> desktop install and it is the default handler for sip: and xmpp: >> URIs. >> >> Currently, Empathy is installed by default >> >> There are several reasons I am suggesting this and it is possible >> that Empathy could address some of them before the release freeze >> in November but we should be completely prepared to go with Jitsi >> if they continue to be the leaders in this area. > > Thanks for all your tremendous work in this field, Daniel. > > Is there some comparison available e.g. at our wiki? > > I am thinking something like https://wiki.debian.org/Groupware - I > know there is https://wiki.debian.org/UnifiedCommunications and a > bunch of sub-pages but there I have located only install guides, no > comparison, which I find essential for a discussion like you raise > here. > Done https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > Putting it on wiki instead of summarizing in an email, you > encourage contribution from others (I happen to use Pidgin, for > example, and might attempt to fill in the bits for that in a > comparison chart if it existed, but I don't feel knowledgeable > enough to put up a chart myself - you seem quite knowledgeable and > might even have the data already. Please go ahead - I've just finished my own edits -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTOADVAAoJEOm1uwJp1aqDDkgP/3Gl14U0BgQAL2fyB2+5fmWe JiIrlWebyrSBVL3RMAxEv1jCcKW16CmJ3NeQEfEqzsi4JlbQwPDooHrL/4r+hsm9 eSgxofEAeCnmRQT8vQVi2ZsaR39bb5kIEjH8wJkF911Z57hKGNLAcrUwm2inOjbR wQbD/wsMyyDArM3K0oHi6I1awbNwLnLHivY+aXsy0p3Mvfcb6KXvi3DCQFjfJwlf XZreLTxui+qH6jZ63L5dITi/qDiGpe5MN5uzIDvrGU2exeAgig60Du1Ph0OclQkS N1T5sgt3MgK9uyQ7BIXdnphu1JdSB3D2+t6+6xczYd0XSWtez6WEDZ00L9pxPr4/ gNcUUIrmspWYQv7pVqq3Y2wMNb32/7wp6m4VK096QVA6EBleLTLsUCwiyG++Cx91 lLjQbkHuYbOVQBB5kYT2LMkFcBP0oBaJujnq62687r8eY5LJ+Ii3FMXkZR4cmfi6 2LofRow+/ru5OCZ4ML1OHwzfH85CC+xuBW6BQCK+Ab9H+/htMFym6Uvdim+c1M6l HTkN+Yf8ecneDBj6ZmWM8LCP8nIFeLVbuQrR4FQgApyjp+/2Yc3xYZWsrC4Ts6hq oJDZKHXd4gMYLOAjL+FMwTxwrrq7BIaltw3VxVVEKZo97MAjztXCJUpBlyDe4ysD 5gaFPDCBkX3aqTZ46uVy =rd6W -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: https://lists.debian.org/533800d6.60...@pocock.pro
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/30/2014 01:17 AM, Thomas Goirand wrote: > On 03/30/2014 02:51 AM, Jan Gloser wrote: > >> Otherwise if you just personally disagree with the design of >> systemd and can't describe such a scenario, why not just migrate to >> Gentoo or BSD? > > This has been said a 100 times... > > There's no need to migrate away. systemd is not (and will not be) > mandatory in Debian in the foreseeable future. Your can continue to > use sysv-rc (or OpenRC, file-rc, Upstart...) if you like. The TC > decision is *only* about the *default* init system. In past discussions, one of the apparently largest things I've seen cited as a benefit of switching to systemd has been that it's much more cost-effective in terms of developer/maintainer time and effort to maintain systemd unit files than to maintain traditional init scripts. If it's been decided to continue to require package maintainers to provide traditional init scripts as well as systemd unit files - e.g. for Debian's non-Linux ports - then that benefit would be lost. If it hasn't, then I think it's entirely foreseeable that package maintainers will at some point stop providing traditional init scripts. At that point, unless a means of producing init scripts from unit files (which, last I heard, had been judged impossible) has been found, the amount of work required to continue to run sysvinit would be far more than the terminology of "changing the default" implies. To be doing more than changing the default here is not necessarily a bad thing, but we shouldn't be pretending that changing the default is all that's happening, unless choosing something other than the default really is - and, barring another project-wide decision, is expected to indefinitely continue to be - as simple as installing one set of packages rather than another. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTOAfCAAoJEASpNY00KDJrsokP/3CHawcLrnZ9S3RcyOmzIBxP NRbQ+bjxDGlojjaN8eqRjFvfMG5K6g73WOCmDektjL/zUh6y2YTL12H8LFE7sRdE /e2rKnXt+OELKedJf/KERAk/d/ei9E8ZBb/iDiMuUvTgcFvO2Ll+Dq9PmveBJ4+C Lz1dM/MBjDkJUXHAgRnbIT6btIQwfunD7iR1PrtPsYG5oUtB6b9RsN6b8Z4ky1Yi kbEZC9nXKjrt2WEj6s4VUZkVd84xEym3302BeeXtToWv/86j/GbXvTKI+9mxi/Is jxvlxzjInJbIvP17CyMrkzwqoD2HEoUDU+iAM9VlBskaEI+ygNOaI0liiw6L9FyT 6cfYk74YJ8IEGjotKwpzIamSv8WA1YQl6YYD9LgL7bvPS1ubW2rIKx1zpOlpoTPx 0FwBXji4mxrCWB//maLiUYrI6yh+FGE0srhrS7Om7aNrj/2rsf8M5N5L2xXO7rVH Gyu35ct1wCxlp1V8VWAFStEYYxs0MKE+0wumUROlRMh9ghu7NNVjeMxCql61SLz4 ZFOCeY+ppj2BvYWm5DRVnv0Ww5dfKHyh7PnZUZ8qu3pDGywzaFyWJOakb5R1O4I5 WBRU3PuaxukK5xOx8t8Fy/vXkvSANLvfEgIUyh5lzW2c0Vy4L8CL2VV0R6BOYqT9 /gesSs527WT6pET3tFL4 =O6Cx -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: https://lists.debian.org/533807c2.1020...@fastmail.fm
Re: default messaging/VoIP client for Debian 8/Jessie
+++ Thomas Goirand [2014-03-30 18:29 +0800]: > On 03/30/2014 05:04 PM, Daniel Pocock wrote: > > On 03/30/2014 05:04 PM, Daniel Pocock wrote: > >JitMeet multi-party video conferencing solution[8] for WebRTC > >browsers > > You should remove the "s" at browsers. It only supports Chrome(ium). It's kind of the pother way round. AIUI Chromium supports multiple video streams, firefox only supports one. So jitmeet doesn't care at all what browser you use, but it does need to support various fairly new WebRTC features, inlcuding this multiple streams thing. I used meet.jit.si for the first time this week (for GSOC) and was very impressed. It's extremely convenient and 'just worked' for both audio and video on testing, which is better than hangouts as well as being free software. OK. I do have to get out a copy of chromium, which is a pain because firefox is my default browser, but that's a fairly minor irritation to get working videoconf. And I assume this annoyance will go away in due course when firefox acquires the necessary feature. It's certainly technology I recommend everyone to try. Is anyone packaging jitmeet itself BTW? > By the way, do you know if it's easy to setup conference calls the way > there is with JitMeet / Hangout, but without a web browser, eg directly > on a VoIP software? Can Jitsi do that? Yes I'm interested in how you use WebRTC clients along with desktop clients. I assume it's possible... Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330121846.gc10...@stoneboat.aleph1.co.uk
Re: default messaging/VoIP client for Debian 8/Jessie
Quoting Wookey (2014-03-30 14:18:47) > +++ Thomas Goirand [2014-03-30 18:29 +0800]: >> By the way, do you know if it's easy to setup conference calls the >> way there is with JitMeet / Hangout, but without a web browser, eg >> directly on a VoIP software? Can Jitsi do that? > > Yes I'm interested in how you use WebRTC clients along with desktop > clients. I assume it's possible... Please use https://wiki.debian.org/UnifiedCommunications as starting point. There is already link to a (mini-)HOWTO on some server setup, but if that does not adequately cover conference calls (I haven't tried yet myself) then consider extending that wiki page instead of sharing details here ;-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: default messaging/VoIP client for Debian 8/Jessie
Hi, On Sun, Mar 30, 2014 at 11:49:08AM +0200, Daniel Pocock wrote: > > If you want GNOME to switch from Empathy to jitsi I think that would > > be a conversation that should be had with upstream, not with Debian. I > > doubt they would be interested in it due to the Java requirement > > though. > > Whichever desktop is in use, why does Debian have to accept what > upstream recommends as an IM/VoIP client if we know something else is > going to give users far greater chance of success? With respect to GNOME, you did not explain how well jitsi is blending into the GNOME3 desktop. Is it using GTK3, does it have a GNOME3 branding? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330134506.gq31...@raptor.chemicalconnection.dyndns.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 15:45, Michael Banck wrote: > Hi, > > On Sun, Mar 30, 2014 at 11:49:08AM +0200, Daniel Pocock wrote: >>> If you want GNOME to switch from Empathy to jitsi I think that would >>> be a conversation that should be had with upstream, not with Debian. I >>> doubt they would be interested in it due to the Java requirement >>> though. >> >> Whichever desktop is in use, why does Debian have to accept what >> upstream recommends as an IM/VoIP client if we know something else is >> going to give users far greater chance of success? > > With respect to GNOME, you did not explain how well jitsi is blending > into the GNOME3 desktop. > > Is it using GTK3, does it have a GNOME3 branding? > These are relevant considerations However, in my view, these questions are much higher on the list of priorities: - does it only talk to friends on the same LAN or anywhere? - is the communication secure (relative to alternatives)? - is it easy to set up? - does it empower other types of development (e.g. for people wanting to build WebRTC web applications) on a free platform? To put it another way, the most widely used softphones are not GNOME related either, millions of users are choosing them simply because they appear to work regularly and they are very easy to set up. Jitsi is probably the most compelling competitor for those proprietary products right now. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53382409.5010...@pocock.pro
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 06:55 PM, Matthias Urlichs wrote: > Hi, > > Thomas Goirand: >> P.S: I don't really care which client is the default, because I find the >> concept of default app bad in itself, and I think users should be given >> the choice, and it isn't the role of a distribution to choose for its >> users. However, if we *have* to have a default, probably Jitsi is a good >> choice. >> > Most new users don't know enough to choose. Excuse me to say it this way, but ... NO! I've read this too many times. You have absolutely no evidence of that. Apart maybe if you talk about your mum, which anyway wouldn't install Debian (or any other OS btw) herself. To me, it looks a lot more logic and probable that those who don't know just don't care about VoIP. Those who need a VoIP client will have enough knowledge to choose. My point above was only that I don't think it's a good idea to install so many stuff by default. It bloats the installer and make it difficult to fit on the 700 MB of the CD1. I very much prefer a more minimalistic approach. Empathy isn't only doing VoIP, it does lots of other (chat) protocol, and trying to compare it to Jitsi doesn't help IMO. I myself prefer pidgin + Ekiga than just Empathy (and I find Jitsi too heavy and slow), but that's just me. Ask 5 persons, and probably you will get 5 different answers (including Ekiga, Skype, Linphone, Mumble, you-name-it). So why even bothering installing anything by default? In the case of Empathy, my understanding was that the reason it was there, is because it's designed to integrate with Gnome. I don't think we can say the same thing with Jitsi (which integrates with nothing). I also find it a pain to add the Jitsi dependencies in the default setup: Depends: libjitsi-jni (>= 2.4.4997-1), default-jre | java6-runtime, libunixsocket-java, libhttpcore-java, liblog4j1.2-java, libjmdns-java, libdnsjava-java, libmac-widgets-java, libfelix-main-java, libfelix-framework-java, libhttpclient-java, libhttpmime-java, libcommons-logging-java, libcommons-codec-java, libcommons-lang3-java, liblaf-widget-java, libdbus-java, libxpp3-java, libjzlib-java, libbcprov-java, libjna-java, libjgoodies-forms-java, libjson-simple-java, libjcalendar-java And yes, Java sux! :/ And it's going to take *a lot* of space on the CD1. This should therefore be discussed on the debian-cd list as well. I don't think that only the argument "it's better because of this or that feature" would be the only one (unfortunately). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53382588.3090...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 07:18 PM, Daniel Pocock wrote: > On 30/03/14 12:29, Thomas Goirand wrote: >> On 03/30/2014 05:04 PM, Daniel Pocock wrote: >>>JitMeet multi-party video conferencing solution[8] for WebRTC >>>browsers >> >> You should remove the "s" at browsers. It only supports Chrome(ium). > > Most of my own WebRTC stuff started out only supporting Chromium but > Firefox support was not hard to add as well. Chrome developers are also > moving to be more Firefox-like (e.g. using DTLS-SRTP and dropping SDES) > and that will force many projects to get in sync. I just hope JitMeet gets support for Firefox soon, and that we (also soon) be able to install it on any given server using Debian packages! > http://packages.qa.debian.org/r/reconserver.html > > is trivial to use and compiles cleanly on wheezy, proper backport coming > soon. Description-en: lightweight SIP conferencing service [... bla bla ...] It supports audio but not video or text. I would need both video, screen sharing & text (mainly to cut/past URLs). Anything that doesn't have these features wouldn't work for what we need (eg: work video conferences with at least 10 persons). We don't care seeing all faces at once, but screen sharing is important (to be able to do demos, or show slides). Up to now, the only solution we've found acceptable is Mumble. Bonus: it can scale up to 50 participants (I never tested more people at once). No way you can do that with Hangout (with a Google enterprise account, the limit is 15). And as you know, Mumble does only voice. We would ALL be happy to switch to a free software solution. > Asterisk has the MeetMe conferencing module > > If you don't need packages, there are additional options like FreeSWITCH > conferencing. Same: I don't think we'd have video, screen sharing & text chat with the above. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533827f4.2010...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 16:09, Thomas Goirand wrote: > On 03/30/2014 06:55 PM, Matthias Urlichs wrote: >> Hi, >> >> Thomas Goirand: >>> P.S: I don't really care which client is the default, because I find the >>> concept of default app bad in itself, and I think users should be given >>> the choice, and it isn't the role of a distribution to choose for its >>> users. However, if we *have* to have a default, probably Jitsi is a good >>> choice. >>> >> Most new users don't know enough to choose. > > Excuse me to say it this way, but ... NO! > Actually, many users will use what their friends are using, that's how they end up using solutions like WhatsApp that uses their phone's IMEI number as a password for XMPP. We should make it easy for people to choose - and Debian does a great job of that. But we should have a good default too. The default needs to work for the widest number of use cases. > My point above was only that I don't think it's a good idea to install > so many stuff by default. It bloats the installer and make it difficult > to fit on the 700 MB of the CD1. I very much prefer a more minimalistic > approach. That is a different issue. If it is too much for a single CD a) lets have it on DVD1 b) lets have some way to get stuff like this automatically if the user supplements CD1 with a network mirror c) or maybe we can have different CD sets, e.g. a set of disks for "deskop / end user" and a different set of disks for "developer / sysadmin" > Empathy isn't only doing VoIP, it does lots of other (chat) protocol, > and trying to compare it to Jitsi doesn't help IMO. I myself prefer Jitsi does IM/chat too, I just didn't emphasize that so mcuh. > pidgin + Ekiga than just Empathy (and I find Jitsi too heavy and slow), > but that's just me. Ask 5 persons, and probably you will get 5 different > answers (including Ekiga, Skype, Linphone, Mumble, you-name-it). So why > even bothering installing anything by default? In the case of Empathy, > my understanding was that the reason it was there, is because it's > designed to integrate with Gnome. I don't think we can say the same > thing with Jitsi (which integrates with nothing). Quite simply, when talking about a communications tool, I feel the default option needs to be able to communicate with the widest number of people. Jitsi currently does that - despite all the legitimate concerns about disk space, GNOME UI, Java, whatever. It maximizes the number of people who can contact each other. By enabling the widest number of people to inter-operate, we help create the foundation for a world of free VoIP. Solutions like Empathy can grow into that at their own pace and the developers will have more motivation to fill those gaps (like DTLS-SRTP support) when there is a more active body of users to tap into. In any case, please feel free to add the other options into the wiki: https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > I also find it a pain to add the Jitsi dependencies in the default setup: > > Depends: libjitsi-jni (>= 2.4.4997-1), default-jre | java6-runtime, > libunixsocket-java, libhttpcore-java, liblog4j1.2-java, libjmdns-java, > libdnsjava-java, libmac-widgets-java, libfelix-main-java, > libfelix-framework-java, libhttpclient-java, libhttpmime-java, > libcommons-logging-java, libcommons-codec-java, libcommons-lang3-java, > liblaf-widget-java, libdbus-java, libxpp3-java, libjzlib-java, > libbcprov-java, libjna-java, libjgoodies-forms-java, > libjson-simple-java, libjcalendar-java > > And yes, Java sux! :/ And it's going to take *a lot* of space on the > CD1. This should therefore be discussed on the debian-cd list as well. I > don't think that only the argument "it's better because of this or that > feature" would be the only one (unfortunately). > I don't work exclusively with Java myself and I'm well aware of the benefits and disadvantages. Quite simply, it gives us a DFSG-compliant solution now. Thanks to Java, it brings that solution to people who are not even ready to change their whole OS and they can communicate with people who are 100% Debian/free-software users. Whatever you think about Java, it is free software and people are welcome to develop alternatives. Some of the building blocks are already out there in C or C++, like the reSIProcate project (which includes reTurn for TURN and reflow for RTP media now). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53382ab6.3030...@pocock.com.au
Re: default messaging/VoIP client for Debian 8/Jessie
On Sun, 2014-03-30 at 22:09 +0800, Thomas Goirand wrote: > On 03/30/2014 06:55 PM, Matthias Urlichs wrote: > > Hi, > > > > Thomas Goirand: > >> P.S: I don't really care which client is the default, because I find the > >> concept of default app bad in itself, and I think users should be given > >> the choice, and it isn't the role of a distribution to choose for its > >> users. However, if we *have* to have a default, probably Jitsi is a good > >> choice. > >> > > Most new users don't know enough to choose. > > Excuse me to say it this way, but ... NO! > > I've read this too many times. You have absolutely no evidence of that. > Apart maybe if you talk about your mum, which anyway wouldn't install Argument from sexism? > Debian (or any other OS btw) herself. To me, it looks a lot more logic > and probable that those who don't know just don't care about VoIP. Those > who need a VoIP client will have enough knowledge to choose. [...] And this sort of attitude is why Skype has won. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: default messaging/VoIP client for Debian 8/Jessie
Quoting Daniel Pocock (2014-03-30 16:31:18) > Jitsi does IM/chat too, I just didn't emphasize that so mcuh. Please add "T" in the relevant "TAV" fields at https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison - and while at it please also add info about JSCommunicator :-) Others: Please add what you know of relevant bits about your pet voip clients to above wiki page. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
On 03/30/2014 08:02 PM, The Wanderer wrote: > If it's been decided to continue to require package maintainers to > provide traditional init scripts as well as systemd unit files - e.g. > for Debian's non-Linux ports - then that benefit would be lost. This, also, has also been discussed. The consensus is that we shouldn't *force* anyone to provide / design anything but systemd support, however, everyone should also accept patches by those who care about non-linux ports or $alternative-init-system. > If it hasn't, then I think it's entirely foreseeable that package > maintainers will at some point stop providing traditional init scripts. They should absolutely *not* remove init scripts that are working. If someone does, I would advise to first politely ask him to revert the regression. And probably asking the TC to force the maintainer to do so if he refuses would be a good idea. Now, not providing an init script for a *new* package is something different. I would expect to soon see patches being sent to the BTS by non-linux port supporters, or people willing to use the package without systemd. Though what I wrote above is only what has been *discussed*, there was no formal decision of what must happen. I dislike this gray area. :( > At that point, unless a means of producing init scripts from unit files > (which, last I heard, had been judged impossible) has been found, the > amount of work required to continue to run sysvinit would be far more > than the terminology of "changing the default" implies. I don't agree. We currently, at this point, have 100% full support for sysv-rc LSB-header scripts. I don't see it going away that fast. > To be doing more than changing the default here is not necessarily a bad > thing, but we shouldn't be pretending that changing the default is all > that's happening We haven't set into the stones of the Debian Policy Manual what init system *must* be supported by packages. Obviously, systemd being the default, it must be supported, but probably, through sysv-rc script is a way to support it. Not supporting sysv-rc is of course a bug, but of which severity? Wishlist? Release critical? We've been fighting on which init system should be the default, but I think those questions are even more important, and I don't have an answer to them. > unless choosing something other than the default > really is - and, barring another project-wide decision, is expected to > indefinitely continue to be - as simple as installing one set of > packages rather than another. See above: I'm unsure Debian Developers have yet a clear view of what should / must be supported, and what's going to happen in this regard. At least, it's not clear to me. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533830df.4010...@debian.org
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/30/2014 10:57 AM, Thomas Goirand wrote: > On 03/30/2014 08:02 PM, The Wanderer wrote: > >> If it's been decided to continue to require package maintainers to >> provide traditional init scripts as well as systemd unit files - >> e.g. for Debian's non-Linux ports - then that benefit would be >> lost. >> If it hasn't, then I think it's entirely foreseeable that package >> maintainers will at some point stop providing traditional init >> scripts. > > They should absolutely *not* remove init scripts that are working. If > someone does, I would advise to first politely ask him to revert the > regression. And probably asking the TC to force the maintainer to do > so if he refuses would be a good idea. What about an init script that used to work, but has stopped working, due to e.g. a change in the rest of the package or a change in the surrounding system? Obviously if someone comes up with a fix to get it working again, the same "maintainers who don't maintain traditional init scripts should accept patches from others" would apply. If no such fix is forthcoming, however, I can easily see a maintainer deciding to drop the nonworking init script. >> At that point, unless a means of producing init scripts from unit >> files (which, last I heard, had been judged impossible) has been >> found, the amount of work required to continue to run sysvinit >> would be far more than the terminology of "changing the default" >> implies. > > I don't agree. We currently, at this point, have 100% full support > for sysv-rc LSB-header scripts. I don't see it going away that fast. I was explicitly referring to the point in the future when maintainers do stop providing traditional init scripts. This likely won't happen that fast, no, but I do think it's likely that it will happen - whether days after the jessie release or decades, or more likely something in between. My point, insofar as I had one, was more about what terminology is appropriate to use in discussing this than anything else. (I don't think I see anything to disagree with in the rest of what you said.) - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTOEI4AAoJEASpNY00KDJrr7QP/39Qf0IUZbTlQ7V7+AM8GXQd +mrTK9UPF8zxr0CnLZb5rcP796S37lw6fIp9sbpjnOXJHXvBz+jDbI/ACq1jb7ri dSLMpoGyhS6H9662rlwD3WAuUgoeObp0Zyg+IgQsNXRxGgXWxOk5U2LMaEhdUMA0 OYeyGrFTstKoivT9u8mUYcyUbKpCn7Qgwao9DNaO35zvLgHdRsfD5JbCKArQOtWo cxejI4rDGnbfY29mei/Egb090ZGdLp+0JWfji9lDF25xGBBlV3AuLfM+3Xf32Tql W39b9BWjSD4EeL3hjMj3p+RpxOPiFGC9j9brlUgzN6ch+5H+fMtEdjvANBH0/A5d iBYZzAdf5OY8s+4+Ryd/Vhghj2RVg0er8ssTdpL9f2hwHfNdWaotTbSZyKvVjuHA ihj3J7oii0y7daNrpcmEvi32fhSopLnwzu1v2RCpeZWcQOWOjeKWxsQmH/0R4PSg SwP3PCp/6C/GVOnAYz8o0mB68tCw/eBjkq2buwqKotDS3S3B75C1e67VcYOxwW29 dvhgEsPJlXgUXKRmyCa2BqTvvtIz/9ojF/bH1eRzQ8a4fNPQUZ9tgadFlMZzMth5 SAGweaCoVaARGiphOUORgyoSBmM27HCQ77QgxVddi1VyqRWeaojzCOAR2ej1sxRX PRefLzcSICn/dMMlbFgm =DM69 -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: https://lists.debian.org/53384238.3060...@fastmail.fm
Bug#743063: ITP: ruby-github-linguist -- detection and highlight of the programming language of source code and ignore binary files
Package: wnpp Severity: wishlist Owner: timothee * Package name: ruby-github-linguist Version : 2.10.11 Upstream Author : GitHub * URL : https://github.com/github/linguist * License : MIT Programming Lang: Ruby Description : detection and highlight of the programming language of source code and ignore binary files Library use by GitHub to detect blob languages, highlight code, ignore binary files, suppress generated files in diffs, and generate language breakdown graphs. Features : - Language detection : ruby-github-linguist defines a list of all languages known to GitHub in a yaml file. In order for a file to be highlighted, a language and a lexer must be defined there. Most languages are detected by their file extension. For disambiguating between files with common extensions, we first apply some common-sense heuristics to pick out obvious languages. After that, we use a statistical classifier. This process can help us tell the difference between, for example, .h files which could be either C, C++, or Obj-C. - Syntax Highlighting : The actual syntax highlighting is handled by our Pygments wrapper, ruby-pygments.rb. It also provides a Lexer abstraction that determines which highlighter should be used on a file. - Stats : The Language stats bar that you see on every repository is built by aggregating the languages of each file in that repository. The top language in the graph determines the project's primary language. - Ignore vendored files : Checking other code into your git repo is a common practice. But this often inflates your project's language stats and may even cause your project to be labeled as another language. ruby-github-linguist is able to identify some of these files and directories and exclude them. - Generated file detection : Not all plain text files are true source files. Generated files like minified js and compiled CoffeeScript can be detected and excluded from language stats. As an extra bonus, these files are suppressed in diffs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330162801.3392.90455.reportbug@debian
Re: Bug#739626: How to name the websocket PT server in Debian; was ITP: tor-pt-websocket -- WebSocket pluggable transport
control: retitle 739626 ITP: pt-websocket -- WebSocket pluggable transport On 20/02/14 17:00, David Fifield wrote: > On Thu, Feb 20, 2014 at 03:58:02PM +, Ximin Luo wrote: >> - tor-pt-websocket or pt-websocket: These are unambigious but >> inconsistent with the other Tor pluggable transport in Debian, >> obfsproxy. And there is also "fteproxy" which will probably retain >> this naming when added to Debian in the future. > > I kind of like this option, with the idea that there will be more of > such in the future. > > websocket is a special case because the upstream package only has a > server (there is client code but just a toy that shouldn't be > installed). What will other packages that have a matched client and > server look like? People installing the client probably don't want to > install the server (and have their init.d messed with, etc.), and people > installing the server don't also need the client. > Lunar suggested pt-websocket since it is not intrinsically tied to Tor usage, so I will go with that. I think the longer name pt-websocket-server is unnecessary, since we are unlikely to ever release a pt-websocket-client, so I will stick pt-websocket. If anyone disagrees, please speak up soon, since I have all the packaging ready and just need to make some final tweaks before submitting it for sponsorship. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Re: default messaging/VoIP client for Debian 8/Jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/03/14 16:54, Jonas Smedegaard wrote: > Quoting Daniel Pocock (2014-03-30 16:31:18) >> Jitsi does IM/chat too, I just didn't emphasize that so mcuh. > > Please add "T" in the relevant "TAV" fields at > https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > - and while at it please also add info about JSCommunicator :-) > That is a trick question - many of the features of JSCommunicator are provided by the media stack in the browser or by JsSIP E.g. if a browser supports Opus, JSCommunicator will use it. If not, it doesn't actually know or care. > > Others: Please add what you know of relevant bits about your pet > voip clients to above wiki page. > > > - Jonas > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTOFM/AAoJEOm1uwJp1aqD+DQP/1r5cOO8l9etBKfs79kcHgqb oGWgciDSTHyRRhdKdWzNsMQuxWioPABlwOl1jnuB5cOWO7C8dAUVyNw0oTnRAwXs Sf3lze9Wzc/OwzLnsqAjrORh0av43xkqAnJBWNYa2elpSg5goMLS1DMmsN4OKFma sW4Fj0jaJzX7B4fkQ48qPhvX8IIrakxtw6LGa2mA83EasQGZreLe2fcRfcAxSMrk da9CpeNc/7YPWLLhbBPbOdCLZp6iw7NyIWlIOwM7z1fW3BeN9hTsMgVQm4N+pimC 3/2BeGoU9wome6hUH3ODg8qDRIBufO+QhxWW5XPuprim8amVRFwpamkaMnxbuSNl IERW9ITygUyHJfs1ZM/x0p4YTOBleBLNUE1B2nO6OLUg2uOog6AGJmSwMlLzVbbE DYCEJrk1q6ZmJjeDdfgZneMZ3xV3zrf+vio0l4UsRdiRHq02L19CLZWBlP83Cj5o LAL05LBVRIxuXZdTgvYXodzCLqQQTswr8ZCJMTxHI8Hg991lmwO1hbnhhMqyrb3x 78Ukt/82RxXplcIuRn2Tk4MgoQXNZJ5QBeDnXbbyIAIw8fsI0e2OGb3V4mu83f8T WX1rcfXdIoxDA4bIW0YfGm3Y1cDrug3naSlZCRdlKXqp3nuJhSE/cO6l52tySThr lAy2E04AU5xJgqS/i4Xh =7lGK -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: https://lists.debian.org/5338533f.1070...@pocock.pro
Re: default messaging/VoIP client for Debian 8/Jessie
On Sun, Mar 30, 2014 at 07:24:15PM +0200, Daniel Pocock wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 30/03/14 16:54, Jonas Smedegaard wrote: > > Quoting Daniel Pocock (2014-03-30 16:31:18) > >> Jitsi does IM/chat too, I just didn't emphasize that so mcuh. > > > > Please add "T" in the relevant "TAV" fields at > > https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > > - and while at it please also add info about JSCommunicator :-) > > > > That is a trick question - many of the features of JSCommunicator are > provided by the media stack in the browser or by JsSIP > > E.g. if a browser supports Opus, JSCommunicator will use it. If not, > it doesn't actually know or care. So this page needs some entries for browsers? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330171503.gp16...@lemon.cohens.org.il
Re: default messaging/VoIP client for Debian 8/Jessie
* Ben Hutchings , 2014-03-30, 15:33: Most new users don't know enough to choose. Excuse me to say it this way, but ... NO! I've read this too many times. You have absolutely no evidence of that. Apart maybe if you talk about your mum, which anyway wouldn't install Argument from sexism? Or a maternal insult. Nah, probably neither. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330180240.ga7...@jwilk.net
Re: default messaging/VoIP client for Debian 8/Jessie
Quoting Daniel Pocock (2014-03-30 19:24:15) > On 30/03/14 16:54, Jonas Smedegaard wrote: > > Quoting Daniel Pocock (2014-03-30 16:31:18) > >> Jitsi does IM/chat too, I just didn't emphasize that so mcuh. > > > > Please add "T" in the relevant "TAV" fields at > > https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > > - and while at it please also add info about JSCommunicator :-) > > > > That is a trick question - many of the features of JSCommunicator are > provided by the media stack in the browser or by JsSIP > > E.g. if a browser supports Opus, JSCommunicator will use it. If not, > it doesn't actually know or care. Desktop clients also use underlying stacks (e.g. libpurple) for some of their work - similar to JSCommunicator relying on JsSIP. If JSCommunicator sends the proper instructions to browsers to use (or favor) Opus and similar for other features, then to me that seems similar to desktop clients expecting the desktop to have some audio output configured for audio and and have adequately powerful graphics driver working with X11 for video. And a keyboard attached for text :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: default messaging/VoIP client for Debian 8/Jessie
Quoting Tzafrir Cohen (2014-03-30 19:15:04) > On Sun, Mar 30, 2014 at 07:24:15PM +0200, Daniel Pocock wrote: > > On 30/03/14 16:54, Jonas Smedegaard wrote: > > > Quoting Daniel Pocock (2014-03-30 16:31:18) > > >> Jitsi does IM/chat too, I just didn't emphasize that so mcuh. > > > > > > Please add "T" in the relevant "TAV" fields at > > > https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison > > > - and while at it please also add info about JSCommunicator :-) > > > > > > > That is a trick question - many of the features of JSCommunicator are > > provided by the media stack in the browser or by JsSIP > > > > E.g. if a browser supports Opus, JSCommunicator will use it. If not, > > it doesn't actually know or care. > > So this page needs some entries for browsers? Please don't: Let's keep it a two-dimensional matrix. Track browser features in a separate wiki page if you find that relevant (and, for comparison, one on how well desktop environments integrates a volume control as part of their GUI, and one on which integrated computers has graphics drivers with XVIDEO supported X11 drivers, etc.). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: default messaging/VoIP client for Debian 8/Jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/03/14 20:53, Jonas Smedegaard wrote: > Quoting Tzafrir Cohen (2014-03-30 19:15:04) >> On Sun, Mar 30, 2014 at 07:24:15PM +0200, Daniel Pocock wrote: >>> On 30/03/14 16:54, Jonas Smedegaard wrote: Quoting Daniel Pocock (2014-03-30 16:31:18) > Jitsi does IM/chat too, I just didn't emphasize that so > mcuh. Please add "T" in the relevant "TAV" fields at https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison - - and while at it please also add info about JSCommunicator :-) >>> >>> That is a trick question - many of the features of >>> JSCommunicator are provided by the media stack in the browser >>> or by JsSIP >>> >>> E.g. if a browser supports Opus, JSCommunicator will use it. >>> If not, it doesn't actually know or care. >> >> So this page needs some entries for browsers? > > Please don't: Let's keep it a two-dimensional matrix. > > Track browser features in a separate wiki page if you find that > relevant (and, for comparison, one on how well desktop environments > integrates a volume control as part of their GUI, and one on which > integrated computers has graphics drivers with XVIDEO supported X11 > drivers, etc.). > To maintain the correct focus here, it is probably more relevant to track browser features from the WebRTC specs rather than all browser features in general. Some things are standard as per the spec and all browsers implement them (e.g. the G.711 codec, AVPF, ICE) There has been variation in the SRTP style and the video codecs but that will hopefully converge. All of this could be summarised by a line in the table for "WebRTC spec" rather than one line per browser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTOGl6AAoJEOm1uwJp1aqDWKsP/3K3FiS01/1ibU0DTSLeNxVk /6HW/pFmnykQlWwg25Q3TBPaEBlhTqjiidpMTQ1zev50UzbNZt1nmWTlmwWb0Eg2 crOvjErfm4of+pdQeqq7r+bAVOk8lX80QYxUveTzPDOuyB7QJgmRw5PzI7JaoUxc rLKDaqJLnhgj16UJJfdg7ECgLGxFVYxudb82oQIXHfDAoiWY0QpzABge/uvO9r10 8Y/IgPkrBEcTmZO6Gfdu1P0cE2P7+UZ01CnV10MTJyqv1txgPQeKpkLwxMwK8NVw O03jLiVNLjfyKCr5HHbtPyXjZSYWlrBSUpwxEXefwjF+mCErGnolQjuIjaP7puJa mSOjlS5DwUPSmNkinydwCY3/0Ho6HPf5BE0esG1iddcN1b4yDnsKm7s//NJUviad sVCS9uDUiw+mx53LxSowWtwoIfcpEbWR7lMaBnnubdbBuFHdfr3oGKaC+uHuwbb7 4amXJUy+i7Ch18RoKR3zrO6SAuYwmjjIx1/Xzk7czZqAXVr3ZqyPUe2+1cxJl1My 7hfUuvXgJkG3A6BgDMwMkRRnIm1jCCi3R0VAH2jUQyd6aG6npO0ODOFvTGTl+zx1 KSgvcfIuaL4lQjXzrWutpPPwP2golnknuX2LkaCZG4TghZJ22epwq3z6qY9uC2Bv G3Q13Ae9pG/UlYwvw0qP =aG2+ -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: https://lists.debian.org/5338697a.2010...@pocock.pro
Bug#743132: ITP: python-fedora -- Python modules for interacting with Fedora Services
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-fedora Version : 0.3.33 Upstream Author : Toshio Kuratomi and others * URL : https://fedorahosted.org/python-fedora/ * License : GPL-2+ and/or LGPL-2.1+ Programming Lang: Python Description : Python modules for interacting with Fedora Services The python-fedora module provides a Python API for connecting to web services provided by the fedora infrastructure. . Specifically, this package provides clients for the Fedora Account System, for the Fedora Package Database, for the Fedora Build System (bodhi), and for the Fedora wiki, as well as a more generic client for the other Fedora web services. This is a dependency of a test dependency (fedmsg-meta-fedora-infrastructure) for the datanommer package. Upstream provides, in the same tarball, modules to build clients and servers for the fedora infrastructure. The Debian package will only contain the client parts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330191358.18040.29391.report...@darboux.home.olasd.eu
Bug#743139: ITP: jitmeet -- In-browser WebRTC JavaScript video conferences
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: jitmeet Version: 0.1 Upstream Author: Jitsi (https://jitsi.org) URL: https://jitsi.org/Projects/JitMeet License: MIT Description: In-browser WebRTC JavaScript video conferences JitMeet is a WebRTC JavaScript application that uses Jitsi Videobridge to provide high quality, scalable video conferences. -- | Yasen Pramatarov |a.k.a. turin | home: http://yasen.lindeas.com | photoblog: http://ltdfocus.com | gnu/linux: http://lindeas.com signature.asc Description: PGP signature
Re: ca-certificates: no more cacert.org certificates?!?
On 30 March 2014 17:26, Marc Haber wrote: > I find this somewhat a fair deal. If you make money from your web > site, you should pay for the certificate. > > Where do you draw the line? Does a commercial company hosting a website, say for documentation for a commercial product count at a per profit website? Also, startcom seems to be offline a lot lately, as I previously mentioned before. A bit poor if you have to pay for such bad service. The actual wording, from http://www.startssl.com/policy.pdf is: "3.1.2.1 "Class 1 Certificates provide modest assurances that the email originated from a sender with the specified email address or that the domain address belongs to the respective server address. These certificates provide no proof of the identity of the subscriber or of the organization. "Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc." What does "commercial in nature mean"? If I run a website as a hobby, and have Google ads on it, does it count as a website of commercial nature? Does this mean if I setup a website giving helpful hints for Microsoft Windows (a high profile brand), I cannot use a class 1 certificate? Not exactly like I would expect to get any money from it. They haven't really defined what they mean, and I think that is a big problem. On the other hand, getting back on topic, cacert.org offers you certificates free, and for any purpose, which is why it is much better then any of the other free alternatives (I only know one free alternative). I don't understand what is going on behind the scenes, however from my perspective (which may or may not be correct) it appears that every time cacert.org is about to get somewhere with getting their CA included with my browsers, they keep getting more and more road blocks put in their way. Road blocks that other, more established commercial CA's don't have to worry about. As such, any statements that say cacert.org is not needed because we have startcom, are incorrect. -- Brian May
The role of Debian in presenting defaults (was: default messaging/VoIP client for Debian 8/Jessie)
Thomas Goirand writes: > On 03/30/2014 06:55 PM, Matthias Urlichs wrote: > > Thomas Goirand: > >> P.S: […] I find the concept of default app bad in itself, and I > >> think users should be given the choice, and it isn't the role of a > >> distribution to choose for its users. > > > > Most new users don't know enough to choose. > > Excuse me to say it this way, but ... NO! > > I've read this too many times. You have absolutely no evidence of > that. He doesn't need evidence for the null hypothesis. Most *people* new to any field have not enough information to choose. So it's the default assumption to say that most newcomers to a field do not have enough information in that field to choose. If you're saying that's false in the specific case of application software, what evidence do you have for that assertion? There is much observational evidence that presenting expert-selected defaults *is* helpful for most recipients; this is the “default effect” in psychology. The Wikipedia page has useful information and many links https://en.wikipedia.org/wiki/Default_effect_%28psychology%29>. Based on that body of evidence, it *is* the role of an OS vendor to choose sensible defaults for the recipient. There's no good reason to think Debian is an exception to this. > My point above was only that I don't think it's a good idea to install > so many stuff by default. That's a different statement, which should be separated from discussions of the role of the OS vendor in presenting defaults to the user. -- \ “Don't worry about what anybody else is going to do. The best | `\ way to predict the future is to invent it.” —Alan Kay | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mwg7mfqf.fsf...@benfinney.id.au
Bug#743153: ITP: node-entities -- Encode and decode XML/HTML entities with ease - module for Node.js
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-entities Version : 1.0.0 Upstream Author : Felix Boehm * URL : https://github.com/fb55/node-entities * License : BSD-2-clause Programming Lang: JavaScript Description : Encode and decode XML/HTML entities - module for Node.js node-entities encodes and decodes three selectable levels of entities: XML, HTML4, HTML5. . Node.js is an event-based server-side javascript engine. This module is a dependency of node-jsdom and has no equivalent module in debian (that i know of). It will be maintained in pkg-javascript-devel team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140330233734.19387.78944.reportbug@imac.chaumes
Re: [jitsi-users] default messaging/VoIP client for Debian 8/Jessie
On behalf of the community, thanks for the suggesting this Daniel! We are currently in the process of preparing deb packages for Jitsi Videobridge and our new conferencing app too, so maybe these would also help Debian's users to get better Free communication. --sent from my mobile On 30 Mar 2014 11:44 AM, "Daniel Pocock" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > I'd like to propose that Jitsi be considered as the default messaging, > VoIP and webcam client for the next major Debian release (jessie). > This would mean it is installed by default in a desktop install and it > is the default handler for sip: and xmpp: URIs. > > Currently, Empathy is installed by default > > There are several reasons I am suggesting this and it is possible that > Empathy could address some of them before the release freeze in > November but we should be completely prepared to go with Jitsi if they > continue to be the leaders in this area. > > * Google dependency: Empathy is hard-coded[1] to use Google >media relay (TURN) servers for NAT traversal. It can't >be configured to use a TURN server on a Debian server, >even though we have three TURN servers packaged for our >users. This means that when Google shifts the goal posts >(as they already did, ditching true XMPP to promote >Google hangouts[2]) or when they have a service outage[3] then >Debian's users are left high and dry. There are also privacy >concerns, Google themselves report a 120% increase in the amount >of data they officially and knowingly give to their government[4]. >Jitsi supports any user-specified TURN server for XMPP and they >plan to support TURN for SIP too. > > * Convenient NAPTR discovery. Empathy does not autoconfigure >itself with services (such as Debian.org's own SIP proxy) that >have NAPTR records in DNS[5]. With Jitsi, this just works. > > * WebRTC integration (calling from browsers to Jitsi desktop). >This depends on new media stream features (e.g. DTLS-SRTP and AVPF) >that are not supported in Empathy yet[6]. > > * ZRTP - peer to peer encryption, like PGP for VoIP. Once again, >it has been in Jitsi for ages but is not in Empathy[7] > > * Upstream. Both Empathy and Jitsi upstreams are very >good developers. Jitsi seem to have an edge though. >Just look at how quickly they turned out the >JitMeet multi-party video conferencing solution[8] for WebRTC >browsers - it is a phenomenal achievement and delivered >in good time to help free software gain traction in the >emerging WebRTC space before any vested interests try to >monopolize the technology. > > The whole real-time communications (RTC) space is very important for > free software in general. If it fails to work conveniently and > reliably, the peer pressure of family and friends pull people back into > dangerous non-free solutions. Some of these solutions are a threat to > the whole concept of free software on mainstream desktops. With all > the recent attention on communications privacy, there has never been a > better time for Debian to try and fill this gap with a solution like > Jitsi on the front-end and the various free SIP/XMPP/TURN servers in > the back-end. > > To put it simply, the Jitsi team are blazing a trail in this area and > a Debian initiative to install Jitsi on every desktop will give them > more momentum and ensure more people can talk to each other in line > with our agreed definition of freedom. > > 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704234 > 2. > > https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging > 3. http://www.cnet.com/news/outage-hits-google-talk-hangouts/ > 4. http://www.bbc.com/news/technology-26786593 > 5. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736149#10 > 6. http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html > 7. https://bugzilla.gnome.org/show_bug.cgi?id=589778 > 8. https://jitsi.org/Projects/JitMeet > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTN94bAAoJEOm1uwJp1aqDRkgP/0jKZ2GfrIIxTy70p8b5PFDo > e9KKTkDTEINpwAdeyP2BpX5BLTEtuzgRZh+AQi7HZHbPAfCq8Cf24FjJfQyY0AgC > jDpzuX05ahNExPbpWOW4OGwinJ4S3kaPG5/o/IQC66y9tUdH0Lrh8AIvmvEgIJ9j > K0Nb669heMCdrn77ihbk9MtJlGvCE1KVOnrg+SrQLSEE1HsXk8iTXlyoGfE2T/ho > 24PxrKwhnjFoojIe0c2f/cMTMOL3prHyndYZB/Q86AiKExCow+6WtSwzb3po153i > USHFS/e+lA1+GquJXYiJq1FMUB+HiPaLer241yodqr7R5mqSD4igiF7/oQzywYId > OcxjqaLZVGxcqd5s+hmv2vCf3FXC21uDeBULZYP6TulELPGK1i6EJPpg0JqiWZbD > rE8Zs1a9W0zLOamc6jpMMx/rMC1Pml00Y69ek/c1uXW3YfxaEsiyV4cv+i99XU5B > hkkmQf5DbV+P3nQqblIkNPTydWlN/spsaLitWQsfr0cG3l4ZH+zCHKoNVl87g7Sy > CCv8FsnyhJy2wOdB//1OreDRmNK28UWwv+GM3Kf2/BI9oylbBmGbN8q3luy8KlQd > NHAledDQ0c2xEnCK0VF5NtOCQyY+cQriPcTUt1MSpq+m2mnqYj40VqBiDJITf/zz > xF+ESMftdl5n0cqmMNQJ > =UwwC > -END PGP SIGNATURE- > > __
Bug#743160: ITP: node-findup-sync -- Find the first file matching a given pattern in the current directory or the nearest ancestor directory.
Package: wnpp Severity: wishlist Owner: matthewp * Package name: node-findup-sync Version : 0.1.3 Upstream Author : Cowboy * URL : https://github.com/cowboy/node-findup-sync * License : MIT Programming Lang: js Description : Find the first file matching a given pattern in the current directory or the nearest ancestor directory. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140331015248.12856.69976.reportbug@ldc.interne-mtd
Bug#743162: ITP: node-hooker -- Monkey-patch (hook) functions for debugging and stuff.
Package: wnpp
Severity: wishlist
Owner: matthewp
* Package name: node-hooker
Version : 0.2.3
Upstream Author : Cowboy
* URL : http://github.com/cowboy/javascript-hooker
* License : MIT
Programming Lang: js
Description : Monkey-patch (hook) functions for debugging and stuff.
This library easy the debug hooking an object with a 'preHookFunction'. For
example:
hooker.hook(Math, "max", function() {
console.log(arguments.length + " arguments passed");
});
Math.max(5, 6, 7) // logs: "3 arguments passed", returns 7
It will also provide a javascript library.
This library is needed for the gruntjs packaging, supported by the pkg-js-team.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140331015643.14006.54110.reportbug@ldc.interne-mtd
Re: ca-certificates: no more cacert.org certificates?!?
On Mar 31, Brian May wrote: > On the other hand, getting back on topic, cacert.org offers you > certificates free, and for any purpose, which is why it is much better then > any of the other free alternatives (I only know one free alternative). And they are about as useful as self-signed ones, as we know. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it
On Mar 30, Thomas Goirand wrote: > See above: I'm unsure Debian Developers have yet a clear view of what > should / must be supported, and what's going to happen in this regard. > At least, it's not clear to me. I believe that it is pretty much obvious myself: http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- ciao, Marco signature.asc Description: Digital signature
