Bug#668248: ITP:
Package: wnpp Owner: Anibal Monsalve Salazar Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: idle3-tools Version : 0.9.1 Upstream Author : Christophe Bothamy * URL : http://idle3-tools.sourceforge.net/ * License : GPL-3.0+ Programming Lang: C Description : change the idle3 timer of recent Western Digital Hard Disk Drives Idle3-tools provides a linux/unix utility that can disable, get and set the value of the infamous idle3 timer found on recent Western Digital Hard Disk Drives. . It can be used as an alternative to the official wdidle3.exe proprietary utility, without the need to reboot in a DOS environment. . A power off/on cycle of the drive will still be mandatory for new settings to be taken into account. . Modern Western Digital "Green" Drives include the Intellipark feature that stops the disk when not in use. . Unfortunately, the default timer setting is not perfect on linux/unix systems, including many NAS, and leads to a dramatic increase of the Load Cycle Count value (SMART attribute #193). . If you have a Western Digital EADS or EARS drive, please check your SMART information before it's too late by running the following command: . sudo smartctl -A /dev/sda | grep "^193" . If the Load cycle count exceeds 1000, you're probably affected by the idle3 timer problem. -- 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/20120410071954.ga5...@debian.org
Re: Social Networking Servers
On Tue, Apr 10, 2012 at 01:35:43PM +1000, Russell Coker wrote:
> Is there any progress being made on packaging these systems? Are
> there other social networking systems released under free licenses
> that we can package?
status.net (#491723) has seen some progress recently, but it's not in
Debian yet. I'm sure it could get there more quickly with the help of
interested and motivated people :-)
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Social Networking Servers
On 12-04-10 at 01:35pm, Russell Coker wrote: > http://www.antipope.org/charlie/blog-static/2012/03/not-an-april-fool-1.html > > The perils of commercial social networking are becoming more widely > known, as demonstrated by the above post by Charles Stross and the > article he cites. [...] > We also have a RFP for diaspora-x2, Jonas reported working on this and > having a private repository just over a year ago with no updates > since. > > > Is there any progress being made on packaging these systems? Are > there other social networking systems released under free licenses > that we can package? I am working on packaging Buddycloud, for which diaspora-x2 was a web-based client which has since been replaced with buddycloud-client - yet to be packaged. I'll look into updating the ITPs to reflect that. Thanks for bringing it to my attention. Others already responded more generally about possible Free federation social networking tools. Feel free to ask more if you feel your curiosity for this area have not yet been fulfilled :-) - 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: Digital signature
Re: The future of non-dependency-based boot
On 04/10/2012 07:03 AM, Marco d'Itri wrote: > On Apr 09, Roger Leigh wrote: > >> majority, it's going to be increasingly untested. Do we want to >> continue to maintain something that will be increasingly >> unsupportable, or complete the migration cleanly before that point? >> > Kill it. With fire. > I wholeheartedly agree. I also agree that wheezy would be the correct moment to do it, and that we shouldn't wait until wheezy+1. >> WRT actually doing this, the main issues I can see are >> > I say just abort the upgrade and let root deal with the issues found, > it's better than risking clobbering some local change. > Considering that most (if not all) scripts would be user custom-scripts, I'd say that the best way would be to, just move them away on a special folder, and execute them one by one, without any particular order, and print a huge warning at boot time, saying: HEY, we've found crap, please fix! It's there ---> $whatever-obsolete-script-path Of course, that's not ideal, but I believe that'd be our best hope to not destroy *too much* old setups during upgrades. My bet is that most user-made scripts would not require any dependencies anyway. Also, doing the last upgrades of some old boxes, I've myself found that I had some rotten bind 8 init scripts, because bind 8 was removed, but not purged. That goes on the way to the user (and that annoyed me quite a bit). I believe that for packages that have been removed but not purged, it's very very likely that the remaining init.d script isn't wanted by the user. I'd be for deleting those with a small warning (or even better, a debconf message with something like: do you want to delete these antediluvian scripts that are still in your box? yes/no with yes as default). Thoughts? Am I doing too many assumptions here, and thinking too much that everyone is facing the same situation I did? 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: http://lists.debian.org/4f84032c.1040...@debian.org
Re: The future of non-dependency-based boot
On 10/04/12 10:53, Thomas Goirand wrote: > I wholeheartedly agree. > I also agree that wheezy would be the correct moment to do it, and > that we shouldn't wait until wheezy+1. I was hesitant to suggest that investing energy into improving the current init system, if it is likely to be wholesale replaced, might not be worthwhile (when that same energy could be put into hastening the inevitable). However the release time frame issue is key here. sysvinit is not going away for wheezy; but this improvement might be possible. -- Jon Dowland signature.asc Description: OpenPGP digital signature
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 10:53 AM, Thomas Goirand wrote: > Considering that most (if not all) scripts would be user custom-scripts, > I'd say that the best way would be to, just move them away on a special > folder, and execute them one by one, without any particular order, and > print a huge warning at boot time With similar intention, I wondered about the possibility of running scripts without the LSB headers after everything else. (= implied dependency on those with LSB headers) Moving the broken scripts to another folder would be easy to implement, but doesn't integrate well with the packaging system -- some of these broken scripts may be from sysadmins' local packages, as well as from ancient packages that are still installed but no longer in Debian. (Detecting that and doing diversions wouldn't work either, as if a fixed version of a local package is installed, we don't want the fixed script to be diverted away.) However it's implemented, running non-LSB scripts after everything else clearly won't work in every case, but would solve the issue of obsolete-but-unpurged scripts harmlessly, and I expect would work for the majority of local scripts from sysadmins. The local scripts which will fail could already have been broken in the old scheme by package maintainers' changes to packaged scripts that they expected to run before -- there were no guarantees against the static ordering of packaged scripts changing. -- Moray -- 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/cahwf6zpcy6c0lgy6mnbxxcip8i1jramn+nx8m-q+oz+tdpj...@mail.gmail.com
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 11:55 AM, Jon Dowland wrote: > I was hesitant to suggest that investing energy into improving the > current init system, if it is likely to be wholesale replaced, might > not be worthwhile (when that same energy could be put into hastening > the inevitable). Yes, it's a pity to invest more energy into additional work for a system that people hope to get rid of, but that argument also applies to time spent on the the sysadmin side. If we just think it's not worth fixing this cleanly, we perhaps shouldn't force sysadmins to tidy up their local scripts for it now, but just leave things until they need to modify their local setups more fundamentally for a replacement system. -- Moray -- 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/cahwf6zpjrufb6u7waffjxursiu_03nz15r66cqdpq8fcmvi...@mail.gmail.com
Re: Debian Project Leader Elections 2012: Second call for votes
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- da569edd-e41f-4ecd-b0d5-ce2848a777f9 [ 1 ] Choice 1: Wouter Verhelst [ 3 ] Choice 2: Gergely Nagy [ 1 ] Choice 3: Stefano Zacchiroli [ 2 ] Choice 4: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Luca BRUNO (kaeso) : .''`. Email: lucab debian.org : : :' : GPG Key ID: 0x3BFB9FB3: `. `'` HAM-radio callsign: IZ1WGT:`- Networking sorcerer <%> Debian Developer signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2012: Second call for votes
Ahem, just forgot to properly set the recipient, sorry for the noise... Cheers, Luca signature.asc Description: PGP signature
Re: The future of non-dependency-based boot
[Moray Allan] > With similar intention, I wondered about the possibility of running > scripts without the LSB headers after everything else. (= implied > dependency on those with LSB headers) The intention of the current implementation is to assume such scripts depend on $syslog and $remote_fs, and at one point in time I believe this worked just fine. But I have seen bug reports indicating that this no longer is true. As Debian should support init.d scripts as long as the Linux Software Base require it, I believe it is worth spending some time making sure init.d scripts work properly in Debian. Of the around 1000 packages with init.d scripts in Debian, I suspect at most 100 of them would need to provide upstart/systemd configuration to make the boot robust and correct, and the rest of the packages can keep using their existing init.d scripts. -- Happy hacking Petter Reinholdtsen -- 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/2fl62d7pya0@login2.uio.no
Re: Debian Project Leader Elections 2012: Call for votes
Le Sun, 1 Apr 2012 01:36:39 +0200,
Kurt Roeckx a écrit :
> Hi,
>
> This is the first call for votes for the Debian Project Leader
> Elections 2012.
>
> Voting period starts 00:00:00 UTC on Sunday, April 1st, 2012
> Votes must be received by 23:59:59 UTC on Saturday, April 14th, 2012
>
> This vote is being conducted as required by the Debian Constitution.
> You may see the constitution at http://www.debian.org/devel/constitution.
> For voting questions or problems contact secret...@debian.org.
>
> The details of the candidate platform can be found at:
> http://www.debian.org/vote/2012/platforms/
>
> Also, note that you can get a fresh ballot any time before the end of
> the vote by sending a signed mail to
>bal...@vote.debian.org
> with the subject "leader2012".
>
>
> HOW TO VOTE
>
> First, read the full text of the platform.
>
> To cast a vote, it is necessary to send this ballot filled out to a
> dedicated e-mail address, in a signed message, as described below.
> The dedicated email address this ballot should be sent to is:
>
> leader2...@vote.debian.org
>
> The form you need to fill out is contained at the bottom of this
> message, marked with two lines containing the characters
> '-=-=-=-=-=-'. Do not erase anything between those lines, and do not
> change the choice names.
>
> There are 4 choices in the form, which you may rank with numbers between
> 1 and 4. In the brackets next to your preferred choice, place a 1.
> Place a 2 in the brackets next to your next choice. Continue until you
> reach your last choice. Do not enter a number smaller than 1 or larger
> than 4.
>
> You may skip numbers, leave some choices unranked, and rank options
> equally. Unranked choices are considered equally the least desired
> choices, and ranked below all ranked choices.
>
> To vote "no, no matter what", rank "None Of The Above" as more desirable
> than the unacceptable choices, or you may rank the "None Of The Above"
> choice and leave choices you consider unacceptable blank. (Note: if the
> "None Of The Above" choice is unranked, then it is equal to all other
> unranked choices, if any -- no special consideration is given to the
> "None Of The Above" choice by the voting software).
>
> Finally, mail the filled out ballot to: leader2...@vote.debian.org.
>
> Don't worry about spacing of the columns or any quote characters (">") that
> your reply inserts.
>
> NOTE: The vote must be GPG signed (or PGP signed) with your key that is
> in the Debian keyring. You may, if you wish, choose to send a signed,
> encrypted ballot: use the vote key appended below for encryption.
>
> The voting software (Devotee) accepts mail that either contains only an
> unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
> (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
>
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> da569edd-e41f-4ecd-b0d5-ce2848a777f9
> [ 1 ] Choice 1: Wouter Verhelst
> [ 2 ] Choice 2: Gergely Nagy
> [ 1 ] Choice 3: Stefano Zacchiroli
> [ ] Choice 4: None Of The Above
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>
> --
> ponses to a valid vote shall be signed by the vote key created
> for this vote. The public key for the vote, signed by the Project
> secretary, is appended below.
>
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> mQINBE93XhgBEAChIKhRwi7drrN36XqVesKmqW4UoKGeacS/6HBbZPHfm7Hw7gCm
> niomrpWcWOgrVLw+z+UTB9YGUSoiKF5yVZTcpQg+snaFAcWFgg4MOY1NrAGTdA95
> eNt6ZKwE9AajZVimmOEeG9bnYF3ZJuCvPAJFsm28mA42Fbzo6K+f/J51zJCKapA/
> npjI4cAd2Gb6R9pbUS7OooBqYXlG5xe3p3TepyWLBKUMwrR0+q0yacs2ubVps0IS
> XgWySgZ/T7LB78NmqMGYN05bgOPL/y2n5Dq9h24TEKxT3i+0jxFKHnnEvEvbKZ4E
> ixxGs8U/D82NWTQLbXGjFpCZmIZj1v724SWRiCunqepGMS7SpIKSI8XFp37YJhU5
> wWfMm6Pho6pXf3MdTV7x9bJPKgRr7UoKVRUl3AxHM5M+JDTbCva6l23ga7plxY+E
> vx9UMwj9TbJgprMAoLP59q2djkUOK6FM3x4Elj8SBsCHHFpg3rNuqUPxERszzIex
> 1/NxUQA8n/RuVuZ+sCL4PThR4g387SyRx+9cj7MHP+GAOrMpibY4qK92lXtetA09
> YxbsIhBAESLRhbmMEQL6WzpxMmhynU2uk34dATBfocH425MDvWd5Qsqrsc/AIBla
> ziyHwl1KqmjBl25CzF+hM4gKtsaxg8paphKwiTP6a1D0FDqIaF1HJKCoiQARAQAB
> tCpEUEwgdm90ZSAyMDEyIDxsZWFkZXIyMDEyQHZvdGUuZGViaWFuLm9yZz6JAj4E
> EwECACgFAk93XhgCGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
> EJ0M4QzEI7mhVSAP/0p3k20icRBe4a9qpK6QrjzXpcOfi8fMzJukmzj3xflbOMw9
> XMx6GCMQ9wBoRNxb07mlBCD7qaol5bMW3LyEB7NRxSK0Qil2615/N6cUa2Je1lgr
> xxX1HmE3PX0of2TDVaKatk0OxsA9zmWQ5n5+YBxuVS3dL2Ej7eNR28rJ4lkRPTiK
> 3C3AD1EQ15GD6Gg3jR1st0PsJif5JA3jkIV1HZo72HePgPsLGVtVJZ9EAlHku+cY
> 3doTpGVcKP2f6WfmD0ONalzaHTKvqAPb5N52gX4QTPC1HmDj/p36c7rbt8YRDbg7
> 5wD8HQxCn/vRQRQmQRvaZuBor/KVuTcqoAKesqeeDHZft13s1sGdIgNss26erzPy
> jSTdPw48g44ND3BJzwR92G4IWgrnZw/h4O8S17ZmUjCI8nqV4twS6IiSa8POddtf
> zjjSpl5YJRimaWtVt7ogABRDfgKZpCfPUn3vH1O05R7yuA6RWegx7chRmhSRSE8F
> C4slcmd3hQqzLpELVo/EnQMfao+0qpnRfirGmUwy4hZQGLWOfVuYDoE4v7C/zDQH
> /
Re: The future of non-dependency-based boot
On Mon, Apr 09, 2012 at 10:26:38PM +0100, Roger Leigh wrote: > Hi, > > When dependency-based booting was introduced, it was initially > entirely optional. We later made it the default, and encouraged > users to switch to dependency-based boot on upgrade. So today, > pretty much everyone will be using dependency-based boot with > there being a minority continuing to use the static boot ordering > of yore. Probably mostly users who upgraded from etch. The upgrade tool still needs some work, most of messages it produces are less than helpful. For example, it will scream about removed but not purged scripts that do have LSB headers (ie, any from lenny or squeeze), and then you have gems like this: │ Unable to migrate to dependency-based boot system │ │ Tests have determined that problems in the boot system exist which │ prevent migration to dependency-based boot sequencing: │ │ package initscripts left obsolete init.d script behind, package │ initscripts left obsolete init.d script behind, package initscripts │ left obsolete init.d script behind │ Am I supposed to fetch a copy of initscripts and manually compare scripts it ships with those on 'dpkg -L initscripts'? Or is there some other obscure way? "grep -L 'BEGIN INIT INFO' `dpkg -L initscripts`" doesn't show anything in /etc/init.d, at least. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20120410151044.ga20...@angband.pl
Re: The future of non-dependency-based boot
[Adam Borowski]
> Am I supposed to fetch a copy of initscripts and manually compare
> scripts it ships with those on 'dpkg -L initscripts'? Or is there
> some other obscure way?
Try this one instead:
dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
--
Happy hacking
Petter Reinholdtsen
--
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/2flzkajobvv@login2.uio.no
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 05:16:36PM +0200, Petter Reinholdtsen wrote:
> [Adam Borowski]
> > Am I supposed to fetch a copy of initscripts and manually compare
> > scripts it ships with those on 'dpkg -L initscripts'? Or is there
> > some other obscure way?
>
> Try this one instead:
>
> dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
Yeah, this one helps, thanks.
Could sysv-rc show this output upon a failure to migrate? Knowing you need
to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and
/etc/init.d/stop-bootlogd would provide the user with straightforward info
of what needs to be done.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
--
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/20120410153904.gc20...@angband.pl
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 02:27:35PM +0200, Petter Reinholdtsen wrote: > As Debian should support init.d scripts as long as the Linux Software > Base require it, I believe it is worth spending some time making sure > init.d scripts work properly in Debian. The LSB requires support for LSB init scripts; LSB init scripts have LSB headers. No need to support non-dependency-based boot on the LSB's account. :) -- 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 -- 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/20120410174437.gd10...@virgil.dodds.net
Bug#668293: ITP: tvnamer -- utility to rename TV-show episodes files
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: tvnamer Version : 2.2 Upstream Author : Ben Dickson * URL : https://github.com/dbr/tvnamer * License : Unlicense Programming Lang: Python Description : utility to rename TV-show episodes files Automatically names downloaded/recorded TV-episodes, by parsing filenames and retrieving show-names from www.thetvdb.com -- 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/20120410171838.27080.4568.report...@zion.matrix.int
Re: The future of non-dependency-based boot
Who said LSB requires insserv ? verify this. Um ... LSB requires everything I write too ! :) Riight???! But innserv makes a good effort to be compatible - so that end should be ok. The LSB requires support for LSB init scripts; LSB init scripts have LSB -- 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/4f8474db.8040...@cox.net
Re: The future of non-dependency-based boot
On Tuesday, April 10, 2012 05:53:48 PM Thomas Goirand wrote: ... > >> WRT actually doing this, the main issues I can see are > > > > I say just abort the upgrade and let root deal with the issues found, > > it's better than risking clobbering some local change. > > Considering that most (if not all) scripts would be user custom-scripts, > I'd say that the best way would be to, just move them away on a special > folder, and execute them one by one, without any particular order, and > print a huge warning at boot time, saying: The main place I've seen this problem is not with custom scripts, but rather old init scripts from Debian packages due to config files left behind from packages that were 'removed' rather than 'purged'. [You apparently ran into this too with and old config file from Bind 8.] > HEY, we've found crap, please fix! It's there ---> > $whatever-obsolete-script-path > > Of course, that's not ideal, but I believe that'd be our best hope to not > destroy *too much* old setups during upgrades. My bet is that most > user-made scripts would not require any dependencies anyway. > > Also, doing the last upgrades of some old boxes, I've myself found that > I had some rotten bind 8 init scripts, because bind 8 was removed, but > not purged. That goes on the way to the user (and that annoyed me > quite a bit). I believe that for packages that have been removed but > not purged, it's very very likely that the remaining init.d script isn't > wanted by the user. I'd be for deleting those with a small warning > (or even better, a debconf message with something like: do you want > to delete these antediluvian scripts that are still in your box? yes/no > with yes as default). > > Thoughts? What I don't like about the idea of deleting the init script by default: - if the init script left behind was part of a Debian package, deleting the init script means removing part of the configuration from the Debian pacakge, yet not purging the package it belongs to. This feels like something that would volate Debian policy regarding one package not altering the configuration of another. Likewise, moving the init script means that purging the old package that had configuration left behind will no longer delete the init script file, which will thus be left behind as orphaned cruft. - the upgrade may be unattended or automatic, in which case presumably the default will be chosen and the user/admin will never know that the init script was removed, so the default of 'yes' is dangerous. - the current administrator at the keyboard may not be the one that wrote or installed the custom-installed init script, so the upgrade may need to be completed before the question of whether the init script can be deleted has a satisfactory answer, but an answer of 'no' will presumably cause an issue for dependency-based bootup. Any thoughts on the above? -- -- Chris Chris Knadle chris.kna...@coredump.us -- 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/1480217.g0xx92AebP@trelane
Bug#668299: ITP: octave-openmpi-ext -- Octave toolbox for parallel computing using MPI
Package: wnpp Severity: wishlist Owner: "Sébastien Villemot" * Package name: octave-openmpi-ext Version : 1.0.2 Upstream Author : Riccardo Corradini * URL : http://octave.sourceforge.net/openmpi_ext/ * License : GPL-2+ Programming Lang: C++, GNU Octave Description : Octave toolbox for parallel computing using MPI This package brings parallel computing capabilities to Octave by providing a convenient interface to OpenMPI primitives. This is achieved using simple MPI Derived Datatypes. . This Octave add-on package is part of the Octave-Forge project. -- 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/20120410184447.16781.53914.report...@brouzouf.villemot.name
Re: The future of non-dependency-based boot
Marco d'Itri wrote:
> On Apr 09, Roger Leigh wrote:
> > majority, it's going to be increasingly untested. Do we want to
> > continue to maintain something that will be increasingly
> > unsupportable, or complete the migration cleanly before that point?
> Kill it. With fire.
Yes please.
> > WRT actually doing this, the main issues I can see are
> I say just abort the upgrade and let root deal with the issues found,
> it's better than risking clobbering some local change.
To the extent root caused the problem in the first place with local
scripts. The vast majority of such cases seem like issues caused by
Debian packages, as mentioned below.
> > - blocking by obsolete-but-unpurged init scripts without LSB header.
> > We could mv them out of the way to .dpkg-old and continue, or
> > abort and require manual intervention.
> Or just say in the release notes that it's a good idea to run something
> like this before upgrading:
>
> dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
Personally, I run into more problems by upgrading packages that drop or
rename init scripts (and other conffiles). dpkg keeps the old files
around even if unmodified, and leaves them associated with the package
despite no longer appearing in that package. (This also makes them
difficult to track down and eliminate.) I'd like to question that
particular decision of dpkg; I think it causes more pain than help.
- Josh Triplett
--
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/20120410184941.GA10156@leaf
Re: The future of non-dependency-based boot
]] Adam Borowski > Could sysv-rc show this output upon a failure to migrate? Knowing you need > to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and > /etc/init.d/stop-bootlogd would provide the user with straightforward info > of what needs to be done. I think this should just be fixed in initscript instead. There's no good reason for it to not clean up after itself. -- 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/87vcl7jozv@qurzaw.varnish-software.com
Re: The future of non-dependency-based boot
On Tue, Apr 10, 2012 at 10:44:36PM +0200, Tollef Fog Heen wrote: > ]] Adam Borowski > > > Could sysv-rc show this output upon a failure to migrate? Knowing you need > > to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and > > /etc/init.d/stop-bootlogd would provide the user with straightforward info > > of what needs to be done. > > I think this should just be fixed in initscript instead. There's no > good reason for it to not clean up after itself. Preferably, both. initscripts because this should work out of the box unless the admin has actually done a modification here. sysv-rc because there may be many more cases like this. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20120410205547.ga30...@angband.pl
Re: The future of non-dependency-based boot
On 10.04.2012 22:44, Tollef Fog Heen wrote: > ]] Adam Borowski > >> Could sysv-rc show this output upon a failure to migrate? Knowing you need >> to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and >> /etc/init.d/stop-bootlogd would provide the user with straightforward info >> of what needs to be done. > > I think this should just be fixed in initscript instead. There's no > good reason for it to not clean up after itself. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: The future of non-dependency-based boot
On Wed, Apr 11, 2012 at 12:31:11AM +0200, Michael Biebl wrote: > On 10.04.2012 22:44, Tollef Fog Heen wrote: > > ]] Adam Borowski > > > >> Could sysv-rc show this output upon a failure to migrate? Knowing you need > >> to delete /etc/init.d/bootlogd, /etc/init.d/stop-bootlogd-single and > >> /etc/init.d/stop-bootlogd would provide the user with straightforward info > >> of what needs to be done. > > > > I think this should just be fixed in initscript instead. There's no > > good reason for it to not clean up after itself. > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653050 Yep. Started looking at this over the weekend, it's a PITA though. Hopefully should be fixed in the next upload if I have time to thoroughly test it this week (but I need to write the helper function first given that this has apparently not been needed until now). Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120410223745.gz30...@codelibre.net
Re: The future of non-dependency-based boot
On 10 April 2012 16:06, Yves-Alexis Perez wrote:
>> dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
>>
> That's a pretty dangerous line. People (sometimes) don't purge packages
> for a reason, you might lose data here.
Under some circumstances it can delete configuration files that are in
use by active packages.
e.g. package b replaces package a, however uses the same set of
configuration files - purge package a and it will delete the
configuration
files now in use by package b.
--
Brian May
--
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/CAA0ZO6ByZp7tr3weApRM5OYaZCht81nrcZ=4ntcn7kdkfty...@mail.gmail.com
Re: The future of non-dependency-based boot
On Wed, 11 Apr 2012, Brian May wrote:
> On 10 April 2012 16:06, Yves-Alexis Perez wrote:
> >> dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
> >>
> > That's a pretty dangerous line. People (sometimes) don't purge packages
> > for a reason, you might lose data here.
>
> Under some circumstances it can delete configuration files that are in
> use by active packages.
>
> e.g. package b replaces package a, however uses the same set of
> configuration files - purge package a and it will delete the
> configuration
> files now in use by package b.
Err, no. At least dpkg shouldn't do that. If you can reproduce it, please
file a bug.
(Make sure it's not some postrm that is badly behaving)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
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/20120411061929.gf8...@rivendell.home.ouaza.com
