Re: why are the watchdog drivers blacklisted?
On Tue, Feb 09, 2010 at 01:20:31AM +, Darren Salt wrote: > > The OOM killer can be disabled for precious processes by writting the > > string "-17" to “/proc//oom_adj”. > > That sounds to me like a good thing to do by default. Absolutely agreed. As soon as I find the time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote: > And while at it, change wd_keepalive and watchdog to default to pat at 1Hz > instead of 0.1Hz. That will reduce a _lot_ the changes of spurious > reboots. This looks like a workaround for some other problem to me. Patting at 0.1Hz should be sufficient if the kernel expects a change at 0.016 Hz. I don't have any report about a spurious reboot, but if you do have some I'd like to learn more about it to see where this problem stems from. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
Vincent Bernat writes: > OoO En ce début d'après-midi ensoleillé du samedi 06 février 2010, vers > 15:15, Goswin von Brederlow disait : > >> He wants to KISS. So lets make it even simpler. > >> - master: patched source >> - upstream: upstream source > > Suppose the following workflow: > - upstream version X.Y > - master branch based on X.Y > - patch Z applied on master branch > - upstream branch is updated to (X+1).0 > - upstream is merged into master branch and manual intervention is >needed because there are conflicts between changes on upstream side >and patch Z > > Now, if upstream want to get patch Z, he can : > - get patch Z for version X.Y > - get patch between upstream (X+1).0 and master (X+1).0 containing >patch Z and other stuff No, he only has the options of: 1) get debian/patches/debian-changes from version X.Y (patch Z) 2) get debian/patches/debian-changes from version (X+1).0 (updated patch Z) At least from the debian source package. What the maintainer can get from the git directly depends how you organize your git and is irelevant to the discussion of the debian source package. > While git allows to keep track of modifications, it is difficult for > upstream (or some other people) to review a precise patch. Or maybe you > rebase master branch on the upstream one (which would be great to see > watch patches are applying to upstream but will lead to difficulties > when tracking master branch)? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg source format 3.0 (git)
Jonathan Nieder writes: > Henrique de Moraes Holschuh wrote: > >> Given the size of the .git dir when you're not using something like stgit >> and have all objects properly packed, one could even consider shipping .git >> inside the package if it is small enough. >> >> Is that a proper way to do this? Or would we need a new 3.0 format variant >> to do it right (assuming we want to do that) ? > > There has been talk [1] of a format variant that uses git bundles to do > that efficiently, but nothing concrete. To me, it seems like a good idea. > > A few points [2] to keep in mind: > > - People can easily download source packages to access the original >source and Debian changes without too much technical >sophistication. Even a quilt series is just a series of patches so >it doesnât require specialized tools. So there is precedent for >making it easy to access a source package from Debian. > >Will âgitâ ever be as ubiquitous as âpatchâ? If the source package >is something you can âgit cloneâ to get a repository with >appropriate âmasterâ and âorigin/upstreamâ branches, is that good >enough? Probably. ;-) > > - The bundle needs to be clonable without use of any external object >repository. The bundle ought to have branches âmasterâ and >âupstreamâ, relevant tags, maybe a âpristine-tarâ branch, and not >much extra junk. > > - To be included in Debian main, everything in the bundle should meet >the free software guidelines (right?); practically speaking, this >means the history would very often be cauterized when the project >is first packaged for Debian. > >Maybe some of the damage from this could be mitigated by including >a suitable grafts file or refs for use by âgit replaceâ. > > - Including the whole history with each upload and forcing users and >buildds to reclone with each download would be unpleasant. (This >can be turned around: with work, a git-based format might be able >to decrease bandwidth use for sites like snapshots.debian.org.) > > - Bundles are hard to recreate. If they were to be created on the >fly some way as in the previous item, the md5sums are not stable. >Just something to think about. > > Thoughts? Especially, if anyone would like to talk implementation, > let me know. It sounds difficult to do right, but thereâs no harm in > experimenting. Two things: 1) Think about doing this for linux-2.6, XOrg or OOo and what it would mean for the source size or usability. 2) If you want a git repository then use a git repository. Castrating git, hacking the history to pices and then mangling the whole thing into a tar.gz is just stupid. Teach DAK, dpkg-source and libapt about git. The Sources.gz file would then just contain a reference and apt-get source foo would clone the repository and so on. Uploading a new source could then be sending a signed ref to the maintainers git or sending a signed bundle or even just pushing and setting a tag. > The easiest way to try this out now is to include a bundle in the > source tarball (ugh) and clone it at build time. If youâre doing > that, please let me know how it goes. But not the best way. :) > Jonathan > > [1] http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/11234 > [2] Thanks to Goswin for many of these: > http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/11234/focus=11264 MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569019: ITP: bzr-pipeline -- Bazaar plugin for managing a pipeline of changes
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: bzr-pipeline Version : 0.0.1 Upstream Author : Aaron Bentley * URL : http://bazaar-vcs.org/BzrPipeline * License : GPL Programming Lang: Python Description : Bazaar plugin for managing a pipeline of changes A Bazaar plugin helps you organize your changes into sections called "pipes" . Pipelines can help you: . * focus on each set of changes as a coherent piece, without being distracted by other sets of changes. * respect diff size limits when submitting changes * avoid reviewer fatigue when submitting changes for code review maintain a set of patches against an upstream branch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Tue, 09 Feb 2010, Michael Meskes wrote: > TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote: > > And while at it, change wd_keepalive and watchdog to default to pat at 1Hz > > instead of 0.1Hz. That will reduce a _lot_ the changes of spurious > > reboots. > > This looks like a workaround for some other problem to me. Patting at 0.1Hz > should be sufficient if the kernel expects a change at 0.016 Hz. I don't have > any report about a spurious reboot, but if you do have some I'd like to learn > more about it to see where this problem stems from. The kernel drivers don't always expect pats at 0.016Hz by default. Some drivers have different defaults, and as far as I recall, some of them default to whatever the BIOS or BMC programmed in the watchdog. A period of 1s would be a much safer default on the userland side. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 09 Feb 2010, Michael Meskes wrote: > > This looks like a workaround for some other problem to me. Patting at 0.1Hz > > should be sufficient if the kernel expects a change at 0.016 Hz. I don't > > have > > any report about a spurious reboot, but if you do have some I'd like to > > learn > > more about it to see where this problem stems from. > The kernel drivers don't always expect pats at 0.016Hz by default. Some > drivers have different defaults, and as far as I recall, some of them > default to whatever the BIOS or BMC programmed in the watchdog. This is definitely the case for embedded drivers, they'll generally inherit the configuration that the hardware has. For many devices a timeout as long as 10s may not even be possible in the hardware. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Mon, Feb 08, 2010 at 08:54:23PM +0100, Guillem Jover wrote: > The OOM killer can be disabled for precious processes by writting the > string "-17" to “/proc//oom_adj”. Added in git. Thanks for the hint. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Cena para enamorados Hotel Tambor!!!
Restaurante Hotel Tambor © informacion - Mercranet.com ( 506) 24403726 Este boletín no tiene fines de venta directa, solo se informa sobre promociones y descuentos disponibles y que usted pueda opinar sobre ellas. Si usted desea solicitar información sobre las mismas entonces debe comunicarse con su proveedor. Si usted no consiente en recibir esta clase de información por favor envíe una petición para poner fin a los avisos sobre promociones y descuentos que habrá disponibles. Si desea saber por qué existe esta comunidad, por favor visite: Mercranet.com ( http://www.Mercranet.com ) Cambiar la suscripción ( http://mercranetpymes.com/index.php?option=com_acajoom&Itemid=999&act=change&subscriber=11803&cle=c4b71992bd71327e8969323a5058372a&listid=8 ) De-suscribirse ( http://mercranetpymes.com/index.php?option=com_acajoom&Itemid=999&act=unsubscribe&subscriber=11803&cle=c4b71992bd71327e8969323a5058372a&listid=8 )
Re: why are the watchdog drivers blacklisted?
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote: > The kernel drivers don't always expect pats at 0.016Hz by default. Some That's what it was years ago. > drivers have different defaults, and as far as I recall, some of them > default to whatever the BIOS or BMC programmed in the watchdog. > > A period of 1s would be a much safer default on the userland side. Okay, will change. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569042: ITP: rinputd -- A server daemon for receiving user input events
Package: wnpp Severity: wishlist Owner: Chase Douglas * Package name : rinputd * Version : 1.0.2 * Upstream Author : Chase Douglas * URL : http://launchpad.net/rinput * License : (GPLV2 + OpenSSL Exemption) * Programming Lang : C++ * Description : A server daemon for receiving user input events Description: rinputd is a server daemon which listens for remote input clients. Clients connect over a secure SSL socket and authenticate with the server though the Cyrus SASL password database /etc/sasldb2. The client may then initialize an input device through the uinput user input event interface. After initialization, the client may send input events such as key presses or mouse movements. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why are the watchdog drivers blacklisted?
On Tue, 09 Feb 2010, Michael Meskes wrote: > > drivers have different defaults, and as far as I recall, some of them > > default to whatever the BIOS or BMC programmed in the watchdog. > > > > A period of 1s would be a much safer default on the userland side. > > Okay, will change. Thanks. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg source format 3.0 (git)
Goswin von Brederlow wrote: > 1) Think about doing this for linux-2.6, XOrg or OOo and what it would > mean for the source size or usability. Indeed, the history is pretty large. A rough estimate (for something less rough, one should use a well packed bundle with only the objects of interest): $ pwd /home/jrn/src/linux-2.6 $ git status -u # On branch next nothing to commit (working directory clean) $ du -sk .git 440664 .git $ du -sk --exclude=.git . 450920 . $ du -sk ../linux-2.6.33-rc7.tar.bz2 64648 ../linux-2.6.33-rc7.tar.bz2 The source package would become about 7 times as large. For usability: I imagine what is typically needed is the set of Vcs-Git fields somewhere conveniently machine-readable, so one could just go apt-get source --git whatever and get a checkout of its packaging repository. That would be the 90% solution. What it doesn’t do is help people with poor connectivity to hack on a package like linux-2.6. Given the high quality of commit messages and the sparsity of comments on the implementation, it is really much easier to work with the history in hand. So it would be nice (though hard) to find some method that allows the git history to be widely mirrored, included on distributed DVDs, and so on. I’m sure the admins of kernel.org would appreciate it as well. > Uploading a new source could then be sending a signed ref to the > maintainers git or sending a signed bundle or even just pushing and > setting a tag. I imagine that would be very nice for people with large packages. Maybe something similar could be accomplished for existing tarball+changes packages by providing a "proxy" git server that runs dpkg-source -b server side. Selfishly, I guess if someone implements the 90% solution above, I would stop caring so much about what source format the buildds use. Others might be more principled, though. ;-) Regards, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569063: ITP: glee -- extension loading library for OpenGL
Package: wnpp Severity: wishlist Owner: Miriam Ruiz * Package name: glee Version : 5.4.0 Upstream Author : Ben Woodhouse * URL : http://elf-stone.com/glee.php * License : BSD Programming Lang: C Description : extension loading library for OpenGL GLee (GL Easy Extension library) is a free cross-platform extension loading library for OpenGL. It provides seamless support for OpenGL functions up to version 3.0 and 399 extensions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569079: ITP: python-xdgapp -- Python XDG application library
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: python-xdgapp Version : 1.1 Upstream Author : Martin Owens * URL : http://launchpad.net/python-xdgapp * License : GPLv3+ Programming Lang: Python Description : Python XDG application library Allows any Python program to access XDG features as a simple xdgApplication object. Also provides access to cache, data and config directories. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: need help of R language expert
Asheesh Laroia asheesh.org> writes: > On Tue, 9 Feb 2010, Atsuhito Kohda wrote: > > I, a maintainer of TeXmacs, have got an FTBFS bug#551254 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551254 > > > > I temporarily remove a problematic patch but clearly it is > > not a real fix. A plugin of R seems not to work anymore. [...] > An R-y friend pointed me toward http://developer.r-project.org/parseRd.pdf > which documents changes to the .Rd format. Correct. R 2.10.0, released in October, switched the documentation parser implementation (from an external one written in Perl to an internal one written in R). At the same time some definitions were tightened. For 'normal' R packages (eg on CRAN) this was transitioned with warnings first that later turned to errors. Ie not unlike what we do with Lintian. Hope this helps. I would be glad to take a look at the Rd file in question if someone could email it my way. Cheers, Dirk (aka the R maintainer, with thanks to Thomas Weber for waving a cluebat my way so that I'd notice this thread) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569085: ITP: extundelete -- extundelete is a utility which recovers deleted files from ext3 and ext4 partitions.
Package: wnpp Severity: wishlist Owner: rich * Package name: extundelete Version : 0.1.8 Upstream Author : Nic Case * URL : http://extundelete.sourceforge.net/ * License : GPLv2 Programming Lang: C++ Description : extundelete is a utility which recovers deleted files from ext3 and ext4 partitions. extundelete is a utility which recovers deleted files from ext4 and ext4 partitions. It extends the work by Carlo Wood on examining the ext3 journal and other metadata for data recovery for efficiency and usability, as well as making use of the ext2fs library. It also extends the work to function on the ext4 filesystem. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#569085: ITP: extundelete -- extundelete is a utility which recovers deleted files from ext3 and ext4 partitions.
On Tue, 9 Feb 2010, rich wrote: Package: wnpp Severity: wishlist Owner: rich * Package name: extundelete Version : 0.1.8 Upstream Author : Nic Case * URL : http://extundelete.sourceforge.net/ * License : GPLv2 Programming Lang: C++ Description : extundelete is a utility which recovers deleted files from ext3 and ext4 partitions. extundelete is a utility which recovers deleted files from ext4 and ext4 partitions. It extends the work by Carlo Wood on examining the ext3 journal and other metadata for data recovery for efficiency and usability, as well as making use of the ext2fs library. It also extends the work to function on the ext4 filesystem. When it's ready, I'd love to sponsor this. -- Asheesh. -- Hate the sin and love the sinner. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569096: ITP: clojure-maven-plugin -- Clojure plugin for Maven
Package: wnpp Severity: wishlist Owner: Peter Collingbourne * Package name: clojure-maven-plugin Version : 1.3.1 Upstream Author : Mark Derricutt * URL : http://github.com/talios/clojure-maven-plugin * License : Apache 2.0, Eclipse 1.0 Programming Lang: Java Description : Clojure plugin for Maven Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. . This package provides a Maven Mojo allowing for programs written using Clojure to be built with Maven. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg source format 3.0 (git)
Jonathan Nieder writes: > Goswin von Brederlow wrote: > >> 1) Think about doing this for linux-2.6, XOrg or OOo and what it would >> mean for the source size or usability. > > Indeed, the history is pretty large. A rough estimate (for something > less rough, one should use a well packed bundle with only the objects > of interest): > > $ pwd > /home/jrn/src/linux-2.6 > $ git status -u > # On branch next > nothing to commit (working directory clean) > $ du -sk .git > 440664 .git > $ du -sk --exclude=.git . > 450920 . > $ du -sk ../linux-2.6.33-rc7.tar.bz2 > 64648 ../linux-2.6.33-rc7.tar.bz2 > > The source package would become about 7 times as large. > > For usability: I imagine what is typically needed is the set of Vcs-Git > fields somewhere conveniently machine-readable, so one could just go > > apt-get source --git whatever > > and get a checkout of its packaging repository. > > That would be the 90% solution. What it doesnât do is help people with > poor connectivity to hack on a package like linux-2.6. Given the high > quality of commit messages and the sparsity of comments on the > implementation, it is really much easier to work with the history in > hand. Then create CD/DVDs of git.d.o. > So it would be nice (though hard) to find some method that allows the > git history to be widely mirrored, included on distributed DVDs, and > so on. Iâm sure the admins of kernel.org would appreciate it as > well. Show the demand and I'm sure mirroring will follow. >> Uploading a new source could then be sending a signed ref to the >> maintainers git or sending a signed bundle or even just pushing and >> setting a tag. > > I imagine that would be very nice for people with large packages. > Maybe something similar could be accomplished for existing > tarball+changes packages by providing a "proxy" git server that runs > dpkg-source -b server side. For non-upstream updates the upload is usualy small. Just the diff.gz or debian.tar.gz file. But yeah, for most upstream changes a pristine-tar upload is much smaller than the full orig.tar.gz. But is that really the problem? > Selfishly, I guess if someone implements the 90% solution above, I > would stop caring so much about what source format the buildds use. > Others might be more principled, though. ;-) > > Regards, > Jonathan MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
