Re: Grub 2.00 in testing?
On Tue, Jul 23, 2013 at 11:01 AM, Cyril Brulebois wrote: > I want rmadison to be a remote madison, meaning a remote dak ls… which > is what it's supposed to be! That means behaving like dak ls, and > showing what matters, that is: not the extra sources. > > I hope it clarifies the above "correctness" you mentioned. rmadison > might currently reflects what's in Sources file, but that isn't the > point, or its job. Ok, makes sense, will look if the needed info is in UDD and fix the madison CGI if so. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6F_zg=od5dQgVSh7oAFFGTqKpgG12ZYySNgaZ=doq0=m...@mail.gmail.com
Re: rmadison vs. dak ls
Hi! Am 2013-07-24 08:51, schrieb Ansgar Burchardt: [..] Just out of curiosity: Does that also mean, that a user running 'apt-get source ' may not receive the package version shipped in testing, but one used by an other package? If there is both a source and binary named or requests source for a binary package, one should get the right version: +--- | $ apt-get -t testing source grub2 | [...] | Need to get 5079 kB of source archives. | Get:1 http://ftp.de.debian.org/debian/ testing/main grub2 1.99-27+deb7u1 (dsc) [3729 B] | [...] +--- Otherwise I think one gets the highest version of the source package. Ah, but that seems to work as expected then. Many thanks for testing! Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/362bc295a17ffe8d9d18bec0532b3...@ssl.alphamar.org
Joanna Lumley to open Campaign to Win Conference, London 7th Nov 2013 - Register Now
Do you have a key role or an interest in campaigning? Ever wondered why some campaigns 'fizz' and others 'fizzle'? Want to get unique insights in how to 'Win'? Come to the Campaign2Win Conference Come and interact with professionals that have in three recent successful campaigns, turned around Government Policy, saved billions of pounds for UK tax payers and businesses and increased the number of potential donating supporters for an international animal project by 6250%. Joanna Lumley, Gurkha and human rights campaigner will open this ground breaking UK conference to be held on 7th November 2013 at Glaziers Hall, London. Speakers will include Joanna herself, Quentin Willson, Robert Halfon MP plus highly experienced campaigning pros from traditional media, the law, research and social networking. The theme of this unique Conference will focus on how the elements of PR, lobbying, technology, communication, polling and the law can be fused into more than the sum of their parts to give a campaign that 'winning' momentum. Designed for organisations and individuals that need that extra help and support in making a real wining difference to their causes. There will be a strong emphasis on 'case studies' from some of the UK's most successful public affairs campaigns, including the Gurkha Justice Campaign and FairFuelUK. More details of the event and the registration form are at www.campaign2win.co.uk Hoping to see you there... Kind regards Peter Carroll Peter Carroll Associates Conference Speakers include Joanna Lumely Quentin Willson Robert Halfon MP Book your place at the Conference 7th November 2013 at Glaziers Hall, London www.campaign2win.co.uk This email has been sent to debian-devel@lists.debian.org which was sourced from your website. If you do not wish to receive further emails regarding the Campaign2Win Conference, please go to unsubscr...@campaign2win.co.uk
Bug#717730: ITP: libdime-tools-perl -- Perl module to parse and generate DIME encoded messages
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libdime-tools-perl Version : 0.03 Upstream Author : Domingo Alcázar Larrea * URL : https://metacpan.org/release/DIME-Tools * License : GPL-2 Programming Lang: Perl Description : Perl module to parse and generate DIME encoded messages DIME::Tools is a collection of modules to parse and generate DIME (Direct Internet Message Encapsulation) messages. DIME stands for Direct Internet Message Encapsulation and defines a way to encode content in a specified binary format. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130724114207.27734.56937.reportbug@localhost
Re: adequate now reports incompatible-licenses - need help to verify and file bugs
* Sune Vuorela , 2013-07-10, 11:59: On 2013-07-10, Andreas Beckmann wrote: osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+ (libgnutls.so.26) + GPLv2 (libpoppler.so.19) osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+ (libgnutls.so.26) + GPLv2 (libpoppler.so.19) osgearth: incompatible-licenses /usr/bin/osgearth_version LGPLv3+ (libgnutls.so.26) + GPLv2 (libpoppler.so.19) osgearth: incompatible-licenses /usr/bin/osgearth_viewer LGPLv3+ (libgnutls.so.26) + GPLv2 (libpoppler.so.19) osgearth also (transitively) links against OpenSSL, which is another incompatibility. tellico: incompatible-licenses /usr/bin/tellico GPLv2 (libpoppler.so.19) + LGPLv3+ (libgnutls.so.26) No need to file these. Poppler is going GPLv2+3 once next upstream lands in debian. [citation needed] At least the Debian Poppler maintainer claims that 0.20.5 is still effectively GPLv2-only: #717732. Perhaps you meant an even newer version, but I can't see anything relevant in the NEWS file either. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130724171611.ga4...@jwilk.net
Re: Survey answers part 3: systemd is not portable and what this means for our ports
brian m. carlson wrote: > On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: > > If you don't do development, and nobody sharing your views does either, > > then there's a limit to the extent you can choose your direction just by > > refusing to follow those that do develop things further. You can't stick > > with Minix forever even if you think the direction of Linux is > > undesirable. > > My point is that Debian developers create lots of great software, and > certainly maintain lots of patches to software for which Debian is not > upstream. But it's simply not feasible for Debian to be the upstream > for all software. That's true, but doesn't affect what I said above. If you can't develop Minix to be competitive then you either have to switch to Linux at some point or you'll become increasingly obsolete. > I don't think it's controversial to say that Debian > developers prefer upstreams that take concerns relevant to Debian and > its users into account. Of course. But my point was that when no other upstreams offer competitive functionality, the friendliness of upstream isn't really relevant when choosing which program to use. The friendliest possible Minix maintainer can't make it a good choice over Linux, no matter how much you despise Torvalds. In the systemd case most of the "concerns" that upstream has been accused of "not taking into account" have clearly more been controversial views of some Debian developers than concerns of its users. For example, if kFreeBSD died as a result of lacking systemd support, that would probably be a net win for users. > > Suppose that in the future systemd does go in a direction you don't > > like. Now would it have done any good for Debian to not adopt it? Not > > really, if nobody develops a competitive alternative to its > > functionality. Not using it would only make Debian obsolete for most use > > cases. And the most realistic way to create a competitive alternative > > going in a different direction would be to fork systemd, so adopting > > current systemd would not make moving to such alternatives harder. > > The vast majority of the work I do on a Linux box, desktop, laptop, or > server, does not involve init in any way. It is therefore not accurate > to claim that using an init system other than systemd would make Debian > obsolete. The init system matters for dynamic behavior like hardware discovery and network connectivity. It will matter in a lot of typical workflows, and choice of init system of course affects how easy it is to develop a distribution overall. Of course there are lots of tasks that you can still achieve on a 10-year-old machine with 10-year-old software. But even if such a machine does not become completely unusable, it is clearly obsolete. > For example, RHEL 6 and Ubuntu use upstart, and I think it's > hardly accurate, based on their significant adoption, to call them > obsolete. And Debian still defaults to sysvinit, yet I wouldn't call it obsolete yet. But it does already suffer from its init system. > > > For example, if an upstream expresses disinterest in supporting non-PC > > > architectures, that may be a bad piece of software for Debian to place > > > in an important role, even if it currently works on all our > > > architectures, since Debian is very portable among different > > > architectures. > > > > Of course, this isn't relevant to systemd, as it has no hardware- > > specific code and supports embedded platforms for which Debian is too > > bloated. > > This was meant as an illustrative example of a common problem with > upstreams, not as a problem particular to systemd. systemd upstream has > made a lot of controversial decisions that Debian may or may not want to > support: combined / and /usr, the journal, logging to the kernel ring > buffer, lack of portability to non-Linux kernels, and merging udev and > systemd are a few examples. I'd say that mainly shows that systemd upstream has managed to develop things forward. Creating and changing things involves decisions, and there's no way to make everyone happy. And when old things are changed there's bound to be a lot of controversy, even if the old stuff was total crap and new is almost perfect. I do not believe there would have been any chance to achieve a similar amount of progress without controversy. The alternative to this kind of controversy is stagnation, not any magical form of progress with total consensus. > If Debian decides that it is preferable for > whatever reason not to adopt one or more of these decisions, the > willingness of upstream to accept that decision and work with Debian > instead of saying, "Too bad, so sad," is something that should be > considered before making a major change. I'm not saying not to use > systemd, I'm just suggesting making a well-reasoned decision. I strongly disagree with the view that being a good upstream should imply accepting such arbitrary demands from distributions. IMO what a g
Bug#717784: ITP: openstack-nose -- nosetests output to mimic the output of openstack's run_tests.py
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: openstack-nose Version : 0.3 Upstream Author : Jason Kölker * URL : https://github.com/openstack-dev/openstack-nose * License : Apache-2.0 Programming Lang: Python Description : nosetests output to mimic the output of openstack's run_tests.py This package provides a nose plugin that allow's nosetests output to mimic the output of openstack's run_tests.py. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130725052411.543.45204.report...@buzig.gplhost.com
Bug#717785: ITP: python-termcolor -- ANSII Color formatting for output in terminal
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-termcolor Version : 1.1.0 Upstream Author : Konstantin Lepa * URL : https://pypi.python.org/pypi/termcolor * License : MIT Programming Lang: Python Description : ANSII Color formatting for output in terminal The termcolor Python module provides ANSII Color formatting for output in terminal. It may be useful for the output of unit testing results in color, for example using openstack.nose_plugin. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130725052914.984.7989.report...@buzig.gplhost.com
