Unpleasant upgrades from Squeeze to Wheezy
Hi The upgrade from Squeeze to Wheezy is collecting some unpleasant problems. They tie large portions of the package space together and make independant upgrades impossible. Packages using dh_python2 - This packages depend on python (>> squeeze). One example is: | python2.7, python (>= 2.6.6-7~) The example package only really needs the versioned package. But because it uses dh_python2, it pulls in the complete upgrade from 2.6 to 2.7 at the same time. I thought about just ripping the whole python magic out completely, but this can't be the solution. Perl Perl got a new upstream version. Packages using libperl* where rebuilt. However libperl* is no real library package, because they are no coinstallable. This ties all the perl using packages together. ABI change in libsasl2-2 libsasl2-2 seems to have an unannounced ABI change. It collected Breaks relations to two packages in the meantime and bumped the shlibs version. This now ties libsasl2-2 tight to several other packages. Fazit - I had a lot different stuff written here, but it is just sad, so I deleted it. Bastian -- Spock: We suffered 23 casualties in that attack, Captain. -- 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/20120326071024.ga7...@wavehammer.waldi.eu.org
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
On Mon, 26 Mar 2012 09:55:35 +0300 "Eugene V. Lyubimkin" wrote: > On 2012-03-25 16:00, Joey Hess wrote: > > But still nothing. ITP is more often than not a pointless bureaucracy. > > No, it's not nothing, and it's not a pointless bureaucracy. Filing an > ITP shows your intent to a hundreds of developers, which is: > > a) useful for the ITP owner since it advertises the package for >the prospective users; That's true mostly after the ITP is closed but it's also true if the package, once uploaded, has a sensible package description. Both get indexed by every search engine worth using. The ITP itself has no real impact on this. The ITP shouldn't need to be open that long. > b) useful for the Debian project since experienced people may >immediately point that there are/there were some problems which >prevented the package to be added before or made the package >disappear from Debian archives in the past; > c) useful for the Debian project since experienced people may ask >the ITP owner why to package the thing at all if they know/suspect >there are superior things in the archive already; > d) useful for the Debian project because people sometimes choose >too confusing/short names for packages, and answering to an ITP >is usually the only chance for the public to suggest some better >name before the package entered the archive, after which the renaming >is more time-consuming and bureaucratic; All of which can be good for those new to packaging but those who would do the commenting are generally reasonably proficient at anticipating such issues and choosing sensible names etc. from the beginning. > > The turnaround time for packaging the average package is less than the > > turnaround time in getting back a ITP bug number. > > I very doubt that. I even have a doubt that there is a single proper > Debian package for which the time between 'Oh, I will package this' and > uploading a package to archives takes less than 15 minutes (which a BTS > turnaround time for me) as there are too many things to write/check > which require the human attention. But maybe that's me being too slow. No, it's quite often true. I can see exactly what Joey is getting at here because I suspect that my development flow may be similar at times. I get an idea for a tool or utility - I do a test in shell or something quick, decide which language it's going to be in when done properly and before I've even written a line of the final code, I'll create a debian/ directory, populate debian/control and get the whole thing rolling because often the easiest way to test the code is as a local package. If it doesn't work, no harm done. If it does work, the packaging is already in place, so the ITP is just a delay. I have still used ITPs for recent packages but the packages were all uploaded within minutes of filing the ITP and closed within hours. As Joey describes, I was waiting for the bug number in order to make the changelog entry, create a tag in the VCS and upload. It does make the whole ITP process seem a waste of time and I might not bother in future as there is not going to be any real opportunity for anyone to comment on the ITP in that time. I do the same with code written at work - the first thing I create is the debian/ directory, even before I've written main.cpp. A Debian package is my natural development platform. I can't remember when I last did any development - including upstream development - which did not start and be completely contained within a Debian package. I often release code without a debian/ directory as an upstream developer but that code has been developed and tested with the same debian/ directory as will be found in the Debian package uploaded a few moments after the upstream release. Therefore packaging takes no time at all, it is always fully complete before the code itself is even worth evaluating as useful to Debian. The packaging is part of my test harness. > > The appropriate thing to do when confronted with a months-old ITP > > for a package with the same content or name as your package is almost > > certianly to ignore old "intent" and get on with it. > > Absolutely disagree. Hijacking the ITP and/or package name without > saying a single word about that to the ITP bug thread is just plain > rude. I think ITP's should have a strict and absolute time limit - there is already some work to monitor aged ITP's/ITA's and rename to RFP: or O: but actually packaging something does not take long and if there are reasons to delay a particular package, it can be mentioned in a comment to the ITP or elsewhere. If an ITP remains open without comment for more than a month, the chances that there will ever be an upload to close it are close to zero. If the upload is simply waiting for a sponsor then *say so* in the ITP and put a link to mentors.debian.net. ITP bugs must not be allowed to block actual work. It's equivalent to domain-squatting and just as distastef
Re: mosh ITP not done, just package name taken over
On Mon, 26 Mar 2012 01:20:10 +0200 Goswin von Brederlow wrote: > There might be a good reason why the ITP is staled, like your own > example with copyright issues. What would you say if someone else just > ignored your ITP and uploaded the package without clearing up the > copyright issues or even uploading a different package hijacking your > package name? When you have to resolve legal issues with upstream a > delay of a month or two is nothing. > > MfG As long as there are comments in the ITP to this effect, fine. An ITP which just sits there for months on end without any comment or upload is unhelpful to everyone. If there are problems, then the ITP is one place where those problems can be shared and others may be able to help. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpGqc2oUoizr.pgp Description: PGP signature
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
[ sorry for duplicate, Neil, pressed the wrong button ] On 2012-03-26 09:17, Neil Williams wrote: > On Mon, 26 Mar 2012 09:55:35 +0300 > "Eugene V. Lyubimkin" wrote: [...] > > No, it's not nothing, and it's not a pointless bureaucracy. Filing an > > ITP shows your intent to a hundreds of developers, which is: > > > > a) useful for the ITP owner since it advertises the package for > >the prospective users; > > That's true mostly after the ITP is closed but it's also true if the > package, once uploaded, has a sensible package description. Both get > indexed by every search engine worth using. The ITP itself has no real > impact on this. [...] No, it has. At least for me. I certainly know about or even installed some software solely because I saw an ITP for them, for example, 'lightspark'. I doubt that many people use a search engine once a while to see if there is new flash player available. And my own example to that is #524605. I know it caused some discussion before that ITP was closed, and I am fairly sure very few people would find it through a search engine. > > b) useful for the Debian project since experienced people may > >immediately point that there are/there were some problems which > >prevented the package to be added before or made the package > >disappear from Debian archives in the past; > > c) useful for the Debian project since experienced people may ask > >the ITP owner why to package the thing at all if they know/suspect > >there are superior things in the archive already; > > d) useful for the Debian project because people sometimes choose > >too confusing/short names for packages, and answering to an ITP > >is usually the only chance for the public to suggest some better > >name before the package entered the archive, after which the renaming > >is more time-consuming and bureaucratic; > > All of which can be good for those new to packaging but those who would > do the commenting are generally reasonably proficient at anticipating > such issues and choosing sensible names etc. from the beginning. Generally, yes. But not always. > > > The turnaround time for packaging the average package is less than the > > > turnaround time in getting back a ITP bug number. > > > > I very doubt that. I even have a doubt that there is a single proper > > Debian package for which the time between 'Oh, I will package this' and > > uploading a package to archives takes less than 15 minutes (which a BTS > > turnaround time for me) as there are too many things to write/check > > which require the human attention. But maybe that's me being too slow. > > No, it's quite often true. can see exactly what Joey is getting at > here because I suspect that my development flow may be similar at times. > I get an idea for a tool or utility - I do a test in shell or something > quick, decide which language it's going to be in when done properly and > before I've even written a line of the final code, I'll create a > debian/ directory, populate debian/control and get the whole thing > rolling because often the easiest way to test the code is as a local > package. If it doesn't work, no harm done. If it does work, the > packaging is already in place, so the ITP is just a delay. > [...] > Therefore packaging takes no time at all, it is always fully complete > before the code itself is even worth evaluating as useful to Debian. > The packaging is part of my test harness. This is true only for the software you are upstream for, which is, I believe, the minority of Debian packages. I'm now convinced that there are proper quickly-packaged things in Debian, but I'm still not convinced the average package could be packaged so. > I think ITP's should have a strict and absolute time limit - there is > already some work to monitor aged ITP's/ITA's and rename to RFP: or O: > but actually packaging something does not take long and if there are > reasons to delay a particular package, it can be mentioned in a comment > to the ITP or elsewhere. May be useful, but not sure if a single absolute time limit would fit all the cases. > If an ITP remains open without comment for > more than a month, the chances that there will ever be an upload to > close it are close to zero. Cannot agree. People who are trying to get their packages to Debian on debian-mentors@l.d.o often wait for more than the month. Of course we can establish a new policy to comment in ITP threads more, but that's not how things are now. Ah, by the way, another example out of my head. #611400 was about 4.5 months without a comment. Would you close it on 2012-03-01? > If the upload is simply waiting for a > sponsor then *say so* in the ITP and put a link to mentors.debian.net. So ITP owners should write more mails to ITP. Sounds fine, but this suggestion to write more manual mails somehow contradicts to the point (of Joey, and, as I understand, of you) that writing a one semi-automatic e-mail (ITP) is a big burde
Bug#665805: ITP: ganv -- canvas widget for graph-based interfaces
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: ganv Version : 0~svn4107 Upstream Author : David Robillard * URL : http://drobilla.net/software/ganv/ * License : GPL Programming Lang: C++ Description : canvas widget for graph-based interfaces Ganv is an interactive Gtkmm canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). . Ganv provides classes for "Modules" (boxes with "Ports"), Circles, and Edges (lines that connect either Ports or Circles). The user can rearrange items, or Ganv can automatically arrange items using GraphViz. Edges can be made by the user one at a time with the mouse, or in groups using the mouse and keyboard. -- 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/20120326092907.10582.63394.reportbug@alessio-laptop
Bug#665811: ITP: libpadre-plugin-snippet-perl -- Padre plugin to provide TextMate-like snippets
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpadre-plugin-snippet-perl Version : 0.01 Upstream Author : Ahmad M. Zawawi * URL : http://search.cpan.org/dist/Padre-Plugin-Snippet/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Padre plugin to provide TextMate-like snippets Once you enable this Plugin under Padre (the Perl IDE), you'll get TextMate-style TAB triggered snippets for Perl, Moose, Mouse and MooseX::Declare -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.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/201203261301.33286@debian.org
Bug#665815: ITP: libpadre-plugin-parsertool-perl -- A realtime interactive parser test tool for Padre
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpadre-plugin-parsertool-perl Version : 0.01 Upstream Author : Adam Kennedy * URL : http://search.cpan.org/dist/Padre-Plugin-ParserTool/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : A realtime interactive parser test tool for Padre The ParserTool plugin adds an interactive parser testing tool for Padre. It provides a two-panel dialog where you can type file contents into a panel on one side, and see a realtime dump of the resulting parsed structure on the other side of the dialog. The dialog is configurable, so it can be used to test both common Perl parsers and parsers for custom file formats of your own. -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.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/201203261332.37408@debian.org
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Hi. On Mon, Mar 26, 2012 at 09:17:53AM +0100, Neil Williams wrote: > > b) useful for the Debian project since experienced people may > >immediately point that there are/there were some problems which > >prevented the package to be added before or made the package > >disappear from Debian archives in the past; > > c) useful for the Debian project since experienced people may ask > >the ITP owner why to package the thing at all if they know/suspect > >there are superior things in the archive already; > > d) useful for the Debian project because people sometimes choose > >too confusing/short names for packages, and answering to an ITP > >is usually the only chance for the public to suggest some better > >name before the package entered the archive, after which the renaming > >is more time-consuming and bureaucratic; > > All of which can be good for those new to packaging but those who would > do the commenting are generally reasonably proficient at anticipating > such issues and choosing sensible names etc. from the beginning. Well, much like code review, a sanity check might be useful sometimes. Just a minor suggestion to improve something could crop up. I always prefer to have my ideas checked by someone else, but then, that's my preference. > I have still used ITPs for recent packages but the packages were all > uploaded within minutes of filing the ITP and closed within hours. As > Joey describes, I was waiting for the bug number in order to make the > changelog entry, create a tag in the VCS and upload. It does make the > whole ITP process seem a waste of time and I might not bother in future > as there is not going to be any real opportunity for anyone to comment > on the ITP in that time. I am guessing that the ITP was closed in hours because of NEW processing. So, to be clear, how does waiting "minutes" for the bug number when it will be processed in "hours" make it a waste of time? > > > The appropriate thing to do when confronted with a months-old ITP > > > for a package with the same content or name as your package is almost > > > certianly to ignore old "intent" and get on with it. > > > > Absolutely disagree. Hijacking the ITP and/or package name without > > saying a single word about that to the ITP bug thread is just plain > > rude. > > I think ITP's should have a strict and absolute time limit - there is > already some work to monitor aged ITP's/ITA's and rename to RFP: or O: > but actually packaging something does not take long and if there are > reasons to delay a particular package, it can be mentioned in a comment > to the ITP or elsewhere. If an ITP remains open without comment for > more than a month, the chances that there will ever be an upload to > close it are close to zero. If the upload is simply waiting for a > sponsor then *say so* in the ITP and put a link to mentors.debian.net. > > ITP bugs must not be allowed to block actual work. It's equivalent to > domain-squatting and just as distasteful. This is taking it to an extreme. Even in the case of domain-squatting, the first attempt to fix the problem would be to contact the domain owner and make a gentle request to vacate. In this case, I frankly don't see the need to hijack an ITP without doing so. > Otherwise, if you are not going to upload within a month of filing the > ITP, then *close the ITP*. There should be no complaints if someone > else assumes that the ITP is stale if there have been no comments on it > for the last month. This may be your opinion, but I would still opine that it would be decent to ask the ITP owner as to why he or she has not got back to uploading it yet. However, my timelines differ greatly, and having the package in the archive very quick may suit your requirements better. Thanks. Kumar -- Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick -- 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/20120326122609.ga7...@bluemoon.alumni.iitm.ac.in
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
"Eugene V. Lyubimkin" writes: > I disagree almost completely. > > On 2012-03-25 16:00, Joey Hess wrote: >> But still nothing. ITP is more often than not a pointless bureaucracy. > > No, it's not nothing, and it's not a pointless bureaucracy. Filing an > ITP shows your intent to a hundreds of developers, which is: > > a) useful for the ITP owner since it advertises the package for >the prospective users; Since you are supposed to file the ITP before starting on the package that is pretty useless. It only advertises the existance of the upstream and that isn't really debians job. One should rather have an IHP (I Have Packaged) for this or a PPN (Package Passed New queue). That's when it gets interesting for users. > b) useful for the Debian project since experienced people may >immediately point that there are/there were some problems which >prevented the package to be added before or made the package >disappear from Debian archives in the past; > c) useful for the Debian project since experienced people may ask >the ITP owner why to package the thing at all if they know/suspect >there are superior things in the archive already; > d) useful for the Debian project because people sometimes choose >too confusing/short names for packages, and answering to an ITP >is usually the only chance for the public to suggest some better >name before the package entered the archive, after which the renaming >is more time-consuming and bureaucratic; > e) useful to prevent a duplicate work. Pointless if the package is uploaded the moment the BTS responds with the bug number for the ITP, which was the hypotetical. >> The turnaround time for packaging the average package is less than the >> turnaround time in getting back a ITP bug number. > > I very doubt that. I even have a doubt that there is a single proper > Debian package for which the time between 'Oh, I will package this' and > uploading a package to archives takes less than 15 minutes (which a BTS > turnaround time for me) as there are too many things to write/check > which require the human attention. But maybe that's me being too slow. In the simple case: 1) file ITP with the infos you put in debian/control 2) dh_make 3) write debian/control (cut&paste the description, homepage, ... from the ITP) 4) write debian/copyright 5) remove some example files 6) build, test, upload If you have a BTS turnaround time of 2h then there certainly is enough time to finish. MfG Goswin -- 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/87bonjxuy8.fsf@frosties.localnet
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
"Eugene V. Lyubimkin" writes: > [ sorry for duplicate, Neil, pressed the wrong button ] > > On 2012-03-26 09:17, Neil Williams wrote: >> On Mon, 26 Mar 2012 09:55:35 +0300 >> "Eugene V. Lyubimkin" wrote: > [...] >> > No, it's not nothing, and it's not a pointless bureaucracy. Filing an >> > ITP shows your intent to a hundreds of developers, which is: >> > >> > a) useful for the ITP owner since it advertises the package for >> >the prospective users; >> >> That's true mostly after the ITP is closed but it's also true if the >> package, once uploaded, has a sensible package description. Both get >> indexed by every search engine worth using. The ITP itself has no real >> impact on this. [...] > > No, it has. At least for me. I certainly know about or even installed > some software solely because I saw an ITP for them, for example, > 'lightspark'. I doubt that many people use a search engine once a while > to see if there is new flash player available. I do read the Debian News which usualy has a section on new and noteworthy packages. I would find it much better if maintainers would write a small blurb for the News when the package is uploaded instead of an ITP. MfG Goswin -- 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/877gy7xuk7.fsf@frosties.localnet
Re: On init in Debian
Martin Wuertele wrote: > * Uoti Urpala [2012-03-23 19:44]: > > IMO your [Steve Langasek's] upstart advocacy and anti-systemd FUD > > crosses the line between having your own opinions and having your > > own facts. > > There was neither FUD nor advocacy in Steves mail and no hostile > attitude towards systemd. IMO calling comments like "The current [bad] state of upstart in Debian is a reflection of the upstart maintainers' respect for Debian and desire to not destabilize the distribution" advocacy is perfectly accurate. Especially when systemd in Debian works much better, without causing such "destabilization". Note that my comment about his FUD posting was not based only on the mail I was replying to. I've already commented on false claims he's made earlier: http://lists.debian.org/debian-devel/2012/02/msg00935.html http://lists.debian.org/debian-devel/2012/02/msg01177.html http://lists.debian.org/debian-devel/2012/02/msg01182.html > In contrast to your systemd advocacy as the new default init Steve > outlined the necessary changes to provide upstart as an alternative to He posted some actual information and some quite dubious claims. My posts about systemd have been more objective. > The RHEL 6 uses upstart [1] and while it is true that Fedora is using > systemd I could not find any evidence that RHEL intends to change any > time soon. I think the evidence I described in my mail is quite significant. Whether the switch actually happens "soon" is another question; but that's due to RHEL being maintained in a very conservative manner. Note that Steve wrote "no indication", and without any qualification such as "soon". Would you really honestly say there's "no indication" of RHEL switching away from upstart? -- 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/1332778117.1709.24.camel@glyph.nonexistent.invalid
Bug#665857: ITP: libv8-i18n -- Native internationalization support for v8 EcmaScript engine.
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: libv8-i18n Version : 0~svn37 Upstream Author : the v8-i18n authors * URL : http://code.google.com/p/v8-i18n * License : Apache-2 Programming Lang: C++ Description : Native internationalization extension for libv8 libv8-i18n is a v8 extension providing internationalization support, and will match ECMAScript Internationalization API standard when it becomes available. . libv8-i18n was part of libv8, and is needed by chromium-browser. . libv8 is a high performance ECMAScript engine. -- 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/20120326171629.24010.62133.reportbug@imac.chaumes
Bug#665903: ITP: calligra -- KDE SC integrated work applications suite
Package: wnpp Severity: wishlist Owner: "Raúl Sánchez Siles" * Package name: calligra Version : 2.4 Upstream Author : calligra-de...@kde.org * URL : http://www.calligra.org/ * License : GPL Programming Lang: C++ Description : KDE SC integrated work applications suite Calligra Suite is a set of applications written to help you to accomplish your work. It includes office applications such as a word processor, a spreadsheet, a presentation program, a database application, etc, and raster and vectorial graphics tools. -- 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/20120326210835.9777.41346.reportbug@localhost
Bug#665911: ITP: haskell-ekg -- remote monitoring of Haskell processes over HTTP
Package: wnpp Severity: wishlist Owner: Iustin Pop * Package name: haskell-ekg Version : 0.3.0.3 Upstream Author : Johan Tibell * URL : https://github.com/tibbe/ekg * License : BSD Programming Lang: Haskell Description : remote monitoring of Haskell processes over HTTP The ekg library lets you remotely monitor a running (Haskell) process over HTTP. It provides a simple way to integrate a monitoring server into any application. signature.asc Description: Digital signature
Re: On init in Debian
]] Stefano Zacchiroli > It is not clear to me the status of similar policy work for systemd, > although I see that systemd maintainers are participating in > #591791. Again, if you're interested in Debian switch to systemd, > please contribute to that work rather than arguing on -devel. It's not entirely clear to me that we need any policy changes at all for packages to ship systemd unit files. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zkb28szu@qurzaw.varnish-software.com
