Bug#705091: ITP: libfennec-perl -- Perl test helper providing RSPEC, Workflows, Parallelization, and Encapsulation
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libfennec-perl Version : 1.012 Upstream Author : Chad Granum * URL : https://metacpan.org/release/Fennec * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl test helper providing RSPEC, Workflows, Parallelization, and Encapsulation Fennec started as a project to improve the state of testing in Perl. Fennec looks to existing solutions for most problems, so long as the existing solutions help meet the features listed below. -- 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/20130410043620.31473.86139.reportbug@localhost
Bug#705085: ITP: pear-aws-channel -- PEAR channel definition file for aws
Package: wnpp Severity: wishlist Owner: David Prévot Control: block 705070 by -1 * Package name: pear-aws-channel Version : 0~20130409 * URL : http://pear.amazonwebservices.com/ * License : public-domain Programming Lang: XML Description : PEAR channel definition file for aws This is the PEAR channel registry entry for aws. PEAR is a framework and distribution system for reusable PHP components. A PEAR channel is a website that provides package for download and a few extra meta-information for files. signature.asc Description: Digital signature
Re: Legal possibility of more open package reviews.
Charles Plessy wrote: > Conversely, the existence of sites such as Ubuntu's PPA, SourceForge, GitHub > and many others show that a large number of software providers are confident > that a policy of a posteriori removals is sufficient. I do not understand why > we do not reach the same conclusion for the NEW queue, which is not even a > software distribution in the sense of the Debian archive or the sites > mentionned above. One significant difference between those sites and the Debian NEW queue, or Debian in general is that sites that allow anyone register and upload content probably operate under the DMCA safe harbor provisions that only require they take down infringing material when informed of it. -- see shy jo signature.asc Description: Digital signature
Re: Legal possibility of more open package reviews.
On 04/10/2013 06:56 AM, Charles Plessy wrote: > Le Tue, Apr 09, 2013 at 05:54:14PM +0200, Bernd Zeimetz a écrit : >>> Suggestion #3: have a system where any other DD can review >>> a package in the NEW queue, not only the FTP masters or the >>> FTP assistants. >> That would include publishing the contents of the NEW queue, >> at least to all Debian Developers - so we might violate >> licenses already. > I have not read any convincing argument in favor of our current practice, not > to mention that most arguments are guesses on the reasons of the persons in > charge rather than a clear statement from the persons in charge themselves. > > We do not have much measures in place to ensure that our archive does not > contain packages that start to violate licenses after their first upload. In > parallel, we have a lot of download points that are not subjected to copyright > and license review. I do not see a reason why the NEW queue must be more > perfect than both our archive and the rest of the non-aptable files we > distribute. > > Conversely, the existence of sites such as Ubuntu's PPA, SourceForge, GitHub > and many others show that a large number of software providers are confident > that a policy of a posteriori removals is sufficient. I do not understand why > we do not reach the same conclusion for the NEW queue, which is not even a > software distribution in the sense of the Debian archive or the sites > mentionned above. > > Fedora for instance publicly reviews the new packages in a bugtracker, with > download links that sometimes are pointing to Fedora-hosted machines. I think > that reaching that level of transparency would have a positive impact on our > capacity to keep on attracting new contributors. > > Cheers, Exactly. Very well said! Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5164be8d.1090...@debian.org
Re: Git packaging workflow discussion on planet.d.o
On Thu, Apr 04, 2013 at 02:25:30PM +, Jeremy Stanley wrote: > makes a lot of sense. If your packaging workflow does not rely on > importing the contents of release tarballs, then for projects like > this you miss some content unless you re-run the same release > scripts post-facto. That was the part I didn't understand. What are people doing to solve this generated files at release problem? I've solved this as upstream and a Debian developer by having tarballs. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- 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/20130409231104.gb16...@enc.com.au
Legal possibility of more open package reviews.
Le Tue, Apr 09, 2013 at 05:54:14PM +0200, Bernd Zeimetz a écrit : > > >Suggestion #3: have a system where any other DD can review > >a package in the NEW queue, not only the FTP masters or the > >FTP assistants. > > That would include publishing the contents of the NEW queue, > at least to all Debian Developers - so we might violate > licenses already. I have not read any convincing argument in favor of our current practice, not to mention that most arguments are guesses on the reasons of the persons in charge rather than a clear statement from the persons in charge themselves. We do not have much measures in place to ensure that our archive does not contain packages that start to violate licenses after their first upload. In parallel, we have a lot of download points that are not subjected to copyright and license review. I do not see a reason why the NEW queue must be more perfect than both our archive and the rest of the non-aptable files we distribute. Conversely, the existence of sites such as Ubuntu's PPA, SourceForge, GitHub and many others show that a large number of software providers are confident that a policy of a posteriori removals is sufficient. I do not understand why we do not reach the same conclusion for the NEW queue, which is not even a software distribution in the sense of the Debian archive or the sites mentionned above. Fedora for instance publicly reviews the new packages in a bugtracker, with download links that sometimes are pointing to Fedora-hosted machines. I think that reaching that level of transparency would have a positive impact on our capacity to keep on attracting new contributors. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130409225639.ga16...@falafel.plessy.net
Bug#705075: ITP: googlizer -- search the web for the contents of your X clipboad
Package: wnpp Severity: wishlist Owner: Tobias Richter This package that I really like was first orphaned and then removed, without me noticing. In case an ITP is not the correct procedure at this point, please advise. The reason for removal was "RoQA; orphaned, better alternatives exist". GNOME shell was named as the "better alternative". On LXDE there is no parallel functionality as far as I am aware. I am aware that upstream isn't active, but given that we are talking about 105 lines of C code this shouldn't be a problem. There are no known bugs, only the packaging needs to be updated. * Package name: googlizer Version : 0.3 Upstream Author : Alan Cox * URL : ftp://ftp.linux.org.uk/pub/linux/alan/Software/Gnome/Googlizer * License : GPLv2 Programming Lang: C Description : search the web for the contents of your X clipboad This is a very simple and very handy utility that just spawns the configured browser with a Google search on whatever you have in the X clipboard (whatever you last selected). It's not even an applet, just a program with a launcher that's nice to put on the panel - drag it there from the menu. It also includes support for a command line option -u/--url, to specify an alternative URL to which the search should be appended before opening. -- 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/20130409205936.14397.57944.report...@cave.achos.com
Tecnicas Super Efectivas de Cobranza
Técnicas Súper Efectivas de Cobranza. Fecha: 15 de abril - 10:00 a.m a 1:00 p.m y De 3:00 p.m. a 6:00 p.m. (Hora del Centro de México). Lugar: Su computadora o dispositivo móvil. Usted aprenderá lo que tiene que saber para evitar pasos legales en falso, recibirá herramientas y técnicas que necesita para ser más productivo, más eficaz y más contundente, sin mencionar que estará menos estresado en el trabajo. Se incluye: •Cómo manejar excusas, mentiras y quejas de los deudores. •Calme a clientes furiosos e irracionales con técnicas que trabajan como un encanto. •Mantenga su organización fuera de problemas, sabiendo exactamente cuáles son sus derechos y límites legales. Adquiera el folleto completo y sin compromiso, solo responda este correo con asunto "tecnicas cobranza" y se lo enviaremos a la brevedad. O bien, comuníquese a nuestro Centro de Atención Telefónica al 018002129393 ¡Será un placer atenderle! Lic. Isaias Koyoc. Líder de Proyectos ¡Reenvíe esta invitación a compañeros que les pueda ser de utilidad! Para eliminar su correo debian-devel@lists.debian.org de nuestra lista responda tec15. -- 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/68fc2aaff9c7ba24f62914100010b...@atraccionenventas.info
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 09/04/13 17:54, Bernd Zeimetz wrote: > On 02.04.2013 22:48, Thomas Goirand wrote: >> On 04/02/2013 12:16 AM, Luca Falavigna wrote: >>> In a perfect world there wouldn't be any need for a NEW queue at all. >>> But we have to face with the reality. >>> We try to do our best to improve things where we can. From the FTP >>> Team side, we always try to be quick and helpful with our fellow >>> developers, and are happy to hear about suggestions how to improve >>> further. >> I got a bunch of suggestions... >> >> Suggestion #1: if a package stays more than a month in the NEW >> queue, then it gets automatically approved, and may be >> reviewed later on. My reasoning is that more than a month, >> it can become really problematic and blocks development. > > No. Go back to start and learn why there is a NEW queue. > >> Suggestion #2: get rid of the new binary queue (not new source >> package, that's different). There's no reason why the licensing >> of a package changes just because the maintainer decides to add >> a new binary, so it makes no sense. This would save a lot of >> time for the FTP team. > > No. Go back to start and learn why there is a NEW queue. That answer is not so clear Plenty of packages have evolved with new upstream releases over many years without any ongoing review by the FTP masters. I'm sure I could find one that has subsequently and inadvertently become non-free if I really looked hard enough. Why should review only take place on those packages that the maintainer chooses to modularise? Isn't it the content of the source package that needs review? Maybe the review should be triggered by some other factor? For example, every time a new upstream major release number increment occurs, the upload goes into NEW? >> Suggestion #3: have a system where any other DD can review >> a package in the NEW queue, not only the FTP masters or the >> FTP assistants. > > That would include publishing the contents of the NEW queue, > at least to all Debian Developers - so we might violate > licenses already. That is not a watertight argument either - it would be quite feasible to publicize the source package without making the upstream tarball public. Just make sure that other DDs can see a link to the upstream tarball on the upstream web site, and the hash from the changes file This would actually be a very good way of helping to distribute the workload of FTP masters as all DDs could presumably practice rejecting things, while the decision to accept something would remain with the FTP master. I also value the work of the FTP masters and everybody who scrutinizes packages to make sure they really are free and open. Just look at the Android market for an example of what would evolve without such efforts. -- 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/516465b6.4050...@pocock.com.au
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/09/2013 11:54 PM, Bernd Zeimetz wrote: > So when did you offer yourself to join the FTP team? I didn't offer to completely join forever, but I offered my help, few months ago. Though considering the mistakes I did in the past (and still do from time to time, despite my (probably wrong) feeling to do double-checks), I do understand why they didn't feel comfortable with me checking for licenses. On 04/09/2013 11:54 PM, Bernd Zeimetz wrote: >> Suggestion #2: get rid of the new binary queue (not new source >> package, that's different). There's no reason why the licensing >> of a package changes just because the maintainer decides to add >> a new binary, so it makes no sense. This would save a lot of >> time for the FTP team. > > No. Go back to start and learn why there is a NEW queue. No what? To which part of the above? Would you care to explain, since I'm so dumb and I should learn? In what way adding lines in debian/control changes the licensing of upstream source? > >> Suggestion #5: make it so that a bunch of packages can be >> reviewed together, as they might depend on each other, and we >> would like to avoid cases where some packages are accepted, but >> can't be installed because their dependencies are in NEW. > > And that breaks exactly what? Such a package will never migrate > to testing. No harm done. Also you might want to avoid to depend > on packages not yet in Debian as they might never end up in > Debian at all. If I upload new packages A and B, that A depends and B, and that A gets approved, but B doesn't, then we end up with package A being in Debian, but never installable. Now, if what you are suggesting that I should wait for B to be approved before uploading A, I think you aren't being realistic when the NEW queue has a 3 months waiting time. This might work with small projects, but if you have to maintain a complex set of packages, with lots of dependencies, it just doesn't work. Been there, tried that ... Also, thinking only about testing, when we have a 10 months period of freeze, is quite crazy. So yes, harm done, even in Experimental (during the freeze)! > No. Go back to start and learn why there is a NEW queue. You didn't need to repeat this sentence 3 times. I believe I know why we have it, never the less, I feel like there would be better ways to handle the problem. I'm only the vocal person here, I know I'm not the only one thinking this way. Others probably fear the reaction of the FTP masters, I personally think (and hope) they are smarter than this and accept constructive critics. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51646364.9040...@debian.org
Bug#705070: ITP: aws-sdk-for-php -- software development kit to build solutions for Amazon
Package: wnpp Severity: wishlist Owner: David Prévot * Package name: aws-sdk-for-php Version : 1.6.2 Upstream Author : Ryan Parman * URL : http://aws.amazon.com/sdkforphp/ * License : Apache-2.0 Programming Lang: PHP Description : software development kit to build solutions for Amazon Official PHP SDK for Amazon Web Services. It allows developers to build solutions for Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon SimpleDB, and more. I intend to maintain it under Debian PHP PEAR umbrella, and get rid of the embedded copy in the current experimental version of owncloud. Regards David signature.asc Description: Digital signature
Re: Interactive package management via aptitude
On Tue, Apr 09, 2013 at 06:15:12PM +0200, Andreas Beckmann wrote: > On 2013-04-09 17:57, Osamu Aoki wrote: > [...] > >>> I'm not sure if it makes sense to recommend aptitude in its present state. > >> I wouldn't recommend it when operating with multiarch enabled. Otherwise > >> it's > >> mostly fine. > Looks like we should start doing some automated upgrade tests with > aptitude ... jenkins.debian.net would be one solution, piuparts another > (anybody who wants to write a patch?). That sounds like a waste of time to me unless someone is first going to fix aptitude's resolver to not propose solutions that *directly contradict what the user requested on the commandline*. http://bugs.debian.org/661678 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Interactive package management via aptitude
> > Aptitude installs all recommended packages by default which was rather > > annoying until I found that in the options menu as I ran out of space a > > couple of times. > > as does apt-get. I'm fairly sure synaptic doesn't select recommended by default, however the synaptic package itself is a package where installing recommended packages by default may be a good idea (Adds useful repo management functionality like add cdrom (which isn't obvious from the dependency descriptions) without pulling in the world). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/827742.38594...@smtp104.mail.ird.yahoo.com
Re: Interactive package management via aptitude
On 2013-04-09 17:57, Osamu Aoki wrote: [...] >>> I'm not sure if it makes sense to recommend aptitude in its present state. >> >> I wouldn't recommend it when operating with multiarch enabled. Otherwise it's >> mostly fine. Looks like we should start doing some automated upgrade tests with aptitude ... jenkins.debian.net would be one solution, piuparts another (anybody who wants to write a patch?). Andreas -- 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/51643e90.3040...@debian.org
Re: Interactive package management via aptitude
On 04/09/2013 11:57 AM, Osamu Aoki wrote: Hi, On Tue, Apr 09, 2013 at 09:32:52AM +0800, Chow Loong Jin wrote: On 09/04/2013 06:43, Adam Borowski wrote: Have you been able to get that effect from aptitude? It seems that whenever it sees some trouble (sometimes even when plain apt-get would succeed), it proposes to remove the world, install a few unrelated packages, and not do whatever you requested it to. After declining a varying number of such "solutions", it gives up even if it would take a single action to resolve the problem. Yeah, I have actually. It's just that the recent multiarch issues (which still haven't been fixed) tend to lead to aptitude attempting to remove the whole (foreign-arch) world. If none of the other decisions make sense, you're actually able to prod aptitude in the right direction by supplying some extra operations interactively at the [Y|n|q] prompt. I'm not sure if it makes sense to recommend aptitude in its present state. I wouldn't recommend it when operating with multiarch enabled. Otherwise it's mostly fine. Yes but it is not that bad. I was also shocked to see: * denial of downgrade request as the first suggestion * massive package removal as the second suggestion I've seen behaviors approximating this from aptitude even without multiarch - indeed, from years before multiarch was even proposed AFAIK. It's precisely that sort of thing that leads me to use apt-get over aptitude almost exclusively. When going through a dozen or more - or several dozen - suggested resolutions which don't even come close to achieving what I requested on the command line (and often seem to be getting progressively further away from it, at that) is more the rule than the exception for aptitude, but apt-get seems to consistently find a suitable resolution on the first try, it seems to me that something is wrong with the aptitude resolver. apt-get's dependency resolver may be less "smart" than that of aptitude, but it also seems to fail less stupidly. Since last I heard mixing and matching between the two is not encouraged (though I don't know why not), and since dealing with the limitations of apt-get is far less aggravating for me than dealing with the attempted cleverness of aptitude, I find the older program by far the more preferable solution. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- 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/51643da4.9050...@fastmail.fm
Re: Interactive package management via aptitude
Hi, On Tue, Apr 09, 2013 at 09:32:52AM +0800, Chow Loong Jin wrote: > On 09/04/2013 06:43, Adam Borowski wrote: > > On Tue, Apr 09, 2013 at 04:19:19AM +0800, Chow Loong Jin wrote: > >> Actually, in the event of aptitude not being able to resolve the > >> dependencies > >> satisfactorily the first round (from aptitude install foo), aptitude > >> allows you > >> to interactively pick other solutions, or tell it what to do: > > > > Have you been able to get that effect from aptitude? It seems that > > whenever it sees some trouble (sometimes even when plain apt-get would > > succeed), it proposes to remove the world, install a few unrelated > > packages, and not do whatever you requested it to. After declining a > > varying number of such "solutions", it gives up even if it would take a > > single action to resolve the problem. > > Yeah, I have actually. It's just that the recent multiarch issues (which still > haven't been fixed) tend to lead to aptitude attempting to remove the whole > (foreign-arch) world. If none of the other decisions make sense, you're > actually > able to prod aptitude in the right direction by supplying some extra > operations > interactively at the [Y|n|q] prompt. > > > I'm not sure if it makes sense to recommend aptitude in its present state. > > I wouldn't recommend it when operating with multiarch enabled. Otherwise it's > mostly fine. Yes but it is not that bad. I was also shocked to see: * denial of downgrade request as the first suggestion * massive package removal as the second suggestion I will be very careful when managing multiarch package with some strict version dependency aptitude. It seems we need to mark both archs simultaneously when we do not-so-common thing such as downgrade. (Also some version selection result seems not to be updated in display but effective internally. I still do not understand what aptitude is doing ... vey strange) It was libboost causing bug for the last release and this time multiarch. So we should keep this text this time again. Osamu -- 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/20130409155731.GC15352@goofy.localdomain
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 02.04.2013 22:48, Thomas Goirand wrote: On 04/02/2013 12:16 AM, Luca Falavigna wrote: In a perfect world there wouldn't be any need for a NEW queue at all. But we have to face with the reality. We try to do our best to improve things where we can. From the FTP Team side, we always try to be quick and helpful with our fellow developers, and are happy to hear about suggestions how to improve further. I got a bunch of suggestions... Suggestion #1: if a package stays more than a month in the NEW queue, then it gets automatically approved, and may be reviewed later on. My reasoning is that more than a month, it can become really problematic and blocks development. No. Go back to start and learn why there is a NEW queue. Suggestion #2: get rid of the new binary queue (not new source package, that's different). There's no reason why the licensing of a package changes just because the maintainer decides to add a new binary, so it makes no sense. This would save a lot of time for the FTP team. No. Go back to start and learn why there is a NEW queue. Suggestion #3: have a system where any other DD can review a package in the NEW queue, not only the FTP masters or the FTP assistants. That would include publishing the contents of the NEW queue, at least to all Debian Developers - so we might violate licenses already. Suggestion #4: recognized that the FTP team needs to work faster, and get more people in the FTP team. When did you read the last announce mail from the FTP team? They always look for people to join. But it is a lot of work, so rarely people like to join. Or they don't get into the team because they fail to understand what they have to take care of. So when did you offer yourself to join the FTP team? Suggestion #5: make it so that a bunch of packages can be reviewed together, as they might depend on each other, and we would like to avoid cases where some packages are accepted, but can't be installed because their dependencies are in NEW. And that breaks exactly what? Such a package will never migrate to testing. No harm done. Also you might want to avoid to depend on packages not yet in Debian as they might never end up in Debian at all. Suggestion #6: get rid of the NEW queue completely. I'm not the only one that thinks it should be like that, and that the licensing review process could happen after packages are accepted. Maybe though, I'll be the only one saying it out loud (but I'm getting used to it...). No. Go back to start and learn why there is a NEW queue. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/3f9836d48fe7ac1b5f0d254d3266c...@mail.recluse.de
Re: Interactive package management via aptitude
Hi, > Le Mon, Apr 08, 2013 at 06:02:27PM +0300, Eugene Lychauka a écrit : > > http://www.debian.org/releases/testing/amd64/release-notes/ch-whats-new.html#pkgmgmt > > > > Here we can read: > > > > "The preferred program for interactive package management from a > > terminal is aptitude. For a non-interactive command line interface for > > package management, it is recommended to use apt-get." > > > > What is meant by interactive interface and non-interactive interface > > here? I understand it as typing "aptitude install foo" is > > non-interactive interface, and the text-user interface of aptitude > > launched by typing "aptitude" is interactive interface. Am I right? You are right. > > Some people assure me that not. Who are they and what are they telling? On Tue, Apr 09, 2013 at 07:40:22AM +0900, Charles Plessy wrote: > The same text is found in Squeeze and Lenny's release notes, at the "What's > new > in the distribution?" chapter. Have you considered to propose to the > maintainers of the release notes to delete that part completely if you thing > it > is confusing, since it brings no new information at all ? At one point we recommended aptitude for everything. Since it caused some trouble in 2010, we settled for this new text quoted in the above. See http://bugs.debian.org/411280 It was fixed to be in current text in 2010 as I recall. So this text is from Sarge I think. The essence of this long bug discussion can be summarized: > Steve Langasek wrote in 2010 http://bugs.debian.org/411280#35 > I think it's clear that the behavior of aptitude in releases after etch has > not been stable and predictable enough for us to recommend it in the release > notes as a non-interactive upgrade interface. I will submit a patch to the > release notes to address this. Osamu -- 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/20130409154725.GB15352@goofy.localdomain
Bug#705062: ITP: libperlx-maybe-xs-perl -- XS backend for PerlX::Maybe
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libperlx-maybe-xs-perl Version : 0.004 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/PerlX-Maybe-XS * License : Artistic or GPL-1+ Programming Lang: Perl, C Description : XS backend for PerlX::Maybe PerlX::Maybe::XS is a (possibly 30% faster) XS implementation of PerlX::Maybe. -- 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/20130409153831.2512.52540.report...@auryn.jones.dk
Re: Bug#704686: ITP: ruby-arr-pm -- RPM reader and writer Ruby library
> Laurent Bigonville wrote: > >Package: wnpp > >Severity: wishlist > >Owner: Laurent Bigonville > > > >* Package name: ruby-arr-pm > > Version : 0.0.8 > > Upstream Author : Jordan Sissel > >* URL : https://github.com/jordansissel/fpm > >* License : Apache 2.0 > > Programming Lang: Ruby > > Description : RPM reader and writer Ruby library > > > >This Ruby library allows to you to read and write rpm packages. > >Written in pure ruby because librpm is not available on all systems > > I'm very curious - why would we want this in Debian? Surely librpm > *is* available on all the systems we support? Hi, This ruby gem is needed by FPM (see my ITP[0]). FPM is able to create .deb but also .rpm from different sources (a directory, a gem file, an other rpm...). I should maybe rephrase the description if you prefer. Cheers Laurent Bigonville [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688896 -- 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/20130409173320.558b1...@soldur.bigon.be
Bug#705047: ITP: ruby-hiredis -- redis ruby driver using Hiredis
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos * Package name: ruby-hiredis Version : 0.4.5 Upstream Author : Pieter Noordhuis * URL : http://github.com/pietern/hiredis-rb * License : BSD Programming Lang: Ruby Description : redis ruby driver using Hiredis ruby-hiredis provides a Ruby extension that wraps hiredis. Both the synchronous connection API and a separate protocol reader are supported. It is primarily intended to speed up parsing multi bulk replies. -- 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/20130409142243.GA21158@marvin
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Tue, Apr 9, 2013 at 3:15 PM, Thomas Goirand wrote: > On 04/03/2013 04:34 AM, Thomas Goirand wrote: >> On 04/01/2013 11:06 PM, Luca Falavigna wrote: >>> On the other hand, FTP Team is willing to fast-track NEW packages >>> anytime, if needed. >> That's simply not truth. I can't let you say that and not reply. > So again, thanks so much Luca! +1 Thanks Luca for your careful review, you manage to still catch glitch in packages while under pressure ! -- 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/CA+7wUsz2gqwY2sa2=823cn6eqc5c052ruxsdbhb0x1rsx+o...@mail.gmail.com
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/03/2013 04:34 AM, Thomas Goirand wrote: > On 04/01/2013 11:06 PM, Luca Falavigna wrote: >> On the other hand, FTP Team is willing to fast-track NEW packages >> anytime, if needed. > That's simply not truth. I can't let you say that and not reply. Hi, I would like to publicly thanks Luca for all the FTP Master assistant work that he did on the Openstack packages recently. Nearly all of the Openstack packages have been approved, and now I'm down to python-pecan and websockify, which have been rejected, for very valid reasons, with 2 or 3 files that are sourceless. I'll work on them, and create a DFSG version, hoping that I can finish the work before the next week Openstack summit. Saying "well, all is done but it's waiting FTP masters approval" is really not the same as saying "well, yeah, everything is now in Debian" !!! This was a very frustrating situation a week ago, and what just happened fills me with a lot of satisfaction. I am really convince that your work will really make a difference next week, when we will discuss with Ubuntu guys, and try to convince everyone that Debian is also a good platform for Openstack. So again, thanks so much Luca! Thomas P.S: I'm unsure if I'll upload all of Grizzly this week to Experimental or what, if I can fix python-pecan and websockify... -- 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/51641476.3050...@debian.org
Bug#705043: ITP: libmodule-install-contributors-perl -- add an "x_contributors" section to your META.yml
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libmodule-install-contributors-perl Version : 0.001 Upstream Author : Toby Inkster * URL : https://metacpan.org/release/Module-Install-Contributors * License : Artistic or GPL-1+ Programming Lang: Perl Description : add an "x_contributors" section to your META.yml Module::Install::Contributors is a plugin for Module::Install. It adds a "x_contributors" section to your META.yml file. This is an array of strings, which should normally be in "Name " 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/20130409121547.10178.43.report...@auryn.jones.dk
Re: Interactive package management via aptitude
On Tue, Apr 9, 2013 at 7:29 PM, Wookey wrote: > Is anyone actually working on making the aptitude multiarch-friendly, or > planning to? It appears so, see the bottom of this mail: http://lists.debian.org/deity/2013/04/msg00027.html -- 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/CAKTje6EBbM4Zp-rNK_b=eyfoqc3zyv9olvlzncfpmkbybjq...@mail.gmail.com
Re: Interactive package management via aptitude
On Tue, Apr 09, 2013 at 12:29:09PM +0100, Wookey wrote: [cut] > > I too am a huge aptitude fan. The curses UI is brilliant for working > out what's up when things are a bit broken. However it doesn't deal > with multiarch well so I've been stuck with apt-get trying to work out > fro the tealeaves what's wrong. Is anyone actually working on making > the aptitude multiarch-friendly, or planning to? Or has at least > tthought about how hard a problem it is? My understanding was that aptitude lagged behind in its support for multiarch, but that it has got much better in recent versions. See the bugs closed here[1], for example. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;include=subject%3Amultiarch;dist=unstable;package=aptitude > > 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: http://lists.debian.org/20130409112909.gg2...@stoneboat.aleph1.co.uk > signature.asc Description: Digital signature
Re: Interactive package management via aptitude
Le mardi 9 avril 2013 13:29:09, Wookey a écrit : > > I too am a huge aptitude fan. The curses UI is brilliant for working > out what's up when things are a bit broken. However it doesn't deal > with multiarch well so I've been stuck with apt-get trying to work out > fro the tealeaves what's wrong. Is anyone actually working on making > the aptitude multiarch-friendly, or planning to? Or has at least > tthought about how hard a problem it is? I had the problem for a few month when I enabled multiarch but then things went fine again after the upload of aptitude 0.6.8.1-1 and its set of multiarch-related bug fix (Debian #672340, LP #831768 and LP #968412). > > Wookey Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: Interactive package management via aptitude
+++ Chow Loong Jin [2013-04-09 09:32 +0800]: > On 09/04/2013 06:43, Adam Borowski wrote: > > On Tue, Apr 09, 2013 at 04:19:19AM +0800, Chow Loong Jin wrote: > >> Actually, in the event of aptitude not being able to resolve the > >> dependencies > >> satisfactorily the first round (from aptitude install foo), aptitude > >> allows you > >> to interactively pick other solutions, or tell it what to do: > > > > Have you been able to get that effect from aptitude? It seems that > > whenever it sees some trouble (sometimes even when plain apt-get would > > succeed), it proposes to remove the world, install a few unrelated > > packages, and not do whatever you requested it to. After declining a > > varying number of such "solutions", it gives up even if it would take a > > single action to resolve the problem. > > Yeah, I have actually. It's just that the recent multiarch issues (which still > haven't been fixed) tend to lead to aptitude attempting to remove the whole > (foreign-arch) world. I too am a huge aptitude fan. The curses UI is brilliant for working out what's up when things are a bit broken. However it doesn't deal with multiarch well so I've been stuck with apt-get trying to work out fro the tealeaves what's wrong. Is anyone actually working on making the aptitude multiarch-friendly, or planning to? Or has at least tthought about how hard a problem it is? 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: http://lists.debian.org/20130409112909.gg2...@stoneboat.aleph1.co.uk
Re: upgraded systems won't boot from UUID volumes
On Mon, 2013-04-08 at 15:46 +0200, Daniel Pocock wrote: > On 08/04/13 13:53, Wouter Verhelst wrote: > > On 08-04-13 08:53, Daniel Pocock wrote: > >> I'm not suggesting that squeeze systems were installed that way by > >> default, although people who have migrated an FS from a raw partition > >> to an LV may have this in fstab. > > And that fact alone makes it a non-RC bug -- if it's even a bug at all. > > > > Changing the way the root filesystem is mounted without performing a > > reinstallation is something that's fairly advanced. I'm not saying we > > shouldn't support people who wish to do something like that, but if they > > do it, they should make sure that whatever configuration they're using > > afterwards is still a valid configuration. > > > > Having a root filesystem on a logical volume, specified by UUID, is not > > strictly a valid configuration. It may work if you're not using > > snapshots, but it might have unforeseen consequences. So Don't Do That > > Then(TM). > > > > If Debian exhibits "wrong" behaviour upon encountering a "strange" > > configuration that, while valid, is not possible to generate using any > > of Debian's tools, then that is probably a bug; but I fail to see why it > > should be release-critical. > > > The coverage of UUID on the Debian wiki makes it seem like it is a good > idea to use it and makes no warning about the LVM snapshot issue: > > http://wiki.debian.org/fstab#UUIDs > > http://wiki.debian.org/Part-UUID > > so maybe it would be good if somebody who knows this issue in more depth > than myself was to update that. [...] Done. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Re: Interactive package management via aptitude
On 2013-04-09 11:05, Kevin Chadwick wrote: > Aptitude installs all recommended packages by default which was rather > annoying until I found that in the options menu as I ran out of space a > couple of times. as does apt-get. -- brother http://sis.bthstudent.se -- 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/5163db33.40...@bsnet.se
Re: Interactive package management via aptitude
> For instance, one of the (ugly) boxes I help admin recently > had 1000 pacakges yet to update and > 60 security packages not done, and not > enough space on the box to do them. Aptitude installs all recommended packages by default which was rather annoying until I found that in the options menu as I ran out of space a couple of times. p.s. Have the devs considered using an _apt user for doing the downloads. Should only take a couple of minutes to add. You may want an advisory to warn users to check their firewall rules however. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/606292.93451...@smtp145.mail.ird.yahoo.com
Re: Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
> > And how would I use it on Debian when there is no Internet Explorer 7 > > available for non-Windows platforms? Wine? > > The purpose is to provide a web thingy, hosted on a Debian platform, > that even clients behind a legacy browser from non-free distribution can > see as they should if they were using a standards-compliant one. > > Regards > > David It's fair enough having it but thought I may as well add to this thread that I go to great length to accomodate all browsers and supporting more video players than youtube, however I have recently dropped supporting IE7 because so few (a fraction of Opera's users even) use IE7. Thankfully too because IE9 never mind 7 is so far behind the other browsers and I expect IE10 to be too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- 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/393361.64573...@smtp143.mail.ir2.yahoo.com
Re: upgraded systems won't boot from UUID volumes
On Sun, 2013-04-07 at 17:15 +0100, Ben Hutchings wrote: > > So it seems that this is only going to be an issue if users take the > unusual step of changing /etc/fstab to refer to LVs by UUID. But > maybe there are management tools that do that as a matter of course? I vaguely recall the occasion which caused me to file this bug report but I can't recall any of the specifics about how I got into this state. (Which points to something of a shortcoming in my bug report, sorry). I do notice that I sent the report from a work machine so it might be something to do with Xen, but it is equally likely to be something on one of our server machines or I just happened to send it from work in my lunch hour. I can't think of a reason why I would have deliberately switched from the LV name to a UUID in fstab, but that's not to say I didn't. It's also possible that this was just a transient issue in the installer or grub or some other component which is gone now. Sorry for not being much help here. Ian. signature.asc Description: This is a digitally signed message part
