Re: Where to upload official OpenStack Debian images?

2014-10-31 Thread Juerg Haefliger 
On Wed, Oct 29, 2014 at 11:53 AM, Thomas Goirand  wrote:
>
> On 10/29/2014 12:54 AM, Steve McIntyre wrote:
> > On Wed, Oct 22, 2014 at 03:58:04PM +0200, Juerg Haefliger wrote:
> >> Hi,
> >>
> >> On Sat, Jul 19, 2014 at 10:12 AM, Thomas Goirand 
wrote:
> >>>
> >>> On 07/18/2014 07:49 PM, Steve McIntyre wrote:
> > [2] I contacted Steve McIntyre privately about it, but he didn't
reply.
> 
>  Bugger, sorry. Must have missed the mail totally. :-(
> >>>
> >>> As I wrote on IRC, I thought you were busy with arm stuff, so I didn't
> >>> dare to ask again. It's probably my fault for not insisting.
> >>>
>  I think we could/should have space on cdimage etc.
> >>>
> >>> That'd be awesome!
> >>>
>  - how big are we talking?
> >>>
> >>> 350 / 400 MB for the normal compressed qcow2 image. We could as well
> >>> ship the raw image, but I don't think that's necessary since it's
> >>> possible to convert the qcow2 back into .img using qemu-img.
> >>
> >> I'd love to be able to download Debian cloud images from an official
place.
> >> What is missing/required to make this happen? Can I help?
> >
> > Simple lack of time thus far, to be honest. :-(
> >
> > Thomas: where are your images currently?
>
> Hi Steve,
>
> I upload them to the HP cloud, but also over here:
> http://archive.gplhost.com/openstack-images/

Very good. Thanks for the pointer.


> Though this image contains the bootlogd patch to support logging on
> multiple consoles. I'm currently trying to make this updated in
> proposed-updates though (see: #767202).
>
> On 10/29/2014 05:13 AM, Martinx - ジェームズ wrote:
> > Lets build something like this:
> > https://cloud-images.ubuntu.com/locator/ec2/ but, for Debian, of
> > course... ?
> > I can help.
>
> Let's stick to the plan of distributing the images together with the
> Debian CDs.

What exactly does that mean, 'together with the CDs'?


> It's not the role of Debian to advertize for a particular
> provider like Amazon (even though it's IMO ok to maintain the images
> within large cloud service providers).

I don't think this is about promoting cloud providers. It's about providing
a central place for users to learn where official Debian images can be
found. Are you concerned about the effort to maintain such a site or about
Debian being perceived as favoring certain cloud providers or is it against
some Debian policy?


> You may also know that we already provide some images within AWS. See
> the debian-cloud list. I would recommend anyone that maintain images to
> advertize about them in that list rather than in debian-devel or on the
> Debian web site.

IMO it feels wrong for a potential user to have to hunt through mailing
lists to find and learn about official Debian cloud images. A central place
to download images (OpenStack, AWS, Docker, ...) is very useful, links to
providers that host such images would be a nice add-on for end users but I
can understand if there's resentment.

...Juerg


> Cheers,
>
> Thomas Goirand (zigo)
>

Re: Bug#767414: ITP: 2048 -- Simple number game for the text console

2014-10-31 Thread Gabriel Pérez-Cerezo 
At Thu, 30 Oct 2014 22:02:56 -0300,
 Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi Gabriel! What would the difference be with 2048-qt which is already in the 
> archive [0]?
> 
> [0]  
2048-qt is a port for the Qt toolkit, and my 2048 package is for the
text console.  (See the screenshot [1]) My 2048 package has fewer
dependencies (only libc), while 2048-qt depends Qt. My version has
three configurable color schemes, while 2048-qt doesn't. I think
2048-qt is to 2048 what quadrapassel [3] is to tint [2], the same
game, but very different UIs and dependencies.

[1] 
[2] 
[3] 


-- 
Gabriel Pérez-Cerezo Flohr .--
GPG Key: BB09BA34D353EC69 / Email is like a postcard, anyone can read 
Website: http://gpcf.eu  / it. Please use the GPG Key to encrypt your 
Email: gabr...@gpcf.eu  / emails (tutorial: emailselfdefense.fsf.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/87ioj0fxj9.wl-gabr...@gpcf.eu

Re: Bug#767418: telegram desktop: Request Telegram client

2014-10-31 Thread Andrei POPESCU 
Control: reassign -1 wnpp
Control: retitle -1 RFP: telegram -- desktop client for the telegram messaging

On Jo, 30 oct 14, 22:58:07, Pierre Bernhardt wrote:
> Package: telegram
> Severity: wishlist
> Tags: upstream
> 
> Dear Maintainer,
> 
> Telegram Desktop is the unoffical desktop client for the telegram messaging.
> Telegram is a secured and privacy platform like what's app, but better.
> Have a look on telegra.org for the description of API, Protocols and so on.
> There is a link to tdesktop.org which is the unofficial client version
> which can be installed for linux32 and linux64 bit.
> 
> The source is available on GitHub: https://github.com/telegramdesktop/tdesktop
> The software is distributed under the license GPLv3.
> 
> Last Version from GitHub is 0.6.6.
> 
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (600, 'testing'), (500, 'proposed-updates'), (500, 'stable'), 
> (190, 'unstable'), (150, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16-2-amd64 (SMP w/6 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Where to upload official OpenStack Debian images?

2014-10-31 Thread Dimitri John Ledkov 
On 31 October 2014 08:39, Juerg Haefliger  wrote:
>
>
> On Wed, Oct 29, 2014 at 11:53 AM, Thomas Goirand  wrote:
>>
>> On 10/29/2014 12:54 AM, Steve McIntyre wrote:
>> > On Wed, Oct 22, 2014 at 03:58:04PM +0200, Juerg Haefliger wrote:
>> >> Hi,
>> >>
>> >> On Sat, Jul 19, 2014 at 10:12 AM, Thomas Goirand 
>> >> wrote:
>> >>>
>> >>> On 07/18/2014 07:49 PM, Steve McIntyre wrote:
>> > [2] I contacted Steve McIntyre privately about it, but he didn't
>> > reply.
>> 
>>  Bugger, sorry. Must have missed the mail totally. :-(
>> >>>
>> >>> As I wrote on IRC, I thought you were busy with arm stuff, so I didn't
>> >>> dare to ask again. It's probably my fault for not insisting.
>> >>>
>>  I think we could/should have space on cdimage etc.
>> >>>
>> >>> That'd be awesome!
>> >>>
>>  - how big are we talking?
>> >>>
>> >>> 350 / 400 MB for the normal compressed qcow2 image. We could as well
>> >>> ship the raw image, but I don't think that's necessary since it's
>> >>> possible to convert the qcow2 back into .img using qemu-img.
>> >>
>> >> I'd love to be able to download Debian cloud images from an official
>> >> place.
>> >> What is missing/required to make this happen? Can I help?
>> >
>> > Simple lack of time thus far, to be honest. :-(
>> >
>> > Thomas: where are your images currently?
>>
>> Hi Steve,
>>
>> I upload them to the HP cloud, but also over here:
>> http://archive.gplhost.com/openstack-images/
>
> Very good. Thanks for the pointer.
>
>
>> Though this image contains the bootlogd patch to support logging on
>> multiple consoles. I'm currently trying to make this updated in
>> proposed-updates though (see: #767202).
>>
>> On 10/29/2014 05:13 AM, Martinx - ジェームズ wrote:
>> > Lets build something like this:
>> > https://cloud-images.ubuntu.com/locator/ec2/ but, for Debian, of
>> > course... ?
>> > I can help.
>>
>> Let's stick to the plan of distributing the images together with the
>> Debian CDs.
>
> What exactly does that mean, 'together with the CDs'?
>

http://cdimage.debian.org/debian-cd/7.7.0/


>
>> It's not the role of Debian to advertize for a particular
>> provider like Amazon (even though it's IMO ok to maintain the images
>> within large cloud service providers).
>
> I don't think this is about promoting cloud providers. It's about providing
> a central place for users to learn where official Debian images can be
> found. Are you concerned about the effort to maintain such a site or about
> Debian being perceived as favoring certain cloud providers or is it against
> some Debian policy?
>

It's more to do with whether the images are fully free, built from
unmodified sources, are verifiable locally, and that the thing
launched from cloud provider panels is actually debian.
I would be happy to see to ec2/openstack/etc compatible images hosted
on cdimage, which users then may upload into a cloud environment and
launch them.
Debian policy is about packaging only.
This is more in-line with good intentions / Debian social contract.

>
>> You may also know that we already provide some images within AWS. See
>> the debian-cloud list. I would recommend anyone that maintain images to
>> advertize about them in that list rather than in debian-devel or on the
>> Debian web site.
>
> IMO it feels wrong for a potential user to have to hunt through mailing
> lists to find and learn about official Debian cloud images. A central place
> to download images (OpenStack, AWS, Docker, ...) is very useful, links to
> providers that host such images would be a nice add-on for end users but I
> can understand if there's resentment.
>

-- 
Regards,

Dimitri.


--
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/canbhlug3fxpdz-v-5kppl8sbym585i5ccknqesxqdv9c5pj...@mail.gmail.com

Re: Doxygen and embedded jquery problem, how to solve?

2014-10-31 Thread Jonas Smedegaard 
Quoting Helmut Grohne (2014-10-30 23:59:11)
> On Wed, Oct 29, 2014 at 03:59:44PM +0100, Jonas Smedegaard wrote:
>> IMO the proper solution is for Debian packaging of doxygen to 
>> untangle jQuery from extensions, depend on + symlink the jQuery part, 
>> provide the extensions as a shared package, and patch doxygen code to 
>> generate docuementation referencing each separately instead of the 
>> entangled one.
>
> Yeah, I had that opinion as well before looking into implementing it. 
> In the mean time I did remove several embedded copies of jquery from 
> Doxygen, just not the one we are discussing here.

Cool!


> Maybe you could help doing the missing work by packaging the missing 
> javascript libraries? It seems futile to discuss whether doxygen 
> should set symlinks to files that do not exist.

I could indeed help with that.  Or others in the Javascript team.

Please file RFP bugs for your needs (or if already filed please 
reference which are the relevant ones).


>> ...but seems from that README that maintainers of doxygen have 
>> already reflected on this and disagrees.
>
> I do not disagree with the goal. I just disagree that doing the work 
> is worth the^Wmy effort. I.e. patches welcome.

Fair enough.


>> I suggest (but won't drive it myself) to file a bug against doxygen 
>> to kindly reconsider...
>
> Please don't. I'd have to merge it into #736432.

Ah, cool!

Perhaps mention that bug in the README, to better encourage those 
running into this issue who might have time and interest in helping out.


>> ...and until eventually maybe progress on that front, either a) try 
>> untangle the jquery+extensions code yourself for each and every 
>> single package using doxygen, or b) embrace same attitude as doxygen 
>> maintainers and add lintian suppressions referencing doxygen README 
>> as comment.
>
> I don't think it makes any sense to untangle this in individual 
> packages. If anyone puts up that work, it should happen in Doxygen.

Right - I fully agree, and mentioned the alternative only in case the 
preferred approach was unacceptable by Doxygen maintainers - which you 
have now clearly stated is *not* the case.  Sorry if that was not clear 
from how I wrote it.


> A lintian suppression is not necessary, because this is a bug in
> lintian: #736360.
>
> Also packages shouldn't set Built-Using: doxygen. That's not what
> Built-Using was created for.

Thanks for clarifying.


 - 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: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

2014-10-31 Thread Bernhard R. Link 
* Christoph Anton Mitterer  [141030 05:10]:
> To be honest, it's really awkward to see how much all this is apparently
> fought against.

You have been told again and again that what you suggest would make the
whole thing less useable to the point that it reduces security for many
people.

You have been told that your thread model is quite strange, in that
you assume that people will
- not only notice every MITM with too old a signature even though
  you suggest to change the system so that this will cause far more
  false positives,
- but will also investigate every short network or mirror problem so
  that the far easier MITM of making the security mirrors inaccessible
  (which your suggested 'improvement' does nothing against) is not
  possible,
- but are not able to notice if there are no security updates applied.

What do you expect? That people on the list think it is a good idea to
do what in their eyes only lowers Debian's security just because someone
continues to claim the opposite?

Please take a step back and try to understand why people think this
will not help (It is not because they do not believe in evil
resourceful governments). This should make it easier to either have
arguments that persuage people or even better lead to solutions that
improve the situation more generally (I'm quite sure the are aspects
that can be improved, just that lowering Valid-Until times is
detrimental).

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
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/20141031114804.gb1...@client.brlink.eu

Bug#767503: ITP: ruby-d3-rails -- Gem installation of javascript framework for data visualization, D3

2014-10-31 Thread Balasankar C 
Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-d3-rails
  Version : 3.4.13
  Upstream Author : Han Kang 
* URL : https://github.com/logical42/d3_rails
* License : Expat, BSD-3-clause
  Programming Lang: Ruby, Javascript
  Description : Gem installation of javascript framework for data 
visualization, D3


Gem installation of javascript framework for data visualization, D3. D3 is a 
small, free JavaScript library for manipulating HTML documents based on data. 
D3 can help you quickly visualize your data as HTML or SVG, handle 
interactivity, and incorporate smooth transitions and staged animations into 
your pages. You can use D3 as a visualization framework (like Protovis), or 
you can use it to build dynamic pages (like jQuery).


-- 
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/20141031142232.6995.90732.reportbug@sasalam

Re: Where to upload official OpenStack Debian images?

2014-10-31 Thread Thomas Goirand 
On 10/31/2014 04:39 PM, Juerg Haefliger wrote:
>> On 10/29/2014 05:13 AM, Martinx - ジェームズ wrote:
>> > Lets build something like this:
>> > https://cloud-images.ubuntu.com/locator/ec2/ but, for Debian, of
>> > course... ?
>> > I can help.
>>
>> Let's stick to the plan of distributing the images together with the
>> Debian CDs.
> 
> What exactly does that mean, 'together with the CDs'?

I mean in here:
http://cdimage.debian.org/debian-cd/7.7.0/amd64/iso-cd/

>> It's not the role of Debian to advertize for a particular
>> provider like Amazon (even though it's IMO ok to maintain the images
>> within large cloud service providers).
> 
> I don't think this is about promoting cloud providers. It's about
> providing a central place for users to learn where official Debian
> images can be found. Are you concerned about the effort to maintain such
> a site or about Debian being perceived as favoring certain cloud
> providers or is it against some Debian policy?

I'm concerned that we're going to advertize only about large providers.
Why should we advertize about HP & Amazon, and not smaller players?

>> You may also know that we already provide some images within AWS. See
>> the debian-cloud list. I would recommend anyone that maintain images to
>> advertize about them in that list rather than in debian-devel or on the
>> Debian web site.
> 
> IMO it feels wrong for a potential user to have to hunt through mailing
> lists to find and learn about official Debian cloud images. A central
> place to download images (OpenStack, AWS, Docker, ...) is very useful,
> links to providers that host such images would be a nice add-on for end
> users but I can understand if there's resentment.

Then a wiki page seems more appropriate. Everyone can edit the wiki, so
it's fair enough. Though even this way, I think it's best to just ship
the images through cdimage.debian.org, and let everyone download and use
them.

Cheers,

Thomas Goirand (zigo)


-- 
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/5453a866.3090...@debian.org

Re: Where to upload official OpenStack Debian images?

2014-10-31 Thread Thomas Goirand 
On 10/31/2014 05:34 PM, Dimitri John Ledkov wrote:
> It's more to do with whether the images are fully free, built from
> unmodified sources, are verifiable locally, and that the thing
> launched from cloud provider panels is actually debian.
> I would be happy to see to ec2/openstack/etc compatible images hosted
> on cdimage, which users then may upload into a cloud environment and
> launch them.
> Debian policy is about packaging only.
> This is more in-line with good intentions / Debian social contract.

Exactly what I think, and written better than I just did. Thanks! :)

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/5453a8b4.4070...@debian.org

Re: Bug#767450: ITP: python-web.py -- framework to make web apps

2014-10-31 Thread Thomas Goirand 
On 10/31/2014 02:35 PM, Thomas Goirand wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand 
> 
> * Package name: python-web.py
>   Version : 0.37
>   Upstream Author : Anand Chitipothu 
> * URL : https://github.com/webpy/webpy
> * License : Public domain
>   Programming Lang: Python
>   Description : framework to make web apps
> 
>  web.py is a web framework for Python that is as simple as it is powerful.
>  Think about the ideal way to write a web app. Write the code to make it
>  happen.
>  .
>  web.py was originally published while Aaron Swartz worked at reddit.com, 
> where
>  the site used it as it grew to become one of the top 1000 sites according to
>  Alexa and served millions of daily page views. "It's the anti-framework
>  framework. web.py doesn't get in your way," explained founder Steve Huffman.
> 
> web.py is a dependency for Fuel web.

This one is already in debian under the name python-webpy. Sorry for the
noise.

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/5453a8e0.2030...@debian.org

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

2014-10-31 Thread Santiago Vila 
Dear ftpmasters:

Contrary to what this report suggests, I believe the current validity
of 7 days for testing and unstable is extremely low and should be
increased.

I have a laptop with testing which I use mostly on weekends. I have a
partial mirror there, which I try to update as soon as I login into
the system.

My sources.list points to the local mirror and very often it happens
that I want to install a package in the partial mirror before the
mirror update has finised. Well, many times it happens that the system
refuses to install anything because of expired Release file, sometimes
by a day or two, sometimes by just a few hours or minutes.

This is a real pain and it reminds me of "subscription" services or
DRM stuff, like those games that fail to work if the player is not "online".

Please consider increasing the expiration time. IMHO, an expiration
time of 30 days or something alike would be a lot better than the
current 7 days for testing and unstable.

Moreover, one day, testing will become stable and the expiration date
will probably be set to infinity. I think it would make sense if this
happen not suddenly but gradually during the frozen state of the
current testing distribution.

Thanks.


-- 
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/20141031153118.GA29422@nuc

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

2014-10-31 Thread Santiago Vila 
More to the point:

If we want testing to be "constantly usable" (as opposed to "mostly useless
if you don't apt-get update in a week"), the expiration time for the
Release file should be a lot closer than the one used for stable and
far away than the one used for unstable.

Thanks.


-- 
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/20141031153811.GA29879@nuc

Bug#767513: ITP: python-nose-timer -- timer plugin for nosetests

2014-10-31 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-nose-timer
  Version : 0.3.0
  Upstream Author : Mahmoud Abdelkader 
* URL : https://github.com/mahmoudimus/nose-timer
* License : BSD-and-Expat-dual-license
  Programming Lang: Python
  Description : timer plugin for nosetests

 A timer plugin for nosetests that answers the question: how much time does
 every test take? Run nosetests with the --with-timer flag, and you will see
 a list of the tests and the time spent by each one (in seconds):
 .
  myapp.tests.ABigTestCase.test_the_world_is_running: 56.0010s
  myapp.tests.ABigTestCase.test_the_rest_of_the_galaxy_is_running: 2356.0010s
 .
 It is also possible to list the 10 slowest tests this way:
 .
  nosetests --with-timer --timer-top-n 10


-- 
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/20141031155212.14755.61988.report...@buzig.gplhost.com

Bug#767515: ITP: python-nose-parameterized -- decorator for parameterized testing with Nose

2014-10-31 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-nose-parameterized
  Version : 0.3.4
  Upstream Author : David Wolever 
* URL : https://github.com/wolever/nose-parameterized
* License : BSD-2-clause
  Programming Lang: Python
  Description : decorator for parameterized testing with Nose

 nose-parameterized is a decorator for parameterized testing with nose.
 .
 Nose. It's got test generators. But they kind of suck:
  * They often require a second function
  * They make it difficult to separate the data from the test
  * They don't work with subclases of unittest.TestCase
  * kwargs? What kwargs?


-- 
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/20141031160957.17644.93382.report...@buzig.gplhost.com

Re: Bug#767414: ITP: 2048 -- Simple number game for the text console

2014-10-31 Thread Lisandro Damián Nicanor Pérez Meyer 
On Thursday 30 October 2014 22:02:56 Lisandro Damián Nicanor Pérez Meyer 
wrote:
[snip]
> > I would maintain the package, because I am also the upstream maintainer.
> 
> Hi Gabriel! What would the difference be with 2048-qt which is already in
> the archive [0]?
> 
> [0] 

Matthias is right, it seems I skipped the relevant part entirely.

Sorry for the noise!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#767522: ITP: python-sphinxcontrib.plantuml -- PlantUML extension for Sphinx

2014-10-31 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-sphinxcontrib.plantuml
  Version : 0.5
  Upstream Author : Yuya Nishihara 
* URL : https://pypi.python.org/pypi/sphinxcontrib-plantuml
* License : BSD-2-clause
  Programming Lang: Python
  Description : PlantUML extension for Sphinx

 Once you enable this extension, a very simple string like this:
  "Alice -> Bob: Hi!"
 will create a nice UML schema. WIth PlantUML, you can specify things like
 height, width, scale, caption and so on. For details, please see PlantUML
 documentation at: http://plantuml.sourceforge.net/.


-- 
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/20141031173852.24175.63230.report...@buzig.gplhost.com

Re: Doxygen and embedded jquery problem, how to solve?

2014-10-31 Thread Helmut Grohne 
Hi Jonas,

On Fri, Oct 31, 2014 at 11:37:48AM +0100, Jonas Smedegaard wrote:
> Please file RFP bugs for your needs (or if already filed please 
> reference which are the relevant ones).

I have no clue about this JavaScript stuff and little intentions to
learn it. After my inquiry, Doxygen upstream kindly added a jquery
folder to the Doxygen source with this README:

http://sources.debian.net/src/doxygen/1.8.8-4/jquery/README/

It tells you what is needed, but I am not entirely sure that it is kept
up to date, so maybe look into the folder as well. Please file those
RFPs yourself, as it requires knowledge of the ecosystem.

Beware though, that just having these libraries in the archive is not
sufficient for the doxygen package to use them. What we really need here
is the exact versions used by Doxygen and the guarantuee that they will
stick around as long as necessary. Since documentation is usually
Arch:all, it cannot just be binNMUed to remove Depends on outdated
JavaScript libraries.

So we probably need what Paul Tagliamonte said in this thread:

| This is the place in which I remind people javascript-common with
| multiple versions of jQuery would reduce maintainer burden and avoid
| filling the archive with tons of binaries if someone has a spare few hours.
|
| For jessie+1 I guess.

Maybe you start seeing why I gave up on this one. I still hope that some
day removing this embedding will be feasible.

Helmut


-- 
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/20141031192249.ga13...@alf.mars

Re: Bug#767414: ITP: 2048 -- Simple number game for the text console

2014-10-31 Thread Gabriel Pérez-Cerezo 
At Fri, 31 Oct 2014 13:32:11 -0300,
Lisandro Damián Nicanor Pérez Meyer wrote:
> Matthias is right, it seems I skipped the relevant part entirely.
Excuse me, but did I miss an email?


-- 
Gabriel Pérez-Cerezo Flohr .--
GPG Key: BB09BA34D353EC69 / Email is like a postcard, anyone can read 
Website: http://gpcf.eu  / it. Please use the GPG Key to encrypt your 
Email: gabr...@gpcf.eu  / emails (tutorial: emailselfdefense.fsf.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/87tx2kuir7.wl-gabr...@gpcf.eu

Re: Bug#767414: ITP: 2048 -- Simple number game for the text console

2014-10-31 Thread Mattia Rizzolo 
On Fri, Oct 31, 2014 at 8:44 PM, Gabriel Pérez-Cerezo  wrote:
> At Fri, 31 Oct 2014 13:32:11 -0300,
> Lisandro Damián Nicanor Pérez Meyer wrote:
>> Matthias is right, it seems I skipped the relevant part entirely.
> Excuse me, but did I miss an email?

maybe. he sent it only to debian-devel@:
https://lists.debian.org/20141031060657.gb8...@smurf.noris.de

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


--
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/cahkymet4aas2xorkat-upsv1+hu3m1nspxbey054hddyvrr...@mail.gmail.com

Re: Bug#767414: ITP: 2048 -- Simple number game for the text console

2014-10-31 Thread Gabriel Pérez-Cerezo 
At Fri, 31 Oct 2014 22:30:47 +0100,
Mattia Rizzolo wrote:
> https://lists.debian.org/20141031060657.gb8...@smurf.noris.de
Yes, that's the email I have been looking for.

-- 
Gabriel Pérez-Cerezo Flohr .--
GPG Key: BB09BA34D353EC69 / Email is like a postcard, anyone can read 
Website: http://gpcf.eu  / it. Please use the GPG Key to encrypt your 
Email: gabr...@gpcf.eu  / emails (tutorial: emailselfdefense.fsf.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/87sii3vpaa.wl-gabr...@gpcf.eu

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

2014-10-31 Thread Wouter Verhelst 
On Thu, Oct 30, 2014 at 06:21:52PM +0100, Christoph Anton Mitterer wrote:
> On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote: 
> > I would hope Debian never becomes a "truly security conscious"
> > distribution by that definition.
> 
> > It implies the distribution thinks it
> > knows better than its users what the right security trade-off is, and
> > that way lies disaster.
> Isn't that the very what we actually do right now?!
> 
> We think we know better which validity time is appropriate to the attack
> model of users.
> We think we know better whether and how users should educate themselves
> above upgrades.
> We think we know better which algos are still appropriate for the user
> or not.
> 
> AFAIU the term "truly security conscious" it's:
> - assuming the worst (attack)
> - default to be secure 
> - in case of uncertainty, security critical warnings or error, or in
> case of unexpected things: try to educate the user what's likely to be
> going on and leave the choice up to him (e.g. disable SSL3 per default,
> tell the user why, but allow him to override
> - try to deploy security to the masses in a way they can still deal with
> it, and not just to the few paranoid people that really dig into it.

You're missing the most critical part of "security": realize that at the
end of the day, a computer is still a tool to get a job done. If
security gets in the way, it gets disabled, so that ends you up with a
worse situation than what you had before.

The world's most secure computer in the world is powered down, encased
in a solid block of concrete, lying at the bottom of the Challenger
Deep.

It is also the world's most useless computer.

To be truly security conscious is to realize that "computer security" is
a study of the condition of the human mind (both that of the attacker
and the attacked) rather than an exact science.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#767545: ITP: minepeon -- MinePeon is a web inteface for managing cryptocoin mining with CGminer or bfgminer

2014-10-31 Thread Shawn L. Djernes 
Package: wnpp
Severity: wishlist
Owner: "Shawn L. Djernes" 

* Package name: minepeon
  Version : 0.30PR2
  Upstream Author : Neil Fincham 
* URL : http://minepeon.com/
* License : GPL-3
  Programming Lang: PHP
  Description : MinePeon is a web inteface for managing cryptocoin mining 
with CGminer or bfgminer

MinePeon is a web interface to manage cryptocoin mining (Bitcoin, Litecoin etc)
with CGminer or BFGminer. MinePeon provides an easy way to configure the miner
and provides statistical capture with graphing via RRD.

-- Why Package It?
Debian has almost all the tools to create an embedded cryptocoin mining 
controller for use with ASIC and FPGA type hardware. The only thing missing
is an easy to use and manage interface.  I feel that MinePeon provides this.
Since MinePeon is web based it also allows for the creation of headless
mining control devices such as for use with an RPi or CubieTruck.

-- Plan for Package Maintenance?
This is my first package so there will be some bumps in the road.  Once I have
the package buildible and installable (Per Policy), I plan to submit it to the
pkg-bitcoin-dev group for review and possible sponsorship into Debian Proper.


-- 
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/20141101002751.102090.2732.report...@jessie-vm.locobird.net